에이전트에게 서비스를 만들어 배포하라고 맡기면, 코드는 빨리 완성돼도 요금은 사람이 자는 동안 계속 늘 수 있다. 새벽에 도착한 예산 경고를 아침에 읽을 때는 이미 추가 사용료가 쌓인 뒤다. 사이먼 윌리슨은 10월 3일 글에서 사용량 기반 서비스의 기본값을 바꾸자고 주장했다. 월 예산에 도달하면 메일만 보내지 말고, 사용을 막아 오류를 반환하는 상한을 두자는 제안이다.
아마존의 클라우드 서비스인 AWS는 9월 16일 발표한 새 가입·프로젝트 관리 경험에 월별 프로젝트 지출 상한을 넣었다. 구글 클라우드는 7월 29일 특정 프로젝트의 특정 서비스를 멈추는 Spend Caps를 공개 프리뷰로 발표했다. 두 기능의 중단 범위와 출시 조건은 다르다. 창업자와 PM은 배포할 서비스가 어느 상한에 포함되는지 먼저 확인해야 한다.
AWS의 지출 상한은 기존 계정 모두에 열렸나
AWS의 새 경험은 신규 고객에게 점진적으로 제공되고 있다. 공식 설정 문서도 일부 고객에게만 출시 중이라고 명시한다. 기존 AWS 계정에서 예산을 만들 수 있다는 이유만으로 이 프로젝트 지출 상한까지 쓸 수 있다고 판단해서는 안 된다.
이 기능은 유료 플랜에서 프로젝트 소유자가 설정한다. 상한은 월별 세전 비용에 적용하며 크레딧을 제외한다. 최소값은 20달러와 AWS가 보수적으로 추정한 예상 지출 중 더 큰 금액이다. 이미 많은 자원이 실행 중이면 20달러보다 높은 최소값이 나올 수 있다. 공식 경로는 AWS Settings의 Billing에서 Cost by project를 열고 해당 프로젝트의 Set limit을 선택하는 방식이다.
사용량이 상한에 도달하면 AWS는 프로젝트를 일시 중단하고 모든 자원을 멈춘다. 데이터는 보존하며, 다시 쓰려면 상한을 올려 프로젝트를 재활성화해야 한다. 일부 자원은 수동으로 다시 시작해야 할 수 있다. 중단 뒤 90일 동안 조치하지 않으면 프로젝트 데이터가 영구 삭제된다. 실험용 서비스를 멈추는 장치라도 담당자가 잊어버린 채 방치해도 되는 것은 아니다.
구글의 Spend Caps는 어떤 사용료를 멈추나
구글 클라우드의 공식 문서는 Spend Caps를 프리뷰로 표시한다. 적용 단위는 프로젝트 한 개와 지원 서비스 한 개의 조합이며, 기간은 매월 1일부터 시작하는 월 단위로 고정된다. 현재 지원 대상은 Gemini API, Gemini Enterprise Agent Platform(이전 Vertex AI), Cloud Run, Cloud Run functions다. 여러 프로젝트나 서비스를 묶은 예산, 리셀러 계정은 대상이 아니다.
설정 화면에서는 경고 전용 예산인 Alerts only와 사용을 막는 Spend cap enforcement를 따로 고른다. 기존 경고 전용 예산을 편집해 중단형 예산으로 바꿀 수는 없다. 새 예산을 만든 뒤 프로젝트와 서비스를 선택하고 Target amount를 입력해야 한다. 비용이 상한을 넘으면 해당 서비스의 새 사용을 차단하며 다른 프로젝트와 다른 서비스는 유지한다.
구글의 상한은 청구액이 한 푼도 넘지 않는 즉시 차단을 보장하지 않는다. 집행에는 지연이 있고, 이미 진행 중인 요청은 완료까지 처리한다. 보고 지연으로 생긴 초과분도 정상 청구한다. 계속 실행되는 컴퓨팅·스토리지의 고정 비용이나 약정의 고정 요금도 남는다. 일부 서비스는 빠른 집행을 위해 할인·크레딧 차감 전 추정 비용을 쓰므로, 나중에 청구 보고서에서 보는 금액과 상한 판단에 쓰인 금액이 같지 않을 수 있다.
비용 때문에 멈춘 서비스를 누가 다시 열 것인가
AWS에서 프로젝트 전체가 멈추면 그 안의 앱과 데이터베이스를 함께 쓰던 서비스가 영향을 받는다. 구글에서 특정 서비스만 막아도 그 API에 의존하는 앱 기능은 실패할 수 있다. PM은 사용자에게 어떤 오류를 보여 줄지, 유료 호출 없이 제공할 수 있는 기능은 무엇인지 배포 전에 정해야 한다.
구글에서는 예산 편집 화면의 Lift spend cap으로 차단을 수동 해제한다. 서비스가 완전히 복구되기까지 최대 한 시간이 걸릴 수 있다. 같은 청구월에 상한을 해제하면 목표 금액을 올리지 않는 한 남은 달에는 다시 발동하지 않는다. 다음 예산 기간에는 상한이 초기화된다. 담당자가 복구한 뒤 같은 상한이 계속 지켜 줄 것으로 기대하면 비용이 다시 늘 수 있다.
작은 실험 서비스라면 중단을 받아들이고 지출을 제한하는 공급자를 고를 수 있다. 고객 결제를 받는 서비스라면 전체 프로젝트 중단과 특정 기능 중단을 구분해 설계해야 한다. 중단 때 남길 기능을 정하는 사례는 Monzo가 핵심 결제 기능만 별도 환경에 남긴 설계에서 볼 수 있다. 에이전트에게 배포를 맡길 때도 사용료가 생기는 서비스 이름과 상한의 적용 범위를 함께 제출하게 하는 편이 낫다. 알림 예산만 설정했다면 자동 중단을 설정한 것으로 승인하지 않는다.
계약이나 배포 승인서에는 실제 차단 대상과 집행 지연 중의 초과 비용 부담을 적는다. 차단 뒤에도 남는 비용, 복구 담당자와 재시작 절차도 함께 남겨야 한다. 상한 해제 뒤 첫 사용료를 누가 점검할지까지 정해 두면, 서비스 복구가 새로운 요금 사고로 이어지는 것을 줄일 수 있다.
출처: Simon Willison · AWS 발표 · AWS 설정 문서 · Google Cloud Billing 문서