내가 목격한 가장 비용이 많이 드는 AI 에이전트의 실패는 모델의 실패가 아니었습니다.

그것은 바로 '침묵의 실패 (silent failures)'였습니다.

에이전트는 정상적으로 보였습니다. 워크플로우 (workflow)는 여전히 실행 중이었고, 토큰 (tokens)도 계속 소비되고 있었습니다.

하지만 에이전트는 이미 의미 있는 진전을 멈춘 상태였습니다.

시간이 흐르면서 나는 동일한 프로덕션 이슈들을 반복해서 마주했습니다:

• 무한 루프 (Infinite loops)
• 재시도 폭풍 (Retry storms)
• 침묵의 정체 (Silent stalls)
• 성공적인 응답 뒤에 숨겨진 도구 실패 (Tool failures)
• 원래 목표에서 벗어나는 에이전트 (Agents drifting away)
• 에이전트가 실제로 무엇을 하고 있는지에 대한 가시성 부족 (No visibility)

더 나은 프롬프트 (prompt)도 이러한 문제들을 해결해주지 못했습니다.

결국 해결책은 더 많은 워크플로우 로직 (workflow logic)을 추가하는 것이 아니라, 에이전트 주변에 런타임 감독 계층 (runtime supervision layer)을 두는 것이었습니다.

문제 (The Problem)

대부분의 에이전트 프레임워크 (agent frameworks)는 에이전트를 실행시키는 데 집중합니다.

하지만 프로덕션 팀은 다른 질문들에 관심을 가집니다:

• 왜 이 실행이 멈춰 있는가?
• 여전히 진전이 있는가?
• 안전하게 일시 중지할 수 있는가?
• 나중에 다시 재개할 수 있는가?
• 완전히 종료해야 하는가?

런타임 (runtime)이 로그 (logs)만을 노출할 때 이러한 질문들은 어려워집니다.

런타임 감독 (Runtime Supervision)

효과적이었던 한 가지 설계 결정은 감독 (supervision)을 에이전트 로직 (agent logic)에서 분리하는 것이었습니다.

모든 가드레일 (guardrail)을 워크플로우 그래프 (workflow graph) 내부에 직접 삽입하는 대신, 전용 런타임 계층 (runtime layer)이 실행을 관찰하고 운영 규칙을 강제합니다.

이를 통해 에이전트 워크플로우는 단순하게 유지하면서도, 감독 로직 (supervision logic)은 독립적으로 발전시킬 수 있습니다.

런타임은 다음을 담당합니다:

• 루프 탐지 (Loop detection)
• 재시도 관리 (Retry management)
• 예산 강제 (Budget enforcement)
• 일시 중지 및 재개 작업 (Pause and resume operations)
• 실행 체크포인트 (Execution checkpoints)
• 중단 사유 분류 (Stop reason classification)
• 실시간 텔레메트리 (Live telemetry)

그 결과, 에이전트의 행동을 수정하지 않고도 운영상의 관심사를 변경할 수 있는 시스템이 구축됩니다.

명시적인 중단 사유 (Explicit Stop Reasons)

내가 빠르게 배운 교훈 중 하나는 다음과 같습니다:

"실패함 (Failed)"은 유용한 상태가 아닙니다.

실행 중단은 그 이유를 스스로 설명할 수 있어야 합니다.

예시:

• LOOP_DETECTED (루프 탐지됨)
• BUDGET_EXCEEDED (예산 초과)
• RETRY_LIMIT_REACHED (재시도 제한 도달)
• TOOL_FAILURE (도구 실패)
• TIMEOUT (시간 초과)
• USER_PAUSED (사용자에 의해 일시 중지됨)
• USER_KILLED (사용자에 의해 종료됨)

복구 경로는 실행이 중단된 이유에 따라 달라집니다.

해당 정보가 없다면 운영자(operators)는 추측할 수밖에 없습니다.

의미론적 루프 탐지 (Semantic Loop Detection)

대부분의 루프 탐지(loop detection) 구현은 단계 수(step counts)를 사용합니다.

문제는 에이전트가 기술적으로 루프를 돌고 있지는 않더라도, 잘못된 목표를 향해 진행할 수 있다는 점입니다.

실행 과정에서 원래의 목표로부터 벗어난 계획을 확신을 가지고 수행하며 20단계를 소비할 수도 있습니다.

더 효과적이었던 방법은 주기적으로 다음과 같이 질문하는 것이었습니다:

"우리가 몇 단계 전보다 목표에 의미 있게 더 가까워졌는가?"

이 방식은 비용이 많이 들기 전에 드리프트(drift, 편차)를 포착합니다.

일시 중지 (Pause) vs 종료 (Kill)

이 둘은 동일한 작업이 아닙니다.

일시 중지 (Pause)

일시 중지는 실행 상태(execution state)를 보존합니다.

실행은 중단되지만, 런타임(runtime)은 최신 체크포인트(checkpoint)를 유지합니다.

재개(Resume)는 단순히 마지막으로 커밋된 상태를 로드하여 계속 진행합니다.

종료 (Kill)

종료는 실행을 완전히 종료합니다.

활성 상태(active state)가 제거되며 실행을 계속할 수 없습니다.

이 차이점은 장시간 실행되는 워크플로(workflows)를 디버깅할 때 중요해집니다.

작업 전 체크포인트 (Checkpoint Before Action)

모든 외부 작업 전에:

• API 호출 (API calls)
• 브라우저 상호작용 (Browser interactions)
• 이메일 전송 (Email delivery)
• 데이터베이스 쓰기 (Database writes)

런타임은 체크포인트를 생성합니다.

성공적인 실행은 체크포인트를 삭제합니다.

만약 프로세스가 충돌(crash)하면, 다음 실행은 무엇이 진행 중이었는지 즉시 알 수 있습니다.

이것은 침묵하는 실패(silent failures)를 복구 가능한 실패(recoverable failures)로 바꾸어 놓았습니다.

재시도 폭풍 방지 (Retry Storm Protection)

하나의 실패한 의존성(dependency)이 수천 개의 낭비되는 요청을 만들어낼 수 있습니다.

가장 효과적이었던 패턴은 다음과 같습니다:

• 지수 백오프 (Exponential backoff)
• 재시도 예산 (Retry budgets)
• 서킷 브레이커 (Circuit breakers)

이 세 가지가 모두 없다면, 에이전트는 아무런 진전 없이 토큰만 소모하며 반복적으로 실패하는 경향이 있습니다.

실시간 텔레메트리 (Live Telemetry)

로그(Logs)는 무엇이 일어났는지를 알려줍니다.

운영자들은 보통 지금 당장 무엇이 일어나고 있는지를 알아야 합니다.

런타임은 다음 사항들을 지속적으로 추적합니다:

• 현재 작업 (Current task)
• 현재 단계 (Current step)
• 활성 도구 (Active tool)
• 실행 상태 (Execution status)
• 최근 전환 (Recent transitions)

목표는 에이전트 실행이 사고가 발생한 후가 아니라, 실행 중인 동안 관찰 가능(observable)하게 만드는 것입니다.

마치며

AI 에이전트를 구축하는 것은 매달 점점 더 쉬워지고 있습니다.

프로덕션 장애(production failures)를 견뎌낼 수 있는 에이전트를 구축하는 것은 여전히 어렵습니다.

제가 배운 가장 중요한 교훈은 신뢰성 문제(reliability problems)가 대개 모델 외부에서 발생한다는 것입니다.

이러한 문제들은 재시도(retries), 체크포인트(checkpoints), 도구 실패(tool failures), 실행 제어(execution control), 그리고 감독(supervision) 단계에서 나타납니다.

AI 에이전트를 실행하는 동안 여러분이 겪었던 가장 힘들었던 프로덕션 장애는 무엇이었나요?