KorLawChestra를 통째로 들이지 않고, 판례 해설 핵심만 이식한 사례

검증 범위

• ✅ 업스트림 커밋·라이선스·선택 범위를 해시로 고정했다.

• ✅ 독립 구현한 어댑터를 합성 판결문 fixture로 실제 실행했다.

• ✅ 신규 테스트 7개와 기존 코어 회귀 테스트 23개·4개를 다시 통과했다.

• 🟡 실행과 기계 검증은 통과했지만 법률 내용 검토는 BLOCKED다.

• ❌ 실제 판결문 canary, 행위시법 검토, 독립 법률심사, 사람 승인, 운영 배포는 하지 않았다.

• ❌ 생성된 판례 해설보고서는 외부 공개나 법률적 의존이 허용되지 않는다.

이 글의 Library 발행은 구현 사례를 기록하는 것이다. 합성 판례 해설보고서를 법률 자료로 승격하는 발행과는 다르다.

🧭 한 줄 요약

KorLawChestra의 전체 앱과 코드를 가져오는 대신, 출처 snapshot·정확한 locator·fail-closed Gate·불변 receipt라는 네 가지 행동만 기존 case-bundle-1 체계에 독립 구현으로 연결했다.

🔗 앞선 사례와 이번 사례의 차이

앞선 사례는 KorLawChestra 원형을 직접 실행하면서 “보고서 생성 완료”와 “법률적으로 믿어도 됨”을 분리해야 한다는 문제를 다뤘다.

이번 글은 그 다음 단계다. 원형을 평가하는 데서 멈추지 않고, 무엇을 내부 시스템에 남기고 무엇을 버렸는지, 그리고 그 경계를 실제 코드와 테스트로 어떻게 고정했는지를 기록한다. 두 글은 같은 프로젝트를 다루지만 산출물과 판단 시점이 다른 별도 사례다.

🚧 왜 전체 프로젝트를 그대로 편입하지 않았나

KorLawChestra는 판례 입력부터 분석·검토·보고서 생성까지 이어지는 구조를 보여준다. 그러나 내부 시스템에 그대로 넣기에는 세 가지 충돌이 있었다.

첫째, 업스트림은 CC BY-NC 4.0이다. 내부의 상업적 활용 가능 경로에 Python·prompt·runtime을 복사하는 방식은 허용 범위를 별도로 판단해야 한다. 이번 작업은 그 판단을 우회하지 않고, 업스트림을 행동 참고면으로만 고정한 뒤 독립 구현했다.

둘째, 내부에는 이미 판례 원본·심급·주장·증거·판단·반사실 경로를 다루는 case-bundle-1 계약이 있다. 새 앱이 별도 canonical을 만들면 같은 사건에 두 개의 진실 원장이 생긴다.

셋째, 동적 planner가 단계를 생략하거나 생산자가 자기 결과를 다시 고쳐 스스로 PASS시키는 흐름은 법률 검토 Gate와 맞지 않았다. 빠른 완성보다 빠진 검증을 빠진 상태로 보존하는 것이 더 중요했다.

🧩 가져온 것은 기능이 아니라 네 개의 계약이었다

그림 1. source manifest와 runtime contract에서 생성한 선별 이식 경계 카드. 업스트림 전체 앱이 아니라 네 개의 행동 계약만 선택했다.

1. 출처 snapshot

입력 원문의 상대경로·bytes·SHA-256을 확인한 뒤 실행 디렉터리에 snapshot을 남긴다. 경로가 source root 밖으로 벗어나거나 symlink를 거치거나 해시가 다르면 보고서 생성으로 넘어가지 않는다.

2. E0/E1 exact locator

판결문에 직접 근거한다고 표시한 사실·주장·증거·판단은 source_id, 문자 범위, 정확 인용문을 함께 가져야 한다. 인용문과 원문 범위가 한 글자라도 다르면 기계 검증은 실패한다.

3. fail-closed Gate

누락을 빈칸으로 덮지 않는다. 직접 명제에 locator가 없으면 BLOCKED, 원문 hash나 인용 범위가 틀리면 FAIL이다. 업스트림 메타데이터가 passed=true라고 말해도 이 Gate를 건너뛸 수 없다.

4. manifest와 receipt

보고서의 hash는 manifest에 기록되고, receipt가 manifest와 report의 hash를 함께 참조하는 단방향 체인으로 결속된다. manifest에는 receipt_included=false를 명시해 순환 결속으로 과장하지 않는다. 같은 run_id로 다시 쓰려고 하면 첫 실행 산출물을 보존하고 충돌을 차단한다. 사람 승인처럼 보이는 필드가 입력에 있어도, 검토 대상 hash와 정식 승인 절차가 결속되지 않으면 의존 가능 상태로 승격하지 않는다.

🧱 명시적으로 가져오지 않은 것

• 업스트림 Python·prompt·runtime

• 동적 LLM planner와 replanner

• 자동 섹션 재작성과 생산자의 자체 PASS

• 판결문에서 추출한 법령·판례를 곧바로 공식 권위로 취급하는 흐름

• 별도 Streamlit 앱과 별도 사건 canonical

업스트림 커밋 f3eb39f25062e86ce9dc1f72ad80be42c78bf179을 기준으로 Python·Markdown·YAML 등 31개 파일과 새 어댑터를 exact-text 방식으로 기계 비교했다. 동일 파일 hash와 50자 이상 정규화 동일 행은 없었다. 가장 긴 원시 연속 일치는 표준 import boilerplate 7행이었고, import·짧은 구문을 제외하면 가장 긴 일치는 상태 상수 1행이었다.

이 검사는 재현성 보조 증거일 뿐, 저작권이나 실질적 유사성에 관한 법률 판단을 대신하지 않는다.

🔄 실제 처리 흐름

이 구현은 판결문 파일을 새 어댑터에 곧바로 넣는 구조가 아니다. 실제 경계는 다음과 같다.

공식 판결문
  → 기존 intake와 case-bundle-1 구조화
  → clean-room practical-report adapter
  → source·locator·quote·provenance Gate
  → 내부 검토용 보고서 + manifest + receipt

즉, “판례 입력 시 실무용 해설보고서 생성”이라는 사용자 경험을 지향하지만, 이번에 새로 구현한 범위는 구조화된 bundle 이후의 검증 가능한 수직 절편이다. 원시 판결문 intake와 법률적 승인 절차는 기존 체계가 계속 소유한다.

🧪 합성 판결문으로 실제 실행해 본 결과

ALT

한국어 텍스트가 있는 페이지

그림 2. 동결한 어댑터와 합성 case-bundle-1 fixture로 생성한 실제 보고서 첫 화면. mechanical_status=PASS와 overall_status=BLOCKED가 동시에 표시된다.

실행 자체는 성공했다. 원문 snapshot, locator 세 개, 정확 인용, 직접 출처 표시는 모두 통과했다. 그러나 결과는 법률적으로 의존 가능한 상태가 아니었다.

그림 3. 실제 CLI receipt에서 생성한 상태 카드. 실행 성공과 법률적 의존 가능성을 하나의 PASS/FAIL로 뭉치지 않았다.

차단 사유도 숨기지 않았다.

• 행위시법과 개정 이력이 검증되지 않음

• 독립 검토가 완료되지 않음

• 사람 승인 절차가 지원되지 않음

• 기록 범위가 판결문에 한정됨

• fixture의 정답 상태가 blocked임

이 다축 상태가 중요한 이유는 단순하다. 파일이 만들어졌다는 사실은 법률적으로 믿을 수 있다는 뜻이 아니기 때문이다.

🧯 실패해야 할 입력도 따로 시험했다

좋은 fixture 하나가 통과한 것만으로는 fail-closed를 입증하기 어렵다. 다음 실패 클래스를 음성 fixture와 단위 테스트로 고정했다.

• 직접 명제에 locator가 없음

• locator가 source를 찾지 못함

• quoted text와 원문 범위가 다름

• source hash가 다름

• source 경로가 허용 root 밖으로 이탈함

• 판결문에 안 보인다는 이유만으로 “제기되지 않았다”고 단정함

• 반사실 FLIP에 forward path가 없음

• 생산자의 자동 재작성·자체 PASS가 개입함

그림 4. 현재 동결 스냅샷에서 다시 계산한 테스트 결과. targeted mechanical PASS가 전체 법률 플랫폼 PASS를 뜻하지 않음을 함께 표시했다.

실제 재실행 결과는 다음과 같다.

• 잠금 산출물 11개와 음성 fixture 8개: PASS

• 신규 어댑터 테스트: 7/7 PASS

• 기존 case-bundle 회귀 테스트: 23/23 PASS

• 기존 reverse bundle 회귀 테스트: 4/4 PASS

• Python compile과 scoped diff 검사: PASS

• 보고서·manifest hash와 receipt 기재값: 일치

완료 시점의 더 넓은 통합 Gate에서는 새 어댑터의 정적·fixture 검사는 통과했지만, 별도 Phase 0 child와 OpenViking의 0-evidence 비교 문제가 남아 aggregate 결과는 FAIL이었다. 이 글은 그 실패를 숨기지 않고, 이번 수직 절편의 통과 범위만 통과했다고 기록한다.

📐 전후 차이는 어디서 생겼나

🛠️ 재사용 가능한 작업 순서

1. 업스트림을 먼저 고정한다. 저장소 URL, commit, tree, license hash를 기록한다.

2. 내부 canonical을 먼저 선언한다. 새 도구가 별도 진실 원장을 만들지 못하게 한다.

3. 기능보다 행동 계약을 고른다. 필요한 검증 행동과 제외할 runtime을 문서로 나눈다.

4. 음성 fixture를 먼저 쓴다. 성공 예시보다 “반드시 막혀야 하는 입력”을 우선 고정한다.

5. 작은 수직 절편을 구현한다. 한 개의 합성 입력이 report·manifest·receipt까지 끝까지 흐르게 한다.

6. 기존 코어를 다시 시험한다. 새 테스트만 통과한 상태를 완료로 보지 않는다.

7. 검토 스냅샷을 hash로 묶는다. 검토 뒤 파일이 바뀌면 이전 판정을 폐기한다.

8. Library 발행과 운영 승격을 분리한다. 사례글은 발행할 수 있어도 생성 보고서는 계속 not_authorized일 수 있다.

💬 바로 써볼 수 있는 프롬프트

선별 이식 경계를 만드는 프롬프트

이 저장소를 전체 편입 대상으로 보지 말고 행동 참고면으로 분석해 줘.
1) 반드시 유지할 내부 canonical과 Gate를 먼저 적고,
2) 가져올 행동 계약과 명시적으로 제외할 runtime을 분리하고,
3) 업스트림 URL·commit·license·선택 파일 hash를 고정하고,
4) 코드·prompt 복사 없이 독립 구현 가능한 최소 수직 절편을 제안해 줘.
성공 조건뿐 아니라 반드시 차단되어야 하는 음성 fixture도 함께 설계해 줘.

판례 보고서의 fail-closed 검토 프롬프트

이 판례 해설보고서를 '완성 여부' 하나로 평가하지 마.
process, mechanical, domain, reliance, publication 상태를 분리해 줘.
E0/E1 직접 명제마다 source_id, 정확한 locator, quoted_text가 있는지 확인하고,
원문 hash·인용 범위·행위시법·전체 기록·독립검토 중 하나라도 빠지면
누락을 추정으로 메우지 말고 BLOCKED 또는 NOT_RUN으로 보존해 줘.

⚠️ 아직 하지 않은 것

• 실제 판결문 canary 실행

• 공식 판결문·심급별 원문 대조

• 행위시법·부칙·경과규정·개정 이력 확인

• 판결문 밖 소송기록과 증거 상태 확인

• 청구·항변·요건사실·입증부담과 최강 반론 검토

• 새 보고서 hash에 결속된 독립 법률심사와 사람 승인

• EvidenceItem·검색 기본값 편입

• 운영 배포와 외부 커뮤니티 발행

따라서 현재 성과는 “판례 해설 AI를 완성했다”가 아니다. 외부 프로젝트에서 유용한 행동을 골라 기존 법률 코어에 안전하게 접속했고, 모르는 것은 모른다고 멈추는 실행 경계를 만들었다는 데 있다.