통신과 핸드오프

멀티에이전트 시스템의 품질은 개별 agent의 지능보다 handoff 품질에 더 크게 좌우됩니다. 좋은 handoff는 대화를 길게 넘기는 것이 아니라, 다음 담당자가 바로 일할 수 있는 작업 패킷을 만드는 일입니다.

통신 방식 선택

실전에서는 "workflow 내부는 shared state, agent 간은 message/event"처럼 혼합하는 경우가 많습니다.

이벤트 드리븐 에이전트 패턴: MCP 서버 푸시

2026년 3월 기준으로 MCP 서버가 에이전트에 이벤트를 푸시하는 패턴이 등장하고 있습니다. 대표적으로 Claude Code의 --channels 플래그는 MCP 서버가 발행하는 이벤트를 에이전트가 구독하여 반응하는 구조를 지원합니다.

이 패턴의 핵심은 agent가 polling하지 않고, MCP 서버의 상태 변경을 구독 기반으로 수신한다는 점입니다. 파일 변경 감지, CI 파이프라인 완료 알림, 외부 서비스 웹훅 등을 agent workflow에 자연스럽게 연결할 수 있습니다.

대규모 이벤트 스트리밍 아키텍처

위의 이벤트 드리븐 패턴은 MCP 서버 푸시처럼 단일 채널 수준의 통신에 적합합니다. 하지만 수십~수백 개의 worker agent가 분산 환경에서 비동기로 협력해야 하는 대규모 시스템에서는 더 견고한 이벤트 스트리밍 인프라가 필요합니다.

Kafka/Pub-Sub 기반 에이전트 오케스트레이션

메시지 브로커(Kafka, Pub/Sub, NATS 등)를 에이전트 간 통신 백본으로 사용하면 다음 이점을 얻습니다.

Saga 패턴: 멀티에이전트 트랜잭션

여러 worker agent가 순차적으로 side effect를 일으키는 작업에서는 중간 실패 시 이전 단계를 **보상(compensation)**해야 합니다. Saga 패턴은 각 단계에 보상 액션을 정의하여, 분산 트랜잭션 없이도 일관성을 유지합니다.

type SagaStep = {
  name: string
  execute: () => Promise<void>
  compensate: () => Promise<void>
}

async function executeSaga(steps: SagaStep[]) {
  const completed: SagaStep[] = []

  for (const step of steps) {
    try {
      await step.execute()
      completed.push(step)
    } catch (error) {
      // 실패 시 완료된 단계를 역순으로 보상
      for (const done of completed.reverse()) {
        await done.compensate()
      }
      throw new SagaFailedError(step.name, error)
    }
  }
}

메시지 순서 보장

에이전트 간 이벤트 순서가 뒤바뀌면 상태 불일치가 발생합니다.

partition key 전략 예시: run_id를 partition key로 사용하면 같은 실행의 모든 이벤트가 순서대로 처리됩니다. 서로 다른 run은 독립적으로 병렬 처리되어 처리량이 확보됩니다.

Dead Letter Queue (DLQ)

worker agent가 처리에 실패한 이벤트를 무한 재시도하면 전체 파이프라인이 막힙니다. DLQ는 실패한 이벤트를 별도 큐로 격리하여 정상 흐름을 보호합니다.

type DeadLetterRecord = {
  originalTopic: string
  originalEvent: AgentEvent
  failureReason: string
  retryCount: number
  lastFailedAt: string   // ISO 8601
  agentId: string
  runId: string
}

이벤트 스트리밍 도입 판단 기준

handoff 패킷의 최소 구성

handoff에는 최소한 아래 정보가 들어가야 합니다.

예시: handoff envelope

{
  "goal": "환불 가능 여부를 판단하고 초안 응답을 작성한다",
  "contextSummary": "고객은 결제 후 3일 이내 환불 요청, 사용량은 0건",
  "constraints": ["환불 확정 금지", "정책 링크 필수"],
  "evidence": [
    { "source": "refund-policy-v3", "excerpt": "미사용 건은 7일 내 환불 가능" }
  ],
  "outputContract": {
    "fields": ["classification", "answerDraft", "confidence", "needsHumanReview"]
  }
}

컨텍스트 압축 전략

1. 전체 대화 전달을 기본값으로 두지 않는다

길어진 대화를 그대로 넘기면 token 비용만 늘고, downstream agent가 핵심 신호를 잃기 쉽습니다.

2. 요약은 "사실, 가설, 미해결 질문"으로 나눈다

이 세 칸으로 요약하면 downstream agent가 무엇을 믿어도 되는지 빠르게 파악할 수 있습니다.

3. 근거는 별도 배열로 유지한다

자연어 요약 안에 근거가 섞여 있으면 재검증이 어려워집니다. 요약과 evidence를 분리하면 evaluator나 human reviewer가 빠르게 판정할 수 있습니다.

통신 구조 예시

이 구조에서 핵심은 각 agent가 전체 대화를 아는 것이 아니라, 다음 결정을 위해 필요한 정보만 받는 것입니다.

shared state와 message passing의 경계

state에는 재실행과 관측성에 필요한 최소 정보만 두고, 실제 작업 의미는 message 안에 담는 편이 명확합니다.

Human Handoff 설계

agent가 사람에게 작업을 넘기는 것도 handoff의 한 형태입니다. 자동화 경계를 넘을 때 언제, 어떤 정보를 담아 사람에게 넘길지 미리 설계해야 합니다.

Human Gate 조건

다음 조건 중 하나라도 해당하면 human gate를 두는 편이 좋습니다.

• 외부 발송, 결제, 권한 변경처럼 되돌리기 어려운 작업
• 품질보다 책임 소재가 중요한 작업
• 모델 confidence만으로는 정당화할 수 없는 작업
• 법률, HR, 재무처럼 규제 리스크가 큰 작업
• 복구 전략(retry, fallback)이 모두 소진된 고위험 상황

Human Approval Queue 구성

사람에게 넘긴다고 문제가 해결되는 것은 아닙니다. handoff payload가 빈약하면 운영자는 더 느리게 판단합니다.

사람 승인 큐에는 최소한 다음이 필요합니다.

실패 모드

ADR 스타일 결론

실무 체크리스트

• handoff payload에 목표와 금지 사항이 모두 포함되는가
• 전체 대화를 그대로 넘기지 않고 요약 단계가 있는가
• 근거와 요약이 분리되어 있는가
• 메시지마다 request id 또는 task id가 있는가
• shared state와 message payload의 책임이 분리되어 있는가

다음에 읽을 장

• 상태 관리와 메모리 시스템
• 라우팅과 디스패치
• MCP와 에이전트 간 프로토콜