플러그인을 위한 스킬 검증

이것이 중요한 이유

스킬을 만들거나 이를 플러그인으로 묶을 때, 여러분은 본질적으로 다른 사람들이 사용할 작은 제품을 만드는 것입니다. 그리고 동료에게 건네주는 다른 모든 것들 — 템플릿, 스프레드시트 모델, 체크리스트 — 과 마찬가지로, 책상을 떠나기 전에 시험 운행을 해볼 가치가 있습니다.

여러분이 직접 만든 스킬을 사용할 때는 어떤 문제나 실패를 어떻게 해결해야 하는지 알고 있습니다. 무엇을 요청해야 하는지, 어떤 파일을 제공해야 하는지, 답이 어떤 모습이어야 하는지 정확히 알고 있습니다. 팀원은 그런 것을 전혀 모릅니다. 요청을 조금 다르게 표현하거나, 약간 다른 입력을 제공하거나, 엣지 케이스 — 스킬이 설계된 범위를 살짝 벗어난 요청처럼 드물지만 실제로 발생하는 상황 — 에 부딪힐 수 있습니다. 바로 그런 지점에서 스킬이 흔들리기 쉬우며, 사용하는 사람은 그 이유를 알지 못합니다.

eval — evaluation(평가)의 줄임말 — 로 스킬을 테스트하는 것은 다른 사람이 발견하기 전에 이런 흔들림을 잡아내는 방법입니다. 이 단어에 위축되지 마세요. eval은 그저 시험 삼아 해보는 것입니다: 현실적인 요청을 입력하고, 나오는 결과를 살펴보고, Claude에게 무엇을 고쳐야 하는지 알려주는 것입니다. 코드도, 테스트 스크립트도 필요 없습니다 — 그저 결과가 여러분의 이름을 걸 만큼 충분히 좋은지에 대한 판단만 있으면 됩니다.

eval 시스템의 작동 방식

skill-creator — 스킬 생성을 위한 Claude의 내장 도우미 — 로 스킬을 만들 때, 이 과정의 일부로 eval을 단계별로 안내받게 됩니다. 실제로 어떤 모습인지 살펴보겠습니다.

skill-creator는 누군가가 여러분의 스킬과 함께 사용할 만한 현실적인 프롬프트를 두 개 이상 생성합니다. 각 프롬프트에 대해 한 쌍의 출력을 생성합니다:

• Claude가 여러분의 스킬을 사용하는 경우
• Claude가 여러분의 스킬 없이 동일한 프롬프트에 답하는 경우

두 번째 것이 비교 기준입니다. 이는 여러분의 스킬이 실제로 어떤 차이를 만들어내는지 나란히 볼 수 있도록 하기 위한 것입니다 — 단순히 "이 출력이 괜찮은가"가 아니라 "이 출력이 Claude가 스스로 했을 때보다 더 나은가"를 보는 것입니다.

각 쌍을 검토하고 리뷰 페이지에서 바로 평이한 언어로 피드백을 제공하세요. 각 쌍을 읽으면서, 여러분은 사실상 두 가지 질문에 답하고 있는 것입니다:

• 스킬 버전이 내가 실제로 사용할 버전인가? 그렇다면 좋습니다 — 무엇이 더 나았는지 기록해서 스킬이 계속 그렇게 하도록 하세요.
• 그렇지 않다면, 무엇이 빠졌거나 잘못되었나? 구체적으로 말하세요. "어조가 너무 격식적이다" 또는 "요약을 빠뜨렸다"는 Claude가 행동할 수 있는 근거를 제공하지만, "이건 좀 아닌 것 같다"는 그렇지 않습니다.

피드백을 제출하면, Claude는 여러분이 말한 내용을 바탕으로 스킬을 수정합니다.

스킬 반복 개선하기

여러분의 피드백이 바로 수정 사항입니다. 제출하면 Claude가 스킬을 업데이트합니다 — 지침을 다시 작성하고, 예시를 조정하고, 요청하는 내용을 더 명확하게 다듬습니다 — 그리고 동일한 프롬프트를 다시 실행해서 변경 사항이 제대로 적용되었는지 확인할 수 있습니다.

한 번에 한 가지씩 바꾸세요. 첫 번째 라운드에서 스킬이 너무 장황하고 동시에 섹션이 빠졌다는 것이 드러났다면, 더 중요한 것을 하나 골라 고치고, 다시 실행한 다음, 다시 돌아와 검토하세요. 그러면 실제로 무엇이 효과가 있었는지 알 수 있습니다. 수정 후에도 출력이 여전히 만족스럽지 않다면 다시 실행하세요 — 이것은 한 번만 통과하면 끝나는 관문이 아니라 반복되는 루프입니다. 대부분의 스킬은 한두 번의 라운드 후에 준비가 됩니다. 스킬을 출시하는 기준 — 자신에게든, 팀원에게든 — 은 완벽한 eval이 아닙니다. 여러분이 신경 쓰는 사례들이 기준선보다 의미 있게 더 잘 통과하고, 아직 처리하지 못하는 사례들을 명확히 밝혀두었다는 것입니다.

그리고 첫 시도에서 이미 출력이 훌륭해 보인다면? 끝난 것입니다. eval은 통과해야 하는 형식적인 절차가 아닙니다 — 확신이 필요할 때를 위한 것이지, 의례를 위한 것이 아닙니다.

지금 해보기

아래에서 모의 eval 검토를 단계별로 진행해 보세요 — 세 개의 프롬프트, 각각 스킬 사용 출력과 스킬 미사용 출력이 나란히 제공됩니다.

각 쌍에 대해: 실제로 보낼 버전을 선택하고, Claude에게 줄 피드백을 한 줄로 작성하세요. 그게 전체 루프입니다.

다음 단계

다음 레슨에서는 "이건 나에게 효과가 있다"에서 "이건 팀에게 효과가 있다"로 넘어갑니다 — 개인 워크플로를 공유 인프라로 전환하는 패턴과 선택들을 다룹니다.