지표 체계 · 측정 계획

성공했는지 어떻게 재나?

읽는 순서 10 / 13 · 요약

성공했는지 어떻게 재나?

대표 지표는 하나, 주당 "확정 결정 수"다. 재확인까지 통과한 방만 세기 때문에 부풀리기 어렵다.
그 아래 방 완주율, 이의 없는 수용률, 최저 만족도 같은 지표 16건의 정의와, 기록할 이벤트 15종을 정했다. 원문과 개인 값은 기록하지 않는다.
목표 수치는 전부 가정이다. 첫 4주 실측으로 바꾼다.

누가 읽나: 성과를 물을 사람

← 이전: 9. 요구사항·정책다음: 11. 심사 대응 →

원본: KKIRI_METRICS_PLAN.md

P0 ⑤ · 목표치는 전부 가정. 같이 보기: ① 문제 정의 · ② AI 설계서 · ③ 심사 대응 · ④ 요구사항·정책 · 안내

작성: 페이블 · 2026-09-06 · P0 산출물 ⑤
목적: 「성공을 어떻게 재나」에 답한다. 북스타 지표 하나, 그 아래 지표 트리, 각 지표의 정의식, 이벤트 로깅 항목, 비공개 원칙을 지키는 계측 방법. 목표 수치는 전부 가정이고, 첫 4주 실측으로 교체한다.
기존 지표 출처: 1 Pager 「성공 지표」 4개(가정 표시), 벤치마킹 통합본 §7 KPI 3개(스파크). 이 문서가 둘을 흡수한다.

0. 한 장 요약

층	지표	정의	가정 목표
북스타	확정 결정 수 / 주	재확인을 통과해 「결정 완료」 상태가 된 방 수	발표 후 4주 누적 20방
핵심 가치	방 완주율	결정 완료 / 방 생성	60%
핵심 가치	이의 없는 수용률	재확인에서 「동의」 / 재확인 응답	70%
핵심 가치	최저 만족도 중앙값	확정 방의 `fairness.min` 중앙값	≥ 55
참여	초대 응답률	답변 제출 / 초대 인원	75%
유지	30일 재사용률	30일 내 두 번째 방 만든 방장 / 방장	30%
신뢰	리포트 열람률	내 리포트 연 참가자 / 응답자	80%
가드레일	구조화 실패율 · 설명 폴백률 · 후보 0개율	각 발생 / 시도	≤ 15% · ≤ 5% · ≤ 10%

1. 북스타 지표: 확정 결정 수

정의: 한 주 동안 「결정 완료」 상태에 도달한 방의 수. 결정 완료 = 재확인 마감 또는 전원 응답 후, 재조율 미요청(또는 재조율 1회 뒤) 상태에서 방장이 확정.

왜 이것인가: 끼리의 가치는 「방을 만드는 것」도 「결과를 보는 것」도 아니고 사람들이 그 결과를 받아들이고 실제로 그 결정으로 움직이는 것이다. 방 생성 수는 마케팅으로 부풀릴 수 있고, 결과 도달은 한 사람이 혼자 눌러도 된다. 확정은 3명 이상이 재확인을 거쳐야 하므로 가장 속이기 어렵다.

북스타를 올리는 세 가지 길: 방을 더 만들게(획득) · 만든 방이 끝까지 가게(완주) · 끝까지 간 방이 확정되게(수용). §2 트리는 이 셋을 분해한 것이다.

2. 지표 트리

확정 결정 수 / 주
├─ 방 생성 수                       [획득]
│    └─ 방장 재사용률 (30일)          [유지]
├─ 방 완주율 = 결정 완료 / 방 생성    [완주]
│    ├─ 초대 응답률 = 답변 / 초대
│    │    ├─ 링크 입장률 = 입장 / 초대
│    │    ├─ 답변 완료율 = 제출 / 입장
│    │    └─ 리마인드 후 응답 증분
│    ├─ 협상 시작률 = 시작 / 방 생성  (응답 ≥ 3 도달)
│    └─ 후보 0개율 = 후보 없음 / 협상
└─ 수용률 = 확정 / 결과 도달          [수용]
     ├─ 이의 없는 수용률 = 동의 / 재확인 응답
     ├─ 조건부 동의율 · 재조율 요청률
     ├─ 재조율 후 확정률
     └─ 리포트 열람률 (신뢰의 대리 지표)

3. 지표 정의표

ID	지표	분자	분모	창	가정 목표	왜 보나
K-01	확정 결정 수	`room_decided` 수	—	주	4주 누적 20	북스타
K-02	방 완주율	`room_decided`	`room_created`	방 생성 주 기준 코호트	60%	어디서 새는지의 총합
K-03	초대 응답률	`answer_submitted` (고유 참가자)	방 정원	방	75%	비공개 약속이 답변 의향을 올리는지
K-04	링크 입장률	`participant_joined`	방 정원	방	85%	초대 방식(공용/개인) 비교
K-05	답변 완료율	`answer_submitted`	`participant_joined`	방	90%	6문항이 너무 긴지
K-06	협상 시작률	`negotiation_started`	`room_created`	방	80%	3명 문턱이 적절한지
K-07	후보 0개율	`negotiation_result{ok:false}`	`negotiation_started`	방	≤ 10%	거부권이 너무 센지 (높으면 대리인 완화 라운드 근거)
K-08	이의 없는 수용률	`ratify{type:agree}`	`ratify` 전체	방	70%	결과가 납득되는지
K-09	재조율 요청률	`ratify{type:renego}`	`ratify` 전체	방	≤ 15%	불만의 직접 신호
K-10	재조율 후 확정률	재조율 방 중 `room_decided`	재조율 방	방	80%	1회 재조율이 충분한지
K-11	최저 만족도 중앙값	확정 방 `fairness.min`의 중앙값	—	주	≥ 55	공정성 약속의 수치. 평균만 오르고 최저가 내리면 경고
K-12	리포트 열람률	`receipt_viewed` (고유)	`answer_submitted`	방	80%	「내 조건이 지켜졌나」 확인 욕구 = 신뢰 형성 지점
K-13	30일 재사용률	30일 내 2번째 `room_created` 방장	첫 방 방장	방장 코호트	30%	유지
K-14	구조화 실패율	`structure_result{ok:false}`	`structure_attempted`	일	≤ 15%	어휘 7종이 부족한지 (가드레일)
K-15	설명 폴백률	`explain_fallback`	`explain_attempted`	일	≤ 5%	LLM 지연 (가드레일)
K-16	방 생성→확정 소요 시간	중앙값	—	주	≤ 30시간	「빠른 결정」 주장 검증 (마감 24h + 재확인)

4. 이벤트 로깅 명세

원칙: 원문·개인 태그·개인 만족도는 이벤트에 넣지 않는다. 방 단위 집계값과 상태 전이만 기록한다. 참가자 식별자는 방 안에서만 유효한 난수 ID.

이벤트	시점	속성	개인정보
`room_created`	FR-01 완료	room_id, people, deadline_option, invite_mode, topic	없음
`invite_shared`	공유 시트 선택	room_id, channel(kakao/slack/copy/qr/calendar)	없음
`participant_joined`	이름 입력 완료	room_id, participant_rid(난수), is_host	이름 제외
`question_viewed`	문항 표시	room_id, participant_rid, q_index	없음
`structure_attempted` / `structure_result`	Q6 제출	room_id, participant_rid, ok, tag_count, unknown_count, latency_ms	원문·태그 값 제외, 개수만
`answer_submitted`	6문항 완료	room_id, participant_rid, has_time_cap, has_budget_cap, avoid_count, elapsed_ms	선택값 제외
`reminder_sent`	자동/수동	room_id, auto, pending_count	없음
`negotiation_started`	시작	room_id, responded, people, auto_started, extensions	없음
`negotiation_result`	엔진 완료	room_id, ok, alive_count, dead_count, veto_total, winner_id, fairness_min, fairness_mean, filter_only	방 집계만
`explain_attempted` / `explain_fallback`	설명 생성	room_id, latency_ms, validator_rejects	없음
`result_viewed`	결과 화면	room_id, participant_rid	없음
`receipt_viewed`	내 리포트	room_id, participant_rid	만족도 값 제외
`ratify`	재확인 제출	room_id, participant_rid, type(agree/cond/renego)	조건 텍스트 제외
`room_decided`	확정	room_id, elapsed_from_created_ms, renegotiated, ratify_agree, ratify_cond, ratify_renego, abstain	없음
`room_closed_no_quorum`	3명 미달 폐쇄	room_id, responded, extensions	없음

이벤트 이름은 engine.js/app.js의 상태 전이 이름과 맞췄다. 목업에 붙일 때는 app.js의 setState 지점에 track(name, props) 한 줄씩 추가하고, 첫 구현은 console.table로 검증한 뒤 서버 전송으로 바꾼다.

5. 발표용 vs 제품용

	발표(내부 리뷰)	제품 4주
말할 수 있는 것	정의와 측정 계획, 헤드리스 검증 결과	실측치
말하면 안 되는 것	목표치를 달성치처럼	표본 10방 미만의 비율
첫 실측 소스	인터뷰 8명에게 목업 완주시켜 K-05·K-08·K-12 초기값	실제 방

6. 가설 검증 실험 (첫 4주)

실험	변수	지표	판단
E-1 초대 방식	공용 vs 개인 링크 (방장 선택 기록)	K-03·K-04	개인 링크 응답률이 10%p 이상 높으면 직장 팀 기본값을 개인으로
E-2 상한 안내 문구	「거부권」 표기 vs 「이 이상은 어려워요」	상한 사용률, K-07	후보 0개율이 10%를 넘으면 문구 완화
E-3 설명 유무	LLM 설명 vs 템플릿만	K-08·K-12	수용률 차이 5%p 미만이면 설명 LLM은 P1로 강등

7. 이 문서의 한계

목표치 전부 가정. 유사 서비스의 공개 벤치마크(응답률·완주율)를 찾지 못했다.
「최저 만족도」는 우리 규칙의 내부 값이라 외부 비교가 불가능하다. 인터뷰에서 「결과에 만족하나」 5점 척도를 같이 받아 상관을 본다.
이벤트는 아직 목업에 붙어 있지 않다. 붙이는 작업은 30분 규모지만 이번 범위(문서)에 넣지 않았다.

1 · 왜 만드나 · 문제 · 서비스 정의 · 시장 안의 자리

2 · 어떻게 쓰나 · 작동 원리 · 화면 순서 · 역할별 흐름 · 실제 예 · 다른 상황

3 · 어떤 규칙으로 만드나 · AI의 역할 · 요구사항 · 정책 결정 · 지표 · 법무 초안

4 · 어떤 화면으로 만드나 · 유즈케이스 · 화면설계서 · 디자인 시안 · 스타일 가이드 · 접근성

5 · 어디까지 왔나 · 심사 결과 · 검토 반영 · 검증 근거 · 작업 기록

6 · 이전 안 · 원본 · 지금 문서의 바탕이 된 개인별 초안. 최신 내용은 1~5에 있다