1장: LLM 평가의 필요성과 전체 프레임워크

LLM 애플리케이션은 왜 평가가 어려운가

전통적인 소프트웨어 테스트는 결정론적(Deterministic)입니다. 같은 입력에 대해 항상 같은 출력이 나오며, 정답이 명확하게 정의됩니다. 반면 LLM 애플리케이션은 근본적으로 다른 특성을 가집니다.

첫째, LLM의 출력은 비결정론적(Non-deterministic)입니다. 동일한 프롬프트에 대해서도 매번 다른 응답이 생성될 수 있으며, temperature 설정에 따라 변동 폭이 달라집니다. 둘째, 정답의 정의가 모호합니다. "좋은 요약"이란 무엇이고, "적절한 답변"이란 어떤 기준으로 판단해야 하는지 명확하지 않습니다. 셋째, 평가 차원이 다층적입니다. 정확성, 관련성, 유창성, 안전성, 지연 시간, 비용 등 여러 축을 동시에 고려해야 합니다.

전통적 소프트웨어 테스트:
  입력 A --> 함수 --> 출력 B (항상 동일, 통과/실패 명확)
 
LLM 애플리케이션 테스트:
  입력 A --> LLM --> 출력 B1, B2, B3... (매번 다름, 품질 스펙트럼)

이러한 특성 때문에 단순한 단위 테스트(Unit Test)만으로는 LLM 애플리케이션의 품질을 보장할 수 없습니다. 체계적인 평가 프레임워크가 필요합니다.

평가 없이 발생하는 문제들

환각의 무방비 노출

LLM이 사실과 다른 정보를 생성하는 환각(Hallucination) 현상은 모든 LLM에 내재된 문제입니다. 평가 체계 없이 프로덕션에 배포하면, 사용자에게 잘못된 정보가 그대로 전달됩니다. 의료, 법률, 금융 등 고위험 도메인에서는 이것이 직접적인 피해로 이어질 수 있습니다.

성능 저하의 감지 불능

LLM 제공업체가 모델을 업데이트하거나, 사용자 질문 패턴이 변화하거나, 외부 데이터 소스의 품질이 달라지면 애플리케이션의 응답 품질이 저하될 수 있습니다. 모니터링이 없으면 이러한 변화를 인지하지 못한 채 장기간 품질이 나빠진 상태로 운영하게 됩니다.

비용의 무분별한 증가

프롬프트 길이, 응답 토큰 수, API 호출 빈도 등을 추적하지 않으면 비용이 예측 불가능하게 증가합니다. 특히 에이전트 시스템에서 반복 호출이 발생하는 경우, 단일 사용자 요청이 수십 번의 API 호출로 이어질 수 있습니다.

LLM 평가의 세 가지 단계

LLM 애플리케이션의 평가는 개발 주기에 따라 세 단계로 나뉩니다.

1단계: 오프라인 평가 (Offline Evaluation)

개발 및 테스트 단계에서 수행하는 평가입니다. 미리 준비된 평가 데이터셋에 대해 모델의 응답을 생성하고, 정의된 메트릭으로 품질을 측정합니다. 프롬프트 변경, 모델 교체, 파라미터 조정 등의 영향을 배포 전에 파악할 수 있습니다.

오프라인 평가 흐름:
 
  평가 데이터셋 --> LLM 애플리케이션 --> 응답 생성 --> 메트릭 계산 --> 리포트
  (입력 + 기대 출력)                                    |
                                                      v
                                              기준치 충족 여부 판정

2단계: 온라인 평가 (Online Evaluation)

프로덕션 환경에서 실시간 트래픽을 대상으로 수행하는 평가입니다. A/B 테스트, 카나리 배포(Canary Deployment) 등을 통해 실제 사용자에게 미치는 영향을 측정합니다. 오프라인 평가에서 포착하지 못하는 실제 사용 패턴과 엣지 케이스(Edge Case)를 발견할 수 있습니다.

3단계: 지속 모니터링 (Continuous Monitoring)

배포 후 운영 중에 지속적으로 품질, 성능, 비용을 추적하는 단계입니다. 드리프트(Drift) 감지, 이상 탐지(Anomaly Detection), 알림(Alerting) 등을 통해 문제를 조기에 발견하고 대응합니다.

평가 프레임워크의 구성 요소

효과적인 LLM 평가 프레임워크는 다섯 가지 핵심 구성 요소로 이루어집니다.

평가 데이터셋

평가의 기반이 되는 입력-기대출력 쌍의 집합입니다. 도메인에 맞는 다양한 시나리오를 포괄해야 하며, 정기적으로 업데이트되어야 합니다. 황금 데이터셋(Golden Dataset)이라고도 부릅니다.

# 평가 데이터셋의 기본 구조
evaluation_dataset = [
    {
        "input": "파이썬에서 리스트와 튜플의 차이점을 설명해 주세요.",
        "expected_output": "리스트는 가변(mutable)이고 튜플은 불변(immutable)입니다...",
        "metadata": {
            "category": "programming",
            "difficulty": "beginner",
            "language": "ko"
        }
    },
    # ... 수백~수천 개의 평가 항목
]

메트릭 (Metrics)

응답의 품질을 수치화하는 기준입니다. 작업 유형에 따라 적절한 메트릭이 달라집니다.

평가자 (Evaluators)

메트릭을 실제로 측정하는 주체입니다. 크게 세 가지 유형이 있습니다.

• 코드 기반 평가자: BLEU, ROUGE, 정규식 매칭 등 프로그래밍 방식으로 계산하는 평가자
• LLM 기반 평가자: 다른 LLM을 활용하여 응답의 품질을 판단하는 방식 (LLM-as-Judge)
• 인간 평가자: 전문가 또는 크라우드소싱을 통한 인간 판단

실행 엔진 (Execution Engine)

평가 데이터셋을 LLM 애플리케이션에 입력하고, 응답을 수집하고, 메트릭을 계산하는 파이프라인입니다. 병렬 실행, 재시도 처리, 결과 저장 등의 기능을 포함합니다.

리포팅 (Reporting)

평가 결과를 시각화하고, 기준치 대비 품질 변화를 추적하고, 이해관계자에게 공유하는 체계입니다. 대시보드, 알림, 주기적 보고서 등이 해당됩니다.

주요 평가 도구와 프레임워크

현재 LLM 평가 생태계에는 다양한 오픈소스 도구와 상용 서비스가 있습니다.

오픈소스 프레임워크

상용 플랫폼

이 시리즈에서 다루는 내용

이 시리즈는 총 10장으로 구성되며, LLM 평가와 모니터링의 전체 주기를 다룹니다.

사전 지식과 준비 사항

이 시리즈를 효과적으로 학습하려면 다음 사전 지식이 도움이 됩니다.

• Python 기초: 코드 예제가 Python으로 작성됩니다
• LLM API 사용 경험: OpenAI, Anthropic 등 API 호출 경험
• 기본적인 통계 지식: 평균, 분산, 신뢰 구간 등의 개념
• 프로덕션 운영 경험: 로깅, 모니터링, CI/CD에 대한 기본 이해

개발 환경 설정은 다음과 같습니다.

# Python 3.11 이상 권장
python --version
 
# 가상환경 생성
python -m venv llm-eval-env
source llm-eval-env/bin/activate
 
# 핵심 패키지 설치
pip install openai anthropic ragas deepeval langsmith
pip install pandas numpy scikit-learn matplotlib

정리

LLM 애플리케이션은 비결정론적 특성, 다차원적 품질 기준, 지속적인 환경 변화로 인해 전통적인 소프트웨어 테스트만으로는 품질을 보장할 수 없습니다. 체계적인 평가 프레임워크는 오프라인 평가, 온라인 평가, 지속 모니터링의 세 단계로 구성되며, 각 단계에서 적절한 메트릭, 평가자, 실행 엔진, 리포팅 체계가 필요합니다.

다음 장에서는 LLM 평가의 핵심인 메트릭 설계를 다룹니다. 작업 유형별로 어떤 메트릭을 선택하고, 어떻게 정의하며, 어떻게 해석해야 하는지를 구체적으로 살펴보겠습니다.