Share           Pin It

회사(카카오)는 요즘 고민이 많습니다. O2O를 시작하면서 예견된 일이지만 O2O에서 서비스적 성과는 냈지만 가시적인 비즈니스 성과는 제대로 내지도 못하고 이리저리 치이다보니 카카오라는 브랜드 이미지마저 나빠집니다. 많은 스타트업에 투자하고 인수를 해서 진행한 일도 카카오라는 이름으로 리브랜딩하는 순간 과거의 모든 것은 사라집니다. 대기업의 골목상권 침해라는 프레임으로 기술과 서비스를 평가하는 것에 억울함은 있지만, 그럴수록 상생과 공생, 그리고 번영이라는 어쩌면 시대의 화두에 대해서 더 고민하게 됩니다.

카카오는 카톡이라는 메신저 플랫폼도 가지고 있고 다음이라는 포털도 가지고 또 다른 많은 브랜드와 서비스를 가지고 있습니다. 그러나 매출은 결국 소위 말하는 트래픽 장사로 벌어들입니다. 즉, 광고입니다. 좀 고상하게 표현하면 데이터 비즈니스를 하고 있습니다. 지난 글에서 적었듯이 카카오가 현재까지는 데이터 비즈니스에 현명하지는 -- 이라고 적고 교활하지는 이라고 해석 -- 못했습니다. (참고 링크. http://bahnsville.tistory.com/1121)

결국 현재 카카오는 데이터 비즈니스를 제대로 하는 기반을 마련하면서 카카오를 중심으로 많은 스타트업들과 상생하는 건전한 생태계를 만들어야 하는 숙제를 가지고 있습니다. 이 두가지 -- 상생과 데이터 비즈니스 --를 한번에 해결(까지는 아니고 조금 도움이될)하는 한가지 방법을 제안합니다. (내부 게시판/아지트를 통해서 적었던 글을 외부용으로 편집해서 블로깅합니다.)

제가 생각했던 것은 '오픈 데이터 Open Data' 전략입니다. 즉, 프로그램 소스 코드나 라이브러리, API를 외부에 공개해서 마음껏 사용하도록 하는 오픈 소스처럼 카카오 서비스 생태계에서 확보한 다양한 데이터를 외부에 공개해서 마음껏 사용하도록 지원하는 것입니다. 가칭 Kakao Open Data Initiative (KODI)입니다. 실시간으로 확보하는 모든 데이터를 외부에 공개하자는 얘기는 당연히 아닙니다. 데이터가 기업의 특급 비밀이며 자산인 시대에 모두를 공개하는 것은 말도 안 되는 소리고, 또 (익명화 과정을 거친다손 치더라도) 사용자의 개인정보를 다수 포함한 데이터를 공개하는 것은 다른 법적 이슈도 발생합니다. 그리고 모든 데이터를 공개한다고 해서 방대한 양의 데이터를 한꺼번에 다 가져다쓸 수 있는 곳도 거의 없습니다. (가능한 곳은 카카오의 몇몇 경쟁 회사들 뿐입니다.) KODI의 기본 전제가 연구자들을 위한 데이터 공개입니다.

지금은 데이터의 시대이면서 지능의 시대로 접어들고 있습니다. (글을 처음 적은 날 구글은 AI-first를 선언했습니다.) 인공지능이 화두인 이 시점에 카카오 내부의 인력과 재원만으로 지능의 파고를 제대로 대처할 수가 없습니다. 일부 분야에서 앞선/첨단 기술을 적용해서 서비스화도 시도하고 있지만, 모든 분야에서 딥러닝 등의 머신러닝 기술을 적용할 수가 없습니다. 구글이나 페이스북도 많은 부분에 인공지능을 접목해서 가시적 성과를 내고 있지만 완벽하지는 않습니다. 그런 상황에서 갈길이 바쁜 카카오가 지금 당장 인공지능의 선두회사가 될 가능성은 거의 없다고 봐도 무관합니다. (앞으로의 가능성에 대한 여지는 남겨둡니다.) 최근 주목받고 있는 conversational UI, 즉 지능형 봇을 카톡에 제대로 구현한다거나 AI 기반으로 검색/추천랭킹을 완전히 바꾼다거나 많은 사용자/트래픽 정보를 비즈니스적 가치가 있는 정보로 가공하는 등의 많은 일들을 현재의 카카오 내부 역량만으로는 모두할 수가 없습니다.

회사 내에서 불가능하다면 회사 밖에서 솔루션을 찾아야 합니다. 그래서 많은 스타트업들에게 투자와 인수를 하는 것입니다. 잠재적 동지이며 경쟁자인 스타트업들도 중요하지만, 눈길을 학교로 돌려야 한다고 생각합니다. 수 테라바이트의 데이터가 우수은 빅데이터의 시대지만, 오늘도 열악한 대학원 연구실에는 수십만개, 아니 수만개의 데이터도 없어서 알고리즘을 개발하거나 개선하지 못하는 실정입니다. 10년 전에 추천 알고리즘에 관한 논문을 쓸 때 사용했던 (ML) 데이터나 BookCrossing (BX) 데이터가 여전히 거의 유이한 추천 알고리즘용 데이터입니다. (물론 이들 데이터는 여러 연구를 통해서 검증을 마친 상태라서 레퍼런스하기에 좋다는 장점이 있음) 대학원 연구실에는 실제 현장/서비스가 만들어내는 데이터가 없어서 앞으로 전진하지 못하는 것이 현실입니다. 그 숨통을 확 터여줬던 것이 Netflix Prize였습니다. 사용한 메트릭의 좋냐 나쁘냐의 이슈를 떠나서, 알고리즘 분야에서 10%이상의 개선은 거의 불가능한 과제였지만, 넥플릭스 프라이즈를 통해서 그 벽을 허물었습니다.

넷플릭스처럼 상금대회를 개최하자는 얘기는 아닙니다. 단지 카카오 (또는 데이터를 가진 다른 회사)가 가진 그리고 해결해야하는 문제와 연관된 일부 (안전한) 데이터만 외부에 오픈하자는 것입니다. 많은 연구자들이 카카오의 데이터로 알고리즘을 개발/개선하고 검증하면서 논문을 쓴다고 상상해보십시오. 저는 이 글을 적으면서 상상만으로도 가슴이 벅찹니다. 그렇게 출판된 논문의 알고리즘을 가져와서 카카오의 서비스를 개선할 수 있습니다. 그런 우수한 연구를 한 연구자가 잡마켓에 나왔을 때 카카오가 먼저 사카우트한다면 인적/기술적 자산을 더 풍부하게 만들 수 있습니다. 이미 카카오의 데이터에 익숙해진 연구자라면 취업 후에 적응에 따른 시행착오도 줄일 수 있습니다. 예전에 '넷플릭스 프라이즈를 다시 생각하다'라는 글에서도 적었듯이, 연구논문에 'Kakao의 데이터를 사용했다'라는 문구만 들어가도 큰 홍보가 됩니다. 앞의 포스트에서 넷플릭스는 겨우 $1M이라는 헐값으로 10%개선된 알고리즘도 획득하고 데이터 비즈니스를 하는 회사라는 명성도 얻었다고 적었습니다. 카카오가 그리고 대한민국의 다른 회사들도 그런 명성을 얻을 수 있습니다.

많은 기업들이 자신들이 개발한 소스 코드를 공개하고 데이터를 오픈하는 것은 그들이 바보라서 아니면 세상을 크게 변화시켜야 한다는 대의 때문만은 아닙니다. 공개를 통해서 실질적인 이득을 얻고 있기 때문입니다. 내부에서 기존의 사고에 갇혀셔 같은 데이터를 같은 프로세스로 같은 관점으로 계속 들여다보면 결국 기존의 것과 전혀 다르지 않은 것을 반복할 뿐입니다. 오픈 이노베이션 Open Innovation이 항상 최고의 전략이라는 것은 아니지만, 손대지 않고 코 풀 수 있는 이만한 전략도 없습니다. 카카오가 필요한 기술과 인력을 외부에서 키우면서 카카오는 연구/기술 생태계를 만들어가는 회사라는 명성도 얻을 수 있습니다. 데이터가 21세기의 원유라고 표현하는데, 굳이 혼자 힘으로 다 캐고 정제할 필요는 없다고 생각합니다.

실제 실행에 옮기기 위해서는 고려해야할 사항이 많고, 장애물도 많습니다. 그래서 전략적 차원에서 고민하고 실행해봤으면 합니다. 그게 카카오가 아니더라도, 대한민국의 그 누군가 그리고 그 어떤 기업에서 먼저...

=== Also in...

F: https://www.facebook.com/unexperienced

댓글을 달아 주세요

Share           Pin It

빅데이터의 시대를 지나 스마트 데이터 시대로 접어들고 있다. 주변에서 데이터가 중요하고 데이터 비즈니스를 하겠다고 하는 회사들은 많지만 정작 데이터 비즈니스에 성공한 회사들은 손에 꼽을만하다. 구글, 페이스북, 아마존 같은 세계적인 기업들이나 겨우 데이터 비즈니스에 성공했다. 아니면 아주 특수한 케이스나 기술에 두각을 보이는 잘 알려지지 않은 데이터/기술 스타트업정도만 생각날 뿐이다. 국내에서는 네이버가 그나마 앞서있는 축에 속하지만 기술에 의한 것인지 아니면 마켓파워 때문인지 구분이 조금 어려운 것도 사실이다. 카카오는 네이버에 비하면 데이터 비즈니스를 한다는 말을 꺼내는 것도 민망하다. 카카오가 다른 큰 회사들보다는 데이터 비즈니스를 위한 최소한의 여건을 갖춘 것은 맞지만, 데이터 비즈니스를 한다고 명함을 내밀만한 수준이 아니다. 단적으로 말해서 카카오가 데이터 비즈니스를 제대로 했다면 지금보다는 배이상의 매출이나 이익을 냈어야 한다고 본다.

원래는 조금 추상적인 수준에서 데이터 과학자 또는 조직이 필요한 것이라는 주제로 글을 적으려 했지만 생각을 전개하다보니 데이터 비즈니스를 제대로 못하는 것으로 생각이 바뀌었다. 그리고 이 글에서는 개인정보 보호나 보안과 같은 법적 외부요인은 고려하지 않는다.

어쨌든, 많은 회사들이 데이터 비즈니스를 하겠다고 선언하지만 가시적인 성과를 내지 못하고 흐지부지 시간만 허비하고 실패하는 것일까? 그런 회사들의 모든 사정을 소상히 알 수는 없지만 몇몇 사례들로 일반화해보려 한다. 왜 데이터 비즈니스에 실패하는 것일까?

첫째는 데이터가 없기 때문이다. 데이터 비즈니스에 필요한 데이터도 없으면서 데이터 비즈니스를 하겠다고 선언만하는 경우가 종종 있다. 데이터가 없다는 것은 말 그대로 아무런 데이터도 없는 경우도 있고, 의미있는 데이터가 없는 경우도 있고, 또 데이터 연동이 제대로 안 되는 경우도 있다. 데이터의 중요성을 간과해서 데이터를 남기는 것 자체가 부재했던 시절이 있었다. 데이터 분석할 사람은 뽑았는데 정작 분석할 데이터가 없는 웃지못할 일이 벌어지는 거다. 데이터가 없거나 어떤 데이터를 어떻게 수집할지 등의 대책없는 시작은 필패를 예약한 거나 다름없다.

그게 뭐냐면 여러분들은 데이터가 없어요 (이미지: 마리텔 캡쳐)


그러나 그동안 데이터가 중요하다고 많이들 떠들고 비즈니스 성공 사례들이 알려지면서 어떻게든 데이터를 남기고 있다. 그러나 막상 비즈니스에서 필요한 의미있는 데이터가 없는 경우가 다반사다. 그저 아파치 서버가 남기는 로그가 데이터의 전부인 경우도 허다하다. 이걸로는 방문자수 카운트 이외의 사실상 할 수 있는 것이 아무 것도 없다. 때로는 어디에 어떻게 사용할지도 모르면서 그냥 데이터를 쌓아두는 경우도 있다. 일단 쌓아두면 나중에 어딘가에는 쓰겠지라는 생각이다. 없는 것보다 있는 게 낫지만 고민없이 남긴 데이터는 결국 나중에 사용될 가능성이 낮다. 속된 말로 똥이다. 의미없이 데이터를 남기다 보면 관리가 허술해지고 또 빈 데이터만 남게 된다. (RDB처럼) 데이터 포맷이 정적이었던 시절에는 스키마 변경이 어려우니 처음 만들 때 일단 모을 수 있는 모든 데이터 필드를 만들고, 또 혹시 모르니 extra 필드를 여러 개 미리 만들어두던 것이 별로 오래전 얘기가 아니다. 분석이나 마이닝이 데이터 더미에서 의미를 찾아내는 것이지만, 무의미한 데이터에서 의미를 찾는 것은 마이닝의 할애비가 와도 안 된다.

의미있는 데이터를 남긴다고 해서 모든 게 해결된 것은 아니다. 여러 팀으로 나뉘어 다양한 서비스를 다루는 큰 회사의 경우 데이터 연동이 안 되는 경우가 많다다. 개별 서비스의 니즈에 맞도록 데이터를 남기다보니 형식이나 의미가 제각각인 데이터 사일로들만 존재한다. 그리고 물리적으로 개별 서비스의 로그를 한 곳에 모으는 것도 쉽지 않다. 주기적으로 데이터 허브 프로젝트를 시작하지만 몇몇 대표 서비스의 데이터는 연동하지만 마이너한 것들까지 싱크를 맞추지는 못한다. 그 사이에 새로운 기술과 서비스가 등장하면서 기존의 데이터와 호환되지 않는다. 설마 그렇기야 하겠어라고 생각하겠지만 이거 우리 이야기네라고 동감하는 사람들도 많을 거다. 데이터가 없거나 의미가 없거나 연동이 안 돼서 결국 데이터를 사용하지 못하는 회사는 데이터 비즈니스를 할 수 없다는 것은 자명하다.

두번째로 데이터를 다룰 사람이 없다. 데이터 엔지니어링 관점에서 각종 서비스에서 데이터를 수집하고 저장하는 인력이 부족한 경우도 있고, 수집된 데이터를 가공해서 의미를 찾아내는 데이터 분석가/사이언티스트가 없는 경우도 있고, 분석 이상의 해석이 부재하거나 분석 결과를 바탕으로 의사를 결정하고 실행하는 사람이 없는 경우도 있다. 다행인 점은 기술이 발전하면서 데이터를 수집하고 저장하는 것을 도와주는 다양한 오픈 소스들이 많이 나왔고 관련 기술이 나날이 발전하고 있다. 그럼에도 각자의 상황에 맞게 그런 기술과 오픈 소스를 자유자재로 다룰 수 있는 전문 인력은 여전히 부족하다.

이 단계를 넘어가면 분석할 사람이 없다. (개인적 생각으론) 분석을 굳이 학위를 가진 사람이 해야하는 것도 아니고, 다양한 분석 기술은 결국 인간의 공통된 사고 방식 heuristic을 정형화한 것에 불과하다. 분석 인력이 부족하다는 것은 결국 분석 기술을 가진 사람이 부족하다는 것보다는 자유로운 데이터 사고를 하는 사람이 부족하다는 뜻에 가깝다. 다행히 여러 데이터 분석 도구들이 개발돼서 일반인들도 쉽게 사용할 수 있게 됐다. 그러나 가장 우려되는 점은 선무당이 사람을 잡는다는 속담처럼 (쉬운) 분석툴들이 제공하는 기능과 속성의 의미를 모르고 기계적으로 데이터를 블랙박스에 넣어서 결과를 얻고선 모든 게 해결됐다고 생각하는 거다. 상황에 맞는 적정 도구를 선택하고 설정하는 것이 중요한데, 예를 들어 단순 선형회귀를 위해서 레이어가 10개가 넘는 인공망 (딥러닝)을 만드는 일이 벌어지지 않으라는 보장이 없다. 기술의 사용이 더 쉬워질수록 그것의 기저에 있는 기술과 의미를 더 잘 알아야 한다.

분석 인력이 보강돼든 분석 소프트웨어를 사용하든 데이터 (수치)가 주는 함의를 해석해야 한다. 해석은 공학이나 과학을 넘어선 영역이다. 그리고 결정을 내려야 하고, 결정에 따라서 실행해야 한다. 원했던 효과가 바로 나오지 않더라도, 다시 데이터를 모으고 분석/해석해서 결정을 내리고 실행해야 한다. 조금 개선이 되면 다른 방법으로 더 나은 것을 찾아야 한다. 하고 또 하고 또 하고… 데이터를 수집하고 분석하고 해석하는 전문 인력이 꼭 필요하지만, 결국에는 그걸 바탕으로 결정해서 실행하는 사람이 결정적이다. 비즈니스 레벨에서는 결국 권한을 가진 사람들의 역할이다. 여기서 세번째 이유와 연결된다.

셋째, 데이터 비즈니스가 실패하는 결정적인 이유는 많은 회사(경영진)들이 데이터 비즈니스를 지속시킬 의지가 없다는 거다. 아닌 말로 데이터가 없으면 지금부터 수집하면 되고 인력과 기술이 부족하면 채용하거나 오픈소스를 잘 이용하면 된다. 하지만 데이터 비전과 의지는 다른 차원의 문제다. 데이터 비즈니스는 겉절이 김치가 아니라 1~2년 묵힌 김치다. 단기간에 가시적인 성과를 내지 못할 수도 있다는 얘기다. 그리고 계속 실패하면서 방향을 수정하고 다른 시도를 계속해야 한다. 데이터 과학이라고 말하지만 똑부러진 법칙과 이론이 존재하는 과학이 아니라 실험과 검증의 지나한 과정을 거치는 방법론적 과학이다.

데이터 비즈니스를 하겠다고 선언을 했으면 지원을 하고 (인력을 보강해서 팀을 꾸리고 인프라를 구축하는 등), 그리고 인내해야 한다. 퀀텀 점프하듯이 바로 눈에 띄는 효과를 보이는 경우도 있지만, 대부분은 등락을 거듭하면서 서서히 점진적으로 효과가 나온다. 보통 경영진들도 계약직으로 단기 성과를 내야하는 사람들이기 때문에 짧게는 분기나 반기, 길게는 1~2년 내에 성과를 보여줘야 한다. 그러나 데이터 비즈니스는 그렇게 번개로 콩을 구워먹는 게 아니다. 의지를 가지고 장기적인 플랜에 따라서 하나씩 해결해야 겨우 성과가 나온다. 물론 얼마나 스마트하냐에 따라서 성과의 시기와 크기에 영향을 주겠지만…

데이터 비즈니스가 중요하다는 것은 이제 모두가 잘 안다. 하지만 그걸 성공하는 기업은 여전히 소수다. 데이터 비즈니스를 하겠다는 회사들은 먼저 의미있는 데이터를 확보하고 적정 기술을 가진 인력을 보강했다면, 의지와 인내를 가지고 멀리 보면서 실행하기 바란다. 현재는 직원으로서 카카오가 그랬으면 하는 것이 개인의 바람이고, 카카오를 떠나서 (Beyond Kakao, not leaving Kakao) -- 여전히 내가 데이터 과학을 하는 사람인지는 모르겠으나 오랫동안 데이터를 보는 것을 업으로 했던 사람으로서 -- 그런 조직의 일부가 된다면 기쁠 거다.


=== Also in...

F: https://www.facebook.com/unexperienced

댓글을 달아 주세요

Share           Pin It
데이터 과학 Data Science 또는 데이터 과학자 Data Scientist에 대해서 검색해보면 아래의 다이어그램 또는 비슷한 설명을 필히 보게 된다. 데이터 과학자는 프로그래밍 능력과 수학과 통계에 대한 지식과 도메인/비즈니스에 대한 이해가 있어야 한다는 내용이다. 물론 이 세가지 영역에서 모두 또는 특정 영역에서 확연히 뛰어나면 좋겠지만 전문 개발자들보다 프로그래밍에 능할 수 없고 수학만 파고든 사람들이나 한 분야에서 수년간의 경험을 쌓은 이들보다 더 뛰어날 수가 없다. 그러나 이 세분야에서 고른 지적 능력을 가져야 함을 부인할 수 없다. 

데이터 과학자는 어떤 능력이 필요한가? (출처. Quora, 아래링크)


데이터 과학에 대해서 더 자세히 알고 싶은 이들은 다음의 Quora 쓰레드를 참조하면 된다.

오늘 글을 적는 것은 단순히 위의 다이어그램을 소개하거나 각 영역에 대해서 자세히 알려주기 위함이 아니다. 페이스북을 통해서 수학을 전공하는 어느 대학생이 금융공학에서 데이터마이닝을 해보고 싶다는 진로 상담을 해왔는데, 질문을 제대로 읽지 않고 바삐 출근하는 길에 잠시 생각했던 생각을 적으려는 것이다.

질문을 제대로 읽기 전에는 이 세 영역의 중요성을 말해주면서 지금 어차피 수학을 전공하고 있으니 어떻게 해서라도 프로그래밍 언어 하나 정도는 마스터하라는 조언을 해줄 참이었다. 그리고 비즈니스/도메인 지식을 습득하는 것이 가장 중요하지만, 이것은 학부 과정 학생이 쉽게 얻을 수 있는 것도 아니고 나중에 대학원에 진학하거나 취직을 해서 여러 프로젝트에 참여하고 경력을 쌓다보면 자연히 얻게 되는 것이다정도로 조언을 해줄 참이었다. 물론 질문의 요지는 이게 아니었기 때문에 다른 대답을 해줬지만...

그런데, 프로그래밍, 수학/통계, 그리고 도메인 지식… 이 세 영역의 의미를 다시 생각하면서 데이터 과학에 대한 생각이 좀더 발전했다. 첫째, 수학/통계 지식은 데이터 과학의 원리나 기초를 제공해주는 것 같다. 소위 말하는 데이터 분석 또는 마이닝에서 (고급) 수학이 핵심이 되지 않는 경우가 많기는 하지만 -- 특히 데이터가 충분히 많은 경우 --, 적어도 데이터에 내재한 패턴/의미를 이해하는데 기초 수학과 통계는 원리적 가이던스를 제공하다.

둘째, 프로그래밍은 데이터 과학의 실행을 담당한다. 요즘은 많은 통계 및 분석 패키지나 오픈소스가 존재하기는 하지만, 여전히 많은 경우 코딩이라는 행위가 이뤄져야 한다. 수학 지식만으로 많고 다양한 데이터 속의 패턴과 의미를 밝혀낼 수가 없고, 많은 도메인 경험은 중요한 인사이트를 주지만 인사이트가 결론이 될 수가 없다. 결국 인사이트를 검증하기 위해서 데이터를 하나하나 캐나가는 과정이 필요한데 그 과정이 결국 코딩/프로그래밍의 도움없이 이뤄지지 않는다. 멋진 툴들이 이런 과정을 쉽게 해주기도 하지만, 아직 만능의 툴은 없다. 손으로 직접 해봐야 한다. 코드를 한 줄씩 짜가면서 실행해야 한다는 거다.

세째, 도메인 또는 비즈니스 지식은 경험이다. 이 경험이라는 것이 문제 (도메인)에 대한 경험일 수도 있고, 방법(분석/마이닝)에 대한 경험일 수도 있다. 그리고 앞서 말했듯이 경험은 인사이트라는 결실을 맺는다. 뛰어난 추론 능력과 실행 능력이 있더라도 인사이트가 없으면 삽질의 연속이다. 물론 그런 삽질을 통한 경험이 유능한 데이터 과학자를 만들어낼 수도 있지만… 내가 풀어야 하는 문제를 잘 이해하는 것 그리고 그걸 풀어가는 과정을 빨리 파악하는 것은 경험이 주는 귀한 선물이다.

위의 다이어그램은 데이터 과학을 설명하는데 유용하지만, 한가지 빠진 게 있다. ‘데이터’에 대한 직접적인 내용이 없다는 점이다. 도메인이 데이터를 약간 내포하고 있지만 명시적으로 데이터의 중요성이 그림에 나타나지 않는다는 거다. 데이터를 다루는 수학, 데이터를 다루는 프로그램밍, 데이터를 다루는 경험은 그냥 수학과 코딩과 도메인과 다를 수가 있다.

그리고, 수학/통계와 프로그래밍이 만나서 — 다이어그램에서는 ‘머신러닝'이라 표현했지만 — 알고리즘이 나온다. 데이터 분석 업무에서 (고급) 알고리즘이 불필요한 경우가 허다하지만 어쨌든 수학과 프로그래밍 양쪽을 마스터해야지 제대로된/쓸만한 알고리즘을 만들 수 있다. 그리고 이 알고리즘과 도메인 지식이 결합해서 일종의 지혜가 된다. 뭐, 그냥 데이터 지식이라고 말해도 된다. 데이터 과학은 결국 원리와 실행과 경험이 만나서 지혜를 구축해나가는 학문이다. 끊임없이...

===
F: https://www.facebook.com/unexperienced


댓글을 달아 주세요

Share           Pin It
다음 검색에서 '데이터마이너'라는 검색어가 갑자기 많이 들어온 날이 있었다. 강풀 작가의 '마녀'라는 작품 속에서 PC 캡쳐 화면과 함께 주인공이 데이터마이너가 됐다라는 짧은 문구가 등장했던 때다. 해당 캡쳐 화면에는 SAS라는 데이터분석툴 아이콘도 있었고 지금은 없어진 마이피플 아이콘도 등장했다 (유료화로 화면캡쳐는 생략. 9화였음.). 강풀 작가님이 웹툰을 그리기 위해서 예전 같은 팀의 팀원에게 자문을 얻었는데, 그 분의 (의도된) PC화면으로 유추된다. 당시에 내가 서울에서 근무했다면 미팅에 함께 참석했지 않을까?라는 생각도 해본다.

빅데이터, 데이터 사이언스, 인공 지능, 딥러닝, 머신러닝 (기계학습) 등의 많은 용어/개념들이 버즈buzz되고 있지만 관련 분야의 사람들이 아니라면 여전히 데이터마이닝 또는 데이터마이너라는 용어가 생소한 것 같다. 그래서 데이터마이닝/너에 대한 지극히 개인의 의견을 적으려 한다.

데이터마이너는 무엇을 하는 사람인가? 데이터를 보는 사람이다. 왜 데이터를 보는가? 데이터에 내재한 패턴 pattern을 찾거나 규칙 rule을 만들기 위해서다. 그런 패턴이나 규칙은 왜 찾고 만드는가? 문제를 해결하기 위해서다. 그렇다. 내가 생각하는 데이터마이닝은 여러 문제와 관련된 데이터를 관찰함으로써 규칙을 찾고 적용해서 문제를 해결하는 것이다. 문제를 해결하는 접근법은 다양하겠지만 데이터에 근거를 둔다는 점에서 다른 것들과 차별점이다. 물론 데이터가 데이터마이너만의 것은 아니다.

문제를 해결하기 위해서 데이터를 본다라고 표현했지만 때로는 문제를 찾아내기 위해서 데이터를 보는 경우도 종종 있다. 즉, 주어진 문제를 해결하기 위해서 근거 데이터를 수집하고 추론하는 것도 마이너의 일이지만, 이미 가진 데이터에서 시스템에 내재된 문제점을 찾아내는 것도 마이너의 역할이다. 그래서 단순히 수학적, 공학적 기술/기법 뿐만이 아니라, 다양한 경험과 (잡) 지식이 마이너에게 요구된다. 마이너가 활용할 수 있는 데이터는 단순히 시스템 구동에 필요한 데이터 (보통 DB나 텍스트 형태)나 시스템이 찍어내는 로그에만 한정된 것이 아니다. 

머신러닝 (또는 인공지능)은 데이터마이닝과 밀접한 관계가 있지만 같다라고 말하기는 어렵다. 밴다이어그램을 그린다면 상당한 공통 영역이 존재하지만 또 다른 영역이 분명 있다. 머신러닝은 특정 미션을 완수하기 위해서 근거 데이터로 학습시켜서 모사하는 것이 목적이다. 주어진 데이터 이상의 추론이 가능하다면 인공지능이라고 불러도 좋다. (Exploitation vs Exploration) 머신러닝/인공지능은 '기계를 사람처럼'이 모토이자 목적이다. 데이터마이닝은 많은 머신러닝 기술을 활용하지만 엄격함을 요구하지는 않는다. 인간 친화적이라고 표현하면 좋을 듯하다. 머신러닝에 일부러 모호함을 추가하는 연구도 진행되고 있지만...

데이터마이닝을 잘 하기 위해서 다양한 수학, 통계 지식이 필요하고, 고도의 알고리즘들도 만들어졌다. 그러나 그런 지식이나 알고리즘은 데이터를 잘 보기 위한 보조 기능을 하는 것일 뿐이다. 많은 지식과 알고리즘을 알고 있다고 뛰어난 데이터마이너가 되지는 않는다. 데이터를 잘 보는 능력과 그걸 돕는 기술을 많이 아는 것은 분명 같지 않다. 원시적이지만 -- 한계도 분명한 -- 텍스트나 엑셀의 테이블에 펼쳐진 (적은/제한된 양의) 수치나 데이터를 눈으로 확인해서 패턴/규칙을 발견할 수 있다면 HDFS에 쌓인 수 테라바이트의 데이터를 고도의 알고리즘으로 확인하는 것보다 더 낫다. 좀 극단적으로 표현했지만, 데이터마이닝은 기계가 이해하는 규칙이 아나라 사람이 이해하고 설명가능한 규칙을 찾는 것에 더 가깝다고 생각한다. (엄격함을 덜 요구한다는 의미도 이의 연장선에서 말한 것이다.)

R이나 SAS 등의 통계분석툴이나 파이썬이나 자바같은 프로그래밍 언어, 또는 Mahout이나 Spark MLlib 같은 (오픈소스) 라이브러리에 능한 것도 데이터마이너의 필수 덕목이 됐지만, 데이터를 보는 눈이 없다면 무용지물이다. 파리를 잡기 위해서 소잡는 칼을 휘두르는 모양새다. 수학이나 알고리즘 지식, 그리고 프로그래밍 스킬보다 도메인 지식 또는 비즈니스 로직을 개인적으로 더 중요하게 생각하는 이유도 데이터가 만들어지고 활용되는 곳을 잘 알아야지 데이터를 더 잘 볼 수 있기 때문이다. 물론, 때론 도메인 지식 (또는 지식 편향)이 데이터를 객관적으로 보는 것에 장애가 된다. 수학/통계/알고리즘과 프로그래밍 스킬, 그리고 도메인 지식은 데이터마이너가 되기 위한 일종의 트리니티라서 고른 역량이 필요하지만, 그렇지 않다면 각각의 능력을 가진 사람들을 모은 그런 팀을 구성하는 것이 필요하다. (그리고 모든 개발자들이 그렇듯이 영어를 읽고 이해하는 능력인 필수다. 유학 또는 취업으로 외국에 가지 않는 이상 영어를 듣고 말하고 쓸 기회는 별로 없지만 영어 문서를 읽어야할 일은 흔하다.)

수학이나 프로그래밍보다 도메인 지식이 더 중요하다고 얘기하는 가장 큰 이유는 우리가 일상에서 만나는 마이닝 문제 또는 해결책이 그렇게 복잡하지 않다는 점이다. 아주 간단한 연산으로 해결되는 경우가 많다. 물론 음성 인식이나 이미지 처리, 기계 번역과 같이 복잡한 태스크를 해결하기 위해서 사용되는 다양한 딥러닝 및 관련 기술들을 온전히 이해하고 구현하기 위해서는 수학과 프로그래밍 스킬이 필요하다. (딥러닝이 구조적으로 복잡해 보이지만 요소요소를 보면 사실 복잡한 연산은 아니다.) 하지만 일상에서 데이터를 가지고 하는 문제들은 그저 데이터를 연결하고 순위를 매기는 것에 불과한 경우가 허다하다. 대표적으로 추천 및 개인화 시스템이라는 것도 아이템과 아이템, 사용자와 아이템, 그리고 사용자와 사용자를 잘 연결시켜서 기준에 따라서 정열해서 상위 N개를 보여주는 것에 불과하다. 특히 독립적인 데이터 샘플이 많아지는 경우라면 더더욱 그렇다. 정성적인 추천의 품질을 가르는 것은 결국 도메인 지식이다. (정량적 지수는 다를 수 있다.) 흔히 말하는 클러스터링, 클래시피케이션 및 레그레션 등의 모든 개념들도 결국 데이터를 연결하고 나열하는 것, 또는 이를 잘 하도록 돕는 것 그 이상도 이하도 아니다.

야구 투수에 비유하면, 데이터마이너의 특기는 강속구가 아니라 제구력이다 (Control Artist). 데이터마이너는 데이터를 보는 사람이고 데이터에서 규칙을 찾는 사람이라는 정의의 연장선에서 생각하면 된다. 완벽한 모델을 찾고 모든 파라메터를 자동으로 최적화하려는 것도 연구의 한 축이겠지만, 여전히 대부분의 알고리즘들이 사람의 손을 타기 마련이다 (Human Intervention). 만능의 인공지능이 등장하지 않은 이상, 어떤 모델 또는 방법론을 선택하고 필요한 다양한 파라메터를 얼마나 잘 설정하느냐가 평범한 마이너와 좋은 마이너의 차이를 가른다. 도메인 지식과 경험이 중요하다는 이유도 제어 능력의 차이를 주기 때문이다. 딥러닝과 같은 강력한 한방 (강속구)를 가졌더라도 제어 능력이 없으면 의미가 반감된다.

데이터 엔지니어도 아닌 사이언티스타라는 사람의 입에서 경험 (또는 경험에 따른 감 — 고급지게 표현해서 인사이트)이 중요하다고 말하는 것이 참 이상할 법하다. 그건 내가 사이비라서 그렇기도 하지만, 실제 그렇기 때문이다. 문제 상황에서 가설을 세우고 데이터로 검증하기 때문에 데이터 사이언스라 불린다. 문제를 인식하고 적절한 가설을 세우고 실험 계획을 통해서 필요한 데이터를 모으고 분석 및 검증으로 얻은 결과를 해석해서 액션을 취하는 일련의 과정이 필요하다. 매우 간단한 과정이지만 이를 어떻게 실행하느냐에 따라서 투입되는 비용과 시간, 반복 그리고 승패가 결정된다. 이때 필요한 것이 -- 천재가 아닌 이상 -- 경험이다. 어차피 초보 마이너나 베테랑 마이너가 가지고 있는 기본 기술셋은 비슷하다.

이전 글에도 적었지만 데이터 문제가 아주 정확한 모델과 설정값을 요구하는 것 같지만 대부분의 경우 설명하기 쉬운 단조로운 모델과 설정하기 쉬운 근사값이 필요한 경우가 많다. 그리고, 경험이 쌓인다는 것 그리고 감이 생긴다는 것은 그저 오랜 시간동안 많은 데이터를 다뤘다고 해서 얻어지는 것은 아니다. 어쩌면 내가 이 글을 적으면서 그냥 데이터마이너라고 적었지만 실제 의미는 시니어 데이터마이너를 뜻했던 것 같다. 그냥 기계적으로 데이터를 분석하는 사람이 아니라 데이터로 생각하고 데이터와 함께 숨쉬는 사람을 생각했던 것이다. 오해를 막기 위해서 경험은 깊은 수학적 지식과 다양한 프로그래밍 연습 위에 쌓인다.

훌륭한 데이터마이너는 데이터를 잘 보는 사람이다. 특별한 재능과 기술을 가진 사람이 아니라 그저 데이터 위에 노는 사람이다.

P.S., 딱 4년 전인 2012년 3월 9일에도 같은 제목의 글을 적었습니다. http://bahnsville.tistory.com/546

===
B: https://brunch.co.kr/@jejugrapher
F: https://www.facebook.com/unexperienced


댓글을 달아 주세요

Share           Pin It
오랫동안 데이터 관련 업무를 해왔지만, 관련된 모든 것을 완벽하게 알고 있는 것은 아니다. 그저 일을 하면서 느낀 의견일 뿐이고, 어쩌면 다른 많은 데이터 분석가들은 동의하지 않을지도 모른다.

많은 일반인들은 데이터는 매우 정확한 것이다라는 인식을 가진 것같다. 특히 일반 개발자들과 일을 하다보면 대략적인 데이터 관련 로직/알고리즘을 스케치해서 알려주면 세세한 부분까지 내가 알려줬던 내용을 그대로 구현하려는 경향이 있다. 데이터 관련 전문성/경험의 부족에 따른 것일 수도 있고, 그냥 시각의 차이일 수도 있다. 데이터 분석의 결과는 매우 정확하고 그것을 반드시 따라야 한다는 생각을 가졌는지도 모른다.

그런데 분석 업무를 하다보면 엄격하게 정확한 데이터에 기반해서 의사를 결정하기도 하지만, 많은 경우 분석가의 감이나 경험에 의존하기도 한다. 해결해야할 문제를 검토하고 관련된 데이터를 수집하다 보면 대강 이렇게 로직을 만들고 이정도의 파라메터를 설정하면 된다는 그런 감 또는 경험치가 있다. 데이터가 보여주는 완벽한 궤적의 함수를 구하기 보다는 그냥 대강 SQRT를 씌우거나 LOG를 취하는 등의 데이터 변형을 시켜서 적용해 본다. 예를들어, scale-free 네트워크에서 빈도는 폭발하기 때문에 그런 종류의 시스템에서 나온 데이터라면 그냥 LOG를 취한다는 거다. 적당히 값을 키우고 싶을 때는 그냥 제곱을 적용해보고 더 급격히 증가하는 걸 원하면 세제곱을 해보기도 한다. 그런 경험치 함수를 적용해서 로직을 개발하는 경우가 많다. 실제 데이터가 그렇게 말해주기 때문에 그런 수식/로직이 나오지 않을 때가 많다는 거다.

대략적인 로직을 정해서 구현할 개발자들에게 알려줄 때, 어떤 변수의 범위가 필요할 때 특정 값을 지정해주는 경우도 있지만 대략 10정도보다 크면 된다라고 말하는 경우가 있다. 사실 11이 좋을지 9가 더 좋을지 나도 모른다. 그냥 안전한 수치를 정하는 것이고, 또 실제 구현해서 테스트하면서 11이 더 좋은 것 같으면 그냥 11로 해도 된다는 의미도 있다. 그런데 최종적으로 구현된 것을 보면 무조건 '10'으로 고정돼있는 걸 본다. 물론 데이터를 보고 값을 정해서 알려주는 것이 내 역할이기는 하지만, 상대방에게 자유도를 주기 위해서 대략적인 걸 말하는데 상대는 그렇지가 않은 것같다. 정확한 스펙과 순서를 요구한다.

아주 미세한 차이가 큰 (역)효과를 내는 분야가 있다. 달에 우주선을 쏘아올리는 경우 0.01도를 잘못 적으면 그 우주선은 우주 미아가 될 수도 있다. 그런데, 현실에서 우리가 만나는 많은 데이터 문제들이 그렇게 세밀하지가 않다. 하루에 '데이터'라는 쿼리가 1000번 들어오는 것과 1001번 들어오는 것은 별로 큰 차이가 없다. 광고 CTR을 0.1%를 올리는 것은 매출에 큰 영향을 준다. 그러나 광고 노출에서 어떤 조건을 10을 두는 것과 10.1 또는 11로 두는 것에 따라서 실제 광고 CTR이 0.1% 이상 차이가 나는 경우가 많지가 않다. (물론 중요한 변수인 경우는 차이를 낼 수도 있고, 여러 변수들이 복합적으로 작용해서 예상치 못한 결과를 줄 수는 있다. 그러나 그렇게 중요한 변수라면 이미 잘 통제되고 있거나 더 정확한 실험 등으로 값을 특정했을 거다.)

그리고 현실에서 정확한 수치가 아닌 것을 원하는 경우가 있다. 예를들어, 최적화 문제/식을 잘 풀었더니 X = 10.56이 나왔다고 치자. 그런데, 원래 문제의 도메인이 정수형이었다면, 즉 Integer program이었다면 10.56은 틀린 답이다. 10이나 11이 돼야 한다. 만약 제고관리나 생산관리 등에서 오늘 하루동안 완성해야하는 자동차의 대수가 100.56대가 나왔다면 100대를 만들고, 나머지 한대는 0.56만큼 미완성품으로 만들어둬야 하는 게 아니다. 이런 경우 하루에 100대를 생산하거나 101대를 생산하라고 명령이 내려져야 한다. (반제품 상태로 나둬도 되는 경우라서 조금 모호하긴 하다.) 최적화 식을 통해서 내일 컴퓨터 8.4대가 필요하다는 값이 나왔다면 당연히 9대를 가져올 거다. 극단적인 예처럼 보이지만, 현실에서는 정확한 수치보다는 그 상황에 맞는 그럴 듯한 수치가 필요한 경우가 많다.

데이터를 다루는 사람들은 늘 직관의 선물을 감사히 받아들여야 한다. (다음 이야기에서 정확한 분야나 숫자는 의미가 없다) 초보 분석가가 며칠동안 고생해서 8.347이라는 해를 구했는데, 상사는 그냥 빈둥거리며 놀다가 한 8.5정도 나오지 않을까?라고 직관적으로 얘기하는데 어렵게 구한 값과 별로 차이가 없었다 등의 풍문이 많다를. 직관/경험이 맞고 데이터가 틀렸다는 얘기가 아니다. 데이터가 주는 정확함에 너무 집착하지 않았으면 한다는 얘기다. 초기의 미세한 차이가 향후에 큰 차이를 만들어낼 수도 있다. 그런 경우라면 중간에 변화의 폭이 커지는 사이에 조정을 해주면 되는 것이지 처음부터 엄격할 필요는 없다. (물론, 중간에 미세 조정이 불가한 경우도 있겠지만...) 그리고 데이터가 정확하다고 믿겠지만, 데이터 내에 부정확함을 내포하기 때문에 데이터가 거짓은 아니지만 진실을 얘기하지 않는 경우도 많다. 어차피 대부분의 분석은 모집단 전체가 아니라 (편향될 수 밖에 없는) 샘플을 사용한다. 빅데이터도 데이터가 많아져서 부정확함을 상쇄시킬 가능성이 높아진 것이지, 데이터 자체의 부정확함은 여전히 존재한다. 그리고 머신러닝에서 사용하는 대부분의 알고리즘도 처음에는 랜덤에서 시작하기도 하고, 같은 데이터로 여러 번 같은 프로그램을 돌려도 다른 결과값을 내주기도 한다. (물론 그런 랜덤성을 최대한 없애고 결과의 일관성을 확보하도록 알고리즘이 발전하고 각종 트릭들이 보완되는 거다.)

부정확함은 어느 곳에든지 존재한다. 그렇기 때문에 데이터는 정확하다는 것은 일종의 미신이다. 처음에는 모호함이 주는 자유를 즐겨라라는 것을 적고 싶었는데, 뒤로 갈수록 뉘앙스가 달라졌다. 개발자들은 데이터 전문가들을 무조건 믿지는 말아야 한다. 엄격한 것이 틀렸을 가능성이 더 높다.

===
B: https://brunch.co.kr/@jejugrapher
M: https://medium.com/jeju-photography
F: https://www.facebook.com/unexperienced

댓글을 달아 주세요

기술과 인간

Gos&Op 2014.08.12 18:09 |
Share           Pin It
"길게 잡아서 2년 내에 당신이 하고 있는 일의 절반 이상을 자동화시킬 수 있어야 한다."

최근 함께 일하고 있는 친구에게 한 말입니다. 미디어다음에서 뉴스를 편집운영하면서 뉴스추천 프로젝트를 메인으로 기획한 친구입니다. 제대로 된 뉴스 편집 및 운영은 끊임없이 쏟아지는 모든 뉴스를 읽고 미담이나 다음탑에 노출시킬 것인가 말것인가를 계속 판단해야 하는 사람손을 많이 타는 일입니다. 그럼에도 불구하고 이 활동의 절반 이상을 단기간 내에 자동화시키고 그 친구는 다른 더 창의적인 생각에 집중해야 한다는 말입니다.

비단 이 친구에게만 들려주고 싶은 말은 아닙니다. 지난 글(참고. 기획에 대해서)에서처럼 함께 일하고 있는 모든 기획자들에게 같은 조언을 해주고 싶습니다. 물론 개발자라고 해서 예외는 아닙니다. 성격이 조금 다를 뿐 허투루 허비하는 많은 잡다한 일들은 자동 영역에 맡기도 늘 새롭고 창의적인 사고, 실행에 집중해야 합니다. 2년이란 시간도 길게 잡은 것입니다. 그만큼 절박한 생존의 문제입니다.

흔히 자동화를 통해서 기계 또는 컴퓨터가 사람을 완전히 대체해버리는 것을 생각합니다. 지구 상의 누군가는 그런 완전무결한 자동화를 꿈꾸고 실현하기 위해서 연구하고 있을 것입니다. 그들의 노력에 찬사를 보내고 좋은 결실을 맺을 것을 바랍니다. 설령 그렇게 되어 내가 할 수 있는 일이 없어진다고 해도 그런 현실을 받아들일 자세가 되어있습니다. 그러나 이 글에서 자동화란 사람을 완전히 대체하는 로봇을 얘기하는 것은 아닙니다.

데이터 마이닝이라는 파트에서 일하다 보니 사람들은 데이터 마이닝을 좀 경외의 대상으로 생각하는 것같습니다. 뭔가 복잡하고 어려운 분야라고 생각합니다. 그래서 회사에서 데이터마이닝/분석을 한다고 말하면 데이터마이닝에 대해서 조금 더 관심을 보이기 전에 손사레를 치고 외면해버립니다. 그러고선 이제껏 편하게 해왔던 일로 돌아섭니다. 그런 두려움과 미신이 저같은 허름한 분석가를 (분석가의 역할을) 보호해주는 것같아 내심 안도하면서도 조금 씁쓸하기도 합니다.

어떤 측면에서 학계를 중심으로 발전시킨 데이터마이닝은 조금 복잡하기도 합니다. 일상에서 전혀 들어볼 수 없는 어려운 용어들로 가득 차있고, 하나의 개념이나 알고리즘을 이해하기 위해서는 선행해서 알아야 하는 지식이 한가득입니다. 그리고 어떤 측면에서는 연구가들은 일부러 더 어려운 용어를 만들어내고 간단한 설명도 복잡한 수식으로 표현하는 것같습니다. 학교에서 농담삼아 얘기했던 건데, 복잡한 증명문제를 그저 'It's trivial'이라고 말하고 증명을 생략하는 경우도 있습니다. 논문 하나를 이해하기 위해서 엮인 많은 논문을 읽어야 하고, 그 참조 논문들을 이해하기 위해서 또 엮인 것들을 읽어야 합니다.

사무실이 조금 추운 것같아서 건물 밖을 한 바퀴 돌면서 생각했습니다. 어쩌면 정작 사람들에게 필요한 기술은 정교하고 복잡한 알고리즘이 아닐 수 있다는 생각입니다. 서두에 말한 자동화도 그렇습니다. 내가 하고 있는 일을 완전히 대체하는 개념의 자동화가 아니라, 내가 하고 있는 일을 더 빠르고 편하게 도와주고 그렇게 해서 절약한 시간을 다른 곳에 집중할 수 있게 해주는 그런 종류의 자동화입니다. 

데이터 기반의 기획이 그렇습니다. (당장은) 아무리 좋은 알고리즘을 개발하더라도 기획자의 역할을 완전히 대체할 수 없습니다. 그러나 적당한 데이터 가공만으로도 그들의 잡다한 수고를 덜어줄 수가 있습니다. 기획자가 자신의 일의 50%이상을 자동화해야 한다는 의미도 어떤 제품/서비스를 만들어낼 것인가만 고민할 것이 아니라, 어떤 도구나 데이터가 있으면 내가 만들고자 하는 서비스/제품을 미리 검증해보고 상상하는데 도움이 될 수 있을까를 고민하는 것입니다. 그런 고민으로 자신의 일을 경감시켜줄 데이터나 도구를 마련한다면 2년 후에는 한차원 높은 기획자가 돼있으리라 생각합니다.

서비스를 준비하면서 여러 논문을 다시 찾아봅니다. 참 읽기 어렵습니다. 인트로까지는 쉽게 읽게는데 그 이후는 내가 논문을 읽고 있는 것인지 아니면 그냥 시간을 보내는 것인지 분간할 수 없는 때가 종종 있습니다. 이런 경험이 쌓여갈수록 내가 만들어내는 알고리즘도 복잡한 수식으로 이뤄진 거창한 무언가가 돼야 한다는 헛생각에 사로잡히기도 합니다. 그러다 보니 간단하게 해결할 문제를 이것저것 새로운 요소들을 갖다붙여서 복잡한 솔루션으로 만들어 냅니다. 마치 알고리즘/솔루션의 복잡함이 나의 위대함을 나타내는 증거인양... 그렇게 해서 큰 효과가 있다면 다행이지만, 그저 간단한 수식이나 몇몇 요소로 해결했을 때보다 더 나아졌다는 보장이 없는 경우가 많습니다. 그래서 간단한 기술, 쉬운 알고리즘이 더 사람에게 필요한 것일 수 있다는 생각으로 다시 돌아왔습니다.

요즘 빅데이터 기술로 인해서 난해한 문제나 알고리즘을 사용할 수 있게도 됐지만 (예를들어 최근 많은 관심을 받는 딥러닝 Deep Learning같은), 오히려 간단한 더하기, 빼기, 곱하기, 나누기 즉 사칙연산만으로도 많은 문제들이 해결되고 있습니다. 그리고 간단한 알고리즘/연산으로 빠른 시간에 해결하는 것이 조금 더 정확한 예측보다 더 유용할 때가 많습니다. 엔지니어링이란 복잡함을 감추는 과정이지만 그것 자체도 굳이 복잡할 필요는 없습니다.

글을 적으면서 여러 논점이 섞였습니다. 기술은 필요에 따라서 복잡해질 수 있습니다. 그 복잡함을 재고하고 정작 인간에게 필요한 것이 뭘까를 고민하게 됩니다.

기술은 인간을 대체하는 것이 아니라 보완합니다. 미리 겁먹을 필요는 없습니다.

==
페이스북 페이지: https://www.facebook.com/unexperienced


댓글을 달아 주세요

Share           Pin It
과학자는 자신이 가진 솔루션을 적용할 문제를 찾고 엔지니어는 자신의 문제를 해결할 솔루션을 찾는다라는 말로 과학(자)과 엔지니어링을 구분한 글을 본 적이 있다. 적절한 구분인 것같다. 데이터 분석/마이닝도 같은 관점에서 구분할 수 있을까? 문제에 맞는 솔루션을 찾는 사람은 데이터 마이너고, 알고리즘에 맞는 문제를 찾는 사람은 데이터 사이언티스트라고 부를 수 있을까? 별로 좋은 구분인 것같지 않다.

최근 빅데이터나 데이터 사이언스 등에 관심이 조금 쏠리고 데이터 기반의 무엇 (Data-driven X)이라는 표현을 자주 접하게 된다. 선무당이 사람잡는다는 말도 있지만, 데이터와 연결된 용어들이 범람하면서 데이터 선무당들도 많이 늘고 있는 것같다. 간혹 지난 몇 년동안 엄청나게 많은 데이터를 모아놓았는데 이걸로 빅데이터 분석할 수 있지 않을까요?라는 류의 질문을 받곤 한다. 가혹 (데이터 분석의 생리를) 알만한 사람들도 비슷한 요청을 한다.

앞서 엔지니어와 과학자를 구분하면서 문제와 솔루션 중 어느 것에 익숙한가로 정했다. 데이터 마이닝이 과학이냐 엔지니어링이냐를 구분하기는 문제와 솔루션이 적당한 측도는 아니지만, 데이터를 접근하는 방식에 대해서는 좋은 설명이 될 것같다. 데이터 마이닝은 문제와 솔루션 사이에 데이터가 존재한다. 데이터가 문제와 솔루션 사이를 연결한다고 봐도 좋다. 그래서 크게, 문제(서비스)에 맞는 데이터를 수집해서 적당한 솔루션을 찾는 방향과 솔루션이 적용될 문제를 찾아서 데이터 인사이트를 얻는 방향이 있을 수 있다. 서비스에 익숙한 사람이라면 나이브하더라도 그것에 맞는 알고리즘을 찾아서 적용해보고 필요하면 더 나은 알고리즘을 찾거나 기존 것을 개선하면 된다. 반대로 알고리즘에 익숙하다면 서비스를 조금씩 이해하가면서 자신의 솔루션을 끼워넣으면 된다. 일반적으로 그렇다는 얘기다.

다른 접근법이 있기는 하다. 주변에서 흔히 접하는 것인데, 가장 이해하기 힘들고 피했으면 하는 접근법이다. 앞서 말했듯이, 우리한테 데이터가 많이 있으니 괜찮은 서비스 하나 만들어볼까요?라는 접근이다. 데이터만 (많이) 있으면 서비스가 하늘에서 뚝 떨어진다는 생각이다. 그래서 많은 경우 데이터 접근법이 실패한다. 모든 것은 컨텍스트 내에서 정의된다. 데이터의 컨텍스트는 서비스다. 유능한 사람은 데이터 더미에서 인사이트를 얻을 수 있겠지만, 나같은 범인은 그러지 못한다. 데이터가 많다고 데이터 기반의 실행이 이뤄지는 것이 아니다.

그리고 이런 경우 데이터가 많기는 한데 데이터 분석에 바로 사용할 수 있는 것도 아니다. 그냥 언젠가 필요할 것같으니 다 모아두자는 식으로 데이터를 쌓아둔 경우가 대부분이다. 물론 많은 회사에서 그런 데이터조차도 관리하고 있지 않지만... 불필요하게 공간만 차지하는 필드들도 많고, 정작 필요한 데이터는 애초에 없는 경우가 많다. 데이터를 분석하고 적용하려면 처음부터 다시 데이터를 모으거나 필요한 형태로 가공해야 한다. 데이터가 잘 정립된 곳에서도 데이터를 가지고 새로운 분석을 하거나 서비스를 만들 때 5할은 데이터 정의/변환에 소요되는데, 그냥 데이터만 쌓아둔 경우라면 9할을 여기에 허비하게 된다. 그러면서 서비스를 이해하게 되는 경우도 발생하지만, 깔끔하지는 않다. 어디에 어떻게 활용할지에 대한 목적없이 데이터를 수집해서 분석가들을 힘들게 만들지 않았으면...

데이터에 맞는 문제, 데이터에 맞는 솔루션은 없다. 데이터가 왕이 아니라, 왕이 될 데이터는 따로 있다.

==
페이스북 페이지: https://www.facebook.com/unexperienced


댓글을 달아 주세요

Share           Pin It

(새벽에 문득 잠에서 깨어 이 글을 적는다.)

최근 데이터 또는 데이터 기반 접근법에 대한 관심이 뜨겁다. 어쩌면 내가 밥벌어먹고 살려고 또 내 몸값을 올리려고 이런 표현을 사용/전파하고 있는지도 모르겠다. 관련 뉴스를 보면서 과연 데이터 기반의 실행조직이라는 것이 실체가 있는 것인지? 아니면 그들도 자기들을 세일즈하기 위해서 억지로 기사를 쏟아내고 있는 것은 아닌지? 또는 구글이나 몇몇 잘 나가는 기업들이 데이터를 가지고 돈을 잘 벌고 있으니 그걸 부각시키고 과대포장하고 있는 것은 아닌지? 등에 대한 의문이 들기는 한다. 그런 의심은 일단 뒤로 하고, 데이터가 공기처럼 편재하고 있다는 것은 사실이다.

많은 기업들이 스스로 좀 더 가치있는 데이터를 생산해내거나 고객들로부터 그런 데이터를 수집하려고 노력중이다. 그러나 확실한 비전이나 전략을 가지고 실행하고 있는 것같지는 않다. 데이터는 21세기의 새로운 금맥, 보이지 않는 오일이다라는 식의 현혹된 멘트에 혹해서 우리도 지금 하지 않으면 뒤처져버리는 것이 아닐까?라는 두려움으로 새로운 골드러쉬, 아니 데이터러쉬에 합류하고 있다는 느낌이 강하다. 우리는 데이터에서 의미를 찾아내고 가치를 만들어가는 데이터 기반의 실행조직으로 다시 태어나겠노라고 선언하며 먼저 깃발을 꽂기 위해서 전진하지만 여전히 고지는 묘연하다. 과연 고지가 있기는 있는 것일까?

스스로 데이터 기반의 조직으로 변모하겠다고 내세우는 기업들의 공통된 실수 또는 인식은 ‘다양한 데이터를 많이 수집해서 데이터 사일로를 만들어놓으면 그 후에는 알아서 될 것이다 (데이터가 데이터를 만들고 궁극에는 돈이 될 것이다)’ ‘데이터 분석 인프라를 구축해서 적당한 데이터분석가들을 채용해서 자리에 앉히면 될 것이다’ 등이 아닐까?라는 생각을 해본다. 특별한 비전이나 실행 계획도 없으면서 그저 전문가들을 한 자리에 모아놓으면 그들이 알아서 뭔가를 만들어내겠지라는 안일한 생각으로 무턱대로 도전하는 것같다.

현실은 그렇게 녹록치가 않다. 단지 몇 명의 뛰어난 데이터 분석가들이 모여있다고 해서 데이터 기반의 실행조직이 만들어지지 않는다. 단지 조직 내에 전담 부서/팀이 구성되었다고 해서 만들어지는 것도 아니다. 분석가들은 언제나 실권이 없는 보조 수단에 불과했다. 변화의 동인이나 목표가 있어도 변화의 힘은 없다. 물론 그들에게 막강한 힘을 더한다고 해서 조직이 데이터 기반으로 재탄생할 수 있다는 얘기를 하는 것은 아니다. 그저 하소연일 뿐이다.

데이터 기반의 실행조직에서 가장 중요한 사람은 데이터 분석가가 아니다. 데이터에 접근할 수 있고 가공할 수 있고 해석할 수 있는 소수에 의해서 실행조직이 만들어지지 않기 때문이다. 조직 내의 모든 구성원들이 — 업무, 관점, 역량의 크기 등과 무관하게 — 데이터를 읽을 수 있고 믿고 움직일 때 가능하다. 경영자들의 의지와 지원이나 분석가들의 우수성 뿐만이 아닌, 전체의 공감대와 실행 문화가 형성되어있지 않다면 아무리 데이터를 통해서 많은 돈을 벌고 전략을 실행한다고 하더라도 그 조직을 데이터 기반이라고 부르기 어렵다.

Data is everywhere and utility. 데이터는 모두의 것이다. 특정 소수만의 특권이 아니다. 모두가 자유롭게 데이터에 접근할 수 있어야 하고, 그것을 분석하고 해석하는 능력을 가져야 한다. 먼저 빨대를 꽂으면 된다.

데이터마이닝에 대한 잘못된 오해가 있다. 마이닝이라는 말에서 오는 오해인지도 모르겠다. 땅 속에서 금맥을 찾아내고 진흙 속에서 진주를 찾아내는 것이 마이닝이 아니다. 금과 진주만 가치가 있고, 흙은 무가치한 것이다라는 인식이 바뀌어야 한다. 데이터는 진흙과 진주가 썩여있는 것이 아니다. 모든 데이터는 그저 흙이며 또 진주다. 마이닝은 단지 그 진주를 닦아서 광을 낼 뿐이며, 흙을 뭉쳐서 벽돌을 만들 뿐이다. 의미를 더하고 가치를 부여할 때만이 의미있는 데이터가 되고 데이터가 스스로 가치를 준다. 흔히 시그널과 노이즈를 말한다. 시그널은 취하는 것이고 노이즈는 버리는 것이다라는 의미다. 그러나 노이즈이도 다른 형태/의미의 시그널일 뿐이다. 물론 시그널 데이터와 노이즈 데이터를 가공하는 공임이나 최종 가격이 같다는 의미는 아니다.

Data-mining is data-meaning. 이름을 불러 줄 때 비로소 꽃이 된다.

소위 데이터 전문가라는 이들도 학점에 맞춰서 대학과 학과를 선택해야 했던 이들이다. 지금은 데이터 사이언스가 유행을 타니 데이터마이너/사이언티스트가 되겠다고 난리 — 까지는 아니지만 — 를 부리지만 지금 데이터마이닝을 하는 이들 중에 과연 몇이나 어릴 적 꿈이 데이터마이너였을까? 상황에 따라서 배우고 학습한 결과가 현재의 모습일 뿐이다. 그들은 절대 특별한 존재가 아니다. 단지 조금 먼저 시작했다는 차이는 있다. 간혹 뛰어난 두뇌의 소지자들도 있지만, 대부분은 아니다. 데이터 기반의 조직은 결국 데이터 기반의 사고에서 시작한다. 그렇다면 그들에게 데이터 기반의 사고를 전파해야 한다.

Nobody is born to be a data-miner. 누구에게나 기회의 문은 열려있다. 절대 닫히지 않는다. 차이는 들어가느냐 마느냐에 있다.

치기로 시작했지만 관련된 글들을 적고 있고 오프라인 강의도 하기로 했다. 모두가 데이터에 자유로워졌으면 좋겠다. 그럴 때 비로소 데이터 기반의 실행조직이 틀을 갖춰가리라 믿는다. 지금 치어를 손에서 놓지 않으면 대어도 없다.

어쩌면 지금 나의 전문성을 Data Analytics에서 Data Inspiration으로 바꿔야할 타이밍인 듯하다. 만약 Data Miner가 아닌 Data Evangelist로 살아간다면 밥은 먹을 수 있을까?

주사위는 던졌고 번호는 나왔다.

==

페이스북 페이지: https://www.facebook.com/unexperienced

댓글을 달아 주세요

Share           Pin It

두번째로 추천에 사용되는 데이터에 대해서 간단히 설명하겠습니다. 추천방식에 따라서 필요한 데이터가 달라지지만, 가장 일반적인 내용을 설명하고 추후에 특정 알고리즘이나 방식에 맞는 데이터는 별도로 설명하겠습니다. (특정 용어가 특정/다른 상황에서 적절하지 않을 수도 있습니다.)

추천의 기본 원리는 과거는 곧 미래다입니다. 그렇기에 추천을 위해서 필요한 데이터는 유저들의 행위 behavior 기록입니다. 상품 구매 이력, 이벤트 참석 이력, 기사를 공유했거나 like를 한 이력, 영화나 드라마를 보거나 평점을 남긴 이력 등의 모든 것들이 추천시스템에서 활용합니다. 그런 모든 이력들이 제품이나 컨텐츠에 대한 사용자의 선호/관심을 나타내는 지표로 사용합니다.

좀 더 구체적으로 쇼핑 추천을 예로 들겠습니다. A라는 사람이 특정 나이키 운동화를 웹에서 조회해본 것도 그 사람이 그 제품에 대한 선호를 보여주는 것이고, 더 나아가 그 제품을 구입했다면 더 확실하게 표시한 것입니다. 더우기 평점을 5점 (5점 스케일에서)으로 매겼다면 그 사람의 제품에 대한 만족도/선호도를 명시적으로 보여주는 것입니다. 댓글을 남긴다거나 추가로 더 구입한다거나 등의 모든 행위들이 사용자의 선호도 지표로 활용됩니다. 조금 복잡한 얘기가 될 수도 있지만, 쇼핑검색에서 특정 제품이 검색결과에 노출되었지만 그 사용자가 그 제품을 조회해보지 않는다면 이는 마이너스 (-) 선호도로 측정되기도 합니다. 선호도의 정도는 경우에 따라서 다양하게 해석이 됩니다.

이런 사용자의 아이템 선호도를 레이팅이라고 말합니다. 레이팅은 말 그대로 평점/별점을 매긴 것을 뜻합니다. 앞서 쇼핑에서 5점 스케일로 평점을 줬다면 이는 명시적 레이팅 explicit rating이라고 부릅니다. 그런데 특정 제품을 조회해봤다거나 구매했다 등의 행위에서는 조회여부 (0/1), 구매여부 (0/1)로 나뉘어질 뿐 명시적으로 점수화시킬 수 없습니다. 이런 경우는 암묵적 점수 implicit feedback이라고 부릅니다. 초기의 연구들이 명시점수에 기반해서 진행되었습니다. 그러나 명시점수와 암묵점수 사이에는 서로 장단점이 있기 때문에 요즘에는 둘을 동시에 사용하는 것이 일반적입니다. 물론, 명시점수가 존재치않는 경우가 더 많습니다.

명시점수의 경우에는 사용자의 선호도가 명시적으로 나타나기 때문에 추천하는 것이 조금더 직관적입니다. 그런데 암묵점수에 비해서 데이터 빈약도 data sparsity가 훨씬 큽니다. 즉, 유저들이 특정 제품을 구입하더라도 평점을 매기지 않는 경우가 허다합니다. Data sparsity는 바로 추천 알고리즘의 정확도와 연결되기 때문에 중요한 이슈입니다. 그래서 더 dense한 암묵점수를 명시점수의 보조역할로 사용하는 경우가 많습니다. (때로는 암묵점수만을 사용하는 경우가 더 많음) 물론 그렇다고 해서 암묵점수가 data sparsity가 없다는 얘기는 아닙니다. 명시점수가 암묵점수보다 더 심하다는 얘기입니다.

Data sparsity 이외에도 명시점수의 단점이 많이 있습니다. 대표적으로 점수의 편향이 있다는 점입니다. 사용자들이 소비한 모든 컨텐츠/상품에 대해서 평점을 남기는 것도 아니고, 남겨진 평점에 대한 신뢰도 문제가 있습니다. 저는 책을 많이 읽는데, 좋은 책을 읽었을 때는 시스템에 접속해서 4 또는 5점을 줍니다. 그런데, 마음에 들지 않는 책을 읽었을 때는 굳이 리뷰를 쓰지 않습니다. 모든 사람들이 저와 같이 점수를 준다면 4/5점대는 많은 데이터가 있는데, 1/2점대는 적은 데이터만 쌓여서 사용자의 선호를 명확히 구분하지 못해서 제대로된 추천이 불가능합니다. 뿐만 아니라, 사용자마다 점수 스케일이 다르다는 점입니다. 누구는 '그저그럼'이 3점이 될 수 있고, 다른 이는 4점이 될 수도 있습니다. 그리고 같은 유저더라도 상황에 따라서 다른 점수 스케일을 사용하는 점도 문제가 될 수 있습니다. 기분이 좋을 때는 4/5점을 남발하다가 기분이 나쁠 때는 1/2점을 줄 수도 있습니다. 이런 사용자 바이어스를 줄이고, 일관성에 맞도록 조정하는 방법도 연구의 한 축입니다.

명시점수에 노이즈가 많기 때문에, 최근에는 그냥 암묵점수를 사용하는 경우도 많아졌습니다. 명시점수에 비해서 더 많은 데이터를 확보할 수 있다는 것이 가장 큰 장점입니다. 명시점수에 비해서 선호도를 제대로 표현할 수 없다는 단점이 있지만, 이는 암묵점수를 어떻게 해석하느냐에 따라서 어느 정도 극복도 가능합니다. 특정 제품을 조회했으면 1, 아니면 0으로 구분하는 것이 아니라, 특정제품이 노출되었지만 조회하지 않았다면 -1, 노출되지 않았다면 0점, 조회했으면 1점, 그리고 구입까지 했다면 2점을 주는 식으로 레이팅을 달리할 수 있습니다.

추천 시스템에서 데이터와 관련해서 해결해야할 가장 큰 문제점은 데이터의 크기 data dimensionality 문제입니다. 넷플릭스의 유저 레이팅도 몇십억건이 넘는다고 합니다. 그런데 앞서 말했듯이 다양한 메타데이터를 사용해서 새로운 축이 생기면 더 큰 문제를 야기할 것입니다. SVD 기반의 Matrix Factorization에서는 로컬 데이터를 업데이트하는 방식으로 데이터의 스케일문제를 해결하기도 합니다. 최근에 많은 주목을 받고 있는 Big Data 기반으로 문제를 해결하기도 합니다. 그런데, 하둡 Mahout에 들어있는 CF를 사용해서 테스트를 진행해봤는데, 데이터 사이즈가 별로 크지도 않았는데 사용된 유사도에 따라서 메모리 문제가 발생하기도 했습니다.

이상의 유저레이팅은 보통 협업필터링 Collaborative Filtering에서 기본적인 데이터입니다. 여기에 더해서 Content-based Filtering (CBF)를 위해서 다양한 메타데이터도 사용이 가능합니다. 영화를 예로들면 특정 영화의 장르, 스태프나 출연진, 내용/줄거리 (에 사용된 키워드 등)이 메타데이터로 사용되고, 이들을 기준으로 관련 영화 (아이템)을 묶어서 추천해줄 수도 있습니다. 그리고 사용자에 대한 데이터도 사용됩니다. 사용자의 특성 (성별, 나이, 지역, 직업 등)에 따라서 제품에 대한 선호가 다른 경우가 많기 때문에 사용자 데모그래픽에 따른 그룹화 및 그룹별 추천도 가능합니다.

트위터나 페이스북의 성공으로 소셜관계 데이터는 최근에 가장 흔하게 사용되는 데이터 중에 하나입니다. 친구 또는 내가 선호하는 (팔로잉) 사람의 글이나 의견을 보여주는 형태입니다. 소셜 데이터가 추천에서 별 효과가 없다는 연구결과도 많지만, 적어도 추천의 신뢰도를 높여주는데는 효과가 있다고 합니다. 즉, '네 친구 XX가 추천한 글이야' 식으로 추천의 이유를 설명해주면, 추천된 글/제품이 별로더라도 결과를 이해하고 넘긴다는 것입니다. '너와 비슷한 누군가의 추천이야'보다는 '네가 알고 있는 누구의 추천이야'가 더 설득력이 있다는 얘기입니다.

간단하게 설명될 것같았는데, 의외로 글이 길어졌습니다. 여전히 추천에 필요한 데이터를 충분히 설명하지 못했습니다. 후속 글들에서 필요한 설명은 추가하겠습니다.

추천시스템 전체 목록

  1. 추천 시스템과의 조우 (PR시리즈.1)
  2. 추천 시스템을 위한 데이터 준비 (PR시리즈.2)
  3. 추천대상에 따른 추천 시스템의 분류 (PR시리즈.3)
  4. 알고리즘에 따른 추천 시스템의 분류 (PR시리즈.4)
  5. 추천 시스템을 위한 유사도 측정 방법 (PR시리즈.5)
  6. 추천 시스템의 성능 평가방법 및 고려사항 (PR시리즈.6)
  7. 추천 시스템에서의 랭킹과 필터링 문제 (PR시리즈.7)
  8. 추천 시스템의 쇼핑하우 적용예 (PR시리즈.8)
  9. 개인화 추천 시스템에 대하여 (PR시리즈.9)
  10. 추천 시스템의 부작용 - 필터버블 (PR시리즈.10)
  11. 추천 시스템의 레퍼런스 (PR시리즈.11)
  12. 추천 시스템에 대한 잡다한 생각들 (PR시리즈.12)
  13. 추천 시스템을 위한 하둡 마훗 사용하기 (PR시리즈.13)
  14. 추천 시스템에 대해서 여전히 남은 이야기들 (PR시리즈.14)

==

페이스북 페이지: https://www.facebook.com/unexperienced

댓글을 달아 주세요

서비스 개발 방법론

Gos&Op 2013.01.21 09:43 |
Share           Pin It

지난 연말에 신규 서비스를 위한 기획회의에 참석한 직후에 적고 싶었던 글입니다. 어떻게 하면 사용자들을 만족시키는 좋은 서비스를 만들 수 있을까?에 대한 글을 적고 싶었습니다. 너무 당연한 일반론이지만 정리해두면 좋을 것같다는 생각을 했습니다. 당시에는 처음부터 제대로된 컨셉/기획안을 만들어서 빈틈없는 개발을 하거나 빠르게 개발하고 사용자들의 반응에 맞춰서 빠르게 수정보완하는 것에 대한 설명을 적을 예정이었습니다. 그런데 이 한문장이외에 덧붙일 내용도 없었기에 그냥 글을 적지 않기로 했습니다. 그런데 최근 몇 가지 더 생각나서 글을 완성시켜야겠다고 마음먹었습니다. 새로운 방법론이라기보다는 앞서 말한 기획중심의 개발과 개발중심의 기획을 확장/변형한 방법론입니다.

성공하는 서비스를 만들기 위해서 어떻게 해야할까요? 기획 또는 개발을 '설계'라는 용어로 아울러서 말하겠습니다.

기획중심의 설계.
가장 먼저 떠오르는 생각은 시대의 트렌드와 사용자들의 니즈를 잘 파악해서 그 트렌드와 니즈를 파고드는 서비스의 컨셉을 정하고, 그 컨셉에 충실한 완벽한 서비스를 기획한다는 것입니다. 완벽한 기획이라는 것이 그 기획대로만 개발하면 무조건 성공할 수 밖에 없는 것입니다. 현실적으로 불가능한 얘기같지만, 말그대로 기획이 완벽했다면 개발 및 운영에 문제가 발생할 수가 없습니다. 보통의 기획서가 완벽하지 않기 때문에 문제인 것입니다. 실패하는 많은 기획서를 보면 대충 리소스를 산정해서 서비스 개발에 대략 10주 걸리고, 테스트하는데 2주면 되기 때문에 3달 후에는 서비스를 런칭할 수 있다 식으로 계획을 세웁니다. 그런데 실제 개발에 착수하면 예기치 못했던 문제들이 발생하고 리소스는 늘 부족하고 개발기간은 늘 촉박하고 그래서 대강 나온 서비스를 제대로 테스트도 하지 않고 런칭을 합니다. 그러면 런칭 직후부터 문제가 터지기 시작하고 초기의 버그는 사용자들을 떠나게 만듭니다. 요즘처럼 대체제가 많은 시기에는 그런 초기의 서비스 불만은 치명적입니다. 우리가 접하는 많은 서비스들은 기획에서부터 시작한 것들이 많습니다. 예전에는 대체제가 없었기 때문에 사용자들이 기다려줬고, 그래서 현재는 나름 성공/정착한 서비스들이 많습니다. 그러나 최근에는 기획에서 시작한 서비스들이 제대로 성공하는 경우를 못 봤습니다. 완벽하지 못했기 때문입니다. 완벽한 기획안을 못 만들면서도 우리는 늘 관념적으로만 이런거 좋겠지?라고 생각하고 불완전한 기획에서 개발에 들어가고 서비스를 런칭하고 그래서 실패하고 맙니다. 다시 말하지만 기획이 완벽하면 서비스는 성공합니다. 제품의 개발주기가 몇년씩 걸리는 산업에서는 여전히 유효합니다.

개발중심의 설계.
두번째로 떠오른 생각은 적당한 감을 가지고 초기 서비스를 만들어보고 일부 사용자들에게 테스트를 받아보고 보완해서 어느 정도 수준에 오른 서비스를 런칭하는 것입니다. 어느 누군가가 이런 기능/서비스가 필요해라고 말하면 그걸 바로 구현해서 적용해보고 사용자들이 꾸준히 사용하면 기능을 더 개선하고 그렇지 않으면 완전히 없애거나 처음부터 다시 디자인/구현해서 런칭을 하는 것입니다. 구글의 성공 이후에 영원한 베타라는 말이 생겼습니다. 지금 가장 많이 사용하는 Gmail도 초기 몇년동안은 계속 Beta 표시를 달고 서비스가 되었습니다. 일반 사용자들은 그냥 괜찮게 사용하고 있었지만 그래도 계속 베타 마크를 붙이고 서비스했습니다. 알파, 베타 마크가 사용자들에게 문제가 발생할 수 있으니 이해해주세요라는 그런 무언의 압력이기도 하지만, 사용자들의 반응을 보고 꾸준히 개선해나갈께요라는 그런 의지의 표현이기도 했습니다. 기획중심의 설계가 완벽한 기획이 필요했다면, 개발중심의 설계에서는 빠른 구현 및 꾸준한 모니터링이 필요합니다. 극단적으로 몇 시간에서 며칠내로 초기 버전이 구현되지 못하면 또는 초기 반응이 시큰둥하면 바로 접을 수 있어야 합니다. 긍정 또는 부정적인 사용자들의 (명시적/암묵적) 피드백을 얼마나 빨리 많이 수집해서, 그것들을 얼마나 빨리 수정/개선해서 차기 버전으로 만들어내느냐가 성공의 관건입니다. 초기 서비스에 버그가 있었지만 사용자들이 완전히 실망하기도 전에 며칠 또는 몇 시간 내에 문제가 해결되는 것을 보여준다면, 아무리 초기에 치명적인 결함이 있더라도 사용자들은 그 문제가 며칠 내에 해결될거다라는 기대감을 가지게 됩니다. 그래고 나의 피드백이 바로 반영이 되는구나라는 것을 느낀 사용자는 해당 서비스의 열혈 사용자가 될 가능성도 더 높습니다. 적당히 좋은 아이디어/컨셉을 빠르게 구현해서 적용해보면서 가능성이 없으면 초기 비용이 별로 안 들었을 때 바로 접으면 그만이고, 가능성이 있으면 더 많은 리소스를 투입해서 더 나은 서비스로 발전시켜나가면 됩니다.

데이터중심의 설계.
세번째 방법은 기획과 개발의 중간 쯤에 위치하면서 개발중심의 변형입니다. 새로운 서비스를 기획, 구현하기에 앞서서 현존하는 데이터들을 모으고 분석하는 것입니다. 예를들어 검색엔진에서 어느날 갑자기 특정 패턴의 검색어들이 많이 유입된다면 그런 패턴어를 처리해줄 수 있는 검색서비스를 만들어서 제공해주는 것입니다. 다음이나 네이버에서 영화, TV프로그램, 인물 등의 다채로운 정보가 검색에서 스페셜로 노출되는 것도 그런 종류의 검색어들이 상시적으로 많다는 것을 관찰/분석한 이후에 만들어진 것입니다. (간혹 경쟁사에서 서비스를 오픈해서 따라하는 경우도 있지만.. 이런 경우 기획중심의 설계로 들어가는 경우가 많음.) 아니면 트위터에서 오프라인 번개에 대한 니즈가 급증하는 것을 관찰했다면 트위터와 매끄럽게 연계된 번개서비스를 만드는 것입니다. 트위터의 초기에 트위터를 둘러싼 수많은 독립 서비스들이 개발되어 트위터에코를 만들었던 것을 생각하면 됩니다. 데이터중심의 설계는 신규서비스의 설계에 국한한 것이 아니라, 이미 런칭한 서비스의 개선에 더 큰 역할을 합니다. A/B 테스트로 알려졌듯이 새로운 기능이 사용자들에게 좋은 평가를 얻는지 확인하기 위해서 기존 기능과 신규 기능 사이의 버킷테스틀르 통해서 새로운 서비스에서 사용성이 더 좋으면 새로운 기능으로 대체하는 방법을 취합니다. 데이터중심의 설계는 개발중심의 설계와 밀접하게 커플링되어있습니다.

경험중심의 설계.
네번째는 기획중심의 설계의 변형이지만, 근본적인 차이점은 관념과 실제에 있습니다. 기획중심에서는 그냥 주변의 트렌드나 설문조사 등에서 나타난 이야기를 바탕으로 새로운 서비스를 기획하는 것이라면, 경험중심에서는 나 자신이 실제 사용자가 되어서 그 속에서 느꼈던 불편한 점들을 모아서 그것들을 극볼할 서비스를 만드는 것입니다. 때로는 기존 서비스에 만족하지 못해서 대체제/경쟁제를 만드는 것도 가능합니다. 작년 말에 사내외에 다양한 페스티벌을 만들어보고 싶다는 글을 적었었는데, 그 속에는 기본적으로 그런 페스티벌을 기획하고 운영해보면서 스스로 불편함도 느껴보고 또 사용자들의 행동을 가까이에서 관찰해보고 그들의 불편을 해소할 방법을 찾아보고 그걸 서비스화시켜보고 싶다는 것을 염두에 둔 생각이었습니다. 내가 직접 여행을 해보면서 불편한 점이나 좋았던 점 등을 경험해보지 않고, 관념적으로만 이런 게 필요할 것같고 이런 건 ROI가 안 나올 것같고 등과 같은 관념으로만 서비스를 기획하고 만들다보면 결국 리소스는 많이 투입했는데 결과는 좋지 못한 그런 경우가 빈번히 발생합니다. 실생활에서 참가해서 경험해보지 않고서는 어떤 서비스가 진짜 필요한지 이해할 수가 없습니다. 인터넷 기업을 다니는 사람들을 주변에서 관찰해보면 그들이 인터넷과 너무 동떨어져서 생활하는 경우를 자주 봅니다. 생활에서는 인터넷/모바일 서비스를 전혀 이용하지 않으면서 새로운 인터넷/모바일 서비스를 기획/개발하는 경우를 종종 봅니다. 그런 사람들에게서 제대로된 것이 나올 수 있을지 의문입니다.

이상으로 네가지로 나누어서 서비스 개발방법론이라고 거창하게 적었지만, 뭔니뭐니해도 오늘날 가장 중요한 것은 래피드프로토타이핑 rapid-prototyping입니다. 빨리 구현해서 테스트해보는 것이 가장 필요합니다. 기획중심의 설계에서도 기획단계에서부터 이런저런 기능을 테스트해보고 실제 데이터를 보면서 파이널 제품으로 갈 것인지 말 것인지를 결정해야 합니다. 실제 서비스의 프로토타입이나 데이터를 보지도 않고 무조건 위에서 시킨 업무라고해서 끝까지 기획서만 만드느라 많은 시간을 허비해버리고 정작 기획서가 나왔을 때는 이미 트렌드는 끝나가거서 유사제품들이 시장에 넘쳐나는 경우를 종종 봅니다. 특히 이미 성공한 제품/서비스를 가진 기업들일 수록, 후속 서비스에 대한 (대박) 압박 때문에 이런 오류를 자주 보입니다. 그럴수록 초기 단계에서부터 테스트 및 분석을 거치면서 큰 그림을 완성해야 합니다. 확고한 (초기) 컨셉이 정해졌다면, 작게 생각하고 빠르게 만들어서 사용자들의 반응을 관찰/분석해서 좀더 강건한 서비스를 기획/개발하는 것이 정석입니다. 애플에서 매킨토시를 처음 만들 때 케이스만 수십가지/차례 만들었다는 전설적인 이야기, 새로운 애플 제품은 적어도 100가지 디자인 중에 하나가 선택된다는 이야기, 페이스북에서 Q&A기능을 넣었다가 사용자 반응이 미비해서 그냥 빼버린 사례, 그리고 앞서 말했던 구글의 영원한 베타전략 및 A/B테스트에서 교훈을 얻어야 합니다.

대학에서 품질공학 수업을 들으면서 초기 기획/설계 단계에서 오랜 시간을 보내면 최종 제품 개발에서 실패가 적다는 것을 정석으로 가르쳐주고 있습니다. 실물 경제에서는 초기 디자인 단계에서 많은 것들이 검토되면 뒤쪽의 생산 단계에서 문제가 적게 발생한다는 얘기입니다. 몇 년의 준비과정이 필요한 제품의 경우에는 맞는 말이지만 인터넷/모바일 서비스처럼 몇 개월 또는 수주 내에 서비스의 승패를 결정하는 분야에서는 재고되어야할 내용입니다. 그리고 기획/설계 단계에 많은 것들을 점검하고 긴 회의를 거치더라도 앞서 말했듯이 꾸준한 프로토타이핑 및 테스트를 거치지 않으면 완벽한 서비스가 그냥 좋은 서비스에 밀려나고 맙니다. 그리고, 3~6개월만 개발이 지연되어도 트렌드에서 벗어나는 경우도 있지만, 6개월 ~ 1년 이상의 장기적인 마일스톤을 세워두고 꾸준히 개발/개선해야할 서비스나 기반기술들도 있습니다. 양자 모두에서 빠른 프로토타이핑과 테스트는 여전히 필수/유효합니다.

결론적으로 말하자면 현실에서는 다양한 경험에서 서비스 아이디어를 얻고 빨리 구현해서 데이터로 검증을 받아서 새로운 서비스를 만드는 것이 정도가 아닐까 생각합니다. 아이디어만으론 절대 성공할 수 없습니다. 어린 친구들에게 좋은 아이템이 있으면 창업해보라고 부채질을 하지만, 기본적으로 그들이 가진 재능과 패기를 바탕으로 조언하는 것이지 능력이 없는 이들에게는 그런 조언도 해주지 않습니다.

지나치게 일반적인 내용을 너무 길게 적었습니다. 앞서 '정석'이라는 표현도 사용했지만, 실제 성공하는 서비스의 왕도는 없습니다. 각 기업/조직의 문화에 따라서 더 적합한 방식이 따로 있습니다. 일반론에 함몰되지는 말았으면 합니다.

PS. 웃픈 글이 있어서 링크를 겁니다. 게임업계인에게 직접 듣는 게임업계의 슬픈 현실. 대화내용에서 카툰 아래에 나오는 '기획자가 필요없다'는 대목이 최근 IT업계의 현주소입니다.

(2013.01.14 작성 / 2013.01.21 공개)

댓글을 달아 주세요