MarsDawn

에이전트 디자인 패턴 네 가지와 각각이 넘기는 문서

2024년 3월, Andrew Ng은 자신의 뉴스레터 The Batch에서 AI 에이전트의 디자인 패턴 네 가지를 소개했습니다. 리플렉션, 도구 사용, 계획, 멀티 에이전트 협업입니다. 이 패턴들은 보통 에이전트를 만드는 쪽의 시각에서, 모델에서 더 나은 결과를 끌어내는 방법으로 설명됩니다. 이 글은 반대편에서 봅니다. 이런 패턴으로 만들어진 에이전트를 쓴다면, 폴더에는 무엇이 들어오고, 무엇부터 읽어야 할까요?

네 가지 패턴은 Andrew Ng의 것입니다. 각 패턴이 보통 넘기는 문서와 그 안에서 확인할 점은 저희의 추론입니다. 그는 둘 중 어느 것에 대해서도 쓰지 않았고, 이 시리즈에서 사람의 검토를 주장하지도 않습니다.

네 가지 패턴 간단히 보기

Ng은 “Agentic Design Patterns Part 1”에서 이 패턴들을 설명합니다. 요약하면 이렇습니다. 리플렉션에서는 모델이 자기 작업을 검토하고 개선합니다. 도구 사용에서는 웹 검색이나 코드 실행 같은 도구를 호출할 수 있습니다. 계획에서는 여러 단계의 계획을 세워 실행합니다. 멀티 에이전트 협업에서는 여러 에이전트가 일을 나누고 논의합니다.

Part 1에서 그는 코딩 벤치마크 HumanEval에서의 향상을, 그의 팀이 여러 연구 그룹에서 모은 결과로 보여 줍니다. “GPT-3.5(zero-shot)는 48.1%를 맞혔습니다. GPT-4(zero-shot)는 67.0%로 더 낫습니다. 그러나 GPT-3.5에서 GPT-4로의 향상은 반복적인 에이전트 워크플로를 도입했을 때의 향상에 비하면 미미합니다. 실제로 에이전트 루프로 감싸면 GPT-3.5는 최대 95.1%를 달성합니다.” 이 수치는 코딩 벤치마크 하나에 대한 것이고, 95.1%는 최선의 경우(“최대”)입니다. 에이전트 워크플로가 결과물을 개선할 수 있다는 것을 보여 줄 뿐, 그것을 누가 확인하는지에 대해서는 아무것도 말하지 않습니다.

여기서부터 문서와 확인 사항은 Ng이 아니라 저희의 해석입니다. 또한 실제 에이전트는 여러 패턴을 섞어 씁니다. 코딩 에이전트는 한 세션 안에서 계획을 세우고, 도구를 실행하고, 자기 작업을 검토하기도 하므로 네 종류의 파일을 모두 받게 되는 경우가 많습니다.

1. 리플렉션: 이미 스스로 검토를 거친 초안

리플렉션에 관한 Ng의 글은 이 패턴을, 원래라면 사람이 했을 피드백을 자동화하는 것으로 설명합니다. “비판적 피드백을 주는 단계를 자동화해서, 모델이 자기 출력을 자동으로 비판하고 응답을 개선하게 하면 어떨까요?”

보통 넘기는 것: 수정된 문서. 때로는 자기 평가 섹션이나 “엣지 케이스를 다시 확인함” 같은 문장이 붙어 있습니다.

확인할 점: 에이전트의 자기 비판이 아니라 여러분의 요청과 결과를 비교하세요. 자기 평가도 나름의 방식으로 틀릴 수 있습니다. Chip Huyen은 이렇게 말합니다. “흥미로운 계획 실패 유형 하나는 리플렉션의 오류에서 비롯됩니다. 에이전트가 작업을 완료하지 않았는데도 완료했다고 확신하는 것입니다.” 당시 OpenAI에 있던 Lilian Weng은 2023년 6월 블로그 Lil’Log에서 그 시기의 모델에 대해 이렇게 썼습니다. “전문 지식이 부족하면 LLM은 자기 결함을 알지 못하고, 따라서 작업 결과가 옳은지 제대로 판단하지 못할 수 있습니다.” (그가 소개한 연구에서는 LLM의 결과 평가와 인간 전문가의 평가가 일치하지 않았습니다.) “확인됨”이라고 쓰여 있다면, 하나는 직접 확인하세요.

2. 도구 사용: 무엇을 실행했는지에 대한 보고

보통 넘기는 것: 에이전트가 무엇을 실행하거나 검색했고 무엇이 나왔는지에 대한 요약. “테스트 스위트를 실행함: 모두 통과.” 결과 표. 찾아낸 링크들.

Anthropic의 가이드는 도구 결과를 에이전트가 스스로를 확인하는 수단으로 설명합니다. “실행 중에는 에이전트가 진행 상황을 평가하기 위해 각 단계에서 환경으로부터 ‘실측 정보’(도구 호출 결과나 코드 실행 등)를 얻는 것이 중요합니다.” 그 확인은 에이전트 내부에서 일어납니다. 여러분에게 도착하는 것은 그에 대한 에이전트의 설명입니다.

확인할 점: 모든 주장이 여러분이 볼 수 있는 출력으로 거슬러 올라가는지. 요약에 있는 숫자 하나를 실제 출력과 비교하세요. 링크 하나를 열어 보세요.

3. 계획: plan.md

보통 넘기는 것: 계획, 명세, 에이전트가 하나씩 체크해 나가는 작업 목록.

Ng은 Part 4에서 이 패턴에 대해 솔직하게 말합니다.

“한편으로 계획은 매우 강력한 능력이지만, 다른 한편으로는 결과를 예측하기 어렵게 만듭니다. 제 경험상 리플렉션과 도구 사용이라는 에이전트 디자인 패턴은 안정적으로 작동시켜 애플리케이션의 성능을 높일 수 있지만, 계획은 아직 덜 성숙한 기술이라 그것이 무엇을 할지 미리 예측하기가 어렵습니다.”

그는 낙관적이기도 합니다. “하지만 이 분야는 계속 빠르게 발전하고 있으며, 계획 능력도 빠르게 향상될 것이라고 확신합니다.”

확인할 점: 실행되기 전의 계획. 5분 검토법으로 구조, 주장 하나, 되돌릴 수 없는 단계, 다이어그램, 범위를 확인하세요. 에이전트가 도중에 계획을 다시 쓰면 승인한 버전과 비교하세요. git으로 관리 중이라면 git diff plan.md로 무엇이 바뀌었는지 볼 수 있습니다. MarsDawn에서는 개요 탭으로 긴 계획의 구조를 볼 수 있고, 다시 쓰인 계획은 저장하지 않은 변경 사항이 없는 한 읽던 위치를 잃지 않고 다시 불러옵니다.

4. 멀티 에이전트 협업: 여러 파일, 여러 작성자

보통 넘기는 것: 한 에이전트의 명세, 다른 에이전트의 구현 노트, 세 번째 에이전트의 검토, 그리고 그 사이를 오가는 요약. 각자 자기 브랜치나 worktree에서 작업하기도 합니다.

확인할 점: 인계 지점. 한 에이전트가 다른 에이전트의 작업을 요약한 곳에서 빠진 요구 사항이 없는지 찾아보세요. 서로 모순되는 두 파일을 찾고, 누군가 다른 쪽을 바탕으로 작업하기 전에 어느 쪽이 기준인지 정하세요. MarsDawn에서 파일 ▸ 폴더 열기…(⇧⌘O)로 공유 폴더를 열면, 에이전트가 새 파일을 쓰는 대로 1초 정도 안에 파일 탭에 나타나고, git 체크아웃에서는 헤더에 브랜치나 worktree가 표시되므로 서로 다른 브랜치에서 같은 이름의 파일을 연 두 창이 똑같아 보이지 않습니다. Markdown을 읽지 않는 사람들에게 결과를 전달해야 한다면 내보낸 PDF 공유하기에서 그 단계를 다룹니다.

한눈에 보기

패턴(Ng)보통 넘기는 것(저희의 추론)먼저 읽을 것(저희의 제안)
리플렉션수정된 초안, 경우에 따라 자기 평가 포함요청 대비 결과, “확인됨” 하나 직접 검증
도구 사용무엇을 실행했고 무엇이 나왔는지에 대한 보고주장 하나를 실제 출력까지 추적
계획plan.md, 명세, 작업 목록실행 전 5분 검토
멀티 에이전트 협업여러 에이전트의 여러 파일, 경우에 따라 여러 브랜치인계 지점과 기준이 되는 파일

여기 인용된 저자 중 누구도 MarsDawn을 언급하거나 추천하지 않으며, 다른 어떤 Markdown 도구도 추천하지 않습니다. MarsDawn에는 AI 모델이 들어 있지 않습니다. 어떤 모델이 파일을 만들었는지 알지 못하고, 이런 확인을 대신 해 주지도 않습니다. 여러분이 확인하는 동안 파일을 읽기 쉽게 유지해 줄 뿐입니다.

사용해 보기

MarsDawn은 Mac App Store에 있습니다. 무료 명령줄 도구 marsdawn도 있습니다.

brew install redtear1115/tap/marsdawn

앱 없이 Markdown을 PDF로 내보냅니다. Markdown을 PDF로를 참고하세요.

명령줄 · 구매 전에 알아 두세요: MarsDawn이 하지 않는 것

더 읽어 보기

출처