pile·
DB / 데이터·너드팩토리너드팩토리·

(1) 평균을 비교하는 A/B 테스트

A/B 테스트와 통계 시리즈 1편으로, 두 안의 평균을 비교하는 A/B 테스트에 필요한 최소 통계 지식을 정리한다. 관측된 평균을 그냥 비교하는 것이 아니라 통계적 가설검정으로 전체 집단에 일반화할 수 있는지 확인해야 한다는 게 요지다.

핵심 포인트
  • A/B 테스트는 전환율이나 클릭률 같은 지표에서 두 안의 평균을 비교한다. 기간 전체 평균을 볼지 일 평균을 볼지는 기획자가 세운 가설에 따라 달라진다.
  • 관측된 평균값을 단순 비교하는 것은 위험하다. 그 데이터가 전체 집단을 대표한다고 확신할 수 없기 때문이다.
  • 그래서 일부 데이터로 전체 집단을 추정하는 통계적 추론을 거친다. 두 집단은 t-test, 셋 이상은 ANOVA 로 비교한다.
  • 결과 판단은 p 값으로 한다. 통상 0.05 이하면 통계적으로 유의하다고 보고 평균이 더 높은 안을 채택한다.
  • 다만 0.05 를 경계로 유의와 비유의를 가르는 이분법은 학계에서도 논란이라 융통성 있게 해석하라고 권한다.
상세 정리
  • 저자는 세탁세제가 식물 성장에 미치는 영향을 본 초등학교 방학숙제를 자신의 첫 A/B 테스트로 든다. 가설이 있었고 두 안이 있었고 베란다라는 통제된 조건까지 갖췄다는 것이다.
  • 그 실험의 결론은 눈에 띄는 차이가 없었다는 것이었는데, 정량 분석을 했다면 결과가 달랐을지 모른다는 데서 글이 출발한다.
  • 문제의식은 A/B 테스트가 통계 분석에 기반한다는 사실 자체를 모른 채, 색이나 위치만 바꿔 전환율이 높은 쪽을 고르는 방식으로 쓰인다는 점이다.
  • 일반화의 위험은 100개 팀 중 A팀에서 30대의 하루 평균 운동량이 20대보다 많다고 회사 전체가 그렇다고 말할 수 있느냐는 예로 설명한다.
  • 절차는 가설 수립, 실험을 통한 데이터 수집, 통계 분석을 통한 전체 집단 추론, 가설 평가 순이다.
  • p 값이 0.06 에서 0.1 정도면 유의하지는 않아도 두 집단 간 차이가 어느 정도 있다고 보고 한 안을 고를 근거로 삼을 수 있다고 본다. 0.3 이상이면 유의하지 않은 것으로 정리한다.
  • 시리즈는 통계적 오류 없이 A/B 테스트하기, 평균 통계가 주는 함정 편으로 이어진다.
왜 읽나A/B 테스트를 돌리면서 p 값 해석에 자신이 없던 기획자와 개발자에게 가설검정 절차와 유의성의 의미를 최소한으로 정리해주는 입문 글.
너드팩토리
너드팩토리 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. DB / 데이터·여기어때 (GC컴퍼니)여기어때 (GC컴퍼니)·

    분석가가 직접 만든 마케팅 자동화 시스템 — 오디언스 빌더 제작기

    여기어때 데이터 분석팀(UB팀)이 개발 경험 없이 AI 에이전트 바이브 코딩으로 마케팅 자동화 시스템 '오디언스 빌더'를 구축한 과정이다. SQL 없이 UI에서 타겟 조건을 설정하면 BigQuery에서 수천만 행 대상자를 추출해 Kafka·S3를 통해 마케팅 도구로 전달하는 파이프라인을 직접 만들어, 캠페인 준비 시간을 2~3일에서 10분으로 단축했다.

    요약 이어보기
    #data-pipeline#kafka#postgres+2
  2. DB / 데이터·vercel-blogVercel Blog·

    모든 Vercel 빌드를 지탱하는 데이터베이스 마이그레이션 이야기

    Vercel이 빌드 웜 풀(warm pool) 상태 데이터를 Redis에서 DynamoDB로 마이그레이션한 과정을 다룬다. 빌드 풀의 청구 매핑 데이터가 Redis 장애 시 복구 불가능하다는 구조적 위험이 이주를 결정한 핵심 이유였고, 24/7 프로덕션 트래픽 속에서 다운타임 없이 5단계 점진적 전환을 완료했다.

    요약 이어보기
    #database-migration#zero-downtime#redis+2
  3. DB / 데이터·channel-talk채널톡·

    DynamoDB 핫 파티션을 해결하는 3가지 방법 (3): 조회를 인덱스 테이블로 옮기기

    채널톡이 DynamoDB 핫 파티션을 해결하려 GSI를 별도 인덱스 테이블로 떼어낸 연재의 마지막 편으로, 조회 경로를 GSI에서 인덱스 테이블로 옮긴 과정을 다룬다. 2편에서 쓰기 파이프라인이 완성돼 WriteThrottleEvents가 월 110만 회에서 0회가 됐지만, 조회 코드가 여전히 GSI를 읽고 있어 GSI를 지울 수 없었다. GSI가 읽기에서 대신해주던 키 해석·정확 일치·삭제 필터·페이지 채우기를 사내 공통 라이브러리의 조회 규칙으로 흡수해, 호출부는 GSI든 인덱스 테이블이든 같은 코드를 쓰게 만들었다.

    요약 이어보기
    #migration#dynamodb#hot-partition+5