하이퍼커넥트 AI의 A/B 테스트
AI 조직에서는 매일, 그리고 매주 새로운 모델이 만들어집니다. 하지만 새로운 모델이 정말 더 좋은 모델일까요?
많은 AI 연구자들은 오프라인 메트릭의 향상으로 모델의 성능을 판단합니다. 하지만 이는 충분하지 않습니다. 오프라인에서 성능이 향상된 모델이 실제 서비스에 올라갔을 때 오히려 지표가 떨어지는 경우도 적지 않습니다. 그 이유는 명확합니다. 모델을 배포하는 순간 데이터의 분포가 바뀌기 때문입니다. 오프라인에서는 유리했던 환경이, 온라인에서는 전혀 다르게 작용할 수 있습니다. 결국 온라인에서 실제로 지표가 좋아지지 않는다면, 아무리 오프라인에서 잘 작동하더라도 그것은 좋은 모델이라 할 수 없습니다.
그렇다면 온라인에서는 어떻게 ‘좋아졌다’를 검증할 수 있을까요? 가장 단순한 방법은 시계열을 관찰하는 것입니다. 모델을 배포한 뒤 리텐션이나 매출 같은 주요 지표의 변화를 시간에 따라 추적하는 것이죠(예시). 하지만 이 방식은 해석이 어렵습니다. 지표의 변화가 모델 때문인지, 아니면 트래픽 변동, 마케팅, 계절성, 신규 유입 등 외부 요인 때문인지 구분하기 어렵기 때문입니다. 아주 큰 변화가 있었다면 시계열만으로도 구분할 수 있지만, 대부분의 경우 그렇지 않습니다.
이 문제를 해결하는 가장 확실한 방법이 A/B 테스트입니다. 모델의 변경(처치, treatment) 외에도 결과에 영향을 줄 수 있는 수많은 요인들인 혼란 변수(confounder)를 통제하기 위한 실험 설계죠. A/B 테스트는 모델의 변경이 실제로 어떤 변화를 일으켰는지를 명확히 구분해줍니다.
A/B 테스트는 단순히 “이 모델이 좋은가 나쁜가”를 가르는 절차가 아닙니다. 어떤 요인이 지표를 바꿨는지를 해부하고, 거기서 얻은 통찰을 다음 개선으로 연결하기 위한 방법입니다. 모델을 더 잘 만드는 기술적인 방법은 다양하지만, A/B 테스트는 그 변화의 ‘진짜 이유’를 찾아내는 과정입니다. 실험을 통해 쌓인 데이터와 도메인 지식이 결국 더 나은 모델을 만듭니다.
마이크로소프트 등 여러 연구에서도 이런 도메인 지식의 축적을 매우 중요하게 다룹니다. A/B 테스트로부터 얻은 학습이 쌓이면, 어느 순간 큰 성장을 만들어내는 전환점이 온다는 여러 보고가 있습니다. A/B 테스트의 교과서 격인 하마책에서도 이런 사례들을 다루고 있죠. 저희도 비슷한 경험을 하고 있습니다. 그런 성장은 ‘운 좋은 한방’이 아니라, 수많은 실험과 검증이 만들어낸 누적된 결과입니다. “무엇이 변화를 만들었는가”를 명확히 구분해, 가설의 신뢰도를 점진적으로 높여가는 것이 중요합니다.
A/B 테스트는 결국 우리가 진실에 더 가까워지도록 돕는 도구입니다.
새로운 모델을 만들었을 때 가장 먼저 떠오르는 질문은 “이걸 바로 A/B 테스트해도 될까?”입니다. 특히 사용자에게 직접적인 영향을 미치는 AI 시스템이라면, 검증은 반드시 신중해야 합니다. 문제의 중요도가 높을수록 실험의 리스크도 커집니다. 아무리 좋은 아이디어라도 실제 환경에서는 의도와 다르게 작동할 수 있고, 그 결과가 사용자 경험을 크게 해칠 수도 있습니다.
그래서 저희는 A/B 테스트에 들어가기 전에 항상 쉐도우 테스트부터 시작합니다. 쉐도우 테스트는 유저에게는 전혀 영향을 주지 않고, ‘그림자 속에서’ 새로운 모델을 검증하는 방식입니다. 프로덕션과 동일한 트래픽을 새로운 모델에도 흘려보내어 결과를 비교하는 것이죠. 이렇게 하면 사용자에게는 아무런 변화가 없지만, 우리는 두 모델의 추론 결과를 동시에 기록해 성능을 확인할 수 있습니다. 이 방식의 가장 큰 장점은 리스크가 없다는 점입니다. 유저 경험을 전혀 해치지 않으면서도 버그나 문제를 조기에 발견할 수 있습니다. 오프라인 평가와 비교했을 때 메트릭이 일관되게 개선되는지 확인하는 과정으로, 만약 여기서 차이가 크다면 A/B 테스트로 넘어가기 전에 엔지니어링이나 모델 자체에 문제가 없는지를 먼저 점검해야 합니다.
쉐도우 테스트에서 개선 신호가 명확히 확인되면, 그다음 단계로 1% A/B 테스트를 진행합니다. 전체 트래픽의 약 1%만 새로운 모델에 노출해 안정성과 성능을 함께 검증하는 단계입니다. 이 테스트에서는 “확실히 좋아졌다”를 증명하기보다는 “명확히 나쁘지 않다”를 확인하는 데 초점을 둡니다. 모델이 안전하게 동작한다고 판단되면 트래픽을 5%, 20%, 50%로 점진적으로 확장하면서 지표의 변화를 관찰합니다. 이런 과정을 거치면 사용자 경험을 크게 해치지 않으면서도, 새로운 모델이 실제로 긍정적인 변화를 만들어내는지를 빠르고 안정적으로 검증할 수 있습니다. 구조적으로 카나리 테스트와 유사하지만, 단순한 안정성 검증을 넘어 지표가 실제로 나빠지지 않는지를 함께 관찰한다는 점에서 조금 다릅니다.
실험은 언제나 리스크를 동반하지만, 실험을 미루면 배움의 기회를 잃습니다. 쉐도우 테스트와 1% A/B 테스트는 그 사이에서 균형을 잡아줍니다. 빠르게 시도하고, 안전하게 실패하며, 다시 배우는 구조를 만들어줍니다. 저희는 이 과정을 통해 꽤 과감한 실험도 두려워하지 않고 진행할 수 있습니다. 빠르게 움직이되, 무모하지 않게 움직이는 것. 그것이 저희 AI 조직이 실험을 대하는 방식입니다.
A/B 테스트는 모델이 실제로 가치를 주는지를 검증하는 가장 강력한 방법입니다. 하지만 잘못 설계된 실험은 오히려 혼란을 만듭니다. 데이터를 기반으로 올바른 의사결정을 하려면, 실험 자체를 신뢰할 수 있어야 합니다. 그래서 저희는 모델을 개선할 때만큼이나, 실험을 설계할 때에도 신중함을 유지하려 합니다.
A/B 테스트 전에 A/A 테스트는 필수입니다. A/A 테스트는 A/B 테스트가 올바르게 작동하는지 확인하는, 말 그대로 ‘실험의 실험’입니다. 실험군과 대조군에 완전히 동일한 모델과 환경을 배포한 뒤, 양쪽의 주요 지표 분포가 통계적으로 유사한지를 검증합니다. 평균 전환율, 세션 길이, 클릭률 등 핵심 지표를 비교했을 때 유의미한 차이가 없어야 합니다. 만약 A/A 테스트에서조차 실험군이 대조군보다 특정 지표가 일관되게 높게 나타난다면, 플랫폼의 랜덤 배정 로직이나 트래픽 분할 방식에 편향이 있을 가능성이 높습니다. 혹은 표본 크기가 너무 작아 유의성을 검정하기 어려운 경우일 수도 있습니다. 이런 검증을 건너뛰면 이후의 모든 A/B 테스트 결과를 신뢰하기 어렵습니다.
실험군과 대조군의 독립성도 매우 중요합니다. 한쪽의 변화가 다른 쪽에 영향을 미치면 결과가 왜곡됩니다. 서비스의 특성상 완전한 독립을 보장하기 어려운 경우가 종종 있지만, 설계 단계에서 그 영향을 최소화해야 합니다. 실험 단위를 사용자 단위로 잡을지, 세션 단위로 잡을지, 혹은 지역 단위로 잡을지를 명확히 정의하는 것도 이런 이유에서입니다.
Carry-over effect도 주의해야 합니다. 예를 들어 유저 아이디를 단순히 홀짝으로 나눠 홀수 유저 아이디를 실험군, 짝수 유저 아이디를 대조군으로 설정한다고 해봅시다. 그리고 다음 실험도 동일한 방식으로 실험군과 대조군을 할당한다고 해봅시다. 이렇게 하면 다음 실험에서도 같은 사용자가 동일한 그룹에 반복 배정될 수 있습니다. 이전 실험의 잔여 효과가 다음 실험 결과에 섞이게 되는 것이죠. 이런 문제를 해결하기 위해서는 유저 아이디에 해시 함수를 적용해 매 실험이 독립되도록 설계합니다. 이렇게 하면 실험마다 다른 분포로 유저가 배정되어, 이전 실험의 영향을 최소화할 수 있습니다. 이런 편향은 A/A 테스트 단계에서 미리 감지할 수도 있습니다.
실험은 충분히 긴 시간 동안 유지되어야 합니다. 하루이틀의 결과만 보고 결론을 내리면, 새 모델을 처음 본 사용자들이 일시적으로 반응한 효과를 개선으로 착각할 수 있습니다. 또, A/B 테스트는 특정 기간 동안 혼란 변수(confounder)를 통제할 뿐, 그 결과가 다른 시기에도 동일하게 재현된다는 보장은 없습니다. 따라서 최소 일주일 이상 실험을 유지하며, 평일과 주말이 모두 포함된 데이터를 관찰하는 것이 좋습니다. 물론 이런다고 모든 문제가 해결되는 것은 아닙니다. 예를 들어 긴 추석 연휴 기간에 얻은 결과가 추석 이후에도 그대로 유지되리란 보장은 없습니다.
실험 기간과 트래픽 비율은 사전에 명확히 정해야 합니다. “원하는 결과가 나왔을 때 실험을 멈추는 것”은 흔한 실수지만, 이는 p-hacking으로 간주됩니다. 표본 수를 늘려가며 원하는 결과가 나올 때 실험을 종료하면, 우연한 결과를 ‘유의미한 발견’으로 착각할 수 있습니다. 실험 시작 전에 몇 퍼센트의 트래픽을 얼마나 오랜 기간 관찰할지를 정해두는 이유가 바로 여기에 있습니다. 실험의 기대 개선 폭을 설정하면 필요한 샘플 크기가 계산되고, 그에 따라 실험 기간과 노출 비율, 타깃 세그먼트를 결정할 수 있습니다.
검정 방식을 중간에 바꾸는 것도 절대 피해야 합니다. 예를 들어 처음에는 t-test를 사용하다가, p-value가 기대한 수준으로 나오지 않자 다른 검정(예: odds ratio test, Welch test 등)을 반복 적용하는 방식은 타당하지 않습니다. 이런 접근은 “결과가 잘 나올 때까지 시도한다”는 것과 다르지 않으며, 결국 p-value의 의미를 무너뜨립니다. 하나의 실험에서는 하나의 검정 방식을 고정하고, 그 결과를 있는 그대로 해석해야 합니다.
한 번의 실험에서 너무 많은 요인을 동시에 바꾸는 것도 피해야 합니다. 여러 개선안을 한꺼번에 적용하면, 어떤 변화가 결과를 만들었는지 알 수 없습니다. 실험의 본질은 “변화의 원인을 분리하는 것”이기 때문에, 단일 변수를 다루는 것이 원칙입니다. A/B 테스트의 목적은 좋은 모델을 한 번 선택하는 데 있지 않습니다. 어떤 처치가 어떤 결과를 만들어내는지를 학습하고, 매 실험마다 지식을 쌓는 것이 진짜 목적입니다.
A/B 테스트는 결국 “데이터로부터 진실을 드러내는 과정”입니다. 숫자 그 자체보다, 그 숫자를 신뢰할 수 있는 실험을 만드는 일이 더 중요합니다. 그리고 여기서 언급한 주의사항 외에도 실험이 실패하거나 왜곡되는 이유는 훨씬 더 많습니다. 저희는 더 나은 모델을 만드는 만큼, 더 나은 실험을 설계하기 위해서도 계속 고민하고 있습니다.
Q. 한 번에 한개의 A/B 테스트만 해야 하지 않나요?
하이퍼커넥트가 매치 그룹에 인수되기 전에 입사해, 회사에 벌써 6년째 재직하면서 여러 데이터/PM 직군 분들과 협업해왔습니다. 이 과정에서 종종 A/B 테스트를 한번에 하나만 해야 한다고 주장하시는 분들을 종종 만나왔습니다. 그 분들의 레셔널이 무엇인지 잘 알지만, 저는 항상 동시에 여러 실험을 돌려야 한다고 주장해왔습니다. 특히, 아자르 같이 MAU가 큰 서비스에서는 더더욱 동시에 여러 실험들을 돌려야 합니다.
우리는 더 많은 실험을 통해 더 유저를 잘 이해할 수 있습니다. 유저를 더 잘 이해해야 유저에게 더 좋은 경험을 줄 수 있고 이게 장기 매출로 이어집니다. 더 많은 실험을 하기 위해, 동시에 여러 실험이 돌아가는 중첩 실험은 필수적입니다.
이 논문은 Google이 중첩 실험을 어떻게 하고 있는지를 말한 2010년 논문입니다. UI Layer, Search Layer, Ads Layer와 같이 독립일 것으로 추정되는 요소들끼리 Layering을 잘하면 되고, 이렇게 Layering을 잘하고나서 실험 수가 폭발적으로 증가했다고 합니다. 너무나 당연하게도 Google 뿐만 아니라, Microsoft, Booking.com도 여러 중첩 실험을 진행하고 있습니다. 이 외 다른 회사들의 사례도 충분히 쉽게 찾을 수 있습니다.
왜 많은 빅테크 회사들은 중첩 실험을 열심히 할까요?
사실 중첩 실험을 할 때 각 실험끼리 독립이라는 가정이 깨지면, 당연히 실험에 문제가 생깁니다. 한번에 실험을 하나만 돌려야 한다고 주장하시는 분들이 보통 이 점을 지적하십니다. 이론적으로 옳은 지적입니다. 하지만, Microsoft, Google, Statsig를 포함해 많은 회사들에서 실무적으로 중첩되는 대부분의 A/B 테스트는 서로 영향을 주지 않는다고 관찰되어왔습니다. 즉, 독립이란 거죠.
하지만, 당연히 여러 실험들이 항상 서로 독립인 것은 당연히 아닙니다. 독립이 아닌 경우에는 실험 해석에 문제가 당연히 생깁니다. 그렇다고 중첩 실험을 하지 않는 것은 답이 아닙니다. 실험 수를 줄이게 되면, 우리는 실험을 더 많이 할 수록 더 많은 지식을 쌓을 수 있고 제품에 대한 이해를 넓힐 수 있는데 이 기회를 날리게 되는 것이기에 다른 방향의 접근이 필요합니다.
중첩 실험을 하면서 실험끼리 독립이 아닌 경우를 체크하기 위해 Google, Bing 등 여러 회사는 모니터링 시스템을 구축했습니다. 독립 여부를 판단하는 모니터링 알고리즘은 각기 다르지만요. 혹은 Tencent는 독립을 좀 더 잘 보장할 수 있는 assignment 방법론을 운영한다고 발표하기도 했습니다.
이 외에도 중첩 실험을 할 때 주의해야 할 점은 몇 가지 더 있습니다. A/B 테스트의 교과서로 불리는 하마 책에도 중첩 실험의 기본 원칙과 주의점이 소개되어있습니다. 각 회사의 상황에 맞는 best practice는 각자의 상황에서 연구될 필요가 있습니다. 하지만, 실무적으로 중첩 실험을 두려워할 이유는 없습니다. 아주 극단적으로 “모니터링 없이 중첩 실험하기 vs 한 유저에게 단 하나의 실험만 하기” 둘 중 하나 선택하라면 저는 망설이지 않고 전자를 택할겁니다.
하이퍼커넥트 AI는 이와 같은 철학으로 실험 환경을 발전시켜 왔습니다. 저희는 “빠른 실험”과 “안전한 실험”을 동시에 가능하게 하는 플랫폼을 직접 구축했습니다. 실험 설정과 리뷰에 걸리던 시간을 97% 단축한 프레임워크를 통해, 누구나 빠르게 실험을 제안하고 결과를 검증할 수 있게 되었습니다. 실험이 중첩되고 복잡해질수록 각 실험이 충돌 가능성이 높아지지만, 그 위험을 줄이는 건 실험을 멈추는 게 아니라 실험과 실험 플랫폼을 더 잘 설계하는 것이라고 믿습니다.
A/B 테스트의 결과를 해석하는 일은 단순히 숫자를 비교하는 것보다 훨씬 어렵습니다. 같은 실험이라도 세그먼트에 따라 전혀 다른 결과가 나올 수 있고, 평균값만 보고 판단하면 오히려 잘못된 결론을 내릴 수 있습니다. 저희는 실험 결과를 볼 때 항상 “어디에서 차이가 생겼는가”를 먼저 확인합니다. 특정 국가나 OS, 혹은 성별에서 기대와 다른 방향으로 움직였다면, 그 이유를 데이터로 검증하고 새로운 가설을 세웁니다. 실험이 모든 사용자 그룹에 고르게 작동하지 않는다면, 그 결과를 단순히 ‘실패’로 보지 않고, 개선의 단서를 찾는 기회로 봅니다.
무엇보다 중요한 것은 불확실성을 감으로 판단하지 않는 일입니다. 지표의 평균값이 조금 높거나 낮아졌다고 해서 곧바로 개선이라고 결론 내릴 수는 없습니다. 지표의 분산(variance)과 표본의 크기를 함께 봐야 그 차이가 우연인지, 실제 변화인지 알 수 있습니다. 데이터는 언제나 불확실성을 동반합니다. 그렇기 때문에 실험 결과를 신뢰하기 위해서는 그 불확실성을 정량적으로 확인해야 합니다. 단순히 숫자를 비교하기보다, 지표의 “분포”와 변동성을 함께 이해하는 것이 훨씬 중요합니다.
많은 분들이 “p-value가 낮으니 개선됐다”고 말하지만, p-value는 단지 관측된 차이가 우연일 가능성을 보여줄 뿐입니다. p-value가 낮다고 해서 반드시 의미 있는 개선이라고 볼 수는 없습니다. 효과 크기, 분산, 그리고 장기적인 추세를 함께 살펴야 합니다. 특히 효과의 크기가 미미하다면, p-value가 낮아도 그 실험은 실질적인 가치가 없을 수 있습니다. 이런 경우에는 A/A 테스트 결과를 함께 참고하는 것이 큰 도움이 됩니다.
실험에서 자주 마주치는 상황이 있습니다. 어떤 지표는 올랐지만, 다른 지표는 오히려 떨어지는 경우입니다. 예를 들어 1차 지표(클릭률 혹은 전환율)는 개선되었지만, 최종적으로 우리가 올리고자 하는 핵심 지표(리텐션이나 매출)는 변화가 없을 때가 있습니다. 이런 경우엔 단순히 결과를 좋다 나쁘다로 판단하지 않고, 퍼널(funnel) 단계별로 어디에서 변화가 일어났는지를 추적합니다. 그 이유에 대한 가설을 세우고, 이를 확인하기 위한 다음 실험을 설계합니다.
결국 실험 결과를 분석한다는 것은 숫자 뒤의 맥락을 읽는 일입니다. 단순히 승패를 판단하는 것이 아니라, 왜 그런 결과가 나왔는지를 탐구하는 과정입니다. 저희는 모델의 개선뿐 아니라, 그 개선이 사용자 경험과 서비스 목표에 어떤 영향을 주는지를 꾸준히 관찰합니다. 실험은 데이터를 해석하는 도구이자, 우리가 세상을 더 정직하게 이해하기 위한 방법이라고 믿습니다.
하이퍼커넥트 AI 조직은 실험을 하나의 문화로 보고 있습니다. 모델을 개선하는 일은 결국 세상을 관찰하는 일이라고 믿기 때문입니다. 실험이 성공하든 실패하든, 그 안에서 배우는 것이 진짜 진전이라고 생각합니다. 실패한 실험도 낭비가 아니라, 다음 시도를 위한 단서가 됩니다.
A/B 테스트는 단순히 더 나은 모델을 선택하기 위한 절차가 아닙니다. 우리가 더 나은 제품을 만들고, 더 좋은 사용자 경험을 제공하기 위한 과정입니다. 실험을 통해 우리는 “이게 정말 더 나은가?”를 데이터로 확인하고, 그 답을 기반으로 다음 개선을 이어갑니다.
AI가 서비스의 중심이 되어갈수록, 실험은 기술 검증을 넘어 조직의 태도가 되어야 한다고 생각합니다. 좋은 모델을 만드는 것보다 중요한 것은, 그 모델이 세상에서 실제로 어떻게 작동하는지를 끝까지 관찰하는 일입니다. 데이터를 통해 진실을 확인하고, 그 배움을 다음 도전으로 이어가는 것. 그것이 저희가 AI를 다루는 방식입니다.
저희는 더 나은 모델을 만드는 것보다, 더 정확한 세상을 이해하는 데에 가치를 둡니다. 실체적 진실에 다가가는 일. 그것이 결국 더 나은 기술을, 그리고 더 나은 제품을 만들어준다고 믿습니다.