서비스 장애보다 청구서 한 장이 더 무서울 때
어느 날 아침 메일함을 열었더니 클라우드 청구서에 수천만 원이 찍혀 있다면 어떨까요? 개발자 커뮤니티에는 잊을 만하면 이런 이야기가 올라와요. 깃허브에 실수로 올린 AWS 키로 누군가 코인 채굴을 돌렸다거나, 무료 플랜으로 운영하던 사이트가 트래픽 공격을 맞았다는 식이죠. 2024년에는 Netlify 무료 플랜으로 정적 사이트를 운영하던 개발자가 DDoS 공격 때문에 약 10만 4천 달러짜리 청구서를 받은 일도 있었어요. 논란이 커지고 나서야 면제받았고요.
Django 공동 창시자이자 LLM 도구에 관한 글로 잘 알려진 사이먼 윌리슨(Simon Willison)이 이 문제를 정면으로 꺼냈어요. 주장은 제목 그대로예요. "거의 모든 것에 기본값으로 하드 예산 상한(hard budget cap)이 필요하다." 이 주장이 지금 특히 와닿는 건, AI 에이전트가 사람 대신 API를 부르고 클라우드 자원까지 직접 만지는 시대가 됐기 때문이에요.
하드 캡과 예산 알림은 완전히 다른 물건이에요
용어부터 정리해 볼게요. 소프트 리밋(예산 알림)은 "정해둔 금액을 넘으면 메일로 알려줄게"예요. 하드 캡은 "정해둔 금액을 넘으면 그냥 멈출게"고요. 비유하자면 소프트 리밋은 카드 결제 알림 문자이고, 하드 캡은 잔액이 없으면 결제 자체가 거절되는 선불카드예요. 알림 문자는 돈이 이미 나간 다음에 오잖아요.
문제는 대부분의 클라우드가 기본으로 주는 게 앞쪽이라는 거예요. AWS Budgets도, GCP 예산 기능도 기본 동작은 '알림'이에요. GCP 공식 문서에 예산 알림을 Pub/Sub로 받아서 Cloud Function으로 결제를 끊는 예제가 있긴 한데, 이건 내가 직접 조립해야 하는 우회로죠. 게다가 청구 데이터는 실시간이 아니라 몇 시간씩 늦게 집계돼요. 알림을 받았을 땐 이미 한참 지나 있을 수도 있다는 뜻이에요.
AI 에이전트가 문제를 키우는 이유
예전엔 요금 폭탄의 원인이 주로 키 유출이나 트래픽 공격처럼 '외부'에 있었어요. 이제는 내가 직접 돌리는 에이전트가 원인이 될 수도 있어요. 에이전트는 목표를 이룰 때까지 스스로 도구를 호출하면서 반복하는 프로그램이거든요. 버그나 애매한 지시 하나 때문에 같은 작업을 수백 번 반복할 수 있고, 테스트한다며 GPU 인스턴스를 띄워 놓고 끄는 걸 잊을 수도 있어요. 사람은 퇴근도 하고 잠도 자지만, 에이전트는 밤새 쉬지 않고 돌아가요.
그래서 여기서 중요한 단어는 "기본값"이에요. 찾아서 켜야 쓸 수 있는 옵션이 아니라, 아무것도 안 해도 처음부터 켜져 있어야 한다는 거죠. 새로 만든 API 키나 클라우드 프로젝트가 처음부터 적당한 상한을 달고 나오고, 더 쓰고 싶은 사람이 직접 올리는 구조요. 대부분의 사고는 "나중에 설정해야지" 하고 미뤄둔 사이에 터지니까요.
업계는 어디쯤 와 있나
그나마 AI API 쪽이 조금 앞서 있어요. OpenRouter는 키마다 크레딧 한도를 걸 수 있고, Anthropic 콘솔은 워크스페이스 단위로 지출 한도를 정할 수 있어요. OpenAI도 선불 크레딧 방식이라 자동 충전을 꺼두면 사실상 상한처럼 동작하고요.
반면 범용 클라우드는 여전히 보수적이에요. 클라우드 회사는 "한도를 넘었다고 고객의 프로덕션 서비스가 갑자기 내려가는 것"을 더 큰 사고로 보거든요. 저장된 데이터를 어떻게 할지도 골치 아파요. 한도를 넘었다고 데이터베이스나 S3 버킷을 지워버릴 순 없으니까요.
하지만 이건 대기업 프로덕션을 기준으로 한 논리예요. 개인 프로젝트를 하는 사람, 학생, 초기 스타트업에게는 서비스가 하루 멈추는 것보다 청구서 한 장이 훨씬 치명적이에요. 기본값은 '보호' 쪽에 두고, 큰 고객이 필요할 때 해제하게 하는 게 맞다는 게 이 논쟁의 핵심이에요.
한국 개발자가 지금 바로 할 수 있는 것
업계가 바뀌길 기다리기보다 직접 방어선을 치는 게 현실적이에요.
- AWS: Budgets에 알림만 걸지 말고 Budget Actions까지 설정하세요. 임계치에 닿으면 권한을 막는 IAM 정책을 붙이거나 EC2·RDS 인스턴스를 멈추게 할 수 있어요.
- GCP: 예산 → Pub/Sub → Cloud Function으로 결제를 비활성화하는 공식 예제를 미리 적용해 두세요.
- LLM API: 프로젝트마다 키를 따로 만들고 키별·워크스페이스별로 한도를 거세요. 키 하나가 유출돼도 피해는 그 한도 안에서 끝나요.
- 에이전트 코드: 루프 안에 비용 가드를 직접 넣으세요.
MAX_USD = 5.0
spent = 0.0
while not done:
# 호출 전에 '최악의 경우' 비용을 먼저 계산
worst = estimate_input_cost(messages) + max_tokens * OUTPUT_PRICE
if spent + worst > MAX_USD:
raise RuntimeError("예산 초과, 에이전트 중단")
resp = call_llm(messages, max_tokens=max_tokens)
spent += resp.cost
포인트는 호출하기 전에 막는 거예요. 호출한 뒤에 확인하면 돈은 이미 나간 뒤니까요. 한국 개발자에겐 환율이라는 변수도 있어요. 대부분 달러로 청구되니까 같은 실수를 해도 환율이 오르면 피해가 더 커지거든요.
마무리
핵심 한 줄: 에이전트가 밤새 일하는 시대에는 '알림'이 아니라 '멈춤'이 기본값이어야 해요.
여러분은 지금 쓰는 클라우드 계정과 API 키에 하드 상한을 걸어두셨나요? 서비스가 멈추는 것과 요금 폭탄 중에 어느 쪽이 더 무섭다고 생각하세요?
🔗 출처: Hacker News