AI 에이전트 실패 시 가장 비용이 많이 발생하는 부분은 대개 재시도 루프(retry loop)입니다

첫 번째 실패는 대개 비용이 많이 들지 않습니다.

비용이 많이 발생하는 부분은 첫 번째 실패 이후, 상황에 아무런 변화가 없음에도 불구하고 시스템이 계속해서 시도하고, 계속해서 비용을 지출하며, 동일한 결과를 계속해서 만들어낼 때 발생합니다.

우리는 단순한 패턴에 계속 직면했습니다. 에이전트가 단계를 놓치면, 런타임(runtime)이 재시도하고, 다음 시도에서도 동일한 상태를 마주하게 되며, 비용이 청구서나 운영 로그(operator log)에 눈에 띄게 나타날 때까지 루프가 반복되는 패턴입니다. 이 지점부터 문제는 모델 품질(model-quality)의 문제가 아니라 제어 시스템(control-system)의 문제가 됩니다.

루프가 실수보다 더 치명적인 이유

단 한 번의 잘못된 단계는 복구 가능합니다. 하지만 경계가 없는 재시도 루프(unbounded retry loop)는 실수를 복리로 쌓아갑니다.

이는 토큰 소비(token spend), API 호출, 그리고 운영자의 주의력(operator attention)에 모두 해당됩니다. 또한 신뢰(trust) 측면에서도 마찬가지입니다. 시스템이 갈팡질팡한다는 평판이 한 번 쌓이면, 사람들은 더 이상 그 시스템이 실제 업무를 처리하도록 내버려 두지 않습니다.

이러한 실패 모드(failure mode)는 지루하기 때문에 놓치기 쉽습니다. 아무도 해피 패스(happy-path) 데모를 보면서 세 번째 동일한 에러가 발생한 이후에 어떤 일이 벌어질지 생각하지 않습니다. 하지만 바로 그 지점에 진짜 비용이 숨어 있습니다.

우리가 처음에 시도했던 것들

뻔한 조치들은 대개 잘못된 방향입니다:

• 프롬프트(prompt)를 더 길게 만들기
• 일반적인 재시도(generic retry) 추가하기
• 타임아웃(timeout) 늘리기
• 모델이 "더 많이 추론(reason more)"하게 하기
• 약간 다른 어구로 동일한 명령을 다시 실행하기

이러한 변화들은 데모를 더 좋아 보이게 만들 수는 있지만, 갇혀버린 루프를 해결하지는 못합니다.

환경이 변하지 않았다면, 재시도는 종종 동일한 실수의 두 번째 복사본일 뿐입니다.

실제로 효과가 있었던 것

해결책은 더 똑똑한 언어가 아니었습니다. 더 엄격한 경계(stricter boundaries)였습니다.

우리는 런타임(runtime)이 계속 진행하기 전에 다음 네 가지 질문에 답하도록 만들어야 했습니다:

1. 예산(budget)은 얼마인가?
2. 무엇을 성공으로 간주할 것인가?
3. 검증기(verifier)는 무엇인가?
4. 동일한 실패가 반복될 때 어떤 일이 발생하는가?

작은 정책 블록(policy block)만으로도 이를 구체화하기에 충분한 경우가 많습니다:

{
  "budget_cap": 250,
  "max_attempts": 3,
...

이것은 야심 차게 들리지 않습니다. 바로 그 점이 핵심입니다.

가장 큰 신뢰성 향상은 반복되는 실패를 진행 상황으로 취급하기를 거부하는 데서 왔습니다. 런타임(runtime)이 동일한 차단 요소(blocker)를 연속으로 두세 번 감지하면, 다음 재실행이 어떻게든 다를 것이라고 가장하는 대신 중단할 수 있는 권한을 부여받았습니다.

영수증(Receipts)이 중요한 이유

영수증은 실행 과정을 모호한 이야기에서 검증 가능한 사실로 바꿔줍니다.

영수증에는 다음 내용이 포함되어야 합니다:

• 에이전트가 무엇을 시도했는지
• 무엇이 변했는지
• 무엇이 실패했는지
• 실행이 왜 중단되었는지

이것이 없다면, 루프(loop)가 신뢰를 생성하는 요약문 속에 숨어버릴 수 있습니다. 영수증이 있다면 정확한 중단 지점을 확인하고, 다음 조치가 인간의 개입(human intervention)이어야 하는지, 다른 도구(tool)를 사용해야 하는지, 아니면 아무런 조치도 취하지 말아야 하는지를 결정할 수 있습니다.

이것이 바로 이러한 종류의 작업이 프롬프트 엔지니어링(prompt engineering)보다는 운영(operations)에 더 가깝게 느껴지는 이유이기도 합니다.

트레이드오프 (The tradeoff)

더 엄격한 제어는 시스템이 더 일찍 중단됨을 의미합니다.

에이전트가 마찰을 뚫고 나아가기를 원할 때는 이것이 짜증스럽게 느껴질 수 있습니다. 하지만 더 일찍 중단하는 것이 길고 맹목적인 재시도 시퀀스(retry sequence)보다 비용이 적게 듭니다. 더 중요한 것은, 이것이 운영자(operator)의 신뢰를 보존한다는 점입니다.

제한된(bounded) 에이전트는 "절대 포기하지 않는" 에이전트보다 덜 화려해 보일 수 있습니다. 하지만 훨씬 더 사용하기 좋습니다.

이것이 바로 우리가 MartinLoop에서 계속해서 되풀이하는 제어 계층(control-layer) 접근 방식의 핵심입니다. 즉, 런타임은 언제 멈춰야 하는지, 언제 도움을 요청해야 하는지, 그리고 언제 발생한 일을 기록해야 하는지를 알아야 합니다.

다음에 주목하고 있는 것

다음 개선 사항은 더 많은 재시도가 아닙니다.

런타임이 다음 항목들을 구분할 수 있도록 하는 더 나은 실패 분류(failure classification)입니다:

• 권한 누락 (missing permission)
• 오래된 상태 (stale state)
• 도구 불일치 (tool mismatch)
• 외부 장애 (external outage)
• 실제 작업 완료 (real task completion)

이러한 항목들이 명확히 구분되면, 시스템은 동일한 명령을 재활용하는 대신 더 나은 다음 단계를 선택할 수 있습니다.

이것이 자율적으로 보이는 에이전트와 실제로 운영 가능한(operable) 에이전트 사이의 경계입니다.

당신의 런타임은 여전히 어떤 형태의 실패를 너무 많이 재시도하도록 내버려 두고 있습니까?