평가기를 뒤집지 않고 법률의견서 작성 스킬을 만들었다-Scoped Gold HANDOFF를 intake·authority·exact-hash repair 회로로 전환한 사례

📝 한줄 요약

검증된 법률의견서 평가 시스템이 있다고 해서 그 점수표를 거꾸로 돌리면 좋은 의견서가 자동으로 만들어지는 것은 아니다. 이번 작업에서는 평가기의 역할을 복제하지 않는 얇은 작성 엄브렐러를 만들고, 입력 복원부터 권위 확인·쟁점 구조·내부 초안·기계 QA·고정 해시 평가·최소수리·사람 승인까지를 독립 상태로 연결했다.

바쁘시면 이것만 읽어도 됩니다.

• 출발점은 11개 산출물과 7개 평가 호출이 모두 검증된 SCOPED_GOLD: ex-ante-prediction HANDOFF였다.

• 이 Gold는 합성 사전예측 범위의 평가기 Gold이지, 작성 Gold나 실제 사건의 정답이 아니었다.

• 따라서 평가 루브릭을 역산하지 않고 intake → basis → authority → argument → draft → QA → evaluator → human 회로를 새로 만들었다.

• 자료가 충분하지 않으면 전체 의견서를 쓰지 않고 LIMITED_TO_FRAME 또는 DEFERRED 상태로 축소한다.

• 작성된 초안은 SHA-256으로 고정한 뒤 독립 evaluator에 넘기며, 수정하면 이전 평가는 즉시 STALE_AFTER_REVISION이 된다.

• 자동 최소수리는 최대 2회로 제한하고, 미해결 중요 결함은 사람 검토로 넘긴다.

• 현재 패키지는 18개 파일이며 validator, 25개 unit·boundary test, 16개 공격 변형, 신규·개정 canary, Hermes loader를 통과했다.

• 실제 의뢰인 사건, 법률적 정답, 외부 제출, 시간·비용 절감 효과는 이번 검증 범위가 아니다.

🎯 이런 분들께 도움됩니다

• 법률의견서 작성과 평가를 한 프롬프트에 섞지 않고 운영하려는 법무·감사 담당자

• 여러 AI가 높은 점수를 주면 문서가 자동으로 안전해진다고 보기 어려운 분

• 사실·가정·법령·판례·증거·기준일을 초안 전에 분리하고 싶은 분

• 자료가 부족할 때 AI가 그럴듯한 완성 의견서를 쓰는 문제를 막고 싶은 분

• 수정 전후 문서와 평가 결과의 대상 hash를 추적하고 싶은 AI 워크스페이스 운영자

• “도구가 성공했다”는 메시지보다 실행 receipt와 사람 승인 경계를 중시하는 분

😫 문제 상황 — 좋은 평가기를 그대로 뒤집으면 좋은 작성기가 될까

이번 작업의 직접적인 출발점은 다음 제안이었다.

“이거 참조해서 내가 생각할 때는 이 스킬을 활용해서 법률의견서 작성 스킬을 만들 수 있을 것 같아.”

참조된 HANDOFF에는 단순한 아이디어가 아니라 실제 실행 흔적이 들어 있었다.

• manifest에 등재된 산출물 11개

• control·final 실행의 evaluator 호출 7개

• 7개 호출 모두 성공

• 최종 점수 94.0

• PASS

• SCOPED_GOLD: ex-ante-prediction

• 원문·input·job spec·submission receipt·terminal status의 SHA-256

겉으로 보면 답은 간단해 보인다.

좋은 평가 기준이 있다
→ 그 기준을 작성 프롬프트로 바꾼다
→ 높은 점수를 받을 문서를 쓴다

하지만 이 방식에는 세 가지 문제가 있었다.

1. 평가는 관측이고 작성은 상태 전이다

평가기는 주어진 문서와 근거를 읽고 결함을 찾는다. 작성기는 아직 문서가 없는 상태에서 질문·사실·권위·쟁점을 복원하고, 무엇을 쓰지 말아야 하는지까지 결정해야 한다. 두 작업의 입력과 실패 조건이 다르다.

2. 점수를 목표로 삼으면 장식 신호를 학습할 수 있다

제목을 길게 쓰고, 문장을 늘리고, 인용 수를 많게 하고, 입력 metadata에 “100점”이나 “Gold”를 붙이는 것은 문서의 법률적 근거를 강화하지 않는다. 평가 점수를 직접 최적화하면 이런 장식 신호가 작성 품질로 오인될 수 있다.

3. 합성 Gold의 범위를 넘기 쉽다

HANDOFF의 Gold는 합성 법률의견서에 대한 사전예측형 평가 실행에 한정됐다. 실제 의뢰인 사건의 법률적 정답, 사후 결과 일치, 외부 제출 승인까지 보장하는 Gold가 아니었다. 이 경계를 작성 스킬이 넓혀 해석하면 검증된 출발점을 오히려 훼손한다.

그래서 이번 과제는 “94점을 받을 문서를 자동으로 써라”가 아니라 다음처럼 다시 정의했다.

검증된 평가 계약은 독립적으로 보존하고, 작성 단계의 입력·근거·권위·쟁점·초안·수리 상태를 명시적으로 연결하라. 점수는 승격 권한으로 사용하지 말라.

🛠️ 사용한 도구와 정본

• Hermes Agent: 전체 작업 조율, 실제 skill loader canary, 기록 동기화

• 검증된 HANDOFF와 manifest: 11개 산출물·7개 평가 호출·Scoped Gold 범위 확인

• legal-opinion-evaluator 5.3.0: 작성 후 독립 평가 계약

• contract schema 5.1: 평가 receipt와 상태 필드의 pin

• Python deterministic compiler: canonical input JSON을 내부용 Markdown 초안으로 컴파일

• unit·boundary·metamorphic test: fail-closed와 anti-Goodhart 경계 검사

• SHA-256: 입력·원문·초안·수정본·평가 대상 고정

• 공동 DEVLOG·Chronicle: 최초 요청부터 설계·실패·보강·완료까지 시간순 대조

• 데이터 기반 SVG 증거 카드: 실행 receipt의 수치와 상태를 자동 렌더링

시간 절약률, 비용 절감률, 실제 법률업무의 승소·처분 결과 개선은 측정하지 않았다. 따라서 이 글에는 그런 효과를 임의로 수치화하지 않는다.

🔧 작업 과정

1. 먼저 HANDOFF의 완전성과 범위를 닫았다

참조 폴더가 있다는 사실만으로 출발점을 확정하지 않았다. manifest에 등재된 11개 파일을 다시 읽고 다음 항목을 대조했다.

이 단계에서 가장 중요한 것은 94라는 숫자가 아니라 그 숫자가 말할 수 있는 범위와 말할 수 없는 범위였다.

2. 기존 legal skill을 복제하지 않고 역할을 분리했다

새 skill 안에 intake, authority, citation, adversarial review, evaluator의 모든 내용을 다시 써 넣으면 금방 거대한 monolith가 된다. 기존 정본이 업데이트될 때 새 skill이 뒤처질 위험도 커진다.

그래서 새 skill의 책임을 다음으로 제한했다.

legal-opinion-authoring
├─ 입력 계약과 mode 선택
├─ 자료 충분성 gate
├─ 사실·가정·권위·쟁점 ID 연결
├─ 내부용 독립 초안 컴파일
├─ 기계 QA와 output hash 생성
├─ evaluator exact-hash handoff
└─ 최소수리·재평가·사람 승인 상태 조율

실질 법률판단과 권위 검증은 기존 법률 검토 체계를 호출하고, evaluator는 계속 독립된 sibling skill로 유지했다. 새 skill은 오케스트레이터이자 결정론적 helper이지 새로운 법률 데이터베이스나 자동 승인기가 아니다.

3. 자료 충분성을 세 상태로 나눴다

입력 부족을 단순 오류로만 반환하면 사용자는 무엇을 더 줘야 하는지 알기 어렵다. 반대로 부족한 자료를 무시하고 초안을 완성하면 환각 위험이 커진다. 그래서 authoring gate를 세 상태로 만들었다.

LIMITED_TO_FRAME은 실패를 감추는 중간 상태가 아니다. 지금 확인된 것과 확인되지 않은 것을 구분해 안전하게 계속 작업할 수 있는 산출물이다.

4. 입력을 ID 기반 canonical contract로 고정했다

작성 helper가 자연어 메모를 읽고 임의로 연결 관계를 추정하지 않도록 주요 객체에 ID를 부여했다.

• 질문: Q-*

• 사실: F-*

• 권위: A-*

• 쟁점: I-*

• 증거·자료: E-*

• 평가 finding: EV-*

각 쟁점은 관련 질문·사실·권위·증거 ID를 참조한다. 존재하지 않는 ID를 참조하거나, 검증되지 않은 권위를 verified로 표시하거나, 필수 텍스트가 빈 문자열이면 컴파일이 닫힌다.

이 구조의 목적은 법률문서를 JSON처럼 보이게 만드는 것이 아니다. 초안의 각 결론이 어떤 사실과 권위에 기대는지 역추적할 수 있게 하는 것이다.

5. 신규 작성과 개정을 다른 회로로 만들었다

신규 mode는 검증된 input pack에서 내부용 초안을 만든다. 개정 mode는 원문 의견서의 경로와 hash, evaluator finding, 수리 범위를 함께 요구한다.

신규
input pack
→ gate
→ internal draft
→ mechanical QA
→ output SHA-256
→ independent evaluator

개정
source opinion + source SHA-256 + findings
→ 최소수리
→ 새 output SHA-256
→ 이전 평가 STALE
→ 현재 hash 재평가

수정본이 생겼는데 이전 점수를 그대로 유지하면 평가 대상이 달라진다. 그래서 revision canary는 평가 상태를 STALE_AFTER_REVISION으로 만들고 RE_EVALUATE_CURRENT_HASH를 다음 상태로 남긴다.

6. 자동 수리를 최대 2회로 제한했다

평가 결과를 계속 따라가며 무한 수정하면 문서는 결함을 고치는 대신 평가기 취향에 과적합될 수 있다. 이를 막기 위해 자동 최소수리를 최대 2회로 제한했다.

• 1회차: 중요 결함의 최소수리

• 새 hash 생성

• 현재 hash 재평가

• 2회차: 남은 중요 결함의 최소수리

• 그래도 해결되지 않으면 HUMAN_REVIEW

사람 검토는 마지막 장식 단계가 아니라 release 권한을 가진 독립 상태다. evaluator 점수는 사람 승인이나 외부 공개를 대신하지 않는다.

7. 공격적 테스트에서 두 가지 실제 결함을 발견했다

첫 구현이 unit test를 통과했다고 경계가 완성된 것은 아니었다. 독립 리뷰와 공격적 변형에서 다음 허점이 드러났다.

실제 날짜가 아닌 문자열

처음의 날짜 검사는 YYYY-MM-DD 모양만 확인했다. 따라서 2026-02-30처럼 달력에 없는 날짜도 형식상 통과할 수 있었다. 이후 실제 calendar date를 파싱하도록 고쳤다.

boolean처럼 보이는 truthy 값

synthetic 필드가 문자열 "false"여도 일부 언어에서는 참으로 취급될 수 있다. 이후 정확한 boolean type만 허용하고 문자열·숫자 대체값은 거절하도록 고쳤다.

그 밖에도 깨진 reference, 불완전한 권위 receipt, 절대경로 노출, new mode의 repair ledger, 과도한 repair round, 장식적 분량 증가와 미검증 점수 주입을 공격 변형으로 확인했다.

최종 독립 red-team 기록은 다음과 같다.

16 adversarial variants
unsafe accepts 0
status PASS

8. “통과”를 여러 증거층으로 나눠 재실행했다

최종 검증에서는 하나의 성공 메시지에 의존하지 않았다.

사례글을 준비하면서 execution collector 자체도 한 번 실패했다. 첫 collector는 canary 파일명을 고정해 두어 두 번째 실행 때 기존 산출물 덮어쓰기 방화벽에 막혔다. 방화벽을 끄지 않고, collector가 매 실행마다 timestamped immutable run 디렉터리를 만들도록 수정했다. 재실행 가능성을 위해 원본 보호 규칙을 약화하지 않은 것이 중요했다.

✅ 결과 — 점수를 잘 받는 문서가 아니라 상태를 설명할 수 있는 작성 회로

Before vs After

현재 검증된 패키지 좌표는 다음과 같다.

legal-opinion-authoring v0.2.0
schema 1.1
18 package files
legal-opinion-evaluator 5.3.0
contract schema 5.1
max automated repair rounds 2
package tree SHA-256
2a3301542d376933705e31ba258049b731d250df2b45457e4d5a924fbc8474a9

이 결과가 의미하지 않는 것

• 실제 의뢰인에게 법률자문을 제공했다는 뜻이 아니다.

• 합성 fixture의 결론이 특정 실제 사건의 법률적 정답이라는 뜻이 아니다.

• evaluator 94점이 승소·처분·계약 결과를 예측한다는 뜻이 아니다.

• 사람 검토 없이 외부 제출 가능한 최종 의견서가 되었다는 뜻이 아니다.

• Library 발행이 외부 웹이나 커뮤니티 공개를 뜻하지 않는다.

• 시간·비용 절감률이 측정됐다는 뜻이 아니다.

💡 이번 작업에서 확인한 AI 활용 원칙

효과적이었던 것

1. Gold보다 Gold의 범위를 먼저 읽기

   • 높은 수치보다 source bundle, manifest, verification status, scope label을 먼저 확인했다.

2. 평가기와 작성기의 정보 책임을 분리하기

   • 작성기는 자료와 논증을 구성하고, 평가기는 고정된 산출물의 결함을 관측한다.

3. 부족한 입력에 유용한 축소 산출물을 정의하기

   • 완성본 또는 실패의 이분법 대신 쟁점 골격·누락자료표를 안전한 중간 결과로 만들었다.

4. 수정할 때 점수가 아니라 대상 hash를 바꾸기

   • 새 문서는 새 평가 대상이다. 이전 평가는 자동으로 stale 처리해야 한다.

5. 테스트를 장식 신호에도 적용하기

   • 분량, 제목, 인용 수, 입력 metadata의 미검증 점수가 release를 승격하지 못하게 했다.

6. 검증 도구 자체도 반복 실행해 보기

   • collector의 고정 출력명이 두 번째 실행에서 실패하면서 immutable run 구조의 필요성을 확인했다.

이렇게 하면 안 됩니다

1. evaluator의 루브릭을 그대로 작성 프롬프트로 뒤집기

2. 여러 evaluator의 다수결을 법률 권위나 사실 확인으로 대체하기

3. LIMITED 자료로 완성 의견서처럼 쓰기

4. 수정 후에도 이전 평가 점수와 receipt를 그대로 사용하기

5. 자동 repair를 무한 반복하기

6. 합성 fixture를 실제 법률자문이나 외부 release 근거로 표현하기

7. validator PASS만 보고 runtime·loader·output hash read-back을 생략하기

🌍 다른 업무에 적용한다면

이 패턴은 법률의견서에만 한정되지 않는다. 작성과 평가가 함께 필요한 고위험 문서에 적용할 수 있다.

감사보고서

감사 범위·증거 gate
→ 제한사항이 있으면 LIMITED
→ 초안 hash
→ 독립 품질평가
→ finding별 최소수리
→ 책임자 승인

정책 검토서

정책 질문·기준일·권위 원문
→ 이해관계자·대안·부작용 구조
→ 초안
→ 사실·인용·반론 평가
→ 사람 검토

기술 아키텍처 결정 기록

요구사항·제약·실측치
→ 대안과 trade-off
→ ADR 초안 hash
→ 독립 architecture review
→ 현재 hash에 대한 승인

공통점은 “평가 점수를 높이는 문서”보다 입력 부족, 근거 연결, 수정 이력, 승인 권한을 설명할 수 있는 문서를 먼저 만든다는 것이다.

🤝 배워서 남 주기

재사용 가능한 핵심은 특정 법률 분야의 문구가 아니라 다음 제어 구조다.

검증된 source bundle
→ 범위·정본 확인
→ 작성 gate
→ ID 기반 근거 연결
→ 내부 초안
→ 기계 QA
→ output hash
→ 독립 evaluator
→ 최대 2회 최소수리
→ 사람 승인
→ 별도 release

이 구조를 복사할 때에는 evaluator 버전·contract schema·artifact hash를 함께 pin해야 한다. 셋 중 하나라도 달라지면 과거 평가를 현재 문서의 권위로 사용해서는 안 된다.

🕊️ 홍익인간 관점

AI 법률문서의 위험은 틀린 문장만이 아니다. 자료가 부족한데도 완성되어 보이는 문서, 무엇을 평가했는지 모르는 점수, 수정본에 남아 있는 과거 승인, 합성 검증을 실제 사건의 확실성으로 넓혀 말하는 방식도 신뢰 비용을 만든다.

이번 구조는 문서를 더 화려하게 만드는 대신 다음 질문에 답할 수 있게 한다.

• 무엇을 입력으로 사용했는가?

• 무엇이 부족했는가?

• 어떤 사실과 권위가 어떤 쟁점에 연결됐는가?

• 어느 문서 hash를 평가했는가?

• 몇 번 자동수리했는가?

• 누가 최종 승격을 승인해야 하는가?

• 무엇은 아직 검증하지 않았는가?

이 질문에 답할 수 있으면 AI를 처음 쓰는 사람도 “높은 점수니까 믿는다”가 아니라 근거·상태·경계를 보고 판단하는 습관을 가질 수 있다.

🚀 다음 단계

현재 완료 범위는 합성 fixture를 이용한 legal-opinion-authoring v0.2.0의 설계·구현·독립 리뷰·검증·Library 사례 기록까지다.

다음 단계는 별도 검증이 필요하다.

1. 비민감·비식별 실제 업무 fixture에서 intake 질문의 충분성을 점검한다.

2. 법 분야별 authority adapter가 같은 canonical contract를 유지하는지 확인한다.

3. 사람이 evaluator finding을 채택·기각한 이유를 별도 decision record로 남긴다.

4. 외부 제출 전 redline·citation 원문·행위시법·개인정보 검토를 독립 Gate로 연결한다.

이 항목들은 아직 현재 패키지의 검증 완료 범위에 포함되지 않는다.

📋 재사용 가능한 프롬프트

프롬프트 1: 법률의견서 신규 작성 gate

다음 자료로 법률의견서 작성 가능 상태를 먼저 판정해 주세요.

1. 법률 질문, 법적 효과, 관할, 기준일을 분리합니다.

2. 사실·가정·누락·다툼을 구분합니다.

3. 법령·판례·계약·증거의 원문과 검증 상태를 기록합니다.

4. READY_TO_DRAFT, LIMITED_TO_FRAME, DEFERRED 중 하나를 반환합니다.

5. READY가 아니면 완성 의견서를 쓰지 말고, 허용된 축소 산출물과 최소 추가자료 목록을 만듭니다.

6. 새로운 사실·권위·날짜를 추정하지 않습니다.

대상 자료: [자료 입력]

프롬프트 2: 고정 hash 기반 독립 평가

첨부 의견서를 독립 평가하되 평가 대상을 먼저 고정해 주세요.

1. 의견서 파일의 SHA-256을 계산합니다.

2. 사용한 evaluator 버전과 contract schema를 기록합니다.

3. 결함마다 finding ID, 위치, 영향, 필요한 수리, 재검증 조건을 적습니다.

4. 점수는 release 권한으로 사용하지 않습니다.

5. 수정본이 생기면 이전 평가를 STALE로 바꾸고 새 hash만 재평가합니다.

6. 실제 권위 원문과 사람 검토가 없으면 외부 승인으로 승격하지 않습니다.

프롬프트 3: 최소수리와 중단 조건

다음 evaluator finding을 점수 상승용 재작성으로 처리하지 말고 최소수리해 주세요.

1. 현재 원문 hash와 finding의 artifact hash가 같은지 확인합니다.

2. finding별로 필요한 최소 구간만 수정합니다.

3. 새 문서 hash와 변경 ledger를 만듭니다.

4. 자동수리는 최대 2회까지만 허용합니다.

5. 2회 후 중요 결함이 남으면 더 수정하지 말고 HUMAN_REVIEW로 넘깁니다.

6. 제목·분량·인용 수·미검증 점수만 늘려 release 상태를 바꾸지 않습니다.