AI Agent A/B 테스트 개요

RAG 기반 Agent 성능 측정을 위한 실험설계 시리즈 — 첫 번째

AI Agent(특히 RAG 기반)의 성능을 과학적으로 측정하고 비교하려면 기존 웹 A/B 테스트와는 다른 실험설계가 필요하다. 비결정적 출력, 평가의 주관성, 제한된 트래픽이라는 Agent 고유의 도전을 정의하고, 오프라인 평가부터 프로덕션 동적 라우팅까지의 실험설계 로드맵을 제시한다.

Experimentation
Agent
저자

Kwangmin Kim

공개

2026년 03월 21일

1 정의

정의: Agent A/B 테스트

AI Agent에 대한 A/B 테스트란, 동일한 사용자 질의(query)에 대해 서로 다른 Agent 구성(프롬프트, 검색 파라미터, 모델 등)을 무작위로 배정하고, 사전 정의한 품질 지표의 차이를 통계적으로 검정하여 최적 구성을 선택하는 실험이다.

  • 역학 용어: Randomized Controlled Trial (RCT)의 Agent 버전
  • 핵심 차이: 결과가 비결정적(non-deterministic)이고, 평가에 주관적 판단이 개입한다
  • 실험 단위: 개별 질의(query), 세션(session), 또는 사용자(user)

2 왜 Agent에 A/B 테스트가 필요한가

2.1 실험 없이 Agent를 평가하면 생기는 문제

RAG 기반 Agent는 설정할 수 있는 파라미터가 많다. 대표적으로:

계층 실험 변수 예시 선택지
모델 LLM 종류 GPT-4.1, GPT-4o, Claude 등
프롬프트 시스템 프롬프트, Few-shot 예시 버전 A, B, C, …
검색 top-k, 유사도 임계값, 검색 전략 k=3, 5, 10 / Hybrid, Vector-only
청킹 chunk size, overlap 512, 1024 / 0%, 20%
후처리 리랭킹, 필터링 Cohere Rerank, Cross-encoder

이 변수들을 “감으로” 조합하면:

  1. 교란 변수 통제 불가 — 프롬프트를 바꿨는데 동시에 문서도 업데이트했다면, 성능 변화의 원인을 특정할 수 없다
  2. 체리피킹(Cherry-picking) — 잘 되는 질의 몇 개만 골라서 “성능이 좋다”고 판단하는 확증 편향
  3. 재현 불가 — 동일 질의에도 LLM 출력이 달라지므로, 1회 테스트 결과를 신뢰할 수 없다

A/B 테스트는 무작위 배정과 통계적 검정으로 이 세 가지 문제를 해결한다.

2.2 MINERVA 프로젝트에서의 실험 필요성

MINERVA는 씨젠 SW연구소에서 개발 중인 RAG 기반 도메인 특화 AI Agent 플랫폼이다. 3종의 Agent가 각각 다른 도메인과 태스크를 담당한다:

Agent 도메인 핵심 태스크 실험 대상 예시
QnA Chatbot 데이터 표준화 원칙 지식 Q&A 프롬프트 변형, top-k 값
Data Standardization Helper 메타데이터 추천 Rule + ML + RAG 하이브리드 추천 알고리즘 가중치, RAG 혼합 비율
Insilico Code Analysis 코드 + 문서 코드 분석·설명 코드 청킹 전략, 문서-코드 매핑 방식

세 Agent가 다루는 태스크의 성격이 다르다는 점이 실험 설계에 직접적 영향을 준다. QnA Chatbot은 정답이 상대적으로 명확하므로 Hit Rate 같은 객관적 지표로 자동 실험을 돌릴 수 있다. 반면 Insilico Code Analysis는 “이 코드 설명이 좋은가?”라는 주관적 판단이 개입하므로, 자동 지표만으로 실험 결과를 신뢰하기 어렵다. 같은 A/B 테스트 프레임이어도 Agent마다 메트릭 설계와 평가 방식이 달라져야 한다. 이것이 이 시리즈에서 메트릭 설계(3편)와 Human-in-the-Loop 평가(8편)를 별도 포스트로 다루는 이유이다.

이들의 RAG 파이프라인은 공통 구조를 따른다:

문서 수집 → Parent-Child Chunking → Embedding(text-embedding-3-small)
→ Hybrid Search(BM25 + Vector, k=6) → Child→Parent 매핑 → LLM 생성

이 파이프라인의 각 단계가 실험 변수이다. 예를 들어:

  • Embedding 모델을 text-embedding-3-small → text-embedding-3-large로 바꾸면 응답 품질이 올라가는가?
  • Hybrid Search에서 BM25 가중치를 0.3에서 0.5로 높이면 도메인 용어 검색 정확도가 개선되는가?
  • top-k를 6에서 10으로 늘리면 응답의 포괄성(completeness)은 좋아지지만 정확성(precision)은 떨어지는가?

이러한 질문에 “그럴 것 같다”가 아닌 “통계적으로 유의하다”로 답하는 것이 실험설계의 목적이다.

3 기존 웹 A/B 테스트와의 차이

웹 서비스 A/B 테스트(버튼 색상, 레이아웃 등)와 Agent A/B 테스트는 실험의 기본 원리(무작위 배정, 가설 검정)는 동일하지만, 실무적으로 중요한 차이가 있다.

3.1 비결정적 출력 (Non-deterministic Output)

웹 A/B에서 “빨간 버튼”은 항상 빨간 버튼이다. 처치(treatment)가 고정되어 있다.

Agent에서는 동일한 질의에 동일한 설정을 적용해도 LLM 출력이 달라진다. temperature=0으로 설정해도 Azure OpenAI 서비스 레이어의 미세한 차이로 완전히 동일한 출력을 보장하지 못한다.

구체적으로 어떤 문제가 생기는가: MINERVA QnA Chatbot에서 “BM25 가중치 0.3 vs 0.5 중 어느 쪽이 낫나”를 실험한다고 하자. 각 설정으로 1회씩만 실행하면, 0.3이 우연히 좋은 응답을 뽑고 0.5가 나쁜 응답을 뽑는 경우를 처치 효과로 오인할 수 있다. 반복 없이 내린 결론은 동전 한 번 던져서 정책을 결정하는 것과 구조적으로 같다.

실험설계 함의: 동일 질의-설정 조합에 대해 복수 회 반복(replication)이 필수이다. 1회 관측은 증거가 아니라 일화(anecdote)이다.

3.2 평가의 주관성 (Subjectivity of Evaluation)

웹 A/B의 지표는 명확하다 — 클릭률, 전환율, 매출. 측정에 주관이 개입하지 않는다.

Agent 응답의 품질은 “이 답변이 좋은가?”라는 주관적 판단을 포함한다:

평가 유형 예시 장단점
자동 평가 ROUGE, BERTScore, LLM-as-Judge 빠르고 저렴하지만 인간 판단과 괴리 가능
인간 평가 전문가 루브릭 기반 점수 정확하지만 느리고 비용이 높음
기능 평가 정답 포함 여부(Hit Rate), 정확 매칭 객관적이지만 평가 범위가 좁음

실험설계 함의: 자동 평가 지표와 인간 평가 간의 상관(correlation)을 검증해야 한다. 자동 지표만으로 실험을 운영하되, 주기적으로 인간 평가로 보정한다. 그 이유는 자동 평가 지표(ROUGE, BERTScore, LLM-as-Judge 등)는 인간이 “좋은 답변”이라고 느끼는 것과 실제로 일치하지 않을 수 있기 때문이다.

예를 들어: - BERTScore가 높아도 사용자는 답변이 너무 길어서 불만일 수 있음 - LLM-as-Judge가 높은 점수를 줬는데 도메인 전문가는 틀렸다고 판단할 수 있음

전략 이유
자동 지표로만 실험 운영 인간 평가는 느리고 비용이 높아서 매 실험마다 쓸 수 없음
주기적 인간 평가로 보정 자동 지표가 인간 판단과 계속 일치하는지 검증 — 일치한다면 자동 지표를 신뢰할 수 있고, 괴리가 생기면 새로운 지표로 교체
상관 검증이 전제 상관이 높다는 게 확인되어야만 “자동 지표로 실험한 결과 = 사용자에게도 좋은 결과”라는 논리가 성립함

결국, 신뢰할 수 있는 자동화를 위한 최소한의 인간 검증 루프가 필요하다는 뜻이다.

3.3 제한된 트래픽 (Low Traffic)

넷플릭스는 하루 수억 건의 요청으로 며칠 만에 실험을 완료한다. 기업 내부 Agent는 하루 수십~수백 건의 질의가 전부일 수 있다.

환경 일일 트래픽 실험 기간 (MDE=10%, α=0.05, power=0.8)
대형 테크 기업 수억 건 수일
중소형 SaaS 수만 건 수주
기업 내부 Agent 수백 건 수개월 이상

이 숫자가 의미하는 바를 풀어보면: MINERVA QnA Chatbot이 하루 50건의 질의를 받는다고 가정하자. MDE=10%, α=0.05, power=0.8 기준으로 필요한 표본은 그룹당 약 1,500건이다. 50:50 배분이면 한쪽 그룹에 하루 25건이 쌓이므로, 편도 60일이 필요하다. 이 기간 동안 프롬프트를 수정하거나 문서가 업데이트되면 실험 자체가 오염된다. 이것이 이 시리즈에서 Sequential Testing과 오프라인 평가 선스크리닝을 먼저 다루는 이유다.

실험설계 함의: 적은 트래픽 환경에서는 고정 표본 설계로는 시간이 부족하다. 다음 전략을 조합하여 현실적인 실험 기간을 확보해야 한다:

  • 오프라인 평가로 후보를 사전 스크리닝하여 온라인 실험 대상을 줄인다 (10개 → 2~3개)
  • 검정력 분석(power analysis)을 통해 현실적으로 감지 가능한 효과 크기(MDE)를 먼저 파악한다
  • 분산 감소 기법(CUPED 등)으로 필요 표본 크기를 줄인다
  • Sequential testing으로 조기 종료 가능성을 확보한다

3.4 다층 파라미터 구조 (Multi-layered Parameters)

웹 A/B는 보통 단일 변수(버튼 색상)를 실험한다. Agent는 모델 × 프롬프트 × 검색 전략 × 청킹 등 다층 파라미터가 상호작용한다.

웹 A/B:     버튼 색상 → {빨강, 초록}  (2 variants)
Agent A/B:  모델(3) × 프롬프트(4) × top-k(3) × 청킹(2) = 72 조합

72개 조합이 왜 문제인가: 각 조합에 통계적 유의성을 확보하려면 그룹당 최소 200건이 필요하다고 하면, 72 × 200 = 14,400건의 질의가 필요하다. 하루 50건 기준으로 288일, 거의 1년이다. 이것이 Fractional factorial이나 Thompson Sampling이 선택이 아니라 필수인 이유다.

실험설계 함의: Full factorial design은 비현실적이다. Fractional factorial로 고차 상호작용을 포기하고 주효과만 추정하거나, Thompson Sampling으로 실시간 동적 배분하여 열등한 조합을 빠르게 탈락시키는 전략이 필요하다.

3.5 비교 요약

차원 웹 A/B 테스트 Agent A/B 테스트
처치(Treatment) 결정적 (UI 고정) 비결정적 (LLM 출력 변동)
지표 객관적 (CTR, CVR) 주관적 + 객관적 혼합
트래픽 대규모 (수만~수억/일) 소규모 (수십~수백/일)
실험 변수 단일 또는 소수 다층 파라미터 조합
반복 필요성 낮음 (결정적 처치) 높음 (비결정적 출력)
평가 비용 낮음 (자동 로깅) 높음 (인간 평가 필요 가능)

4 실험설계 로드맵

이 시리즈는 다음 순서로 Agent A/B 테스트를 다룬다. 난이도가 낮은 오프라인 평가부터 시작하여 프로덕션 운영까지 단계적으로 진행한다.

4.1 Phase 1: 기초 (★☆☆)

[오프라인 평가 설계] → [메트릭 설계]
  • 오프라인 평가: Golden dataset 구축, RAG 평가 지표(Relevance, Faithfulness, Groundedness), 자동 평가 파이프라인 설계
  • 메트릭 설계: North Star / Proxy / Guardrail 메트릭 정의, 오프라인→온라인 전환 논리

온라인 실험 전에 무엇을 측정할 것인가를 먼저 정의한다. 오프라인 평가만으로 충분한 경우(명확한 정답이 있는 태스크)와 온라인 실험이 반드시 필요한 경우(사용자 선호도, 장기 효과)를 구분한다.

4.2 Phase 2: 실험 설계 (★★☆)

[단순 A/B 설계] → [표본 크기와 검정력]
  • 단순 A/B: 프롬프트 A vs B, top-k=5 vs 10 등 단일 변수 실험. 무작위 배정 단위(query-level vs session-level) 결정
  • 표본 크기: 내부 Agent의 제한된 트래픽에서 현실적으로 감지 가능한 효과 크기 산출

4.3 Phase 3: 고급 설계 (★★★)

[Sequential Testing] → [다중 비교] → [Human Eval] → [결과 분석·의사결정]
  • Sequential Testing: 적은 트래픽에서의 조기 종료 판단, Group Sequential Design, Alpha Spending
  • 다중 비교: 3종 Agent 동시 비교, Factorial design(모델 × 프롬프트 × retrieval), Multiple testing 보정
  • Human-in-the-Loop: 평가자 간 일치도(Cohen’s κ), 평가 루브릭 설계, 자동-인간 평가 상관 검증
  • 결과 분석: 효과 크기 해석, 신뢰구간 기반 판단, 가드레일 위반 처리, Go/No-Go 의사결정

4.4 Phase 4: 프로덕션 (★★★)

[Thompson Sampling 동적 라우팅] → [프로덕션 플랫폼]
  • Thompson Sampling: Beta 분포 기반 동적 트래픽 배분, 탐색-활용(Exploration-Exploitation) 균형, Regret 최소화
  • 프로덕션 플랫폼: Assignment service, Feature flag, 로깅 아키텍처, 자동 중단 규칙

5 이 시리즈에서 다루지 않는 것

범위 밖

6 관련 주제

선행 지식

시리즈 다음 포스트

다른 카테고리 연결

Subscribe

Enjoy this blog? Get notified of new posts by email: