핸드오프 문제: 왜 Multi-Agent Systems가 경계에서 깨지는가

발행: (2026년 3월 8일 PM 08:10 GMT+9)
7 분 소요
원문: Dev.to

Source: Dev.to

AI 에이전트가 작업을 마치고 다음 에이전트에게 넘길 때, 중요한 것이 하나 사라집니다: 그 과정에서 내려진 모든 결정의 이유.
받는 에이전트는 파일, 결과, 변형된 데이터와 같은 출력만을 보게 되며, 다음과 같은 정보를 전혀 알 수 없습니다:

  • 시도했지만 거부된 접근 방식
  • 적용된 제약 조건
  • 이미 처리된 예외 상황

이것이 바로 인수인계 문제이며, 모델 자체의 한계나 도구 버그보다 더 많은 멀티‑에이전트 실패의 원인입니다.

실제로 인계 시 일어나는 일

  • Researcher는 40개의 출처를 찾고, 8개로 필터링한 뒤, 그 이유를 오직 자신만 아는 32개를 폐기합니다.
  • Analyst는 8개를 받아 모델을 구축하고, 2개의 이상치를 의심스러운 것으로 표시하지만—그 이유는 밝히지 않습니다.
  • Writer는 분석을 받아 연구자가 이미 검토한 내용과 모순되는 결론을 씁니다.

Writer는 틀린 것이 아니라 연구자가 알고 있던 것을 모를 뿐입니다. 그 결과 최종 산출물에는 보이지 않는 버그가 포함되는데—서로 다른 방향으로 두 번 내려진 결정이며, 그 갈등을 인식하는 사람은 없습니다.

해결책: 모든 핸드오프에 decisions.json 추가

모든 에이전트 핸드오프 패키지에 파일 하나를 추가합니다:

{
  "task": "source_research",
  "completed_at": "2026-03-08T04:30:00Z",
  "decisions": [
    {
      "choice": "excluded_arxiv_papers_pre_2023",
      "reason": "outdated model architectures — not relevant to current tooling"
    },
    {
      "choice": "flagged_source_7_as_low_confidence",
      "reason": "single-author blog, no citations, contradicts 3 peer-reviewed sources"
    }
  ],
  "constraints_applied": [
    "max_sources: 10",
    "recency_cutoff: 18_months"
  ],
  "what_was_not_tried": [
    "patent_database_search — not in scope per task brief"
  ]
}

이 파일은 작업과 함께 이동합니다. 모든 하위 에이전트는 시작하기 전에 이를 읽습니다.

왜 이것이 효과적인가

  • 중복된 결정을 방지합니다. Analyst는 Researcher가 이미 결정한 내용을 다시 평가하지 않으며, 단순히 결과물만이 아니라 그 추론을 기반으로 합니다.
  • 제약 위반을 조기에 드러냅니다. Writer의 작업이 2023년 이전 논문을 인용해야 하는데 Researcher가 이를 제외했다면, 그 충돌이 최종 초안이 작성된 후가 아니라 즉시 드러납니다.
  • 감사 추적을 생성합니다. 문제가 발생했을 때 최종 상태만이 아니라 모든 의사결정 지점을 기록으로 남길 수 있습니다.

최소 구현

세 가지 간단한 규칙:

  1. 모든 에이전트는 넘겨주기 전에 decisions.json 파일을 작성합니다 — 비록 {"decisions": [], "constraints_applied": []}와 같이 비어 있어도 마찬가지입니다.
  2. 받는 모든 에이전트는 먼저 decisions.json을 읽습니다 — 다른 입력을 읽기 전에.
  3. 결정은 누적됩니다 — 각 에이전트는 파일을 교체하지 않고 자신의 결정을 추가합니다.

추가 패턴을 사용하면 전체 파이프라인에서 이루어진 모든 선택의 완전한 계보를 확인할 수 있습니다.

비용

  • 핸드오프당 파일 쓰기 한 번 추가.
  • 에이전트 시작 시 파일 읽기 한 번 추가.

이 작업을 않는 경우의 비용: 최종 출력물에 보이지 않는 충돌, 디버깅이 불가능한 실패, 그리고 20분짜리 파이프라인을 실행한 뒤 마지막에 단계 2에서 두 에이전트가 서로 모순된 것을 발견하는 고통스러운 경험.

대규모에서의 모습

5명의 에이전트가 각각 평균 3번의 핸드오프를 수행하면 파이프라인 실행당 15개의 결정 파일이 누적됩니다. 30 일 동안 매일 실행하면 450개의 결정 레코드가 됩니다.

이는 파이프라인이 올바른 판단과 잘못된 판단을 내리는 지점, 에이전트들이 일관되게 의견이 다른 지점, 그리고 제약 조건이 위배되는 지점을 이해하기 위한 학습 데이터셋입니다.

decisions.json 패턴은 단순히 협업을 해결하는 것이 아니라, 전체 시스템을 개선하는 데 필요한 가시성 데이터를 생성합니다.

인수인계 체크리스트

  • decisions.json 파일이 존재하고 최소 하나의 항목이 포함되어 있는지 확인
  • 작업 브리프의 모든 제약 조건이 문서화되어 있는지 확인
  • “시도하지 않은 내용” 섹션이 채워져 있는지 확인
  • 상위 단계의 결정이 존재할 경우 파일이 덮어쓰기되지 않고 추가되는지 확인

멀티 에이전트 시스템을 운영하면서 이러한 패턴을 실제 운영 환경에서 작동하도록 검증된 설정을 원한다면, 전체 라이브러리는 askpatrick.co/library에서 확인할 수 있습니다. 실제 배포에서 나온 패턴으로 매일 밤 업데이트됩니다.

0 조회
Back to Blog

관련 글

더 보기 »

당신의 에이전트는 작고 저위험인 HAL

개요 나는 code를 검토하고, architecture를 설계하며, faults를 찾고, designs를 비평하는 멀티‑에이전트 시스템과 작업한다. 이러한 시스템은 조용하고 … 방식으로 실패한다.