입사한지 두 달이 되어간다. 실시간으로 적응해나가고 있다는 안도감을 느끼는 동시에, 가까운 미래에 무언가 큰 일이 터질 것 같은 불안함도 커져가고 있다. 사건의 발단은 한 슬랙 메세지였다. 특정 화면에 남는 파라미터에 대한 문의였는데, 생전 처음 본 듯한 내용이었다. 분명 지난 달에 내가 확인했던 로그 데이터였는데..! 심지어 ‘이걸 내가 로그 QA 했다고?’ 하는 의심마저 들었다. 한주에 무엇을 했는지 돌아보지 않고 쉬다가 주말이 끝나다보니 깊게 고민하지 않는 일은 바로 기억속에서 사라지는 것 같다.
그런 의미로 최근 수행한 로깅 업무를 돌아보는 글을 쓰고자 한다. 하나의 제품을 출시하기 위해 디자이너, 개발자, PO 등이 핑퐁 논의를 하고, 그 결과 만들어진 화면에서 로그를 정의하면 되는 일이기에 처음에는 쉬워보였다. 하지만 막상 해보니, 로그 정의는 고민이 꼬리에 꼬리를 무는 어려운 일이었다. 로깅을 하면서 어떤 어려움이 있었고, 무엇을 배웠는지 돌아보았다.
1. 어디까지 남겨야하나
나는 직무 특성상 여러 팀의 로그 QA와 로그 정의 업무를 하고 있다. 그렇다보니 나는 제품을 만드는 메이커가 아닐뿐더러, 로그 데이터를 분석하는 주체라기에도 애매하다. 그래서 로깅할 때 어떤 목적으로 로그를 정의해야할지, 내가 정의한 로그를 미래에 어떻게 활용할 수 있을지 가늠하는 것이 가장 어려웠다. 내가 로깅 경험이 부족해서 생긴 문제일 수 있다. 하지만 시간이 지나면 저절로 해결되는 문제일까? 그렇지도 않아보인다.
로그 정의처럼 정답이 없는 문제일수록 팀원(데이터 분석가, PO, 개발자 등)들에게 의견을 물어보고 결정하는 것이 더 효율적인 방법 같다. 어려워서 하루 넘게 붙들고 있기보단, 내가 어디에서 막혔는지 정확히 파악하고 같이 일하는 팀원 혹은 위클리 미팅을 통해서 도움을 받아서 했더라면 여러날에 걸쳐 마친 업무가 하루만에 끝났을 수도 있겠다 싶었다. 이렇게 의견을 구하는 것 자체가 중요한 스킬이라는 생각이 들고(하지만 나는 여전히 부족한..) 내가 생각하지 못했던 맥락을 빠르게 이해해 우선순위를 파악하기 좋은 것 같다.
2. 이것까지 남겨야하나?
화면에 진입하는 유저가 어떤 행동을 하느냐에 따라 다양한 이벤트 로그를 정의할 수 있다. 예를 들어 click, impression, scroll 등을 남길 수 있다. 그 중 impression 로그를 남기는 목적은 무엇일까? impression 로그는 일반적으로 어떤 요소가 유저에게 노출되었는지 구분하기 위해 쓰인다. 예를 들어, 배너 A가 유저마다 노출 여부가 다른 경우 특정 유저에게 해당 배너가 노출되었는지 여부를 남길 때도 쓰이고, 유저가 여러 항목이 포함된 리스트에서 한 아이템을 클릭하기까지 어떤 아이템들이 노출되었는지 로깅할 수도 있다.
이것까지 로그를 남겨야햐나, 말아야하나 고민이 들 때는 직접 실행해볼 수 있는 테스트 스킴을 개발자에게 요청해서 확인하면 좋다.
스킴이란?
- 스킴은 특정 페이지로 바로 이동할 수 있는 url이다.
- 스킴을 통한 이동은 크게 1. 네이티브 앱 화면으로 이동과 2. 웹뷰로 만든 화면으로 이동으로 나눌 수 있다.
- 개발된 기능을 테스트할 때 쓰이고, 푸시를 통해 사용자를 진입시킬 때도 스킴이 쓰인다.
프레이머나 피그마를 통해 디자인으로 보고 바로 로깅하기보단, 스킴을 통해 직접 퍼널을 타보며 한번 더 확인하는 작업이 필요하다. 최근에는 스킴으로 앱을 실행해보다가 내가 빠트린 로그를 발견한적이 있다. 퍼널 중간 즈음에 뒤로가기를 눌렀는데 예상했던 것과 다른 화면으로 랜딩되었던 것이다.
스킴으로 앱을 직접 실행하다보면 로깅 시점을 파악하기도 편하다. 예를 들어 유저가 생년월일과 주소를 차례대로 입력하는 화면이 있다고 할 때, 주소 입력 단계를 impression 로깅한다고 하자. 그럼 로그를 남겨야하는 시점은 언제일까? 유저가 주소 입력 화면을 만났을 때가 될 수도 있고 유저가 주소를 입력하기 시작하는 시점일 수도 있다. 만약 “유저가 주소 정보를 입력하다가 거부감을 느껴 이탈한다” 라는 가설을 확인해보고 싶다면 유저가 입력을 시작하는 시점에 로그를 남길 수도 있겠지만 그러한 원인 파악이 중요하지 않다면 유저가 해당 화면을 보는 시점에만 로그를 남겨도 될 것이다. 최종적으로 내가 정의한 시점대로 로그를 남기는 것이 가능할지 개발자와 소통하며 확인해야하고, 이때 논의한 내용은 추후 로그가 예상한 시점대로 들어오는지 확인하는 QA 과정에서 중요하다.
3. 마무리하며
로깅을 하다가 이전 로그 중 비슷한 제품을 찾아 참고하기도 한다. (아니 거의 매일 참고한다..) 간단하게는 로그 이름을 어떻게 정의했는지부터 어떤 이벤트 로그를 남겼는지 등을 참고하고 있다. 과거에 누군가 로깅한 자료들을 보면, 로깅 방식과 로그 종류의 장단점을 배울 수 있다. 로그 정의 경험이 늘어날수록 로깅 정답을 더 많이 알게 된다기보단, 특정 로그를 포함할지 말지,에 대해 장단점을 폭넓게 이야기할 수 있게 되는 것 같다. 그래서 나의 가까운 목표는 로그 정의 경험을 쌓으며 해당 로그를 추가하면 어떤 분석에 활용할 수 있는지 설명하고, 각 로깅 방식마다 장단점을 제시할 수 있는 사람이 되는 것이다.
