토스플레이스가 대시보드 대신 '주간 지표 리뷰'를 고집하는 이유

토스플레이스 Metric Review

대시보드는 예뻐요. 차트는 올라가고, 숫자는 채워지고, 리포트는 정시에 나옵니다. 근데 제품은 안 움직여요. 토스플레이스 데이터 팀도 같은 벽을 맞았더라고요. "인사이트는 분명히 나왔는데, 왜 실행은 느릴까?" 이 질문에서 시작된 게 Metric Review예요.

토스플레이스 Data Platform Team을 이끄는 박종익 님이 공유한 내용인데, 읽다가 좀 찔렸어요. 분석 조직이 리포트 생산 공장이 되는 건 정말 흔한 일이거든요.

데이터 분석가는 리포트 작성자가 아니다

박종익 님이 오래전부터 품어온 생각이 하나 있었다고 해요. "현상에 대한 통찰은, 현업 매니저분들이 분석 기술만 익힌다면 더 잘할 수 있는 영역이 아닐까?" Data Literacy가 높은 조직이 되려면, 데이터 분석가만 분석하는 구조에서 벗어나야 한다고 믿었다고 합니다. 물론 그 생각에는 항상 "그러면 내 밥그릇은 어떡하지?"라는 걱정이 따라왔다고요. (이 고백이 좋았어요. 보통 이런 말 안 하잖아요.) 그래도 그게 나아가야 할 방향이라는 확신은 변하지 않았다고 합니다.

그래서 토스플레이스 데이터 조직은 구성원 누구나 분석할 수 있는 환경을 만드는 걸 목표로 잡았어요. 사용성 높은 인프라를 구축하고, '분석을 어떻게 해야 하는지'에 대한 방법론을 제시하는 것이 출발점이었습니다. 조직은 크게 두 축으로 돌아가요.

두 팀이 공유하는 목표는 하나. 전사의 데이터 리터러시를 높이는 것이에요. 그리고 개별 분석가에게 요구하는 역량도 세 가지로 정의했습니다.

이 셋이 양적으로도 질적으로도 같이 자라야 진짜 딜리버리가 나온다는 거죠.

데이터 분석가의 세 가지 역량

그 성장의 엔진이 Metric Review라고 합니다. 토스의 핵심 가치 중 'Focus on Impact'가 있는데, Metric Review가 데이터 분석가로서 임팩트에 집중하는 가장 직접적인 방법이라는 거예요.

데이터 분석가가 제품과 사업에 임팩트를 내려면, 조직의 목표와 얼라인된 분석 인사이트를 제공해야 하잖아요. 그 인사이트의 출발은 언제나 '가설'과 '지표'에서 시작합니다. 토스플레이스에서 Metric은 단순한 숫자가 아니라, 구성원들이 같은 목표를 향해 달릴 때 쓰는 공동의 언어라는 설명이었어요. 이 언어를 통해 조직의 목표가 온트랙인지, 위협은 없는지, 기회는 어디 있는지를 발굴하는 거예요.

결국 핵심은 동료들이 최고의 의사결정을 할 수 있도록 인사이트를 제공하는 것. 리포트를 써서 드리는 게 아니라, 지표를 통해 기회와 위협을 발굴하고 실행까지 독려하는 것. 그게 Metric Review를 하는 이유라고요.

OKR에서 Driver Metric까지, 지표가 내려오는 구조

Metric Review가 그냥 "이번 주 지표 봅시다"로 끝나면 월간 회의랑 다를 게 없잖아요. 토스플레이스는 OKR 기법으로 전사와 각 하위 조직의 목표를 정렬합니다. Company 레벨의 Key Result가 Team/Silo의 Key Result로 내려가고, 각 팀의 KR에 대한 레버들이 곧 Driver Metric이 돼요.

Metric Hierarchy

이 구조를 Metric Hierarchy라고 부르는데, 이걸 기반으로 뭐가 기회이고 뭐가 위협인지를 파악하는 거예요. 제품과 사업 개발 사이클은 "목표 설정 → 가설 수립 → 검증 및 실행 → 인사이트 발굴"로 돌아가고, 이걸 분석 사이클에 대입하면 "지표 분석 → 가설 검증 → 인사이트 제시 → 실행 독려"가 됩니다.

분석 사이클

Metric Review 사이클

이 사이클을 돌리는 게 Metric Review의 역할이에요.

매주 안 보면 타이밍을 놓친다

운영에서 가장 중요한 건 뭘까요? 박종익 님은 단호하게 "매주 꾸준히"라고 답했어요. 지표를 월말에 한 번 보는 순간, 설명은 할 수 있지만 실행 타이밍을 잃기 쉽다는 거죠. 주간 리듬을 유지하면 두 가지가 생긴다고요.

매주 꾸준히

여기서 멈추지 않아요. 단순히 지표 등락을 확인하는 것에서 그치지 않고, 가설 기반의 EDA(탐색적 데이터 분석)까지 함께 진행해서 Metric Review에 담아 동료들에게 공유합니다. 인사이트를 제시하고, 실행이 되도록 독려하는 것까지. 이게 토스플레이스 데이터 분석가가 Metric Owner로서 수행하는 역할이에요.

근데 좀 무서운 말이기도 하거든요. 리포트 작성자가 아니라 Metric Owner라는 건, 지표가 안 움직이면 본인 책임이라는 뜻이니까요.

세 팀이 증명한 것 — Growth, POS, SCM

말만으로는 부족하죠. 실제 사례 세 개가 있어요.

Growth Tribe — 같은 지표를 보기 시작했습니다

Growth Tribe는 토스플레이스 매장 수를 늘리는 데 집중하는 조직이에요. Tribe DA가 매주 목표 지표 현황을 공유하고, 현상에 대한 해석까지 리포팅했습니다. 처음에는 "수치를 공유하는 것" 정도로 시작했는데, 꾸준히 반복하니까 변화가 생겼어요.

Growth Tribe Metric Review

디자이너가 제품 구조를 잡을 때 "어떤 지표를 올릴 것인가"를 가설로 세우고 로그 설계 방향성까지 디자인 안에 담기 시작했어요. 서버 개발자는 분석에 용이한 테이블 구조를 DA와 함께 논의하며 만들어갔고, 클라이언트 개발자는 지표화할 수 있는 이벤트 위주로 로그를 개발하게 됐습니다. 읽다가 놀랐어요. 디자이너가 로그 설계까지 생각한다고?

Growth Tribe 결과

PO는 정성적 피드백을, DA는 정량적 성과 측정을 통해 "목표 지표가 온트랙인가"를 다시 Metric Review로 점검하는 루프가 만들어졌고요. 실제로 목표를 달성하는 제품들이 출시되면서 전사 지표까지 함께 개선되는 성과를 냈다고 합니다.

POS Tribe — 군집별로 다르게 처방했습니다

토스플레이스는 직접 매장에 포스를 파는 게 아니라 대리점을 통해 확산하는 구조예요. 그러다 보니 대리점별로 확산 편차가 발생했습니다. POS Tribe DA는 대리점별 군집 분석을 진행했어요. 군집이 나뉘자 PO는 군집별 인터뷰를 진행했고, 정량과 정성의 근거를 기반으로 가설을 세웠습니다.

POS Tribe 군집 분석

같은 문제를 하나의 처방으로 밀지 않고, 군집별 맞춤 액션으로 풀면서 포스 확산 가속화에 기여했다는 거예요. 포스 설치 비율이 낮은 군집에게는 "우리 포스 어렵지 않아요, 꽤 괜찮아요"라는 메시지와 함께 집체 교육과 온보딩 강화로 허들을 낮추고, 이미 높은 군집에게는 매장 생성 및 설치 플로우를 단순화해서 사용성 자체를 개선한 거예요. 정량 데이터로 군집을 나누고, 정성 인터뷰로 각 군집의 맥락을 파악하고, 거기에 맞는 처방을 따로 내린 케이스. 이게 Metric Review가 만들어낸 실행이에요.

SCM — 예측 기반으로 유통을 최적화했습니다

여담인데, 토스플레이스는 소프트웨어만 만드는 게 아니에요. 하드웨어를 직접 제조하고 유통하는 조직이기도 합니다. 그래서 SCM(Supply Chain Management), 즉 유통망 관리가 중요한 영역이에요. 소프트웨어 회사인 줄만 알았는데 하드웨어 유통까지 한다니, 좀 의외였어요.

플레이스 DA는 SCM 팀과 함께 지표를 설정하고 분석했습니다. 구체적으로 보면:

SCM 유통 최적화

이 과정에서 가설 기반 액션 아이템들이 만들어졌고, 전체적인 유통 구조에서의 최적화와 비용 절감에 기여하게 됐다고 합니다. 데이터 분석이 소프트웨어 제품에만 적용되는 게 아니라, 하드웨어 공급망까지 영향을 미치는 거예요.

조직의 언어가 바뀌었다는 건 이런 뜻이다

Metric Review가 꾸준히 쌓이면서 가장 크게 바뀐 건 조직의 언어였다고 해요. 분석가는 리포트 작성자가 아니라 Metric Owner처럼 일하고, 제품 조직은 "무엇을 만들까"보다 "어떤 지표를 움직일까"를 먼저 물어요. 사업 조직은 전략을 정량 근거로 정렬하기 시작했고요.

이런 루프가 누적되면서 데이터 리터러시가 높아지고 있다는 걸 체감한다고요. 지난 상반기에는 전사 Key Result 달성에 의미 있는 기여를 만들었다고 합니다. 6개월 동안 치열하게 고민하고 실행한 결과.

토스플레이스 데이터 조직은 화려한 분석보다 실행으로 연결되는 분석을 더 높게 평가한다고 해요. 문제를 구조화하고, 가설을 검증 가능하게 만들고, 액션과 검증 지표를 끝까지 닫는 것. 여기서 핵심은 "끝까지 닫는 것"이에요. 인사이트를 던져놓고 끝나는 게 아니라, 실행되었는지까지 확인한다는 거잖아요. 솔직히 이게 제일 어려운 부분이에요.

Data Literacy는 결국 데이터 조직의 딜리버리와 깊게 연결되어 있다는 말. 맞아요. 근데 그 딜리버리라는 게 리포트를 잘 쓰는 게 아니라, 지표를 실행으로 바꾸는 거라는 점. 이게 이 글의 핵심이었습니다.