에이전트 핸드오프(Agent Handoffs): 라우팅을 런타임 상태로 전환하기 | Focused Labs

에이전트 핸드오프(Agent handoffs)는 멀티 에이전트 시스템(multi-agent systems)이 단순한 라우팅 다이어그램을 넘어 실제 프로덕션 소프트웨어(production software)로 변모하는 지점입니다.

멀티 에이전트 시스템 내 에이전트 간의 핸드오프, 즉 고객이 한 에이전트에서 다른 에이전트로(보통 다른 질문을 해결하기 위해 한 전문가에서 다른 전문가로) 전달되는 방식은 실제 상황에서 결코 사소하지 않으며, 해당 고객과의 대화 트레이스(trace)에 영향을 미칩니다. 특히 첫 번째 핸드오프에서 문제가 발생하곤 합니다. 예를 들어, 결제(billing) 팀은 지원(support) 팀이 여전히 동일한 질문에 답변하고 있다고 믿고, 지원 팀은 결제 팀이 고객과의 대화를 인계받았다고 믿으며, 부정 결제(fraud) 팀은 고객의 전체 상황을 파악한 후 첫 번째 에이전트로부터 승인 상태를 확인해야 하는 상황이 벌어집니다.

멀티 에이전트 시스템의 어려운 부분은 바로 핸드오프입니다. 핸드오프 계약(Handoff contracts)은 AI 에이전트 오케스트레이션(AI agent orchestration)을 구매 가능한 런타임 소프트웨어(runtime software)로 만들어 줍니다.

소유권이 이동하거나, 혹은 이동하지 않거나

OpenAI가 설명한 바와 같이, 오케스트레이션(Orchestration)은 대화를 이어가기 위해 고객을 전문가에게 인계하는 것과, 매니저가 고객의 질문에 대한 책임을 유지하면서 최종 답변에 도달하기 위해 에이전트를 도구로 사용하는 것 사이에 중요한 차이를 둡 (OpenAI는 이 구분을 직접적으로 설명합니다). 이것이 바로 멀티 에이전트 시스템 구매자들이 반드시 고려해야 할 사항입니다. 고객의 질의에 대한 책임이 전문가에게 전달되는 것인가, 아니면 매니저가 정보를 수집하고 작업을 수행하기 위해 에이전트를 사용하면서도 고객의 질문에 대한 책임을 계속 유지하는 것인가?

아키텍처 스택의 더 아래 단계에서는 동일한 구조를 지칭하기 위해 다른 용어들이 사용됩니다. 예를 들어, Microsoft Agent Framework에서는 고객이 한 에이전트에서 다른 에이전트로 전달되는 핸드오프(handoff)를 시스템 내의 에이전트들이 노드(node)가 되고 에이전트 간의 허용된 핸드오프가 엣지(edge)가 되는 유향 그래프(directed graph)로 모델링합니다. 두 에이전트 간의 핸드오프는 첫 번째 에이전트가 호출할 수 있는 합성 도구(synthetic tool)로 모델링됩니다 (Jacob Alber의 이 패턴에 대한 투어는 매우 구체적입니다). 반면, Amazon Bedrock은 관리자(supervisors)와 협업자(collaborators)라는 용어를 사용합니다. Bedrock의 설정 문서에서는 관리자가 라우터(router)로 기능하도록 구성하는 방법과, 이후 협업자가 고객에게 최종 답변을 보내는 방법을 설명합니다 (Bedrock의 설정 문서는 이 두 가지 모드를 명시하고 있습니다). 한편, LangChain은 핸드오프 오케스트레이션(handoff orchestration)을 상태 기반 동작(state-driven behavior)으로 모델링하며, 여기서 각 도구는 대화의 현재 단계를 업데이트하거나 시스템 내의 새로운 활성 에이전트를 지정합니다 (LangChain 문서는 이러한 상태 변수들을 명시적으로 사용합니다).

어휘는 다르지만, 핵심적인 문제 지점은 동일합니다.

핸드오프는 멀티 에이전트 시스템(multi-agent system)에서 시스템이 다음에 누가 말할지, 다음에 누가 행동할지, 그리고 이전 작업으로부터 얻은 어떤 증거를 대화의 다음 에이전트가 유지할지를 결정하는 지점입니다. 이는 프롬프트(prompt) 내의 영리한 문구로 취급될 것이 아니라, 런타임 상태 변화(runtime state change)로 취급되어야 합니다.

패턴의 선택은 곧 런타임 소유권(runtime ownership)의 선택입니다.

이것이 바로 멀티 에이전트 아키텍처 결정(multi-agent architecture decisions)이 단순히 고객 전화를 위한 깔끔한 라우팅 다이어그램 그 이상인 이유입니다. 대신, 이 결정은 관리자(supervisors), 전문가(specialists), 라우터(routers), 스웜(swarms), 그리고 핸드오프 그래프(handoff graphs)에 관한 결정을 내려, 단 하나의 비즈니스 질문에 답하는 프로덕션 시스템을 구축합니다: '누가 다음 고객 가시적 결과물을 생성할 것인가?'

컨텍스트 경계가 곧 제품의 경계입니다

LangChain은 대화 기록(conversation history) 내에서의 핸드오프(handoff) 시 발생할 수 있는 프로덕션상의 지뢰를 문서화하고 있습니다. 핸드오프가 Command.PARENT를 사용할 때, 부모 기록(parent history)에는 도구를 호출한 AIMessage와 핸드오프를 확인하는 일치하는 ToolMessage가 반드시 포함되어야 합니다. 이 두 메시지가 모두 없다면, 수신 측 모델은 잘못된 형식의 기록을 해석해야 합니다 (LangChain은 핸드오프 컨텍스트 섹션에서 이 쌍을 지적합니다). 그 작은 디테일이 바로 추상화(abstraction)입니다. 핸드오프는 영수증이 동반된 상태 업데이트(state update)입니다.

컨텍스트 엔지니어링(Context engineering) 연구는 대화에서의 전송 경계를 설명하는 데 중요한 일련의 용어들을 밝혀냅니다. 컨텍스트 엔지니어링에 관한 arXiv 논문은 관련성(relevance), 충분성(sufficiency), 격리성(isolation), 경제성(economy), 그리고 출처(provenance)를 나열합니다 (arXiv 초록에서 이 다섯 가지 기준을 설명합니다). 특히, 에이전트 간의 대화 상태(conversation state) 핸드오프는 현재 작업과 관련된 사실(relevance), 작업을 완료하기에 충분한 상태(sufficiency), 다른 경쟁적인 컨텍스트로부터의 충분한 격리(isolation), 비용과 주의(attention)를 최소화하기 위한 경제적인 크기의 메시지(economy), 그리고 정보가 애초에 어디에서 왔는지에 대한 기록인 출처(provenance)를 전달한다고 말할 수 있습니다.

반면에, 모호한 경계는 문제를 일으킵니다. 최악의 경우, 도구 간의 대화(tool chatter), 완료되지 않은 분석, 오래된 승인(stale approvals), 그리고 이전 전문가가 고객에 대해 수집한 중복된 정보 등을 포함하여 대화의 모든 이력이 가공되지 않은 형태(raw form)로 체인의 다음 에이전트에게 전달됩니다. 다음 차례의 전문가가 이전 전문가가 이미 수행한 작업을 다시 수행해야 하므로, 에이전트 간 정보 전달에 드는 토큰 비용(token cost)이 급격히 상승합니다. 반대로, 다음 전문가에게 제공되는 요약(summary)이 너무 빈약할 수도 있으며, 이로 인해 전문가는 이전 전문가가 이미 답변한 것과 동일한 질문을 다시 던지게 될 수도 있습니다. 이 과정에서 시스템 내의 시간(traceability/time)이 사라지며, 누가 무엇을 수행했는지 감사(audit)하기가 어려워집니다.

계약(contract)은 지루해야 합니다:

• 현재 소유자 (current owner)
• 허용된 다음 소유자 (allowed next owners)
• 상태 변화량 (state delta)
• 컨텍스트 페이로드 (context payload)
• 도구 엔벨로프 (tool envelope)
• 승인 상태 (approval status)
• 체크포인트 ID (checkpoint id)
• 트레이스 스팬 ID (trace span id)
• 전송 영수증 (receipt for the transfer)

지루한 것이 좋습니다. 지루한 것이 장애(incident) 상황에서도 살아남습니다.

핸드오프 그래프는 가드레일(guardrails)입니다

예를 들어, Microsoft의 이커머스 그래프 내에서 프로덕션 팀은 단순한 분류 라우팅(triage routing) 이상의 구조를 지원하는 체계 하에서 운영되기를 원할 수 있습니다. Microsoft의 경우, 결제(billing), 반품(returns), 그리고 반품 사기(return-to-fraud) 활동은 그래프의 엣지(edges)를 따라 진행되며, 후자는 해당 주제에 관한 Microsoft 블로그 포스트(Microsoft 블로그에서 해당 토폴로지를 설명합니다)에 기술된 대로 잠재적인 사기 결정 지점으로 이어집니다.

개발자는 코드로서의 토폴로지(topology as code)를 소유합니다. 에이전트는 해당 토폴로지 내에서의 라우팅 결정(routing decision)을 소유합니다.

이것은 또한 하네스(harness)가 라우팅과 상태를 소유하는 지점이기도 합니다. 모델은 프로덕션 팀에 의해 개발됩니다. 이 모델이 지원해야 하는 내구적인 동작(durable behavior)은 어떤 에이전트가 활성화되어 있는지, 해당 에이전트에 의해 어떤 도구(tools)가 마운트(mounted)되는지, 해당 에이전트가 어떤 도구 엔벨로프(tool envelope)를 사용하는지, 대기 중인 승인(pending approvals) 사항은 무엇인지, 그리고 어떤 트레이스(traces)가 해당 에이전트의 결정을 지원할지를 결정하는 레이어에 존재합니다.

핸드오프 그래프(handoff graph)는 코드 리뷰(code review)를 통해 검토 가능해야 하며, 예시를 통해 테스트 가능해야 하고, 트레이스의 흔적을 생성해야 합니다. 여기에는 중간에 활성화된 모든 에이전트의 전후(before and after) 트레이스, 핸드오프를 시작한 도구에 대한 트레이스, 그리고 인계하는 에이전트가 차례로 마운트하는 도구 엔벨로프(tool envelope)에 대한 트레이스가 포함되어야 합니다. 예를 들어, 케이스가 사기(fraud)로 이동된 후 사기 에이전트가 갑자기 케이스 관리 도구(case-management tool)에 대한 접근 권한을 얻는 것과 같은 권한 변경 사항을 런타임 이벤트(runtime events)로서 보고 싶습니다. 이것이 바로 도구 호출 전의 런타임 거버넌스(runtime governance before tool calls) 영역입니다.

그렇지 않다면, 팀은 조직도를 설명하기 위해 모델이 예의 바르게 행동하는 것을 구경만 하고 있는 셈이 됩니다.

유용한 핸드오프는 단순한 프롬프트 핸드오프(prompt handoff)가 아니라, 상태 델타(state delta)와 영수증(receipt)을 남깁니다.

트레이스는 책임 전송을 보여주어야 합니다

에이전트가 수행한 호출을 기록하면서도, 해당 호출을 수행한 에이전트가 누구였는지를 함께 기록하지 않는 에이전트 트레이스는 불완전한 핸드오프 트레이스입니다.

이 지점에서 에이전트 모니터링은 인프라가 됩니다. 핸드오프(handoff)된 케이스의 트레이스(trace)는 이제 활성 에이전트(active agent) 및 런타임 거버넌스(runtime governance)와 같은 런타임 이벤트(runtime events)에 의해 모니터링될 수 있는 것이 됩니다. Honeycomb의 10년 선언문(10-year manifesto)에서 언급했듯이, AI 생성 코드와 함께 소프트웨어 개발자의 업무는 소프트웨어를 생성하는 것에서 소프트웨어로부터 배우고 이를 안전하게 운영하는 것으로 점점 더 이동할 것입니다 (Charity Majors는 Honeycomb의 10년 선언문에서 그 근거를 제시합니다). 이는 AI 에이전트 오케스트레이션(AI-agent-orchestration)에도 마찬가지로 적용됩니다. 전문가들 사이의 작업 전달을 모니터링하는 것은 안전하고 효과적인 사용을 위해 중요합니다.

AI 시스템의 전문가들 사이에서 이러한 작업 전달이 일어난 후, 부수 효과(side effects), 즉 첫 번째 전문가의 작업 결과로 발생하는 효과는 예상치 못한 비용을 초래할 수 있습니다. 전형적인 사례는 첫 번째 에이전트에 의해 환불이 시작된 후, 해당 케이스가 결제 전문가(billing specialist)에게 핸드오프되는 경우입니다. 결제 전문가가 작업을 수행하기 위해서는 환불을 시작한 문장 이상의 정보가 필요합니다. 해당 전문가는 작업 키(operation key), 케이스의 현재 상태(current status), 케이스의 영수증(receipt), 케이스의 소유자(owner), 그리고 케이스의 재시도 규칙(retry rules)이 필요합니다. 이것들이 없다면 재시도, 작업 재개, 또는 다른 전문가의 작업조차 중복 작업으로 이어질 수 있습니다. 따라서 핸드오프 이후의 부수 효과 영수증(side-effect receipts after a handoff) 또한 런타임(runtime)에 포함되어야 합니다.

이러한 정보들은 쿼리(queryable) 가능해야 하며, 특히 전달 영수증(transfer receipt), 승인 상태(approval state), 도구 엔벨로프(tool envelope), 그리고 현재 활성화된 에이전트(currently active agent)가 그러해야 합니다. 이러한 쿼리 가능 여부가 AI 호출을 라우팅하고 제어하는 운영 모델과, 둘 다 유용할 수는 있지만 단순히 대화 내용을 예쁘게 기록한 전사(transcript) 사이의 차이점입니다.

중앙 컨트롤러는 병목 현상으로 변합니다

또 다른 흔한 함정은 안전이나 제어를 위해 중앙 관리자(central manager)를 도입하는 것입니다. 이들은 통신 중간에 위치하여 작업을 위임하고, 다양한 하위 에이전트(sub-agents)로부터 나온 결과들을 병합한 뒤, 고객에게 최종 답변을 제공합니다. 제어는 안전하고 깔끔하게 들립니다. 하지만 현실에서 이러한 관리자는 병목 현상(bottleneck)이 됩니다.

탈중앙화된 멀티 에이전트 시스템(Decentralized multi-agent systems) 연구에 따르면, 중앙 집중식 시스템은 하위 에이전트들이 병렬로 실행되는 것을 가능하게 할 수는 있지만, 이것이 메인 작업의 병렬적 조정(parallel coordination)으로 이어지지는 않는다고 합니다. 왜냐하면 한 에이전트에 의해 다시 작성되고 다른 에이전트들에게 선택적으로 노출된 작업이, 해당 작업을 작성한 메인 에이전트를 거쳐 라우팅되기 때문입니다 (DeLM 논문에서는 이러한 조정 병목 현상을 직접적으로 명시하고 있습니다). 따라서 하위 에이전트를 둔 중앙 집중식 시스템 대신, 대안으로는 에이전트들, 공유된 검증된 컨텍스트(shared verified context), 그리고 각 작업 항목이 다른 에이전트들이 그 위에 구축할 수 있는 검증된 진행 상황을 나타내는 작업 큐(task queue)를 사용하는 방식이 있습니다.