AX LABS
← 블로그 에이전트 제품 설계

멀티 에이전트는 연결에서 무너진다

역할보다 계약, 검증, 운영 경계가 먼저다

AX LABS 5분 읽기

현장에서 멀티 에이전트 설계를 꺼내면 초안은 대개 그럴듯하다. 기획 에이전트, 검색 에이전트, 작성 에이전트, 검토 에이전트가 순서대로 놓인다. 회의실에서는 조직도처럼 보인다. 문제는 운영에 들어가면 조직도가 아니라 분산 시스템이 된다는 점이다.

멀티 에이전트 시스템은 에이전트를 많이 붙인다고 강해지지 않는다. 오히려 실패 지점이 늘어난다. 최근 OpenReview에 공개된 「Why Do Multi-Agent LLM Systems Fail?」도 실패를 specification, inter-agent misalignment, task verification 세 범주로 정리한다. 현장에서 보는 실패도 같은 방향이다.

첫째, 병렬화되지 않는 일을 억지로 나눈다

가장 흔한 실패는 일을 쪼개는 순간 시작된다. 모든 업무가 병렬 처리에 맞지 않는다. 앞 단계 판단이 뒷 단계 입력을 바꾸는 업무는 병렬화 대상이 아니다. 그런데 많은 팀이 역할 이름부터 나눈다.

Anthropic은 2025년 멀티 에이전트 리서치 시스템 설명에서 의존성이 많은 도메인, 모든 에이전트가 같은 context를 공유해야 하는 도메인은 현재 멀티 에이전트에 맞지 않는다고 밝혔다. 같은 글에서 멀티 에이전트 시스템은 일반 chat 대비 약 15배 토큰을 쓴다고도 했다. 비용이 늘어나는 구조다. 성능 이득이 비용과 복잡도를 이겨야 한다.

멀티 에이전트는 업무 분장이 아니라 의존성 설계다.

첫 질문은 “몇 개의 에이전트를 둘 것인가”가 아니다. “이 업무는 독립 탐색이 가능한가”다. 독립 탐색이 안 되면 단일 에이전트와 명시적 workflow가 더 낫다.

둘째, 에이전트 사이 계약이 없다

두 번째 실패는 핸드오프에서 발생한다. 앞 에이전트는 자신이 한 일을 요약해서 넘긴다. 뒤 에이전트는 그 요약을 사실, 판단, 지시가 섞인 덩어리로 받는다. 여기서 drift가 생긴다.

OpenAI Agents SDK 문서는 multi-agent orchestration을 크게 agents as tools와 handoffs로 나눈다. manager가 최종 책임을 갖는 구조와 specialist가 대화를 넘겨받는 구조는 다르다. 이 차이를 정하지 않으면 누가 최종 판단자인지 흐려진다.

Google Cloud도 2025년 12월 MCP와 A2A를 함께 다룬 글에서 production-ready agentic system에는 에이전트가 도구와 서로에게 말하는 공유 프로토콜이 필요하다고 설명했다. 표준이 중요한 이유는 유행이어서가 아니다. 핸드오프를 대화가 아니라 계약으로 만들기 위해서다.

실패 지점 겉으로 보이는 증상 필요한 설계
역할 과분해 에이전트가 중복 조사한다 병렬화 가능성부터 판단
느슨한 핸드오프 뒤 에이전트가 전제 조건을 오해한다 typed schema와 거절 조건
책임 불명확 모두 맞는 말만 하고 결론이 없다 manager, handoff, HITL 경계

계약에는 입력 schema, 출력 schema, confidence, source, rejected field, 다음 행동 권한이 들어가야 한다. 자연어 요약만 넘기는 구조는 PoC에서는 빠르지만 운영에서는 추적이 안 된다.

셋째, 종료와 검증을 사람에게 미룬다

세 번째 실패는 검증과 종료다. 멀티 에이전트는 중간 산출물이 많다. 중간 산출물이 틀렸는데 다음 에이전트가 그럴듯하게 보완하면 오류는 사라지지 않는다. 더 설득력 있게 포장된다.

Microsoft Agent Framework 문서는 agent와 workflow를 구분한다. 업무 단계가 명확하면 workflow를 쓰고, 여러 agent나 function이 조정되어야 하면 명시적 실행 경로를 둔다. 또한 2026년 문서에서 sequential, concurrent, handoff, group chat, magentic 같은 orchestration pattern과 human-in-the-loop approval을 제시한다. 핵심은 자율성을 없애는 것이 아니다. 자율성이 작동할 경계를 코드와 관측으로 고정하는 것이다.

검증은 마지막 reviewer 에이전트 하나로 해결되지 않는다. 각 경계에서 작게 해야 한다.

  • 입력이 계약을 만족하지 않으면 멈춘다.
  • 출처가 필요한 판단은 source 없이 통과시키지 않는다.
  • 실행 권한이 필요한 행동은 approval gate를 둔다.
  • 종료 조건은 에이전트의 감이 아니라 상태값으로 둔다.

멀티 에이전트 시스템은 똑똑한 에이전트 묶음이 아니다. context, memory, tool, schema, trace, approval을 묶은 harness다. AX Ops에서는 이 harness를 먼저 설계하고, 그 다음 에이전트 수를 정한다.

참고

멀티 에이전트를 검토 중이라면 에이전트 목록보다 실패 경계부터 그려야 한다. 그 작업이 AX Ops의 출발점이다. AX Ops 방법론 →