실험 플랫폼 선택: 회고

출처: Towards Data Science

모든 기업이 사람들에게 사랑받는 제품을 출시하고 싶어 할 때, “우리는 더 많이 실험해야 한다”는 이야기가 “우리는 이렇게 실험을 계속할 수 없다”는 현실로 바뀝니다. 손수 조정하는 홀드아웃, 트래픽 할당 티켓이 PM과 엔지니어 사이를 오가고, 분석가들의 일정이 몇 주씩 미리 잡혀 있는 상황이죠. 데이터‑드리븐이 되고자 하는 바람이, 이를 가능하게 해줄 기계보다 커져버린 겁니다.

그때가 바로 우리가 작년 ManyChat에서 있었던 상황이었습니다. 우리는 Eppo를 선택했지만, 그 결정 자체는 이야기의 가장 작은 부분이며, 여러분이 자신의 회사에 가장 쉽게 옮길 수 있는 부분도 아닙니다. 대신 제가 공유하고 싶은 것은 우리가 그곳에 도달하기까지 거친 과정, 그 과정에서 잘못된 점, 그리고 계약서 반대편에서 나를 놀라게 한 점(네, 의사들은 이 트릭 때문에 저를 싫어합니다)입니다.

타이밍에 대한 한 마디

우리는 업계가 매우 흥미로운 순간에 Eppo를 선택했습니다. 평가 중에 공급업체 지도 자체가 급격히 변하고 있었거든요. Eppo는 몇 달 전 Datadog에 인수되었고, Statsig는 최근 OpenAI에 인수된 뒤 나중에 Amplitude에 매각될 예정이었습니다. 아래에 적힌 내용이 그 특정 뉴스 사이클에 의존한다고는 생각하지 않지만, 결정 과정에서 우리의 분위기에 영향을 준 것은 사실입니다.

아래 이야기를 세 단계로 나눠서 설명합니다: 결정 전, 결정 중(결정을 내리는 과정), 그리고 결정 후.

Before

먼저, 모든 일이 일어나기 전 우리 팀의 분위기를 알려드리겠습니다. 입사 초기에 한 엔지니어가 말하길, 동시에 두 개의 실험 기회가 생기면 그의 팀은 두 번째 아이디어를 다음 스프린트로 미룬다고 했습니다. 두 개의 트래픽 할당을 동시에 설정하는 기술적 골칫거리가 너무 커서, 잘못될 위험이 실험에 대한 흥미보다 더 크게 느껴졌기 때문이죠. 말 그대로 속도 저하에 가깝고, 최악의 경우 실험 자체가 사라지는 상황이었습니다. 그리고 그 실험을 위해서는 보일러플레이트 할당 로직을 복사‑붙여넣기 하는 것이 일상이었습니다.

같은 파이프라인을 담당하던 한 분석가는 자신을 “인간 마이크로서비스”라고 소개했습니다. 즉, 손으로 정의하고, 손으로 새로 고치고, 엔지니어에게 전달하는 일련의 홀드아웃 그룹을 직접 관리한다는 뜻이었죠. 직접 체험하는 일인 만큼 흥미로운 경험이었지만, 아이러니하게도 바로 그 순간 플랫폼 도입의 필요성이 구체적인 형태로 다가왔습니다.

몇 년 전 Marktplaats에서 저는 비슷한 고통을 흡수하려는 사내 파이썬 라이브러리를 만들었습니다. 그 결과 인사이트 도출 시간이 며칠에서 몇 시간으로 크게 단축됐습니다(극단적인 경우).

그 뒤 Adevinta에서도 전 세계적으로 빌드‑오어‑바이 논쟁이 다시 일어났고, 결국 직접 구축을 선택했습니다. 다행히 ManyChat에서는 2025년 말까지 플랫폼 제품군이 충분히 성숙해졌고, 우리 규모와 시점에서는 구매가 가장 명확한 선택이었습니다.

우리는 실험 프로그램을 원하는 목표에 가장 가깝게 끌어올릴 수 있는 도구를 원했습니다. 최신 통계 기법도 중요하지만, 더 중요한 것은 기본적으로 결과가 확정적인 실험을 유도하는 도구였습니다. 여기에는 제품 매니저도 포함됩니다.

우리 앞에 놓인 두 가지 문제는 다음과 같습니다.

1. 문제 정의는 했지만, 아직은 일화 수준이었습니다. 리더십은 무엇이 부서졌는지 대략적인 감을 가지고 있었고, 제가 처음 만난 개발자와 제품 매니저도 현재 스택에 대해 불만을 토로했지만, 이것이 공급업체 요구사항 리스트와 같은 구체적인 객체는 아니었습니다. 두 가지를 나란히 놓지 못하면, 어떤 기능이 ‘필수’이고 어떤 것이 ‘선택’인지 판단할 수 없었습니다.

2. 결정의 무게가 컸습니다. 어느 플랫폼을 선택하든 일정 수준의 락인(lock‑in) 효과가 있기 때문이죠—문화적이든 기술적이든. 자원도 한정돼 있었고, 모든 플랫폼을 POC(Proof of Concept)로 검증할 수는 없었습니다. 결정이 잘못되면 다시 뒤로 돌아가야 하는 기회비용도 막대합니다. 결국 하나의 고위험 결정을 여러 개의 저위험 결정으로 나눠서 차근차근 진행해야 했습니다.

인터뷰와 위험 완화

우선 인터뷰부터 시작했습니다. 대상은 PM, 제품 분석가, 엔지니어, 마케터 등 다양했습니다. 목표는 일화를 공급업체 기능 리스트와 비교 가능한 형태로 바꾸는 것이었습니다. 엔지니어의 캘린더 이야기, 분석가의 “인간 마이크로서비스” 개념, 원자 실험을 포기하고 큰 릴리즈에 묶어버린 PM 등은 모두 도구가 가져야 할 직무 설명서가 되었습니다. 이 과정이 나중에 얼마나 큰 도움이 되었는지는 말로 다 할 수 없습니다. 프로세스가 흐트러질 때마다 인터뷰 내용이 우리를 다시 잡아주었고, 조직 내에서 이 작업의 신뢰성을 확보하는 데도 큰 역할을 했습니다. CPO에게 POC를 진행한다는 이야기를 할 때, 구체적인 마찰 지점을 인용할 수 있었기 때문이죠.

단일 문제를 해결하기 위해 우리는 세 단계로 탐색을 진행했습니다.

• Desk research. 공급업체 문서를 읽고 긴 리스트를 작성했습니다. 대부분의 플랫폼은 여기서 스스로 탈락했으며, 이 단계에서도 꽤 많은 Claude Code가 활용되었습니다.

• Demos. 최종 후보에 오른 각 공급업체와 집중적인 대화를 나눴습니다. 약간의 영업 피치가 있었지만, 대부분은 우리가 중요하다고 판단한 영역을 파악하는 것이었습니다.

• POC. 실제 데이터와 실제 평가자를 가지고 두 최종 후보만 손에 잡히게 테스트했습니다.

각 단계마다 후보 수를 좁히면서도 감당할 수 있는 “가격”에 맞는 정보를 얻었습니다. POC 단계에 이르렀을 때는 두 후보만 남았고, 선택지는 Statsig 혹은 Eppo였습니다.

앞으로 어떤 플랫폼을 선택하든 인터뷰가 고통 포인트를 정의한다는 점을 강조하고 싶습니다. 이것이 전체 과정에서 가장 큰 잠금 해제 요소였고, 그 뒤를 이은 것이 스폰서십이었습니다. 단순히 제 상사만을 설득한 것이 아니라, 결정에 동참하고 채택해야 할 동료와 이해관계자를 처음부터 끝까지 계속 참여시켰습니다. POC가 끝날 무렵, 결정이 놀라울 일은 없었습니다.

“Before” 단계가 끝났을 때 우리는 두 후보와 그들을 선정한 기준을 명확히 알게 되었습니다. 이제 남은 질문은 우리에게 실제로 더 나은 선택이 무엇인가? 라는 것이었습니다. “더 나은”을 어떻게 정의하고, 실질적으로 어떻게 합의할 것인가가 남아 있었습니다.

During

POC가 끝