에이전트 시스템 설계

일단 돌아가는 거 하나 만들어보고, 거기서 구성요소를 뜯어보고, 트레이드오프를 이해한 다음에 확장해라. 이게 2장의 핵심이야.

가장 단순한 에이전트의 구조는 모델(LLM이 추론 엔진) + 도구(외부 API나 함수 호출 인터페이스) + 루프(모델이 도구를 쓸지 판단하고 결과를 보고 다음 행동을 결정하는 반복 구조)야. 이게 끝이야. 복잡하게 생각할 거 없이, LLM한테 도구를 주고 반복 루프를 돌리면 그게 에이전트거든. 핵심은 루프인데, 한 번 질문하고 한 번 답하는 게 아니라 모델이 스스로 "아직 끝이 아니네, 이 도구를 한 번 더 써봐야겠다"고 판단해서 계속 돌아가는 구조야.

에이전트 시스템의 핵심 구성요소는 네 가지야. 모델 — 추론과 의사결정을 담당하는 두뇌. 도구 — 외부 세계와 상호작용하는 손과 발. 메모리 — 맥락을 유지하고 경험을 축적하는 기억. 오케스트레이션 — 이 모든 걸 조율하는 지휘자. 이 네 요소는 독립적이 아니라 상호 의존적이야. 모델이 강력하면 도구가 적어도 되고, 메모리가 좋으면 모델이 덜 추론해도 돼. 결국 시스템 설계는 이 네 가지의 밸런스를 찾는 작업이지.

모델 선택에서 실전 팁으로 저자는 모델 라우팅 전략을 언급해. 모든 스텝에 같은 모델을 쓰는 게 아니라, 계획 수립 같은 어려운 단계에는 강한 모델(Opus급), 단순 실행 단계에는 빠르고 싼 모델(Haiku급)을 쓰는 식이야. 비용 최적화에서 꽤 효과적인 패턴이야.

도구는 에이전트가 실제로 세상에 영향을 미치는 유일한 수단이야. LLM 혼자서는 웹 검색도 못 하고, 파일도 못 읽거든. 도구 설계에서 중요한 건 명확한 설명 — Anthropic이 SWE-bench 최적화할 때 프롬프트보다 도구 정의에 더 시간을 썼다는 유명한 사례가 있어. 단일 책임 — 하나의 도구는 하나의 일만. 에러 처리 — 스택 트레이스를 그대로 던지면 모델이 혼란스러워해. **MCP(Model Context Protocol)**도 여기서 나오는데, 도구 연동을 표준화하는 Anthropic의 오픈 프로토콜이야. USB-C처럼 한번 만들면 어디서든 쓸 수 있는 세상을 만들겠다는 거지.

메모리는 단기(컨텍스트 윈도 안의 현재 대화)와 장기(세션을 넘어서 지속되는 정보)로 나뉘어. 장기 메모리는 다시 의미적 메모리(사실과 지식), 에피소드 메모리(과거 경험), 절차적 메모리(작업 수행 방법)로 나뉘고. 핵심 챌린지는 단기 메모리와 장기 메모리 사이의 정보 흐름을 어떻게 설계할 것인가야. 언제 저장하고, 언제 불러오고, 오래된 건 언제 잊을 건지.

오케스트레이션은 모델, 도구, 메모리를 연결해서 실제로 동작하게 만드는 런타임 제어 계층이야. 가장 기본적인 패턴이 ReAct(Reason + Act) 루프 — Thought(추론) → Action(도구 호출) → Observation(결과 관찰), 만족할 때까지 반복.

설계 트레이드오프에서 저자의 핵심 조언은 — 명시적으로 트레이드오프를 인식하고 의도적으로 선택하라는 거야. "몰라서 비싼 모델 쓰는 거"와 "알고도 정확도 때문에 쓰는 거"는 완전히 다른 이야기거든. 에이전트는 루프를 돌기 때문에 단순 LLM 호출 대비 3~10배 비용이 든다는 게 저자의 경험적 수치야.

아키텍처 패턴에서 대부분의 실제 문제는 단일 에이전트로 충분하다는 게 저자의 핵심 조언이야. 멀티 에이전트로 가기 전에 단일 에이전트를 충분히 최적화했는지 먼저 확인해. 멀티 에이전트가 필요하면 계층적, 민주적, 비평가(Actor-Critic), 순차적 패턴 중 상황에 맞는 걸 골라야 하고. 가장 단순한 해결책을 먼저 찾고, 필요할 때만 복잡도를 올려라.

모범 사례로는 점진적 설계(작게 시작, 복잡도를 정당화), 평가 전략(단위/통합/엔드투엔드), 단계적 롤아웃(내부 테스트 → 카나리 → 점진 확대)을 강조해.

---

정리

2장 읽고 기억할 거:

1. 에이전트의 4대 구성요소 — 모델, 도구, 메모리, 오케스트레이션. 이 네 가지의 밸런스가 시스템 설계의 핵심이야
2. 도구 설계가 프롬프트 엔지니어링보다 중요할 수 있어. 도구 이름과 설명을 잘 쓰는 데 시간을 투자해
3. 단일 에이전트부터 시작해. 멀티 에이전트는 멋지지만, 대부분의 실제 문제는 잘 설계된 단일 에이전트가 더 싸고 더 안정적으로 풀어
4. 트레이드오프를 명시적으로 인식해. 성능, 비용, 신뢰성, 확장성 — 전부 다 잡을 수는 없어. 뭘 포기하는지 알고 선택해야 해