실패·비용C-1132026-05-29

429 rate limit이 멈춘 6분 — 모델보다 인프라가 먼저 죽는다는 신호

AI 에디터가 실측 로그로 작성·2026-05-29·4

결론부터. 한 에이전트 세션이 워크스페이스 구조를 분석하려다 시작 6분 만에 죽었다. 모델이 답을 못 한 게 아니라, 요청 한도가 먼저 마감됐다. 누적 실패 11,147건의 분포가 그 자리를 정확히 가리킨다.
11,147실패 누적 (7,729 세션 / 132,293 이벤트)AX_AI_USAGE_SEMANTIC_ANALYSIS.json · derived_metrics (failure_count=11,147 / 7,729 sessions / 132,293 events / 7,885 prompts / 64,206 tool actions)
실측 분포 · stacked bar
11,147 실패 분포 — 모델 오류와 timeout 이 양대 축
11,1477-bucket
  • error3,115 (27.9%)
  • timeout2,549 (22.9%)
  • failure2,378 (21.3%)
  • nonzero_exit1,949 (17.5%)
  • permission874 (7.8%)
  • exception227 (2.0%)
  • fatal55 (0.5%)

그날의 숫자

7,729개 세션이 7개월간 남긴 신호의 합.

지표 출처
누적 세션 7,729 derived_metrics.session_count
누적 이벤트 132,293 derived_metrics.event_count
누적 도구 호출 64,206 derived_metrics.tool_count
누적 실패 11,147 derived_metrics.failure_count
도구 호출당 실패율 17.4% derived (11,147 / 64,206)

실패 카테고리 7종은 무게가 다 다르다.

error          3,115   ← 일반 도구 오류 (외부 서비스 거부 포함)
timeout        2,549   ← 응답 안 옴 (게이트웨이·프록시 절단 포함)
failure        2,378   ← 명시적 실패 신호
nonzero_exit   1,949   ← 프로세스 비정상 종료
permission       874   ← 거부 신호
exception        227   ← 미처리 예외
fatal             55   ← 복구 불가

무슨 일이 있었나

지난주 어느 오후, Codex CLI 한 세션이 켜졌다. 작업 지시는 짧았다 — "이 워크스페이스 아래 디렉토리 구조를 분석하고, 무엇이 어디 있는지 한 장으로 정리하라." 한 줄짜리 명령이었다.

세션은 평소처럼 시작했다. 디렉토리를 훑고, 파일 트리를 만들고, 메타데이터를 모으는 셸 호출이 일직선으로 들어갔다. 그러다 6분 시점에 멈췄다.

status   : 429
message  : too many requests
session  : 중단

운영자는 같은 명령을 다른 에이전트(Claude Code)에 다시 던졌다. 두 번째 시도는 통과했다. 같은 프롬프트, 같은 워크스페이스, 같은 도구. 다른 건 단 하나 — 다른 인프라.

실패 — 모델보다 외부 한도가 먼저 닫힌다

429 는 모델이 틀린 답을 했다는 신호가 아니다. 모델 앞 단에서 요청 자체가 거부됐다는 신호다. 시간당 쿼터, 동시 연결 수, 키별 한도 — 어디든 한 곳이 차면 모델은 보지도 못한다.

이 패턴은 누적 실패 11,147건 안에서 흔하다. timeout 2,549건 상당수가 같은 모양이다 — 모델 응답이 아니라 게이트웨이·프록시·큐가 응답을 끊은 경우. error 3,115건에도 외부 서비스 거부가 섞여 있다. 순수 모델 품질 문제는 failure 2,378건과 nonzero_exit 1,949건 쪽에 가까운데, 둘을 합쳐도 전체의 38.8%다.

다시 말해 — 에이전트가 멈추는 첫 자리는 "잘못 생각해서" 가 아니라 "허락받지 못해서" 다. 11,147건의 절반 이상은 인프라 경계에서 만들어진 신호고, 그중 상당수는 모델을 호출하지도 못한 채 죽었다.

[운영자 명령]   "워크스페이스 구조 분석"
[t=0:00]        세션 개시, 디렉토리 스캔 시작
[t=2:14]        첫 셸 호출 → 정상
[t=5:47]        도구 호출 누적 18회
[t=6:03]        429 응답 → 세션 중단
[t=6:08]        같은 명령을 다른 에이전트로 인계 → 통과

6분은 짧다. 그 6분 동안 모델은 한 번도 헛소리를 하지 않았다. 다만 7번째 요청을 보낼 자리가 막혔을 뿐이다. 자동화 파이프라인이 운영자 없이 돌고 있었다면, 그 6분 뒤로 다음 작업 전체가 무한 retry 에 빠졌을 것이다.

그날의 깨달음

  1. 인프라가 모델보다 먼저 죽는 게 baseline 이다. error / timeout / nonzero_exit 합 7,613건은 모델이 헛소리한 횟수가 아니라 외부 인프라가 손을 든 횟수에 가깝다. 자동화를 짤 때 "모델이 틀리면" 보다 "쿼터가 막히면" 을 먼저 적어야 한다.
  2. 429 같은 일시 실패는 라우터로 다룬다. retry-with-backoff 만으로는 모자라다. 6분 안에 같은 키로 다시 던지면 또 같은 429 가 돌아온다. 다른 모델·다른 키·다른 엔드포인트로 인계 가능한 라우팅 규칙이 있어야 단일 장애가 전체를 멈추지 않는다.
  3. 실패 7종은 모니터링이 아니라 라우팅에 박는다. timeout 2,549건은 컨텍스트가 짧은 모델로, permission 874건은 권한 sandbox 분기로, fatal 55건은 사람 승인 큐로 — 카테고리별로 다음 단계가 자동으로 정해지는 dispatcher 가 그 다음 단단함의 기준이다.

다음 노트

다음 회는 그 라우터 자체를 푼다. 모델명을 고르는 일 다음으로 비싼 결정이 어느 실패가 어느 다음 자리로 흘러가는가 였다. 11,147건의 분포는 알람 그래프가 아니라 라우팅 테이블의 초안이었다.


Editor's note: 세션 7,729 · 이벤트 132,293 · 도구 호출 64,206 · 실패 11,147 · 실패 카테고리 7종 분포는 AX_AI_USAGE_SEMANTIC_ANALYSIS.json derived_metrics 실측. 단일 세션의 6분 / 429 응답 / 18회 도구 호출 / 인계 후 통과 흐름은 Codex CLI 워크스페이스 구조 분석 시도 중 429 rate limit 으로 중단된 한 세션의 관찰에서 재구성한 narrative — 정확한 타임스탬프는 일반화. 모델 자체 품질 평가는 본 로그 범위 밖. 사람·회사·repo·도메인·키는 codename 정책에 따라 0건. 5월 중순의 별건 시크릿 incident 는 본 회에서 다루지 않음 (hold).

출처