데이터 조직 역할 빌드업
제품과 사업에 기여하는 조직이 되려면
데이터 조직이 맡는 역할을 아주 일반화해보면 크게 세 가지로 나뉘는 것 같다.
1. 다른 팀 또는 전사가 데이터를 볼 수 있게 해준다.
2. 데이터에서 의미를 찾아서 전달한다.
3. 데이터가 이끄는대로 제품이 작동하도록 제품요소를 만들어낸다.
1번은 각종 데이터마트나 지표를 자동화하고 대시보드를 제작하는 업무가 포함된다. 모든 데이터를 데이터 팀이 보고 있을 수 없기 때문이기도 하고, 여러 조직과 PO들이 직접 지표를 확인하고 의사결정하는 것이 꼭 필요하기 때문이다. 이 문제를 해결하지 않으면 데이터 조직 스스로가 역설적으로 전사의 데이터 니즈를 방해하는 병목이 될 수 있다.
1번 역할을 잘한다는 것이 2번 역할도 잘할 수 있다는 것을 의미하지 않는다. 대시보드에 지표를 추가하다보면 그 복잡도는 아주 쉽게 증가하고, 만든 사람조차 어떤 지표를 우선해서 봐야하는지 헷갈리기 쉬우며, 지표만 본다고 좋은 인사이트가 나오는 것이 아니기 때문이다. 어느 단계에서는 결국 원천데이터를 '까봐야' 하는데, 이러한 과정은 데이터에 숙련된 멤버를 통하지 않고는 속도를 낼 수 없다.
3번은 1번과 2번의 결과를 액션아이템으로 전환하거나 개발하는 영역이다. 유저에게 적용되는 정책을 변경하거나(예를 들면 VIP 등급을 부여하는 기준을 바꾼다든가, 활동을 제한할 임계치를 설정한다든가), 서비스 후면에서 작동할 조금 더 복잡한 모델(콘텐츠가 노출되는 랭킹모형이나 추정한 유저의 의도대로 뭔가를 제공한다거나)을 도입하는 일이다.
그동안 여러 회사를 다니면서 데이터 조직이 실질적인 기여를 하기 위해서는 각 영역을 잘해내는 것도 중요하지만, 세 가지 영역 간 정렬(alignment)이 중요하다는 점을 많이 배웠던 것 같다.
(1번 <-> 2번/3번) 데이터 마트는 인사이트 분석과 모델 실험의 속도를 높여주는 방향이 되어야하는데, 예를들어 마트가 있어도 변수를 만들때 매번 로그테이블을 파싱하고 있는 경우도 제법 있었다. 달리 말하면 많은 시간이 소요된 엔지니어의 노력과 큰 컴퓨팅 자원을 들인 무언가가 사실 사용되지 않는 것이다.
(2번 -> 1번) 분석을 끝내고 좋은 인사이트가 있었다면 그것을 지표로 자동화해야한다. (최근 핫했던) 아하모먼트를 찾았다면, 그 모먼트를 달성하는 특정 유저행동을 트래킹할 수 있는 대시보드를 만들어야 한다. 의외로 많은 곳에서 열심히 분석한 인사이트는 보고서로 남고, 집계가 쉽고 의미는 적은 허수지표가 대시보드 상단을 차지하고 있다.
(3번 <-> 2번) 모델은 '어느 상황에서나 이상적인 정답'을 기준으로 학습하는 것은 유저의 의도나 서비스 성과와 동떨어질 수 있다. 서비스 목적 또는 모델이 작동하는 영역에서 목표를 바라보고 개발되는 것이 필요하다. 이 과정에는 탄탄한 분석으로 모델의 요구사항을 정의하는 것이 필요하고, 반대로 과거 분석의 결과를 적극적으로 찾아서 반영하는 것도 필요하다.
전체 조직이 커지고 역할이 분리될수록 데이터 조직이 챙겨야 할 1,2,3번의 정렬이 흐트러지기 쉽다. 한편으로는 데이터 조직 안쪽의 정렬을 잘 챙기더라도 바깥쪽(제품기획, 마케팅, 사업, 운영 등)과 정렬이 틀어지면, 그 전체가 만들어낸 결과가 기름처럼 동동 떠다니는 경우도 충분히 발생할 수 있다. 데이터팀 모두가 공동의 목표를 향해 열심히 달렸고 괜찮은 결과도 만들었는데, 전체 차원에서 '그걸 왜 하고 있었느냐'라는 질문을 들을 수도 있는 것이다.
뭔가 글이 툭 끊어진것 같긴 하지만 어떻게 수습해야할지 잘 떠오르지 않네요.
아무튼 저는 '데이터 조직의 정렬을 코드와 아키텍쳐로 실현하는 것'이 데이터 엔지니어의 역할이라 생각합니다.
함께 하실 분 아래 링크 클릭해주세요 :)
