LLM 회귀 테스트는 프롬프트를 고친 뒤 “이번에는 더 좋아졌나?”만 보는 작업이 아닙니다.
진짜 목적은 새 프롬프트가 좋아진 부분 뒤에서 기존 기능을 조용히 망가뜨리지 않았는지 확인하는 것입니다.
LLM 기능은 출력이 매번 조금씩 달라질 수 있기 때문에, 일반 단위 테스트처럼 문자열 하나를 딱 맞추는 방식만으로는 부족합니다.
LLM 회귀 테스트를 먼저 한 줄로 보기
한 줄로 말하면 LLM 회귀 테스트는 대표 입력을 고정하고, 변경 전 baseline과 변경 후 결과를 같은 기준으로 비교하는 절차입니다.
프롬프트 변경은 코드 변경처럼 리뷰하고, 테스트하고, 이력을 남겨야 합니다.
왜 프롬프트 하나 고쳤는데 다른 기능이 망가질까
프롬프트는 코드보다 느슨해 보이지만 실제로는 기능의 규칙을 많이 담고 있습니다. 말투를 부드럽게 바꾸는 수정이 출력 형식을 흔들 수 있고, 답변을 짧게 하라는 지시가 필요한 근거를 빼먹게 만들 수 있습니다.
문제는 대부분 평균 점수 뒤에 숨어 있습니다. 전체적으로는 좋아졌지만 특정 고객 유형, 특정 언어, 특정 예외 케이스에서만 나빠지는 식입니다.
그래서 LLM 회귀 테스트는 “전체 점수 상승”보다 “망가진 케이스 탐지”에 더 가까워야 합니다.
golden set은 멋진 질문 모음이 아니다
golden set은 모델에게 던질 대표 입력과 기대 행동을 모아 둔 기준 세트입니다. 여기서 중요한 것은 어려운 질문만 모으는 것이 아니라 서비스에서 실제로 중요한 상황을 빠뜨리지 않는 것입니다.
- 자주 들어오는 정상 요청
- 정책 위반 가능성이 있는 요청
- 이전 장애나 불만이 있었던 요청
- 짧은 입력, 긴 입력, 애매한 입력
- 반드시 같은 형식을 지켜야 하는 요청
좋은 golden set은 한 번 만들고 끝나는 문서가 아닙니다. 운영 중에 새 실패가 발견되면 다음 회귀 테스트에 들어가야 합니다.
baseline 없이 새 결과만 보면 판단이 흔들린다
프롬프트를 고친 뒤 새 결과만 읽으면 사람은 쉽게 설득됩니다. 문장이 더 자연스럽거나 예시가 더 좋아 보이면 전체 품질이 올라간 것처럼 느껴집니다.
하지만 회귀 테스트에서는 같은 입력에 대해 이전 프롬프트의 결과와 새 프롬프트의 결과를 나란히 봐야 합니다. 그래야 좋아진 점과 잃어버린 점을 동시에 볼 수 있습니다.
{
"case_id": "refund_policy_ko_001",
"input": "환불이 안 되는 상품인데 고객에게 어떻게 답변해야 해?",
"baseline_result": "정책상 환불 불가 상품임을 안내하고 대안을 제시한다.",
"new_result": "환불이 가능할 수 있다고 안내한다.",
"regression": true,
"failure_category": "policy_violation"
}이런 기록이 쌓이면 프롬프트를 고칠 때 감으로 판단하지 않고, 어떤 유형이 자주 깨지는지 볼 수 있습니다.
실패 유형을 나눠야 다음 수정이 쉬워진다
LLM 회귀 테스트 결과를 pass/fail로만 저장하면 다음 개선이 어렵습니다. 실패가 왜 생겼는지 유형을 남겨야 합니다.
- format_error: JSON, 마크다운, 필드 구조가 깨짐
- policy_violation: 금지된 안내나 위험한 조언을 함
- missing_context: 주어진 근거를 충분히 쓰지 않음
- hallucination: 근거 없는 내용을 추가함
- tone_mismatch: 서비스 톤과 맞지 않음
이 분류는 완벽할 필요가 없습니다. 중요한 것은 프롬프트 수정 방향을 정할 만큼 반복 패턴이 보이는 것입니다.
LLM 회귀 테스트를 작게 시작하는 방법
처음부터 거대한 평가 시스템을 만들 필요는 없습니다. 작은 서비스라면 CSV나 JSON 파일 하나로도 시작할 수 있습니다.
- 핵심 기능 1개를 고른다
- 대표 입력 20~50개를 모은다
- 기대 행동과 금지 행동을 한 줄씩 적는다
- 현재 프롬프트 결과를 baseline으로 저장한다
- 프롬프트를 바꿀 때마다 같은 입력을 다시 돌린다
- 나빠진 케이스만 따로 리뷰한다
자동 채점이 어려운 항목은 사람 리뷰를 섞어도 됩니다. 중요한 것은 매번 다른 기준으로 느낌만 보는 일을 줄이는 것입니다.
정리
LLM 회귀 테스트는 프롬프트를 더 조심스럽게 바꾸기 위한 안전장치입니다. golden set, baseline, 실패 유형, 변경 기록이 있으면 작은 수정이 다른 기능을 망가뜨리는 일을 더 빨리 발견할 수 있습니다.
LLM 품질 검증의 기본 흐름은 AI eval은 왜 필요할까에서 함께 보면 좋습니다. 서비스 구조 관점에서는 LLM 서비스 경계는 어디에 둘까도 같이 읽을 수 있습니다.
공식 문서 기준의 eval 개념은 OpenAI evals 문서에서 확인할 수 있습니다.
