ADR 0060 — 전자소송 모델링 에픽: 접수 메타·제출 브리지·진행 매핑·도메인 확장
- 상태: 채택 (2026-07-01)
- 관련: ADR 0058 (형사 Pack 정식 도입 — 도메인 확장 선례) · case-flow SSoT · 수신 서류 OCR 분류(incoming-doc, PR #3021~)
- 후속: 행정소송 Pack Phase 1 (별도 ADR 예정)
맥락
대한민국 법원 민원업무가 전자소송으로 대체되는 흐름을 반영해, 대표(CEO)가 전자소송의 사건 종류·서류 종류·접수 방식·업무 방식을 모델 삼아 플랫폼 기능을 향상하자는 디스커버리(전자소송흐름.hwp)를 제기했다. 이를 5개 카드로 분해했다: ① 사건 종류 확장 ② 제출 브리지 ③ 전자송달 수신 정합 ④ 사건번호·접수 메타 ⑤ 진행 단계 정합.
핵심 발견 — 코드 전수 검증 시 5개 중 3개가 이미 구축돼 있었다. hwp 도메인 모델링이 코드 미확인 상태로 도출돼 gap 을 과다 계상했다. "검증 후 행동" 원칙을 재확인한 사례:
- ③ 전자송달 수신 = 이미 완성.
functions/src/incoming-doc-classify.ts가 법원 발송 서류 13+종(지급명령·이행권고·화해권고·강제조정·상고기록·약식·보정·판결·결정·소장부본·준비서면/답변서·기일통지·증거신청·감정)을 분류하고,deadlineRuleId→service-deadline.ts10규칙으로 송달기한을 연결하며,IncomingDocClassificationChip/ServiceDeadlineCardUI + calendar-feed 까지 배선돼 있었다. - ② 인지/송달료 계산 = 이미 존재(
LitigationCostCard). 단 정산 탭에만 있어 소장 작성 변호사가 제출 시점에 못 찾는 disconnect 가 진짜 gap 이었다. - ⑤ 진행 단계 = case-flow 6단계(+형사 9phase)로 이미 존재. 카드의 "9단계" 전제가 부정확했다.
결정
전자소송을 법원 절차 관점의 참조 모델로 삼되, 우리 화면 라벨은 사무소 업무 흐름 관점을 유지한다(제품 가치 = "법률 사무소가 관리"). 실제 코드 gap 인 ④ 사건번호 구조화·② 제출 브리지를 구현하고, ⑤는 대응 문서화, ①은 도메인 확장 결정으로 처리한다.
구현
④ 사건번호·접수 메타 정합 (PR #3138)
자유텍스트 courtCaseNumber 를 [법원][연도][사건부호][일련] 로 구조화. apps/web/lib/legal/case-number.ts(순수) 의 CASE_CODE_TABLE(민사·형사·가사·행정·특허)에서 사건부호→분야·심급·재판부를 도출하고, checkCaseNumberConsistency 로 recoveryType 과 분야가 어긋나면 소프트 경고(입력 오류 가드). 미등재 부호는 분야를 추측하지 않고 unknown(fail-safe). CaseNumberMetaChip 이 사건상세 읽기뷰 배지 + 편집 라이브힌트. 기존 미사용 parseCourtCaseNumber 는 위임 통합(정규화 경계 단일화).
부호 테이블은 lex 가 대법원 재판예규 「사건별 부호문자의 부여에 관한 예규」+ 실무 6+ 출처와 대조 검증: 고정 label 교정(약식→정식재판청구), 차전 제거(예규 실재 미확인 → fail-safe), 재/준재 접두 처리, 너(가사조정)/아(행정신청) 대칭 보강.
② 제출 브리지 (PR #3139)
서류 탭에 접이식 FilingBridgeCard 추가 — 소장 작성 후 제출 행동으로 연결. 전자소송 접수 체크리스트(본안·지급명령·보전 3종, _lib/filing-checklist.ts 순수) + 인지/송달료 예상액(litigation-cost.ts SSoT 엔진 read-only 재사용, 계산 중복 0) + 정산 탭 계산기 링크. 형사 미노출(별도 절차)·가사 안내(인지 계산기 비적용).
⑤ 진행 단계 정합 (PR #3140)
case-flow.md 에 전자소송 상태 대응표 문서화 — 4 제출→접수 · 수신서류→송달 · 5 재판→변론 · 6-A 판결→선고 · 6-B/C→확정. 라벨은 통일하지 않는다(사무소 관점 유지). 사건번호 접수 메타(④)·제출 브리지(②)·수신 분류(③)가 전자소송 화면과의 인지 일관성을 보조.
① 사건 종류 확장 → 행정소송 결정 (PR #3141, Phase 1 후속)
현 지원 = 민사 15 + 형사 6. 미지원 = 행정·회생파산·특허·비송. RAG 코퍼스 커버리지를 sync-config(scripts/law-go-kr-categories.ts)로 확정한 뒤(현 코퍼스 = 민사 Pack 1~5 + 형사 + 집행), 우선순위를 도출: ① 행정(수요 중상 + 민사 소장·기한 로직 재사용 마찰 최소 + 제소기간 90일이 기한관리 강점과 정합) > ② 회생파산 > ③ 비송 > ④ 특허. CTO 결정 = 행정소송부터 확장.
안전 슬라이스 먼저(case-creation 흐름 미접촉): 행정 판례 RAG 카테고리 6종 정의(취소소송·무효확인·부작위위법확인·과세처분·정보공개·제재처분, extra tier). 행정 도메인 타입 Phase 1(~12파일 fan-out + create.ts ADMINISTRATIVE 축 + 위저드) 및 docgen·제소기간 로직은 별도 ADR + lex 도메인 검증 갖춘 집중 작업으로.
의도적 제외 / 비목표
- 법원 e-소송(전자소송) API 연동 없음 (Chair 지시) — 사건번호 자동 캡처·실시간 진행 상태 동기화는 미지원. 수동 입력·수신 서류 분류로 추정한다.
- 회생파산·비송·특허 도메인 — 후순위(향후 결정).
근거 메모리
project_electronic_litigation_epic_2026_07_01 — 카드별 상세·fan-out 매핑·행정 Pack 계획.