judge

judge 개요

judge가 하는 일

judge skill은 두 단계 평가 워크플로를 실행합니다. 먼저 메타-judge가 작업에 맞는 루브릭을 정의하고, 그다음 judge 서브에이전트가 분리된 컨텍스트와 증거를 바탕으로 결과물을 채점합니다. 이 skill은 대충 의견을 내는 용도보다 코드, 분석, 글, 에이전트 출력물을 엄격하게 검토해야 하는 사용자에게 더 잘 맞습니다.

누가 judge를 사용해야 하나

명확한 기준, 인용, 실행 가능한 피드백이 포함된 보고서형 평가가 필요하다면 judge skill을 사용하세요. Skill Authoring 검토, repo 변경 검토, 그리고 확인 편향이나 세션 잔상이 판단을 흐릴 수 있는 모든 작업에 특히 잘 맞습니다.

무엇이 다른가

단순히 “피드백해 달라”는 일반 프롬프트와 달리, judge는 채점을 시작하기 전에 평가 기준부터 만듭니다. 그래서 산출물 유형이 아직 불명확하거나, 다차원 채점이 필요하거나, 다른 사람에게도 근거 있게 설명할 수 있는 검토가 필요할 때 judge skill이 더 유리합니다.

judge skill 사용 방법

judge를 설치하고 진입 파일을 확인하기

npx skills add NeoLabHQ/context-engineering-kit --skill judge로 설치하세요. plugins/sadd/skills/judge/SKILL.md부터 확인하는 것이 좋습니다. 이 파일에 judge의 설치 동작을 정의하는 워크플로, 입력값, 평가 제약이 들어 있습니다.

judge에 구체적인 평가 대상을 지정하기

이 skill은 작업과 관점을 함께 지정할 때 가장 잘 작동합니다. 좋은 프롬프트 예시는 Judge the last draft of the launch page for clarity, SEO fit, and factual accuracy.입니다. 반대로 Review this처럼 쓰면 메타-judge가 추측해야 할 부분이 너무 많아집니다.

judge 파이프라인에 맞는 컨텍스트 제공하기

평가할 산출물, 성공 기준, 그리고 톤, 대상 독자, 루브릭 우선순위, 금지되는 변경 사항 같은 강한 제약을 함께 넣으세요. Skill Authoring에 judge를 쓰는 경우에는 그 사실을 명시하고 대상 skill 이름도 적어야 합니다. 설치 명확성, 발견 가능성, 지시 품질에 맞게 루브릭이 달라져야 하기 때문입니다.

먼저 이 파일들을 읽기

설치와 적용을 위해서는 먼저 SKILL.md를 읽고, 그다음 이 repo에 포함된 워크플로 또는 정책 파일을 확인하세요. 이 repo에서는 skill 본문 자체가 핵심 기준이므로, 패턴을 자신의 시스템에 그대로 옮기기 전에 프롬프트 구조, 워크플로 단계, 증거 요구사항을 먼저 살펴보는 것이 가장 빠른 방법입니다.

judge skill FAQ

judge는 코드 리뷰에만 쓰는 건가요?

아닙니다. judge skill은 루브릭으로 평가할 수 있는 모든 산출물에 사용할 수 있습니다. 예를 들면 프롬프트, 문서, 분석, 에이전트 출력, 설계 결정 등이 있습니다. 핵심은 결과를 명시적 기준과 증거에 따라 판단할 수 있어야 한다는 점입니다.

언제 judge를 쓰지 말아야 하나요?

빠른 주관적 반응만 필요하거나, 아직 완성된 산출물이 없거나, 증거만으로 평가할 수 없는 작업이라면 judge를 쓰지 않는 편이 좋습니다. 이런 경우에는 더 단순한 프롬프트가 보통 더 빠르고 덜 취약합니다.

초보자도 judge를 쓰기 좋은가요?

네, 산출물과 성공 기준을 이름으로 지정할 수 있다면 그렇습니다. 초보자는 보통 맥락 없이 판단을 요청할 때 가장 어려움을 겪습니다. 이 skill은 메타-judge 단계를 강제해서 그 문제를 줄여 주지만, 그래도 평가 대상은 분명해야 합니다.

judge는 일반 프롬프트와 어떻게 다른가요?

일반 프롬프트는 한 모델이 기준을 만들고 결과를 채점하는 일을 한 번에 처리하게 만드는 경우가 많습니다. judge skill은 그 역할을 분리합니다. 그래서 일관성이 높아지고, 편향이 줄어들며, 최종 보고서를 더 신뢰하기 쉬워집니다.

judge skill 개선 방법

평가 대상을 분명하게 적기

judge에 가장 좋은 입력은 정확한 산출물, 원하는 독자, 그리고 지원하려는 의사결정을 함께 적은 것입니다. 예를 들면 Evaluate the new onboarding doc for first-time contributors, with emphasis on setup clarity and missing prerequisites.처럼 쓰는 편이 좋습니다. Check my doc보다 나은 이유는, 실제 사용자 리스크에 맞춰 루브릭을 정렬할 수 있기 때문입니다.

루브릭에 영향을 주는 제약 추가하기

라인 단위 증거, 인용해야 할 요구사항, 특정 점수 체계가 중요하다면 처음부터 명시하세요. judge는 정확성, 완전성, UX 명확성, 정책 준수 중 무엇을 우선해야 하는지 알 때 더 잘 작동합니다. 이 기준들을 암묵적으로 평균 내기보다, 우선순위를 분명히 알려 주는 편이 낫습니다.

첫 보고서 이후에는 반복해서 다듬기

첫 judge 보고서를 바탕으로 다음 프롬프트를 더 날카롭게 만드세요. 빠진 컨텍스트를 추가하고, 트레이드오프를 더 분명히 하고, 과소평가된 것처럼 느껴진 섹션이 있으면 이름을 지정하세요. Skill Authoring에서는 설치 명확성, 사용 현실성, 경계 사례를 각각 따로 재평가해 달라고 요청하는 반복이 특히 유용합니다.

흔한 실패 패턴을 주의하기

원본 작업이 모호하거나, 산출물이 불완전하거나, 평가 초점이 너무 많은 목표로 과부하되면 judge의 성능이 떨어질 수 있습니다. 그런 경우에는 작업을 더 좁은 단계로 나누고, 현재 판단에 필요한 자료만 judge에 넣으세요.