A/B 테스트와 카나리 배포 완벽 가이드

새로운 기능을 안전하게 배포하는 방법을 알아봅니다. A/B 테스트 설계부터 카나리 배포, 블루-그린 배포, 그리고 통계적 유의성 검증까지 실무에서 바로 적용할 수 있는 배포 전략을 다룹니다.

---

목차

1. A/B_테스트_설계
2. 트래픽_분할_전략
3. 카나리_배포_구현
4. 블루그린_배포
5. 롤아웃_자동화
6. 통계적_유의성_검증

---

1. A/B 테스트 설계

김개발 씨는 이커머스 서비스를 운영하는 스타트업에서 일하고 있습니다. 어느 날 PM이 찾아와 말했습니다.

"구매 버튼 색상을 빨간색으로 바꾸면 전환율이 올라갈 것 같은데, 확인해볼 수 있을까요?" 김개발 씨는 고민에 빠졌습니다. 단순히 바꿔버리면 기존보다 결과가 나빠질 수도 있는데, 어떻게 안전하게 테스트할 수 있을까요?

A/B 테스트는 두 가지 이상의 버전을 동시에 사용자에게 보여주고, 어떤 버전이 더 좋은 성과를 내는지 비교하는 실험 방법입니다. 마치 식당에서 두 가지 레시피로 같은 요리를 만들어 손님들의 반응을 비교하는 것과 같습니다.

이를 통해 감이 아닌 데이터에 기반한 의사결정을 할 수 있습니다.

다음 코드를 살펴봅시다.

// A/B 테스트 설정 인터페이스
interface ABTestConfig {
  testId: string;
  variants: Variant[];
  targetMetric: string;
  minSampleSize: number;
}

// 변형(Variant) 정의
interface Variant {
  id: string;
  name: string;
  weight: number;  // 트래픽 비율 (0-100)
}

// A/B 테스트 관리자 클래스
class ABTestManager {
  private tests: Map<string, ABTestConfig> = new Map();

  // 새로운 A/B 테스트 생성
  createTest(config: ABTestConfig): void {
    const totalWeight = config.variants.reduce((sum, v) => sum + v.weight, 0);
    if (totalWeight !== 100) {
      throw new Error('변형들의 가중치 합은 100이어야 합니다');
    }
    this.tests.set(config.testId, config);
  }

  // 사용자에게 변형 할당
  assignVariant(testId: string, userId: string): string {
    const test = this.tests.get(testId);
    if (!test) throw new Error('테스트를 찾을 수 없습니다');

    // 일관된 할당을 위한 해시 기반 선택
    const hash = this.hashCode(userId + testId);
    const bucket = Math.abs(hash) % 100;

    let cumulative = 0;
    for (const variant of test.variants) {
      cumulative += variant.weight;
      if (bucket < cumulative) return variant.id;
    }
    return test.variants[0].id;
  }

  private hashCode(str: string): number {
    let hash = 0;
    for (let i = 0; i < str.length; i++) {
      hash = ((hash << 5) - hash) + str.charCodeAt(i);
      hash = hash & hash;
    }
    return hash;
  }
}

김개발 씨는 입사 6개월 차 주니어 개발자입니다. PM의 요청을 받고 나서 어떻게 해야 할지 막막했습니다.

그냥 버튼 색상을 바꿔버리면 될 것 같지만, 만약 결과가 더 나빠지면 어떻게 하죠? 선배 개발자 박시니어 씨가 다가와 말했습니다.

"A/B 테스트를 해보면 어떨까요? 사용자 절반에게는 기존 버튼을, 나머지 절반에게는 새 버튼을 보여주는 거예요." 그렇다면 A/B 테스트란 정확히 무엇일까요?

쉽게 비유하자면, A/B 테스트는 마치 아이스크림 가게에서 새로운 맛을 출시하기 전에 시식 행사를 하는 것과 같습니다. 손님 절반에게는 기존 베스트셀러를, 나머지 절반에게는 신메뉴를 맛보게 합니다.

그리고 어떤 맛이 더 많이 팔리는지 지켜보는 것이죠. 이처럼 A/B 테스트도 사용자들을 나누어 각 버전의 성과를 비교합니다.

A/B 테스트가 없던 시절에는 어땠을까요? 개발자와 기획자들은 "감"에 의존해야 했습니다.

"이 색상이 더 눈에 잘 띄니까 전환율이 올라갈 거야"라는 추측으로 결정을 내렸습니다. 문제는 이런 추측이 틀릴 때 발생했습니다.

한 번 배포한 후에 성과가 떨어지면 다시 롤백해야 하고, 이 과정에서 사용자 경험이 일관되지 않게 됩니다. 바로 이런 문제를 해결하기 위해 A/B 테스트가 등장했습니다.

A/B 테스트를 사용하면 안전하게 실험할 수 있습니다. 일부 사용자에게만 새로운 버전을 보여주기 때문에, 만약 결과가 나빠도 전체 사용자에게 영향을 주지 않습니다.

또한 데이터 기반 의사결정이 가능해집니다. "내 생각에는..."이 아니라 "데이터를 보니..."로 대화할 수 있게 됩니다.

위의 코드를 살펴보겠습니다. 먼저 ABTestConfig 인터페이스에서 테스트의 기본 설정을 정의합니다.

testId로 테스트를 구분하고, variants 배열에 비교할 버전들을 담습니다. targetMetric은 무엇을 측정할지 정하고, minSampleSize는 통계적으로 의미 있는 결과를 얻기 위해 필요한 최소 표본 크기입니다.

assignVariant 메서드가 핵심입니다. 사용자 ID와 테스트 ID를 조합하여 해시값을 만들고, 이를 기반으로 어떤 변형을 보여줄지 결정합니다.

해시 기반 할당의 장점은 같은 사용자가 다시 방문해도 항상 같은 변형을 보게 된다는 것입니다. 실제 현업에서는 어떻게 활용할까요?

네이버 쇼핑이나 쿠팡 같은 이커머스 서비스를 생각해보세요. 상품 상세 페이지에서 "장바구니 담기" 버튼의 위치, 색상, 문구를 테스트합니다.

A 그룹에게는 "장바구니 담기"를, B 그룹에게는 "바로 담기"를 보여줍니다. 2주 후 데이터를 확인해보니 B 그룹의 클릭률이 15% 높았다면, 자신 있게 문구를 변경할 수 있습니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 표본 크기를 무시하는 것입니다.

100명만 테스트하고 "A가 5% 높으니까 A로 결정!"이라고 하면 안 됩니다. 통계적으로 의미 있는 결과를 얻으려면 충분한 표본이 필요합니다.

또한 한 사용자에게 여러 버전을 번갈아 보여주면 혼란을 줄 수 있으므로, 일관된 경험을 제공해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 조언을 듣고 A/B 테스트를 설정한 김개발 씨는 2주 후 결과를 확인했습니다. 빨간색 버튼의 전환율이 12% 높았습니다.

PM에게 데이터와 함께 보고하니, "역시 데이터로 보니까 확실하네요!"라는 칭찬을 받았습니다.

실전 팁

💡 - 한 번에 하나의 변수만 테스트하세요. 버튼 색상과 문구를 동시에 바꾸면 무엇이 효과를 낸 건지 알 수 없습니다.

• 테스트 기간은 최소 1-2주를 권장합니다. 요일별, 시간대별 트래픽 패턴을 반영해야 합니다.

---

2. 트래픽 분할 전략

A/B 테스트를 설계한 김개발 씨에게 새로운 고민이 생겼습니다. "50:50으로 나누면 되는 거 아니야?"라고 생각했는데, 박시니어 씨가 말했습니다.

"상황에 따라 다르게 나눠야 해요. 새 기능이 위험할 수 있다면 처음에는 10%만 보여주는 게 좋아요."

트래픽 분할 전략은 사용자들을 어떤 비율로 각 버전에 할당할지 결정하는 방법입니다. 마치 새로운 레스토랑 메뉴를 테스트할 때, 처음에는 단골손님 10%에게만 제공하다가 반응이 좋으면 점차 확대하는 것과 같습니다.

위험을 최소화하면서 충분한 데이터를 수집하는 균형이 중요합니다.

다음 코드를 살펴봅시다.

// 트래픽 분할 전략 타입
type SplitStrategy = 'equal' | 'weighted' | 'progressive';

interface TrafficSplitter {
  strategy: SplitStrategy;
  segments: TrafficSegment[];
}

interface TrafficSegment {
  variantId: string;
  percentage: number;
  conditions?: TargetingCondition[];
}

// 타겟팅 조건 (특정 사용자 그룹만 테스트)
interface TargetingCondition {
  attribute: 'country' | 'device' | 'userType' | 'version';
  operator: 'equals' | 'contains' | 'greaterThan';
  value: string | number;
}

class TrafficSplitterService {
  // 점진적 롤아웃 설정
  createProgressiveRollout(variantId: string, stages: number[]): TrafficSegment[] {
    // stages 예: [10, 25, 50, 100] - 10%부터 시작해서 100%까지
    return stages.map((percentage, index) => ({
      variantId,
      percentage,
      stageIndex: index,
    }));
  }

  // 조건부 트래픽 분할
  assignWithConditions(
    user: UserContext,
    segments: TrafficSegment[]
  ): string | null {
    for (const segment of segments) {
      if (this.matchesConditions(user, segment.conditions)) {
        if (this.isInPercentage(user.id, segment.percentage)) {
          return segment.variantId;
        }
      }
    }
    return null;  // 기본 버전 사용
  }

  private matchesConditions(
    user: UserContext,
    conditions?: TargetingCondition[]
  ): boolean {
    if (!conditions || conditions.length === 0) return true;

    return conditions.every(condition => {
      const userValue = user[condition.attribute];
      switch (condition.operator) {
        case 'equals': return userValue === condition.value;
        case 'contains': return String(userValue).includes(String(condition.value));
        case 'greaterThan': return Number(userValue) > Number(condition.value);
        default: return false;
      }
    });
  }

  private isInPercentage(userId: string, percentage: number): boolean {
    const hash = this.simpleHash(userId);
    return (hash % 100) < percentage;
  }

  private simpleHash(str: string): number {
    let hash = 5381;
    for (let i = 0; i < str.length; i++) {
      hash = ((hash << 5) + hash) + str.charCodeAt(i);
    }
    return Math.abs(hash);
  }
}

interface UserContext {
  id: string;
  country: string;
  device: string;
  userType: string;
  version: string;
  [key: string]: string | number;
}

김개발 씨는 A/B 테스트의 기본을 이해했습니다. 하지만 실제로 트래픽을 나누려고 하니 여러 가지 의문이 생겼습니다.

모든 사용자를 대상으로 해도 될까? 해외 사용자와 국내 사용자를 같이 테스트해도 될까?

박시니어 씨가 화이트보드에 그림을 그리며 설명했습니다. "트래픽 분할에는 여러 전략이 있어요.

상황에 맞게 골라야 합니다." 트래픽 분할 전략이란 무엇일까요? 비유하자면, 이것은 마치 학교에서 새로운 급식 메뉴를 테스트하는 것과 같습니다.

처음부터 전교생에게 제공하지 않고, 먼저 3학년 한 반에만 제공해봅니다. 반응이 좋으면 3학년 전체로 확대하고, 그 다음에 전교생으로 확대합니다.

만약 반응이 안 좋으면 한 반만 영향을 받으니까 피해가 적습니다. 가장 단순한 방법은 **균등 분할(Equal Split)**입니다.

50:50으로 나누는 방식이죠. 빠르게 통계적 유의성에 도달할 수 있지만, 새 버전에 문제가 있으면 절반의 사용자가 영향을 받습니다.

따라서 충분히 검증된 기능에 적합합니다. 다음은 **가중치 분할(Weighted Split)**입니다.

예를 들어 90:10으로 나눕니다. 기존 버전에 90%, 새 버전에 10%를 할당합니다.

새 기능의 위험도가 높을 때 사용합니다. 문제가 생겨도 10%만 영향을 받으니까요.

대신 통계적 유의성에 도달하는 데 시간이 더 걸립니다. 마지막으로 **점진적 롤아웃(Progressive Rollout)**입니다.

위의 코드에서 createProgressiveRollout 메서드를 보세요. [10, 25, 50, 100]이라는 단계를 설정합니다.

처음에는 10%로 시작하고, 문제가 없으면 25%로 올립니다. 계속 모니터링하면서 최종적으로 100%까지 확대합니다.

대부분의 대기업에서 이 방식을 사용합니다. 조건부 타겟팅도 중요한 개념입니다.

TargetingCondition 인터페이스를 보면, country, device, userType 같은 조건을 설정할 수 있습니다. 예를 들어 "한국 사용자 중 모바일 앱 버전 3.0 이상인 사용자"에게만 새 기능을 테스트할 수 있습니다.

이렇게 하면 특정 환경에서의 문제를 미리 발견할 수 있습니다. 실제 현업에서는 어떻게 활용할까요?

토스나 카카오뱅크 같은 핀테크 서비스를 생각해보세요. 송금 화면 UI를 변경한다면, 처음에는 내부 직원들에게만 보여줍니다.

문제가 없으면 베타 테스터 그룹으로 확대합니다. 그 다음 전체 사용자의 5%에게 노출하고, 점차 비율을 높여갑니다.

금융 서비스는 한 번의 실수가 큰 손실로 이어질 수 있기 때문에 이런 신중한 접근이 필수입니다. 주의할 점이 있습니다.

샘플 오염을 조심해야 합니다. 한 사용자가 여러 기기에서 접속할 때, 어떤 기기에서는 A 버전을, 다른 기기에서는 B 버전을 보면 데이터가 왜곡됩니다.

따라서 사용자 ID 기반으로 일관되게 할당하는 것이 중요합니다. 위 코드의 simpleHash 함수가 바로 이 역할을 합니다.

김개발 씨는 고개를 끄덕였습니다. "아, 그래서 쿠키나 세션이 아니라 사용자 ID를 기준으로 하는 거군요!" 박시니어 씨가 웃으며 대답했습니다.

"맞아요. 일관된 경험을 제공하면서 정확한 데이터를 수집하는 게 핵심이에요."

실전 팁

💡 - 위험도가 높은 기능은 5-10%로 시작하고, 안정적인 기능은 50%로 시작하세요.

• 내부 직원이나 베타 테스터 그룹을 활용하면 초기 버그를 빠르게 발견할 수 있습니다.
• 타임존과 지역을 고려하세요. 한국 저녁 시간에만 테스트하면 직장인 데이터만 수집될 수 있습니다.

---

3. 카나리 배포 구현

어느 날 김개발 씨의 회사에서 대형 장애가 발생했습니다. 새 버전을 배포했는데 서버가 다운된 것입니다.

CTO가 긴급 회의를 소집했습니다. "앞으로는 카나리 배포를 도입합시다.

전체 배포 전에 일부 서버에서 먼저 테스트해야 해요." 김개발 씨는 카나리가 뭔지 궁금해졌습니다.

카나리 배포는 새 버전을 전체 서버 중 일부에만 먼저 배포하고, 문제가 없는지 확인한 후 점진적으로 확대하는 방식입니다. 이름의 유래는 옛날 광부들이 탄광에 카나리아 새를 데려가 유독가스를 감지했던 것에서 왔습니다.

새가 먼저 위험을 알려주듯이, 일부 서버가 먼저 문제를 감지합니다.

다음 코드를 살펴봅시다.

// 카나리 배포 설정
interface CanaryConfig {
  serviceName: string;
  stableVersion: string;
  canaryVersion: string;
  initialWeight: number;  // 카나리에 보낼 초기 트래픽 비율
  maxWeight: number;
  stepWeight: number;     // 단계별 증가량
  interval: number;       // 단계 간격 (분)
  metrics: CanaryMetrics;
}

interface CanaryMetrics {
  errorRateThreshold: number;    // 에러율 임계값 (%)
  latencyP99Threshold: number;   // P99 레이턴시 임계값 (ms)
  successRateThreshold: number;  // 성공률 임계값 (%)
}

class CanaryDeployer {
  private currentWeight: number = 0;

  async deploy(config: CanaryConfig): Promise<boolean> {
    console.log(`카나리 배포 시작: ${config.canaryVersion}`);
    this.currentWeight = config.initialWeight;

    // 초기 카나리 배포
    await this.updateTrafficWeight(config.serviceName, this.currentWeight);

    // 점진적 롤아웃
    while (this.currentWeight < config.maxWeight) {
      await this.wait(config.interval);

      // 메트릭 확인
      const isHealthy = await this.checkHealth(config);

      if (!isHealthy) {
        console.log('카나리 배포 실패 - 롤백 시작');
        await this.rollback(config.serviceName);
        return false;
      }

      // 트래픽 비율 증가
      this.currentWeight = Math.min(
        this.currentWeight + config.stepWeight,
        config.maxWeight
      );
      await this.updateTrafficWeight(config.serviceName, this.currentWeight);
      console.log(`트래픽 비율 증가: ${this.currentWeight}%`);
    }

    console.log('카나리 배포 성공 - 전체 롤아웃 완료');
    return true;
  }

  private async checkHealth(config: CanaryConfig): Promise<boolean> {
    const metrics = await this.fetchMetrics(config.serviceName);

    // 에러율 체크
    if (metrics.errorRate > config.metrics.errorRateThreshold) {
      console.log(`에러율 초과: ${metrics.errorRate}%`);
      return false;
    }

    // 레이턴시 체크
    if (metrics.latencyP99 > config.metrics.latencyP99Threshold) {
      console.log(`레이턴시 초과: ${metrics.latencyP99}ms`);
      return false;
    }

    return true;
  }

  private async rollback(serviceName: string): Promise<void> {
    await this.updateTrafficWeight(serviceName, 0);
    console.log('롤백 완료: 모든 트래픽이 안정 버전으로 전환됨');
  }

  private async updateTrafficWeight(service: string, weight: number): Promise<void> {
    // 실제로는 로드밸런서나 서비스 메시 설정 업데이트
    console.log(`${service}: 카나리 가중치 ${weight}%로 설정`);
  }

  private async fetchMetrics(service: string): Promise<{errorRate: number; latencyP99: number}> {
    // 실제로는 Prometheus, Datadog 등에서 메트릭 조회
    return { errorRate: 0.5, latencyP99: 150 };
  }

  private wait(minutes: number): Promise<void> {
    return new Promise(resolve => setTimeout(resolve, minutes * 60 * 1000));
  }
}

김개발 씨는 "카나리"라는 이름이 왜 붙었는지 궁금했습니다. 박시니어 씨가 설명해주었습니다.

"옛날 광부들은 탄광에 들어갈 때 카나리아 새를 데려갔어요." "새를요? 왜요?" "카나리아는 일산화탄소에 민감해서, 사람보다 먼저 쓰러져요.

새가 이상하면 광부들은 바로 대피했죠. 카나리 배포도 마찬가지예요.

일부 서버가 먼저 문제를 감지하는 거죠." 카나리 배포는 전체 서버 중 일부에만 새 버전을 배포하는 전략입니다. 예를 들어 서버가 100대라면, 처음에는 5대에만 새 버전을 배포합니다.

이 5대의 서버로 전체 트래픽의 5%가 흘러갑니다. 모니터링 시스템이 에러율, 응답 시간, CPU 사용량 등을 계속 지켜봅니다.

문제가 없으면 10대로 늘립니다. 계속 문제가 없으면 20대, 50대, 그리고 최종적으로 100대 전체로 확대합니다.

위의 코드에서 CanaryConfig를 살펴보겠습니다. initialWeight는 처음 카나리에 보낼 트래픽 비율입니다.

보통 5-10%로 시작합니다. stepWeight는 한 번에 얼마나 증가시킬지, interval은 단계 사이에 얼마나 기다릴지를 정합니다.

예를 들어 5%에서 시작해서 10분마다 5%씩 증가시키면, 100%까지 약 3시간이 걸립니다. CanaryMetrics가 핵심입니다.

errorRateThreshold는 "에러율이 이 값을 넘으면 문제가 있다"는 기준입니다. 보통 1-5%로 설정합니다.

latencyP99Threshold는 상위 1% 요청의 응답 시간 기준입니다. P99이 500ms를 넘으면 느린 요청이 너무 많다는 의미입니다.

checkHealth 메서드가 문지기 역할을 합니다. 배포가 진행되는 동안 계속해서 메트릭을 확인합니다.

에러율이 임계값을 넘거나, 레이턴시가 너무 높아지면 즉시 배포를 중단합니다. 그리고 rollback 메서드가 호출되어 모든 트래픽을 다시 안정 버전으로 돌립니다.

실제 현업에서는 어떻게 구현할까요? 넷플릭스나 스포티파이 같은 글로벌 서비스는 수천 대의 서버를 운영합니다.

이들은 카나리 배포를 완전 자동화했습니다. 개발자가 코드를 머지하면 CI/CD 파이프라인이 자동으로 카나리 배포를 시작합니다.

메트릭이 정상이면 자동으로 비율이 증가하고, 이상이 감지되면 자동으로 롤백됩니다. 사람의 개입 없이 안전하게 배포가 이루어지는 것이죠.

주의할 점도 있습니다. 카나리 배포가 효과를 발휘하려면 좋은 메트릭이 필수입니다.

에러율만 보면 안 됩니다. 사용자 경험과 직결되는 지표들, 예를 들어 전환율, 이탈률, 페이지 로드 시간 등도 함께 모니터링해야 합니다.

또한 새 버전과 기존 버전이 동시에 운영되므로 데이터베이스 스키마 호환성도 고려해야 합니다. 김개발 씨가 물었습니다.

"그러면 A/B 테스트랑 뭐가 다른 거예요?" 박시니어 씨가 대답했습니다. "A/B 테스트는 어떤 버전이 '더 좋은지' 비교하는 실험이에요.

카나리 배포는 새 버전이 '문제없이 작동하는지' 확인하는 안전장치예요. 목적이 다르죠.

물론 둘을 함께 사용할 수도 있어요."

실전 팁

💡 - 카나리 비율을 너무 빨리 올리지 마세요. 문제가 서서히 나타나는 경우도 있습니다.

• 롤백 기준은 보수적으로 잡으세요. 의심스러우면 롤백하는 게 안전합니다.
• 배포 시간대를 고려하세요. 트래픽이 적은 새벽보다는 주간에 배포해야 문제를 빨리 발견합니다.

---

4. 블루그린 배포

김개발 씨의 회사에서 카나리 배포를 도입한 후 장애가 많이 줄었습니다. 하지만 어느 날 DBA 선배가 말했습니다.

"카나리도 좋지만, 데이터베이스 마이그레이션이 있는 배포에는 블루-그린이 더 적합해요." 김개발 씨는 또 새로운 용어를 배우게 되었습니다.

블루-그린 배포는 동일한 프로덕션 환경을 두 개 유지하고, 트래픽을 한 번에 전환하는 방식입니다. 마치 무대 뒤에서 다음 장면을 완벽하게 준비해놓고, 순간적으로 무대를 바꾸는 연극과 같습니다.

현재 운영 중인 환경을 블루, 새 버전이 배포된 환경을 그린이라고 부릅니다.

다음 코드를 살펴봅시다.

// 블루-그린 배포 환경 상태
type Environment = 'blue' | 'green';
type EnvironmentStatus = 'active' | 'idle' | 'deploying';

interface BlueGreenConfig {
  serviceName: string;
  blueEndpoint: string;
  greenEndpoint: string;
  healthCheckPath: string;
  healthCheckTimeout: number;
  switchoverDelay: number;
}

interface EnvironmentState {
  environment: Environment;
  version: string;
  status: EnvironmentStatus;
  lastDeployedAt: Date;
}

class BlueGreenDeployer {
  private state: Map<Environment, EnvironmentState> = new Map();
  private activeEnvironment: Environment = 'blue';

  async deploy(config: BlueGreenConfig, newVersion: string): Promise<boolean> {
    // 현재 활성 환경의 반대편에 배포
    const targetEnv = this.activeEnvironment === 'blue' ? 'green' : 'blue';
    const targetEndpoint = targetEnv === 'blue'
      ? config.blueEndpoint
      : config.greenEndpoint;

    console.log(`${targetEnv} 환경에 버전 ${newVersion} 배포 시작`);

    try {
      // 1. 대기 환경에 새 버전 배포
      await this.deployToEnvironment(targetEnv, newVersion);

      // 2. 헬스 체크 수행
      const isHealthy = await this.performHealthCheck(
        targetEndpoint,
        config.healthCheckPath,
        config.healthCheckTimeout
      );

      if (!isHealthy) {
        console.log('헬스 체크 실패 - 배포 중단');
        return false;
      }

      // 3. 트래픽 전환 전 대기
      console.log(`${config.switchoverDelay}초 후 트래픽 전환`);
      await this.wait(config.switchoverDelay);

      // 4. 로드밸런서에서 트래픽 전환
      await this.switchTraffic(config.serviceName, targetEnv);

      // 5. 상태 업데이트
      this.activeEnvironment = targetEnv;
      this.updateState(targetEnv, newVersion, 'active');
      this.updateState(
        this.activeEnvironment === 'blue' ? 'green' : 'blue',
        this.state.get(this.activeEnvironment === 'blue' ? 'green' : 'blue')?.version || '',
        'idle'
      );

      console.log(`트래픽이 ${targetEnv} 환경으로 전환됨`);
      return true;

    } catch (error) {
      console.error('배포 실패:', error);
      return false;
    }
  }

  async rollback(config: BlueGreenConfig): Promise<void> {
    const previousEnv = this.activeEnvironment === 'blue' ? 'green' : 'blue';

    console.log(`${previousEnv} 환경으로 롤백`);
    await this.switchTraffic(config.serviceName, previousEnv);
    this.activeEnvironment = previousEnv;
  }

  private async performHealthCheck(
    endpoint: string,
    path: string,
    timeout: number
  ): Promise<boolean> {
    const startTime = Date.now();
    const maxAttempts = 10;

    for (let attempt = 1; attempt <= maxAttempts; attempt++) {
      try {
        const response = await fetch(`${endpoint}${path}`, {
          signal: AbortSignal.timeout(timeout * 1000)
        });

        if (response.ok) {
          console.log(`헬스 체크 성공 (시도 ${attempt})`);
          return true;
        }
      } catch (error) {
        console.log(`헬스 체크 시도 ${attempt}/${maxAttempts} 실패`);
      }

      await this.wait(5);
    }

    return false;
  }

  private async deployToEnvironment(env: Environment, version: string): Promise<void> {
    this.updateState(env, version, 'deploying');
    // 실제로는 Kubernetes, ECS 등을 통해 배포
    console.log(`${env} 환경에 ${version} 배포 중...`);
  }

  private async switchTraffic(service: string, targetEnv: Environment): Promise<void> {
    // 실제로는 로드밸런서 설정 변경
    console.log(`${service}의 트래픽을 ${targetEnv}로 전환`);
  }

  private updateState(env: Environment, version: string, status: EnvironmentStatus): void {
    this.state.set(env, { environment: env, version, status, lastDeployedAt: new Date() });
  }

  private wait(seconds: number): Promise<void> {
    return new Promise(resolve => setTimeout(resolve, seconds * 1000));
  }
}

박시니어 씨가 화이트보드에 두 개의 박스를 그렸습니다. 하나는 파란색, 하나는 초록색입니다.

"지금 사용자들은 블루 환경을 사용하고 있어요. 그린 환경은 완전히 똑같지만, 아무도 사용하지 않고 대기 중이에요." 김개발 씨가 물었습니다.

"서버를 두 배로 유지한다는 건가요? 비용이 많이 들지 않나요?" "맞아요, 비용은 단점이에요.

하지만 그만큼 큰 장점이 있죠." 블루-그린 배포의 핵심은 즉각적인 전환입니다. 카나리 배포가 서서히 비율을 높이는 것과 달리, 블루-그린은 스위치를 딸깍 누르듯 한 번에 전환합니다.

현재 블루 환경에서 서비스하고 있다면, 그린 환경에 새 버전을 완전히 배포하고 충분히 테스트합니다. 준비가 끝나면 로드밸런서 설정을 변경해서 모든 트래픽을 그린으로 보냅니다.

위의 코드에서 deploy 메서드의 흐름을 보겠습니다. 먼저 현재 활성 환경의 반대편을 찾습니다.

블루가 활성이면 그린에 배포합니다. 새 버전을 배포한 후, 헬스 체크를 수행합니다.

이 과정에서 실제 프로덕션 트래픽은 영향을 받지 않습니다. 그린 환경은 아직 대기 상태니까요.

헬스 체크가 통과하면 로드밸런서를 통해 트래픽을 전환합니다. 롤백이 정말 빠릅니다. 문제가 발생하면 rollback 메서드 한 번 호출로 이전 환경으로 돌아갑니다.

블루 환경은 그대로 살아있거든요. 새로 배포할 필요 없이, 로드밸런서만 다시 블루로 향하게 하면 됩니다.

몇 초 만에 롤백이 완료됩니다. 다운타임이 거의 없습니다. 사용자 입장에서는 서비스 중단을 경험하지 않습니다.

한 요청은 블루로, 다음 요청은 그린으로 갈 수 있지만, 양쪽 다 정상 작동하니까 문제없습니다. 물론 세션 처리나 데이터 일관성은 별도로 고려해야 합니다.

언제 블루-그린을 선택해야 할까요? 데이터베이스 스키마 변경이 있을 때 특히 유용합니다.

카나리 배포에서는 새 버전과 기존 버전이 같은 데이터베이스를 공유합니다. 스키마가 달라지면 호환성 문제가 생깁니다.

블루-그린에서는 각 환경이 별도의 데이터베이스를 가질 수 있어서 이런 문제를 피할 수 있습니다. 주의할 점도 있습니다.

첫째, 비용입니다. 동일한 환경을 두 개 유지해야 하므로 인프라 비용이 거의 두 배입니다.

클라우드 환경에서는 대기 환경의 사양을 낮춰두었다가 배포 시에만 스케일업하는 방법도 있습니다. 둘째, 데이터 동기화입니다.

두 환경이 같은 데이터베이스를 쓴다면 괜찮지만, 별도 데이터베이스를 쓴다면 전환 시점에 데이터가 동기화되어야 합니다. 김개발 씨가 정리했습니다.

"카나리는 조금씩 늘려가면서 테스트하고, 블루-그린은 완전히 준비한 다음에 한 번에 바꾸는 거네요." 박시니어 씨가 고개를 끄덕였습니다. "맞아요.

상황에 따라 선택하면 돼요. 작은 변경은 카나리로, 큰 변경이나 DB 마이그레이션은 블루-그린으로 하는 경우가 많아요."

실전 팁

💡 - 대기 환경을 항상 최신 상태로 유지하세요. 급하게 배포할 때 환경 설정부터 해야 하면 시간이 오래 걸립니다.

• 전환 후에도 일정 시간 이전 환경을 유지하세요. 예상치 못한 문제 발생 시 빠르게 롤백할 수 있습니다.
• 두 환경 간 환경 변수나 설정이 다르지 않은지 정기적으로 확인하세요.

---

5. 롤아웃 자동화

몇 달이 지나자 김개발 씨의 팀은 카나리 배포와 블루-그린 배포를 능숙하게 다루게 되었습니다. 하지만 매번 수동으로 메트릭을 확인하고 비율을 조정하는 게 번거로웠습니다.

"이거 자동화할 수 없을까요?"라고 김개발 씨가 물었습니다. 박시니어 씨가 웃으며 대답했습니다.

"드디어 그 질문을 하는군요."

롤아웃 자동화는 배포 과정에서 사람의 개입을 최소화하고, 메트릭 기반으로 자동 승격 또는 롤백을 수행하는 시스템입니다. 마치 자동 온도 조절 장치가 설정 온도에 맞춰 냉난방을 조절하듯, 배포 시스템이 설정된 기준에 따라 스스로 판단하고 행동합니다.

다음 코드를 살펴봅시다.

// 롤아웃 자동화 설정
interface AutoRolloutConfig {
  serviceName: string;
  stages: RolloutStage[];
  metrics: MetricConfig[];
  notifications: NotificationChannel[];
  autoRollback: boolean;
}

interface RolloutStage {
  name: string;
  weight: number;          // 이 단계의 트래픽 비율
  duration: number;        // 이 단계 유지 시간 (분)
  requiredApprovals?: number;  // 수동 승인 필요 시
}

interface MetricConfig {
  name: string;
  query: string;           // Prometheus 쿼리 등
  threshold: number;
  comparison: 'lessThan' | 'greaterThan';
  weight: number;          // 가중치 (종합 점수 계산용)
}

interface NotificationChannel {
  type: 'slack' | 'email' | 'pagerduty';
  target: string;
  events: ('stageChange' | 'failure' | 'success' | 'rollback')[];
}

class AutomatedRolloutController {
  private currentStage: number = 0;
  private rolloutId: string;

  constructor(private config: AutoRolloutConfig) {
    this.rolloutId = `rollout-${Date.now()}`;
  }

  async execute(): Promise<{ success: boolean; reason?: string }> {
    console.log(`롤아웃 시작: ${this.rolloutId}`);
    await this.notify('stageChange', `롤아웃 시작: ${this.config.serviceName}`);

    for (let i = 0; i < this.config.stages.length; i++) {
      this.currentStage = i;
      const stage = this.config.stages[i];

      console.log(`스테이지 ${stage.name} 시작 (${stage.weight}%)`);

      // 트래픽 비율 설정
      await this.setTrafficWeight(stage.weight);
      await this.notify('stageChange', `${stage.name}: ${stage.weight}%`);

      // 수동 승인이 필요한 경우
      if (stage.requiredApprovals) {
        const approved = await this.waitForApprovals(stage.requiredApprovals);
        if (!approved) {
          return this.handleFailure('수동 승인 거부됨');
        }
      }

      // 스테이지 기간 동안 모니터링
      const monitorResult = await this.monitorForDuration(stage.duration);

      if (!monitorResult.healthy) {
        return this.handleFailure(monitorResult.reason || '메트릭 기준 미달');
      }
    }

    await this.notify('success', '롤아웃 완료');
    return { success: true };
  }

  private async monitorForDuration(
    durationMinutes: number
  ): Promise<{ healthy: boolean; reason?: string }> {
    const checkInterval = 1;  // 1분마다 체크
    const checks = durationMinutes / checkInterval;

    for (let i = 0; i < checks; i++) {
      await this.wait(checkInterval);

      const score = await this.calculateHealthScore();
      console.log(`헬스 스코어: ${score.toFixed(2)}`);

      if (score < 70) {  // 70점 미만이면 실패
        return {
          healthy: false,
          reason: `헬스 스코어 ${score.toFixed(2)} < 70`
        };
      }
    }

    return { healthy: true };
  }

  private async calculateHealthScore(): Promise<number> {
    let totalScore = 0;
    let totalWeight = 0;

    for (const metric of this.config.metrics) {
      const value = await this.queryMetric(metric.query);
      const passed = metric.comparison === 'lessThan'
        ? value < metric.threshold
        : value > metric.threshold;

      totalScore += passed ? metric.weight * 100 : 0;
      totalWeight += metric.weight;
    }

    return totalScore / totalWeight;
  }

  private async handleFailure(reason: string): Promise<{ success: boolean; reason: string }> {
    console.log(`롤아웃 실패: ${reason}`);
    await this.notify('failure', reason);

    if (this.config.autoRollback) {
      console.log('자동 롤백 시작');
      await this.setTrafficWeight(0);
      await this.notify('rollback', '자동 롤백 완료');
    }

    return { success: false, reason };
  }

  private async setTrafficWeight(weight: number): Promise<void> {
    console.log(`트래픽 가중치 설정: ${weight}%`);
  }

  private async queryMetric(query: string): Promise<number> {
    // 실제로는 Prometheus, Datadog 등에서 쿼리
    return Math.random() * 100;
  }

  private async waitForApprovals(required: number): Promise<boolean> {
    console.log(`${required}명의 승인 대기 중...`);
    return true;  // 실제로는 승인 시스템과 연동
  }

  private async notify(event: string, message: string): Promise<void> {
    const channels = this.config.notifications.filter(n =>
      n.events.includes(event as any)
    );

    for (const channel of channels) {
      console.log(`[${channel.type}] ${message}`);
    }
  }

  private wait(minutes: number): Promise<void> {
    return new Promise(resolve => setTimeout(resolve, minutes * 60 * 1000));
  }
}

박시니어 씨가 화면을 보여주었습니다. "이건 우리 팀에서 사용하는 롤아웃 대시보드예요.

배포가 시작되면 자동으로 진행됩니다." 화면에는 스테이지 바가 있었습니다. "5% - 10% - 25% - 50% - 100%"라고 표시된 단계들이 보입니다.

현재 25% 단계에 초록색 불이 들어와 있었습니다. 롤아웃 자동화란 무엇일까요?

마치 스마트 홈 시스템을 생각해보세요. "온도가 28도 이상이면 에어컨 켜기, 22도 이하면 끄기"라고 설정해두면 자동으로 작동합니다.

롤아웃 자동화도 마찬가지입니다. "에러율 1% 이하면 다음 단계로, 5% 이상이면 롤백"이라고 설정해두면 시스템이 알아서 판단합니다.

위의 코드에서 AutoRolloutConfig를 보겠습니다. stages 배열에 각 단계를 정의합니다.

첫 번째 단계는 5%로 10분 동안 유지, 두 번째 단계는 25%로 30분 유지, 이런 식입니다. 각 단계에는 requiredApprovals를 설정할 수 있습니다.

예를 들어 50% 단계에서는 테크리드의 승인이 필요하도록 설정할 수 있죠. MetricConfig가 자동화의 두뇌입니다.

어떤 메트릭을 어떤 기준으로 판단할지 정의합니다. 예를 들어 "error_rate가 1 미만이면 통과", "p99_latency가 500 미만이면 통과" 같은 조건들입니다.

각 메트릭에 가중치를 줘서 종합 점수를 계산합니다. calculateHealthScore 메서드가 이 역할을 합니다.

알림 시스템도 중요합니다. NotificationChannel에서 Slack, 이메일, PagerDuty 같은 채널을 설정합니다.

각 채널별로 어떤 이벤트에 알림을 받을지 정할 수 있습니다. 성공 알림은 Slack으로, 실패 알림은 PagerDuty로 보내는 식이죠.

배포가 자동으로 진행되더라도 팀원들은 상황을 실시간으로 알 수 있습니다. 자동 롤백이 안전망입니다.

autoRollback이 true로 설정되어 있으면, 메트릭 기준을 만족하지 못할 때 자동으로 이전 버전으로 롤백합니다. 새벽 3시에 배포가 진행되다가 문제가 생겨도 개발자가 잠에서 깨기 전에 롤백이 완료됩니다.

실무에서는 어떻게 구현할까요? Argo Rollouts, Flagger, Spinnaker 같은 도구들이 있습니다.

Kubernetes 환경이라면 Argo Rollouts가 인기 있습니다. 선언적으로 롤아웃 전략을 정의하고, Prometheus와 연동해서 메트릭을 수집합니다.

조건에 따라 자동으로 승격하거나 롤백합니다. 주의할 점이 있습니다.

메트릭 선정이 정말 중요합니다. 에러율만 보면 안 됩니다.

에러율은 낮은데 응답 시간이 10배 느려졌다면? 사용자 경험은 크게 나빠집니다.

비즈니스에 중요한 지표들을 종합적으로 고려해야 합니다. 또한 알림 피로를 조심해야 합니다.

모든 이벤트에 알림을 보내면 정작 중요한 알림을 놓칠 수 있습니다. 정말 중요한 이벤트만 선별해서 알림을 설정하세요.

김개발 씨가 감탄했습니다. "이게 있으면 편하게 퇴근할 수 있겠네요!" 박시니어 씨가 웃었습니다.

"자동화가 잘 되어 있으면 그렇죠. 하지만 처음 설정할 때는 보수적으로 하고, 점점 자동화 범위를 넓혀가는 게 좋아요."

실전 팁

💡 - 처음에는 수동 승인 단계를 여러 곳에 두고, 안정화되면 점차 줄여가세요.

• 메트릭 임계값은 평상시 데이터를 기반으로 설정하세요. 너무 빡빡하면 정상 배포도 롤백됩니다.
• 롤백 알림은 반드시 설정하세요. 자동 롤백이 일어났는데 아무도 모르면 안 됩니다.

---

6. 통계적 유의성 검증

A/B 테스트 결과가 나왔습니다. A 버전의 전환율은 3.2%, B 버전은 3.5%였습니다.

PM이 기뻐하며 말했습니다. "B가 0.3%p 높으니까 B로 가죠!" 하지만 박시니어 씨가 손을 들었습니다.

"잠깐요, 이게 진짜 차이인지 아니면 우연인지 확인해봐야 해요. 통계적 유의성을 검증해봅시다."

통계적 유의성은 관찰된 차이가 우연이 아니라 실제 차이인지 판단하는 방법입니다. 마치 동전을 10번 던져서 6번 앞면이 나왔을 때, 이게 동전이 앞면에 유리해서인지 아니면 그냥 운이 좋았던 건지 판단하는 것과 같습니다.

p-value와 신뢰구간을 통해 결과의 신뢰도를 측정합니다.

다음 코드를 살펴봅시다.

// 통계적 유의성 검증을 위한 타입
interface ABTestResult {
  variantA: VariantMetrics;
  variantB: VariantMetrics;
}

interface VariantMetrics {
  visitors: number;      // 방문자 수
  conversions: number;   // 전환 수
  conversionRate: number;  // 전환율
}

interface StatisticalResult {
  pValue: number;
  confidenceInterval: [number, number];
  isSignificant: boolean;
  recommendedWinner: 'A' | 'B' | 'none';
  sampleSizeReached: boolean;
  powerAnalysis: PowerAnalysis;
}

interface PowerAnalysis {
  requiredSampleSize: number;
  currentPower: number;
  minimumDetectableEffect: number;
}

class StatisticalAnalyzer {
  private significanceLevel: number = 0.05;  // 95% 신뢰수준
  private desiredPower: number = 0.8;        // 80% 검정력

  analyzeABTest(result: ABTestResult): StatisticalResult {
    const { variantA, variantB } = result;

    // 전환율 계산
    const pA = variantA.conversions / variantA.visitors;
    const pB = variantB.conversions / variantB.visitors;

    // 풀링된 전환율
    const pooledP = (variantA.conversions + variantB.conversions) /
                    (variantA.visitors + variantB.visitors);

    // 표준 오차 계산
    const standardError = Math.sqrt(
      pooledP * (1 - pooledP) *
      (1 / variantA.visitors + 1 / variantB.visitors)
    );

    // Z-점수 계산
    const zScore = (pB - pA) / standardError;

    // p-value 계산 (양측 검정)
    const pValue = 2 * (1 - this.normalCDF(Math.abs(zScore)));

    // 95% 신뢰구간
    const diff = pB - pA;
    const marginOfError = 1.96 * standardError;
    const confidenceInterval: [number, number] = [
      diff - marginOfError,
      diff + marginOfError
    ];

    // 필요 표본 크기 계산
    const powerAnalysis = this.calculatePowerAnalysis(pA, pB,
      variantA.visitors + variantB.visitors);

    // 결과 판정
    const isSignificant = pValue < this.significanceLevel;
    const sampleSizeReached = (variantA.visitors + variantB.visitors) >=
                              powerAnalysis.requiredSampleSize;

    let recommendedWinner: 'A' | 'B' | 'none' = 'none';
    if (isSignificant && sampleSizeReached) {
      recommendedWinner = pB > pA ? 'B' : 'A';
    }

    return {
      pValue,
      confidenceInterval,
      isSignificant,
      recommendedWinner,
      sampleSizeReached,
      powerAnalysis
    };
  }

  private calculatePowerAnalysis(pA: number, pB: number, currentN: number): PowerAnalysis {
    const effect = Math.abs(pB - pA);
    const pooledP = (pA + pB) / 2;
    const pooledVar = pooledP * (1 - pooledP);

    // 필요 표본 크기 (그룹당)
    const zAlpha = 1.96;  // 95% 신뢰수준
    const zBeta = 0.84;   // 80% 검정력
    const requiredN = 2 * pooledVar * Math.pow(zAlpha + zBeta, 2) /
                      Math.pow(effect, 2);

    // 현재 검정력 계산
    const currentSE = Math.sqrt(2 * pooledVar / (currentN / 2));
    const currentZ = effect / currentSE - zAlpha;
    const currentPower = this.normalCDF(currentZ);

    return {
      requiredSampleSize: Math.ceil(requiredN * 2),
      currentPower,
      minimumDetectableEffect: effect
    };
  }

  // 표준 정규분포 누적분포함수 근사
  private normalCDF(z: number): number {
    const a1 = 0.254829592, a2 = -0.284496736, a3 = 1.421413741;
    const a4 = -1.453152027, a5 = 1.061405429, p = 0.3275911;

    const sign = z < 0 ? -1 : 1;
    z = Math.abs(z) / Math.sqrt(2);

    const t = 1.0 / (1.0 + p * z);
    const y = 1.0 - (((((a5 * t + a4) * t) + a3) * t + a2) * t + a1) * t * Math.exp(-z * z);

    return 0.5 * (1.0 + sign * y);
  }

  // 결과 해석 헬퍼
  interpretResult(result: StatisticalResult): string {
    if (!result.sampleSizeReached) {
      return `표본 크기 부족. 현재 검정력: ${(result.currentPower * 100).toFixed(1)}%. ` +
             `최소 ${result.powerAnalysis.requiredSampleSize}명 필요.`;
    }

    if (!result.isSignificant) {
      return `통계적으로 유의미한 차이 없음 (p=${result.pValue.toFixed(4)}). ` +
             `두 버전 간 실질적 차이가 없을 가능성이 높습니다.`;
    }

    const ci = result.confidenceInterval;
    return `${result.recommendedWinner} 버전 승리 (p=${result.pValue.toFixed(4)}). ` +
           `전환율 차이: ${(ci[0] * 100).toFixed(2)}% ~ ${(ci[1] * 100).toFixed(2)}% (95% 신뢰구간)`;
  }
}

"0.3%p 차이면 큰 거 아닌가요?" PM이 물었습니다. 박시니어 씨가 동전을 꺼냈습니다.

"이 동전을 10번 던져서 6번 앞면이 나왔다고 해봐요. 이 동전이 앞면에 유리하다고 확신할 수 있을까요?" PM이 고개를 저었습니다.

"아니요, 운이 좋았을 수도 있죠." "바로 그거예요. A/B 테스트도 마찬가지입니다.

우연히 발생한 차이일 수도 있어요." 통계적 유의성이란 무엇일까요? 쉽게 말해, "이 결과가 진짜인지 우연인지" 판단하는 도구입니다.

동전 던지기로 다시 설명하면, 10번 중 6번 앞면은 우연일 수 있습니다. 하지만 1000번 중 600번 앞면이 나왔다면?

이건 동전에 뭔가 문제가 있다고 확신할 수 있습니다. 표본 크기가 충분해야 결과를 신뢰할 수 있습니다.

위의 코드에서 핵심 개념들을 살펴보겠습니다. p-value는 "귀무가설이 참일 때 현재 결과가 나올 확률"입니다.

쉽게 말해, "두 버전이 사실은 똑같은데 우연히 이런 차이가 나왔을 확률"입니다. p-value가 0.05보다 작으면 "우연이라고 보기엔 너무 큰 차이"라고 판단합니다.

이게 바로 95% 신뢰수준입니다. **신뢰구간(Confidence Interval)**은 실제 차이가 존재할 범위를 알려줍니다.

예를 들어 "전환율 차이는 0.1%에서 0.5% 사이일 가능성이 95%"라고 해석합니다. 이 구간이 0을 포함하면, 즉 음수에서 양수에 걸쳐 있으면, 실제로는 차이가 없을 수도 있다는 뜻입니다.

**검정력(Power)**도 중요합니다. 검정력은 "실제로 차이가 있을 때 그것을 발견할 확률"입니다.

보통 80% 이상을 목표로 합니다. 검정력이 낮으면 실제 차이를 놓칠 수 있습니다.

위 코드의 calculatePowerAnalysis 메서드가 필요한 표본 크기를 계산합니다. 실무에서는 어떻게 활용할까요?

테스트를 시작하기 전에 사전 분석을 수행합니다. "우리가 감지하고 싶은 최소 효과 크기가 얼마인가?" 예를 들어 전환율이 3%에서 3.3%로 올라가는 것(10% 상대 개선)을 감지하려면 얼마나 많은 표본이 필요한지 계산합니다.

A/B 테스트 도구들, 예를 들어 Google Optimize, Optimizely, VWO 같은 도구들은 이런 통계 계산을 자동으로 해줍니다. 하지만 원리를 이해하고 있어야 결과를 제대로 해석할 수 있습니다.

주의할 점이 있습니다. 조기 종료를 조심하세요.

테스트 시작 후 며칠 만에 결과를 보고 "유의하다!"라고 선언하면 안 됩니다. 데이터가 누적되면서 p-value가 요동칠 수 있습니다.

미리 정한 표본 크기에 도달할 때까지 기다려야 합니다. 다중 비교 문제도 있습니다.

한 테스트에서 10개의 메트릭을 동시에 본다면, 우연히 하나쯤은 유의하게 나올 수 있습니다. 주요 메트릭을 미리 정하고, 그것만 기준으로 판단해야 합니다.

김개발 씨가 계산기를 두드렸습니다. "그러면 저희 테스트는요?

사용자 5000명씩 모았는데요." 박시니어 씨가 코드를 돌려봤습니다. "p-value가 0.12네요.

0.05보다 크니까 아직 유의하지 않아요. 표본이 더 필요하거나, 실제로 차이가 없을 수도 있어요." PM이 한숨을 쉬었습니다.

"아, 기다려야 하는 거군요." 박시니어 씨가 웃었습니다. "네, 하지만 좋은 소식도 있어요.

지금 검정력이 60%니까 표본을 2배로 늘리면 충분히 결과가 나올 거예요."

실전 팁

💡 - 테스트 전에 필요 표본 크기를 계산하고, 그 숫자에 도달할 때까지 기다리세요.

• p-value만 보지 말고 신뢰구간도 확인하세요. 실질적으로 의미 있는 차이인지 판단해야 합니다.
• 하나의 테스트에서 하나의 주요 메트릭만 기준으로 삼으세요. 나머지는 참고용으로만 활용합니다.

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!