데이터·분석

제품을 고칠지 말지 정할 때 쓸 수 있는 근거가 회의실 안의 의견뿐이던 시절이 있었습니다. 누군가 사용자 세 명을 만나고 와서 이 기능이 불편하다고 하면 그게 곧 결론이었고, 다른 사람이 다른 세 명을 만나고 와서 반대로 말하면 결론이 뒤집혔습니다. 어느 쪽도 거짓말을 하지는 않았지만 어느 쪽도 전체를 말하고 있지는 않았습니다.

숫자가 아예 없지는 않았습니다. 서버에는 접속 기록이 쌓였고 결제 시스템에는 거래 내역이 남았습니다. 문제는 그 숫자를 꺼낼 때마다 값이 달라진다는 데 있었습니다. 마케팅이 말하는 이번 달 사용자 12만 명과 개발팀이 말하는 4만 명이 회의에서 부딪히면, 그다음 30분은 제품 이야기가 아니라 누구 숫자가 맞느냐를 가리는 시간이 됐습니다. 한쪽은 페이지를 한 번이라도 연 사람을 셌고 다른 쪽은 로그인한 사람을 셌으니 둘 다 틀리지 않았습니다. 같은 이름을 서로 다른 뜻으로 쓰고 있었을 뿐입니다.

숫자를 꺼내는 일 자체도 매번 사람을 잡아먹었습니다. 지난 분기 기업 고객의 결제액을 지역별로 보고 싶다는 요청 하나에 개발자가 이틀을 썼고, 다음 주에 같은 요청이 조금 다른 형태로 들어오면 또 이틀을 썼습니다. 그렇게 뽑아 준 표가 맞는지 검증하는 사람은 따로 없었습니다.

데이터·분석은 이 세 가지 곤란을 한 분야로 묶어 놓은 것입니다. 무엇을 셀지 미리 합의하고, 셀 수 있게 기록을 남기고, 흩어진 기록을 한곳에 모아 믿을 수 있는 상태로 관리하고, 거기서 뜻을 읽어 내기까지를 따로따로가 아니라 하나의 흐름으로 다룹니다.

데이터·분석 아래 묶인 일은 여덟 갈래입니다. 누가 하는지(역할), 행동을 어떻게 기록으로 남기는지(수집), 그 기록을 어떻게 옮기고 관리하는지(처리), 무엇을 셀지 어떻게 정하는지(지표 설계), 쌓인 것에서 뜻을 어떻게 끌어내는지(분석), 인과를 어떻게 확인하는지(실험), 결과를 조직에 어떻게 놓아 주는지(활용), 데이터로 예측을 어떻게 만드는지(모델)입니다.

역할은 이 분야의 사람을 가르는 갈래입니다. 다섯 자리가 있고, 나뉘는 기준은 데이터가 흐르는 과정 중 어디를 맡느냐입니다.

1. 데이터 분석가 — 이미 쌓인 데이터를 뒤져 질문에 답을 만듭니다. 지난 분기에 이탈이 늘어난 구간이 어디냐는 물음을 받아 숫자로 답하는 자리입니다.
2. 데이터 사이언티스트 — 통계와 모델로 설명과 예측을 만듭니다. 어떤 계정이 석 달 안에 떠날 가능성이 높은지를 과거 기록에서 추정하는 일이 여기 속합니다.
3. 애널리틱스 엔지니어 — 분석가가 바로 꺼내 쓸 수 있게 데이터를 미리 정리해 둡니다. 결제와 가입과 접속 기록을 계정 단위로 합쳐 표 하나로 만들어 두면 같은 계산을 매번 새로 짜지 않아도 됩니다.
4. 머신러닝 엔지니어 — 만들어진 모델을 실제 서비스에 올려 매일 돌아가게 합니다. 모델을 만드는 일과 그 모델이 초당 수백 건의 요청을 받아 내게 만드는 일은 기술이 달라서 자리가 갈립니다.
5. BI 담당자 — 대시보드와 정기 리포트로 현황을 조직에 공유합니다. 분석가가 한 번 답하고 마는 질문을 매주 자동으로 답하게 만들어 두는 자리입니다.

회사가 작을 때는 이 다섯이 한 사람입니다. 사람이 늘 때 가장 먼저 갈라져 나오는 쪽은 애널리틱스 엔지니어입니다. 분석가 셋이 각자 자기 방식으로 매출을 계산하기 시작하면 회의에 매출이 세 개 들어오기 때문입니다.

나머지 일곱 갈래 중 여섯은 한 줄로 이어집니다. 수집에서 시작해 처리를 거쳐 지표가 되고, 분석과 실험으로 뜻이 붙고, 활용에서 사람들 앞에 놓입니다. 앞 단계가 부실하면 뒤 단계를 아무리 정교하게 해도 결과가 틀립니다.

수집은 기록을 남기는 갈래입니다. 이벤트 수집은 사용자가 버튼을 누르거나 화면을 열 때마다 누가 언제 무엇을 했는지를 한 줄로 남겨 둡니다. 이 갈래의 성격은 되돌릴 수 없다는 데서 나옵니다. 지난달에 공유 버튼을 누른 사람이 몇 명인지 알려면 지난달에 이미 그 기록이 남고 있었어야 합니다. 오늘 심으면 오늘부터입니다. 그래서 기능을 만들 때 무엇을 남길지를 함께 정해 둡니다.

처리는 남은 기록을 쓸 수 있는 상태로 만드는 갈래이고 셋으로 나뉩니다. 데이터 파이프라인은 흩어진 원천에서 데이터를 끌어와 형태를 맞추고 한곳으로 옮기는 흐름입니다. 결제는 결제 시스템에, 접속 기록은 서버 로그에, 문의는 고객 문의 도구에 들어 있으니 그대로 두면 같이 볼 수 없습니다. 분석용 데이터 저장소는 그렇게 모은 것을 담아 두는 곳입니다. 서비스가 쓰는 데이터베이스와 따로 두는 이유는, 2년치를 전부 훑는 집계 질의 하나가 도는 동안 사용자 화면까지 같이 느려지면 안 되기 때문입니다. 데이터 품질은 그 안의 값을 믿을 수 있게 지키는 일입니다. 결제 금액 칸이 비어 있는 줄이 섞이거나 같은 사용자가 두 줄로 들어가 있으면 그 위에서 돌린 계산이 전부 조금씩 틀어집니다.

지표 설계는 무엇을 셀지 정하는 갈래입니다. 지표는 현황을 판단하려고 미리 정의해 둔 숫자인데, 이 갈래에서 실제로 하는 일의 대부분은 계산이 아니라 합의입니다. 활성 사용자를 한 번이라도 접속한 사람으로 볼지 문서를 한 건이라도 만든 사람으로 볼지에 따라 같은 달 숫자가 12만과 4만으로 갈립니다. 어느 쪽이 맞는지는 제품이 정합니다.

분석은 쌓인 것에서 뜻을 끌어내는 갈래입니다. 분석 기법에는 가입한 달이 같은 사용자끼리 묶어 시간에 따라 추적하는 방법, 가입부터 결제까지 단계마다 몇 명이 남는지 세는 방법처럼 자주 쓰는 틀이 정리돼 있습니다. 그 틀을 제대로 읽으려면 통계 기초가 함께 필요합니다. 평균과 중앙값 중 무엇을 볼지, 표본이 200명일 때 3퍼센트 차이를 차이라고 불러도 되는지 같은 판단이 여기 걸려 있습니다.

실험은 인과를 확인하는 갈래입니다. 실험은 사용자를 무작위로 반씩 갈라 한쪽에만 바꾼 화면을 보여 주고 결과를 비교합니다. 분석은 이미 벌어진 일에서 함께 움직인 것을 찾아 주지만 무엇이 무엇을 일으켰는지는 말해 주지 않습니다. 가입 첫날 문서를 만든 사람이 오래 남는다는 사실을 알아도, 문서를 만들도록 밀어 주면 오래 남게 되는지는 실제로 갈라서 해 봐야 압니다.

활용은 결과를 조직 앞에 놓아 주는 갈래입니다. 대시보드는 매주 같은 질문에 다시 답하지 않으려고 주요 지표를 한 화면에 모아 둔 것입니다. 잘 만들었는지는 담긴 숫자의 개수가 아니라 그 화면을 보고 나서 할 일이 갈리느냐로 판정합니다. 아무도 행동을 바꾸지 않는 숫자는 자리만 차지합니다.

모델은 데이터로 예측을 만드는 갈래입니다. 머신러닝은 사람이 규칙을 적어 주는 대신 과거 기록에서 규칙을 스스로 찾게 하는 방식이고, 광고성 문서를 걸러 내거나 떠날 것 같은 계정을 미리 골라내는 데 씁니다. 앞의 갈래들이 부실하면 이 갈래는 시작도 못 합니다. 학습에 넣을 재료가 곧 앞에서 모으고 다듬은 데이터이기 때문입니다.

여덟 갈래는 앞뒤로 물려 있습니다. 그래서 대시보드의 숫자가 이상할 때 계산식부터 뜯어보는 것은 대개 순서가 틀렸습니다. 이벤트가 빠졌는지, 파이프라인이 어제 실패했는지, 지표 정의가 지난주에 바뀌었는지를 먼저 봅니다.

"이 숫자 어디서 나온 거예요? 대시보드랑 다른데요."

같은 이름의 지표가 두 군데에서 다른 값으로 나오고 있으니 정의부터 맞추자는 말입니다.

"그건 실험으로 확인하죠. 절반한테만 켜고 2주 보겠습니다."

의견으로 다투는 대신 갈라서 결과를 비교하겠다는 제안입니다.

"이벤트가 안 심겨 있어서 지난달 수치는 못 봅니다."

기록이 남지 않은 행동은 소급해서 셀 수 없다는 뜻입니다.

페이지덱에서는 월요일 오전에 지현이 대시보드를 열고 한 주를 시작합니다. 지난주 신규 가입은 늘었는데 첫 문서를 만든 비율이 떨어져 있으면 그 구간에서 무엇이 바뀌었는지를 태오에게 묻습니다. 새 가입 화면을 배포한 날짜와 숫자가 꺾인 날짜가 겹치면 그때부터는 분석이 아니라 확인 작업입니다.

현우는 같은 화면을 다른 각도로 씁니다. 지난달에 가입 안내 메일 제목을 두 가지로 나눠 보낸 실험이 이번 주에 끝나는데, 메일을 열어 본 비율은 새 제목이 높지만 결제까지 간 비율은 차이가 없습니다. 이대로 제목을 바꿀지는 지현과 함께 정합니다.

데이터를 많이 모아 두면 언젠가 답이 나온다고 여기는 경우가 가장 흔합니다. 저장 비용이 싸졌고 남겨서 손해 볼 일은 없어 보이니 자연스러운 생각입니다. 하지만 답은 데이터의 양이 아니라 질문의 선명함에서 나옵니다. 무엇을 알고 싶은지 정하지 않고 쌓기만 하면, 3년치 기록을 앞에 두고도 이번 달 활성 사용자가 몇 명인지 답하지 못하는 상태가 됩니다. 그 사이 파이프라인은 늘어나고 쓰이지 않는 표가 수백 개 쌓여, 나중에 정작 필요한 질문이 생겼을 때 어느 표를 믿어야 할지부터 막힙니다.

분석을 데이터 조직만의 일로 넘기는 것도 자주 보는 오해입니다. 숫자를 다루는 기술이 필요하니 전담 조직에 맡기는 게 효율적으로 보입니다. 그런데 무엇을 셀지 정하는 일은 제품과 마케팅 쪽이 하지 않으면 아무도 대신해 주지 못합니다. 분석가는 질문에 답하는 사람이지 질문을 지어내는 사람이 아니기 때문입니다. 질문 없이 요청만 넘기면 "데이터 좀 뽑아 주세요"가 반복되고, 받은 표는 열어 보기만 하고 닫힙니다. 결국 분석 조직은 바쁜데 바뀌는 결정은 하나도 없는 상태가 굳어집니다.