프로덕션에 LLM 붙이고 3주 뒤에 전체 파이프라인을 뒤집어엎었다. 원인은 허무할 정도로 단순했다. 답변 품질을 측정할 방법이 아예 없었다.
데모 통과, 프로덕션 폭발
고객 문의 자동 응답 시스템이었다. RAG 달고, 프롬프트 좀 다듬고, 내부 데모에서 "오 괜찮은데?" 한마디에 바로 배포했다. 첫 주는 순탄했다. CS팀에서 "AI가 생각보다 잘 답변한다"는 슬랙도 왔다.
둘째 주부터 리포트가 올라왔다. "AI가 환불 정책을 잘못 안내했다." "존재하지 않는 기능을 있다고 했다." 건건이 프롬프트 수정으로 때웠다. 셋째 주, 같은 유형이 또 터졌다. 프롬프트를 고칠수록 다른 데서 깨지는 두더지 잡기가 시작된 거다.
돌이켜보면 데모에서 테스트한 건 열 몇 개 질문이었다. 그것도 팀원들이 직접 던진, 예쁘게 정제된 질문들. 실제 고객은 오타 섞인 문장, 두 가지 질문을 한 문장에 우겨넣기, "아까 그거요" 같은 맥락 의존형 질문을 날린다. 데모 환경이 현실을 대변한다는 착각이 근본 원인이었다.
프롬프트 수정이 도박이 되는 순간
eval 셋이 없으면 프롬프트 변경의 효과를 검증할 수가 없다. A 케이스를 잡았더니 B가 망가지는 걸 눈치채려면 B를 직접 테스트해봐야 하는데, 그 B가 뭔지도 모른다. 결국 모든 수정이 "아마 괜찮겠지"로 끝난다.
이건 LLM 특유의 문제다. 전통적인 소프트웨어에서 함수 하나 고치면 영향 범위가 코드 의존성 그래프로 추적된다. 타입 체크, 유닛 테스트가 잡아준다. 프롬프트는 그런 게 없다. 시스템 프롬프트에 "환불은 30일 이내"를 추가하면, 전혀 관련 없어 보이는 배송 관련 답변의 톤이 달라질 수 있다. 프롬프트 변경은 전역 상태 변경이고, 부작용을 예측할 방법이 구조적으로 부재한다.
실제로 겪은 사례 하나. "답변을 간결하게 해줘"라는 지시를 시스템 프롬프트에 추가했더니, 환불 절차 안내에서 필수 단계 하나를 빼먹기 시작했다. 간결함과 완전성이 충돌한 건데, 이걸 프로덕션 CS 리포트가 올라오기 전까지 아무도 몰랐다.
셋째 주에 배포 롤백하고 eval 파이프라인부터 세웠다.
3일 만에 만든 구조
| 단계 | 하는 일 | 도구 |
|---|---|---|
| 골든 셋 | CS 로그에서 Q&A 50개 추출, 기대 답변 수동 작성 | 스프레드시트 |
| 자동 채점 | LLM-as-a-Judge로 정확성·완전성 각 0–5점 | Claude API |
| 회귀 테스트 | 프롬프트 변경 시 골든 셋 전량 자동 실행 | GitHub Actions |
| 샘플 리뷰 | 프로덕션 응답 5%를 매주 사람이 검수 | Slack 봇 연동 |
50개가 적어 보이지만 방향성을 잡기엔 충분했다. 이 구조를 넣은 뒤로 "고쳤더니 오히려 나빠짐" 사고가 한 건도 안 났다. 점수가 떨어지면 머지를 안 하면 되니까.
골든 셋 구성에서 가장 신경 쓴 건 엣지 케이스 비중이었다. 50개 중 20개는 해피 패스, 나머지 30개는 의도적으로 까다로운 케이스로 채웠다. 정책이 바뀐 시점의 질문, 두 정책이 충돌하는 질문, 고객이 분노한 톤의 질문. 해피 패스만으로 골든 셋을 채우면 높은 점수가 나오지만 실제 장애는 못 잡는다.
LLM-as-a-Judge 방식에도 한계가 있다는 건 안다. 채점하는 LLM 자체가 환각을 일으킬 수 있고, 미묘한 뉘앙스 차이를 잡아내지 못할 때도 있다. 그래서 샘플 리뷰 단계를 뺄 수 없다. 자동 채점은 명백한 회귀를 빠르게 걸러내는 용도이고, 진짜 품질 판단은 결국 사람 몫이다. 자동화 100%가 목표가 아니라 "눈에 띄는 문제를 배포 전에 잡는다"가 목표다.
핵심은 골든 셋의 크기가 아니라 회귀 테스트가 자동으로 돈다는 점이다. 프롬프트 PR을 올리면 CI에서 eval 돌리고, 평균 점수가 기존 대비 0.3점 이상 하락하면 머지 블로킹. 코드 리뷰처럼 프롬프트 리뷰가 된다.
한 가지 팁을 더 붙이면, 0.3점이라는 임계값도 고정이 아니다. 초기에는 0.5점으로 느슨하게 잡았다가, 골든 셋이 안정화되면서 0.3으로 조였다. 너무 엄격하면 사소한 표현 변경도 블로킹되어 개발 속도가 죽고, 너무 느슨하면 의미 있는 품질 하락을 놓친다. 이 값은 팀 상황에 맞게 조정해야 한다.
"eval 없이도 잘 되고 있는데요"
반론은 예상한다. 특히 트래픽이 적은 초기 서비스에서는 CS팀이 수동으로 전수 검토할 수도 있으니까. 맞다, 하루 문의가 20건이면 사람이 다 볼 수 있다. 하지만 200건이 되는 순간 수동 검토는 샘플링이 되고, 2000건이 되면 불가능해진다. eval 파이프라인은 스케일 문제다. 지금 안 필요해 보여도, 필요해지는 시점에 만들면 이미 장애가 터진 뒤다. 우리처럼.
그래서
eval 파이프라인 만드는 데 3일 걸렸다. 처음부터 했으면 롤백도 없었고, CS팀한테 사과 슬랙도 안 보냈을 거다. 데모에서 되는 것과 프로덕션에서 안정적인 것 사이의 거리는, 측정 가능 여부가 결정한다.