Cloudflare가 셀프서비스 계정을 위한 Billable Usage API를 공개했다. 이 API는 계정에서 발생한 사용량과 비용을 제품 및 과금 구간별로 조회할 수 있게 한다. Workers, R2, D1, Workers AI, Vectorize, Images, Stream을 비롯해 계정에서 사용하는 사용량 기반 제품을 한 번의 호출로 확인할 수 있어, 대시보드 조회와 수동 내보내기에 의존하던 비용 수집 작업을 자동화하기 쉬워졌다.
다만 실시간 비용 차단 장치로 이해해서는 안 된다. 현재 사용량과 비용 데이터는 매일 갱신되며, Cloudflare는 향후 더 실시간에 가까운 데이터 제공을 목표로 하고 있다. 또한 API가 반환하는 과금 구간은 대부분 제품에서 일별이지만, 데이터 갱신 주기와 각 행이 나타내는 과금 구간은 서로 다른 개념이다. 배포 직후의 급격한 사용량 증가를 즉시 탐지해야 한다면 운영 지표를 별도로 감시해야 한다.
API가 반환하는 정보
엔드포인트는 계정 식별자를 경로에 포함하며, from과 to 조건으로 조회 기간을 지정할 수 있다. 응답의 각 행은 계정 내 한 제품의 한 과금 구간을 나타낸다. 계정 전체 합계만 반환하는 방식이 아니므로 어떤 제품이 비용 변화를 만들었는지 추적하는 데 적합하다.
응답은 Cloudflare의 표준 API 봉투 구조를 사용한다. 사용량 행이 담긴 result 배열과 함께 success, errors, messages가 제공된다. 수집기를 구현할 때는 HTTP 상태뿐 아니라 이 필드들도 검사해야 성공, 오류, 빈 결과를 구분하기 쉽다.
| 필드 | 의미와 활용 |
|---|---|
| ServiceName | Workers Standard, R2 Storage처럼 과금되는 서비스 이름이다. 제품별 비용 보고에 활용할 수 있다. |
| ServiceFamilyName | Workers, R2 같은 Cloudflare 제품군이다. 여러 세부 서비스를 상위 제품군으로 묶을 때 유용하다. |
| ChargePeriodStart, ChargePeriodEnd | 해당 행이 포괄하는 과금 구간이다. 기간별 비교와 중복 적재를 판단하는 기준이 된다. |
| ConsumedQuantity, ConsumedUnit | 사용량과 측정 단위다. 요청, 저장 용량, 연산량 등 비용 변화의 원인을 분석할 수 있다. |
| PricingQuantity | 가격 계산에 대응하는 수량 필드다. 사용량 데이터와 함께 보존해 과금 구조를 분석할 수 있다. |
| ContractedCost, BillingCurrency | 해당 구간의 비용과 통화다. 예산 집계나 다른 공급자의 비용 데이터와 결합할 때 필요하다. |
| CumulatedPricingQuantity, CumulatedContractedCost | 현재 청구 기간의 누적 수량과 누적 비용이다. 월중 지출 추세를 살피는 데 사용할 수 있다. |
| ZoneId, ZoneName | 사용량이 특정 존에 귀속될 때 제공되는 식별 정보다. 모든 행에 존재한다고 가정해서는 안 된다. |
FOCUS와 비슷하지만 아직 완전 준수는 아니다
Cloudflare는 필드 이름과 의미를 FinOps Open Cost and Usage Specification, 즉 FOCUS에 맞추는 방향으로 설계했다. BillingCurrency, BillingPeriodStart, ChargePeriodStart, ChargePeriodEnd, ServiceName, ConsumedQuantity, ConsumedUnit, PricingQuantity, ContractedCost 등은 FOCUS 열과 직접 대응한다. 다른 공급자의 FOCUS 형식 데이터를 이미 처리하는 조직이라면 기존 변환 규칙과 분석 모델을 일부 재사용할 수 있다.
그러나 현재 응답이 FOCUS를 완전히 준수하는 것은 아니다. Cloudflare는 규격상 필요한 일부 열이 아직 payload에 없으며 완전한 준수는 향후 계획이라고 밝혔다. ServiceFamilyName은 Cloudflare 고유의 분류이고, FOCUS의 ServiceCategory는 통제된 어휘를 사용한다. 누적 비용은 편의를 위해 제공되는 파생 필드이며, ZoneId와 ZoneName도 FOCUS의 ResourceId와 ResourceName에 가까운 필드일 뿐 동일하다고 단정할 수 없다.
따라서 기존 FOCUS 파이프라인에 연결할 때는 필드 이름이 비슷하다는 이유만으로 의미까지 같다고 가정하지 않는 편이 안전하다. 누락된 필수 열을 어떻게 처리할지, Cloudflare 전용 필드를 별도로 보존할지, 새 필드가 추가됐을 때 파서가 실패하지 않도록 할지를 먼저 정할 필요가 있다.
어떤 자동화에 유용한가
- 제품별 비용 분석: Workers, R2, D1 등 어느 제품의 사용량이 비용 변화를 만들었는지 구분할 수 있다.
- 반복 보고 자동화: 대시보드 화면이나 수동 내보내기 대신 정기적인 API 수집 작업을 구성할 수 있다.
- 다중 공급자 집계: Cloudflare 비용을 다른 클라우드 및 SaaS 비용과 같은 저장소나 보고 체계에 적재할 수 있다.
- 비용 귀속 기반 마련: 계정, 제품, 적용 가능한 경우 존 정보를 내부 팀이나 서비스와 연결할 수 있다.
- 일별 비용 알림: 수집한 데이터를 기준선과 비교해 평소와 다른 지출 증가를 알림 시스템으로 전달할 수 있다.
API가 팀이나 고객별 비용 배분을 자동으로 완성해 주는 것은 아니다. 계정, 제품, 존을 내부 프로젝트와 연결하는 매핑 규칙은 사용자가 마련해야 한다. ZoneId와 ZoneName이 없는 비용도 수용할 수 있도록 저장소에서는 이 필드를 선택 값으로 취급하는 것이 적절하다.
도입 전에 확인할 조건
셀프서비스 계정 대상
첫 출시의 적용 대상은 모든 셀프서비스 계정이며 Enterprise 계약용 경험은 개발 중이다. 발표는 계정 내 사용량 기반 Cloudflare 제품을 포괄한다고 설명한다. 이를 고정 요금이나 별도 계약 항목까지 모두 같은 방식으로 제공한다는 의미로 확대해서는 안 된다. 운영에 사용하기 전에는 실제 응답을 현재 청구 자료와 대조해 필요한 비용 범주가 포함되는지 확인해야 한다.
Billing Read 권한과 토큰 관리
Cloudflare는 Billing Read 권한을 가진 API 토큰으로 호출하도록 안내한다. Vantage 연동 역시 이 읽기 전용 권한을 사용한다. 자체 수집기에서도 비용 조회에 필요한 최소 권한만 부여한 전용 토큰을 사용하는 것이 좋다. 토큰을 소스 코드나 클라이언트 애플리케이션에 포함하지 않고 조직의 비밀정보 관리 방식에 따라 주입하는 것도 필요한 운영 조치다.
비용 데이터에는 사용 제품과 지출 변화가 드러날 수 있다. 저장 위치, 접근 범위, 보존 기간과 외부 서비스 전송 여부는 조직의 보안 기준에 따라 결정해야 한다. 이는 API가 강제하는 별도 정책이 아니라 도입 조직이 검토할 운영 원칙이다.
일별 갱신에 맞는 용도
현재 데이터는 매일 갱신되므로 청구 관점의 비용 보고와 추세 확인에 우선 적합하다. 분 단위 이상 징후 탐지나 즉시 차단이 필요하다면 Workers 호출 수나 R2 작업량 같은 운영 지표를 함께 감시해야 한다. Billable Usage API만으로 실시간 장애 대응 지표를 대체하려 해서는 안 된다.
정기 수집기는 같은 기간을 다시 조회할 수 있다는 전제에서 중복을 처리하도록 설계하는 편이 좋다. 제품, 과금 시작·종료 시각, 계정과 적용 가능한 존 식별자를 보존하면 같은 행을 갱신하거나 비교하기 쉽다. 개별 구간 비용과 누적 비용을 동시에 합산하면 이중 계산이 생길 수 있으므로 보고서에서 어느 값을 합계 기준으로 사용할지도 명확히 해야 한다.
발표만으로 확정할 수 없는 항목
제공된 발표에는 API 자체의 별도 요금, 호출 한도, 조회 가능한 전체 과거 기간과 데이터 보존 범위가 명시돼 있지 않다. 따라서 이런 조건을 추정해서 운영 설계에 반영해서는 안 된다. 여러 계정을 자주 조회하거나 장기 데이터를 복원해야 한다면 최신 공식 API 문서와 계정에 적용되는 조건을 별도로 확인해야 한다.
작게 검증하는 적용 순서
- 셀프서비스 계정 하나와 짧은 조회 기간을 정한다.
- Billing Read 권한만 가진 전용 API 토큰을 준비한다.
- 날짜 범위를 지정해 호출하고 HTTP 상태와 success, errors, messages를 기록한다.
- result의 각 행을 제품, 과금 구간, 사용 단위, 비용과 통화 기준으로 저장한다.
- 같은 기간의 대시보드 또는 청구 자료와 비교해 제품별 사용량과 비용 차이를 확인한다.
- ZoneId처럼 없을 수 있는 값과 앞으로 추가될 수 있는 필드를 허용하도록 파서를 점검한다.
- 수집 결과가 안정적이면 비용 보고, 이상 증가 알림, 내부 배분 중 필요한 흐름부터 연결한다.
조회 결과가 비어 있을 때는 사용량이 없었던 것인지, 계정·권한·기간 조건이 잘못된 것인지 구분할 필요가 있다. 실패한 요청의 오류 내용을 남기고 재시도 횟수를 제한하는 방식도 수집기 운영을 안정시키는 실무적 권고다.
Vantage 연동과 직접 구축
Cloudflare는 비용 관리 플랫폼 Vantage와의 기본 연동도 소개했다. Vantage는 Billing Read 권한의 읽기 전용 토큰으로 연결한 뒤 Billable Usage 데이터를 매일 가져와 제품, 존, 계정 기준으로 나눈다. 기존 Cost Reports, Budgets, Cost Alerts에 Cloudflare 지출을 포함할 수 있으며, 다른 공급자의 비용과 함께 배분하거나 평소 기준선에서 벗어난 지출을 알리는 흐름도 지원한다.
여러 공급자와 계정을 이미 Vantage에서 관리한다면 기본 연동으로 수동 내보내기와 별도 대시보드를 줄일 수 있다. 반대로 계정 하나의 간단한 일별 보고만 필요하다면 API를 직접 호출해 필요한 저장과 알림만 구성하는 방식도 가능하다. 외부 서비스를 선택할 때는 발표만으로 가격이나 모든 계정의 지원 조건을 추정하지 말고, 토큰 보관 방식과 데이터 전송 범위, 접근 해제 절차를 해당 서비스의 최신 문서에서 확인해야 한다.
판단 기준
여러 Cloudflare 제품의 비용을 반복해서 확인하거나, 여러 계정과 공급자의 지출을 한곳에서 집계하거나, 제품과 존 단위의 비용 귀속이 필요한 조직에는 우선순위가 높다. 자동화된 프로그램이 Workers를 배포하고 R2 버킷이나 D1 데이터베이스를 관리하는 환경에서도 비용 가시성을 같은 자동화 흐름에 넣을 수 있다.
반면 계정 하나의 사용량 변화가 작고 월별 대시보드 확인으로 충분하다면 별도 수집기를 유지할 실익이 크지 않을 수 있다. 채택 여부는 API의 존재 자체보다 수동 내보내기, 비용 합산, 증가 원인 확인 같은 반복 작업을 얼마나 줄일 수 있는지로 판단하는 편이 합리적이다.
출처와 검증
기능 범위, 셀프서비스 계정 지원, 일별 데이터 갱신, 응답 필드, FOCUS 호환 수준과 Vantage 연동은 Cloudflare의 2026년 8월 3일 발표를 기준으로 정리했다. 운영 환경에 적용하기 전에는 공식 API 문서에서 현재의 응답 스키마, 인증 권한, 호출 한도, 조회 기간과 가격 조건을 다시 확인해야 한다. 원문: Cloudflare Blog — Introducing the Billable Usage API