조직도를 그대로 옮기면 생기는 일

멀티에이전트 시스템이 실패하는 원인은 모델이나 프롬프트에만 있지 않다. 에이전트의 경계를 어디에 그었는지가 더 중요할 때가 많다.

마케팅, 영업, 고객지원처럼 조직의 팀 구성을 그대로 에이전트로 옮겨 보자. 업무를 잘 나눈 듯하지만 실제로는 부서 사이의 승인 절차와 정보 단절까지 시스템에 복제된다.

멀티에이전트에서는 에이전트가 바뀔 때마다 맥락을 요약하고 복원해야 한다. 사람은 빠진 설명을 대화로 보충하지만 에이전트는 전달받은 내용만으로 판단한다. 모호한 인계가 다음 작업의 전제가 되면 오류와 재시도가 늘어난다.

NeurIPS 2025에 채택된 MAST 연구는 7개 멀티에이전트 프레임워크의 실행 기록 1,642건을 분석했다. 연구진이 찾은 주요 실패 원인은 모델의 추론 능력보다 역할 정의, 에이전트 간 소통, 검증과 종료 조건에 가까웠다.

컨웨이 법칙이 말하듯 시스템은 이를 만든 조직의 소통 구조를 닮는다. 주문 예외 처리를 결제팀, 물류팀, 고객지원팀 에이전트에 차례로 넘기면 매번 담당 범위와 소유권을 다시 해석해야 한다. 정작 필요한 일은 결제 확인, 재고 잠금 해제, 고객 통지뿐인데 인계와 재확인에 더 많은 비용이 든다.

따라서 먼저 실제 작업 흐름을 그려야 한다. 어떤 일은 병렬로 처리할 수 있는지, 어떤 정보가 서로 의존하는지, 어디서 결과를 검증할지 정한 뒤 에이전트 수를 결정해야 한다. 조직 경계는 권한과 감사, 온콜을 나누는 데 쓰고 과제 경계는 실행 흐름을 나누는 데 쓴다.

병렬화 전에 의존성부터 보라

에이전트 사이의 요약은 단순한 압축이 아니다. 무엇을 남기고 뺄지 고르는 과정에서 제약, 근거, 불확실성이 조금씩 사라진다. 다음 에이전트는 무엇이 빠졌는지 알 수 없기 때문에 그 요약을 완전한 지시로 받아들인다. 인계가 반복될수록 최초 요청과 최종 결과 사이의 거리는 벌어진다.

AI 코딩 스타트업 Cognition은 게임을 여러 에이전트가 나눠 만드는 사례로 이 문제를 설명했다. 배경과 캐릭터를 따로 맡기면 각 에이전트가 스타일과 동작을 제각각 결정한다. 원래 요청을 모두 공유해도 다른 에이전트가 작업 중 내린 세부 판단까지 알 수는 없다. 그래서 상호 의존성이 큰 작업을 병렬로 쓰면 결과의 일관성이 깨지기 쉽다.

반대로 독립적인 자료 조사는 병렬 처리와 잘 맞는다. Anthropic의 리서치 시스템은 서브에이전트의 긴 결과를 대화창에 계속 복사하지 않는다. 결과를 외부 저장소에 남기고 리드 에이전트에는 참조만 전달한다. 구조화된 아티팩트를 직접 참조하면 정보 손실과 토큰 비용을 함께 줄일 수 있다.

멀티에이전트가 항상 더 뛰어난 것도 아니다. Google Research의 비교 실험에서는 싱글 에이전트의 정확도가 약 45%를 넘으면 에이전트를 추가할 때 얻는 이익이 줄거나 오히려 손해로 바뀌는 경향이 나타났다. 분해하기 쉬운 금융 추론에서는 중앙형 멀티에이전트가 효과적이었지만 제약을 순서대로 추적해야 하는 과제에서는 모든 멀티에이전트 구조가 싱글 에이전트보다 낮은 성능을 냈다. 통신 비용은 구조에 따라 싱글 에이전트의 몇 배까지 늘었다.

에이전트 수보다 과제의 성격이 결과를 좌우한다. 서로 영향을 주지 않는 탐색은 병렬화할 수 있지만 공유 상태를 계속 바꾸는 코딩이나 운영 작업은 한 주체가 이어서 처리하는 편이 낫다. 다른 에이전트가 필요하다면 검색과 검토를 맡기고 최종 변경은 한곳에서 반영하는 방식이 안전하다.

인계가 꼭 필요하다면 짧은 채팅 요약만 넘겨서는 안 된다. 결정 사항, 제약, 근거, 불확실성, 검증 기준을 일정한 형식의 문서나 데이터로 남겨야 한다. 메시지가 아니라 검증 가능한 산출물이 핸드오프의 기본 단위다.

PM 에이전트는 단일 장애점인가

조직도를 본뜬 시스템은 흔히 중앙의 PM 에이전트가 일을 나누고 여러 전문 에이전트가 답을 돌려주는 스타 구조가 된다. 모든 에이전트가 중앙 허브의 요약을 공통 전제로 삼는 구조가 문제다. 허브가 요청을 잘못 분류하거나 중요한 조건을 빼먹으면 오류가 전체로 퍼진다.

2026년 오류 캐스케이드 연구에서는 LangGraph와 CrewAI의 스타 구조 모두 허브에 오류를 넣었을 때 전체 실패율이 100%에 이르렀다. 반면 리프 노드에 넣은 오류의 영향은 훨씬 작았다.

그렇다고 모든 에이전트를 대등하게 연결하면 문제가 해결되는 것은 아니다. 에이전트들이 서로의 중간 결론을 인용하면 먼저 채택된 오류가 이후 판단을 묶는다. 메시지는 많아지고 최종 결정의 책임자는 불분명해진다. 장애가 났을 때 어느 메시지가 원인이었는지 추적하기도 어렵다.

조직의 지시를 요약해 널리 뿌리는 허브는 단일 장애점이 된다. 반면 출처를 확인하고 산출물을 검증하며 종료 조건을 판단하는 허브는 오류의 확산을 막는다. 라우팅과 검증은 같은 기능이 아니다.

운영 평가도 데모 성공률만 봐서는 부족하다. 허브와 리프에 같은 오류를 각각 넣어 최종 결과가 얼마나 오염되는지 비교해야 한다. 재시도가 중복 작업을 만드는지, 메시지와 도구 호출을 끝까지 추적할 수 있는지도 확인해야 한다. 복잡한 메시 구조보다 얇고 명시적인 작업 그래프와 검증 루프가 원인 분석에 유리하다.

프로토콜보다 먼저 정할 것들

에이전트 경계는 조직도가 아니라 과제 그래프에서 출발해야 한다. 경계를 정할 때는 다음을 본다.

  • 서로의 작업 결과 없이 병렬로 진행할 수 있는지
  • 스타일이나 예외 처리 같은 결정을 한 주체가 계속 유지해야 하는지
  • 결과를 스키마, 테스트, 출처로 검증할 수 있는지
  • 보안, 법무, 데이터 주권 때문에 맥락을 분리해야 하는지

독립 자료를 넓게 찾는 리서치는 병렬 탐색에 적합하다. 여러 에이전트가 각자 조사하고 리드 에이전트가 출처를 확인해 합치면 된다. 반면 통합 코드는 한 변경이 다른 모듈의 설계와 테스트에 영향을 준다. 이런 작업은 탐색과 검토만 병렬화하고 실제 수정과 커밋은 한 주체가 맡는 편이 낫다.

실전에서는 다음 구조가 가장 단순하다. 오케스트레이터가 과제를 명확히 나누고 리프 에이전트는 서로 독립된 구간만 처리한다. 결과는 검증 단계를 거치며 최종 반영은 하나의 쓰기 주체가 맡는다. 즉, 읽기는 병렬화하고 쓰기는 직렬화한다.

노드를 과제에 맞게 바꿨다면 운영 책임도 함께 옮겨야 한다. 데이터 소유권, 도구 권한, 장애 대응, 재시도 예산, 감사 로그의 담당자를 새 경계에 맞춰야 한다. 이 책임을 명확히 나눌 수 없다면 에이전트를 더 만드는 대신 싱글 에이전트를 유지하는 편이 낫다.

A2A나 MCP 같은 프로토콜은 그다음 문제다. MCP는 에이전트를 도구와 데이터에 연결하고 A2A는 서로 다른 에이전트의 협업 방식을 표준화한다. 두 프로토콜은 서로 보완하는 관계지만 잘못된 요약이나 모호한 결정 권한까지 해결해 주지는 않는다. 프로토콜을 고르기 전에 핸드오프 형식, 추적 기록, 안전한 재시도, 부분 실패 처리, 최소 권한부터 정해야 한다.

도입은 고정된 예산으로 싱글 에이전트의 성능을 측정하는 데서 시작한다. 성능이 부족하면 먼저 도구와 컨텍스트, 검증 절차를 보강한다. 그래도 분해가 필요할 때만 에이전트를 늘린다. 노드 이름은 ‘마케팅팀’이나 ‘개발팀’이 아니라 ‘자료 조사’, ‘출처 검증’, ‘코드 반영’처럼 과제와 산출물이 드러나게 붙인다.

멀티에이전트의 목표는 조직을 흉내 내는 것이 아니다. 작업을 더 빠르고 정확하게 끝내는 것이다. 과제 그래프가 실행 흐름을 정하고 조직 그래프는 그 위에서 권한과 책임을 제한해야 한다.

#research