현재 MVP 2종(소장·지급명령신청서) → 전체 서면으로 확장하기 위한 데이터 설계 · 박보검(Chief of Staff) 합성 · 2026-06-22
문서만 모으면 출력 흉내는 되지만 '왜 그 사실이 그 문장이 됐는지'를 못 배운다. 사건 풀기록 단위로 모아야 사실추출 엔진이 학습된다.
| 출처 | 역할 | 비고 |
|---|---|---|
| 재단 기존 사건기록 | 정답 본체 — 입력증거 + 제출서면을 둘 다 보유 | 정형·반복 서면의 핵심 공급원. 1순위 확보 대상 |
| 법원 공식 양식·별지 | 출력 템플릿/골격 — 신청서류는 양식이 곧 정답에 근접 | 변동폭 작음. 즉시 디지털화 가능 |
| 공개 판결문 | 작성대상 아님 — 청구취지↔주문 정합성 검증용 참조 | 가명처리 경로(2026-06-20 결정)와 연동 |
소장★ · 지급명령신청서★ · 구상채권 산정표 · 주소보정서 · 집행 4종(채권압류추심/전부·재산명시·재산조회·채무불이행자명부) · 확정/송달/집행문 증명
구상금 사건 물량 대부분이 소장→지급명령→채권압류추심의 정형 라인에 몰림. 이 라인만으로 자동화 효과의 다수를 흡수. 여기서 데이터셋 구축 시작.
가압류신청서 · 사실조회신청서 · 공시송달 · 청구취지·원인 변경 · 증거신청/서증목록 · 부동산 강제경매 · 배당요구
재단 기록에 존재하나 사건별 변동 ↑ → 정답 라벨링에 변호사 검수 비중을 높여야 함.
준비서면(원고) · 조정/화해 의견서
사건별 사실관계·항변에 종속 + 공개 판결문에 본문 미수록 → 정답 확보 최난. 정답 부족을 전제로 증거표 + 항변 매핑 기반 반구조화 생성으로 접근. 후속서면 결정(2026-06-20, 소장 작업대 재사용)과 직결.
검증(verified)의 정의 = 재단 실제 제출본 + 변호사 검수 완료 = ground truth. ⑥ 회귀셋은 모델 변경 시 품질 후퇴 감시용으로 학습셋과 분리 보관.
데이터 스키마(안): 사건ID → { 증거원본[], 추출사실라벨{}, 단계별제출서면[], 검수자, 검수일, 가명처리여부 }
위 3건은 비가역/대외 협의 사안이라 내 선에서 정하지 않고 옵션으로 올림.