생성형 AI 프로덕트의 리그레션 방지: LLM Evals(평가) 파이프라인과 자동화 테스트 설계

서론: “프롬프트 하나 고쳤더니 다른 기능이 망가졌다”

소프트웨어 공학에는 단위 테스트(Unit Testing)와 회귀 테스트(Regression Testing)라는 견고한 안전장치가 존재합니다. 그러나 많은 AI 엔지니어들이 프롬프트를 수정할 때 ‘눈대중(Vibe Checking)‘으로 몇 번 테스트해 보고 배포하는 위험한 관행에 의존하고 있습니다.

LLM은 비결정적(Non-deterministic) 특성을 지니고 있어, 하나의 버그를 고치기 위해 프롬프트를 튜닝하면 이전에 완벽히 작동하던 다른 시나리오가 조용히 망가지는 **‘기능 퇴행(Regression)‘**이 매우 빈번하게 발생합니다.

본 칼럼에서는 지속 가능한 AI 소프트웨어 개발을 위해 반드시 도입해야 할 정량적 LLM Evals(평가) 파이프라인의 설계 표준을 다룹니다.

1. 계층별 LLM 테스트 피라미드

전통적인 테스트 피라미드와 마찬가지로, LLM 테스트 역시 비용과 속도에 따라 3단계 계층으로 구성되어야 합니다.

       ▲
      / \     [Layer 3: Human Review & Golden Set] (가장 고비용, 최종 품질 검증)
     /   \
    /     \    [Layer 2: LLM-as-a-Judge (GPT-4o/Claude 3.5)] (의미론적 유사도, 유해성)
   /       \
  /_________\   [Layer 1: Deterministic Assertions] (정규식, JSON 스키마, 지연 시간)

결정론적 검증 (Deterministic Assertions):
- JSON 출력 스키마 준수 여부 (Zod, Pydantic)
- 필수 키워드 포함 여부 및 금지어(PII 개인정보) 필터링
- 첫 토큰 응답 시간(TTFT) 및 총 응답 지연 시간(Latency)
모델 기반 평가 (LLM-as-a-Judge):
- 더 상위 등급의 모델(Claude 3.5 Sonnet / GPT-4o)을 심사위원으로 지정하여 생성된 답변의 일관성과 정확도를 1~5점 척도로 루브릭(Rubric) 평가.
인간 검수 (Human in the loop):
- 불일치 점수가 높은 에지 케이스 데이터셋을 선별하여 도메인 전문가가 최종 검수.

2. RAG 파이프라인을 위한 3대 핵심 평가 지표 (RAG Triad)

검색 증강 생성(RAG) 시스템이 잘못된 답변을 내놓았을 때, 그것이 ‘검색기(Retriever)‘의 문제인지 ‘생성기(Generator)‘의 문제인지 분리 진단해야 합니다.

평가 지표	진단 질문	실패 원인 및 해결책
컨텍스트 관련성 (Context Relevance)	“검색된 문서들이 사용자 질문과 실질적으로 연관되어 있는가?”	임베딩 모델의 성능 저하 또는 청킹(Chunking) 단위가 너무 큼.
근거 충실도 (Groundedness / Faithfulness)	“모델의 답변이 검색된 문서의 팩트에 기반하고 있는가?”	모델의 환각 발생. 시스템 프롬프트에 “문서에 없는 내용은 모른다고 답하라”는 제약 강화.
답변 적합성 (Answer Relevance)	“최종 생성된 답변이 사용자가 질문한 본래 의도에 부합하는가?”	모델이 엉뚱한 부가 설명에 치중함. 프롬프트 내 Few-Shot 출력 형식 재정의.

결론: 측정할 수 없는 것은 개선할 수 없다

프롬프트 엔지니어링의 성패는 모델의 창의성이 아니라, 얼마나 신뢰할 수 있는 벤치마크 데이터셋(Golden Dataset)을 보유하고 있는가에 달려 있습니다.

코드 변경 시마다 자동으로 Evals 점수를 산출하고, 품질 저하 발생 시 배포를 자동 차단하는 CI/CD 안전망을 구축하십시오.

서론: “프롬프트 하나 고쳤더니 다른 기능이 망가졌다”

1. 계층별 LLM 테스트 피라미드

2. RAG 파이프라인을 위한 3대 핵심 평가 지표 (RAG Triad)

결론: 측정할 수 없는 것은 개선할 수 없다

DeltaSquared AI Research Lab