지금 이 순간 어딘가에서, 한 엔지니어링 팀이 자신들의 AI 에이전트(AI agent)에 대한 회고(retro)를 진행하고 있습니다. 데모에서는 모든 것이 완벽하게 작동했습니다. 하지만 프로덕션(production) 환경에서 한 고객이 "그냥 아무것도 하지 않았다"라고 말합니다. 팀은 프롬프트(prompt)를 다시 작성할지를 두고 논쟁 중입니다.

로그는 다른 이야기를 하고 있습니다. 에이전트는 올바르게 추론했습니다. 올바른 도구(tool)를 선택했습니다. 호출(call)을 수행했습니다. 하지만 그 호출은 타임아웃(timeout)이 발생했습니다. 아무도 이를 재시도(retry)하지 않았습니다. 동작은 실행되지 않았고, 아무에게도 알림이 가지 않았으며, 모델(model)은 네트워크 문제에 대한 책임을 떠안게 되었습니다.

이것은 우리가 목격하는 가장 흔한 에이전트 실패 사례이며, 그 어떤 프롬프트로도 이를 해결할 수 없습니다.

에이전트는 트렌치코트를 입은 이벤트 기반 시스템(event-driven systems)입니다

참신함을 걷어내고 보면, 에이전트의 동작은 세 단계로 이루어집니다: 결정(decide), 실행(act), 확인(confirm). 결정 단계가 모든 관심을 독차지합니다. 실행 단계는 대개 단순한 HTTP 호출인 fetch(url)이며, 그저 운에 맡기는 식입니다.

백엔드 엔지니어들은 웹훅(webhook)을 통해 이 영화가 어떻게 끝날지 이미 알고 있습니다. 네트워크는 실패합니다. 엔드포인트(endpoint)는 속도 제한(rate-limit)을 겁니다. 프로세스는 요청 중간에 재시작됩니다. 업계의 해답은 더 똑똑한 송신자가 아니었습니다. 그것은 지속성(persistence), 재시도(retries), 멱등성(idempotency), 관측 가능성(observability)과 같은 전달 인프라(delivery infrastructure)였습니다. 결제 기업들은 지난 10년 동안 이 인프라를 기반으로 운영되어 왔습니다.

에이전트들은 조용히 정확히 똑같은 문제를 물려받았습니다. 에이전트가 생성하는 모든 도구 호출(tool call), 콜백(callback), 알림(notification)은 반드시 도달해야 하는 이벤트(event)입니다. 그리고 오늘날 대부분의 에이전트 스택(agent stacks)은 2015년의 웹훅 통합보다도 더 부주의하게 이러한 이벤트들을 전달하고 있습니다.

유실된 동작의 비용

프롬프트가 평범하면 출력(output)도 평범합니다. 이는 눈에 보이고, 즉각적이며, 수정 가능합니다.

하지만 전달(delivery)이 조용히 실패하면, 그 비용은 지연되고 복리로 쌓입니다. 고객에게 알림이 가지 않았습니다. 워크플로(workflow)는 절반만 완료되었습니다. 그리고 '발사 후 망각(fire-and-forget)' 방식은 아무런 흔적을 남기지 않기 때문에 디버깅(debug)할 수 있는 것이 아무것도 없습니다. 상태 코드(status code)도, 시도 이력(attempt history)도 없으며, "에이전트가 잘못 결정한 것"과 "에이전트는 올바르게 결정했지만 네트워크가 삼켜버린 것"을 구분할 방법이 없습니다.

그 마지막 차이가 전부입니다. 이 차이가 없다면, 모든 인프라 실패는 당신의 모델에 대한 비난이 될 것이며, 당신은 결코 문제가 아니었던 프롬프트를 튜닝하는 데 시간을 허비하게 될 것입니다.

실제로 성과를 내는 신뢰성 체크리스트

이 중 어느 것도 생소한 것이 아닙니다. 이는 신뢰할 수 있는 웹훅 (webhook) 시스템이 사용하는 것과 동일한 규율을 에이전트 동작 (agent actions)에 적용한 것입니다.

시도하기 전에 영속화(Persist)하세요. 이벤트를 전달하려고 시도하기 전에 먼저 기록하십시오. 프로세스가 종료되거나 배포가 재시작되더라도, 의도는 살아남고 전달은 재개됩니다. 메모리에만 유지되는 모든 것은 동전 던지기(운에 맡기는 것)와 같습니다.

지수 백오프 (Exponential backoff)와 함께 재시도하고, 언제 멈출지 결정하세요. 대부분의 전달 실패는 일시적입니다: 타임아웃 (timeout), 502 오류, 속도 제한 (rate limit) 등입니다. 지수 백오프 (Exponential backoff)는 엔드포인트 (endpoint)를 계속 두드리지 않고도 이러한 문제를 해결합니다. 서킷 브레이커 (circuit breaker)는 고전하고 있는 엔드포인트를 더 악화시키는 것을 방지합니다.

재시도를 안전하게 만드세요. 최소 한 번 전달 (At-least-once delivery) 방식은 가끔 중복이 발생함을 의미하므로, 모든 전송에는 멱등성 키 (idempotency key)가 필요합니다. Mittr의 MCP 도구에서 mittr_send_event가 정확히 이 이유로 idempotencyKey 파라미터를 받는 것은, 모델이 누구에게도 이중 청구하지 않고 도구 호출 (tool call)을 재시도할 수 있도록 하기 위함입니다.

모든 시도를 로그로 남기세요. 상태 코드 (status code), 지연 시간 (latency), 응답 본문 (response body), 타임스탬프 (timestamp). "웹훅이 전혀 도착하지 않았다"는 상황은 하루 종일 grep을 돌려야 하는 일이 아니라, 30초 이내의 조회로 해결되어야 합니다.

재생(Replay) 버튼을 유지하세요. 엔드포인트가 한 시간 내내 다운되는 경우처럼, 일부 이벤트는 합리적인 재시도 예산을 초과하여 실패합니다. 이는 치명적인 오류가 아니라 복구 가능해야 합니다: 데드 레터 (dead-letter)로 처리하고, 알림을 보내고, 엔드포인트가 복구되었을 때 다시 재생하십시오.

실행(run) 단위로 상관관계를 파악하세요. 에이전트 디버깅 (Agent debugging)에는 웹훅에는 없었던 차원이 있습니다: 하나의 추론 루프 (reasoning loop)가 많은 동작을 생성한다는 점입니다. 모든 이벤트에 실행 식별자 (Mittr의 경우 agentRunId)를 태깅하면, 단일 실행에서 에이전트가 수행한 모든 것을 불러와 어떤 동작이 언제 왜 실패했는지 정확하게 확인할 수 있습니다.

레버리지(leverage)가 있는 곳

다음은 한 가지 비교를 통한 논거입니다.

프롬프트를 개선하는 것은 에이전트가 가끔 조금 더 나은 결정을 내리도록 만듭니다. 하지만 전달 계층 (delivery layer)을 개선하는 것은 에이전트가 취하는 모든 동작(모든 도구 호출 (tool call), 모든 콜백 (callback), 모든 알림 (notification))이 도착하거나, 혹은 복구 가능하고 가시적인 흔적을 남기며 떠나도록 만듭니다. 하나는 지능적인 부분에 대한 미미한 이득(marginal gain)인 반면, 다른 하나는 시스템에서 실패 유형(failure class) 전체를 제거합니다.

프롬프트는 기술 (craft)입니다. 전달 (delivery)은 보장 (guarantee)입니다. 프로덕션 시스템 (production systems)은 보장 위에 구축됩니다.

지루한 결말

프로덕션 에이전트 (production agents)에 대한 불편한 진실은, 차별화되는 작업(당신의 제품, 당신의 추론, 당신의 UX)이 차별화되지 않은 배관 작업 (plumbing): 큐 (queues), 재시도 엔진 (retry engines), 데드 레터 큐 (dead-letter queues), 감사 로그 (audit logs), 재생 시스템 (replay systems)의 더미 위에 놓여 있다는 점입니다.

당신은 그 더미를 직접 구축할 수 있습니다. 팀들은 그렇게 하며, 이를 구축하는 데는 몇 주가 걸리고 관리(babysit)하는 데는 몇 년이 걸립니다. 아니면 전달 (delivery)을 인프라 (infrastructure)로 취급하고, 에이전트를 그곳에 연결하여, 그 몇 주를 고객이 실제로 보는 시스템 부분에 사용할 수도 있습니다.

두 번째 옵션이 바로 Mittr가 존재하는 이유입니다. 당신의 에이전트는 이벤트를 보냅니다. 나머지는 저희가 합니다.

Mittr는 이벤트, 웹훅 (webhooks), 그리고 에이전트 동작 (agent actions)을 위한 전달 인프라 (delivery infrastructure)입니다: 우선적으로 영속화(persisted)되며, 백오프 (backoff)와 함께 재시도되고, 모든 시도 시 로그가 기록되며, 언제든 재생 (replayable) 가능합니다. 에이전트는 하나의 설정 블록을 통해 MCP를 통해 연결됩니다: docs.mittr.io/guides/ai-agents. 무료 티어는 월 3,000개의 메시지이며, 신용카드는 필요하지 않습니다.