neozest : neo+zest

개인적으로 구체적인 스토리를 가지고 특정 기술을 설명하는 방식을 좋아한다. 기술이 발전하면서 다양한 측면에서 발전이 이루어지기 때문에 기술 그 자체를 중심에 놓고 학습하다보면 종종 그 기술을 왜 배우고 어떻게 사용할 것인지라는 나침반을 잊어버리게 되기도 한다.

개발 측면에서 나는 C++개발자로 분류되지만, 데이터 분석 같은 작업에는(대용량 데이터 분석이 아닌 이상) 로컬머신에서 파이썬을 주로 사용한다. 파이썬은 이미 충분한 성능 및 좋은 데이터 분석 라이브러리를 갖추고 있다. (불행(?)히도 점점 파이썬을 사용하는 비중이 높아지고 있다. 다행히 C++ 역시 파이썬과 문법적 개념이 비슷해지고 있다.)

최근 데이터 분석과 관련된 파이썬 책이 많이 출간되고, 출간될 예정이다. 그런데 그동안 읽었던 책 중에서 마음에 드는 책을 발견하여 소개한다. 바로 O'reilly에서 출간된 'Data Wrangling with Python'이란 책이다.

http://www.amazon.com/Data-Wrangling-Python-Tools-Easier/dp/1491948817/

책 제목에서 알 수 있듯, 이 책은 파이썬을 사용하는 책이긴 하지만 범용 파이썬 개발자를 대상으로 쓰인 책이 아니다. 파이썬으로 데이터를 요리조리 다루고 싶은 사람(책 저자는 언론사나 데이터 분석가를 대상으로 쓴 것 같다.)들을 위한 책이다.

책은 크게 3개 부분으로 나뉘어진다. 1)데이터 획득 2) 데이터 정리 3) 데이터 탐험

데이터를 다루게 된다면 대부분 위 그림과 같은 작업 흐름을 따르게 될 것이다. 이 책은 위 그림의 각 단계에서 파이썬을 어떻게 활용할 수 있는지를 적절하게 잘 설명하고 있다. 예컨데 데이터 획득의 경우, 물론 데이터의 정의부터 시작하지만, 엑셀 파일, CSV(TSB), JSON, XML등 다양한 데이터 소스를 처리하는 방법을 소개한다. 각 소주제에 따라 파이썬에서 유명한 모듈들을 소개한다. 기본적인 파이썬의 문법이나 자료구조(딕셔너리, 리스트, 셋 등)들에 대해서도 짧게 다루지만, 이 책으로 파이썬 문법을 이해하기에는 글쎄. 조금 힘들다. 기본적인 문법을 알고 있는 상태라면 초급에서 중급으로 올라갈 수 있는 디딤돌이 될 것이다.

7장과 8장에서는 데이터에서 부적절한 데이터나 튀는 데이터, 신뢰성이 있는 데이터인지 등을 검증하는 방법들을 소개한다. 이후 데이터 탐색 및 프리젠 테이션을 다루는데, 후반에는 약간 내용의 중심이 흐려지는 기분이 있다. 웹스크래핑을 다루는 11장/12장의 내용은 개인적으로는 Acquire the Data섹션에서 소개되어야 적절하다고 본다. 후반부에서 자동화 및 확장성을 고려한 구조등을 다룰 때도 한 챕터에 다루기에는 너무 큰 내용이지 않았나 싶다. 

파이썬을 공부하기 위하여 이 책을 골랐다면 부적절한 선택일 수 있다. 반대로 데이터를 처리하는 비 개발자가 이 책을 본다면 왠지 파이썬 기본 문법책을 하나 찾고싶은 욕구가 생길지도 모르겠다. 파이썬이 데이터 처리 분야에서 가지는 장점을 잘 훑어볼 수 있다.  또한 파이썬 개발자가 데이터를 처리하기 위하여 자신의 기술을 어떻게 활용할 지를 알고 싶다면 좋은 선택일 수도 있겠다.

회사내 데이터를 다루는 팀 동료에게 이 책을 권했는데, 대단히 흥미로워 한다. 읽으면서 파이썬이라는 언어에 흥미를 가진다. :) 이 책의 효과는 이로써 충분하다.

 아직은 한글판이 없지만, 조만간 인사이트 출판사를 통해 번역본도 나올 듯 하다.  국내 데이터 엔지니어들에게도 파이썬의 날개를 달아주었으면 좋겠다.

같은 팀 동료가 공유해 준 글입니다. 짧은 글이지만 많은 인사이트를 얻었던 글이기도 합니다.그래서 잠시 시간을 내서 발번역을 했습니다. 의역도 조금 했습니다만, 글쓴이의 의도는 충분히 전달할 수 있을 수준이라 생각되어 같이 나눠봅니다. :)

영어를 잘하시는 분들은 원문의 감동을 느껴보세요:

http://www.azarask.in/blog/post/the-wrong-problem/

링크가 바뀐 것 같아서 수정(2023-03-16): https://uxmag.com/articles/you-are-solving-the-wrong-problem

이 글을 쓴 Aza Raskin님은 HCI 분야의 대가인 Jef Raskin님의 아들로, 파이어폭스 브라우저 개발에도 참여했으며 지오로케이션 API의 초안 작성자이기도 합니다. 현재 조본사의 VP입니다.

--------------------------------------------------------------------------

당신은 엉뚱한 문제를 풀고 있다.

일상생활에서나 직장생활에서, 혹은 무언가를 만들 계획이라면 그 과정에서  해결해야 하는 문제들이 늘 있기 마련이다. 그런데 여러분은 정작 엉뚱한 문제를 풀고 있을지도 모른다. 20세기가 낳은 위대한 기계공학자로 손꼽히는 폴 맥크레디(Paul MacCready)는 이를 한마디로 멋있게 요약했다. : "진짜 문제는 우리가 문제를 전혀 이해하지 않는다는 사실이다."

옛날 이야기

1959년은 격동의 시대였다. 디즈니는 명작 '잠자는 숲 속의 미녀'를 상영했고, 피델 카스트로는 쿠바 평의회 의장이 되었고, 아이젠하워는 하와이를 미국의 50번째 주로 공식 인정하였다. 영국의 산업계 거물인 앙리 크레머(Henry Kremer)는 예전부터 조종사의 힘만으로 동작하는 비행기가 과연 현실적으로 가능한가에 대해 호기심이 많았다. 다빈치가 가능하다고 믿었던 것처럼 크레머도 인력 비행기를 만들 수 있다고 믿었고, 이를 실현해 보고 싶었다. 그해 그는 1.5마일(약 2.5km) 떨어진 두 표지판 사이를 8자로 비행하는 인력 비행기를 처음 만든 사람에게 5만 파운드의 엄청난 상금을 주겠다고 발표했다. 또한, 최초로 인력비행기로 해협을 횡단하는 사람에게는 따로 10만 파운드의 상금을 걸었다. 이 상금을 현재 가치로 환산하면 각각 130만 달러(약 15억원)와 250만 달러(약 28억원) 정도 된다. 그 당시의 X프라이즈(XPRIZE)였던 셈이다.

그로부터 10년의 시간이 지나갔다. 수십팀이 요구조건을 충족하는 비행기를 만드려고 노력했지만 실패했다. 이제는 불가능한 과제처럼 보였다. 그 이후 또다시 10년이 지났을 때 우리의 영웅, 맥 크레디가 이 공모전에 참여하기로 결정했다. 그는 문제를 살펴보고, 기존 방법들이 왜 실패했는지, 어떤 식으로 비행기의 구조를 개선해나갔는지 살펴보았다. 그 과정에서 그는 사람들이 전혀 엉뚱한 문제를 풀고있다는 사실을 최초로 깨닫게 된다. 그는 이렇게 단언했다. "문제는 우리가 문제를 이해하지 않는다는 사실이다"

맥 크레디는 인력 비행기를 만들고자 하는 사람들이 모두 실증적 테스트를 수행하지 않고 이론과 가설에 기반하여 비행기를 만드는데 수년의 시간을 썼다는 사실을 간파했다. 그렇게 호기롭게 제작된 비행기로 시험비행에 도전했지만, 몇분뒤에는 수년간 작업한 결과물이 땅에 내동댕이치는 광경을 바라볼 수 밖에 없었다. 하늘로 떠오르는데 성공했더라도 겨우 몇백미터를 비행한 뒤에 조종사가 탈진해버리고 말았다. 연구팀들은 이렇게 얻어진 데이터를 기반으로 개선된 이론과 가설을 세운 다음 또다시 새로운 비행기를 만들고, 테스트해보고, 다시 배우는 과정을 반복해야 했다. 진행속도는 더딜 수 밖에 없었지만 그처럼 어려운 비전을 구현하는 과정에서 이런 난관은 당연한 것이라 생각했었다. 인류는 이와 비슷하게 어려운 과제를 도전해 왔다.

문제는 문제다.

폴은 우리가 풀어야 할 문제는 사실 인력 비행기가 아니라는 점을 깨달았다. 문제를 그렇게 설정해버리면 사람들의 관심은 엉뚱한 곳에 쏠리고 만다. 문제는 프로세스 그 자체였다. 매우 어려운 과제를 어떻게 해결해 나갈 것인지에 대한 성찰없이 맹목적으로 목표만 쫓은 것이다. 그는 자신이 풀어야할 문제를 새롭게 정의했다. 그가 정의한 문제는 '어떻게 하면 몇달씩 걸리던 비행기를 몇시간 내에 새로 만들 수 있는가?'였다. 그는 비닐 테이프, 알리미늄 관, 노끈으만으로 비행기를 만들었다.

첫번째 비행기는 제대로 동작하지 않았다. 너무 조잡했다. 그러나 그가 설정한 문제는 몇시간 이내에 새로운 비행기를 만들수 있는가 였으므로, 빠른 속도로 여러번 다양한 비행기를 제작해서 실험해 볼 수 있었다. 때로는 다양한 구조의 비행기를 하루에 서너대씩 날려볼 수도 있었다. 새로 만들고, 테스트하고, 다시 학습하는 과정이 몇년 혹은 몇달씩 걸렸는데, 폴은 이 과정을 수시간 내지 하루이틀 정도로 줄였다.

앙리 크리머가 상금을 내건지 18년이 흘렀다. 아무도 인력 비행기를 실제로 만들어 내지 못했다. 폴 맥크레디는 자신이 풀어야 할 문제를 새롭게 정의했다. 6개월후 맥그레디는 자신이 만든 고사머 콘돌기로 2172미터를 나는데 성공하며 상금을 거머지게 되었다. 1년 뒤, 그는 새로운 고사머 알바트로스 기를 타고 해협을 횡단했다.

도대체 어떻게 문제를 해결할 수 있었을까? 어려운 문제를 풀고자 한다면 문제를 다시 생각해보고, 어떻게 하면 해결책을 빨리 배울 수 있을 것인가를 생각해 보라. 빠른 실패를 겪으면서 더 나은 해결책을 시도할 수 있는 더 빠른 길을 찾아라. 최고의 대표작을 만들려고만 한다면 어쩌면 엉뚱한 문제를 풀고 있을 지도 모른다.