RAG 및 코드 생성 평가

4.0 장 구성 로드맵

이 장은 크게 두 부분으로 나뉜다. 전반부(4.1~4.9)는 RAG 평가를, 후반부(4.10~4.19)는 코드 생성 평가를 다룬다. 두 부분 모두 "왜 다른가 → 메트릭의 수학적 정의 → 프레임워크 비교 → 실무 구현 → 사례 연구"의 동일한 흐름을 따른다.

4.1 RAG 평가는 왜 다른가

RAG는 외부 지식 베이스(knowledge base)에서 관련 문서를 검색하여 LLM의 생성에 주입하는 아키텍처다. Lewis et al. (2020, "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", arXiv:2005.11401)이 정식화한 이래, 환각(hallucination)을 줄이고 지식을 최신 상태로 유지하는 사실상의 표준 패턴이 되었다. 문제는 평가다. 순수 LLM은 입력→출력의 단일 함수지만, RAG는 여러 단계가 직렬로 연결된 파이프라인이다. 어느 단계에서 실패했는지를 구분하지 못하면 개선의 방향을 잡을 수 없다.

4.1.1 RAG 파이프라인의 다섯 구성 요소

전형적인 RAG 파이프라인은 다음 다섯 단계로 분해된다. 각 단계는 독립적인 실패 지점(failure point)이며, 따라서 독립적인 평가 대상이다.

예컨대 "Query Understanding"에서 질문의 핵심 의도를 잘못 파악하면, 그 뒤의 모든 단계가 잘못된 방향으로 흘러간다. 반대로 검색과 컨텍스트 선택이 완벽해도 Generation 단계에서 LLM이 컨텍스트를 무시하고 자신의 파라미터 지식(parametric knowledge)으로 답하면 환각이 발생한다. 따라서 RAG 평가는 본질적으로 단계별 책임 귀속(attribution) 문제다.

4.1.2 핵심 통찰: "답변이 맞더라도, 검색이 잘못되었으면 문제다"

RAG 평가에서 가장 반직관적인 명제가 이것이다. 최종 답변이 사실적으로 정확하더라도, 그 정확성이 검색된 컨텍스트가 아니라 LLM의 내부 지식에서 비롯되었다면 그 RAG 시스템은 신뢰할 수 없다. 왜냐하면 그 시스템은 지식 베이스가 업데이트되어도 반영하지 못하고, 출처를 제시할 수 없으며, 도메인 특화 정보(예: 사내 문서)에서는 환각으로 직행할 것이기 때문이다. 즉 "운 좋게 맞은" 답은 평가에서 감점되어야 한다.

4.1.3 RAG의 세 가지 실패 양식

RAG 시스템이 실패하는 방식은 표면적으로는 "틀린 답"이지만, 그 원인은 세 가지로 명확히 구분된다. 이 분류는 RAGAS의 네 메트릭이 무엇을 잡으려 하는지를 이해하는 출발점이다.

세 양식은 서로 다른 메트릭으로 잡힌다. Faithfulness가 낮으면 생성 단계의 환각, Context Recall이 낮으면 검색 단계의 누락, Context Precision이 낮으면 컨텍스트 선택 단계의 잡음이다. 이 대응 관계가 RAGAS 설계 철학의 핵심이며, 이를 통해 "어디를 고쳐야 하는가"가 즉시 도출된다.

4.2 RAG 평가의 세 레벨

RAG 평가는 위계적으로 세 레벨로 구성된다. 아래에서 위로 올라갈수록 통합적이지만 진단력은 떨어진다. 실무에서는 세 레벨을 모두 측정하되, 문제 발생 시 위에서 아래로 드릴다운(drill-down)한다.

4.2.1 레벨 1: Retrieval Quality와 고전 IR 메트릭

검색 품질은 정보 검색(Information Retrieval, IR) 분야가 수십 년간 정제해 온 메트릭으로 측정한다. 가장 기본은 Precision@k와 Recall@k다. 상위 k개 결과 중 관련 문서의 비율(정밀도)과, 전체 관련 문서 중 상위 k에 포함된 비율(재현율)이다.

그러나 P@k와 R@k는 순위(rank)를 무시한다. 관련 문서가 1위에 있든 10위에 있든 같은 점수다. 검색에서는 순위가 결정적이므로, 순위를 반영하는 메트릭이 필요하다. 대표적으로 MRR(Mean Reciprocal Rank)과 nDCG(normalized Discounted Cumulative Gain)가 있다.

이 IR 메트릭들은 정답 관련도 라벨만 있으면 LLM 호출 없이 즉시 계산할 수 있어, RAG 검색 단계의 빠르고 저렴한 진단 도구다. 아래는 nDCG와 MRR을 함께 산출하는 구현이다.

4.2.2 레벨 2: Generation Quality와 reference-free 평가

생성 품질의 핵심 난점은 "정답(reference)이 없거나 다양하다"는 것이다. RAG의 답변은 검색된 컨텍스트에 의존하므로, 고정된 정답 문장과의 BLEU·ROUGE 비교는 의미가 없다. 그래서 RAGAS는 reference-free 평가를 지향한다 — 정답 문장 대신 "답변이 컨텍스트에 충실한가", "답변이 질문에 직접 답하는가"를 LLM과 NLI(Natural Language Inference) 모델로 판정한다. 이것이 다음 절(4.3~4.5)의 주제다.

4.2.3 레벨 3: End-to-End Quality와 그 함정

전체 품질은 사용자가 실제로 체감하는 것이지만, 그 자체로는 진단 정보가 거의 없다. "정확도 72%"라는 숫자는 무엇을 고쳐야 할지 알려주지 않는다. 더구나 앞서 말한 "운 좋게 맞은 답" 문제 때문에, 높은 E2E 정확도가 좋은 RAG 시스템을 보장하지도 않는다. 따라서 E2E는 최종 KPI로 추적하되, 개선 작업은 항상 레벨 1·2로 내려가서 수행한다.

4.3 RAGAS 심층 (1) — Faithfulness

RAGAS(Es et al., 2024, "RAGAS: Automated Evaluation of Retrieval Augmented Generation", arXiv:2309.15217)는 RAG 평가의 사실상 표준 프레임워크다. 네 가지 핵심 메트릭 — Faithfulness, Answer Relevance, Context Precision, Context Recall — 을 reference-free로 산출하며, LlamaIndex·LangChain에 공식 통합되어 있다. 가장 먼저 Faithfulness(충실도)부터 해부한다.

4.3.1 정의: 모든 claim이 컨텍스트에서 지지되는가

Faithfulness는 "생성된 답변의 모든 주장(claim)이 검색된 컨텍스트에 의해 지지되는가"를 측정한다. 직관적으로 이것은 환각(hallucination)의 정량적 반대 개념이다. 답변을 개별 claim들로 분해한 뒤, 각 claim이 컨텍스트로부터 추론 가능한지를 NLI(자연어 추론) 방식으로 판정한다.

4.3.2 계산 절차: claim 추출 → NLI 판정

Faithfulness 계산은 두 단계로 이뤄진다. 첫째, LLM을 사용해 답변을 원자적(atomic) claim들로 분해한다. 둘째, 각 claim에 대해 "이 claim이 주어진 컨텍스트로부터 추론될 수 있는가?"를 NLI 모델 또는 LLM 판사로 판정한다(entailment / contradiction / neutral). entailment로 판정된 claim의 비율이 Faithfulness 점수다.

4.3.3 시나리오 1 — 완전한 환각

구체적 예시로 메커니즘을 보자. 컨텍스트와 답변, 그리고 claim별 판정이다.

컨텍스트: "에펠탑은 1889년 파리 만국박람회를 위해 건설되었으며 높이는 약 330미터다."

답변: "에펠탑은 1889년에 건설되었고, 높이는 약 330미터이며, 귀스타브 에펠이 노벨상을 받았다."

3개 claim 중 2개가 지지되므로 $F = 2/3 \approx 0.67$이다. 답변의 일부는 정확하지만 환각이 섞여 있어 충실도가 감점되었다. 주목할 점은 claim 3이 사실 여부와 무관하게 감점된다는 것이다. 설령 에펠이 실제로 노벨상을 받았더라도(받지 않았지만), 그것이 컨텍스트에 없으면 RAG 관점에서는 "근거 없는 진술"이다.

4.3.4 시나리오 2 — 부분 충실(추론 비약)

컨텍스트: "이 약물은 임상 1상에서 안전성이 확인되었다."

답변: "이 약물은 안전하며 시판이 승인되었다."

$F = 0/2 = 0.0$. 이 사례는 Faithfulness의 진가를 보여준다. 답변이 명백한 거짓말은 아니지만 컨텍스트가 보장하지 않는 강한 결론으로 비약했다. 의료·법률처럼 정밀함이 생명인 도메인에서 이런 "근거 없는 단정"은 치명적이며, Faithfulness가 정확히 이를 잡아낸다.

4.3.5 시나리오 3 — 완전 충실

컨텍스트: "회사의 2023년 매출은 50억 원으로 전년 대비 20% 증가했다."

답변: "2023년 매출은 50억 원이며 전년보다 20% 늘었다."

$F = 2/2 = 1.0$. 모든 주장이 컨텍스트에 근거하므로 완전 충실하다. 이것이 RAG가 지향하는 이상적 답변이다 — 컨텍스트를 충실히 종합하되 그 너머로 나아가지 않는다.

4.3.6 인터랙티브 데모 — Faithfulness 추정기

아래 데모는 답변의 claim 수와 그중 컨텍스트에서 지지되는 수를 입력하면 Faithfulness를 즉시 계산한다(실제 RAGAS는 LLM/NLI가 이 판정을 자동화한다).

4.3.7 NLI 모델이라는 토대 — Faithfulness의 신뢰도 상한

Faithfulness와 Context Recall은 모두 NLI(자연어 추론) 판정에 의존하므로, 그 신뢰도가 메트릭의 신뢰도 상한을 결정한다. NLI는 전제(premise)와 가설(hypothesis) 쌍을 entailment·contradiction·neutral로 분류하는 과제로, MNLI(Williams et al., 2018, "A Broad-Coverage Challenge Corpus for Sentence Understanding through Inference", NAACL 2018, arXiv:1704.05426) 같은 대규모 코퍼스로 학습된 모델이 표준이다. RAGAS는 컨텍스트를 전제로, 각 claim을 가설로 두어 entailment 여부를 판정한다.

문제는 NLI 모델이 수량("3개 이상" vs "정확히 3개"), 부정("안전하지 않다"의 이중 부정), 시제, 함축("1상 안전"으로부터 "안전")에서 자주 틀린다는 점이다. 이 때문에 도메인이 정밀할수록(의료·법률) 범용 NLI 모델의 오판이 늘어, 4.6.2에서 지적한 한계가 증폭된다. 실무에서는 (1) 도메인 NLI 파인튜닝, (2) 강한 LLM을 NLI 판사로 대체, (3) 4.6의 권고대로 인간 골드셋으로 NLI 판정의 정확도 자체를 검증하는 보정 절차를 둔다.

4.4 RAGAS 심층 (2) — Answer Relevance

Faithfulness가 "답변이 컨텍스트에 충실한가"라면, Answer Relevance(답변 관련성)는 "답변이 질문에 직접 답하는가"를 측정한다. 충실하지만 동문서답인 답변이 가능하므로, 이 둘은 독립적이다.

4.4.1 정의와 직관: 역질문(reverse question)

RAGAS의 Answer Relevance는 기발한 아이디어에 기반한다 — "이 답변에서 어떤 질문이 유도되는가?"를 LLM에게 묻고, 그 역질문(reverse question)이 원래 질문과 얼마나 유사한지를 측정한다. 직관은 명료하다. 답변이 질문에 잘 답했다면, 그 답변만 보고도 원래 질문을 복원할 수 있어야 한다. 동문서답이거나 장황한 답변은 원래 질문과 동떨어진 역질문을 유도한다.

4.4.2 코사인 유사도의 정의

역질문과 원질문의 유사도는 임베딩 공간에서의 코사인 유사도로 측정한다. 코사인 유사도는 두 벡터가 이루는 각도의 코사인으로, 벡터의 크기가 아닌 방향만 비교하므로 길이가 다른 문장 간 의미 유사도에 적합하다.

4.4.3 구현

4.4.4 Answer Correctness — 의미 유사도와 사실 일치의 결합

Faithfulness·Answer Relevance가 reference-free였다면, ground truth 답변이 있을 때는 더 직접적인 Answer Correctness(답변 정확성)를 측정할 수 있다. RAGAS의 Answer Correctness는 두 성분의 가중합이다 — (1) 답변과 정답의 의미 유사도(semantic similarity, 임베딩 코사인), (2) 사실 단위의 일치도(factual overlap, claim 수준 F1). 표면 일치가 아닌 의미·사실 수준에서 비교한다는 점이 핵심이다.

사실 F1이 환각(FP)과 누락(FN)을 동시에 벌점한다는 점에 주목하라. 이는 Faithfulness(환각만)와 Context Recall(누락만)을 ground truth 기준으로 합친 형태로 볼 수 있다. 의미 유사도 성분은 표현이 다르되 뜻이 같은 답변(의역)에 관대함을 부여한다.

4.5 RAGAS 심층 (3) — Context Precision과 Context Recall

앞의 두 메트릭이 생성 품질(레벨 2)이었다면, Context Precision과 Context Recall은 검색 품질(레벨 1)을 본다. 전자는 "관련 문서를 상위에 잘 배치했는가", 후자는 "필요한 정보를 다 가져왔는가"이다.

4.5.1 Context Precision — 순위 가중 정밀도

Context Precision은 검색된 문서들 중 관련 문서가 상위 순위에 배치되었는지를 측정한다. 단순 Precision@k와 달리 순위를 가중하므로, 관련 문서가 1위에 있으면 10위에 있을 때보다 높은 점수를 받는다. 이는 정보 검색의 Average Precision(AP)과 동일한 철학이다.

예를 들어 5개 문서가 검색되었고 관련도 패턴이 $[1,0,1,0,0]$(1·3위가 관련)이라면, precision@1=1.0, precision@3=2/3이고 관련 문서 위치에서만 합산하므로 $\text{CP}=\frac{1.0+0.667}{2}\approx 0.83$이다. 반대로 패턴이 $[0,0,1,0,1]$(3·5위)이라면 precision@3=1/3, precision@5=2/5로 $\text{CP}=\frac{0.333+0.4}{2}\approx 0.37$로 크게 낮아진다. 같은 수의 관련 문서라도 순위가 낮으면 감점된다.

4.5.2 Context Recall — 답변 문장의 컨텍스트 출처 비율

Context Recall은 "답을 구성하는 데 필요한 정보가 컨텍스트에 포함되었는가"를 측정한다. RAGAS는 ground truth 답변의 핵심 문장을 추출한 뒤, 각 문장이 검색된 컨텍스트에서 근거를 찾을 수 있는지의 비율로 계산한다.

4.5.3 네 메트릭의 종합 — RAG 진단 사분면

네 메트릭을 두 축으로 묶으면 RAG 시스템의 상태를 사분면으로 진단할 수 있다. 가로축은 검색 품질(Context Precision·Recall), 세로축은 생성 품질(Faithfulness·Answer Relevance)이다.

4.5.4 검색 내부 (1) — 임베딩과 유사도 검색

Context Precision·Recall이 낮을 때 무엇을 고쳐야 하는지를 알려면 검색 단계의 내부 메커니즘을 이해해야 한다. 가장 흔한 RAG 검색은 밀집 검색(dense retrieval)이다 — 질문과 문서를 같은 임베딩 공간으로 사상한 뒤, 질문 벡터와 가장 가까운 문서 벡터를 회수한다. 거리(또는 유사도)는 보통 코사인 유사도(4.4.2)나 내적(inner product)을 쓴다.

밀집 검색은 의미적으로 유사하지만 단어가 다른 문서를 잘 찾는 반면, 정확한 키워드(고유명사·코드 식별자)에는 약하다. 그래서 실무에서는 밀집 검색과 희소 검색(sparse retrieval, BM25)을 결합한 하이브리드 검색을 자주 쓴다. BM25는 단어 빈도(term frequency)와 역문서빈도(inverse document frequency)에 문서 길이 정규화를 더한 고전 IR 점수 함수다.

4.5.5 검색 내부 (2) — 청킹과 재순위화

검색 품질을 좌우하는 또 다른 결정적 요소는 청킹(chunking)이다. 문서를 너무 크게 자르면(사례 연구 1) 한 청크에 여러 주제가 섞여 임베딩이 흐려지고, 너무 작게 자르면 문맥이 끊겨 답에 필요한 정보가 분산된다. 그래서 의미 단위 청킹(semantic chunking)이나 오버랩(overlap)을 둔 슬라이딩 윈도우가 쓰인다. 청킹 후에는 1차 검색 결과를 정밀 모델로 다시 정렬하는 재순위화(reranking)가 Context Precision을 크게 끌어올린다 — 보통 cross-encoder가 질문·문서 쌍을 함께 인코딩해 더 정확한 관련도를 매긴다.

4.6 RAGAS의 한계

RAGAS는 강력하지만 만능이 아니다. 그 한계를 정확히 이해해야 잘못된 신뢰를 피할 수 있다. 한계는 크게 세 갈래다.

4.6.1 합성 데이터와 실제 데이터의 격차

RAGAS는 평가용 테스트셋을 LLM으로 합성(synthetic generation)하는 기능을 제공한다. 이는 빠르고 저렴하지만, 합성 질문은 실제 사용자 질문의 분포(distribution)와 다르다. 실제 사용자는 모호하고, 오타가 있고, 다중 의도를 담고, 도메인 은어를 쓴다. 합성 데이터로 0.9를 받은 시스템이 실 사용자에게 0.6을 받는 일이 흔하다. 따라서 합성 데이터는 개발 초기 스모크 테스트(smoke test)로 쓰되, 최종 판단은 실제 로그 기반 데이터로 해야 한다.

4.6.2 NLI 모델·LLM 판사 자체의 오류

Faithfulness와 Context Recall은 NLI 판정(또는 LLM 판사)에 의존한다. 그런데 NLI 모델 자체가 부정·수량·시제·함축 같은 어려운 추론에서 자주 틀린다. "이 약은 1상에서 안전"으로부터 "이 약은 안전"이 entailment인지 neutral인지는 NLI 모델마다 다르게 판정한다. 즉 메트릭의 신뢰도가 그 메트릭을 계산하는 모델의 신뢰도에 상한이 걸린다(Ch.03의 LLM-as-judge 편향 논의와 연결된다).

4.6.3 claim 추출의 비결정성

Faithfulness의 첫 단계인 claim 추출은 LLM 생성이므로 비결정적(non-deterministic)이다. 같은 답변이라도 실행할 때마다 claim의 개수와 경계가 달라진다. claim을 세분화할수록 분모가 커져 점수 분포가 바뀐다. RAGAS는 여러 번 샘플링해 평균하여 이를 완화하지만, 근본적으로 점수에 노이즈가 끼는 원천이다.

4.7 RAG 평가 프레임워크 비교

RAGAS 외에도 여러 RAG 평가 프레임워크가 경쟁한다. 각각 철학과 강점이 다르므로, 상황에 맞게 선택해야 한다. 대표 네 가지 — RAGAS, ARES, TruLens, DeepEval — 을 비교한다.

4.7.1 ARES — 합성 데이터 + 통계적 보정

ARES(Saad-Falcon et al., 2024, "ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation Systems", NAACL 2024, arXiv:2311.09476)는 RAGAS와 유사하게 LLM 판사를 쓰지만, 예측-기반 추론(prediction-powered inference, PPI)으로 통계적 보정을 추가한다. LLM 판사의 점수를 소량의 인간 라벨로 보정하여, 편향을 제거한 신뢰구간(confidence interval)이 있는 추정치를 제공한다. "판사를 평가하라"는 4.6.3의 권고를 프레임워크 차원에서 자동화한 셈이다.

4.7.2 TruLens — RAG Triad

TruLens는 RAG 평가를 세 꼭짓점의 삼각형(RAG Triad)으로 정식화한다 — Context Relevance(컨텍스트가 질문과 관련 있는가), Groundedness(답변이 컨텍스트에 근거하는가), Answer Relevance(답변이 질문과 관련 있는가). 이 세 가지가 모두 높아야 RAG가 신뢰할 수 있다는 직관적 모델로, 개발자가 빠르게 이해하고 적용하기에 좋다.

4.7.3 DeepEval — 단위 테스트 패러다임 + 통계적 검정

DeepEval은 RAG 평가를 소프트웨어 단위 테스트(unit test)처럼 다룬다. pytest 스타일로 assertion을 작성하고, Hallucination·Answer Relevance·Faithfulness 등 메트릭에 임계값을 걸어 CI에서 자동 검증한다. G-Eval(Liu et al., 2023, "G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment", arXiv:2303.16634) 기반 LLM 메트릭과 통계적 유의성 검정을 함께 제공해, "이번 버전이 이전보다 통계적으로 유의하게 나빠졌는가"를 판정할 수 있다.

4.7.4 메트릭 커버리지 매트릭스

4.7.5 LLM 의존의 공통 약점과 임베딩 기반 보완

네 프레임워크 모두 LLM 판사에 크게 의존하므로, 비용·지연·편향·재현성의 공통 약점을 공유한다. 이를 보완하는 한 방법이 임베딩 기반 보조 메트릭이다. 예컨대 BERTScore(Zhang et al., 2020, "BERTScore: Evaluating Text Generation with BERT", ICLR 2020, arXiv:1904.09675)로 답변과 컨텍스트의 의미 중첩을 빠르게 근사하여, 비싼 LLM 호출 전에 1차 필터링할 수 있다.

물론 BERTScore는 표면 의미 중첩만 보므로 환각·추론 비약을 잡지 못한다. 따라서 BERTScore는 RAGAS를 대체하는 것이 아니라 저비용 1차 스크리닝으로 결합하는 것이 실용적이다 — BERTScore가 명백히 낮으면 LLM 호출 없이 탈락, 애매한 경우만 RAGAS로 정밀 판정한다.

4.8 프레임워크 선택 가이드

"어떤 프레임워크를 써야 하는가"는 비용, 신뢰도 요구, CI 통합, 통계적 엄밀성에 따라 달라진다. 아래 결정 트리가 출발점이다.

4.8.1 RAG 평가의 흔한 안티패턴

도구 선택만큼 중요한 것이 "하지 말아야 할 것"을 아는 것이다. 실무에서 반복되는 RAG 평가의 안티패턴(anti-pattern)을 정리한다. 이들은 대부분 4.1의 첫 번째 계명("검색과 생성을 한 숫자로 합치지 말라")이나 4.6의 한계(평가기 신뢰성)를 무시한 데서 비롯된다.

이 안티패턴들의 공통 교훈은 명확하다 — RAG 평가는 일회성 점수 산출이 아니라, 분해된 메트릭을 골드셋으로 보정하며 지속적으로 추적하는 운영 프로세스(operational process)다. 단발성 0.85라는 숫자보다, "검색 재현율이 지난 버전 대비 0.05 떨어졌고 그 원인이 새 문서 청킹 변경"이라는 추적 가능한 서사가 훨씬 가치 있다.

4.9 RAG 평가 실무 — 동작하는 파이프라인

이론을 종합해 실제로 돌아가는 RAG 평가 파이프라인을 구성한다. 핵심은 네 메트릭을 한 번의 평가 호출로 묶고, 데이터셋 단위로 집계·시각화하는 것이다.

4.9.1 RAGEvaluationPipeline 클래스

4.9.2 ContextRelevanceEvaluator — TruLens 스타일 보조기

RAG Triad의 Context Relevance를 별도로 측정하면, 검색이 질문과 무관한 문서를 가져오는 문제를 조기에 잡을 수 있다. 아래는 청크별 관련도를 LLM으로 채점하는 보조 평가기다.

4.9.3 데이터셋 단위 결과 시각화

50개 케이스의 메트릭 분포를 함께 보면 "평균은 괜찮은데 꼬리가 나쁜" 케이스를 발견할 수 있다. 아래 차트는 개입 전후의 4메트릭 평균 변화를 보여준다.

4.9.4 회귀 게이트 — 버전 간 통계적 비교

RAG 평가를 CI에 통합하려면 "이번 버전이 이전보다 통계적으로 유의하게 나빠졌는가"를 판정해야 한다. 데이터셋 평균이 0.82→0.80으로 떨어졌을 때, 이것이 진짜 회귀인지 측정 노이즈인지를 구분하려면 표본 분산을 고려한 검정이 필요하다. 케이스별 점수 쌍을 가진 경우 대응표본 t-검정(paired t-test) 또는 부트스트랩 신뢰구간을 사용한다.

4.10 코드 생성 평가는 왜 다른가

이제 두 번째 도메인, 코드 생성으로 넘어간다. RAG가 "검색과 생성의 분리"를 요구했다면, 코드 생성은 또 다른 특수성을 가진다 — 출력을 실제로 실행(execute)해서 검증할 수 있다는 점, 그리고 정답이 무한히 다양하다는 점이다.

4.10.1 코드의 특수성: 실행 가능성과 정답의 다양성

자연어 생성에서는 "정답"을 정의하기 어렵다. 같은 의미를 무한히 많은 문장으로 표현할 수 있어서 BLEU·ROUGE 같은 표면 비교가 한계를 가진다. 코드도 정답이 다양하다는 점은 같지만(같은 함수를 무수히 많은 방식으로 구현 가능), 결정적 차이가 있다 — 코드는 실행해서 정답인지 객관적으로 검증할 수 있다. 구현이 어떻게 생겼든, 테스트 케이스를 통과하면 기능적으로 정답이다. 이것이 코드 생성 평가가 자연어 평가보다 더 객관적일 수 있는 이유이자, 실행 기반 평가(execution-based evaluation)가 표준이 된 이유다.

4.10.2 표면 비교(BLEU)가 코드에서 실패하는 이유

초기 코드 생성 연구는 CodeBLEU 같은 표면 비교를 시도했지만, 코드에서는 특히 부적합하다. 변수명을 바꾸거나 동등한 구문(예: 리스트 컴프리헨션 vs for 루프)을 쓰면 BLEU는 떨어지지만 기능은 동일하다. 반대로 한 글자(예: < vs <=)만 틀려 완전히 다르게 동작하는 코드가 높은 BLEU를 받을 수 있다. Chen et al. (2021, "Evaluating Large Language Models Trained on Code", arXiv:2107.03374)이 HumanEval과 함께 실행 기반 pass@k를 도입한 핵심 동기가 이것이다.

4.11 Pass@k 재고찰

Ch.02에서 pass@k를 소개했지만, 여기서는 그 수학적 깊이를 파고든다. pass@k는 "k개의 샘플을 생성했을 때 적어도 하나가 모든 테스트를 통과할 확률"이다. 단순해 보이지만, 이를 편향 없이 추정하는 것은 미묘하다.

4.11.1 순진한 추정의 편향과 불편 추정량

k개를 생성해 하나라도 통과하면 1, 아니면 0으로 세는 순진한 방법은 분산이 크고 비싸다. Chen et al. (2021)은 더 많은 $n$개($n \geq k$)를 한 번 생성해 그중 통과한 개수 $c$를 세고, 거기서 pass@k를 불편(unbiased) 추정하는 공식을 제시했다. 핵심은 "$n$개 중 $k$개를 뽑았을 때 하나도 통과 못 할 확률"을 조합으로 계산하는 것이다.

이 공식이 왜 불편인가? $\binom{n-c}{k}$는 통과 샘플($c$개)을 한 번도 뽑지 않고 실패 샘플($n-c$개)에서만 $k$개를 고르는 경우의 수이고, $\binom{n}{k}$는 전체 경우의 수다. 그 비율이 "k번 시도가 모두 실패할 확률"의 불편 추정이며, 1에서 빼면 "적어도 하나 성공"이 된다. 순진한 추정과 달리 모든 $\binom{n}{k}$ 조합을 암묵적으로 평균하므로 분산이 작다. 수치적으로는 큰 $n$에서 조합 계산이 오버플로하므로, 아래처럼 곱셈 누적 형태로 안정화한다.

4.11.2 n과 k의 민감도: 엄격함의 스펙트럼

같은 모델이라도 k에 따라 점수가 극적으로 달라진다. pass@1은 "첫 시도에 맞히는가"로 매우 엄격하고, pass@100은 "100번 중 한 번이라도 맞히는가"로 관대하다. 예를 들어 어떤 모델이 문제당 평균 통과율 $p=0.1$(즉 10%)이라면, pass@1=0.1이지만 pass@100 $\approx 1-(0.9)^{100}\approx 0.9999$로 거의 100%가 된다.

(위 값은 $\text{pass@}k \approx 1-(1-p)^k$ 근사로 계산. p=10%, k=100이면 거의 확실히 하나는 통과)

4.11.3 추정 분산과 신뢰구간

pass@k는 추정치이므로 분산을 동반한다. 데이터셋 전체 pass@k는 문제별 pass@k의 평균이고, 문제별 값은 독립이라 가정하면 평균의 표준오차로 신뢰구간을 구성할 수 있다. 작은 데이터셋(예: HumanEval 164개)에서는 이 구간이 의외로 넓어, 두 모델의 pass@1이 1~2%p 차이라면 통계적으로 구분 불가능할 수 있다.

이는 4.16에서 다룰 "단일 벤치마크의 위험"과 직결된다. 작은 벤치마크의 점수 차이는 우연일 수 있으므로, 모델 비교는 반드시 신뢰구간과 함께 보고하고, 여러 벤치마크로 삼각측량해야 한다. 점 추정치 하나로 순위를 단정하는 것은 통계적으로 부주의하다. 실무에서는 부트스트랩(bootstrap)으로 신뢰구간을 구하고, 두 모델의 구간이 겹치면 "유의한 차이 없음"으로 보고하는 것이 정직한 관행이다.

4.11.4 pass@1 vs pass@k: 어느 것을 보고할 것인가

벤치마크 리더보드는 종종 큰 k의 pass@k를 자랑하지만, 제품 의사결정에는 pass@1(또는 사용자가 실제로 보는 후보 수에 해당하는 k)이 더 정직하다. 자율 코딩 에이전트라면 자가 검증·재시도 루프가 있으므로 작은 k의 pass@k가 적절할 수 있다. 핵심은 k를 실제 사용 시나리오에 맞추는 것이며, k를 명시하지 않은 pass@k 수치는 비교 불가능하다.

4.12 실행 기반 평가 vs 정적 분석

코드 평가는 크게 두 축이다 — 실제로 돌려보는 실행 기반(execution-based)과, 돌리지 않고 코드 구조를 분석하는 정적 분석(static analysis). 둘은 경쟁이 아니라 상호 보완적이다.

4.12.1 실행 기반 평가와 샌드박스

실행 기반 평가는 생성된 코드를 테스트 케이스와 함께 실제로 실행하여 통과 여부를 본다. 가장 신뢰할 수 있지만, 임의 코드를 실행하는 것은 보안 위험(파일 삭제, 네트워크 접근, 무한 루프)을 동반한다. 따라서 반드시 격리된 샌드박스(sandbox) — 컨테이너, 시간/메모리 제한, 시스템 콜 차단 — 안에서 실행해야 한다.

4.12.2 정적 분석: AST, 타입 체크, 린트

정적 분석은 코드를 실행하지 않고 구조를 검사한다. 추상 구문 트리(Abstract Syntax Tree, AST)를 파싱해 위험 패턴을 탐지하거나, 타입 체커(mypy)로 타입 오류를, 린터(ruff, pylint)로 스타일·잠재 버그를 잡는다. 실행 전 1차 필터로 유용하다 — 컴파일도 안 되는 코드를 비싼 샌드박스에 보내기 전에 걸러낸다.

4.13 pass/fail을 넘어선 코드 품질

테스트를 통과했다고 좋은 코드는 아니다. "돌아가는가?"는 최소 조건이고, 실무에서는 "올바르게, 효율적으로, 안전하게, 유지보수 가능하게 돌아가는가?"가 중요하다. 단순 pass/fail을 넘어서는 다차원 품질 메트릭을 살펴본다.

4.13.1 시간·공간 복잡도

두 코드가 모두 테스트를 통과해도, 하나는 $O(n^2)$이고 다른 하나는 $O(n\log n)$이면 큰 입력에서 전자는 실용 불가다. 복잡도는 정적 분석(루프 중첩 분석)으로 근사하거나, 입력 크기를 키워가며 실행 시간을 측정해 경험적으로 추정한다.

4.13.2 에러 핸들링과 견고성

HumanEval식 "행복 경로(happy path)" 테스트만 통과하는 코드는 엣지 케이스(빈 입력, None, 음수, 오버플로)에서 무너진다. 견고한 코드 평가는 정상 입력 테스트 외에 적대적 입력(adversarial input) 테스트를 추가하고, 예외 처리 구조의 존재 여부를 정적으로 확인한다. EvalPlus(Liu et al., 2023, "Is Your Code Generated by ChatGPT Really Correct? Rigorous Evaluation of Large Language Models for Code Generation", NeurIPS 2023, arXiv:2305.01210)는 HumanEval의 테스트가 너무 빈약해 통과율이 과대평가됨을 보이고, 테스트를 대폭 증강한 HumanEval+를 제안했다.

4.13.3 가독성과 린터 점수

유지보수 가능성은 가독성에 크게 의존한다. 변수명, 함수 길이, 중첩 깊이, 주석 등은 린터로 정량화할 수 있다. 이는 주관적이지만, 팀 컨벤션과의 정합성을 측정하는 대리 지표(proxy)로 유용하다. 다만 가독성은 기능 정확성과 독립이므로, 별도 차원으로 보고해야지 통과율에 섞으면 안 된다.

4.13.4 보안 취약점 (SAST)

생성된 코드가 SQL 인젝션, 명령 주입, 하드코딩된 비밀키, 안전하지 않은 역직렬화 같은 취약점을 포함할 수 있다. 정적 애플리케이션 보안 테스트(Static Application Security Testing, SAST) 도구(예: Bandit, Semgrep)로 이를 탐지한다. Pearce et al. (2022, "Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions", IEEE S&P 2022, arXiv:2108.09293)는 Copilot이 생성한 코드의 약 40%가 보안 약점을 포함했다고 보고했다 — 기능적으로 맞아도 안전하지 않을 수 있음을 보여주는 경고다.

4.13.5 순환 복잡도(Cyclomatic Complexity)의 정의

복잡도를 정량화하는 고전 지표가 McCabe(1976)의 순환 복잡도다. 제어 흐름 그래프(control flow graph)에서 독립적인 실행 경로의 수를 세는데, 직관적으로는 분기(if/for/while/and/or 등)의 수에 1을 더한 값이다. 값이 클수록 테스트해야 할 경로가 많고 버그 위험이 높다.

4.12.2의 StaticAnalyzer가 분기 노드를 세어 복잡도를 근사한 것이 바로 이 지표의 단순화 버전이다. 생성 코드의 복잡도를 정상 정답(ground truth) 구현의 복잡도와 비교하면, "불필요하게 복잡한 구현"을 감지할 수 있다.

4.13.6 다차원 코드 평가 파이프라인

지금까지의 구성 요소 — 정적 분석, 샌드박스 실행, 복잡도, 보안 — 를 하나의 계층적 파이프라인으로 묶는다. 4.12.2 인사이트의 "싸고 안전한 검사 먼저" 원칙을 코드로 구현한 것이다.

4.14 SWE-bench 심층

HumanEval·MBPP가 단일 함수의 짧은 문제라면, SWE-bench(Jimenez et al., 2024, "SWE-bench: Can Language Models Resolve Real-World GitHub Issues?", ICLR 2024, arXiv:2310.06770)는 차원이 다르다 — 실제 GitHub 이슈를 받아 리포지토리 전체를 이해하고 패치(patch)를 만들어, 기존 테스트 스위트를 통과시켜야 한다. 이것은 "코딩 테스트"가 아니라 "실제 소프트웨어 엔지니어링 워크플로우"다.

4.14.1 구조: 이슈 → 리포지토리 컨텍스트 → 패치 → 테스트

SWE-bench의 각 태스크는 다음으로 구성된다. (1) GitHub 이슈 설명(자연어 버그 리포트 또는 기능 요청), (2) 해당 시점의 리포지토리 스냅샷(수만~수십만 줄), (3) 모델이 생성해야 할 코드 패치, (4) 그 패치가 통과해야 할 테스트(이슈를 실제로 해결한 PR이 추가/수정한 테스트). 모델은 어디를 고쳐야 할지조차 스스로 찾아야 한다 — 파일 위치도 주어지지 않는다.

4.14.2 평가: resolved vs unresolved

평가 기준은 단순하고 객관적이다. 패치 적용 후 (1) 이슈와 관련된 테스트(FAIL_TO_PASS: 패치 전엔 실패, 후엔 통과해야 함)가 모두 통과하고, (2) 기존에 통과하던 테스트(PASS_TO_PASS: 회귀 방지)가 여전히 통과하면 resolved, 아니면 unresolved다. 이 이중 조건이 중요하다 — 버그는 고쳤지만 다른 기능을 망가뜨리면(회귀) 실패로 친다. 실제 엔지니어링과 동일한 기준이다.

4.14.3 SWE-bench Lite와 Verified

원본 SWE-bench는 12개 인기 Python 리포지토리에서 2,294개 태스크를 담고 있어 평가에 막대한 비용(태스크당 수만~수십만 토큰)이 든다. 이를 완화하고 신뢰성을 높이기 위해 두 부분집합이 만들어졌다.

SWE-bench Verified는 OpenAI가 96명의 전문 개발자와 협업하여, 원본의 문제 중 "테스트가 불완전하거나 이슈 설명이 모호한" 케이스를 걸러내 만든 500개 검증셋이다. 원본에서 모델이 실패한 일부는 사실 문제 자체의 결함(불가능하거나 애매한 테스트)이었기에, Verified에서는 같은 모델이 더 높은 점수를 받는다. 이는 4.6.1에서 본 "평가셋 자체의 품질" 문제가 코드 평가에도 그대로 적용됨을 보여준다.

4.14.4 성능 현황과 해석

(수치는 시점·구성에 따라 변동하는 근사치다. 정확한 최신 값은 공식 리더보드 swebench.com을 참조하라.)

4.14.5 에이전트 스캐폴딩과 성능 분해

SWE-bench resolve rate는 모델 단독 능력이 아니라 모델과 스캐폴딩(scaffolding) — 즉 에이전트가 코드베이스를 탐색·편집·실행하는 도구 루프 — 의 결합 성능이다. 같은 기반 모델이라도 스캐폴딩에 따라 점수가 두 배 이상 차이 난다. 대표 패러다임이 ReAct(Yao et al., 2023, "ReAct: Synergizing Reasoning and Acting in Language Models", ICLR 2023, arXiv:2210.03629)의 추론-행동 교차 루프와, 이를 코드 환경에 특화한 SWE-agent(Yang et al., 2024, "SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering", NeurIPS 2024, arXiv:2405.15793)의 에이전트-컴퓨터 인터페이스다.

SWE-bench 성능을 분해하려면 단계별 성공률을 계측해야 한다. 아래는 localization·patch·test 단계의 성공 여부를 추적해, 어느 단계가 병목인지 진단하는 평가 래퍼다.

4.15 코드 평가 프레임워크 비교

코드 생성 벤치마크는 단일 함수에서 리포지토리 규모까지, 정적 데이터셋에서 오염 방지 라이브 평가까지 스펙트럼을 이룬다. 대표 벤치마크를 비교한다.

4.15.1 MBPP와 Austin et al.

MBPP(Austin et al., 2021, "Program Synthesis with Large Language Models", arXiv:2108.07732)는 입문~중급 난이도의 약 974개 Python 문제로, 자연어 설명과 3개 정도의 테스트로 구성된다. HumanEval과 함께 가장 널리 쓰이지만, 문제 난이도가 낮아 강한 모델 간 변별력이 부족하다(천장 효과, ceiling effect).

4.15.2 LiveCodeBench와 오염 방지

LiveCodeBench(Jain et al., 2024, "LiveCodeBench: Holistic and Contamination Free Evaluation of Large Language Models for Code", arXiv:2403.07974)는 경쟁 프로그래밍 사이트(LeetCode, AtCoder, CodeForces)의 문제를 출제 날짜와 함께 지속적으로 수집한다. 모델의 훈련 컷오프(training cutoff) 이후에 출제된 문제만으로 평가하면, 그 문제는 훈련 데이터에 있을 수 없으므로 오염(contamination)이 원천 차단된다. 이것이 다음 절의 핵심 주제다.

4.16 오염과 데이터 누출

코드 벤치마크의 가장 심각한 신뢰성 위협은 데이터 오염(data contamination)이다. HumanEval·MBPP는 공개된 지 오래되어 거의 모든 LLM의 훈련 데이터에 포함되었을 가능성이 높다. 모델이 문제를 "푸는" 것이 아니라 "외운" 것이라면, 그 점수는 일반화 능력을 반영하지 못한다.

4.16.1 오염의 증거와 진단

오염을 진단하는 한 방법은 시간적 분할(temporal split)이다. 훈련 컷오프 이전 문제와 이후 문제에서 성능 격차가 크면 오염을 의심한다. LiveCodeBench가 출제 날짜를 기록하는 이유가 이것이다 — 같은 모델을 컷오프 전후 문제로 나눠 평가하면, 컷오프 이전 문제에서만 비정상적으로 높은 점수가 나오는 "기억(memorization) 신호"를 볼 수 있다.

4.16.2 오염 방지 전략

오염을 막는 전략은 세 갈래다. (1) 라이브 평가 — LiveCodeBench처럼 컷오프 이후 문제만 사용. (2) 비공개 테스트 — SWE-bench가 일부 테스트를 숨기고, 히든 테스트로 채점하여 답을 외우기 어렵게 함. (3) 변형(perturbation) — 문제의 변수명·구조를 바꿔 표면 기억을 무력화. 다만 변형은 의미가 보존되는지 검증이 어렵다는 한계가 있다.

4.16.3 오염 진단 자동화

오염을 운영 단계에서 자동 감시하려면 시간적 격차를 통계적으로 검정해야 한다. 컷오프 전후 동질 문제군의 통과율 차이를 부트스트랩으로 신뢰구간과 함께 추정하면, 격차가 우연인지 체계적 기억인지 판정할 수 있다.

4.17 평가의 비용·지연 엔지니어링

이 장의 거의 모든 고급 메트릭(RAGAS 4메트릭, G-Eval, Answer Correctness, 샌드박스 실행)은 LLM 호출이나 코드 실행을 동반하므로 느리고 비싸다. 수천 개 케이스를 매 커밋마다 평가하면 비용과 지연이 개발 속도를 잠식한다. 따라서 평가 자체도 엔지니어링 대상이다 — 정확도를 거의 잃지 않으면서 비용을 줄이는 전략이 필요하다.

4.17.1 비용 모델과 병목 식별

RAG 평가의 총 비용은 케이스 수, 메트릭 수, 메트릭당 LLM 호출 수, 호출당 토큰 비용의 곱으로 근사된다. 4.7.4의 비용 차트에서 보았듯 Faithfulness·Answer Relevance가 claim/역질문 생성으로 호출이 많아 병목이다.

4.17.2 계층적 필터링과 샘플링

비용을 줄이는 두 축은 (1) 저비용 1차 필터(4.7.5의 BERTScore, 4.12의 정적 분석)로 명백한 케이스를 LLM 호출 없이 처리하고, (2) 전수 평가 대신 층화 샘플링(stratified sampling)으로 대표 부분집합만 평가하는 것이다. 단 회귀 게이트(4.9.4)에는 충분한 표본이 필요하므로 샘플 크기를 검정력(statistical power) 기준으로 정해야 한다.

4.18 통합 관점 — RAG와 코드 평가의 공통 교훈

표면적으로 RAG 평가와 코드 평가는 다른 영역이지만, 이 장을 관통하는 세 가지 보편 원리를 공유한다. 이 원리들은 Part III에서 다룰 에이전트 6차원 평가 프레임워크로도 이어진다.

4.18.1 원리 1: 분해(Decomposition)

두 영역 모두 파이프라인을 블랙박스로 평가하지 않고 구성 요소로 분해한다. RAG는 검색·생성으로, 코드는 기능·복잡도·견고성·가독성·보안으로 분해한다. SWE-bench는 한 걸음 더 나아가 localization(검색)과 editing(수정)으로 분해된다. 분해 없이는 진단도 개선도 없다.

4.18.2 원리 2: 실행과 근거(Grounding)

두 영역 모두 "표면 비교"를 거부하고 "객관적 근거"를 추구한다. RAG는 컨텍스트라는 근거에 답변을 묶고(grounding), 코드는 테스트라는 근거에 정확성을 묶는다(execution). 둘 다 BLEU 같은 표면 유사도를 신뢰하지 않는다는 점이 공통이다.

4.18.3 원리 3: 다차원과 거부권(Multi-dimensionality & Veto)

두 영역 모두 단일 점수의 한계를 인정하고 다차원으로 본다. 그리고 일부 차원은 다른 차원으로 보상될 수 없는 거부권(veto)을 가진다 — 코드에서 심각한 보안 취약점, RAG에서 PII 노출이 그렇다. 이는 Ch.13의 Safety Gate 철학과 정확히 일치한다.

4.19 요약과 다음 장 예고

이 장에서 우리는 RAG와 코드 생성이라는 두 도메인 특화 평가를 깊이 다뤘다. 핵심을 정리하면 다음과 같다.

4.19.1 핵심 요약

4.19.2 다음 장 예고 — Ch.05 근본적 도전과제

이 장에서 우리는 도메인 특화 평가가 일반 LLM 평가보다 더 정밀할 수 있음을 보았다 — 검색을 근거로, 테스트를 근거로 묶을 수 있기 때문이다. 그러나 이 정밀함에도 불구하고 모든 평가가 공유하는 근본적 한계들이 있다. NLI 모델·LLM 판사의 신뢰성, 평가셋 자체의 오염과 편향, 합성 데이터와 실제 분포의 격차, 그리고 "측정하는 순간 최적화 대상이 되어 메트릭이 무의미해지는" 굿하트의 법칙(Goodhart's Law)이 그것이다.

Ch.05 "근본적 도전과제(Fundamental Challenges)"에서는 이러한 평가의 본질적 한계들을 정면으로 다룬다. 왜 완벽한 평가는 불가능한가, 그럼에도 어떻게 신뢰할 수 있는 평가에 점근(漸近)할 것인가를 논한다. 그 논의는 Part II에서 단일 모델 평가를 넘어 에이전트·멀티 에이전트 평가로 패러다임이 전환되는 토대가 된다.

4.19.3 독자 가이드 — 역할별 진입 경로

독자의 역할에 따라 이 장에서 우선 읽어야 할 절이 다르다. 아래 경로는 각자의 목표에 가장 빠르게 도달하도록 구성했다.

4.19.4 핵심 용어 사전

이 장에서 도입한 핵심 용어를 한곳에 정리했다. 후속 장에서 다시 등장하므로 참조용으로 활용하라.