Hermes로 법률의견서 평가를 세 갈래로 나누고, 조정자까지 검증해 보았습니다

📝 한줄 요약

법률의견서 평가를 한 명의 평가자가 한 번에 판단하는 방식에서, 세 명의 독립 평가자·검증자·조건부 조정자가 역할을 나누는 방식으로 바꾸어 보았습니다. 실제로 합성 납품지연 의견서를 실행한 결과 7회 호출이 모두 성공했고, 최종 점수는 80.0이었지만 Gold는 실제 승소가 아니라 SCOPED_GOLD: ex-ante-prediction으로 한정했습니다.

바쁘시면 이것만 읽어도 돼요:

• 시작점은 “평가자를 세 명으로 늘리자”가 아니라 “어떤 의견서에 어느 정도의 검증이 필요한가”를 고르는 구조였습니다.

• 평가자 A는 범위·사실·출처, B는 법리·권위·논증, C는 증거·사용성·반론을 맡았습니다.

• 검증자는 평가자 점수를 보기 전에 자기 체크리스트를 먼저 작성했고, 조정자는 평균·다수결 대신 충돌 문항만 다시 읽었습니다.

• 실제 canary는 7회 호출·7회 성공·retry 0회였고, A 77.0·B 84.75·C 80.0에서 최종 80.0을 확인했습니다.

• 법령 제390조·제393조·제396조의 citation map은 모두 통과했지만, 실제 판결·처분·승소·손해액은 검증하지 않았습니다.

• 가장 큰 교훈은 모델 수가 아니라 독립성, 공식 권위의 범위, 불확실성 공개, 재현 가능한 기록이 평가 신뢰성을 만든다는 점입니다.

🎯 이런 분들께 도움돼요

• AI로 법률의견서나 법률 검토문을 반복 평가하는 법무 담당자

• 여러 모델을 사용하지만 단순 평균이나 다수결에 의존하고 싶지 않은 분

• 법령·판례·증거·기준일을 함께 검토해야 하는 연구자와 감사 담당자

• 아직 판결이나 처분이 없는 사전예측형 의견서를 평가하는 분

• AI 평가 결과를 Gold로 저장하기 전에 근거와 한계를 확인하고 싶은 분

• 평가 시스템을 만들면서도 실제 사용자가 이해할 수 있는 사례글이 필요한 분

😫 문제 상황 (Before)

법률의견서 평가는 처음에는 다음 네 단계로 끝낼 수 있을 것처럼 보였습니다.

의견서 읽기
→ 점수 매기기
→ 잘한 점과 부족한 점 쓰기
→ 수정 방향 제시하기

하지만 실제로는 한 문서 안에 서로 다른 종류의 판단이 동시에 들어 있었습니다.

• 의뢰인의 질문에 답했는가

• 사실과 가정을 구분했는가

• 기준일에 맞는 법령을 사용했는가

• 법률요건과 결론을 연결했는가

• 주장을 어떤 증거로 입증할 것인가

• 상대방은 어떤 반론을 할 것인가

• 실제 실무자가 다음에 무엇을 해야 하는가

이 모든 항목을 한 명의 평가자가 한 번에 읽으면, 점수가 그럴듯하게 나와도 무엇을 놓쳤는지 확인하기 어려웠습니다. 법률의견서에서는 특히 다음과 같은 오류가 위험했습니다.

• 존재하지 않는 판례를 사실처럼 인용할 수 있습니다.

• 현재 법령과 과거 기준일의 법령을 섞을 수 있습니다.

• 합성 fixture의 사실을 실제 증거처럼 다룰 수 있습니다.

• 필수 권위와 선택적 보강 권위를 혼동할 수 있습니다.

• 실제 결과가 아직 없다는 이유로 사전예측 의견서를 자동으로 평가불가 처리할 수 있습니다.

이 작업을 시작하게 된 계기는 다음 요청이었습니다.

논술 채점 Skill에 세 명의 채점자와 조정자를 붙인 사례글을 참고해서 우리 법률의견서 평가 Skill에도 평가자를 붙이는 과정을 사례게시글로 작성해보자.

처음에는 세 명의 모델을 병렬로 부르면 해결될 것처럼 보였습니다. 그러나 같은 입력을 보고 같은 실수를 반복한다면 평가자 수가 늘어도 독립적인 검증은 되지 않습니다. 그래서 모델 수보다 정보 경계와 역할 분리를 먼저 설계했습니다.

🛠️ 사용한 도구

• Hermes Agent: 평가자·검증자·조정자의 역할을 독립 실행하고, 각 호출과 최종 상태를 기록했습니다.

• legal-opinion-evaluator Skill: 입력 게이트, 법리·권위·증거·실무성 평가축, Gold 범위를 사용했습니다.

• ENSEMBLE runtime: 평가자 A·B·C, 독립 검증자, 조건부 조정자를 연결했습니다.

• 법률 권위 확인 계층: 기준일 법령 receipt, claim manifest, external recheck, citation map을 사용했습니다.

• 합성 납품지연 fixture: 개인정보와 실제 사건정보를 제외하고 반복 실행 가능한 입력을 고정했습니다.

• write-post Skill: 비개발자 독자가 문제·과정·결과를 따라올 수 있는 이야기 구조와 📚 도움받은 글 attribution 형식을 적용했습니다.

이번 사례는 실제 자문 의뢰인의 원문을 게시한 것이 아닙니다. 합성 fixture를 대상으로 한 사전예측 평가이며, 실제 소송 결과나 행정처분의 적법성을 검증한 사례가 아니라는 점을 처음부터 분리했습니다.

🔧 작업 과정

1. “세 명을 항상 부르기” 대신 평가 깊이를 고르는 문부터 만들었습니다

이 작업의 출발점이 된 실제 요청은 다음과 같습니다.

논술 채점 Skill에 세 명의 채점자와 조정자를 붙인 사례글을 참고해서 우리 법률의견서 평가 Skill에도 평가자를 붙이는 과정을 사례게시글로 작성해보자.

모든 법률의견서를 긴 앙상블로 실행하면 검증 품질은 높아질 수 있지만, 초안 피드백까지 같은 비용을 치르게 됩니다. 반대로 중요한 제출 전 의견서를 한 명의 평가자에게만 맡기면 놓친 부분을 다시 발견하기 어렵습니다.

그래서 먼저 평가 모드를 선택하도록 했습니다.

이번 의견서는 어느 수준으로 평가할까요?

1. QUICK: 평가자 1명 + 독립 검증자 1명
2. ENSEMBLE: 독립 평가자 3명 + 검증자 + 충돌 시 조정자

빠른 문안 점검이나 초기 초안은 QUICK으로 처리하고, Gold 후보·제출 전 검토·중요한 법률 리스크 검토는 ENSEMBLE로 처리합니다.

이 선택 단계가 생기면서 “모델을 몇 개 붙였는가”보다 “이 문서에 어느 정도의 검증이 필요한가”가 먼저 보이기 시작했습니다. AI를 많이 호출하는 것이 목적이 아니라, 위험도에 맞는 검증 깊이를 선택하는 것이 목적이 된 것입니다.

2. 한 문서를 세 명이 같은 방식으로 읽지 않도록 했습니다

평가자 세 명에게 같은 질문과 같은 루브릭만 주면, 결과 세 개가 생길 뿐 독립적인 관점 세 개가 생기지는 않습니다. 그래서 평가자가 문서를 읽는 방향을 나누었습니다.

세 평가자는 서로의 점수와 의견을 보지 않습니다.

평가자 A가 독립적으로 읽습니다.
평가자 B가 독립적으로 읽습니다.
평가자 C가 독립적으로 읽습니다.
→ 각 결과를 별도로 보관합니다.
→ 검증자가 자기 체크리스트를 먼저 작성합니다.
→ 그 후 평가자 결과를 제한적으로 대조합니다.

여기서 가장 중요한 규칙은 “모델 이름이 다르다”가 아니었습니다. 각 평가자가 무엇을 보았고 무엇을 보지 않았는지를 고정하는 일이었습니다.

예를 들어 평가자 B가 법령의 현재성과 법리 연결을 깊게 보더라도, 평가자 A가 놓친 사실 누락이나 평가자 C가 찾은 증거 공백을 미리 알 수 없게 했습니다. 그래야 앞선 평가자의 표현을 따라가는 연쇄 동조를 줄일 수 있습니다.

3. 검증자는 점수를 보기 전에 자기 판단을 먼저 만들었습니다

평가자 결과를 먼저 보여 주고 “이 점수가 맞는지 확인해 달라”고 하면 검증자는 평가자의 문장과 숫자에 끌릴 수 있습니다. 그래서 검증자는 평가자 점수를 보기 전에 다음 질문에 답합니다.

• 이 문서가 답해야 할 의뢰 질문은 무엇인가

• 결론을 바꿀 수 있는 사실과 가정은 무엇인가

• 기준일과 관할은 무엇인가

• 반드시 확인해야 할 법령·권위는 무엇인가

• 각 법률요건은 어떤 증거와 연결되는가

• 상대방의 가장 강한 반론은 무엇인가

• 아직 확인하지 못한 자료는 무엇인가

그 다음 평가자 결과를 비교하며 다음 오류를 찾습니다.

• 원문을 잘못 읽은 부분

• 근거 없는 감점이나 가점

• 필수 권위와 선택적 보강 권위의 혼동

• 의견서 위치와 citation map의 불일치

• 점수 산술 오류

• 조정자가 필요한 critical issue

이 순서를 정하고 나서 평가 결과를 보는 방식이 달라졌습니다. 검증자는 “누가 더 높은 점수를 줬는가”를 확인하는 사람이 아니라, “이 점수가 원문과 근거로 설명되는가”를 확인하는 사람이 되었습니다.

4. 조정자는 전체 문서를 다시 채점하지 않았습니다

평가자 세 명의 결과가 다르면 보통 평균을 내거나 다수결을 사용하기 쉽습니다. 하지만 법률적 판단에서는 다수가 말한다고 해서 자동으로 맞는 것은 아닙니다.

그래서 조정자는 다음 경우에만 호출하도록 했습니다.

• 영역별 점수 차이가 정해진 범위를 넘는 경우

• 평가 가능성이나 critical issue 판정이 갈리는 경우

• 검증자가 과잉 감점·중대한 누락·오독을 표시한 경우

• 필수 권위와 선택적 보강 권위가 충돌하는 경우

조정자는 전체 의견서를 다시 읽지 않았습니다. 충돌한 문항과 연결된 원문, Gold contract, 공식 권위 receipt, external recheck, citation map만 다시 확인했습니다.

실제 canary에서는 평가자 A와 B가 Gold contract에 필수로 지정되지 않은 민법 제387조를 사실상 필수 권위처럼 요구했습니다. 평가자 C는 이를 핵심 결함으로 보지 않았습니다.

조정자는 “두 명이 그렇게 말했으니 맞다”고 결론 내리지 않고, 제387조가 이번 평가의 필수 권위인지 다시 확인했습니다. 그 결과 제387조는 선택적 보강사항으로 분류했고, 필수 권위 누락으로 인한 치명적 감점은 하지 않았습니다.

이 장면에서 조정자의 역할이 선명해졌습니다.

조정자는 평균을 내는 사람이 아니라, 충돌의 원인을 확인하고 필요한 범위만 다시 읽는 사람입니다.

5. 반복 실행할 수 있는 합성 fixture를 먼저 고정했습니다

평가 구조를 검증하려면 같은 조건에서 여러 번 실행해야 합니다. 실제 자문 원문을 그대로 사용하면 개인정보와 비공개 정보가 섞이고, 매번 사실관계가 달라질 수 있습니다.

그래서 다음과 같은 합성 납품지연 fixture를 고정했습니다.

의뢰 질문은 다음과 같이 고정했습니다.

이 의견서가 매도인의 납품 지연에 관한 채무불이행·손해배상 쟁점과 반론·증거·권고를 적절히 연결하는지 평가해 주세요.

이 입력은 다음을 한 번에 시험합니다.

• 납품 지연과 채무불이행의 연결

• 귀책사유와 불가항력의 구분

• 지연과 대체구매 사이의 인과관계

• 통상손해·특별손해와 예견가능성

• 채권자 과실과 손해확대 방지

• 원래 계약가격과 대체구매가격의 비교

• 증거와 각 요건의 연결

• 상대방의 최강 반론

• 보수적인 손해액 산정

반대로 계약상 면책·불가항력·책임제한·통지·유예 조항, 운송장애의 실제 원인, 원계약가격, 대체품의 동등성, 직접 관련 판례, 실제 손해액은 확정하지 않았습니다.

처음부터 모르는 자료를 비워 둔 이유는, 실제 사건처럼 보이게 만드는 것보다 평가자가 무엇을 전제로 판단했는지 반복해서 확인하는 일이 더 중요했기 때문입니다.

6. 실제 결과가 없다는 이유로 사전예측 평가를 멈추지 않았습니다

이번 fixture에는 실제 판결이나 행정처분이 없습니다. 처음에는 이런 상황에서 평가를 제한해야 하는지 고민이 생겼습니다.

그러나 다음 두 질문은 서로 달랐습니다.

질의, 합성 사실, 기준일, 관할, 필수 조문 receipt, 독립 확인 자료를 확인할 수 있었으므로 입력 게이트는 EVALUABLE로 두었습니다.

다만 평가 범위는 제한했습니다. 실제 청구액·승소 여부·처분 결과를 평가한 것이 아니라, 기준일 당시 의견서가 법리·증거·반론·불확실성을 어떻게 구성했는지를 평가했습니다.

이 구분을 하지 않으면 결과가 아직 없는 모든 사전예측 의견서가 자동으로 낮은 평가를 받게 됩니다. 반대로 이 구분을 명시하면 무엇을 평가했고 무엇을 아직 평가하지 않았는지 독자가 확인할 수 있습니다.

7. 점수보다 먼저 Gold contract와 citation map을 고쳤습니다

첫 live 실행은 성공했지만, 실행이 성공했다고 바로 Gold를 부여하지는 않았습니다.

처음에는 본문 인용과 권위 receipt의 연결이 충분히 세밀하지 않았고, 미확인 자료를 limitation으로 남길지 치명적 결함으로 볼지 기준도 더 분명해야 했습니다.

그래서 Gold contract를 다음처럼 나누었습니다.

• 기준일과 관할

• 필수 권위 조문

• verified authority receipt

• claim과 source_refs

• 의견서 위치와 인용 문구

• external recheck

• evidence pack

• 경쟁 해석과 decision pivot

• bounded uncertainty

• SCOPED_GOLD: ex-ante-prediction

필수 조문은 다음 경로로 연결했습니다.

필수 조문 → verified authority receipt → claim ID → 의견서 위치 → 실제 인용 문구

이렇게 확인하고 나서야 “본문에 조문 번호가 있다”와 “필수 권위가 실제 평가 근거로 연결되어 있다”를 구분할 수 있었습니다.

8. live 실행과 문구 보정을 따로 하지 않았습니다

v4에서 SCOPED_GOLD 자격을 확보한 뒤에도 민법 제396조와 관련된 표현을 다시 읽었습니다.

처음 문구는 다음과 같았습니다.

참작될 수 있다

조정자 검토 후 다음과 같이 보정했습니다.

참작하여야 한다

표현 하나가 바뀌었지만, 법률문서에서는 그 차이가 권고 수준과 법적 의무의 뉘앙스를 바꿀 수 있습니다. 수정 원문, claim manifest, authority citation map을 동기화한 뒤 mock과 Hermes Full live를 다시 실행했습니다.

이때 배운 점은 Gold가 “한 번 통과하면 끝나는 도장”이 아니라는 것입니다. Gold를 받은 문장도 원문·법문·근거가 다시 맞물리는지 확인할 수 있어야 했습니다.

9. 검증 결과를 읽히는 사례글로 다시 정리했습니다

평가 runtime이 통과했다고 해서 사례게시글도 자동으로 완성되는 것은 아니었습니다. 기술 문서처럼 역할과 상태만 나열하면 비개발자 독자는 왜 이 구조가 필요한지 이해하기 어렵습니다.

이번 v3를 작성하게 된 실제 요청은 다음과 같습니다.

이거 사례게시글을 v3를 작성해. 이 때 도움받은 글을 적어주고, write-post 스킬의 형식에 맞도록 작성해줘

그래서 v3에서는 평가 결과를 다음 흐름으로 다시 배치했습니다.

• 문제 상황에서 기존 단일 평가의 한계를 먼저 보여 줍니다.

• 작업 과정에서 선택·독립성·검증·조정의 이유를 순서대로 설명합니다.

• 결과 표에는 확인된 호출 수, 점수, citation map, Gold 범위를 함께 적습니다.

• 독자가 바로 써 볼 수 있도록 재사용 프롬프트를 인용문으로 제공합니다.

• 외부 원문을 참고한 사실은 📚 도움받은 글에 작성자·제목·링크·적용 방식을 명시합니다.

• 내부 경로와 명령어는 본문에서 제외하고, 이미지가 필요한 섹션을 추천합니다.

이번 단계에서 배운 점은 사례게시글도 하나의 검증 결과물이라는 사실입니다. 내용이 맞는 것뿐 아니라, 독자가 문제·과정·결과를 따라갈 수 있고 참고한 원문을 확인할 수 있어야 게시글의 재사용성이 생깁니다.

✅ 결과 (After)

Before vs After

소요 시간과 비용은 이번 canary에서 비교 측정하지 않았습니다. 따라서 “몇 분 절약했다”거나 “비용이 줄었다”고 말하지 않습니다. 이번 실행에서 확인한 것은 시간 효율이 아니라 역할 분리, 근거 추적, 재현 가능한 live read-back입니다.

실제 실행 결과

v5 Hermes Full live에서 read-back한 값은 다음과 같습니다.

오프라인 회귀 테스트는 32개가 통과했습니다.

결과물은 점수표 하나가 아니었습니다

이번 작업에서 남은 결과물은 다음 묶음입니다.

• 평가자 A·B·C의 관점별 rubric과 근거

• 검증자의 독립 체크리스트와 flags

• 조정자의 disputed items와 source recheck

• 필수 조문 authority citation map

• evidence pack과 external recheck

• bounded uncertainty

• 최종 점수와 Gold scope

• 실제 호출·성공·retry 기록

세 평가자의 점수는 서로 달랐습니다. 그러나 점수가 다르다는 사실 자체를 오류로 보지 않았습니다.

• A는 범위·사실·출처의 공백을 강조했습니다.

• B는 법리·권위·논증의 보강 필요성을 강조했습니다.

• C는 증거 설계와 실제 사용성을 중점적으로 읽었습니다.

• 검증자는 필수 권위와 선택적 보강 권위를 혼동한 부분을 표시했습니다.

• 조정자는 충돌 문항만 다시 읽어 과잉 감점을 줄였습니다.

• 문구 보정 후 citation map과 Gold 범위를 다시 확인했습니다.

실제 판결이나 처분이 없으므로 OUTCOME_GOLD는 부여하지 않았습니다. 실제 공고·처분·판결·계약자료가 확보되면 별도의 OUTCOME_VALIDATION으로 다시 확인해야 합니다.

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 모델 수보다 정보 경계를 먼저 정했습니다. 세 평가자가 서로의 결과를 보지 않아야 독립적인 누락을 찾을 가능성이 생깁니다.

2. 평가 전에 모드를 골랐습니다. 모든 문서를 앙상블로 돌리지 않고, 위험도와 사용 목적에 따라 QUICK과 ENSEMBLE을 나눴습니다.

3. 검증자를 점수 앞에 배치했습니다. 검증자가 먼저 원문·기준일·필수 권위를 읽어야 평가자 표현에 끌리지 않습니다.

4. 조정자에게 충돌 문항만 주었습니다. 전체 재평가를 시키지 않아 새로운 추측이 늘어나는 것을 막았습니다.

5. Gold contract를 점수표에서 분리했습니다. 높은 점수와 근거 검증은 서로 다른 품질 게이트입니다.

6. 확인하지 못한 자료를 limitation으로 남겼습니다. 직접 판례·계약 조항·실제 가격자료가 없다는 사실을 숨기지 않았습니다.

이렇게 하면 안 돼요

1. 세 모델의 점수를 평균하고 “정확도가 올라갔다”고 바로 결론 내리면 안 됩니다.

2. 평가자 두 명이 같은 조문을 요구했다고 해서 Gold contract 밖의 조문까지 필수 권위로 만들면 안 됩니다.

3. 실제 결과가 없다는 이유만으로 사전예측형 의견서를 자동 LIMITED로 내리면 안 됩니다.

4. 법령 receipt가 확인되었다고 해서 직접 관련 판례나 실제 증거까지 확인했다고 쓰면 안 됩니다.

5. 설계 문서의 예정 흐름을 실제 live 성공으로 표현하면 안 됩니다. 호출·게이트·retry·citation map을 read-back해야 합니다.

6. SCOPED_GOLD를 승소 가능성·처분 결과·손해액 보장으로 사용하면 안 됩니다.

7. 📚 도움받은 글을 링크 하나로 끝내면 안 됩니다. 누가 쓴 글인지, 무엇을 배웠고 어떻게 바꾸었는지를 함께 적어야 합니다.

🌍 다른 업무에 적용한다면?

이 구조는 내부 감사 대응 메모를 제출 전에 검토하는 업무에도 적용할 수 있습니다.

예를 들어 감사 지적에 대한 법무 검토문을 평가한다고 가정해 보겠습니다.

• 평가자 A는 감사 지적의 사실, 계약·문서의 시간순서, 누락 자료를 확인합니다.

• 평가자 B는 적용 법령, 내부 규정, 권한·절차, 기준일을 확인합니다.

• 평가자 C는 감사기관의 최강 반론, 재발방지 조치, 실무자가 실행할 수 있는 대응을 확인합니다.

• 검증자는 세 평가자의 점수를 보기 전에 감사 질문과 필수 근거 체크리스트를 작성합니다.

• 조정자는 처분 가능성이나 중대한 절차 위반처럼 의견이 갈린 문항만 공식 자료로 재검토합니다.

이렇게 하면 “법적으로 맞는가”와 “감사 대응에 실제로 쓸 수 있는가”를 한 점수로 섞지 않게 됩니다. 사실·권위·증거·실행계획을 분리해서 확인할 수 있으므로, 법무 검토문을 고치는 사람도 어떤 부분부터 보완해야 하는지 알 수 있습니다.

🚀 앞으로의 계획

이번 실행은 사람 채점자의 Gold 정답과 비교한 실험이라기보다, 평가 구조와 근거 추적성을 검증한 canary였습니다.

다음에는 비식별 법률의견서와 사람 판정을 연결해 단일 평가와 앙상블을 비교할 예정입니다. 점수 하나만 보지 않고 다음 항목을 확인하려고 합니다.

• 사람 판정과의 평균절대오차

• 영역별 점수 분산

• 핵심 법리·권위 누락 발견률

• unsupported deduction 비율

• citation map 완성률

• EVALUABLE / LIMITED / DEFERRED 판정 일치율

• 조정자 개입률과 개입 후 오류 감소율

• 호출 시간과 비용

• 실제 결과가 생긴 뒤 OUTCOME_VALIDATION의 일치·불일치 양상

목표는 모델을 계속 늘리는 것이 아닙니다. 어떤 의견서는 QUICK으로 충분하고, 어떤 의견서는 ENSEMBLE과 조정자까지 필요한지 운영 기준을 더 분명하게 만드는 것입니다.

📋 재사용 가능한 프롬프트

프롬프트 1: 독립 법률의견서 평가자

당신은 법률의견서 평가자 [A/B/C]입니다. 아래 의견서 원문, 의뢰 질의, 사실·전제, 기준일·관할, 공식 권위 receipt만 사용하여 [범위·사실·출처 / 법리·권위·논증 / 증거·사용성·반론] 관점에서 독립적으로 평가해 주세요. 다른 평가자의 점수나 의견은 보지 않았다고 전제하세요. 확인되지 않은 판례·조문·사실은 만들지 말고 AUTH, MISSING, LIMITATION으로 표시하세요. 각 점수에는 의견서 위치와 근거를 연결하고, 결론을 바꾸는 사실과 상대방의 최강 반론을 함께 적어 주세요. 실제 소송 결과나 승소 가능성을 평가하지 말고, 기준일 당시 사전예측의 구조와 실무성을 평가해 주세요. [의견서 원문], [의뢰 질의], [사실·전제], [권위 receipt]는 실제 자료로 교체하세요.

프롬프트 2: 점수 전 검증자와 충돌 조정자

먼저 평가자 점수와 결론을 보지 않고 [질의·범위], [결정적 사실·가정], [기준일·법령 버전], [필수 권위], [필수 법리 연결], [증거 공백], [상대방 반론] 체크리스트를 작성하세요. 그 다음 평가자 결과를 대조하여 원문 오독, 근거 없는 감점, 필수 권위와 선택적 보강 권위의 혼동, citation map 불일치, 산술 오류, 조정 필요 여부를 표시하세요. 조정이 필요하면 충돌한 문항만 [원문], [Gold contract], [공식 receipt], [external recheck]로 재검토하세요. 평균·다수결로 법적 결론을 정하지 말고, 점수 변경 여부와 별도로 미해결 불확실성과 재개 조건을 기록하세요. [required_authority_articles], [authority_receipts], [citation_map], [grader_digest]는 이번 평가 자료로 교체하세요.

📚 도움받은 글

이 사례는 MOSL님이 작성하신 사례글을 직접 읽고 핵심 구조를 확인한 뒤, 빠른 단일 평가·앙상블 평가의 선택, 독립 채점자, 점수 전 검증, 충돌 문항 조정 방식을 법률의견서의 권위 receipt·증거·기준일 체계에 대조해 정리했습니다.

• 논술 채점 Skill에 세 명의 채점자와 조정자를 붙여 보았다 — 작성자는 MOSL님입니다.

원문에서 배운 구조를 그대로 복사하지 않고, 논술의 제시문 근거를 법률의견서의 법령·판례·증거 receipt로 바꾸었습니다. 또한 사전예측형 법률의견서에 필요한 SCOPED_GOLD: ex-ante-prediction, authority citation map, bounded uncertainty, OUTCOME_VALIDATION 분리를 추가했습니다.

🖼️ 추천 이미지

• 문제 상황(Before) 섹션: 한 명의 평가자가 범위·사실·법리·증거를 한꺼번에 읽으며 여러 종류의 메모가 섞이는 장면을 보여주는 전후 비교 도식이 좋습니다.

• 작업 과정 섹션: 평가자 A·B·C가 서로 독립적으로 출발하고, 검증자를 거쳐 충돌 문항만 조정자로 이동하는 흐름도가 좋습니다.

• 결과(After) 섹션: A 77.0, B 84.75, C 80.0, 최종 80.0, 7/7 성공, retry 0을 한 장에 보여주는 결과 카드가 적합합니다.

• citation map 섹션: 민법 제390조·제393조·제396조가 receipt·claim·의견서 위치·인용 문구로 연결되는 provenance 도식이 좋습니다.

🏁 마무리

세 명의 평가자와 조정자를 붙이는 일은 AI에게 같은 질문을 세 번 던지는 일이 아니었습니다. 실제로 필요한 것은 다음 네 가지였습니다.

독립성, 공식 권위의 범위, 불확실성의 공개, 재현 가능한 감사 기록입니다.

이번 앙상블은 점수를 한쪽으로 끌어올리는 장치가 아니었습니다. 어떤 평가는 과잉 감점을 되돌렸고, 어떤 평가는 법률 표현을 더 엄격하게 고치게 했습니다. 조정자는 다수결로 결론을 만들지 않고 충돌의 원인을 좁혔습니다.

최종 Gold도 점수의 높이에 붙인 것이 아닙니다. 무엇을 확인했고 무엇을 아직 모르는지 설명할 수 있는 상태에 붙였습니다.

따라서 이번 사례의 Gold는 다음 의미로만 사용합니다.

SCOPED_GOLD: ex-ante-prediction은 정해진 기준일·관할·권위·사실 전제 안에서 사전예측형 법률의견서의 구조·근거·조건부 논증·불확실성 처리가 평가계약을 통과했다는 뜻입니다. 실제 판결·처분·승소·손해액을 보증하는 라벨은 아닙니다.

실제 결과자료가 생기는 날에는 별도의 OUTCOME_VALIDATION을 실행해야 합니다. 그것이 법률 AI 평가에서 점수보다 중요한 경계입니다.