타 직군이 로그 설계를 해야 한다면?_1편
데이터 분석가가 아니세요? 하지만 해야 한다면, 로그 설계 A to Z
"데이터 분석을 통하여~", "유저의 행동 데이터를 분석하여~", "데이터 드리븐의~"라는 이야기들을 저희는 들어오고 있습니다.
이 것이 진행되기 위한 근간에는 로그의 개발, 그리고 그 앞에는 로그의 설계가 있지요.
기록이 없는데 분석을 할 수는 없는 법..!
오늘은 이 기록을 어떻게 남길 것인가? 에 관한, 로그 설계에 대한 이야기를 다룰 것인데요, 그중에서도 "데이터 분석가가 아닌 타 직군이 로그 설계해야 한다면 어떻게 해 볼 수 있을까? " 라는 포인트로 이야기를 다루려고 합니다.
*참고: 글쓴이는 위에서 말한 '데이터 분석가가 아닌 타 직군'인 프로덕트 매니저로 일하고 있습니다.
저는 직접 로그를 설계하기 전에는 데이터 분석가들에게 추상적이고 모호한 요청사항을 드렸던 대역죄인이었습니다만....
시간이 흘러, 업무 프로세스가 정비되면서, 직접 프로덕트 조직에서 직접 1차 로그 설계를 하고, 분석 조직에서 피드백을 주는 방식으로 일하게 됨에 따라 과거의 죄를 반성할 수 있는 사람이 되었습니다.
죄인,,, 어쩔 수 없이 이미 되버렸거나 될 예정이라면, 반성할 수 있는 죄인이 되자.... 지금은 매 과제 배포 시마다, 로그 설계 부분을 직접 챙기게 되면서, 로그 설계가 저의 자연스러운 업무의 한 흐름으로 자리하게 되었어요. 데이터 분석 직군이 아닌 타 직군으로서 직접 로그를 설계하고 고민하면서, 그간의 시행착오를 통해 배운 점들을 기록, 공유하여, 로그 설계에 뛰어드실 다른 분들에게 조금이나마 도움이 되었으면 합니다.
데이터 분석가 외 타 직군이 로그 설계를 해야 하는 상황
타 직군이 로그 설계를 해야 하는 상황은 크게 2가지입니다.
1.PM(때에 따라 프로덕트 디자이너, 개발 등)이 로그를 설계하면 장점이 있다는 조직 내의 합의, 분위기가 이루어진 경우
2. 모두가 도움을 줄 수 있는 데이터 분석가 직군이 갖춰진 조직에서 근무하는 것이 아니어서
2번... 이것이 현실이다... 누구나 파라다이스에 살고 있진 않으니까요.저 또한 현재 재직 중인 회사에서 일하기 전에는 별도의 데이터 분석가 직군이 갖춰지지 않은 회사들을 거쳐왔기 때문에 광야를 개척해나가는 마음을 누구보다 잘 알고 있는데요,
광야여,,,기존에 사내에 로그 개발을 진행하고 있지 않았다면, 참고할 데이터 로깅 관련 문서가 존재하지 않기 때문에, 더 막막할 것입니다. "GA, 앰플리튜드 등 각종 좋다는 툴들이 좋다는 많이 들리는데... 도입해볼까..?" 도 싶지만, 그 좋다는 툴들을 도입하더라도 무엇을 어떻게 정의하여야 로그를 심어야 할지는 막막하기 때문이죠...
하지만 두려워하지 맙시다! 이 글은 그런 분들을 위해 써보는 것이니까요.
분석가 분들의 지원을 받을 수 없는 환경일지더라도, 프로덕트 조직에 있는 분들은 왜 이 기능이 만들어졌는지에 대해 가장 잘 이해하고 있으니만큼, 또 장점을 발휘할 수 있는 일이기도 합니다.
또한 앞서 1번으로 정의했던 조직 내에서 로그설계는 데이터분석가가 아닌 다른 직군이 하는 것으로 정의했으나 막막하실 분들에게도 작은 도움이 될 수 있으면 합니다.
그렇다면 가봅시다! 반성할 수 있는 죄인으로 거듭나자!
목차
1) 로그, 그것이 무엇이냐?
2) 로그를 둘러싼 업무
3) 로그 설계를 위한 기본 지식
4) 해보자 로그 설계
5) 로그 설계를 할 때 고민되는 점
6) 그 외...
로그, 그것이 무엇이냐?
우선 더 자세한 이야기를 진행하기 전에 로그가 무엇인지 먼저 짚고 넘어갈까요?
로그를 크게 2가지로 나누어 이야기해보겠습니다.
1) 서버 로그
2) 클라이언트 로그 (앱/웹 로그)
서버 로그와 클라이언트 로그는 서로 상호 보완적입니다.
주문, 결제를 하는 상황을 예를 들어 설명해보겠습니다.
서버 로그
DB에 저장되는 데이터를 의미합니다.
-00시 00분 User_Id 1이 이 N0,000원 주문함. 상품 목록 a, b, c. 주문번호 12번 생성됨.
-결제 수단 A
클라이언트 로그 (앱/웹 로그) - 유저 행동 로그
앱/웹에서 유저가 어떤 행동을 하는지에 대한 기록을 의미합니다.
-00시 00분 User_Id 1이 주문지면에 진입함.
-결제수단 선택하기 버튼을 클릭한 후 스와이프 3번 하여, 결제수단 A 선택 클릭.
-결제하기 버튼 클릭
노란색 하이라이트 된 부분인 이 부분을 보시면 클라이언트 로그에서는 어떤 정보를 남길 수 있는지 서버로그와 구분하여 와닿으실 수 있으실 것입니다.
주문지면에 진입 (View)
결제수단 선택하기 버튼 클릭 (Click)
스와이프 3번 (Swipe)
결제수단 선택 클릭 (Click)
결제하기 버튼 (Click)
두 로그는 상호보완적이어서, 각각의 로그에만 남길 수 있는 로그도 있지만,
필요에 따라 동일한 정보를 남길 수도 있습니다. 예시에서는, 00시 00분 User_Id, 결제 수단 A를 서버 로그와 클라이언트 로그에서 둘 다 남길 수 있도록 중복으로 정의했네요.
오늘 이 로그 중에서도 유저의 인터렉션을 포함한 유저의 행동을 파악할 수 있는 클라이언트 로그 설계에 관련된 이야기를 다룰 것입니다.
유저 행동 로그를 둘러싼 일의 과정
글쓴이가 일하고 있는 조직에서 로그를 둘러싼 일의 과정은 다음과 같습니다.
1) 현황 파악 및 문제 정의 : 프로덕트의 현황을 파악하고 무엇이 문제인지 정의합니다.
2) 피처 설계(과제) : 그 문제를 해결하기 위한 피처를 설계합니다. 새로운 기능이 될 수도 있고, UX/UI 개편이 될 수도 있고, 로직 or 모델 변경이 될 수 도 있고요, 혹은 새로운 서비스를 런치 해보는 것이 될 수도 있겠습니다.
3) 과제의 성과를 판단할 지표를 정의 : 과제 설계 시, 해당 과제를 정량적으로 측정할 수 있을지 고민합니다. 모든 과제가 정량적 측정이 가능한 것은 아닙니다. 하지만 정량적으로 측정이 가능하다면, 어떤 지표를 기준으로 과제의 성과를 판단하고, 모니터링할지 고민해봅니다.
4) 로그 상세 설계 : 과제 상세 요건을 협의하고 개발 스펙을 검토하는 동안, PM은 로그 상세 설계를 진행합니다. 해당 과제용의 별도 로그 상세 설계 내역을 만듭니다. 협업하기 쉬운 구글 스프레드 시트를 애용하고 있습니다. 이때 만드는 시트는 협업용이므로, 협의가 완료된 내역은 별도 관리 툴 or 페이지 등에 옮길 것입니다.
5) 개발자 상세로그 미팅 : 개발자 분들을 소집하여, 로그 상세 설계 진행한 내용을 리뷰하고, 해당 로그의 개발 가능 여부와 대안에 대해 논의합니다.
6) 데이터 분석가분들과의 로그 설계 내역 검수 : 해당 과제의 배경과 목적에 대해 설명하고, 협의된 로그 설계 내역에서 벗어나는 것이 있는지, 더 좋은 로그 설계 방법은 없는지 피드백을 주고받습니다. 개발자도 함께 리뷰에 참석하여, 새롭게 논의되는 내역에 대한 가능 여부와 대안을 함께 논의합니다.
7) 최종 로그 확정, 로그 관리 내역 반영 : 최종 로그를 확정 짓습니다. 이 확정된 로그는 사내 로그관리 페이지 내 반영되어 관리됩니다.
<--- 간주 점프 ----> : 과제 개발
8) 로그 개발 : 과제 개발이 어느 정도 끝났다면, 로그 개발 준비를 시작합니다. 이쯤 되면 QA 시작일 1~2주 전쯤이 되었을 것입니다. 로그 개발이 시작됩니다.
9~10) 로그 개발, 베타 QA : 로그 개발 본을 포함한 베타 버전이 배포됩니다. 로그가 의도대로 잘 남고 있는지. 베타 앱/웹을 통해 검수합니다.
11) 운영 배포 : 짠~ 축하합니다. 해당 과제의 배포와 함께, 해당 로그도 세상에 배포됩니다.
12) 운영 검수 & 성과 지표, 이용현황 확인 : 베타 QA를 진행했음에도 불구하고, 잡아내지 못한 이슈가 있을 수 있습니다. 성과지표, 이용현황을 실제로 확인하다가 발견되는 이슈도 있고요. 이슈가 없다면 축하합니다. 앞서 정의한 해당 과제의 성과지표, 이용현황을 확인합니다.
13) 로그 검수 이슈 수정 : 운영 로그 검수 시 발견된 로그를 수정합니다.
14) 현황 파악 및 문제 정의 (다시 처음으로) : 배포된 과제의 성과 및 이용현황을 확인했더니, 새로운 가설이 생겼나요...? 다시 첫 번째 스텝인 '현황 파악 및 문제 정의'로 돌아가 새로운 가설과 검증을 시작할 때입니다~
로그 배포 시기는 어떻게 되나요?
1) 새로운 피처 배포 나갈 때마다
시기를 놓치면, 소급 적용해서 로그 개발 전의 데이터를 볼 수 있는 방법이 없습니다.
ex. 앱의 경우, 과제가 배포되고 난 이후의 이용현황이 궁금하다고 할 지라도, 해당 로그가 개발된 앱 버전 이상부터 데이터를 확인할 수 있습니다.
로그는 과제 배포 시기에 맞추어 함께 배포될 수 있도록 그때 그때, 함께 심는 것이 가장 베스트..!
2) 운영 QA 돌리다가, 마치 베타에서 발견되지 못한 이슈, 정정
3) 중간에 한 번씩 전수 검수
양이 많을 것이라, 극악무도하다고 느낄 수도 있지만, 저희 조직은 로그 전수 검사를 가끔, 진행하고 있습니다. (OS별로 로그가 남겨지는 시점 등이 상이한지 등을 잡아냅니다. )
로그를 둘러싼 전체 협업 사이클 중 개발과의 협업 사이클 포인트?
1) 로그 개발도 개발이다.
2) 로그 개발 일정을 전체 개발 일정상 별도로, 꼭 넣는다.
로그 개발과 과제 개발을 전체로 묶어서 '개발' 이라고 일정을 두지 마세요.
해당 과제의 일정 산정시, 피처 개발과 별개로, 로그 개발만 별도로 일정을 잡아두는 것을 권고합니다.
이 일정은 과제 사이즈에 따라 달라집니다. 저는 3주정도의 개발사이즈의 과제면 적어도 1주일 정도는 로그 개발일정을 두려고 하는 편입니다. 물론 과제의 사이즈가 정말 간단한 것이라면, 로그 개발 검수까지 1~2일 정도까지도 쭉 줄어들 수도 있고, 신규 서비스 오픈과 같은 큰 사이즈라면 아무리 기간이 타이트하다고 해도, 최~소, 1주일 정도는 확보해두어야겠죠. 그래야, 로그 QA도 가능하고, 해당 시기 쯤 들어오는 앞에서 밀린 개발 작업 보강과, QA 시작과도 살짝 걸쳐질테니,
QA기간 내 로그 개발을 병행하는 동일한 일정으로 잡아두는 것은 정말 급한 상황이 아니면, 모두의 평화를 위하여 피해 주세요~
3) 로그 설계 상세 내역 리뷰는 QA 1주 전일지라도, 설계 내역을 최대한 빨리 리뷰하는 것이 좋다.
개발 스펙 검토 직후에 로그 설계 내역도 리뷰가 가능하면 가장 좋습니다만, 시간이 조금 걸린다면, 전체 개발 일정 초까지면 좋습니다.
이유는 원하는 방식으로의 로그 개발을 위해 대안을 찾아야 하는 경우도 있으므로, 개발 범위, 일정이 달라지는 경우가 있기 때문입니다.
파라미터 내의 특정 정보를 서버에서 넘겨줄지, 앱/웹에서 하드코딩으로 처리할지 등을 개발자 간 논의하고 개발에 착수해야 합니다.
그 외 더 상세한 협업 포인트는 하단 로그 설계하는 내용에 포함될 예정입니다.
*위 첨부 이미지 내의 사이클은 담당자 등을 변형하시어 각 조직에 맞게 사용하실 수 있습니다.
로그 설계를 위한 기본 지식
로그 설계를 위한 기본 지식을 짚고 넘어가 보겠습니다.
남기고 싶은 데이터가 어디에서 발생하는가?
데이터가 어디에서 발생하는지 확인해야 합니다. 이에 따라 원하는 로그를 꼭 클라이언트 로그에서 남겨야 하는가도 점검해 볼 수 있으며, 설계 내역 내 파라미터의 정보를 누가(서버 or 앱/웹) 어떻게 넘겨줄 것인가를 확인할 수 있습니다.
서버 : 특정 API의 Request(요청)/Response(응답) 정보를 기록할 수 있습니다. 앱이나 웹에서 API 호출할 경우 요청 시점, 혹은 응답 시점에 기록할 수 있습니다.
앱/웹 : 화면에서 유저가 어떤 화면에 진입했는지, 어떤 버튼을 클릭했는지 등을 기록합니다.
로그 설계의 3대 원칙과 점검사항
로그를 설계할 때 이 3원칙을 유의하고 설계하지 않으면, 꼭 남기지 않아도 되는 로그를 TMI로 남기거나(제가 자주 그랬습니다), 로그의 규칙이 존재하지 않거나 혼재함으로 인해, 후에 고생을 하게 됩니다.
혹은 데이터 사용자를 고려하지 않고 설계했기 때문에, 데이터 사용자가 쿼리를 작성할 때에 번거로움이 발생할 수 있습니다. 다음 3원칙을 유의하면서 체크리스트 점검도 함께 해보세요.
로그를 설계할 때마다 이 3원칙과 체크리스트에 벗어나는지 고민하는 것도 중요하지만, 로그를 설계하는 조직이 이 원칙들을 함께 합의하는 것도 중요합니다.
로그 설계의 3원칙
1. 목적성 : 분명한 목적을 가진 로그를 정의 및 설계하여야 한다.
2. 일관성 : 여러 로그 간의 형태적 일관성이 확보되어야 한다.
3. 유용성 : 로그를 활용 함에 있어 유용한 형태여야 한다.
로그 설계 3원칙 체크 리스트
1. 목적성 )
해당 기능을 통해 어떤 목표를 달성하고자 하는지?
해당 목표가 달성되었는지 확인하려면 어떤 지표를 분석해야 하는지?
지표를 확인하기 위해 설계되어야 하는 로그는 무엇인지?
2. 일관성 )
로그 세부사항을 정의함에 있어 네이밍 컨벤션(조직 내의 관습, 규칙)을 따르고 있는지?
유사한 로그들과 일관적인 형태를 갖추고 있는지?
3. 유용성 )
누가 봐도 명확히 의미를 파악할 수 있고, 쉽게 이해할 수 있는 형태인지?
분석 쿼리를 작성할 때 유용하게 활용할 수 있는지?
추가적인 가공 없이 지표를 바로 확인할 수 있는지?
연결하여 보고자 하는 로그와 Join 할 수 있는 값이 있는지?
해보자 로그 설계
자 이제까지 로그를 둘러싼 일들이 어떻게 진행되는지 전반적으로 살펴봤습니다. 그럼 실전으로 가볼까요?
(미리 보기)
로그 정의 항목
로그 설계 탬플릿이 사내에 존재하거나, 기존에 누군가 만들어 둔 내역이 있다면, 기존 조직의 탬플릿을 기반으로 로그 설계를 하면 되니, 행운입니다~!
기존에 가이드가 없는 경우에는 다음의 항목을 참고하여, 로그 설계 내역 구글 스프레드 시트 양식을 만들어보세요~
하단 탬플릿 내 각 항목에 대한 상세한 설명 (무엇을 어떻게 정의하고 고민하면서 설계할 수 있는지)는 '해보자 로그 설계'부터 다시 2편에서 이어서 이야기합니다.
그럼 다음 이 시간에...
