2025년 7월 15일·3분
사용량 기반 과금 구현: 미터링과 정산
사용량 기반 과금 구현: 무엇을 계량할지, 어디서 합계를 계산할지, 송장 발행 전에 과금 버그를 잡는 정산 점검 항목들.
사용량 기반 과금 구현: 무엇을 계량할지, 어디서 합계를 계산할지, 송장 발행 전에 과금 버그를 잡는 정산 점검 항목들.
사용량 과금은 송장에 적힌 숫자가 제품이 실제로 제공한 것과 일치하지 않을 때 깨집니다. 처음엔 작은 차이(몇 건의 누락된 API 호출)로 시작하다가 환불, 화난 고객 티켓, 그리고 대시보드를 신뢰하지 못하는 재무팀으로 커집니다.
원인은 대개 예측 가능합니다. 서비스가 사용량을 보고하기 전에 크래시가 나서 이벤트가 사라지거나, 큐가 다운되거나, 클라이언트가 오프라인이 되는 경우 이벤트가 누락됩니다. 재시도 때문에 이벤트가 두 번 세어지거나, 워커가 같은 메시지를 재처리하거나, 임포트 작업이 다시 실행되는 경우 중복 집계가 발생합니다. 시간은 자체 문제를 만듭니다: 서버 간 시계 차이, 시간대, 서머타임, 그리고 지연 도착 이벤트가 사용량을 잘못된 청구 기간으로 밀어 넣을 수 있습니다.
간단한 예: AI 생성당 과금하는 채팅 제품은 요청이 시작될 때 이벤트를 하나, 완료될 때 또 하나를 발생시킬 수 있습니다. 시작 이벤트로 과금하면 실패에 대해 과금할 수 있고, 완료 이벤트로 과금하면 최종 콜백이 도착하지 않으면 사용량을 놓칠 수 있습니다. 둘 다 과금하면 이중 청구가 됩니다.
여러 사람이 같은 숫자를 신뢰해야 합니다:
목표는 단순히 정확한 합계가 아닙니다. 설명 가능한 송장과 빠른 분쟁 처리입니다. 항목을 원시 사용량으로 추적할 수 없다면 하나의 장애가 청구를 추측으로 만들고, 그때 청구 버그는 큰 사고로 번집니다.
한 가지 간단한 질문으로 시작하세요: 정확히 무엇에 대해 과금하나요? 단위와 규칙을 1분 안에 설명할 수 없다면 시스템이 추측하게 되고 고객이 알아차립니다.
미터당 하나의 주요 청구 단위를 선택하세요. 일반적인 선택지는 API 호출, 요청, 토큰, 컴퓨트 분, 저장 GB, 전송 GB, 또는 좌석 수입니다. 혼합 단위(예: “활성 사용자 분”)는 정말 필요하지 않다면 피하세요. 감사와 설명이 더 어렵습니다.
사용의 경계를 정의하세요. 사용이 언제 시작되고 끝나는지 구체적으로 정하세요: 체험판에 초과 사용이 포함되는가, 아니면 상한까지 무료인가? 유예 기간을 제공하면 유예 중의 사용량을 나중에 청구하나요, 아니면 탕감하나요? 요금제 변경 시 혼란이 가장 많이 생깁니다. 비례 배분(prorate)할지, 즉시 한도를 재설정할지, 다음 청구 주기부터 적용할지 결정하세요.
반올림과 최소 단위를 문서화하세요. 예: 초/분/1,000 토큰 단위로 올림, 일일 최소 청구 적용, 또는 최소 청구 단위(예: 1MB) 강제 등. 이런 작은 규칙들이 큰 “왜 청구되었나요?” 티켓을 만듭니다.
초기에 확정해둘 규칙들:
예: 한 팀이 Pro 요금제를 쓰다가 월 중간에 업그레이드하면, 업그레이드 시 한도를 재설정하면 한 달에 두 번 무료 한도를 받는 셈이 될 수 있습니다. 재설정하지 않으면 업그레이드한 고객이 불이익을 받는다고 느낄 수 있습니다. 어느 선택이든 일관되고 문서화되어 시험 가능해야 합니다.
청구 가능한 이벤트가 무엇인지 결정하고 데이터를 기록하세요. 이벤트만으로 “무슨 일이 일어났는가”의 이야기를 재생할 수 없다면 분쟁 시 추측하게 됩니다.
“사용이 발생했다”뿐만 아니라 고객이 지불해야 할 것이 바뀌는 이벤트도 필요합니다.
대부분의 청구 버그는 문맥 부족에서 옵니다. 지루한 필드를 지금 캡처하면 지원, 재무, 엔지니어링이 나중에 질문에 답할 수 있습니다.
지원 등급 메타데이터도 유용합니다: 요청 ID 또는 트레이스 ID, 리전, 앱 버전, 적용된 가격 규칙 버전. 고객이 “2:03 PM에 두 번 청구되었어요”라고 하면 이 필드들이 무슨 일이 있었는지 증명하고 안전하게 되돌리며 반복을 방지하게 해줍니다.
첫 번째 규칙은 간단합니다: 작업이 실제로 발생한 것을 진짜로 아는 시스템에서 청구 이벤트를 발생시키세요. 대부분의 경우 이는 브라우저나 모바일이 아니라 서버입니다.
클라이언트 측 카운터는 조작하기 쉽고 잃어버리기 쉽습니다. 사용자가 요청을 차단하거나 재생하거나 오래된 코드를 실행할 수 있습니다. 악의가 없어도 모바일 앱이 크래시하고 시계가 어긋나며 재시도가 발생합니다. 클라이언트 신호를 읽어야 한다면 힌트로만 취급하고 송장 근거로 삼지 마세요.
실무적으로는 영구화된 지점(레코드를 영속화했을 때, 작업을 완료했을 때, 증명할 수 있는 응답을 전달했을 때)에 사용량을 발생시키는 것이 좋습니다. 신뢰할 수 있는 방출 지점 예시:
오프라인 모바일은 주요 예외입니다. Flutter 앱이 연결 없이 작동해야 하면 로컬에서 사용량을 추적하고 나중에 업로드할 수 있습니다. 가드레일을 추가하세요: 고유 이벤트 ID, 디바이스 ID, 단조 증가 시퀀스 번호를 포함하고 서버에서 계정 상태, 요금제 한도, 중복 ID, 불가능한 타임스탬프를 검증하세요. 앱이 재연결되면 서버는 이벤트를 멱등하게 수용해 재시도로 중복 과금이 일어나지 않게 해야 합니다.
이벤트 타이밍은 사용자가 기대하는 바에 따라 달라집니다. API 호출처럼 사용자가 대시보드에서 실시간으로 보는 경우 실시간이 필요합니다. 몇 분 단위의 근실시간(near real time)은 보통 충분하고 비용도 적습니다. 배치 방식은(예: 스캔 같은 고빈도 신호) 지연을 명확히 고지하고 같은 출처 규칙을 적용해 지연 데이터가 과거 송장을 조용히 변경하지 않도록 하세요.
두 가지가 필요합니다. 원시 이벤트(무슨 일이 일어났는지)와 파생된 합계(청구할 항목). 원시 이벤트는 진실의 근원이고 집계는 빠르게 조회하고 송장으로 전환하는 데 사용됩니다.
총계를 계산할 수 있는 두 장소가 일반적입니다. 데이터베이스에서 계산(SQL 작업, 물질화 테이블, 예약 쿼리)은 처음에 운영이 쉽고 데이터에 로직이 가까이 있습니다. 전용 집계기 서비스(이벤트를 읽어 롤업을 쓰는 작은 워커)는 버전 관리, 테스트, 확장이 쉽고 제품 전반에 일관된 규칙을 강제하기 좋습니다.
원시 이벤트는 버그, 환불, 분쟁에서 보호해 줍니다. 집계는 느린 송장과 비싼 쿼리로부터 보호해 줍니다. 집계만 저장하면 잘못된 규칙 하나가 기록을 영구적으로 손상할 수 있습니다.
실무 구성 예:
집계 창을 명시적으로 정하세요. 청구 시간대를 선택하고 고수하세요. “하루” 경계는 시간대에 따라 달라지고 고객은 사용량이 다른 날로 이동하면 알아차립니다.
지연 및 순서 불일치 이벤트는 정상입니다(오프라인 모바일, 재시도, 큐 지연). 과거 송장을 조용히 변경하지 마세요. 닫고 동결하는 규칙을 사용하세요: 청구 기간이 청구되면 수정은 다음 송장의 조정 항목으로 기록하세요.
예: API 호출을 월별로 과금하면 대시보드를 위한 시간별 집계, 경보를 위한 일별 집계, 송장을 위한 월별 동결 합계를 만들 수 있습니다. 200건의 호출이 이틀 늦게 도착하면 이를 기록하되 다음 달에 +200 조정으로 청구하고 지난달 송장을 다시 쓰지 마세요.
중복 과금과 누락은 보통 같은 근원에서 옵니다: 시스템이 이벤트가 새 것인지, 중복인지, 또는 유실되었는지 구별하지 못함. 해결책은 이벤트 정체성과 검증에 대한 엄격한 통제입니다.
idempotency 키가 첫 방어선입니다. 실제 행동에 대해 안정적인 키를 생성하세요. 좋은 키는 결정적이고 청구 단위당 고유합니다. 예: tenant_id + billable_action + source_record_id + time_bucket(시간 기반 단위인 경우 시간 버킷을 사용). 이를 수신 데이터베이스나 이벤트 로그의 첫 번째 영구 쓰기 지점에서 고유 제약으로 강제하세요.
재시도와 타임아웃은 정상입니다. 클라이언트가 504 이후 같은 이벤트를 보낼 수 있습니다. 규칙은: 반복을 수용하되 두 번 계산하지 않는 것입니다. 수신과 집계를 분리하세요: 멱등하게 한 번 수신한 뒤 저장된 이벤트에서 집계하세요.
검증은 불가능한 사용량이 합계를 손상시키지 않게 합니다. 수신과 집계에서 모두 검증하세요.
누락된 사용량은 발견하기 가장 어렵습니다. 수신 오류를 1급 데이터로 취급하세요. 실패한 이벤트도 동일한 필드로 별도로 저장하고(아이덴포텐시 키 포함) 오류 사유와 재시도 횟수를 기록하세요.
사용량 기반 과금은 송장 합계가 제품이 실제로 제공한 것과 일치하지 않을 때 깨집니다.
일반적인 원인은:
해결은 "더 나은 수학"이 아니라 이벤트를 신뢰할 수 있고, 중복 제거되며, 끝에서 끝으로 설명 가능하게 만드는 것입니다.
미터당 하나의 명확한 단위를 선택하고 한 문장으로 정의하세요(예: “성공한 API 요청 하나” 또는 “완료된 AI 생성 하나”).
그다음 고객이 이의제기할 규칙들을 적어 두세요:
단위를 빠르게 설명할 수 없다면, 나중에 감사하고 지원하기 어려워집니다.
소비만이 아니라 요금에 영향을 주는 이벤트도 추적하세요.
최소한 다음을 기록하세요:
이렇게 하면 요금제가 바뀌거나 수정이 있을 때 송장을 재현할 수 있습니다.
나중에 후회하지 않도록 문맥을 포함해 기록하세요:
지원용 메타데이터(요청 ID/트레이스 ID, 리전, 앱 버전, 적용된 가격 규칙 버전)도 있으면 분쟁 해결이 훨씬 빨라집니다.
작업이 실제로 발생했음을 가장 잘 아는 시스템에서 청구 이벤트를 내보내세요. 대부분의 경우 서버(백엔드)에서 내보내는 것이 신뢰할 수 있습니다. 브라우저나 모바일은 쉽게 조작되거나 손실될 수 있습니다.
실무적으로는 기록이 불가역적인 시점에 사용량을 발생시키세요. 신뢰할 수 있는 방출 지점 예시:
오프라인 모바일 예외가 있다면, 로컬에서 사용량을 저장하고 나중에 업로드하도록 하되 고유 이벤트 ID, 디바이스 ID, 단조 증가 시퀀스 번호 등을 포함하고 서버에서 검증하세요. 서버는 이벤트를 멱등하게 수용해 재시도로 중복 청구가 발생하지 않게 해야 합니다.
둘 다 필요합니다:
합계를 계산할 수 있는 두 장소가 일반적입니다. 데이터베이스(SQL 작업, 물질화 테이블, 예약 쿼리)에서 계산하면 처음엔 운영이 간단합니다. 전용 집계기 서비스(이벤트를 읽어 롤업을 쓰는 작은 워커)는 버전 관리, 테스트, 확장이 쉽고 제품 전반에 일관된 규칙을 적용하기 좋습니다.
왜 두 레이어를 모두 유지해야 하는가:
원시 이벤트는 버그, 환불, 분쟁에서 당신을 보호합니다. 집계는 느린 쿼리와 비용을 줄여줍니다. 집계만 저장하면 잘못된 규칙 하나가 영구적으로 기록을 손상할 수 있습니다.
실무 권장 구성:
작동하는 사용량 파이프라인은 데이터 흐름과 강력한 가드레일입니다. 순서를 맞추면 가격을 나중에 바꿔도 모든 것을 수작업으로 재처리할 필요가 줄어듭니다.
이벤트가 도착하면 즉시 검증하고 정규화하세요. 필수 필드를 확인하고 단위를 변환(바이트→GB, 초→분 등)하며 타임스탬프 규칙(event time vs received time)에 따라 클램프하세요. 잘못된 항목은 이유와 함께 거부된 상태로 저장하고 조용히 드랍하지 마세요.
정규화 후에는 추가 전용(append-only) 사고방식을 유지하고 역역사 수정하지 마세요. 원시 이벤트가 진실의 근원입니다.
대부분의 제품에 유용한 흐름은:
이중 청구와 누락은 보통 같은 근원에서 옵니다: 시스템이 이벤트가 새것인지, 중복인지, 혹은 유실되었는지 구별하지 못할 때입니다. 이는 영리한 청구 로직 문제가 아니라 이벤트 정체성과 검증에 관한 엄격한 통제 문제입니다.
첫 방어선은 idempotency 키입니다. 실제 행동에 대해 안정적인 키를 생성하세요. 좋은 키는 결정적이고 청구 단위당 유일합니다. 예: tenant_id + billable_action + source_record_id + time_bucket(시간 기반 단위인 경우 시간 버킷은 사용할 수 있음). 수신 데이터베이스나 이벤트 로그와 같은 첫 번째 영구 쓰기 지점에서 고유 제약으로 이를 강제하세요.
재시도와 타임아웃은 정상입니다. 클라이언트는 504 이후 같은 이벤트를 다시 보낼 수 있습니다. 규칙은: 반복을 수용하되 두 번 계산하지 마세요. 수신과 집계를 분리하세요: 한 번 멱등하게 수신한 뒤 저장된 이벤트에서 집계하세요.
검증은 불가능한 사용량이 합계를 손상시키지 않게 합니다. 수신 시와 집계 시 두 번 검증하세요.
정산 점검은 고객이 알아차리기 전에 “너무 많이 청구했다/놓쳤다”를 잡아내는 지루하지만 중요한 가드레일입니다.
먼저 같은 시간 창을 두 곳에서 대조하세요: 원시 이벤트와 집계 사용량. 고정된 창(예: 어제 UTC)을 선택하고 건수, 합계, 고유 ID를 비교하세요. 작은 차이는(지연 이벤트, 재시도) 설명 가능해야 하고 신비한 차이면 안 됩니다.
다음으로 청구한 것과 가격을 적용한 것을 대조하세요. 송장은 가격이 적용된 사용 스냅샷에서 재현 가능해야 합니다: 정확한 사용 합계, 적용된 가격 규칙 버전, 통화, 반올림 규칙 등. 나중에 계산을 다시 했을 때 송장이 바뀐다면 그건 송장이 아니라 추정치입니다.
일일 점검은 수학적 오류가 아닌 현실의 이상을 잡아냅니다:
복잡한 수식보다는 작은 가정들이 문제를 일으킵니다. 말단에서 시간, 정체성, 규칙에 대해 하나의 진실을 정하고 그것을 굽히지 않는 것이 중요합니다.
자주 발생하는 함정들:
단순한 예: Acme Co 고객 하나에 대해 API 호출, 스토리지(GB-일), 프리미엄 기능 실행 등 세 가지 미터로 과금한다고 합시다.
다음은 애플리케이션이 하루(1월 5일)에 내보낸 이벤트입니다. 나중에 이야기를 재구성하기 쉬운 필드들에 주목하세요: event_id, customer_id, occurred_at, meter, quantity, 그리고 idempotency 키.
청구를 켜기 전에 사용량 시스템을 작은 재무 원장처럼 다루세요. 동일한 원시 데이터를 재생했을 때 같은 합계가 나오지 않으면 불가능한 청구를 쫓느라 밤을 새게 됩니다.
다음 체크리스트를 최종 기준으로 사용하세요:
첫 릴리스는 파일럿처럼 다루세요. 하나의 청구 단위(예: “API 호출” 또는 “GB 저장”)와 하나의 정산 리포트만 켜고 예상 청구와 실제 청구를 비교하세요. 한 사이클 안정적이면 다음 단위를 추가하세요.
지원과 재무가 첫날부터 성공하도록 내부 페이지를 제공하세요. 원시 이벤트와 계산된 합계 양쪽을 보여주는 단일 화면이면 됩니다. 고객이 “왜 청구되었나요?”라고 물으면 몇 분 안에 답할 수 있어야 합니다.
실제 돈을 청구하기 전에 현실을 재생하세요. 스테이징 데이터를 사용해 한 달 분량을 시뮬레이션하고 집계를 실행해 송장을 생성하세요. 소수 샘플 계정에 대해 수동 집계와 비교해 결과가 일치하는지 확인하세요(저사용, 급등형, 안정형 고객을 골라 검증).
미터링 서비스를 직접 구축 중이라면 Koder.ai 같은 프로토타입 도구를 사용해 내부 관리자 UI와 Go + PostgreSQL 백엔드를 빠르게 만들고, 로직이 안정되면 소스 코드를 내보내 실무에 적용할 수 있습니다.
가격 규칙이 바뀔 때 위험을 줄이는 릴리스 루틴:
집계 창을 명시적으로 정하세요. 청구 표준 시간대(종종 고객의 시간대 또는 모두 UTC)를 정하고 일관되게 사용하세요. 지연 및 순서 뒤바뀐 이벤트는 정상입니다. 청구 기간이 이미 청구되었다면 과거 송장을 조용히 변경하지 말고 다음 송장에 조정 항목으로 기록하세요.
그다음 송장 버전을 고정하세요. “고정”이란 어떤 원시 이벤트, 어떤 중복 제거 규칙, 어떤 집계 코드 버전, 어떤 가격 규칙으로 해당 라인아이템이 생성되었는지를 감사할 수 있게 하는 것입니다. 이후 가격을 바꾸거나 버그를 수정하면 새로운 송장 리비전을 만들고 조용히 편집하지 마세요.
누락된 사용량은 발견하기 가장 어렵습니다. 수신 오류를 1급 데이터로 취급하세요. 실패한 이벤트도 동일한 필드로 별도 저장하고(아이덴포텐시 키 포함) 오류 사유와 재시도 카운트를 기록하세요.
문제가 발견되면 백필(backfill) 프로세스가 필요합니다. 백필은 의도적이어야 하고 기록으로 남기세요. 어떤 창을, 어떤 고객을, 누가 왜 트리거했는지, 무엇이 변경되었는지 기록하세요. 조정은 회계 항목처럼 취급하고 조용히 편집하지 마세요.
간단한 분쟁 워크플로는 지원팀을 진정시킵니다. 고객이 이의를 제기하면 동일한 스냅샷과 가격 버전으로 원시 이벤트에서 송장을 재현할 수 있어야 합니다. 그러면 막연한 불만이 해결 가능한 버그가 됩니다.
예: 고객이 20일에 업그레이드했고 이벤트 프로세서가 19일 데이터를 재시도하면 idempotency 키와 규칙 버전이 없을 때 19일이 중복되어 1–19일이 새 요금으로 가격 책정될 수 있습니다.
{"event_id":"evt_1001","customer_id":"cust_acme","occurred_at":"2026-01-05T09:12:03Z","meter":"api_calls","quantity":1,"idempotency_key":"req_7f2"}
{"event_id":"evt_1002","customer_id":"cust_acme","occurred_at":"2026-01-05T09:12:03Z","meter":"api_calls","quantity":1,"idempotency_key":"req_7f2"}
{"event_id":"evt_1003","customer_id":"cust_acme","occurred_at":"2026-01-05T10:00:00Z","meter":"storage_gb_days","quantity":42.0,"idempotency_key":"daily_storage_2026-01-05"}
{"event_id":"evt_1004","customer_id":"cust_acme","occurred_at":"2026-01-05T15:40:10Z","meter":"premium_runs","quantity":3,"idempotency_key":"run_batch_991"}
월말에 집계 작업은 customer_id, meter, 청구 기간으로 원시 이벤트를 그룹화합니다. 1월 합계는 월 전체 합계입니다: API 호출 합계 1,240,500; 스토리지 GB-일 합계 1,310.0; 프리미엄 실행 합계 68.
이후 2월 2일에 1월 31일에 속하는 지연 이벤트가 도착할 수 있습니다(모바일 클라이언트가 오프라인이었음). occurred_at(수신 시간이 아닌)으로 집계하면 1월 합계가 변경됩니다. 정책에 따라 (a) 다음 달 송장에 +200 조정 항목을 생성하거나 (b) 정책상 허용하면 1월 송장을 재발행합니다.
정산은 여기서 버그를 잡습니다: evt_1001과 evt_1002는 동일한 idempotency_key(req_7f2)를 공유합니다. 점검은 “하나의 요청에 대해 두 개의 청구 이벤트”를 플래그하고 송장 발행 전에 하나를 중복으로 표시하여 제거합니다.
지원팀은 이렇게 설명할 수 있습니다: “재시도로 인해 동일한 API 요청이 두 번 보고되었습니다. 중복 사용 이벤트를 제거해 한 번만 청구했습니다. 수정된 합계는 송장에 조정 항목으로 반영되어 있습니다.”
실무 테스트: 한 고객을 골라 최근 7일 간의 원시 이벤트를 깨끗한 DB에 재생한 뒤 사용량과 송장을 생성하세요. 결과가 프로덕션과 다르면 수학 문제가 아니라 결정성 문제입니다.