실험을 더 편하게 설계할 수 있게: 당근 실험플랫폼 이야기

2026년 8월 4일

안녕하세요. 당근 데이터 가치화팀이에요.

저희 팀은 '매일 데이터를 통해 사용자를 위한 의사결정을 해요'라는 비전 아래, 전사 구성원이 데이터로 더 나은 결정을 내릴 수 있도록 인프라와 도구들을 만들고 있어요. 그중 하나가 실험플랫폼이에요. 어떤 안이 더 나은지 A/B 테스트로 검증할 수 있도록, 실험의 설계부터 결과 분석까지 한곳에서 지원하는 사내 플랫폼이죠.

약 3년 전, 100+ 팀원의 의사결정에 영향을 주는 Data Scientist, Decision : 실험플랫폼에서 실험플랫폼이 처음 만들어진 과정을 소개한 적이 있어요. 그때는 누적 실험이 350여 개, 실험 오너가 80여 명 수준이었어요. 지금은 누적 실험 4,600여 개, 실험 오너 280여 명, 활성 도메인도 중고거래·검색·피드·커뮤니티·동네생활·광고·알바·중고차 등 60여 개에 달해요. 월간으로 보면 당시 20개 수준이던 진행 실험이 지금은 290여 개로 약 14배 늘었어요. 규모가 커진 만큼 운영 방식을 어떻게 바꿔야 할지 고민도 점점 커졌어요.

실험이 늘어나며 마주한 두 가지 문제

첫째, 실험 한 사이클을 완료하기까지 너무 오랜 시간이 걸렸어요. 매주 수십 건의 실험이 진행되는 환경인데,지표를 정의하는 데만 1~2시간이 걸렸고, 실험 설계 문서를 쓰고 플랫폼에 등록하는 데 또 시간이 들었어요. 지표 리뷰 과정에서 데이터 가치화팀과 서비스팀 사이에 핑퐁이 여러 번 오갔고, 실험을 빠르게 반복하고 싶은 서비스팀은 데이터 가치화팀의 일정에 묶여 페이스가 끊겼던 거죠.

둘째, 같은 시점에 진행되는 실험들이 서로 간섭하기 시작했어요. 같은 화면에서 UI 실험 두 개가 동시에 돌아가면, 같은 사용자에게 두 변화가 함께 노출돼서 결과가 어느 실험의 효과인지 가려내기 어려워졌어요. 실험을 통한 인과 추론의 토대가 흔들리는 거죠. 사용자 입장에서도 갑자기 너무 많은 것이 한 번에 바뀌면 어색함을 느끼게 되고요.

지난 시간 동안 이 두 문제를 풀려고 많은 걸 바꿔왔는데, 오늘은 그중 실험을 만들고 운영하는 과정이 어떻게 더 편해졌는지를 세 가지 변화로 나눠 이야기해 보려고 해요.

지표를 코드 없이, UI로 --- 지표 정의·등록의 진입장벽을 낮춰 사이클의 첫 병목을 해소했어요.
상호배제 그룹 --- 같은 지면의 실험들이 충돌 없이 동시에 돌아가게 했어요
Experiment MCP --- 실험 한 사이클의 반복 작업을 LLM에게 맡겨 남은 병목을 줄였어요

1. 지표를 코드 없이, UI로

왜 지표 등록이 데이터 가치화팀의 일이 됐을까?

실험에서 지표 정의는 가장 중요하면서도 가장 손이 많이 가는 작업이었어요. 기존에는 지표를 코드로 정의했어요. 보통 세 종류의 파일을 한 세트였는데요. GitHub의 데이터 파이프라인 저장소에 직접 작성해야 했죠. 가장 위에는 지표의 정의(metrics.yaml), 그 사이에는 유저의 행동 정의(subject_events.yaml), 가장 아래에는 실제 데이터 쿼리(events/*.sql)가 있었어요. 양 끝의 두 파일만 잠깐 보여드릴게요.

# metrics.yaml — 지표의 정의
avg_number_of_item_click_per_user:
  description: "1인당 item 평균 클릭수"
  metric_type: "count"
  numerator: click_item
  ...

-- events/click_item.sql — 실제 데이터 쿼리
SELECT
    CAST(user_id AS string) AS user_id,
    ...
FROM `<프로젝트>.<데이터셋>.<테이블>`
WHERE DATE(event_timestamp, '{{ timezone }}')
    BETWEEN '{{ start_date }}' AND '{{ end_date }}'

지표 하나를 추가하려면 보통 이런 흐름을 거쳐야 했어요. YAML과 SQL을 작성해서 PR을 올리고, CI 검사를 통과시키고, 테스트 Airflow에서 결과를 확인하고, 데이터 가치화팀의 리뷰를 거쳐, 머지한 뒤 약 1~2시간 뒤 실험플랫폼에 반영되는 식이었죠.

개발자가 아니라면 YAML 문법은 물론,GitHub PR 흐름 자체가 낯설어요. PM·DA 분들은 시작 단계부터 막혔고, 팀 내 엔지니어에게 요청하거나 지표 등록을 미루게 되는 일이 발생하고 있었죠. 그런데 더 큰 문제는 데이터 가치화팀이 병목이 될 수 있다는 점이었어요. 실험을 진행하는 팀이 늘어날수록 리뷰 대기 시간도 함께 늘어났으니까요.

UI로 옮긴 뒤

위와 같은 어려움을 극복하기 위해 지표 정의와 등록 과정을 실험플랫폼 UI로 옮겼어요.

기존에 진행하던 세 단계(event → subject event → metric)를 한 화면 안에서 진행할 수 있어요. 이미 쌓이고 있는 사용자 이벤트를 그대로 가져와 지표로 활용하거나, 원한다면 새로운 사용자 행동(subject event)을 정의하고 어떤 종류의 지표(count/ratio/sum 등)로 집계할지 정해요. 이렇게 구성한 지표는 버튼 한 번으로 테스트를 실행해서 실제 결과가 어떻게 나오는지, 쿼리에는 문제가 없는지 바로 확인할 수 있고 등록 즉시 실험에서 바로 사용할 수 있어요.

코드 기반에서 1~2시간이 걸리던 일이 이제 몇 분 안에 끝나요. YAML 문법을 몰라도, GitHub PR 흐름을 몰라도, 도메인을 가장 잘 아는 사람이 스스로 지표를 만들 수 있어요.

UI 도입 이후 신규 지표는 모두 코드 없이 UI에서 만들어지고 있어요. 등록 전 별도의 리뷰 과정도 사라졌어요. 각 팀이 지표를 만들고 자체적으로 테스트하며 검증할 수 있는 환경이 되었거든요.

데이터 가치화팀이 더 이상 길목에 있지 않게

가장 큰 변화는 데이터 가치화팀이 모든 지표 등록의 길목에 서 있지 않아도 된다는 점이에요. 각 도메인의 PM·DA·엔지니어가 지표를 직접 정의하고, 데이터 가치화팀은 컨벤션 관리나 품질 점검 같은 더 본질적인 역할에 집중할 수 있게 됐어요. 실험 도중 새로운 가설이 떠올라 지표를 추가해야 할 때도, 서비스팀이 즉시 추가하고 다음 날 결과를 바로 확인할 수 있어요. 실험을 가설 검증의 도구로 쓰려면 빠른 반복이 핵심인데, 그 사이클이 한 단계 짧아진 셈이에요.

2. 충돌 없이 동시에 실험을 돌릴 수 있게 --- 상호배제 그룹

같은 화면에서 두 실험이 만나면

당근에서는 다양한 팀이 동시다발적으로 실험을 진행하고 있어요. 다른 화면, 다른 도메인의 실험이라면 보통은 문제가 없어요. 그런데 같은 화면에서 두 실험이 동시에 돌아가면 실험 해석이 어려워질 수 있어요.

예를 들어 한 화면에서 글자 색을 바꾸는 실험과 배경 색을 바꾸는 실험이 같은 시점에 진행된다고 해볼게요. 각자 따로 보면 의도가 분명해요. 글자 색 실험은 어떤 톤이 더 잘 읽히는지, 배경 색 실험은 어떤 톤이 화면 분위기에 더 잘 맞는지 보려는 거니까요. 그런데 한 사용자가 두 실험에 동시에 노출되면 글자는 A 변형, 배경은 B 변형이 함께 적용되면서 의도하지 않은 조합이 만들어져요. 어두운 배경 위에 어두운 글자처럼 가독성이 떨어지는 화면이 사용자에게 그대로 노출될 수도 있고요. 이때 다음과 같은 문제가 생겨요.

글자 색 실험의 효과가 배경 색 때문인지 헷갈리고, 반대도 마찬가지예요
무작위 배분 덕에 평균 효과 자체가 크게 왜곡되진 않더라도, 측정된 효과가 글자 색 단독의 것인지 배경 색과 만났을 때만 나타나는 것인지 구분할 수 없어서 효과가 과소·과대평가될 수 있어요
사용자 입장에서도 의도치 않은 조합이 함께 적용돼 경험이 어색해질 수 있어요

슬롯 기반으로 사용자를 나누다

위와 같은 문제를 방지하기 위해 실험플랫폼에 상호배제 그룹 기능을 만들었어요. 핵심 아이디어는 아래와 같아요.

1부터 10,000까지의 슬롯 을 정의하고, 사용자를 슬롯에 무작위로 배분해요. 상호배제하고 싶은 실험들에는 서로 다른 슬롯을 할당 해요. 슬롯을 공유하지 않는 두 실험은 상호배제된다

가장 단순한 방법은 실험 하나하나에 직접 슬롯 범위를 지정하는 거예요. 실험 A에는 1~3000번 슬롯, 실험 B에는 3001~6000번 슬롯을 주면, 한 사용자는 둘 중 한 실험에만 노출돼요. 슬롯 배분은 사용자 ID의 해시 값으로 결정되기 때문에 같은 사용자는 언제나 같은 슬롯에 배정돼요.

한 그룹에서 돌리는 실험이 많아지면 그룹 안에 레이어를 두는 방식도 쓸 수 있어요. 레이어에 먼저 슬롯을 배정해 두고, 실험을 레이어에 할당하면 그 안에서 슬롯이 자동으로 분배돼요. 자주 실험을 추가·제거하는 도메인에서는 레이어 단위로 운영하면 슬롯을 매번 다시 조절하지 않아도 돼서 운영이 한결 수월해져요.

이런 레이어링은 저희만 쓰는 방식이 아니에요. 아래 Optimizely 문서의 그림처럼 전체 트래픽을 서로 겹치지 않는 조각으로 나누고 각 실험이 자기 조각의 사용자에게만 노출되게 하는 건, Optimizely나 Statsig 같은 업계 실험 플랫폼들이 공통적으로 채택한 원리예요. 저희의 슬롯과 레이어도 같은 원리 위에 있어요. 출처: https://support.optimizely.com/hc/en-us/articles/4410289064205-Mutually-exclusive-experiments

사례

"실험을 잘게 쪼개서 겹치지 않게 반복하고 싶어요" --- 반복 실험이 많은 도메인은 사용자를 최소 단위로 잘게 나눠 실험 사이의 영향을 분리해야 했어요. 실험플랫폼이 슬롯 기반 분배를 지원하기 전에는 서비스 서버 엔진에서 자체적으로 슬롯을 관리했지만, 지금은 실험플랫폼의 상호배제 그룹으로 옮겨서 여러 실험을 슬롯 충돌 없이 안전하게 진행할 수 있어요.

"성격이 다른 여러 실험을 한 시점에 함께 돌리고 싶어요" --- 결이 다른 실험들을 동시에 운영해야 하는 도메인에서는 다음과 같이 레이어 단위로 슬롯 구조를 정리했어요.

holdout 레이어   10%   (전용 슬롯)
A 레이어         10%   (전용 슬롯)
B 레이어         80%   (남은 슬롯을 C 레이어와 직교로 공유)
C 레이어         80%   (남은 슬롯을 B 레이어와 직교로 공유)

숫자만 보면 합이 100%를 넘어서 오류가 있는 것처럼 보이는데요. holdout(실험을 적용하지 않고 남겨두는 비교용 집단)·A 레이어가 전용 슬롯 20%를 점유하고, 남은 80%의 슬롯 위에서 B·C 레이어가 서로 직교(orthogonal)하게 겹쳐 돌아가는 구조예요. 같은 사용자가 B 레이어의 실험과 C 레이어의 실험에는 동시에 들어갈 수 있지만, 같은 레이어 안의 실험들끼리는 상호배제돼요. B와 C처럼 서로 간섭할 일이 없는 성격의 실험들은 이렇게 겹쳐 돌려서 트래픽을 최대한 활용하고, 간섭할 수 있는 실험들만 같은 레이어에 넣어 분리하는 거죠.

각 레이어가 어떤 슬롯을 점유하는지를 미리 정해 두니, 새 실험을 추가할 때 슬롯 할당으로 머리를 싸맬 일이 줄어들었죠. 도메인 안의 누구든 새 실험을 만들 때 '이 실험은 어느 레이어에 가야 하는가'만 결정하면 되니까, 구성원 사이의 커뮤니케이션 비용도 줄어들었어요.

장점과 한계

이 구조의 장점은 명확해요.

여러 도메인에 걸친 실험도 같은 분배 메커니즘 위에서 안전하게 진행돼요.
새 실험을 추가할 때 매번 코드로 슬롯 충돌을 방지하지 않아도 돼요.
한 사용자가 동시에 여러 실험에 노출되지 않으니, 결과 해석이 깔끔해져요.

물론 한계도 있어요.

슬롯을 나눠 쓰면 그만큼 각 실험에 도달하는 표본 수가 줄어들어요. 슬롯을 10개 실험이 나눠 쓰면 한 실험의 표본 수는 전체의 약 10분의 1이 돼요.
표본 수가 적으면 같은 효과 크기여도 통계적으로 잡아내기 어려워져요.

그래서 모든 실험을 무조건 상호배제 그룹에 넣지는 않아요. 같은 화면을 건드리는 실험들, 결과 해석에 서로 영향을 줄 가능성이 있는 실험들만 그룹에 묶고, 그 외 실험은 자유롭게 트래픽을 활용하도록 운영해요. 줄어든 표본 수의 부담은 분산을 줄여 검정력을 보완하는 CUPED로라는 기법으로 일부 상쇄할 수 있는데, 이 이야기는 다음 글에서 자세히 다룰게요.

3. 실험 한 사이클을 LLM과 함께 --- Experiment MCP

반복되던 한 사이클

지표 등록을 UI로 옮기고 나니, 그 다음에 보인 건 그 앞뒤로 늘어선, 손이 많이 가는 작업들이었어요. 실험 한 사이클은 보통 다음 단계를 거쳐요.

실험 설계 문서를 쓰면서 가설을 정리해요
어떤 지표로 측정할지 결정해요
실험플랫폼에 실험을 등록해요. 이때 대조군·실험군, 상호배제 그룹 적용 여부, CUPED 활성화 여부 같은 설정을 정해요. CUPED는 실험 전 데이터를 활용해 지표의 분산을 줄여서, 같은 표본 수로도 효과를 더 민감하게 잡아내는 기법이에요.
실험이 끝나면 결과 페이지에서 지표별 결과를 읽어요
결과를 정리해서 팀 내에 공유해요

각 단계가 어렵진 않지만, 매번 같은 패턴이 반복됐어요. 그리고 누가 진행하느냐에 따라 산출물의 품질이 달라지기도 했어요. 익숙한 사람은 실험 설계 문서를 30분 만에 작성했지만, 처음 쓰는 사람은 반나절이 걸렸고, 결과 정리도 일관된 양식이 없으니 어떤 실험은 한 줄짜리 슬랙 메시지로 끝나고 어떤 실험은 긴 노션 문서로 정리되는 식이었어요.

도구와 노하우를 열다 --- Experiment MCP와 스킬

이 반복을 자동화하려면 실험플랫폼을 사람이 클릭하는 UI가 아니라 LLM이 호출할 수 있는 도구 로 노출할 필요가 있었어요. 그래서 실험과 지표, 사용자 행동 이벤트를 조회·생성·수정할 수 있는 인터페이스를 MCP(Model Context Protocol) 형태로 묶었어요. 이게 Experiment MCP예요.

Experiment MCP가 있으면 Claude나 Claude Code 같은 LLM 클라이언트가 실험 생성, 지표 등록, allowlist 수정, 결과 지표 조회 같은 작업을 직접 수행해요. 사용자는 자연어로 실험 문서나 가설을 던지고, LLM이 MCP 도구를 차례로 호출해서 실험을 구성해 줘요.

도구만 연 건 아니에요. 그 도구들을 잘 쓰는 분석 노하우도 스킬(skill) 형태로 함께 제공해요. 예를 들어 experiment-followup-analysis 스킬은 Experiment MCP로 실험 정보와 결과를 조회하고, BigQuery MCP로 실험 파이프라인 테이블을 직접 쿼리해서, 파이프라인이 계산해 주는 결과 너머의 심층 후속 분석을 수행해요. 세그먼트별 효과, 시계열 트렌드, novelty effect 확인, 코호트 슬라이싱, subject-level 원본 데이터 확인 같은 커스텀 분석을 "실험 후속분석 해줘" 한마디로 시작할 수 있죠. 이런 스킬 역시 뒤에서 이야기할 에이전트들이 가져다 쓰는 재료가 돼요.

Experiment Agent

Experiment MCP를 활용해 다양한 에이전트를 구성할 수 있어요. 저희 데이터 가치화팀은 모든 팀이 공통으로 쓸 수 있는 기본적인 실험 구성 에이전트를 만들어 두었어요. 실험 문서나 슬랙 스레드를 입력으로 주면 가설을 정리하고, 어떤 지표를 쓸지 제안하고(필요하면 새 지표를 만들고), 실험 등록까지 자연스럽게 이어줘요. 첫 실험을 만들어보는 사람이 어디서 시작해야 할지 막막할 때 가장 먼저 찾을 수 있는 도구예요.

실험에 더 익숙하고 도메인 컨텍스트를 깊이 아는 팀은 자체 에이전트를 구성해서 Experiment MCP를 활용해요. 도메인에서 자주 쓰는 지표·실험 패턴·정책을 에이전트에 미리 담아두면, 매번 같은 맥락을 반복해서 설명하지 않아도 돼요. 예를 들어 피드팀은 도메인의 테이블·이벤트·실험 정책을 모아 둔 분석 스킬을 만들어서, 그 안에서 Experiment MCP와 다른 데이터 MCP들(BigQuery·Event·Superset 등)을 함께 호출해 실험을 빠르게 돌려요. 슬랙 스레드를 입력으로 받는 분석 에이전트를 만들어 결과 해석까지 자동화하는 팀도 있고요. Experiment MCP를 팀 내 워크플로우에 끼워 넣어 실험 생성 자체를 자연어로 수행하는 사례도 늘고 있어요.

각 팀이 에이전트를 빌드할 수 있도록 데이터 가치화팀은 재료를 제공하고, 각 팀이 자기 컨텍스트에 맞게 레시피를 짜는 셈이에요.

짧아지는 리드타임, 높아지는 기본 품질

실험 한 사이클의 리드타임이 짧아졌어요. 실험 문서 작성에서 플랫폼 등록까지 거쳐야 했던 단계와 시간이 크게 줄었어요. 누가 진행하든 문서·등록의 기본 품질이 일정 수준 위로 올라왔고요. 반복 작업이 자동화되면서 남는 시간은 가설 설계 같은 더 본질적인 부분으로 옮겨갔어요.

특히 신규 입사자나 실험을 처음 해보는 분들에게 변화가 컸어요. 예전에는 '실험을 어떻게 시작하는지' 자체가 진입장벽이었지만, 이제는 에이전트와 대화하면서 첫 실험을 만들어봐요.

그리고 앞으로

지금까지 이야기한 세 가지 변화는 모두 실험을 더 편하게 만들고 운영할 수 있게 하기 위한 변화였어요. 앞으로 저희가 보고 있는 방향은 그 연장선이에요.

실험 대상의 정교한 타겟팅 --- 지금은 실험 대상이 주로 트리거 포인트 기반으로 정해지지만, 신규·복귀 유저나 특정 지역, 특정 행동 패턴 같은 더 세밀한 기준으로 실험 대상을 좁힐 수 있다면 작은 그룹의 효과까지 정확하게 측정할 수 있어요. 올해 팀 목표 중 하나로 잡고 있는 방향이에요.
실험 사이클을 한 곳에서 --- 지금은 실험 문서, 결과 정리 같은 산출물이 Notion·Slack 등 여러 도구에 흩어져 있어요. 앞으로는 실험 문서를 실험플랫폼 안에 내재화하는 식으로, 실험 한 사이클이 한 곳에서 자연스럽게 흘러갈 수 있도록 실험플랫폼을 발전시켜 나갈 예정이에요.

마무리

AI 시대에서 데이터 실험은 이제 데이터 가치화팀의 전문 영역이 아니라 도메인을 가장 잘 아는 사람이 직접 설계하고 다루는 일이 됐어요. 지표 등록의 진입장벽이 낮아지고, 동시에 진행되는 실험이 충돌 없이 돌아가고, 한 사이클의 반복 작업이 에이전트로 줄어들면서요.

다음 글에서는 그 실험들의 결과를 더 잘 읽고 해석할 수 있도록 만든 변화를 이어서 이야기해볼게요. 결과 페이지 재설계, LLM 자동 요약, CUPED 이야기 등이 남아있어요.

궁금한 점은 댓글이나 제 링크드인으로 남겨주시면 답변드릴게요!

긴 글 읽어 주셔서 감사해요.

실험을 더 편하게 설계할 수 있게: 당근 실험플랫폼 이야기 was originally published in 당근 기술 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.