Booking.com은 모든 제품 변경을 A/B 테스트로 감싼다 — 동시에 1,000개 이상 진행 중

Booking.com이 가장 큰 여행 마켓플레이스 중 하나로 성장하면서, 제품 팀은 의견에 따라 기능을 결정할 위험이 있었다. 이 회사는 10년 넘게 온라인 통제 실험을 운영해 왔으며, 제품 관리자뿐 아니라 모든 사람이 아이디어를 저렴하고 안전하게, 그리고 신뢰할 수 있는 데이터로 검증하기를 원했다.

실험을 기본 의사결정 시스템으로 만든다. 버그 수정을 포함한 모든 변경은 A/B 테스트로 감싸서 출시되고, 누구나 실험을 시작하고 이력을 확인하며 해로운 테스트를 중단할 수 있다.

엔지니어들은 과거의 모든 성공과 실패를 검색할 수 있는 저장소, 모집·추적·지표를 위한 범용 API, 두 개의 독립적인 모니터링 파이프라인, A/A 테스트 풀, 그리고 사전 등록과 성공 사례의 동료 검토 같은 안전장치를 갖춘 사내 실험 플랫폼을 구축했다. 모든 부서에 전담 지원 팀이 배정되어 누구나 실험을 처음부터 끝까지 직접 담당할 수 있었다.

모바일 앱, 호텔리어 도구, 고객 서비스 전화선, 내부 시스템 전반에 걸쳐 1,000개 이상의 실험이 동시에 진행된다. 모든 재설계, 인프라 변경, 버그 수정이 테스트로 감싸지므로 제품 결정은 의견에서 증거로 옮겨갔고, 학습 내용은 팀 간에 재사용된다.

Booking.com에서 실험은 일부 팀이 사용하는 도구가 아니라 회사가 결정을 내리는 방식이다. 10년 넘게 이 여행 플랫폼은 증거 기반 제품 개발을 해왔으며, 2017년까지 각 부서는 어느 하루든 모바일 앱, 호텔리어 도구, 고객 서비스 전화선, 내부 시스템 전반에 걸쳐 1,000개 이상의 동시 실험을 운영하고 분석하고 있었다.

의도된 선택은 민주화였다. 실험 플랫폼은 최초의 실험 이래 모든 성공과 실패를 검색할 수 있는 저장소 역할을 하므로 누구나 이력을 참고하고 새로운 가설을 세울 수 있다. 범용 API는 모집, 무작위화, 보고를 추상화하며, 각 부서에는 전담 지원 팀이 있어 테스트 실행에 제품 관리의 허가가 필요하지 않다.

신뢰는 엔지니어링 규율에서 나왔다. 별도로 유지되는 두 파이프라인이 동일한 지표를 계산하고 서로 대조하여 모니터링되며, A/A 실험 풀이 통계를 검증하고, 사전 등록과 성공 사례의 동료 검토 같은 안전장치가 p-해킹을 억제한다. 회사 내 모든 사람은 해로운 실험을 스스로 중단할 권한을 가진다.

그 결과는 엔지니어들이 2017년 논문에서 쓴 것처럼 '전체 재설계와 인프라 변경부터 버그 수정까지 모든 변경이 실험으로 감싸지는' 회사가 되었다. 이는 제품 개발을 일련의 의견이 아니라 측정된 베팅의 흐름으로 바꾸었다.

실험의 분산화는 수천 명이 제품 관리자가 우선순위를 정해주기를 기다리는 대신 아이디어를 테스트할 수 있게 했다.

성공과 실패의 검색 가능한 이력은 팀이 서로의 학습을 다시 찾아보고 그 위에 쌓을 수 있게 한다.

신뢰할 수 있는 인프라(이중 파이프라인, A/A 풀, 사전 등록)는 증거를 의사결정의 결정자로 받아들일 수 있게 했다.

실험 플랫폼을 비즈니스 로직과 느슨하게 결합한 덕분에, 승리한 변경을 출시하는 일은 API 호출 하나를 제거하는 것만큼 간단해졌다.

누구나 해로운 실험을 중단할 수 있는 권한은 속도와 안전성을 양립시켰다.

모두가 저렴하고 안전한 실험을 실행할 수 있다면 의견에 대한 합의는 필요 없다. 인프라와 증거 문화가 결정을 테스트로, 실패를 공유되고 검색 가능한 학습으로 바꾼다.

2000년대 중반 암스테르담 엔지니어들이 작성한 사내 프레임워크는 확장되었지만 다시 작성된 적은 없다. 2026년 Silicon Canals는 Booking.com이 여전히 실제 운영 중인 예약 페이지에서 1,000개 이상의 동시 테스트와 연간 수만 건의 누적 실험을 운영하며, 0.1%의 전환율 변화가 여덟 자리 수 금액에 해당한다고 보도했다. 이 패턴은 '실험 문화'로 업계 전반에 퍼졌다. 벤더 플랫폼, 공개 플레이북, 다른 기술 기업들이 Booking.com이 개척한 동일한 기본-테스트 모델을 채택했다.