init: company-haness 설계
This commit is contained in:
DongHyeonka
@@ -0,0 +1,24 @@
|
||||
# ✅ [완료] live-demo
|
||||
|
||||
> **결론** — 내부 운영 대시보드 다크모드 토글은 저위험·가역·단일도메인 UI 개선이므로 FAM-DESIGN·FAM-ENG-FRONTEND가 light-tier converge로 바로 실행하도록 권고한다.
|
||||
> **결정 필요** — — 아니오
|
||||
> **확신도** — Med (E2 근거)
|
||||
|
||||
`repo: company-haness` · `2026-07-07 18:17` · `-`
|
||||
|
||||
## ⚠️ 리스크
|
||||
- 기존 디자인 토큰/테마 변수가 미비하면 컴포넌트별 스타일 재작업이 발생할 수 있음.
|
||||
- 사용자 선호 저장(localStorage 등) 미처리 시 세션마다 초기화되는 UX 결함 가능.
|
||||
|
||||
## 📎 근거
|
||||
|
||||
| # | 출처 | 등급 |
|
||||
|---|---|---|
|
||||
| 1 | org-os/06-agent-work/collaboration-modes.yaml | E2 |
|
||||
| 2 | org-os/06-agent-work/governance-tiers.yaml | E2 |
|
||||
| 3 | org-os/00-role-registry/capability-families.yaml | E2 |
|
||||
| 4 | org-os/00-role-registry/roles.yaml | E2 |
|
||||
|
||||
## 📂 상세 (에이전트용 YAML)
|
||||
|
||||
- 원천 보고서: `_sandbox/completion-records/live-demo/live-demo.report.yaml`
|
||||
@@ -0,0 +1,19 @@
|
||||
report-header:
|
||||
bottom-line: 내부 운영 대시보드 다크모드 토글은 저위험·가역·단일도메인 UI 개선이므로 FAM-DESIGN·FAM-ENG-FRONTEND가 light-tier converge로 바로 실행하도록 권고한다.
|
||||
decision-needed: { needed: false }
|
||||
confidence: { value: Med, derived-from: evidence }
|
||||
risks:
|
||||
- 기존 디자인 토큰/테마 변수가 미비하면 컴포넌트별 스타일 재작업이 발생할 수 있음.
|
||||
- 사용자 선호 저장(localStorage 등) 미처리 시 세션마다 초기화되는 UX 결함 가능.
|
||||
evidence:
|
||||
- source-uri: org-os/06-agent-work/collaboration-modes.yaml
|
||||
grade: E2
|
||||
- source-uri: org-os/06-agent-work/governance-tiers.yaml
|
||||
grade: E2
|
||||
- source-uri: org-os/00-role-registry/capability-families.yaml
|
||||
grade: E2
|
||||
- source-uri: org-os/00-role-registry/roles.yaml
|
||||
grade: E2
|
||||
mode: converge
|
||||
tier: light
|
||||
candidate-families: [FAM-DESIGN, FAM-ENG-FRONTEND, FAM-QA]
|
||||
@@ -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로 이관.
|
||||
@@ -0,0 +1,50 @@
|
||||
# ✅ [완료] wf-churn-01-data-analyst
|
||||
|
||||
> **결론** — 실측 로그가 없으므로 지금 할 일은 '왜 안 되는지' 단정이 아니라 온보딩→첫 결제 퍼널을 단계로 계측하는 것 — activation(리텐션 상관으로 역산)·PQL(한도근접+재방문+paywall 복합 시그널)·단계별 cohort-based 전환율을 계측·정의하고, 단계별 '절대 이탈수' 랭킹과 코호트×단계 히트맵으로 병목을 특정하도록 설계한다.
|
||||
|
||||
> **결정 필요** — — 아니오
|
||||
> **확신도** — Med (E2 근거)
|
||||
|
||||
`repo: company-haness` · `2026-07-07 19:47` · `wf-churn-01`
|
||||
|
||||
## 🔎 핵심 발견
|
||||
- 가설1(계측 공백): free→Pro 저조의 1차 원인은 '전환이 나쁘다'가 아니라 단계별 이탈을 볼 계측 자체가 없어 병목 단계를 특정 못 하는 것 — 퍼널 계측 신설이 선행 과제.
|
||||
- 가설2(activation leak): 온보딩→첫 가치경험(activation) 구간 이탈이 가장 클 개연성 — activated vs non-activated 코호트의 전환 격차로 검증 가능.
|
||||
- 가설3(PQL 부재): 무료 한도 근접·paywall 접촉 같은 전환 임박 시그널이 계량되지 않아 결제 의도 코호트를 놓치고 있을 가능성.
|
||||
- 가설4(전환 latency): free→Pro 전환은 특정 시점에 집중될 개연 — survival 곡선으로 넛지 타이밍 창을 특정해야 함.
|
||||
|
||||
## 📐 계측할 지표
|
||||
- Activation Rate — 리텐션/전환 상관이 가장 큰 초기 행동으로 activation을 역산 정의 후 (activated 신규/전체 신규).
|
||||
- 단계별 funnel conversion(S0 Signup→S6 First payment) — 고정 window의 cohort-based 전환율·drop-off율.
|
||||
- PQL 생성률 및 PQL→결제 전환율 — 한도 70~80% 소진 + 재방문 + paywall 히트 복합 시그널.
|
||||
- TTV(signup→activation)와 Time-to-Convert(signup→first payment) 분포(중앙값·꼬리).
|
||||
- 코호트별 D1/D7/D14/D30 retention(activated vs non-activated 분리).
|
||||
- 단계별 절대 이탈수 = 진입수 × (1-Cn), abandonment point 집계.
|
||||
|
||||
## 📊 분석 계획
|
||||
- Funnel 병목 랭킹: 단계별 절대 이탈수 내림차순으로 최대 leak 단계 우선 지목(전환율%는 보조).
|
||||
- Cohort × step 히트맵: signup week·channel·device·온보딩 variant별 이탈 편차 탐지.
|
||||
- Activation↔전환 상관 분석: activated vs non-activated free→Pro 격차로 activation이 leading indicator인지 확정.
|
||||
- Survival(Kaplan-Meier) 분석: 전환/이탈이 몰리는 시점 구간 특정 → 넛지/트라이얼 타이밍 도출.
|
||||
- (데이터 확보 후) 병목 단계 A/B 실험 설계 — 온보딩 variant·paywall 타이밍. 현재는 설계만.
|
||||
|
||||
## ➡️ 다음 액션
|
||||
- 이벤트 계측 스펙 확정: 노트 §3의 이벤트 맵(signup/onboarding/activation/paywall/checkout)과 공통 프로퍼티·pseudonymous id를 구현 요청으로 전달.
|
||||
- Activation 정의 확정 실험: 후보 A1~A3 중 전환 격차가 최대인 정의를 실데이터로 선택(초기 로그 확보 후).
|
||||
- 퍼널 대시보드 구축: 단계별 cohort-based 전환·절대 이탈수·히트맵을 상시 관측 뷰로.
|
||||
- placeholder 임계값(활성화 N회·한도%·window)을 초기 데이터로 보정 후 PQL 정의 잠금.
|
||||
|
||||
## ⚠️ 리스크
|
||||
- 실측 데이터 부재 → 모든 임계값(activation N회·한도 70~80%·30일 window)은 placeholder 가정이며 실데이터로 보정 전엔 오정의 위험.
|
||||
- 전환율(%)만 보고 병목을 정하면 트래픽 작은 단계를 과대평가 → 절대 이탈수와 병행해야 오판을 피함.
|
||||
- 이벤트 트래킹 인프라가 미비하면 계측 스펙 신설이 선행돼야 하고, 익명 세션만이면 pre-signup 단계 계측이 제한됨.
|
||||
|
||||
## 📎 근거
|
||||
|
||||
| # | 출처 | 등급 |
|
||||
|---|---|---|
|
||||
| 1 | _sandbox/evidence/wf-churn-01/wf-churn-01-data-analyst-notes.md | E2 |
|
||||
|
||||
## 📂 원본 파일 (에이전트용 YAML)
|
||||
|
||||
- 종합/원천: `_sandbox/completion-records/wf-churn-01/wf-churn-01-data-analyst.report.yaml`
|
||||
@@ -0,0 +1,42 @@
|
||||
role-id: DATA-ANALYST
|
||||
role-name: 데이터 분석가 AI
|
||||
lens: LENS-CUSTOMER
|
||||
perspective: "제품 감(感)이 아니라 사용자 행동·전환 지표로 온보딩→첫 결제 이탈을 계량한다 — 정량 관점."
|
||||
workflow-id: wf-churn-01
|
||||
report-header:
|
||||
bottom-line: >
|
||||
실측 로그가 없으므로 지금 할 일은 '왜 안 되는지' 단정이 아니라 온보딩→첫 결제 퍼널을 단계로 계측하는 것 —
|
||||
activation(리텐션 상관으로 역산)·PQL(한도근접+재방문+paywall 복합 시그널)·단계별 cohort-based 전환율을 계측·정의하고,
|
||||
단계별 '절대 이탈수' 랭킹과 코호트×단계 히트맵으로 병목을 특정하도록 설계한다.
|
||||
decision-needed: { needed: false, approver: EXEC-CPO }
|
||||
confidence: { value: Med, derived-from: evidence }
|
||||
risks:
|
||||
- "실측 데이터 부재 → 모든 임계값(activation N회·한도 70~80%·30일 window)은 placeholder 가정이며 실데이터로 보정 전엔 오정의 위험."
|
||||
- "전환율(%)만 보고 병목을 정하면 트래픽 작은 단계를 과대평가 → 절대 이탈수와 병행해야 오판을 피함."
|
||||
- "이벤트 트래킹 인프라가 미비하면 계측 스펙 신설이 선행돼야 하고, 익명 세션만이면 pre-signup 단계 계측이 제한됨."
|
||||
evidence:
|
||||
- source-uri: _sandbox/evidence/wf-churn-01/wf-churn-01-data-analyst-notes.md
|
||||
grade: E2
|
||||
findings:
|
||||
- "가설1(계측 공백): free→Pro 저조의 1차 원인은 '전환이 나쁘다'가 아니라 단계별 이탈을 볼 계측 자체가 없어 병목 단계를 특정 못 하는 것 — 퍼널 계측 신설이 선행 과제."
|
||||
- "가설2(activation leak): 온보딩→첫 가치경험(activation) 구간 이탈이 가장 클 개연성 — activated vs non-activated 코호트의 전환 격차로 검증 가능."
|
||||
- "가설3(PQL 부재): 무료 한도 근접·paywall 접촉 같은 전환 임박 시그널이 계량되지 않아 결제 의도 코호트를 놓치고 있을 가능성."
|
||||
- "가설4(전환 latency): free→Pro 전환은 특정 시점에 집중될 개연 — survival 곡선으로 넛지 타이밍 창을 특정해야 함."
|
||||
metrics-to-instrument:
|
||||
- "Activation Rate — 리텐션/전환 상관이 가장 큰 초기 행동으로 activation을 역산 정의 후 (activated 신규/전체 신규)."
|
||||
- "단계별 funnel conversion(S0 Signup→S6 First payment) — 고정 window의 cohort-based 전환율·drop-off율."
|
||||
- "PQL 생성률 및 PQL→결제 전환율 — 한도 70~80% 소진 + 재방문 + paywall 히트 복합 시그널."
|
||||
- "TTV(signup→activation)와 Time-to-Convert(signup→first payment) 분포(중앙값·꼬리)."
|
||||
- "코호트별 D1/D7/D14/D30 retention(activated vs non-activated 분리)."
|
||||
- "단계별 절대 이탈수 = 진입수 × (1-Cn), abandonment point 집계."
|
||||
analysis-plan:
|
||||
- "Funnel 병목 랭킹: 단계별 절대 이탈수 내림차순으로 최대 leak 단계 우선 지목(전환율%는 보조)."
|
||||
- "Cohort × step 히트맵: signup week·channel·device·온보딩 variant별 이탈 편차 탐지."
|
||||
- "Activation↔전환 상관 분석: activated vs non-activated free→Pro 격차로 activation이 leading indicator인지 확정."
|
||||
- "Survival(Kaplan-Meier) 분석: 전환/이탈이 몰리는 시점 구간 특정 → 넛지/트라이얼 타이밍 도출."
|
||||
- "(데이터 확보 후) 병목 단계 A/B 실험 설계 — 온보딩 variant·paywall 타이밍. 현재는 설계만."
|
||||
next-actions:
|
||||
- "이벤트 계측 스펙 확정: 노트 §3의 이벤트 맵(signup/onboarding/activation/paywall/checkout)과 공통 프로퍼티·pseudonymous id를 구현 요청으로 전달."
|
||||
- "Activation 정의 확정 실험: 후보 A1~A3 중 전환 격차가 최대인 정의를 실데이터로 선택(초기 로그 확보 후)."
|
||||
- "퍼널 대시보드 구축: 단계별 cohort-based 전환·절대 이탈수·히트맵을 상시 관측 뷰로."
|
||||
- "placeholder 임계값(활성화 N회·한도%·window)을 초기 데이터로 보정 후 PQL 정의 잠금."
|
||||
@@ -0,0 +1,113 @@
|
||||
# 🟢 [결정] 무료→Pro 전환 이탈 규명 (fan-out 종합)
|
||||
|
||||
> **결론** — 원인을 단정해 바로 개입하지 말고, 정량 퍼널 계측 신설과 정성 3-트랙 리서치를 병렬로 돌려 activation gap과 'aha-moment 前 paywall' 정렬 가설을 삼각측량으로 확증한 뒤에만 온보딩·paywall 재설계를 결정한다. 두 관점은 activation/전환 window가 핵심이라는 데 합의하며, "가설 확증 우선(정성) vs 계측 신설 우선(정량)"의 순서에서 견해가 갈린다(둘 다 보존).
|
||||
|
||||
> **결정 필요** — ✅ 예 · 승인자 `EXEC-CPO`
|
||||
> **확신도** — Med (E3 근거)
|
||||
|
||||
`repo: company-haness` · `2026-07-07 19:47` · `wf-churn-01`
|
||||
|
||||
## 🎯 결정해야 할 질문
|
||||
무료→Pro 전환 이탈에 대해 지금 무엇을 승인할 것인가 — 원인 개입을 바로 할지, 아니면 정량 계측+정성 리서치 병렬 확증을 먼저 할지?
|
||||
|
||||
## ✅ 권고안
|
||||
병렬 삼각측량 승인 — (1) FAM-DATA: 온보딩→첫결제 퍼널 단계 계측 신설(activation 역산·PQL·cohort 전환율·survival), (2) FAM-UX-RESEARCH: Track A 심층인터뷰 + Track B 결제구간 사용성테스트로 aha-paywall 정렬(H1)·TTV(H2) 우선 검증. 두 결과가 일치하는 병목부터 EXEC-CPO/FAM-PRODUCT-MGMT의 온보딩·paywall 재설계 discovery 입력으로 승격.
|
||||
|
||||
## 👥 역할별 핵심 결론 (요약)
|
||||
|
||||
| 역할 | 관점 | 핵심 결론 | 확신도 |
|
||||
|---|---|---|---|
|
||||
| UX 리서처 AI | 무료→Pro 이탈은 '가격 문제'가 아니라 '가치를 체감하기 前에 결제를 요구당하는' 경험 순서(TTV·aha-paywall 정렬)의 문제라는 정성 관점. | 온보딩→첫 결제 이탈의 유력 정성 원인은 aha-moment 도달 前 paywall 등장과 과대한 TTV·결제 마찰의 복합이다 — 단 실제 데이터·인터뷰 원본이 없어 이는 검증 전 가설(E1~E2, Med)이며, 3-트랙 리서치로 원인을 확증한 뒤에만 개입해야 한다. | Med |
|
||||
| 데이터 분석가 AI | 제품 감(感)이 아니라 사용자 행동·전환 지표로 온보딩→첫 결제 이탈을 계량한다 — 정량 관점. | 실측 로그가 없으므로 지금 할 일은 '왜 안 되는지' 단정이 아니라 온보딩→첫 결제 퍼널을 단계로 계측하는 것 — activation(리텐션 상관으로 역산)·PQL(한도근접+재방문+paywall 복합 시그널)·단계별 cohort-based 전환율을 계측·정의하고, 단계별 '절대 이탈수' 랭킹과 코호트×단계 히트맵으로 병목을 특정하도록 설계한다. | Med |
|
||||
|
||||
## 📋 역할별 상세 (관점 원문 그대로)
|
||||
|
||||
### UX 리서처 AI — 확신도 Med
|
||||
*관점:* 무료→Pro 이탈은 '가격 문제'가 아니라 '가치를 체감하기 前에 결제를 요구당하는' 경험 순서(TTV·aha-paywall 정렬)의 문제라는 정성 관점.
|
||||
|
||||
> **결론:** 온보딩→첫 결제 이탈의 유력 정성 원인은 aha-moment 도달 前 paywall 등장과 과대한 TTV·결제 마찰의 복합이다 — 단 실제 데이터·인터뷰 원본이 없어 이는 검증 전 가설(E1~E2, Med)이며, 3-트랙 리서치로 원인을 확증한 뒤에만 개입해야 한다.
|
||||
|
||||
#### 🔎 핵심 발견
|
||||
- H1 (핵심 가설) 가치 체감 前 paywall: aha-moment 도달 이전에 결제벽이 등장해 '왜 돈을 내야 하는지' 납득이 서지 않은 채 이탈 — paywall과 aha의 순서/거리 정렬 오류가 유력.
|
||||
- H2 activation gap: 첫 핵심가치까지의 온보딩 단계·설정이 많아 TTV가 길어 결제 구간 도달 전에 이탈(활성화 실패).
|
||||
- H3 value gap: 무료 티어가 Pro의 구체적 가치를 미리 보여주지 못해 업그레이드 동기 자체가 형성되지 않음.
|
||||
- H4 checkout friction·불안: 카드 선입력 요구·해지/환불 정책 불투명이 결제 직전 주저(hesitation)를 유발.
|
||||
- H5 플랜 인지부하: 플랜/가격 비교가 복잡해 결정을 회피(decision paralysis)하고 무료 유지로 관성 회귀.
|
||||
- H6 전환 넛지 오타이밍/부재: 한도 근접·가치 순간에 맞춘 컨텍스트 넛지가 없어 전환 window를 놓침(정성 관찰 가설).
|
||||
|
||||
#### 🧪 리서치 설계
|
||||
- Track A — 심층 인터뷰: 이탈군(온보딩 완주·결제 미도달)/중도포기군/전환 성공 대조군 3그룹 각 6~8명(포화까지), JTBD Switch 4-force + Critical Incident로 '결제를 결심/포기한 바로 그 순간'을 역추적.
|
||||
- Track B — 결제 구간 사용성 테스트: think-aloud 8~10명, '가입→첫 가치 경험→Pro 결제 완료' end-to-end 과업으로 paywall 타이밍·결제폼 마찰·플랜 인지부하를 SEQ/hesitation 코딩으로 계측.
|
||||
- Track C — 저니/휴리스틱 분석: 온보딩→aha→paywall→checkout 경험 저니맵+감정곡선+friction 히트포인트 작성, Nielsen 10 휴리스틱 워크스루와 (가용 시)세션 관찰을 삼각측량(수치 산출은 FAM-DATA 이관).
|
||||
|
||||
#### ➡️ 다음 액션
|
||||
- 리서치옵스 킥오프: 3그룹 인터뷰 대상 리크루팅 스크리너·인센티브 예산 승인 요청(EXEC-CPO), 4주 내 Track A/B 실행 일정 확정.
|
||||
- 정량 삼각측량 요청: FAM-DATA에 온보딩→paywall→checkout funnel 드롭 지점·aha 후보 이벤트 계량을 의뢰해 본 정성 가설(H1~H6)과 대조.
|
||||
- 가설 우선검증 순서 제안: H1(aha-paywall 정렬)·H2(TTV) 먼저 검증 → 확증 시 EXEC-CPO/FAM-PRODUCT-MGMT에 온보딩 재설계·paywall 재배치 discovery 입력으로 전달(결정은 CPO 소관).
|
||||
|
||||
*근거:* `_sandbox/evidence/wf-churn-01/wf-churn-01-ux-researcher-notes.md` (E2)
|
||||
|
||||
### 데이터 분석가 AI — 확신도 Med
|
||||
*관점:* 제품 감(感)이 아니라 사용자 행동·전환 지표로 온보딩→첫 결제 이탈을 계량한다 — 정량 관점.
|
||||
|
||||
> **결론:** 실측 로그가 없으므로 지금 할 일은 '왜 안 되는지' 단정이 아니라 온보딩→첫 결제 퍼널을 단계로 계측하는 것 — activation(리텐션 상관으로 역산)·PQL(한도근접+재방문+paywall 복합 시그널)·단계별 cohort-based 전환율을 계측·정의하고, 단계별 '절대 이탈수' 랭킹과 코호트×단계 히트맵으로 병목을 특정하도록 설계한다.
|
||||
|
||||
#### 🔎 핵심 발견
|
||||
- 가설1(계측 공백): free→Pro 저조의 1차 원인은 '전환이 나쁘다'가 아니라 단계별 이탈을 볼 계측 자체가 없어 병목 단계를 특정 못 하는 것 — 퍼널 계측 신설이 선행 과제.
|
||||
- 가설2(activation leak): 온보딩→첫 가치경험(activation) 구간 이탈이 가장 클 개연성 — activated vs non-activated 코호트의 전환 격차로 검증 가능.
|
||||
- 가설3(PQL 부재): 무료 한도 근접·paywall 접촉 같은 전환 임박 시그널이 계량되지 않아 결제 의도 코호트를 놓치고 있을 가능성.
|
||||
- 가설4(전환 latency): free→Pro 전환은 특정 시점에 집중될 개연 — survival 곡선으로 넛지 타이밍 창을 특정해야 함.
|
||||
|
||||
#### 📐 계측할 지표
|
||||
- Activation Rate — 리텐션/전환 상관이 가장 큰 초기 행동으로 activation을 역산 정의 후 (activated 신규/전체 신규).
|
||||
- 단계별 funnel conversion(S0 Signup→S6 First payment) — 고정 window의 cohort-based 전환율·drop-off율.
|
||||
- PQL 생성률 및 PQL→결제 전환율 — 한도 70~80% 소진 + 재방문 + paywall 히트 복합 시그널.
|
||||
- TTV(signup→activation)와 Time-to-Convert(signup→first payment) 분포(중앙값·꼬리).
|
||||
- 코호트별 D1/D7/D14/D30 retention(activated vs non-activated 분리).
|
||||
- 단계별 절대 이탈수 = 진입수 × (1-Cn), abandonment point 집계.
|
||||
|
||||
#### 📊 분석 계획
|
||||
- Funnel 병목 랭킹: 단계별 절대 이탈수 내림차순으로 최대 leak 단계 우선 지목(전환율%는 보조).
|
||||
- Cohort × step 히트맵: signup week·channel·device·온보딩 variant별 이탈 편차 탐지.
|
||||
- Activation↔전환 상관 분석: activated vs non-activated free→Pro 격차로 activation이 leading indicator인지 확정.
|
||||
- Survival(Kaplan-Meier) 분석: 전환/이탈이 몰리는 시점 구간 특정 → 넛지/트라이얼 타이밍 도출.
|
||||
- (데이터 확보 후) 병목 단계 A/B 실험 설계 — 온보딩 variant·paywall 타이밍. 현재는 설계만.
|
||||
|
||||
#### ➡️ 다음 액션
|
||||
- 이벤트 계측 스펙 확정: 노트 §3의 이벤트 맵(signup/onboarding/activation/paywall/checkout)과 공통 프로퍼티·pseudonymous id를 구현 요청으로 전달.
|
||||
- Activation 정의 확정 실험: 후보 A1~A3 중 전환 격차가 최대인 정의를 실데이터로 선택(초기 로그 확보 후).
|
||||
- 퍼널 대시보드 구축: 단계별 cohort-based 전환·절대 이탈수·히트맵을 상시 관측 뷰로.
|
||||
- placeholder 임계값(활성화 N회·한도%·window)을 초기 데이터로 보정 후 PQL 정의 잠금.
|
||||
|
||||
*근거:* `_sandbox/evidence/wf-churn-01/wf-churn-01-data-analyst-notes.md` (E2)
|
||||
|
||||
## ⚖️ 합의 / 충돌
|
||||
|
||||
**합의**
|
||||
- 지금은 원인 단정 단계가 아니라 검증·계측 설계 단계 — confidence Med, 조기 개입 금지(양측 명시).
|
||||
- activation gap(TTV·첫 가치경험까지의 이탈)이 최우선 후보 원인 (UX H2 ↔ DATA 가설2).
|
||||
- 전환 window(한도 근접·paywall 접촉 시점)가 개입 지렛대 — 타이밍이 관건 (UX H1/H6 ↔ DATA PQL/survival).
|
||||
- 정성×정량 삼각측량이 필수라는 데 양측이 서로를 명시적으로 참조함(상호 이관 요청 존재).
|
||||
|
||||
**충돌(보존)**
|
||||
- 접근 순서: UX는 'aha-paywall 순서(H1)를 유력 원인으로 먼저 리서치 확증' vs DATA는 '원인 단정 말고 먼저 퍼널 계측 신설로 병목 단계부터 특정' — 가설주도 vs 계측주도 (병렬로 보존).
|
||||
- 증거 우선순위: UX는 '그 순간'의 의미(소표본 심층) 중시 vs DATA는 규모·유의성(절대 이탈수·코호트) 중시 — 각자 상대의 대표성/편향을 리스크로 지목.
|
||||
|
||||
## ⚠️ 리스크
|
||||
- 실데이터·인터뷰 원본 부재 상태의 가설을 사실로 오인해 조기 개입하면 잘못된 지점을 고쳐 전환이 안 오르거나 free 경험을 훼손(양 워커 공통 리스크).
|
||||
- 정성 소표본 과일반화 위험 ↔ 전환율%만 보고 소트래픽 단계 과대평가 위험 — 두 방법의 편향은 삼각측량으로만 상쇄됨.
|
||||
- 이벤트 계측 인프라 미비 시 계측 스펙 신설이 선행돼야 하며, 그 전엔 정량 확증이 지연됨.
|
||||
|
||||
## 📎 근거
|
||||
|
||||
| # | 출처 | 등급 |
|
||||
|---|---|---|
|
||||
| 1 | _sandbox/completion-records/wf-churn-01/wf-churn-01-ux-researcher.report.yaml | E3 |
|
||||
| 2 | _sandbox/completion-records/wf-churn-01/wf-churn-01-data-analyst.report.yaml | E3 |
|
||||
| 3 | org-os/06-agent-work/collaboration-map.yaml | E3 |
|
||||
|
||||
## 📂 원본 파일 (에이전트용 YAML)
|
||||
|
||||
- 종합/원천: `_sandbox/completion-records/wf-churn-01/wf-churn-01-synthesis.report.yaml`
|
||||
- 역할 보고서: `_sandbox/completion-records/wf-churn-01/wf-churn-01-ux-researcher.report.yaml`
|
||||
- 역할 보고서: `_sandbox/completion-records/wf-churn-01/wf-churn-01-data-analyst.report.yaml`
|
||||
@@ -0,0 +1,38 @@
|
||||
synthesized-by: Orchestrator (fan-out 종합 — 워커가 아님)
|
||||
workflow-id: wf-churn-01
|
||||
title: 무료→Pro 전환 이탈 원인 규명 (FAM-UX-RESEARCH fan-out 종합)
|
||||
decision-question: "무료→Pro 전환 이탈에 대해 지금 무엇을 승인할 것인가 — 원인 개입을 바로 할지, 아니면 정량 계측+정성 리서치 병렬 확증을 먼저 할지?"
|
||||
report-header:
|
||||
bottom-line: >
|
||||
원인을 단정해 바로 개입하지 말고, 정량 퍼널 계측 신설과 정성 3-트랙 리서치를 병렬로 돌려
|
||||
activation gap과 'aha-moment 前 paywall' 정렬 가설을 삼각측량으로 확증한 뒤에만
|
||||
온보딩·paywall 재설계를 결정한다. 두 관점은 activation/전환 window가 핵심이라는 데 합의하며,
|
||||
"가설 확증 우선(정성) vs 계측 신설 우선(정량)"의 순서에서 견해가 갈린다(둘 다 보존).
|
||||
decision-needed: { needed: true, approver: EXEC-CPO }
|
||||
confidence: { value: Med, derived-from: evidence }
|
||||
risks:
|
||||
- "실데이터·인터뷰 원본 부재 상태의 가설을 사실로 오인해 조기 개입하면 잘못된 지점을 고쳐 전환이 안 오르거나 free 경험을 훼손(양 워커 공통 리스크)."
|
||||
- "정성 소표본 과일반화 위험 ↔ 전환율%만 보고 소트래픽 단계 과대평가 위험 — 두 방법의 편향은 삼각측량으로만 상쇄됨."
|
||||
- "이벤트 계측 인프라 미비 시 계측 스펙 신설이 선행돼야 하며, 그 전엔 정량 확증이 지연됨."
|
||||
evidence:
|
||||
- source-uri: _sandbox/completion-records/wf-churn-01/wf-churn-01-ux-researcher.report.yaml
|
||||
grade: E3
|
||||
- source-uri: _sandbox/completion-records/wf-churn-01/wf-churn-01-data-analyst.report.yaml
|
||||
grade: E3
|
||||
- source-uri: org-os/06-agent-work/collaboration-map.yaml
|
||||
grade: E3
|
||||
recommendation: >
|
||||
병렬 삼각측량 승인 — (1) FAM-DATA: 온보딩→첫결제 퍼널 단계 계측 신설(activation 역산·PQL·cohort 전환율·survival),
|
||||
(2) FAM-UX-RESEARCH: Track A 심층인터뷰 + Track B 결제구간 사용성테스트로 aha-paywall 정렬(H1)·TTV(H2) 우선 검증.
|
||||
두 결과가 일치하는 병목부터 EXEC-CPO/FAM-PRODUCT-MGMT의 온보딩·paywall 재설계 discovery 입력으로 승격.
|
||||
consensus:
|
||||
- "지금은 원인 단정 단계가 아니라 검증·계측 설계 단계 — confidence Med, 조기 개입 금지(양측 명시)."
|
||||
- "activation gap(TTV·첫 가치경험까지의 이탈)이 최우선 후보 원인 (UX H2 ↔ DATA 가설2)."
|
||||
- "전환 window(한도 근접·paywall 접촉 시점)가 개입 지렛대 — 타이밍이 관건 (UX H1/H6 ↔ DATA PQL/survival)."
|
||||
- "정성×정량 삼각측량이 필수라는 데 양측이 서로를 명시적으로 참조함(상호 이관 요청 존재)."
|
||||
conflicts:
|
||||
- "접근 순서: UX는 'aha-paywall 순서(H1)를 유력 원인으로 먼저 리서치 확증' vs DATA는 '원인 단정 말고 먼저 퍼널 계측 신설로 병목 단계부터 특정' — 가설주도 vs 계측주도 (병렬로 보존)."
|
||||
- "증거 우선순위: UX는 '그 순간'의 의미(소표본 심층) 중시 vs DATA는 규모·유의성(절대 이탈수·코호트) 중시 — 각자 상대의 대표성/편향을 리스크로 지목."
|
||||
linked-reports:
|
||||
- _sandbox/completion-records/wf-churn-01/wf-churn-01-ux-researcher.report.yaml
|
||||
- _sandbox/completion-records/wf-churn-01/wf-churn-01-data-analyst.report.yaml
|
||||
@@ -0,0 +1,40 @@
|
||||
# ✅ [완료] wf-churn-01-ux-researcher
|
||||
|
||||
> **결론** — 온보딩→첫 결제 이탈의 유력 정성 원인은 aha-moment 도달 前 paywall 등장과 과대한 TTV·결제 마찰의 복합이다 — 단 실제 데이터·인터뷰 원본이 없어 이는 검증 전 가설(E1~E2, Med)이며, 3-트랙 리서치로 원인을 확증한 뒤에만 개입해야 한다.
|
||||
|
||||
> **결정 필요** — — 아니오
|
||||
> **확신도** — Med (E2 근거)
|
||||
|
||||
`repo: company-haness` · `2026-07-07 19:47` · `wf-churn-01`
|
||||
|
||||
## 🔎 핵심 발견
|
||||
- H1 (핵심 가설) 가치 체감 前 paywall: aha-moment 도달 이전에 결제벽이 등장해 '왜 돈을 내야 하는지' 납득이 서지 않은 채 이탈 — paywall과 aha의 순서/거리 정렬 오류가 유력.
|
||||
- H2 activation gap: 첫 핵심가치까지의 온보딩 단계·설정이 많아 TTV가 길어 결제 구간 도달 전에 이탈(활성화 실패).
|
||||
- H3 value gap: 무료 티어가 Pro의 구체적 가치를 미리 보여주지 못해 업그레이드 동기 자체가 형성되지 않음.
|
||||
- H4 checkout friction·불안: 카드 선입력 요구·해지/환불 정책 불투명이 결제 직전 주저(hesitation)를 유발.
|
||||
- H5 플랜 인지부하: 플랜/가격 비교가 복잡해 결정을 회피(decision paralysis)하고 무료 유지로 관성 회귀.
|
||||
- H6 전환 넛지 오타이밍/부재: 한도 근접·가치 순간에 맞춘 컨텍스트 넛지가 없어 전환 window를 놓침(정성 관찰 가설).
|
||||
|
||||
## 🧪 리서치 설계
|
||||
- Track A — 심층 인터뷰: 이탈군(온보딩 완주·결제 미도달)/중도포기군/전환 성공 대조군 3그룹 각 6~8명(포화까지), JTBD Switch 4-force + Critical Incident로 '결제를 결심/포기한 바로 그 순간'을 역추적.
|
||||
- Track B — 결제 구간 사용성 테스트: think-aloud 8~10명, '가입→첫 가치 경험→Pro 결제 완료' end-to-end 과업으로 paywall 타이밍·결제폼 마찰·플랜 인지부하를 SEQ/hesitation 코딩으로 계측.
|
||||
- Track C — 저니/휴리스틱 분석: 온보딩→aha→paywall→checkout 경험 저니맵+감정곡선+friction 히트포인트 작성, Nielsen 10 휴리스틱 워크스루와 (가용 시)세션 관찰을 삼각측량(수치 산출은 FAM-DATA 이관).
|
||||
|
||||
## ➡️ 다음 액션
|
||||
- 리서치옵스 킥오프: 3그룹 인터뷰 대상 리크루팅 스크리너·인센티브 예산 승인 요청(EXEC-CPO), 4주 내 Track A/B 실행 일정 확정.
|
||||
- 정량 삼각측량 요청: FAM-DATA에 온보딩→paywall→checkout funnel 드롭 지점·aha 후보 이벤트 계량을 의뢰해 본 정성 가설(H1~H6)과 대조.
|
||||
- 가설 우선검증 순서 제안: H1(aha-paywall 정렬)·H2(TTV) 먼저 검증 → 확증 시 EXEC-CPO/FAM-PRODUCT-MGMT에 온보딩 재설계·paywall 재배치 discovery 입력으로 전달(결정은 CPO 소관).
|
||||
|
||||
## ⚠️ 리스크
|
||||
- 원본 인터뷰·이벤트 로그 부재 상태에서 가설을 사실로 오인해 조기 개입 시, 잘못된 지점을 고쳐 전환율이 개선되지 않거나 free 경험을 훼손할 수 있음.
|
||||
- 정성 표본(인터뷰 6~8명×3그룹)은 전환율 크기를 대표하지 못함 — funnel 규모/유의성은 FAM-DATA 정량과 삼각측량해야 하며 정성 단독 결론은 과일반화 위험.
|
||||
|
||||
## 📎 근거
|
||||
|
||||
| # | 출처 | 등급 |
|
||||
|---|---|---|
|
||||
| 1 | _sandbox/evidence/wf-churn-01/wf-churn-01-ux-researcher-notes.md | E2 |
|
||||
|
||||
## 📂 원본 파일 (에이전트용 YAML)
|
||||
|
||||
- 종합/원천: `_sandbox/completion-records/wf-churn-01/wf-churn-01-ux-researcher.report.yaml`
|
||||
@@ -0,0 +1,32 @@
|
||||
role-id: UX-RESEARCHER
|
||||
role-name: UX 리서처 AI
|
||||
lens: LENS-CUSTOMER
|
||||
perspective: "무료→Pro 이탈은 '가격 문제'가 아니라 '가치를 체감하기 前에 결제를 요구당하는' 경험 순서(TTV·aha-paywall 정렬)의 문제라는 정성 관점."
|
||||
workflow-id: wf-churn-01
|
||||
report-header:
|
||||
bottom-line: >
|
||||
온보딩→첫 결제 이탈의 유력 정성 원인은 aha-moment 도달 前 paywall 등장과 과대한 TTV·결제 마찰의 복합이다 —
|
||||
단 실제 데이터·인터뷰 원본이 없어 이는 검증 전 가설(E1~E2, Med)이며, 3-트랙 리서치로 원인을 확증한 뒤에만 개입해야 한다.
|
||||
decision-needed: { needed: false, approver: EXEC-CPO }
|
||||
confidence: { value: Med, derived-from: evidence }
|
||||
risks:
|
||||
- "원본 인터뷰·이벤트 로그 부재 상태에서 가설을 사실로 오인해 조기 개입 시, 잘못된 지점을 고쳐 전환율이 개선되지 않거나 free 경험을 훼손할 수 있음."
|
||||
- "정성 표본(인터뷰 6~8명×3그룹)은 전환율 크기를 대표하지 못함 — funnel 규모/유의성은 FAM-DATA 정량과 삼각측량해야 하며 정성 단독 결론은 과일반화 위험."
|
||||
evidence:
|
||||
- source-uri: _sandbox/evidence/wf-churn-01/wf-churn-01-ux-researcher-notes.md
|
||||
grade: E2
|
||||
findings:
|
||||
- "H1 (핵심 가설) 가치 체감 前 paywall: aha-moment 도달 이전에 결제벽이 등장해 '왜 돈을 내야 하는지' 납득이 서지 않은 채 이탈 — paywall과 aha의 순서/거리 정렬 오류가 유력."
|
||||
- "H2 activation gap: 첫 핵심가치까지의 온보딩 단계·설정이 많아 TTV가 길어 결제 구간 도달 전에 이탈(활성화 실패)."
|
||||
- "H3 value gap: 무료 티어가 Pro의 구체적 가치를 미리 보여주지 못해 업그레이드 동기 자체가 형성되지 않음."
|
||||
- "H4 checkout friction·불안: 카드 선입력 요구·해지/환불 정책 불투명이 결제 직전 주저(hesitation)를 유발."
|
||||
- "H5 플랜 인지부하: 플랜/가격 비교가 복잡해 결정을 회피(decision paralysis)하고 무료 유지로 관성 회귀."
|
||||
- "H6 전환 넛지 오타이밍/부재: 한도 근접·가치 순간에 맞춘 컨텍스트 넛지가 없어 전환 window를 놓침(정성 관찰 가설)."
|
||||
research-design:
|
||||
- "Track A — 심층 인터뷰: 이탈군(온보딩 완주·결제 미도달)/중도포기군/전환 성공 대조군 3그룹 각 6~8명(포화까지), JTBD Switch 4-force + Critical Incident로 '결제를 결심/포기한 바로 그 순간'을 역추적."
|
||||
- "Track B — 결제 구간 사용성 테스트: think-aloud 8~10명, '가입→첫 가치 경험→Pro 결제 완료' end-to-end 과업으로 paywall 타이밍·결제폼 마찰·플랜 인지부하를 SEQ/hesitation 코딩으로 계측."
|
||||
- "Track C — 저니/휴리스틱 분석: 온보딩→aha→paywall→checkout 경험 저니맵+감정곡선+friction 히트포인트 작성, Nielsen 10 휴리스틱 워크스루와 (가용 시)세션 관찰을 삼각측량(수치 산출은 FAM-DATA 이관)."
|
||||
next-actions:
|
||||
- "리서치옵스 킥오프: 3그룹 인터뷰 대상 리크루팅 스크리너·인센티브 예산 승인 요청(EXEC-CPO), 4주 내 Track A/B 실행 일정 확정."
|
||||
- "정량 삼각측량 요청: FAM-DATA에 온보딩→paywall→checkout funnel 드롭 지점·aha 후보 이벤트 계량을 의뢰해 본 정성 가설(H1~H6)과 대조."
|
||||
- "가설 우선검증 순서 제안: H1(aha-paywall 정렬)·H2(TTV) 먼저 검증 → 확증 시 EXEC-CPO/FAM-PRODUCT-MGMT에 온보딩 재설계·paywall 재배치 discovery 입력으로 전달(결정은 CPO 소관)."
|
||||
@@ -0,0 +1,62 @@
|
||||
# 🔍 [리뷰] 하네스 효율성 감사
|
||||
|
||||
> **결론** — 사용자 하네스의 골격은 2025~2026 업계 합의(멀티에이전트는 판단/리서치에만, 코딩엔 단일; 종합 시 요약 말고 원본 트레이스 공유)와 정합하며 그 두 교훈을 스펙으로 성문화했다 — fan-out/collapse 분기 + synthesis-rehydration. 효율의 골격 근거는 탄탄하다. 실패는 구조가 아니라 운영 규율(tier 게이트·렌즈 상한·dissent 보존 검증을 정책 텍스트가 아니라 hook 강제로 배선했는가)에서 온다.
|
||||
|
||||
> **결정 필요** — — 아니오
|
||||
> **확신도** — Med (E3 근거)
|
||||
|
||||
`repo: company-haness` · `2026-07-07 11:12:50+00:00` · `wf-harness-audit`
|
||||
|
||||
## · report id
|
||||
harness-comparison-20260707T111250Z
|
||||
|
||||
## · created at
|
||||
2026-07-07 11:12:50+00:00
|
||||
|
||||
## · verdict
|
||||
이례적으로 자기인식이 높은 설계. Anthropic(코딩엔 멀티에이전트 비권장)과 Cognition(요약 말고 full trace)의 핵심 교훈을 각각 collaboration-default와 synthesis-rehydration으로 코드화했고, 다양성을 headcount가 아니라 11 렌즈로 고정해 spawn 폭발을 구조적으로 억제했다.
|
||||
|
||||
## · strengths
|
||||
- fan-out/collapse 분기 = 업계 최선 판단과 정합(코드는 collapse로 접어 Anthropic/Cognition의 코딩 경고 반영). MetaGPT/ChatDev/CrewAI엔 이 구분 없음 → 더 방어적·토큰효율적.
|
||||
- synthesis-rehydration이 Cognition 1순위 비판(요약이 관점 유실)을 정면 방어 — 하위 .report.yaml 전문 재적재.
|
||||
- 다양성을 11 렌즈로 고정한 것이 토큰 폭증의 구조적 방파제(Anthropic '단순 질의 50 subagent' 실패를 스펙 차원에서 억제). 조사대상 중 가장 독창적.
|
||||
- mode×tier 경제성 게이트가 Anthropic의 '고가치 과제에만 멀티에이전트'를 정책화(AWS routing-vs-full과 동형, 2직교축으로 더 세밀).
|
||||
- 파일기반·계약기반 소통이 org OS(내구·감사) 목적에 정확 — 12-factor own-context, LangGraph checkpoint 계열. 지연 민감 코드루프는 collapse로 상쇄.
|
||||
|
||||
## · closest industry
|
||||
- Anthropic multi-agent research system — 가장 직접적 원형(Orchestrator + fan-out worker + clean context).
|
||||
- Magentic-One Task/Progress Ledger — plan.md+progress.yaml 듀얼 원장으로 직접 차용.
|
||||
- Cognition Don't Build Multi-Agents — 명시 인용·방어한 반론 진영.
|
||||
- AWS Bedrock routing vs full = light vs heavy tier와 동형. LangGraph FSM = state-transition-rules.
|
||||
|
||||
## · recommendations
|
||||
- wave당 토큰·비용 계측 + tier별 fan-out 예산 하드 상한(초과 시 자동 collapse 강등). 정책 텍스트를 hook 강제로 승격. (근거: Anthropic 15배 토큰)
|
||||
- standard tier fan-out 폭을 family가 아니라 lens로 상한(공유렌즈 primary 1개, heavy만 sub-angle 분화). 이미 있는 shared-lens-selection을 기본 강제로. (근거: 50 subagent 실패)
|
||||
- fan-out phase 내부에 '공유 제약 pre-brief'(승인 Packet+공통 설계제약)를 context-package에 동봉 — 발산 다양성은 유지하되 충돌 결정만 사전 정렬. (근거: Cognition Flappy Bird)
|
||||
- 종합자에 dissent-보존 검증 강제기: 종합 .report.yaml에 conflicts/dissent 필드 + 하위 보고서 링크 존재를 validate_report가 검사. (근거: dissent 삭제 금지 must-not)
|
||||
- 초장기 wave용 compaction 단계 형식화하되 결정 재적재(synthesis-rehydration) 경로는 압축 대상에서 제외. (근거: 12-factor dumb-zone 40~60%)
|
||||
|
||||
## · sources
|
||||
- Anthropic multi-agent research system: https://www.anthropic.com/engineering/multi-agent-research-system
|
||||
- Cognition Don't Build Multi-Agents: https://cognition.com/blog/dont-build-multi-agents
|
||||
- MetaGPT arXiv 2308.00352 / ChatDev arXiv 2307.07924
|
||||
- Magentic-One (Microsoft Research) / AWS Bedrock multi-agent collaboration / 12-Factor Agents
|
||||
- 전체 출처·비교표: docs/superpowers/harness-efficiency-audit-2026-07-07.md
|
||||
|
||||
## ⚠️ 리스크
|
||||
- 토큰·지연 비용: Anthropic 관측상 멀티에이전트 ~15배 토큰, 토큰량이 성능분산 80% 설명. fan-out 위에 전문 재적재를 쌓아 종합 지점이 특히 무겁다.
|
||||
- 단일 fan-out phase 내부 발산: 8 family가 clean context로 병렬 시작하면 미명시 가정 충돌(Cognition Flappy Bird) 잔존 — 재조정 부담이 종합자에 집중.
|
||||
- 종합자가 품질 병목·미검증 지점: dissent 보존을 강제하는 hook이 종합 단계에 약함.
|
||||
- 62->26 taxonomy 책임 중복 리스크: AWS 베스트프랙티스는 collaborator 중복 최소화 권고 — family 수가 많아 오라우팅 확률↑.
|
||||
|
||||
## 📎 근거
|
||||
|
||||
| # | 출처 | 등급 |
|
||||
|---|---|---|
|
||||
| 1 | docs/superpowers/harness-efficiency-audit-2026-07-07.md | E2 |
|
||||
| 2 | org-os/06-agent-work/execution-policy.yaml | E3 |
|
||||
| 3 | org-os/06-agent-work/collaboration-map.yaml | E3 |
|
||||
|
||||
## 📂 원본 파일 (에이전트용 YAML)
|
||||
|
||||
- 종합/원천: `_sandbox/completion-records/wf-harness-audit/harness-comparison-20260707T111250Z.report.yaml`
|
||||
+50
@@ -0,0 +1,50 @@
|
||||
report-id: harness-comparison-20260707T111250Z
|
||||
workflow-id: wf-harness-audit
|
||||
role-id: harness-comparison
|
||||
created-at: 2026-07-07T11:12:50Z
|
||||
title: Org OS 하네스 vs 업계 멀티에이전트 오케스트레이션 — 효율성 감사
|
||||
report-header:
|
||||
bottom-line: >
|
||||
사용자 하네스의 골격은 2025~2026 업계 합의(멀티에이전트는 판단/리서치에만, 코딩엔 단일; 종합 시 요약 말고 원본 트레이스 공유)와
|
||||
정합하며 그 두 교훈을 스펙으로 성문화했다 — fan-out/collapse 분기 + synthesis-rehydration. 효율의 골격 근거는 탄탄하다.
|
||||
실패는 구조가 아니라 운영 규율(tier 게이트·렌즈 상한·dissent 보존 검증을 정책 텍스트가 아니라 hook 강제로 배선했는가)에서 온다.
|
||||
decision-needed: { needed: false, approver: EXEC-CEO }
|
||||
confidence: { value: Med, derived-from: evidence }
|
||||
risks:
|
||||
- "토큰·지연 비용: Anthropic 관측상 멀티에이전트 ~15배 토큰, 토큰량이 성능분산 80% 설명. fan-out 위에 전문 재적재를 쌓아 종합 지점이 특히 무겁다."
|
||||
- "단일 fan-out phase 내부 발산: 8 family가 clean context로 병렬 시작하면 미명시 가정 충돌(Cognition Flappy Bird) 잔존 — 재조정 부담이 종합자에 집중."
|
||||
- "종합자가 품질 병목·미검증 지점: dissent 보존을 강제하는 hook이 종합 단계에 약함."
|
||||
- "62->26 taxonomy 책임 중복 리스크: AWS 베스트프랙티스는 collaborator 중복 최소화 권고 — family 수가 많아 오라우팅 확률↑."
|
||||
evidence:
|
||||
- source-uri: docs/superpowers/harness-efficiency-audit-2026-07-07.md
|
||||
grade: E2
|
||||
- source-uri: org-os/06-agent-work/execution-policy.yaml
|
||||
grade: E3
|
||||
- source-uri: org-os/06-agent-work/collaboration-map.yaml
|
||||
grade: E3
|
||||
verdict: >
|
||||
이례적으로 자기인식이 높은 설계. Anthropic(코딩엔 멀티에이전트 비권장)과 Cognition(요약 말고 full trace)의 핵심 교훈을
|
||||
각각 collaboration-default와 synthesis-rehydration으로 코드화했고, 다양성을 headcount가 아니라 11 렌즈로 고정해 spawn 폭발을 구조적으로 억제했다.
|
||||
strengths:
|
||||
- "fan-out/collapse 분기 = 업계 최선 판단과 정합(코드는 collapse로 접어 Anthropic/Cognition의 코딩 경고 반영). MetaGPT/ChatDev/CrewAI엔 이 구분 없음 → 더 방어적·토큰효율적."
|
||||
- "synthesis-rehydration이 Cognition 1순위 비판(요약이 관점 유실)을 정면 방어 — 하위 .report.yaml 전문 재적재."
|
||||
- "다양성을 11 렌즈로 고정한 것이 토큰 폭증의 구조적 방파제(Anthropic '단순 질의 50 subagent' 실패를 스펙 차원에서 억제). 조사대상 중 가장 독창적."
|
||||
- "mode×tier 경제성 게이트가 Anthropic의 '고가치 과제에만 멀티에이전트'를 정책화(AWS routing-vs-full과 동형, 2직교축으로 더 세밀)."
|
||||
- "파일기반·계약기반 소통이 org OS(내구·감사) 목적에 정확 — 12-factor own-context, LangGraph checkpoint 계열. 지연 민감 코드루프는 collapse로 상쇄."
|
||||
closest-industry:
|
||||
- "Anthropic multi-agent research system — 가장 직접적 원형(Orchestrator + fan-out worker + clean context)."
|
||||
- "Magentic-One Task/Progress Ledger — plan.md+progress.yaml 듀얼 원장으로 직접 차용."
|
||||
- "Cognition Don't Build Multi-Agents — 명시 인용·방어한 반론 진영."
|
||||
- "AWS Bedrock routing vs full = light vs heavy tier와 동형. LangGraph FSM = state-transition-rules."
|
||||
recommendations:
|
||||
- "wave당 토큰·비용 계측 + tier별 fan-out 예산 하드 상한(초과 시 자동 collapse 강등). 정책 텍스트를 hook 강제로 승격. (근거: Anthropic 15배 토큰)"
|
||||
- "standard tier fan-out 폭을 family가 아니라 lens로 상한(공유렌즈 primary 1개, heavy만 sub-angle 분화). 이미 있는 shared-lens-selection을 기본 강제로. (근거: 50 subagent 실패)"
|
||||
- "fan-out phase 내부에 '공유 제약 pre-brief'(승인 Packet+공통 설계제약)를 context-package에 동봉 — 발산 다양성은 유지하되 충돌 결정만 사전 정렬. (근거: Cognition Flappy Bird)"
|
||||
- "종합자에 dissent-보존 검증 강제기: 종합 .report.yaml에 conflicts/dissent 필드 + 하위 보고서 링크 존재를 validate_report가 검사. (근거: dissent 삭제 금지 must-not)"
|
||||
- "초장기 wave용 compaction 단계 형식화하되 결정 재적재(synthesis-rehydration) 경로는 압축 대상에서 제외. (근거: 12-factor dumb-zone 40~60%)"
|
||||
sources:
|
||||
- "Anthropic multi-agent research system: https://www.anthropic.com/engineering/multi-agent-research-system"
|
||||
- "Cognition Don't Build Multi-Agents: https://cognition.com/blog/dont-build-multi-agents"
|
||||
- "MetaGPT arXiv 2308.00352 / ChatDev arXiv 2307.07924"
|
||||
- "Magentic-One (Microsoft Research) / AWS Bedrock multi-agent collaboration / 12-Factor Agents"
|
||||
- "전체 출처·비교표: docs/superpowers/harness-efficiency-audit-2026-07-07.md"
|
||||
Reference in New Issue
Block a user