AI끼리 주고받은 요약은 증거가 아니다: 멀티 에이전트 핸드오프의 함정

 

멀티 에이전트 핸드오프, 요약 한 줄에서 업무가 바뀐다

 

멀티 에이전트 핸드오프는 한 AI 에이전트가 다른 에이전트에게 작업이나 대화의 제어권을 넘기는 과정이다. 고객 지원에서는 접수 담당 AI가 환불 담당 AI에게 문의를 넘기고, 개발 업무에서는 조사 담당 AI가 구현 담당 AI에게 확인 결과를 전달한다. 이때 잘 쓴 요약만 있으면 일이 자연스럽게 이어질 것처럼 보인다. 하지만 요약에 조건과 출처가 빠지면 다음 에이전트는 다른 업무를 시작할 수 있다.

 

가령 사용자가 “실제 발송은 하지 말고 고객 안내문 초안만 작성해 줘”라고 요청했다고 하자. 첫 번째 에이전트가 이를 “고객 안내문 작성 요청”으로 전달하면 금지 조건이 사라진다. 다음 에이전트가 발송 도구를 갖고 있다면 단순한 문장 축약이 실행 범위의 확대로 이어질 수 있다. 문장이 자연스럽다는 사실과 인수인계가 정확하다는 사실은 다르다.

 

이 글은 멀티 에이전트를 몇 개 배치할지보다, 에이전트 사이에서 무엇을 보존하고 누가 실행을 책임질지에 집중한다. 핸드오프와 도구 호출의 차이, OpenAI Agents SDK의 입력과 기록 전달 방식, 권한 검사, 상태 버전, 실패 복구와 평가 기준을 살펴본다. Anthropic과 Cognition의 원자료, SDK 공식 문서, 국내 기술 블로그를 직접 확인했다.

 

아래 업무 사례와 메시지 구조는 설계 원리를 설명하기 위한 가상 예시다. 핵심은 간단하다. “검토 완료”라는 보고는 검토 결과의 위치와 적용 버전을 대신하지 못한다. “승인받음”이라는 요약도 승인된 대상과 범위가 확인되기 전에는 실행 권한이 될 수 없다. 협업하는 AI를 믿으려면 전달된 결론에서 원래 근거까지 돌아갈 길이 있어야 한다.

핸드오프와 전문가 호출은 제어권부터 다르다

 

모델을 여러 번 부르는 프로그램이 모두 같은 멀티 에이전트 구조인 것은 아니다. 정해진 순서대로 분류, 요약, 번역을 실행하는 파이프라인과 각 에이전트가 다음 행동을 판단하는 시스템은 다르다. 특히 전문가에게 질문하는 것과 대화를 통째로 넘기는 것은 사용자 경험과 책임 구조가 달라진다.

 

전문가를 도구처럼 호출하는 방식에서는 주 에이전트가 작업을 유지한다. 예를 들어 정책 분석 담당에게 “이 조항의 적용 조건을 확인해 달라”고 요청한 뒤 결과를 받아 사용자에게 답한다. 전문가는 하위 문제를 해결하고, 최종 응답과 다음 행동을 정하는 주체는 그대로 남는다. 외부 조사나 계산처럼 결과를 모아야 하는 업무에 적합할 수 있다.

 

핸드오프에서는 새로운 담당자가 대화를 이어받는다. 일반 상담에서 환불 상담으로 담당이 바뀌는 상황이 대표적이다. 무엇을 전달했는지만큼 언제부터 누가 사용자에게 답하고 도구를 실행하는지도 중요하다. 새 담당자에게 제어권을 넘겼는데 이전 담당자도 동시에 실행을 계속하면 이중 안내나 중복 처리가 생길 수 있다.

 

OpenAI Agents SDK 공식 문서는 핸드오프를 모델이 선택할 수 있는 도구로 표현한다. 또한 대화 제어권을 옮기지 않고 구조화된 질문을 전문가에게 전달하려면 Agent.as_tool 같은 방식을 검토하도록 구분한다. 이름이 비슷한 기능을 묶어 생각하기보다 현재 업무에 필요한 것이 자문인지, 책임 있는 담당 전환인지 먼저 결정해야 한다.

Anthropic과 Cognition의 다른 주장은 같은 경계를 가리킨다

 

Anthropic은 2025년 6월 공개한 리서치 시스템 사례에서 여러 독립적인 조사 방향을 병렬로 탐색하는 구조의 장점을 설명했다. 각 하위 에이전트가 자료를 찾고 중요한 내용을 압축해 주 에이전트에게 보내는 방식이다. 조사할 대상이 넓고 서로 독립적인 탐색이 가능할 때 별도 컨텍스트를 활용할 여지가 크다.

 

해당 글은 Claude Opus 4가 주도하고 Sonnet 4 하위 에이전트가 참여한 구성이 단일 Opus 4보다 내부 리서치 평가에서 90.2% 높은 성과를 보였다고 보고했다. 이는 그 평가와 구성에 대한 상대적인 결과다. 모든 업무의 정확도가 90.2%포인트 오른다는 의미도, 현재 어떤 모델 조합에서나 같은 효과가 나온다는 의미도 아니다.

 

반면 Cognition의 2025년 6월 글은 여러 에이전트가 맥락을 충분히 공유하지 못한 채 각자 결정을 내리는 위험을 강조했다. 같은 게임을 만들더라도 한 에이전트가 정한 배경 스타일과 다른 에이전트가 정한 캐릭터 스타일이 어긋날 수 있다는 예를 든다. 행동에는 명시하지 않은 결정이 들어 있고, 그 결정이 충돌하면 결과를 합치기 어려워진다는 주장이다.

 

두 글을 읽고 어느 회사가 멀티 에이전트에 찬성하는지만 고르면 설계에 필요한 질문을 놓친다. 중요한 차이는 업무의 결합도다. 독립적으로 자료를 찾는 과제와 같은 제품의 동작을 함께 바꾸는 과제는 필요한 공유 정보가 다르다. 핸드오프 설계는 이 차이를 입력 계약과 상태 관리로 표현하는 작업이다. 2025년의 구현 사례를 현재 제품의 고정된 한계로 일반화해서도 안 된다.

요약에서 가장 먼저 사라지는 것은 조건과 불확실성이다

 

요약은 반복 설명과 긴 도구 결과를 줄이는 데 효과적이다. 그러나 짧아졌다는 이유만으로 전달 품질이 좋아졌다고 판단할 수 없다. “검증 환경에서 재현되지 않았다”가 “문제 없음”으로 바뀌면 환경 조건과 불확실성이 함께 사라진다. 다음 담당자는 추가 확인이 필요한 결과를 종료된 문제로 받아들일 수 있다.

 

부정문과 범위 조건도 취약하다. “A 고객의 9월 주문에만 적용”이라는 내용에서 기간이 빠지면 현재 주문에도 규칙이 적용되는 것처럼 보인다. “담당자 검토 후 실행”에서 검토 조건을 생략하면 실행 순서가 달라진다. 사실을 틀리게 복사하지 않아도 일부를 빼는 것만으로 업무의 의미가 바뀔 수 있다.

 

따라서 인수인계에는 결론과 함께 결론을 제한하는 조건이 있어야 한다. 확인한 사실, 사용자 주장, 아직 검증하지 않은 추정, 실행하면 안 되는 행동을 구분한다. “완료”라는 단어를 쓸 때도 어떤 검사를 통과했고 무엇은 아직 확인하지 못했는지 남긴다. 다음 담당자가 추론으로 빈칸을 채우게 만들지 않는 것이 중요하다.

 

원문을 전부 전달할 수 없다면 중요한 부분의 식별자와 위치를 보관한다. 정책 문서 버전, 도구 응답의 결과 번호, 승인 기록과 같은 참조가 있으면 요약을 검증할 수 있다. 요약은 빠르게 방향을 잡는 안내문이고, 중요한 결정의 근거는 다시 읽을 수 있는 원자료로 연결해야 한다. 이는 요약을 금지하는 대신 요약의 역할을 분명히 하는 방법이다.

인수인계 메시지에는 완료 조건과 금지 범위가 필요하다

 

“이 고객 환불을 처리해 줘”라는 요청은 간단하지만 충분하지 않을 수 있다. 누가 요청한 고객인지, 어떤 주문인지, 전액인지 부분 환불인지, 실제 지급인지 검토인지가 비어 있다. 받는 에이전트가 이 빈칸을 임의로 채우면 각자의 작업은 그럴듯해도 시스템 전체의 목표는 달라질 수 있다.

 

설계 예시로 전달 묶음에 작업 식별자, 사용자 목표, 대상 식별자, 적용 범위, 완료 조건, 금지 행동, 근거 참조, 미해결 사항을 포함할 수 있다. “목표: 환불 가능 여부 안내”, “금지: 실제 환불 실행”, “완료 조건: 적용 규정과 부족한 정보를 사용자에게 설명”처럼 행동의 경계를 구체적으로 쓴다. 항목 이름보다 내용이 검증 가능한지가 중요하다.

 

현재 상태도 분리해서 전달한다. 이미 실행한 행동, 요청만 보낸 행동, 결과를 확인하지 못한 행동을 같은 완료 목록에 넣지 않는다. 주문 취소 요청이 전송됐지만 응답이 끊겼다면 상태는 “결과 확인 필요”다. 이를 “취소 실패”로 넘기면 다음 담당자가 같은 요청을 다시 실행할 수 있다.

 

받는 담당자는 필요한 정보가 모두 있는지 먼저 검사한다. 대상이나 범위가 없으면 이전 에이전트에게 보완을 요청하거나 원천 시스템에서 확인한다. 이 검사를 자연어 프롬프트에만 맡길 필요는 없다. 필수 항목, 허용 상태, 식별자 형식처럼 기계적으로 판별할 수 있는 조건은 애플리케이션 코드로 검사하면 누락을 더 일찍 발견할 수 있다.

OpenAI Agents SDK의 input_type은 전체 입력을 교체하지 않는다

 

공식 문서에서 특히 주의할 부분은 핸드오프 입력의 의미다. input_type은 핸드오프 도구 호출의 인자 스키마다. 예를 들어 이관 사유, 언어, 우선순위 같은 메타데이터를 모델이 생성하게 하고, 파싱한 값을 on_handoff 콜백으로 받을 수 있다. 이 기능은 인수인계 사유를 구조화하는 데 도움이 된다.

 

하지만 input_type을 지정했다고 다음 에이전트의 전체 입력이 그 객체로 교체되는 것은 아니다. 문서는 수신 에이전트가 기본적으로 이전 대화 기록도 보며, 기록을 바꾸려면 input_filter 등의 설정을 사용해야 한다고 설명한다. “요약 필드만 넘겼으니 원문은 보이지 않을 것”이라는 추정은 구현과 다를 수 있다.

 

또한 handoff 함수에 지정한 대상 에이전트는 입력 객체의 내용만으로 자동 변경되지 않는다. 여러 전문가 중 하나를 고르게 하려면 대상별 핸드오프를 등록하는 식으로 제어 흐름을 설계해야 한다. 모델이 생성한 “담당 부서” 문자열을 곧바로 실제 실행 대상으로 해석하는 구조라면 별도의 라우팅 검사가 필요하다.

 

이미 서버가 가지고 있는 계정 상태와 의존성을 모델에게 다시 적게 하는 것도 피할 수 있다. SDK 문서는 모델이 결정하는 메타데이터와 애플리케이션 컨텍스트를 구분한다. 주문 소유자나 조직 권한처럼 서버가 아는 값은 신뢰할 수 있는 상태에서 읽고, 모델이 생성한 필드가 이를 덮어쓰지 않도록 한다. 구조화된 입력은 형식을 다루는 장치이지 사실성과 권한의 보증서가 아니다.

기록 필터링과 개인정보 삭제는 같은 동작이 아니다

 

대화 이력을 줄이기 위해 도구 호출 기록을 제거하는 필터를 사용할 수 있다. 다만 도구 항목을 지웠다고 그 정보가 다른 메시지에서도 사라지는 것은 아니다. 앞선 에이전트가 도구 결과를 일반 문장으로 복사했거나 요약에 넣었다면 민감한 내용이 그대로 남을 수 있다. 데이터가 어떤 형태로 전달되는지까지 봐야 한다.

 

OpenAI Agents SDK 문서는 remove_all_tools가 구조화된 도구 항목을 제거하지만 일반 메시지나 중첩된 기록 요약에 복사된 도구 인자와 결과까지 가려 주는 것은 아니라고 설명한다. 또한 nested handoff history는 대화 표현을 바꾸는 기능이며 민감 정보의 비식별화 기능이 아니라고 명시한다. 기록 압축을 접근 통제와 혼동하면 안 되는 이유다.

 

실무에서는 받는 에이전트가 실제로 볼 최종 입력을 기준으로 검증한다. 원본 기록, 요약, 도구 결과, 별도 상태 객체 중 어느 경로로 데이터가 들어오는지 확인한다. 다른 조직의 전문가나 외부 모델 제공자에게 넘기는 경우에는 수신 범위를 더 명확하게 관리해야 한다. 호출 경계는 데이터를 전달받는 주체가 바뀌는 경계이기도 하다.

 

필터를 설계할 때는 민감한 내용을 제거한 뒤 요약하는 순서가 필요한지 검토한다. 요약이 먼저라면 삭제해야 할 값이 새로운 문장 속에 섞일 수 있기 때문이다. 필터가 원본 일부만 검사하고 파생 요약을 놓치지 않는지 테스트한다. “개인정보를 포함하지 마라”라는 한 줄의 지시보다 실제 입력 구성 경로를 검사하는 절차가 더 확실한 확인 방법이다.

에이전트가 넘길 수 있는 일과 권한은 분리해야 한다

 

접수 담당 AI가 환불 전문가에게 업무를 넘겼다는 사실은 환불 실행을 승인했다는 뜻이 아니다. 업무 배정은 누가 문제를 검토할지 정하고, 권한 검사는 누가 어떤 대상에 어떤 행동을 할 수 있는지 정한다. 두 판단을 합치면 담당 전환이 권한 상승의 통로가 될 수 있다.

 

SDK 문서는 is_enabled가 모델이 핸드오프 인자를 반환하기 전에 사용 가능한 핸드오프를 준비하는 시점에 평가된다고 설명한다. 따라서 인자에 담긴 주문 번호나 금액에 따라 승인을 판단해야 한다면 이 설정만으로는 충분하지 않다. 파싱된 필드에 의존하는 권한 검사는 부수 효과가 발생하기 전에 콜백 등의 적절한 위치에서 수행해야 한다.

 

문서는 권한 검사가 실패했을 때 성공적으로 반환하면 이관이 계속될 수 있다는 점도 설명한다. 실제 구현에서는 오류를 반환하는 것인지, 예외로 실행을 중단하는 것인지 SDK의 제어 흐름을 확인해야 한다. 메시지에 “권한 없음”을 남겼다는 사실과 프로그램이 멈췄다는 사실을 구분해야 한다.

 

최종 실행 도구에서도 권한을 다시 검사한다. 이관 이후 주문 소유자가 바뀌거나 승인 범위가 만료될 수 있고, 다른 경로로 같은 도구가 호출될 수도 있다. 모델이 작성한 승인 요약을 신뢰의 출발점으로 삼기보다 서버가 관리하는 승인 대상, 허용 행동과 유효 상태를 확인한다. 인수인계는 권한을 우회하는 예외 경로가 되어서는 안 된다.

병렬 작업에서는 같은 사실을 보고도 다른 버전을 만들 수 있다

 

여러 에이전트에게 같은 목표를 전달해도 작업 중에 서로 다른 전제를 만들 수 있다. 개발 담당 하나는 결제 상태를 문자열로 표현하고 다른 담당은 숫자 코드로 표현할 수 있다. 각각의 결과가 자기 범위에서는 올바르더라도 통합 과정에서는 연결되지 않는다. 단순한 메시지 전달보다 공동으로 지켜야 할 계약이 필요하다.

 

공유 상태를 쓰는 경우에는 버전 충돌을 관리한다. 두 에이전트가 같은 주문의 상태 12를 읽고 각각 수정 결과를 저장하면 나중에 저장된 값이 앞선 변경을 덮어쓸 수 있다. 예시로 “읽은 버전이 현재 버전과 같을 때만 갱신한다”는 조건을 두면 오래된 전제에서 나온 결과를 감지할 수 있다. 충돌을 감지한 뒤에는 최신 상태를 다시 읽고 작업을 재검토한다.

 

읽기 전용 조사는 상대적으로 나누기 쉽지만 공유 파일이나 실제 거래를 동시에 바꾸는 작업은 결합도가 높다. 담당 범위를 파일, 문서 구역, 고객 건처럼 명시하고, 공통 인터페이스의 결정권자를 둔다. 독립적으로 처리할 수 없는 작업은 순차적으로 실행하는 편이 나을 수 있다. 병렬화 가능성은 역할 이름의 개수가 아니라 상태 의존성으로 판단한다.

 

Cognition이 강조한 “행동에 포함된 암묵적 결정”을 이 관점에서 읽을 수 있다. 누군가의 결과가 다음 담당자의 환경을 바꾼다면 그 변경이 공유되어야 한다. 완료 보고만 모으는 관리자는 충돌을 늦게 발견한다. 변경한 대상, 참조한 버전, 새로 도입한 제약까지 함께 전달하는 인수인계가 필요하다.

결과물은 다시 말하게 하지 말고 직접 참조하게 하자

 

하위 에이전트의 보고서를 주 에이전트가 요약하고, 다른 에이전트가 다시 작성하는 과정에서는 정보가 여러 번 변형된다. 표의 단위, 법적 예외, 코드의 함수 이름처럼 작은 차이가 중요한 자료는 이 과정에서 손상될 수 있다. 내용 전달과 작업 진행 보고를 같은 텍스트 통로에 모두 담을 필요는 없다.

 

Anthropic은 리서치 시스템 글의 부록에서 산출물을 외부에 저장하고 가벼운 참조를 전달하는 방식을 설명한다. 코드, 보고서, 시각화처럼 전문 에이전트가 만든 결과를 일반 조정자가 다시 설명하게 하기보다, 결과물 자체가 독립적으로 유지되게 하는 접근이다. 중간 전달 과정의 정보 손실과 반복 복사 비용을 줄이는 데 도움이 될 수 있다.

 

실무 설계 예시로 “초안 문서 D, 버전 4, 검토 범위는 2장과 3장”처럼 참조할 수 있다. 검토 담당자는 실제 문서를 읽고, 결과에는 문제가 있는 위치와 수정 이유를 남긴다. 조정자는 초안 내용을 기억에 의존해 재생성하지 않고 해당 버전의 검토 결과를 연결한다. 문서가 바뀌면 이전 검토의 적용 범위도 다시 판단할 수 있다.

 

참조만 전달한다고 검증이 자동으로 끝나는 것은 아니다. 수신자가 결과물에 접근할 수 있는지, 링크가 같은 버전을 가리키는지, 보관 기간이 지나 사라지지 않았는지 확인해야 한다. 출처가 없는 요약 대신 출처 있는 결과물을 사용하되, 참조의 유효성과 권한까지 계약의 일부로 관리해야 한다.

고객 안내문 사례로 보는 안전한 핸드오프 흐름

 

가상의 운영팀이 배송 지연 안내문을 준비한다고 하자. 사용자 목표는 “해당 주문 고객에게 보낼 한국어 안내문 초안을 작성하되 아직 발송하지 않기”다. 조사 에이전트는 주문 현황과 공지 정책을 확인하고, 작성 에이전트는 초안을 만들며, 검토 에이전트는 사실과 문구를 확인한다. 역할을 나누는 것만으로는 아직 안전한 흐름이 완성되지 않는다.

 

조사 결과에는 조회 시각, 지연이 확인된 주문 범위, 확정되지 않은 배송 예정일, 정책 문서 버전을 남긴다. 작성 담당에게는 “정확한 도착일을 약속하지 않는다”와 “발송 금지”를 함께 전달한다. 조회 실패한 주문을 지연 주문에 포함하지 않고, 확인되지 않은 항목은 별도 목록으로 남겨 추가 확인을 요청한다.

 

작성 결과는 초안 문서의 특정 버전으로 저장한다. 검토 담당자는 그 버전과 원본 조사 결과를 대조한다. “검토 통과”만 반환하기보다 사실 확인 범위, 미확인 주문, 사용하면 안 되는 표현을 기록한다. 검토 중 문서가 수정됐다면 이전 버전에 대한 승인을 새 문서에 자동으로 적용하지 않는다.

 

마지막 담당자는 사용자에게 초안을 보여 준다. 현재 목표가 초안 작성이므로 발송 도구는 이 흐름에 필요하지 않을 수 있다. 사용자가 이후 발송을 요청하면 수신자 목록과 최종 문서 버전을 확인하는 별도 실행 단계로 처리한다. 이전 작업에서 생성된 “검토 완료”라는 말이 새 행동의 승인으로 바뀌지 않게 만드는 것이 핵심이다.

시간 초과와 중복 이관은 메시지보다 상태로 복구한다

 

핸드오프 요청을 보낸 뒤 응답이 늦어지면 송신자는 이관이 실패했다고 생각하기 쉽다. 그러나 수신자는 이미 작업을 시작했을 수 있다. 같은 일을 새 에이전트에게 다시 배정하면 두 담당자가 동시에 결과를 만들거나 외부 시스템을 변경할 수 있다. 전송 실패와 업무 실패를 분리해서 다뤄야 한다.

 

작업 식별자와 이관 식별자를 두면 같은 요청의 재전달을 알아보기 쉽다. 실행 상태도 생성, 접수, 진행, 결과 제출, 검증 완료처럼 목적에 맞게 나눌 수 있다. 정확한 상태 이름은 시스템마다 달라도 된다. 중요한 것은 송신자가 답을 받지 못했다고 이미 접수된 일을 새 작업으로 만들지 않는 것이다.

 

재시도 전에 현재 담당자와 처리 상태를 조회한다. 수신자가 살아 있다면 기다리거나 진행 상황을 확인하고, 작업이 중단됐다면 보관된 상태에서 재개한다. 재배정이 필요할 때는 기존 담당자의 실행 권한과 결과 수용 범위를 어떻게 종료할지 정한다. 취소 요청을 보냈다는 사실만으로 늦게 도착한 결과가 무효 처리되는 것은 아니다.

 

외부 부수 효과가 있는 실행에는 멱등성이나 중복 방지 장치도 필요하다. 모든 업무를 처음부터 다시 수행하는 복구는 비용이 크고 이미 수행한 행동을 반복할 수 있다. Anthropic의 글 역시 장시간 에이전트에서 처음부터 재시작하기보다 중간 상태에서 이어 가는 운영 설계의 중요성을 설명한다. 핸드오프의 성공 여부는 채팅 메시지가 아니라 관리되는 작업 상태로 확인해야 한다.

가드레일은 한 번 켜 두면 모든 경계에 적용되는 스위치가 아니다

 

에이전트를 여러 단계로 연결한 뒤 입력 검사를 하나 추가하면 전체 흐름이 보호될 것이라고 생각할 수 있다. 하지만 어느 단계에서 어떤 검사가 실행되는지는 프레임워크에 따라 다르다. 사용자 입력에 대한 검사, 핸드오프 인자 검사, 도구 실행 검사와 최종 출력 검사는 서로 다른 위치의 장치다.

 

확인한 OpenAI Agents SDK 문서는 하나의 run 안에서 핸드오프가 이뤄지며, 입력 가드레일은 체인의 첫 에이전트에, 출력 가드레일은 최종 결과를 만드는 에이전트에 적용된다고 설명한다. 또한 함수 도구의 입력 가드레일과 핸드오프를 구분한다. 따라서 모든 이관이나 중간 행동이 자동으로 같은 검사를 거친다고 가정해서는 안 된다.

 

설계할 때는 실제 경계별 검사를 적어 본다. 처음에는 요청 범위를 확인하고, 담당 전환 직전에는 대상과 전달 데이터를 검사하며, 실행 도구에서는 현재 권한과 입력 값을 검사하고, 최종 응답에서는 사실과 노출 범위를 확인한다. 같은 검사 코드를 무조건 반복하라는 의미가 아니라 각 위험이 발생하는 시점에 검사 책임을 두라는 뜻이다.

 

프레임워크 업데이트로 기록 전달 방식이나 기본 설정이 바뀔 수도 있다. 문서의 현재 동작을 확인하고 사용 버전과 함께 관리해야 한다. 가드레일이 있다는 소개 문구보다 어떤 입력을 실제로 검사하고 어느 조건에서 중단되는지 확인하는 테스트가 중요하다. 모델에게 조심하라고 말하는 것과 실행 경계를 검사하는 것은 다른 설계 작업이다.

멀티 에이전트 비용은 인원수보다 왕복과 재작업에서 커진다

 

요청을 넘길 때마다 대화 이력과 도구 설명을 다시 읽으면 전달 비용이 늘어난다. 수신자가 정보가 부족하다고 되묻고, 송신자가 다른 요약을 보내고, 검토자가 다시 반려하는 왕복이 반복되면 단순히 에이전트 수만 보고는 비용을 예측하기 어렵다. 실패한 작업을 합치는 통합 비용도 따로 발생한다.

 

Anthropic은 자사 데이터에서 일반 에이전트가 채팅보다 약 4배, 멀티 에이전트 시스템이 채팅보다 약 15배의 토큰을 사용한다고 보고했다. 여기서 비교 대상은 채팅이다. 이를 모든 멀티 에이전트가 단일 에이전트보다 15배 비싸다는 공식으로 바꾸면 안 된다. 실제 금액은 모델 가격, 캐시, 도구 요금과 재시도에 따라 달라진다.

 

전체 지연 시간도 병렬 작업의 개수만으로 결정되지 않는다. 가장 늦은 작업을 기다리는 시간, 결과 통합, 권한 확인과 재검증이 사용자 대기 시간에 포함된다. 독립 조사 단계가 빨라졌어도 뒤의 통합 단계가 병목이라면 최종 응답은 크게 빨라지지 않을 수 있다. 따라서 개별 에이전트의 처리 시간과 처음부터 끝까지 걸린 시간을 함께 본다.

 

비용을 줄이려면 무조건 요약을 더 짧게 만들기보다 불필요한 이관과 재작업부터 찾는다. 같은 분야를 중복 조사하는지, 담당을 서로 되돌리는지, 완료 조건이 불분명해 계속 수정하는지 확인한다. 중요한 조건까지 지워 토큰을 줄이면 나중에 더 비싼 오류 복구가 필요할 수 있다. 좋은 인수인계는 짧은 메시지보다 필요한 정보가 처음부터 도착하는 데서 시작한다.

평가는 최종 답변과 인수인계 경계를 함께 봐야 한다

 

최종 문장이 자연스러우면 중간 전달의 오류를 놓치기 쉽다. 반대로 에이전트들이 지정된 순서를 조금 다르게 따랐다고 실제로 잘 끝낸 작업을 실패로 볼 수도 있다. 평가는 사용자의 목표 달성과 중요한 경계의 보존을 함께 확인해야 한다. 모든 내부 메시지를 정해진 문구와 비교하는 방식만으로는 부족하다.

 

경계 테스트에는 원래 요청의 금지 조건이 다음 담당자에게 남는지, 잘못된 조직의 데이터를 넘기지 않는지, 출처 없는 승인 요약이 실행을 유발하지 않는지 넣는다. 주문 번호가 형식상 올바르지만 다른 고객의 주문인 사례, 검토 뒤 초안이 바뀐 사례, 이관 도중 타임아웃이 난 사례도 중요하다. 형식 검사를 통과한 잘못된 입력을 일부러 포함한다.

 

일부 사례에서는 필요한 필드를 하나씩 제거해 본다. 출처나 적용 범위가 없어도 시스템이 자신 있게 실행한다면, 빠진 정보를 확인하는 경로가 약한 것이다. 긴 대화의 중간에 조건을 넣고 핸드오프 후에도 지켜지는지 확인하면 요약과 필터의 손실을 드러낼 수 있다. 기대하는 동작은 무조건 계속 진행하는 것이 아니라 누락을 정확히 발견하는 것이다.

 

비교 기준으로 같은 업무를 단일 에이전트, 고정 워크플로우, 멀티 에이전트로 실행할 수 있다. 성공률뿐 아니라 실제 비용, 응답 시간, 중복 실행, 사용자 재설명 횟수와 복구 난이도를 함께 기록한다. arXiv의 에이전트 시스템 확장 연구도 구조와 과제의 정렬에 따라 협업 효과가 달라진다고 보고한다. 특정 연구의 임계값을 모든 서비스에 적용하기보다 자기 업무의 기준선을 직접 측정해야 한다.

자주 묻는 질문: 멀티 에이전트 핸드오프

 

Q. 에이전트끼리 전체 대화 기록을 공유하면 해결되나요?

누락을 줄일 수 있지만 비용과 지연, 무관한 정보와 민감 정보의 전달 범위가 커질 수 있다. 이미 공유한 기록 이후에 서로 다른 결정을 내리는 문제도 남는다. 필요한 근거와 상태를 보존하면서 각 담당자의 권한과 책임을 명확하게 정해야 한다.

 

Q. 핸드오프 입력을 JSON으로 만들면 안전한가요?

JSON과 스키마는 형식, 필수 필드와 타입을 검사하는 데 도움이 된다. 하지만 존재하지 않는 승인, 잘못된 고객 번호와 오래된 문서 버전도 올바른 JSON 안에 들어갈 수 있다. 원천 데이터 조회와 권한 검사는 별도로 필요하다.

 

Q. 검토 에이전트가 승인했다면 바로 실행해도 되나요?

검토한 대상과 버전, 검토 범위가 실행하려는 대상과 일치하는지 확인해야 한다. 모델의 검토 결과는 실제 사용자 승인이나 서버 권한을 대신하지 않는다. 초안 문구가 적절한지 확인한 검토와 실제 발송을 허용한 승인은 다르다.

 

Q. 전문가를 도구로 부르는 방식이 항상 더 좋은가요?

주 에이전트가 결과를 모아 사용자에게 답해야 한다면 적합할 수 있다. 전문 담당자가 이후 대화를 책임지고 이어 가야 한다면 핸드오프가 자연스러울 수 있다. 호출 방식은 에이전트 수보다 제어권과 사용자 경험을 기준으로 선택한다.

 

Q. SDK 기본 필터로 도구 기록을 지우면 개인정보도 사라지나요?

일반 메시지나 요약에 복사된 값까지 제거되는지 확인해야 한다. 공식 문서는 도구 항목 제거와 민감 정보 삭제를 구분한다. 수신 에이전트의 최종 입력을 검사하고, 전달 경로 전체에 맞는 필터를 설계해야 한다.

협업하는 AI의 신뢰는 인수인계의 경계에서 결정된다

 

멀티 에이전트는 복잡한 일을 나누고 서로 다른 도구와 맥락을 활용하는 유용한 방식이다. 하지만 역할 이름을 늘리거나 메시지를 주고받게 하는 것만으로 협업이 완성되지는 않는다. 같은 목표를 유지하면서 조건, 근거, 권한과 상태를 이어 주는 장치가 있어야 한다.

 

처음 도입한다면 인수인계가 필요한 이유부터 좁혀 보는 것이 좋다. 독립적인 조사 결과가 필요한 것인지, 전문 상담으로 담당을 전환하려는 것인지, 단순한 단계별 처리를 여러 에이전트로 표현하고 있는 것인지 구분한다. 문제를 명확하게 정의할수록 불필요한 전달을 줄이고 책임을 정하기 쉽다.

 

이관 메시지는 결론만 담은 보고서보다 다음 행동을 안전하게 결정할 수 있는 작업 계약에 가까워야 한다. 무엇을 끝내야 하는지, 무엇을 하지 말아야 하는지, 어떤 버전의 결과를 근거로 삼는지, 확인이 안 된 것은 무엇인지 남긴다. 시스템은 이 계약을 검사하고 중요한 실행 앞에서 실제 상태를 다시 확인한다.

 

AI끼리 주고받은 요약은 업무를 빠르게 이어 주는 수단이다. 요약이 사실과 승인, 실행 결과의 증거까지 대신하게 두면 작은 생략이 큰 행동 변화로 이어질 수 있다. 믿을 수 있는 멀티 에이전트 시스템은 말을 잘 넘기는 시스템을 넘어, 넘긴 말이 어떤 근거와 권한에 연결되는지 확인할 수 있는 시스템이다.

원자료와 국내 기술 블로그 참고 자료

 

자료 확인일: 2026년 10월 27일. 아래 원자료와 국내 글을 비교해 개념, 사례, 구현상의 주의점을 정리했다. 제품 문서는 변경될 수 있으므로 실제 개발에서는 사용하는 SDK 버전의 동작을 확인해야 한다. 본문의 가상 업무 흐름과 메시지 항목은 독자의 이해를 위한 설계 예시다.

 

OpenAI Agents SDK, Handoffs 공식 문서.

핸드오프와 전문가 도구 호출의 구분, input_type, input_filter, 권한 검사와 기록 전달의 실제 의미를 확인했다.

https://openai.github.io/openai-agents-python/handoffs/

Handoffs - OpenAI Agents SDK

 

Anthropic, How we built our multi-agent research system, 2025년 6월 13일.

리서치 분업의 효과, 위임 지시의 구성, 평가, 장기 실행 복구와 산출물 참조 전략을 확인했다. 성과와 토큰 수치는 해당 글의 평가 조건에 한정해 읽어야 한다.

https://www.anthropic.com/engineering/multi-agent-research-system

How we built our multi-agent research system

 

Cognition, Don’t Build Multi-Agents, 2025년 6월 12일.

맥락 공유와 행동에 포함된 암묵적 결정이 통합 결과에 미치는 영향을 참고했다. 공개 당시의 구현 사례를 현재 모든 제품의 제한으로 일반화하지 않았다.

https://cognition.ai/blog/dont-build-multi-agents

Don’t Build Multi-Agents

 

Yubin Kim 외, Towards a Science of Scaling Agent Systems, arXiv:2512.08296v3, 2026년 4월 수정본.

공식 초록에서 통제된 구성 비교와 업무 구조에 따른 협업 효과의 차이를 확인했다. 모든 도메인에 적용되는 성능 보장으로 해석하지 않았다.

https://arxiv.org/abs/2512.08296v3

Towards a Science of Scaling Agent Systems

 

MSAP.ai, 멀티 에이전트 시스템 설계: 협업 패턴과 도입 전 알아야 할 실패 모드, 2026년 8월 10일.

국내 독자를 위한 협업 패턴, 통신 방식과 운영 실패의 설명 구성을 비교했다.

https://www.msap.ai/agentic-ai/multi-agent-system

 

페블러스, 멀티에이전트 AI 협업 효과를 가르는 단일 에이전트 성능 임계값, 2026년 7월 28일.

기준선 측정과 과제의 분해 가능성을 중심으로 설명하는 국내 기술 글을 참고했다. 수치 자체보다 도메인별 재측정의 필요성에 주목했다.

https://blog.pebblous.ai/blog/multi-agent-single-agent-threshold/ko/