단일 에이전트 vs 멀티에이전트: 언제 복잡성을 감수할 가치가 있나?

30초 답변

대부분의 기업용 AI 업무는 하나의 에이전트에 제한된 도구와 명확한 정책을 주는 구조로 시작해야 한다. 멀티에이전트는 조사 방향처럼 서로 독립적인 하위 작업을 병렬로 탐색해야 하거나, 한 에이전트가 감당하기 어려운 도구·지침·컨텍스트를 전문 영역별로 격리할 때 가치가 있다. 역할 이름을 여러 개 붙이는 것만으로 품질이 오르지는 않으며, 라우팅 오류, 상태 전달, 비용, 지연, 평가와 보안 경계가 늘어난 만큼 단일 에이전트 기준선보다 실제 업무 완료율이 좋아졌을 때만 채택해야 한다.

이 글의 핵심

• 단일 에이전트가 기본값이다. 프롬프트와 도구 설명을 정리해도 해결되지 않는 구체적 실패가 있을 때만 분리한다.
• 멀티에이전트의 가장 강한 근거는 역할극이 아니라 병렬성, 컨텍스트 격리, 도구 소유권, 독립 평가다.
• 순차 의존성이 높고 모든 작업자가 같은 상태를 봐야 하면 멀티에이전트의 조정 비용이 이득을 넘기 쉽다.
• 사용자는 내부 에이전트 수보다 한 곳에서 진행 상태, 책임 주체, 승인 요청과 최종 결과를 이해할 수 있어야 한다.
• 전환 판단은 데모 인상보다 같은 평가셋의 품질, 지연, 토큰·도구 비용, 실패 복구 시간으로 한다.

먼저 비교할 대상부터 정확히 정한다

단일 에이전트

하나의 실행 주체가 사용자 목표, 대화 상태와 도구 집합을 받아 계획-행동-관찰 루프를 수행한다. 도구가 여러 개여도 최종 제어권이 한 에이전트에 있으면 단일 구조다. 내부 코드를 분리하거나 모델을 단계별로 바꾸는 것만으로 멀티에이전트가 되는 것은 아니다.

멀티에이전트

서로 다른 지침, 도구 또는 컨텍스트를 가진 둘 이상의 에이전트가 위임, 병렬 작업, 토론 또는 핸드오프로 목표를 수행한다. 각 에이전트가 모델 호출과 판단 루프를 갖기 때문에 조정 대상도 늘어난다.

기존 AI Agent는 어떻게 생각하고 행동하는가가 한 에이전트의 루프를 설명한다면, 이 글의 질문은 그 루프를 여러 개로 나누는 것이 언제 정당한가다.

단일 에이전트가 더 적합한 경우

OpenAI의 에이전트 구축 가이드는 먼저 단일 에이전트의 역량을 최대화하라고 권한다. 도구를 점진적으로 추가하면 평가와 유지보수의 복잡성을 조기에 키우지 않고도 많은 업무를 처리할 수 있다는 이유다.

다음 조건에서는 단일 구조를 유지할 근거가 강하다.

• 작업 단계가 순차적이고 앞 단계 결과가 다음 단계의 필수 입력이다.
• 모든 단계가 같은 고객, 문서 또는 코드 상태를 자세히 공유해야 한다.
• 도구 수가 적고 이름·입력·출력이 명확히 구분된다.
• 한 팀이 전체 정책과 도구를 함께 소유한다.
• 짧은 응답 시간과 낮은 작업당 비용이 중요하다.
• 최종 결과와 실행 경로를 한 흐름에서 감사해야 한다.
• 실패했을 때 한 지점에서 재개하는 것이 중요하다.

예를 들어 고객 문의를 분류하고 계정 정보를 조회한 뒤 정해진 정책으로 답변 초안을 만드는 업무는 단일 에이전트와 결정론적 검증으로 충분할 수 있다. “분류 에이전트”, “조회 에이전트”, “작성 에이전트”로 나누면 각 단계의 모델 호출과 전달 오류만 늘 수 있다. 분류가 안정적인 구조화 출력이라면 아예 에이전트가 아니라 고정 워크플로 단계가 더 명확하다. 이 경계는 AI 에이전트 vs 워크플로 자동화에서 먼저 판단한다.

멀티에이전트를 검토할 만한 네 가지 신호

1. 독립적인 하위 문제를 실제로 병렬화할 수 있다

시장 조사에서 기술, 규제, 경쟁사, 사용자 반응을 서로 독립적으로 수집한 뒤 합치는 업무는 병렬 탐색의 이점이 있다. 반대로 앞 단계가 끝나야 다음 단계가 가능한 결재 업무는 여러 에이전트로 나눠도 병렬성이 생기지 않는다.

병렬화 가능성을 확인하려면 “각 작업자가 다른 작업자의 상세 중간 결과 없이 시작할 수 있는가?”를 묻는다. 그렇지 않으면 조정 메시지가 늘고 컨텍스트 일관성이 떨어질 수 있다.

2. 도구와 지침이 너무 많아 선택 오류가 반복된다

한 에이전트가 영업, 재무, 개발 도구를 모두 보고 비슷한 이름의 기능을 자주 잘못 고른다면 영역별로 도구를 격리할 수 있다. 단, 먼저 도구 이름·설명·스키마의 중복을 제거하고 라우팅 규칙을 개선해야 한다. 나쁜 도구 설계를 여러 에이전트로 나누면 문제 위치만 이동한다.

3. 하위 작업이 별도의 큰 컨텍스트를 소비한다

법률 원문 검토와 기술 로그 분석처럼 각 하위 작업이 많은 문서와 도구 결과를 사용하지만 최종 조정자에게는 요약된 결론만 필요할 수 있다. Anthropic의 컨텍스트 엔지니어링 글은 하위 에이전트가 각자의 깨끗한 컨텍스트에서 깊이 탐색하고 주 에이전트에는 압축된 결과를 돌려주는 패턴을 설명한다.

4. 전문 역할별로 별도 평가와 권한이 필요하다

재무 도구를 쓰는 에이전트와 공개 웹을 조사하는 에이전트가 다른 데이터 정책, 모델, 평가셋과 운영팀을 가져야 한다면 경계를 분리할 이유가 있다. 다만 “전문가 페르소나”가 아니라 실제 도구 권한, 지식 범위, 출력 계약과 책임자가 달라야 한다.

멀티에이전트가 맞지 않는 신호

• 한 에이전트의 결과를 다른 에이전트가 계속 수정하며 왕복해야 한다.
• 모든 에이전트가 동일한 긴 대화와 업무 상태를 복제해야 한다.
• 짧고 저가치인 요청이 대부분이라 추가 모델 호출을 회수하기 어렵다.
• 정답이 구조화되어 있어 일반 코드로 분해와 검증을 할 수 있다.
• 하위 결과의 진위를 확인할 독립 평가 기준이 없다.
• 각 에이전트에 필요한 권한을 최소화할 수 없고 모두 같은 관리자 권한을 가진다.
• 사용자가 여러 역할의 상충된 답을 직접 조정해야 한다.

멀티에이전트 연구 결과를 일반화할 때도 주의해야 한다. Anthropic의 멀티에이전트 리서치 시스템 사례는 해당 내부 평가에서 단일 구성보다 높은 연구 성능을 보고했지만, 동시에 자사 측정에서 멀티에이전트가 일반 채팅보다 훨씬 많은 토큰을 사용했고 공유 컨텍스트와 의존성이 많은 영역은 잘 맞지 않는다고 설명한다. 이 수치는 특정 모델·리서치 과제·시스템의 결과이지 모든 기업 업무의 예상 효과가 아니다.

대표 아키텍처 3가지와 선택 기준

패턴 A. 관리자-전문가

하나의 관리자 에이전트가 사용자와 대화하고, 전문 에이전트를 도구처럼 호출한 뒤 결과를 종합한다.

적합한 경우:

• 사용자 경험을 하나의 대화로 유지해야 한다.
• 하위 작업이 독립적이고 결과를 구조화할 수 있다.
• 최종 책임과 승인 요청을 관리자에 모으고 싶다.

주의할 점:

• 관리자가 하위 결과를 무비판적으로 신뢰하지 않도록 출처와 품질 신호를 받는다.
• 전문가 입력에 필요한 정보만 보내고 전체 대화를 자동 공유하지 않는다.
• 전문가가 고위험 도구를 요청하면 최상위 작업의 승인 경계로 올린다.

패턴 B. 라우터-전담 에이전트

초기 라우터가 요청을 한 전문 에이전트에 넘기고, 이후 해당 에이전트가 사용자를 담당한다. 고객지원에서 주문, 환불, 기술지원의 정책과 도구가 뚜렷이 나뉠 때 후보가 된다.

적합한 경우:

• 요청이 대체로 한 전문 영역에 속한다.
• 각 영역의 프롬프트와 도구가 독립적이다.
• 핸드오프 이후 주 담당자를 명확히 할 수 있다.

주의할 점:

• 오분류 시 사용자가 처음부터 설명하지 않도록 필요한 대화만 안전하게 전달한다.
• 순환 핸드오프 횟수를 제한한다.
• OpenAI Agents SDK의 Handoffs 문서가 보여주듯 핸드오프 시 전달할 이력을 필터링할 수 있으므로, 민감정보와 불필요한 도구 결과를 그대로 넘기지 않는다.

패턴 C. 병렬 작업자-결과 합성

조정자가 작업을 여러 독립 하위 질문으로 나누고 작업자들이 동시에 수행한 뒤 합성기가 중복·충돌·누락을 정리한다.

적합한 경우:

• 탐색 범위가 넓고 정답 경로를 사전에 알기 어렵다.
• 하위 과제가 서로 독립적이다.
• 빠른 첫 답보다 포괄성과 출처가 중요하다.

주의할 점:

• 작업자 수, 총 도구 호출, 총 토큰과 시간을 상한으로 둔다.
• 같은 하위 문제를 중복 탐색하지 않도록 계획과 소유권을 기록한다.
• 합성 단계가 새로운 주장을 만들지 않고 하위 근거와 연결되게 한다.

에이전트끼리 자유롭게 토론하는 메시 네트워크는 특별한 근거가 없으면 피한다. 누가 종료를 결정하고, 어떤 메시지가 신뢰 가능한 상태이며, 비용과 권한을 어디서 제한할지 불명확해지기 쉽다.

전환 전에 수행할 평가 절차

1. 단일 에이전트 기준선을 고정한다

실제 요청과 실패 사례가 포함된 평가셋을 만든다. 정답뿐 아니라 허용된 도구, 금지 행동, 필수 근거와 최대 단계도 정의한다. 가능한 한 가장 단순한 단일 구조의 품질·지연·비용을 기록한다.

2. 실패를 원인별로 분류한다

• 지침 충돌
• 잘못된 도구 선택
• 컨텍스트 부족 또는 과잉
• 순차 계획 실패
• 넓은 탐색의 누락
• 도구 자체 오류
• 평가 기준 또는 데이터 문제

도구 오류와 데이터 품질 문제는 에이전트를 늘려도 해결되지 않는다. 넓은 병렬 탐색 누락이나 영역 간 도구 혼선처럼 분리와 직접 연결되는 실패만 멀티에이전트 가설로 삼는다.

3. 가장 작은 분리 실험을 한다

전체를 역할 여러 개로 바꾸지 말고, 예를 들어 웹 조사만 별도 작업자로 분리한다. 작업자 입력·출력을 JSON Schema 같은 계약으로 제한하고, 사용자에게 직접 행동할 권한은 주지 않는다.

4. 품질과 운영 비용을 함께 비교한다

품질 개선이 통계적으로나 업무적으로 의미 있는지 확인하고, 고가치 요청에만 멀티 경로를 라우팅하는 방안도 검토한다.

상태·메모리·권한을 나누는 방법

멀티에이전트에서 공유해야 할 것은 “모든 대화”가 아니라 최소 공통 작업 상태다.

• 최상위 작업에는 목표, 요청자, 예산, 현재 계획과 완료 조건을 둔다.
• 하위 작업에는 제한된 입력, 허용 도구, 시간·비용 한도와 출력 스키마를 둔다.
• 장기 사용자 기억은 필요한 에이전트에만 정책 필터 후 제공한다.
• 하위 작업 결과에는 출처, 생성 시각, 사용한 도구, 불확실성과 오류를 포함한다.
• 에이전트별 서비스 계정과 도구 권한을 분리하고, 위임이 권한 상승이 되지 않게 한다.

세션 이력, 업무 상태와 장기 기억의 차이는 AI 에이전트 메모리 설계에서 자세히 설명한다.

사용자 경험·실패 시나리오

실패 1: 사용자가 어느 에이전트에게 말해야 할지 결정한다

내부 조직도처럼 여러 봇을 먼저 고르게 하면 사용자가 시스템의 라우팅 문제를 떠안는다. 특별한 전문 채널이 필요한 경우가 아니라면 하나의 진입점을 제공하고, 자동 라우팅 결과와 변경 방법을 보여준다.

실패 2: 핸드오프 때 같은 설명을 반복한다

새 에이전트에 전체 대화를 넘기는 것도 위험하지만 아무것도 넘기지 않으면 사용자가 다시 설명해야 한다. 목표, 확인된 사실, 미해결 질문과 동의된 범위만 구조화해 전달하고, 사용자가 전송 내용을 확인할 수 있게 한다.

실패 3: 에이전트들이 서로 작업을 떠넘긴다

라우팅 기준이 겹치면 A가 B로, B가 A로 되돌리는 루프가 생긴다. 한 요청의 최대 핸드오프 수를 제한하고, 경계 사례는 중앙 분류기 또는 사람에게 보낸다.

실패 4: 병렬 결과가 서로 모순된다

합성기가 다수결로 고르면 신뢰할 수 없다. 출처의 권위, 최신성, 직접성에 따른 충돌 규칙을 두고 해결되지 않으면 양쪽 근거와 확인할 질문을 사용자에게 보여준다.

실패 5: 한 하위 에이전트 실패가 전체를 지운다

작업자별 상태와 결과를 저장해 성공한 작업은 유지한다. 최종 화면에는 완료, 실패, 시간 초과, 생략을 구분하고 부분 결과로 계속할지 다시 시도할지 선택하게 한다.

실패 6: 내부 대화가 많아졌지만 결과는 느리고 불투명하다

“에이전트 5명이 협업 중”이라는 연출보다 실제 진행 단계, 검색 범위, 남은 시간, 취소와 부분 결과가 중요하다. 내부 사고 과정을 그대로 노출하지 말고 사용자에게 의미 있는 행동과 근거를 요약한다.

실무 체크리스트

• 단일 에이전트와 고정 워크플로 기준선을 먼저 측정했다.
• 멀티에이전트가 해결할 구체적 실패 유형을 정의했다.
• 하위 작업이 다른 작업의 상세 상태 없이 병렬 실행 가능한지 확인했다.
• 프롬프트·도구 정리만으로 해결할 수 없는지 먼저 검증했다.
• 각 에이전트의 입력, 출력, 허용 도구, 예산과 종료 조건이 명확하다.
• 관리자, 라우터, 병렬 작업자 중 최소한의 패턴을 선택했다.
• 전체 대화 대신 최소 작업 상태만 전달한다.
• 사용자·테넌트·민감 데이터와 장기 기억의 전달 범위를 제한한다.
• 하위 에이전트의 권한이 최상위 요청자의 권한을 넘지 않는다.
• 최대 에이전트 수, 핸드오프, 토큰, 도구 호출, 시간 상한이 있다.
• 부분 성공을 저장하고 실패한 하위 작업만 재실행할 수 있다.
• 승인 요청이 최상위 사용자 작업과 연결되어 한 화면에 나타난다.
• 단일·멀티 구성을 같은 평가셋으로 품질, 비용, p95 지연, 복구 시간까지 비교했다.
• 사용자에게 하나의 진입점, 진행 상태, 취소, 부분 결과를 제공한다.

자주 묻는 질문

Q1. 업무 역할이 세 개면 에이전트도 세 개가 필요한가?

아니다. 조직의 역할 수는 소프트웨어 에이전트 수와 같지 않다. 지침과 도구가 충분히 명확하고 컨텍스트를 공유해야 한다면 하나의 에이전트가 역할 변수를 받아 처리할 수 있다. 권한·데이터·평가·도구 소유권이 실제로 분리되고 그 분리가 품질을 개선할 때 별도 에이전트를 검토한다.

Q2. 멀티에이전트는 항상 단일 에이전트보다 정확한가?

아니다. 넓고 독립적인 병렬 탐색에서는 이점이 있을 수 있지만, 라우팅·전달·합성 단계가 새로운 오류를 만든다. 순차 의존성이 높은 업무에서는 공유 상태 손실이 더 클 수 있다. 특정 모델과 자체 평가셋으로 단일 기준선과 직접 비교해야 한다.

Q3. 여러 에이전트에 서로 다른 모델을 써도 되는가?

가능하다. 분류나 단순 추출에는 작고 빠른 모델, 복잡한 합성에는 더 강한 모델을 쓰는 식이다. 다만 모델별 출력 계약, 안전 정책, 버전과 평가 결과를 추적해야 하며, 모델 교체가 하위 결과의 형식과 전체 라우팅에 미치는 영향을 회귀 테스트해야 한다.

근거 자료

• OpenAI, A practical guide to building agents — 단일 에이전트 우선 원칙과 관리자·분산 핸드오프 오케스트레이션 패턴.
• OpenAI Agents SDK, Handoffs — 에이전트 간 제어 이전과 전달 이력 필터링, 가드레일 적용 범위에 관한 구현 문서.
• Anthropic, Building effective agents — 단순하고 조합 가능한 패턴 우선 원칙과 워크플로·에이전트 설계 패턴.
• Anthropic, How we built our multi-agent research system — 병렬 리서치 멀티에이전트의 이점, 토큰 비용, 조정·평가·운영 실패에 대한 실제 시스템 사례. 수치는 해당 내부 구성의 결과로만 해석했다.
• Anthropic, Effective context engineering for AI agents — 하위 에이전트를 통한 컨텍스트 격리와 요약 전달의 설계 근거.