ADR 0036 — 사건등록 위저드 (3단계, ADR 0035) 후속 개선

날짜: 2026-05-03 상태: Accepted Tier: A (전략·전술 복합 7개 안건) 선행 결정: ADR 0035 (등록 위저드 3단계화 + 도메인별 당사자 라벨 분기) 적용 범위: apps/web/app/(workspace)/cases/new/**, apps/web/lib/cases/schemas.ts, packages/business-logic/src/cases/**, 신규 Firestore 컬렉션 (prefillSnapshots, wizardDraftEvents)

결정문

ADR 0035 의 3단계 위저드 구조 (Step1 회수유형 / Step2 당사자 / Step3 도메인+법원) 를 유지하면서, 7개 후속 결정으로 마찰·학습·관할 안전성 을 동시에 개선한다. ADR 0035 폐기·개정 없음. 즉시 ship 5건 + 데이터 게이트 후속 결정 2건.

배경 — 안건

ADR 0035 ship 직후 7개 결함·기회가 식별됐다.

• A1. AI Prefill confidence 4종 점수가 표시용 노이즈 인지 학습 신호인지 미정 — tenants/{tid}/draftDiffs (ADR 0018) 와 join 안 됨
• A2. 14종 recoveryType 에 라벨 모드가 3종뿐 — 부동산·상속·이전등기 등 실무 호칭 부재
• A3. Step3 가 비-채권 8종에 사실상 법원 1필드만 묻는 빈 화면
• A4. AI Prefill 이 step1 진입 1회만 노출 — 도중 보강 entry 없음
• A5. CaseWizardSuccess 의 다음 액션 CTA 미설계
• A6. localStorage v2 draft 3일 TTL · 단말 종속 한계
• A7. PLAN_LIMIT_EXCEEDED 가 Step3 마지막에 터지는 좌절 + 가정법원/전속관할 분기 누락

5인 회의 (R1 발산 → R2 충돌 → R3 수렴)

R1 은 5인 subagent 병렬 독립 발산. R2 충돌 4건 (A1·A2·A3·A6) 모두 R2 에서 좁혀짐. R3 는 서기 모드 단축.

안건	P1 변호사	P2 사무장	P3 PM	P4 디자이너	P5 개발자	결정
A1	숫자 숨기고 배지	closed loop 필수	보류 → snapshot 즉시 ship	숫자 노출 금지	snapshot 컬렉션 L	텔레메트리 즉시 캡처, UI 1개월 후
A2	5~6종 확장	확장 필수	현행 → 확장 양보	카드 헤더만 라벨	party-labels.ts S	6종 라벨 모드 채택
A3	도메인 필드, 통합 반대	도메인 필드, 통합 반대	Step 통합 → 필드 추가 양보	도메인 필드 + 헤더 desc 변경	discriminated union M	도메인 필드 추가 + 측정 게이트
A4	Step2/3 entry	재호출+메모 보존	entry 찬성	Sparkles+Sheet	dirty flag M	entry 추가 + dirty flag, 메모 세션 한정
A5	증거→포털→서면	위임장→소장→대시보드	서면→포털→일정	사건상세→포털→다른사건	router.push S	사건상세 진입 + 2 secondary CTA
A6	불필요	승격 → 14일 절충	보류 → 14일 + 텔레메트리	복원 dialog	TTL 변경 S	localStorage TTL 14일 + 복원 dialog + 텔레메트리
A7	전속관할 자동분기 양보 불가	사전점검 + 주소→관할	사전점검 P1·관할 P2	잔여량 헤더 warning	Step1 마운트 점검 S	사전 점검 + 전속관할 자동분기

대안 검토 (충돌 핵심 4건만)

A3 — Step3 빈 화면

안	채택	사유
α. ADR 0035 폐기 + Step2~3 통합	❌	PR #1474 progressive disclosure 회귀 (한 화면 8~10필드) · 사무장 통화메모 옮길 때 위치 상실 (P2) · ADR 0035 불과 1일만에 폐기 부담
β. 현행 유지 (법원 1필드)	❌	비-채권 8종 등록 funnel 죽임 (P3) · "법원만 묻는 단계"의 좌절 (P4)
γ. 도메인 필드 1~2개 추가 + Step3 헤더 desc 변경 + 측정 게이트	✅	시효·청구취지 핵심 식별자 (P1) · 위임장 초안 자동 생성에 필수 (P2) · 화면 인지 부담 안 깸 (P4) · schema discriminated union 안전 (P5)

A2 — 라벨 모드

안	채택	사유
α. 현행 3종 유지	❌	P3 가 근거로 든 debt-parity routine 은 H 룰 균형이지 라벨 추적 아님 (정정 후 양보)
β. 14종 1대1 매핑	❌	인지 부담 한계 (P4) · 부동산 입장 분쟁마다 갈려 매핑 불안정 (party-labels.ts 주석)
γ. 6종 라벨 모드 (채권/이혼/부동산-임대/부동산-매매/상속/계약)	✅	변호사·사무장 실무 호칭 일치 (P1·P2) · 매핑 정적 안정 (P5) · 카드 헤더 한정 노출 (P4)

A1 — confidence 학습 루프

안	채택	사유
α. 현행 — confidence 숫자 4종 노출, 학습 연결 없음	❌	노이즈 (P1·P4) · "검증해야 한다" 변호사 부담만
β. 즉시 UI 변경 (숫자 → 시각 신호 3단계)	❌	임계값 근거 데이터 0건 (P4·P5) · 추측 임계값 ship 위험
γ. 텔레메트리만 즉시 ship (UI 동결, 1개월 후 결정)	✅	ship-then-layer (P3) · ADR 0018 draftDiffs 와 동일 컬렉션 모델 (consistency) · 1개월 후 데이터 기반 UI 결정

A6 — draft Firestore 승격

안	채택	사유
α. Firestore 승격 (즉시)	❌	인덱스·보안룰·동시성·삭제 cron 4종 비용 · ADR 0029 fail-loud 정합 위험 (P5)
β. localStorage TTL 3일 → 14일 + 복원 dialog + 텔레메트리	✅	S 비용 · 의뢰인 일주일 공백 케이스 흡수 (P2) · 복원 사용률 데이터 확보 (P3)
γ. 현행 3일 TTL 유지	❌	P2 의뢰인 공백 케이스 무시

결정 — 즉시 ship 큐 (6건, S5 3 분할로 9 PR)

S1. 도메인 필드 추가 + Step3 헤더 desc 변경 (A3)

• 적용 위치: apps/web/app/(workspace)/cases/new/_components/Step3DomainInfo.tsx · apps/web/lib/cases/schemas.ts
• 도메인별 추가 필드 (실제 RECOVERY_TYPE_VALUES 키 기준):
  • divorce — 혼인기간 (시작·종료), 미성년 자녀 유무
  • real-estate-eviction · rent-arrears · title-transfer — 부동산 목적물 주소
  • inheritance-share · inheritance-division — 피상속인 성명, 사망일
  • unjust-enrichment · contract-damages — 계약일, 계약 종류
• Step3 헤더 desc: "관할법원 + 핵심 정보"
• schema 분리: apps/web/lib/cases/step3-schema.ts 단일 파일로 추출 (Step3BaseSchema + makeStep3Schema). Pack 별 분리는 후속 PR (도메인 필드 단순화로 본 PR 에선 통합).
• 비용: M
• Ship 결과: PR #1484 (2026-05-03)

S2. 6종 라벨 모드 확장 (A2)

• 적용 위치: apps/web/app/(workspace)/cases/new/_lib/party-labels.ts
• 매핑 (실제 RECOVERY_TYPE_VALUES 키 기준):

  채권 6 종 (debt·construction·subrogation·agreement·lease-deposit·assigned)
                                       → 채권자 / 채무자 (현행 유지)
  divorce                              → 의뢰인 / 배우자 (현행 유지)
  real-estate-eviction · rent-arrears  → 임대인 / 임차인
  title-transfer                       → 매도인 / 매수인
  inheritance-share · inheritance-division → 의뢰인 / 공동상속인
  unjust-enrichment · contract-damages → 의뢰인 / 상대방 (현행 유지)

• 카드 헤더에만 라벨, 입력 필드 통일 (P4)
• schema 검증 메시지는 도메인 중립 ("의뢰인/상대방") 유지 (P5 양보 불가)
• 비용: S
• Ship 결과: PR #1478 (2026-05-03)

S3. AI Prefill 텔레메트리 캡처 (A1) — Ship 단계 결정 변경

원안: 신규 컬렉션 tenants/{tid}/prefillSnapshots/{draftUUID} 신설.

Ship 단계 변경: ADR 작성 시 tenants/{tid}/casePrefillRuns/{runId} 인프라가 이미 존재하는 것을 미처 반영하지 못함. 동일 목적·스키마 (PII 무전파 + confidence

• caseId + recordedBy + recordedAt) — 중복 컬렉션 신설 비용 (인덱스·보안룰·reconcile 로직 L) vs 기존 인프라 확장 (S) 트레이드오프 끝에 기존 흡수 채택.

확장 내용:

• casePrefillRuns 페이로드에 finalizerRole: "owner" | "staff" | null 추가 (P2 사무장 vs 변호사 finalize 분리)
• 스푸핑 차단: 클라이언트 input 무시, 서버가 session.role 로 덮어씀
• ADR 0018 tenants/{tid}/draftDiffs 와 join (caseId 키, 기존 동일)

draftUUID 별도 추적·신규 컬렉션 신설은 1 개월 후 결정 (Minority M3 게이트와 동일 시점 — casePrefillRuns 데이터 ≥ 100 건 + finalizerRole 분포 분석).

• UI 변경 없음 — 1 개월 후 confidence calibration 데이터 보고 결정 (P3·P4)
• 비용: S (실측, 기존 인프라 확장)
• Ship 결과: PR #1485 (2026-05-03)

S4. AI Prefill 재호출 entry + dirty flag (A4)

• 적용 위치: CaseWizardPage 헤더 우측 Sparkle 버튼 → Dialog (Sheet 컴포넌트 apps/web 미존재로 Dialog 채택, 시각적 영향 동등)
• 재호출 시 field-level dirty flag 검사: 정식 step1/2/3 데이터의 비어있지 않은 필드는 새 prefill 에서 제거 (mergePreservingFinalized 헬퍼)
• 통화메모 원문은 세션 한정 메모리 보관 (Firestore·localStorage 저장 금지, P5 PII 정책)
• 사건 상세 attached note 보존은 별도 안건 (후속)
• 비용: M
• Ship 결과: PR #1483 (2026-05-03)

S5. localStorage TTL 14일 + 복원 dialog + 텔레메트리 (A6) + 한도 사전 점검 + 전속관할 자동분기 (A7)

S5a. localStorage v3 마이그

• apps/web/app/(workspace)/cases/new/_lib/wizardContext.tsx:
  • STORAGE_KEY = "case-wizard-draft-v3" · v0·v2 legacy 키 발견 시 폐기
  • DRAFT_TTL_MS = 14 * 86_400_000
• 복원 시 자동 → 명시 dialog ("X 분/시간/일 전 작성 내용 발견. 이어쓰기 / 새로 시작")
• 신규 텔레메트리 컬렉션 tenants/{tid}/wizardDraftEvents/{ts} — Ship 단계 보류 (S3 와 동일 패턴 — 데이터 누적 가치 입증 후 결정)
• Ship 결과: PR #1481 (2026-05-03)

S5b. PLAN_LIMIT_EXCEEDED 사전 점검

• AiPrefillCard 마운트 시 getAssistQuotaForWizardAction 1 회 호출 (단순 read-only)
• 한도 임박 (≥ 90 %) 시 헤더 잔여량 text-amber-600 (P4 시맨틱)
• 한도 초과 시 AiPrefillCard textarea·button disabled + "AI 없이 수동 입력" 안내 카드
• Ship 결과: PR #1482 (2026-05-03)

S5c. 전속관할 자동분기 (P1 양보 불가)

• apps/web/app/(workspace)/cases/new/_lib/wizardConfig.ts:

  • 부동산 (eviction·rent-arrears·title-transfer) → 부동산 소재지 지방법원 (민소법 §20) — 가정법원 선택 시 error
  • 가사 (divorce·inheritance-share·inheritance-division) → 가정법원 (가소법 §22) — 일반 지법 선택 시 error
  • 부동산 사건 + 일반 지법 → warning (소재지 일치 확인 필요)

• FAMILY_COURTS set (가정법원 8 개) O(1) 조회

• Ship 결과: PR #1480 (2026-05-03)

• 비용: S5a M / S5b S / S5c S = 합 M

S6. 등록 후 CTA (A5) — Success 화면 재설계

• 적용 위치: apps/web/app/(workspace)/cases/new/_components/CaseWizardSuccess.tsx
• Primary CTA (큰 버튼): 사건 상세로 이동 (router.push(/cases/${caseId}))
• Secondary CTA (grid 2x1): ① 위임장 만들기 ② 포털 발급 (?openPortal=1 → CaseDetailClient open-portal-link-dialog 이벤트 dispatch)
• Ghost CTA: "새 사건 등록" (P2 사무장 연속 등록 시나리오)
• 14종별 CTA 분기 없음 (사건 상세 4패널이 도메인 분기 흡수, P3·P5)
• 비용: S
• Ship 결과: PR #1479 (2026-05-03)

측정 가능한 성공 지표

지표	목표	측정 방법
비-채권 8종 사건 등록 완료율	≥ 70%	caseCreated / wizardStarted (recoveryType 필터)
채권 6종 등록 완료율	회귀 없음 (현재 ±5%)	동일
AI Prefill 재호출 빈도	≥ 10% (Step2/3 진입 사건 중)	AiPrefillReentryButton 호출 → casePrefillRuns 의 동일 caseId 중복 (또는 별도 로그)
localStorage 14일 draft 복원 사용률	5% ~ 30%	클라이언트 텔레메트리 (별도 컬렉션 보류 — S3 패턴)
한도 사전 점검 → 등록 완료 비율	한도 임박 사용자 ≥ 80%	aiAssists 카운터 ≥ 90 % 사용자의 caseCreated
전속관할 자동분기 적용 사건 비율	부동산·가사 사건의 ≥ 95%	wizardConfig.ts checkCourtJurisdiction 결과 로그
confidence ↔ diff calibration 데이터	1 개월 후 casePrefillRuns ≥ 100 건 + finalizerRole 분포 분석	casePrefillRuns 집계 (기존 컬렉션, S3 흡수)

적용 범위 (코드 위치)

• ✅ apps/web/app/(workspace)/cases/new/_components/Step3DomainInfo.tsx (S1·S5c)
• ✅ apps/web/lib/cases/schemas.ts + apps/web/lib/cases/step3-schema.ts 신규 (S1, 200 줄 mandate 회피)
• ✅ apps/web/app/(workspace)/cases/new/_lib/party-labels.ts (S2)
• ✅ apps/web/app/(workspace)/cases/new/_lib/wizardContext.tsx (S4·S5a)
• ✅ apps/web/app/(workspace)/cases/new/_lib/wizardConfig.ts (S5c — checkCourtJurisdiction + FAMILY_COURTS)
• ✅ apps/web/app/(workspace)/cases/new/_components/AiPrefillCard.tsx (S5b)
• ✅ apps/web/app/(workspace)/cases/new/_components/AiPrefillReentryButton.tsx 신규 (S4)
• ✅ apps/web/app/(workspace)/cases/new/_components/CaseWizardSuccess.tsx (S6)
• ✅ apps/web/app/(workspace)/cases/[caseId]/_components/CaseDetailClient.tsx — ?openPortal=1 자동 dialog (S6)
• ✅ apps/web/app/(workspace)/cases/_actions/get-assist-quota-action.ts 신규 (S5b)
• ✅ apps/web/app/(workspace)/cases/_actions/record-case-prefill-accuracy-action.ts — finalizerRole 추가 (S3)
• ✅ apps/web/types/case.ts + apps/web/app/(workspace)/cases/_lib/schemas.ts — CasePayload + CasePayloadSchema 8 도메인 필드 (S1)
• ✅ apps/web/app/(workspace)/cases/_actions/case-create-actions.ts — createCase 호출에 8 필드 전달 (S1, ADR 0028 정합)
• ✅ packages/business-logic/src/cases/create.ts — CreateCaseInputSchema + casesCol.add stamp (S1)
• ⚠️ Firestore 보안룰 — 신규 컬렉션 신설 보류 (S3 → 기존 casePrefillRuns 흡수)
• ⚠️ Firestore 인덱스 — 동일 (신규 컬렉션 없음)

Minority Report (반대의견)

M1. P2 사무장 — A6 Firestore 승격 보류 결정

"의뢰인 일주일 공백 케이스가 흔하다. 14일 TTL 도 PC 바꾸거나 캐시 비우면 날아가는 건 동일. 사무장이 처음부터 다시 옮겨 적게 됨."

• 현재 결정: localStorage 14일 절충
• 흡수 조건: S5a 텔레메트리 (wizardDraftEvents.restored 사용률) 가 30% 초과 시 Firestore 승격 재검토
• 위험: 14일 후 draft 잃은 사용자가 등록 자체 포기하는 silent churn

M2. P5 개발자 — A2 부당이득 라벨 "원고/피고" 통일 vs P1 "반환청구인/수령자"

"부당이득은 법원 표준 용어가 아닌 '반환청구인/수령자'보다 '원고/피고' 통일이 더 명확."

• 현재 결정: 계약 2종 (contract-damages · contract-unjust) 모두 "의뢰인/상대방" 현행 유지
• 흡수 조건: P1 이 부당이득 사건 등록 시 라벨 마찰 호소 시 재검토
• 위험: 실무 변호사가 "원고/피고" 카드를 보고도 입장 혼동 (낮음)

M3. P3 PM — A3 측정 게이트의 의미

"비-채권 8종 등록 완료율 < 70% 시 Step 통합 재검토. 도메인 필드 추가가 funnel 회복에 충분한가는 ship 후에야 알 수 있음."

• 현재 결정: 도메인 필드 추가 채택, Step 통합 보류
• 흡수 조건: S1 ship 후 1개월 funnel 데이터 < 70% 시 ADR 0035 개정 재검토
• 위험: 1개월 추가 churn 발생

후속 과제

• S1 (도메인 필드): 본 ADR 의 ship 큐로 통합 ship (Pack 별 분리 후속 단순화 — 도메인 필드 자체가 작음)
• S3 (텔레메트리): 기존 casePrefillRuns 흡수, ADR 0018 draftDiffs 와 caseId join 패턴 동일
• S5c (전속관할) — 행정구역 → 관할법원 매핑 ADR: 대법원 관할구역표 기반 데이터 수집 + 별도 ADR (연 1 회 검토)
• A4 통화메모 attached note 보존 — PII 정책 + 사건 상세 컬렉션 영향 별도 회의 안건
• 보전처분 (가압류·가처분) 등록 경로 — P1 R2 신규 질문, 현재 위저드 본안 전제 유지, 사건 상세 → "관련 사건 추가" 경로 별도 안건
• 모바일 ProgressBar sticky 처리 — P4 polish 큐 (모바일 1~5 % 시나리오)
• 1 개월 후 (≈ 2026-06-03) confidence UI 결정 회의 — casePrefillRuns 데이터 ≥ 100 건 + finalizerRole 분포 분석 → P4 시각 신호 3 단계 ship 여부 결정 (Minority M3 게이트와 동일 시점)
• draft Firestore 승격 재검토 — wizardDraftEvents 텔레메트리 누적 사용률 5~30 % 범위 벗어나면 결정 (Minority M1)

변경 이력

버전	날짜	변경
1.0	2026-05-03	초안 — 5인 회의 R1·R2·R3 결과. 7개 안건 즉시 ship 5건 + Minority 3건
1.1	2026-05-03	정정 — (1) recoveryType 키 매핑 실제 RECOVERY_TYPE_VALUES 기준으로 통일 (rent-arrears·title-transfer·unjust-enrichment). (2) S3 결정 변경 — 신규 prefillSnapshots 컬렉션 보류, 기존 casePrefillRuns 에 finalizerRole 추가로 흡수 (인프라 중복 회피). (3) 9 PR ship 결과 (#1477~#1485) 각 ship 큐에 명시. (4) 적용 범위 코드 경로 실제 ship 파일 기준으로 갱신