결론부터.
(1) canonical_doc_id 추가·매핑 — 지금 가능합니다. 단, 컬럼 추가만 안전 / 행 삭제는 금지
현재 스키마 (LAX-site/migrations/0044_legal_doc_catalog_full_civil.sql):
legal_doc_catalog: PKid(AUTOINCREMENT),UNIQUE(tab, proc, doc_name). canonical 컬럼 없음 — 같은 서식이 tab/proc/feature_group별로 별도 행으로 쪼개져 적재됨.- 라이브 prod(
lax-prod, ICN) 실측: 총 2,062행 / 고유 doc_name 853개. 다중적재 서식 368종이 1,577행을 차지(= 통합 시 1,209행이 중복으로 흡수됨).
A그룹 실측 단편화 (prod 직접 조회):
| 서식 | 적재 행수 | 분산된 tab/proc |
|---|---|---|
| 보정서 | 19 | 가사·민사·민사집행·특허·행정·회생파산 전반 |
| 소송위임장 | 15 | 〃 |
| 사실조회 촉탁신청서 | 15 | 〃 |
| 신청취하서 | 16 | 〃 |
| 주소보정서(특별/공시/일반송달) | 12 | 〃 |
| 기일변경신청서 | 10 | 〃 |
| 증인신청서 | 5 | 가사·민사·특허·행정·형사 |
| 예납금납입 보정서 | 5 | 회생파산 5분야 |
| 판결경정신청서 | 5 | 가사·민사·특허·행정·형사 |
| 서증 / 소취하서 | 각 4 | — |
작업 방식·소요: 신규 마이그레이션(0062)으로 canonical_doc_id INTEGER nullable 컬럼 추가 + UPDATE 백필 한 번. 컬럼 추가는 가산적(additive)이라 작고 안전 — 마이그레이션 1턴 분량. 적용·prod 반영은 손석구(데몬/마이그레이션 적용) 경로.
리스크 3가지:
- FK 캐스케이드(가장 큼) —
user_doc_selections.doc_id → legal_doc_catalog(id) ON DELETE CASCADE(0051). 통합한다고 비-canonical 중복행을 삭제하면 사용자 핀 선택이 같이 날아간다. → 행은 보존하고 canonical_doc_id로 묶기만 할 것. 정 삭제하려면 선택 레코드를 canonical로 먼저 재지정 후 삭제. - 과병합 위험 — 비슷한 이름은 별개 서식. 예:
소취하서/소취하동의서/소취하부동의서(각 4행)는 다른 서면,서증/서증인부서도 별개,사실조회 촉탁신청서vs사실조회 회신서도 별개. doc_name 정규화 규칙을 사람이 검수해야 함(자동 LIKE 병합 금지). - canonical 대표행 선정 규칙 필요 — 그룹마다 어느 id를 대표로 할지(최소 id 또는 민사·본안 우선 등) 명문화.
(2) 매핑 후 자산 개수 확인 — 가능합니다 (COUNT(DISTINCT canonical_doc_id))
매핑이 끝나면 SELECT COUNT(DISTINCT canonical_doc_id) 한 줄로 통합 자산 단위 수를 즉시 확인 가능. A그룹 10개 패밀리는 위 표 기준 약 110여 행 → canonical 자산 약 10~14개로 수렴(소취하·서증 변형을 별개로 둘지에 따라 ±).
단, 주의 — "184" 출처 미확인: '자주 찾는 184개'라는 수치는 LAX brain·LAX-site 어디에도 기록이 없습니다(log.md·wiki·온보딩 코드 전수 확인). 온보딩 풀(in_scope != 'excluded')은 184가 아니라 전체 2,062행, core 9 / core+conditional 46으로, 184와 일치하는 정의가 코드/DB에 없음. 따라서 "184 → N개로 정리" 검증은 184의 정의가 어디서 나온 수치인지 먼저 확정해야 분모를 맞출 수 있습니다 — 그 정의만 주시면 매핑 후 정확한 자산 수를 바로 산출·확인해 드립니다. (현재로선 184는 근거 없음.)
출처: LAX-site/migrations/0044·0051_*.sql, src/app/onboarding/routes.tsx, prod D1 lax-prod 직접 조회.