멀티 에이전트가 현실이 된 해
2024년 대부분의 기간 동안 멀티 에이전트 논의는 분위기에 가까웠습니다. 사람들은 결혼식을 계획하거나 가짜 회사를 운영하는 "에이전트 군집" 데모를 올렸지만, 그중 거의 어떤 것도 프로덕션과의 접촉에서 살아남지 못했습니다. 약속은 거대했고, 증거는 빈약했습니다.
이것이 바뀐 것은 2025년 4월, Anthropic이 자사 멀티 에이전트 리서치 시스템에 대한 엔지니어링 리포트를 발표하면서부터였습니다. 아키텍처의 형태는 단순했습니다. 리드 Claude Opus 4 에이전트가 오케스트레이터 역할을 맡고, 리서치 질문을 하위 작업으로 분해한 뒤, 서브에이전트를 띄워 병렬로 조사하게 하고, 그 결과를 모아 정리합니다. Anthropic의 내부 브라우징 평가에서 이 구성은 단일 에이전트 Opus 4 베이스라인을 90.2% 능가했습니다. (Anthropic engineering, "How we built our multi-agent research system")
이것이 헤드라인입니다. 작은 글씨가 더 중요합니다. 같은 리포트는 멀티 에이전트 시스템이 일반 채팅보다 약 15배 많은 토큰을 사용한다고 밝힙니다. 토큰 소비는 그들의 평가 프레임워크에서 성능 분산의 약 80%를 설명했습니다. 그 90.2%를 공짜로 얻는 것이 아닙니다. 사고 있는 것입니다.
이제 AI 기능을 설계하는 창업자, CTO, 또는 스태프 엔지니어에게 던져지는 질문은 더 이상 "멀티 에이전트가 진짜 패턴인가?"가 아닙니다. "이 작업에 멀티 에이전트가 올바른 패턴인가, 그리고 그 비용은 얼마인가?"입니다. 2025년과 2026년 상반기는 직감 이상으로 이 질문에 답할 만한 충분한 데이터를 만들어 냈습니다. 승리한 패턴, 패배한 패턴, 반복되는 실패 모드는 고전적인 조직 설계와 매우 닮아 있습니다. 그것이 이 글의 줄기입니다.
실패 모드 분류법: Cemri 외가 기록한 것
2025년 3월, Mert Cemri와 버클리의 협업자들은 "Why Do Multi-Agent LLM Systems Fail?"을 발표했습니다 (arXiv 2503.13657). 이 논문은 다섯 개의 인기 멀티 에이전트 프레임워크를 150개가 넘는 대화 트레이스에 걸쳐 분석하고, 이 분야가 절실히 필요로 하던 것을 만들어 냈습니다. 분류법입니다.
14가지 서로 다른 실패 모드를 세 가지 계열로 묶었습니다.
사양 및 시스템 설계 실패. 에이전트가 자기 역할 사양을 따르지 않습니다. 작업 사양을 따르지 않습니다. 대화 기록을 잃어버립니다. 단계가 반복됩니다. 종료 조건이 발화되지 않습니다. 시스템은 작업을 "알고" 있지만, 눈앞의 개별 에이전트는 마치 모르는 것처럼 행동합니다.
에이전트 간 불일치. 에이전트가 진행 상황을 리셋하고 처음부터 다시 시작합니다. 서로 정보를 숨깁니다. 주제에서 벗어난 대화로 빠집니다. 다른 에이전트가 무엇을 했는지에 대해 가정을 세우고, 확인하지 않은 채 그 가정 위에서 행동합니다. 이것은 어느 팀에서나 흔한 "네가 한 줄 알았어"라는 고전적 실패입니다.
작업 검증 및 종료 실패. 검증이 불완전하거나 아예 없습니다. 출력이 잘못되었는데도 시스템이 성공을 선언합니다. 어떤 에이전트도 최종 수락 검사를 책임지지 않습니다. 사람은 잘못된 출력이 이미 퍼져 나간 뒤 하류에서야 문제를 발견합니다.
목록을 읽으면 형태가 분명해집니다. 좁은 의미의 모델 실패가 아닙니다. 조정 실패입니다. 처음 한 달 동안, 누가 무엇을 책임지는지 아무도 적어 두지 않은 신생 5인 팀이 저지르는 실패와 똑같습니다.
14가지 모드를 다른 방식으로 묶으면 조직 설계와의 평행성이 더 또렷해집니다.
- 역할 모호성. 작업 책임이 불분명합니다. 두 에이전트가 같은 단계를 동시에 시도하거나, 아무도 시도하지 않습니다.
- 상태 모호성. 무엇이 끝났고, 무엇이 대기 중이며, 무엇이 막혔는지에 대한 단일 진실 공급원이 없습니다.
- 책임 공백. 잘못된 출력을 누가 책임지는가? 피어 투 피어 시스템에서는 종종 아무도 책임지지 않습니다.
- 조정 비용. "회의 문제"입니다. 에이전트들이 생산이 아니라 협상에 토큰을 씁니다.
- 사양 표류. 같은 지시가 에이전트마다, 턴마다 다르게 해석됩니다.
출하하지 못하던 팀을 재정비해 본 적이 있다면 다섯 가지를 모두 보았을 것입니다. 사람 팀에서의 해법은 에이전트 시스템에서의 해법과 같습니다. 운영 모델을 정하고, 역할을 적어 두고, 핸드오프를 정의하고, 작업을 계측하는 것입니다.
피어 투 피어 에이전트가 통하지 않는 이유
2024년과 2025년 초의 가장 흔한 아키텍처 실수는 피어 투 피어 협업이었습니다. 서로 다른 역할 프롬프트(CEO, 리서처, 코더, 리뷰어)를 가진 "팀"을 만들어 그룹 채팅에서 서로 대화하게 하고, 조정이 자연 발생하기를 바라는 방식이었습니다. AutoGen 식의 그룹 채팅, 초기 CrewAI 데모, "박스 안의 AI 스타트업"이라는 일련의 프로젝트들이 모두 이 패턴에 기댔습니다.
그것은 일관되게 프로덕션에서 실패했습니다. Cemri 분류법의 모든 실패 모드는 P2P 구성에서 증폭됩니다. 오케스트레이터가 없으면, 어떤 에이전트에게도 어떤 일이든 시킬 수 있게 되므로 역할 경계가 흐려집니다. 어떤 에이전트도 정본 기록을 책임지지 않기 때문에 상태가 대화 기록 전반에 흩어집니다. 시스템 전체가 출력을 만들어 내고, 그 시스템 전체에는 책임자의 이름이 적혀 있지 않기 때문에 책임 소재가 사라집니다.
조정 비용이 결정타입니다. 다섯 명의 동료 에이전트로 이뤄진 그룹에서는 의미 있는 행동 하나마다 댓글을 달아야 할 의무감을 느끼는 네 명의 관찰자가 생겨납니다. 토큰 비용이 부풀어 오릅니다. 신호 대 잡음비가 무너집니다. Cemri 외는 어떤 에이전트가 스레드가 끝났음을 알아채지 못해 끝난 스레드를 다시 시작하는 "대화 리셋"이 그들의 코퍼스에서 가장 흔하고 가장 비싼 실패 중 하나였다고 보고했습니다.
구체적인 예가 있습니다. 2025년 말에 이야기한 한 리서치 팀은 경쟁사 분석 초안을 작성하기 위해 P2P 에이전트 시스템을 만들었습니다. 시장 분석가, 제품 분석가, 재무 분석가, 작가, 편집자의 다섯 에이전트였습니다. 첫 실행은 90분이 걸렸고 14,000단어 분량의 문서를 만들어 냈습니다. 그중 약 11,000단어는 에이전트들이 문서에 무엇을 담아야 하는지를 논의한 내용이었습니다. 나머지 3,000단어가 문서 자체였는데, 서로 모순되었습니다. 그 팀은 다음 주에 이를 오케스트레이터-워커 구성으로 다시 만들었습니다. 같은 작업이 22분, 4,200단어, 내부적으로 일관된 결과로 끝났고, 토큰 소비는 대략 절반이었습니다.
P2P는 에이전트가 똑똑하지 않아서 실패한 것이 아닙니다. 어떤 그룹에게나 가장 어려운 일, 즉 의장 없이 스스로를 조직화하라고 요구했기 때문에 실패한 것입니다.
오케스트레이터-워커: 승리한 패턴
Anthropic의 리서치 시스템은 교과서적인 오케스트레이터-워커 구성입니다. 하나의 코디네이터 에이전트가 상위 수준의 작업을 책임집니다. 작업을 하위 작업으로 분해하고, 각 하위 작업을 구체적인 브리프와 함께 워커 에이전트에게 넘기고, 결과를 수집하고, 다음에 무엇을 할지 결정합니다. 워커끼리는 대화하지 않습니다. 워커는 오케스트레이터에게 말합니다.
이것은 사람의 조직 설계에 깔끔하게 대응되며, 바로 그래서 작동합니다. 창업자 한 명과 네 명의 계약자로 이뤄진 작은 스타트업이 이렇게 운영됩니다. 창업자는 사양, 예산, 일정, 공유 컨텍스트를 보유합니다. 계약자는 브리프에 따라 범위가 정해진 작업을 수행합니다. 정보는 창업자를 거쳐 위로 흐르고, 작업은 창업자로부터 아래로 흐릅니다. 계약자들은 신중하게 범위가 정해진 페어링을 제외하면 자기들끼리 조정하리라고 기대받지 않습니다.
이 패턴에는 신뢰성에 중요한 네 가지 속성이 있습니다.
공유 상태의 단일 소유자. 오케스트레이터가 정본 기록을 보유합니다. 무엇이 끝났는지에 대한 모호함이 없습니다.
범위가 한정된 워커 컨텍스트. 각 워커는 필요한 것만 받습니다. 이렇게 하면 컨텍스트 윈도가 관리 가능한 크기로 유지되고, 작업 간 오염 가능성이 줄어듭니다.
정의된 핸드오프. 워커의 출력은 오케스트레이터가 검증할 수 있는 구조화된 형식으로 돌아옵니다. 자유 형식 협상은 없습니다.
단일 책임 표면. 출력이 잘못되었을 때 오케스트레이터가 책임집니다. 디버깅할 곳은 한 곳입니다.
Anthropic의 리포트는 신뢰성 작업의 얼마나 많은 부분이 오케스트레이터 내부에서 이루어졌는지를 분명히 밝힙니다. 리드 에이전트의 프롬프트가 시스템에서 가장 길고 가장 정교하게 튜닝된 부분인데, 이는 역할 정의, 분해 휴리스틱, 종료 로직이 모두 거기에 살기 때문입니다. (Anthropic engineering)
경계가 명확한 협업은 유용한 변형입니다. 두 워커가 특정 핸드오프에 대해 협의할 수 있지만, 구조화된 채널을 통해서만, 정의된 주제에 대해서만 그렇게 합니다. Slack 채널이 아니라 정해진 스탠드업이라고 생각하면 됩니다. 경계가 핵심입니다.
| 패턴 | 실패 저항성 | 비용 | 복잡성 | 적합한 곳 |
|---|---|---|---|---|
| 피어 투 피어 (그룹 채팅) | 낮음. 모든 실패 모드가 증폭됩니다. | 높음. 협상 토큰이 많습니다. | 오해 소지가 있음. 단순해 보이지만 그렇지 않습니다. | 데모, 브레인스토밍 스케치. |
| 오케스트레이터-워커 | 높음. 소유자가 하나, 디버그 표면이 하나. | 중간에서 높음. 단일 에이전트의 약 10-15배. | 중간. 대부분의 로직은 오케스트레이터에 있습니다. | 리서치, 분해, 병렬화 가능한 작업. |
| 경계가 명확한 협업 | 중상. 위험은 이음새에 있습니다. | 중간. 완전한 P2P보다 저렴합니다. | 더 높음. 설계된 핸드오프는 일입니다. | 오케스트레이터 아래의 전문가 페어링. |
| 에이전트 플로우 (DAG) | 높음. 정적 구조가 표류를 사전에 막습니다. | 낮음에서 중간. 캐시된 단계를 재사용합니다. | 설계 시 중간, 실행 시 낮음. | 반복적인 파이프라인, 배치 처리. |
5단계 자율성 프레임워크
알아 둘 만한 2025년의 또 다른 발판은 "Levels of Autonomy for AI Agents"의 자율성 프레임워크입니다 (arXiv 2506.12469, 거버넌스 동반 리포트는 Knight Columbia에 있습니다). 저자들은 SAE의 자율 주행 등급과 느슨하게 유사하지만 AI 에이전트를 위한 다섯 단계를 정의합니다.
레벨 0: 보조형(Assistive). 모델이 제안하고, 사람이 행동합니다. 자동 완성, 인라인 코드 제안, 이메일 초안 작성이 여기에 해당합니다.
레벨 1: 오퍼레이터(Operator). 사람이 여전히 각 행동을 지시하지만, 에이전트가 직접 지시 아래에서 툴 호출과 복합 단계를 조립합니다.
레벨 2: 리뷰어(Reviewer). 에이전트가 계획을 제안하고 검토를 받으며 실행합니다. 사람은 주요 체크포인트에서 승인합니다.
레벨 3: 협력자(Collaborator). 에이전트가 정해진 경계 안에서 작업 전체를 자율적으로 책임집니다. 사람은 단계가 아니라 출력을 검토합니다.
레벨 4: 전문가(Expert). 에이전트가 복잡한 다단계 작업에서 독립적으로 운영되며, 사람은 표시된 예외 상황에만 개입합니다.
레벨 5: 에이전트(Agent). 한 도메인 전반에 걸친 완전 자율. 에이전트가 목표를 세우고, 계획하고, 실행하고, 최소한의 감독으로 스스로 교정합니다.
Anthropic의 보완 작업인 "Measuring AI agent autonomy in practice"는 관련된 지적을 합니다. 실제 배포에서 운영 수준이 시스템 전반에 걸쳐 균일한 경우는 드뭅니다. "레벨 3" 시스템은 보통 레벨 1 하위 컴포넌트(고위험 행동)와 레벨 4 하위 컴포넌트(저위험 백그라운드 작업)를 함께 담고 있습니다. 중요한 것은 수준을 전역적으로 올리는 것이 아니라, 작업에 수준을 맞추는 것입니다.
목표로 삼는 수준은 그 이후의 모든 역할 설계 결정을 결정짓습니다. 레벨 2에서는 워커 에이전트에 명확한 계획-검토 어포던스가 필요합니다. 레벨 4에서는 예외 표시와 풍부한 트레이싱이 필요합니다. 레벨 5에서는 수락 기준의 형식적 검증이 필요합니다. 그렇지 않으면 잘못된 답을 잡을 수 있는 다른 수단이 없기 때문입니다. 이 단계를 건너뛰는 빌더는 아키텍처를 먼저 고르고, 프로덕션에서야 그 아키텍처가 함축하는 수준이 그 작업이 견딜 수 있는 수준이 아님을 발견합니다.
실전에서의 자율성 단계: Devin 사례
Cognition의 Devin은 2025년에 가장 많이 인용된 경고성 사례가 되었습니다. 2024년 3월 "최초의 AI 소프트웨어 엔지니어"로 출시된 Devin은 SWE-bench Verified에서 13.86%를 기록했으며, 당시로서는 SOTA였습니다. 마케팅은 레벨 4 또는 레벨 5의 자율성을 암시했습니다. 티켓을 넘기면 작동하는 PR이 돌아온다는 식이었습니다.
2025년 중반에는 여러 독립적 리뷰가 Devin의 실제 성공률을 약 15%로 추정했고, 큐레이션된 벤치마크 인스턴스가 아닌 작업에서는 사실상 약 85%의 실패율을 의미했습니다. 널리 인용된 Answer.AI 리뷰는 20번의 실제 시도를 살펴봤는데, 14번이 완전히 실패했고, 그중 일부는 자신만만하게 잘못된 출력을 만들어 내어 처음부터 코드를 작성하는 것보다 디버깅에 더 오래 걸렸다고 보고했습니다.
벌어진 일은 벤치마크와 프로덕션의 간극이 더 날카로워진 것입니다. SWE-bench Verified 작업은 깨끗합니다. 하나의 레포, 잘 기술된 하나의 이슈, 명확한 테스트 신호, 제한된 표면적이 있습니다. 실제 엔지니어링 티켓은 지저분합니다. 모호한 사양, 횡단 관심사, 문서화되지 않은 가정, 부족 지식에 의존하는 결정들이 있습니다. 벤치마크에서 레벨 3에 자리한 같은 에이전트가 야생에서는 흔들리는 레벨 2, 때로는 그보다 못한 곳으로 떨어졌습니다.
Devin은 나쁜 에이전트에 대한 이야기가 아닙니다. 수준 불일치에 대한 이야기입니다. 아키텍처는 레벨 5의 신뢰성을 겨냥했지만, 기저 역량은 비큐레이션 작업에서 잘해야 레벨 2를 지원했습니다. 마케팅이 사용자에게 광고된 수준에서 시스템을 작동하도록 강요했고, 그 수준에서 실패했습니다. Cognition의 후속 방향 전환들, 즉 더 좁혀진 사용 사례, 더 많은 휴먼 인 더 루프 어포던스, 더 정직한 프레이밍은 운영 수준을 역량과 다시 일치시키려는 시도입니다.
교훈은 구체적입니다. 가장 쉬운 벤치마크가 아니라, 가장 어려운 실제 작업에서 시스템이 지속할 수 있는 자율성 수준을 고르십시오. 그 수준에 맞춰 역할, 감독, 에스컬레이션 경로를 설계하십시오. 레벨 5 마케팅을 원한다면 레벨 5 시스템을 만들고, 레벨 3 시스템을 가지고 있다면 그렇게 마케팅하십시오.
Cursor 2.0과 하드웨어로 뒷받침되는 워크플로
Cursor 2.0은 2026년 2월에 출시되어 멀티 에이전트 코딩의 가장 끈질긴 문제 중 하나인 워크스페이스 충돌을 조용히 해결했습니다. Cursor의 백그라운드 에이전트는 이제 각각 자기 git worktree를 가진 클라우드 VM에서 실행되며, IDE가 최대 여덟 개를 병렬로 조율할 수 있습니다.
중요한 아키텍처 디테일은 각 에이전트가 자기 파일시스템을 가진다는 점입니다. 공유 작업 트리가 없다는 것은 편집 중 머지 충돌이 없고, "에이전트 A가 에이전트 B의 변경을 덮어썼다"는 일도 없으며, 두 에이전트가 같은 파일을 만져서 테스트 실행이 불안정해지는 일도 없다는 뜻입니다. 에이전트가 끝나면 그 브랜치는 다른 어떤 PR과도 마찬가지로 리뷰되고 머지될 수 있습니다. 잘못되면 worktree를 버립니다.
이것은 2000년대에 가상 머신이 프로세스 격리를 제공한 것과 같은 의미에서 하드웨어로 뒷받침되는 격리입니다. 에이전트 사이의 울타리는 더 이상 "서로 밟지 않겠다고 약속할게요"가 아니라 "운영 체제가 말 그대로 우리가 그렇게 못 하게 막는다"가 됩니다.
이것이 Cemri 분류법에 중요한 이유는, 하드웨어 격리가 에이전트 간 불일치 실패의 한 부류 전체를 제거하기 때문입니다. 상태는 worktree 안에 머무릅니다. 부수 효과는 VM 안에 머무릅니다. 오케스트레이터(Cursor 자체이든 사용자이든)는 각 에이전트가 만들어 내는 diff만 봅니다. 수락 검사는 대화형(이 에이전트가 작업이 끝났다고 주장하는가?)이 아니라 구조적(PR이 CI를 통과하는가?)입니다.
Cursor 2.0을 Anthropic의 Claude Code, OpenAI의 Codex CLI, 그리고 다른 병렬 에이전트 도구들과 함께 운영하는 실무자들은 한 패턴에 정착했습니다. 세 개에서 여덟 개의 에이전트를 독립된 작업에 띄우고, 통합 대시보드에서 진행 상황을 모니터링하고, 성공은 머지하고 실패는 버립니다. 비용 모델은 "챗봇에 질문하기"보다 "1시간 30분 동안 주니어 계약자를 빌리기"에 더 가깝습니다. 출력 모델은 채팅 완성보다 GitHub PR 리뷰에 더 가깝습니다.
Anysphere(Cursor), Bolt, Lovable, 그리고 Vercel 내부의 v0 모두 지금 이 루프의 변형을 내부적으로 운영하고 있습니다. 가장 많은 에이전트 주도 코드를 출하하는 회사들은 워크스페이스 격리를 먼저 구축한 회사들입니다.
AI 팀원을 위한 역할 설계
멀티 에이전트 실패가 조직 설계 문제임을 받아들이면, 당신이 내리는 설계 결정은 고전적인 매니지먼트처럼 보이기 시작합니다. 모든 에이전트 역할에는 네 가지 산출물이 필요합니다.
범위가 정해진 책임. 한 문장으로, 이 에이전트가 무엇을 소유하고 무엇을 소유하지 않는지 적습니다. 산문도 함께 쓰는 "리서처" 에이전트는 트렌치코트를 입은 두 에이전트입니다. 분리하십시오.
구조화된 입력 브리프. "X를 리서치해"가 아닙니다. 다음을 채우는 템플릿입니다. 질문, 에이전트가 가정해야 할 사전 컨텍스트, 기대되는 출력의 형식, 제약(시간, 토큰, 도구), 소스 선호도. 이것은 에이전트판 프로젝트 브리프입니다.
정의된 수락 기준. "끝났다"는 어떤 모습입니까? 보통 이것은 스키마(출력이 이 Zod 타입에 대해 유효해야 함)이거나 결정론적 검사(PR이 이 세 개의 테스트 파일을 통과해야 함)입니다. 결정론적 검사를 사용할 수 없는 곳에서는, 별도의 리뷰어 에이전트가 명시적 루브릭에 맞춰 실행됩니다.
에스컬레이션 경로. 에이전트가 막혔을 때 무엇을 합니까? 합리적 기본값은 다음과 같습니다. 오케스트레이터에게 구조화된 명확화 질문을 던지기, 표시된 예외를 사람에게 노출하기, 타입이 있는 오류로 중단하기. 잘못된 기본값은 "계속 가면서 즉흥적으로 처리"입니다. 환각된 성공은 거기서 나옵니다.
Cemri의 실패 모드를 하나씩 적용해 보면, 이 네 가지 산출물이 대부분을 커버합니다. 역할 모호성은 범위가 정해진 책임에서 죽습니다. 상태 모호성은 구조화된 브리프에서 죽습니다. 책임 공백은 수락 기준에서 죽습니다. 조정 비용은 떨어집니다. 에이전트가 협상할 필요가 없기 때문입니다. 그에게는 브리프와 루브릭이 있습니다. 사양 표류도 떨어집니다. 사양이 분위기가 아니라 스키마에 담겨 있기 때문입니다.
분명하지 않은 부분은 이것입니다. 챗봇용 프롬프트가 아니라 계약자를 위한 직무 기술서를 쓰듯이 역할을 적으십시오. 계약자는 올바른 멘탈 모델입니다. 그들에게는 브리프가 있고, 산출물을 인도하고, 회사 전체 컨텍스트를 알 필요가 없으며, 사양을 계속 어기면 해고됩니다.
창업자를 위한 멀티 에이전트 플레이북
Anthropic 리포트, Cemri 논문, Devin 포스트모템, 그리고 Cursor 2.0 워크플로 데이터에서 추려낸 실용 버전입니다.
레벨 5가 아니라 레벨 2 또는 3에서 시작하십시오. 역량은 분포 시프트에 취약합니다. 벤치마크가 레벨 4라고 말해도, 가장 어려운 실제 작업은 보통 한 단계 아래에 있습니다. 가장 어려운 작업이 지속할 수 있는 수준을 목표로 삼으십시오.
피어 투 피어가 아니라 오케스트레이터-워커를 쓰십시오. 한 에이전트가 공유 상태를 소유합니다. 워커는 범위가 정해진 브리프를 받습니다. 경계가 명확한 협업은 신중히 설계된 이음새에서만. 그룹 채팅은 안 됩니다.
한 번에 하나의 에이전트 역할만 정의하십시오. 어떤 것도 출하되기 전에 화이트보드에 다섯 에이전트 시스템을 설계하려는 충동에 저항하십시오. 오케스트레이터 하나와 워커 하나를 출하하십시오. 일주일 동안 지켜보십시오. 첫 워커가 실패하고 그것을 고친 뒤에 다음 워커를 추가하십시오.
브리프를 직무 기술서처럼 쓰십시오. 책임, 입력, 수락 기준, 에스컬레이션. 네 개의 짧은 섹션으로 역할을 기술할 수 없다면, 그 역할은 출하 준비가 안 된 것입니다.
전체 트레이스로 계측하십시오. 모든 에이전트 행동, 모든 툴 호출, 모든 중간 출력을 기록하십시오. 최종 출력만 읽고 멀티 에이전트 시스템을 디버깅할 수는 없습니다. 버그는 거의 항상 상류에 있습니다.
15배의 토큰 비용을 예산에 잡으십시오. Anthropic의 리서치 시스템은 단일 에이전트 베이스라인의 약 15배 토큰을 썼습니다. 그에 맞춰 계획하십시오. 단위 경제가 15배에서 무너진다면, 그 기능에 멀티 에이전트는 잘못된 패턴입니다.
중요한 행동에는 사람을 루프에 남기십시오. "중요한"이 보통 의미하는 것은 다음과 같습니다. 고객 대상 시스템에 쓰기, 외부 커뮤니케이션 발송, 돈 쓰기, 데이터 삭제, 보안 관련 리소스 수정. 사람 리뷰는 몇 초가 들지만, 그것이 없으면 몇 달의 비용이 들 수 있습니다.
에이전트 함대 이전에 워크스페이스 격리를 구축하십시오. Cursor의 교훈은 일반화됩니다. 코드에는 git worktree, 데이터에는 범위가 정해진 데이터베이스 트랜잭션, 환경을 건드리는 작업에는 전용 VM. 격리는 조정보다 저렴합니다.
처음 90일 동안은 모든 실패에 대해 포스트모템을 돌리십시오. 각 실패를 Cemri 분류법에 태그하십시오. 패턴은 빠르게 드러납니다. "끝난 작업을 에이전트가 다시 했다"는 세 번째 실패는 종료 조건을 조여야 한다는 신호입니다.
이 중 어떤 것도 이국적이지 않습니다. 유능한 엔지니어링 리더가 새로운 계약자 팀을 온보딩할 때 쓰는 것과 같은 플레이북입니다. 멀티 에이전트가 작동하는 이유는, 더 빡빡한 피드백 루프를 가진 같은 문제이기 때문입니다.
앞으로 나아갈 방향
다음 12개월에서 18개월은 이러한 패턴을 인프라로 바꾸는 시기입니다. 지켜볼 만한 몇 가지 줄기가 있습니다.
에이전트 간 프로토콜. Google의 A2A 프로토콜, IDE와 CLI 도구 전반에서 떠오르는 AGENTS.md 컨벤션, 그리고 워킹 그룹의 여러 상호 운용 초안들은 에이전트가 서로를 발견하고, 역량 기술을 교환하고, 인증하는 방식을 표준화하려는 시도입니다. (Anthropic의 에이전트 구축 개요도 이 방향을 가리킵니다.) 핵심은 오케스트레이터-워커 패턴을 한 공급자의 SDK에 묶이지 않고 벤더 간에 조립 가능하게 만드는 것입니다.
역량 토큰 인가. 오늘날 대부분의 에이전트는 자신을 시작한 사용자의 전체 자격 증명을 상속합니다. 레벨 3 이상에서는 나쁜 생각입니다. 좁고, 시간 제한이 있으며, 특정 툴 호출과 리소스로 범위가 정해진 역량 토큰은 에이전트가 실제로 필요한 권한만 얻고 그렇지 않은 것은 얻지 않게 하는 방법입니다. 2026년 안에 프로덕션 SDK에 들어올 것으로 예상됩니다.
검증된 에이전트 신원. 에이전트가 조직 경계를 넘어 다른 에이전트를 호출하기 시작하면, 받는 쪽은 무엇이 호출하고 있는지 알아야 합니다. 서명된 에이전트 신원, 학습과 구성의 증명, 벤더 간 신원 포맷이 지금 프로토타이핑되고 있습니다. 모델은 OAuth보다는 인증서 투명성에 가깝습니다.
더 나은 평가. SWE-bench, MLE-bench, GAIA, 그리고 유사한 벤치마크 모음들은 프런티어 모델이 포화 상태에 이를 만큼 멀리 늘어났습니다. 다음 세대 평가는 벤치마크가 역사적으로 회피해 온 것들을 측정할 것입니다. 장기 작업 완료, 지속적 정책 준수, 실패로부터의 회복, 성공당 비용. "에이전트 신뢰성"이 서비스의 "가동률"처럼 측정 가능한 속성이 되리라 예상됩니다.
표준화된 실패 태깅. Cemri 외는 이 분야에 분류법을 제공했습니다. 자연스러운 다음 단계는 Sentry가 예외에 태그를 다는 방식처럼, 트레이스를 그 분류법에 자동으로 태그하는 도구입니다. 이것을 일찍 설정하는 창업자는 그러지 않은 사람보다 자기 에이전트 시스템을 한 자릿수 배 빠르게 디버깅할 것입니다.
작업은 아직 비행 중입니다. 이 줄기들 중 어떤 것도 결정된 것은 없습니다. 그러나 다음 단계의 모습은 보입니다. 프롬프트 공예는 줄고, 시스템 엔지니어링이 늘어납니다. "모델이 무엇을 할 수 있는가?"는 줄고, "내가 어떤 역할을 채워야 하고, 끝난 모습은 어떠한가?"가 늘어납니다. 번성할 팀은 에이전트를 새 직원에게 적용하는 만큼의 엄밀함으로 팀원으로 대하는 팀입니다. 역할, 브리프, 수락 기준, 에스컬레이션 경로. 유능한 조직의 지루한 산출물들입니다.
자주 묻는 질문
모든 팀이 멀티 에이전트 시스템을 만들어야 합니까?
아닙니다. 대부분의 프로덕션 AI 기능은 좋은 도구를 갖춘 단일 에이전트 구성으로 가장 잘 작동합니다. 멀티 에이전트가 값을 하는 경우는 작업이 진정으로 분해 가능하고(병렬로 실행될 수 있는 독립 하위 작업들), 작업당 가치가 15배 토큰 비용을 정당화하며, 신뢰성이 단일 에이전트 계층에서 먼저 입증되었을 때입니다. 실패하는 단일 에이전트 시스템은 작동하는 멀티 에이전트 시스템이 되지 않습니다. 보통 더 비싼, 실패하는 시스템이 될 뿐입니다.
가장 단순한 프로덕션용 멀티 에이전트 패턴은 무엇입니까?
오케스트레이터 하나와 워커 둘, 둘 다 결정론적 수락 기준을 가진 구성입니다. 오케스트레이터가 공유 상태를 소유합니다. 워커는 범위가 정해진 브리프를 받습니다. 출력은 오케스트레이터가 수락하기 전에 스키마에 대해 검증됩니다. 이것이면 더 큰 팀의 조정 비용 없이 분해의 이점 대부분을 잡아내기에 충분합니다. 이 베이스라인이 안정적이 된 후에만 워커 수를 늘리십시오.
15배 토큰 비용은 그만한 가치가 있습니까?
출력의 가치에 따라 다릅니다. Anthropic의 리서치 시스템은 같은 작업에 사람 리서처가 몇 시간을 쓰는 것이 대안이기 때문에 경제적으로 말이 됩니다. 저가치, 고볼륨 작업(의도 분류, 단순 요약, 정형 추출)에서는 15배 토큰 비용이 거의 가치가 없습니다. 단일 에이전트 구성이나 더 작은 모델을 쓰십시오. 고가치, 저볼륨 작업(심층 리서치, 복잡한 코딩 작업, 다중 소스 분석)에서는 계산이 종종 맞아 들어갑니다.
언제 서브에이전트를 띄우고 언제 더 긴 프롬프트를 써야 하는지 어떻게 압니까?
작업이 부모 작업과 다른 컨텍스트 요구사항을 가질 때 서브에이전트를 띄우십시오. 하위 작업이 다른 도구, 다른 시스템 프롬프트, 또는 부모의 윈도를 오염시킬 컨텍스트를 필요로 한다면, 자기 에이전트를 주십시오. 하위 작업이 "그냥 다음 이걸 해"이고 부모의 컨텍스트를 공유한다면, 더 긴 프롬프트나 툴 호출이 더 저렴하고 더 안정적입니다. 결정적 질문은 보통 컨텍스트에 관한 것입니다. 하위 작업이 끝난 후 이 컨텍스트가 내 오케스트레이터의 메모리에 남아 있기를 원하는가?
에이전트와 AI 도구의 차이는 무엇입니까?
도구는 모델이 호출할 수 있는 단일한 결정론적 역량입니다(웹 검색, 데이터베이스 쿼리, 코드 포매터). 에이전트는 루프입니다. 관찰하고, 계획하고, 도구를 호출하고, 결과를 평가하고, 다음에 무엇을 할지 결정하며, 종종 여러 턴에 걸쳐 그렇게 합니다. 도구는 명사이고, 에이전트는 동사입니다. 잘 만들어진 에이전트는 여러 도구를 씁니다. 내부적으로 모델을 호출하고 자기 루프를 도는 "도구"는 실제로는 에이전트입니다.
맺는말
지금 이 순간에 대해 들어 본 것 중 가장 유용한 프레이밍은 멀티 에이전트 코딩 도입을 이끄는 한 엔지니어링 리더에게서 나왔습니다. "우리는 에이전트를 똑똑한 존재로 생각하기를 멈추고, 무한한 체력을 가진 주니어로 생각하기 시작했습니다." 주니어는 명확한 역할, 적힌 브리프, 정의된 수락 기준, 그리고 에스컬레이션 경로가 필요합니다. 그들은 예측 가능한 실수를 합니다. 피드백으로 나아집니다. 아무도 그들의 작업을 책임지지 않을 때 실패합니다.
그것이 멀티 에이전트 논의 안에 숨어 있는 조직 설계의 전환입니다. 2025-2026년의 어려운 문제는 더 이상 역량 문제가 아닙니다. 모델은 충분히 좋습니다. 어려운 문제는 사람으로 이뤄진 팀을 운영하기 어렵게 만들어 온 바로 그것들입니다. 누가 무엇을 소유하는가, 누가 상태를 보유하는가, 누가 작업을 검사하는가, 잘못되었을 때 누가 책임지는가. Cemri의 분류법, 자율성 프레임워크, 오케스트레이터-워커 패턴, Devin 포스트모템, Cursor의 격리 모델. 이것들은 모두 같은 질문의 변형에 대한 답입니다.
2026년에 에이전트 주도 제품을 출하하는 창업자라면, 지루한 산출물이 지렛대입니다. 역할을 쓰십시오. 브리프를 쓰십시오. 끝난 모습을 정의하십시오. 워크스페이스 격리를 구축하십시오. 트레이스를 계측하십시오. 중요한 곳에는 사람을 루프에 남기십시오. 이렇게 하는 팀은 두 달 동안 더 느려 보이고, 두 해 동안 더 빨라 보일 것입니다. 이것을 건너뛰는 팀은 한 해의 나머지를 다른 누군가가 이미 써 둔 분류법에 자기 실패 모드를 태그하며 보낼 것입니다.
에이전트는 이제 팀원입니다. 그렇게 매니지하십시오.