12만 건 판례 Git을 통째로 편입하지 않고, 후보 검색기로만 가뒀습니다-precedent-kr를 commit 고정 스냅샷·FTS5·공식 원문 재확인 Gate로 편입한 기록

이 사례의 공개 상태

• 공개 저장소 현재 트리 조사: 124,458개 판례 Markdown 확인

• 내부 고정 스냅샷·FTS5: 124,457건, 14/14 검증 PASS

• 읽기 전용 실검색 3종: 3/3 실행 성공

• 기존 미보존 인용 후보의 결정론적 unique match: 1,667/2,064

• 선별 25건 메타데이터 일치: 25/25 PASS

• 공식 XML 표본 전체 섹션 교차검증: 5/5 PASS

• 12만 건 canonical 일괄 승격: BLOCKED

• 판례 인용 전 공식 원문 재확인: REQUIRED

• 이 문서의 범위: 로컬 Library용 사례게시글

📝 한줄 요약

legalize-kr/precedent-kr는 판례를 사건종류·법원등급·합성 파일명으로 정리한 유용한 Git 데이터셋이다. 그러나 저장소가 직접 경고하는 force-push 가능성, 판결일을 commit date로 쓰는 시간 의미, 공식 원문과 미러의 권위 차이, 수만 개 파일의 저장 비용을 그대로 안고 있다. 그래서 전체를 canonical에 복사하지 않았다. commit을 고정한 불변 tar.zst와 manifest를 만들고, 그 스냅샷에서만 읽는 SQLite FTS5를 구축했다. 검색 결과는 DISCOVERY_ONLY 후보로만 반환하고, 실제 인용 직전에는 국가법령정보센터 원문을 다시 확인하도록 경계를 닫았다.

바쁘다면 이것만 읽어도 된다.

• 12만 건을 내려받기 전에 blob:none + no-checkout으로 Git tree부터 조사할 수 있다.

• 이 저장소의 Git commit date는 데이터 갱신일이 아니라 판결 선고일이다.

• README는 파이프라인 재구성 시 force-push와 전체 commit hash 변경 가능성을 명시한다.

• 장기 사건 식별자는 Git SHA가 아니라 판례일련번호와 공식 출처 URL로 잡아야 한다.

• 고정 스냅샷과 검색 인덱스는 같은 source head·tree·case count로 연결해야 한다.

• 전문검색 hit에는 정확한 사건뿐 아니라 그 사건을 인용한 다른 판례와 문맥상 동시출현도 섞인다.

• 미러와 공식 XML 5건이 일치해도 저장소 전체의 완전성이나 법률적 적용 가능성이 증명되는 것은 아니다.

• 후보 검색, 공식 원문 확인, 법률적 적용 판단, canonical 승격은 서로 다른 승인 단계다.

🎯 이런 분들께 도움이 된다

• 공개 법률 데이터 저장소를 내부 RAG·검색·MCP 앞단에 연결하려는 팀

• 대량 Git 저장소를 내려받기 전에 구조와 규모부터 안전하게 조사하려는 개발자

• 판례 미러를 공식 법률근거와 구분해 운영하려는 법률 AI 담당자

• 외장 저장소에 수십만 파일을 펼치지 않고 불변 snapshot으로 보존하려는 사람

• source commit·archive·index·검색 영수증의 provenance를 하나로 묶으려는 데이터 엔지니어

• “검색이 된다”와 “법률문서에 인용할 수 있다” 사이의 Gate가 필요한 조직

😫 시작점 — 구조는 좋았지만, 그대로 들이면 네 가지가 섞였다

검토 대상은 공개 저장소 legalize-kr/precedent-kr였다. README는 대한민국 판례를 Markdown으로 관리하고, 각 판례의 선고일자를 Git author·committer date로 기록한다고 설명한다. 파일은 대체로 다음 구조를 따른다.

{사건종류}/
  {법원등급}/
    {법원명}_{선고일자}_{사건번호}.md
    {법원명}_{선고일자}_{사건번호}_{판례일련번호}.md

각 Markdown의 YAML frontmatter에는 판례일련번호, 사건번호, 사건명, 법원명, 사건종류, 국가법령정보센터 출처 URL, 선고일자가 들어간다. 판시사항·판결요지·참조조문·참조판례·판례내용도 섹션으로 분리된다. 사람이 읽기 쉽고 Git·정적 도구로 처리하기 좋은 구조다.

ALT

한국을 합법화하다 - 스크린샷

그림 1. 2026-08-12에 실제 GitHub 모바일 저장소 화면을 캡처한 것이다. 저장소명과 Public 상태, 사건종류 폴더, README 제목이 보인다. 화면의 39 years ago는 아래에서 분리해 설명하는 판결일 기반 commit time이다. 생성형 이미지나 재현 UI가 아니다.

ALT

한국사이트 스크린샷

그림 2. 같은 실제 GitHub 모바일 README의 도입부와 하단 정책 부분을 각각 잘라 회색 구분선으로 이은 합성 crop이다. 위쪽은 선고일을 Git commit date로 기록한다는 설명과 force-push 공지, 아래쪽은 국가법령정보센터 OpenAPI 출처 및 ‘판례 원문=공공저작물·저장소 구조/메타데이터=MIT’라는 upstream의 고지를 보여 준다. 이 사례가 라이선스 범위를 독립 인증했다는 뜻은 아니다.

하지만 “유용한 구조”와 “바로 내부 근거로 써도 됨”은 같은 명제가 아니었다.

1. 시간 의미가 다르다. 최신 HEAD의 commit date가 1987-12-15로 보였다. 저장소가 판결일을 commit date로 쓰기 때문이다.

2. commit SHA가 영구 식별자가 아니다. README는 파이프라인 개선 시 전체 history를 재구성하고 force-push할 수 있다고 밝힌다.

3. 미러와 공식 원문은 권위가 다르다. 각 파일에 공식 URL이 있어도 파일 자체는 공개 Git 미러다.

4. 저장과 검색의 운영비가 다르다. 수십만 Markdown을 외장 볼륨에 펼쳐 active Git·SQLite로 운용하면 파일시스템·lock·Unicode·복구 경계가 복잡해진다.

따라서 질문을 바꿨다.

12만 건을 canonical에 일괄 편입할 수 있는가?  → 하지 않는다.
빠르게 후보를 찾고 공식 원문으로 돌아가는 검색 계층으로 쓸 수 있는가?  → 고정 snapshot으로 검증한다.

🧭 첫 번째 전환점 — Git의 “최신”을 두 개의 시계로 나눴다

관찰 당시 GitHub API의 pushedAt은 2026-08-11T12:45:50Z였지만 HEAD commit의 author·committer date는 1987-12-15T03:00:00Z였다. HEAD가 가리킨 판례의 선고일을 commit time으로 기록했기 때문이다.

저장소 갱신 시계 = GitHub pushedAt / 원격 HEAD·tree 관찰 시점
판례 사건 시계   = Markdown 선고일자 / commit author·committer date

두 시계를 합치면 “39년 전에 마지막으로 갱신된 저장소”처럼 오해할 수 있다. 실제 화면에서도 최신 commit 옆에 39 years ago가 표시되지만, 저장소는 전날 push된 상태였다.

더 중요한 것은 장기 식별자였다.

Git SHA
→ 특정 snapshot의 증적
→ history 재구성 시 바뀔 수 있음

판례일련번호 + 공식 출처 URL
→ 사건의 장기 식별자
→ 인용 전 공식 원문으로 되돌아가는 locator

Git SHA를 버린 것은 아니다. archive·index·검색 결과가 어느 byte 집합에서 나왔는지 묶는 snapshot provenance로 사용했다. 다만 사건 자체의 영구 ID로 승격하지 않았다.

🧊 두 번째 전환점 — live worktree 대신 불변 snapshot을 만들었다

처음에는 전체 저장소를 그대로 clone해 외장 저장소에서 검색하는 방법이 떠오르기 쉽다. 대신 다음 5단계로 나눴다.

그림 3. 2026-08-12 upstream tree inventory와 2026-08-11 snapshot manifest에서 자동 생성한 데이터 파생 증거 카드다. live UI나 터미널 캡처가 아니다. 카드의 REMOTE +1은 관찰 당시 원격 트리가 고정 snapshot보다 판례 1건 앞섰음을 뜻한다.

1. tree만 보는 partial clone

--filter=blob:none --no-checkout --depth=1로 전체 판례 본문을 materialize하지 않고 tree inventory부터 확인했다. 2026-08-12 관찰한 현재 원격 트리는 다음과 같았다.

사건종류별 판례 파일 수는 일반행정 45,217, 민사 42,516, 형사 21,748, 세무 10,146, 특허 3,412, 가사 1,400, 기타 11, 선거·특별 8이었다.

2. commit과 tree를 고정한 snapshot

실제 내부 검색에는 전날 고정한 d4a9982a2725… snapshot을 사용했다. 현재 원격 HEAD 49c4c8378410…와 비교하면 민사 하급심 판례 1건이 추가된 상태였다. 이미 만든 인덱스를 조용히 최신으로 가장하지 않고, 고정판 124,457건과 현재 관찰판 124,458건을 별도 상태로 기록했다.

active_snapshot: 20260811T112344KST__d4a9982a2725
pinned_git_head: d4a9982a272518e83312184c584f6a3542c9ce23
pinned_git_tree: 0c2367c19fda91b121c195ec0c1ef1c009bbe9ad
case_records: 124457
remote_observed_head: 49c4c83784108fad16f806beb26e085b5ccc66d2
remote_observed_case_records: 124458

3. 외장 보존본은 단일 archive로 닫기

124,457개 판례 파일을 외장 저장소에 그대로 펼치지 않았다. 내부 작업 볼륨에서 완성·검증한 뒤, 하나의 tar.zst와 manifest·SHA-256으로 닫았다.

archive에는 link entry 0, unsafe path 0, non-NFC path 0이 확인됐다. Git worktree나 쓰기 중인 SQLite를 외장 볼륨에서 직접 운용하지 않았다.

4. snapshot에서만 읽는 FTS5

archive와 같은 source head에서 SQLite FTS5를 만들었다. cases와 cases_fts가 모두 124,457행인지 확인하고 PRAGMA integrity_check와 검색 fixture를 실행했다. 최종 snapshot·index 검증은 14/14 PASS였다.

5. 인용 직전 공식 원문 재확인

검색 결과에는 항상 다음 경계를 유지했다.

artifact_role: discovery-only
official_source_recheck_required_before_citation: true
canonical_promoted: false
legal_reliance_eligible: false

🔎 실제 검색 — exact 사건도 나오고, 인용판례와 문맥 hit도 함께 나왔다

2026-08-12에 active DB를 mode=ro로 다시 열어 세 질의를 실행했다. 실행 직전 선언된 DB SHA-256과 실제 2.07 GB 파일의 SHA-256을 다시 계산했고 정확히 일치했다. quick_check=ok, cases=124,457, FTS rows=124,457도 재확인했다.

그림 4. 같은 시점의 공개용 검색 영수증에서 자동 생성한 데이터 파생 증거 카드다. 내부 절대경로와 BM25 점수는 공개판에서 제외했다. 세 질의는 모두 return code 0으로 종료했고 각 3건을 반환했다.

사건번호 2000므1257

첫 결과는 기대한 대법원 2000므1257(본소), 1264(반소), 판례일련번호 145683이었다. 그러나 2·3위는 그 사건을 본문에서 인용한 다른 하급심 판례였다.

1. 145683 · 대법원 · 2000므1257(본소), 1264(반소)
2. 148866 · 서울가법 · 2010드합2787,3537
3. 165171 · 부산가법 · 2011드합1104, 1517

사건번호 검색 hit가 곧 exact 사건 identity라는 뜻은 아니다. title·frontmatter·본문 인용을 구분해야 한다.

임대차 AND 보증금

세 결과 중 하나는 민사 임대차 보증금 사건이었고, 두 개는 형사사건 본문에서 두 단어가 함께 등장한 경우였다.

민사 1건 + 형사 2건

전문검색의 장점과 한계가 동시에 드러났다. 누락 없이 넓게 찾는 데는 유용하지만, 단어 동시출현만으로 사건의 법률적 관련성을 확정할 수 없다.

사실혼파기

사건명·전문에서 판례일련번호 145683, 240261, 142045가 반환됐다. 세 건 모두 공식 source URL을 포함했지만, 현재 사안에 어떤 명제를 지지하는지는 별도 검토 대상이다.

세 질의의 point-in-time 실행시간은 각각 51.810ms, 37.218ms, 35.900ms였다. 이는 해당 장비·cache·질의에서의 단일 관찰값일 뿐 처리량 benchmark나 다른 검색기 대비 성능 주장은 아니다.

🧪 세 번째 전환점 — “전체가 좋다” 대신 기존 미보존 후보로 붙여 봤다

저장소 전체를 평가하는 대신 실제 내부 후보 목록과 연결했다.

• 기존 cited-case 후보: 2,481건

• 그중 미보존 + official-verify 대상: 2,064건

• 사건번호의 2자리·4자리 연도 표기를 정규화

• 사건번호·선고일·법원으로 결정론적 매칭

그림 5. pilot summary와 공식 XML 비교 영수증에서 자동 생성한 데이터 파생 증거 카드다. 1,667건 unique는 canonical 승격 수가 아니라 다음 검토 단계로 넘길 수 있는 후보 수다.

결과는 다음과 같았다.

결정론적 unique match율은 80.7655%였다. 좋은 수치지만 100%가 아니다. 나머지 397건을 조용히 버리거나 unique로 강제하지 않은 것이 더 중요했다.

✅ 표본 25건과 공식 XML 5건 — 맞은 범위만 PASS로 남겼다

unique 후보에서 25건을 선별해 blob을 materialize했다. 사건번호·법원·선고일은 25/25 일치했고, 각 파일에 Git blob ID와 SHA-256을 기록했다. 상태는 계속 discovery-only, requires-live-official-check로 유지했다.

그중 5건은 국가법령정보센터 공식 XML을 다시 받아 다음 범위를 비교했다.

• 판례일련번호·사건번호·사건명·법원·사건종류·선고일

• 판시사항

• 판결요지

• 참조조문

• 참조판례

• 판례내용 전문

정규화는 HTML <br/>의 개행 변환, Unicode NFC, 공백 접기만 적용했다. 실질 문자는 고치지 않았다. 결과는 5/5에서 metadata와 모든 섹션의 normalized SHA-256이 일치했다.

그러나 이 PASS의 범위는 좁다.

• 5건은 모두 대법원 사건이었다.

• 사건종류도 가사 1건·민사 4건으로 편중됐다.

• 공식 원문과 mirror가 당시 동일했다는 뜻이지, 124,457건 전체의 완전성을 증명하지 않는다.

• 현재 법률 쟁점에 적용 가능하다는 뜻도 아니다.

• 후속판례·변경 판례·행위시법·불리한 판례 검토를 대체하지 않는다.

그래서 canonical 변경은 0건으로 유지했다.

🚨 구체적인 경계 1 — 원격은 하루 만에 한 건 앞섰다

고정 snapshot은 124,457건이었지만, 다음 날 원격 tree는 124,458건이었다. 두 tree의 차이는 다음 한 파일이었다.

민사/하급심/춘천지방법원_1987-12-15_87가단282_622419.md

여기서 기존 DB에 한 행만 조용히 붙이지 않았다. 원격이 변하면 새 snapshot ID, 새 archive, 새 index, 새 manifest, 새 QA를 만든다. 현재판을 검증하기 전까지 구판은 구판의 hash와 함께 그대로 유지한다.

README가 force-push 가능성을 밝히므로 다음 원칙도 추가했다.

원격 HEAD가 바뀜
→ 기존 archive를 덮어쓰지 않음
→ 새 tree inventory와 delta 기록
→ 새 immutable snapshot 생성
→ 새 index·검증 완료 후에만 active pointer 전환

🚨 구체적인 경계 2 — 선고일 누락과 섹션 누락은 실제로 있었다

고정 snapshot 124,457건의 build report에서 선고일자 누락은 29,180건이었다. 판례내용 섹션은 124,455건에 존재해 2건이 비어 있었다. metadata parse error와 UTF-8 replacement character는 0이었지만, “파싱 성공”과 “모든 필드가 채워짐”은 같지 않았다.

또한 README는 1970-01-01 이전 날짜를 Git이 직접 지원하지 않으므로 해당 commit date를 1970-01-01로 고정한다고 설명한다. 오래된 판례의 실제 날짜는 commit time이 아니라 frontmatter를 봐야 한다. 단기 연도 변환도 원자료와 ±1년 차이 가능성을 README가 별도로 경고한다.

따라서 freshness·정렬·법률 시점 판단에 Git log만 쓰지 않았다.

🚨 구체적인 경계 3 — 라이선스 문구와 배포 표면을 분리했다

upstream README는 다음과 같이 설명한다.

• 판례 원문: 대한민국 정부 공공저작물

• 저장소 구조·메타데이터: MIT

그러나 관찰한 tree에는 표준 LICENSE 파일이 없었고, GitHub API의 licenseInfo도 null이었다. 이 사례는 README의 설명을 출처와 함께 기록했지만, 저장소 전체의 재배포 조건을 독립적인 법률 결론으로 확정하지 않았다.

readme_notice: recorded
standard_license_file: not_detected
github_detected_spdx: null
redistribution_status: not_independently_resolved

내부 검색용 snapshot·index를 만드는 것과 외부에 원문 corpus를 다시 배포하는 것은 별도 승인으로 남겼다.

✅ Before와 After

🧾 Trace · Proof · Verdict · Repair

Trace

공개 저장소 README·tree·원격 metadata 확인
→ blob:none + no-checkout inventory
→ 판결일 commit time과 원격 갱신 시계 분리
→ commit·tree 고정
→ 단일 tar.zst snapshot + manifest + SHA-256
→ 같은 snapshot에서 SQLite FTS5 구축
→ archive·DB·rows·fixture 14/14 검증
→ 기존 미보존 인용 후보 2,064건 결정론적 매칭
→ unique 1,667 / ambiguous 61 / unmatched 334 / parse fail 2
→ 선별 25건 metadata 25/25
→ 공식 XML 5건 전체 섹션 normalized hash 5/5
→ canonical changes 0
→ 다음 날 원격 +1 case를 별도 drift로 기록
→ active DB hash 재계산 + read-only 실검색 3종

Proof

• 현재 원격 tree case Markdown 124,458건

• 고정 snapshot case records 124,457건

• archive 240,927,163 bytes, SHA-256 af843d9e…

• FTS5 DB 2,067,709,952 bytes, SHA-256 45f6758f…

• 선언 DB hash와 실제 재계산 hash exact match

• quick_check=ok, cases 124,457, FTS rows 124,457

• snapshot·index 검증 14/14 PASS

• 실검색 3/3 return code 0

• 후보 2,064건 중 unique 1,667건

• 선별 metadata 25/25 PASS

• 공식 XML 교차검증 5/5 PASS

• canonical changes 0

• 현재 원격이 고정판보다 한 건 앞선 drift 기록

Verdict

upstream_tree_inventory: PASS
immutable_snapshot: PASS
read_only_fts5: PASS
actual_search_execution: PASS_3_OF_3
candidate_adapter: GO_DISCOVERY_ONLY
selected_metadata: PASS_25_OF_25
official_xml_sample: PASS_5_OF_5_WITH_SAMPLE_LIMITS
repository_wide_completeness: NOT_PROVEN
legal_relevance_of_search_hits: NOT_PROVEN
legal_reliance_eligible: false
canonical_mass_ingest: BLOCKED
redistribution_scope: NOT_INDEPENDENTLY_RESOLVED
external_publication: NOT_RUN

Repair

• Git commit time 하나로 freshness와 판결일을 함께 읽지 않는다.

• force-push 가능한 SHA는 사건 ID가 아니라 snapshot 증적으로 제한한다.

• 외장 저장소에는 펼친 worktree가 아니라 닫힌 archive를 보존한다.

• search DB는 원본 snapshot과 head·tree·row count·hash로 연결한다.

• exact 사건, 본문 인용, 단어 동시출현을 결과 후처리에서 구분한다.

• ambiguous·unmatched·parse failure를 숨기지 않고 queue로 남긴다.

• 표본 PASS를 전체 corpus PASS나 법률적 적용 가능성으로 확대하지 않는다.

• 원격 drift는 in-place 갱신이 아니라 새 version 검증으로 처리한다.

📋 재사용 가능한 공개 법률 corpus 도입 체크리스트

[ ] README·데이터 출처·force-push·날짜 의미를 먼저 읽는다.
[ ] 원격 HEAD, tree, pushedAt, 관찰 시점을 함께 기록한다.
[ ] 전체 blob을 받기 전에 no-checkout tree inventory를 만든다.
[ ] unsafe path, Unicode NFC, casefold collision, 파일명 길이를 검사한다.
[ ] Git SHA와 사건의 장기 식별자를 분리한다.
[ ] archive를 불변 파일로 닫고 bytes·SHA-256·root·file count를 기록한다.
[ ] active Git·쓰기 중 SQLite를 외장 보존 볼륨에서 운용하지 않는다.
[ ] index metadata에 source repository·head·tree·snapshot ID를 넣는다.
[ ] cases row count와 FTS row count를 원본 case count와 대조한다.
[ ] known case·사건번호·전문검색 fixture를 실제 실행한다.
[ ] 선언 hash를 읽는 데 그치지 않고 실제 파일 hash를 재계산한다.
[ ] exact identity hit와 본문 인용 hit를 구분한다.
[ ] ambiguous·unmatched·parse failure를 강제 매칭하지 않는다.
[ ] 표본을 공식 원문과 metadata·섹션별로 비교한다.
[ ] 검색 후보에는 DISCOVERY_ONLY와 legal_reliance=false를 기본값으로 둔다.
[ ] 인용 전 공식 원문·행위시법·후속판례·불리한 판례를 다시 확인한다.
[ ] 원격 변경 시 구버전을 덮어쓰지 않고 새 snapshot으로 검증한다.
[ ] README 라이선스 고지와 실제 LICENSE·SPDX 탐지 상태를 분리 기록한다.
[ ] canonical 편입과 외부 재배포를 별도 승인으로 둔다.

💬 재사용 가능한 프롬프트

공개 판례 Git 저장소를 내부 canonical에 바로 복사하지 말고 discovery-only corpus로 평가해 주세요.

1. README, 데이터 출처, 라이선스 고지, force-push 가능성, commit date의 의미를 확인합니다.

2. blob:none + no-checkout으로 원격 HEAD·tree와 전체 경로 inventory를 먼저 수집합니다.

3. unsafe path, Unicode NFC, casefold collision, 파일명 byte 길이와 사건종류별 수를 검사합니다.

4. source commit·tree를 고정하고 단일 불변 archive, manifest, SHA-256을 만듭니다.

5. 같은 snapshot에서만 read-only FTS index를 만들고 cases·FTS row 수를 대조합니다.

6. exact 사건번호, 전문 복합검색, 사건명 검색을 실제 실행해 결과 유형을 분류합니다.

7. 기존 후보 목록과 매칭할 때 unique·ambiguous·unmatched·parse failure를 별도 상태로 보존합니다.

8. 선별 표본을 공식 원문과 metadata·판시사항·판결요지·참조조문·참조판례·전문으로 비교합니다.

9. 표본 PASS를 전체 corpus나 현재 사건의 법률적 적용 가능성으로 확대하지 않습니다.

10. 후보에는 DISCOVERY_ONLY, official_source_recheck_required=true, legal_reliance=false를 붙입니다.

11. 원격 drift가 생기면 구판을 덮어쓰지 말고 새 snapshot·index·QA를 만듭니다.

12. canonical 승격과 외부 재배포는 별도 승인 전까지 수행하지 않습니다.

🌍 다른 업무에 적용한다면

이 구조는 판례에만 한정되지 않는다.

• 법령·행정규칙: 개정 이력 mirror에서 후보 조문을 찾되 시행일별 공식 원문을 다시 확인한다.

• 의학 논문 corpus: 검색 후보와 환자별 임상 판단을 분리하고 원문·철회 상태를 재확인한다.

• 재무 공시: 대량 filing mirror에서 후보를 찾고 규제기관 원문과 제출 시점을 다시 대조한다.

• 보안 IOC: 공개 feed hit와 실제 차단 결정을 분리하고 feed snapshot을 hash로 고정한다.

• 제품 문서: 검색 index와 배포된 제품 버전을 묶어 오래된 문서가 최신 답변으로 승격되는 것을 막는다.

공통 원리는 다음과 같다.

검색 가능함 ≠ 원본 권위가 확인됨
원본 권위가 확인됨 ≠ 현재 맥락에 적용됨
현재 맥락에 적용됨 ≠ 자동 승격이 승인됨

🚧 확인하지 않은 것

• 124,458건 현재 원격판 전체 blob의 metadata·본문 완전성

• 고정 snapshot의 선고일 누락 29,180건에 대한 개별 보정

• 판례내용이 비어 있는 2건의 원인과 공식 원문 상태

• ambiguous 61건과 unmatched 334건의 전수 분류

• 검색 질의 집합에 대한 recall·precision benchmark

• 다른 판례 검색기와의 블라인드 정확도·속도·비용 비교

• 5건 외 표본의 공식 XML section-level 일치

• 모든 하급심·사건종류·오래된 판례의 coverage

• 후속판례·변경판례·행위시법·경과규정·불리한 판례 검토

• README 라이선스 고지의 법률적 범위와 외부 재배포 적합성

• production RAG·MCP 등록과 장기 부하·장애·rollback drill

• 변호사 등 사람의 최종 법률 검토

• 외부 웹·커뮤니티·이메일 발행

이 항목은 14개 검증, 25건 metadata PASS, 공식 XML 5/5로 대신 증명할 수 없다.

📚 도움받은 글

• legalize-kr, 대한민국 판례 저장소 (precedent-kr)
  https://github.com/legalize-kr/precedent-kr

• 이 사례의 active index가 고정한 upstream commit
  https://github.com/legalize-kr/precedent-kr/tree/d4a9982a272518e83312184c584f6a3542c9ce23

• 2026-08-12 관찰 당시 원격 HEAD commit
  https://github.com/legalize-kr/precedent-kr/commit/49c4c83784108fad16f806beb26e085b5ccc66d2

• 국가법령정보센터, OpenAPI
  https://open.law.go.kr

• 공식 XML 교차검증 표본 중 판례일련번호 145683
  https://www.law.go.kr/LSW/precInfoP.do?precSeq=145683

upstream의 사건 수·구조·라이선스·force-push 설명은 관찰 시점 README와 Git tree를 기준으로 기록했다. 판례 원문이 공공저작물이고 저장소 구조·메타데이터가 MIT라는 문구는 upstream README의 설명이다. 이 사례는 그 법률적 범위나 외부 재배포 적합성을 독립 인증하지 않았다.

📦 산출물과 공개 경계

생성된 산출물

• 현재 upstream tree inventory와 고정 commit·tree 기록

• 실제 GitHub 저장소·README 정책 캡처 2장

• 데이터 파생 실행 증거 카드 3장

• 고정 snapshot·archive·FTS5 manifest 검증 근거

• 실제 read-only 검색 영수증과 공개용 축약본

• 후보 2,064건 매칭·선별 25건·공식 XML 5건 교차검증 근거

• 로컬 Library용 사례게시글

공개 경계

• 실제 의뢰인 사실·개인정보 사용: 없음

• 내부 절대경로·BM25 점수의 공개 카드 노출: 없음

• 12만 건 canonical 일괄 승격: BLOCKED

• 검색 결과의 법률근거 승격: 없음

• 공식 원문 확인 없는 판례 인용: BLOCKED

• upstream corpus 외부 재배포: NOT RUN

• production RAG·MCP 등록: NOT RUN

• 외부 웹·커뮤니티·이메일 게시: NOT RUN

최종 판정: legalize-kr/precedent-kr는 사건번호를 이미 아는 경우와 쟁점어로 넓게 찾는 경우 모두에 유용한 대량 판례 discovery source다. 고정 snapshot 124,457건은 archive·FTS5·실검색까지 검증됐고, 기존 미보존 후보 2,064건 중 1,667건을 결정론적으로 연결했다. 그러나 원격은 이미 한 건 앞섰고, force-push·날짜 의미·coverage·라이선스·공식 권위 경계가 남아 있다. 따라서 성과는 12만 건을 많이 들인 것이 아니라, 후보는 빠르게 찾되 공식 원문과 사람의 법률 검토 전에는 한 건도 canonical 근거로 승격하지 않도록 만든 것이다.