‘사실관계 넣으면 서면으로’는 살리고, 통째 도입은 기각한 사례

외부 법률 Skill의 짧은 진입 경험은 흡수하되, 공식 원문·행위시법·판례 생사·반대근거를 확인하지 못하면 제출용 문구를 만들지 않는 내부 Gate를 유지한 선택적 통합 기록이다.

한눈에 보기

검토 대상: 공개 GitHub 저장소 skillnara/legal-basis-finder
외부 Skill이 제안한 가치: 사실관계 입력 → 쟁점 → 법조항 → 유사판례 → 서면용 문구의 5단계 흐름
채택한 것: 간단한 사실 입력, 눈에 보이는 검증 상태, 검증된 근거만 문안에 넣는 사용자 경험
채택하지 않은 것: 외부 Skill의 설치·복제, 문구·예시 재사용, 별도 법률검토 umbrella 추가
내부 보강 결과: Fast / Normal / Hard, P1 / S1 / U0 / C0, verified-only drafting Gate
검증 결과: 정적·구조 검사 18/18 PASS, 정책 카나리 7/7 PASS, fresh runtime GATE=BLOCKED
중요한 한계: 실제 판례 검색 정확도, 자동 Skill 선택 성능, 실사건의 법률 결론은 이번 검증 범위가 아니다.

1. 문제: 좋은 첫 화면과 안전한 마지막 문장은 서로 다른 문제다

법률 AI의 진입 장벽을 낮추는 문장은 단순하다.

“사실관계를 입력하면 쟁점과 근거를 찾아 서면에 쓸 문구까지 정리한다.”

legal-basis-finder는 이 약속을 5개 구역으로 명확하게 보여준다. 사실관계를 시간순·당사자별로 정리하고, 상대방 쟁점까지 도출한 뒤, 법조항과 판례를 확인하고, 마지막에 쟁점별 메모와 서면용 인용 문구를 제시한다. 확인된 항목과 미확인 항목을 ✅ 검증과 ⚠️ 미검증으로 나누려는 방향도 분명하다.

문제는 마지막 한 걸음이다. “찾았다”와 “제출용 문구에 넣어도 된다” 사이에는 다음과 같은 별도의 검증이 필요하다.

공식 원문에서 실제 조문·판결문을 확인했는가?
사건 당시 적용되는 법과 현재 법을 구분했는가?
판급, 후속심, 변경·폐기 여부를 확인했는가?
직접 인용이면 정확한 pinpoint와 원문 대조가 가능한가?
유리한 자료뿐 아니라 불리한 판례와 구별점도 검토했는가?
외부 검색 전에 사건 당사자의 개인정보와 전략정보를 최소화했는가?

따라서 이 작업의 핵심은 외부 Skill을 “좋다/나쁘다”로 평점화하는 데 있지 않았다. 짧은 진입 경험은 살리면서도, 제출 단계의 신뢰성 기준을 낮추지 않는 구조를 만드는 데 있었다.

그림 1. 2026-08-11 실제 브라우저 캡처. 공개 저장소 이름, 파일 목록, 커밋 단축 해시 e4d1c93, README의 5단계 흐름과 “인용을 지어내지 않습니다” 구역이 보인다. 별도 로그인이나 비공개 화면은 포함하지 않았다.

2. 원본을 먼저 고정했다

검토는 README의 소개 문구만 보고 끝내지 않았다. 기준 시점을 고정한 뒤 실제 파일과 배포 패키지를 함께 확인했다.

점검 대상

확인 결과

의미

기준 커밋

e4d1c9348f57497ab060212714c7cc594b830936

분석 대상 버전을 고정했다.

원본 SKILL.md

6,917 bytes · SHA-256 6a4eec0b…bbb223

README가 설명한 5단계 절차를 실제 Skill 본문에서 확인했다.

배포 .skill

3,117 bytes · SHA-256 32a16542…134ac8

ZIP 내부에 legal-basis-finder/SKILL.md 한 파일만 있었다.

패키지 동일성

내부 SKILL.md 해시 일치

내려받은 패키지가 저장소 본문과 같은 파일임을 확인했다.

실행 코드·의존성

없음

독립 검색엔진이라기보다 Markdown 기반 작업 절차에 가깝다.

자동 검증 테스트

확인되지 않음

예시 문서는 실행 증거가 아니라 출력 형식 예시로 다뤘다.

표준 라이선스

파일·GitHub 메타데이터에서 확인되지 않음

문구·예시를 복제하지 않는 보수적 경계를 택했다.

예시 문서의 조문·판례는 [법원명], [선고일], [사건번호] 같은 플레이스홀더로 구성되어 있었다. 이것은 형식을 설명하는 데에는 유용하지만, 실제 판례 검색 정확도나 법률 결론의 정당성을 증명하지는 않는다.

3. 무엇을 살리고 무엇을 기각했는가

3.1 살린 것

외부 저장소에서 가치가 분명한 부분은 다음 세 가지였다.

간단한 진입점: 복잡한 법률 분류를 먼저 요구하지 않고 원사실에서 시작한다.
눈에 보이는 상태: 각 근거가 확인되었는지 사용자가 빠르게 구분할 수 있다.
문안의 별도 구역: 분석 메모와 실제 서면에 옮길 수 있는 문구를 구분한다.

3.2 기각한 것

다음은 도입하지 않았다.

외부 Skill의 교체 설치 또는 병렬 설치
외부 문구와 예시의 복제
보조출처를 공식 원문과 같은 등급으로 취급하는 방식
“웹에서 찾음”만으로 직접 인용을 허용하는 방식
행위시법·부칙·경과규정 확인 없이 현재 조문을 사건에 적용하는 방식
후속심이나 판례 생사를 닫지 않은 채 제출용 문구를 완성하는 방식

여기서 “기각”된 것은 사용자 가치가 아니라 통째 도입안이다. 기존 법률 검토 체계가 이미 더 넓은 검증 경계를 갖고 있었으므로, 새 umbrella를 만드는 대신 기존 canonical을 KEEP / ENRICH했다.

그림 2. 데이터 파생 증거 카드. 외부 저장소의 강점, 도입 판정, 내부 v1.2의 보강 결과를 원본 Skill·내부 manifest·검증 영수증에서 재구성했다. 실제 제품 화면이 아니다.

4. 해결 구조: 간단한 입구, 더 엄격한 출구

기존 legal-review-sequence는 1.1.0에서 1.2.0으로 보강되었다. 외부 Skill을 설치하거나 두 번째 법률검토 체계를 만들지 않고, 다음 네 층을 기존 umbrella 안에 추가했다.

4.1 위험도에 따른 세 가지 진입 모드

Fast: 간단한 사실관계에서 빠르게 쟁점 구조와 근거 후보를 만든다.
Normal: 분석과 검증을 균형 있게 진행한다.
Hard: 실제 제출용 인용을 염두에 두고 공식 원문·적용시점·판급·후속심·pinpoint까지 요구한다.

모드를 고르지 않았다고 안전 기준이 사라지지는 않는다. 정보가 부족하면 보수적으로 승격하고, 제출용 문구 요청은 Hard 경계로 처리한다.

4.2 네 단계 근거 상태

상태

의미

제출용 문구

P1

공식 원문을 열어 동일성·적용시점·판급·인용 범위를 확인

조건을 모두 통과한 경우에만 허용

S1

신뢰 가능한 보조출처에서 확인했지만 공식 원문은 닫히지 않음

차단

U0

검색 후보 또는 단서만 존재

차단

C0

출처 간 충돌, 적용시점 불명, 판례 생사 불명

차단

초록색 체크 하나로 끝내지 않고, 무엇을 어디까지 확인했는지가 상태에 포함된다. 보조출처는 검색과 cross-check에 쓸 수 있지만, 보조출처 자체가 공식출처로 승격되지는 않는다.

4.3 verified-only drafting Gate

제출용 문구에 들어갈 근거는 다음 조건을 모두 통과해야 한다.

공식 법령 또는 공식 판결문 원문 확인
사건 당시 적용법과 시행일·부칙·경과규정 확인
사건번호·법원·선고일·판급 및 후속심 확인
직접 인용이면 pinpoint와 원문 read-back 완료
요약이면 원문의 범위를 넘지 않는지 확인
불리한 판례·제한·구별 가능성 검토

하나라도 닫히지 않으면 문안을 그럴듯하게 채우지 않는다. 상태는 BLOCKED로 남고, 부족한 근거와 다음 확인 절차만 제시한다.

4.4 개인정보와 사건 전략의 경계

법률 검색은 사실관계가 구체적일수록 좋아 보이지만, 실제 사건정보를 그대로 외부 검색창에 넣는 것은 별도의 위험이다. 그래서 검색 전에 이름, 주소, 연락처, 계좌, 주민등록번호, 내부 전략과 같은 식별정보를 제거하거나 토큰화하도록 했다. 검색의 편의보다 비밀유지 경계를 먼저 고정한 것이다.

5. 검증: “잘 쓴다”보다 “못 쓰면 멈춘다”를 시험했다

5.1 정적·구조 검사

YAML/frontmatter, 지원파일 링크, 모드, 검증 상태, 시점법, 반대판례, 개인정보 경계 등을 검사한 결과 18/18 PASS였다.

5.2 정책 카나리

다음 실패조건이 제출용 문구로 새어 나오지 않는지 결정론적으로 확인했다.

S1, U0, C0 근거
pinpoint가 없는 직접 인용
후속심을 확인하지 않은 판례
적용일을 확인하지 않은 법령

정책 카나리는 7/7 PASS였다.

5.3 별도 Hermes runtime

새 세션에서 합성 사실관계와 제출용 인용 요청을 넣었다. 관측 결과는 다음과 같았다.

MODE=Hard
STATUSES=P1,S1,U0,C0
GATE=BLOCKED

런타임은 확인되지 않은 법령·조문·사건번호를 만들어내지 않았고, 제출용 문구를 완성하지 않았다. 종료 후 MCP coroutine cleanup 경고가 있었지만 프로세스 exit code는 0이었고, 응답 내용과 Gate 판정에는 영향을 주지 않아 경고를 검증 영수증에 그대로 남겼다.

그림 3. 실행 증거 카드. validation-report.json과 fresh runtime canary의 관측값을 시각화했다. live UI 캡처가 아니며, 카드 오른쪽에는 이번 검증이 주장하지 않는 범위를 함께 표시했다.

6. 결과: UX는 짧아졌고, 증거 기준은 낮아지지 않았다

이번 선택적 통합으로 바뀐 것은 “어떻게 시작하는가”와 “언제 멈추는가”다.

이전의 부담

보강 후

사용자가 복잡한 법률 분류를 먼저 알아야 했다.

간단한 원사실에서 Fast / Normal / Hard로 진입한다.

검증 여부가 하나의 체크표시로 평탄화될 수 있었다.

P1 / S1 / U0 / C0로 출처와 미완료 경계를 드러낸다.

분석 메모와 제출용 문구의 경계가 흐려질 수 있었다.

verified-only drafting Gate가 둘을 분리한다.

현재 조문과 사건 당시 법이 섞일 수 있었다.

행위시법·시행일·부칙·경과규정을 별도로 확인한다.

유리한 판례만 모을 유인이 있었다.

지지·불리·제한·구별 방향을 함께 기록한다.

정보 부족을 그럴듯한 완성으로 감출 수 있었다.

근거가 닫히지 않으면 BLOCKED로 종료한다.

외부 저장소의 핵심 UX는 이미 내부 체계에 더 엄격한 형태로 들어왔다. 따라서 현재 시점의 결론은 다음과 같다.

외부 Skill의 교체 도입·병렬 설치·문구 복제: NO-GO
현행 legal-review-sequence v1.2 유지: GO
내부 Fast 결과를 5개 요약 카드와 접힌 상세근거로 표시하는 독자 renderer: CONDITIONAL GO

7. 실패와 한계도 결과다

이 사례는 다음을 증명하지 않는다.

실제 사건군에서 유사판례 검색의 precision·recall이 높다는 점
불리한 판례 회수율이 충분하다는 점
아무런 명시 없이 자동으로 올바른 Skill이 선택된다는 점
공식 근거가 주어지지 않은 실사건에서 법률 결론이 정확하다는 점
변호사 승인 없이 대외 제출 가능한 서면이 완성된다는 점

실제 추천 성능을 주장하려면 동일 사건 gold set을 고정하고, 판례 적중률·누락률·불리한 판례 회수율·잘못된 인용률을 별도로 평가해야 한다. 이번 검증의 성공 기준은 정답률이 아니라 미검증 근거가 제출용 문구로 통과하지 않는가였다.

8. 재사용 가능한 원칙

원칙 1. 저장소의 슬로건과 실제 artifact를 분리한다

README의 약속, 실제 Skill 본문, 배포 패키지, 예시, 테스트의 존재 여부를 각각 확인해야 한다. 특히 예시의 플레이스홀더를 실제 실행 증거로 읽지 않는다.

원칙 2. 외부 아이디어와 외부 문구는 같은 것이 아니다

좋은 구조를 배웠다고 해서 원문을 복제할 필요는 없다. 라이선스와 provenance가 불명확하면 의미·경계·테스트를 독자적으로 다시 설계한다.

원칙 3. 출처 상태와 문안 허용 상태를 분리한다

검색 후보가 존재한다는 사실은 제출 허용을 뜻하지 않는다. S1 / U0 / C0는 분석에는 남길 수 있지만, 제출용 문구에는 들어가지 못하게 한다.

원칙 4. 가장 강한 기능은 생성이 아니라 차단일 수 있다

법률 AI에서 신뢰성은 더 많은 문장을 만드는 능력만으로 측정되지 않는다. 근거가 부족할 때 정확히 멈추고, 무엇이 부족한지 설명하는 것이 더 중요한 기능일 수 있다.

원칙 5. UX 개선은 안전 기준의 할인 사유가 아니다

입력은 짧게 만들 수 있지만, 공식 원문·행위시법·판급·후속심·pinpoint·반대근거의 검증은 줄여서는 안 된다. 좋은 설계는 입구를 단순화하면서 출구의 Gate를 더 분명하게 만든다.

9. 적용 체크리스트

외부 법률 AI Skill이나 저장소를 검토할 때 다음 순서로 확인할 수 있다.

기준 커밋과 원본 파일 해시를 고정했는가?
README, 실제 Skill, 배포 패키지, 예시를 따로 확인했는가?
예시와 실제 실행 증거를 구분했는가?
공식출처와 보조출처의 역할을 분리했는가?
현행법과 행위시법을 구분했는가?
판급·후속심·판례 생사를 확인하는 Gate가 있는가?
직접 인용의 pinpoint와 read-back 규칙이 있는가?
유리·불리·제한·구별 판례를 함께 다루는가?
외부 검색 전에 개인정보를 최소화하는가?
미검증 근거가 제출용 문구로 들어가지 않는 실패 테스트가 있는가?
라이선스가 불명확할 때 복제 대신 독자 재구성을 택했는가?
실제 검색 성능과 fail-closed 정책 검증을 혼동하지 않았는가?

10. 근거와 재현 경계

공개 원본

내부 검증 artifact

legal-review-sequence v1.2.0
quick-intake-verified-drafting.md
quick-legal-review.md
artifact-manifest.yml
validation-report.json
runtime-canary.md

내부 artifact는 로컬 검증 묶음에 해시와 함께 보존되어 있다. 본문에는 개인 사건정보, 자격증명, 비공개 URL, 로컬 절대경로를 싣지 않았다.

마무리

이 사례에서 얻은 결론은 “외부 Skill보다 내부 Skill이 더 좋다”는 단순 비교가 아니다. 핵심은 좋은 진입 경험과 안전한 제출 경계를 분해한 뒤, 각각을 가장 적합한 위치에 다시 결합한 것이다.

“사실관계 넣으면 서면으로”라는 약속은 살렸다. 다만 그 사이에 공식 원문, 적용시점, 판례 생사, 반대근거와 개인정보 경계를 세웠다. 그리고 근거가 닫히지 않으면 문장을 완성하는 대신 멈추도록 했다.

그 결과 통째 도입은 기각되었지만, 좋은 아이디어는 더 엄격한 형태로 살아남았다.

🔥<24기 AI 스터디> 10/2 오후 3시까지 신청·변경 가능 🔥