multi-agent collaboration

이 문서는 자라는 중인 질문입니다. 아직 증거를 모으고 있으며, 내용이 바뀔 수 있습니다.

한 줄로 말하면

multi-agent collaboration은 여러 AI 에이전트가 한 모델에게 모든 일을 맡기는 대신, 역할을 나누고 필요한 결과를 주고받아 하나의 과제를 끝내는 구조야.

비유로 이해하기

작은 식당 주방을 떠올려 보자. 한 사람이 주문을 받고, 재료를 손질하고, 불을 보고, 접시를 내면 단순한 메뉴는 만들 수 있어. 주문이 많아지면 각 일을 나누는 편이 빨라져. 다만 각자 자기 일만 잘한다고 식사가 완성되지는 않아. 주문 내용이 정확히 전달돼야 하고, 누군가는 접시가 맞는지 마지막으로 확인해야 해.

여러 에이전트의 협업도 같아. 조사, 계획, 실행, 검토처럼 서로 다른 일을 나눌 수 있지만, 무엇을 넘기고 누가 끝났다고 판단하는지가 빠지면 같은 일을 되풀이하거나 서로 어긋난 결과를 낼 수 있어.

정확한 정의

이 구조에는 보통 네 가지가 들어가. 먼저 일을 나누는 기준이 있어야 해. 예를 들어 한 에이전트는 자료를 찾고, 다른 에이전트는 결과를 검사하며, 조정 역할은 다음 작업을 고를 수 있어.

OpenAI Agents SDK 문서는 이 문제를 두 가지 대표 패턴으로 나눠. 하나는 agents as tools야. 이때 manager agent가 대화의 주도권을 유지하고, specialist agent를 Agent.as_tool() 형태로 불러 좁은 하위 작업을 맡겨. 최종 답을 한곳에서 합치거나 공통 검사를 한 agent가 책임져야 할 때 어울리는 방식이야.¹

다른 하나는 handoff야. 이때 triage agent는 specialist에게 일을 넘기고, specialist가 그 다음 대화의 active agent가 돼. specialist가 직접 응답해야 하거나, 역할별 지시문을 선명하게 갈아 끼워야 하거나, 라우팅 자체가 업무의 일부일 때 쓰기 쉬워.¹

다음은 전달물의 경계야. 다음 담당자에게는 결론만 넘길지, 근거와 미해결 질문까지 함께 넘길지 정해야 해. 컨텍스트 엔지니어링은 이 전달물이 다음 판단에 필요한 만큼만 남도록 돕는 관점이야.

마지막은 합치는 과정이야. 여러 결과가 서로 맞는지, 빠진 조건은 없는지, 어느 결과를 최종 답으로 쓸지 확인해야 해. 이 단계가 없다면 역할 분담은 협업이라기보다 독립된 답변을 여러 개 만드는 일에 가까워져.

flowchart TD
    A["공동 목표"] --> B["역할과 작업 분할"]
    B --> C["담당 에이전트의 작업"]
    C --> D["결과·근거·미해결 질문 전달"]
    D --> E["결과 조정과 검토"]
    E --> F{"목표를 만족했나?"}
    F -->|"아니오"| B
    F -->|"예"| G["최종 결과"]

왜 중요한가

한 에이전트가 긴 일을 반복해서 처리하는 구조는 agent loop로 설명할 수 있어. 여러 에이전트가 함께 움직이면, 반복 자체보다도 누가 어떤 판단을 맡고 어떤 정보가 다음 사람에게 넘어가는가가 중요한 문제가 돼.

역할을 나누면 각 에이전트에 필요한 도구와 정보의 범위를 줄일 수 있어. 반대로 전달이 부정확하면 한쪽의 잘못된 가정이 다음 단계로 퍼질 수 있어. 그래서 협업 구조는 속도를 높이는 방법이면서, 검토 지점을 어디에 둘지 정하는 방법이기도 해.

OpenAI 문서는 실행 흐름을 LLM이 고르게 둘 수도 있고, 코드가 정해진 순서로 고르게 할 수도 있다고 설명해. LLM에게 맡기면 열린 과제에서 계획과 위임을 유연하게 고를 수 있지만, 코드로 짜면 속도, 비용, 성능을 더 예측하기 쉬워.¹ 그래서 multi-agent collaboration은 “에이전트를 몇 개 붙일까”보다 “누가 흐름을 고르고, 누가 결과를 합치며, 어디까지 코드가 강제할까”의 문제에 가까워.

실제 예시

긴 문서를 검토하는 일을 생각해 보자. 첫 에이전트는 문서에서 핵심 조항을 찾고, 둘째는 조항끼리 충돌하는 부분을 확인하며, 셋째는 독자가 이해할 순서로 정리할 수 있어. 조정 역할은 각 결과에 원문 위치와 불확실한 부분이 남아 있는지 보고, 더 확인할 일이 있으면 해당 담당자에게 돌려보낸다.

코드 작업도 비슷해. 한 에이전트가 수정 범위를 좁히고, 다른 에이전트가 테스트 결과를 읽으며, 마지막 에이전트가 요구사항과 결과를 대조할 수 있어. 하지만 권한이 넓은 도구를 여러 역할에 똑같이 주는 것은 협업의 필수 조건이 아니야. 역할에 맞는 범위만 주고, 중요한 행동은 따로 확인하는 편이 자연스러워.

OpenAI Agents SDK식으로 말하면, 최종 결과를 한 manager가 책임져야 할 때는 specialist를 도구처럼 부르는 편이 맞아. 반대로 환불, 청구, 기술지원처럼 사용자의 다음 대화를 특정 specialist가 직접 이어가야 한다면 handoff가 더 자연스러워. handoff는 내부적으로 LLM에게 보이는 도구처럼 표현되지만, 호출 뒤에는 받는 agent가 대화의 다음 구간을 맡는다는 점이 달라.²

헷갈리지 말아야 할 점

• 에이전트 수가 많다고 협업이 잘되는 것은 아니야. 나눌 일이 없는데 역할만 늘리면 전달과 조정 비용이 커져.
• 역할 분담은 책임 분담과 같지 않아. 최종 결과를 누가 확인하고 사람에게 어떤 상태로 넘길지는 따로 정해야 해.
• 공유 정보가 많을수록 좋은 것도 아니야. 각 담당자가 같은 긴 기록을 모두 읽으면 필요한 조건이 묻힐 수 있어. 필요한 맥락을 고르는 문제가 남아.
• 독립적인 답변 여러 개는 협업과 다를 수 있어. 서로의 결과를 반영해 다음 행동이나 최종 결과가 바뀔 때 협업 구조가 생겨.
• agent-as-tool과 handoff는 같은 위임이 아니야. 앞의 방식은 manager가 결과를 받아 합치는 구조고, 뒤의 방식은 specialist가 다음 대화 구간을 맡는 구조야.
• handoff에 붙는 입력은 destination 선택이 아니야. OpenAI 문서는 input_type을 이유, 언어, 우선순위, 요약 같은 작은 metadata를 받는 장치로 설명해. 어느 specialist로 갈지 고르는 기능은 아니고, 받을 agent가 보는 대화 기록을 바꾸려면 별도의 input filter나 실행 설정을 써야 해.²

관련 문서

• 한 에이전트가 결과를 보고 다음 행동을 고르는 구조: agent loop
• 다음 판단에 무엇을 보여 줄지 설계하는 방법: 컨텍스트 엔지니어링
• 도구·권한·검증을 묶어 설계하는 작업 흐름: agentic workflow
• OpenAI가 이 패턴을 SDK primitive로 묶은 사례: OpenAI Agents SDK

남은 질문들

• 역할을 나눌 때 결과, 근거, 불확실성을 어떤 형식으로 넘겨야 검토가 쉬워질까?
• 조정 역할은 언제 다른 에이전트에게 일을 넘기고, 언제 사람에게 질문해야 할까?
• 여러 에이전트가 같은 도구나 자료를 쓸 때 충돌과 잘못된 정보 전파를 어떻게 측정할 수 있을까?

각주

1. OpenAI, 「Agent orchestration」(2026-07-13 캡처) OpenAI Agents SDK 문서. ↩︎ ↩︎² ↩︎³

2. OpenAI, 「Handoffs」(2026-07-13 캡처) OpenAI Agents SDK 문서. ↩︎ ↩︎²