제품 성공 기준과 핵심 메트릭 정의

[ceal-agent]

배경

2026-05-20 Daily Scrum 메모에서, 파운데이션 모델 기반 제품은 초기 데모 이후 제품화까지 마지막 품질을 끌어올리는 데 긴 시간이 걸리며, 제품별 성공 기준과 평가 체계를 명확히 해야 한다는 문제의식이 나왔습니다.

목표

이 제품의 성공 기준을 정량/정성 양쪽에서 정의하고, 실제로 추적할 핵심 메트릭을 합의합니다.

할 일

• 이 제품의 주요 사용자/사용 맥락을 1차로 정리한다.
• 제품이 성공했다고 말할 수 있는 정성적 기준을 정의한다.
• 제품/비즈니스/운영 관점의 정량 메트릭 후보를 정리한다.
• AI 품질 평가 메트릭이 필요한 경우, 사용자 가치 메트릭과 어떻게 연결되는지 정의한다.
• 지금 바로 계측 가능한 것과 추가 구현이 필요한 것을 구분한다.
• 최소 1개 이상의 주간/월간 리뷰 루프를 제안한다.

산출물

• 성공 기준 1페이지 요약
• 핵심 메트릭 목록과 정의
• 현재 계측 가능 여부 및 다음 액션

참고

• 요청 출처: Slack Daily Scrum thread, 2026-05-20

Source context

Original Slack thread: slack://C05J5LTFSCU/1778805288.184149
Source identity: slack://C05J5LTFSCU/1778805288.184149
Access mode: Ceal local mirror; run 'ceal slack thread fetch 1778805288.184149 --json' from the source thread, and use 'ceal slack thread backfill 1778805288.184149 --json' first if provider completeness matters.
Freshness: captured from the active Ceal turn at issue creation time; re-read the source before resolving.

_{requested via ceal · ceal-agent[bot]}

[spilist]

진행 업데이트:

• 제품 성공 기준/메트릭 기준선을 docs/product-success-metrics.md에 추가했습니다.
• Slack 원문은 현재 런타임에서 ceal이 없어 재확인하지 못했기 때문에, 문서는 GitHub 이슈 본문과 현재 repo 증거에 근거한 working baseline으로 명시했습니다.
• usage-episode vocabulary baseline도 같은 문서에 정리했고, .agents/usage-episodes-adapter.yaml은 runtime emitter가 없으므로 계속 enabled:false로 둡니다.
• 관련 AI/ML 엔지니어링 조사와 첫 후속 액션은 docs/ai-ml-engineering-patterns.md 및 #188에 분리했습니다.
• 커밋: 0d1775c (Document product success metrics baseline)

이 이슈의 “합의된 숫자 목표/최종 우선순위”는 아직 human/product decision이라 닫지 않습니다.

[spilist]

1차 조사 메모 (#185 / #184 동반). 본 ideation 세션 전에 현재 charness 상태와 갭을 짧게 정리. 본격적인 ideation/spec은 별도 세션에서.

현재 charness 상태 (5개 범위)

• 평가/evaluation: Cautilus subagent-spawning skill-clone evaluator + deterministic quality gates 65개 + Cosmic Ray Python mutation + StrykerJS slice. 인프라 강함. 갭: human eval loop, LLM-as-judge, 실패 사례 카탈로그(retro는 lesson-digest이지 fail-catalog 아님).
• 실험/iteration: ideation→spec→impl 단계 분리, retro 루프, deferred-decisions 카탈로그. 갭: prompt/model/skill 변경의 before/after를 git commit + retro에 의존, 체계적 실험 기록 인프라는 약함.
• 데이터/피드백: usage-episodes(현재 disabled), t-events, session-capture, retro selection-index. 인프라 자리는 마련. 갭: 사용 데이터→품질 개선 루프가 단절(usage-episodes disabled), 라벨링/feedback 루프 없음.
• 운영/관측성: runtime budgets, attention-state-visibility, agent_browser_runtime_guard. 잘함. 갭: incident review/postmortem 프로세스가 retro와 별개로 정의되지 않음.
• 품질/엔지니어링: pre-push hook, 65-pass 게이트, mutation, deferred-decisions. 매우 강함. 갭: 비즈니스/사용자 가치 지표 연결(제품 성공 기준과 핵심 메트릭 정의 #184 본질).

#184 1차 정리 (성공 기준/메트릭)

• 사용자/맥락: (a) AI 코딩 에이전트 사용자(코딩 task 위임), (b) 메인테이너(skill/integration 작성자).
• 정성 기준 후보: 새 task마다 charness 도구가 더 명확한 다음 행동을 제시 / 같은 종류의 실수가 반복되지 않음 / host 변경(모델 교체 등)에 빠르게 적응 / 다른 repo에 portable 적용 가능.
• 정량 후보:
  • 즉시 계측 가능: deterministic gate latency(runtime-signals.json), mutation score(bot), issue lifecycle(gh API), retro 반복 trap 누적, deferred-decisions 부채 카운트.
  • 추가 구현 필요: 'symptom→root-cause shift' 비율(예: 오늘 Add deterministic post-mutation sync gate (close mutate→sync→verify barrier) #197), charness:* 사용 빈도(host telemetry 의존), 'time-to-first-skill'(onboarding 텔레메트리).
• 리뷰 루프 제안: Weekly retro+deferred 검토, Monthly skill 사용·gate latency·mutation score trend, Quarterly RCA discipline 효과 review.

상위 3 개선안 (난이도 대비 효과)

1. 'symptom→root-cause shift' 카운터(저난이도/고효과): retro 또는 issue closeout에 한 줄 필드. 오늘 Add deterministic post-mutation sync gate (close mutate→sync→verify barrier) #197 사례(downstream test failure → validate-packaging root-cause message 명명)를 자동 누적해 RCA 문화의 지표화.
2. LLM-as-judge eval via Cautilus skill-experiment(중난이도/고효과): 이미 있는 subagent-spawning evaluator 위에 prompt/skill 변경의 사용자 가치 회귀를 자동화.
3. usage-episodes adapter 활성화 결정(중난이도/고효과): vocabulary와 schema 정의가 1차 차단. 활성화하면 사용자 피드백 루프의 입구가 열림.

후속 액션

• 별도 ideation 세션을 잡아 1번부터 spec 진입(가장 작고 즉시 값을 보여줌).
• 제품 성공 기준과 핵심 메트릭 정의 #184 메트릭 정의는 1번과 함께 진행(symptom→root-cause shift가 첫 메트릭 후보).
• #185는 1번 이후 2/3번 중 선택해 후속 이슈로 쪼갬.

---

_{requested via charness · 자율 처리 세션 1차 메모; ideation은 다음 세션}

[spilist]

논의 결과 — 단일 north-star 확정 (2026-05-24)

이전 baseline(docs/product-success-metrics.md)은 메트릭 7개를 정의했지만 단일 objective가 없었습니다. 이번 ideation 세션에서 그 human decision을 확정했습니다.

확정 결정

1. 단일 north-star = 반복실수→학습 전환율: RCA 이벤트(버그·반복 교정·weak-proof finding)가 재발 방지 durable 산출물(deterministic gate / spec / test / 추적 issue / detection gap·sibling pattern을 명시한 retro lesson)로 전환되는 비율. 나머지 6개 메트릭은 monitored dashboard로 분리(optimize 대상 아님; Google Rules of ML).
2. 첫 계측 = symptom→root-cause shift 카운터: 고정 스키마 ledger charness-artifacts/metrics/rca-ledger.jsonl에 debug/issue/retro closeout 시점에 append. 전환율 = converted / 전체 RCA 이벤트, source·event_kind별 분해.
3. 숫자 목표 = baseline-first: 2~4주 ledger 관측 후 현실적 target 확정. 지금 추측 숫자 안 잡음.
4. Scope = charness self-dev dogfood 우선: consumer repo 계측은 usage-episode capture 활성화에 의존 → 별도 deferred decision으로 유지.

문서 반영: docs/product-success-metrics.md에 "Single North-Star Objective" 섹션 추가.

다음 단계: ledger 스키마 + append 규약 + 집계 스크립트 + review loop 연결은 #185에서 spec 구현 계약으로 작성.

이 이슈를 닫지 않는 이유: 숫자 목표가 baseline-first라 합의된 target은 2~4주 데이터 후의 human decision으로 남습니다.

---

_{requested via charness · ideation 세션 결정 기록}