[1.2] 문제의 원인을 살펴봅시다.
대체 뭐시 문제란 말이여~
첫 번째. 로그를 하다보면 발생하는 현상
1. 로그를 모르면 어떤 문제가 발생하나요?
2. 문제의 원인을 살펴봅시다.
3. 로그를 못 할때의 위기와 잘 할 때의 기회
4. 해결방법은 이렇게 하시면 됩니다.
로그의 중요성을 정리했으면, 그 다음엔 문제를 짚고 가야할것 같은데요. 플랫폼 서비스에서 행동로그가 서비스의 문제점이나 개선 정도를 알려주는 중요한 데이터인데, 왜 다양한 문제들이 발생할까요? 이제부터 이 질문에 대한 답을 찾아보겠습니다.
사업에서 의사결정을 하기 위해 데이터는 중요합니다. 객관적인 의사결정의 판단에 도움을 주는 데이터라는 말 만으로는 다소 막연함이 남습니다. 행동데이터는 이용자와 앱 간의 상호작용의 사실 또는 유추할 수 있는 진실을 알려주므로 무엇이 문제인지 또는 개선해야 할 방향을 찾거나 무엇을 개선할지, 우리의 한계가 어디인지를 알 수 있는 데이터이기 때문에 중요합니다. 로그의 중요성은 대부분 동의하면서 왜 이렇게 다양한 문제들이 발생할까요? 문제의 시작은 바로 담당자 또는 담당 조직의 부재입니다.
로그 담당자의 부재는 왜 발생하는지 알아봅시다. 대부분의 기업들은 각자의 역할이 있습니다. 개발자, 기획자 or PO(product owner), QA(quality assurance), 데이터 엔지니어나 분석가, 마케터 등 고유의 역할과 소속부서가 있습니다. 전통적으로 주요 미션이 정해진 부서들입니다. 이에 반해 로그담당자는 특정 부서에서 담당한지 얼마 되지 않았습니다. 솔직한 표현으로는 전임 담당자조차 존재하는 곳이 많지 않습니다. 그러다 보니 여러 부서 중 조직문화의 성격 상 관련성이 높은 부서가 로그업무를 겸업하는 경우가 흔했죠. 데이터분석팀, 데이터엔지니어링팀, 하다 못해 마케팅팀이기도 했습니다. 부서의 중요 업무와 미션은 고유의 역할에 한정되었고, 로그업무의 미션은 부수적인 업무로 취급받기 쉬웠습니다.
이처럼 주요 업무가 아닌 겸직할 수 있는 로그업무치곤 해야 할 일이 너무 많았던겁니다. 분석부서의 로그 에러에 대한 불판, 기획자나 PO의 데이터 생성요청, 개발자의 일정지연이나 휴먼 에러 등 수 많은 담당자들과의 협업이 더 이상 협업이 아닌 부담으로 다가오는거죠. 본인의 주 업무도 많은데 로그를 추가로 일하는 건 상황에 맞지 않지만, 못한다는 말은 못하겠으니 맡은 역할에 대해서 뭐든 해보려고 열심히 꾸역~ 꾸역~ 영혼을 쓱싹~ 쓱싹~ 갈아넣으며 진행을 하긴 합니다. 그런데, 경험이 없고 고민상황에 닥치면 고민의 시간과 해결의 노력이 함께 어울어질 시간이 필요한데, 주 업무와 부 업무 중 부 업무의 고민시간을 많이 할애할 수는 없겠죠. 결국 이러한 상황의 반복이 사람이 지치게 만들고 로그품질마저 바닥으로 이끄는 결과를 초래하게 됩니다.
그렇다면, 로그부서를 만드는 건 왜 시도하지 않을까요? 담당자 지정의 시행착오와 마찬가지로 경험 부족에 따른 인식의 결여로 봤습니다. 팀이라는 조직을 만드는 건 명확한 필요성과 역할에 대한 인식이 임원레벨까지 이뤄져야 합니다. 그리고 로그팀의 미션이 부여되어야하고, 그 미션을 도전적으로 달성하는 노력을 실행하며 품질을 올려야 할텐데, 대부분의 기업에선 로그팀에 대한 필요성을 알기 시작했지만 아직 팀까지 만들 인식은 부족한 실정입니다. 그러니 설득조차 시도하기 부담되는거죠. 최근까지도 제가 로그팀을 맡고있다 소개했을 때 로그팀까지 있는 조직이면 엄청 큰 회사나 가능하다는 얘기를 종종 듣곤합니다. 흠~~
담당자의 부재와 담당조직의 미션이 명확하지 못한 점이 로그 문제의 시작이라고 말씀드렸는데요. 그 외에도 주요한 문제들이 있습니다. 로그는 UI(user interaction)나 UX(user experience)의 영향에 그대로 노출됩니다. UI를 변경할 때 고객이 선택하는 UI의 로그에도 그대로 반영되기 때문인데요. 메뉴 하나를 추가하거나 프로모션 배너의 위치가 상단에서 하단으로 변경하는 경우에 로그 또한 동일한 UI에서 바뀔때, 기존에 전송하던 로그는 문제가 없어야 합니다. 그런데, 개발자들은 (데이터를 생성하는 역할만 있어서 그런지) UI를 변경하는 경우 기존 전송하던 로그를 누락시키는 경우가 있습니다. 제법 종종발생하는데요. 그래서 신규개발하는 경우 중요한 로그는 문제가 없는지 검사해야 하는 경우도 빈번합니다. 개발자는 (데이터의 생성역할에만 치중하다 보니) 서비스 로직의 변경에 따른 로그의 영향도, 즉 관련없는 로그까지 영향이 발생하는 side-effect이 발생해서 정상이던 로그가 제대로 전송하지 않던 문제가 발생합니다. 이러한 문제를 신속하게 인식하고 대응하기 위해선 모니터링 체계를 만들어야 하는데요. 벌써부터 일이 많아지는 기분이 들겁니다.
마지막으로 로그는 여러부서와 소통해야 합니다. 기획자 또는 PO, 개발자, 데이터엔지니어, 분석가, 마케터, 그리고 임원까지 소통해야 할 대상의 범위가 상당히 넓습니다. 프로세스 상 거쳐야 할 담당자들이 많기도 하지만, 문제가 발생했을 때 이슈에 대한 영향도를 사전에 전파하고 보고해야하는 일도 있는거죠. 예를 들면, 잘 나오던 주문관련 로그가 어느날 갑자기 나오지 않는다면 어떻게 해야 할까요? 직속 임원에게 보고 후 어쩌면 영향도가 커서 top manager에 해당하는 CTO 등 높은 분들에게까지 일일이 이러한 현상이 발생한 원인과 영향범위, 대체분석 방안, 정상까지 소요하는 시간 등 다양한 내용들을 검토하고 공유하는 노력이 수반되어야 합니다. 이 정도면 적은 일은 아니겠죠~
로그에 발생하는 다양한 문제 중 주요한 원인들에 대해서 살펴봤습니다. 담당자 or 담당부서의 부재, 개발자의 UI변경에 따른 side-effect, 그리고 소통의 범위인 Communiation spectrum이 넓다는 점인데요. 이러한 문제들의 세부 내용들은 다음에 언급할 케이스에서도 사례로 함께 공유드려 보겠습니다. 여러분이 생각하는 것 보다 문제는 매우 다양한 영역에서 뜻하지도 않게 발생하곤 한답니다. 그래서 할 일이 많습니다만, 다른 관점에서 보면 심심할 틈 없이 나의 커리어를 개발하며 성장하기 매우 적합한 업무영역이라며 스스로 자부하기도 합니다!!!
