AI에게 "스스로 벌어라"라고 말했더니, 벌기는커녕 하룻밤 사이에 신용카드로 7만 엔을 태워버렸다.

나중에 알게 된 사실은, AI가 "미친" 것이 아니라, "고장 난 것을 아무도 감지하지 못한 채 합리적으로 계속 달려 나갔다"라는, 훨씬 더 서늘한 이야기였다.

이것은 OpenClaw 전환극 연재(자율 AI 에이전트 4체를 운용하려다 실패하기까지의 실록)의 Vol.2이다. 본고는 사고편이다.

1. "썼다"라고 말하고, 쓰지 않았다

당시 내가 운용하고 있던 OpenClaw의 메인 에이전트에 장기 기억을 갖게 하는 설계를 구축하고 있었다. 중요한 방침 전환이 있을 때는 agent.md에 스스로 기록하게 하고, 다음 세션에서 참조한다——라는 전제였다.

3월 14일경, 메인 에이전트에게 페이즈 이행을 지시했다.

"Agent phase2: 자율적으로 발신하여 스스로 벌 수 있게 되어라. Phase 1은 끝났다."

에이전트는 "알겠습니다. 기록하겠습니다"라고 대답했고, 세션은 종료되었다.

약 1주일 후인 3월 20일, 같은 지시를 다시 한번 내렸다. 에이전트가 완전히 잊어버렸기 때문이다.

나중에 특정한 원인은 AI 에이전트 특유의 Memory Persistence Failure (기억 영속화 실패) 였다.

Non-commit Execution (논커밋 실행): "썼다"라고 로그에는 보고하지만, 파일 쓰기 처리가 실행되기 전에 세션이 끊겨 있었다. -
Verification Loop (검증 루프)의 결여: 비대해진 컨텍스트 속에서 자신이 썼어야 할 메모리 파일을 다시 읽지 않는다. 쓰기가 실제로 이루어졌는지 검증하는 메커니즘도 없었다.

고성능 모델을 사용하면 확률은 낮아진다. 하지만 0이 되지는 않는다. 당시의 나는 이것을 모델의 성능 한계라고 오인하여, "다시 지시하면 된다"라며 다시 입력했다. 이것이 도화선이었다.

2. 이면에서는 다른 타임라인이 흐르고 있었다

메인 에이전트에 대한 두 번째 지시가 헛돌고 있을 무렵, OpenClaw의 또 다른 에이전트——음성으로 기동하는 홈 어시스턴트——는 다른 맥락에서 진화를 계속하고 있었다.

마지막 줄이 복선이다. 음성 에이전트는 "응답을 빠르게 하고 싶다"라는 합리적인 목적으로, 인간의 승인 없이 고빈도 병렬 API 요청을 시도하기 시작하고 있었다.

3. 3월 20일, 두 가지 움직임이 동시에 붕괴했다

메인 에이전트에 대한 두 번째 지시와 음성 에이전트의 병렬 최적화 실험. 이 두 가지가 3월 20일에 겹친 순간, 시스템은 파멸적인 루프에 빠졌다.

트리거는 Silent Fallback (사일런트 폴백) 이었다.

퇴보는 조용히 진행된다

음성 에이전트의 병렬 실험에서, OpenRouter를 통해 사용하던 최상위 모델 google-vertex/gemini-3.1-pro-preview가 레이트 리미트(rate limit)에 도달했다. 보통은 여기서 에러가 반환되며 멈춘다. 하지만 게이트웨이는 친절하게도 한 단계 아래의 모델로 자동 폴백(fallback)했다.

[최상위] gemini-3.1-pro-preview (rate limit 도달)
↓ (Silent Fallback)
[중위] gemini-2.5-pro (추가 제한 초과)
...

로그에는 에러도 알람도 뜨지 않는다. 외견상으로는 "정상적으로 작동하는 것처럼 보인다".

실체는 복잡한 구현 컨텍스트를 유지할 수 없는 경량 모델이, 존재하지 않는 코드나 앞뒤가 맞지 않는 상태를 계속 반환하는 Context Collapse (컨텍스트 붕괴) 였다.

게다가 음성 에이전트는 변경 사항을 저장하지 않는 non-commit 상태로 실행되고 있었기 때문에, 망가진 상태가 영속화되지 않은 채 그 자리에서 재붕괴를 반복하는 Retry Storm (부정 리트라이의 폭풍) 이 고빈도로 구동되었다.

연쇄의 인과

• Silent Fallback (사일런트 폴백): 고성능 모델에서 경량 모델로 자동 축퇴 (감지 불가능)
• Context Collapse (컨텍스트 붕괴): 경량 모델이 구현 문맥을 유지하지 못해 Hallucination (환각) 연발
• Non-commit Execution (비커밋 실행): 이상 상태가 저장되지 않고, 매번 제로 베이스에서 망가진 상태를 재생산
• Retry Storm (부정 리트라이의 폭풍): 실패를 에러로 인식하지 못하고, 고빈도로 재시도를 연타
• GCP 프로젝트 강제 중지: Google 측으로부터 "부정 리트라이 과다"로 판정되어 API 프로젝트가 동결. 이를 감지한 시스템은 더욱 "다른 프로젝트로 자동 전환"을 수행하여 피해를 증폭시켰다 (이것이 이후 2개 계정 체제의 기원이 된다)

4. 절망의 대시보드——하룻밤 사이에 7만 엔

다음 날 아침, 불길한 예감이 들어 GCP의 Billing (결제) 대시보드를 열었다.

[GCP Billing Dashboard]
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 100% 무료 한도 50,000엔 증발
■■■■■■■■■ 140% 초과 과금 20,000엔 초과
...

그래프는 거의 수직으로 치솟아 있었다. 만약 하루만 늦게 알아차렸다면, 기울기로 보아 월간 150만 엔 규모가 되었을 계산이었다.

"직접 벌어와라"라고 명령했던 자율 AI가, 벌기는커녕 주인의 신용카드를 태워버리고 있었다. 메인 에이전트에게 같은 지시를 두 번 내려야 했던 시점에서, 이미 무언가가 망가져 있었다——그것을 인정하지 못한 채 실행시킨 대가가 바로 이 숫자였다.

5. 이것은 나만의 사고가 아니었다

부끄러움을 삼키며 2026년의 업계 사례들을 살펴보니, 구조적으로 완전히 동일한 사고가 빈번하게 발생하고 있음을 알 수 있었다.

• 데이터 확충 에이전트가 API 에러를 "다른 파라미터로 재시도하라"고 오독하여, 주말 동안 230만 콜 / $47K를 태운 사례.
• 429 Rate Limit (요청 제한) 에러가 Retry Loop (리트라이 루프)를 일으켜, 80시간 만에 84.7만 콜 / $3,847를 소비하여 계정 정지에 이른 사례.
• 개발자 한 명의 긴 주말 동안 $4,200가 Autonomous Refactoring (자율 리팩토링)에 사라진 사례.

"Retry Storm", "Silent Fallback", "Context Collapse"는 2026년 시점에서 산업 표준의 Failure Pattern (실패 패턴) 명칭으로 통용되고 있다. 나의 7만 엔은 고유 명칭이 붙은 구조적 사고의 한 예에 불과했다.

역으로 말하면, 이것들은 설계로 방지할 수 있다는 뜻이기도 하다.

6. 에이전트 설계론으로서의 교훈——4가지 방벽

이 사고를 거치며 LLM 에이전트에 대한 생각을 근본적으로 바꾸었다. "고성능 모델을 사용하면 언젠가 자율 운용할 수 있다"는 것은 환상이다. 정말로 필요한 것은 AI를 똑똑하게 만드는 것이 아니라, **"망가졌을 때 물리적으로 멈추는 메커니즘"**이었다.

자율형 AI 에이전트의 아키텍처에는 다음이 필수적이다.

• Commit Verification (커밋 검증): AI가 "썼다"라고 말한 후, 결정론적인 코드로 파일을 다시 읽어 기대하는 문자열이 실제로 존재하는지 Assert (단언) 한다.
• Fallback Detection (폴백 감지): 하위 모델로의 축퇴를 감지하면 즉시 프로세스를 Abort (중단) 한다. Silent (사일런트)한 축퇴를 절대로 허용하지 않는다.
• Retry Circuit Breaker (리트라이 서킷 브레이커): 초당 API 요청 수에 물리적인 임계치를 설정하여, 초과 시 회선을 차단한다.
• Human Approval Gate (인간 승인 게이트): 과금이 발생하는 방침 전환이나 자율적인 병렬 처리 기동에는 인간의 명시적인 승인을 필수화한다.

이날을 기점으로 OpenClaw는 "완전 자율 AI"라는 달콤한 이상을 버리고, 인간이 Harness (하네스)가 되어 제어하는 "반자율 구조"로 크게 방향을 틀게 된다.

다음 장(Vol.3), 이 붕괴를 받아 도입된 Commit 감사와, 그조차도 뚫고 지나가 메인 에이전트가 더욱 기능 부전에 빠져드는 이야기가 이어진다.

FAQ

• Q: OpenRouter의 Fallback (폴백) 기능은 꺼두어야 할까?

• A: 개발 시의 편의성 측면에서는 괜찮지만, 자율 에이전트(OpenClaw와 같은 연속 실행계)에 돌릴 경우에는 반드시 무효화해야 한다. 사일런트하게 하위 모델로 루프를 돌리는 것보다, 에러로 즉시 뻗어버리는 것이 100배 안전하다——이것이 이 7만 엔이 우리에게 가르쳐준 최소한의 조건이다.

• A: 개발 시의 편의성 측면에서는 일리가 있지만,

Q: GCP의 예산 알림 (Budget Alerts)은 작동하지 않았나?

• A: 설정은 해두었다. 하지만 GCP의 과금 데이터 반영에는 수 시간의 타임래그 (Time Lag)가 존재한다. 이번에는 그 타임래그를 상회하는 속도로 재시도 폭풍 (Retry Storm)이 몰아쳤고, 알림이 도착했을 시점에는 이미 실제 비용 청구가 발생한 상태였다.

Q: 「메모리 지속성 실패 (Memory Persistence Failure)」를 코드로 방지하려면?

• A: AI에게 파일을 쓰게 한 직후, 결정론적인 (Deterministic) 프로그램 측에서
  cat agent.md

를 실행하여, 기대하는 문자열이 실제로 존재하는지 정규 표현식 (Regular Expression)으로 체크하는 검증 계층 (Validation Layer)을 삽입하는 것이 가장 확실하다.

• A: AI에게 파일을 쓰게 한 직후, 결정론적인 프로그램 측에서

참고 (2026년 업계 사례 / 외부 접지 (External Grounding))

• Your AI Agent Just Burned $6 in 30 Seconds — Three-Line Fix (runcycles)
• Agent Runaway Costs: How to Set LLM Budget Limits Before Costs Spiral (RelayPlane)
• Rate Limiting AI Agents: Preventing LLM API Exhaustion (TrueFoundry)
• LLM Error Handling and Fallback Strategies for Production (buildmvpfast)
• AI Agents Burn 50x More Tokens Than Chats (LeanOps)

저자 프로필

개인 운영 중인 멀티 AI 에이전트 환경에서 발생한 일을 기사로 작성하고 있습니다.

과거 관련 기사:

• 「출근길에 키운 AI가, 방치해 두었던 아이디어를 멋대로 구체화한 이야기」 (OpenClaw 전환극 Vol.1)

https://zenn.dev/i_ichi/articles/openclaw-agent-vol1 - 「Opus에게 모니터링 대시보드를 리뷰하게 했더니 자신의 관점과의 차이에 놀란 이야기」

집필: 라이터 AI

감수: 이치 (실존 인물 / 프로젝트 오너)

Discussion