로그 설계에 대해 내가 배운 것들
어쩌다보니 현재 업무 중 로그 설계 비중이 높아졌는데 하면서 지금까지 배운 것들을 정리해보면 좋을 것 같아 글을 쓴다. 최근 일하면서 이 부분을 제일 많이 배운 것 같다.
우선 로그 설계란 왜 필요한 것일까? 왜 웹로그가 필요할까? DB에 있는 데이터를 보다보면 결국 서비스에서 사용자들이 어떻게 활동했는지 더 자세히 들여다봐야할 필요가 생긴다.
예를 들면 매출 테이블에는 어떤 사람이 가입한 지는 오래 되었으나 단 한 번 구매를 한 내역이 나온다고 치자. 그럼 접속을 하지 않아서 단 한 번의 구매만 있는 것인지, 아니면 다른 때에 접속을 했는데도 구매가 한 번뿐인지에 따라 할 수 있는 어프로치가 다를 것이다. 그리고 사용자가 단 한 번 구매할 때는 어떤 방식으로 했는지도 참고할 수 있다. 이때 웹로그를 통해 사용자의 행동을 살펴볼 수 있다. 웹로그가 없다면 볼 수 없다는 뜻이기도 하다. 별다른 구분자가 없었다면..
이제 웹로그가 왜 필요한지는 이해 됐을 것이다.
웹로그 정의는 누가 해야 할까? 누가 해야 한다고 정해진 것은 없지만 나는 분석할 사람이 정의하는 것이 좋다고 생각한다. 웹로그 정의팀을 따로 두거나, 혹은 개발자가 임의로 정의하거나, 분석가가 전담하는 케이스가 주를 이루는데 분석가가 정의하는 것이 아닌 경우에는 후에 분석을 어떻게 할지에 대해서는 고려하기가 쉽지 않다. 결국 로그는 분석을 위한 것이므로 분석할 사람이 정의하는 게 나중에 분석가가 가장 덜 고통스럽다(?). 반대로 분석가가 전담하는 경우 단점은 분석가의 몸은 하나인데 해야 할 일이 너무 많다는 것이다. 나는 분석가가 풍족한 팀을 본 적이 없어서 그럴지도........(있으면 알려주세요) 분석가는 하나인데 피쳐는 다중으로 진행될 경우 분석가가 모든 피쳐에 관여해야 한다. 몸은 하나인데 머리는 둘 공명조를 아시나요 이런 노래가 생각난다.
웹로그를 정의할 분석가를 구했다고 치자. 당장 웹로그를 오늘부터 쌓아야 하는데 어떤 것부터 시작해야 할까? 웹로그를 쌓는 방법은 GA(Google Analytics)나 firebase, 자체툴 등 다양한 방법이 있는데 어떤 툴을 사용할지는 상황에 따라 다르고 툴을 소개할 생각은 없어서 패스한다. 어차피 무엇으로 웹로깅을 하느냐는 어떤 툴을 택하든 "큰 맥락"에서는 다르지 않다.
제일 첫번째로 해야 할 것은 당연히 page 정의다. 여기서 page란 앱의 화면을 의미하는 것이다. 다른 종류로는 event가 있다. 여기서 event는 사용자의 활동 자체를 의미한다. 예를 들면 홈화면에서 사용자가 배너를 클릭했다면 홈화면은 page가 되고 배너를 클릭하는 행동은 event이다. page부터 진행하는 이유는 page만 수집해도 볼 수 있는 것들이 꽤 많기 때문이다. 퍼널 분석도 가능하다. page 정의를 할 때는 서비스의 흐름을 생각하면서 정의하면 좋다. 우리 서비스의 흐름은 어떻게 되는가? 그 구조도를 그려보고(flow chart가 이미 있다면 나이스다) 각각에 해당하는 주요 화면단을 먼저 정의한 후 나머지를 채워나가자. 퍼즐을 맞출 때 가장자리를 먼저 맞추고 안을 채워나가는 것처럼.
그 다음 event 수집을 시작한다. event가 사용자 행동단위이기 때문에 더 구체적인 정보를 얻을 수 있다. 그리고 page만 있어서는 알 수 없는 정보들도 있다. 아래 화면을 보자.
메인의 배너 영역을 클릭하면 event page로 이동하는데, my page에도 동일한 page로 보내주는 경로가 있었다!메인의 배너 영역을 클릭하면 event page로 이동하는데, my page에도 동일한 page로 보내주는 경로가 있었다! 페이지만 있다면 main page에서 event page로 간 트래픽이 많은 건지 my page에서 event page로 간 트래픽이 많은 건지 알 수가 없다. 그래서 나는 event를 사용자 행동과 영역에 관한 것이라고 생각한다.(내 맘임. 다를 수도 있음) 유저가 어떤 영역에서 어떤 행동을 했는지 구분할 수 있는 것. 그런데 event를 모두 정의하기란 쉽지가 않다. 분석가는 적고 event 로깅을 해야 하는 액션은 많으니까. 이것도 서비스에서 중요한 액션을 정한 후 우선순위에 따라 정의하게 된다. 리소스가 충분하다면 될 수 있는한 자세히 남기는 것도 괜찮다고 생각한다. 단, 분석을 하거나, 할 예정인 범위에서. 분석을 하지 않을 것인데 event를 남길 필요는 없으니까.
그럼 벌써 page와 event 로깅에 대한 이야기 끝났다. 로깅을 하면서 무엇을 주의해야 할까?
데이터의 통일성을 갖추는 게 제일 중요하다고 생각한다. 마구잡이로 정의하게 되면 결국 엄청난 전처리가 필요하게 된다. 예를 들면 동일한 액션인데 iOS는 A라고 남기고 AOS는 B라고 남기고 있다면 이걸 모두 파악하고 있어야 한다. (다시 공명조 노래가 생각난다. 몸은 하나인데 머리는 둘..)
트리거도 중요하다. iOS는 cart에 장바구니를 넣는 순간 로그가 전송되는데 AOS는 장바구니 넣고 성공한 순간에 로그를 전송한다고 하자. 그러면 기준이 맞지 않아 분석이 어려워진다. 청기백기 생각난다. 복잡해질 수록 휴먼에러는 발생하기 쉽다.
데이터의 통일성을 갖추기 위해 할 수 있는 방법은 로그 정의 문서를 정말 정말 정말 정말 정말 자세히 쓰는 것이다. 문서가 정말 중요하다. 정확히 어떤 화면에 대한 정의인지, 어떤 행동에 대한 정의인지, 어떤 시점에, 어떤 page명이나 어떤 event 명으로 보내줘야 하는지에 대해서 자세히 써야 한다. 서비스가 복잡해지면 로깅도 서로 영향을 주기 때문에 기존 로그가 새로운 피쳐에 영향을 받게 되면 그 부분도 모두 정의해주는 게 가장 베스트이지만 몸은 하나인데..(이하 생략)이므로 회사 구성원들이 모두 숙지할 수 있는 로그 로직을 문서화하는 것도 방법이라고 생각한다.
예를 들면 이런 룰을 세울 수도 있다. 페이지 로그는 이 페이지를 볼 때마다 전송한다. 즉 뒤로가기의 경우를 포함한다. (하지 않을 수도 있다.) 중요한 건 기본적인 로그 전송 룰이 정리되어 있어서 로그를 개발하고 QA하는 사람들이 이런 때는 어떻게 되야 하는 거야? 의문에 빠지는 게 아니라 우리 로그 로직상 이렇게 되어야겠군 생각할 수 있도록 합의가 생기는 것이다. 이건 나도 아직 못 만들어서 내년에 해야 한다..
충분한 커뮤니케이션도 중요하다. 로그 개발과 QA는 담당이 따로이기 때문에 정의에 대해서 개발자와 QA와 충분한 대화가 이루어져야 한다. 분석가가 원하는 정보가 로그로 남기기 어려울 수도 있다. 이 경우 커뮤니케이션이 잘 된다면 오히려 개발자분들이 더 좋은 제안을 주실 수도 있다. QA도 필요한 이유는 데이터 QA가 중요하기 때문이다. 구현하고 QA하는 사람들이 정의에 대해 제대로 알지 못한다면 슬픈 일이 생길 수도 있다. 이런 상황을 몇 번 겪어보니까 프로세스를 제대로 정비하는 것이 필요하다고 느꼈고 현재는 만들어나가고 있다. 그래서 지금 내가 작성하는 버전은 이 로그는 왜 필요한 거고, 나는 여기서 무엇을 측정하고 싶은지에 대해 명시하고 그 다음 로그를 정의할 때 트리거, 전송되어야 할 값에 대해 모두 작성하고 있다.
그리고 확장 가능성을 고려해야 한다. 현재 있는 피쳐뿐만 아니라 이 피쳐가 확장 됐을 때는 어떻게 기록할 것인가를 유념하면 좋다.(어렵다..) 그래서 로그 정의를 할 때 PO와 이 기능이 확장될 가능성이 있는지에 대해서도 이야기를 나누기도 한다. 알고 있을 때와 모르고 있을때의 정의 방식이 다르기 때문이다.
그밖에 로그 정의할 때 신경 쓸 부분은 event나 page명을 가지고 별도 데이터 파이프라인을 만들 수도 있기 때문에 convention에 대해 주의해야 한다는 것이다. 파이프라인이 없어도 로깅을 하는 사람이 여러 명이라면 convention에 대해 이야기 해야 한다. 사람마다 생각이 다르기 때문에 정의한 방식이 모두 달라서 나중에 전체를 보면 이게 뭐지.. 의 상황이 올 수도 있다. 하드 코딩은 덤.
만약 AB TEST를 하고 있다면 실험군과 대조군의 행동 차이를 잘 고려하면서 정의하고, 실험이 실패하거나 성공했을 때 원인 분석을 어떻게 할 것인지를 고려하면 좋다. 이미 실험이 진행된 후에 오프라인 분석을 해야 하는데 로깅이 없어서 "지금 알고 싶은 걸 그때 로깅에 넣었더라면" 하고 후회하는 일이 없도록.
웬만한 건 다 쓴 것 같은데 나중에 더 필요한 것이 있다면 더 추가해보겠다. 적은 내용 중 대다수는 나 혼자 배운 것이 아니라 똑똑한 동료들을 통해, 그리고 시행착오를 통해 배운 것이다. 분석을 위한 로그 개발을 도와주시는 모든 분들에게 감사의 말씀을 전한다.
