운영 중인 서비스에서 프롬프트 A/B 테스트는 요청 트래픽을 두 갈래로 나누고, 각 그룹의 응답 품질을 같은 기준으로 비교해 더 나은 프롬프트를 골라내는 작업입니다. 트래픽 분리를 대충 하면 두 그룹의 사용자 특성이 애초에 달라져 버리고, 품질 지표를 미리 정하지 않으면 결과를 보고 나서야 기준을 끼워 맞추게 됩니다. 이 글에서는 해시 기반 트래픽 분리 코드와, 실무에서 바로 쓸 수 있는 품질 지표 후보를 조건과 함께 정리했습니다.
프롬프트 A/B 테스트, 운영 중에는 왜 다르게 접근해야 하나요?
개발 단계에서 프롬프트를 비교할 때는 테스트 데이터셋 몇십 건을 놓고 결과를 눈으로 훑어보는 정도로 충분합니다. 하지만 서비스가 운영 중이라면 이야기가 달라집니다. 실제 사용자의 입력은 테스트셋보다 훨씬 다양하고, 시간대·기기·사용자 유형에 따라 요청 패턴 자체가 편향돼 있는 경우가 많습니다.
이런 상황에서 A안과 B안을 순서대로(예: 이번 주는 A, 다음 주는 B) 운영하면 요일 효과나 캠페인 효과가 프롬프트 효과와 섞여 버립니다. 그래서 같은 시간대에 동시에 두 프롬프트를 트래픽 분리로 병행 운영하고, 사용자 단위로 그룹을 고정하는 방식이 필요합니다. 이 조건은 API 기반으로 LLM을 호출하고 대화 세션 ID나 사용자 ID를 이미 로깅하고 있는 서비스를 전제로 합니다.
트래픽 분리는 해시 기반 샘플링으로 구현합니다
가장 흔한 실수는 매 요청마다 random.random()으로 그룹을 정하는 방식입니다. 이렇게 하면 같은 사용자가 요청할 때마다 A안과 B안을 오가게 되어, 사용자별 만족도나 재사용률 같은 지표를 그룹별로 비교할 수 없습니다. 사용자 ID를 해시로 변환해 결정론적으로 그룹을 배정하면 같은 사용자는 실험이 끝날 때까지 항상 같은 그룹에 남습니다.
import hashlib
def assign_group(user_id: str, experiment_name: str, ratio: float = 0.5) -> str:
"""사용자 ID + 실험 이름을 해시해 결정론적으로 그룹을 배정합니다."""
key = f"{experiment_name}:{user_id}".encode("utf-8")
digest = hashlib.md5(key).hexdigest()
bucket = int(digest, 16) % 1000 / 1000 # 0.0 ~ 0.999
return "B" if bucket < ratio else "A"
# 예시 실행
for uid in ["user_1001", "user_1002", "user_1003"]:
print(uid, assign_group(uid, "prompt_v2_test", ratio=0.5))
user_1001 B
user_1002 A
user_1003 B
experiment_name을 해시 입력에 함께 넣는 이유는, 실험이 여러 개 동시에 돌아갈 때 한 사용자가 항상 같은 쪽(A 또는 B)에만 배정되는 상호 오염을 막기 위해서입니다. 실험마다 배정이 독립적으로 섞이도록 하는 셈입니다. GrowthBook이나 Statsig 같은 오픈소스·SaaS 실험 플랫폼도 내부적으로 이와 비슷한 해시 버킷팅을 씁니다.
품질 지표 후보와 측정 방법
품질 지표를 하나만 정하면 프롬프트가 그 지표에만 맞춰 튜닝되는 부작용이 생깁니다. 그래서 자동 지표와 사용자 행동 지표를 함께 보는 편이 안전합니다. 아래는 실무에서 자주 쓰는 조합입니다.
| 지표 | 측정 방법 | 자동화 여부 | 활용 시점 |
|---|---|---|---|
| 작업 성공률 | 규칙 기반 검증(JSON 스키마 통과, 필수 필드 존재 등) | 자동 | 매 요청마다 실시간 집계 |
| LLM-as-judge 점수 | 별도 모델로 두 응답을 상대 평가(A/B 중 우세 판정) | 자동(비용 발생) | 하루 단위 배치로 표본 평가 |
| 사용자 명시 피드백 | 좋아요/싫어요, 재시도(regenerate) 클릭률 | 반자동(로깅 필요) | 실험 종료 시점 집계 |
| 응답 지연시간 | API 응답까지 걸린 시간(ms) | 자동 | 실시간 모니터링 |
| 토큰 비용 | 입력·출력 토큰 수 × 단가 | 자동 | 그룹별 평균 비용 비교 |
LLM-as-judge 방식을 쓸 때는 판정 모델에 어느 쪽이 A이고 B인지 알려주지 않는 블라인드 비교가 필요합니다. 순서를 매번 무작위로 바꾸지 않으면 판정 모델이 먼저 제시된 응답을 선호하는 위치 편향이 생길 수 있다는 점은 관련 연구에서도 지적된 부분입니다. 자동 평가 설계에 대한 구체적인 기준은 Anthropic의 공식 프롬프트 평가 가이드에서 다루는 평가 파이프라인 구성 방식을 참고할 만합니다.
최소 샘플 수와 종료 시점을 미리 정해 보세요
실험을 시작하기 전에 "작업 성공률이 최소 5%포인트 차이 나야 의미 있다"처럼 기준을 잡고, 그 차이를 통계적으로 구분해내는 데 필요한 표본 수를 먼저 계산해 두는 편이 좋습니다. 표본 수 계산 없이 실험을 돌리다가 하루 이틀 만에 그룹 간 차이가 보인다고 바로 결론을 내리면, 우연히 벌어진 차이를 실제 효과로 오인하기 쉽습니다. 이 문제는 통계학에서 다루는 A/B 테스트의 유의성 검정 개념과 그대로 맞닿아 있습니다.
실험 도중 지표를 계속 들여다보면서 유의미한 차이가 보이는 순간 바로 종료하는 습관(피킹, peeking)도 조심해야 합니다. 사전에 정한 표본 수나 기간을 채우기 전에 중간 결과만 보고 실험을 멈추면, 우연히 튄 구간에서 종료하게 될 확률이 올라갑니다. 실험 설계 단계에서 "n명 또는 n일 중 먼저 도달하는 시점까지 유지" 같은 규칙을 문서로 남겨두면 이런 함정을 피할 수 있습니다.
이 방식이 잘 안 맞는 경우도 있습니다
일 트래픽이 수백 건 수준으로 적은 서비스라면, 통계적으로 의미 있는 차이를 확인하는 데 몇 주가 걸릴 수 있습니다. 이런 경우 실시간 트래픽 분리보다는, 과거 로그에서 실제 사용자 질문을 표본으로 뽑아 두 프롬프트에 동일하게 돌려보고 LLM-as-judge나 사람이 오프라인으로 비교하는 방식이 더 현실적입니다. 트래픽을 굳이 쪼개지 않아도 되고, 결과도 더 빨리 나옵니다.
또한 프롬프트 변경 폭이 아주 큰 경우(예: 답변 형식 자체를 JSON에서 자연어로 바꾸는 경우)에는 A/B 테스트보다 카나리 배포로 소수 트래픽에만 먼저 노출하고 오류율부터 확인하는 편이 안전합니다. A/B 테스트는 두 버전이 비슷한 수준으로 안정적일 때, 미세한 품질 차이를 가려내는 데 적합한 도구이지 신규 기능의 안전성을 검증하는 도구는 아닙니다.
지금 운영 중인 프롬프트가 있다면 이렇게 시작해 보세요
먼저 사용자 ID를 해시로 묶어 그룹을 고정하는 코드부터 배포하고, 작업 성공률처럼 자동으로 집계되는 지표 하나와 사용자 피드백처럼 행동 기반 지표 하나를 함께 로깅하는 구조를 만들어 두는 게 순서입니다. 실험 시작 전에 필요한 표본 수와 종료 시점을 문서로 정해두면, 중간에 결과를 보고 흔들리는 일을 줄일 수 있습니다. 트래픽이 충분하지 않다면 실시간 분리 대신 과거 로그 기반 오프라인 비교부터 시도해 보는 편이 시간을 아끼는 방법입니다.
