왜 그는 데이터를 보게 되었는가?
개인적인 관점임을 전제하고, 요즘은 IT 기획자로서 살아간다는 것이 너무나 어려운 시대가 되었다고 생각한다.
보통 기획자로 불리던 사람들은 어느 순간 서비스 기획자로 불리며 보다 많고 복잡한 업무를 수행하게 되었고, 근래에는 PO(Product Owner)라는 이름으로 불리며 의사결정을 할 수 있는 막강한 권한은 없고 잘 되게 할 책임만 있는 기이한 직군이 된 것이 기획자다. 무슨 사업전략이라고 나온 건 왠 판타지 소설인지.. 영업 쪽에선 왠 황당한 물건을 들고 오는지, 내 앞가림할 시간도 없는데 나이 30 40 먹은 사람들 쫓아다니면서 닦달은 왜 해야 하는지..
쫓기는 일정 속에서 해야 하는 일 중 어떻게든 되는 것을 찾아내고, 윗사람에게 시간과 일정이 더 필요하다고 하소연하고, 지친 동료들을 상대로 이대로 가면 우리는 모두 죽는다, 여기까지는 되어야 한다고 읍소하고, 기상천외한 영업적 요구와 싸우고, 복잡한 코드 레벨에서 얘기하지 않아도 문제가 될 수준으로 기술부채가 쌓이는 상황을 알면서도 감당할 방법이 없어 속을 끓이고.. 요구되는 것은 더욱 많아지고 있는 데에 비해, ‘하는 직군’이 아니라 ‘되는 직군’으로 불리던 기획자로 살아가는 것은 더욱 어려워지고 있는 것이 현실 같다.
그러나 기획자라면 동의할 수밖에 없는 — 더 정확히 말하면 IT 인력이 모두 동의할 수밖에 없는 진실 중 하나는 기획자가 존재하건 존재하지 않건 기획 업무는 누군가가 해야만 하는 일이라는 것이다. 누군가는 일명 Unmet Needs를 찾아야 하고, 누군가는 컨셉을 잡아야 하며, 누군가는 누군가는 설계를 해야 하고, 누군가는 우선순위를 정해야 하고, 누군가는 설득해야 하고, 누군가는 싸워야 하고, 누군가는 쫓아다니며 검수를 해야 한다. 이름이 뭐든 업무는 죽지 않는다. 이런 일이 필요가 없는 시대가 된다면 인류는 노동에서 해방되어 있을 것이다.
기획자들의 삶에 변수가 되고 있는 것은 많다. 프로토타이핑 툴의 발전으로 인한 디자인과 기획의 업무적 통합, 프로젝트 관리 기법의 발전으로 인한 기획과 관리의 업무적 통합, 갈수록 높아지는 개발 복잡도, 끝도 없이 파편화되는 UX, 서비스 레벨에서의 마케팅 전략이 필요해지면서 발생한 마케팅적 요소의 기획 소요..
다만 이번 포스팅에서는 데이터 분석 기업에 굴러들어온 기획자답게 그 중에서도 데이터에 대한 내용만 중점적으로 다뤄보고 싶다. 기획의 관점에서 데이터를 본다는 행위는 무엇인가? 그걸 왜 해야 하나?
애초에 데이터를 본다는 행위는 무엇인가?
내가 과문해서 그런지는 모르겠지만 아직 내가 잘 납득할 수 있는 말을 보지 못해서 순수하게 사견임을 전제하고, 기획적인 관점에서 데이터를 본다는 것이 어떤 말인지부터 명확하게 정리해 볼 필요가 있을 것 같다. 크게 2가지의 의미를 갖고 있다고 생각한다.
- 나중에 내가 원하는 걸 얻기 위한 투자로서 데이터를 본다.
- 내가 원하는 것을 얻기 위한 방안으로서 데이터를 본다.
보통 기획자들에게 데이터의 중요성을 강조하거나, 일명 Data-Driven한 기획을 해야 한다는 이야기들의 상당수는 1번보다는 2번에 해당하는 것이다. 결국 그런 얘기들의 공통점은 데이터로부터 고객을 이해해야 한다는 것이기 때문이다. 그러나 여기서 잠깐 선후관계를 생각해 보면, 데이터가 없는데 데이터를 볼 수는 없다. 다시 선후관계를 생각해 보면, 데이터를 안 만들었는데 데이터가 있을 수는 없다(리얼 월드에서는 보통 데이터를 쌓는 게 문제가 아니라 데이터를 안 만드는 게 문제다).
그리고 사실 서비스를 둘러싼 어떤 데이터가 어떻게 쓰여야 하는지는 정말 데이터가 필요한 상황이 아니면 알 수가 없다. 기획자에게 데이터가 필요한 이유는 대부분 의사결정 상에서 ‘근거’를 들어 누군가를 설득하거나 누군가의 논리로부터 자신을 방어하기 위해서인데, 이게 말이 간단하지 실제 케이스는 정말 수도 없이 다양할 것이기 때문이다.
결국 기획의 관점에서 데이터를 본다는 것은 데이터를 설계하는 행위와 데이터를 해석하는 행위로 나뉘어 버린다. 보다 기획적인 언어로 얘기하면, 고객이 서비스에서 일으키는 행동과 그 결과를 어떤 식으로 찍어 놓을 것인가를 정하는 문제와, 나중에 보고 싶은 대로 그걸 봐서 써먹는 문제라고 할 수 있겠다. 많이 거칠게 요약하면 전자가 데이터 직무에서 흔히 말하는 DW(Data Warehouse)의 문제고 후자가 DM(Data Mart)의 필요성이라고도 말할 수 있다.
그런데 눈치가 빠른 사람이라면 위의 이야기가 일종의 늪과 같은 얘기처럼 들릴 것이다.
위의 논리대로라면 데이터를 활용하려는 기획자는 데이터를 쓰려면 데이터를 만들어야 한다-> 데이터를 만들려면 투자의 정당성을 입증해야 한다-> 투자의 정당성을 입증하려면 데이터를 써서 뭔가를 보여줘야 한다-> 하지만 데이터가 없다’ 의 무한루프에 빠지게 되기 때문이다.
이런 무한루프는 솔직히 실무자급 기획자 개인이 어떻게 해결할 수 있는 것이 아니다. 그러므로 일단 이 논점에 대해서는 나중에 별도로 다뤄보도록 하겠다.
일단 지금까지 나온 얘기를 요약하면 기획자가 데이터를 보는 것은 이미 쌓여 있는 데이터를 해석한다는 맥락도 있지만 나중에 해석할 때 쓸 수 있는 뭔가를 정해 놓는다는 개념도 포함되어야 한다는 말이다. 사실 데이터를 해석하는 얘기는 데이터 분석에 관련된 수많은 글들이 잘 다루고 있으므로 굳이 언급할 필요 자체를 못 느낀다. 아니 뭐 까놓고 기획자들이 혼자서 알고리즘 써서 데이터 분석하고 해도 할 수 있는 게 별로 없기도 하고.
그래서 좀 더 실무적인 1번에 관련된 부분을 중점적으로, 최소한 ‘내가 데이터를 공부할테니 교육비를 주십시오’ 라고 얘기하는 것에 좀 도움이 될 수 있도록 꼭지들을 잡아서 간단하게 데이터를 봐야 하는 이유에 대한 내 나름대로의 생각을 정리해 보겠다.
그럼 구체적으로 대체 데이터를 왜 보는가?
데이터를 보는 것 자체야 그냥 좋아서 볼 수도 있고, 데이터 분석가가 되고 싶어서 볼 수도 있고.. 여러 동기가 있을 수 있다고 생각한다. 내 경우는 이런 이유 때문에 데이터를 본다. 현재 내가 다니는 회사는 사실상 프로젝트 베이스인 회사이기 때문에, 서비스 베이스인 회사의 기획자와는 다소 업무상 중요한 논점에 차이가 있다는 점을 우선 말씀드리고, 크게 3가지 부분 때문에 데이터를 본다.
- 미션 크리티컬 이슈의 방지
원론적으로 IT 서비스란 뭔가를 받고 뿌리고 갱신하는 작은 원칙들이 자동으로 돌아가는 프로그램이다. 물론 서비스의 환경이나 성격에 따라서 차이가 있겠지만, 실제 구축과 운영에서 심각하게 문제가 되는 것은 근본적으로 시스템의 구조가 기능적으로 추가되거나 변경되어야 하는 요소에 아예 대응할 수가 없는 상황이고, 보통은 서버 인프라 아니면 운영 데이터 구조 때문에 이런 상황이 발생한다. 서버 인프라의 경우는 일단 차치하고(이것은 정말 답이 쉽게 안 나온다), 운영 데이터 구조의 경우 사실상 서비스에서 제공할 수 있는 모든 중요 기능의 기반이기 때문에 처음에 어떻게 짜느냐가 아주 중요하다.
이 문제에 대해서 기획자가 신경을 써야 하는 영역은 데이터의 내용보다 종류와 관계, 즉 데이터 모델이다. 가령 한 개인 식별자로 여러 번 회원 가입이 가능한가? 주문정보에서 주문상품은 가격이 변동될 수 있는 요소인가? 이런 부분에서 설계가 잘못 일어나면 향후 변경하기 대단히 어려워진다. 이런 미션 크리티컬한 문제의 관리를 위해서는 ‘반드시’ 기획자가 시스템에 흐르는 데이터의 구조가 자신이 정의한 관계와 기능에 맞게 구현되는지 확인할 능력과 의사가 있어야 한다. DBA적으로 행동하라는 말이 아니라, 서비스의 동작에 필요한 수많은 값들의 형태와 제약조건, 관계에 대해서 파악하고 있어야 한다는 뜻이다.
2. 개발 상의 효율 극대화
서비스에 흐르는 데이터가 무엇인지를 알고 있다면 비즈니스 로직에 관련된 문제도 매우 간소화된다. 구현 상태를 봤을 때 상식적으로 존재할 수 없는 상황이 존재한다는 것을 기획자가 판별할 수 있고, 이것이 데이터 상에서 어느 부분과 연결될 것인지를 짐작할 수 있다면 오류가 있을 확률이 높은 선택지가 급격하게 줄어들기 때문이다.
오류 이전에, 기획자가 애초부터 비즈니스 로직을 설계할 때 데이터 레벨에서 로직의 요소와 선후를 지정할 수 있다면 구현과 검수 과정에서 애초에 정상적으로 구현된 결과가 무엇인지 개발하기 전에 어느 정도 짐작이 가능하다. 단가 데이터와 프로모션을 통한 감면 비율 데이터가 따로 관리되고 있고 실제 사용자가 결제한 금액이 정상단가에 프로모션이 적용된 금액이라면, 결제 금액을 집계한 결과물이 무엇일지는 뻔하지 않은가?
이것만으로도 이미 기획자는 설계 단계에서 테스트를 진행하고 있는 것이나 마찬가지고 개발자의 입장에서도 정답지가 이미 존재하는 것이나 다름없기 때문에 개발을 하면서 디버그를 하고 있는 것과 같다. 이 경우에는 서비스 기획은 다 줬는데 기능 개발은 커녕 DB 설계하느라 몇 주씩 쓰는 상황이 발생할 가능성이 매우 낮고, 검수 시에도 버그가 적을 수밖에 없다. 즉 개발 시의 효율이 급격하게 높아진다.
3. 사용자 행동의 자산화
DW(Data Warehouse)를 구축한다는 것은 단순히 데이터 덩이를 한 곳으로 모은다는 것이 아니라 데이터를 일관성 있게 정리하여 휘발되지 않는 공간에 보관한다는 것이다. 물론 잘 유지보수된 시스템들은 나름대로의 원칙에 따라서 데이터가 쌓이고는 있지만, 이것을 실제 데이터 분석으로 연계하기 위해서는 이 데이터가 대체 (현실에서) 무엇을 의미하는지에 대해서 해석할 방법이 있어야 한다. 사실 이 표현도 너무 SI적이고, 실제로는 일관성 있는 작성 방법에 의해서 작성된 데이터를 기반으로 DW를 구축해야 한다는 표현이 더 맞을 것이다.
이 논점이 개발적인(혹은 순수하게 데이터에 관련된) 것인가? 내가 생각하는 답은 ‘아니오’다. 이건 SI를 하면서 레거시 시스템의 데이터 스키마 명세서를 보는 순간 바로 깨달을 수가 있다. 사용자의 행동, 시스템의 기능, 관련 데이터가 일목요연하게 통합되어 있는 경우는 아예 본 적이 없고, 갈겨쓴 스키마 정의서 몇 장이 있는데 그나마도 그 스키마가 운영 DB와 100% 일치하기나 하면 평타는 친다.
일이 이 지경이 된 건 나중에 이 데이터를 분석을 통한 서비스 기획 고도화에 사용할 것이라고 전혀 예상하지 않았(못했)기 때문이지만, 동시에 기획자가 서비스에서 발생하는 실제 데이터의 자산화에 필요한 데이터의 생성 프로세스와 설계 규격에 대해서 ‘기획적으로’ 정리할 필요를 못 느꼈고 요구도 받지 않았기 때문이기도 하다. 가령, 사용자가 앱에서 ‘이탈한’ 순간을 포착할 수 있는 데이터는 무엇인가? 사용자의 Demographic 데이터는 어떤 규격으로 어떻게 수급되는가? 주문 프로세스에서 데이터는 어떻게 생성되는가? 반품 시에는 어떻게 처리되는가?
이것을 쪼개 보면 실제 DM(Data Mart) 기반으로 뭔가를 ‘분석’하기 위해서는 그 모든 것들을 포괄적으로 분석할 수 있는 기반 데이터가 설계되어 있고 축적되어 있어야 한다. 1번과 같이 엮어서 생각해 본다면, 결국 기획자는 서비스 자체의 장기적 고도화 방향성과 함께 서비스 데이터의 비즈니스적/서비스적 활용 가능성을 고려하여 사용자-시스템-데이터가 빈틈없이 연결된 데이터 구조를 구성하여야만 할 것이다. 극단적인 예로 한 동영상이나 음악을 사용자가 100번 직접 눌러 플레이한 것과 반복 플레이 버튼을 눌러놓고 아무런 액션을 몇 시간 동안 취하지 않은 것을 구분할 수 없다면 사용자의 컨텐츠에 대한 관심도 내지는 충성도를 무슨 수로 정확하게 평가하겠는가? 오히려 고도의 분석을 진행하는 것은 On-Demand로 하면 될 일이고 그것들 사이에서 필요한 개념(데이터의 관점에서는 Entity와 Attribute와 Domain과 Relation)의 누락이 없어야 향후에 데이터 분석으로 연결이 쉬울 것이다.
지금까지 대충 내가 3년 가까이 데이터 분석 기업에서 기획자로 일하면서 느겼던, 기획자가 데이터를 ‘본다’는 것의 의미와 그것이 필요한 이유에 대해서 나름대로 써봤다. 데이터 인력과 기획 인력, 개발 인력, 의사결정자 사이에서 일하다 보면 도저히 메우기 어려운 인식의 간극을 느낄 때가 많고 사실 이게 원래 기획자의 숙명이다. 그래서 처음 블로그를 다시 시작하면서 중요한 글감으로 생각했던 것 중 하나가 기획자가 데이터에 대해서 어떤 관점을 가져야 효과적으로 상황을 주도하고 통제할 수 있느냐 하는 것이었다. 이 포스팅으로 약간 개운해진 기분이다.
