데이터의 시대 2강. 많다고 다 아는 것은 아닙니다
표본이 100만 건이어도 한쪽으로 기울어 있으면, 그 데이터는 틀린 답을 아주 정밀하게 말해 줍니다.
풀고 시작
한 대로는 안 되는 순간
빅데이터를 이야기할 때 흔히 세 개의 V를 듭니다. 규모(volume), 속도(velocity), 다양성(variety)입니다. 이 셋이 중요한 이유는 형용사여서가 아니라, 각각이 처리 방식을 바꾸도록 강제하기 때문입니다.
규모부터 보시죠. 데이터가 한 서버의 디스크와 메모리에 들어가는 동안에는 더 좋은 서버를 사면 됩니다. 그러나 서버 한 대의 성능에는 한계가 있고 가격은 성능보다 훨씬 가파르게 오릅니다. 그래서 값싼 기계 여러 대에 데이터를 쪼개 얹는 수평 확장으로 방향이 바뀝니다. 속도는 다른 압력입니다. 하루치를 밤에 몰아 처리하는 배치 방식으로는 결제 사기를 막을 수 없으니, 흘러들어오는 데이터를 도착하는 대로 처리하는 스트림 방식이 필요해집니다. 다양성은 로그, 이미지, 문장처럼 표의 칸에 넣기 어려운 데이터가 다수가 됐다는 뜻입니다. 1강의 관계형 데이터베이스는 저장하기 전에 스키마를 정하라고 요구하는데, 무엇을 쓸지 모르는 데이터에는 그 요구가 잘 맞지 않습니다.
계산을 데이터가 있는 곳으로 보내기
수평 확장에는 골치 아픈 문제가 따라옵니다. 데이터가 백 대에 흩어져 있는데 계산은 어떻게 할까요. 데이터를 한곳에 모아서 계산하면 네트워크가 병목이 됩니다. 맵리듀스(MapReduce)는 발상을 뒤집었습니다. 데이터를 옮기는 대신 계산 코드를 데이터가 있는 기계로 보냅니다.
동작은 세 단계입니다. 맵 단계에서 각 기계가 자기가 가진 조각만 읽어 키와 값의 쌍을 뽑아냅니다. 문서에서 단어를 세는 작업이라면 단어를 키로, 1을 값으로 내놓습니다. 셔플 단계에서 같은 키를 가진 쌍들이 같은 기계로 모입니다. 리듀스 단계에서 그 기계가 키별로 값을 합칩니다. 프로그래머는 맵 함수와 리듀스 함수만 쓰고, 조각을 어느 기계에 배정할지와 죽은 기계의 작업을 어디서 다시 돌릴지는 프레임워크가 맡습니다. 수백 대를 돌리면 몇 대가 죽는 일은 예외가 아니라 일상이라서, 실패한 조각만 다시 실행하는 구조 자체가 핵심 기능입니다. 이 모형을 오픈소스로 구현한 하둡이 한 시대를 열었고, 이후 중간 결과를 디스크 대신 메모리에 두어 반복 계산을 빠르게 한 스파크가 널리 쓰이게 됐습니다.
창고와 호수
데이터를 모아 두는 방식에는 성격이 다른 두 갈래가 있습니다. 데이터 웨어하우스는 분석용으로 정제된 창고입니다. 여러 시스템에서 데이터를 뽑아 형식을 맞추고 정해진 스키마에 넣은 뒤 저장합니다. 넣을 때 구조를 강제하니 질의가 빠르고 신뢰할 만하지만, 새로운 종류의 데이터를 넣으려면 설계를 손봐야 합니다.
데이터 레이크는 반대로 원본을 형식 그대로 쏟아 넣고, 읽는 시점에 그때그때 구조를 입힙니다. 무엇에 쓸지 모르는 데이터를 일단 보존한다는 점이 강점이죠. 문제는 관리가 없으면 아무도 무엇이 들었는지 모르는 늪이 된다는 것입니다. 어떤 데이터가 어디서 와서 어떻게 가공됐는지 기록해 두지 않으면, 창고에 물건은 가득한데 재고 목록이 없는 상태가 됩니다.
| 구분 | 웨어하우스 | 레이크 |
|---|---|---|
| 구조를 정하는 시점 | 저장할 때 | 읽을 때 |
| 강점 | 일관성과 질의 성능 | 형식 자유도와 보존성 |
| 실패 양상 | 새 데이터 수용이 느림 | 목록 없는 늪이 됨 |
크기가 대표성을 사 주지는 않습니다
여기서 이 강의 핵심으로 갑니다. 1936년 미국 대선에서 리터러리 다이제스트라는 잡지는 200만 명이 넘는 응답을 모아 랜던의 승리를 예측했습니다. 결과는 루스벨트의 압승이었습니다. 훨씬 적은 표본으로 정확히 맞힌 갤럽과 갈린 지점은 크기가 아니라 누가 응답했는가였습니다. 명단이 전화 가입자와 자동차 등록자 중심이었으니, 대공황기에 그 명단은 유권자 전체가 아니었습니다.
이 교훈은 데이터가 커져도 그대로입니다. 표본이 커지면 우연에서 오는 흔들림은 줄어들지만, 표본이 모집단을 닮지 않아 생기는 편향은 줄지 않습니다. 소셜미디어 글을 아무리 많이 긁어모아도 그 플랫폼을 쓰지 않는 사람의 의견은 한 건도 들어오지 않습니다. 더 고약한 것은 데이터가 클수록 추정의 오차 범위가 좁게 계산돼, 틀린 값을 더 자신 있게 말하게 된다는 점입니다.
구글 독감 예측이 남긴 것
이 함정을 가장 유명하게 보여 준 사례가 구글 독감 트렌드입니다. 독감 관련 검색어의 빈도로 독감 유행 정도를 추정하겠다는 시도였고, 초기에는 공식 통계와 잘 맞아 큰 화제가 됐습니다. 그런데 시간이 지나면서 유행을 크게 부풀려 추정하는 일이 이어졌고, 결국 서비스는 접혔습니다.
원인 분석에서 반복해 지적된 것은 두 가지입니다. 첫째, 검색어와 독감 사이의 관계는 상관에 기댄 것이지 인과 구조가 아니었습니다. 독감이 아니라 독감 뉴스 때문에 검색이 늘면 모형은 그 차이를 구분하지 못합니다. 둘째, 측정 도구 자체가 변했습니다. 검색 엔진은 자동완성과 추천을 계속 바꾸고, 그 변화가 사람들의 검색어를 바꿉니다. 재는 자가 재는 동안 스스로 늘어나는 셈이죠. 상관과 인과의 구분이 왜 데이터 분석의 뼈대인지는 상관과 인과 강에서 더 자세히 다룹니다. 다음 강에서는 이런 데이터로 규칙을 직접 짜는 대신 기계가 규칙을 찾아내게 하는 방법으로 넘어갑니다.
인출 문제
생각해볼 질문 (정답 없음)
- 여러분이 자주 쓰는 서비스가 여러분에 대해 모은 데이터는, 여러분이라는 사람의 어떤 면을 구조적으로 놓치고 있을까요?
이전: 데이터의 시대 1강 · 다음: 데이터의 시대 3강