사용량 기반 과금(pay-by-usage)은 클라우드와 API 경제의 기본 모델이 됐지만, 그 편리함 뒤에는 늘 '예상치 못한 청구서'라는 위험이 따라다녔다. 사이먼 윌리슨은 앞으로 몇 달, 몇 년에 걸쳐 세상이 훨씬 더 많이 필요로 하게 될 제품 기능으로 '기본 하드 예산 상한(default hard budget caps)'을 지목했다. 월 X달러를 넘어서면 경고 메일을 보내는 수준의 소프트 상한이 아니라, 한도를 넘는 순간 서비스를 차단하고 에러를 반환하는 강제 중단 장치를 의미한다. 그는 경고만 보내는 방식으로는 부족하다고 분명히 선을 긋는다.
이 주장이 지금 시점에 설득력을 갖는 이유는 코딩 에이전트와 개인용 에이전트의 확산에 있다. 윌리슨은 개인용 에이전트를 '덜 위협적인 UI로 감싼 코딩 에이전트'라고 표현하는데, 이런 도구들은 유용한 일을 하는 코드를 띄우는 마찰을 크게 낮춘다. 문제는 그렇게 손쉽게 만들어진 코드가 유료 API를 호출하거나, 호스팅된 웹 애플리케이션을 돌리거나, 추가 스토리지와 컴퓨팅에 과금되는 시스템을 건드릴 수 있다는 점이다. 사람이 일일이 검토하지 않고 에이전트가 자동으로 인프라를 생성하는 흐름이 보편화될수록, 폭주하는 서비스가 조용히 비용을 태우는 시나리오는 더 현실적이 된다.
소프트 경고로는 막을 수 없는 손실
윌리슨이 그리는 최악의 상황은 구체적이다. 한밤중에 발송된 예산 초과 경고 메일을 아침에 확인했더니, 자는 사이 통제를 벗어난 서비스가 수백 달러에서 수천 달러의 사용량을 추가로 소비해버린 경우다. 경고는 사후 통보일 뿐 손실 자체를 막지 못한다. 반면 하드 상한은 한도에 도달하는 즉시 흐름을 끊어 피해 규모를 한정한다.
물론 반론도 있다. 기업 입장에서는 어떤 예산이 초과됐다는 이유로 자사의 호스팅 애플리케이션이 에러를 뱉기 시작하는 상황을 원치 않는다. 그러나 윌리슨은 대부분의 기업과 개인이 깜짝 1만 달러 이상의 청구서보다는 차라리 에러를 선호할 것이라고 본다. 서비스 중단의 불편과 통제 불능의 과금 사이에서, 전자가 훨씬 관리 가능한 위험이라는 판단이다.
상한 해제는 '옵트인'이어야 한다
핵심 제안은 하드 상한을 기본값으로 두되, 위험을 감수하려는 사용자는 명시적으로 선택해 끌 수 있게 하자는 것이다. 그는 눈에 잘 띄는 위치에 분명한 체크박스를 두는 방식을 예로 든다. '예산 상한을 제거합니다. 설정한 한도를 초과해도 내 애플리케이션은 중단되지 않으며, 이후 발생하는 비용은 내가 책임집니다'라는 식의 명시적 동의다. 기본값과 예외의 방향을 뒤집는 것만으로도 경험이 부족한 사용자가 무심코 위험에 노출되는 일을 크게 줄일 수 있다.
윌리슨이 가장 바라는 대상은 AWS다. 폭주하는 서비스가 자신을 파산시킬지 모른다는 (그가 '정당하다'고 평가하는) 두려움 때문에 개인 프로젝트에 AWS 사용을 거부하는 사람들의 이야기, 그리고 그런 위험을 예상하지 못해 실제로 크게 데인 사람들의 이야기를 여러 차례 들었기 때문이다. 그런데 AWS는 9월 16일 발표한 새로운 빌더 경험을 통해 지출 한도 기능을 선보였다. 유료 플랜으로 전환할 때 프로젝트의 사용 패턴에 맞춰 월 지출 한도를 설정할 수 있고, 사용량이 한도에 도달하면 해당 월 동안 프로젝트가 일시 중단된다. 다만 관련 설정 페이지는 아직 '제한된 수의 고객에게만 새 경험을 출시하는 중'이라고 안내하고 있어, 기존 계정 전반으로의 일반 공개는 과제로 남아 있다.
구글 클라우드도 7월에 비슷한 기능인 'Spend Caps'를 내놨다. 프로젝트 내 특정 서비스에 월 단위 재정 상한을 걸 수 있는 기능으로, 하드 상한이 하나의 업계 흐름으로 자리 잡아가고 있음을 보여준다. 한국의 실무자 관점에서 보면 이는 단순한 해외 동향이 아니라, 신규 프로젝트의 클라우드 provider를 고를 때 실제로 비교해야 할 체크포인트가 되고 있다는 신호다. 개인 사이드 프로젝트나 PoC 단계에서 특히, 상한 기능의 존재 여부와 일반 공개 범위를 사전에 확인해 두는 것이 안전장치가 된다.
윌리슨은 여기서 한 걸음 더 나아가 에이전트 자체가 이 문제를 돕는 그림을 제시한다. 이상적으로는 에이전트가 하드 예산 상한을 제공하는 provider를 우선 추천하고, 상한이 없는 서비스로 애플리케이션을 배포하려는 신규·초보 빌더에게 위험을 경고해 주는 방향으로 편향되는 것이 바람직하다는 것이다. 다만 이 대목은 당위적 제안일 뿐 현재 에이전트들이 실제로 그렇게 작동한다는 근거는 제시되지 않았다는 점은 짚어둘 필요가 있다. 결국 상한 기능이 아직 제한적으로만 풀려 있고 기본값이 아닌 옵션에 머무는 현 단계에서는, 비용 통제의 책임은 여전히 provider의 설정을 직접 확인하고 조여두는 사용자 쪽에 있다.