에이전트를 계량하고,
고객에게 청구하세요.
에이전트 플랫폼을 위한 사용량 기반 빌링 엔진입니다: 메트릭, 플랜, 구독, 사용 이벤트, 적응형 한도 적용, 인보이스 발행까지 — Stripe 같은 대중적인 결제 게이트웨이를 결제 레일로 사용하고, 고객이 자신의 사용자에게 직접 요금을 청구할 수 있는 벤더 모델을 제공합니다.
문서 보기에이전트를 위한 사용량 기반 빌링은 단순한 Stripe 연동이 아닙니다.
불변의 사용 원장, 점진적 완화가 가능한 메트릭별 한도, 일할 계산, 연체 처리 정책, LLM 비용의 패스스루 가격 책정, 그리고 매 요청마다 네트워크 홉을 추가하지 않는 한도 체크가 필요합니다. Billing Server가 이 모든 것을 담당하며 — Stripe는 오직 결제 처리자일 뿐이므로 구독 로직이 두 곳에 나뉘어 존재하지 않습니다.
메트릭
애플리케이션이 보고하는 측정 가능한 모든 단위 — API 호출, 일일 메시지 수, LLM 비용(달러) — 재설정 주기는 분 단위부터 결제 주기 단위까지, 빌링 사이클과 독립적으로 설정할 수 있습니다. "월간 플랜에서 하루 100개 메시지"는 설정 한 줄이면 됩니다.
플랜
완전히 셀프서비스입니다: 기본 가격, 결제 주기, 선불/후불/혼합, 업그레이드 및 해지 동작, 결제 실패 정책까지. 메트릭별 가격 책정은 포함 단위, 단위당 요금, 계단식 구간, 패스스루를 지원합니다 — 실제 비용을 보고하고 마진을 적용하는, 가변적인 LLM 가격에 맞춘 구조입니다.
구독
구독자(사용자 또는 애플리케이션)를 플랜에 연결합니다. 이 플랜은 다른 조직이 소유한 것일 수도 있습니다. 플랜 조건은 구독 시점에 스냅샷으로 고정되므로, 이후 플랜을 수정해도 기존 구독자의 조건은 바뀌지 않습니다.
사용 이벤트
불변이며 추가 전용(append-only)이고, 멱등성 키가 적용되어(24시간 내 중복은 무시) 7년간 보관됩니다. 정정은 편집이 아니라 새로운 음수 이벤트로 처리됩니다.
적응형 한도
무제한, 소프트(추적 후 알림), 하드(차단) 방식에 더해 조건부 오버라이드도 가능합니다: 일일 할당량을 소진하면 절벽처럼 차단되는 대신 분당 요청 비율이 조여듭니다. 앱은 유효 한도를 캐시하고 서버가 계산한 recheck_after 힌트를 따르므로, 한도 적용이 요청 처리 경로를 막지 않습니다.
인보이스 발행
주기마다 기본 요금, 사용량, 패스스루, 조정 등 유형이 지정된 항목으로 생성되며, 순차 번호가 매겨지고 영구 보관되며, 일할 계산 방식의 간단한 비례 배분이 적용됩니다.
Stripe + Connect
Stripe가 카드 정보를 보관하고(Elements — 플랫폼 서버에는 절대 닿지 않음) PaymentIntent를 처리합니다. Connect는 각 벤더 조직을 연결된 계정으로 온보딩하여, 해당 벤더 플랜의 결제가 그 벤더의 Stripe 계정으로 라우팅되도록 합니다.
벤더 API
인증된 애플리케이션이 자신의 사용자를 자신의 플랜에 구독시킬 수 있습니다 — 신뢰 경계는 플랜 소유권이며, 최종 사용자의 JWT는 빌링 서버에 도달하지 않습니다. 자동 프로비저닝을 사용하면 신규 사용자의 첫 API 호출만으로 구독이 투명하게 생성됩니다.
연체 처리까지 내장된, 요청에서 결제 완료까지의 흐름.
계량 루프
확인 — 앱은 로컬에 캐시된 유효 한도를 확인합니다. recheck_after 임계값에 도달하면 빌링 서버에서 다시 가져옵니다 — 하드 한도에 가까울수록 자주, 멀수록 드물게.
처리 및 보고 — 요청이 처리되고, 소비량은 멱등성 있는 사용 이벤트로 게시됩니다. 패스스루 메트릭은 단위 대신 실제 비용을 보고합니다.
적응 — 소프트 한도 초과는 웹훅을 발생시킵니다. 오버라이드 트리거는 관련 한도를 자동으로 조이고, 트리거 메트릭이 초기화되면 다시 완화합니다.
계산 — 주기 종료 시: 기본 요금 + 단위당 요금 + 계단식 구간 + 마진이 적용된 패스스루 비용에서 포함 금액을 뺍니다.
청구 — 저장된 결제 수단으로 PaymentIntent가 실행되며, 벤더의 연결된 계정으로 라우팅됩니다.
확인 또는 연체 처리 — 성공하면 인보이스가 결제 완료로 표시됩니다. 실패하면 벤더의 정책에 따라 유예 기간, 예약된 재시도, 연체, 정지, 선택적 자동 해지가 진행되며 매 단계마다 양측에 웹훅이 전송됩니다.
플랜, 구독, 사용량, 한도 — 그리고 벤더 전용 API까지.
원장처럼 설계되었습니다 — 실제로 원장이니까요.
불변의 사용 기록 — 추가 전용이며 멱등성 있는 이벤트; 7년 보관; 인보이스와 빌링 이벤트는 무기한 보관됩니다.
바뀌지 않는 조건 — 플랜 스냅샷 덕분에 기존 구독자의 조건은 플랜 수정과 무관하게 유지됩니다.
PCI는 Stripe에서만 — 카드 데이터는 플랫폼 서버에 절대 닿지 않습니다 — Elements와 PaymentIntent가 이를 보장합니다.
테넌트 격리 — 벤더는 자신의 플랜에 대한 구독만 볼 수 있으며 구독자의 내부 빌링 정보는 볼 수 없습니다. 모든 조직 범위 지정은 사용자 입력이 아닌 JWT에서 도출됩니다.
핫 패스를 막지 않음 — 서버가 계산한 재확인 주기를 사용한 캐시 기반 한도 적용; 빌링 서버가 잠시 연결되지 않아도 캐시된 한도로 계속 서비스됩니다.
모든 변경 사항이 귀속됨 — 행위자 정보가 포함된 추가 전용 빌링 이벤트 로그로 분쟁 및 감사에 대응합니다; HMAC로 서명된 아웃바운드 웹훅.
에이전트의 실제 비용 구조에 맞는 가격 모델.
하루 100개 메시지는 소프트 한도이며, 101번째부터 오버라이드가 분당 메트릭을 하드 한도 2회로 전환합니다. 사용자는 차단되는 대신 느려질 뿐이며, 자정에 자동으로 해제됩니다.
앱이 에이전트 실행당 $0.0847의 비용을 보고하면, 플랜은 첫 $5는 포함하고 나머지에는 실제 비용에 20% 마진을 더해 청구합니다.
$0.02 / $0.01 / $0.005 구간에 걸친 API 호출 15,000건은 정확히 $135가 청구됩니다 — 각 요금은 해당 구간 안에서만 적용됩니다.
AgentOS 위에 서비스를 구축하는 조직이 자신의 사용자를 위해 "Pro, 월 $29" 플랜을 정의합니다. 결제는 자신의 Stripe Connect 계정으로 라우팅되고, 앱은 벤더 API를 통해 가입마다 자동으로 구독을 생성합니다.
31일 중 15일이 남은 시점에 $10 → $30으로 변경하면 정확히 $9.68이 일할 계산되어 청구됩니다 — 단순한 일할 계산일 뿐, 놀랄 일은 없습니다.
한 번 계량하면, 에이전트가 실행되는 모든 곳에서 청구할 수 있습니다.
사용 이벤트부터 결제 완료된 인보이스까지 — Billing Server가 전 과정을 책임지므로 구독 로직이 두 곳에 나뉘어 존재하지 않습니다.