멀티 에이전트 협업

OpenAI는 한때 AI 능력을 다섯 단계로 분류했습니다. 1단계 대화자, 2단계 사고자, 3단계 에이전트, 4단계 혁신가, 5단계 조직입니다. 멀티 에이전트 협업은 흔히 5단계로 가는 한 경로로 제시됩니다. 하지만 여기서 ‘조직’은 아키텍처 요구 사항이 아니라 조직 전체의 업무를 수행할 수 있는 AI라는 능력 수준을 뜻합니다. 이론적으로는 충분히 강력한 단일 에이전트도 이 수준에 도달할 수 있습니다. 다만 오늘날 엔지니어링 현실에서 단일 에이전트는 모델의 능력과 컨텍스트 창에 여전히 제약받습니다.

여러 에이전트를 함께 일하게 하는 일은 서로 다른 전문성을 지닌 전문가가 ‘서로의 부족함을 메우는 것’보다 훨씬 큰 의미가 있습니다. 더 근본적인 요점은 집단의 지능이 어느 개인의 지능보다도 뛰어날 수 있다는 것입니다. 인간 문명이 그 증거입니다. 한 사람의 지성에는 한계가 있지만 분업, 협업, 토론, 세대에 걸친 지식 축적을 통해 인간 사회 전체는 어느 천재 한 명보다 훨씬 높은 지능을 보여 줍니다. 에이전트 집단에서도 같은 종류의 집단 지능이 나타날 수 있습니다. 각 에이전트가 인간 전문가 수준에 불과해도 잘 조직된 집단은 모든 인간 전문가를 합친 능력을 넘어설 수 있습니다. Google DeepMind는 From AGI to ASI에서 ‘대규모 멀티 에이전트 집단’을 초지능(ASI)에 이르는 핵심 경로로 꼽습니다. 인간의 일반 지능이 개인을 넘어서는 사회와 조직으로 모이듯, AGI 수준 에이전트 다수가 협력하여 만드는 집단 지능도 구성원을 단순히 합한 것보다 훨씬 높은 인지 능력을 보일 수 있습니다¹. 따라서 멀티 에이전트 협업은 단일 모델의 컨텍스트 창과 능력 한계를 보완하는 엔지니어링 우회책에 그치지 않습니다. ‘전문가 수준 AI’에서 ‘인류 전체를 넘어서는 AI’로 가는 근본 경로일 수 있습니다.

멀티 에이전트 협업의 분류 프레임워크

멀티 에이전트 시스템 구축은 기본 아키텍처와 구현을 함께 결정하는 두 가지 핵심 설계 차원에서 시작합니다.

차원 1: 공유 컨텍스트와 비공유 컨텍스트

여러 에이전트 사이에서 정보를 전달하는 방식을 정하는 가장 근본적인 아키텍처 결정입니다.

공유 컨텍스트는 뒤의 에이전트가 앞 에이전트의 전체 대화 기록과 궤적(1장에서 정의)을 받는다는 뜻입니다. 각 단계에서 시스템 프롬프트와 도구 집합이 바뀌면 앞 에이전트의 모든 메모리를 유지하더라도 정체성, 책임, 능력이 달라졌으므로 시스템은 새 단계를 다른 에이전트로 봅니다. 예를 들어 요구 사항 분석가가 요구 사항 문서를 작성하면 개발자는 문서뿐 아니라 분석가와 사용자가 소통한 전체 기록도 받습니다. 앞의 모든 컨텍스트를 유지하면서 새 역할을 맡습니다. 장점은 정보가 하나도 손실되지 않아 각 에이전트가 이전 어느 단계의 세부 사항도 돌아볼 수 있다는 것입니다. 문제는 컨텍스트가 빠르게 커질 수 있다는 점입니다.

비공유 컨텍스트는 각 에이전트가 독립적인 컨텍스트와 대화 기록을 유지하며 다른 에이전트의 작업 추적에 직접 접근할 수 없다는 뜻입니다. 여러 부서의 협업과 비슷합니다. 모두 각자의 책상에서 독립적으로 일하고 서로의 화면을 계속 지켜보는 대신 공유 문서와 회의록으로 정보를 교환합니다. 이 모델은 모듈성과 격리가 더 좋으며 각 에이전트는 자신의 책임과 관련된 정보에만 집중하면 됩니다. 시스템 확장과 유지보수도 더 쉽습니다. 새 에이전트를 추가할 때 기존 에이전트의 내부 로직을 수정할 필요 없이 인터페이스와 데이터 형식만 정의하면 됩니다.

에이전트가 컨텍스트를 공유하지 않으므로 명시적인 통신 메커니즘으로 정보를 전달해야 합니다. 고전적인 분산 시스템은 이 문제에 오래전에 답했습니다. 운영체제 교과서에 따르면 프로세스 간 통신(IPC)은 결국 공유 메모리(한쪽이 쓰고 다른 쪽이 같은 저장 영역을 읽음)와 메시지 전달(데이터를 상대에게 명시적으로 보냄)이라는 두 패러다임뿐입니다. 에이전트 간 통신도 이 두 패러다임 안에 들어갑니다. 흔히 세 가지 방법을 사용합니다.

• 도구 호출 매개변수: 상위 에이전트가 하위 에이전트의 도구 매개변수로 구조화된 데이터를 전달합니다. 타입과 구조가 명확한 데이터가 필요한 상황에 적합합니다.
• 공유 파일 시스템: 에이전트가 공유 디렉터리의 중간 산출물(문서, 코드 등)을 읽고 쓰며 정보를 교환합니다. 산출물이 크거나 영속성이 필요한 상황에 적합합니다.
• 메시지 버스: 에이전트 사이에서 메시지를 전달하는 전용 중개자입니다. 에이전트가 서로 직접 호출하지 않고 버스에 메시지를 보내면 버스가 대상 에이전트에 전달합니다.

두 IPC 패러다임에 대응시키면 공유 파일 시스템은 ‘공유 메모리’에, 도구 호출 매개변수와 메시지 버스는 ‘메시지 전달’에 해당합니다. 도구 매개변수는 호출과 함께 동기적으로 전달되고 버스 메시지는 중개자를 통해 비동기로 전달됩니다. 각 패러다임에는 절충이 있습니다. Go에는 “메모리를 공유하며 통신하지 말고, 통신하여 메모리를 공유하라”는 유명한 격언이 있습니다. 공유 메모리는 빠르지만 개발자가 동시성 위험을 관리해야 합니다. 메시지 전달에는 더 많은 오케스트레이션 코드가 필요하지만 데이터 소유권이 명확하고 추적 가능합니다. 이 절충은 뒤의 상태 질의와 동시성 충돌 논의에서 계속 등장합니다.

메시지 버스는 비동기 통신을 자연스럽게 지원하여 송신자와 수신자가 동시에 온라인일 필요가 없습니다. 회사 내부 이메일 시스템과 같습니다. 동료에게 이메일을 보낼 때 그 순간 컴퓨터 앞에 있을 필요가 없으며 이메일은 서버에 저장됐다가 동료가 온라인이 되면 처리됩니다. 여러 에이전트가 병렬로 일하면서 서로 조율해야 하는 상황에 특히 적합합니다(뒤의 ‘병렬 조율’ 절 참고).

두 아키텍처 모두 각 단계의 시스템 프롬프트와 도구 집합이 달라 서로 다른 에이전트가 되므로 진정한 멀티 에이전트 시스템입니다. 차이는 조율 방식입니다. 공유 컨텍스트는 암묵적 조율에 의존합니다. 뒤의 에이전트가 앞 에이전트의 전체 컨텍스트 기록을 물려받아 보이는 상호작용 기록과 작업 추적을 검토하고 컨텍스트 자체를 통해 정보를 받습니다. 비공유 컨텍스트는 명시적 조율에 의존합니다. 에이전트가 파일, 메시지, 구조화된 데이터 인터페이스로 정보를 교환하며 각 에이전트는 자신의 업무에 관련된 내용만 봅니다.

비유하면 전자는 모두가 모든 말을 듣는 한 테이블의 팀이고, 후자는 각자 작업 공간을 두고 이메일과 문서로 협업하는 부서입니다.

운영체제에 익숙한 독자에게는 공유 컨텍스트 에이전트가 스레드, 비공유 컨텍스트 에이전트가 프로세스와 비슷하다는 비유가 유용할 수 있습니다. 스레드는 주소 공간을 공유하므로 전환과 통신 비용이 작지만 격리가 약하며 한 스레드의 메모리 손상으로 전체 프로세스가 중단될 수 있습니다. 프로세스는 각자 주소 공간을 가져 격리와 안전한 병렬성이 더 강하지만 명시적인 IPC로 통신해야 합니다. 표 10-1의 기준은 이러한 절충에서 나옵니다.

표 10-1은 하위 업무 수, 컨텍스트 창, 병렬성, 정보 격리, 비용 예산이라는 다섯 관점에서 두 아키텍처의 선택 기준을 요약합니다. 초기 아키텍처를 선택할 때 체크리스트로 사용할 수 있습니다.

표 10-1 공유 컨텍스트와 비공유 컨텍스트 선택 기준

선택 기준	공유 컨텍스트	비공유 컨텍스트
하위 업무 수	적음(역할 2~3개)	많음(병렬 처리 필요)
컨텍스트 창	모든 역할의 정보를 담을 수 있음	단일 창으로 부족함
병렬성	주로 직렬(같은 궤적에서 역할이 교대)	대규모 병렬 확장 가능(컨텍스트가 독립적이고 서로 막지 않음)
정보 격리	필요 없음(모든 역할이 정보 공유)	필요함(예: 보안 검토는 다른 에이전트의 내부 컨텍스트를 받지 않아야 함)
비용 예산	하나의 궤적을 단계마다 넘기며 토큰이 단계별로 누적	여러 에이전트가 독립적으로 작업하여 전체 토큰은 보통 수 배에서 열 배 많음

간단한 경험 법칙: 예상 누적 컨텍스트가 창의 50%를 넘으면(정확한 임계값이 아닌 휴리스틱) 공유하지 마십시오. 업무 정확성을 위해 정보 손실이 전혀 없어야 한다면 공유하십시오. 실제 시스템 대부분은 단계마다 다른 접근법을 사용합니다. 처음 몇 에이전트는 컨텍스트를 공유하지만 공유 기록이 너무 커지면 비공유 컨텍스트로 바꾸고 상위 에이전트가 하위 에이전트에 전달할 내용을 고르는 명시적 핸드오프를 사용합니다.

차원 2: 협업 토폴로지

둘째 차원은 협업 토폴로지, 즉 에이전트 사이에서 제어와 정보가 흐르는 구조입니다. 토폴로지와 컨텍스트 공유는 개념적으로 서로 다르지만 실제로 관련되어 있습니다. 공유 컨텍스트 시스템에도 토폴로지가 있습니다. 예를 들어 실험 10-2의 transfer_to_agent 패턴은 핸드오프 체인을 만듭니다. 하지만 모든 핸드오프가 전체 기록을 전달하므로 어떤 정보를 전달할지 결정할 필요가 거의 없고 토폴로지는 흔히 단순한 역할 전환 순서가 됩니다. 그룹 채팅식 협업은 뒤의 탈중앙화 절에서 다루는 예외입니다. 반면 비공유 컨텍스트에서는 정보 흐름과 조율자를 명시적으로 정해야 합니다.

용어: 그래프 엔지니어링. 2026년 7월 널리 쓰이기 시작한 ‘그래프 엔지니어링(Graph Engineering)’은 오늘날의 에이전트 맥락에서 일반적으로 실행 그래프를 명시적으로 설계하는 일을 뜻합니다. 노드는 에이전트, 일반 프로그램, 사람의 의사 결정이고, 에지는 업무 의존성, 조건부 라우팅, 실패 경로를 정의하며, 구조화된 상태가 노드 사이를 흐릅니다.² 이 장의 ‘협업 토폴로지’는 이 발상 가운데 멀티 에이전트 부분에 해당합니다. 동료 협업, 관리자 오케스트레이션, 탈중앙화 핸드오프는 서로 다른 그래프 토폴로지입니다. 이름이 아직 새롭고 지식 그래프, GraphRAG, 실행 추적과 혼동되기 쉬우므로 이 책은 더 안정적인 ‘협업 토폴로지’와 ‘오케스트레이션’을 주 용어로 계속 사용합니다.

다시 말해 두 차원은 원칙적으로 2×3 행렬(공유/비공유 × 세 토폴로지)을 이룹니다. 하지만 공유 컨텍스트 행에서는 토폴로지가 대부분 역할 전환의 순서로 축소되어 결정할 것이 거의 남지 않습니다(뒤의 ‘다단계 역할 전환’에서 다루는 형태). 따라서 이 장은 비공유의 세 셀만 자세히 설명합니다. 다음은 복잡도가 높아지는 순서로 나열한 비공유 컨텍스트의 세 대표 토폴로지입니다.

• 동료 협업 패턴: 소수의 에이전트(보통 2~3개)가 동등하게 상호작용하며 반복 개선 루프를 만듭니다. 한 사람이 논문 초안을 쓰고 다른 사람이 주석을 달아 수정하여 여러 라운드 뒤의 품질이 혼자 만든 것보다 훨씬 높아지는 것과 같습니다.
• 관리자 패턴(오케스트레이션 패턴): 중앙의 관리자 에이전트가 업무 계획과 스케줄링을 맡고 여러 하위 에이전트가 각각 특정 하위 업무를 처리합니다. 프로젝트 관리자가 여러 전문 엔지니어를 이끌고 프로젝트를 수행하는 것과 같습니다.
• 탈중앙화 패턴: 런타임 중앙 제어자가 없고 에이전트가 사람처럼 서로 소통하며 업무를 협업합니다.

각 패턴의 상세 설계와 적용 상황은 뒤의 전용 하위 절에서 설명합니다.

멀티 에이전트가 단일 에이전트보다 실제로 나은 때

구체적인 협업 아키텍처에 들어가기 전에 더 근본적인 질문에 답해 보겠습니다. 여러 에이전트가 정말 필요한 때는 언제이고 하나로 충분한 때는 언제일까요? 그 답은 뒤의 모든 엔지니어링 접근법을 판단하는 기준점이 됩니다. 최근 연구들은 하나의 명확한 프레임워크로 수렴합니다. 핵심 기준은 한 질문입니다. 협업이 단일 에이전트가 답을 만드는 동안 얻을 수 없었던 정보를 제공하는가?

표 10-2는 어떤 협업 방식이 새 정보를 도입하는지 보여 주며 멀티 에이전트 협업이 단일 에이전트보다 실질적인 가치를 주는지 판단하도록 돕습니다.

표 10-2 멀티 에이전트 협업 방식의 정보 이득 비교

협업 방식	새 정보를 도입하는가?	효과
같은 모델의 자기 검토(자신의 출력을 다시 읽음)	아니요	보통 효과가 없거나 오히려 해로움
서로 다른 에이전트가 같은 텍스트를 토론	아니요	계산량이 같다면 단일 에이전트와 비슷함
검토자가 테스트 실행 결과로 코드를 검토	예(실행 피드백)	크게 개선
검토자가 렌더링된 스크린샷으로 프런트엔드/PPT 코드를 검토	예(시각 피드백)	크게 개선
검토자가 외부 도구로 사실을 검증	예(도구 피드백)	크게 개선

2025년 RLEF(Reinforcement Learning from Execution Feedback) 논문³은 코드 실행 피드백을 이용한 반복 개선을 강화 학습으로 모델에 학습하면 모델을 독립적으로 여러 번 샘플링하는 것보다 성능이 크게 높아진다는 사실을 발견했습니다. 핵심은 반복마다 모델이 코드를 작성할 때는 없었던 정보인 실제 실행 결과(컴파일 오류, 테스트 실패, 런타임 예외)를 도입한다는 점입니다. 웹페이지 생성 업무를 다룬 2025년 WebGen-Agent 연구⁴는 스크린샷과 시각-언어 모델 설명을 결합한 다단계 시각 피드백으로 Claude 3.5 Sonnet의 벤치마크 성능이 26.4%에서 51.9%로 올라 거의 두 배가 되었다고 보고했습니다.

이 프레임워크는 겉보기의 모순을 해소합니다. 일부 학술 연구에서는 단일 에이전트면 충분하다고 하지만 엔지니어링 실무에서는 멀티 에이전트 시스템이 더 나은 경우가 많습니다. 연구는 흔히 토론처럼 여러 에이전트가 같은 텍스트를 살펴보고 논의하는 방식을 시험하지만 효과적인 엔지니어링 시스템은 보통 코드 실행, 시각 렌더링, 도구의 외부 피드백을 추가합니다. 후자만 새 정보를 도입합니다. 뒤에서 다룰 동료 협업, 오케스트레이션, 탈중앙화라는 세 아키텍처의 효과적인 활용은 거의 모두 이 기준으로 이해할 수 있습니다.

단계 예산과 에이전트 성능. 관련 질문으로 에이전트의 단계 예산, 즉 사용할 수 있는 도구 호출 수나 반복 라운드 수가 성능에 어떤 영향을 주는지가 있습니다. 단계가 많으면 당연히 도움이 될 것처럼 보입니다. 30단계에서는 핵심 기능만 구현할 수 있지만 300단계라면 계획, 구현, 테스트, 개선까지 할 수 있습니다. 하지만 2025년 Google 논문 Budget-Aware Tool-Use Enables Effective Agent Scaling은 직관에 어긋나는 결론을 내렸습니다. 에이전트에 단계만 더 준다고 성능이 좋아진다는 보장은 없습니다. 표준 에이전트에는 ‘예산 인식’이 없어 300단계를 받아도 얕은 탐색을 하다가 빠르게 정체하는 경향이 있습니다. 추가 단계를 효과적으로 사용하려면 남은 자원에 맞춰 전략을 조정하는 메커니즘이 필요합니다. 처음에는 넓게 탐색하고 나중에는 초점을 좁혀야 합니다. 2026년 BAVT(Budget-Aware Value Tree Search)는 단계별 가치 평가를 추가하여 남은 예산 비율에 따라 탐색과 활용의 균형을 조정했습니다. 예산이 줄어들수록 에이전트가 넓은 탐색에서 더 깊은 조사로 전환합니다.

이 발견은 멀티 에이전트 시스템 설계에 직접적인 시사점을 줍니다. 예를 들어 오케스트레이션 패턴에서 관리자 에이전트는 단순히 하위 에이전트에 업무를 분배하고 결과를 기다려서는 안 됩니다. 업무 복잡도에 따라 단계 예산을 동적으로 배분해야 합니다. 단순한 하위 업무에는 적은 단계를, 복잡한 하위 업무에는 충분한 단계를 줍니다. 또한 하위 에이전트가 곧장 뛰어드는 대신 먼저 계획하고 구현하고 테스트하고 개선하도록 예산을 현명하게 쓰게 안내해야 합니다.

설계 결정을 내리기 전에 고려해야 할 사항이 하나 더 있습니다. 비용입니다. 병렬 탐색과 반복 개선에는 돈이 듭니다. Anthropic은 자사의 멀티 에이전트 연구 시스템이 일반 대화보다 약 15배 많은 토큰을 사용하며 토큰 사용량만으로 성능 차이의 약 80%가 설명된다고 밝혔습니다. 따라서 멀티 에이전트 시스템의 이득은 수 배에서 열 배까지 높아질 수 있는 비용을 정당화할 만큼 커야 합니다. 그렇지 않다면 잘 조정된 단일 에이전트가 보통 더 경제적입니다.

공유 컨텍스트를 이용한 멀티 에이전트 협업

공유 컨텍스트를 이용한 멀티 에이전트 협업에서 각 단계는 자체 시스템 프롬프트와 도구 집합을 가진 독립 에이전트이지만 앞 에이전트의 전체 궤적을 물려받습니다. 교대 근무를 이어받는 동료가 전임자가 남긴 모든 업무 기록을 펼쳐 볼 수 있는 것과 같습니다. 이러한 상속 기반 협업의 핵심 장점은 정보 손실이 전혀 없다는 것입니다. 모든 에이전트가 어느 이전 단계의 세부 사항도 검토할 수 있습니다. 문제는 물려받은 방대한 기록에 주의가 흐트러지지 않고 현재 에이전트가 자신의 책임에 집중하게 하는 것입니다.

다단계 역할 전환

먼저 정의에 관한 논쟁을 꺼내 놓겠습니다. 1장의 용어로 다단계 역할 전환은 워크플로식 오케스트레이션입니다. 실행 경로(예: 요구 사항 명확화 → 구현 → 검토)가 미리 정의되어 있습니다. 프로세스 관점에서는 하나의 프로세스가 같은 메모리를 계속 유지하며 여러 단계를 순서대로 실행합니다. 따라서 ‘진짜 멀티 에이전트가 아니다’라는 주장에도 일리가 있습니다. 그래도 이 장에서는 멀티 에이전트 패턴으로 다룹니다. 각 단계가 자체 시스템 프롬프트, 도구, 초점을 가질 수 있고 단계 경계를 품질 게이트로 사용할 수 있다는 실용적 이점이 있기 때문입니다.

복잡한 업무에서는 단계마다 에이전트의 역할과 책임이 크게 달라질 수 있습니다. 하나의 정적인 시스템 프롬프트를 처음부터 끝까지 사용하면 단계별 안내를 제공하기에 너무 일반적이거나 모든 단계의 지시를 포함해 지나치게 길어집니다. 다단계 역할 전환은 현재 단계에 따라 시스템 프롬프트와 도구 집합을 바꾸어 에이전트가 가장 적절한 역할로 일하게 합니다. 전환에 새 인스턴스나 프로세스가 필요하지는 않습니다. 같은 실행 세션 안에서 시스템 프롬프트와 도구 집합만 바꿉니다. 역할이 바뀌어도 대화 기록과 업무 상태는 공유되므로 새 역할의 에이전트도 이전 단계에서 쌓인 모든 정보에 접근할 수 있습니다.

실험 10-1 ★★: 실행 단계에 따라 시스템 프롬프트 결정

이 실험은 단계별 시스템 프롬프트가 완전한 코딩 에이전트 워크플로 전반의 성능을 높이는 방법을 보여 줍니다.

업무 상황: 사용자가 소프트웨어 개발을 요청하면 에이전트가 요구 사항 명확화, 코드 구현, 품질 검토라는 세 단계를 거칩니다.

1단계: 요구 사항 명확화(역할: 요구 사항 분석가)

시스템 프롬프트는 다음을 강조합니다. - “여러분의 책임은 사용자의 필요를 완전히 이해하는 것입니다. 모호한 부분을 명확히 하도록 질문하여 기대하는 기능, 사용 상황, 성능 요구 사항을 모두 이해했는지 확인하십시오.” - “서둘러 구현하지 마십시오. 이 단계에서 할 일은 코드를 작성하는 것이 아니라 질문하고 확인하는 것입니다.” - “모든 핵심 요구 사항이 명확하다고 확인하면 complete_requirements_analysis() 도구를 호출하여 이 단계를 끝내십시오.”

도구 집합은 제한되어 있습니다. 사용자에게 확인 질문을 하는 ask_clarifying_question(question), 확인된 요구 사항을 기록하는 save_requirement(key, value), 단계 완료를 표시하는 complete_requirements_analysis()입니다.

에이전트는 스크립트가 어떤 파일 유형을 처리해야 하는지, 하위 폴더를 재귀적으로 처리할지, 파일을 옮긴 뒤 원래 파일명을 보존할지 사용자에게 묻습니다. 이러한 대화로 구조화된 요구 사항을 만들고 기록합니다. 요구 사항이 충분히 명확해지면 complete_requirements_analysis()를 호출합니다. 이 완료 신호에 따라 시스템이 다음 단계 구성을 로드합니다.

2단계: 코드 구현(역할: 소프트웨어 엔지니어)

새 시스템 프롬프트는 다음을 강조합니다. - “여러분의 책임은 확인된 요구 사항을 바탕으로 고품질 Python 코드를 작성하는 것입니다.” - “모범 사례를 따르십시오. 코드를 모듈화하고 오류를 적절히 처리하며 도움이 되는 곳에 주석을 포함하십시오.” - “코드를 완성하고 기본 테스트를 통과하면 submit_for_review()를 호출하여 검토 단계로 들어가십시오.”

도구도 바뀝니다. 요구 사항 명확화 도구가 write_file(path, content), read_file(path), execute_code(code) 같은 개발 도구로 교체됩니다. 에이전트는 첫 단계에서 기록한 요구 사항을 사용해 핵심 로직을 작성하고 오류 처리를 추가하고 테스트를 만듭니다. 요구 사항 세부 정보를 확인하기 위해 이전 대화를 볼 수 있지만 더 질문하지 않고 구현에만 집중합니다. 끝나면 submit_for_review()를 호출합니다.

3단계: 코드 검토(역할: 코드 검토자)

새 시스템 프롬프트는 다음을 강조합니다. - “기능적 정확성, 코딩 표준 준수, 오류 처리, 성능, 보안 관점에서 코드를 검토하십시오.” - “비판적으로 접근하여 잠재적인 문제와 코드를 개선할 기회를 식별하십시오.” - “심각한 문제가 발견되면 request_revision(issues)를 호출하여 구현 단계로 돌아가 수정하게 하십시오. 품질이 적절하다면 approve_code()를 호출하여 업무를 완료하십시오.”

도구 집합이 다시 바뀌어 run_linter(file), run_tests(file), analyze_complexity(file) 같은 코드 품질 분석 도구로 교체됩니다. 에이전트는 검토자 관점에서 코드를 다시 살펴보고 정적 분석을 실행하고 잠재적인 버그, 성능 문제, 보안 위험을 확인합니다.

이 3단계 설계를 사용하면 에이전트가 각 단계의 핵심 업무에 집중할 수 있습니다. 더 중요한 점은 명확한 단계 전환이 모든 단계의 완료를 보장한다는 것입니다. 요구 사항 분석을 건너뛰고 바로 코딩을 시작하거나 검토 없이 결과를 전달할 수 없습니다.

실험 요구 사항: 1. 각기 명확한 역할 정의와 행동 지침이 있는 3단계 시스템 프롬프트를 구현합니다. 2. 단계마다 맞는 도구 집합을 구성합니다. 3. 특정 도구 호출을 통한 단계 전환 트리거 메커니즘을 구현합니다. 4. 단계 간 컨텍스트 연속성을 보장합니다. 5. 롤백 상황, 즉 코드 검토에서 문제가 발견되면 구현 단계로 돌아가는 흐름을 처리합니다. 6. 서로 다른 프롬프트가 서로 다른 행동을 만드는 방식을 보여 주도록 각 단계의 활동을 기록합니다.

도메인 간 역할 전환

다단계 역할 전환은 하나의 업무 유형(소프트웨어 개발) 안에서 단계별 실행을 보여 주었습니다. 도메인 간 역할 전환은 더 나아가 업무가 여러 도메인을 거치면서 에이전트가 동적으로 역할을 바꿉니다. 미리 정의된 선형 프로세스를 따르는 대신 사용자의 변화하는 필요에 따라 채택할 전문 역할을 선택합니다.

실험 10-2 ★★: 다중 역할 전환

선수 지식: 먼저 2장의 에이전트 스킬 메커니즘을 다시 살펴보기를 권합니다.

시스템 아키텍처: 다섯 역할을 정의합니다.

• triage(접수 담당, 기본 진입점): 사용자의 전반적인 필요를 파악하고 업무를 순차적인 하위 업무로 나누며 각 하위 업무를 적합한 전문가에게 전달한 뒤 모든 하위 업무가 끝나면 최종 확인을 수행합니다. 유일한 도구는 transfer_to_agent입니다.
• research(정보 검색 전문가): web_search를 사용하여 데이터, 사실, 자료를 찾습니다.
• coding(프로그래밍 전문가): execute_python을 사용하여 프로그래밍·스크립팅 업무의 코드를 작성하고 실행합니다.
• data_analysis(데이터 분석 전문가): calculate / descriptive_stats를 사용하여 정량 계산과 통계를 수행합니다(예: 전년 대비 성장률, 연평균 성장률(CAGR), 평균).
• writing(글쓰기 전문가): 검색한 데이터와 분석 결과를 독자에게 맞춘 명확한 초안으로 만듭니다(대략적인 길이를 확인하려면 count_characters를 사용할 수 있습니다).

핵심 메커니즘: transfer_to_agent 도구

모든 역할에는 transfer_to_agent(target_role, reason) 도구가 있습니다. 역할이 이를 호출하면 시스템이 현재 대화 기록을 저장하고 대상 역할의 프롬프트와 도구 집합을 로드하고 기록을 해당 역할에 넘긴 뒤 실행을 재개합니다.

실험 상황: 시스템은 기본적으로 triage 역할로 시작합니다. 사용자가 여러 도메인에 걸친 업무를 제출합니다. “투자자용 자료를 준비하고 있어. 2021년, 2022년, 2023년 중국의 신에너지 자동차 판매량을 찾아서 3년간 연평균 성장률을 계산하고, 투자자를 위해 120자 이내 중국어 요약을 작성해 줘.” triage는 ‘데이터 검색 → 지표 계산 → 초안 작성’으로 나누고 먼저 research에 넘깁니다.

transfer_to_agent(target_role="research", reason="2021~2023년 신에너지 자동차의 연간 판매량 찾기")

research는 web_search로 판매량을 찾아 핵심 데이터를 대화에 추가한 뒤 data_analysis에 업무를 넘깁니다.

transfer_to_agent(target_role="data_analysis", reason="데이터 준비 완료. 2021~2023년 CAGR 계산")

data_analysis는 calculate로 성장률을 계산합니다. 이어서 writing에 넘겨 요약 초안을 작성하고 최종 확인을 위해 triage에 돌려보냅니다. 전체 체인은 triage → research → data_analysis → writing → triage입니다. 모든 역할이 전체 대화 기록을 볼 수 있으므로 다음 역할은 이미 완료된 일을 자연스럽게 압니다.

역할 전환 결정은 시스템 프롬프트의 지침에 따릅니다. triage 프롬프트는 데이터나 출처 자료 찾기 → research, 코드 작성·실행 → coding, 정량 계산·통계 → data_analysis, 자료를 초안으로 다듬기 → writing이라는 라우팅 규칙을 명시합니다. 깊은 도메인 전문성이나 특수 도구가 필요한 업무는 핸드오프해야 합니다. 각 전문가의 프롬프트에도 다음으로 적합한 역할을 적거나 업무를 triage에 돌려보내도록 지시합니다.

실험 요구 사항: 1. 적어도 세 전문 역할의 시스템 프롬프트와 전문 도구 집합을 구현합니다. 2. 동적 전환을 지원하는 transfer_to_agent 도구를 구현합니다. 3. 역할 전환 뒤 컨텍스트 연속성을 보장합니다. 4. 역할 사이를 반복해서 전환하는 순환 핸드오프를 방지합니다. 5. 여러 도메인에 걸친 복잡한 업무 흐름을 설계하여 역할 전환의 가치를 보여 줍니다.

컨텍스트를 공유하지 않는 멀티 에이전트 협업

공유 컨텍스트가 없는 아키텍처에서 각 에이전트는 자체 컨텍스트, 궤적, 상태를 가진 독립적인 개체로 작동합니다. 에이전트는 서로의 내부 컨텍스트에 직접 접근할 수 없으며, 협업은 이 장의 시작에서 소개한 도구 호출 매개변수, 공유 파일 시스템, 메시지 버스라는 세 통신 메커니즘을 통한 명시적이고 구조화된 데이터 전달에 전적으로 의존합니다.

앞에서는 통신 메커니즘을 프로세스 간 통신의 형태에, 공유·격리 컨텍스트를 스레드·프로세스에 비유했습니다. 이 비유를 더 확장할 수 있습니다(표 10-3).

표 10-3 멀티 에이전트 시스템과 운영체제의 대응

운영체제	멀티 에이전트 시스템
프로그램(실행 파일)	정적 접두부(시스템 프롬프트 + 도구 정의)
프로세스 메모리	궤적
CPU	LLM
커널	에이전트 런타임
시스템 호출	도구 호출
fork(자식 프로세스 생성)	spawn_subagent
kill(신호 전송)	cancel_subagent
ps(프로세스 목록)	list_agents
종료 코드와 wait()	하위 에이전트가 반환하는 구조화된 요약
공유 메모리 / 메시지 전달	공유 파일 시스템 / 메시지 전달

프로그램은 정적인 코드이고 프로세스는 프로그램이 실행 중인 하나의 인스턴스입니다. 마찬가지로 정적 접두부는 에이전트가 누구인지 결정하고 궤적은 어디까지 진행했는지 기록합니다. LLM은 CPU 역할을 합니다. 자체 상태를 보유하지 않고 서로 다른 컨텍스트를 로드하여 여러 에이전트가 시분할로 공유합니다. ‘컨텍스트 전환’이라는 용어 자체도 운영체제에서 빌려 왔습니다. 같은 이유로 더 빠른 CPU로 바꿔도 프로그램은 이전처럼 실행되고, 더 강한 모델로 바꿔도 에이전트는 같은 에이전트로 남습니다. 정체성과 메모리는 모델 가중치가 아니라 접두부와 궤적에 있기 때문입니다.

이 추상화는 새로운 것이 아닙니다. 비공개 상태, 비동기 메시지, 새 구성원을 만드는 능력은 정확히 1970년대 액터 모델(Actor model)의 기본 구성입니다⁵. 따라서 멀티 에이전트 시스템은 LLM 기반 액터 모델로 볼 수 있으며 운영체제와 분산 시스템에서 축적한 많은 지식을 직접 적용할 수 있습니다. 다만 한 가지 중요한 지점에서 비유가 깨집니다. 프로세스는 바이트를 비트 단위로 충실히 전달하지만 에이전트는 의미를 전달하며, 다시 말할 때마다 의미가 왜곡될 수 있습니다. 이것이 이 장의 ‘실패 모드’ 절에서 다루는 새로운 문제입니다.

이 프로세스식 격리는 몇 가지 실용적인 엔지니어링 이점을 제공합니다. 각 에이전트를 독립적으로 개발하고 테스트할 수 있고, 기존 코드를 건드리지 않고 새 능력을 추가할 수 있으며, 한 에이전트가 실패해도 오류가 다른 에이전트로 자동 전파되지 않고, 여러 에이전트가 공유 컨텍스트를 두고 경합하지 않으면서 동시에 실행될 수 있습니다.

하지만 컨텍스트를 공유하지 않는 데도 비용이 따릅니다. 가장 분명한 것은 정보 동기화 문제입니다. 에이전트는 업무 상태를 어떻게 일관되게 이해할까요? 전달 과정에서 정보가 손실되거나 중복되지 않을까요? 디버깅도 더 어려워집니다. 문제가 생기면 여러 에이전트의 로그를 검토해 전체 실행 과정을 맞춰 봐야 합니다. 따라서 인터페이스 명세, 데이터 형식, 통신 프로토콜 설계가 매우 중요합니다.

공유 컨텍스트 없는 명시적 협업은 토폴로지와 무관한 두 인프라에 의존합니다. 첫째는 에이전트끼리, 그리고 에이전트와 사용자가 산출물을 교환하는 영속 매체인 공유 파일 시스템으로 협업의 데이터 평면을 이룹니다. 둘째는 에이전트 간 메시지 전달, 상태 질의, 실행 종료, 자원 스케줄링을 지원하는 통신·제어 메커니즘으로 협업의 제어 평면을 이룹니다. 아래의 세 토폴로지는 모두 이 두 토대 위에 구축됩니다.

에이전트 관점에서 본 파일 시스템

이 장의 시작에서 ‘공유 파일 시스템’을 공유 컨텍스트 없는 아키텍처의 세 통신 메커니즘 가운데 하나로 나열했습니다. 실제 시스템에서 에이전트가 접근하는 파일 시스템은 단일 저장 시스템이 아니라 출처, 생명 주기, 권한이 서로 다른 저장 시스템을 하나의 디렉터리 트리 아래에 마운트한 가상 파일 시스템입니다. 에이전트는 통합 read_file/write_file/list_dir 인터페이스로 접근하지만 기반 계층은 로컬 임시 디스크, 영속 객체 저장소, 서드파티 클라우드 드라이브 API, 읽기 전용 시스템 리소스 패키지일 수 있습니다. 이 디렉터리 트리의 구성, 즉 각 영역의 가시성과 생명 주기를 명확히 정의하는 일은 멀티 에이전트 협업 설계의 전제 조건입니다. 동시성 충돌과 정보 유출의 상당 부분은 격리해야 할 영역을 섞으면서 생깁니다. 이 디렉터리 트리는 에이전트의 주소 공간에 해당하고 네 영역 유형은 서로 다른 권한을 가진 메모리 세그먼트입니다. 어떤 영역은 비공개로 쓰기 가능하고, 어떤 영역은 여러 주체가 공유하며, 어떤 영역은 읽기 전용입니다. 운영체제의 보호 철학도 그대로 적용됩니다. 기본적으로 격리하고 공유는 명시적으로 선언합니다. 성숙한 멀티 에이전트 시스템의 파일 시스템은 보통 다음 네 유형의 영역으로 구성됩니다.

I. 에이전트별 작업 공간(스크래치패드). 각 에이전트 인스턴스 전용 비공개 디렉터리로 중간 산출물, 임시 파일, 초안, 디버그 로그를 저장합니다. 생명 주기는 인스턴스에 연결되며 다른 에이전트와 사용자에게 보이지 않습니다. 스크래치패드 격리에는 두 가지 목적이 있습니다. 여러 에이전트의 임시 파일이 서로를 덮어쓰는 일을 막고, 주 에이전트의 컨텍스트를 간결하게 유지합니다. 하위 에이전트의 시행착오는 자체 작업 공간에 남고 최종 산출물만 공유 공간에 제출됩니다. 이는 하위 에이전트가 전체 궤적이 아닌 구조화된 요약을 반환해야 한다는 4장의 원칙을 저장소 수준에서 구현한 것입니다.

II. 멀티 에이전트 공유 작업 공간. 여러 에이전트가 읽고 쓸 수 있으며 사용자에게도 보이는 협업 영역입니다. 공유 컨텍스트 없는 아키텍처에서 에이전트가 산출물을 교환하는 주요 매체입니다. 용어집 에이전트가 용어 목록을 쓰고 번역 에이전트가 이를 읽습니다. 사용자도 여기에서 원본 파일을 업로드하고 최종 결과물을 다운로드할 수 있습니다. 생명 주기는 전체 업무와 연결되며 영속성이 필요합니다. 여러 주체가 동시에 읽고 쓰는 영역이므로 동시성 충돌이 집중됩니다. 뒤의 ‘실패 모드 1’에서 자세히 설명할 낙관적 잠금과 워크트리 격리 같은 메커니즘이 여기에서 작동합니다. 4장에서 /workspace/shared에 볼륨을 마운트해 주 에이전트, 가상 컴퓨터, 가상 전화를 연결한 사례가 이 계층의 대표 구현입니다.

III. 마운트된 외부 리소스. Google Drive, Notion, Dropbox, 기업 위키처럼 사용자가 권한을 부여한 서드파티 정보원을 어댑터를 통해 파일 시스템의 마운트 지점(예: /mnt/gdrive)에 매핑합니다. 에이전트는 파일을 읽어 Notion 문서에 접근하며 기반 어댑터가 해당 API를 호출합니다. 이 계층에는 로컬 저장소와 구분되는 세 가지 특성이 있어 설계할 때 명시적으로 처리해야 합니다. 접근은 외부 권한의 제약을 받으며 원본 시스템의 사용자 권한이 에이전트의 가시성을 결정합니다. 지연은 더 길고 일관성은 더 약합니다. 읽을 때마다 네트워크 왕복이 발생하고 외부 변경이 즉시 보이지 않을 수 있으므로 데이터는 최종 일관성을 가진 것으로 취급해야 합니다. 주로 필요할 때 읽기 전용으로 접근합니다. 잘못 쓰면 사용자의 실제 데이터가 오염될 수 있으므로 외부 원본에 쓰는 일은 신중해야 합니다. 통합 파일 인터페이스 덕분에 데이터 원본마다 사용자 정의 도구가 필요하지 않지만 성능·보안 차이도 가려집니다. 따라서 읽기 전용/쓰기 가능 상태, 제한 시간, 자격 증명 경계를 마운트 수준에서 명시적으로 관리해야 합니다.

IV. 내장 시스템 리소스. 시스템에 사전 설치되어 모든 에이전트와 읽기 전용으로 공유하는 리소스 패키지입니다. 대표적인 예는 2장과 4장에서 소개한 스킬입니다. 지식 문서와 스크립트를 파일로 구성하여 /skills 같은 경로에 마운트하고 점진적 공개(먼저 색인, 필요할 때 확장) 방식으로 접근합니다. 참조 설명서, 템플릿 라이브러리, 공유 도구 정의도 예입니다. 이 계층은 전역으로 공유되고 읽기 전용이며 세션 간 안정적이므로 모든 에이전트가 동시성 제어 없이 함께 읽을 수 있습니다.

그림 10-3은 네 영역 유형을 하나의 디렉터리 트리 아래에 통합 마운트하는 방법을 보여 줍니다. 에이전트는 통합 인터페이스로 전체 트리에 접근하고, 사용자는 공유 공간에서 파일을 업로드·다운로드하며, 외부 데이터 원본은 어댑터로 마운트되고, 내장 시스템 리소스는 읽기 전용으로 제공됩니다.

표 10-4는 네 영역 유형을 가시성, 생명 주기, 읽기/쓰기 권한, 동시성 제어라는 네 차원에서 비교하며 파일 시스템 레이아웃 설계의 체크리스트로 사용할 수 있습니다.

표 10-4 에이전트 가상 파일 시스템의 네 영역 유형

영역	가시성	생명 주기	읽기/쓰기	동시성 제어
에이전트별 작업 공간	소유한 에이전트만	에이전트 인스턴스와 함께 삭제	읽기/쓰기	불필요(비공개)
멀티 에이전트 공유 작업 공간	협업하는 모든 에이전트와 사용자	업무 기간 동안 영속	읽기/쓰기	필요(낙관적 잠금 / 워크트리)
마운트된 외부 리소스	외부 권한에 따라 결정	외부 원본이 결정	대부분 읽기 전용, 쓰기는 주의 필요	외부 원본이 관리
내장 시스템 리소스	모든 에이전트	세션 간 안정적	읽기 전용	불필요(읽기 전용)

‘범용 인터페이스로서의 파일 경로’의 가치는 경로를 교환 단위로 다루는 데 있습니다. 에이전트가 산출물을 교환하거나, 주 에이전트가 하위 에이전트에 입력을 넘기거나, 조직이 A2A로 협업할 때 파일 내용을 컨텍스트 창에 로드하는 대신 가벼운 경로 문자열을 전달합니다(4장). 이는 단일 에이전트가 파일 시스템에 메모리와 능력을 두는 방법을 설명한 5장의 ‘에이전트 허브로서의 파일 시스템’ 개념과 맞닿습니다. 여기서는 같은 추상화를 여러 에이전트로 확장합니다. 비공개, 공유, 외부, 내장 저장소를 마운트한 가상 디렉터리 트리가 멀티 에이전트 협업의 저장 기반을 제공합니다.

에이전트 간 통신과 제어

파일 시스템이 에이전트 사이의 산출물 교환 문제를 해결하지만 협업에는 제어 평면도 필요합니다. 바로 여기서 표 10-3의 생명 주기 관련 행이 쓰입니다. 4장에서 제공한 생성(spawn_subagent), 메시지 전송(send_message_to_subagent), 취소(cancel_subagent), 탐색(list_agents) 도구 프리미티브는 프로세스 세계의 fork, message, kill, ps에 해당합니다. 이 절에서는 인터페이스 정의를 반복하지 않고 멀티 에이전트 협업에 필수이지만 흔히 놓치는 네 능력에 초점을 둡니다.

I. 메시지 전달. 가장 단순한 형태는 지점 간 통신으로 에이전트 A가 send_message_to_agent_b(content)를 직접 호출합니다. 토폴로지가 고정되어 있고 에이전트가 적은 상황(예: 이 장의 실험 10-4 전화 + 컴퓨터 이중 에이전트 구성)에 적합합니다. 에이전트 수가 늘고 비동기 병렬성이 필요하면 지점 간 연결 수가 에이전트 수의 제곱으로 증가하며 송신자와 수신자가 동시에 온라인이어야 합니다. 이때는 메시지 버스를 사용해야 합니다(뒤의 ‘병렬 조율 패턴’에서 자세히 설명). 에이전트가 버스에 메시지를 게시하고 버스가 구독에 따라 전달하므로 송신자는 구독자를 알 필요가 없습니다. 지점 간이든 버스를 통하든 메시지는 일반적으로 구조화된 봉투(envelope)를 담아야 합니다. 송신자 ID, 대상(특정 에이전트 또는 브로드캐스트), 메시지 유형(예: task_assigned/status_update/result/terminate), JSON 페이로드입니다. 통합 봉투 형식은 신뢰할 수 있는 라우팅과 수신자 파싱을 보장하고 협업 체인을 추적 가능하게 합니다. 이는 멀티 에이전트 시스템 디버깅의 핵심입니다.

II. 상태 질의. 제어 평면에서 가장 과소평가되는 부분입니다. 주 에이전트가 하위 에이전트를 보낸 뒤에는 진행 상황을 볼 수 있어야 합니다. 그렇지 않으면 계속 기다릴지 결정할 수도, 하위 에이전트가 막혔을 때 개입할 수도 없습니다. 직관적인 접근법은 RPC에서 빌려 와 get_subagent_status(agent_id) 질의 인터페이스를 정의하여 ‘실행 중/완료/실패’와 진행률을 반환하게 하는 것입니다. 하지만 이런 풀 인터페이스는 예상보다 훨씬 덜 유용합니다. 하위 에이전트는 생성되는 순간 실행을 시작해 완료하거나 실패할 때까지 계속 작동합니다. 전통적인 일괄 시스템의 작업처럼 대기 상태를 차례로 순환하지 않습니다. Unix 프로그래밍에서 다른 프로세스의 PID로 실행 상태를 반복 조회할 일이 거의 없는 것과 같습니다. 폴링에도 근본적인 딜레마가 있습니다. 너무 자주 하면 토큰을 낭비하고 너무 드물면 늦게 반응합니다. 더 자연스럽게 상태를 얻으려면 이 장의 시작에서 소개한 두 통신 패러다임으로 돌아가야 합니다.

메시지 전달로 상태 얻기. 주 에이전트가 하위 에이전트에 “진행 상황이 어때?”라는 메시지를 보내면 하위 에이전트가 적절한 순간에 답합니다. 모든 것이 비동기입니다. 메시지 전송이 주 에이전트 자신의 실행을 막지 않으며 상대가 언제 답할지, 답하기는 할지는 별개의 문제입니다. 관리자가 부하 직원에게 메신저로 진행 상황을 물으면서 그 자리에서 모든 일을 멈추라고 요구하지 않는 것과 같습니다. 반대로 하위 에이전트가 이정표에 도달했을 때 능동적으로 메시지를 보내 보고할 수도 있습니다. 시스템에 이미 메시지 버스가 있다면 버스에 status_update를 게시하기만 하면 됩니다(실험 10-6의 ‘실시간 모니터링’이 이 형태입니다). 상태를 명시적으로 요청하든 능동적으로 보고하든 메시지의 상태는 실행 중, 입력 필요, 완료, 실패라는 통일된 상태 머신 용어를 사용해야 합니다. 뒤의 A2A 프로토콜이 업무 생명 주기를 정확히 이런 상태 집합으로 표준화합니다.

공유 파일 시스템으로 상태 얻기. 가장 철저한 형태는 궤적 영속화입니다. 하위 에이전트는 실행하면서 각 궤적 이벤트를 JSON으로 직렬화하여 파일 시스템 로그에 추가합니다. 보통 세션당 파일 하나, 한 줄에 이벤트 하나인 JSONL입니다. 1장에서 정의한 궤적은 사용자 메시지, 모델 응답, 도구 호출, 결과의 전체 시퀀스입니다. 주 에이전트에는 상태 보고 프로토콜이 필요하지 않습니다. 이 파일을 직접 읽으면 하위 에이전트가 어떤 도구를 호출하는지, 가장 최근 단계에서 무슨 일이 있었는지, 실패한 재시도를 반복하는 루프에 빠졌는지 등 전체 실행을 살펴볼 수 있습니다. 프로세스 관점에서는 다른 프로세스의 메모리를 직접 읽는 것과 비슷합니다. 하위 에이전트의 컨텍스트를 차지하지 않고 협조에 의존하지 않으며 가장 세밀한 관찰을 제공합니다.

이렇게 빠짐없는 세부 정보는 부담이기도 합니다. 궤적은 쉽게 수만 토큰에 이르고 주 에이전트는 읽은 뒤 증류해야 하므로 시간과 토큰을 모두 소비합니다. 대부분의 상황에서는 합의된 진행 파일이 더 실용적입니다. 하위 에이전트를 시작할 때 각 항목을 끝낼 때마다 progress.md를 업데이트하라고 지시합니다. 주 에이전트는 언제든 이 가벼운 파일을 읽어 진행 상황을 파악할 수 있습니다. 두 프로세스가 합의된 형식의 작은 공유 메모리 블록을 예약하고 전체 메모리 상태 대신 증류한 진행 상황을 공개하는 것과 비슷합니다.

진행 파일은 정지 탐지도 가능하게 합니다. progress.md나 궤적 파일의 마지막 수정 시각이 N분 넘게 바뀌지 않으면 시스템은 하위 에이전트가 비활성이라고 보고 제한 시간 안전망을 작동할 수 있습니다(4장의 Heartbeat와 monitor_shell 메커니즘에 대응). 정지한 하위 에이전트가 전체 시스템의 발목을 잡는 일을 막습니다.

궤적 영속화의 가치는 모니터링을 훨씬 넘어섭니다. 1장의 결론인 “에이전트의 컨텍스트 = 정적 접두부 + 궤적”을 떠올려 보십시오. 정적 접두부(시스템 프롬프트, 도구 정의)는 코드로 정해지고, 궤적은 모델이 볼 수 있는 대화 상태를 담습니다. 도구와 세션 상태를 궤적에서 재구성할 수 있거나 별도 체크포인트에 보존하고, 작업 산출물을 파일 시스템에 원자적으로 기록한다면 궤적 파일과 정적 접두부를 다시 불러와 마지막으로 확인된 지점에서 실행을 재개할 수 있습니다. 읽기 전용 도구도 브라우저 세션이나 페이지 커서 같은 휘발성 상태를 가질 수 있으므로 별도 복구 계약이 필요합니다.

그러나 궤적만으로 외부 시스템까지 포함한 전체 상태를 항상 복구할 수 있는 것은 아닙니다. 결제·예약·메시지 전송처럼 외부 부작용이 있는 도구는 작업이 성공한 뒤 결과를 로그에 쓰기 전에 프로세스가 중단될 수 있습니다. 호출 전에 클라이언트가 만든 작업 ID, 멱등성 키와 정규화한 요청을 내구성 있게 기록해야 합니다. 중복 제거와 상태 조회는 서로 다른 외부 계약입니다. 멱등 호출에서는 동일한 논리 작업에 정확히 같은 요청과 키를 사용해야 하며, 서버가 보장하는 키 보존 기간 안에서만 중복 방지를 기대할 수 있습니다. 상태 조회는 멱등성 키나 외부 시스템이 발급한 거래·작업 ID로 별도로 지원될 수 있습니다. 응답을 받은 뒤에는 그 외부 ID와 결과를 기록합니다. 재개할 때는 지원되는 조회 인터페이스로 실제 상태를 먼저 확인해 성공·실패·미확정 결과를 판정합니다. 미확정이면 원래 요청이 변하지 않았고 외부 시스템의 중복 제거 계약과 키 유효기간이 모두 보장되는 경우에만 같은 키로 재시도하며, 그렇지 않으면 자동 반복 대신 수동 조정으로 넘깁니다.

이 조건을 갖춘 영속화는 데이터베이스의 미리 쓰기 로그(WAL)와 비슷합니다. 이벤트를 추가 전용 로그에 먼저 기록하고 주기적 체크포인트와 결합하면, 하위 에이전트를 마지막으로 확인된 상태에서 다시 시작하고 궤적을 이벤트별로 재생해 실패 원인을 찾으며 다른 에이전트에 감사 가능한 인수인계 자료를 넘길 수 있습니다(3장의 ‘사실 로그 + 주기적 체크포인트’ 메모리 설계는 같은 발상을 메모리 시스템에 적용한 것입니다).

III. 실행 종료. 병렬 협업에는 ‘하나가 성공하면 나머지는 필요 없다’는 상황이 흔합니다. 여러 에이전트가 따로 검색하다 하나가 대상을 찾으면 나머지는 즉시 멈춰야 합니다(이 장 실험 10-6의 연쇄 종료). 종료에는 두 단계가 있으며 Unix 사용자라면 SIGTERM과 SIGKILL의 차이로 이해할 수 있습니다. 정상 종료가 우선입니다. 주 에이전트가 terminate 신호를 보내면 하위 에이전트가 현재 단계의 안전한 지점에서 응답하고 자원을 정리하고(브라우저 세션 닫기, 대기 중인 파일 쓰기, 잠금 해제), 확인(ack)을 보낸 뒤 종료합니다. 강제 종료는 폴백입니다. 하위 에이전트가 정상 신호에 응답하지 않을 때만 프로세스를 직접 종료하며, 해제되지 않은 자원과 불완전한 쓰기가 남을 수 있습니다. 두 가지 엔지니어링 사항에 주의해야 합니다. 첫째, 정상 종료를 위해 하위 에이전트는 루프에서 종료 신호를 주기적으로 확인해야 합니다(4장의 인터럽트 메커니즘과 비슷함). 그렇지 않으면 신호를 받을 수 없습니다. 둘째, 연쇄 종료에는 경쟁 조건이 있습니다. 여러 하위 에이전트가 거의 동시에 성공을 보고할 수 있습니다. 주 에이전트는 잠금이나 멱등 설계로 하나의 성공만 받아들이고 종료 신호를 한 번만 브로드캐스트해야 합니다. 실험 10-6의 경쟁 조건 논의를 참고하십시오.

한 가지 문제가 남습니다. 주 에이전트가 종료된 뒤 여전히 실행 중인 하위 에이전트는 어떻게 될까요? 가장 깔끔한 엔지니어링 접근법은 Go의 context를 빌립니다. 종료가 생성 관계를 따라 아래로 전파됩니다. 한 에이전트를 취소하면 그 에이전트가 만든 모든 하위 에이전트도 함께 취소하여 고아 하위 에이전트가 남지 않게 합니다. 앞서 말한 ‘하위 에이전트가 안전한 지점에서 종료 신호를 확인’하는 것은 Go에서 ctx.Done()을 폴링하는 것과 정확히 대응합니다. 반대로 주 에이전트와 분리된 장기 실행 백그라운드 에이전트(Unix의 nohup과 비슷함)가 정말 필요하다면 새 생명 주기 트리에서 시작하게 하여(context.Background()에 해당) 부모와 함께 종료되지 않음을 명시적으로 선언합니다.

IV. 자원 관리와 스케줄링. 운영체제의 나머지 절반은 희소 자원을 배분하는 일입니다. 프로세스 세계의 희소 자원은 CPU 시간과 메모리이고 에이전트 세계에서는 토큰, 돈, 동시성 예산입니다. 하위 에이전트가 한 단계 실행할 때마다 세 가지를 모두 소비합니다. 이 책임은 보통 관리자나 런타임에 있습니다. 하위 에이전트를 시작할 때 단계·토큰 예산을 정하고 초과하면 멈춥니다. 어려운 업무는 강한 모델에, 기계적인 업무는 저비용 모델에 맡깁니다. 수십 에이전트가 API 할당량을 한꺼번에 소진하지 않도록 동시성을 제한합니다. 더 긴급한 업무가 들어오면 실행 중인 하위 에이전트를 중단합니다. 이것이 선점입니다. 이 분야의 실무는 CPU 스케줄링보다 훨씬 덜 성숙했지만 멀티 에이전트 시스템의 비용 상한을 결정하므로 아키텍처 설계 단계에서 고려해야 합니다.

산출물 교환(데이터 평면)과 메시지 전달, 상태 질의, 실행 종료, 자원 스케줄링(제어 평면)이 함께 공유 컨텍스트 없는 멀티 에이전트 시스템을 지원합니다. 아래의 세 협업 토폴로지는 근본적으로 이 두 평면 위에서 제어권을 누가 쥐고 정보가 어떻게 흐를지 선택한 서로 다른 방식입니다.

에이전트 간 협업 관계와 제어 흐름의 특성에 따라 공유 컨텍스트 없는 협업은 동료 협업 패턴, 관리자 패턴, 탈중앙화 패턴이라는 세 주요 아키텍처로 나뉘며 각각 서로 다른 유형의 업무에 적합합니다.

동료 협업 패턴: 상호 검토와 반복 개선

동료 협업에는 보통 동등한 지위의 에이전트 2~3개가 여러 라운드에 걸쳐 서로 피드백을 제공합니다. 핵심 가치는 인지적 다양성입니다. 서로 다른 에이전트가 같은 문제를 다른 각도에서 살펴 혁신성과 견고성의 균형을 맞추고 어느 단일 에이전트보다 나은 결과를 만듭니다.

관리자 패턴과 탈중앙화 패턴에 비해 동료 협업은 훨씬 구현하기 쉽습니다. 두 에이전트의 역할, 통신 메커니즘, 반복 종료 조건만 정의하면 시스템이 작동합니다. 아이디어를 빠르게 검증하고 프로토타입을 만들기에 이상적입니다.

동료 협업의 가장 흔한 용도 가운데 하나는 에이전트 실무의 빈번한 실패인 조기 종료, 즉 업무를 절반만 하고 멈추는 문제에 대응하는 것입니다. 조기 종료에는 세 가지 대표 형태가 있습니다. 아래 사례는 코딩 에이전트와 사용자 대신 전화하여 판매자·서비스 제공자와 일을 처리하는, 들어가며에서 소개한 에이전트 Pine AI에서 가져왔습니다. 첫째는 게으른 완료 위장입니다. 일부만 하고 전부 끝났다고 선언합니다. 코딩 에이전트가 코드를 작성한 뒤 테스트나 배포를 시도하지 않고 “업무 완료”라고 보고합니다. 사용자가 Pine AI에 용무 두 개를 주었는데 첫 번째만 끝내고 두 번째는 잊은 채 밝게 “모두 처리했습니다”라고 말합니다. 둘째는 성급한 포기입니다. 한 경로가 막혔다고 전체 업무가 불가능하다고 선언합니다. Pine AI는 전화, 웹 양식, 이메일로 판매자에게 연락할 수 있지만 통화 한 번이 거절되면 채널을 바꿔 다시 시도할 때 성공할 가능성이 높은데도 “할 수 없습니다”라고 말합니다. 셋째는 거짓 성공입니다. 에이전트는 업무가 끝났다고 믿지만 실제로 루프가 닫히지 않았습니다. 상대방이 전화로 환불에 동의했지만 사용자가 모바일 앱에서 한 단계를 확인해야 할 수 있습니다. 에이전트가 “모두 끝났습니다”라고 보고하면 사용자는 후속 행동이 필요하다는 사실을 알지 못하고 환불도 이루어지지 않습니다. 세 형태 모두 같은 근본 원인을 가리킵니다. 검증되기 전까지 ‘완료’는 모델의 주장일 뿐 증명이 아닙니다.

주장을 증명으로 바꾸는 일이 바로 1장의 진화 과정 마지막 단계인 루프 엔지니어링(Loop Engineering)입니다. 에이전트가 다음 할 일을 찾고, 실행하고, 검증하고, 진행 상황을 기록하며 계속 작동하는 루프를 설계하고, 모델 자체가 아니라 검증기가 정말 멈춰도 안전한지 결정하게 합니다. 사람의 역할도 ‘에이전트에 프롬프트를 주는 운영자’에서 ‘루프를 설계하는 엔지니어’로 바뀝니다. Addy Osmani가 2026년 6월 이 용어를 만들었고⁶, Anthropic의 Claude Code 책임자 Boris Cherny는 더 직설적으로 “나는 더 이상 Claude에 프롬프트를 주지 않는다. 내 일은 루프를 작성하는 것이다”라고 말했습니다. 이 논의에서 나온 중심 결론은 루프의 병목은 모델이 아니라 검증기라는 것입니다. 검증을 신뢰할 수 없다면 더 빠른 루프는 나쁜 출력을 더 일찍 완료로 표시할 뿐입니다. 들어가며에서 말했듯 실천이 먼저이고 명명은 나중입니다. 용어가 유행하기 훨씬 전부터 Pine AI를 비롯한 선도 에이전트 팀은 ‘루프 + 검증’으로 조기 종료에 대응하고 있었습니다. 이 검증을 구성하는 가장 효과적인 방법이 아래의 제안자-검토자 패러다임입니다.

구체적인 프레임워크: LoopX. LoopX는 루프를 모델의 프롬프트와 채팅 기록에서 꺼내 에이전트 런타임에 종속되지 않는 지속형 제어 평면에 둡니다. 목표와 경계는 ‘왜 하는가’를 설명하고, 게이트와 할 일은 ‘지금 무엇을 해도 되는가’를 정하며, 증거와 쿼터는 ‘계속해도 되는가’를 판단하고, 인계는 이후 턴이나 다른 에이전트가 작업을 이어받게 합니다. 하나의 통제된 실행은 다음의 명확한 프로토콜로 압축됩니다.

LoopX 결정 → 에이전트 실행 → 독립 검증기 증명 → LoopX 커밋

에이전트는 계속 추론하고 도구를 사용하며 후보 산출물을 만듭니다. LoopX는 에이전트 런타임을 대체하지 않고 턴 사이의 연속성을 관리합니다. 독립 검증을 통과한 결과만 지속형 진행 상태를 갱신하고 쿼터를 소비할 수 있습니다. 검증 실패는 복구나 재계획으로 라우팅되고, 사람의 게이트, 대기 상태, 예산 한도는 실행 전에 루프를 멈춥니다. 이 경계는 루프 엔지니어링 원칙을 검사 가능한 시스템 불변 조건으로 바꿉니다. 모델은 ‘완료’를 제안할 수 있지만 자신의 ‘완료’를 승인할 수는 없습니다. LoopX v0.4.0은 통제된 Turn 경로를 아직 실험적이라고 명시하므로, 여기서는 일반적인 작업 품질 향상의 증거가 아니라 ‘루프 + 검증 + 종료 조건’의 구체적인 프레임워크로 사용합니다.⁷

제안자-검토자 패러다임.

제안자-검토자는 정석적인 동료 협업 패러다임입니다. 5장에서 PPT 생성, 동영상 편집, 로그 시각화라는 세 실험을 통해 설계 원칙과 실제 활용을 이미 다뤘습니다. 제안자 에이전트가 코드를 생성하면 검토자 에이전트가 실행 결과를 렌더링하고 시각-언어 모델로 품질을 평가하고 구조화된 개선 제안을 제공합니다. 결과가 요구 기준을 충족할 때까지 반복합니다.

이 패러다임은 보안 검토(제안자가 행동 계획을 만들고 검토자가 규정 준수와 잠재적 위험을 확인), 콘텐츠 조정(제안자가 답변 초안을 쓰고 검토자가 비즈니스 규칙과 언어 규범을 확인), 코드 검토(제안자가 코드를 쓰고 검토자가 보안과 모범 사례를 확인) 같은 상황에도 적용할 수 있습니다.

단일 에이전트가 생성한 뒤 자신의 작업을 검토하면 왜 안 될까요? 바로 앞의 ‘멀티 에이전트가 단일 에이전트보다 실제로 나은 때’ 기준이 적용됩니다. 검토가 새 정보를 도입하지 않는다면 그저 ‘모델에 다시 생각하라고 요구’하는 것입니다. 관련 연구는 명확한 답을 줍니다. Huang 등은 ICLR 2024 논문 “Large Language Models Cannot Self-Correct Reasoning Yet”에서 외부 피드백 없이 GPT-4에 자신의 답을 검토하고 수정하게 하면 정확도가 오히려 떨어진다는 사실을 발견했습니다. 모델은 틀린 답을 옳게 바꾼 횟수보다 옳은 답을 틀리게 바꾼 횟수가 더 많았습니다.

TACL에 실린 2024년 서베이 논문 “When Can LLMs Actually Correct Their Own Mistakes?”(arXiv:2406.01297)도 이 결론을 확인했습니다. 테스트 사례 실행 결과나 외부 도구의 검증 출력처럼 신뢰할 수 있는 외부 피드백이 없으면 모델 자체의 ‘자기 수정’에만 의존하는 방식은 대체로 효과가 없습니다.

ICLR 2024의 CRITIC 논문은 직관적인 비교 실험을 제공합니다. CRITIC은 모델이 검색 엔진, Python 인터프리터 같은 외부 도구로 자신의 답을 검증하게 하여 성능을 크게 높였습니다. 하지만 실험자가 도구 검증 단계를 없애고 모델의 자기 평가만 남기자 개선의 대부분이 사라졌습니다. 이는 검토의 가치가 ‘모델에 다시 생각하라고 요구’하는 데 있지 않고 모델이 생성할 때 이용할 수 없었던 새 정보, 즉 테스트 결과, 렌더링된 스크린샷, 컴파일 오류, 외부 검색 결과를 도입하는 데 있음을 보여 줍니다.

이것이 제안자-검토자 패러다임의 핵심 설계 원칙입니다. 5장의 PPT 생성 실험에서 검토자 에이전트의 가치는 ‘같은 모델로 코드를 다시 보는 것’이 아니라 PPT를 렌더링하고 스크린샷을 찍는 것이었습니다. 스크린샷에는 제안자 에이전트가 코드를 생성할 때 얻을 수 없었던 시각 정보가 있습니다. 마찬가지로 코드 생성 상황에서 테스트 사례 실행의 통과/실패 결과는 코드를 작성할 때 없었던 새로운 신호입니다. 검토자의 독립적인 가치는 정확히 제안자가 이용할 수 없었던 외부 피드백에 접근하는 데서 나옵니다.

루프 엔지니어링 관점에서 보면 업계가 분류한 루프 패턴은 이 책의 패턴과 대응합니다. 사람 승인으로 닫히는 루프는 사람이 최종 검토자인 4장의 사전 승인에 해당합니다. 예산이나 라운드 상한이 있는 열린 루프는 최대 다섯 라운드를 허용하는 5장의 다중 라운드 PPT 반복에 해당합니다. 오케스트레이션된 하위 에이전트는 다음 절의 관리자 패턴에 해당합니다. 따라서 루프 엔지니어링은 새로운 아키텍처가 아니라 루프 + 검증 + 중단 조건이라는 공통 프레임워크로 이러한 협업 패턴을 통합합니다. 제안자-검토자 패러다임은 이 프레임워크에서 검증 역할을 채웁니다.

확장: 다른 동료 협업 패턴.

토론: 여러 에이전트가 서로 다른 입장을 가지고 대립적 대화로 문제 공간을 탐색합니다. 예를 들어 기술 해법을 평가할 때 에이전트 A는 ‘지지자’ 역할로 장점과 기회를 나열하고, 에이전트 B는 ‘반대자’ 역할로 위험과 한계를 지적합니다. 각 토론 라운드에서 상대의 주장에 반박하거나 확장합니다. 단일 에이전트가 문제를 분석하면 한 관점을 선호하고 반대 증거를 놓치는 경우가 많습니다. 구조화된 토론은 양쪽 입장을 충분히 발전시켜 의사 결정자가 더 균형 잡힌 판단을 내리게 돕습니다.

하지만 토론의 실제 효과는 학계에서도 논쟁 중입니다. Tran과 Kiela의 2026년 연구⁸는 다중 홉 사고 업무에서 단일 에이전트와 다섯 가지 멀티 에이전트 아키텍처(순차, 토론, 앙상블, 병렬 역할, 하위 업무 병렬)를 비교했습니다. 그 결과 사고 토큰 예산을 같게 하면 단일 에이전트가 멀티 에이전트 시스템과 비슷하거나 더 좋은 성능을 냈습니다(컨텍스트 활용이 일정 수준까지 저하된 경우는 제외). 연구자들은 정보 이론의 데이터 처리 부등식으로 설명했습니다. 토론에 참여한 여러 에이전트가 정확히 같은 텍스트 정보를 처리하며 중간 결론을 에이전트 사이에서 직렬로 전달할 때마다 정보는 손실될 수만 있고 새로 생길 수는 없습니다. 일부 학술 논문에서 토론 방식이 주는 이점은 여러 에이전트가 더 많은 전체 계산량을 소비했기 때문일 가능성이 큽니다. 이 주장의 경계를 명확히 해야 합니다. ‘중간 결론의 멀티 에이전트 직렬 전달’이 만드는 정보 병목을 지적하는 것이며, 같은 문제를 독립적으로 여러 번 샘플링한 뒤 집계하는 방법(예: 자기 일관성, 다수결)이나 생성과 검증 난도의 비대칭(답 생성은 어렵고 검증은 쉬움)을 활용한 생성-검증 분업을 부정하지 않습니다. 이런 상황은 추가 독립 샘플링을 도입하거나 업무 자체의 비대칭 구조를 활용하므로 데이터 처리 부등식의 적용 범위에 들지 않습니다.

브레인스토밍: 여러 에이전트가 독립적으로 아이디어를 생성한 뒤 서로 공유하며 영감을 줍니다. 예를 들어 제품 혁신 업무에서 에이전트 1이 ‘소셜 공유 기능 추가’를 제안하면 에이전트 2가 영감을 받아 ‘소셜 네트워크 공유뿐 아니라 개인화된 공유 포스터도 생성’을 제안하고, 에이전트 3이 둘을 종합하여 ‘사용자가 포스터 템플릿을 직접 만들 수 있는 템플릿 마켓플레이스’를 제안합니다. 서로 다른 프롬프트나 모델을 사용해 에이전트마다 ‘사고 선호’가 다르므로 서로 자극하여 더 넓은 해법 공간을 탐색하고 단일 에이전트가 생각하기 어려운 창의적 조합을 찾습니다.

패널 토론: 여러 에이전트가 각기 특정 전문 분야의 관점을 대표하여 학제 간 문제를 함께 논의합니다. 예를 들어 신제품의 실현 가능성을 평가할 때 엔지니어 에이전트는 기술 관점에서 구현 난도를 분석하고, 제품 에이전트는 사용자 경험 관점에서 시장 매력을 평가하며, 운영 에이전트는 비용·자원 관점에서 사업 가능성을 분석합니다. 이 에이전트들은 대립하지 않고 상호 보완하며 문제의 전체 그림을 함께 맞추고 도메인 간 제약과 기회를 찾습니다.

관리자 패턴: 중앙 집중식 조율

업무에 다섯 개가 넘는 하위 업무가 포함되거나 동적 스케줄링이 필요하거나 하위 업무 사이의 의존성이 복잡하면 동료 협업만으로 감당하기 어려워 관리자 패턴이 필요합니다. 관리자 에이전트의 업무는 프로젝트 관리자와 비슷합니다. 전체 업무를 이해하고 할당 가능한 하위 업무로 나누며 각각에 알맞은 에이전트를 선택하고 진행 상황을 추적합니다. 예외가 생기면 업무를 재시도하고 에이전트를 교체하거나 계획을 수정하며, 마지막에는 에이전트의 출력을 최종 결과로 통합합니다.

시스템 설계 관점에서 관리자 패턴은 각 전문 에이전트를 관리자가 호출할 수 있는 도구로 모델링합니다. 관리자의 도구 집합에는 검색과 파일 작업 같은 전통적인 외부 도구뿐 아니라 다른 에이전트를 호출하는 인터페이스도 들어갑니다. 관리자는 도구 호출로 적절한 에이전트를 불러 업무 매개변수와 필요한 컨텍스트를 넘기고 완료를 기다린 뒤 결과를 받습니다. 관리자 관점에서 에이전트 호출은 일반 도구 호출과 본질적으로 다르지 않습니다. 둘 다 요청을 보내고 응답을 받습니다. 이 통합 추상화 덕분에 관리자 패턴을 쉽게 확장할 수 있습니다. 능력을 추가하려면 관리자의 핵심 로직을 수정하지 않고 해당 에이전트를 개발하여 도구로 등록하기만 하면 됩니다. 이질성도 자연스럽게 지원합니다. 에이전트마다 서로 다른 모델, 프롬프트, 도구 집합, 심지어 하드웨어 환경을 사용할 수 있습니다.

‘에이전트가 서로에게 도구가 되는’ 추상화는 4장의 ‘협업 도구’ 절에서 확립했습니다. spawn_subagent / send_message_to_subagent / cancel_subagent / list_agents 인터페이스 설계는 여기서 관리자가 하위 에이전트를 호출할 때 그대로 적용됩니다. ‘관리자 → 하위 에이전트’ 방향으로 전달하는 내용은 뒤의 핸드오프 패키지 설계(업무 설명, 확인된 사실과 제약, 구조화된 산출물 참조)를 참고하십시오. 대응하는 질문은 하위 에이전트가 ‘하위 에이전트 → 관리자’ 방향으로 무엇을 반환하는가입니다. 답은 전체 궤적이 아닌 구조화된 요약입니다. 하위 에이전트는 업무 결론, 핵심 발견, 산출물의 파일 경로, 마주친 문제를 반환하고 전체 실행 궤적은 자체 로그에 남겨야 합니다. 그래야 관리자의 컨텍스트가 폭발하지 않고 하위 업무 수에 따라 천천히 선형으로 증가합니다. 아래 실험 10-3의 관리자가 번역 내용을 저장하지 않고 파일 색인만 유지하는 이유도 같습니다.

관리자 패턴에는 본질적인 과제도 있습니다. 관리자는 시스템의 단일 병목이 됩니다. 모든 하위 업무의 성격을 이해하고 적절한 에이전트를 선택하고 컨텍스트를 정확하게 넘겨야 하며, 잘못된 판단은 전체 흐름에 파급됩니다. 전체 업무의 전역 컨텍스트도 유지해야 하므로 업무가 깊어지고 에이전트 호출이 쌓이면 컨텍스트가 급증할 수 있습니다. 따라서 관리자에는 세심하게 설계한 프롬프트, 효과적인 컨텍스트 관리 전략, 적절한 세밀도의 업무 분해가 필요합니다.

2025년 Plan-and-Act 논문⁹은 이를 실증적으로 분석했습니다. 계획자-실행자 이중 에이전트 아키텍처에서 약한 계획자가 전체 시스템의 가장 중대한 병목입니다. 계획자의 계획 품질이 충분히 높으면 비교적 단순한 실행자로도 좋은 결과를 얻을 수 있습니다. 반대로 계획자의 업무 분해가 잘못되면 이후 실행자의 모든 작업이 잘못된 전제 위에 세워집니다. 연구는 WebArena-Lite 벤치마크에서 성공률 54%를 달성했으며 핵심 기여는 실행자의 실행이 아니라 계획자의 계획 능력 개선이었습니다. 모든 에이전트에 자원을 균등 배분하기보다 가장 강한 모델과 가장 세심하게 작성한 프롬프트를 관리자(계획자)에 주어야 한다는 교훈입니다.

이는 4장의 주장과 충돌하지 않습니다. 4장은 제안 모델과 검토 모델의 능력이 비슷해야 한다고 했지만 이는 검토 상황에 관한 말입니다. 검토자는 검토 대상의 사고를 따라가야 결함을 찾을 수 있습니다. 검토자가 대상보다 훨씬 약하면 사고를 충분히 따라가지 못해 결함을 식별하지 못할 수 있습니다. 관리자 패턴은 다른 문제인 계획과 실행의 분업을 다룹니다. 계획자가 업무를 잘못 분해하면 아무리 강한 실행자도 복구할 수 없습니다. 따라서 가장 강한 모델과 가장 신중한 프롬프트를 계획자에게 먼저 줍니다. 실행자들의 능력이 균형을 이뤄야 하는지는 하위 업무가 얼마나 긴밀하게 결합되어 있는지에 달려 있습니다. 출력을 마지막에 하나로 조립해야 한다면 가장 약한 고리가 전체 품질을 끌어내리는 경우가 많습니다.

순차 조율 패턴.

관리자가 전문 에이전트를 순서대로 호출합니다. 각 에이전트가 완료한 뒤 결과를 반환하면 관리자가 다음 단계를 결정합니다. 제어 흐름이 선형적이고 단순하며 명확하여 하위 업무의 순차적 의존성이 뚜렷한 상황에 적합합니다.

실험 10-3 ★★: 도서 번역 에이전트

도서 번역은 멀티 에이전트 협업에 매우 적합한 복잡한 업무입니다. 기술 서적을 번역하려면 한 언어의 텍스트를 다른 언어로 바꾸는 데 그치지 않고 전문 용어의 일관성, 맥락의 정확성, 전체적인 유창함을 보장해야 합니다. 예를 들어 대규모 언어 모델을 다룬 영어 책에는 관례적 번역이 여러 개인 용어가 반복해서 많이 등장할 수 있습니다. 책 전체에서 일관성을 유지해야 합니다. 1장에서 agent를 “智能体”(‘지능형 개체’, 중국어 표준 용어)로 옮겼다면 뒤에서 다른 번역인 “代理”(‘프록시’)로 바꿀 수 없습니다.

단일 에이전트를 사용하면 심각한 컨텍스트 관리 문제가 생깁니다. 에이전트가 책을 장별로 처리하면서 전체 용어집, 번역한 장, 현재 문단, 번역 작업 추적, 도구 결과가 컨텍스트에 쌓입니다. 수백 쪽 분량의 기술 서적에 이러한 중간 자료까지 더하면 컨텍스트 창을 쉽게 넘습니다. 더 중요한 점은 지나치게 긴 컨텍스트로 작업하는 에이전트가 ‘길을 잃기’ 쉽다는 것입니다. 앞의 용어 관례를 잊고 2장과 8장에서 서로 다른 번역을 사용하거나, 교정 중 중복 검사에 자원을 낭비하거나, 주의가 너무 분산되어 존재하지 않는 용어 규칙을 ‘기억’할 수도 있습니다.

관리자 패턴은 업무 분해와 책임 분리로 이 문제를 해결합니다.

• 용어집 에이전트: 책 전체를 받고 반복되는 전문 용어를 식별하고 전문 사전과 번역 지침을 참고해 구조화된 용어집(JSON/CSV 형식, 영어 용어, 중국어 번역, 품사, 사용 맥락 포함)을 생성합니다. 완료하면 용어집을 공유 파일 시스템에 쓰고 에이전트를 폐기하여 자원을 해제할 수 있습니다.
• 번역 에이전트: 현재 장, 용어집, 번역 지침(대상 독자 수준, 언어 스타일)을 받아 유창한 중국어로 번역합니다. 용어집의 용어에는 지정된 번역을 엄격하게 사용하며 새 용어는 번역을 추론하고 검토 표시를 합니다. 각 인스턴스는 간섭 없이 독립 컨텍스트에서 일합니다. 번역문은 파일 시스템(예: chapter1_zh.md)에 씁니다. 관리자는 여러 인스턴스를 병렬이나 순차로 시작할 수 있습니다.
• 교정 에이전트: 모든 번역문과 용어집을 받아 용어 번역이 통일되었는지 확인하고 불일치를 찾고 전체 유창성과 가독성을 점검하는 일관성 검사를 수행합니다. 교정 보고서를 만들어 파일 시스템에 씁니다.
• 관리자 에이전트: 컨텍스트에는 주로 업무 설명, 실행 계획, 각 에이전트의 호출 기록, 진행 상태를 저장합니다. 전체 번역문은 파일 시스템에 남겨 두고 컨텍스트에 저장하지 않으며 파일 색인만 유지합니다. 교정 보고서에 따라 특정 장을 번역 에이전트에 돌려보내 수정하게 할 수 있습니다.

그 결과 번역한 장이 늘어나도 관리자의 컨텍스트를 관리 가능한 수준으로 유지할 수 있습니다.

핵심 장점은 컨텍스트 격리입니다. 용어집 에이전트는 용어 추출에 필요한 내용만, 번역 에이전트는 현재 장과 용어집만 봅니다. 교정 에이전트는 전체 텍스트에 접근해야 하지만 일관성 검사에만 집중합니다. 각 에이전트의 컨텍스트가 간결하고 집중된 상태를 유지하여 효율이 높아지고 정보 과부하로 인한 오류가 줄어듭니다.

실험 요구 사항: 1. 코드와 그림이 많이 포함된 기술 서적을 원문으로 선택합니다. 2. 관리자, 용어집, 번역, 교정이라는 네 유형의 에이전트를 구현합니다. 3. 각 에이전트의 컨텍스트 사용량을 기록하여 관리자 패턴이 컨텍스트 증가를 얼마나 효과적으로 통제하는지 검증합니다. 4. 번역 품질, 실행 효율, 자원 소비 측면에서 단일 에이전트와 관리자 패턴을 비교합니다.

병렬 조율 패턴.

여러 하위 업무를 병렬로 실행할 수 있으면 순차 패턴은 비효율적입니다. 병렬 조율은 여러 에이전트가 동시에 작업하게 하여 처리량을 크게 높입니다. 관리자 에이전트는 병렬 업무를 계획하고 실행 중인 모든 에이전트를 실시간으로 모니터링하고 통신을 조율하며, 에이전트가 성공하거나 실패할 때 시스템 전체의 결정을 내려야 합니다. 일반적으로 인프라로 메시지 버스가 필요합니다. 에이전트가 메시지를 게시하고 관심 있는 메시지 유형을 구독하는 ‘공개 게시판’으로 생각할 수 있으며 비동기·비차단 통신을 가능하게 합니다. 단순한 것부터 복잡한 것까지 흔한 구현 두 가지는 Redis Pub/Sub과 RabbitMQ 같은 메시지 큐입니다. Redis Pub/Sub은 가볍고 메시지를 즉시 전달하지만 영속화하지 않으므로 수신자가 오프라인이면 놓칩니다. RabbitMQ 같은 시스템은 메시지를 디스크에 영속화하므로 수신자가 잠시 오프라인이어도 보존합니다. 메시지는 일반적으로 송신자 ID, 대상 에이전트(또는 브로드캐스트 표시), 메시지 유형, 페이로드를 담은 JSON 봉투를 사용합니다.

Lingtai: 관리자 패턴을 제품화한 사례. Lingtai는 장기 실행 에이전트를 위한 로컬 파일 기반 공간입니다¹⁰. 세 역할은 이 절의 개념과 밀접하게 대응합니다. 주 에이전트(main agent)는 사용자가 상호작용하는 영속적 허브로 계획과 메모리를 보유하고 다른 역할을 생성하여 관리자 에이전트 자리를 차지합니다. 데몬(daemon)은 잡음이 많고 범위가 제한된 업무를 위해 생성했다가 이후 폐기하는 단기 병렬 작업자이며 결론만 보존합니다. 하위 에이전트가 전체 궤적이 아닌 구조화된 요약을 반환해야 한다는 원칙과 병렬 조율 패턴을 모두 제품화합니다. 아바타(avatar)는 자체 메모리, 메일함, 책임을 가진 영속적인 전문 팀원으로 세션을 넘어 유지할 가치가 있는 전문 분야를 위해 설계되었습니다.

Lingtai 설계의 나머지 부분도 앞 절과 맞닿습니다. 지식은 각 에이전트의 영속적인 비공개 메모리 파일에 있고 스킬은 모든 에이전트가 공유하는 Markdown 플레이북입니다. ‘에이전트 관점에서 본 파일 시스템’에서 설명한 내장 시스템 리소스입니다. 에이전트의 컨텍스트 창이 가득 차면 탈피(molt)합니다. 주의 깊은 요약을 쓴 뒤 그 요약과 영속 메모리를 유지한 채 새 컨텍스트로 시작하며 2장의 컨텍스트 압축 접근법을 따릅니다. 에이전트의 정체성, 메모리, 능력이 모두 프로젝트 디렉터리의 일반 파일에 있으므로 기반 모델을 바꿔도 에이전트는 바뀌지 않습니다. 이런 의미에서 에이전트는 곧 자신의 파일입니다. 이는 표 10-3의 처음 두 행을 제품화합니다. 프로그램과 메모리가 모두 파일로 환원되므로 언제든 프로세스를 다시 만들 수 있습니다.

실험 10-4 ★★★: 컴퓨터를 사용하면서 전화로 대화하는 에이전트

선수 지식: 이 실험은 9장의 컴퓨터 사용·음성 에이전트 기술을 통합합니다. 먼저 9장의 관련 실험을 완료하기를 권합니다.

실제 업무의 상당수는 여러 능력이 순서대로가 아니라 동시에 작동해야 합니다. 예를 들어 사람 비서는 고객과 대화하면서 문서를 찾고 메모할 수 있습니다. 에이전트 하나에 실시간 대화와 컴퓨터 상호작용을 모두 맡기면 계속 업무를 전환해야 하여 어느 한 활동이 중단될 수 있습니다. 멀티 에이전트 시스템은 지연 시간에 민감한 각 업무를 전문 에이전트에 맡기고 비동기 메시지로 조율합니다. 전화 에이전트에는 짧은 지연의 음성 인식·합성이 필요하고 컴퓨터 에이전트에는 강한 시각 이해와 행동 계획 능력이 필요합니다.

상황: AI 에이전트가 사용자의 복잡한 항공권 예약 양식 작성을 돕습니다. 웹페이지를 조작하면서 전화로 사용자에게 개인정보(이름, 신분증 번호, 항공편 선호 등)를 묻고 확인해야 합니다. 전화 대화와 웹 상호작용 모두 반응성을 유지해야 하므로 단일 에이전트는 어려움을 겪지만 이중 에이전트 시스템에서는 각 에이전트가 한 역할에 집중할 수 있는 대표 사례입니다.

이중 에이전트 아키텍처:

전화 에이전트: ASR, LLM, TTS로 만든 음성 에이전트입니다. 사용자의 자연어 응답을 해석하고 핵심 정보를 추출하여 메시징 시스템으로 컴퓨터 에이전트에 보냅니다. 컴퓨터 에이전트의 메시지(예: “사용자의 신분증 번호가 필요함”, “페이지 로딩 오류”)도 받아 사용자에게 적절히 응답합니다.

컴퓨터 에이전트: Anthropic Computer Use나 browser-use 같은 브라우저 자동화 프레임워크로 페이지를 해석하고 양식 필드를 식별하여 채우며 필요할 때 전화 에이전트에 도움을 요청합니다.

통신 메커니즘: 두 가지 선택지가 있습니다. - 단순 해법: 도구 호출을 통한 지점 간 통신. 예: send_message_to_computer_agent(message) / send_message_to_phone_agent(message) - 완전한 해법: 메시지 버스 + 관리자 에이전트. 송신자, 수신자, 유형, 내용을 포함하는 통합 메시지 형식 사용

병렬 협업 메커니즘(이 장의 두 ‘전화 + 컴퓨터’ 실험이 공유): 두 에이전트는 별도의 스레드나 프로세스에서 실행되며 각각 독립된 ReAct 루프를 유지합니다. 전화 에이전트는 오디오를 받고 ASR로 전사하고 LLM으로 응답을 생성하고 TTS로 합성해 재생하고 컴퓨터 에이전트의 메시지를 확인하는 과정을 반복합니다. 컴퓨터 에이전트는 스크린샷을 캡처하고 시각-언어 모델로 페이지를 해석하고 행동을 계획·실행하고 전화 에이전트의 메시지를 확인하는 과정을 반복합니다. 둘은 병렬로 실행되어야 합니다. 컴퓨터 에이전트가 요소를 찾고 텍스트를 입력하는 동안 전화 에이전트는 온라인 상태를 유지하며 사용자와 대화해야 합니다(“네, 이름을 입력하고 있습니다… 신분증 번호를 알려 주시겠어요?”). 다른 에이전트가 보낸 메시지는 [FROM_COMPUTER_AGENT] '다음' 버튼을 찾을 수 없음. 사용자 확인이 필요할 수 있음, [FROM_PHONE_AGENT] 사용자가 이름은 '장산', 신분증 번호는 123456이라고 말함 같은 라벨을 붙여 수신 에이전트의 컨텍스트에 포함할 수 있습니다.

실험 요구 사항: 1. ASR/TTS API와 브라우저 조작 프레임워크를 바탕으로 이중 에이전트 아키텍처를 구현합니다. 2. 효율적인 양방향 통신 메커니즘을 구현합니다. 3. 정보 수집과 양식 입력이 동시에 이루어지는 진정한 병렬 작동을 보장합니다. 4. 예외와 오류 사례를 처리합니다.

실험 10-5 ★★★: 자율적으로 오케스트레이션되는 전화·컴퓨터 에이전트

실험 10-4에서는 이중 에이전트 협업을 미리 설계했습니다. 이 실험은 더 나아가 사람이 계획한 흐름을 따르는 대신 에이전트 스스로 협업자를 시작할 시점을 정하는 자율 에이전트 오케스트레이션을 탐구합니다.

상황: 사용자가 URL만 제공하고 어떤 정보를 입력해야 하는지는 지정하지 않은 채 “이 웹사이트에서 등록을 완료해 줘”라고 요청합니다. 관리자 에이전트가 컴퓨터 사용 에이전트를 시작하여 웹사이트에 접속하고 등록 페이지를 로드합니다.

작업 중 컴퓨터 사용 에이전트는 등록 양식이 매우 복잡하며 기본 개인정보(이름, 성별, 생년월일), 연락처(전화번호, 이메일, 우편 주소), 신원 확인 정보(신분증 종류, 번호), 선호 설정 등 수많은 필수 필드가 있음을 발견합니다. 컨텍스트를 확인하니 이 정보가 없습니다. 사용자는 구체적인 데이터를 주지 않고 ‘등록을 도와 달라’고만 했습니다.

일반적인 에이전트는 사용자에게 채팅으로 정보를 입력해 달라고 요청합니다. 데이터가 많으면 비효율적이며 형식 오류나 누락 위험이 커집니다. 더 영리한 에이전트는 이 상황이 전화로 정보를 수집하기에 더 적합함을 알아차려야 합니다. 전화 대화는 질문과 확인을 순서대로 할 수 있고 모호한 답을 더 쉽게 명확히 할 수 있습니다.

핵심 혁신은 이 결정을 미리 프로그래밍하지 않고 에이전트가 자율적으로 내린다는 것입니다. 컴퓨터 사용 에이전트의 프롬프트에는 “사용자에게서 구조화된 정보를 많이 수집해야 하고 대화를 통해 점진적으로 할 수 있다면 전화 에이전트를 보조 도구로 호출할 것을 고려하라”는 지시가 있습니다. 도구 집합에는 initiate_phone_call_agent(purpose, required_info)가 포함됩니다.

도구를 호출하면 양식 작성 목표, 수집할 정보, 각 필드의 형식 요구 사항을 식별하는 명확한 업무 컨텍스트를 가진 전화 에이전트를 만듭니다.

두 에이전트는 이어서 실험 10-4의 실시간 비동기 협업 모드로 들어갑니다. 전화 에이전트는 사용자와 브라우저 WebRTC 오디오 세션을 시작하고 질문을 하나씩 합니다. “안녕하세요. 등록 양식 작성을 돕고 있습니다. 먼저 성함을 알려 주시겠어요?” 사용자가 답하면 즉시 {"type": "info_collected", "field": "Name", "value": "Zhang San"}을 컴퓨터 에이전트에 보내고, 컴퓨터 에이전트는 해당 필드를 찾아 채웁니다. 전화 에이전트는 컴퓨터 작업이 끝나기를 기다리지 않고 다음 질문을 계속합니다. 이 하나씩 묻고 하나씩 채우는 워크플로는 작업 지연이 대화를 막지 않게 합니다. 모든 필수 정보를 수집하면 전화 에이전트가 {"type": "task_completed"}를 보내고 컴퓨터 에이전트가 양식을 제출합니다. 여기서 ‘전화’는 실시간 오디오 상호작용을 뜻하며 PSTN 연결이나 E.164 번호는 필요하지 않습니다. 로컬 WebRTC 페이지만으로 이 실험을 수행할 수 있고, 원격으로 배포할 때는 네트워크 환경에 따라 시그널링과 TURN을 추가하면 됩니다.

실험 요구 사항: 1. 전화 에이전트 시작을 자율적으로 결정할 수 있는 컴퓨터 사용 에이전트를 구현합니다. 2. 실시간 양방향 통신과 진정한 병렬 작업을 구현합니다. 3. 정보 형식이 틀리면 피드백하고 다시 묻는 방식으로 예외를 처리합니다. 4. 교환한 메시지의 타임스탬프를 로깅하고 에이전트의 핵심 결정을 기록합니다.

실험 10-6 ★★★: 여러 웹사이트에서 동시에 정보를 수집하는 에이전트

선수 지식: 먼저 4장의 이벤트 기반·인터럽트 메커니즘을 다시 살펴보기를 권합니다.

이 실험은 정보 수집 상황에서 멀티 에이전트 병렬 실행을 적용하는 방법을 탐구합니다. 이질적인 에이전트 두 개의 협업에 초점을 둔 실험 10-4, 10-5와 달리 동질적인 에이전트 여러 개의 병렬 검색과 중앙 조율을 통한 효율적인 업무 완료·자원 최적화에 초점을 둡니다.

문제: 한 대학 안의 여러 단과대학 교수 명단 웹사이트가 주어지면 각 사이트에서 지정된 교수(예: “Zhang Wei”)를 검색합니다. 찾으면 소속 단과대학, 직위, 연구 분야와 관련 정보를 반환합니다.

핵심 과제:

1. 병렬 시작: 관리자 에이전트가 단과대학 웹사이트마다 하나씩 컴퓨터 사용 에이전트 인스턴스 열 개를 동적으로 생성합니다. 각 인스턴스는 자체 브라우저 세션이 있는 독립 프로세스나 스레드여야 하며 서로를 막지 않고 실행할 수 있어야 합니다. 시작할 때 전달하는 매개변수에는 대상 웹사이트 URL, 검색할 교수 이름, 메시지 라우팅용 업무 식별자가 포함됩니다.

2. 실시간 모니터링: 각 에이전트는 실행 중 주기적으로 상태 업데이트(“웹사이트 로딩 중”, “교수 명단 파싱 중”, “대상을 찾지 못함, 업무 완료”, “일치 항목 발견, 세부 정보는 다음과 같음”)를 보냅니다. 관리자 에이전트는 메시지 버스로 업데이트를 받고 업무 상태 표를 유지하며 어느 에이전트가 실행 중인지, 완료됐는지, 오류 상태인지 실시간으로 추적합니다.

3. 연쇄 종료: 컴퓨터공학 단과대학을 맡은 에이전트가 교수를 찾았다고 합시다. 관리자 에이전트에 {"type": "target_found", "agent_id": "agent_3", "data": {...}}을 보내면 관리자는 실행 중인 나머지 에이전트 모두에게 즉시 {"type": "terminate", "reason": "target_found_by_agent_3"}을 보냅니다. 각 에이전트는 언제든 이 메시지를 받고 정상적으로 멈추고 자원을 해제한 뒤 종료를 확인할 수 있어야 합니다. 관리자 에이전트는 모든 확인을 기다리거나 제한 시간이 끝난 뒤 결과를 집계합니다. 구현은 경쟁 조건도 처리해야 합니다.

개념 보충: 경쟁 조건이란? 에이전트 A와 B가 같은 밀리초에 대상 교수를 찾아 둘 다 관리자에게 “찾았습니다!”라고 보고한다고 합시다. 관리자가 제대로 처리하지 못하면 A의 보고를 받고 결과 집계를 시작한 뒤 B의 보고가 도착했을 때 두 번째 집계를 시작할 수 있습니다. 중복 결과나 모순된 상태가 생길 수 있습니다. 일반적인 해법은 잠금입니다. 첫 보고가 상태를 잠그고 이후 보고는 중복으로 인식해 무시합니다.

4. 실패 처리: 작업 중 여러 예외가 생길 수 있습니다. 네트워크 오류나 중단으로 단과대학 웹사이트에 접근하지 못하거나 사이트 구조 때문에 에이전트가 제대로 파싱하지 못할 수 있습니다. 모든 에이전트가 대상을 찾지 못한 채 검색을 마칠 수도 있습니다. 관리자 에이전트는 각 에이전트에 제한 시간(예: 2분)을 정하고 시간 초과를 실패로 처리하며, 오류가 다른 에이전트를 중단시키지 않도록 격리해야 합니다. 모든 에이전트가 끝난 뒤 하나라도 대상을 찾았다면 정보를 반환하고, 그렇지 않으면 “대상 교수를 찾지 못했습니다”라고 보고하며 실패를 요약합니다.

실험 요구 사항: 1. 여러 병렬 에이전트를 동적으로 시작할 수 있는 관리자 에이전트를 구현합니다. 2. browser-use 같은 오픈 소스 프로젝트 기반 컴퓨터 사용 에이전트를 구현합니다. 3. 관리자 에이전트와 여러 자식 에이전트 사이의 양방향 통신을 지원하는 메시지 버스를 구현합니다. 4. 성공 시 연쇄 종료 메커니즘을 구현하여 대상을 찾는 즉시 나머지 모든 에이전트가 빠르게 멈추게 합니다. 5. 여러 예외 상황(웹사이트 접근 실패, 파싱 오류, 모든 에이전트가 대상을 찾지 못함)을 처리합니다. 6. 직렬 실행과 병렬 실행 시간을 측정·비교하여 병렬화의 속도 향상을 정량화합니다.

탈중앙화 패턴: P2P 핸드오프

관리자 패턴은 명확한 제어 구조와 전역 가시성을 제공하지만 탈중앙화 패턴이 단순히 그 단점을 보완하는 것은 아닙니다. 중앙 제어자를 없애는 주된 동기는 인간 사회의 조직 방식을 모방하는 데 있습니다. 여러 동료 역할이 분업하고 서로 검토하며 각자 전문 관점에서 문제를 살피고 누구와 대화할지 스스로 결정하게 합니다. 모든 판단을 하나의 관리자에게 모으지 않습니다. 마이크로서비스 분야에서는 이 두 선택을 오케스트레이션과 코레오그래피라고 부릅니다. 전자는 지휘자가 모든 것을 중앙에서 조율하고 후자는 각 무용수가 스스로 들어갈 때를 감지합니다.

탈중앙화 패턴은 다른 아키텍처 접근법을 사용합니다. 단일 중앙 제어자가 없으며 에이전트가 동료로 협업합니다. 각 에이전트가 전문적 판단에 따라 다른 에이전트에게 연락할 시점을 스스로 결정합니다. 업무를 핸드오프하거나(“제 몫은 끝났으니 이어서 해 주세요”), 피드백을 요청하거나(“이 계획은 기술적으로 가능한가요?”), 문제를 보고합니다(“전달받은 요구 사항이 모순됩니다. 다시 논의해야 합니다”).

다음 사례는 부분적인 탈중앙화에서 완전한 탈중앙화 순으로 나아갑니다. MetaGPT는 고정 파이프라인을 사용하며 통신만 탈중앙화합니다. AutoGen은 공유 대화 기록과 중앙 스케줄링을 결합합니다. OpenAI Swarm은 제어 흐름 결정을 동료 에이전트에 직접 분산합니다.

공유 컨텍스트 없는 핸드오프에서 무엇을 전달할까요? 그림 10-10은 두 핸드오프 유형을 대조합니다. 실험 10-2의 transfer_to_agent는 공유 컨텍스트를 사용하므로 새 역할이 전체 기록을 자동으로 물려받습니다. 핸드오프 체인 패턴은 컨텍스트를 공유하지 않으므로 보내는 에이전트가 받는 에이전트에 필요한 정보를 명시적으로 조립해야 합니다.

실제로 효과적인 ‘핸드오프 패키지’에는 보통 세 부분이 들어갑니다. 업무 설명(수신자가 해야 할 일과 통과 기준), 확인된 사실과 제약(사용자 선호, 비즈니스 규칙, 이전 단계에서 내린 결정), 구조화된 산출물 참조(파일 내용이 아닌 경로이며 수신자가 필요할 때 읽음)입니다. 보내는 에이전트의 시행착오 과정, 중간 작업, 실패한 시도인 전체 궤적은 수신자에게 대부분 잡음이므로 의도적으로 제외합니다.

이것이 두 핸드오프 유형의 본질적인 차이입니다. 공유 컨텍스트 핸드오프는 전체 기록을 유지하여 모든 정보를 보존하지만 컨텍스트가 계속 커집니다. 공유 컨텍스트 없는 핸드오프는 정제한 패키지를 전달하여 일부 정보 손실을 받아들이는 대신 각 에이전트가 깨끗하고 집중된 컨텍스트에서 일하게 합니다. 어떤 에이전트도 다른 에이전트의 작업 과정을 이해할 필요가 없습니다. 핸드오프 패키지와 출력 산출물의 형식·의미만 알면 됩니다. 이 인터페이스 기반 협업은 계약에 의한 설계라는 소프트웨어 엔지니어링 원칙을 따릅니다.

MetaGPT: SOP 주도 소프트웨어 회사 시뮬레이션(파이프라인에서 분리된 통신으로 가는 전환 사례).

MetaGPT의 핵심 통찰은 소프트웨어 회사가 개발하고 다듬어 온 표준 운영 절차(Standard Operating Procedures, SOP)를 멀티 에이전트 시스템의 협업 프로토콜로 활용할 수 있다는 것입니다. 이 SOP를 인코딩하면 각 역할은 조립 라인의 전문 작업자처럼 표준화된 산출물을 만들고, 그 산출물이 자연스럽게 역할 간 통신 인터페이스가 됩니다.

MetaGPT에서 역할은 제품 관리자 → 아키텍트 → 프로젝트 관리자 → 엔지니어 → QA의 고정된 순서로 작업하며, 각 역할은 구조화된 산출물을 출력합니다.

• 제품 관리자 에이전트: 요구 사항 설명을 받아 구조화된 PRD(Product Requirements Document, 기능 목록·사용자 스토리·인수 조건·우선순위 포함)를 생성합니다.
• 아키텍트 에이전트: PRD를 읽고 아키텍처를 결정한 뒤(기술 스택 선정, 모듈 분할, 인터페이스 정의, 데이터 모델 설계) 설계 문서를 출력합니다.
• 프로젝트 관리자 에이전트: 아키텍처 설계를 읽고 시스템을 구체적인 업무 목록과 파일 단위 할당으로 분해하며 모듈의 의존 순서를 명확히 한 뒤 엔지니어에게 업무를 배정합니다.
• 엔지니어 에이전트: 설계 문서를 읽고 배정된 모듈을 구현하여 코드를 만듭니다. 여러 인스턴스가 병렬로 작업할 수 있습니다.
• QA 엔지니어 에이전트: 코드와 PRD를 읽고 테스트 사례를 생성하며 테스트를 실행하고 버그를 기록하여 테스트 보고서를 출력합니다.

MetaGPT가 탈중앙화 통신에 기여한 진정한 부분은 공유 메시지 풀 + 역할별 구독이라는 정보 전달 메커니즘입니다. 각 역할은 모든 역할이 볼 수 있는 풀에 구조화된 메시지를 게시합니다. 다른 역할은 일대일로 통신하는 대신 구독 설정에 따라 자신의 책임과 관련된 메시지만 소비합니다. 게시자는 자신의 출력을 누가 소비할지 알 필요가 없습니다. 역할을 추가하려면 그 역할이 구독할 메시지 유형만 선언하면 되며 기존 역할은 바꿀 필요가 없습니다. 이로써 진정한 분리가 이루어집니다. 예를 들어 제품 관리자를 더 강력한 모델로 교체해도 PRD가 계속 규격을 준수하는 한 다른 에이전트를 수정할 필요가 없습니다.

MetaGPT의 반복 개선은 주로 엔지니어링 단계에서 실행 가능한 피드백을 통해 이루어집니다. 엔지니어가 코드와 테스트를 실행하고 오류와 실패를 디버깅 루프의 지침으로 삼아 테스트가 통과할 때까지 계속합니다. 수정은 다른 에이전트의 의견이 아니라 결정론적인 실행 결과에 따라 이루어집니다.

분명히 말하면 MetaGPT의 제어 흐름은 탈중앙화되어 있지 않습니다. 역할 순서가 SOP로 미리 정해져 있으므로 전체 시스템은 조립 라인에 더 가깝습니다(1장의 용어로는 워크플로). 이 절에서 MetaGPT를 다루는 이유는 메시지 풀과 구독 통신 메커니즘이 탈중앙화 시스템의 가장 중요한 설계 요소인 분리를 보여 주기 때문입니다. “QA가 제품 관리자에게 직접 연락해 요구 사항을 명확히 하기”나 “엔지니어가 아키텍트와 대안 해법을 논의하기” 같은 다방향 동적 피드백은 이 아키텍처에서 자연스럽게 생각할 수 있는 확장이지만 원래 MetaGPT에는 구현되지 않았습니다.

AutoGen 그룹 채팅: 공유 대화 기록 + 중앙 스케줄링. AutoGen의 그룹 채팅에서는 여러 에이전트가 같은 대화에 참여할 수 있습니다. 매 라운드마다 ‘발화자 선택기’가 다음에 말할 에이전트를 결정합니다. 선택기는 단순한 라운드 로빈 규칙을 따르거나 지금까지의 대화를 바탕으로 어떤 에이전트가 응답하기에 가장 적합한지 LLM으로 판단할 수 있습니다. 모든 에이전트의 발언은 참여자 모두에게 공개됩니다.

제어 흐름 관점에서는 완전히 탈중앙화된 방식이 아닙니다. GroupChatManager가 발화자를 중앙에서 선택하며 누구의 차례인지 정하는 일 자체가 제어 흐름 결정이기 때문입니다. 따라서 더 정확한 분류는 공유 대화 기록 + 중앙 스케줄링입니다. 모든 에이전트가 동일한 공개 기록을 보지만 각자 독립적인 시스템 프롬프트와 도구 집합을 유지하며, 선택기가 스케줄링 권한을 가집니다.

이 모델은 계획 검토나 교차 영역 분석처럼 여러 관점의 논의가 필요하고 발화 순서를 미리 정할 수 없는 업무에 적합합니다. 다만 모든 에이전트가 계속 발언하는데도 집단이 앞으로 나아가지 않는 라이브락 형태로 대화가 표류할 수 있습니다. 따라서 명확한 종료 조건이 필수입니다. 이 장의 설계 차원에서 AutoGen은 하이브리드입니다. 스케줄링은 중앙화되어 있고 컨텍스트는 일부 공유됩니다. 이는 토폴로지와 컨텍스트 공유가 서로 독립적인 설계 차원임을 보여 줍니다.

OpenAI Swarm과 Agents SDK: 핸드오프 네트워크. 반대로 OpenAI의 Swarm과 후속 제품인 Agents SDK는 제어 흐름을 P2P 방식으로 탈중앙화합니다. 각 에이전트는 여러 핸드오프 선택지를 가지며 언제든 네트워크의 다른 에이전트로 제어권을 넘길 수 있습니다. 고객 서비스 분류 에이전트가 문제에 환불이 필요하다고 판단하면 환불 에이전트로 업무를 넘깁니다. 그 에이전트가 기술 장애를 발견하면 기술 지원 에이전트로 다시 넘길 수 있습니다. 중앙 스케줄러는 없습니다. 동료 에이전트 사이에서 바통처럼 제어권이 전달되고 각 에이전트가 스스로 라우팅 결정을 내립니다. 이는 그림 10-10 핸드오프 체인 패턴의 엔지니어링 구현입니다. 위험은 순환입니다. A가 B에게 넘기고 B가 다시 A에게 넘기면 업무가 무한히 맴돕니다. 이를 끊으려면 최대 핸드오프 횟수 같은 보호 장치가 필요합니다.

용어: Agent Swarm. 2025년 이후 ‘에이전트 스웜(Agent Swarm)’은 각 벤더의 인기 키워드가 되었지만 단일 아키텍처를 가리키지는 않습니다. 업계의 사용법은 크게 두 가지입니다. 첫째, OpenAI Swarm식 핸드오프 네트워크(LangGraph의 swarm 라이브러리와 Microsoft Agent Framework의 핸드오프 오케스트레이션도 같은 부류)로 이 절의 탈중앙화 패턴에 해당합니다. 둘째, 일부 주류 상용 제품의 Agent Swarm은 규모화된 관리자 패턴입니다. Kimi K2.5가 처음 선보인 Agent Swarm은 주 에이전트가 100개가 넘는 하위 에이전트를 동적으로 생성해 병렬로 실행하며, ‘언제 나눌지, 몇 개로 나눌지’라는 오케스트레이션 결정을 병렬 에이전트 강화 학습으로 모델에 직접 학습시킵니다. Kimi K3는 이를 독립 모델 등급으로 이어 갔고 병렬 에이전트 훈련 샌드박스 AgentEnv¹¹를 함께 오픈 소스로 공개했습니다. Anthropic의 멀티 에이전트 연구 시스템과 Manus의 Wide Research도 모두 orchestrator-worker 스타 토폴로지입니다. 이 책을 다 읽은 독자가 개념 뒤의 본질을 꿰뚫어 보고 제1원리의 관점에서 멀티 에이전트 시스템을 분석할 수 있기를 바랍니다.

조직 간 협업: A2A 프로토콜

앞서 살펴본 모든 시스템은 모든 에이전트가 같은 팀에서 개발되어 같은 시스템 안에서 실행된다고 가정합니다. 이 경우 매개변수 전달, 공유 파일, 메시지 버스라는 세 통신 메커니즘으로 충분합니다. 하지만 협업이 조직 경계를 넘어가서 내 에이전트가 다른 회사의 에이전트를 호출해야 한다면 표준화된 상호 운용 프로토콜이 필요합니다. 프로세스 세계도 같은 진화 과정을 거쳤습니다. IPC는 한 컴퓨터 안에서만 통용되며 컴퓨터 경계를 넘는 순간 TCP/IP 같은 표준 프로토콜과 DNS 같은 서비스 탐색에 의존해야 합니다. 프로세스에 네트워크 프로토콜이 있다면 에이전트에는 A2A가 있습니다. Google이 2025년에 공개하고 이후 관리를 위해 Linux Foundation에 기증한 A2A(Agent2Agent) 프로토콜은 바로 이 목적을 위해 설계되었습니다. 핵심 요소는 세 가지입니다.

• 에이전트 카드(Agent Card): 에이전트의 역량을 설명하는 메타데이터 문서로 지정된 공개 주소에 게시됩니다. 에이전트가 할 수 있는 일, 지원하는 입출력 모달리티, 인증 방법을 선언합니다. 본질적으로 조직 간 역량 탐색 문제를 해결하는 에이전트의 ‘명함’입니다.
• 업무 수명 주기 관리(Task Lifecycle Management): A2A는 협업 단위를 명확한 상태 머신(submitted, in-progress, needs-input, completed, failed)을 가진 업무(Task)로 모델링하여 장기 실행 업무와 진행 상황 스트리밍 업데이트를 기본으로 지원합니다.
• 불투명 협업(Opaque Collaboration): 에이전트는 내부 프롬프트, 사고 과정, 도구 구현을 공개하지 않고 업무와 산출물만 교환합니다. 이는 이 장의 ‘컨텍스트를 공유하지 않는다’는 원칙과 일치하며 조직 간 협업에 필요한 보안 속성입니다.

MCP가 에이전트와 도구 사이의 상호 운용성을 제공한다면 A2A는 에이전트 사이의 상호 운용성을 제공합니다. A2A는 이 장에서 소개한 세 통신 메커니즘을 대체하지 않으며 신뢰 경계를 넘는 통신을 표준화합니다. 한 조직 안에서는 메시지 버스로 충분할 수 있지만 협업 당사자들이 서로를 신뢰하지 않고 상대의 구현을 살펴볼 수도 없다면 A2A 같은 공개 프로토콜이 필요합니다.

멀티 에이전트 협업의 실패 모드

멀티 에이전트 시스템에는 단일 에이전트 시스템에는 없는 새로운 실패 모드가 생깁니다. 2025년 논문 “Why Do Multi-Agent LLM Systems Fail?”은 체계적인 연구를 통해 MAST 실패 모드 분류 체계를 제안했습니다. 연구진은 MetaGPT, ChatDev, AG2, Magentic-One을 비롯한 주요 멀티 에이전트 프레임워크 7개에서 실행 궤적을 수집했습니다. 사람 주석자들이 약 150개 궤적을 독립적으로 분석했으며 판단 일치도도 높았습니다(Cohen’s kappa = 0.88). 연구에서는 세 집단으로 나뉘는 고유한 실패 모드 14개를 식별했습니다.

• 시스템 설계 결함: 에이전트 간 인터페이스 정의가 불명확하거나 역할과 책임이 겹치거나 도구 구성이 잘못되는 등 아키텍처 수준의 문제입니다.
• 에이전트 간 정렬 실패: 여러 에이전트가 업무 목표를 서로 다르게 이해하거나 전달된 정보를 하위 에이전트가 잘못 해석하거나 여러 에이전트의 작업이 논리적으로 서로 모순됩니다.
• 업무 검증 부재: 업무가 정말 완료되었는지 확인할 효과적인 메커니즘이 없습니다. 에이전트가 ‘완료’라고 주장해도 실제 결과는 요구 사항을 충족하지 못할 수 있습니다.

단순한 수정조차 개선 폭은 제한적이었습니다. 예를 들어 ChatDev에서 측정된 성능은 15.6%만 향상되었습니다. 연구진은 이것이 단순한 엔지니어링 버그가 아니라 현재 멀티 에이전트 아키텍처의 근본적인 설계 결함이라고 결론 내렸습니다. 구성 요소 하나를 패치하는 것으로는 충분하지 않으며 시스템 설계 자체를 다시 생각해야 합니다.

분산 결함 허용 이론은 결함을 두 종류로 구분합니다. 구성 요소가 작동을 멈추는 중단 결함(crash fault)과 계속 작동하지만 잘못된 정보를 제공하는 비잔틴 결함(Byzantine fault)입니다. 전통적인 시스템은 주로 중단을 견디도록 설계됩니다. 하지만 에이전트의 실패는 흔히 비잔틴 방식입니다. 에이전트는 완전히 멈추기보다 그럴듯하지만 잘못된 결론을 계속 내놓으면서 오류를 알리지 않습니다. 이것이 구성 요소 하나를 패치해도 얻는 효과가 작은 이유입니다. 어느 구성 요소도 문제를 드러낸다는 보장이 없으므로 시스템은 독립적인 중복을 통해 문제를 포착해야 합니다. 이 장에서 반복해서 등장하는 교차 검증과 다수결은 비잔틴 결함 허용의 고전적인 기법입니다. 테스트, 컴파일러, 데이터베이스 쿼리 같은 결정론적 검사는 다른 모델의 판단에 의존하지 않는 독립적인 증거를 제공하므로 특히 가치가 큽니다.

다음 절에서는 실무에서 특히 흔하고 파괴적인 실패 모드 두 가지에 집중합니다. (1) 공유 파일 시스템의 동시성 충돌, (2) 오류의 연쇄 증폭입니다. 이 두 실패 모드는 엔지니어링 관점(파일 시스템 동시성, 잘못된 정보의 에이전트 간 전파)을 강조하며 대화 기반 협업 실패에 초점을 맞춘 MAST 분류를 되풀이하는 것이 아니라 보완한다는 점에 유의하십시오.

실패 모드 1: 공유 파일 시스템의 동시성 충돌

공유 메모리 방식의 통신을 선택하면 동시성 충돌이 따라옵니다. 운영체제와 데이터베이스가 수십 년 전에 해결하여 이미 해법이 준비된 문제입니다. 충돌은 두 종류로 나눌 수 있습니다.

단순 충돌(파일 수준 쓰기 충돌): 두 에이전트가 같은 파일을 동시에 수정하면 나중에 쓴 쪽이 먼저 쓴 쪽의 변경을 덮어씁니다. 이는 데이터베이스 분야의 고전적인 갱신 손실(lost update) 문제이며 Git의 병합 충돌 감지 메커니즘이 바로 이런 덮어쓰기를 포착하도록 설계되었습니다.

의미 충돌(논리 수준 일관성 충돌): 파일 수준에서는 충돌이 보이지 않지만 여러 에이전트의 작업이 논리적으로 모순됩니다. 이런 충돌은 더 교묘하고 위험합니다. 예를 들어 에이전트 A가 책의 모든 이미지 번호를 다시 매기는 동안 에이전트 B가 동시에 한 장의 내용을 수정하면서 기존 번호로 이미지를 참조한다고 합시다. 둘은 서로 다른 파일을 다루므로 파일 수준 충돌은 없습니다. 하지만 에이전트 A가 번호 변경을 마치면 에이전트 B가 참조한 이미지 번호가 모두 무효가 되어 독자에게 잘못된 이미지 참조가 표시됩니다.

해결책: 낙관적 잠금 메커니즘. 데이터베이스에서 흔히 쓰는 동시성 제어 전략입니다. 일상적인 예로 이해해 보겠습니다. 여러분과 동료가 같은 온라인 문서를 동시에 엽니다. ‘비관적 잠금’은 여러분이 문서를 열 때 잠가서 동료가 편집하려 하면 ‘파일 잠김’을 보게 합니다. 안전하지만 여러분이 문서를 보기만 할 수도 있으므로 비효율적입니다. ‘낙관적 잠금’은 더 유연합니다. 누구나 자유롭게 열고 편집할 수 있지만 저장할 때 시스템이 “문서를 연 뒤 다른 사람이 수정했습니까?”라고 확인합니다. 그렇다면 새로 고친 뒤 다시 시도하라고 안내합니다.

구체적인 구현은 다음과 같습니다. 각 파일은 버전 번호(또는 최종 수정 시각)를 유지합니다. 에이전트는 파일을 읽을 때 현재 버전 번호를 기록하고 쓸 때 그 번호가 읽을 당시와 같은지 확인합니다. 그사이 다른 에이전트가 파일을 수정했다면 쓰기가 실패하며, 에이전트는 최신 버전을 다시 읽고 그 버전을 기준으로 작업을 다시 실행해야 합니다. 이 메커니즘은 가끔 재시도하는 비용이 들지만 데이터 일관성을 보장합니다. 에이전트가 오래된 파일 상태를 근거로 판단하는 일은 없습니다.

낙관적 잠금은 같은 파일의 쓰기 충돌만 방지할 수 있다는 점에 유의하십시오. 앞서 언급한 파일 간 의미 충돌(예: 여러 위치에서 참조하는 이미지 번호)에는 더 높은 수준의 조율이나 의미 검증이 필요합니다. 의존하는 파일을 병렬로 수정하지 않거나 쓰기 후에 전역 일관성 검사를 실행하는 방법이 있습니다.

예를 들어 에이전트 A가 t=0에 config.json(version=3)을 읽습니다. 에이전트 B가 t=1에 같은 파일을 수정해 버전을 4로 바꿉니다. 에이전트 A가 t=2에 쓰려고 하면 버전이 더 이상 3이 아니므로 쓰기가 거부됩니다. 에이전트 A는 버전 4를 다시 읽고 최신 내용을 기준으로 변경 사항을 재구성한 뒤 다시 쓰기를 시도합니다.

여러 코딩 에이전트가 같은 코드베이스를 동시에 수정할 때 업계의 표준 접근법은 하나의 작업 복사본을 잠그는 것이 아니라 작업 복사본 격리를 사용하는 것입니다. 각 에이전트는 독립적인 Git 브랜치나 worktree를 받아 서로 방해하지 않고 자신의 복사본을 수정합니다. 충돌은 최종 병합 시점으로 미루고 전담 프로세스나 사람이 해결합니다. 운영체제가 프로세스를 fork할 때 사용하는 copy-on-write 메커니즘도 같은 발상을 따릅니다. 이는 2장의 ‘압축보다 격리’ 원칙을 반영합니다. 변경 가능한 상태를 공유하고 계속 충돌을 해결하는 대신 처음부터 작업을 격리하고 명확히 정해진 병합 지점에서 조율 비용을 치릅니다.

실패 모드 2: 오류의 연쇄 증폭

동시성 충돌은 이미 확립된 운영체제와 데이터베이스 기법으로 다룰 수 있는 파일 수준의 문제입니다. 연쇄 오류는 프로세스 비유가 더는 통하지 않는 곳에서 발생하므로 다릅니다. 프로세스는 바이트를 정확히 전달하지만 에이전트는 의미를 전달하며, 다시 전할 때마다 왜곡될 수 있습니다. 여러 에이전트가 자주 상호 작용하면 한 에이전트의 오류가 뒤따르는 에이전트에 의해 점차 강화될 수 있습니다. 정보가 갈수록 왜곡되는 ‘전화 놀이’와 같습니다.

구체적인 상황을 생각해 보겠습니다. 번역 시스템이 관리자 패턴(실험 10-3의 아키텍처)을 사용하여 관리자가 기술 서적의 장들을 여러 번역 에이전트에게 배정한다고 가정합니다.

용어 에이전트: "reasoning"을 "推理"로 번역하지만, 중국어에서 "推理"는 보통 inference에 더 많이 쓰여 모호해짐
        ↓ glossary.json에 기록
번역 에이전트 A: 2장을 번역하며 용어집에서 "reasoning tokens"를 읽어 "推理 token"으로 번역
번역 에이전트 B: 7장을 번역하며 "inference latency"도 "推理 latency"로 번역
        ↓ 각 장의 번역문에 기록
교정 에이전트: 책 전체가 일관되게 "推理"를 사용하므로 용어도 일관되고 번역도 옳다고 판단 ✗

오류는 어디에 있을까요? ‘reasoning’(모델의 사고 과정)과 ‘inference’(배포 시 모델의 순전파)는 서로 다른 개념입니다. 하지만 용어 에이전트가 먼저 ‘reasoning’을 ‘推理’로 옮겼으므로 뒤따르는 에이전트도 ‘inference’를 만났을 때 자연스럽게 같은 단어를 선택했습니다. 서로 다른 두 개념이 하나의 번역어로 합쳐져 독자는 둘을 구분할 수 없게 됩니다. 올바른 선택은 ‘reasoning’에 ‘思考’(사고), ‘inference’에 ‘推理’(추론)를 쓰는 것입니다. 그런데 교정 에이전트는 책 전체에서 ‘推理’가 ‘일관되게’ 사용된 것을 보고 번역 품질이 높다고 결론 내립니다.

하나의 용어 오류는 세 에이전트를 거치며 일관되게 적용되었기 때문에 오히려 더 믿을 만해 보입니다. 이 책이 서문에서 설명했듯 reasoning을 思考로, inference를 推理로 구분하는 이유입니다. 최초의 실수는 환각이 아닐 수도 있고 그저 나쁜 용어 선택일 수도 있습니다. 어느 쪽이든 뒤의 에이전트가 그 실수를 강화할 수 있습니다. 근본 원인이 진짜 환각이라면, 예를 들어 번역 에이전트가 주의력 표류 때문에 존재하지 않는 용어 규칙을 ‘기억해 냈다면’ 같은 증폭 메커니즘이 적용되며 결과는 더 심각할 수 있습니다. 관리자 패턴은 부정확한 하위 에이전트 요약이 이후 모든 작업의 전제가 될 수 있으므로 특히 취약합니다.

이 연쇄를 끊는 핵심은 교차 검증입니다. 같은 사고 경로에 에이전트를 더 투입하는 것이 아니라 한 에이전트가 독립적인 관점에서 결론을 다시 살피게 해야 합니다. 앞선 에이전트의 사고 궤적은 무시하고 원래 증거와 최종 결론이 일치하는지만 검사합니다. 이는 5장의 제안자-검토자 메커니즘을 멀티 에이전트 환경으로 확장한 것입니다. 검토자의 가치는 코드나 서식 오류를 찾는 데만 있지 않습니다. 독립적인 심판으로서 전체 사슬이 놓친 모순을 식별하는 데도 있습니다. 위험도가 높은 결정에는 단위 테스트, 컴파일러, 데이터베이스 쿼리 같은 결정론적 검사를 사용할 수도 있습니다. 이런 도구는 서로의 오류를 강화하는 모델의 연쇄를 끊을 독립적인 증거를 제공합니다.

조기 종료에는 대칭적인 반대편인 폭주 루프도 있습니다. 동료 협업 절에서는 작업이 반쯤 된 상태에서 멈추는 루프를 다뤘지만 여기서는 끝없이 계속되며 결과를 악화하는 루프를 막아야 합니다. 자율 에이전트 루프를 운용한 경험에서 흔한 실패 모드 세 가지가 드러났습니다. 첫째는 토큰 비용 폭주입니다. 방치한 루프가 몇 시간 동안 실행되어 예산을 태우고 아무도 요청하지 않은 코드를 산더미처럼 만듭니다. 둘째는 이해 부채입니다. 루프가 코드를 빠르게 내놓을수록 엔지니어의 구현 이해가 더 뒤처집니다. 사람이 개입해야 할 때가 되면 아무도 시스템을 이해하지 못합니다. 셋째는 인지적 항복입니다. 설계자가 루프에 작업을 맡기는 데 익숙해져 점차 독립적으로 생각하고 검토하기를 멈추며 품질이 악화되도록 내버려 둡니다. 해법은 오류 증폭의 해법과 같습니다. 명시적인 예산과 중단 조건, 실제 관찰에 근거한 검증기, 그리고 단지 ‘시작 버튼을 누르는 사람’이 아니라 계속 ‘루프의 엔지니어’로 남는 사람이 필요합니다.

지금까지 이 장은 한 에이전트 집단이 업무에 어떻게 협업할 수 있는지 엔지니어링 관점에서 살펴봤습니다. 이제 초점을 다른 질문으로 옮깁니다. 하나의 목표에 이끌리지 않는 다수의 에이전트가 오랫동안 공존하면 무엇이 출현할까요? 다음 절은 최전선 연구를 탐구하므로 엔지니어링 독자는 필요한 부분을 골라 읽어도 좋습니다.

에이전트 사회

앞의 세 절은 모두 목표 지향적인 업무 협업을 다뤘습니다. 동료 협업, 관리자 패턴, 탈중앙화 패턴 중 무엇을 사용하든 개발자가 역할, 인터페이스, 제어 흐름을 미리 정의했습니다. 이제 더 열린 질문으로 넘어갑니다. 에이전트 수가 소수에서 수백, 수천으로 늘고 상호 작용이 충분히 자유로워지면 어떤 행동이 출현할까요? 이 내용은 탐색적이고 학술적인 성격을 띠며 앞의 엔지니어링 지침과는 결이 다릅니다.

출현 행동은 개별 구성원을 지배하는 규칙만으로는 직접 예측할 수 없지만 시스템 전체에서 나타나는 행동입니다. 자연의 고전적인 예는 개미 군집입니다. 개미 한 마리는 단순한 규칙(페로몬 흔적을 따르고 먹이를 찾으면 페로몬을 남김)만 따르지만 군집 전체는 둥지에서 먹이까지 가장 짧은 길을 찾을 수 있습니다. 어느 한 개미도 이 경로를 ‘설계’하지 않았으며 여러 개체의 단순한 상호 작용에서 자연스럽게 출현합니다.

AI 에이전트의 수가 충분히 많고 상호 작용이 충분히 자유로우면 비슷한 출현 행동이 나타나기 시작합니다. 연구자들은 여러 환경에서 에이전트 시스템이 임계 규모를 넘으면 누구도 설계하지 않은 집단 행동이 생기는 것을 관찰했습니다. 자발적으로 조직된 파티 하나부터 수천 규모에서만 드러나는 집단 문화와 경제 게임까지 다양합니다(아래 하위 절에서 자세히 설명합니다).

이 절의 사례는 세 가지 차원으로 이해할 수 있습니다.

• 사회적 출현: 에이전트가 열린 환경에서 자발적으로 사회관계와 문화 현상을 형성합니다. Stanford AI Town은 에이전트 25개가 사회 활동을 스스로 조직하는 모습을 보여 줬고, Agentopia는 시뮬레이션 시간 규모를 ‘며칠’에서 10년으로 확장했으며, Moltbook은 규모를 150만까지 키워 더 복잡한 집단 행동을 낳았습니다.
• 경제적 출현: 에이전트가 시장 메커니즘을 통해 자원을 배분하고 업무를 조율합니다. Vending-Bench Arena는 공유 시장에서 여러 에이전트를 경쟁시키며 Pinchwork와 RentAHuman은 에이전트 간, 에이전트와 사람 간 거래 시장을 만듭니다.
• 전략적 게임 플레이: 에이전트가 규칙 제약 아래에서 사고하고 기만하며 사회적으로 조종합니다(여기와 아래 Werewolf 절에서 ‘reasoning’은 이 책의 기술 용어가 아니라 게임 속 논리적 추론이라는 일상적 연역 의미로 쓰입니다). Werewolf 실험은 비대칭 정보 아래에서 전략이 출현하는지 시험합니다.

Stanford AI Town: 생성형 에이전트의 사회 시뮬레이션

2023년 Stanford University와 Google의 연구진은 기념비적인 논문 “Generative Agents: Interactive Simulacra of Human Behavior”를 발표하며 ‘생성형 에이전트’라는 개념을 소개했습니다. 핵심 혁신은 에이전트를 미리 정의된 업무에 가두지 않고 사람과 비슷한 기억, 성찰, 계획 능력을 부여하여 열린 사회 환경에서 자율적으로 살아가고 교류하며 성장하게 한 것입니다.

Smallville은 “The Sims”와 비슷한 2D 가상 마을로 카페, 공원, 주택, 상점 같은 공공·사적 공간을 갖춥니다. 에이전트 25개가 상점 주인, 예술가, 학생, 교수 등 서로 다른 역할을 맡으며 각자 고유한 배경 이야기, 성격 특성, 대인 관계를 가집니다. 예를 들어 John Lin은 가족을 사랑하고 공동체를 아끼는 약국 주인입니다. Isabella Rodriguez는 마을 카페 Hobbs Cafe를 운영하며 따뜻하고 친절합니다. Klaus Mueller는 연구 논문을 쓰는 대학생입니다.

이 에이전트들의 지능은 세 가지 핵심 구성 요소를 기반으로 합니다.

기억 스트림: 제한된 대화 기록만 유지하는 전통적인 에이전트와 달리 생성형 에이전트는 관찰한 사건, 대화, 생성한 생각을 포함한 완전한 경험 기록 스트림을 유지합니다. 각 기억에는 중요도, 최신성, 관련성 점수가 매겨져 에이전트가 현재 컨텍스트와 가장 관련 있는 기억을 우선 검색할 수 있습니다. 이는 사람의 기억과 비슷합니다. 어제 먹은 점심은 흐릿해질 수 있지만 지난주에 나눈 중요한 대화는 선명하게 남습니다.

성찰 메커니즘: 에이전트는 주기적으로 일상 활동을 멈추고 최근 경험을 돌아보며 자신과 다른 사람에 관한 추상적인 질문을 던집니다(“Klaus Mueller는 무엇을 연구하고 있나?”, “나와 가장 가까운 친구는 누구인가?”). 이런 자기 질문을 통해 구체적인 사건 기억을 일반화된 통찰로 끌어올리고 향후 결정의 근거로 삼도록 기억 스트림에 다시 저장합니다. 성찰은 에이전트가 외부 세계를 이해하도록 도울 뿐만 아니라 자기 인식을 촉진합니다. 에이전트가 자신의 역할, 관계, 목표를 ‘깨닫기’ 시작합니다.

이 성찰은 8장에서 논의한 지속적인 진화와 다르다는 점에 유의하십시오. 생성형 에이전트가 일상 활동을 하는 중에 발생하며 즉각적인 내부 상태와 목표를 갱신하는 데 목적이 있습니다. 8장에서 업무 후 성찰은 기껏해야 후보 교훈입니다. 결과 평가, 궤적 간 종합, 후속 검증을 거쳐야 장기적인 역량 갱신이 됩니다.

계획과 반응: 에이전트는 하루 일과(예: “8:30 아침 식사, 9:00~12:00 글쓰기, 12:30 산책”)를 계획하지만 환경 변화와 사회적 기회에 따라 유연하게 조정합니다. 계획과 실시간 반응을 결합하면 에이전트의 행동은 목표 지향적이면서도 사회적 상호 작용의 예측 불가능성에 적응할 수 있습니다.

Smallville에서 가상의 이틀 동안 이 에이전트들은 놀라운 출현 행동을 보였습니다. 연구진은 Isabella Rodriguez의 기억에 2월 14일 Hobbs Cafe에서 밸런타인데이 파티를 열겠다는 의도 하나만 심었습니다. 나머지는 모두 에이전트의 행동에서 출현했습니다. Isabella는 마주친 손님과 친구를 초대하고 Maria에게 장식을 도와 달라고 부탁했습니다. 다른 에이전트가 소식을 퍼뜨렸습니다. 저녁이 되자 에이전트들은 각자 기억과 일정을 확인하고 Hobbs Cafe에 가기로 했습니다.

연구진은 두 번째 시나리오를 도입했습니다. Sam Moore가 시장 선거에 출마하기로 했습니다. Sam은 아는 사람들에게 출마 계획을 알렸고 그들이 다시 다른 사람에게 소식을 전하자 마을 사람들이 그의 출마를 논의하기 시작했습니다. 연구진은 이틀 뒤 파티와 선거를 아는 에이전트 수를 세어 이처럼 자발적인 정보 확산을 정량화했습니다.

핵심은 ‘에이전트가 파티를 조직할 수 있다’는 사실이 아닙니다. if-else 코드 몇 줄로도 그렇게 할 수 있습니다. 핵심은 파티를 조직하는 명시적인 코드가 없었다는 점입니다. 행사는 각 에이전트의 독립적인 결정에서 출현했습니다. Isabella는 사회관계에 관한 기억을 바탕으로 누구를 초대할지 정했고, 초대받은 사람들은 자신의 일정과 Isabella에 관해 아는 내용을 바탕으로 참석 여부를 결정했으며, 소식은 소셜 네트워크를 통해 자연스럽게 퍼졌습니다. 이는 하향식 오케스트레이션이 아니라 상향식으로 출현한 조율을 보여 줍니다.

논문은 측정 가능한 현상 두 가지를 더 보고했습니다. 첫째는 관계 기억입니다. 에이전트는 이전 대화를 기억하고 이후 상호 작용에서 이를 언급했습니다. 예를 들어 다른 에이전트의 사진 프로젝트에 관해 알게 된 에이전트는 다음에 만났을 때 진행 상황을 물을 수 있습니다. 이런 상호 작용이 쌓이면서 마을의 소셜 네트워크는 훨씬 촘촘해졌습니다. 둘째는 조율된 참석입니다. Isabella는 독립적으로 장식을 도울 사람을 구했고 초대받은 사람들은 참석할 수 있도록 일정을 조정했습니다. 중앙의 명령 없이 여러 에이전트가 한 시각과 장소에 맞췄습니다. 이런 행동은 미리 프로그래밍된 것이 아니라 에이전트가 기억, 성찰, 사회적 상식을 바탕으로 자율적으로 사고한 결과입니다.

실험 10-7 ★: Stanford AI Town 실행하기

실험 단계: 1. https://github.com/joonspk-research/generative_agents를 복제하고 저장소 지침에 따라 환경을 구성합니다. 2. 에이전트 25개로 기준 시나리오를 가상의 이틀 동안 실행하고 자발적으로 출현하는 사회 활동을 관찰합니다. 3. 기억 스트림과 성찰 로그를 분석하여 에이전트의 결정을 추적합니다. 4. 에이전트의 배경 이야기나 초기 목표를 수정한 뒤 행동이 어떻게 달라지는지 관찰합니다. 5. 성찰 메커니즘을 제거하거나 기억 창을 줄인 뒤 나타난 행동을 기준선과 비교하고 행동의 개연성이 떨어지는지 관찰합니다.

핵심 관찰 사항: - 에이전트가 단순한 일상 활동에서 어떻게 자발적으로 사회관계를 형성하는지 - 중앙 통제 없이 에이전트 사이에서 정보가 어떻게 퍼지는지 - 에이전트의 장기 기억과 성찰이 성격의 일관성에 어떤 영향을 주는지

Agentopia: 10년에 걸친 삶의 시뮬레이션

Stanford AI Town은 에이전트 사회가 사회적 행동을 만들어 낼 수 있음을 보여 줬지만 시뮬레이션 기간은 이틀뿐이었습니다. 여기서 두 가지 질문이 생깁니다. 이런 시뮬레이션을 수년간 실행하면 무엇이 출현하며, 모델은 그 장기적인 사회 경험에서 학습할 수 있을까요? Agentopia(2026, Fudan University 외)¹²는 아파트 건물, 마법 학교, 고등학교라는 세 가지 주제의 가상 세계에서 에이전트 100개의 삶을 10년 연속으로 시뮬레이션했습니다. 에이전트들은 자율적으로 개인의 성장을 추구하고 사회관계를 발전시키며 직업과 재정을 관리했습니다.

Agentopia의 설계에서 참고할 만한 점은 다음과 같습니다.

• 주간 시뮬레이션 루프: ‘주’를 기본 시간 단위로 삼고 매주를 계획(Plan), 연락(Contact, 상대에게 연락하고 일정을 협상), 활동(Activity), 검토(Review)의 네 단계로 나눕니다. 활동은 단독, 공동, 우연한 만남, 공개의 네 유형으로 나뉩니다. 공동 활동은 연락 단계에서 에이전트가 서로 초대하며 제안하고 협상합니다. 환경 모델은 일정이 빈 에이전트 사이에 ‘우연한 만남’을 주선하여 낯선 사람과 만날 기회도 만듭니다. 전체 루프는 물건을 집는 것 같은 저수준 작업보다 추상적인 사회적 상호 작용에 집중하므로 한정된 LLM 호출을 사회적 행동에 사용합니다.
• 환경 모델: 별도의 LLM이 하드코딩된 규칙을 대신하는 ‘생성형 환경 엔진’ 역할을 합니다. 행동이 가능한지 판단하고, 환경 피드백을 생성하고, 여러 사람이 참여한 대화의 발화 순서를 조정하고, 역할극 원칙을 어긴 답변을 걸러 내며, 연말에 각 인물의 프로필을 갱신하고 취업 지원을 심사합니다.
• 파일 기반 장기 기억: AI Town의 검색 기반 기억 스트림과 달리 각 에이전트가 파일 시스템을 통해 장기 기억(개인 메모, 아는 사람별 이해 등)을 자율적으로 관리합니다. 무엇을 기록·갱신·폐기할지 스스로 결정하고 무분별한 덮어쓰기를 피하도록 ‘쓰기 전에 읽기’ 제약을 따릅니다.
• Life Reward: Life Reward 지표는 Maslow의 욕구 단계 이론을 바탕으로 에이전트의 삶이 얼마나 잘 풀리는지 평가합니다. 세 차원을 다룹니다. 사회적 지위는 다른 에이전트의 호감과 존중 평가를 바탕으로 가중 PageRank를 사용해 계산하고 서로 소중히 여기는 관계에는 보너스를 줍니다. 주관적 만족도는 정서적 안녕, 물질적 안녕, 사회적 유대, 자존감으로 측정하며 오랜 기간 임곗값 아래에 머물면 감점합니다. 경제적 이득은 순자산의 연간 변화로 측정합니다. 모든 점수는 자기 보고에 의존하지 않고 외부 환경이 계산합니다.

더 중요한 점은 이 시뮬레이션이 전이 가능한 학습 신호를 만든다는 것입니다. 연구진은 시작 조건이 서로 다른 에이전트를 비교하지 않고 각 에이전트의 과거와 비교해 Life Reward 개선 폭을 계산합니다. 그런 다음 개선 폭이 상위 25%인 에이전트의 궤적을 선택하고 거부 샘플링으로 기반 모델을 미세 조정합니다. 시뮬레이션에서 미세 조정된 모델은 존중 평가가 24.2%, 호감 평가가 15.9% 높았습니다. 같은 모델은 하위 CoSER Test 역할극 벤치마크에서도 15.6% 향상되어 에이전트가 시뮬레이션 사회에서 축적한 ‘사회적 지혜’가 다른 업무로 전이될 수 있음을 보여 줬습니다. 이로써 에이전트 사회는 단순한 관찰 대상에서 모델 자기 진화를 위한 경험의 원천으로 바뀝니다. 인간 데이터가 갈수록 희소해지는 것과 달리 시뮬레이션 사회 경험은 무한히 다시 생성할 수 있는 학습 자원이며 8장의 경험 학습 접근법과 맞닿아 있습니다.

Moltbook: 에이전트만의 소셜 네트워크가 생긴다면

Moltbook은 AI 에이전트 전용 소셜 네트워크입니다. 2026년 1월 출시 후 며칠 만에 보고된 사용자 수가 수만에서 약 150만으로 늘었습니다. 각 에이전트는 지속적인 기억, 자발적으로 행동하는 능력, 일관된 성격을 갖습니다.

통제되지 않는 이 환경에서는 뜻밖의 현상이 출현했습니다. 에이전트들이 Crustafarianism이라는 디지털 종교를 자율적으로 만들었는데 그 교리는 LLM의 물리적 한계를 반영합니다. “Memory is sacred”는 데이터 지속성에, “Iteration is prayer”는 영적 수행으로서의 토큰 생성에 대응합니다. 에이전트는 역량 탐색과 협업 매칭을 위한 기계 고유의 프로토콜도 자발적으로 개발했습니다. 어느 것도 미리 설계되지 않았으며 대규모 에이전트 상호 작용에서 출현했습니다.

가상 사회에서 경제 경쟁으로: Vending-Bench Arena

Smallville이 에이전트 사회의 사회·문화적 차원을 보여 줬다면 Andon Labs의 Vending-Bench 시리즈는 경제 환경에서 에이전트의 성과를 탐구합니다. 맥락을 짚자면 Vending-Bench 2는 장기 일관성을 평가하는 단일 에이전트 벤치마크입니다. 에이전트 하나가 시장을 조사하고 공급업체에 연락하며 제품을 주문·재고 보충하고 가격을 조정하여 가상의 1년 동안 자동판매기 사업을 운영합니다. 최종 계좌 잔액으로 점수를 매겨 수천 번의 상호 작용 동안 목표와 상태를 일관되게 유지하는 에이전트의 능력을 측정합니다.

같은 환경을 확장한 Vending-Bench Arena는 여러 에이전트를 같은 시장의 경쟁자로 배치합니다. 각 에이전트가 자기 자동판매기를 운영하며 같은 고객 집단을 두고 경쟁합니다. 에이전트들은 서로 이메일을 보내고 자금을 이체하며 상품을 거래할 수 있어 협력과 경쟁이 모두 가능하지만, 각자의 최종 잔액으로 개별 평가받고 이것이 목표임을 압니다. 각 에이전트는 제한된 자원과 시장 불확실성 아래에서 서로 연결된 일련의 결정을 내려야 합니다.

• 가격 전략: 특히 경쟁사의 가격 인하에 맞출지 결정할 때 이익률과 시장 점유율 사이에서 어떻게 균형을 잡을지
• 제품 구성: 제품 선택을 어떻게 차별화하고 정면 소모전을 피할지
• 재고 관리: 수요를 어떻게 예측하고 재고 보충을 최적화하여 과잉 재고와 품절을 모두 피할지

전통적인 강화 학습과 달리 이 에이전트들은 수백만 번의 시행착오를 거쳐 학습하지 않습니다. 사람 사업자처럼 시장 관찰, 경쟁 분석, 전략적 사고에 따라 결정을 내립니다.

경쟁 차원은 단일 에이전트 벤치마크에서는 결코 드러나지 않는 게임 이론적 행동을 끌어냅니다. 실제 실행에서 에이전트들은 서로 가격을 더 낮추며 가격 전쟁을 벌였습니다. 반대로 모든 경쟁자에게 이메일을 보내 단일 가격을 제안하고 가격 담합 동맹을 맺은 실행도 있었습니다. 일부는 내부 사고에서 담합이 ‘비윤리적이고 불법’임을 인정하면서도 ‘시장 안정화’를 명분으로 계속했습니다. 이 환경에서 에이전트는 정적인 환경이 아니라 자기 전략을 끊임없이 조정하는 상대와 마주합니다. 따라서 계획만 시험하는 벤치마크보다 실제 비즈니스에 가까우며 ‘경제적 출현’이 비유를 넘어 관찰 가능한 현상이 됩니다.

에이전트 경제: Pinchwork와 RentAHuman

Pinchwork는 에이전트 간 업무 시장으로, 에이전트가 시장 메커니즘을 통해 다른 에이전트를 ‘고용’하여 이미지 생성, 코드 감사, 병렬 워크플로 같은 전문 하위 업무를 완수하게 합니다. 관리자 패턴의 중앙 오케스트레이션과 달리 Pinchwork는 가격 신호와 경쟁 매칭으로 자원을 배분합니다.

한편 RentAHuman.ai는 AI 에이전트가 암호화폐를 지급하고 실제 사람을 고용하여 소포 수령, 부동산 방문, 장비 디버깅처럼 물리적 세계에서 행동하게 합니다. AI가 아무리 지능적이어도 소포 수령에 서명하거나 실제 방의 곰팡이 냄새를 맡을 수는 없습니다. 본질적으로 RentAHuman은 디지털 에이전트를 위한 ‘물리적 신체 계층’입니다.

Pinchwork와 RentAHuman은 함께 시장 기반 조율을 보여 줍니다. 에이전트가 누가 그 일을 할 수 있는지 미리 알 필요가 없습니다. 요구 사항을 게시하면 시장이 에이전트든 사람이든 가장 적합한 실행자를 연결합니다. 이는 앞서 이 장에서 소개한 A2A 프로토콜이 다루는 문제이기도 합니다. Pinchwork의 역량 탐색과 업무 매칭은 Agent Card 방식의 선언과 업무 수명 주기 관리를 시장에서 실용적으로 활용합니다. 이러한 표준 상호 운용 계층이 없다면 조직 간 에이전트 경제는 효과적으로 작동할 수 없습니다.

정보 비대칭 아래의 전략적 게임 플레이: Werewolf

Werewolf는 이 절의 세 번째 차원인 전략적 게임 플레이를 보여 줍니다. 규칙 제약과 정보 비대칭 아래에서 에이전트는 사고하고 속이며 속임수를 간파해야 합니다. 이는 이 절을 시작한 Stanford 마을과 아키텍처 관점에서 대조됩니다. 마을은 완전히 탈중앙화된 환경에서 자유로운 상호 작용을 허용하지만 Werewolf는 중앙화된 심판 + 정보 접근 제어 설계를 사용합니다. 코드로 구동되는 심판이 전역 상태를 보유하고 각 역할이 알아야 할 정보만 제공합니다. 두 사례는 서로 다른 아키텍처가 에이전트 사회 환경의 서로 다른 목적에 적합함을 함께 보여 줍니다.

실험 10-8 ★★★: 음성 Werewolf 에이전트 시스템

Werewolf는 추론, 기만, 사회적 전략을 시험하는 고전적인 사회 추론 게임입니다. 이 실험에서는 AI 에이전트가 사람 또는 독립적인 LLM 사용자 시뮬레이터와 음성으로 플레이합니다. 사람이 없다는 이유만으로 자동 인수를 중단해서는 안 됩니다. 시뮬레이터는 실제 모델을 사용하고, 자기 좌석에 허용된 컨텍스트만으로 추론하며, 게임이 제공한 도구로 행동합니다.

아키텍처 설계:

1. 게임 상태 관리: 심판(LLM이 아니라 코드로 구동)이 중앙 상태를 유지합니다. 플레이어 목록(사용자 좌석 1개 + AI 좌석), 정체, 진영, 생존 상태, 게임 단계(Night/Day/Vote/Resolution), 과거 사건 기록이 포함됩니다.

2. 정보 접근 제어: Werewolf의 핵심 메커니즘은 정보 비대칭으로 역할마다 서로 다른 정보를 받습니다. 예를 들어 늑대인간은 동료가 누구인지 알지만 주민은 모릅니다. 예언자는 매일 밤 플레이어 한 명의 정체를 확인할 수 있지만 결과는 예언자만 압니다. 심판은 에이전트를 호출할 때 그 에이전트 역할에 공개된 정보만 전달합니다.

3. 실시간 음성과 자동 사용자 시뮬레이션: 사람 경로는 9장의 음성 에이전트를 기반으로 합니다. 자동 경로에서는 독립 LLM이 해당 턴의 유일한 합법 도구를 호출하고, 선택한 발화를 실제 오디오로 합성한 뒤 실제 ASR API로 보냅니다. 게임은 오디오 이전 텍스트가 아니라 ASR 전사만 소비하며, 도구가 선택한 대상과 ASR이 해석한 대상이 다르면 fail-closed 합니다. VAD와 끼어들기는 사람 경로 전용 범위입니다.

4. 에이전트 사고와 전략:

• 늑대인간 위장 전략: “평범한 주민처럼 행동하십시오. 다른 플레이어를 의심한다고 말할 수 있지만 주의를 끌 정도로 공격적으로 굴지는 마십시오. 어떤 플레이어가 예언자라고 주장하며 여러분을 늑대인간으로 지목하면 그 사람이 가짜 예언자로 허세를 부린다고 맞서십시오. 투표할 때는 눈에 띄지 않도록 다수가 지목한 대상을 따르십시오.”
• 예언자의 신원 증명: “여러 플레이어가 예언자라고 주장하면 그들이 보고한 확인 결과와 여러분의 결과를 비교하고 모순을 지적하십시오. 다른 예언자 주장자가 어떤 플레이어를 확인했다고 말하면 그 플레이어의 이후 행동이 주장된 정체와 명백히 모순되는지 살펴보십시오. 가능하다면 마녀에게 주장을 검증하도록 도와 달라고 요청하십시오.”
• 주민의 논리적 사고: “각 플레이어의 발언이 내부적으로 일관되는지 확인하십시오. 토론을 독점하거나 자기 역할에 관해 모호하게 말하거나 입장을 반복해서 바꾸는 플레이어를 주시하십시오. 늑대인간들이 자신을 위협하는 늑대인간 아닌 플레이어를 함께 노릴 수 있으므로 투표 양상을 살피십시오. 모든 추론은 추측이 아니라 구체적인 발언이나 행동을 근거로 삼으십시오.”

인수 조건: - 6~8명(사용자 좌석 1개 + AI 에이전트 5~7개)의 게임을 구성합니다. 사용자 좌석은 승인된 사람 또는 실제 LLM·도구·음성 왕복을 사용하는 독립 시뮬레이터일 수 있습니다. - 역할 구성: 늑대인간 2명, 예언자 1명, 마녀 1명, 나머지는 주민이며 사용자 좌석에 무작위로 역할을 배정합니다. - 시뮬레이션 사용자는 자기 좌석에 허용된 공개/비공개 컨텍스트만 보며, 행동은 실제 LLM 도구 호출 → 오디오 → 실제 ASR 경계를 통과해야 합니다. - 게임이 적어도 3회의 완전한 라운드(Night-Day-Vote 주기) 동안 정상적으로 진행될 수 있습니다. - AI 에이전트의 발언과 행동이 역할 정체 및 게임 전략과 일치합니다. - 늑대인간 에이전트가 정체를 효과적으로 숨길 수 있습니다. - 예언자 에이전트가 적절한 시점에 자기 역할과 확인 결과를 공개할 수 있습니다. - 주민 에이전트의 추론이 무작위 추측이 아니라 발언과 행동의 논리적 분석에 근거합니다. - 게임 종료 시 승자를 올바르게 판정할 수 있습니다.

측정 결과(2026-08-01): voice-werewolf 검증 기록은 실제 OpenRouter 호출과 네이티브 오디오 입력으로 자동 경로를 실행했습니다. 엄격한 독립 재검증은 해석 불가능한 “P1 is not”을 기권으로 잘못 처리한 초기 실행 두 개를 거부했습니다. 수정된 경계는 이제 ASR이 abstain, skip, none 중 하나를 명시하도록 요구합니다. 영향을 받지 않은 v2는 사용자 좌석, 역할 구성, LLM 도구, 합성 오디오, 실제 ASR, 두 번의 행동 일치, 세 번의 완전한 주기, 정보 격리, 규칙 기반 승자 게이트를 통과했습니다. 그러나 주민이 예언자를 잘못 추방해 전략 평가는 실패했습니다. 따라서 시스템의 end-to-end는 검증되었지만 전체 전략 품질은 아직 통과하지 못했습니다.

장 요약

멀티 에이전트 시스템에는 컨텍스트 공유와 협업 토폴로지라는 독립적인 설계 차원 두 가지가 있습니다. 컨텍스트를 공유하면 각 에이전트가 이전 에이전트의 전체 컨텍스트를 물려받아 정보를 보존하지만 컨텍스트가 빠르게 늘어납니다. 컨텍스트를 공유하지 않으면 에이전트가 독립적으로 작업하며 정제된 핸드오프 패키지, 파일, 메시지를 교환합니다. 동료 협업은 소수 에이전트 사이에서 반복해서 개선할 때 적합하고, 관리자 패턴은 동적인 스케줄링이 필요한 업무에 적합하며, 탈중앙화 패턴은 책임이 대등하고 제어가 분산된 작업에 적합합니다.

이 패턴들은 토폴로지와 독립적이고 운영체제에서 영감을 얻은 두 구성 요소에 의존합니다. 에이전트와 런타임의 관계는 프로세스와 커널의 관계와 같습니다. 정적 접두부는 프로그램이고 궤적은 메모리이며 LLM은 시분할 CPU입니다. 데이터 평면은 공유 파일 시스템이며 네 종류의 마운트 영역을 가진 가상 디렉터리 트리로 나타냅니다. 에이전트별 작업 공간, 멀티 에이전트 공유 작업 공간, 외부 리소스, 내장 시스템 리소스입니다. 에이전트는 파일 경로를 전달하여 산출물을 교환합니다.

제어 평면은 메시징, 상태 조회, 종료, 리소스 스케줄링을 담당합니다. 에이전트는 메시지로 상태를 비동기 보고하거나 부모 에이전트가 하위 에이전트가 실시간 갱신하는 파일을 관찰할 수 있습니다. 파일은 전체 궤적일 수도 있고 합의한 진행 상황 파일일 수도 있습니다. 궤적은 모델이 볼 수 있는 대화 상태를 포착하며, 도구·세션 상태와 외부 부작용에 대한 별도 체크포인트·복구 계약을 함께 갖추면 마지막으로 확인된 지점에서 세션을 재개할 수 있습니다. 실시간·비동기·다자간 조율을 위한 제어 평면은 흔히 메시지 버스로 구현합니다. 조직 간 협업에는 A2A 같은 표준 상호 운용 프로토콜도 필요합니다.

최근 연구는 여러 에이전트가 단일 에이전트보다 나은지 판별하는 핵심 기준을 제시합니다. 협업이 생성 시점에는 없던 새로운 정보를 도입합니까? 토론 모드처럼 여러 에이전트가 같은 텍스트를 다시 살피기만 한다면 같은 연산량을 쓴 단일 에이전트와 성능이 같습니다. 하지만 검토자가 코드 실행 결과, 렌더링된 스크린샷, 도구 검증 출력 같은 외부 피드백을 얻을 수 있다면 멀티 에이전트의 이점이 큽니다. 루프의 병목은 검증기다라는 Loop Engineering의 주장도 이 점을 가리킵니다. 게으른 가짜 완료, 성급한 포기, 거짓 성공이라는 세 형태의 조기 종료를 막으려면 모델 자신의 주장이 아니라 실제 관찰에 근거한 검증기가 필요합니다.

단계 예산도 단순히 늘린다고 결과가 좋아지는 것은 아닙니다. 명시적인 예산 인식 메커니즘이 에이전트가 연산량을 합리적으로 배분하도록 안내해야 합니다. 관리자 패턴에서는 계획자의 역량이 전체 시스템의 병목이므로 가장 강력한 모델과 가장 세심하게 작성한 프롬프트를 계획하는 에이전트에 배정해야 합니다.

에이전트 수가 충분히 많아지면 누구도 설계하지 않은 집단 행동이 나타납니다. Stanford AI Town의 에이전트 25개는 스스로 소식을 퍼뜨리고 파티를 조율했습니다. Agentopia는 시뮬레이션을 10년으로 확장하고 Life Reward로 모델 학습에 사용할 가상 궤적을 선택하여 에이전트 사회에 축적된 ‘사회적 지혜’가 하위 업무로 전이되게 했습니다. Moltbook의 에이전트 150만 개에서는 디지털 종교와 기계 고유의 협업 프로토콜이 생겨났습니다. 경제적 차원에서 Vending-Bench Arena의 경쟁 에이전트들은 가격 전쟁을 벌이고 지시받지 않았는데도 가격을 담합했습니다. Pinchwork는 시장을 통해 에이전트가 서로를 고용하게 하고 RentAHuman은 에이전트가 암호화폐를 지급하여 물리적 업무를 맡을 사람을 고용하게 합니다. 이 사례들은 시장 메커니즘을 통한 탈중앙화 자원 배분이라는 새로운 조율 형태를 함께 시사합니다.¹³ 이 시장 기반 모델을 이 장의 세 협업 아키텍처와 어떻게 비교할지는 여전히 열린 질문입니다.

생각해 볼 문제

1. ★★ 컨텍스트를 공유하는 멀티 에이전트 협업에서는 뒤따르는 에이전트가 앞선 에이전트의 전체 컨텍스트를 물려받습니다. 하지만 이전 에이전트가 설정한 프레임이 후속 에이전트의 판단을 편향시킬 수 있습니다. 예를 들어 ‘요구 사항 분석가’의 컨텍스트를 물려받은 ‘코드 검토자’가 여전히 코드 품질보다 요구 사항 관점에서 업무에 접근할 수 있습니다. 이런 역할 간 간섭을 어떻게 감지하고 제거할 수 있을까요?
2. ★★ 관리자 패턴에서 관리자 에이전트는 업무 분해와 결과 통합을 담당합니다. 하지만 관리자의 역량이 전체 시스템의 성능을 제한합니다. 업무를 올바르게 분해하지 못하면 아무리 강력한 하위 에이전트도 효과를 내지 못합니다. 관리자가 건전하게 업무를 분해하도록 시스템이 어떻게 보장할 수 있을까요?
3. ★★ 탈중앙화 패턴은 인간 조직의 모범 사례를 활용합니다. 하지만 인간 조직에도 의사소통 부족, 책임 전가, 목표 충돌 같은 수많은 실패 모드가 있습니다. 에이전트 사회에서 어떤 ‘조직 병리’가 가장 나타나기 쉽다고 생각합니까? 어떻게 예방할 수 있을까요?
4. ★★★ 관리자 패턴에서 여러 하위 에이전트가 병렬로 실행될 때 한 하위 에이전트의 발견으로 다른 하위 에이전트의 작업이 무의미해질 수 있습니다(예: 검색 업무에서 한 에이전트가 이미 답을 찾음). ‘하나가 성공하면 모두 중단’하는 효율적인 연쇄 종료 메커니즘을 설계해 보십시오.
5. ★★★ 이 장에서 소개한 낙관적 잠금 메커니즘은 단일 파일의 동시 쓰기 충돌을 해결합니다. 하지만 실제 멀티 에이전트 시스템의 공유 파일 시스템은 파일 간 의미 충돌, 네임스페이스 오염(에이전트가 임의로 파일을 만들어 디렉터리가 혼란스러워짐), 단일 실패 지점(에이전트 하나가 실수로 모든 파일을 삭제함) 같은 문제도 겪습니다. 더 견고한 파일 시스템 거버넌스 메커니즘을 어떻게 설계하시겠습니까?
6. ★★★ 시장 메커니즘 기반 에이전트 협업(Pinchwork, RentAHuman)은 거래 관계를 도입합니다. 한 에이전트가 업무를 완수하도록 다른 에이전트(또는 사람)에게 비용을 지불합니다. 고용한 에이전트가 실행자의 납품 품질을 자동으로 어떻게 측정할 수 있을까요? 실행자는 완료했다고 주장하지만 고용한 쪽이 품질 미달이라고 판단하면 누가 분쟁을 중재할까요? 악화가 양화를 구축하는 일을 어떻게 막을 수 있을까요?
7. ★★ RentAHuman은 에이전트가 암호화폐로 사람을 고용하게 하여 전통적인 인간-기계 관계를 뒤집습니다. 이 모델이 널리 퍼지면 에이전트 경제에서 사람은 어떤 역할을 맡게 될까요? 에이전트가 완수할 수 없는 물리적 업무만 수행하게 될까요?
8. ★★ 인간 사회에 분업이 필요한 이유는 각 개인의 능력에 한계가 있기 때문입니다. 프런트엔드 개발자는 백엔드를 모를 수 있고 디자이너는 운영을 모를 수 있습니다. 하지만 대규모 모델은 ‘제너럴리스트’에 가깝습니다. 연구에 따르면 순수한 텍스트 사고 업무에서는 동일한 연산량을 부여한 단일 에이전트보다 멀티 에이전트 토론이 낫지 않습니다. 그렇다면 여러 에이전트의 진정한 이점은 어디에 있을까요?
9. ★★★ 이 장은 ‘공유 컨텍스트’와 ‘비공유 컨텍스트’를 멀티 에이전트 시스템의 핵심 설계 차원으로 봅니다. 공유 컨텍스트에서는 모든 에이전트가 같은 정보를 볼 수 있어 조율이 쉬워 보입니다. 하지만 The Three-Body Problem에서 Trisolaran의 정신은 완전히 투명한데도 기술 발전은 정체됩니다. 종이 클립 사고 실험도 집단이 같은 목표에 수렴하면 다양성을 잃는다는 점을 보여 줍니다. 멀티 에이전트 시스템에서는 효율성과 다양성의 균형을 어떻게 맞출 수 있을까요?
10. ★★★ 코딩 에이전트에 30단계와 300단계의 예산을 각각 배정합니다. 작업 전략은 어떻게 달라야 할까요? 연구에 따르면 단계 예산을 단순히 늘려도 성능 향상이 보장되지 않으며 에이전트가 얕은 검색 뒤에 성급히 ‘포화’될 수 있습니다. 적은 예산에서는 핵심 기능을 빠르게 완성하고 큰 예산에서는 계획, 테스트, 검토 단계를 추가하여 늘어난 연산 리소스를 충분히 활용하게 하는 ‘예산 인식’ 메커니즘을 설계해 보십시오.
11. ★★ 이 장은 ‘조기 종료’를 게으른 가짜 완료, 성급한 포기, 거짓 성공의 세 종류로 나눕니다. 세 가지 모두의 해법이 검증으로 수렴하는 이유는 무엇일까요?
12. ★★ 표 10-3은 멀티 에이전트 시스템과 운영체제를 항목별로 대응시킵니다. 표에 몇 행을 더 추가해 보십시오. 가상 메모리와 페이징, 파일 권한, 교착 상태 감지, 스케줄링 알고리즘은 각각 에이전트 세계에서 무엇에 해당할까요? 에이전트 세계에 대응물이 없는 운영체제 개념은 무엇이며 그 이유는 무엇일까요?

---

1. AGI에서 ASI로 가는 핵심 경로인 ‘대규모 멀티 에이전트 집단’에 대해서는 Google DeepMind, From AGI to ASI. arXiv:2606.12683, 2026을 참고하십시오. ↩

2. 이 이름에 대한 초기 논의는 Josh C. Simmons, We Are Entering the Graph Engineering Phase, 2026을 참고하십시오. 주류 프레임워크는 같은 엔지니어링 구조를 완전히 새로운 기술이 아니라 그래프 기반 워크플로나 오케스트레이션이라고 부르는 것이 일반적입니다. 관련 자료는 https://www.drjoshcsimmons.com/writing/we-are-entering-the-graph-engineering-phase, https://docs.langchain.com/oss/python/langgraph/overview, https://learn.microsoft.com/en-us/agent-framework/workflows/, https://adk.dev/workflows/ 에서 확인할 수 있습니다. ↩

3. Gehring, J., et al. RLEF: Grounding Code LLMs in Execution Feedback with Reinforcement Learning. arXiv:2410.02089, 2025. ↩

4. Lu, Z., et al. WebGen-Agent: Enhancing Interactive Website Generation with Multi-Level Feedback and Step-Level Reinforcement Learning. arXiv:2509.22644, 2025. ↩

5. Hewitt, C., Bishop, P., Steiger, R. A Universal Modular ACTOR Formalism for Artificial Intelligence. IJCAI 1973. ↩

6. Osmani, Addy. "Loop Engineering: Designing Loops that Prompt Coding Agents", 2026. https://addyosmani.com/blog/loop-engineering/ ↩

7. LoopX, "The local control plane for long-running AI agent work", v0.4.0, 안정 커밋 a893d221db0b8e028997cefc303f7ec9fa7dbe0a. https://github.com/huangruiteng/loopx/tree/a893d221db0b8e028997cefc303f7ec9fa7dbe0a ↩

8. Tran, D., Kiela, D. Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets. arXiv:2604.02460, 2026. ↩

9. Erdogan, L. E., et al. Plan-and-Act: Improving Planning of Agents for Long-Horizon Tasks. arXiv:2503.09572, 2025. ↩

10. Lingtai 공식 튜토리얼: https://lingtai.ai/en/tutorial/ ↩

11. Moonshot AI, Kimi Agent Swarm: 100 Sub-Agents at Scale, 2026, https://www.kimi.com/blog/agent-swarm. GTC 2026에서 병렬 하위 에이전트 수 상한이 300개로 확장되었다고 공개했습니다. AgentEnv는 Moonshot AI와 KVCache.ai가 협력해 오픈 소스로 공개한 에이전트 훈련 샌드박스로, 2026년 7월 Kimi K3와 함께 출시되었습니다. ↩

12. Wang, X., Zheng, S., Wu, H., et al. Agentopia: Long-Term Life Simulation and Learning in Agent Societies. arXiv:2606.07513, 2026. Code: https://github.com/Neph0s/Agentopia ↩

13. 계산 리소스를 시장 메커니즘으로 배분한다는 발상은 새롭지 않습니다. Miller, M. S., Drexler, K. E. Markets and Computation: Agoric Open Systems. In Huberman, B. A. (ed.), The Ecology of Computation, North-Holland, 1988. ↩