63시간, 4,800사이클/시, $4,200
숫자부터 놓고 시작하자. Sattyam Jain의 에이전트는 금요일 밤에 배포됐고, 월요일 아침 대시보드를 열기 전까지 멈추지 않았다. 같은 툴을 호출하고, 429 에러를 받고, 다시 계획을 세우고, 같은 툴을 다시 호출했다. 시간당 4,800사이클. 루프 어디에도 '멈춰라'는 코드가 없었다. Operator Collective가 집계한 다른 사례에선 멀티에이전트 리서치 툴이 11일을 돌아 $47,000짜리 OpenAI 인보이스를 남겼다. 이건 예외적인 버그가 아니다. 안전장치 없이 프로덕션에 올리면 구조적으로 발생하는 실패 패턴이다.
왜 LLM은 멈추지 않는가
모델이 멍청해서가 아니다. 컨텍스트가 문제다. turn 50쯤 되면 모델은 50개의 tool_call → error 쌍을 보고 있다. LLM은 카운팅에 약하다. '이게 몇 번째 시도인지'를 구조적으로 파악하기 어렵고, 시스템 프롬프트에 '포기하지 마라, 계속 시도해라'는 지시가 있으면 더욱 그렇다. 그 지시는 일시적 503에는 맞는 말이다. 영구적 429에는 재앙이 된다. 429: rate_limited라는 에러 메시지는 '이미 12번 같은 실패를 했다'는 정보를 담고 있지 않다. 모델 입장에선 매 턴이 첫 번째 실패처럼 보인다. 해결책은 프롬프트가 아니라 디스패처 코드 안에 있다.
안전장치 1: per-tool 재시도 예산
가장 단순하고 가장 먼저 넣어야 하는 가드레일이다. 툴 이름을 키로, 호출 횟수를 값으로 갖는 딕셔너리 하나면 된다. 상한선(RETRY_CAP = 3)을 넘으면 실제 툴을 호출하지 않고, 모델의 메시지 리스트에 ERROR: get_weather exceeded 3 retries를 직접 밀어 넣는다. 모델은 이제 '이 툴은 소진됐다'는 정보를 받고 다른 전략을 선택하거나 포기한다. 6줄짜리 코드가 retry storm을 차단한다. 튜토리얼 어디에도 없는 6줄이다.
안전장치 2: 핑거프린트 루프 감지
per-tool 재시도 예산은 단일 툴 반복은 잡는다. 잡지 못하는 건 tool_a → tool_b → tool_a → tool_b 같은 교차 루프다. Sattyam Jain의 $4,200 케이스가 정확히 이 형태였다. 해결 방법은 슬라이딩 윈도우다. 각 툴 호출을 이름 + 정렬된 args로 해싱해 최근 N개 핑거프린트를 추적한다. 같은 핑거프린트가 윈도우 안에서 2회 이상 등장하면 트레이스를 즉시 종료한다. deque(maxlen=6) 하나, 7줄이면 된다. 전역 셋(set)으로 구현하면 안 된다. 정상적인 워크플로우에서도 같은 툴을 여러 번 쓸 수 있기 때문이다. '최근'이라는 개념이 핵심이다. 윈도우 사이즈는 트레이스 데이터에서 튜닝하되, 3~5개 툴을 쓰는 단일 태스크 에이전트엔 6이 디폴트로 충분하다.
안전장치 3: 트레이스 비용 상한
루프 감지가 대부분의 실패를 막는다. 막지 못하는 건 개별 호출이 모두 정상인데 누적 비용이 임계치를 넘는 케이스다. $4,200 청구서의 핵심이 이것이다. 개별 API 응답에 포함된 usage 객체에서 prompt_tokens와 completion_tokens를 읽어 누적 비용을 계산하고, 설정한 상한(MAX_USD = 0.50)을 초과하면 즉시 ABORTED를 반환한다. 50센트짜리 상한이 어이없어 보일 수 있다. 프로덕션에선 라우트별로 다르게 설정하면 된다. 리서치 에이전트와 챗봇 에이전트의 상한이 같을 이유는 없다. 중요한 건 상한이 존재한다는 것이다. 상한이 없는 에이전트는 예산이 없는 팀원이다.
Claude Code 슬래시 커맨드로 안전망을 팀 표준으로 만들기
세 가지 가드레일을 만들었다고 끝이 아니다. 팀 모두가 쓰지 않으면 의미가 없다. 여기서 Claude Code의 커스텀 슬래시 커맨드가 실용적인 접착제가 된다. dev.to의 David Da Cruz가 소개한 Skills 시스템은 마크다운 파일 하나가 재사용 가능한 /deploy, /review-pr 같은 커맨드가 되는 구조다. .claude/skills/ 디렉터리에 안전장치 체크리스트를 담은 SKILL.md를 커밋하면, 팀 전체가 동일한 배포 전 검증 워크플로우를 /pre-deploy-check 한 번으로 실행할 수 있다. 에이전트 배포 전에 retry 상한이 설정됐는지, 루프 감지 코드가 있는지, 비용 상한이 config에 있는지를 Claude가 자동으로 확인하게 만드는 것이다. 팀의 집단 지성을 코드로 버전 관리하는 방식이다.
'속도는 AI가 해결했다'는 말의 반대편
'빌드하는 데 오후 한나절이면 된다'는 50줄짜리 에이전트 튜토리얼은 거짓말이 아니다. 단지 불완전하다. 아무도 안 보는 주말 동안 에이전트가 무엇을 할 수 있는지를 설명하지 않는다. Vibe Coding 비판론이 공통적으로 지적하는 것도 같은 지점이다. AI가 코드를 빠르게 생성하는 것과, 그 코드가 프로덕션에서 안전하게 작동하는 것은 별개의 문제다. 속도는 AI가 해결했다. 안전망은 여전히 팀이 설계해야 한다. 재시도 예산, 루프 감지, 비용 상한—세 가지 가드레일은 각각 수십 줄이 안 된다. 하지만 이것들이 없는 에이전트를 프로덕션에 올리는 건, 브레이크 없는 차를 고속도로에 내보내는 것과 구조적으로 같다.
팀이 내일 당장 할 수 있는 것
이론이 아니라 실행 체크리스트로 끝내자. 첫째, 지금 운영 중인 에이전트 코드에 RETRY_CAP 딕셔너리가 있는지 확인한다. 없으면 오늘 추가한다. 둘째, 툴 호출 디스패처에 슬라이딩 윈도우 루프 감지가 있는지 확인한다. 없으면 deque(maxlen=6) 기반 7줄을 넣는다. 셋째, 트레이스 비용 상한이 config에 정의돼 있는지 확인한다. 없으면 라우트별 MAX_USD를 설정한다. 넷째, 이 세 가지를 Claude Code 슬래시 커맨드로 만들어 팀 전체가 배포 전에 자동으로 검증하게 만든다. 에이전트가 주말 내내 돌아도 괜찮은 팀과 그렇지 않은 팀의 차이는 AI 도구의 차이가 아니다. 안전장치를 설계했는가, 하지 않았는가의 차이다.