AX LABS
← 블로그 에이전트 제품 설계

재시도는 신뢰성이 아니다

멱등성 없는 도구 호출은 운영 사고다

AX LABS 6분 읽기

현장에서 에이전트 PoC는 대개 잘 돈다. 사내 검색을 하고, 티켓을 만들고, CRM을 조회한다. 문제는 운영 전환 직후 나온다. 같은 티켓이 두 번 생성된다. 결재 요청은 성공했는데 에이전트는 실패로 판단한다. 외부 API가 늦어지자 모델은 같은 도구를 다시 부른다. 이때 장애의 원인은 모델이 아니라 도구 호출 하네스다.

도구 호출은 대화가 아니라 거래다

OpenAI의 function calling 문서는 도구 호출을 모델과 애플리케이션 사이의 다단계 흐름으로 설명한다. 모델은 도구 호출을 “요청”하고, 실제 코드는 애플리케이션 쪽에서 실행한 뒤 결과를 다시 모델에 전달한다. 즉 도구 호출의 신뢰성은 모델 내부가 아니라 애플리케이션 실행 계층에서 결정된다. (platform.openai.com)

그래서 에이전트 설계에서 중요한 질문은 “모델이 어떤 도구를 고르는가”가 아니다. 운영에서는 다음 질문이 먼저다.

  • 이 호출은 언제 포기할 것인가
  • 실패를 어떤 오류 코드로 돌려줄 것인가
  • 같은 요청이 다시 오면 같은 결과로 수렴하는가
  • 이미 실행된 부작용을 어떻게 확인할 것인가

에이전트 도구 호출은 프롬프트 문제가 아니라 분산 시스템 문제다.

Claude의 fine-grained tool streaming 문서도 같은 방향의 경고를 준다. 도구 입력을 빠르게 받는 대신 부분 JSON이나 유효하지 않은 JSON을 받을 수 있으므로 코드가 그 경계를 처리해야 한다. 빠른 스트리밍은 신뢰성을 대체하지 않는다. (platform.claude.com)

타임아웃은 한 번이 아니라 예산이다

타임아웃을 “도구별 30초”처럼 고정하면 체인이 길어질수록 실패한다. 에이전트는 한 번의 사용자 요청 안에서 검색, 조회, 검증, 쓰기, 알림을 순차 실행한다. 각 도구가 자기 타임아웃만 주장하면 전체 요청은 이미 사용자가 기다릴 수 없는 시간이 된다.

운영 하네스는 전체 run budget을 먼저 잡고, 그 안에서 도구별 예산을 배분해야 한다. 읽기 도구는 짧게 실패해도 된다. 쓰기 도구는 확인 단계까지 포함해야 한다. 외부 SaaS 호출은 네트워크 지연과 rate limit을 별도 범주로 봐야 한다.

설계 항목 PoC식 처리 운영식 처리
타임아웃 도구마다 고정값 run budget에서 배분
실패 응답 문자열 에러 retryable / hard_error / unknown
지연 호출 모델이 다시 판단 하네스가 재시도 정책 결정
부분 성공 실패로 뭉갬 상태 조회와 보상 로직 분리

2026년 MCP 런타임 장애 분류 논문은 MCP 서버 장애 범주에 tool invocation, schema enforcement, state management, timeouts, explicit cancellation을 포함했다. 표준 프로토콜만으로 운영 신뢰성이 자동 확보되지 않는다는 뜻이다. (arxiv.org)

재시도는 예산과 멱등성 뒤에 온다

재시도는 편리하지만 위험하다. AWS는 2026년 SDK retry 동작 업데이트에서 standard retry mode에 retry quota, exponential backoff with jitter, retryable error classification을 포함한다고 설명했다. 지속 장애 상황에서 무제한 재시도는 복구를 돕지 않고 부하를 키운다. (aws.amazon.com)

에이전트는 일반 API 클라이언트보다 더 위험하다. 모델이 실패 맥락을 보고 다시 도구를 부를 수 있고, 오케스트레이터도 자동 재시도할 수 있으며, 하위 SDK도 재시도할 수 있다. 세 층이 각각 선의로 재시도하면 쓰기 작업은 중복된다.

따라서 쓰기 도구에는 세 가지가 필수다.

  1. idempotency key: 사용자 요청, 대상 리소스, 의도, 시간 범위를 조합한 실행 키
  2. result cache: 같은 키가 다시 오면 새 실행이 아니라 이전 결과 반환
  3. status probe: timeout 이후 성공 여부를 별도 조회
  4. compensation path: 취소·정정·수동 승인 경로

AWS SDK 문서는 2026년 retry behavior에서 transient, throttling, non-retryable 오류를 구분하고, retry quota가 소진되면 재시도하지 않고 빠르게 실패하도록 설명한다. 에이전트 도구도 이 수준의 오류 분류를 가져야 한다. (docs.aws.amazon.com)

참고와 다음 행동은 한 장에 있어야 한다

운영 가능한 에이전트 설계 문서는 프롬프트보다 먼저 도구별 실행 계약서를 가져야 한다. 입력 스키마, 타임아웃 예산, 재시도 조건, 멱등성 키, 상태 조회, 보상 절차, trace 필드를 한 장에 적는다. 이 문서가 없으면 장애 때 원인을 찾지 못하고 모델만 바꾼다.

참고한 1차 출처와 최근 자료는 아래와 같다.

AX LABS는 에이전트를 데모가 아니라 운영 단위로 설계한다. 도구 호출 하네스부터 재설계할 때 PoC가 업무 시스템으로 바뀐다. AX Ops 방법론 →