빠른 흐름

1. 성공 기준을 문장으로 정의한다
2. prompt에 변수 자리를 만든다
3. 정상, 경계, 실패 입력을 test case로 추가한다
4. 출력 품질을 같은 기준표로 채점한다
5. prompt 버전을 바꾼 뒤 같은 test suite로 비교한다

평가 구조

eval은 프롬프트 수정의 회귀 테스트다

프롬프트를 고칠 때 한두 예시만 다시 실행하면 좋아진 것처럼 보일 수 있습니다. 실제로는 특정 입력은 나아지고 다른 입력은 나빠질 수 있습니다. eval은 같은 test case 묶음으로 프롬프트 버전을 반복 비교해 회귀를 찾는 장치입니다.

Prompt v1
  -> test cases 20개 실행

Prompt v2
  -> 같은 test cases 20개 실행
  -> 품질, 누락, 형식 위반 비교

프롬프트가 제품 기능이나 운영 자동화에 들어가면 eval은 선택 사항이 아니라 변경 관리 기준이 됩니다.

변수는 입력 차이를 드러내는 자리에 둔다

Claude Console의 평가 흐름에서는 prompt 안에 동적 변수 자리를 두고 test case마다 값을 바꿔 넣습니다. 변수는 무작정 많이 만들기보다 실제 사용자 입력, 문서 본문, 정책 버전처럼 결과를 바꿀 수 있는 축에 둡니다.

<task>
Classify the support request in {{request_text}}.
</task>

<policy>
{{routing_policy}}
</policy>

변수 위치가 명확하면 test case를 CSV나 표 형태로 관리하기 쉽고, 어떤 입력 축에서 실패하는지도 추적하기 쉽습니다.

test case는 정상 입력보다 실패 입력이 더 중요하다

좋은 test suite에는 성공하기 쉬운 정상 입력만 있으면 안 됩니다. 길이가 긴 입력, 정보가 부족한 입력, 서로 충돌하는 입력, 형식만 맞고 의미가 틀린 입력을 넣어야 실제 운영 실패를 빨리 볼 수 있습니다.

test case 종류
- 정상 입력
- 누락된 필드
- 상충하는 지시
- 너무 긴 문서
- 예상 밖 카테고리
- 안전상 거절해야 하는 요청

판정 기준

채점은 가능하면 고정 rubric으로 합니다. "좋음/나쁨"만 기록하면 다음 버전에서 무엇을 고쳐야 하는지 남지 않습니다.

주의할 점

자동 채점만으로는 문서 품질, 법적 판단, 브랜드 톤 같은 항목을 완전히 검증하기 어렵습니다. 높은 위험의 프롬프트는 자동 eval과 사람 검토를 분리해서 운영해야 합니다.