012 — RelatedMemoriesPanel prefetch 타이밍
Tier: C (1회차) · 상태: 확정
안건 배경
ADR 0011 Phase 1 S1 착수 전 필요한 micro 결정. 서류 생성 InlineDocGenerate Step 2 (초안 작성) 우측 RelatedMemoriesPanel (비슷한 과거 기억 카드 3~5개) 의 prefetch 타이밍 확정.
대안
- A — Step 1 직후 prefetch (즉시 표시, weight 낭비 리스크)
- B — Step 2 진입 시 skeleton + load (300~800ms 대기)
- C — 캐시 재사용 (24h TTL, hit rate 의존)
R1 의견
P4 디자이너 (B 선호)
Step 2 전환 animation (150250ms) + 초안 첫 문장 타이핑 23초 동안 skeleton 은 주변시로만 감지 → 체감 지연 ~0. A 는 "이 결과가 내 docType 과 맞나" 인지 부조화. C 는 docType 조합 캐시 키 분산으로 hit rate 낮고 drift 위험. 절충: B 로 먼저 배포 → 관찰 → C-lite 추가.
P5 개발자 (C 선호)
weight 2 × 월 30회 상한 × Step 2 이탈 30% = 실사용 15회로 어뷰징 방어선이 기능 차별처럼 오해됨. C 는 dailyBriefings 검증 패턴 재사용 1 eng-day 구현. 캐시 키 tenants/{tid}/relatedMemoriesCache/{caseHash}_{docType} · 24h TTL · legacy_* 3종 이벤트 drift 무효화 · double-checked read 로 중복 차감 방지.
P1 변호사 (B 지지)
Step 2 이탈 20~30% 실무 빈도 맞음. 초안 보고 "이 양식 아니네" 나가는 경우 흔함 → weight 낭비 무시 못 함. 500ms 는 실무 체감 공짜.
확정 스펙 (B 채택 + S3 말 C 재평가)
S1 구현 (즉시 착수 가능)
- 파일:
apps/web/app/(workspace)/cases/[caseId]/_modals/RelatedMemoriesPanel.tsx(신규) - 호출:
InlineDocGenerateStep 2 마운트 시findRelatedMemoriesAction(caseId, docType) - 로딩:
<Skeleton count={3} /> - 성공: 카드 최대 5개 (사건명 · 유사도 · 종결일 · "이 기억 반영" CTA)
- 실패: silent hide (사용자 흐름 방해 금지)
- weight: 2 (
ragSearch, 기존 한도) - 텔레메트리 3종:
related_memories_shown·related_memory_clicked·step2_cancel_before_load
S3 말 (10~13M) C 추가 재평가
다음 모든 조건 충족 시 C 캐시 도입:
- Hit rate 추정 ≥ 40% (동일 case+docType 재조회 비율)
- 월 평균 weight 소비 ≥ 20회/tenant (캐시 절감 가치 존재)
- Step 2 이탈률 ≥ 25% (낭비 방어 의미)
C 도입 시 스펙 (P5 제안 수용):
- 경로:
tenants/{tid}/relatedMemoriesCache/{caseHash}_{docType} - TTL: 24h
- Stale OR: TTL 초과 ·
sourceLegacyIds중 수정·삭제 · 킬 스위치 - 캐시 키 빌더:
lib/cases/brief-cache-key.ts패턴
Minority Report
P5 개발자: "C 를 S1 부터 도입하는 게 weight 경제성 · 지연 · drift 모두 우위. B → C 2-단계 배포는 구현 2회 부담." 처리: S1 시점 hit 데이터 0 → C 캐시 키 설계 근거 약함. 먼저 B 로 관찰 후 근거 있을 때 C 착수. 재평가 시점에 P5 스펙 그대로 채택.
Anti-Goal · 성공 지표 체크
- Anti-Goal 4개 위반 없음
- 측정 지표: 텔레메트리 3종 + S3 말 hit rate / weight 소비 리포트
후속 (파생 안건 없음)
본 결정은 구현 스펙 확정으로 종결. S1 착수 시 바로 구현 진입.