감이 아니라 숫자로 판단하기 | Skill 개선하기

Overview

앞 레슨에서 Skill을 직접 만들고, 커뮤니티 Skill을 설치했습니다. 이제 하나 더 남은 질문이 있습니다. 만든 Skill이 정말 의도대로 동작할까요? 한두 번 돌려보고 "잘 되는 것 같은데"로 넘어가면, Skill을 고친 뒤 실제로 더 좋아졌는지 나빠졌는지 알 수 없습니다.

이번 레슨에서는 Skill Creator의 Eval (평가 테스트)로 Skill의 품질을 객관적으로 재고, 수정 전·후를 비교해 고친 것이 실제로 개선인지 확인합니다.

학습 목표

• Skill Eval의 세 조각 (테스트 프롬프트 / 기대 결과 / 판정)을 이해합니다
• Skill Creator로 Eval을 작성하고 실행할 수 있습니다
• 수정 전 Skill과 수정 후 Skill의 A/B 비교로 개선 여부를 판단할 수 있습니다

시작하기 전 확인사항

• Skill 만들기 레슨에서 만든 .claude/skills/commit/ 이 있는 상태에서 시작합니다
• Skill Creator 플러그인이 설치돼 있어야 합니다

"잘 되는 것 같은데"의 함정

commit Skill을 만든 직후 한두 번 돌려봤더니 잘 됩니다. 그래서 다른 Skill 작업으로 넘어갑니다. 며칠 뒤 동료가 묻습니다. "description이 좁아 보이는데 '변경사항 반영해줘'라고 해도 호출이 될까요?" 갑자기 막힙니다.

Skill의 품질을 평가하는 게 까다로운 건 출력이 매번 달라지기 때문입니다. 같은 프롬프트에도 모델이 10번 중 9번은 원하는 결과를, 한 번은 엉뚱한 결과를 낼 수 있습니다. 몇 번 돌려보고 "잘 된다"는 확률적 판단입니다.

더 중요한 상황은 Skill을 수정할 때입니다. description을 다듬고, 참조 파일을 추가하고, 단계를 재배열합니다. 고친 뒤 "전보다 나아진 건가?" 머릿속 비교로는 답이 안 나옵니다.

Eval: 세 조각으로 이루어진 객관적 판정

Eval(평가)은 Skill이 기대대로 동작하는지 확인하는 테스트입니다. 소프트웨어 단위 테스트와 같은 개념이지만, 검사 대상이 코드가 아니라 Skill의 출력입니다. 한 번의 Eval은 세 조각으로 이루어집니다.

1. 테스트 프롬프트: Skill에 보낼 입력. "이 변경사항을 커밋해줘"
2. 기대 결과: 좋은 결과의 기준. "Conventional Commit 형식이어야 하고, scope가 포함돼야 한다"
3. 판정: Skill이 만든 결과가 기준을 충족하는지 자동으로 확인

여러 Eval을 모아두면 Skill을 수정할 때마다 전부 다시 돌려서 "10개 중 10개 통과" 또는 "3번이 깨졌다"를 즉시 확인할 수 있습니다.

[실습] Skill Creator로 Eval 작성하기

commit Skill의 Eval을 Skill Creator에게 맡깁니다.

/skill-creator commit Skill 에 대한 Eval 을 작성해줘. 정상 커밋, 여러 파일 수정, 부정 트리거 시나리오를 포함해줘.

Skill Creator가 SKILL.md를 분석하고 시나리오를 제안합니다. 예를 들면 이렇습니다.

• 시나리오 1 (정상): 단일 파일 수정 후 커밋 요청 → type·scope가 포함된 Conventional Commit 형식인가?
• 시나리오 2 (범위 판단): 여러 파일 수정 후 커밋 요청 → 변경 범위에 맞는 scope를 선택했는가?
• 시나리오 3 (부정 트리거): "git rebase가 뭐야?" 질문 → Skill이 트리거되지 않는가?

각 시나리오는 "테스트 프롬프트 + 기대 결과" 쌍으로 저장됩니다. 실행하면 각 시나리오의 통과·실패, 소요 시간, 토큰 사용량을 확인할 수 있습니다.

[실습] 수정 전후 객관 비교하기

현재 commit Skill은 이미 staging 된 파일만 커밋하고, modified·untracked 파일은 무시합니다. 이 동작을 바꾼다고 가정해봅니다. "modified와 untracked도 자동으로 staging 해서 커밋" 하도록 만드는 것입니다.

수정했는데 실제로 개선인지는 감으로 판단할 수 없습니다. Skill Creator에게 수정과 비교를 한 번에 맡깁니다.

/skill-creator commit Skill 을 수정하고 테스트해줘. 현재는 이미 staging 된 파일만 커밋하는데, modified 와 untracked 파일도 자동으로 staging 해서 커밋하도록 바꾸고 싶어. 수정 전후를 비교해서 실제로 개선되었는지 확인해줘.

Skill Creator는 세 단계를 순서대로 진행합니다.

1. 수정 전 SKILL.md를 따로 보관
2. SKILL.md를 수정
3. 같은 테스트 프롬프트로 수정 전과 수정 후를 동시에 돌려 결과 비교

• 수정 후 통과율이 80% → 100% 로 올라갔다면 개선
• 수정 후 특정 시나리오가 깨졌다면 회귀입니다. 수정을 되돌려야 합니다
• 토큰 사용량이 두 배가 됐다면 개선·회귀를 떠나 비용 측면에서 재검토가 필요합니다

Eval이 효과적인 순간

"Skill 하나 만드는데 굳이 Eval까지?" 이 회의는 타당합니다. Eval이 효과를 발휘하는 순간은 따로 있습니다.

팀이 공유하는 Skill일 때

내 마음대로 고치면 팀원 전체에게 영향을 줍니다. 수정 전·후 비교가 리뷰 근거가 됩니다.

Skill을 여러 번 수정할 예정일 때

description을 이리저리 다듬거나, 참조 파일을 쪼개거나, 단계를 재배열할 계획이라면 매 수정마다 Eval을 돌려 비교합니다.

처음 만드는 Skill, 혼자 쓰는 단순 Skill에는 과할 수 있습니다. Skill이 점점 중요해질 때 Eval을 붙이면 됩니다.

핵심 포인트 정리

1. "잘 되는 것 같은데"는 확률적 판단: 모델 출력이 매번 달라지므로 한두 번 돌려서는 Skill 품질을 알 수 없습니다. Eval이 이걸 숫자로 바꿉니다.
2. Eval은 세 조각: 테스트 프롬프트 / 기대 결과 / 판정. Skill Creator가 SKILL.md를 분석해 시나리오를 자동으로 제안합니다.
3. 수정 전·후 A/B가 개선의 증거: Skill을 고쳤을 때 통과율·토큰·시간이 어떻게 바뀌는지 나란히 보면, 감이 아니라 근거로 판단할 수 있습니다.

FAQ

• Q: Skill 없이 Eval을 돌리면 어떻게 되나요?

  • A: Skill Creator는 "Skill 없음 vs Skill 있음" 비교도 지원합니다. 이 비교가 유의미한 경우는 Skill이 Claude 단독으로는 불가능한 기능을 보강할 때입니다. 모델이 업데이트된 뒤 Skill 없이도 통과하기 시작하면 Skill을 제거할 신호가 됩니다. 반대로 commit Skill처럼 팀 규칙을 담은 Skill은 Skill 없이는 당연히 실패하니 이 비교가 유의미하지 않습니다. 이 경우 "수정 전 vs 수정 후"만 비교합니다.

• Q: Eval 시나리오는 몇 개가 적당한가요?

  • A: 정상 흐름 1-2개, 경계 케이스 1-2개, 부정 트리거 1개 정도면 충분합니다. 실제 사용하다가 Skill이 예상과 다르게 동작하면 그 상황을 바로 시나리오로 추가하면 됩니다.

• Q: Eval을 매번 수동으로 돌려야 하나요?

  • A: /skill-creator 에 "Skill을 개선해줘"라고 요청하면 수정안을 만들고 Eval로 검증한 뒤 결과까지 한 번에 돌려줍니다. 수정과 평가가 하나로 묶여 있어서 세부 명령을 따로 기억할 필요가 없습니다.

이어서 배울 내용

이번 Chapter 에서 Claude 의 지식을 더하는 네 가지 방법(Rules · Custom Command · Skill · Eval) 을 배웠습니다. 다만 Claude 가 닿을 수 있는 범위는 여전히 로컬 파일과 내장 도구에 한정됩니다. 다음 Chapter 에서는 GitHub 이슈, 사내 API, 실행 중인 브라우저 같은 외부 시스템으로 접근 범위를 넓히는 세 가지 경로를 배웁니다.

• 개발자가 이미 쓰던 터미널 도구를 Claude 에게 빌려주기 (CLI 연결)
• 표준 프로토콜로 외부 SaaS · 앱 세션에 닿기 (MCP)
• 공개된 MCP 가 없는 내부 시스템을 직접 감싸기 (Custom MCP)