구글 엔지니어링 디렉터: AI 에이전트를 위한 21가지 디자인 패턴 만들기

핵심 관점

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

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

대부분 사람들이 사용하는 "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에 대한 글에서 "상태 파일"과 "작업 공간 문서"를 언급한 것은 본질적으로 상태 층과 메모리 층을 수작업으로 다루고 있었으며, 책에서는 이 작업을 프레임워크화했습니다.

다섯 가지 가정, 다섯 번째가 가장 황당함

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

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

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

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

이것은 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에 어떤 통신 토폴지를 사용해야 할지 실험할 필요가 없습니다.

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