데이터 문해력: 기법에 집착하지 마라

들어가며

결론부터 말하면, 해결 방안은 문제가 아니라 원인에 대고 내야 한다. 원인은 “왜?”를 반복해서 찾는다. 5 why 기법은 이 반복을 절차로 만든 것이다. 『데이터 문해력』 5장 “기법에 집착하지 마라”는 분석 기법보다 먼저 갖춰야 할 힘으로 전체 구성력을 든다. 개별 데이터와 분석을 하나의 스토리(논리)로 엮어 결론의 설득력을 높이는 힘이다.

2장 정리에서는 문제를 정의하는 법을, 4장 정리에서는 데이터로 원인을 찾는 순서를 다뤘다. 5장은 이 둘을 하나로 묶는 장이다. 책이 정리한 문제 해결 프로세스는 세 칸이다.

문제 → 원인 → 해결 방안

이 글은 5장을 세 부분으로 나눠 정리한다.

1. 원인을 건너뛰는 “방법맨”은 왜 늘어나는가
2. 방법맨이 되는 구조: “생각한다”의 두 가지 의미
3. “왜?”를 몇 번이나 반복해야 하는가

각 부분에 빅테크의 실제 사례를 붙였다. 사례는 실적 발표 원고, 공식 블로그, 주주서한 같은 1차 출처에서 확인한 것만 골랐다. 마지막에는 내 블로그의 DAU 문제에 5장의 방법을 대 봤다.

원인을 건너뛰는 ‘방법맨’

누구나 하는 실수: 곧바로 해결 방안으로 달려든다

책이 말하는 “방법맨”은 분석 방법이나 해결 방안부터 찾는 사람이다. 책의 예시는 “우리 도시의 인구 문제”다.

대부분은 정보를 모아 현재 상태를 파악하는 데서 시작한다. 여기까지는 괜찮다. 그런데 그다음에 바로 인구 감소를 완화할 대응 방안을 고민한다. 행사 건수를 늘리고, 규모를 키우고, 다른 지역에도 적극적으로 홍보하자는 아이디어가 나온다.

책은 여기서 묻는다. 이게 정말 “데이터 기반”인가? 데이터로 확인한 내용이 제안한 방안과 직접 관계가 있는가? 참신한 아이디어만 내면 되는 거라면 애초에 데이터는 필요 없다.

해결 방안은 원인에 적용한다

해결 방안으로 뛰어들기 전에 먼저 할 일은 원인 분석이다. 그리고 원인을 분석하려면 그 전에 문제가 제대로 정의돼 있어야 한다. 책의 핵심 문장은 이것이다.

해결 방안은 문제에 직접 적용하는 것이 아니라, 문제를 일으키고 있는 원인에 적용한다.

책은 데이터를 써도 결과가 아쉬운 이유가 데이터 활용이나 분석 내용에 있지 않다고 본다. 적절한 사고 과정을 밟지 않았기 때문이다. 기법을 아무리 잘 써도 순서가 틀리면 결론이 틀린다.

사례: Snapchat 2018 리디자인 뒤 DAU가 두 분기 연속 줄었다

Snap은 2018년 초 앱을 크게 바꿨다. 친구의 스토리와 채팅을 한 화면에 모으고, 크리에이터 콘텐츠는 다른 화면으로 분리했다. Evan Spiegel은 1분기 실적 발표에서 이 설계가 “친구와 전문 크리에이터를 분리하는 것이 중요하다는 근본적인 믿음(fundamental belief)“에서 나왔다고 설명했다(Snap Q1 2018 실적 발표 원고, 2018-05-01).

결과는 이랬다. 같은 원고들 기준으로 DAU는 다음과 같이 움직였다.

회사는 2분기 감소의 이유를 “리디자인이 만든 혼란 때문에 사용 빈도가 조금 낮아진 것”이라고 밝혔다(Snap Q2 2018 원고, 2018-08-07). Spiegel은 1분기에 이미 “친구와 대화하기와 친구의 스토리 보기, 이 두 가지 행동을 동시에 최적화하는 게 얼마나 어려운지 몰랐다”고 말했다. 3분기에는 리디자인이 핵심인 커뮤니케이션 기능에 타격을 줬다고 인정했다(Snap Q3 2018 원고, 2018-10-25).

출시 전에 Snap이 어떤 원인 분석을 했는지는 공개된 자료로는 알 수 없다. 다만 회사가 밝힌 출발점은 데이터로 확인한 원인이 아니라 “믿음”이었다. 그리고 해결 방안이 건드린 것은 사용자가 하루에 가장 많이 하던 행동이었다. 5장의 표현을 빌리면, 무엇이 결정 요인인지 확인하기 전에 무엇을 할지부터 정한 셈이다.

사례: Duolingo는 다른 앱의 성공 기능을 가져왔지만 효과가 없었다

Duolingo의 전 CPO Jorge Mazal은 2018년 무렵의 시행착오를 이렇게 회고했다(Lenny’s Newsletter, 2023-02-28). 성장이 둔해지자 팀은 다른 앱에서 잘된 기능을 가져왔다. 모바일 게임 Gardenscapes의 이동 횟수 제한(moves counter)을 그대로 들여왔지만 결과는 “완전히 중립”이었다. 리텐션도 DAU도 그대로였다. Uber식 친구 추천 프로그램을 만들었을 때는 신규 사용자가 3%밖에 늘지 않았다.

Mazal의 진단은 이렇다. “다른 제품의 성공한 기능을 빌려 왔지만, 잘못된 방식으로 빌려 왔다.” 그 기능이 다른 앱에서 통한 원인과 Duolingo의 문제를 만든 원인이 같은지 확인하지 않았다는 뜻이다. 이 팀이 그다음에 무엇을 바꿨는지는 아래에서 이어서 다룬다.

방법맨이 되는 구조: ‘생각한다’의 두 가지 의미

창의적으로 생각하기와 논리적으로 생각하기

책은 “생각한다”에 두 가지 의미가 있다고 짚는다.

1. 풍부한 창의성으로 혁신적인 아이디어를 떠올린다.
2. 논리적으로 꾸준히 사물이나 현상의 원리를 따진다.

방법맨은 첫 번째만 “생각”이라고 여긴다. 아이디어를 내는 일은 눈에 띄고 성과처럼 보인다. 반면 원인을 따지는 일은 시간이 걸리고 겉으로는 진척이 없어 보인다. 그래서 프로세스를 잊어버리기 쉽다.

책이 제시하는 순서는 분명하다. 아래 두 가지를 먼저 확실히 한다.

• 무엇을 해결·실현하려 하는가 (목적·문제)
• 무엇이 결정 요인인가 (원인)

그다음에야 무엇을 해야 하는가(해결 방안)로 넘어간다.

평가 기준이 애매하면 아이디어가 이긴다

책은 방법맨이 늘어나는 이유로 평가 기준이 애매하다는 점도 든다. 결과물을 “얼마나 참신한가”로 평가하는 조직에서는 원인을 건너뛴 아이디어가 이긴다. 전체 논리가 얼마나 탄탄한지를 평가 기준으로 삼지 않으면, 논리적으로 생각하는 것이 얼마나 중요한지 인식하기 어렵다.

그래서 스스로 물어봐야 한다. 지금 내가 하는 “생각”은 어느 쪽인가?

사례: Amazon은 슬라이드 대신 6쪽짜리 서술형 문서를 쓴다

논리를 평가 기준으로 만든 대표적인 조직이 Amazon이다. Jeff Bezos는 2017년 주주서한에서 이렇게 썼다(Amazon 2017 Letter to Shareholders, 2018-04-18).

Amazon에서는 파워포인트(나 슬라이드 형식의) 발표를 하지 않는다. 대신 서술형 구조의 6쪽짜리 메모를 쓴다. 회의를 시작할 때 일종의 “자습 시간”처럼 모두가 조용히 메모를 읽는다.

슬라이드는 글머리표 몇 개로 아이디어를 나열해도 그럴듯해 보인다. 서술형 문서는 문장과 문장이 이어져야 해서, 문제에서 원인으로, 원인에서 해결 방안으로 가는 연결이 비면 바로 드러난다. Bezos는 같은 서한에서 좋은 메모를 하루 이틀에 쓸 수 있다고 생각하는 것이 착각이며, 실제로는 일주일 이상 걸릴 수 있다고 덧붙였다.

제품 기획에서는 Working Backwards라는 방식을 쓴다. CTO Werner Vogels는 이를 “고객에서 출발해 거꾸로 거슬러 올라가, 달성하려는 것을 만족시키는 최소한의 기술 요구 사항에 이르는 과정”이라고 설명했다(All Things Distributed, 2006-11-01). 기능 아이디어가 아니라 고객의 문제가 출발점이다. 전직 임원 Colin Bryar와 Bill Carr는 이 과정에서 쓰는 보도자료·FAQ(PR/FAQ) 문서를 검토할 때 임원들이 흔히 하는 질문이 “그래서 뭐?(so what?)”라고 소개했다(About Amazon, 2021-02-09). 기능이 고객의 어떤 문제를 푸는지 설명하지 못하면 통과하지 못한다.

‘왜(원인)’ 그런지 끈질기게 생각하라

지금 생각하는 것이 문제인가, 원인인가, 해결 방안인가

5장 마지막 절의 첫 번째 조언은 간단하다. 지금 내가 생각하는 것이 문제인지, 원인인지, 해결 방안인지 스스로 구분하라는 것이다. 회의에서 “DAU가 줄었다”, “업로드가 줄었다”, “알림을 더 보내자”가 한꺼번에 나오면, 세 문장은 서로 다른 칸에 속한다. 칸을 구분하지 않으면 원인을 하나 찾자마자 해결 방안으로 넘어가 버린다.

원인의 구조는 단순하지 않다

원인은 한 겹이 아니다. “어째서?”, “왜?”를 반복해 더 본질적인 원인까지 파고들어야 정확하고 밀도 있는 해결 방안을 낼 수 있다.

책을 읽으며 내 블로그로 예를 들어 봤다. 블로그의 DAU가 줄었다고 하자.

• DAU가 줄었다. 왜? 글 업로드 수가 줄었다.
• 업로드 수가 왜 줄었나? 내가 다쳐서 한동안 글을 못 썼다.
• DAU가 줄었다. 왜? 유저의 클릭 수가 줄었다.
• 클릭 수가 왜 줄었나? 글의 퀄리티가 떨어졌다.

한 문제에서도 원인이 여러 갈래로 나뉘고, 갈래마다 “왜?”를 다시 물어야 한다. 그런데 여기서 멈추면 해결 방안이 “다치지 말자”, “잘 쓰자”가 된다. 행동으로 옮길 수 없는 답이다. 아래 그림은 같은 예를 한두 번 더 파고들어 본 것이다.

5 why 기법: 토요타에서 Amazon까지

“왜?”를 반복하는 방법을 절차로 만든 것이 5 why 기법(5 Whys)이다. 원조는 토요타 생산 방식을 만든 오노 다이이치다. 토요타 공식 자료에 따르면 오노는 “선입견 없이 생산 현장을 관찰하라. 모든 일에 대해 ‘왜’를 다섯 번 물어라”라고 조언했다(Toyota Traditions, 2006-03, 보관본). 같은 자료에 실린 용접 로봇 예시는 이렇다.

1. 로봇이 왜 멈췄나? 회로에 과부하가 걸려 퓨즈가 끊어졌다.
2. 회로에 왜 과부하가 걸렸나? 베어링에 윤활유가 부족해 베어링이 걸렸다.
3. 윤활유가 왜 부족했나? 로봇의 오일 펌프가 기름을 충분히 순환시키지 못했다.
4. 펌프가 왜 기름을 충분히 순환시키지 못했나? 펌프 흡입구가 금속 부스러기로 막혔다.
5. 흡입구가 왜 금속 부스러기로 막혔나? 펌프에 필터가 없었다.

1단계에서 멈추면 해결 방안은 “퓨즈를 갈자”다. 5단계까지 가면 “필터를 달자”가 된다. 퓨즈를 갈면 로봇은 다시 돌지만 언젠가 또 멈춘다. 오노는 “어떤 문제든 근본 원인이 오래가는 해결책의 열쇠”라고 말했다. 그리고 이 말도 남겼다. “제조에서 데이터는 물론 중요하다. 하지만 나는 사실을 가장 중시한다.” 데이터 문해력 책이 말하려는 것과 같은 이야기다. 데이터는 사실을 확인하는 도구이지, 생각을 대신하지 않는다.

Amazon은 장애가 나면 COE(Correction of Error) 문서를 쓰고, 근본 원인을 찾는 도구로 5 why 기법을 쓴다. AWS는 “Amazon에서 근본 원인을 찾는 메커니즘을 ‘5 Whys’라고 부른다”고 설명한다(AWS Cloud Operations Blog, 2022-02-18). 이 글에는 원칙이 두 가지 더 나온다.

• 사람이 아니라 이유를 찾는다. 5 why 기법은 “누가”를 탓하지 않고 “왜”를 찾는 방식으로 써야 한다.
• “사람의 실수”에서 멈추지 않는다. 근본 원인 분석에서 “사람의 실수”가 원인으로 나왔다면 확인 장치나 안전장치가 없다는 신호일 수 있다. 그 실수가 왜 가능했는지 다시 물어야 한다.

AWS가 공개한 COE 예시 문서(AWS Cloud Operations Blog, 2023-11-06)는 “애플리케이션이 왜 멈췄나?”에서 시작해 여섯 번째 “왜?”에서 “오류 처리 코드를 요구하는 개발 정책이 없었다”에 이른다. 해결 방안은 버그 수정이 아니라 “오류 처리 코드를 의무화하도록 개발 정책을 바꾼다”였다. 원인이 코드에서 프로세스로 한 단계 올라갔고, 해결 방안도 그 높이에서 나왔다.

얼마나 ‘왜?‘를 반복하면 될까

5 why 기법의 “5”는 정해진 횟수가 아니다. AWS 예시도 여섯 번을 물었다. 책의 기준은 횟수가 아니라 상태다. 원인이 명확하게 규명될 때까지 반복한다. 앞의 내 블로그 예라면 “다쳐서”에서 멈추지 않고, “초안이 없다”처럼 무엇을 할 수 있는지가 보이는 원인에 닿을 때까지다.

해결 방안을 고민하는 것은 마지막 단계다. “왜?”를 묻는 도중에 좋은 아이디어가 떠올라도, 일단 적어 두고 원인 규명을 끝낸 뒤에 꺼낸다.

사례: Duolingo는 DAU를 쪼개서 진짜 레버를 찾았다

앞에서 다른 앱의 기능을 가져왔다가 효과를 못 본 Duolingo는 접근을 바꿨다. 출발점은 문제 정의였다. Duolingo 공식 블로그는 “2018년, 몇 년간 강한 성장을 이어 온 뒤 DAU가 정체됐다”고 적었다(Duolingo Blog, 2023-02-17).

다음은 원인이었다. 팀은 “DAU라는 덩어리를 더 작고 의미 있는(그리고 최적화하기 쉬운) 단위로 어떻게 쪼갤 수 있을까”를 물었다. 사용자를 일곱 가지 상태로 겹치지도 빠지지도 않게(MECE) 나누고, 상태 사이의 이동률이 DAU에 미치는 영향을 시뮬레이션했다. 그 결과 현재 사용자 유지율(CURR, Current User Retention Rate)이 DAU에 미치는 영향이 두 번째로 큰 지표의 5배였다(Lenny’s Newsletter, 2023-02-28).

해결 방안은 마지막이었다. CURR를 북극성 지표로 삼는 리텐션 팀을 만들었고, 리더보드 같은 기능을 CURR 기준으로 실험했다. Mazal에 따르면 CURR는 21% 올랐고, 다른 시도들과 함께 DAU는 4.5배가 됐다. 공식 블로그는 같은 기간을 “2019년 이후 DAU 4배 성장”이라고 적었고, “상관관계는 인과관계가 아니다”라는 단서도 붙였다. 4.5배 전체를 CURR 덕분으로 볼 수는 없다. 그래도 같은 팀이 순서를 바꾸자 결과가 달라졌다는 점은 분명하다.

사례: LinkedIn은 ‘업로드가 줄어드는’ 원인을 랭킹 모델에서 찾았다

앞에서 든 “업로드 수 감소” 예시와 가장 가까운 실제 사례는 LinkedIn 피드다. LinkedIn 엔지니어링 블로그에 따르면, 팀은 글을 올려도 반응을 하나도 받지 못하는 크리에이터 수가 오히려 늘고 있다는 것을 발견했다(LinkedIn Engineering, 2018-10-16).

“왜?”를 따라가 보면 이렇다.

1. 왜 크리에이터가 다시 글을 올리지 않나? 반응을 못 받기 때문이다. 글을 올리고 좋아요를 10개 이상 받은 회원은 반응을 전혀 못 받은 회원보다 다음 주에 다시 글을 올릴 가능성이 17% 높았다.
2. 왜 반응을 못 받나? 피드의 반응이 소수의 상위 크리에이터에게 몰리고 있었다.
3. 왜 모델이 그렇게 동작했나? 버그가 아니었다. 랭킹을 늘 보는 사람의 관점에서만 설계해서, 반응이 크리에이터에게 주는 가치를 모델이 보지 못했다.

해결 방안은 세 번째 원인에 맞췄다. 랭킹에 크리에이터 쪽 효용을 넣어 상위 0.1% 크리에이터가 받던 반응의 약 8%를 하위 98%에게 돌렸다. 그러자 다시 글을 올리는 크리에이터가 5% 늘었다. 같은 작업을 정리한 논문의 A/B 테스트에서는 유지된 크리에이터가 5.26% 늘었다(Tu et al., KDD 2019).

1단계에서 멈췄다면 해결 방안은 “크리에이터에게 글쓰기 알림을 더 보내자” 정도였을 것이다. 3단계까지 갔기 때문에 문제를 만들던 모델의 목적 함수 자체를 고칠 수 있었다. 단, 17%는 상관관계 수치이고 논문도 소비자 쪽 이득은 작았다고 적었다. 이 변경이 DAU를 얼마나 바꿨는지는 공개되지 않았다.

내 블로그에 적용해 보기

2장 글에서 내 블로그의 문제를 “DAU가 적다”(하루 평균 약 5명)로 정의했다. 4장 글에서는 원인 후보 중 “노출 부족”을 확인하려면 일별 노출과 DAU를 시계열로 나란히 봐야 한다고 정리했다.

5장의 기준으로 그동안 한 일을 칸에 나눠 보면 이렇다.

솔직히 말하면 나도 방법맨에 가까웠다. 그래서 “왜?”를 다시 물어봤다.

1. DAU가 왜 적은가? 후보는 검색 유입이 적거나, 검색 밖 유입(직접 방문, SNS)이 적은 것이다. DAU 중 검색 유입 비중은 아직 확인하지 않았다.
2. 검색 유입이 왜 적은가? 노출 자체가 적다. 약 3주 동안 노출 72회, 클릭 5회였다. CTR 6.9%는 표본이 작아 아직 판단하지 않는다.
3. 노출이 왜 적은가? 평균 게재 순위가 13.7이라 대부분 검색 결과 2페이지에 있다.
4. 왜 2페이지에 머무는가? 아직 모른다. 글이 검색 의도와 안 맞는지, 발행 후 시간이 짧아서인지, 경쟁 글보다 내용이 약한지 구분하지 못했다.

1번과 4번에서 막혔다는 것은 아직 해결 방안을 고민할 단계가 아니라는 뜻이다. 그래서 다음에 할 일을 해결 방안이 아니라 원인 확인으로 정했다.

1. GA4에서 DAU를 유입 경로별로 나눠, 검색 유입 비중부터 확인한다. 비중이 낮다면 1번의 답은 검색이 아니다.
2. 글별로 발행 후 경과 일수와 게재 순위를 나란히 놓고, 시간이 지나면 순위가 오르는지 본다. 오른다면 4번의 답은 “시간”이고, 지금 제목을 또 고칠 이유가 없다.

마치며: 해결 방안을 말하기 전에 던질 질문

회의나 리포트에서 해결 방안을 꺼내기 전에 아래 다섯 가지를 확인한다.

1. 지금 하는 말이 어느 칸인가? 문제인지, 원인인지, 해결 방안인지 구분했는가.
2. 해결 방안이 원인을 향하는가? 문제에 바로 대고 있지 않은가.
3. “왜?”를 원인이 규명될 때까지 물었는가? “사람의 실수”나 “퀄리티 저하” 같은 답에서 멈추지 않았는가.
4. 원인 후보를 여러 갈래로 열었는가? 첫 번째 원인을 찾자마자 멈추지 않았는가.
5. 처음부터 끝까지 한 문장으로 이어지는가? “문제는 A이고, 원인은 B라서, C를 한다”가 막힘없이 읽히는가. 이어지지 않는 곳이 생각을 건너뛴 곳이다.

기법은 이 다섯 가지를 확인한 뒤에 고른다. 상관계수든 A/B 테스트든 회귀분석이든, 어느 칸의 질문에 답하려고 쓰는지 알 때 비로소 의미가 생긴다.

분석을 마친 뒤 그 내용을 결론 한 문장으로 모으는 법은 6장 정리에서 이어서 다룬다.

참고 자료

• 카시와기 요시키 (2021). 『빅데이터 시대, 성과를 이끌어 내는 데이터 문해력』 5장 기법에 집착하지 마라. 강모희 옮김. 프리렉.
• Snap Inc. (2018-05-01). Q1 2018 Earnings Call Transcript.
• Snap Inc. (2018-08-07). Q2 2018 Earnings Call Transcript.
• Snap Inc. (2018-10-25). Q3 2018 Earnings Call Transcript.
• Mazal, J. (2023-02-28). How Duolingo reignited user growth. Lenny’s Newsletter.
• Gustafson, E. (2023-02-17). Meaningful metrics: How data sharpened the focus of product teams. Duolingo Blog.
• Bezos, J. (2018-04-18). 2017 Letter to Shareholders. Amazon.
• Vogels, W. (2006-11-01). Working Backwards. All Things Distributed.
• Bryar, C., & Carr, B. (2021-02-09). An insider look at Amazon’s culture and processes. About Amazon.
• Toyota Motor Corporation (2006-03). Toyota Traditions: Ask “why” five times about every matter. Internet Archive 보관본.
• AWS (2022-02-18). Why you should develop a correction of error (COE). AWS Cloud Operations Blog.
• AWS (2023-11-06). Creating a correction of errors document. AWS Cloud Operations Blog.
• LinkedIn Engineering (2018-10-16). Spreading the Love in the LinkedIn Feed with Creator-Side Optimization.
• Tu, Y., et al. (2019). Feedback Shaping: A Modeling Approach to Nurture Content Creation. KDD ‘19.