협업이 새로 만드는 실패축
Anthropic이 자사 리서치용 멀티에이전트 시스템을 운영하며 정리한 실패 유형은 프롬프트 품질보다 조율 실패에 몰려 있습니다. 서브에이전트가 같은 질의를 중복 실행하거나, 단순한 확인 요청에도 서브에이전트를 과다하게 생성하거나, 근거가 충분한데도 검색을 계속 이어가는 사례가 대표적입니다. 도구 설명이 모호하면 서브에이전트가 완전히 다른 경로로 새기도 해서, 도구 인터페이스 설계는 프롬프트 설계와 같은 무게의 실패 원인으로 다뤄야 합니다.
장애를 재현 가능한 단위로 자르는 관측 모델
에이전트 호출은 같은 프롬프트를 다시 넣어도 다른 경로로 흐르는 비결정성을 갖고 있어, 로그 한 줄만으로는 원인을 특정하기 어렵습니다. OpenTelemetry의 GenAI 시맨틱 컨벤션은 최상위 invoke_agent 스팬 아래 각 LLM 호출을 chat 스팬으로, 각 도구 실행을 execute_tool 스팬으로 중첩시켜 추론 사슬 전체를 트레이스 하나로 묶습니다. gen_ai.usage.input_tokens·output_tokens·finish_reasons 같은 속성을 스팬에 남기면, 어느 서브에이전트의 몇 번째 도구 호출에서 토큰이 튀었는지, 왜 응답이 끊겼는지를 로그 전수 검색 없이 트레이스 뷰 하나로 좁힐 수 있습니다.
장애 재현부터 재발 방지까지: 멀티에이전트 디버깅 로드맵
체계를 설계하기 전에 통과 기준부터 수치로 박아둡니다. 트레이스 커버리지(서브에이전트 호출·도구 실행에 스팬이 붙는 비율) 100%, 서브에이전트 간 중복 호출률 10% 이하, 평균 복구 시간(MTTR) 30분 이내, 최종 실패 후 사람 개입률 15% 이하를 출발 기준으로 둡니다. 기준이 없으면 트레이스를 도입해도 눈으로 보기 좋다는 인상 평가에서 멈춥니다.
가장 흔한 실패는 서브에이전트 간 중복 작업입니다. 리드 에이전트가 하위 작업을 명확히 분할하지 않으면 두세 개 서브에이전트가 같은 질의를 반복 실행해 토큰과 지연을 낭비합니다. 두 번째 실패는 과다 생성으로, 단순한 확인 요청에도 다수 서브에이전트를 병렬로 띄우면 조율 비용이 작업 자체보다 커집니다.
세 번째는 종료 조건 부재로 인한 끝없는 검색입니다. 근거가 충분히 모인 뒤에도 검색을 이어가거나, 신뢰도 낮은 콘텐츠를 근거로 채택하는 경우가 여기 속합니다. 네 번째는 도구 설명이 모호해 서브에이전트가 의도와 다른 도구를 호출하는 경로 이탈로, 프롬프트를 아무리 다듬어도 도구 인터페이스 자체가 부정확하면 반복됩니다.
복구는 전체 재시도보다 격리를 우선합니다. 실패한 서브에이전트 하나만 체크포인트에서 재실행하고 나머지 서브에이전트의 결과는 보존해 작업 전체를 처음부터 되돌리지 않습니다. 재시도가 2회를 넘으면 사람 확인 게이트로 넘기고, 그래도 반복되면 서브에이전트 수를 줄인 안전 모드로 축소 실행합니다.
배포 전에는 서브에이전트 하나를 의도적으로 타임아웃시키거나 빈 응답을 주는 장애 주입 시나리오를 통과시켜야 합니다. 로그는 invoke_agent 스팬 ID, 하위 execute_tool 스팬 ID, 토큰 사용량, 재시도 횟수, 종료 사유(finish_reason)를 고정 스키마로 남기고, 사용자 식별정보가 담긴 도구 인자는 저장 전에 마스킹합니다.
주간 단위로 실패 트레이스 상위 유형을 추려 회귀 테스트셋에 역주입하면 같은 조율 실패가 다음 릴리스에서 자동으로 걸러집니다. 프롬프트·도구 설명 변경과 오케스트레이션 로직 변경의 로그를 분리해 남겨야, 어떤 변경이 중복 호출률을 낮췄는지 나중에 되짚을 수 있습니다.
핵심 실행 포인트
멀티에이전트 장애의 대부분은 모델이 아니라 조율과 도구 인터페이스에서 시작됩니다. 트레이스 커버리지 100%·중복 호출률 10% 이하·MTTR 30분 이내를 기준으로 삼고, invoke_agent·execute_tool 스팬으로 실패 지점을 좁힌 뒤 격리 재실행과 안전 모드 축소로 복구하면, 다음 장애도 같은 절차로 처리할 수 있습니다.