실제 운영 중인 에이전트에 계측(instrument)을 수행하고 어디서 실제로 문제가 발생하는지 관찰해 보면, 대부분의 파손은 모델의 추론(reasoning)이 아니라 도구 경계(tool boundary)에서 발생합니다. 모델은 올바르게 결정했지만, 호출(call)이 잘못된 동작을 수행했거나, 두 번 실행되었거나, 혹은 조용히 절반만 성공한 경우입니다. 도구 호출(Tool calling)은 에이전트 시스템(agentic systems)의 주요 실패 지점이며, 동시에 가장 해결 가능한 지점이기도 합니다. 왜냐하면 그 해결책이 일반적인 백엔드 엔지니어링(backend engineering)이기 때문입니다.

저는 생업으로 AI 에이전트를 구축하고 있으며, 신입 엔지니어들에게 프롬프트(prompt)를 건드리기 전에 반드시 집착해야 한다고 말하는 레이어가 바로 이곳입니다.

도구 호출이 실제로 실패하는 네 가지 방식

과장된 광고를 걷어내고 보면, 운영 환경에서의 도구 실패는 네 가지 형태로 군집화됩니다:

1. 잘못된 인자 유형 (Wrong argument types): 검증(validation)을 통과하여 도구가 쓰레기 데이터로 실행되는 경우.
2. 재시도되지 않는 타임아웃 (Timeouts that aren't retried): 일시적인 오류가 영구적인 실패처럼 보이는 경우.
3. 부분적 성공 (Partial successes): 에이전트가 이를 완전한 완료로 오해하는 경우 (예: 이메일이 대기열에는 들어갔으나 발송되지 않음; 레코드는 생성되었으나 링크 단계에서 실패함).
4. 두 번 실행되는 비멱등적 쓰기 (Non-idempotent writes that execute twice): 에이전트가 재시도하기 때문에 발생하며, 이로 인해 중복 티켓, 중복 결제, 모든 것의 중복이 발생함.

이 네 가지 중 세 가지는 모델의 문제가 아닙니다. 그것은 에이전트와 도구 사이의 계약(contract) 문제입니다. 계약을 수정하면 모델을 전혀 바꾸지 않고도 에이전트의 신뢰성을 극적으로 높일 수 있습니다.

쓰기 작업에서 멱등성(Idempotency)은 타협할 수 없는 원칙입니다

이것은 제가 끝까지 고수할 원칙입니다. 쓰기 작업을 수행하는 모든 도구(레코드 생성, 메시지 전송, 트랜잭션 시작 등)는 반드시 멱등성 키(idempotency key)를 수용해야 하며, 도구 레이어에서 멱등한 동작(idempotent behavior)을 강제해야 합니다.

이유는 간단합니다: 에이전트는 재시도하기 때문입니다. 모델이 머뭇거리거나, 네트워크가 깜빡이거나, 타임아웃이 발생하면 오케스트레이터(orchestrator)는 다시 시도합니다. 멱등성 보호 장치가 없다면, 두 번째 create_ticket 호출은 두 번째 티켓을 생성합니다. 멱등성 키가 있다면, 도구는 이미 처리한 키를 확인하고 재실행하는 대신 첫 번째 실행의 캐시된 결과(cached result)를 반환합니다.

def create_ticket(payload, idempotency_key):
    cached = store.get(idempotency_key)   # 아무것도 하기 전에 확인
    if cached:
...

이 키는 호출자(caller)로부터 전달되며, 유효 기간(window)은 설정 가능합니다(24시간이 합리적인 기본값입니다). 중복된 키는 첫 번째 실행의 결과를 반환합니다. 이 단일 패턴만으로도 "에이전트가 고객에게 비용을 두 번 청구했다"와 같은 범주의 사고를 완전히 제거할 수 있습니다. 도구가 쓰기(write) 작업을 수행한다면, 반드시 멱등성 키(idempotency key)를 가져야 합니다. 예외는 없습니다.

모델이 읽을 수 있도록 에러 메시지를 만드세요

도구 호출(tool call)이 실패했을 때, 모델에 무엇을 다시 보내느냐는 실패 그 자체만큼이나 중요합니다. 가공되지 않은 스택 트레이스(stack trace)는 노이즈일 뿐입니다. 필드 수준의 설명과 올바른 형태의 예시를 포함한 구조화된 에러(structured error)는 모델이 조치를 취할 수 있는 정보가 됩니다.

잘못된 인자(argument)에 대한 다음 두 가지 응답을 비교해 보십시오. 잘못된 응답은 모델이 추측하게 만들지만, 좋은 응답은 모델이 필드, 문제점, 그리고 올바른 입력 예시를 읽음으로써 다음 턴(turn)에 스스로 수정(self-correct)할 수 있게 합니다. 도구 에러를 모델을 위해 작성하는 프롬프트(prompt)라고 생각하십시오. 실제로 그것이 바로 에러의 본질이기 때문입니다.

진정성 있게 재시도(Retry)하세요

단순한 재시도는 상황을 악화시킵니다. 백오프(backoff) 없는 즉각적인 재시도는 속도 제한(rate-limited)이 걸린 API를 '천둥 치는 들소 떼(thundering herd)' 상태로 만들어, 더 심한 속도 제한을 초래합니다. 실제로 효과가 있는 규칙은 다음과 같습니다:

• 지터(jitter)를 포함한 백오프(Backoff with jitter): 일시적인 에러(타임아웃, 429, 503) 발생 시 적용합니다. 절대 간격 없이 즉시 재시도하지 마십시오.
• 멱등성이 보장되지 않는 쓰기 작업은 재시도하지 마십시오: 도구가 멱등성을 강제하지 않는 한 마찬가지입니다. 그렇지 않다면 재시도는 중복 작업이 됩니다.
• 재시도 횟수를 제한하고 오케스트레이터(orchestrator)에 실패를 알리십시오: 무한 루프를 돌지 마십시오. 재시도에 갇힌 에이전트는 토큰만 낭비하며 아무런 진전도 이루지 못합니다.
• 재시도 가능한 에러와 종료 에러(terminal error)를 구분하십시오: 400 에러는 재시도한다고 해결되지 않지만, 503 에러는 해결될 수도 있습니다.

MCP는 통신 규격(wire)을 표준화할 뿐, 어려운 부분을 해결해주지는 않습니다

Model Context Protocol (MCP)는 진정으로 유용합니다. 이는 도구(tool)가 설명되고 호출되는 방식을 표준화하여, 수많은 글루 코드(glue code)를 제거하고 도구를 에이전트 간에 이식 가능하게 만듭니다. 하지만 MCP가 하지 않는 작업이 무엇인지 명확히 알아야 합니다. MCP는 OAuth, 속도 제한(rate-limit) 전략, 멱등성(idempotency), 부분 실패 의미론(partial-failure semantics), 또는 컴플라이언스 로깅(compliance logging)을 처리하지 않습니다. 이러한 요소들은 여전히 여러분의 도구 구현 단계에 남아 있습니다. MCP는 여러분의 도구로 요청을 깔끔하게 전달할 뿐이며, 도구를 신뢰할 수 있게(reliable) 만드는 모든 작업은 여전히 여러분의 몫입니다.

이는 우리가 다단계 에이전트 워크플로우(multi-step agent workflows)를 운영하며 배운 교훈과 직결됩니다. 실패는 에이전트 자체가 아니라, 핸드오프(handoffs)와 I/O 단계에서 집중적으로 발생합니다. 우리는 이 내용을 여기서 정리했습니다: I ran a company on AI-agent departments, here's what actually broke.

핵심 요약 (Key takeaways)

• 추론(reasoning)이 아니라, 도구 호출(tool calling)이 대부분의 프로덕션 에이전트가 실패하는 지점입니다.
• 모든 쓰기 도구(write tool)에는 호출자가 제공하는 멱등성 키(idempotency key)와 중복 제거(dedup) 윈도우가 필요합니다. 이는 중복 실행 버그를 방지합니다.
• 모델이 한 번의 턴 내에서 스스로 수정(self-correct)할 수 있도록, 예시를 포함한 구조화된 에러(structured, example-bearing errors)를 반환하세요.
• 백오프(backoff)와 지터(jitter)를 적용하여 재시도하고, 보호되지 않은 쓰기(unguarded writes)는 절대 재시도하지 마며, 루프에 상한선(cap)을 두세요.
• MCP는 인터페이스를 표준화하지만, OAuth, 속도 제한(rate limits), 멱등성(idempotency)은 여전히 여러분의 과제입니다.

FAQ

멱등성 키(idempotency keys)는 어디에서 생성되어야 하나요?
호출자(여러분의 오케스트레이터)가 생성하며, 일반적으로 논리적 작업에서 유도됩니다. 그래야 동일한 작업의 재시도가 동일한 키를 재사용할 수 있기 때문입니다. 도구는 해당 키를 기준으로 중복 제거를 강제합니다.

모든 실패한 도구 호출을 재시도해야 하나요?
재시도가 가능한 경우(타임아웃, 429, 503)에만, 그리고 반드시 백오프(backoff)와 함께 재시도해야 합니다. 400 에러와 같은 치명적 에러(terminal errors)는 재시도해도 개선되지 않으며, 보호되지 않은 쓰기(unguarded writes)는 아예 재시도해서는 안 됩니다.

더 나은 모델을 사용하면 도구 호출 실패가 줄어드나요?
더 나은 모델이 인자(arguments)를 더 정확하게 선택하기 때문에 어느 정도는 그렇습니다. 하지만 타임아웃, 부분적 성공(partial successes), 중복 쓰기(double-writes)는 어떤 모델로도 해결할 수 없는 인프라 문제입니다.

만약 당신의 에이전트(agents)가 불안정하고 도구 계층(tool layer)이 의심된다면, 그것이 원인일 가능성이 높습니다. 우리는 이 분야를 구축하고 있는 누구와도 도구 계약 패턴(tool-contract patterns)을 비교할 준비가 되어 있습니다. Shanti Infosoft에서 저희를 찾아주세요.