조직 내 데이터전담 기획자의 1년 셀프 회고

21년 4분기와 22년 1분기에는 분석보다는 인프라 구축과 대시보드 제작, 그리고 설명회가 주요 업무였다. 

1. Working Backwards를 언제나 따를 것

인프라를 구성할 때엔 ‘결과적으로 누가 어떻게 사용할 인프라인가’에 대해 초기에 깊은 고민을 해야 한다.

가능하다면 관련 전문가 혹은 관련 부서 담당자의 지혜를 빌리는 것이 좋다.

A프로젝트는 기획과 개발 간에 ‘XXX zone의 데이터를 실시간으로 OOO zone으로 꺼낸다’ 정도의 목표만 막연하게 협의한 채 시작되었다. 그 뒤에 목표로 했던 ‘태블로 대시보드 연결’이라는 실제 사용 형태에 대해서는 깊은 논의를 하지 않은 것이었다.

A 프로젝트 회고때 개발자분이 말한 것이 딱 그 내용이었다.

db구성은 되었지만, 태블로 앱에서 쿼리 날리는 데 있어서 무거운 게 발견.

태블로에서 어떻게 동작하는지를 미리 파악해서, 거기에 적합한 db를 초기에 고려했었다면 어땠을까

제 생각으로는 ‘raw data를 원한다, 반출을 원한다’라는 것만 고려해서 rdb로 구성한 건데.

결론적으로는, 태블로 활용에 있어서 부하가 많이 가는 것..

‘결과적으로 누가 어떻게 사용할 인프라인가’를 Working Backwards에 입각해 들여다보았다면 아래처럼 되었을 거다.

  1. 태블로에 연동할 실시간 데이터라는 걸 정립
  2. 원본 데이터의 스펙을 파악하고, 그걸 실시간 복제하여 태블로 사용하고자 한다는 것을 간단명료하게 표현 (글과 도식 활용)
  3. 데이터정보플랫폼파트에 질문답변 회의를 요청한다
  4. 데정플과 회의를 하여, 2번에서 정리한 정도의 스펙이라면 mysql은 부적절하다는 것을 알게 되었을 것
  5. target db로 hadoop 혹은 druid를 사용하도록 가이드를 받았을지도
  6. 실시간 복제 DB의 target을 hadoop/druid로 구성
  7. 그러면 리얼타임 복제 mysql과 그걸 매일 다시 복제한 hadoop 2중 구성을 피했을 수도. 

일을 할 때엔 목적과 목표를 항상 구체적으로 작성하자.

그때 ‘결과적으로 누가 어떻게 사용할 것인가’를 구체적으로, 구체적으로, 또 구체적으로 작성하자. 3월에 작성한 ‘기획자의 커뮤니케이션’에서도 다짐했던 것이다. 

2. ‘상대방에겐 주요 업무가 아닌 일’을 진행시키는 것의 어려움.

해당 DB 구축이 완료된 이후로는 데이터 관련 업무를 본업으로 하는 사람이 나 혼자였다. 업무상 상대방인 서버 개발자나 클라이언트 개발자에겐 로그나 지표가 메인 업무가 아니었다. 물론 기획팀 내에서도 마찬가지였고.

소외감을 느꼈다거나 하는 건 아니다. 누구하고든 상시로 대화를 했고, 계속해서 일은 주어졌다.

그러나 ‘지표’라는 키워드로 진행되는 일이 나에게는 1차 역할/업무인데 반해, 상대방과 조직 전체에선 n차 우선순위인 것을 매번 느낄 수밖에 없었다. 

같은 일을 함께 하고 있더라도,  A라는 사람에겐 1순위지만 B라는 사람에겐 곁다리 업무인 경우는 언제나 발생할 수 있다. 그럴 때 A라는 사람은 상대방의 인지 리소스와 시간 리소스를 효율적으로 사용하기 위해 늘 고민해야 한다. 

내가 A일 때는 지금처럼 해왔듯이 하면 된다. 열심히. 구체적으로. 공개적으로.

그런데 내가 B일 때는 어떻게 해야할까? 내 노력과 시간을 투입하는 최적점은 어느 정도일까? 

3. 제품 기획자와 데이터 기획자

여러 제품을 오가며 행동 로그를 설계하고, 대시보드를 제작하고, 분석용 데이터 환경을 구성한 것을 값진 경험이었다. 

그러면서 로그설계의 기술적 노하우도 많이 쌓았고, 기획자로서 필요한 데이터 리터러시도 향상시킬 수 있었다. 이번 1년의 데이터 업무는 앞으로 내 커리어에 좋은 양분이 될 거라 믿어 의심치 않는다. 

(담당할 제품이 없는 상태에서) 팀의 모든 제품에 대한 데이터 업무를 맡겠다고 한 건 나 스스로의 결정이었고 팀장의 승인을 받았다. 물론 그때도 ‘데이터 커리어를 계속하지 않을 것이며, 이건 2021년 한시적인 담당 업무다’라고 다짐했었다.  

기능에 집중하여 어러 제품에 관여하는 방식의 업무를 경험해보니… 제품 기획자로서 커리어를 계속해야겠다는 생각을 더 단단하게 하는 계기가 되었다.

6월 말에 면담에서 팀 내 데이터를 전담하겠다고 말하고 조직장의 동의를 얻었지만, 그로부터 오래지 않은 9월 말에 면담을 하며 ‘분석용 DB 구축까지 마무리하고 나면 다시 제품을 담당하고 싶다’고 말하게 되었다.

물론 그 사이에 서비스 A를 맡게 되었었지만, 데이터 관련 업무에 시간을 훨씬 더 많이 할애했었다. 분석용 DB 구축과 대시보드 제작은 2021년 겨울과 2022년 새해가 되어서야 어느 정도 마무리되었고, 22년 3월 말 조직 개편이 되어서야 공식적으로 ‘데이터 전담 업무 종료’를 할 수 있게 되었다.

A라는 작은 제품을 맡게 되었다. 이제 무엇을 어떻게 할지는 나에게 달린 일이다. 

4. 적극적으로 나서야 할 때는 언제인가

그럼에도 기능 기획자로서 잘해내고 싶었던 것은 전자증명서 프로젝트였다. 분석용 DB 프로젝트에서 설정한 Try를 총동원하고, 그 사이 알게 된 ‘데이터레이크와 데이터웨어하우스 모델’을 잘 도입하고, 사내 행동로그까지 통합하여 BI 환경을 마련해보고 싶었다.

이걸 해내기 위해선 프로젝트 초반에 내가 더 적극적으로 회의에 참석하고 프로젝트 매니저/서버 개발/프론트 개발과 긴밀히 소통했어야 했다. 미리 했어야 했다. ‘프로젝트의 일정’에 포함될 수 있게.

그렇게 하지 못했다. 너무 늦은 시점이 되어서야, 그것도 아지트 멘션이라는 소극적인 방법으로 커뮤니케이션하는 데에 그쳤다. 

적극적으로 나서야 할 때가 언제일지 사실은 알고 있었다. 당연히 프로젝트 초반이었다. 그런데 왜 적극적으로 나서지 않았을까/못했을까? 행동로그 적용 가능시점을 핑계로 삼았던 건 아닐까? ‘UI가 나와야 할 수 있는 일’이라는 핑계로 차일피일 미뤘던 거 아닐까? 

일의 ‘부분’이 늦게 시작해도 된다는 것은 일의 ‘전체’를 늦추는 이유가 되지 말았어야 했다. 사내망에 글 쓰는 정도 말고, 프로젝트 매니저에게 ‘지표 업무 논의를 위한 개발자와의 자리’를 요청하거나, 내가 12월에 했듯이 스스로 요청하든지 했어야 했다. 그리고 더 촘촘하게 커뮤니케이션을 했어야 했다. 

5. 데이터 분석과 시각화

언제나 주제 문장 혹은 메세지를 명료하게 세울 것. 

내용이 길어진다면 내러티브에 맞추어 데이터를 나열할 것.

분석과 시각화는 상대방에게 정보를 전달하기 위한 수단이고, 그 정보는 언제나 문장의 형태로 표현되는 것이 먼저이다. 

주제 문장/메시지와 내러티브가 없는 데이터 분석은 숫자 덩어리에 불과하다. 

주제 문장/메시지와 내러티브가 없는 시각화는 그래픽 덩어리에 불과하다. 

6. 설명회와 업무 인계

업무 정리는 ‘히스토리’와 ‘현황’으로 나누어 생각하자. 현황은 현황을 일목요연하게 정리하면 되는 거다. 히스토리는 자세해야 하고. 현황과 히스토리를 한 번에 담으려 하지 말자. 지표에 유량 지표와 저량 지표가 있는 것과 똑같이 생각하자.

업무 인계와 설명회는 다르다. 업무 인계는 대상이 분명해야 한다. 설명회 같은 방식으로는 업무를 넘겨줄 수 없다. 모두에게 하는 설명과 한 명에게 하는 설명은 내용과 깊이가 다를 수밖에 없다.

설명회는 수요가 있는지부터 확인해야 한다. 잠재 수요든 직접 수요든. 예상 청중이 그 내용을 듣기 위해 시간과 노력을 투자할 의향이 있는지부터 확인하자.

그리고 수요 조사를 하면서 홍보를 하는 거고. 홍보를 하면서 일정을 협의하고, 그런 이후에 설명회를 잡자.

회사에서 주최하는 ‘전직원 대상 설명회’가 아니다. 그런 규모의 설명회일 때만 주최측 시간에 맞추어서 진행하는 거다. 

Leave a Reply

Your email address will not be published. Required fields are marked *