self-eval
작성자 alirezarezvaniself-eval은 작업 이후의 검토를 솔직하게 수행하도록 돕는 prompt-only Claude Code skill입니다. 작업, 코드 리뷰, 업무 세션이 끝난 뒤 AI 작업 품질을 평가하기 위해 두 축 점수화, devil's advocate reasoning, 점수 이력 저장, 점수 부풀림 방지 검사를 사용합니다.
이 skill은 80/100점으로, 작업 후 품질 검토 워크플로를 체계화하려는 디렉터리 사용자에게 충분히 추천할 만한 항목입니다. 저장소 근거를 보면 명확한 트리거와 재사용 가능한 평가 규칙을 갖춘 실질적인 prompt-only skill입니다. 다만 지속 기록 동작은 번들 도구가 아니라, 에이전트가 파일 처리 지시를 잘 따르는지에 의존한다는 점을 염두에 두어야 합니다.
- 활성화 맥락이 명확합니다. 작업, 코드 리뷰, 업무 세션을 마친 뒤 사용하라고 설명합니다.
- 두 개의 독립 축, 고정 lookup matrix, 필수 devil's advocate reasoning, 점수 부풀림 감지 등 구체적인 평가 메커니즘을 제공합니다.
- 일반 프롬프트보다 에이전트 활용도가 높습니다. AI가 점수를 과하게 주기 쉬운 문제를 명시적으로 다루고, 세션 간 점수 이력을 보존합니다.
- 지원 스크립트나 참조 파일이 없는 prompt-only skill이므로, 지속 기록과 점수 부풀림 방지 검사는 에이전트가 `.self-eval-scores.jsonl`을 안정적으로 읽고 쓰는지에 달려 있습니다.
- 제공된 구조상 설치와 도입 안내가 제한적입니다. `SKILL.md`에 README, metadata, install command가 없습니다.
self-eval skill 개요
self-eval의 용도
self-eval skill은 작업이 끝난 뒤 결과물을 솔직하게 평가하도록 돕는 prompt-only Claude Code skill입니다. 작업 수행, 코드 리뷰, 구현 세션, 디버깅, 계획 수립이 끝난 후 AI agent가 자기 결과물을 점검할 때, 막연한 칭찬이나 부풀려진 “4/5” 점수로 흐르지 않게 해줍니다.
self-eval은 “이거 얼마나 잘했나?”를 하나의 주관적 척도로 묻는 대신, 작업의 야심도와 실행 품질이라는 두 축으로 평가를 나눕니다. 그래서 “정말 뛰어난 작업이었나, 아니면 쉬운 과제를 무난히 처리한 수준인가?”처럼 보정된 판단이 필요할 때 유용합니다.
잘 맞는 사용자와 작업
self-eval skill은 agent가 완료한 작업을 수락하거나, merge하거나, 그 위에 계속 작업하기 전에 한 번 더 검토하게 만들고 싶을 때 적합합니다. 특히 코드 생성, 리팩터링, 이슈 분류, 테스트 작성, 아키텍처 분석에 AI를 활용하는 엔지니어링 팀에 잘 맞습니다.
다만 테스트 스위트, 사람의 리뷰, 보안 리뷰, 프로덕션 검증을 대체하지는 않습니다. 이 skill의 가치는 구조화된 자기비판에 있습니다. 과신을 줄이고, 약점을 드러내며, 여러 작업 세션에 걸쳐 점수 기록을 남기는 데 도움을 줍니다.
일반 프롬프트와 다른 점
일반적인 “네 작업을 평가해 봐” 프롬프트는 대개 무난한 장점, 가벼운 단서 조항, 낙관적인 점수로 끝나는 경우가 많습니다. self-eval은 점수 부풀리기를 어렵게 만드는 제약을 추가합니다. 필수 devil’s advocate 추론, 고정된 scoring matrix, .self-eval-scores.jsonl에 대한 점수 저장이 포함됩니다.
이 저장 기능이 중요합니다. 최근 평가 점수가 지나치게 좁은 범위에 몰리면, 이 skill은 각 리뷰를 독립적으로만 보지 않고 점수 인플레이션 패턴을 감지할 수 있습니다.
self-eval skill 사용 방법
self-eval 설치와 저장소 확인
다음과 같이 skill manager를 사용해 GitHub skill source에서 설치합니다.
npx skills add alirezarezvani/claude-skills --skill self-eval
관련 저장소 경로는 다음과 같습니다.
engineering/skills/self-eval/SKILL.md
현재 구조에는 외부 의존성, helper script, bundled rules, reference files가 없습니다. 설치 전에 빠르게 검토하려면 먼저 SKILL.md를 읽어보세요. 이 파일에는 scoring model, workflow, output expectations가 들어 있습니다. prompt-only skill이기 때문에 도입 리스크는 낮지만, 결과 품질은 충분한 작업 맥락을 제공하느냐에 크게 좌우됩니다.
skill에 필요한 입력
self-eval을 제대로 활용하려면 단순히 “이거 평가해 줘”라고 요청하지 마세요. 완료된 작업과 그 작업을 어떤 기준으로 판단해야 하는지 함께 제공해야 합니다.
좋은 입력에는 다음이 포함됩니다.
- 원래 사용자 요청 또는 이슈 설명
- agent가 만든 최종 답변, patch, plan, review
- 시간 제한, 스타일 규칙, 테스트 요구사항, 금지된 접근 방식 같은 관련 제약
- 실행한 테스트, 변경한 파일, 실행한 명령, 알려진 공백 같은 검증 근거
- maintainer, reviewer, product owner, beginner user, production team 등 의도한 독자 또는 사용자
약한 프롬프트는 점수만 요구합니다. 강한 프롬프트는 이 skill이 “야심도는 낮지만 깔끔한 작업”과 “야심도는 높지만 미완성인 작업”을 구분할 수 있을 만큼 충분한 근거를 제공합니다.
더 나은 결과를 위한 프롬프트 패턴
self-eval은 작업 전에 쓰기보다 작업이 끝난 뒤에 사용하세요. 실용적인 프롬프트는 다음과 같습니다.
Use the self-eval skill to evaluate the work below. Original task: [goal]. Output produced: [answer or diff summary]. Constraints: [tests, style, repo rules]. Validation performed: [commands or none]. Known concerns: [risks]. Give the two-axis evaluation, devil's advocate reasoning, final matrix score, and concrete follow-up actions.
이 구조는 모델이 말투나 노력만 보고 평가하는 일을 막아주기 때문에 결과가 좋아집니다. 평가가 야심도, 실행, 근거, 남은 위험을 함께 고려하도록 강제합니다.
권장 워크플로
겉으로만 긍정적인 평가가 비용이 될 수 있는 지점에서 self-eval을 실행하세요.
- 작업을 완료하거나 해결안을 초안으로 작성합니다.
- 원래 목표와 작업 근거를 포함해 self-eval을 요청합니다.
- 최종 점수보다 먼저 devil’s advocate 섹션을 읽습니다.
- 드러난 약점을 짧은 수정 목록으로 바꿉니다.
- 단순한 문구 수정이 아니라 의미 있는 변경이 있었을 때만 다시 실행합니다.
작업 디렉터리에 .self-eval-scores.jsonl이 생성되면 이를 로컬 평가 이력으로 취급하세요. 팀에서 이 파일을 commit할지, ignore할지, 또는 주기적으로 검토할지 결정해야 합니다.
self-eval skill FAQ
self-eval은 Model Evaluation용인가요, 코드 품질 평가용인가요?
둘 다에 유용하지만 의미는 좁게 잡아야 합니다. self-eval for Model Evaluation은 benchmark-grade model measurement가 아니라 AI agent가 수행한 특정 작업 단위의 자기 평가로 이해하는 편이 적절합니다. 세션 간 비교, 부풀려진 자기 점수 감지, 리뷰 규율 개선에는 도움이 되지만 formal eval harnesses, golden datasets, human-labeled scoring을 대체하지는 않습니다.
언제 self-eval을 쓰면 안 되나요?
보안에 민감한 변경, 법률 또는 의료 콘텐츠, 프로덕션 마이그레이션, 검증된 정확성이 필요한 작업처럼 고위험 작업의 유일한 관문으로 사용해서는 안 됩니다. 평가할 구체적인 산출물이 없을 때도 피하는 편이 좋습니다. 이 skill에는 task, output, evaluation criteria가 필요합니다. 그렇지 않으면 형식은 만들어내더라도 근거가 약한 평가가 됩니다.
초보자도 사용하기 쉬운가요?
네. prompt-only이고 도구 의존성이 없기 때문에 시작하기 쉽습니다. 그래도 초보자는 사용 전에 특히 scoring logic을 중심으로 SKILL.md를 읽어보는 것이 좋습니다. 주요 학습 곡선은 설치가 아니라, 평가가 감에 의존하지 않도록 충분한 맥락을 제공하는 데 있습니다.
critique를 요청하는 것과 어떻게 다른가요?
critique는 보정된 점수 없이 문제 목록만 제시할 수 있습니다. self-eval은 two-axis model과 matrix-locked final score를 사용하므로 agent가 “그럴듯하게 느껴지는” 점수를 마음대로 정당화할 여지가 줄어듭니다. devil’s advocate 단계도 최종 판단 전에 더 높은 점수와 더 낮은 점수 양쪽을 모두 주장하도록 요구합니다.
self-eval skill 개선 방법
self-eval에 더 강한 근거 제공하기
self-eval 결과를 개선하는 가장 좋은 방법은 근거를 구체적으로 만드는 것입니다. 변경된 파일, 실패하거나 통과한 테스트, 중요한 누락 사항, acceptance criteria를 포함하세요. 테스트를 실행하지 않았다면 그렇게 명시하세요. 답변이 의도적으로 특정 요구사항을 제외했다면 그 점도 포함해야 합니다.
더 나은 입력이 반드시 더 긴 입력을 뜻하지는 않습니다. 평가 가능한 입력이어야 한다는 뜻입니다. “Refactored auth code”는 약합니다. “Refactored auth/session.ts to remove duplicated token parsing; ran npm test -- auth; did not test OAuth callback manually”는 이 skill이 실제로 점수를 매길 수 있는 근거를 제공합니다.
흔한 실패 모드 주의하기
가장 흔한 실패는 모델이 결과가 아니라 노력을 보상하게 두는 것입니다. 또 다른 실패는 어려운 작업을 일부만 수행했는데도 자동으로 높은 평가를 주는 것입니다. self-eval은 이를 막도록 설계되어 있지만, 사용자가 원래의 야심도와 실제 산출물을 함께 제공할 때에만 제대로 작동합니다.
점수 이력의 노이즈도 주의해야 합니다. .self-eval-scores.jsonl에 서로 관련 없는 작업 유형이 섞이면 clustering signal의 의미가 약해질 수 있습니다. 문서 다듬기와 복잡한 마이그레이션은 같은 숫자 점수를 받았다는 이유만으로 동등하게 해석되어서는 안 됩니다.
점수를 행동으로 이어가기
최종 점수에서 멈추지 마세요. 유용한 출력은 야심도와 실행 사이의 간극입니다. 그 간극을 다음과 같은 수정 프롬프트로 바꾸세요.
Based on the self-eval weaknesses, revise the work to address the top three execution gaps. Do not expand scope. Preserve the original constraints and report what changed.
이렇게 하면 다음 반복 작업의 초점이 유지됩니다. 또한 agent가 더 높은 점수를 얻으려고 관련 없는 기능을 추가하면서 작업을 “개선”하는 일을 막아줍니다.
신중하게 커스터마이즈하기
self-eval skill을 수정하더라도 보정을 만들어내는 핵심 요소는 유지하세요. 분리된 평가 축, devil’s advocate reasoning, 고정된 score mapping, score-history awareness가 그것입니다. label, output format, 팀별 acceptance criteria를 바꾸는 것은 대체로 안전합니다. 하지만 모델이 스스로 반대 논리를 제시하게 만드는 제약을 제거하면, 이 skill은 평범한 review prompt처럼 동작하게 됩니다.