init: company-haness 설계

2026-07-23 17:49:00 +09:00
parent 57d1bab894
commit f668d6a158
962 changed files with 98989 additions and 1 deletions
@@ -0,0 +1,29 @@
+# ✅ [완료] probilling-cfo
+
+> **결론** — 사용량 과금은 COGS(변동 인프라 원가)에 연동된 단위마진 하한(floor)을 걸어야 매출 성장이 곧 마진 성장으로 이어진다.
+> **결정 필요** — — 아니오
+> **확신도** — Med (E2 근거)
+
+`repo: company-haness` · `2026-07-07 19:47` · `-`
+
+## 💡 아이디어
+- usage 단위마진 하한선(unit gross-margin floor) 설정 - 과금 단가를 인프라 COGS의 N배 이상으로 고정해 사용량이 늘수록 마진이 방어되게 설계.
+- 예측가능성 확보용 하이브리드(약정 base fee + 초과분 usage) - MRR 예측가능성과 현금선회수(prepaid credit)로 현금흐름 변동성 완화.
+- 무료->유료 전환의 재무 임팩트 게이팅 - 무료 tier에 usage 원가 상한(cost cap)을 둬 CAC 회수 전 COGS 유출을 통제하고 전환 기여마진을 (+)로 유지.
+
+## 💰 수익화 관점
+사용량 과금은 NRR(확장매출)을 통해 코호트 LTV를 우상향시켜 LTV:CAC 3배 이상을 지렛대화하고, base fee로 회수기간(payback)을 단축해 자본효율(현금 재투자 속도)을 정당화한다.
+
+## ⚠️ 리스크
+- 사용량 변동성으로 월별 현금흐름/매출 예측가능성 저하 (기업고객 예산 승인 마찰)
+- 무료->유료 전환 시 usage 원가가 요금보다 먼저 발생해 초기 단위마진 음(-) 전환 위험
+
+## 📎 근거
+
+| # | 출처 | 등급 |
+|---|---|---|
+| 1 | org-os/06-agent-work/agent-operating-kpi.yaml | E2 |
+
+## 📂 원본 파일 (에이전트용 YAML)
+
+- 종합/원천: `_sandbox/completion-records/probilling/probilling-cfo.report.yaml`
@@ -0,0 +1,16 @@
+report-header:
+  bottom-line: 사용량 과금은 COGS(변동 인프라 원가)에 연동된 단위마진 하한(floor)을 걸어야 매출 성장이 곧 마진 성장으로 이어진다.
+  decision-needed: { needed: false }
+  confidence: { value: Med, derived-from: evidence }
+  risks:
+    - 사용량 변동성으로 월별 현금흐름/매출 예측가능성 저하 (기업고객 예산 승인 마찰)
+    - 무료->유료 전환 시 usage 원가가 요금보다 먼저 발생해 초기 단위마진 음(-) 전환 위험
+  evidence:
+    - source-uri: org-os/06-agent-work/agent-operating-kpi.yaml
+      grade: E2
+lens: LENS-FINANCE
+ideas:
+  - usage 단위마진 하한선(unit gross-margin floor) 설정 - 과금 단가를 인프라 COGS의 N배 이상으로 고정해 사용량이 늘수록 마진이 방어되게 설계.
+  - 예측가능성 확보용 하이브리드(약정 base fee + 초과분 usage) - MRR 예측가능성과 현금선회수(prepaid credit)로 현금흐름 변동성 완화.
+  - 무료->유료 전환의 재무 임팩트 게이팅 - 무료 tier에 usage 원가 상한(cost cap)을 둬 CAC 회수 전 COGS 유출을 통제하고 전환 기여마진을 (+)로 유지.
+monetization-angle: 사용량 과금은 NRR(확장매출)을 통해 코호트 LTV를 우상향시켜 LTV:CAC 3배 이상을 지렛대화하고, base fee로 회수기간(payback)을 단축해 자본효율(현금 재투자 속도)을 정당화한다.
@@ -0,0 +1,30 @@
+# ✅ [완료] probilling-cpo
+
+> **결론** — usage-based Pro는 "가치를 쓴 만큼만 낸다"는 고객 문제를 풀어 activation 문턱을 낮추고, 사용량이 곧 확장이 되도록 value-metric을 요금과 정렬하는 방향으로 설계하라.
+
+> **결정 필요** — — 아니오
+> **확신도** — Med (E2 근거)
+
+`repo: company-haness` · `2026-07-07 19:47` · `-`
+
+## 💡 아이디어
+- 가치정렬 패키징: 좌석당 고정비가 부담인 소규모/불규칙 사용 고객에게 seat 대신 실사용 value-metric(예: 처리 건수)으로 과금해 진입장벽 제거.
+- value-first 온보딩: 무료/저한도 구간에서 aha-moment까지 먼저 도달시키고, 한도 근접 시점에 usage 대시보드로 자연스러운 Pro 전환 유도.
+- 투명한 usage 계량 UX: 실시간 사용량·예상 청구·한도 알림을 제품 안에 노출해 예측가능성을 제품 가치로 전환(bill-shock 방지).
+
+## 💰 수익화 관점
+value-metric이 곧 고객 성공 지표가 되도록 정렬하면 activation(저한도 무료 진입)과 expansion(사용량 증가=자연 매출 증가)이 같은 곡선을 타 land-and-expand가 제품 사용 자체로 구동된다. 구체 재무모델·가격탄력성은 LENS-FINANCE/REVENUE로 이관.
+
+## ⚠️ 리스크
+- value-metric을 잘못 고르면(고객 가치와 비상관) 요금 예측불가로 이탈·불신 유발
+- usage 미터링/한도 UX 부재 시 bill-shock로 activation 이후 조기 이탈
+
+## 📎 근거
+
+| # | 출처 | 등급 |
+|---|---|---|
+| 1 | org-os/00-role-registry/lens-registry.yaml | E2 |
+
+## 📂 원본 파일 (에이전트용 YAML)
+
+- 종합/원천: `_sandbox/completion-records/probilling/probilling-cpo.report.yaml`
@@ -0,0 +1,20 @@
+report-header:
+  bottom-line: >
+    usage-based Pro는 "가치를 쓴 만큼만 낸다"는 고객 문제를 풀어 activation 문턱을 낮추고,
+    사용량이 곧 확장이 되도록 value-metric을 요금과 정렬하는 방향으로 설계하라.
+  decision-needed: { needed: false }
+  confidence: { value: Med, derived-from: evidence }
+  risks:
+    - value-metric을 잘못 고르면(고객 가치와 비상관) 요금 예측불가로 이탈·불신 유발
+    - usage 미터링/한도 UX 부재 시 bill-shock로 activation 이후 조기 이탈
+  evidence:
+    - source-uri: org-os/00-role-registry/lens-registry.yaml
+      grade: E2
+lens: LENS-PRODUCT
+ideas:
+  - "가치정렬 패키징: 좌석당 고정비가 부담인 소규모/불규칙 사용 고객에게 seat 대신 실사용 value-metric(예: 처리 건수)으로 과금해 진입장벽 제거."
+  - "value-first 온보딩: 무료/저한도 구간에서 aha-moment까지 먼저 도달시키고, 한도 근접 시점에 usage 대시보드로 자연스러운 Pro 전환 유도."
+  - "투명한 usage 계량 UX: 실시간 사용량·예상 청구·한도 알림을 제품 안에 노출해 예측가능성을 제품 가치로 전환(bill-shock 방지)."
+monetization-angle: >
+  value-metric이 곧 고객 성공 지표가 되도록 정렬하면 activation(저한도 무료 진입)과 expansion(사용량 증가=자연 매출 증가)이
+  같은 곡선을 타 land-and-expand가 제품 사용 자체로 구동된다. 구체 재무모델·가격탄력성은 LENS-FINANCE/REVENUE로 이관.
@@ -0,0 +1,42 @@
+# 🟢 [결정] 사용량 기반 Pro 요금제
+
+> **결론** — Pro를 확장-상관 value-metric(호출/크레딧/완료건수) 기반 하이브리드(committed base + metered overage)로 설계하되, 단위마진 하한과 무료 tier 원가상한을 가드레일로 고정하고, 한도 근접을 PQL로 계량해 셀프서비스 전환을 구동하라.
+
+> **결정 필요** — ✅ 예 · 승인자 `HUMAN-001`
+> **확신도** — Med (E2 근거)
+
+`repo: company-haness` · `2026-07-07 18:17` · `-`
+
+## ✅ 권고안
+하이브리드 구조 채택 - committed base fee(예측가능 ARR)에 확장지표와 정렬된 metered overage를 얹고, 무료 저한도 진입 + 소프트캡/한도알림으로 bill-shock를 막아 land-and-expand를 제품 사용 자체로 구동한다.
+
+## 👥 역할별 핵심 결론
+
+| 역할 | 관점 | 핵심 결론 | 확신도 |
+|---|---|---|---|
+| probilling-cfo | LENS-FINANCE | 사용량 과금은 COGS(변동 인프라 원가)에 연동된 단위마진 하한(floor)을 걸어야 매출 성장이 곧 마진 성장으로 이어진다. | Med |
+| probilling-cpo | LENS-PRODUCT | usage-based Pro는 "가치를 쓴 만큼만 낸다"는 고객 문제를 풀어 activation 문턱을 낮추고, 사용량이 곧 확장이 되도록 value-metric을 요금과 정렬하는 방향으로 설계하라. | Med |
+| probilling-revops | LENS-REVENUE | 확장(NRR)과 상관하는 value-metric을 가격 단위로 고정하고, Pro 티어 경계를 PQL 임계로 설정해 사용량 초과 시점이 곧 PLS 이관·확장 파이프라인 트리거가 되도록 lead-to-cash를 설계하라. | Med |
+| probilling-growth | LENS-REVENUE-GROWTH | usage-based Pro는 "사용량 증가 곡선"을 그대로 전환 트리거로 삼아라 — 한도 근접·아하모먼트 도달을 PQL 시그널로 계량해 무료 사용자가 스스로 Pro로 넘어오게 만드는 것이 수요/전환 가속의 핵심. | Med |
+
+## ⚠️ 리스크
+- value-metric이 고객 가치·계정 성장과 비상관이면 예측불가·과금분쟁·이탈로 activation과 파이프라인이 동시 훼손
+- 순수 종량제는 매출/현금흐름 변동성이 커 기업고객 예산승인 마찰 및 forecasting 신뢰도 저하
+- 무료->유료 전환 초기 usage COGS가 요금보다 선발생해 전환 기여마진 음(-) 전환 위험
+
+## 📎 근거
+
+| # | 출처 | 등급 |
+|---|---|---|
+| 1 | _sandbox/completion-records/probilling/probilling-cpo.report.yaml | E2 |
+| 2 | _sandbox/completion-records/probilling/probilling-cfo.report.yaml | E2 |
+| 3 | _sandbox/completion-records/probilling/probilling-revops.report.yaml | E2 |
+| 4 | _sandbox/completion-records/probilling/probilling-growth.report.yaml | E2 |
+
+## 📂 상세 (에이전트용 YAML)
+
+- 원천 보고서: `_sandbox/completion-records/probilling/probilling-exec-packet.report.yaml`
+- 역할 보고서: `_sandbox/completion-records/probilling/probilling-cfo.report.yaml`
+- 역할 보고서: `_sandbox/completion-records/probilling/probilling-cpo.report.yaml`
+- 역할 보고서: `_sandbox/completion-records/probilling/probilling-revops.report.yaml`
+- 역할 보고서: `_sandbox/completion-records/probilling/probilling-growth.report.yaml`
@@ -0,0 +1,35 @@
+report-header:
+  bottom-line: >
+    Pro를 확장-상관 value-metric(호출/크레딧/완료건수) 기반 하이브리드(committed base + metered overage)로 설계하되,
+    단위마진 하한과 무료 tier 원가상한을 가드레일로 고정하고, 한도 근접을 PQL로 계량해 셀프서비스 전환을 구동하라.
+  decision-needed: { needed: true, approver: HUMAN-001 }
+  confidence: { value: Med, derived-from: evidence }
+  risks:
+    - value-metric이 고객 가치·계정 성장과 비상관이면 예측불가·과금분쟁·이탈로 activation과 파이프라인이 동시 훼손
+    - 순수 종량제는 매출/현금흐름 변동성이 커 기업고객 예산승인 마찰 및 forecasting 신뢰도 저하
+    - 무료->유료 전환 초기 usage COGS가 요금보다 선발생해 전환 기여마진 음(-) 전환 위험
+  evidence:
+    - source-uri: _sandbox/completion-records/probilling/probilling-cpo.report.yaml
+      grade: E2
+    - source-uri: _sandbox/completion-records/probilling/probilling-cfo.report.yaml
+      grade: E2
+    - source-uri: _sandbox/completion-records/probilling/probilling-revops.report.yaml
+      grade: E2
+    - source-uri: _sandbox/completion-records/probilling/probilling-growth.report.yaml
+      grade: E2
+recommendation: >
+    하이브리드 구조 채택 - committed base fee(예측가능 ARR)에 확장지표와 정렬된 metered overage를 얹고,
+    무료 저한도 진입 + 소프트캡/한도알림으로 bill-shock를 막아 land-and-expand를 제품 사용 자체로 구동한다.
+lens-contributions:
+  product: value-metric을 고객 성공지표와 정렬해 저한도 무료로 activation 문턱을 낮추고 사용량 증가=자연 확장이 되게 하되, 투명한 usage UX로 bill-shock 방지.
+  finance: 과금 단가를 인프라 COGS의 N배 이상으로 고정한 단위마진 하한 + 무료 tier 원가상한으로, 매출 성장이 곧 마진 성장이 되도록 방어.
+  revenue: 확장(NRR) 상관 value-unit을 가격단위로 고정하고, Pro 티어 경계를 PQL 임계로 설정해 초과 시점이 자동으로 CRM handoff·확장 파이프라인 트리거가 되게 설계.
+  growth: 한도 근접·아하모먼트 도달을 복합 PQL 시그널로 계량하고, 60/80/100% 인앱 넛지+셀프서비스 업그레이드 CTA로 무료 사용자가 스스로 전환하게 유도.
+tradeoffs:
+  - 성장(무료 관대·넛지 적극) vs 재무(마진 하한·원가상한) - 해법 무료 tier에 usage 원가 상한을 걸어 관대함의 상한을 재무가 정의, CAC 회수 전 COGS 유출 통제.
+  - 성장/제품(순수 종량제=낮은 진입장벽) vs 재무/RevOps(예측가능성·forecasting) - 해법 committed base fee로 ARR 예측가능성을 확보하고 초과분만 metered로 land-and-expand.
+  - 성장(넛지 극대화 전환) vs 제품(넛지 피로·브랜드 신뢰) - 해법 PQL을 사용량 단일축이 아닌 복합 시그널(재사용+팀초대)로 정의해 저의도 헤비유저 오탐·넛지 과다 방지.
+user-decision-needed:
+  - value-metric 최종 선정(호출량 vs 크레딧 vs 완료건수) - 고객 가치·확장 상관성 기준으로 택1.
+  - 가격 구조 파라미터 확정 - base fee 수준, 단위마진 하한 배수(N), 무료 tier 원가상한 값.
+next: 승인 시 가격구조·미터링/빌링 이벤트 스펙과 PQL 트리거 구현을 담은 RFC를 FAM-ENG-BACKEND에 위임, 가격탄력성 상세 재무모델은 LENS-FINANCE에 후속 의뢰.
@@ -0,0 +1,23 @@
+# ✅ [완료] probilling-growth
+
+> **결론** — usage-based Pro는 "사용량 증가 곡선"을 그대로 전환 트리거로 삼아라 — 한도 근접·아하모먼트 도달을 PQL 시그널로 계량해 무료 사용자가 스스로 Pro로 넘어오게 만드는 것이 수요/전환 가속의 핵심.
+
+> **결정 필요** — — 아니오
+> **확신도** — Med (E3 근거)
+
+`repo: company-haness` · `2026-07-07 18:17` · `-`
+
+## ⚠️ 리스크
+- PQL 임계값을 사용량 단일축으로만 잡으면 저의도 헤비유저를 오탐해 세일즈/넛지 리소스 낭비
+- 한도 넛지 과다 노출 시 free 사용자 이탈·부정 브랜드 인식(넛지 피로) 유발
+
+## 📎 근거
+
+| # | 출처 | 등급 |
+|---|---|---|
+| 1 | org-os/06-agent-work/collaboration-modes.yaml | E2 |
+| 2 | _sandbox/completion-records/probilling/probilling-cpo.report.yaml | E3 |
+
+## 📂 상세 (에이전트용 YAML)
+
+- 원천 보고서: `_sandbox/completion-records/probilling/probilling-growth.report.yaml`
@@ -0,0 +1,23 @@
+report-header:
+  bottom-line: >
+    usage-based Pro는 "사용량 증가 곡선"을 그대로 전환 트리거로 삼아라 —
+    한도 근접·아하모먼트 도달을 PQL 시그널로 계량해 무료 사용자가 스스로 Pro로 넘어오게 만드는 것이 수요/전환 가속의 핵심.
+  decision-needed: { needed: false }
+  confidence: { value: Med, derived-from: evidence }
+  risks:
+    - PQL 임계값을 사용량 단일축으로만 잡으면 저의도 헤비유저를 오탐해 세일즈/넛지 리소스 낭비
+    - 한도 넛지 과다 노출 시 free 사용자 이탈·부정 브랜드 인식(넛지 피로) 유발
+  evidence:
+    - source-uri: org-os/06-agent-work/collaboration-modes.yaml
+      grade: E2
+    - source-uri: _sandbox/completion-records/probilling/probilling-cpo.report.yaml
+      grade: E3
+lens: LENS-REVENUE-GROWTH
+ideas:
+  - "사용량 기반 PQL 정의: '무료 한도 70~80% 소진 + 2주내 재사용(재방문) + 팀 초대' 복합 시그널을 PQL로 계량해 전환 임박 코호트를 자동 세그먼트."
+  - "한도 근접 인앱 넛지 실험: 한도 60/80/100% 시점에 실시간 usage 대시보드+'이번 달 예상 초과분' 카피를 A/B로 노출, 전환 훅을 마찰 없는 셀프서비스 업그레이드 CTA로 연결."
+  - "value-based 트리거 온보딩: 아하모먼트(첫 처리 완료) 직후 사용량 여정 리마인드 이메일/인앱 시퀀스를 발화해 TTV를 단축하고 Pro 가치를 사전 전달(PMM 메시지 정합)."
+monetization-angle: >
+  사용량이 곧 전환 시그널이자 확장 매출이므로, 유입-활성화 캠페인을 '많이 쓰게 만드는' 데 집중하면
+  사용량 증가가 자연스럽게 Pro 전환·PQL 파이프라인을 밀어올려 CAC 회수와 land-and-expand가 제품 사용 자체로 구동된다.
+  가격구간·탄력성·전사 재무모델은 침범하지 않고 LENS-PRODUCT/FINANCE로 이관.
@@ -0,0 +1,24 @@
+# ✅ [완료] probilling-impl
+
+> **결론** — Pro 하이브리드(committed base + metered overage)를 Stripe Billing Meters로 구현한다 — licensed 기본료 price와 meter 연결 metered price를 한 subscription의 두 item으로 묶고, 사용량은 결정론적 identifier를 붙인 Meter Event로 멱등 전송해 Stripe가 집계·티어링·정산하게 한다.
+
+> **결정 필요** — — 아니오
+> **확신도** — Med (E3 근거)
+
+`repo: company-haness` · `2026-07-07 18:17` · `-`
+
+## ⚠️ 리스크
+- 멱등성/중복계량 - at-least-once 전송·재시도 시 identifier가 없거나 24h 롤링 윈도를 넘겨 재전송되면 이중 계량 → 결정론적 identifier(EVENT_NAME:customer:unit_key) 필수, 윈도 밖 재처리 금지.
+- 정산 오차 - timestamp가 과거 35일/미래 5분 밖이면 이벤트가 거부되어 미청구 누락 발생, 클록 스큐·지연배치 주의. 앱측 추정치는 UX 전용이며 Stripe 집계가 원장.
+- 파라미터 미확정 - value-metric(호출/크레딧/완료건수), 무료 allotment, 단위마진 하한 배수(overage 단가)가 CPO/CFO 미승인 상태라 price 재발행 시 마이그레이션 비용 발생 가능.
+
+## 📎 근거
+
+| # | 출처 | 등급 |
+|---|---|---|
+| 1 | _sandbox/evidence/probilling/stripe-usage-billing.md | E3 |
+| 2 | _sandbox/evidence/probilling/metering_sample.py | E3 |
+
+## 📂 상세 (에이전트용 YAML)
+
+- 원천 보고서: `_sandbox/completion-records/probilling/probilling-impl.report.yaml`
@@ -0,0 +1,41 @@
+report-header:
+  bottom-line: >
+    Pro 하이브리드(committed base + metered overage)를 Stripe Billing Meters로 구현한다 —
+    licensed 기본료 price와 meter 연결 metered price를 한 subscription의 두 item으로 묶고,
+    사용량은 결정론적 identifier를 붙인 Meter Event로 멱등 전송해 Stripe가 집계·티어링·정산하게 한다.
+  decision-needed: { needed: false }
+  confidence: { value: Med, derived-from: evidence }
+  risks:
+    - 멱등성/중복계량 - at-least-once 전송·재시도 시 identifier가 없거나 24h 롤링 윈도를 넘겨 재전송되면 이중 계량 → 결정론적 identifier(EVENT_NAME:customer:unit_key) 필수, 윈도 밖 재처리 금지.
+    - 정산 오차 - timestamp가 과거 35일/미래 5분 밖이면 이벤트가 거부되어 미청구 누락 발생, 클록 스큐·지연배치 주의. 앱측 추정치는 UX 전용이며 Stripe 집계가 원장.
+    - 파라미터 미확정 - value-metric(호출/크레딧/완료건수), 무료 allotment, 단위마진 하한 배수(overage 단가)가 CPO/CFO 미승인 상태라 price 재발행 시 마이그레이션 비용 발생 가능.
+  evidence:
+    - source-uri: _sandbox/evidence/probilling/stripe-usage-billing.md
+      grade: E3
+      note: >
+        공식 Stripe 문서 근거 — 개요 https://docs.stripe.com/billing/subscriptions/usage-based ,
+        Meter 생성 https://docs.stripe.com/api/billing/meter/create ,
+        Meter Event https://docs.stripe.com/api/billing/meter-event/create (+ v2 24h 멱등 윈도
+        https://docs.stripe.com/api/v2/billing/meter-events/object ),
+        Price(metered/tiered) https://docs.stripe.com/api/prices/create ,
+        Subscription https://docs.stripe.com/api/subscriptions/create . 인용일 2026-07-07.
+    - source-uri: _sandbox/evidence/probilling/metering_sample.py
+      grade: E3
+      note: 공식 API 시그니처 기반 실행가능 샘플(py_compile 통과). 테스트키로 --demo 프로비저닝 가능.
+design:
+  api-flow:
+    - "1. Meter 생성: POST /v1/billing/meters (stripe.billing.Meter.create) — event_name=pro_api_call, default_aggregation.formula=sum, customer_mapping.type=by_id."
+    - "2. Price 생성: POST /v1/prices — (a) licensed 기본료 price(committed base), (b) metered price(recurring.usage_type=metered, recurring.meter=<meter id>, billing_scheme=tiered, tiers_mode=graduated: allotment까지 unit_amount=0, 초과분 overage 단가)."
+    - "3. 구독: POST /v1/subscriptions (stripe.Subscription.create) — items[]에 기본료 item(quantity=1) + metered item(quantity 없음). Idempotency-Key 헤더로 재시도 안전."
+    - "4. 계량: POST /v1/billing/meter_events (stripe.billing.MeterEvent.create) — event_name + payload{stripe_customer_id,value} + identifier(멱등)."
+    - "5. 정산: 청구주기 말에 Stripe가 meter event를 formula로 집계 → metered tier 적용 → 기본료와 합산해 단일 invoice 발행. overage=max(0, 집계량-allotment)*overage단가."
+  idempotency: >
+    Meter Event에 결정론적 `identifier`(예: sha256(EVENT_NAME:customer_id:unit_key))를 부여한다.
+    Stripe는 identifier를 롤링 24시간 윈도 내에서 유일성 강제하므로 동일 unit_key의 재전송·재시도는
+    이중 계량되지 않는다(공식 권고: 전역 유일 식별자 사용). timestamp는 과거 35일/미래 5분 이내만 허용.
+    쓰기 API(Meter/Price/Subscription create)는 `Idempotency-Key` 요청 헤더로 재시도 멱등 보장.
+  interface-for-consuming-teams: >
+    제품/프론트는 얇은 파사드 두 메서드만 호출한다 —
+    (1) MeteringClient.report(customer_id, value, unit_key): 사용 1건을 멱등 계량(Stripe API·identifier 은닉),
+    (2) MeteringClient.estimate(customer_id, aggregated_usage) -> UsageEstimate: 60/80/100% 인앱 넛지용
+    overage_units·estimated_invoice_total 추정치 반환(표시 전용, 원장은 Stripe). 팀은 Stripe SDK를 직접 다루지 않는다.
@@ -0,0 +1,24 @@
+# ✅ [완료] probilling-qa
+
+> **결론** — 통과(Accepted) — RFC 보고서의 evidence 2건이 실존하고 metering_sample.py가 py_compile exit 0로 실행 아티팩트(E5)를 확보했으며, report-header(BLUF)·evidence·confidence 계약을 준수한다.
+
+> **결정 필요** — — 아니오
+> **확신도** — High (E5 근거)
+
+`repo: company-haness` · `2026-07-07 18:17` · `-`
+
+## ⚠️ 리스크
+- py_compile은 구문/바이트코드 컴파일만 보장하며 Stripe 테스트키 기반 --demo 실런타임 프로비저닝은 미검증(정적 검증 범위).
+- value-metric/allotment/overage 단가가 CPO/CFO 미승인 상태 — 파라미터 확정 전 price 재발행 마이그레이션 리스크 잔존(설계 책임 아님, 승인 대기).
+- source-uri 2건은 grade E3(문서/코드 인용) — 원장 정합성은 Stripe 집계 실측 시점에 최종 확인 필요.
+
+## 📎 근거
+
+| # | 출처 | 등급 |
+|---|---|---|
+| 1 | python3 -m py_compile _sandbox/evidence/probilling/metering_sample.py | E5 |
+| 2 | _sandbox/completion-records/probilling/probilling-impl.report.yaml | E3 |
+
+## 📂 상세 (에이전트용 YAML)
+
+- 원천 보고서: `_sandbox/completion-records/probilling/probilling-qa.report.yaml`
@@ -0,0 +1,21 @@
+report-header:
+  bottom-line: >
+    통과(Accepted) — RFC 보고서의 evidence 2건이 실존하고 metering_sample.py가 py_compile exit 0로
+    실행 아티팩트(E5)를 확보했으며, report-header(BLUF)·evidence·confidence 계약을 준수한다.
+  decision-needed: { needed: false }
+  confidence: { value: High, derived-from: evidence }
+  risks:
+    - py_compile은 구문/바이트코드 컴파일만 보장하며 Stripe 테스트키 기반 --demo 실런타임 프로비저닝은 미검증(정적 검증 범위).
+    - value-metric/allotment/overage 단가가 CPO/CFO 미승인 상태 — 파라미터 확정 전 price 재발행 마이그레이션 리스크 잔존(설계 책임 아님, 승인 대기).
+    - source-uri 2건은 grade E3(문서/코드 인용) — 원장 정합성은 Stripe 집계 실측 시점에 최종 확인 필요.
+  evidence:
+    - command: "python3 -m py_compile _sandbox/evidence/probilling/metering_sample.py"
+      exit-code: 0
+      grade: E5
+    - source-uri: _sandbox/completion-records/probilling/probilling-impl.report.yaml
+      grade: E3
+verdict: Accepted
+findings:
+  - evidence source-uri 2건(refs/stripe-usage-billing.md 8305B, refs/metering_sample.py 9994B) 실존 확인 — dead-link 없음.
+  - metering_sample.py py_compile exit code 0 — 보고서의 "py_compile 통과" 주장이 실행 근거(E5)로 재현됨.
+  - impl 보고서가 report-header(bottom-line/decision-needed/confidence/risks/evidence) 계약을 충족하고 confidence:Med가 E3 근거와 정합 — 형식/근거 위반 없음.
@@ -0,0 +1,23 @@
+# ✅ [완료] probilling-revops
+
+> **결론** — 확장(NRR)과 상관하는 value-metric을 가격 단위로 고정하고, Pro 티어 경계를 PQL 임계로 설정해 사용량 초과 시점이 곧 PLS 이관·확장 파이프라인 트리거가 되도록 lead-to-cash를 설계하라.
+
+> **결정 필요** — — 아니오
+> **확신도** — Med (E2 근거)
+
+`repo: company-haness` · `2026-07-07 18:17` · `-`
+
+## ⚠️ 리스크
+- value-metric이 계정 가치와 비상관이면 예측 불가·과금 분쟁으로 파이프라인 예측 오차·이탈 확대
+- committed base 없는 순수 종량제는 사용량 변동 시 매출 인식 불안정 → forecasting 신뢰도 저하
+
+## 📎 근거
+
+| # | 출처 | 등급 |
+|---|---|---|
+| 1 | org-os/00-role-registry/team-topology-map.yaml | E2 |
+| 2 | org-os/06-agent-work/report-templates.yaml | E2 |
+
+## 📂 상세 (에이전트용 YAML)
+
+- 원천 보고서: `_sandbox/completion-records/probilling/probilling-revops.report.yaml`
@@ -0,0 +1,24 @@
+report-header:
+  bottom-line: >
+    확장(NRR)과 상관하는 value-metric을 가격 단위로 고정하고, Pro 티어 경계를 PQL 임계로 설정해
+    사용량 초과 시점이 곧 PLS 이관·확장 파이프라인 트리거가 되도록 lead-to-cash를 설계하라.
+  decision-needed: { needed: false }
+  confidence: { value: Med, derived-from: evidence }
+  risks:
+    - value-metric이 계정 가치와 비상관이면 예측 불가·과금 분쟁으로 파이프라인 예측 오차·이탈 확대
+    - committed base 없는 순수 종량제는 사용량 변동 시 매출 인식 불안정 → forecasting 신뢰도 저하
+  evidence:
+    - source-uri: org-os/00-role-registry/team-topology-map.yaml
+      grade: E2
+    - source-uri: org-os/06-agent-work/report-templates.yaml
+      grade: E2
+lens: LENS-REVENUE
+ideas:
+  - "가격메트릭=확장지표 정렬: 계정 성장과 상관하는 value-unit(호출량/크레딧/완료건수)을 Pro 과금 단위로 고정해 사용량 증가가 자동으로 매출 확장(net-negative churn)이 되게 설계."
+  - "티어 경계=PLS 트리거: 무료/저한도 구간의 사용량이 PQL 임계(예: value-unit 소진율·연속 초과)를 넘는 순간 SSOT(CRM)에 handoff-brief를 자동 생성해 Sales/CS로 이관하고 확장 파이프라인에 적재."
+  - "하이브리드 확약+종량 구조: committed base + 소프트캡/초과 알림 기반 metered overage로 bill-shock 이탈을 막고, 확약 갱신 시점을 NRR 방어·업셀 창구로 운영."
+monetization-angle: >
+  가격메트릭은 value-unit(호출/크레딧/완료건수) 종량이며, 미터링 이벤트=billing 이벤트로 연결해 lead-to-cash를 계량화한다.
+  구조는 committed base(예측가능 ARR) + metered expansion(사용량 연동 확장) + 가드레일(소프트캡·초과 알림)로,
+  usage 텔레메트리를 CRM에 적재해 lead-score·churn-score·확장 forecast를 사용량 코호트로 구동한다.
+  제품가치 설계·가격탄력성/전사 재무모델은 LENS-PRODUCT / LENS-FINANCE로 이관.