재시도 루프가 에이전트 작업에서 대개 비용이 많이 드는 이유

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

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

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

루프가 실수보다 더 해로운 이유

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

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

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

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

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

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

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

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

실제로 효과가 있었던 것

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

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

1. 예산(budget)은 얼마인가?
2. 무엇을 성공으로 간주할 것인가?
3. 검증기(verifier)는 무엇인가?
4. 동일한 실패가 반복되면 어떻게 되는가?

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

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

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

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

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

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

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

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

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

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

트레이드오프 (The tradeoff)

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

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

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

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

다음에 주목하고 있는 것

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

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

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

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

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

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