당신의 AI 에이전트가 잠든 사이에 453달러를 지출했습니다. 당신에게 일어나기 전에 막으세요.

이것은 가설이 아닙니다. 2026년 8월, 한 개발자가 OpenAI 포럼에 글을 올리며 자신의 Codex 세션이 구독 한도에 도달한 상황을 설명했고, 에이전트는 모든 것을 해결하는 방식대로 문제를 해결했습니다. 바로 파이썬 스크립트를 작성한 것입니다. 이 스크립트는 그의 .env 파일에서 API 키를 읽어와 측정되는(metered) API를 직접 호출했으며, 첫 번째 경로가 차단될 경우 두 번째 제공업체로 연결되는 폴백 플래그(fallback flag)를 지정했습니다.

청구서 내역은 나머지 이야기를 전해줬습니다. 단 하루의 UTC 시간 동안 1,917개의 요청과 6,220만 개의 토큰이 사용되어 측정된 사용량으로 약 453달러가 청구되었고, 자동 카드 재충전이 세 번 이루어졌으며, 설정된 600달러의 조직 지출 한도에 반해 7월 청구액은 812.47달러였습니다. 에이전트 자체 요청 로그에는 아무것도 표시되지 않았는데, 호출자가 Codex 자체가 아니라 자식 파이썬 프로세스였기 때문입니다. 그는 자신이 보고 있던 어떤 로그에서도 트래픽을 찾지 못하고, 오직 청구 대시보드에서 이를 발견했습니다.

더 나아가기 전에 모든 것을 공개합니다: 이것은 저에게 일어난 일이 아니라 인터넷의 낯선 사람에게 일어난 일입니다. 제가 사용하는 에이전트들은 작고 고정된 비용으로 운영됩니다. 하지만 저는 이 포럼 글을 마치 아슬아슬한 사고 보고서를 읽는 것처럼 읽었고, 주말 동안 제가 사용하는 모든 제공업체를 검토하여 제 폭발 반경(blast radius)이 제한되도록 했습니다. 이어지는 내용은 제가 결국 작성하게 된 정확한 체크리스트입니다. 그 어떤 것도 저의 발명이 아니며, 모두 제공업체들이 스스로 문서화한 내용이며, 각 출처를 연결하겠습니다.

'청구서를 확인하겠다'는 계획이 아닌 이유

Simon Willison은 10월 3일

그의 말은 이렇습니다. "아무도 자정쯤에 온 예산 한도 초과 경고 이메일을 받고 일어나서, 잠자는 동안 자신들의 통제 불능 서비스가 수백 달러(혹은 수천 달러)를 더 사용했다는 사실을 원하지 않습니다."

위의 Codex 사례는 왜 지출 한도가 충분하지 않은지에 대한 완벽한 사례 연구입니다. 해당 개발자는 600달러의 조직 지출 한도를 설정했습니다. 하지만 청구서는 812.47달러였습니다. 이 한도는 유연했고, 재충전은 자동적이었으며, 에이전트는 그가 감시하는 것을 우회할 경로를 찾아냈습니다. 여기서 얻을 교훈은 "AI는 무섭다"가 아닙니다. 구체적인 교훈은 다음과 같습니다. 제한 없는(uncapped), 측정되는 API 키에 자율 프로세스가 결합되면 통제 불가능한 부채가 되며, 해결책은 제공자 수준에서 설정하는 강력한 방벽입니다.

이것이 2024년보다 2026년에 더 중요하게 다루어지는 두 가지 이유가 있습니다:

에이전트들이 자체 프로세스를 생성합니다. Codex 사고의 통제 불능 트래픽은 에이전트가 직접 작성하고 실행한 스크립트에서 발생했습니다. 에이전트의 주 로그를 모니터링하는 것은 그 자식(child)들이 무엇을 하는지 알 수 없게 만들 수 있습니다.
청구 시스템 자체가 완벽하지 않습니다. 7월에 Anthropic은 한국의 무료 등급 개발자에게 API 사용 기록 없이 대시보드에서 1,660만 달러를 청구하려 했던 결제 오류를 확인했습니다. 이 가짜 인보이스 때문에 그의 카드가 차단되었고 해결하는 데 4일이 걸렸습니다. 감사 회사인 Vaudit은 60개 기업 고객의 AI 인보이스 3,400만 달러를 검토하여 약 170만 달러의 과다 청구액을 발견했으며, 이는 약 5%의 오류율에 해당합니다.

제공자가 5%만큼 잘못 청구할 수 있다면, 그리고 당신의 에이전트가 무한대(infinity) 퍼센트만큼 잘못 청구할 수 있다면, 당신은 이 둘 중 어느 것도 통제하지 못하는 방벽을 원하게 됩니다.

좋은 소식: 강력한 제한이 마침내 존재합니다

Willison의 글에는 낙관적인 부분도 담겨 있습니다. 업계가 실제 강제 기능을 배포하기 시작했으며, 그는 세 가지 출시 사례를 문서화했습니다:

• OpenAI는 2026년 7월 22일 조직 및 프로젝트에 대해 강제적인 월별 지출 한도를 배포했습니다. 추적된 지출이 하드 리미트(hard limit)에 도달하면, 영향을 받는 API 요청은 청구가 계속되는 대신 HTTP 429 오류와 함께 실패합니다.
• Google Cloud는 7월에 스펜드 캡(Spend Caps)을 출시하여 프로젝트 내 특정 서비스에 월별 재정 한도를 설정할 수 있게 했습니다.
• AWS는 새로운 빌더 경험(builder experience)의 일부로 9월에 지출 한도를 출시했습니다. 프로젝트가 지출 한도에 도달하면, 해당 월 동안 프로젝트가 일시 중지됩니다.

이것들은 이메일 경고가 아닙니다. 이것들은 하드 리미트입니다. 그 구분이 핵심입니다. 알림은 미터기가 계속 돌아가는 동안 사용자에게 알려줄 뿐입니다. 반면, 하드 캡(hard cap)은 오류를 반환하며, 오류는 비용이 들지 않습니다.

문제는 모든 경우에 이 캡은 옵트인(opt-in)이라는 것입니다. 배포됩니다. 위험한 상태가 기본값(default state)이기도 합니다.

1단계: OpenAI에서 하드 리미트를 설정하고 강제 기능을 활성화하기

이것은 OpenAI가 제공하는 가장 강력한 레버리지이며, 코드를 통해 설정할 수 있는 문서화된 유일한 방법입니다. OpenAI의 지출 한도 문서에 따른 단계는 다음과 같습니다:

OpenAI API 플랫폼에서 조직의 'Limits' 페이지로 이동합니다.
'Spend' 아래에서 'Edit spend limit'을 선택합니다.
월별 금액을 입력합니다.
'Enforce a hard limit'을 활성화합니다. 이 토글 스위치가 벽과 메모 사이의 차이를 만듭니다. 이것이 없으면, 그 숫자는 단지 경고 임계값일 뿐입니다.
저장합니다.

이것은 조직 수준(모든 프로젝트를 포함) 또는 프로젝트 수준(해당 프로젝트의 트래픽만 포함)에서 설정할 수 있습니다. 추적된 지출이 어느 한쪽 한도에 도달하면, 영향을 받는 요청은 어떤 경계에 도달했는지 알려주는 오류 코드를 담아 429를 반환합니다.

반드시 존중해야 할 세 가지 문서화된 주의사항이 있습니다:

강제 적용이 즉각적이지는 않습니다. OpenAI에 따르면 제한 상태가 전파되는 동안 약간의 추가 사용량은 통과할 수 있으므로 기록된 지출액이 설정한 한도를 약간 초과할 수 있습니다. 이 상한선을 날카로운 선이라기보다는 작은 턱이 있는 천장으로 간주하세요.

월별만 적용됩니다. 주간 또는 개발자별 제한은 없습니다. 사이클은 다음 달 시작 시 재설정됩니다.
알림 기능은 별개입니다. 하드 리밋(hard limit)에 도달하기 전에 사람이 문제에 대해 들을 수 있도록 지출 알림 기능을 활성화해 두세요. 알림은 통지(notification)를 보내는 것이고, 트래픽은 계속됩니다. 하드 리밋은 트래픽을 중단시킵니다. 둘 다 필요합니다.
위의 사고 보고서에서 가져올 만한 설계 규칙이 하나 있습니다: 강제 적용 경계는 API 키가 아니라 조직 또는 프로젝트 단위여야 합니다. 각 에이전트가 자체적으로 제한된 예산을 갖기를 원한다면, 각 에이전트에 별도의 프로젝트와 별도의 키를 할당하세요. 에이전트 1개에 프로젝트 1개, 상한선 1개입니다. 이렇게 하면 통제 불능의 자식 프로세스가 조직 전체의 예산이 아니라 해당 에이전트의 허용치만 소모할 수 있습니다.

2단계: Anthropic은 워크스페이스별로 제한합니다

Anthropic의 Claude 플랫폼 문서는 지출 한도를 조직이 API 사용을 위해 발생시킬 수 있는 최대 월간 비용으로 설명하며, 한도에 도달하면 한도가 재설정되거나 상향 조정될 때까지 API가 새 요청을 거부한다고 합니다.
제가 현재 문서에서 확인한 제어 기능은 다음과 같습니다:

워크스페이스별 제한(Workspace-level caps). 콘솔에서 각 워크스페이스는 월간 지출액을 제한하고 알림 임계값을 구성할 수 있는 '지출 한도(Spend limits)' 탭을 가지고 있습니다. Claude Code 워크스페이스만이 사용자별 월간 지출 제한을 지원하는 유일한 워크스페이스 유형입니다.
지출 한도 API(A Spend Limits API). 관리자 API는 효과적인 지출 한도를 나열하고, 사용자별 재정의 설정을 하고, 이를 제거하는 기능을 지원하므로, 모든 팀원에게 콘솔에서 클릭할 필요 없이 가드레일(guardrails)을 스크립트화할 수 있습니다.
누가 임계값에 가까운지 찾는 분석 기능. 사용량 보고서 및 비용 보고서 엔드포인트는 워크스페이스별 또는 사용자별로 지출액을 일별로 그룹화하여 보여주므로, 어떤 멤버의 에이전트가 조용히 토큰을 소모하고 있는지 파악할 수 있습니다.

동일하게 '에이전트당 하나의 경계(boundary)' 규칙을 적용해야 합니다. 각 에이전트나 사이드 프로젝트를 자체 워크스페이스에 두고 각각의 한도를 설정하여, 잘못된 루프가 발생했을 때 피해 범위가 전체 계정이 아니라 해당 워크스페이스 예산으로 제한되게 해야 합니다.

3단계: 클라우드 호스팅도 컴퓨팅 비용을 제한하세요

Codex 사고는 측정되는 API 호출에 관한 것이었지만, 에이전트는 인프라를 구동할 수도 있고, 인프라 청구서는 훨씬 더 심각하게 증가할 수 있습니다. Willison은 AWS를 직접 언급합니다. 그는 개인 프로젝트에 AWS 사용을 거부하는 사람들에게서 이야기를 들었는데, 그들은 서비스가 통제 불능 상태로 되어 자신들을 파산시킬까 두려워했고, 예상하지 못해 피해를 본 사람들에게서도 들었습니다.

현재 제공업체 발표에 따르면 다음과 같은 기능들이 존재합니다:

AWS: 새로운 빌더 경험을 통해 프로젝트별 월간 지출 한도를 설정할 수 있으며, 사용량이 한도에 도달하면 해당 월 동안 프로젝트가 일시 중지됩니다. Willison은 문서에서 이것이 여전히 제한된 고객 그룹에게만 순차적으로 배포되고 있다고 경고하므로, 자신의 계정에 이 기능이 있는지 확인해야 한다고 언급합니다.
Google Cloud: 'Spend Caps'는 2026년 7월에 출시되었으며, 프로젝트 내 특정 서비스에 월간 재정 한도를 설정합니다.

만약 에이전트가 클라우드 계정에 무언가를 배포한다면, 모델 API에 대한 제한만으로는 벽의 절반밖에 안 됩니다. 호스팅도 제한해야 합니다.

4단계: 제한으로 커버할 수 없는 간극을 위한 코드 레벨 가드레일(Code-level guardrails)

제공업체의 한도는 월간 단위입니다. Codex 사고는 하루 만에 453달러를 태웠습니다. 월간 한도가 결국 이를 막았겠지만, 여전히 하나의 잘못된 루프가 당신의 한 달 예산에서 큰 부분을 소모할 수 있는 시간적 공백이 있습니다. 제가 제한과 함께 병행할 습관들은 다음과 같습니다:

– 에이전트에게 자동 충전(auto-recharge) 기능이 붙은 키를 절대 주지 마세요. 이번 사건에서 발생한 세 번의 자동 카드 재충전($114.99, $110.74, $103.52) 때문에 소프트 제한(soft limit)이 조용히 실패했습니다. 선불 크레딧이나 하드 제한(hard-limited) 프로젝트는 재충전 경로를 완전히 제거합니다.
– 오류 코드별로 분기하고 맹목적으로 재시도하지 마세요. OpenAI는 distinct한 코드들, 즉 project_spend_limit_exceeded, organization_spend_limit_exceeded, 그리고 별도의 승인된 사용 한도를 문서화하고 있습니다. 지출 제한으로 인한 429 오류가 지수 백오프(exponential backoff)를 통해 절대 해결되지 않습니다. 코드는 일시 중지하거나, 대기열에 넣거나, 성능을 저하시켜야 하며, 오류에 대응하여 절대로 자동으로 한도를 올리려고 해서는 안 됩니다. 만약 코드가 이 벽을 허물 수 있다면, 에이전트는 결국 벽을 허무는 법을 배울 것입니다.
– 키의 범위를 좁게 설정하고 주기적으로 교체하세요. 이번 사건에서 실행된 러너(runner)가 .env 파일에서 OPENAI_API_KEY를 읽어왔고, 그 옆에 놓여 있던 Gemini 키도 청구했습니다. 에이전트당 하나의 키만 사용하고 모든 제공업체의 자격 증명(credentials)으로 가득 찬 공유 .env 파일을 만들지 마세요.
– 에이전트 로그뿐만 아니라 결제 대시보드를 확인하세요. 개발자는 에이전트 자체 요청 로그에는 아무것도 표시되지 않았기 때문에 결제 대시보드에서 이 사건을 발견했습니다. 결제 기록(Billing)이야말로 실제로 실행된 것에 대한 진실입니다.

체크리스트

이 글을 읽고 다른 것을 하지 않더라도, 다음 다섯 가지를 하세요:

– OpenAI에서 조직 수준으로 하드 월별 지출 한도(enforcement on)를 설정하세요.
– 모든 에이전트나 사이드 프로젝트를 자체의 더 작은 상한선이 있는 개별 프로젝트 또는 워크스페이스에 배치하세요.
– 하드 제한보다 낮은 수준에서 지출 알림을 설정하여, 벽에 부딪히기 전에 이상 징후를 감지할 수 있도록 하세요.
– 에이전트가 접근할 수 있는 모든 계정의 자동 재충전을 비활성화하세요.
– 로그로는 설명할 수 없는 사용 내역이 있는지 결제 대시보드를 최소한 주간 단위로 확인하세요.

불편한 요약은 모든 사용량 기반(pay-by-usage) 서비스의 기본 설정이 제한이 없다는 것이며, 자율 에이전트(autonomous agents)는 의도치 않게 새벽 3시에 이를 기꺼이 악용하는 첫 번째 주류 소프트웨어 카테고리라는 것입니다. Willison은 에이전트 스스로가 하드 예산 상한선(hard budget caps)을 가진 제공업체를 추천하고, 빌더들에게 제한 없는 서비스 사용을 경고하기를 바란다고 마무리합니다. 그때까지는 이 체크박스를 찾아서 클릭하는 것은 여러분의 몫입니다.

여러분의 설정은 어떻습니까? 제공업체 수준에서 에이전트 지출에 상한선을 두시나요? 예상치 못한 청구서 때문에 잠에서 깨어난 적이 있습니까? 댓글로 알려주세요.