이 기사에서 알 수 있는 것: LLM에게 품질 평가를 시킬 때, 수치 점수 대신 「이진 체크(Binary Check) + 이름이 붙은 판정」으로 설계하는 방법. 평가 대상을 교체하면 바로 사용할 수 있는 judge 프롬프트 구조 포함.

LLM에게 결과물의 평가를 맡기는 수법은 LLM-as-judge라고 불립니다. 이를 도입하면 많은 사람이 동일한 벽에 부딪힙니다.

• 루브릭 (Rubric, 채점 기준표)으로 5점 만점의 채점을 시키면, 동일한 입력임에도 실행할 때마다 3점과 4점을 왔다 갔다 한다.
• 합계 점수의 임계값으로 합격/불합격을 나누면, 치명적인 결함이 하나 있어도 다른 항목의 고득점에 희석되어 통과된다.
• 나중에 점수를 다시 읽어봐도, 「왜 3.5점인가」를 아무도 설명할 수 없다.

이 기사에서는 이 세 가지 벽을 한꺼번에 회피하는 설계 패턴을 소개합니다. 핵심은 한 줄입니다.

체크는 Yes/No의 이진 값으로 증거를 수집하고, 판정은 이름이 붙은 라벨 중에서 하나를 선택하는 종합 판단으로 내리며, 점수 집계는 하지 않는다.

저는 이 패턴을 Claude Code의 스킬 품질 감사(/skill-stocktake)와 지식 추출 품질 게이트(/learn-eval)에서 약 4개월 반 동안 운용해 왔습니다. 스킬 감사 명령어를 어떻게 만들었는지——수치 루브릭을 버리게 된 시행착오——는 지난 기사에 적었습니다.

본 기사는 그 속편입니다. 그 설계를 LLM-as-judge의 범용 패턴으로 일반화하고, 운용 중에 자신의 설계를 스스로 검증하여 다시 만든 에피소드까지 포함하여 소개합니다.

전제

• 대상 독자: LLM으로 결과물(문서·코드·데이터)의 품질 평가를 자동화하고 싶은 사람
• 예시는 Claude Code의 스킬 평가이지만, 패턴 자체는 평가 대상·모델·도구에 관계없이 사용할 수 있습니다.
• 용어:
  판정 라벨 (Verdict Label) = 평가의 최종 출력. 「Keep / Retire」와 같은 이름이 붙은 선택지 중 하나를 고르게 하는 형태입니다. 영어 문헌에서는 이를 verdict(버딕트)라고 부르며, 본 기사의 JSON 예시 필드명에도 verdict를 사용하고 있습니다.
• 용어:
  종합 판단 (Holistic Judgment) = 항목별 채점을 거치지 않고, 전체를 보고 하나의 결론을 내는 판단. 영어 문헌에서는 holistic(홀리스틱) 평가라고 불립니다.

패턴의 전체 모습 — 3가지 원칙

① 체크는 Yes/No의 이진 값으로 한다

「이 스킬의 구체성은 5점 만점에 몇 점인가」가 아니라, 「읽고 바로 실행할 수 있는 구체적인 명령어 예시가 있는가? Yes/No」라고 묻습니다.

이진 질문에는 수치 채점에는 없는 두 가지 성질이 있습니다.

• 검증 가능: 「명령어 예시가 있는가」는 본문을 보면 흑백이 분명해집니다. 「구체성 3점」은 검증할 방법이 없습니다.
• 증거가 됨: No 답변은 「무엇이 결여되어 있는가」를 그대로 가리킵니다. 개선 리스트로 직결됩니다.

실제로 운용 중인 스킬 감사에서는 각 대상에 이 4가지 질문을 반드시 통과시킵니다.

- [ ] Actionability: 바로 실행할 수 있는 절차·명령어·실례가 있는가?
- [ ] Scope fit: 이름·트리거·본문이 일치하는가 (너무 넓거나 좁지 않은가)?
- [ ] Uniqueness: 동일한 배치 내의 다른 스킬과 내용이 중복되지 않는가?
...

② 판정은 이름 붙은 라벨을 종합 판단으로 선택하게 한다

종합 판단은 LLM의 특기 분야입니다. 지난 기사에서 썼듯이, LLM은 차원별 독립 채점에 서툴고 전체적인 인상에 휘둘립니다. 그렇다면 처음부터 「전체적인 인상으로 하나를 골라라」라고 설계하는 편이 솔직합니다.

포인트는 판정 라벨을 다음 액션과 1:1로 대응하는 이름으로 만드는 것입니다.

accept / reject와 같은 2진 값보다, 후속 처리가 그대로 분기될 수 있는 고정된 선택지로 만드는 편이 실용적입니다 (프로그래밍에서 말하는 enum(열거형) — 정해진 값 이외에는 취하지 못하게 하는 메커니즘입니다. 자유 기술형으로 두면 "Improve", "조금 개선"과 같이 값이 흔들려 code가 분기될 수 없습니다). Merge into [X]와 같이 대상의 이름을 강제하는 설계로 만들면, "어딘가와 중복되는 것 같다"라는 모호한 판정을 구조적으로 쓸 수 없게 됩니다.

이 "LLM이 이름이 붙은 선택지에서 고르고, 실행은 code가 담당한다"는 분리에는 판정 실수에 대한 방파제라는 의미도 있습니다. 판정과 실행을 나누어 두면, LLM의 판단 실수가 직접적으로 시스템 상태를 망가뜨리는 일은 없습니다 (저는 이것을 LLM judge + Code enforce 패턴이라고 부르며 운용하고 있습니다).

③ 이진 답변을 집계하지 않는다

이 부분이 이 패턴의 가장 큰 분기점입니다. 이진 체크(binary check)를 도입하면, "8문항 중 6문항이 Yes이므로 75%, 임계값 70%를 넘었으므로 합격"이라고 하고 싶어집니다. 이것을 해서는 안 됩니다.

이유는 단순합니다. 충족률은 단 하나의 치명적인 No를 희석시키기 때문입니다. "참조 대상 파일이 존재하지 않는다"라는 No가 하나 있다면, 나머지 7문항이 Yes라 하더라도 그 스킬은 망가져 있는 상태입니다. 평균이나 비율은 이 지배적인 No를 12.5%의 감점으로 변환해 버립니다.

대신 해야 할 일은 두 가지입니다.

• No 답변을 판정의 근거로서 반드시 열거하게 한다 (숨겨진 No는 판정의 편차를 만듭니다)
• 지배적인 No(실재하지 않는 참조, 근거 없는 주장 등)가 하나라도 있다면, 나머지가 전부 Yes라도 비(非) Keep 측으로 기울인다

스킬 감사 정의 파일에는 이 원칙을 한 문장으로 이렇게 적어두었습니다.

Evaluation is holistic judgment, not a numeric rubric— binary answers are evidence feeding the verdict, never aggregated into a score (a satisfaction ratio changes no decision and dilutes a single dominant No).

(평가는 종합 판단(holistic judgment)이지 수치 루브릭(numeric rubric)이 아니다. 이진 답변은 판정에 제공하는 증거일 뿐, 점수로 집계해서는 안 된다. 충족률은 어떤 결정도 바꾸지 못하며, 단 하나의 지배적인 No를 희석시킨다.)

반증 압박 테스트 (Refutation Pressure Test) — 판정을 확정하기 전에 두드리기

이진 체크와 종합 판단만으로도 작동하지만, 한 단계 더 높은 품질 장치를 끼워 넣으면 판정의 신뢰도가 올라갑니다. 가판정(provisional judgment)을 확정하기 전에, 그 판정을 반증하려는 질문을 LLM 스스로 생성하고 답변하게 하는 단계입니다.

절차 (비(非) Keep 후보에만 적용):
1. 가판정에 대해, 이를 반증하는 Yes/No 질문을 1~3개 생성한다
예: 가판정이 "Update (참조 중인 CLI 플래그가 폐지됨)"라면
...

질문 설계에는 두 가지 규율을 부여합니다.

• 일문일주장 (atomicity): 하나의 질문은 하나의 검증 가능한 주장만을 테스트한다
• 반증 지향 (refutation-oriented): 가판정을 긍정하는 방향이 아니라, 반증을 찾는 방향으로 질문을 던진다

또 하나, 수정 후 재판정에 중요한 규율이 있습니다. 재판정은 동일한 질문 세트로 단 한 번만 수행합니다. 질문을 다시 만들면 "수정이 효과가 있었던 것인지, 기준이 완화된 것인지"를 구분할 수 없게 되기 때문입니다.

복사해서 바로 쓸 수 있는 judge 프롬프트 구조

지금까지의 패턴을 평가 대상만 바꾸면 바로 사용할 수 있는 형태로 만든 것이 다음과 같습니다.

당신은 {평가 대상의 종류}의 품질 평가자입니다. 다음 단계에 따라 평가해 주세요.
## Step 1: 이진 체크 (전 문항 필수)
각 질문에 Yes/No와 1행의 증거(evidence)로 답해 주세요.
...

출력은 JSON으로 받으면 후속 코드(code)가 그대로 처리할 수 있습니다.

{
"verdict": "Improve",
"evidence": [
...

verdict 필드는 고정된 선택지만 가질 수 있으므로, 받은 코드는 switch 문으로 분기하기만 하면 됩니다. evidence의 No 항목은 그대로 개선 태스크 리스트로서 다음 공정(인간 또는 다른 LLM)에 전달할 수 있습니다.

이 템플릿을 포함한 설계 패턴 일체는 Claude Code의 Agent Skill로서 github.com/shimo4228/llm-as-judge 에 공개되어 있습니다. skills/llm-as-judge를 ~/.claude/skills/에 복사하면, judge를 설계하는 상황에서 자동으로 발화합니다.

같은 원칙이라도, 규모에 따라 운용은 달라진다

이 패턴을 두 가지 규모로 운용하며 알게 된 것은, 원칙은 공통되나 적용 조건은 규모에 따라 바꿔야 한다는 점입니다.

평가 대상이 1건이라면 모든 기능을 다 넣어도 문제없습니다. 수십 건 규모가 되면 비용이 높은 장치(반증 질문)는 의심스러운 후보에만 집중합니다.

단일 컨텍스트(Single Context) 평가는 정밀도가 떨어지지 않는가 — 자신의 설계를 검증하다

여기서부터가 본 기사의 후반부 주제입니다. 위의 스킬 감사에는 원래 "모든 스킬을 하나의 컨텍스트에 실어서 평가한다"는 설계를 채택하고 있었습니다. 롱 컨텍스트 (Long Context) 모델이라면 전 건을 한눈에 볼 수 있고, 스킬 간의 중복도 보일 것이라는 논리였습니다.

그런데 이 설계로 돌린 감사가 전 건 Keep이라는 결과를 반환했습니다. 단 1건의 결함도, 한 쌍의 중복도 검출하지 못했습니다. 이것이 "라이브러리가 건전한" 것인지, 아니면 "평가가 헛돌고 있는" 것인지 구분하기 위해, 동일한 라이브러리를 10건 전후의 소규모 배치(small batch)로 나누어 독립 에이전트에게 정독시키는 방식과, 중복 검출만을 전담하는 방식으로 재감사했습니다 (실험 설계와 수치에 대한 주석은 절 끝부분의 접기 섹션에 정리했습니다).

결과 — 떨어지는 차원과, 떨어지지 않는 차원이 있었다

놓쳐진 12건 중 절반은 404 링크, 삭제된 파일에 대한 참조, 폐기된 CLI 플래그 등 기계적으로 검출할 수 있는 결함이었습니다. 결정적인 것은, 디스크 상에 존재하지 않는 파일 2건에 Keep 판정이 내려졌다는 점입니다.

반면 중복 0건은 희석(컨텍스트가 채워져 주의력이 분산되는 것)이 아닌 실제 상황이었습니다. "전 건을 한눈에 볼 수 있으므로 중복이 보인다"라는 단일 컨텍스트의 근거는, description의 경량 스캔 + 타겟팅된 정독만으로 대체되어 있었던 셈입니다.

최대의 교훈은 "컨텍스트 폭"이 아니라 "검증의 소유권"

놓침(miss)의 메커니즘을 추적해 보니 컨텍스트의 넓이 그 자체보다 깊은 원인이 보였습니다. 감사의 정의에는 "참조가 오래되어 보이면 확인한다"라는 조건부 검증 지시가 적혀 있었습니다. 이 "~해 보이면"이라는 조건 판단 자체가 LLM의 주의력에 의존하고 있습니다. 컨텍스트가 채워져 주의력이 분산되면, 조건부 트리거는 "확인하지 않음" 쪽으로 기울어집니다.

지난 기사의 결론은 "기계적 처리는 스크립트에, 품질 판단은 AI에"였습니다. 이번 검증은 그 경계선을 한 단계 더 깊게 다시 그었습니다. 품질 판단의 내부에도, 코드(code)로 내려보내야 할 결정론적인 부분이 숨어 있다. "파일이 실재하는가"는 판단이 아니라 ls

명령입니다. 판단 단계(phase) 속에 섞여 있던 결정론적 체크를, 조건 없는 필수 전처리로서 code 측으로 옮겼어야 했습니다. 이것이 소제목인 「검증의 소유권」의 의미입니다. 즉, 결정론적 체크의 실행 주체를 LLM의 주의력(attention)에서 code로 옮기는 것입니다.

개정된 설계(v3.0)는 체크하는 성질에 따라 실행 환경을 분리합니다.

검출된 12건은 1건씩 확인하여 당일 내에 수정했습니다. 그중 1건은 수정안을 적용하기 전의 실측에서 명령어가 작동하지 않는다는 것을 확인하여 다른 형식으로 교체했습니다. 판정뿐만 아니라 수정도 검증한 후 확정한다 —— 동일한 패턴이 평가의 외곽에서도 나타나고 있습니다.

실험 설계와 숫자에 관한 주석 (관심 있는 분들을 위해)

• Baseline: 전체 건을 단일 컨텍스트에서 감사한 결과. 장부상으로는 84개 엔트리 전건 Keep이었습니다. 디스크 상의 실제 파일은 73건이었으며, 차분은 장부의 버그였습니다. 동일한 스킬이 두 가지 키로 이중 계상되어 있었고, 이미 존재하지 않는 파일의 엔트리까지 남아 있었습니다. 장부가 이 정도로 오염되어 있었다는 사실 자체를 이 시점에서는 아무도 알아채지 못했습니다. 이후의 검증은 실제 파일 73건을 대상으로 합니다. -
• 처치 A (소규모 배치 정독): 73건을 10~11건 × 7 배치로 분할하여, 독립된 서브 에이전트(sub-agent)가 동일한 기준(이진 체크 → 종합 판단)으로 정독. 참조의 실재 여부는 ls 등으로 반드시 검증하도록 명시. -
• 처치 B (중복 전담 프로브): 1개의 에이전트가 전체 73건의 description을 읽고 후보 클러스터를 열거 → 본문을 병치하여 정독 판정. -
• 편향 통제: baseline이 전건 Keep이었다는 사실을 에이전트에게 숨겼습니다. -
• 교란 요인에 대한 솔직한 주석: 처치 A의 프롬프트는 「참조 실재를 ls로 반드시 검증하라」고 명시했기 때문에, baseline과의 차이 중 일부는 「컨텍스트 폭(context window)」이 아니라 「검증 강제 여부」에 기인합니다. 다만, description과 본문의 불일치, 지나치게 추상적인 기술, 스코프 이탈과 같은 의미적 판단에 의한 검출은 검증 강제만으로는 설명할 수 없으며, 배치당 10건과 73건이라는 주의력 밀도의 차이가 작용한 것으로 해석하고 있습니다. -

왜 점수를 사용하지 않는가 — 제안 논문이 스스로 그은 경계선

「평가 기준을 이진 질문(binary question)으로 분해한다」는 접근법에는 연구의 계보가 있습니다. CheckEval (arXiv:2403.18771, 2024), TICK (arXiv:2410.03608, 2024), 그리고 후발 주자인 BinEval 「Ask, Don't Judge」 (arXiv:2606.27226, 2026)입니다. 저의 운용 방식은 「이진 체크 + 종합 판단」이라는 골격이 먼저 있었고, 이 계보는 나중에 알게 되어 각 스킬의 References에 편입했습니다. BinEval은 일문일주장(一問一主張) 형태의 Yes/No 질문으로의 분해와, 실패한 질문을 개선 피드백으로 직결시키는 설계를 제안하고 있으며, 반증 질문의 동적 생성과 「No 답변 = 개선 리스트」의 직결은 BinEval 공개 이후 이곳에서 이식한 부분입니다.

흥미로운 점은 BinEval 스스로 밝힌 limitations(한계점)입니다. 논문은 두 가지 유보 사항을 자기 고백하고 있습니다. 첫째, 이진 분해가 신뢰할 수 있는 것은 「코드 예시가 있는가」와 같이 구체적으로 확인할 수 있는 기준까지입니다. 「문장으로서 좋은가」와 같은 주관적인 품질은 인간이라면 개별 체크의 축적이 아니라 전체를 보고 판단하는 것이며, Yes/No 질문의 묶음으로 완전히 분해할 수 없습니다 (less reliable). 둘째, 「충족된 질문의 비율이 품질에 대략 선형적으로 대응한다는 전제를 두고 있지만, 이것이 항상 성립하는 것은 아니다」라는 점입니다. 즉, 「분해된 질문의 충족률을 점수(score)로 사용하는 것」에 대해서는 제안 논문 스스로가 유보를 표하고 있습니다.

이 한계의 고백은 뒤집어 말하면 그대로 분업의 경계선입니다. 구체적으로 확인할 수 있는 기준은 Yes/No로 분해할 수 있습니다. 그러므로 체크(check)에는 증거 수집을 맡깁니다. 반면, 최종적인 가치 판단은 「문장으로서 좋은가」 유형의 주관적인 층위에 속하며, 질문의 묶음이나 충족률로 완전히 환원할 수 없습니다. 그렇기에 이 층위는 종합 판단으로서 남겨둡니다. 본 기사의 3대 원칙은 이진 분해 연구가 스스로 밝힌 경계선을 그대로 설계에 옮겨 적은 것입니다.

요약

• LLM-as-judge의 평가는 「이진 체크 (Binary Check) = 증거」, 「판정 = 명명된 라벨 (Named Label) 중에서 종합 판단으로 1개 선택」, 「집계 금지」의 3대 원칙으로 설계합니다.
• 판정 라벨은 다음 액션과 1:1로 대응하는 고정된 선택지로 구성하며, 판정 근거에는 반드시 'No' 답변을 열거하게 합니다.
• 확정 전에 반증 압박 테스트 (Counter-evidence Pressure Test)를 거치면 판정의 신뢰도가 높아집니다. 재판정은 동일한 질문 세트로 단 1회만 수행합니다.
• 본인의 검증 결과, 항목별 (per-item) 정밀 조사는 컨텍스트가 채워지면 희석되었습니다 (16%의 누락 발생). 결정론적으로 검증 가능한 체크는 LLM의 주의력 (Attention)에 맡기지 말고, 조건 없는 코드 (Code) 소유로 내려보내십시오.
• '충족률'을 점수로 삼지 않는 근거는, 이진 분해를 제안한 논문 (BinEval) 자체가 명시한 한계에 있습니다. 분해할 수 있는 것은 구체적인 기준까지이며, 가치 판단의 층위는 종합 판단으로 남겨둡니다.

지난 기사의 분업 원칙인 「기계적 처리는 스크립트에, 품질 판단은 AI에」는 이번에 한 단계 더 깊어졌습니다. 판정의 내부에도 코드 (Code)로 내려보내야 할 부분이 있습니다. LLM-as-judge를 설계할 때는, judge에게 넘기기 전에 「이것이 정말 판단인가, 아니면 ls인가」를 묻는 것부터 시작하십시오.

관련 링크

• llm-as-judge — 본 기사의 설계 패턴을 Agent Skill로 만든 것 (설치하여 바로 사용할 수 있습니다)
• 지난 기사: AI가 못하는 일을 스크립트로 넘기기 — 스킬 재고 (Skill Stocktake) 커맨드의 설계·구현·공개 전 기록
• claude-skill-stocktake — 본 기사의 스킬 감사 커맨드 (v3.0 하이브리드 구조)
• agent-knowledge-cycle — 본문에서 언급한 LLM judge + Code enforce 패턴의 정의 원천
• 논문: CheckEval (arXiv:2403.18771, 2024) — 체크리스트 분해형 LLM 평가의 선행 연구
• 논문: TICK (arXiv:2410.03608, 2024) — 생성된 체크리스트를 통한 평가·생성의 개선
• 논문: BinEval 「Ask, Don't Judge」 (arXiv:2606.27226, 2026) — 일문일주장 (One question, one claim) 방식의 Yes/No 분해와 「No 답변 = 개선 리스트」 제안의 원천. limitations가 본 기사 경계선의 근거
• github.com/shimo4228 — 저자의 다른 리포지토리 목록

Discussion