Section 1모델만으로는 부족해지는 순간
오늘날의 생성형 AI 모델 — GPT-4, Claude, Gemini와 같은 대규모 언어 모델(LLM) — 은 문단 요약, 개체 추출, 코드 생성에서 탁월하다. 그러나 과업이 장시간에 걸치고, 여러 단계를 수반하며, 다양한 관점을 요구하고, 동적인 해결 공간을 탐색해야 할수록 모델 단독으로는 충분하지 않다.
책은 과업을 세 가지 복잡성 수준으로 가른다. 이 분류가 책 전체를 관통하는 사고의 골격이다.
"프랑스의 수도는?"처럼 학습 데이터의 일반 지식 사실로 답할 수 있거나, 웹 검색 같은 기존 시스템으로 처리되는 단순 정보 검색. 계획 수립도, 툴도, 적응도 필요 없다. 모델을 직접 호출하면 끝난다.
"오늘 NVIDIA 주가는?" — 학습 중 접한 적 없는 정보다. 모델 단독이라면 그럴듯하지만 부정확한 값을 지어낸다(환각, hallucination). 이 과업은 질의 이해, 계획 수립(데이터를 가져오고 분석하는 단계 분해), 행동(웹 검색·API 호출), 결과 제시를 요구한다. 바로 여기서 에이전트가 필요하다 — 모델의 추론과, 우리를 대신해 행동하는 툴을 결합한 시스템.
"주가 조회·매수·세금 신고가 가능한 모바일 앱을 구축하라" — 유능한 단일 에이전트조차 효과적으로 다룰 수 없다. 인터페이스 디자인, 안드로이드 개발, API 활용, 통합 테스트 등 여러 유형의 전문성이 필요하고, 행동 결과에 따라 다음 단계가 결정되는 반복적 해결이 요구된다.
에이전트 — 추론하고, 툴을 사용해 행동하며, 의사소통하고, 적응할 수 있는 AI 시스템. 다중 에이전트 시스템 — 각자 전문화된 역량을 갖춘 여러 에이전트가 협업하여 과업을 해결하는 시스템. 툴 — API, 코드 실행, 웹 검색처럼 에이전트의 능력을 확장하는 외부 기능.
복잡한 과업의 네 가지 특성
다중 에이전트 접근을 정당화하는 과업은 일반적으로 네 가지 특성을 보인다. 하나만으로도 복잡도가 오르지만, 가장 큰 기회는 이들의 조합에서 나온다.
- 계획 수립(Planning) — 과업을 일련의 단계로 분해하고 전략적으로 사고해야 한다. 로봇공학 계획 문헌에서 잘 연구된 속성이다.
- 다양한 전문성 — 단계마다 서로 구별되는 도메인 지식이 필요하다. 이는 단일 에이전트가 일반적 지시만으로는 달성하기 어려운 관심사의 분리를 가능케 한다.
- 광범위한 컨텍스트 — 방대한 정보를 처리해야 한다. LLM은 텍스트 앞·끝에는 주의를 기울이나 가운데 데이터는 소홀히 다루는 경향(Liu et al. 2024)이 있고, 인지 부하 이론(Sweller 1988)이 시사하듯 작업 기억은 과부하된다. 다중 에이전트는 선택적 컨텍스트 제공으로 이를 다룬다.
- 적응적 해결 방안 — 정확한 해법이 행동을 취하기 전까지 불확실한 동적 환경. 해법은 에이전트가 계획·행동·결과를 가로질러 반복 추론하는 과정에서 솟아난다.
YCombinator의 5,622개 기업 분석에 따르면, AI 에이전트를 구축하는 스타트업 비중은 2020년 6.1%에서 2025년 47.7%로 — 5년 만에 7.8배 — 늘었다. 업계가 보조 도구의 단계를 넘어 완전 자율 시스템으로 이동하고 있다는 신호다.
Section 2에이전트란 무엇인가
고전적 정의(Russell & Norvig)에서 에이전트는 센서로 환경을 지각하고 액추에이터로 행동하며, 지각을 행동에 매핑하는 에이전트 함수로 작동한다. 로봇 청소기가 그 예다 — 장애물→회피, 먼지→청소, 배터리 부족→충전이라는 사전 정의된 논리.
생성형 AI 에이전트는 동일한 지각-행동 사이클을 유지하되, LLM이 뒷받침하는 복잡한 추론, 동적 툴 사용, 자연어 의사소통, 적응적 행동을 더한다. 책의 정의: 에이전트란 추론하고, 행동하며, 의사소통하고, 적응하여 문제를 해결하는 개체다.
네 가지 핵심 역량
가용한 컨텍스트에 규칙·논리를 적용해 새 정보를 종합한다. 연역·귀납·가설추론일 수 있다. "오늘의 NVIDIA"가 과거 정보가 아닌 현재 시장 데이터를 요구한다는 사실을 이해하는 일.
환경에 영향을 주거나 정보를 수집하기 위한 구체적 행동. 코드 실행, API 호출, 웹 검색, 외부 시스템 상호작용 — 단순한 텍스트 생성을 넘어선다.
사용자·다른 에이전트·외부 시스템과 효과적으로 정보를 교환한다. 자연어 이해, 응답 형식화, 명확화 요청 시점 판단을 포함한다.
피드백·변화·새 정보에 따라 접근을 수정한다. 비율 제한으로 API 호출이 실패하면 대기 후 재시도하거나 대안 소스로 전환한다.
세 가지 핵심 구성 요소
- 모델 — 의사결정과 계획 수립을 가능하게 하는 추론 엔진. 에이전트의 "두뇌". 생성형 AI 모델, 사전 정의 논리, 명시적 인간 입력이 결합될 수 있다.
- 툴 — 특정 과업을 수행하는 논리의 구체적 구현물. 범용 툴(코드 실행기, UI 드라이버)과 도메인 특화 툴(날씨 API 호출)로 나뉜다.
- 메모리 — 과거 상호작용에서 정보를 회상·재활용하는 능력. 단기 메모리(현재 과업의 작업 메모리)와 장기 메모리(세션을 가로지른 축적 지식)로, 또 누가 통제하는가에 따라 애플리케이션 관리와 에이전트 관리 메모리로 갈린다.
에이전트와 모델은 모두 자연어를 처리하지만 근본적으로 다르다. 모델은 학습 데이터로 텍스트를 처리·생성하는 데 그치고, 에이전트는 행동을 취하고 툴을 사용하며 컨텍스트를 유지하고 결과에 적응한다. 단일/다중 에이전트의 경계도 종종 흐릿하다 — 어떤 에이전트는 그 자체가 에이전트인 툴을 쓰고, 하나처럼 보이는 시스템이 내부적으로 여러 하위 에이전트를 조율할 수 있다.
Section 3다중 에이전트 시스템의 정의
다중 에이전트 시스템이란 다양한 역량과 특화된 목표를 지닌 일군의 에이전트들이 협업하여 과업을 해결하는 애플리케이션이다. 이를 구별 짓는 핵심은 그 오케스트레이션 메커니즘이다.
오케스트레이션이란 여러 에이전트가 공동 목표를 향해 효과적으로 함께 일하도록 하는 메커니즘과 패턴이다. 두 가지 측면을 포함한다 — 그들이 정보를 어떻게 공유하는가, 그리고 누가 실행의 흐름(행동 순서)을 통제하는가. 학술 문헌은 "조율(coordination)"과 같은 의미로도 쓰지만, 이 책은 산업 표준에 맞춰 "오케스트레이션"을 주된 용어로 삼는다.
Section 4두 가지 오케스트레이션 접근법
다중 에이전트 시스템은 근본적으로 다른 두 방식으로 조직된다. 두 접근 모두 동일한 핵심 해부 구조(모델·메모리·툴)를 가진 에이전트를 쓰지만, 오케스트레이션 결정이 내려지는 방식에서 갈라진다.
| 차원 | 다중 에이전트 워크플로우 | 자율적 다중 에이전트 |
|---|---|---|
| 제어 흐름 | 사전 정의 — 정해진 시퀀스와 핸드오프 | 런타임 동적 결정 — AI 모델이 주도 |
| 오케스트레이션 논리 | 명시적으로 프로그래밍됨 | 에이전트 간 상호작용으로부터 창발 |
| 제공하는 가치 | 예측 가능성·신뢰성 | 적응성·혁신성 |
| 적합한 과업 | 잘 정의되고 반복 가능한 프로세스 | 최적 전략을 사전에 정할 수 없는 복잡한 과업 |
| 모듈 구현 | picoagents.workflow | picoagents.orchestration |
Section 5적합한 아키텍처 선택하기
AI 애플리케이션 구축은 아키텍처 스펙트럼에서 적절한 복잡도를 고르는 일이다. 의사결정은 다루는 과업의 특성을 따라 논리적 흐름으로 진행된다.
- 근본 질문 — 과업이 텍스트 생성을 넘어선 행위를 요구하는가? 아니라면 모델을 직접 호출하라.
- 해결 방식이 알려져 있는가? — 단계와 수행 방식이 명확하면 워크플로우로 표현 가능하다.
- 전문화된 역량이 필요한가? — 그렇다면 다중 에이전트 워크플로우. 하나의 전문성으로 충분하면 단일 에이전트가 효율적이다.
- 탐험이 필요한가? — 해법이 탐험과 동적 상호작용을 통해 비로소 드러난다면 자율적 다중 에이전트 시스템.
요구사항을 효과적으로 충족하는 가장 단순한 아키텍처를 선택하라. 정교함의 단계가 올라갈수록 능력과 적응성을 얻지만, 추가 복잡도·개발 시간·잠재적 실패 지점이 따라붙는다. 확신이 없으면 단순하게 시작하고 진화시켜라.
10.6절의 평가가 이를 뒷받침한다 — 단순 추론 과제에서 직접 모델 호출은 다중 에이전트 대비 24배 높은 토큰 효율로 9.7/10을 기록했고, 다중 에이전트는 툴 조율이나 전문화 역량이 필요할 때에만 오버헤드를 정당화했다(웹 검색 리서치: 직접 모델 3.2/10 vs 툴 에이전트 9.0/10).
Section 6첫 다중 에이전트 시스템 — 시인과 비평가
책 전체에서 우리는 picoagents라는 다중 에이전트 라이브러리를 처음부터 함께 만든다. 맛보기로 시인-비평가 협업 시스템을 라운드 로빈 오케스트레이션으로 구축한다. 핵심 아이디어 — 비평가의 피드백이 시인의 결과물을 반복적으로 개선한다.
# 두 전문화된 에이전트 생성 poet = Agent( name="poet", instructions="You are a haiku poet.", model_client=client) critic = Agent( name="critic", instructions="You are a haiku critic. Give 2-3 actionable suggestions, or reply 'APPROVED'.", model_client=client) # 종료 조건 — 8개 메시지 또는 'APPROVED' 언급 termination = (MaxMessageTermination(max_messages=8) | TextMentionTermination(text="APPROVED")) # 라운드 로빈 오케스트레이터 orchestrator = RoundRobinOrchestrator( agents=[poet, critic], termination=termination, max_iterations=4) async for message in orchestrator.run_stream(task): print(message)
RoundRobinOrchestrator는 차례를 주고받는 루프를 관리하고, 종료 조건은 대화가 적절한 시점에 마무리되도록 보장한다. serve() 함수로 감싸면 브라우저에서 협업을 실시간으로 지켜볼 수 있는 웹 UI가 열린다. 이 모든 구성 요소 — Agent 클래스, RoundRobinOrchestrator, model_client, 종료 조건 — 는 4장 이후 처음부터 함께 쌓아 올린다.