에이전틱 디자인 패턴: "에이전트란 도대체 무엇인가"를 다시 이해하게 해준 책

핵심 관점

당신이 쓴 것은 에이전트가 아닐 수 있습니다

책에서 가장 강력한 판단은 서문에 숨겨져 있습니다.

대부분 사람들이 사용하는 "AI"는 단지 Level 0입니다: 맨몸 LLM, 도구도 기억도 행동도 없습니다. 당신이 2025년 아카데미 시상식의 최우수 작품상은 무엇인지 물어보면, 그것은 추측합니다. 책에서는 매우 직설적으로 말합니다: Level 0의 것은 에이전트가 아닙니다.

위로 올라가야 진정한 에이전트입니다:

Level 1: 도구 사용자

에이전트는 도구를 사용하기 시작합니다: 검색, API, 데이터베이스. 하지만 그것은 단순히 "인터페이스를 조정할 수 있다"는 것에 그치지 않고, 언제 조정해야 할지, 무엇을 조정해야 할지, 결과를 어떻게 사용할지를 스스로 판단해야 합니다. 책에서는 매우 구체적인 예를 제공합니다: 사용자가 "최근에 어떤 새로운 드라마가 있나요?"라고 묻는 경우, 에이전트는 이 정보가 훈련 데이터에 없다는 것을 스스로 인식하고, 검색 도구를 사용하여 찾고, 결과를 합성합니다. "스스로 인식"하는 것이 핵심 단계입니다. 인간이 "검색해봐"라고 말하는 것이 아니라, 스스로 검색이 필요하다고 판단합니다. 이 판단 능력이 Level 1의 기준입니다.
Level 2: 전략적 사고자

두 가지가 추가됩니다: 계획과 Context Engineering. 책에서는 Context Engineering을 정의합니다: 정보의 쌓임을 하지 않고, 정교하게 선별하고, 잘라내고, 맥락을 포장하는 것입니다. 예가 매우 기발합니다: 사용자가 두 장소 사이에서 커피숍을 찾고자 할 때, 에이전트는 먼저 지도 도구를 사용하여 많은 데이터를 얻고, 그 다음 "다음 단계에서는 거리 이름만 필요하다"고 판단하여 지도를 잘라 짧은 목록으로 만들고, 이를 지역 검색 도구에 제공합니다. 각 단계에서 정보의 노이즈를 줄이고 있습니다.

책에는 제가 여러 번 읽은 문장이 있습니다: "AI가 최고의 정확도를 달성하려면 짧고 집중적이며 강력한 맥락을 제공해야 한다." Context Engineering은 바로 이 일을 하는 것입니다.

이 수준에 도달하면, 에이전트는 스스로 반성할 수 있습니다. 작업을 마친 후 스스로 검토하고, 문제를 발견하면 스스로 수정합니다. 이 부분은 나중에 자세히 설명하겠습니다.

Level 3: 다중 에이전트 협력

책의 입장은 매우 명확합니다: 전능한 슈퍼 에이전트를 만들려고 하지 마십시오. 진정으로 신뢰할 수 있는 방법은 팀을 구성하는 것처럼, 프로젝트 매니저 에이전트 + 연구원 에이전트 + 디자이너 에이전트 + 카피 에이전트입니다. 책에서 제시한 예는 신제품 출시입니다: "프로젝트 매니저 에이전트"가 총 조정을 하고, "시장 조사 에이전트", "제품 디자인 에이전트", "마케팅 에이전트"에게 작업을 할당합니다. 핵심은 통신입니다: 에이전트 간에 데이터를 어떻게 전달하고, 상태를 어떻게 동기화하며, 충돌을 어떻게 처리하는지. 이 장에서는 가장 간단한 단일 에이전트에서 가장 유연한 사용자 정의 혼합까지 여섯 가지 통신 토폴로지를 그렸으며, 각 유형이 어떤 상황에 적합한지 설명합니다.

이 네 가지 수준을 보고, 많은 사람들이 "내 에이전트는 사용하기 어렵다"고 말하는 이유를 갑자기 이해했습니다. 모델에는 문제가 없지만, 당신이 그것을 채팅 로봇처럼 사용하고 있기 때문에, 그것은 아마도 Level 1에도 도달하지 못했을 것입니다.

Context Engineering: 책에서 가장 과소평가된 개념

저는 Harness Engineering에 대해 쓴 적이 있는데, 이는 트랙 디자인이 엔진의 마력보다 더 중요하다는 내용입니다. 이 책을 읽고 나서, Context Engineering은 Harness Engineering의 프롬프트 측면에서의 매핑이라는 것을 발견했습니다.

전통적인 프롬프트 엔지니어링은 "당신이 어떻게 질문하는가"에만 집중합니다. 책의 Context Engineering은 "질문하기 전에 에이전트 앞에 무엇이 놓여 있는가"를 다룹니다. 이는 네 가지 정보 층을 포함합니다:

첫 번째 층, 시스템 프롬프트. 에이전트가 누구인지, 어떤 어조인지, 어떤 경계가 있는지를 정의합니다. 대부분의 사람들은 이 층만 작성했습니다.
두 번째 층, 외부 데이터. RAG가 검색한 문서, 도구 호출의 반환 값, 실시간 API 데이터. 이는 대부분의 사람들이 막히는 부분입니다: 데이터를 제공해야 한다는 것은 알지만, 어떻게 제공해야 모델이 침수되지 않을지를 모릅니다.
세 번째 층, 암묵적 데이터. 사용자 신원, 상호작용 기록, 환경 상태. 당신이 명시적으로 말하지 않았지만 에이전트가 알아야 할 것들입니다. 예를 들어, 당신이 에이전트에게 "John에게 내일 회의를 확인하는 이메일을 보내줘"라고 말하면, 에이전트는 당신의 달력에 내일의 회의가 무엇인지, 당신과 John의 관계가 무엇인지 알아야 합니다.
네 번째 층, 피드백 루프. 에이전트는 매번 출력을 한 후, 자동으로 품질을 평가하고 다음 번의 맥락 전략을 조정합니다. 책에서는 이를 "자동화된 맥락 최적화"라고 부르며, Google의 Vertex AI Prompt Optimizer는 이 아이디어의 공학적 구현입니다.

제가 여기까지 읽었을 때, 이전에 쓴 "AI 에이전트는 마법이 아니다"라는 글에서 "당신의 에이전트는 규칙이 필요하며, 많은 규칙이 필요하다"는 경험이 떠올랐습니다. 지금 돌아보면, 그 규칙들은 본질적으로 Context Engineering의 수작업 버전이며, 책에서는 이를 시스템화했습니다.

Reflection: 두 개의 에이전트가 하나보다 낫다

이것은 전체 책에서 저에게 가장 실전 가치가 있는 패턴입니다.

Reflection의 핵심은 매우 간단합니다: 에이전트는 작업을 마친 후 스스로 검토하고, 문제를 발견하면 스스로 수정합니다. 하지만 구현 방식에는 주의가 필요합니다. 책에서는 명확히 말합니다: 생산자와 비평가는 반드시 두 개의 다른 에이전트를 사용해야 하며, 서로 다른 시스템 프롬프트를 제공해야 합니다. 같은 페르소나가 자신의 작업을 검토하면 반드시 맹점이 생깁니다. 같은 LLM에게 먼저 코드를 작성하게 한 다음, 자신이 작성한 코드를 검토하게 하면, 그 에이전트는 대개 "괜찮다"고 말할 가능성이 높습니다.

책에서는 완전한 코드 예제를 제공합니다.

생산자의 프롬프트는 "당신은 Python 개발자이며, 경계 조건과 예외를 처리하는 팩토리얼 계산 함수를 작성하십시오"입니다.
비평가의 프롬프트는 "당신은 매우 까다로운 고급 엔지니어이며, 코드를 한 줄씩 검토하고, 버그, 스타일, 누락된 경계 조건, 개선할 점을 확인하십시오. 완벽하다면 CODE_IS_PERFECT를 출력하고, 그렇지 않다면 모든 문제를 나열하십시오"입니다.
그런 다음 for 루프가 있습니다: 생산자가 코드를 작성 → 비평가가 검토 → 생산자가 의견에 따라 수정 → 비평가가 다시 검토 → 비평가가 CODE_IS_PERFECT라고 말하거나 최대 반복 횟수에 도달할 때까지.

그렇게 간단합니다. 하지만 책에서는 쉽게 간과할 수 있는 비용 문제를 상기시킵니다: 매번 반사 루프는 새로운 LLM 호출이며, 반복 횟수가 많아질수록 비용이 증가합니다. 또한 대화 기록이 팽창함에 따라, 맥락 창이 이전 버전과 비평 의견으로 가득 차게 되어 실제로 사용할 수 있는 추론 공간이 줄어듭니다. 따라서 Reflection의 최선의 실천은: 합리적인 최대 반복 횟수를 설정하고(책에서는 3을 사용), 비평가가 만족하면 멈추고, 완벽을 추구하지 마십시오.

용도는 코드 작성에 그치지 않습니다. 글쓰기, 계획 세우기, 문서 요약, 논리 문제 해결 등에서 생산자-비평가 모델을 모두 적용할 수 있습니다. 책에서는 일곱 가지 응용 시나리오를 나열하며, 핵심 논리는 동일합니다: 먼저 생산하고, 그 다음 검토하고, 다시 수정합니다.

다중 에이전트는 복잡할수록 좋은 것이 아니다

Multi-Agent Collaboration 장에서 제가 가장 좋아하는 것은 그 여섯 가지 통신 토폴로지입니다. 많은 사람들이 처음부터 복잡하게 만들지만, 사실 대부분의 상황에서는 세 가지면 충분합니다:

단일 에이전트(독립 실행): 작업을 서로 의존하지 않는 하위 문제로 나눌 수 있으며, 각 에이전트는 자신의 문제를 해결합니다. 간단하고 유지 관리가 쉽습니다.
피어 투 피어 네트워크: 에이전트 간에 직접 통신하며, 중앙 제어 노드가 없습니다. 탈중앙화되어 있으며, 내결함성이 좋고, 하나의 에이전트가 실패해도 전체에 영향을 미치지 않습니다. 하지만 조정 비용이 높고 혼란스러울 수 있습니다.
감독자(중앙 조정): 하나의 감독자 에이전트가 여러 작업자 에이전트를 관리합니다. 작업을 할당하고, 결과를 수집하며, 충돌을 해결합니다. 계층이 명확하고 관리하기 쉽습니다. 하지만 감독자는 단일 실패 지점이며 성능 병목이 될 수 있습니다.

나머지 세 가지(감독자-도구, 계층적, 사용자 정의 혼합)는 앞의 세 가지의 변형 및 조합입니다. 책에서는 매우 현실적으로 말합니다: 당신이 필요한 토폴로지 구조는 작업의 복잡도에 따라 다릅니다. 작업이 점점 더 세분화될수록 통신 비용이 증가하며, 일정 수준에 도달하면 감독자 모델이 오히려 계층적 모델보다 더 효율적일 수 있습니다.

제 경험으로는, 많은 사람들이 Multi-Agent를 구성할 때 통신 프로토콜에 80%의 시간을 소비하고, 더 기본적인 질문을 잊어버립니다: 이 작업이 정말로 여러 에이전트를 필요로 하나요? 책에서는 매우 명확하게 말합니다. Level 2의 단일 에이전트 + Reflection이 종종 대부분의 실제 상황을 커버할 수 있습니다. Level 3는 단일 에이전트가 확실히 해결할 수 없는 상황을 위해 준비된 것입니다.

메모리 3층 모델, 이전에 느꼈지만 이름을 붙이지 못했던 것

Memory 장에서 저는 가장 공감했습니다. 왜냐하면 제가 Obsidian + Claude에 대한 두 편의 글을 쓸 때, 항상 고민하던 질문이 있었기 때문입니다: 에이전트의 기억은 어떻게 층을 나눌까요?

책은 답을 제공합니다:

세션(회차 층): 현재 대화의 맥락 창, 가장 짧은 기억이며 대화가 끝나면 사라집니다. 긴 맥락 모델은 단지 이 창을 확대하는 것일 뿐, 본질적으로는 여전히 임시적이며, 매번 추론할 때마다 전체 창을 처리해야 하므로 비싸고 느립니다.
상태(상태 층): 현재 진행 중인 임시 데이터. 예를 들어 "현재 작업이 무엇인지", "어디까지 완료되었는지", "중간에 생성된 데이터는 무엇인지"입니다. 세션보다 길지만 작업이 끝나면 정리됩니다. 책에서는 Google ADK의 상태 메커니즘을 사용하여 완전한 예제를 제공합니다.
메모리(지속 층): 세션 간, 작업 간의 장기 기억. 사용자 선호, 배운 경험, 중요한 역사적 결정 등을 데이터베이스나 벡터 저장소에 저장하고, 의미적으로 검색합니다. 책에서는 메모리가 단순히 저장하는 것이 아니라, "무엇을 저장할지, 언제 저장할지, 어떻게 검색할지"에 대한 전체 전략을 설계해야 한다는 점을 강조합니다. 너무 많은 것을 저장하면 노이즈가 커지고, 너무 적게 저장하면 부족합니다.

제가 이전에 쓴 Clawdbot에 대한 글에서 "상태 파일"과 "작업 공간 문서"를 언급했는데, 본질적으로는 State 층과 Memory 층을 수작업으로 만드는 것이며, 책에서는 이 작업을 프레임워크화했습니다.

다섯 가지 가정, 다섯 번째는 가장 엉뚱하다

책의 끝에서는 에이전트의 미래에 대한 다섯 가지 가정을 제시합니다. 앞의 네 가지는 여전히 합리적인 추론 범위 내에 있습니다: 범용 에이전트가 코드를 작성하는 것에서 프로젝트를 관리하고, 깊이 개인화된 방식으로 당신의 요구를 능동적으로 발견하며, 구체적인 지능이 화면을 넘어 물리적 세계로 나아가고, 에이전트가 독립 경제 실체가 되는 것입니다.

다섯 번째는 저를 놀라게 했습니다: 변형 다중 에이전트.

당신은 목표만 선언합니다, 예를 들어 "고급 커피를 판매하는 전자상거래 비즈니스를 만들기"입니다. 시스템은 자동으로 결정합니다: 먼저 "시장 조사 에이전트"와 "브랜드 에이전트"를 생성합니다. 데이터를 한 바퀴 돌린 후, 스스로 브랜드 에이전트가 필요 없다고 판단하고, 세 개의 새로운 에이전트로 나눕니다: "로고 디자인 에이전트", "웹사이트 구축 에이전트", "공급망 에이전트". 만약 웹사이트 구축 에이전트가 병목이 된다면, 시스템은 자동으로 세 개의 병렬 에이전트를 복제하여 동시에 다른 페이지를 작업합니다. 이 과정에서 시스템은 각 에이전트의 프롬프트를 지속적으로 자동 조정하며, 팀 구조를 재구성합니다.

책에서는 이를 "목표 주도적, 자기 변형 다중 에이전트 시스템"이라고 부릅니다. 이는 당신이 작성한 계획을 실행하는 것이 아니라, 스스로 계획을 생성하고, 스스로 계획을 조정하며, 스스로 실행 팀을 재구성하는 것입니다.

이것은 Karpathy의 AutoResearch를 떠올리게 합니다: program.md를 작성하고, 목표, 지표, 경계를 정의한 후 "시작"을 누릅니다. 인간은 루프 외부에 있습니다. 하지만 이 책은 더 나아갑니다: 에이전트 팀이 어떻게 구성되고, 어떻게 재구성되는지조차 시스템이 스스로 결정하게 합니다. 인간은 단지 "무엇을 원하느냐"만 선언합니다.

즉시 실행할 수 있는 세 가지 작업

이 책을 읽고 나서, 제가 즉시 실행할 수 있는 세 가지 행동이 있습니다:

첫째, 현재의 에이전트에 비평가를 추가하십시오. Claude Code, CrewAI를 사용하든, 자신이 구성한 프레임워크를 사용하든, 현재의 워크플로우 끝에 한 단계를 추가하십시오: 다른 에이전트(서로 다른 시스템 프롬프트를 사용)가 이전 단계의 출력을 검토하게 하십시오. 코드 생성에 코드 검토를 추가하고, 글 작성에 사실 확인을 추가하며, 계획 수립에 실행 가능성 평가를 추가하십시오. LLM 호출이 한 번 더 늘어나지만, 품질 향상은 종종 두 배가 됩니다. 책의 생산자-비평가 모델은 즉시 사용할 수 있습니다.
둘째, 프롬프트 엔지니어링뿐만 아니라 Context Engineering을 시작하십시오. 에이전트에게 작성한 지시 파일을 다시 살펴보십시오. 만약 전부 "당신은 어떻게 해야 하는가"라는 규칙으로만 구성되어 있다면, "당신이 지금 어떤 환경에 있는가"라는 맥락이 부족합니다. 에이전트에게 현재 어떤 프로젝트에 있는지, 이전에 어떤 결정을 내렸는지, 사용자 선호는 무엇인지 알려주십시오. 책의 Context Engineering 장과 당신의 AGENTS.md는 동일한 작업의 두 가지 표현입니다.
셋째, 다중 에이전트에 서두르지 마십시오. 단일 에이전트를 Level 2로 만드십시오: 도구가 있고, Reflection이 있으며, Memory가 있습니다. 책에서는 반복적으로 강조합니다. Level 2의 단일 에이전트에 생산자-비평가와 Context Engineering을 추가하면, 대부분의 실제 상황을 커버할 수 있습니다. Level 3는 진정으로 다분야, 다단계, 병렬 분업이 필요한 작업을 위해 준비된 것입니다. 대부분의 사람들의 문제는 에이전트가 충분하지 않다는 것이 아니라, 하나의 에이전트조차 제대로 조정하지 못했다는 것입니다.

이 책은 453페이지이며, Springer에서 2025년에 출판됩니다. 코드 예제는 LangChain/LangGraph, Google ADK, CrewAI, OpenAI API를 포함합니다. 서문은 Google Cloud AI VP가 작성했으며, Goldman Sachs CIO의 추천 서문도 있습니다. 의외로 잘 읽힙니다.

하지만 제가 이 책을 추천하는 이유는 "포괄적"이기 때문이 아닙니다. 당신이 이 책을 읽고 나면 한 가지를 깨닫게 될 것입니다: 당신이 지난 반년 동안 에이전트에서 겪었던 시행착오가 이미 누군가에 의해 패턴으로 정리되었습니다. 당신은 더 이상 Reflection을 발명할 필요가 없고, Memory를 어떻게 층을 나눌지 추측할 필요가 없으며, Multi-Agent에 어떤 통신 토폴지를 사용해야 할지 실험할 필요가 없습니다.

누군가 당신을 위해 지도를 그렸습니다. 남은 것은 그 길을 걷는 것입니다.