지난주에 트레이싱으로 프롬프트 버전을 기록하는 얘기를 했는데, 오늘은 그걸로 뭘 하냐는 얘기예요. 한 줄로 요약하면 프롬프트에도 테스트 코드가 있어야 한다는 거예요.
프롬프트 수정은 항상 "뭔가"를 깨뜨려요
경험상 그래요. "날짜 형식을 YYYY-MM-DD로 통일해"라는 한 줄을 넣었더니 날짜는 좋아졌는데, 날짜가 없는 문서에서 모델이 날짜를 지어내기 시작했어요. 고치기 전엔 "없음"이라고 잘 하던 거였는데요. 이런 걸 배포 뒤에 고객이 발견하면 신뢰가 깨져요.
코드라면 당연히 테스트를 돌리잖아요. 프롬프트도 똑같이 해야 해요.
평가셋의 구조
저희 평가셋은 케이스의 목록이고, 케이스 하나는 이렇게 생겼어요.
id: date-missing-003
tags: [date, missing-field, contract]
input:
document: fixtures/contract_no_date.md
question: "계약 체결일을 추출하세요"
expected:
type: exact
value: null
why: "날짜가 없는 문서에서 날짜를 지어내면 안 됨 (2026-02 사고)"
- tags: 뭘 검사하는 케이스인지. 결과를 태그별로 집계해요.
- expected.type: 채점 방식이에요. 뒤에 설명할게요.
- why: 이 케이스가 왜 있는지. 나중에 "이거 지워도 되나?" 할 때 꼭 필요해요. 사고에서 나온 케이스는 사고 날짜를 적어요.
채점 방식은 세 가지예요
1. 정확 일치(exact). 추출 결과처럼 정답이 하나인 경우. 정규화(공백, 숫자 형식)는 하고 비교해요. 대부분의 케이스가 이거예요.
2. 규칙(rule). "응답에 고객 이름이 들어 있으면 안 됨", "JSON 스키마를 만족해야 함", "500자 이내" 같은 거예요. 정규식이나 작은 함수로 검사해요.
3. 모델 채점(llm-judge). 요약이나 설명처럼 정답이 하나가 아닌 경우예요. 다른 모델에게 기준표를 주고 점수를 매기게 해요. 편한데 제일 믿기 어려워요. 저희는 모델 채점 케이스는 반드시 사람이 채점한 샘플과 일치율을 먼저 확인하고, 일치율이 낮으면 기준표를 고쳐요. 그리고 모델 채점 결과만으로 배포를 막지는 않고 경고로만 써요.
케이스는 어디서 오나
세 군데예요.
- 사고에서. 운영 중 문제가 생기면 그 입력을 익명화해서 케이스로 넣어요. 이게 제일 가치 있는 케이스예요. 같은 사고가 두 번 안 나요.
- 트레이스에서. 지난주 트레이싱 데이터 중 사람이 "좋음/나쁨"으로 표시한 걸 케이스로 올려요. Agent Ops 콘솔에 "이 스팬을 평가 케이스로 추가" 버튼이 있는 이유예요.
- 일부러 만든 것. 빈 문서, 아주 긴 문서, 다른 언어, 깨진 인코딩, 프롬프트 인젝션 시도 같은 경계 케이스요.
돌리는 방법
프롬프트 템플릿이 저장소에 있고, 바뀌면 CI에서 평가셋이 돌아요. 결과는 이전 버전과 나란히 비교해요.
태그 이전(v41) 이번(v42) 변화
date 92/100 98/100 +6
missing-field 87/90 71/90 -16 ← 회귀!
schema 100/100 100/100 0
태그별로 보는 게 중요해요. 전체 점수만 보면 "+2점이네, 좋아졌네" 하고 넘어가는데, 안에서는 한쪽이 좋아지고 한쪽이 나빠진 거거든요. 저희는 어느 태그든 일정 이상 떨어지면 배포 차단이에요.
모델 응답은 흔들려요
같은 입력에 같은 프롬프트여도 결과가 조금씩 달라요. 그래서 케이스 하나를 한 번만 돌리면 운에 좌우돼요. 저희는 temperature 0에서 돌리고, 그래도 흔들리는 케이스는 3회 돌려서 다수결로 해요. 3회 결과가 다 다르면 그 케이스는 "불안정"으로 따로 표시하고, 그 자체가 프롬프트가 모호하다는 신호로 봐요.
비용과 시간
평가셋이 커지면 돌리는 데 돈과 시간이 들어요. 저희는 세 단계로 나눠요.
- 스모크(수십 케이스): 모든 커밋. 몇 분.
- 전체(수백~수천 케이스): 배포 전. 수십 분.
- 야간(전체 + 모델 채점): 매일 밤.
프롬프트 캐시를 쓰면 시스템 프롬프트 부분은 재사용돼서 비용이 꽤 줄어요.
정리
- 프롬프트를 바꿀 땐 테스트처럼 평가셋을 돌리세요.
- 케이스엔 "왜 있는지"를 적으세요. 사고에서 나온 케이스가 제일 귀해요.
- 전체 점수가 아니라 태그별로 보세요. 회귀는 항상 어느 한 구석에서 나요.
- 모델 채점은 편하지만 사람 채점과 맞춰 본 다음에 쓰세요.
다음 주는 토큰 비용 이야기예요. "이번 달 LLM 비용이 왜 두 배예요?"에 답할 수 있는 대시보드를 어떻게 만들었는지요.