AI 에이전트가 만든 요금 폭탄을 막으려면 사용량 하드 캡이 기본값이어야 한다

종량제 API와 호스팅 서비스에는 '하드 예산 상한'이 기본값으로 들어가야 한다는 제안이 나왔다. 사이먼 윌리슨은 최근 글에서 앞으로 몇 달, 몇 년 사이에 훨씬 더 많은 제품이 갖춰야 할 기능으로 이 하드 캡을 꼽았다. 요금이 사용량에 비례하는 서비스에서 "월 X달러를 넘기면 이걸 차단하고 에러를 돌려달라"고 지정할 수 있어야 한다는 것이다.

핵심은 '하드'라는 조건이다. 한도를 넘겼을 때 경고 메일만 보내는 소프트 캡으로는 부족하다. 실제로 요청을 거부하고 실패 응답을 반환해야 한다. 경고 메일은 이미 벌어진 지출을 사후에 알려줄 뿐, 다음 시간의 과금을 멈추지 못한다.

문제가 커진 배경에는 코딩 에이전트와 개인용 에이전트가 있다. 이들은 유용한 일을 하는 코드를 띄우는 마찰을 크게 낮춰줬는데, 그 코드가 유료 API를 호출하거나 호스팅 웹 애플리케이션을 만들거나 스토리지·컴퓨트를 추가로 과금하는 시스템을 건드리면 비용이 곧바로 발생한다. 자정에 날아온 예산 경고 메일을 아침에 확인했더니, 자는 동안 통제를 벗어난 서비스가 수백에서 수천 달러를 더 써버린 상황은 충분히 현실적이다.

반론도 있다. 호스팅 애플리케이션이 예산 초과를 이유로 갑자기 에러를 뱉기 시작하는 걸 기업이 달가워하지 않는다는 것이다. 하지만 윌리슨의 판단은 반대다. 대부분의 기업과 개인은 예상치 못한 1만 달러 이상의 청구서보다 에러를 택한다는 것이다. 그래서 기본값은 하드 캡이어야 하고, 위험을 감수하려는 사람은 눈에 잘 띄는 체크박스로 명시적으로 해제해야 한다는 구상이다. 한도를 넘겨도 애플리케이션이 종료되지 않으며 이후 요금은 본인이 책임진다는 내용을 확인시키는 방식이다.

가장 이 기능이 필요했던 곳은 AWS다. 개인 프로젝트에 AWS를 쓰기를 거부하는 사람들의 이유는 늘 같았다. 통제를 벗어난 서비스 하나가 파산으로 이어질 수 있다는 두려움이다. 실제로 이런 상황을 예상하지 못했다가 크게 손해를 본 사례도 적지 않다. 그런데 AWS가 지난 9월 16일 새 AWS 경험을 발표하면서 지출 한도를 내놨다. 유료 플랜으로 올릴 때 사용 패턴에 맞춰 프로젝트별 월 지출 한도를 설정할 수 있고, 사용량이 그 한도에 도달하면 해당 프로젝트는 그달 동안 일시중지된다. 다만 AWS 설정에서 지출 한도를 만드는 문서는 현재 새 경험을 제한된 고객에게만 배포 중이라고 경고하고 있어, 기존 계정에서 일반적으로 쓸 수 있게 되기까지는 시간이 더 걸릴 전망이다.

구글 클라우드도 비슷한 흐름에 올라탔다. 지난 7월 선보인 Spend Caps는 프로젝트 안의 특정 서비스에 월 단위 재정 상한을 걸 수 있게 해준다. 서로 다른 클라우드 사업자가 비슷한 시기에 같은 기능을 내놓는다는 건, 사용량 기반 과금의 위험이 개별 사용자 문제가 아니라 업계 공통의 구조적 문제로 인식되기 시작했다는 신호로 읽힌다.

개발자 입장에서 실무적으로 달라지는 지점은 두 가지다. 첫째, 개인 프로젝트나 사이드 프로젝트에 클라우드를 쓰는 문턱이 낮아진다. 예전에는 요금 폭주를 막을 방법이 마땅치 않아 아예 손을 대지 않는 선택이 합리적이었지만, 이제는 프로젝트 단위 상한을 걸어두는 것이 기본 절차가 된다. 둘째, 에이전트가 인프라를 추천하거나 코드를 배포해주는 흐름에서는 상한 설정 여부가 설계 요구사항이 된다. 윌리슨은 에이전트가 하드 예산 캡을 제공하는 공급자를 우선 추천하고, 경험이 적은 개발자에게는 상한 없는 서비스를 쓰지 않도록 경고해주면 좋겠다고 덧붙였다.

주의할 점도 분명하다. AWS의 지출 한도는 아직 제한된 고객에게만 풀린 새 경험이라 모든 계정에서 바로 쓸 수 있다고 가정하면 안 된다. 또 이런 기능은 어디까지나 서비스 사업자가 제공하는 범위 안에서만 작동하므로, 여러 서비스를 조합한 파이프라인이라면 각 구성 요소마다 상한이 걸려 있는지 따로 확인해야 한다.