멀티 Agent Handoff: 왜 완전한 이력을 전부 넘기면 안 되는가
「Token이 너무 많아서」는 절반만 맞다. 진짜 핵심은 **컨텍스트 경계(Context Boundary)**이며, 함부로 넘기면 노이즈, 월권, 책임 경계 혼란이라는 세 종류의 리스크가 생긴다. 올바른 방식은 handoff를 통제된 인계로 다루는 것이다: 표준화된 구조화 인계 패키지(고정 필드)를 생성해 인수 작업에 필요한 정보만 넘기고, 완전한 이력은 백엔드 trace에 남겨 필요할 때 조회하게 한다.
표면 vs 본질: 컨텍스트 경계
- Handoff는 단톡방 전달이 아니라 티켓 이관에 가깝다.
- 수신자가 필요한 것: 작업 목표, 핵심 사실, 제약 조건, 이미 완료한 단계, 인계 사유
- 수신자가 필요로 하지 않는 것: 앞선 잡담, 실패한 시도, 무관한 도구 출력, 이미 실효했을 수 있는 중간 가정
한 문장: 컨텍스트 필터링 + 구조화 요약
| 현재 상태 | 실행 단계와 진행 상황을 명확히 |
|---|
| 확인된 사실 | 유효한 핵심 데이터를 적립 |
| 미해결 문제 | 할 일과 난점에 집중 |
| 권한 경계 | 조작과 보안 범위를 획정 |
| 호출 가능 도구 | 사용 가능한 인터페이스와 함수 열거 |
| 기대 출력 | 납품 결과 기준을 명확히 |
완전한 이력은 백엔드 trace에 보존해도 되지만, 인수 Agent에게 기본으로 밀어 넣어서는 안 된다.
전달 금지
- 민감 정보 → 은밀한 월권 방지
- 금지 항목: 사용자 신원, 결제 정보, 내부 도구 반환, 타 부서 데이터
- 핵심 논리: 원래 Agent에게 권한이 있다 ≠ 인수 Agent에게 권한이 있다. 필터링하지 않으면 곧 은밀한 월권이다
- 고위험 장면: 부서 간, 테넌트 간, 도구 간
- 처리 동작: 완전 인계 패키지 → 수신자 권한에 따라 재재단 → 안전 인계 패키지
- 노이즈와 잘못된 가정 → 오류 상속 방지
- 완전한 이력에는 다음이 섞여 있다: 모델의 시행착오, 도구 실패, 사용자가 부정한 내용, 초기의 잘못된 판단
- 도식: 「대량의 낡은 컨텍스트 → Agent가 잘못된 방향으로 끌려감」
- 대책: 인계 요약은 반드시 세 가지로 표기해야 한다 — 어떤 사실이 확인됨, 어떤 것이 추측일 뿐, 어떤 시도가 이미 실패함. 인수 측이 같은 우회로를 반복하지 않게 한다
- 책임 경계 → 인계 후 누가 무엇을 책임지는가
- 최종 답변: 누가 사용자에게 최종 결론을 주는가?
- 도구 호출: 누가 외부 API를 발동할 권한이 있는가?
- 정보 보충: 정보가 부족할 때 누가 사용자에게 되물을 수 있는가?
- 이상 폴백: 실행 실패나 로직 혼란이 발생하면 누가 처리하는가?
요약 과압축 방지: 인계 패키지를 고정 필드로 쪼개기
- 딜레마
- 요약이 너무 짧으면 → 핵심 제약과 컨텍스트를 잃는다
- 요약이 너무 길면 → 대량의 노이즈와 무효 정보를 도입한다
- 산업급 방식: 인계 패키지를 표준화된 고정 필드(Handoff Payload)로 분해
- 목표 Goal
- 확인된 사실 Facts
- 증거 링크 Evidence
- 시도한 동작 Actions
- 실패 원인 Failures
- 리스크 Risks
- 다음 단계 제안 Next Steps
- 읽기 플로우: Step 1 표준화 필드 읽기 → 정보 완전성 평가 → Step 2 필요에 따라 백엔드 Trace 조회
- 이득: Token 컨텍스트를 최대한 절약하면서 동시에 직전 턴의 오류 상속을 줄인다
Handoff를 검증하는 5가지 정량 지표
- 인계 후 재질문율
- 오류 상속률
- 민감 필드 유출률
- 인수 성공률
- 평균 컨텍스트 보충 횟수
판정 레드라인: 인계 비용 > 단일 Agent 비용 = 경계 설계 실패. 멀티 Agent는 많을수록 고급인 것이 아니다.
핵심 경계 원칙: 권한이 부족하면 인수를 거절할 것
재단된 정보를 들고 맹목적으로 「답을 추측」하지 말 것. 수신자의 권한이나 정보가 부족하면 인수를 직접 거절하거나 재인가를 요청해야 한다.
정리
handoff를 통제된 인계로 다루고 완전한 컨텍스트를 그대로 넘기지 않는다. 시스템이 먼저 구조화 인계 패키지를 생성하는데, 여기에는 작업 목표, 핵심 사실, 증거 출처, 이미 실행한 동작, 실패한 시도, 리스크 경고, 수신자 권한이 포함된다. 그다음 수신자가 계속 처리하며, 필요 시 고위험 정보에 대해 사용자에게 다시 확인한다. 멀티 Agent의 난점은 역할을 나누는 것이 아니라 인계에서 핵심을 잃지 않고, 정보를 유출하지 않고, 오류를 상속하지 않는 것이다. 진짜 성숙한 handoff는 백엔드에 완전한 흔적을 남기고 전면에는 수신자에게 필요한 정보만 준다.
핵심 통찰
- Handoff의 본질은 권한 재인가이지 데이터 운반이 아니다 — 인계 시 진짜로 넘겨지는 것은 「누가 무엇을 볼 수 있고 누가 무엇을 할 수 있는가」이며 Token 비용은 부산물일 뿐이다. handoff를 이력 복사로 여기면 보안 모델까지 함께 망가뜨려 복사하는 것이다.
- 컨텍스트는 완전할수록 좋은 것이 아니라 「충분하면서 깨끗할수록」 좋다 — 전면 상속은 상류의 잘못된 가정과 실패 경로까지 함께 상속시켜, Agent B가 Agent A가 이미 잘못 간 길을 따라 계속 가게 만든다. 정보 완비성과 판단의 순수성은 한 쌍의 모순이다.
- 「요약해서 Token 절약」은 표층 인식이고 「경계 거버넌스」가 아키텍트 관점이다 — 이 두 답변의 분수령은 권한 필터링, 사실 확인, 실패 기록, 수신자 직책을 언급했는가다.
- 요약 길이는 양쪽 모두의 리스크이므로 분량이 아니라 고정 필드로 해결해야 한다 — 「요약을 얼마나 길게 쓸까」로 씨름하느니 Schema(Goal/Facts/Evidence/Actions/Failures/Risks/Next Steps)를 정의해 길이가 내용에 따라 자연히 결정되게 하라.
- 사실은 반드시 등급화해야 한다: 확인됨 / 추측 / 이미 반증됨 — 인계 패키지에서 가장 값진 것은 흔히 「무엇을 했는가」가 아니라 「어느 길이 이미 안 된다고 증명되었는가」다. 이 표기가 빠지면 인수 측은 반드시 우회로를 반복한다.
- 완전한 이력은 삭제하지 않되 계층 분리해 보관한다 — 전면에는 필요한 정보만 주고 백엔드에는 완전한 흔적(trace)을 남긴다. 인수 측이 필요에 따라 드릴다운하지, 기본으로 밀어 넣지 않는다. 이것은 감사 가능성을 만족시키면서 추론을 오염시키지 않는다.
- 멀티 Agent 아키텍처는 비용으로 스스로를 반증해야 한다 — 「인계 비용 > 단일 Agent 비용」이면 분할 자체가 틀렸다는 뜻이다. 이는 자기 설계를 정량적으로 부정할 수 있는 기준을 준다.
- 인수 거절은 능력이지 장애가 아니다 — 권한이나 정보가 부족할 때 Agent가 능동적으로 멈춰 서서 인가를 요청하게 하는 편이, 「부상을 안고 출전해 답을 추측하게」 하는 것보다 훨씬 안전하다. 이 항목이 「컨텍스트를 적게 넘기기」보다 중요하다.
엔지니어링 실전 Tips
- Handoff Payload를 강 Schema(JSON/Pydantic)로 정의할 것. 필드가 빠지면 검증 실패가 되게 해 자유 텍스트 요약의 자의성을 피할 것.
- 권한 재단은 생성 후·전송 전에 두고 독립 미들웨어로 만들 것. 각 Agent의 prompt에 흩어놓으면 새 Agent를 추가할 때 반드시 누락된다.
- 민감 필드는 삭제가 아니라 마스킹할 것: 플레이스홀더를 남겨(예:
card_no: ***1234) 인수 측이 「존재하지만 볼 권한이 없다」는 것을 알게 해, 사용자에게 반복해서 요구하지 않게 할 것.
- Evidence는 본문이 아니라 링크를 넘길 것: 인계 패키지에는 증거 ID / URL을 두고 인수 측이 필요에 따라 가져오게 한다. 컨텍스트 절약에서 가장 가성비 높은 한 칼이다.
- Failures 필드가 중복 노동 방지의 핵심이다. 「실패 동작 + 실패 원인」 두 항목을 반드시 기록할 것. 「실패했음」만 쓰는 것은 안 쓴 것과 같다.
- 백엔드 Trace와 전면 Payload를 같은 trace_id로 꿰맬 것. 그래야 「필요에 따른 드릴다운」과 사후 감사가 가능하다.
- 5개 지표 중 「인계 후 재질문율」을 가장 먼저 계측할 것 — 가장 민감하다. 요약이 핵심 제약을 잃는 순간 이 지표가 즉시 상승한다.
- 상용 전에 비용 대조 실험을 먼저 할 것: 같은 배치의 작업을 단일 Agent와 멀티 Agent로 각각 돌려, 멀티 Agent의 총 Token/소요가 더 높은데 품질 향상이 없다면 바로 단일 Agent로 되돌릴 것.
- 「인수 거절」을 합법적인 반환 경로로 만들 것. 오케스트레이션 계층에 폴백 전략(재인가 / 사람 전환 / Agent A로 반송)을 정의해 두지 않으면 Agent는 환각을 만들어낼 수밖에 없다.