봉투 뒷면에 하는 검증
'봉투 뒷면에 하는 계산' 이라는 관용어가 있다. 어떤 복잡한 문제를 풀기 전에 간단한 추정이나 어림 계산하는 것을 말한다. 물리학자인 엔리코 페르미가 이걸 잘했다고 해서 이런 어림 계산에 의한 추정을 '페르미 추정' 이라고도 부른다. 맨하탄 프로젝트에서 핵폭탄 실험 당시, 페르미가 폭발 시점에 종이 조각을 날려서 조각이 날아간 거리와 폭발 지점으로부터의 거리를 통해 핵폭탄의 위력을 어림 계산했는데 이게 실제 정밀 계산 결과와 거의 차이가 나지 않았다는 일화는 매우 유명하다.
데이터 분석에 있어서도 이와 유사한 '봉투 뒷면에 하는 검증'이 매우 유용하다. 대량의 데이터를 이용해서 여러 단계의 전처리를 거쳐 복잡한 분석을 하다보면 사소한 오류로 인해 결과가 엉뚱하게 나오는 경우가 종종 있다. 보통 데이터 분석을 하고 나면 그 결과를 근거로 의사 결정을 하게 된다. 그리고 중요한 결정이 필요할수록 심도 있는 분석을 하게 되는데 문제는 이런 심도 있는 분석일수록 다양한 데이터를 이용해서 복잡한 분석을 하기 때문에 오류가 날 확률이 그만큼 높다는 것이다.
따라서 데이터 분석이 끝나면 데이터 및 분석 과정에 대한 검증이 꼭 필요하다. 일종의 '재현성 검증'이다. 그런데 '재현성 검증'은 보통 분석 과정에 드는 비용만큼이나 (혹은 그보다 더) 많은 노력이 필요하다. 따라서 만약 결과로 나온 수치를 토대로 결과가 합리적인지 어림 검증을 통해 오류를 빠르게 찾을 수 있으면 검증에 필요한 상당한 노력을 줄일 수 있을 것이다. 때문에 이런 '봉투 뒷면에 하는 검증' 능력을 갖추는 것이 중요하다.
이를 위해 가장 중요한 것중 하나는 숫자에 대한 감을 키우는 것이다. 어떤 결과들은 너무나 엉뚱해서 집계하거나 예측한 수치가 전혀 엉뚱한 값인 경우가 있다. 그런데 분석 과정이 복잡할수록 그리고 그 과정에 깊이 참여한 사람일수록 이런 수치상의 오류를 잘 찾지 못하거나 아니면 다른 수치에 집착하는 경우가 많다. 가령, 유형별 비율에 집착한 나머지 집계 수치 자체가 엉뚱하다는 것을 눈치채지 못하는 경우가 한 예이다. 그런데 숫자에 대한 감각이 뛰어나면 이런 이상한 수치를 잘 찾아낼 수 있다.
이런 숫자에 대한 감을 키우는 것은 '봉투 뒷면에 하는 계산'을 잘하는 것과도 관련성이 높다. 예를 들어 예전에 유행했던 면접 문제였던 '뉴욕 시에 있는 맨홀 뚜껑의 개수는 얼마인가?', '이 방에 풍선을 가득채우려면 몇 개의 풍선이 필요한가?' 등의 문제가 이런 숫자에 대한 감과 연관성이 높은 문제이다.
내가 생각하기에 이런 숫자에 대한 감은 다소 타고나야 하는 것 같다. 다만 후천적으로도 노력해서 키울 수 있는데 먼저 분석에서 자주 사용되는 다양한 숫자들을 외워두는 것이 있다. 가령 내 경험상 데이터 분석가라면 다음과 같은 숫자들은 암기해 놓는 것이 좋다.
시간 관련 수치들 : 1일 = 1440분 = 86400초
2의 제곱수 : 2의 5승 = 32, 2의 8승 = 256, 2의 10승 = 1024, 2의 16승 = 65536, 2의 24승 = 약 1670만, 2의 32승 = 약 42억
큰 수를 세자리씩 끊어서 단위 읽기 : 1K = 천, 1M = 백만, 1G = 십억, 1T = 1조, 1P = 천조
이 정도만 외워놔도 일상에서 다양한 수치 오류를 쉽게 찾아 낼 수 있다. 가령, 가장 쉽게 접하는 오류가 숫자 단위를 잘못 사용하는 것이다. 예전에 어떤 책에서 아래와 같은 문장을 본 적이 있다.
' 이 경우 하루 동안 90만 번의 심장박동을 기록하는 장치를 그들의 몸에 붙이게 된다.'
위 문장에서 '90만 번'은 영어로 된 90 thousands를 잘못 번역한 것일 가능성이 매우 높다. 왜냐하면 하루는 대략 8만 6천초이고 심장은 보통 분당 60~70회 뛰니까 일반적인 사람이라면 하루에 8~9만번 심장박동을 하기 때문이다.
또 하나, 회사에서 유저별 어떤 컨텐츠 이용 현황에 대한 수치를 집계하는데 특정 항목이 음수값으로 나오는 문제가 있었다. 그런데 수치를 보니 대략 -1600만 정도가 되었다. 위에 언급한 수치 중 -1600만은 2의 24승과 관련이 깊다. 아마 프로그래머라면 이게 bit masking이나 혹은 overflow 문제일 가능성이 높다는 것을 눈치챘을 것이다. 아니나 다를까 해당 항목을 계산하는데 사용하는 로그 컬럼은 서버 프로그래머가 24번째 비트를 특정 상황을 구분하기 위한 목적으로 사용하고 있었다(그래서 해당 값을 모두 16777216으로 나눈 나머지 값으로 집계하니 정상 수치가 나왔다).
이렇게 2의 제곱수들은 컴퓨터를 이용하는 수치 작업에서 종종 발견되는 패턴이기 때문에 미리 숙지해 두면 이상 패턴을 찾는데 유리하다.
둘째, 숫자들의 분포나 관계에 대해 민감해져야 한다. 예전에 회사에서 하둡 클러스터의 신규 로그 포맷에 대한 성능 테스트를 수행한 적이 있다. 아래는 그 실험 결과 표이다.
위 표에서 A,B,C,D는 다양한 파일 포맷이며 이 포맷들에 대해 동일한 데이터로 같은 map/reduce 작업을 수행했을 때 걸리는 시간을 측정한 것이다. 그리고 split num 은 해당 데이터를 얼마나 많은 작업으로 쪼개어 분산 처리했는지를 나타내는 수치이다. 보통 split num 이 크면 mapper당 처리해야 하는 데이터 양이 적어서 좋지만 그렇다고 마냥 데이터를 쪼개서 처리하면 각 분산 작업을 관리하거나 실행하는 부담이 커지기 때문에 분산 효율은 떨어지게 된다.
암튼 위 표를 보면 각 단위 작업당 수행 시간은 D가 가장 짧다. 그런데 자세히 보면 저 테스트 결과는 이상하다. A, B, C의 경우 split num이 커질수록 (각 단위 작업당 처리할 데이터 양이 줄어들기 때문에) mapper당 수행 시간이 줄어든다. 반면 D는 split num도 작은데 mapper당 수행 시간도 지나치게 짧다. 당시 그 이유에 대해 테스트 담당자에게 질문을 했고 원인 설명을 위해 테스트를 살펴본 담당자는 이 테스트 결과가 잘못된 것을 발견하였다.
한편, 비율에 집착한 나머지 실제 수치를 간과하는 경우도 흔히 하는 실수이다. 내가 경험한 몇 가지 사례를 나열해 보면 다음과 같다(이해를 돕기 위해 수치는 다소 과장하였다).
각 그룹별 데이터의 모수가 지나치게 작은 상태에서 비율을 보고 비교하는 경우 - 1~10번까지 10개의 고객 유형을 나누고 각 유형별 A 제품의 구매 비율을 비교해 보니 5번 유형의 구매 비율이 33%로 가장 높게 나왔다. 그런데 알고 보니 5번 유형의 고객 수는 3명이었다.
사기 탐지 모델을 만드는데 탐지율이 50%이고 오탐율은 1%밖에 되지 않았다. 그런데 알고 보니 전체 데이터에서 fraud의 비율이 0.1%밖에 안되기 때문에 개수와 금액을 기준으로 보면 잘못 탐지하는 결제 금액이 훨씬 커서 이대로 서비스에 사용할 수 없는 수준이었다.
셋째, 평균의 오류에 빠지는 경우가 있다. 평균의 문제점에 대해서는 이미 널리 알려져 있기도 하고 예전에 한번 다룬 적(http://agbird.egloos.com/6004322)이 있지만 그럼에도 불구하고 종종 빠지기 쉬운 오류이다. 예전글에도 썼듯이 이 오류에 빠지지 않으려면 분포를 보거나 최소한 최대/최소 및 분위수 정도는 확인하는 것이 좋다.
마지막으로 해당 분야의 도메인 지식에 기반한 검증도 중요하다. 데이터 모델링에 치중하다보면 알고리즘이나 숫자에 집착해 실제 해당 분야를 아는 사람이라면 쉽게 눈치챌 수 있는 말도 안되는 숫자를 그냥 넘어가기 쉽다. 반대로 얘기하면 분석 결과를 검증할 때 이렇게 도메인 지식이나 상식을 이용해 검증하는 것은 좋은 검증 방법이다.
예를 들어, 얼마전 다른 회사에 다니는 사람의 LTV(Life Time Value: 고객 생애 가치, 고객이 일생동안 가져다 주는 총 이익) 분석 결과를 리뷰해 준 적이 있다. 사용자들을 몇 가지 유형으로 나누고 각 유형별 기대 수명과 과거 매출을 기반으로 몇 가지 데이터 마이닝 기법을 써서 나온 결과였다. 이 자료를 보고 내가 가장 먼저 한 것은 각 유형별 LTV 와 고객수를 이용해서 총 LTV를 구하고 이것을 그 회사에 대한 기대 수명으로 나눈 값과 이 회사의 현재 연간 영업 이익을 비교한 것이었다(그 회사는 대기업이었기 때문에 벤처기업처럼 폭발적인 성장을 기대할만한 회사는 아니었고 따라서 이 두 수치는 크게 차이가 없어야 정상일 것이다).
내가 그 회사에 대해 잘 알지 못하고 전체 분석 과정을 모르기 때문에 분석 방법에 기반한 검증을 하는 것은 실상 쉽지 않다. 다만 이런 식으로 내가 알 수 있는 상식에 기반해 분석 결과로 나온 수치를 비교해보면 이 결과가 터무니 없는지 아니면 합리적인지 정도는 어림 검증할 수 있다.
정리하자면, 분석 결과에 대해 검증하는 것은 꼭 필요한 작업이다. 그러나 제대로 된 검증을 하려면 분석 자체에 든 비용만큼이나 많은 비용이 든다. 그런데 대부분의 경우 수치 관련 오류는 '어림 검증'을 통해 찾을 수 있다. 그리고 이런 어림 검증은 몇 가지 패턴을 갖고 있어서 이에 대해 숙지해 놓는 것이 좋다.
