AI로 만든 서비스, 경고 메일보다 ‘실제로 멈추는’ 비용 상한이 먼저다

AI 코딩 도구로 만든 작은 서비스를 띄워 두고 잠들었는데, 아침에 일어나 보니 메일함에 ‘예산 한도에 가까워졌다’는 알림이 와 있습니다. 알림이 온 시각은 자정이었고, 그 사이 서비스는 멈추지 않고 계속 돌았습니다. 청구 금액은 이미 알림 기준을 한참 넘어 있습니다. 개발자 사이먼 윌리슨(Simon Willison)이 최근 글에서 그린 장면이 바로 이것입니다. 그는 이런 일을 막으려면 쓰는 만큼 돈을 받는 서비스마다 기본으로 켜진 강제 상한이 필요하다고 주장합니다.

경고 메일은 쌓이는 비용을 멈추지 못합니다

윌리슨이 말하는 강제 상한은 “한 달에 얼마를 넘으면 이 서비스를 끊고 오류를 돌려주라”는 기능입니다. 반대편에는 “얼마를 넘으면 경고 메일을 보내라”는 부드러운 상한이 있는데, 그는 이것으로는 충분하지 않다고 봅니다. 이유는 AI 코딩 에이전트에 있습니다. 에이전트는 돈이 드는 코드를 띄우는 문턱을 크게 낮췄습니다. 유료 API 호출, 호스팅되는 웹 앱, 저장 공간과 연산을 추가로 청구하는 시스템까지, 몇 마디 지시만으로 실제 과금이 일어나는 구조가 만들어집니다. 사람이 자는 동안 잘못 짜인 서비스가 수백, 많게는 수천 달러를 더 쓸 수 있고, 경고 메일은 그 사이 아무것도 멈추지 않습니다.

서비스가 갑자기 오류를 내는 것을 싫어하는 사업자도 있을 것이라는 반론에 대해 윌리슨은, 대부분의 기업과 개인은 예상하지 못한 10,000달러가 넘는 청구서보다 차라리 오류를 택할 것이라고 답합니다. 그래서 상한은 기본값으로 켜 두고, 위험을 감수하고 싶은 사람만 눈에 잘 띄는 체크 상자를 직접 눌러 해제하는 방식이어야 한다는 것입니다. 구글 클라우드도 같은 문제를 비슷하게 설명합니다. 생성형 AI는 다섯 단어짜리 프롬프트 하나로 복잡한 작업을 돌리고 상당한 비용을 만들 수 있어서, 초당 요청 수 같은 기존 지표로는 청구 금액을 가늠하기 어렵다는 것입니다.

큰 클라우드 두 곳이 같은 방향으로 움직이기 시작했습니다

이 주장이 의견에 그치지 않는 것은 실제 제품이 따라오고 있기 때문입니다. AWS는 새로 시작하는 개발자를 위한 간소화된 가입 화면을 내놓으면서 프로젝트마다 월 지출 한도를 걸 수 있게 했습니다. 안내에 따르면 대부분의 신규 고객은 신용카드 없이 가입해 최대 200달러의 무료 크레딧을 받고, 코딩 에이전트를 프롬프트 한 번으로 AWS에 연결할 수 있습니다. 유료로 넘어갈 때 프로젝트별 한도를 정해 두면, 사용량이 한도에 닿는 순간 그 프로젝트는 그달 동안 멈춥니다. 에이전트로 빠르게 만들게 해 주는 기능과 비용 상한이 처음부터 한 묶음으로 들어간 셈입니다.

구글 클라우드는 그보다 앞서 ‘지출 상한(Spend Caps)’을 공개 미리보기로 내놓았습니다. 한 프로젝트 안의 특정 서비스에 월 상한을 걸고, 누적 비용이 그 금액에 닿으면 그 서비스의 과금 사용만 막는 방식입니다. 대상은 Gemini API, 에이전트 플랫폼, Cloud Run 같은 AI와 서버 서비스입니다. 구글은 일반 청구 데이터는 정산에 몇 시간이 걸릴 수 있지만, AI 서비스의 지출 상한은 기준에 닿고 몇 분 안에 작동한다고 설명합니다. 함께 나온 ‘조기 이상 감지’는 프로젝트의 과거 비용으로 평소 수준을 계산해 두고, 하루 비용이 비정상적으로 오르면 원인이 된 상위 3개 항목을 짚어 알려 줍니다.

상한이 걸리는 방식은 생각보다 세밀하게 설계돼 있습니다

AWS 문서를 보면 지출 한도가 단순한 차단 스위치가 아니라는 점이 드러납니다. 한도는 세금 전 비용의 최댓값이고, 설정할 수 있는 최솟값은 20달러와 ‘보수적으로 추정한 예상 지출’ 중 큰 쪽입니다. 평소 사용량의 작은 변동만으로 서비스가 멈추는 일을 막기 위해서입니다. 실제 비용이 한도의 50%, 75%, 90%에 닿을 때, 그리고 앞으로 10일 안에 한도를 넘을 것으로 보일 때 알림이 옵니다.

여기에 더 일찍, 더 부드럽게 작동하는 선택 기능이 붙습니다. 한도에 닿기 7일쯤 전에는 새 자원 생성을 막고, 5일쯤 전에는 쉬고 있는 자원을 멈추며, 4일쯤 전에는 비용을 가장 많이 쓰는 자원을 멈춥니다. ‘쉬고 있다’의 기준도 구체적입니다. 가상 서버(EC2)는 최근 14일 동안 최대 CPU 사용률이 5% 미만이고 네트워크 사용량이 하루 5MB 미만이면 멈춥니다. 끝내 한도에 닿으면 프로젝트 전체가 멈추지만 데이터는 남습니다. 다만 멈춘 뒤 90일 동안 아무 조치를 하지 않으면 프로젝트 데이터가 영구 삭제되고, 이 기능이 아직 일부 고객에게만 순차적으로 열리고 있다는 점은 알고 써야 합니다.

구글의 지출 상한은 범위를 더 좁게 잡습니다. 상한에 걸린 서비스만 멈추고 데이터나 자원은 지우지 않으며, 범위 밖의 서비스는 그대로 돌아갑니다. 예산의 50%, 80%, 100%에서 청구 관리자와 프로젝트 소유자에게 메일이 가고, 막힌 사용은 예산 화면에서 클릭 한 번으로 풀 수 있습니다. 대신 약정 할인처럼 계약으로 정해진 고정 요금은 상한이 걸려도 계속 청구됩니다. 두 회사 모두 멈추면 곤란한 운영 서비스보다 실험과 개발 환경을 먼저 겨냥한다는 점도 눈여겨볼 만합니다. AWS 문서는 지출 한도가 실험·학습·시험용으로 설계됐고, 잠깐 멈춰도 괜찮은 경우에만 운영 환경에 쓸 수 있다고 적고 있습니다.

작은 온라인 사업일수록 ‘멈춤’이 더 싼 보험입니다

AI로 웹사이트에 상담 기능을 붙이거나, 매일 자료를 모아 글을 만드는 자동화를 돌리는 혼자 일하는 사업자에게 이 흐름은 남의 이야기가 아닙니다. 큰 회사에는 비용 담당자와 사내 규칙이 있지만, 혼자 운영하는 서비스에서는 반복문 하나, 잘못된 자동 호출 하나가 한 달 매출보다 큰 청구서로 돌아올 수 있습니다. 구글이 위험 사례로 ‘폭주하는 모델, 무한 반복, 거대한 조회’를 꼽은 것도 같은 맥락입니다.

그래서 새 서비스를 띄울 때는 기능보다 먼저 비용이 어디서 생기는지 적어 보는 편이 낫습니다. AI API 키, 서버, 저장소처럼 쓰는 만큼 청구되는 곳마다 경고만 오는지, 실제로 끊기는 상한이 있는지 확인하는 것입니다. 상한이 없는 서비스라면 사용량 제한을 건 API 키를 따로 쓰거나 시험용 프로젝트를 분리해 사고가 나도 피해가 한곳에 머물게 할 수 있습니다. 윌리슨은 한 걸음 더 나아가, 코딩 에이전트가 처음부터 강제 상한이 있는 공급자를 추천하고 상한 없는 서비스에 배포하려는 초보자에게 경고해 주기를 기대합니다.

물론 지금의 상한 기능은 일부 고객과 일부 서비스에만 열려 있고, 서비스가 멈췄을 때 잃는 고객과 매출은 사업마다 따로 따져야 합니다. 그래도 순서는 분명해 보입니다. 자는 동안 불어난 청구서는 되돌리기 어렵지만, 멈춘 서비스는 버튼 하나로 다시 켤 수 있습니다.

AI로 서비스를 빠르게 만들수록, 경고 메일이 아니라 실제로 멈추는 비용 상한을 먼저 걸어 두어야 합니다.