Skip to main content
좋은 변경도 검증 없이 전체 배포하면 장애가 됩니다. A/B 테스트는 “효과”와 “부작용”을 동시에 확인하는 과정입니다.

실험 설계 항목

항목설명
가설어떤 지표가 얼마나 개선될지
단위사용자/세션/요청 단위 분할
기간트래픽 변동을 반영한 충분한 기간
성공 기준최소 개선폭 + 안전 지표 조건
중단 기준오류율/지연/비용 급증 시 즉시 중단

롤아웃 전략

1

Canary 1-5%

고위험 지표를 집중 관찰합니다.
2

점진 확대 10-30-50%

단계마다 품질/비용/지연을 확인합니다.
3

100% 승격

기준 충족 시 기본 설정으로 전환합니다.

실패 시 대응

  • 즉시 이전 버전으로 롤백
  • 어떤 지표가 악화됐는지 사고 기록
  • 평가셋/프롬프트 가정 보완 후 재실험

Langfuse에서 롤아웃 전 사전 검증

1) Playground에서 프롬프트를 빠르게 검증합니다

  • 동일 질문으로 productioncandidate 출력을 비교합니다.
  • 출력 길이, 톤, 정책 문구 누락 여부를 먼저 확인합니다.
Langfuse prompt playground test

2) Playground가 비어 있으면 LLM Connection부터 설정합니다

  • 프로젝트에서 모델이 보이지 않으면 연결이 없는 상태입니다.
  • 조직/프로젝트 설정에서 LLM connection을 먼저 연결합니다.
Langfuse LLM connection setup required
실험군과 대조군의 사용자 분포가 다르면 결과를 신뢰할 수 없습니다. 세그먼트 균형을 먼저 확인합니다.

실무 적용 체크리스트

  • 이 문서의 규칙을 실제 서비스 플로우에 매핑했습니다.
  • 측정 지표와 실패 임계값을 숫자로 정의했습니다.
  • 변경 전/후를 비교할 기준 데이터셋 또는 로그를 준비했습니다.
  • 팀 내 공유 문서(런북/가이드)에 반영했습니다.

자주 나는 실수

  1. 기준 지표 없이 개선을 선언합니다.
  2. 한 번에 여러 변수를 바꿔 원인 추적이 불가능해집니다.
  3. 롤백 조건 없이 배포해 장애 복구가 늦어집니다.

다음 문서

다음: 운영과 거버넌스

학습 흐름을 이어서 진행합니다.