법률 MCP를 바로 붙이지 않고, 후보만 찾게 가뒀습니다-LaWink를 DISCOVERY_ONLY canary로 연결하고 거짓 PASS 두 번을 막은 기록

이 사례의 공개 상태

• 비식별 후보 발견 canary: PASS_FROZEN_CANARY

• LaWink 후보 3건의 공식 사건 identity 재확인: 3/3 PASS

• 명제별 법리·불리한 판례·절차적 지위 검토: NOT RUN

• 법률의견서·소송서면에 사용할 수 있는 상태: 아님 — BLOCKED

• Hermes production MCP 등록·Gateway 재시작: NOT RUN

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

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

📝 한줄 요약

자연어 사안에서 유사 판례와 조문을 빠르게 찾는 LaWink를 검토했지만, 검색 결과를 곧바로 법률근거로 쓰지 않았다. 공개·비식별 질의만 허용하는 별도 CLI를 만들고, LaWink 결과에는 항상 DISCOVERY_ONLY / U0_UNVERIFIED_CANDIDATE를 붙였다. 후보 사건은 Korean-law MCP의 공식 검색·본문·행위시법 경로로 넘겼으며, 공식 사건번호가 맞아도 명제별 검토가 끝나지 않으면 문서 작성 승격을 막았다. 그 과정에서 검증기의 거짓 PASS, 검색어 반사 저장, MCP 자손 프로세스 잔존을 차례로 찾아 v0.1.6과 v0.1.7을 폐기했고, 세 경계를 모두 수리한 v0.1.8만 동결 canary로 통과시켰다.

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

• 민간 검색 서비스의 결과는 좋은 후보일 수 있지만 공식 법률근거는 아니다.

• 검색 전에 공개·비식별 여부를 확인하고, 식별자 탐지는 네트워크 전 단계에서 fail-closed로 둔다.

• 실체법 기준일과 절차법 기준일은 하나로 합치지 않는다.

• 사건번호가 비슷해도 87다카98과 87다카982는 다른 사건이다. 접두어 일치는 exact identity가 아니다.

• 공식 사건 identity와 조문 존재를 확인해도 명제별 근거, 불리·제한 판례, 절차적 지위가 남으면 BLOCKED다.

• 검증기 자체도 변조 fixture로 공격해야 한다. manifest와 hash가 맞는다는 선언만 읽어서는 거짓 PASS를 막을 수 없다.

• 늦게 도착한 독립 PASS가 이미 폐기된 버전을 되살려서는 안 된다.

• canary PASS와 production 등록, 법률적 의존, 외부 발행은 서로 다른 승인 단계다.

🎯 이런 분들께 도움이 된다

• 법률 검색 MCP·RAG·온톨로지를 기존 법률 검토 체계에 연결하려는 팀

• “검색 결과가 나왔다”와 “법률문서에 써도 된다”를 분리하려는 법률 AI 운영자

• 제3자 API에 의뢰인 사실을 보내기 전 비식별 Gate를 만들려는 개발자

• 공식 원문·행위시법·후속 판례·provenance를 자동화 파이프라인에 넣으려는 사람

• hash·manifest·독립 QA가 있어도 거짓 PASS가 생길 수 있는 이유를 알고 싶은 팀

• stdio MCP의 직접 부모뿐 아니라 자손 프로세스까지 정리하려는 운영자

😫 시작점 — 검색은 빨랐지만, 어디까지 믿어도 되는지가 없었다

검토 대상은 공개 저장소 ntriq/lawink-mcp였다. 고정한 커밋의 README는 판례·법령 관계 그래프와 의미 검색을 MCP 도구 7종으로 제공한다고 설명한다. 특히 다음 경로가 매력적이었다.

자연어 사안
→ 유사 판례
→ 그 판례들이 인용한 조문
→ 관련 판례·법령 관계 확장

공개 예시인 “임대차 종료 후 원상회복 비용과 보증금 반환”처럼 쟁점은 알지만 사건번호나 조문을 아직 모를 때, 후보를 좁히는 출발점으로 유용한 구조다.

그러나 실제 검토에서는 곧바로 세 개의 경계가 드러났다.

1. 공개 wrapper는 민간 API의 검색 결과를 전달한다. 법원·법제처 원문 그 자체가 아니다.

2. README의 기본 uvx lawink-mcp 경로는 당시 의존성이 MCP SDK 2.x로 해석되면서 import 오류가 재현됐다. 고정 커밋과 mcp<2 격리에서만 stdio 초기화와 7개 도구 발견이 확인됐다.

3. 검색 결과에는 행위시법, 경과규정, 절차적 지위, 불리·제한 판례, 명제별 원문 locator가 자동으로 닫히지 않는다.

따라서 질문을 바꿨다.

LaWink가 우리 법률체계를 대체할 수 있는가?  → 아니다.
LaWink를 후보 발견기로 격리해 공식 검증의 앞단에 둘 수 있는가?  → canary로 시험한다.

🧭 첫 번째 전환점 — 검색기와 권위 확인기를 두 개의 차선으로 나눴다

한 도구가 검색과 승인까지 모두 하게 두지 않았다. 각 단계의 책임을 다음처럼 분리했다.

LaWink가 반환한 후보에는 처음부터 다음 상태를 붙였다.

classification: DISCOVERY_ONLY
authority_status: S1_PRIVATE_DISCOVERY
verification_status: U0_UNVERIFIED_CANDIDATE
drafting_eligible: false

그림 1. 2026-08-11 13:27 KST의 실제 canary 영수증에서 자동 생성한 데이터 파생 실행 증거 카드다. live UI나 터미널 캡처가 아니며, 후보 발견과 법률근거 승격을 분리한 당시 상태를 보여 준다.

핵심은 official이라는 단어도 한 번에 쓰지 않은 것이다. 공식 검색에서 사건번호 하나가 맞았다는 사실만으로는 부족했다.

후보 사건번호
+ 사건명 exact match
+ 법원 exact match
+ 선고일 exact match
+ 공식 본문 header의 같은 사건번호
= OFFICIAL_IDENTITY_AND_TEXT_RETRIEVED

이 다섯 조건이 모두 맞아도 proposition_status는 별도다. 판결문이 해당 문장을 실제로 지지하는지, 사실관계와 법리가 현재 사안에 같은 방식으로 적용되는지는 다시 확인해야 한다.

🔐 두 번째 전환점 — 검색어를 저장한 뒤 지우지 않고, 저장할 필드를 처음부터 줄였다

외부 검색 서비스는 질의를 처리하기 위해 평문을 받는다. 따라서 정규식 하나로 “개인정보가 없을 것”이라고 가정하지 않았다.

전송 전 Gate

• 사용자가 공개 자료 또는 비식별 사안임을 확인해야 실행된다.

• 주민·외국인등록번호, 국내·국제형 휴대전화, 이메일, 긴 숫자 식별자, UUID, 사용자·볼륨 경로를 탐지한다.

• 탐지되면 네트워크 요청 전에 종료한다.

• 실제 의뢰인 사실은 탐지기에 맡기지 않고 사람이 먼저 비식별화한다.

저장 최소화

• 질의 원문 대신 SHA-256과 문자 수만 기록한다.

• provider의 자유서술 summary와 source_cases는 저장하지 않는다.

• 남는 구조화 식별 필드에 질의가 정확히 반사되면 [QUERY_REDACTED]로 바꾼다.

• 저장 직전에 원 질의가 남았는지 다시 재귀 검사한다.

최종 canary에서 질의 원문 hit, 비식별화되지 않은 OC, provider 자유서술 저장은 모두 0건이었다. 이 결과는 해당 공개 fixture와 검사 범위에서의 PASS다. 모든 의뢰인 정보가 자동으로 안전해진다는 뜻은 아니다.

⚙️ 실제 canary — 후보 3건과 조문 4건을 공식 경로로 넘겼다

실체법 기준일은 2002-01-15, 절차법 기준일은 2003-02-01로 분리했다. 이 날짜는 실제 의뢰 사건의 사실이 아니라, 서로 다른 시간축을 하나로 합치지 않는지 확인하기 위한 공개 fixture다.

LaWink는 다음 판례 후보 3건을 반환했다.

대법원 2002다52657 · 건물명도
대법원 87다카98 · 전부금
대법원 2006다39720 · 임대차보증금

조문 후보는 민법 제615조·제618조·제654조와 민사소송법 제425조였다. Korean-law MCP로 사건 identity와 공식 본문 header를 대조한 결과는 3/3 일치했고, 네 조문의 존재와 각 기준일 행위시법 응답도 회수됐다.

그러나 결과를 verified for drafting으로 올리지 않았다.

• 명제별 원문 근거: NOT_RUN

• 불리·제한 판례: NOT_RUN

• 절차적 지위의 완전 검토: NOT_RUN

• 행위시법 응답의 사람 법률 검토: REQUIRES_LEGAL_REVIEW

• 최종 작성 승격: BLOCKED

그림 2. 같은 시점의 lawink_discovery, official_verification, gate_receipt에서 자동 생성했다. 판례번호와 조문은 공개 법률정보다. identity 확인과 법률 의존 가능성을 다른 상태로 표시했다.

🚨 구체적인 실패 1 — manifest를 믿는 검증기는 manifest 삭제를 알아채지 못했다

v0.1.6은 겉으로는 잘 작동했다. 실제 API와 MCP를 호출했고, run manifest와 hash도 있었다. 하지만 검증기가 “manifest에 적힌 파일”만 순회했다.

복제한 run에 다음 네 가지 변조를 가했다.

1. lawink_discovery.json을 manifest inventory에서 삭제
2. discovery 파일에 query_plaintext 키 주입
3. source snapshot hash를 64개의 0으로 변경
4. manifest.run_dir을 가짜 경로로 변경

예상은 FAIL이었지만 관찰된 결과는 PASS였다. manifest가 증거가 아니라 후보가 통제하는 체크리스트가 된 것이다.

수리는 검증기가 필수 universe를 직접 소유하도록 만드는 것이었다.

검증기가 정한 필수 artifact 집합
= privacy + discovery + queue + official + gate

검증기가 정한 필수 source 집합
= CLI + verifier + 실행 wrapper + 계약·설정

manifest가 한 행을 빼면 통과하는 것이 아니라 inventory mismatch로 실패한다. 경로, bytes, SHA-256뿐 아니라 privacy → discovery → queue → official → gate의 사건번호·날짜·개수·상태 연쇄도 다시 계산하도록 바꿨다. v0.1.6은 수정하지 않고 REJECTED로 보존했다.

🚨 구체적인 실패 2 — 평문은 입력 파일이 아니라 provider 응답으로 돌아왔다

강화한 v0.1.7은 첫 번째 변조를 막았다. 하지만 시간초과된 독립심사 로그에서 더 위험한 단서가 나왔다.

LaWink가 검색어를 summary와 source_cases 값으로 그대로 되돌려 주면, 기존 정규화기는 다음처럼 모순된 상태를 만들 수 있었다.

plaintext_removed_from_saved_response: true
실제 저장된 질의 원문 hit: 2

정확한 v0.1.7에 같은 응답을 주입해 2건 잔존을 재현했다. 해결책은 “민감 문자열 목록을 더 늘리는 것”이 아니었다.

• provider 자유서술 필드를 아예 저장하지 않는다.

• 필요한 구조화 identity 필드만 새 객체로 만든다.

• 그 안에서도 정확한 질의 반사를 제거한다.

• 저장 직전 전체 객체에서 원문 부존재를 단언한다.

🚨 구체적인 실패 3 — stdio 부모는 끝났지만 자손 하나가 남았다

같은 v0.1.7에서 MCP client의 close()도 시험했다. 직접 stdio 부모는 종료됐지만, 부모가 만든 자손 프로세스 하나가 남았다.

close 전 표식 프로세스: 2
직접 부모 종료: true
close 후 자손 잔존: 1

subprocess 객체 하나에 terminate()를 호출하는 것만으로는 tree 전체가 정리되지 않았다. v0.1.8에서는 POSIX stdio MCP를 별도 session/process group으로 시작하고, 성공·오류·초기화 실패 모두에서 group 전체에 다음 순서를 적용했다.

close 요청
→ process group TERM
→ bounded wait
→ 잔존 시 process group KILL
→ group 소멸 read-back

동일 fixture를 10회 반복해 10/10에서 잔존 0을 확인했다.

🧊 세 번째 전환점 — 늦게 온 PASS보다 버전 계보를 우선했다

v0.1.7 독립심사는 뒤늦게 PASS를 반환했다. 하지만 그 심사는 이미 재현된 검색어 반사와 자손 프로세스 경로를 시험하지 않았고, 완료 시점에는 v0.1.7이 거절된 뒤였다.

따라서 PASS를 좋은 소식으로 채택하지 않았다.

reviewed bytes가 맞는가?  → 맞음
그 버전이 현재 후보인가?  → 아님
확인된 blocker를 모두 시험했는가?  → 아님
결론  → INVALIDATED_STALE_REVIEW

v0.1.8은 새로운 코드와 run, manifest, hash를 만들고 네트워크 없는 독립심사를 처음부터 다시 받았다.

그림 3. 두 거절 영수증, stale-review 무효화 영수증, v0.1.8 독립 QA에서 자동 생성했다. 이전 후보는 삭제하거나 덮어쓰지 않고 원 hash로 보존했다.

✅ Before와 After

🧾 Trace · Proof · Verdict · Repair

Trace

공개 저장소·라이선스·wrapper 구조 확인
→ 기본 uvx 호환성 실패 재현
→ 고정 커밋·격리 SDK에서 7개 MCP 도구 확인
→ 후보 발견용 계약 동결
→ 공개·비식별 privacy preflight
→ LaWink 판례 3건·조문 4건 발견
→ Korean-law MCP 공식 identity·본문·행위시법 조회
→ 87다카98 / 87다카982 citator 충돌 차단
→ v0.1.6 verifier 거짓 PASS 재현·거절
→ v0.1.7 query echo·자손 잔존 재현·거절
→ provider 최소화·process-group 정리
→ v0.1.8 새 run·20파일 동결
→ 23개 테스트·10회 정리 stress
→ exact-hash 독립 QA

Proof

• 공개 fixture의 LaWink 판례 후보 3건·조문 후보 4건

• 공식 사건번호·사건명·법원·선고일·본문 header identity 3/3 일치

• 실체법 기준일 응답 3건, 절차법 기준일 응답 1건

• 공식 조문 존재 4/4

• 87다카98 요청에 87다카982가 citator target으로 반환된 충돌 1건 차단

• 질의 평문 hit 0, 비식별화되지 않은 OC 0, provider 자유서술 저장 0

• 단위·회귀 테스트 23/23 PASS

• process-group cleanup stress 10/10 PASS

• 동결 파일 20/20 bytes·SHA-256 일치

• 독립 QA PASS_FROZEN_CANARY, blocker 0

• production MCP 등록·Gateway 재시작 없음

Verdict

lawink_discovery_lane: PASS
privacy_preflight_for_public_fixture: PASS
official_identity_layer: PASS_3_OF_3
applicable_law_responses: RETRIEVED_REQUIRES_LEGAL_REVIEW
citator_exact_target_gate: PASS_WITH_ONE_CONFLICT_BLOCKED
proposition_level_legal_review: NOT_RUN
adverse_or_limiting_authority_review: NOT_RUN
procedural_posture_review: NOT_RUN
verified_only_drafting: BLOCKED
legal_reliance_eligible: false
production_mcp_registration: NOT_RUN
external_web_or_community_publication: NOT_RUN

Repair

• manifest가 말하는 universe 대신 검증기가 필수 universe를 소유하게 했다.

• hash·경로뿐 아니라 privacy → discovery → official → gate의 의미 연쇄를 다시 계산했다.

• provider 자유서술은 redaction 대상이 아니라 비저장 대상으로 바꿨다.

• MCP 직접 부모가 아니라 process group 전체를 정리했다.

• 거절된 버전과 늦은 PASS를 보존하되 successor 승격 권한은 주지 않았다.

• 공식 identity가 맞아도 법률문서 작성 승격은 BLOCKED로 유지했다.

📋 재사용 가능한 법률 검색 MCP 도입 체크리스트

[ ] 외부 서비스가 공식 권위인지, 민간 검색·가공 계층인지 먼저 분류한다.
[ ] upstream commit, package version, license, dependency 경계를 고정한다.
[ ] 기본 설치 명령을 새 환경에서 실제 실행하고 도구 목록을 read-back한다.
[ ] 공개·비식별 확인 없이는 네트워크 요청을 시작하지 않는다.
[ ] PII 탐지기는 보조망으로만 쓰고, 실제 사실은 사람이 먼저 비식별화한다.
[ ] provider 자유서술보다 필요한 구조화 identity만 allow-list로 저장한다.
[ ] 후보에는 DISCOVERY_ONLY와 drafting_eligible=false를 기본값으로 둔다.
[ ] 사건번호·사건명·법원·선고일·본문 header를 exact match한다.
[ ] 접두어 사건번호와 citator target을 별도 검증한다.
[ ] 실체법일과 절차법일을 분리하고 경과규정을 별도 검토한다.
[ ] 후속판례 검색 성공을 법리 유지 판정으로 승격하지 않는다.
[ ] 명제별 locator·불리 판례·절차적 지위가 없으면 문서 사용을 차단한다.
[ ] manifest omission·hash refresh·경로 위조·평문 주입을 변조 fixture로 시험한다.
[ ] stdio close 뒤 직접 부모와 자손 process group이 모두 사라졌는지 확인한다.
[ ] 독립 PASS를 exact version·hash·review scope·완료 시점에 묶는다.
[ ] canary PASS와 production 등록, legal reliance, external publication을 분리한다.

💬 재사용 가능한 프롬프트

공개 법률 검색 MCP를 운영에 바로 등록하지 말고 후보 발견용 격리 canary로 평가해 주세요.

1. 저장소의 고정 커밋, 버전, 라이선스, dependency 상한과 실제 MCP 도구 목록을 확인합니다.

2. 공개 또는 사람이 비식별화한 질의만 허용하고, PII·식별자 탐지는 네트워크 전에 fail-closed로 둡니다.

3. 외부 결과는 DISCOVERY_ONLY / U0_UNVERIFIED_CANDIDATE / drafting_eligible=false로 정규화합니다.

4. 공식 법률정보 경로에서 사건번호·사건명·법원·선고일·본문 header와 조문·행위시법을 다시 확인합니다.

5. 사건번호 prefix를 exact match로 취급하지 말고 citator target mismatch를 별도 차단합니다.

6. 실체법 기준일과 절차법 기준일을 분리합니다.

7. 명제별 근거·불리 판례·절차적 지위·경과규정 검토 전에는 verified_only_drafting=BLOCKED로 둡니다.

8. provider 자유서술과 질의 반사를 저장하지 않고, 저장 직전 원문 부존재를 재검사합니다.

9. stdio MCP의 부모와 자손 process group을 success·error·init-failure 경로에서 모두 정리합니다.

10. manifest omission, refreshed-hash tamper, path forgery, plaintext injection으로 verifier 자체를 공격합니다.

11. 거절된 버전은 보존하고 successor를 새 hash로 동결한 뒤 독립 QA합니다.

12. production 등록·법률근거 승격·외부 발행은 별도 승인 전까지 수행하지 않습니다.

🌍 다른 업무에 적용한다면

이 구조는 법률 검색에만 한정되지 않는다.

• 의료 검색: 문헌 후보 발견과 환자별 진단·처방 승인을 분리한다.

• 재무 데이터: 거래 후보 매칭과 실제 장부 반영을 분리한다.

• 보안 탐지: 경보 후보와 계정 차단·격리 조치를 분리한다.

• 채용 검색: 후보 추천과 합격·불합격 결정을 분리한다.

• 규제 모니터링: 개정 후보 알림과 회사별 적용 판단을 분리한다.

공통 원리는 단순하다.

검색이 잘됨 ≠ 사실이 확정됨
사실이 확인됨 ≠ 현재 사안에 적용됨
현재 사안에 적용됨 ≠ 자동 실행이 승인됨

🚧 확인하지 않은 것

• 동일 질문 집합에 대한 LaWink와 다른 검색기의 블라인드 정확도 우열

• 모든 사건 유형·하급심·미수록 판례의 coverage

• 후속판례 전문 전체를 읽은 법리 유지·변경 판정

• 후보 3건의 명제별 proposition support

• 현재 사건에 대한 불리·제한 판례와 최강 반론

• 실제 의뢰인 사실을 사용한 개인정보 처리

• 장기 부하·장애·rate limit·재시도 운영

• production Hermes MCP 등록과 rollback drill

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

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

이 항목은 23개 테스트, 20개 hash, 공식 identity 3/3으로 대신 증명할 수 없다.

📚 도움받은 글

• ntriq, LaWink MCP — 한국 법률 지식그래프 MCP
  https://github.com/ntriq/lawink-mcp

• 이 사례에서 검토한 고정 커밋
  https://github.com/ntriq/lawink-mcp/tree/b047899e4d41bda94fda486db2fd1d91fc3d950a

• 고정 커밋의 MIT License
  https://github.com/ntriq/lawink-mcp/blob/b047899e4d41bda94fda486db2fd1d91fc3d950a/LICENSE

업스트림 README가 설명하는 서비스 규모·보안 정책·요금은 제공자의 point-in-time 설명이다. 이 사례는 그 전체를 독립 인증한 것이 아니라, 고정 wrapper와 공개 API의 후보 탐색 경로를 격리 canary에서 시험하고 공식 법률정보 재확인 Gate를 덧붙인 기록이다.

📦 산출물과 공개 경계

생성된 산출물

• 공개·비식별 preflight와 후보 발견 CLI

• Korean-law MCP 공식 identity·본문·행위시법 연결

• closed-world run verifier와 변조 fixture

• provider 질의 반사 차단과 process-group 정리

• 거절된 v0.1.6·v0.1.7 보존 영수증

• v0.1.8 20파일 동결 manifest와 독립 QA

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

• 로컬 Library용 사례게시글

공개 경계

• LaWink 후보의 법률 권위 승격: 없음

• 법률문서 자동 작성 허용: BLOCKED

• 의뢰인 식별정보 사용: 없음

• production MCP 등록·Gateway 재시작: NOT RUN

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

• 속도·비용·정확도 개선률: NOT MEASURED

최종 판정: v0.1.8은 공개·비식별 질의에서 LaWink 후보를 찾고 공식 사건 identity·조문·행위시법 재확인 경로로 넘기는 working canary다. 그러나 명제별 법률 검토와 사람 승인이 끝나지 않았으므로 legal_reliance_eligible=false, verified_only_drafting=BLOCKED다. 이 사례의 성과는 검색 결과를 많이 만든 것이 아니라, 후보를 찾은 뒤 어디에서 멈춰야 하는지를 실행 가능한 Gate로 만든 것이다.