목차
에이전트 아키텍처는 멋있어 보이는 패턴을 고르는 문제가 아니라, 태스크의 구조와 실패 비용에 맞는 최소 패턴을 고르는 문제다. 결정 트리 접근은 ReAct, Planning, Reflection, Multi-Agent를 감으로 선택하지 않고 질문 순서로 좁혀 간다.
5가지 질문
| 질문 | 예이면 | 아니면 |
|---|---|---|
| 1. 해결 경로가 미리 알려져 있는가? | 고정 워크플로를 우선 검토 | 적응형 에이전트 필요 |
| 2. 외부 도구나 최신 정보가 필요한가? | 툴 사용을 기본 레이어로 둔다 | 단순 추론·생성으로 충분할 수 있다 |
| 3. 실행 전에 구조를 설명할 수 있는가? | Planning + 단계별 ReAct | 단일 ReAct로 탐색 |
| 4. 품질이 속도보다 중요한가? | Reflection 추가 | 추가 비평 루프 생략 |
| 5. 전문화나 규모 문제가 있는가? | Multi-Agent 고려 | 단일 에이전트 유지 |
패턴별 사용 지점
Single Agent + Tools + ReAct
해결 경로가 실행 중에 드러나고 도구 호출이 필요한 일반 업무의 기본값이다. 디버깅, 조사, 고객지원처럼 다음 행동이 이전 관찰에 따라 달라질 때 적합하다.
Planning Agent + ReAct Execution
큰 단계와 의존성은 미리 보이지만 각 단계 내부에 불확실성이 있는 경우에 쓴다. 기능 개발, 리서치 보고서, 온보딩 자동화처럼 “계획은 가능하지만 실행은 적응적”인 작업이 여기에 해당한다.
Single Agent + Reflection
최종 산출물 품질이 중요하고 검증 기준이 명확할 때 추가한다. SQL, 코드, 계약서 검토, 외부 공개 문서처럼 오류 비용이 높고 한 번 더 비평할 시간이 있는 경우다.
Multi-Agent Specialist System
서로 다른 전문성이 필요하거나 한 컨텍스트에 담기 어려운 규모일 때만 쓴다. 법무·재무·코딩·보안 검토처럼 역할별 판단 기준이 다르거나 병렬 실행이 실제 시간을 줄일 때 효과가 있다.
실패 신호와 수정 방향
| 신호 | 의미 | 수정 |
|---|---|---|
| ReAct가 같은 단계를 반복한다 | 진행 상태와 종료 조건이 불명확하다 | 계획, 상태 머신, 더 나은 도구 계약 추가 |
| 계획을 계속 버린다 | 문제 구조를 너무 고정적으로 봤다 | 가벼운 계획 + ReAct로 낮춘다 |
| Reflection이 품질을 못 올린다 | 평가 기준이 모호하거나 비평자가 생성자와 너무 비슷하다 | 체크리스트·테스트·다른 모델 비평 사용 |
| 멀티에이전트 라우팅이 흔들린다 | 전문가 선택이나 합성 로직이 약하다 | 예측 가능한 경우 LLM 라우팅 대신 결정 규칙 사용 |
실무 원칙
처음부터 멀티에이전트로 시작하지 말고 단일 에이전트가 실패하는 구체적인 병목을 먼저 확인한다. 패턴은 고정된 제품 구조가 아니라 시작점이다. 운영 로그와 평가 결과가 쌓이면 계획, 비평, 전문화 레이어를 점진적으로 더한다.
관련 문서
- agent-harness — 에이전트 하네스 설계 방법론
- long-running-agents — 장기 실행 에이전트 패턴
- subagent-tips-patterns-2026 — 서브에이전트 아키텍처 패턴
참고 자료
- Choosing the Right Agentic Design Pattern: A Decision-Tree Approach — Machine Learning Mastery (2026-05-13)