에이전트 핸드오프 계약 (Agent Handoff Contracts): 프로덕션 에이전트 시스템의 누락된 조각

올해 여러분이 읽게 될 "우리 운영 플랫폼에 AI를 추가하고 있습니다"라는 이야기 대부분은 시스템의 작동 여부를 실제로 결정짓는 한 가지 부분, 즉 에이전트 간의 핸드오프 (handoff)를 건너뛸 것입니다. 이것이 왜 중요한지, 그리고 좋은 핸드오프란 어떤 모습인지 설명하겠습니다.

문제점

에이전트가 하나뿐이라면 핸드오프는 문제가 되지 않습니다. 에이전트가 자기 할 일을 하고 출력을 반환하면 끝입니다. 에이전트가 두 개가 되면 형식이 필요해지기 시작합니다. 에이전트 A가 에이전트 B에게 무엇을 전달할까요? 에이전트가 열 개가 되면, 그 형식이 곧 제품이 됩니다.

저는 각 에이전트가 개별적으로는 매우 뛰어나지만, 전체 시스템은 프로덕션 (production) 환경에서 실패하는 인상적인 멀티 에이전트 (multi-agent) 데모를 출시하는 팀들을 지켜봐 왔습니다. 실패는 거의 항상 접합부 (seam)에서 발생합니다. 각자서는 괜찮았던 두 에이전트가 갑자기 함께 작동할 때 이상하게 행동하는 이유는, 한 에이전트가 다른 에이전트에게 무엇을 전달할 수 있는지 아무도 명시하지 않았기 때문입니다.

핸드오프 계약 (Handoff Contract)이란 무엇인가

핸드오프 계약은 두 에이전트 사이의 명시적이고, 타입이 지정되었으며(typed), 문서화된 인터페이스 (interface)입니다. 모든 계약에는 다섯 가지 요소가 포함되어야 합니다.

스키마 (Schema). 핸드오프 페이로드 (payload)를 설명하는 타입이 지정된 객체입니다. 자유 형식의 텍스트가 아닙니다. 채팅 메시지도 아닙니다. 이름이 지정된 필드를 가진 구조화된 레코드 (structured record)입니다.

범위 (Scope). 이 산출물이 무엇을 나타내고 무엇을 나타내지 않는지를 정의합니다. 조사 에이전트 (investigation agent)의 출력은 "여기에 제가 제안하는 근본 원인과 증거가 있습니다"라고 말합니다. "이에 대해 무엇을 해야 하는지"를 말하지 않습니다. 그것은 다른 에이전트의 역할입니다.

신뢰 신호 (Confidence signals). 수신 에이전트는 송신자가 얼마나 확신하고 있는지 알 필요가 있습니다. 높은 신뢰도는 자동 진행을 트리거할 수 있고, 낮은 신뢰도는 인간의 확인을 트리거해야 합니다.

출처 (Provenance). 송신자가 어떤 입력을 보았습니까? 어떤 데이터 소스를 사용했습니까? 어떤 도구 (tools)를 호출했습니까? 수신자는 이를 감사 (audit)할 수 있고, 인간도 이를 감사할 수 있습니다.

폴백 경로 (Fallback path). 수신자가 이 핸드오프를 처리할 수 없는 경우 어떻게 됩니까? 계약은 그것이 다음에 어디로 갈지(인간 대기열, 에스컬레이션, 데드 레터 등)를 지정합니다.

구체적인 예시

다음은 상관관계 에이전트 (correlation agent)에서 조사 에이전트 (investigation agent)로 전달되는 단순화된 핸드오프 예시입니다:

{
  "incident_id": "inc-2026-04-17-0042",
  "signal_types": ["metric", "log", "trace"],
...

조사 에이전트 (investigation agent)는 이를 대화가 아닌 데이터로 읽습니다. 조사 에이전트는 무엇을 찾아봐야 하는지 정확히 알고, 상관관계 분석 (correlation)의 신뢰도가 어느 정도인지 알며, 진전이 없을 경우 무엇을 해야 하는지도 알고 있습니다.

대규모 환경에서의 바람직한 핸드오프 (Handoff)

압박 속에서도 유지되는 몇 가지 규칙입니다.

기본적으로 단방향 (One-way by default). 에이전트 A가 에이전트 B에게 전달합니다. 문서화된 회신 계약 (return contract)이 없는 한, B는 A에게 다시 전달하지 않습니다. 양방향 핸드오프 (bidirectional handoffs)를 피해야 루프 (loop)가 발생하는 것을 막을 수 있습니다.

수신 시 멱등성 유지 (Idempotent on receive). 수신 에이전트는 동일한 핸드오프를 두 번 받더라도 이를 견뎌낼 수 있어야 합니다. 네트워크는 신뢰할 수 없으며, 에이전트는 재시도 (retry)를 수행합니다. 이를 고려하여 설계하십시오.

외부에서 관찰 가능할 것 (Observable from outside). 모든 핸드오프는 사람이 에이전트의 내부 상태를 읽지 않고도 검사할 수 있는 이벤트를 방출해야 합니다. 이를 에이전트 메시 (agent mesh)를 위한 API 로그라고 생각하십시오.

버전 관리 (Versioned). 핸드오프 스키마 (schema)를 변경할 때는 버전을 지정하십시오. 서로 다른 버전을 가진 에이전트들은 협상하거나 거부합니다. 스키마는 반드시 변경하게 되어 있습니다. 이를 계획하십시오.

팀들이 저지르는 실수

세 가지 흔한 실수입니다.

아티팩트 (artifact)의 과부하. 팀들은 "혹시 모르니까"라는 생각으로 가능한 모든 필드를 핸드오프에 집어넣습니다. 이 경우 수신 에이전트가 혼란을 겪습니다. 스키마를 최소한으로 유지하고, 필요할 때 필드를 추가하십시오.

폴백 경로 (fallback path)의 부재. 수신 측에서 실패하면 핸드오프는 사라져 버립니다. 인시던트 (incident)가 유실됩니다. 모든 계약에는 데드 레터 큐 (dead-letter queue)가 필요합니다.

데모가 일반화될 것이라는 착각. 깔끔한 핸드오프를 가진 두 개의 에이전트는 훌륭해 보입니다. 하지만 서로 다른 열 가지 핸드오프 형식을 가진 열 개의 에이전트는 분산 시스템 버그 농장처럼 보일 것입니다. 스키마를 신중하게 선택하고, 모든 곳에서 동일하게 사용하십시오.

요점 (The takeaway)

모델이 대부분의 관심을 받습니다. 하지만 핸드오프 계약 (handoff contracts)이야말로 멀티 에이전트 시스템 (multi-agent system)이 프로덕션 인시던트를 믿고 맡길 수 있는지 여부를 실제로 결정하는 요소입니다. 시스템을 구축하고 있다면, 에이전트 자체보다 에이전트 사이의 경계면 (seams)에 더 많은 시간을 투자하십시오.

작성자: Dr. Samson Tanimawo
BSc · MSc · MBA · PhD
Nova AI Ops 창립자 겸 CEO. https://novaaiops.com