tool-calling 에이전트의 턴 단위 실패 탐지

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

도구 호출 에이전트의 실패는 개별 trace 행이 아니라 한 턴 전체의 순서에서 드러나는 경우가 많습니다. 동의 거부를 예외 대신 반환값으로 처리하면 모델이 이를 무시하고 실제로 전송하지 않았는데도 완료를 서술할 수 있으며, `group_id=None` 같은 인자 누락은 게이트 단위 테스트만으로 잡히지 않았습니다. 작성자는 LLM judge 없이 모든 턴을 검사하는 결정론적 detector를 만들고, 도구 호출 없는 작업 서술·인자 누락에 따른 반복 호출·그룹 스레드 무응답을 탐지 대상으로 삼았습니다. 다만 예외 처리는 거부 사유를 잃게 만들고 `queued=true, sent=false` 같은 지연 전송을 실패로 오인할 수 있어, 상태 의미를 보존한 구조화된 결과와 턴 단위 검증을 함께 설계해야 합니다.

실용적 조언

도구 호출의 입력과 반환값만 저장하지 말고 한 턴 안에서 모델의 주장과 실제 호출 순서를 함께 비교하는 규칙을 두는 편이 안전합니다. ‘생성했다’ 같은 일반적인 write 결과가 특정 업무 완료를 자동으로 만족시키지 않도록 작업별 필수 도구와 필수 인자를 명시해야 합니다. 이렇게 해야 거의 모든 턴에서 발생하는 공통 write가 성공 근거로 잘못 사용되는 문제를 줄일 수 있습니다.
`sent=false` 하나만으로 실패를 판정하지 말고 `reason`, `queued`, 실제 전달 완료 여부를 분리된 상태로 보존해야 합니다. 동의 거부와 릴레이 대기 상태는 후속 행동이 다르므로 모델이 대체 채널을 선택할 수 있는 정보와 탐지기가 사용할 판정 기준을 각각 유지해야 합니다. 특히 `group_id`처럼 게이트 판정에 필요한 인자가 누락되지 않았는지 정상 동의 사례와 함께 검증해야 합니다.

섹션별 상세

전송 도구가 동의 거부를 예외가 아닌 `{"sent": false, "reason": "no_consent"}` 결과로 반환하면서 에이전트 실행이 정상 턴으로 이어진 사례가 제시됐습니다. 모델은 도구 결과를 읽고 다음 단계로 진행한 뒤 세 단계 후에 실제 전송이 끝났다는 취지의 문장을 생성했습니다. 원인은 한 sender가 `group_id=None`을 게이트에 넘겨 데이터베이스의 기존 동의를 모두 보이지 않게 만든 구현 오류였고, 게이트 자체의 단위 테스트는 정상 경로만 검증해 통과했습니다.

모델의 자연어 서술과 실제 도구 실행 사이의 불일치는 개별 이벤트만 읽을 때 놓치기 쉽다는 경험이 공유됐습니다. 도구 호출 없이 모델이 쓰기 작업을 완료했다고 말하거나, 인자가 빠져 같은 read를 여덟 번 실행하거나, 그룹 스레드가 응답하지 않는 현상은 각각의 trace 행만 보면 깨끗해 보였습니다. 전체 trace를 처음부터 끝까지 읽어야만 한 턴의 입력·호출·결과·후속 서술이 서로 맞지 않는다는 사실이 드러났습니다.

이를 잡기 위해 작성자는 LLM judge 대신 한 턴 전체를 순서대로 읽는 결정론적 detector를 만들었습니다. 모든 턴에 실행할 수 있도록 샘플링 기반 평가를 피했고, 초기 규칙에서는 일반적인 write가 ‘lead를 생성했다’는 서술을 만족시키는 문제가 발생했습니다. 거의 모든 턴이 timeline entry를 기록한다는 특성 때문에 도구 호출 없이 생성됐다는 서술도 정상으로 분류됐으며, 반대로 규칙에서 sender를 빠뜨리자 정상 턴이 오류 보고서의 대부분을 차지했습니다.

도구가 실패하면 예외를 발생시키는 단순한 수정은 거부 이유를 문자열화해 모델이 대체 채널을 안내할 기회를 없앨 수 있다는 반론이 제기됐습니다. 또한 `{"queued": true, "sent": false}`처럼 릴레이가 나중에 전달하는 도구에서는 `sent=false`만 검색하면 성공한 대기 상태를 실패로 오인하게 됩니다. 따라서 MCP server나 vendor SDK처럼 내부 동작을 소유하지 않은 도구에서는 예외로 감싸는 방식과 구조화된 거부 결과를 인밴드로 처리하는 방식 사이의 선택이 핵심 쟁점으로 남았습니다.

용어 해설

도구 호출 에이전트(Tool-calling Agent): — 모델이 외부 도구의 입력을 구성하고 호출 결과를 해석해 다음 행동을 선택하는 에이전트입니다. 도구가 반환한 성공·거부·지연 상태를 모델의 자연어 응답과 연결해야 하므로 호출 기록과 실제 결과를 함께 추적해야 합니다.
컴플라이언스 게이트(Compliance Gate): — 메시지 전송이나 데이터 변경 같은 작업을 실행하기 전에 동의 여부와 정책 조건을 검사하는 제어 계층입니다. 조건을 충족하지 못하면 예외 대신 거부 결과를 반환할 수 있어 후속 로직이 그 이유를 보존해야 합니다.
턴 단위 실패 탐지(Turn-level Failure Detection): — 에이전트의 한 턴에서 발생한 도구 호출, 반환값, 모델 서술을 순서대로 읽어 불일치를 찾는 방식입니다. 개별 관찰값이 정상이어도 전체 실행 흐름에서만 드러나는 누락 호출, 반복 호출, 무응답을 포착하는 데 초점을 둡니다.
OpenTelemetry(OTel): — 분산 시스템의 실행 정보를 공통 형식으로 수집하고 전송하는 관측성 프레임워크입니다. 이 글에서는 에이전트 턴과 도구 호출을 추적하는 어댑터의 연결 대상으로 제시되며, 실패 탐지 결과를 기존 trace에 붙이는 역할을 합니다.

코드 예제

json

{"sent": false, "reason": "no_consent"}

동의 검사를 통과하지 못한 전송 도구가 예외 대신 반환한 거부 결과입니다.

json

{"queued": true, "sent": false}

릴레이가 나중에 전송하는 구조에서 작업이 대기열에 들어갔지만 아직 직접 전송되지는 않은 상태를 나타냅니다.

언급된 도구

postflight추천링크

에이전트의 한 턴을 순서대로 읽어 도구 호출과 모델 서술 사이의 실패를 탐지하는 오픈소스 도구입니다.

Langfuse중립

postflight 결과를 연결할 수 있는 관측성 플랫폼으로 제시됐습니다.

OTel중립

postflight trace를 연결하기 위한 어댑터 대상으로 제시된 관측성 표준입니다.

언급된 리소스

GitHubBase-Homes/postflight