분석가가 직접 만든 마케팅 자동화 시스템 — 오디언스 빌더 제작기
여기어때 데이터 분석팀(UB팀)이 개발 경험 없이 AI 에이전트 바이브 코딩으로 마케팅 자동화 시스템 '오디언스 빌더'를 구축한 과정이다. SQL 없이 UI에서 타겟 조건을 설정하면 BigQuery에서 수천만 행 대상자를 추출해 Kafka·S3를 통해 마케팅 도구로 전달하는 파이프라인을 직접 만들어, 캠페인 준비 시간을 2~3일에서 10분으로 단축했다.
요약 이어보기NC Soft 데이터 분석팀(DANBI)이 게임에서 희귀 아이템 획득이 유저의 향후 플레이 변화에 실제로 원인이 되는지 인과 추론 방법론을 통해 분석한 사례다. 단순 상관관계와 인과관계를 구별하는 방법론(confounder, collider, 인과 다이어그램)을 실제 데이터에 적용하는 과정을 상세히 설명한다. 보상-생산성 인과 효과 분석의 게임 데이터 적용 사례로, 방법론 이해와 적용에 초점을 둔다.
핵심 포인트 - 단순 실험군/대조군 비교로는 인과 효과를 증명할 수 없음 — confounder(교란 변수) 제거가 필수 - confounder: 원인·결과 변수에 동시에 영향을 주는 변수 (예: 게임 애착도) - collider: 원인·결과 변수에 동시에 영향을 받는 변수 — 통제하면 오히려 편향 발생 (제외 필수) - 인과 다이어그램(DAG)으로 변수 간 관계를 시각화해 confounder/collider를 체계적으로 판별 - 선형 회귀에 통제 변수를 포함시켜 "다른 조건 동일" 상태에서 원인 변수만의 효과 추정 - 결론: 영웅/전설 등급 획득은 접속 일수·유저 등급 상향에 유의미한 인과 효과 있음 (결제 금액은 미유의)
상세 정리 - 분석 배경: 높은 보상이 생산성에 미치는 영향 (FA 선수 사례 — 보상 후 성적 하락 역설) - 게임 적용: "영웅/전설 등급 전직(영변)" 획득이 이후 플레이 증가에 원인이 되는가 - 연구 설계: 측정 기간 7일, 5개 분석 기간(업데이트 시점 기준), 그룹1(고활동)/그룹2(저활동) 분리 - 역인과 편향 방지: 측정 기간 중 접속한 유저만 대상으로 선정 (접속→획득 역방향 인과 차단) - 통제 변수 후보 9개: 희귀 등급 수, 컬렉션, 스킬, 인챈트, 등급합성, 사망횟수, 계정경과일, 레벨, 총결제액 - DAG step1: 원인·결과 변수에 직접 연결 안 된 엣지의 노드 통제 - DAG step2: 결과 변수에 직접 영향 주는 다른 노드 통제 - DAG step3: collider 식별 → 통제 변수에서 제외 - 접속 일수 회귀모델: 영웅/전설 획득 + 7개 통제 변수 (희귀등급수, 컬렉션, 스킬, 인챈트, 레벨, 총결제액, 사망횟수) - 유저그룹지표(binary): 선형 대신 로지스틱 회귀 사용 - 결과: 5개 기간 모두 접속 일수·유저 등급 상향에 유의미한 양의 인과 효과 확인 — 재현성 검증 완료 - 결제 금액: 통계적으로 유의하지 않음 (획득이 결제를 늘리지는 않음)
왜 읽나: A/B 테스트 없이 관측 데이터만으로 인과 관계를 추론해야 하는 상황에서, confounder·collider 구별과 DAG 기반 통제 변수 선정 프로세스를 실제 게임 데이터 분석 사례로 배울 수 있는 글이다.
여기어때 데이터 분석팀(UB팀)이 개발 경험 없이 AI 에이전트 바이브 코딩으로 마케팅 자동화 시스템 '오디언스 빌더'를 구축한 과정이다. SQL 없이 UI에서 타겟 조건을 설정하면 BigQuery에서 수천만 행 대상자를 추출해 Kafka·S3를 통해 마케팅 도구로 전달하는 파이프라인을 직접 만들어, 캠페인 준비 시간을 2~3일에서 10분으로 단축했다.
요약 이어보기Vercel이 빌드 웜 풀(warm pool) 상태 데이터를 Redis에서 DynamoDB로 마이그레이션한 과정을 다룬다. 빌드 풀의 청구 매핑 데이터가 Redis 장애 시 복구 불가능하다는 구조적 위험이 이주를 결정한 핵심 이유였고, 24/7 프로덕션 트래픽 속에서 다운타임 없이 5단계 점진적 전환을 완료했다.
요약 이어보기채널톡이 DynamoDB 핫 파티션을 해결하려 GSI를 별도 인덱스 테이블로 떼어낸 연재의 마지막 편으로, 조회 경로를 GSI에서 인덱스 테이블로 옮긴 과정을 다룬다. 2편에서 쓰기 파이프라인이 완성돼 WriteThrottleEvents가 월 110만 회에서 0회가 됐지만, 조회 코드가 여전히 GSI를 읽고 있어 GSI를 지울 수 없었다. GSI가 읽기에서 대신해주던 키 해석·정확 일치·삭제 필터·페이지 채우기를 사내 공통 라이브러리의 조회 규칙으로 흡수해, 호출부는 GSI든 인덱스 테이블이든 같은 코드를 쓰게 만들었다.
요약 이어보기