사실관계와 법리검토

전처리가 끝나면 사실관계 구조화(②)와 법리 검토(③)가 이어집니다. 둘 사이와 뒤에 변호사 검수 게이트가 들어가는, 파이프라인의 중심 단계입니다.

② 사실관계 구조화

fact-agent가 fact-extractor로 추출된 텍스트에서 사실을 구조화합니다. 출처 없는 사실은 무효입니다.

추출 항목과 정규화:

항목	정규화
날짜와 시각	YYYY-MM-DD HH:MM
당사자	원고, 피고, 피해자, 피의자, 채권자, 채무자 + 이름
금액	숫자 + 단위 + 맥락
장소	구체 주소나 지명
행위와 사실	육하원칙 한 문장
출처	[자료N, p.X]나 [메시지ID] (필수)

결과는 facts.json으로 떨어집니다. 자료 간 모순도 탐지합니다. 같은 사실이 자료마다 다르게 적혀 있으면 모순으로 표시합니다.

5시트 사실관계 보고서

fact-report-builder가 facts.json을 변호사 검토용 엑셀로 렌더합니다. 번들 스크립트로 결정적으로 생성합니다.

python3 {skill_dir}/scripts/build_report.py \
  {case_dir}/01_분석결과/facts.json \
  {case_dir}/01_분석결과/사실관계보고서_{날짜}.xlsx

다섯 시트는 타임라인, 자료목록, 사실목록, 모순보고, 검증결과입니다. 모순과 추정 행은 자동으로 하이라이트되고, 변호사 입력 컬럼이 들어 있습니다. 원본 대조가 필요한 건수(original_check_flagged)를 사용자에게 보고합니다.

검수 게이트 1

②가 끝나면 변호사 검수입니다. 모순과 추정을 확인하는 자리입니다. 사용자가 “확인했어”라고 하기 전에는 ③으로 넘기지 않습니다. AI는 검수를 대행하지 않습니다.

③ 법리 검토

legal-research-agent가 legal-review-ko로 facts.json에서 쟁점을 도출하고 법령과 판례를 검색합니다. 이 단계의 골격은 모든 인용을 공식 API로 교차검증한다는 것입니다(네 번째 원칙).

다층 검증 파이프라인:

1. 구조 검증 — 인용 포맷이 유효한지(사건번호, 조문번호 형식)
2. 내용 검증 — korean-law-mcp나 법제처 API로 실존 확인. 검증에 쓴 도구명을 반드시 기재. 없으면 무효
3. 논리 검증 — distinguish. 본 사건과 판례의 유사점, 차이점, 적용 가능성을 작성

korean-law-mcp는 법령, 판례, 행정규칙, 헌재결정을 검색하고, 조문 영향 그래프와 시점 비교를 제공합니다. 약칭을 자동 인식하고 조문번호를 변환합니다.

결과는 법리검토 Word 문서와 인용검증 JSON으로 떨어집니다.

API 키가 없을 때 Mock 모드

법제처 API 키(LAW_GO_KR_OC)가 없으면 Mock 모드로 돕니다. 검색을 실행하지 않고, 모든 인용을 [검증 미완: API 미연동]으로 표시합니다. 검증 안 된 인용을 검증된 것처럼 출력하지 않습니다.

이 자리가 중요합니다. 변호사가 검증 안 된 인용을 그대로 서면에 쓰면 신뢰 실패로 이어집니다. 키 발급 전에는 모든 인용이 [검증 미완] 태그를 달고 나오니, 실제로 쓰기 전에 키를 발급받아 다시 검증합니다. 키 발급 자리는 설치와 설정에 있습니다.

검수 게이트 2

③이 끝나면 변호사 검수입니다. 인용을 재확인하는 자리입니다. AI가 교차검증을 했어도, 본 사건에 적용 가능한지의 최종 판단은 변호사 몫입니다. 사용자 확인 전에는 ④로 넘기지 않습니다.

다음

사실과 법리가 검수를 통과하면 검수와 서면으로 갑니다. 산출물을 QA하고 검수 패키지를 조립하는 자리입니다.