LLM 애플리케이션은 의미론적 (semantic) 수준에서 조용히 실패합니다. 표준 단위 테스트 (unit tests)는 함수가 값을 반환하는지 확인하지만, 출력이 사실적으로 틀렸는지, 어조가 맞지 않는지, 또는 단계가 누락되었는지는 감지할 수 없습니다. 평가 (Evals)는 프롬프트 (prompt)를 실행하고, 출력을 검사하며, 프로그래밍 방식 또는 판단을 통해 품질을 결정함으로써 이 문제를 해결합니다.

LLM 테스트가 다른 이유

단위 테스트는 비결정론 (non-determinism) 때문에 깨집니다. 온도 (Temperature) 설정에 따른 무작위성은 동일한 입력이 다양한 유효한 출력을 생성하게 만들며, 이는 정적 일치 확인 (static equality checks)을 무력화합니다. 의미론적 동등성 ("Paris is the capital" 대 "Capital is Paris")은 문자열 매칭을 무용지물로 만듭니다. 작은 모델 업데이트나 프롬프트 업데이트는 대규모 환경에서만 드러나는 점진적인 품질 드리프트 (quality drift)를 유발합니다. 어조와 정확성은 기본적인 단언 (assertions)으로 인코딩할 수 없는 판단을 필요로 합니다.

세 가지 평가 유형

**1. 휴리스틱 평가 (Heuristic Evals)**는 측정 가능한 속성인 JSON 유효성, 단어 수, 개인정보 (PII) 존재 여부 등을 확인합니다. 이는 빠르고 객관적이어서 모든 풀 리퀘스트 (pull request)에 대한 회귀 게이트 (regression gates)로 이상적입니다.

2. LLM-as-Judge는 두 번째 LLM을 사용하여 루브릭 (rubric)에 따라 출력을 채점합니다. 코드로 구현하기에는 너무 복잡하지만 수동 검토를 하기에는 너무 방대한 주관적 콘텐츠에 가장 적합합니다.

**3. 인간 평가 (Human Evals)**는 정답 (ground truth)입니다. 이를 사용하여 골든 데이터셋 (golden dataset)을 구축하고, LLM judge를 보정하며, 주요 출시 전에 최종 결정을 내리십시오.

평가 인프라 구축하기

최소한으로 시작하세요: Python 스크립트, 테스트 케이스가 담긴 JSON 파일, 그리고 LLM 출력을 단언 (assertions) 또는 루브릭과 비교하는 루프를 준비합니다. 엣지 케이스 (edge cases)와 적대적 프롬프트 (adversarial prompts)를 포함하여 실제 운영 환경을 대표하는 500~1000개의 요청으로 구성된 골든 데이터셋을 큐레이션하십시오. 사용자 행동 드리프트에 맞추기 위해 이를 분기별로 갱신하십시오.

GitHub Actions에서 테스트 하네스 (harness)를 자동화하십시오. 통과율이 임계값 미만으로 떨어지면 배포를 차단하십시오 (90%가 일반적인 시작점입니다). 모든 PR에는 빠른 휴리스틱 테스트를 실행하고, 전체 LLM-judge 평가는 매일 밤 실행하십시오.

주요 도구

• PromptFoo — 내장된 CLI 러너(runner)와 차이점 보고(diff reporting) 기능을 갖춘 YAML 기반의 오픈 소스 (Open-source) 테스트 케이스 도구입니다.
• Braintrust — 데이터셋 관리 및 실험 비교를 위한 호스팅 플랫폼입니다.
• Inspect — 영국 AI 안전 연구소 (UK AI Safety Institute)에서 개발한 오픈 소스 (Open-source) 프레임워크로, 엄격한 벤치마킹 (benchmarking)에 최적화되어 있습니다.

권장 사항 (Best Practices)

• 공개 벤치마크가 아닌, 귀하의 데이터에 맞춰 최적화하십시오. MMLU 점수는 귀하의 앱이 실제 운영 환경 (production)에서 요구하는 사항을 반영하지 않습니다.
• 완벽함보다는 커버리지 (coverage)를 우선시하십시오. 85%의 통과율을 가진 광범위하고 다양한 데이터셋이 99%의 통과율을 가진 좁은 데이터셋보다 낫습니다.
• 제공업체의 드리프트 (drift)를 고려하십시오. Anthropic과 OpenAI는 기반 모델을 조용히 업데이트합니다. 코드 변경이 없더라도 정기적으로 전체 평가를 실행하십시오.

최소 시작 경로 (Minimal Starting Path)

운영 환경 (production)에서 실제 요청 100개를 추출하십시오. 그중 50개를 수동으로 검토하여 정답 (ground-truth) 기준점을 구축하십시오. 기본적인 테스트 러너 (test runner) 스크립트를 작성하십시오. 하나의 휴리스틱 (heuristic) 체크를 구현하십시오. 이는 자동화된 테스트가 전혀 없는 상태보다 더 높은 안전성을 제공하며, 구축을 위한 토대가 됩니다.

참고 문헌 (References)

• LLM Evals in 2026: A Practical Guide to Testing Your AI App: https://devtoollab.com/blog/llm-evals-guide-2026
• PromptFoo — https://promptfoo.dev
• Braintrust — https://braintrust.dev
• Inspect (UK AISI) — https://inspect.ai.uk.gov