[26/1/8~]Agentic Design Patterns: a hands-on guide to building intelligent systems

0. 이 책이 말하는 “에이전트 시스템”의 핵심 관점

에이전트 시스템 정의(요약)

에이전트 시스템은 “단순 응답기”가 아니라,
• 환경을 인지(perceive)하고
• 목표/상태에 기반해 의사결정(decide)하며
• 도구·API·외부시스템을 호출해 행동(act)하고
• 상호작용/히스토리를 기억(memory)하며
• 사용자·시스템·다른 에이전트와 커뮤니케이션하는 시스템으로 설명합니다.  

여기서 중요한 건 LLM이 ‘두뇌’라면, 패턴은 그 두뇌가 안정적으로 일하도록 만드는 ‘구조(아키텍처)’라는 점입니다. 

---

Chapter 1. Prompt Chaining (패턴: 파이프라인/체이닝)

 

 

1) 패턴 요지

복잡한 작업을 한 번에 풀지 말고, 여러 개의 작은 단계로 쪼개 “연쇄 호출”로 해결하는 패턴(파이프라인 패턴으로도 언급).  

2) 언제 쓰나 
• 단일 프롬프트로는 정확도/일관성이 떨어질 때
• 단계 사이에 도구 호출/검증/정규화가 필요할 때
• “멀티스텝 추론 + 상태 유지”가 필요할 때  

3) 설계 포인트 

(A) “단계 경계”를 어떻게 자를까
• 좋은 체인은 단계마다 입출력 계약(contracts)이 명확합니다.
• 예: extract_entities -> validate_constraints -> retrieve_policies -> draft_answer -> format_output
• 각 단계 출력은 자연어 덩어리가 아니라, 가능하면 구조화(JSON/스키마)로 다음 단계가 안정적으로 소비하게 만듭니다.

(B) 중간 산출물 검증이 품질을 좌우
체인은 오류가 누적되기 쉬워서, 중간에 최소한 하나는 넣는 게 좋습니다.
• 스키마 검증(필수 필드 누락/타입 불일치)
• 금칙/정책 위반 검사
• 근거 존재성 체크(RAG면 “근거 청크 id 반드시 포함” 같은 룰)

(C) 비용/지연 최적화 기본기
• 단계별 캐시(동일 입력이면 중간결과 재사용)
• 저렴한 모델→비싼 모델 계단식(초기 단계는 라우팅/정규화용)
• 단계별 토큰 예산을 강제(장문 생성은 마지막 단계로 몰기)

4) 대표 실패 모드와 처방
• 누적 드리프트: 앞 단계가 조금 틀리면 뒤가 크게 틀어짐
→ 중간 검증 + “불확실하면 질문하기” 단계 삽입
• 컨텍스트 비대화: 단계가 늘수록 히스토리 커짐
→ 단계별로 필요한 요약만 전달(상태 요약/핵심 변수만)
• 스텝 과분해: 너무 잘게 쪼개면 비용/지연만 증가
→ “결정이 필요한 지점”에만 단계를 둠(결정이 없으면 합치기)

5) 핵심 요약

Prompt Chaining은 “divide-and-conquer”로 신뢰성과 제어력을 높이고, 멀티스텝 추론/도구통합/상태관리를 가능하게 하는 기본 패턴으로 정리됩니다.  

 

 

---

Chapter 2. Routing (패턴: 조건 분기/동적 경로 선택)

 

1) 패턴 요지

체이닝이 “선형”이라면, 라우팅은 상황에 따라 다른 경로(도구/서브프로세스/서브에이전트)를 선택하게 하는 패턴입니다. 현실 에이전트는 입력·환경 상태·이전 결과에 따라 다른 액션 후보를 중재해야 하고, 그 메커니즘이 라우팅이라고 설명합니다.  

2) 구현 형태(현업에서 바로 쓰는 3종 세트)

(A) Rule-based Router (가드레일 우선)
• 정규식/키워드/엔터티 기반 라우팅
• 장점: 예측 가능, 보안/정책 강함
• 단점: 커버리지 확장 비용

(B) Classifier/LLM Router (유연성 우선)
• 의도 분류(cheap 모델) → 목적지 선택
• 장점: 신규 의도에 강함
• 단점: 오분기가 치명적이라 “신뢰도 임계치 + fallback” 필수

(C) Hierarchical Router (대규모 기능 확장)
• 1차: 도메인(예: “계좌/대출/외환/오류”)
• 2차: 작업유형(조회/변경/신청/상담)
• 3차: tool/agent 선택
이 구조가 복잡한 엔터프라이즈 에이전트에서 특히 안정적입니다.

3) 책의 예시 포인트(“Coordinator → sub-agents”)

코디네이터(상위 에이전트)가 들어온 요청을 분석해서 Booker / Info 같은 전문 서브 에이전트에 위임하는 구조를 보여주며, 프레임워크가 서브에이전트 정의를 바탕으로 자동 위임 흐름을 처리하는 식으로 설명합니다.  

4) 라우팅에서 가장 흔한 실패 모드 & 처방
• Misrouting(오분기): 다른 툴/에이전트로 가서 엉뚱한 행동
→ (필수) confidence threshold, (필수) unclear/fallback handler, (권장) “추가 질문” 루트
• Routing oscillation(왔다갔다)
→ 상태에 “이미 시도한 경로” 기록 + 재시도 제한
• Prompt injection으로 라우팅 탈취
→ 라우터는 “유저 지시”보다 “시스템 정책/툴 스키마”를 우선, 입력을 안전 필터링한 뒤 분기

5) 핵심 요약

Routing은 에이전트가 상황별로 맞춤 행동을 하게 만드는 핵심 구성요소이며, LangGraph는 상태/전이를 명시적으로, ADK는 도구/핸들러 중심으로 라우팅을 단순화할 수 있다고 정리합니다.  

---

Chapter 3. Parallelization (패턴: 팬아웃/팬인 병렬 실행)

 

1) 패턴 요지

독립적인 서브태스크(LLM 호출, 툴 호출, 서브에이전트 작업)를 동시에 실행해 전체 지연을 줄이는 패턴입니다.  

2) 전형적인 구조(실전 설계)
• Fan-out: (동시에) search A, search B, search C
• Join barrier: 모두 완료 대기 + 타임아웃/부분성공 규칙
• Fan-in: 결과를 정규화→통합→최종 생성(대개 마지막은 순차)

책에서도 “소스 A/B를 동시에 검색·요약 후 합성” 같은 예로 설명합니다.  

3) 병렬화의 숨은 비용
• Rate limit / 비용 폭증: 병렬은 QPS를 순간적으로 올림
• 결과 불일치: 서로 다른 서브결과가 충돌(팩트/정의/단위)
• 조인 실패: 일부 태스크 실패 시 전체 실패로 번짐

처방(운영 레벨)
• max_concurrency(동시 실행 상한)
• timeout + partial results 허용 정책
• 결과를 합치기 전에 스키마 정규화 + 중복 제거
• 합성 단계에서 컨센서스 전략(vote / rank / cite-only merge)

4) 핵심 요약

병렬 처리는 Chaining/Routing과 조합될 때 고성능 워크플로를 만들 수 있고, ADK는 멀티에이전트 위임으로 병렬화를 달성할 수 있다고 요약합니다.  

---

Chapter 4. Reflection (패턴: 자기평가/비평 루프)

 

1) 패턴 요지

에이전트의 첫 출력은 종종 부정확/불완전/요건 미충족이므로, 결과를 스스로 평가하고 개선하는 피드백 루프를 넣는 패턴입니다. 단순 체이닝/라우팅과 달리 “생성 → 검토 → 개선” 반복 루프가 핵심이라고 설명합니다.  

2) 두 가지 대표 아키텍처

(A) Self-reflection (단일 에이전트)
• 같은 모델이 “내가 쓴 답”을 다시 읽고 개선
• 장점: 구현 간단
• 단점: 자기확증/편향, 놓치는 오류

(B) Producer–Critic (분리형)
• Producer가 초안을 만들고, Critic이 **명시적 기준(rubric)**으로 평가한 뒤 수정 지시
• 장점: 품질/객관성↑, 역할 분리로 유지보수↑
• 책은 “critic 에이전트를 두면 초기 응답이 품질과 무관하게 최종이 되는 것을 막는다”는 취지로 설명합니다.  

3) Reflection 루프 설계의 핵심은 “종료 조건”

루프는 잘못 만들면 끝이 없습니다. 실전에서는 아래를 세트로 둡니다.
• max_iters
• budget_stop(비용/시간)
• delta_stop(수정 폭이 임계치 미만이면 종료)
• criteria_pass(rubric 통과)

4) 책이 강조하는 트레이드오프(운영 관점)

Reflection은 품질을 올리지만,
• 반복 호출로 비용/지연 증가
• 반복 누적으로 메모리(컨텍스트) 증가
→ 속도·비용보다 품질·정확도가 중요할 때 쓰라고 정리합니다.  

5) 실패 모드 & 처방
• 끝없는 개선(루프 폭주) → 종료 조건/예산 강제
• Critic이 근거 없이 트집 → Critic에게도 “근거 기반 지적만” 룰 + 필요 시 툴(검증) 부여
• 환각 교정(틀린 비평을 반영해 더 나빠짐) → “검증 가능한 지적만 반영”, 또는 외부 평가(테스트셋/룰)로 게이트