LLM 시스템 평가: 지표, 방법론 및 스코어카드

원문은 BlockSimplified에 게시되었습니다 — 읽는 데 11분 소요

이 포스트는 제가 응용 AI (Applied AI) 개념에 대해 학습한 내용을 기록하는 AI Fluency 시리즈의 일부입니다. 목표는 여러분이 실제 프로젝트에 적용할 수 있는 실무 기술을 쌓도록 돕는 것입니다.

LLM 개발에 대한 냉혹한 진실은 이렇습니다. 대부분의 팀이 적절한 평가 (Evaluation) 없이 제품을 출시한다는 점입니다. 몇 번의 수동 테스트를 실행하고, 결과물이 "좋아 보이면" 완료되었다고 생각합니다. 그러다 사용자들이 이상한 응답에 대해 불평하기 시작하면, 갑자기 누구도 이 문제가 프롬프트 (Prompt) 때문인지, 모델 (Model) 때문인지, 아니면 검색 파이프라인 (Retrieval Pipeline) 때문인지 알지 못하게 됩니다.

저도 그런 경험이 있습니다. LLM 프로젝트 초기에는 프롬프트를 수정하고, 몇 개의 결과물을 눈으로 확인한 뒤 배포하곤 했습니다. 생산적이라고 느꼈죠. 하지만 운영 환경 (Production)에서 무언가 고장 났을 때, 비교할 수 있는 기준점 (Baseline)이 없었습니다. 새로운 프롬프트가 실제로 도움이 되었을까요? 모델이 항상 엣지 케이스 (Edge Cases)에 이렇게 취약했던 걸까요? 전혀 알 수 없었습니다.

**평가 및 테스트 (Evaluation & Testing)**는 단순히 버그를 잡는 것만이 아닙니다. 그것은 개선을 위한 나침반입니다. 체계적인 평가 없이는, 직관이 자주 실패하는 영역에서 감에 의존하여 항해하는 것과 같습니다.

평가가 어려운 이유 (그리고 왜 대부분의 팀이 이를 건너뛰는가)

LLM은 전통적인 소프트웨어와 다릅니다. 두 숫자를 더하는 함수를 테스트할 때는 예상되는 출력값이 명확합니다. 하지만 LLM의 경우, "정답"은 주관적이고, 문맥 의존적이며, 종종 정확하게 정의하는 것이 불가능합니다.

이 상황을 생각해 보십시오: LLM에게 기사를 요약해 달라고 요청합니다. 수십 가지의 유효한 요약본이 존재할 수 있습니다. 어떤 것은 핵심 논점에 집중하고, 어떤 것은 뒷받침하는 세부 사항에 집중합니다. 어떤 것은 격식 있고, 어떤 것은 대화체입니다. 이것을 어떻게 점수화할 수 있을까요?

이러한 모호함 때문에 팀들은 평가를 완전히 건너뛰게 됩니다. 불확실한 이득을 위해 너무 많은 노력을 들여야 하는 것처럼 느껴지기 때문입니다. 하지만 평가를 건너뛴다는 것은 다음과 같은 상황을 의미합니다:

• 프롬프트 (Prompt) 변경 시 눈을 가리고 비행하는 것과 같음
• 모델을 객관적으로 비교할 수 없음
• 사용자에게 피해를 주는 성능 저하 (Regression)를 놓침
• 신뢰할 수 없는 기반 위에 구축함

좋은 소식은, 평가가 유용하기 위해서 반드시 완벽할 필요는 없다는 것입니다. 대략적인 지표라도 없는 것보다는 훨씬 낫습니다. 실용적인 평가 시스템을 구축하는 방법을 보여드리겠습니다.

평가 피라미드: 세 가지 엄격함의 단계

저는 LLM 평가를 세 가지 단계로 이루어진 피라미드로 생각합니다. 각 단계는 정확도 (Accuracy)와 확장성 (Scalability) 사이에서 절충(Trade-off)을 이룹니다.

레벨 1: 인간 평가 (Human Evaluation, 황금 표준)

**인간 평가 (Human Evaluation)**는 가장 정확하지만 확장성이 가장 낮습니다. 실제 사람이 유용성 (Helpfulness), 정확성 (Accuracy), 어조 (Tone)와 같은 기준에 따라 실제 출력을 평가합니다.

사용 시점:

• 자동화된 지표가 실제 품질과 상관관계가 있는지 검증할 때
• "이것이 자연스럽게 들리는가?"와 같은 주관적인 기준을 평가할 때
• 오류의 비용이 큰 고위험 (High-stakes) 애플리케이션
• 골든 데이터셋 (Golden dataset)을 위한 초기 라벨을 생성할 때

잘 수행하는 방법:

1. 명확한 기준을 정의하십시오. "품질을 평가하라"와 같은 모호한 지침은 일관성 없는 점수로 이어집니다. 대신 다음과 같이 명시하십시오: "유용성을 1~5점으로 평가하십시오. 1점은 응답이 질문에 전혀 답하지 않음을 의미하며, 5점은 실행 가능한 세부 사항과 함께 질문에 완전히 답변함을 의미합니다."

2. 여러 명의 주석가 (Annotator)를 사용하십시오. 최소한 3명이 각 응답을 평가하도록 하십시오. 코헨의 카파 (Cohen's Kappa)를 사용하여 평가자 간 일치도 (Inter-rater agreement)를 계산하십시오. 일치도가 낮다면 (0.6 미만), 가이드라인을 수정해야 합니다.

3. 교정 예시 (Calibration examples)를 포함하십시오. 주석가들이 시작하기 전에 각 점수 수준에 해당하는 응답 예시를 보여주십시오. 이는 그들의 판단 기준을 고정(Anchor)해 줍니다.

실질적인 현실: 인간 평가는 비용이 많이 듭니다. 운영 환경(Production)의 모든 응답을 사람이 검토할 수는 없습니다. 이것이 바로 자동화된 방법이 필요한 이유입니다.

레벨 2: LLM-as-a-Judge (확장 가능한 품질 평가)

LLM-as-a-Judge는 성능이 뛰어난 모델을 사용하여 시스템의 출력을 평가합니다. 이는 인간보다 빠르고 저렴하면서도, 단순한 지표(metrics)보다 더 미세한 차이를 포착할 수 있습니다.

기본 패턴:

judge_prompt = """
당신은 전문 평가자입니다. 다음 응답의 유용성(HELPFULNESS)을 1-5점 척도로 평가하세요.
...

주요 고려 사항:

1. 더 강력한 모델을 판사(judge)로 사용하세요. 만약 GPT-3.5의 출력을 평가하고 있다면, 판사로는 GPT-4를 사용하세요. 판사는 평가 대상이 되는 모델만큼, 혹은 그보다 더 유능해야 합니다.

2. 인간의 라벨(human labels)과 대조하여 검증하세요. 인간의 점수가 있는 데이터 세트에 판사 모델을 실행해 보세요. 상관관계(correlation)가 0.7 미만이라면 루브릭(rubric, 평가 기준)을 개선해야 합니다.

3. 편향(biases)을 주의하세요. LLM은 장황한 응답을 선호하거나 자신의 학습 데이터와 유사한 출력을 선호할 수 있습니다. 평가 과정에서 이러한 패턴이 나타나는지 확인하세요.

4. 가능하다면 참조 가이드 기반 판정(reference-guided judging)을 사용하세요. 판사 모델에게 참조 답변(reference answer)을 제공하면 일관성이 향상됩니다.

레벨 3: 자동화된 지표 (빠르지만 제한적임)

자동화된 **평가 지표 (Evaluation Metrics)**는 가장 빠르고 저렴한 옵션입니다. 이들은 LLM 호출 없이 알고리즘적으로 점수를 계산합니다.

전통적인 NLP 지표:

지표 (Metric)	측정 대상	용도
BLEU	참조 문장과의 N-gram 중첩도	번역
...

문제점: 이러한 지표들은 실제 품질이 아닌 표면적인 유사성을 측정합니다. 응답이 유용하고 정확하더라도, 참조 문장과 다른 단어를 사용했다는 이유로 낮은 점수를 받을 수 있습니다.

자동화된 지표가 효과적인 경우:

• 명확한 정답이 있는 작업 (수학, 테스트 케이스가 있는 코딩)
• 명백한 실패 감지 (빈 응답, 오류)
• 시간에 따른 트렌드 추적 (불완전한 지표라도 방향성은 보여줌)

RAG 전용 평가: 중요한 지표들

검색 증강 생성 (Retrieval-Augmented Generation, RAG) 시스템을 구축하고 있다면, 일반적인 평가만으로는 부족합니다. 검색 품질(retrieval quality)과 생성 품질(generation quality)을 모두 평가할 수 있는 지표가 필요합니다.

검색 지표 (Retrieval Metrics)

LLM이 컨텍스트 (context)를 확인하기도 전에, 올바른 문서를 검색했습니까?

• 컨텍스트 정밀도 (Context Precision): 검색된 문서 중 실제로 관련이 있는 문서는 얼마나 됩니까?
• 컨텍스트 재현율 (Context Recall): 코퍼스 (corpus) 내의 모든 관련 문서 중 얼마나 많은 문서를 검색했습니까?
• Recall@K / Precision@K: 상위 K개의 결과로 제한된 위 지표들의 버전입니다.

이것이 중요한 이유: 검색 (retrieval)에 실패하면, 아무리 뛰어난 LLM이라도 좋은 답변을 내놓을 수 없습니다. 항상 검색을 독립적으로 평가하십시오.

생성 지표 (Generation Metrics) (RAG 특화)

이 지표들은 검색된 컨텍스트가 주어졌을 때 LLM의 출력을 평가합니다.

충실도 (Faithfulness): 답변이 컨텍스트에 있는 내용에 충실합니까? 이는 모델이 검색된 문서에 의해 뒷받침되지 않는 사실을 지어내는 환각 (hallucinations) 현상을 잡아냅니다.

답변 관련성 (Answer Relevance): 답변이 실제로 사용자의 질문에 답하고 있습니까? 답변이 컨텍스트에는 충실할 수 있지만, 사용자가 질문한 내용을 놓칠 수도 있습니다.

답변 정확성 (Answer Correctness): 답변이 사실적으로 정확합니까? 이는 사용 가능한 경우 정답 (ground truth) 답변과 비교합니다.

RAGAS 프레임워크 (RAGAS Framework)

RAGAS (Retrieval Augmented Generation Assessment) 프레임워크는 이러한 지표들에 대한 구조화된 접근 방식을 제공합니다. 이 프레임워크는 내부적으로 LLM-as-a-Judge를 사용하여 각 차원을 점수화합니다.

# 개념적 예시 - 실제 RAGAS API는 다를 수 있습니다
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_precision
...

에이전트 평가 (Agent Evaluation): 단일 턴 응답을 넘어

**AI 에이전트 (AI Agents)**를 평가하는 것은 다른 차원의 도전 과제입니다. 에이전트는 여러 단계를 거치고, 도구 (tools)를 사용하며, 그 성공 여부는 단순히 좋은 텍스트를 생성하는 것이 아니라 목표를 달성하는지에 달려 있습니다.

목표 달성률 (Goal Completion Rate)

에이전트가 사용자가 요청한 것을 완수했습니까? 여행 계획 에이전트라면 실제로 항공권을 예약했습니까? 조사 에이전트라면 정보를 찾아냈습니까?

이는 이진 지표 (binary metric, 성공/실패)이지만 믿을 수 없을 정도로 중요합니다. 유창한 텍스트를 생성하지만 작업을 완료하지 못하는 에이전트는 쓸모가 없습니다.

도구 사용 정확도 (Tool-Use Accuracy)

에이전트가 도구를 사용하기로 결정했을 때, 다음을 수행합니까?

• 상황에 맞는 올바른 도구를 선택하는가?
• 정확한 파라미터 (Parameters)를 제공하는가?
• 도구의 결과값을 적절하게 사용하는가?

이 각각의 항목을 별도로 추적하십시오. 에이전트가 도구 선택은 잘하지만 파라미터 형식을 맞추는 데는 서툴다는 사실을 발견할 수도 있습니다.

궤적 분석 (Trajectory Analysis)

다단계 작업 (Multi-step tasks)의 경우, 전체 궤적 (Trajectory)을 검토하십시오.

• 몇 단계가 소요되었는가? (효율성 (Efficiency))
• 오류로부터 회복했는가? (강건성 (Robustness))
• 불필요한 우회 경로를 택했는가? (계획 품질 (Planning quality))

안전 위반율 (Safety Violation Rate)

실제 환경에서 동작하는 에이전트에게 특히 중요합니다. 에이전트가 다음과 같은 행동을 한 적이 있습니까?

• 승인되지 않은 작업을 시도했는가?
• 민감한 정보를 유출했는가?
• 명시적인 제약 조건을 위반했는가?

의미 있는 능력을 갖춘 프로덕션 에이전트에게 0.1%의 위반율조차 너무 높습니다.

평가 스코어카드 구축하기

스코어카드 (Scorecard)는 모든 지표를 하나의 뷰로 통합합니다. 이를 통해 시스템이 건강한 상태인지 한눈에 파악할 수 있습니다.

포함해야 할 항목

핵심 지표 (Core metrics) (항상 추적):

• 전체 품질 점수 (LLM-as-Judge, 1-5)
• 충실도 (Faithfulness, RAG의 경우)
• 목표 달성률 (Goal completion rate, 에이전트의 경우)
• 안전 위반율 (Safety violation rate)

진단 지표 (Diagnostic metrics) (핵심 지표가 하락할 때 심층 분석):

• 컨텍스트 정밀도/재현율 (Context precision/recall, RAG 검색 건강도)
• 도구 사용 정확도 (Tool-use accuracy, 에이전트 역량)
• 지연 시간 및 토큰 사용량 (Latency and token usage, 운영 건강도)

골든 데이터셋 (The Golden Dataset)

**골든 데이터셋 (Golden Dataset)**은 신뢰할 수 있는 평가를 위한 토대입니다. 이는 검증된 기대 출력값이 포함된 정제된 입력 세트입니다.

구축 방법:

1. 실제 쿼리로 시작하십시오. 프로덕션 로그(익명화 처리됨)에서 추출하십시오. 이는 실제 사용자의 요구를 나타냅니다.

2. 엣지 케이스 (Edge cases)를 포함하십시오. 실패를 유발했던 쿼리를 추가하십시오. 이것이 회귀 테스트 (Regression tests)가 됩니다.

3. 전문가 검증을 거치십시오. 도메인 전문가가 참조 답변을 작성하거나 검증하도록 하십시오.

4. 관리 가능한 수준을 유지하십시오. 1,000개의 부실한 예시보다 50~100개의 고품질 예시가 더 낫습니다. 양보다 질입니다.

사용 방법:

어떠한 변경 사항이 발생하든 골든 데이터셋 (Golden Dataset)을 실행하십시오:

• 새로운 프롬프트 (Prompt) 버전? 골든 데이터셋을 실행하십시오.
• 모델 업그레이드? 골든 데이터셋을 실행하십시오.
• 검색 파이프라인 (Retrieval pipeline) 변경? 골든 데이터셋을 실행하십시오.

점수를 기준점 (Baseline)과 비교하십시오. 품질이 저하된다면 배포하기 전에 조사하십시오.

자동 회귀 테스트 (Automated Regression Testing)

골든 데이터셋 평가를 CI/CD 파이프라인에 통합하십시오:

# 개념적인 GitHub Actions 워크플로우
name: LLM Evaluation
on: [pull_request]
...

실무 구현: 어디서부터 시작할 것인가

LLM 평가를 이제 막 시작하려는 단계라면, 제가 권장하는 순서는 다음과 같습니다:

1주 차: 골든 데이터셋 (Golden Dataset) 생성

• 실제 운영 환경이나 브레인스토밍을 통해 대표적인 쿼리 (Query) 30~50개를 추출합니다.
• 각 쿼리에 대한 참조 답변 (Reference answers)을 작성합니다.
• 10개 이상의 엣지 케이스 (Edge cases) 또는 알려진 실패 시나리오를 포함합니다.

2주 차: LLM-as-a-Judge 설정

• 주요 품질 기준에 대한 판사 프롬프트 (Judge prompt)를 작성합니다.
• 골든 데이터셋에 대해 이를 실행합니다.
• 판사의 출력이 타당한지 확인하기 위해 수동으로 검토합니다.

3주 차: 검증 및 반복 (Iterate)

• 동일한 응답의 일부 서브셋에 대해 사람이 직접 점수를 매기게 합니다.
• 사람의 점수와 판사의 점수를 비교합니다.
• 상관관계가 적절해질 때까지 판사 프롬프트를 개선합니다 (0.7 이상을 목표로 합니다).

4주 차: 자동화

• 평가를 배포 프로세스에 통합합니다.
• 품질 임계값 (Quality thresholds)을 설정하여 품질이 낮은 배포를 차단합니다.
• 시간에 따른 지표를 추적할 수 있는 대시보드를 만듭니다.

지속적인 작업: 확장 및 유지 관리

• 실패 사례를 발견할 때마다 골든 데이터셋에 새로운 예시를 추가합니다.
• 새로운 차원(안전성, 지연 시간 등)에 대한 지표를 추가합니다.
• 분기별로 검토하고 업데이트합니다.

피해야 할 흔한 실수

목표가 아닌 지표를 최적화하는 것. 지표는 품질을 나타내는 대리 지표 (Proxy)일 뿐, 품질 그 자체는 아닙니다. 만약 판사의 점수를 극대화하기 위해 프롬프트를 튜닝한다면, 실제 사용자의 요구사항이 아닌 판사의 선호도에 과적합 (Overfit)될 수 있습니다.

골든 데이터셋의 예시가 너무 적은 것. 사용 사례에 대한 커버리지가 필요합니다. 50개의 예시는 최소치이며, 100개가 더 좋습니다. 하지만 단순한 양이 아니라 품질과 다양성에 집중하십시오.

판단자(Judge)를 검증하지 않는 것. LLM 판단자(LLM judge)는 체계적인 편향(systematic biases)을 가질 수 있습니다. 이를 신뢰하기 전에 항상 인간의 판단(human judgment)과의 상관관계(correlation)를 확인하십시오.

고립된 상태에서의 평가. 특정 구성 요소(component)가 개별적으로는 높은 점수를 받을 수 있지만, 전체 파이프라인(pipeline) 내에서는 실패할 수 있습니다. 부분적인 테스트가 아닌 엔드 투 엔드(end-to-end) 테스트를 수행하십시오.

정적인 평가 세트. 당신의 애플리케이션은 진화합니다. 평가 세트(evaluation set) 또한 마찬가지여야 합니다. 정기적으로 검토하고 업데이트하십시오.

핵심 요약 (Key Takeaways)

핵심 개념 (Key Concepts)