2025.11.05 ab test

 

2024.06.27 canary, AB test

과거 피쳐 토글을 활용한 ab 테스트를 구현했다.

다른 회사는 어떻게 구현하는지 살펴본다.

생각해보니 어떻게 구현보다 데이터로 뭘 볼지, 뭘 분석할지가 더 중요한 것 같다.

a/b 테스트 목적에 따라 다르지만.

예로 신규 기능을 배포해 안정적인 기능 배포를 확인하고자 할 때와 가설을 실험할 때의 차이이다.

 

 

생각해볼만한 것은 결국 a/b 그룹을 나눠야하는데, 이때의 레이턴시가 들어갈 수 있다는 것이다.

서비스 기업에서는 이를 줄이는 것이 중요해보인다.

 

 

오늘의집 A/B 실험 플랫폼 구축기 - 오늘의집 블로그

내가 생각한 것 보다 아키텍쳐가 고도화되어있다. 

사용자의 로그를 쌓아서 이를 분석에 활용한다. 

log 적재에는 kafka를 활용하고, kafka connet, stream을 활용한다. 요즘 stream관련 책을 보고 있는데, 지금은 안쓰지만 개념을 어느정도 알고 있으면 활용할 수 있는 날이 올거 같은 느낌이다. 

그만큼 매력적인 기능을 가지고 있다.

 

log만을 위한 서버가 존재하고 이거 kafka로 보내는게 동작인가보다.  하긴 기능과는 분리시키는게 옳은 판단이다.

클라이언트가 호출할 수 있는 로그 서버를 앞에 두고, 로그 서버가 클라이언트로부터 로그를 받아 Kafka에 보내면 Kafka Connect를 통해서 S3로 적재가 됩니다. S3에 적재가 된 로그 데이터는 Hive External Table Format을 따르도록 아래와 같이 Kafka S3 Sink connector에 설정을 해두었습니다.

 

 

 

실험과 기능플래그를 위한 실험플랫폼 구축하기 | 우아한형제들 기술블로그

오늘의 집에서도 실험이라는 도메인을 만들고 상태를 부여할 수 있었는데, 여기도 그렇다.

a/b 테스트에 해당하는 것을 만들고 라이프사이클을 갖는다.

그룹을 나누는 것도 세분화되어있다.

리전이나, 디바이스등이 있다. 이걸로 대상을 제한하고 안에서 a/b로 나누는 행위를 한다.

좋은거 같다. 필터링을 건다는게.

그룹은 모듈러 연산을 통해 나눈다고 이야기한다. 

https://techblog.woowahan.com/9935/

실험 대상에 대한 것은 흥미로운데, 큰 회사의 경우 여러 a/b테스트를 동시다발적으로 진행할 수 있다.

이때 유저 대상이 겹칠 수 있는데, 여기서는 하나의 앞서 나눈 모듈러 연산을 유저 전체를 대상으로 공통적으로 가져가고, 그 결과로 대상 군을 각 실험마다 나눠가지는 방식을 이야기한다.

모든 실험이 동일한 모듈러 연산 규칙을 가져간다면 좋은 생각인거 같다.

 

밑에 더 좋은 내용들이 많은데, 내일 읽어보자.

---

 

 

 

+ 토스의 카나리 배포 찾아보기.

예전에 영상에서 본거 같은데..

 

마틴파울러 피쳐 토글