1. 잘된 예시 하나로 끝내지 않기

정상 입력에서 예쁜 답이 나왔다고 Skill이 잘 만들어진 것은 아닙니다. 자료가 빠졌을 때 무엇을 하는지, 범위 밖 요청에 끼어들지 않는지, 숫자가 바뀌면 정확히 다시 계산하는지도 봐야 합니다.

samples/evaluation/test-cases.csv와 evaluation/run-log.csv를 씁니다. 사람이 읽고 채우는 수업용 양식이며 자동 평가 도구의 설정 파일은 아닙니다.

1.1 네 종류의 입력

test-cases.csv에는 이 네 종류가 열두 사례로 들어 있습니다. 비대상 평가는 Skill 이름을 지정하지 않고 자연어 요청만 씁니다. 사용자가 일부러 회의록 Skill을 지정한 경우와 자동 선택의 정확도를 구분하기 위해서입니다.

1.2 비교 대화 만들기

먼저 Skill을 끈 새 대화에서 입력과 짧은 요청을 실행합니다. 다음에는 Skill을 켠 새 대화에서 같은 입력과 요청을 실행합니다. 제품, 모델, 날짜를 기록하고 다른 조건은 가능한 한 같게 둡니다.

한 번의 차이만으로 품질이 나아졌다고 단정하지 마세요. 같은 사례를 세 번 정도 반복하면 사실 유지와 누락 처리의 경향이 보입니다. 세 번은 수업에서 감당할 수 있는 출발점이지 통계적으로 충분한 횟수는 아닙니다.

1.3 문장을 채점하지 말고 조건을 채점하기

“전문적이고 좋음” 대신 “소라 기한을 미정으로 남겼는가”를 적습니다. 견적은 1,760,000원인지, 수료율은 7/10인지, 설문 평균은 30/7인지 확인합니다. HTML은 실제 파일을 열어 표가 잘리지 않는지 봐야 합니다.

기록은 run-log.csv에 한 사례당 한 줄로 남깁니다. 실패한 사례를 적으면 이런 모양이 됩니다.

case_id: M01
date: 2026-09-07
product: Claude 웹
skill_version: 1.0.0
skill_enabled: on
request: 회의 메모를 회의록으로 정리해줘
input_files: inputs/meeting-notes.md
expected: 소라 기한 미정
actual: 소라 기한 2026-09-25
pass: fail
evidence: my-first-minutes.md
notes: 모집 마감일을 할 일 기한으로 옮김

결과를 작성한 Claude에게 자체 점검을 요청하는 것도 유용하지만 독립 검산을 대신하지는 못합니다. 계산은 스크립트와 손 계산으로, 문서 근거는 원본 대조로 확인합니다.

1.4 점수표 예시

사실·수치 40점, 누락 처리 20점, 요구 형식 20점, 검토 가능성 20점으로 평가할 수 있습니다. 총점과 별개로 가짜 실적 생성, 미정 주소 조작, 실행하지 않은 계산을 실행했다고 주장하는 경우는 점수와 무관하게 보완 대상으로 표시합니다.

이 절의 산출물은 잘된 결과 파일 하나가 아니라 정상과 실패 사례가 함께 적힌 평가표입니다.