0. 들어가며

우아한형제들 데이터서비스팀 송훈화입니다. 제 업무는 로그를 설계/정의하고 데이터를 분석하는 것입니다. 궁극적으로, 유저가 남긴 로그로부터 유저의 경험을 추정하고 니즈를 파악해 서비스 개선에 필요한 인사이트를 제공하는 것입니다. 이를 위해 로그 설계/수집/분석에 이르는 전반적 과정에 직/간접적으로 관여하고 있으며, 입사후 4개월간 경험한 내용과 생각을 공유하고자 합니다.

1. 분석의 시작은 서비스를 이해하는 것부터

입사 직후 진행한 업무는 클라이언트 로그를 설계하는 것이었습니다. 앱의 모든 화면과 이벤트(클릭, 배너 노출)를 상세히 파악하고, 시나리오와 서비스의 흐름을 이해하는 것부터 시작했습니다. 마치 실제 유저가 앱을 쓰듯이 모든 기능과 화면을 하나씩 파악하면서 로깅 항목을 정리했습니다. 다소 노가다 업무였지만, 이 작업을 하면서 앱에 대한 이해가 한 단계 더 깊어지는 경험을 하게 되었습니다. 또, 이 과정에서 (제가 느끼기에) 편리한 기능도 있었고 이상한(?) 기능도 있었는데, 향후 분석을 위한 방향과 프레임을 잡는 데 유용한 정보를 얻었습니다.

로그 설계/정의 업무가 마무리되고 엔지니어 및 개발자와 협업하면서 로그 수집을 진행하였습니다. 데이터는 JSON 형태로 저장소에 차곡히 쌓이기 시작했고, 엔지니어의 도움으로 언제든 저장소에 접근해 데이터를 추출/분석할 수 있는 환경이 마련되었습니다. 실제 수집된 로그는 아래와 같았습니다.(아래 이미지 참고) 유저가 우리 서비스에 접속해 특정 화면을 보거나 액션을 할때마다, 설계된 스키마 대로 데이터가 쌓였고 샘플을 추출하여 데이터 탐색 준비를 마무리 하였습니다.

로그 데이터 예시(일부 항목 숨김처리)

로그데이터 예시

2. 품질 확보와 분석 프레임 설정

이번과 같이 로그 수집 프로세스가 처음 진행된 경우, 본격적인 데이터 분석을 진행하기 앞서 데이터 품질을 확보하는 것이 중요하다고 판단했습니다. 기존에 정의한 대로 각 필드 및 파라메터에 적절한 로그가 쌓이고 있는지, 누락되거나 이상한 데이터가 없는지 확인하고 만약 수정/보완이 필요한 경우 데이터 품질을 확보하는 작업을 진행하였습니다. 예를 들어, 아래 예시와 같이 수집이 잘못된 경우 유관자와 원인을 파악하고 문제 해결 과정을 통해 데이터 품질 확보에 많은 노력과 시간을 투입하였습니다.

데이터 수집 오류의 예시

데이터 수집 오류의 예시

또 다른 중요한 과정은 분석 프레임을 설정하는 것이었습니다. 일반적으로 로그 데이터의 경우 단기간에 몇 십만, 몇 백만 건의 데이터가 순식간에 쌓이고 로그 정의 항목은 수백 건에 달합니다. 무작정 데이터 탐색 분석으로 뛰어들 경우 망망대해에서 길을 잃고 허우적거리는 경험을 할 것 같았습니다. 따라서 목적을 명확히 설정하고 적절한 질문을 사전에 작성하는 것이 효과적일 것으로 판단했고, 로그 설계시 경험을 바탕으로 대략적인 프레임을 구축하여, 데이터 분석 및 인사이트 도출 과정에 유용한 나침반으로 활용하였습니다. 분석 프레임 설정의 예시는 아래와 같습니다.

  • 목적
    • 앱내 시나리오 및 기능을 개선할 수 있는 방안을 찾자 (궁극적으로 사용성 및 UX 개선)
  • 질문
    • 구간별 Conversion Rate은? 어떠한 기준으로 계산할 것인가? 세션 기준? DAU 기준으로?
    • Funnel 별 이탈율은 얼마나 될까? 주요 bottleneck 구간은 어디일까?
    • 각 단계별 주요 행동 패턴은? 주로 활용되는 기능은? 세부적인 개선점은?
    • 재구매율 혹은 재방문율은 어떠한가?
    • 지표 계산 방식은? 평균 재구매 시간? 시간이 오래 걸릴수록 패널티 주는 방식은?
    • 초기 주요 인사이트 및 시사점은?
    • 분석의 한계점 및 논의/개선 필요사항은?
  • 목적 - 전체 유저를 세분화하여 행동 패턴의 차이를 확인하자 » 핵심 그룹 타깃팅
  • 질문
    • 지역별에 따른 유저 행동 패턴의 차이는?
    • 주간 방문수 기준으로 구분하면?
    • 주문 경험 유 vs 무 여부로 구분
    • 신규 유저 vs 기존 가입 유저의 행동 패턴의 차이는?
    • 타 플랫폼 이용 경험 유 vs 무 (디바이스 크로스)가 결제에 미치는 영향은?
    • 주문한 카테고리 (예, 시킨 것만 시키는 그룹, 바꾸는 그룹)별로 구분하면?
    • 결제시 주문 방식별 세분화? 주문 방식별로 특이한 패턴은?
    • 클릭한 배너에 따른 결제율 차이는?

여담이지만, 현재 팀에는 분석가를 위해 전용 서버, Spark, Zeppelin 등 최적화된 분석 환경이 마련되어 있습니다. 쾌적한 환경 구축을 위해 애쓰신 엔지니어분들께 감사를 전하고 싶습니다. 또 로그 수집과 데이터 품질 개선을 위해 노력해주신 개발자분들께 감사를 전하고 싶습니다.

3. 디테일에 목숨걸지 말자!

로그 데이터를 추출해보면 난해한 결과가 나오는 경우가 있습니다. 경험상 주로 다음과 같은 이유로 발생하는 것 같습니다.

  • 로그 설계 과정에서 항목 누락 혹은 잘못된 필드/값 정의
  • 로그 데이터 관리 부족 (예, 업데이트된 서비스의 시나리오 및 기능을 기존 로그 설계에 반영 못했을 경우)
  • 데이터 품질 확보를 위한 노력 부족
  • 수집 과정에서 중복 데이터 발생 (아래 표 예시 참고)

위 4번에 해당하는 예시

위 4번에 해당하는 예시

위 항목 중 1,2,3 번의 경우 인적요인으로 인해 발생한 것이며, 실무자와 협의를 통해 해결 가능한 부분입니다. 4번의 경우는 기계적으로 수집되는 과정에서 자연스럽게 발생할 수 있는 부분입니다. 이 역시 협업을 통해 해결할 수 있으나, (엔지니어분과 개발자분들은 항상 바쁘므로) 4번 같은 경우 분석 과정에서 자체적으로 해결하는 것이 효과적일 것으로 판단했습니다.

즉 위 테이블을 그대로 읽으면, ‘UserNo가 천사(1004)인 유저가 MyPage 화면을 3초동안 5번 보았다’로 해석되는데, (유저는 기계가 아닌 인간이기에) 어떤 유저도 이런 식으로 앱을 이용하지 않을 것 같았습니다. 차라리 초(Second) 단위의 정보를 무시하고(중복 수집으로 판단), ‘2017년 5월 1일 10시 10분에 천사 유저가 MyPage를 1번 보았다’로 해석하는 것이 더 적절할 것으로 판단했습니다.

때로는 ‘이러한 방식이 세밀한 정보를 놓치는 것이 아닌가?’ 혹은 ‘너무 자의적인 해석이 아닌가?’ 라고 스스로 반문하기도 하였으나, (비록 정보 손실이 있더라도) 효율을 추구하는 동시에, 인간의 행동을 효과적으로 설명할 수 있는 해석이 타당해보였습니다. 결과적으로 기존 5개 행의 데이터를 중복으로 처리해 하나의 행으로 축약시켰으며, 유사한 데이터가 있을 경우 ‘무엇을 기준으로 중복 값을 제거하는 것이 적절한가?’에 대한 물음을 자문하며 분석을 진행했습니다. 이 과정에서 유용했던 것은 초반에 설정한 목적과 의미, 그리고 논리성과 인간을 기반으로 한 접근 방식이었던 것 같습니다.

4. 결과는 이해하기 쉽고 명확하게!

로그 데이터를 설계/수집하고 분석하는 일련의 과정은 이 업무의 절반에 해당한다고 생각합니다. 나머지는 분석 결과를 유관자에게 전달하고, 설득을 통해 실제적인 변화와 성과를 이끌도록 지원하는 것이라고 생각합니다. 이를 위해 분석 결과를 명확하고 간결하며, 이해하기 쉽게 전달하는 것은 매우 중요한 과정인 것 같습니다.

주니어 분석가 시절에는 시각화와 리포트 작성에 많은 노력을 투입했고, 단순하고 쉬운 방법론 보다 고급 방법론이 항상 좋은 것이라고 착각했었습니다. 하지만 아무리 고수준의 방법론이라도, 결과를 공유받는 상대로부터 실제적인 변화를 이끌어내지 못한다면 큰 의미가 없다는 것을 깨닫고, 아래 원칙을 토대로 커뮤니케이션하기 위해 노력하고 있습니다.

단순하고 이해하기 쉬운 그래프

단순하고 이해하기 쉬운 그래프

보기에 멋지지만 이해하는 데 시간이 오래걸리고 만들기도 어려운 시각화

멋있지만 복잡해 보이는 시각화 예시

5. 로그 데이터를 잘 활용하는 방법

일반적으로 로그 데이터를 수집/처리/분석하기 위해 많은 담당자분들이 노력과 시간을 투입합니다. 이러한 인적자원뿐 아니라, 서버 및 분석도구 등 시스템적 비용 역시 발생하기 때문에 데이터 활용도를 높이는 것이 중요하다고 생각합니다.

일차적으로 생각해볼 수 있는 각 영역/부문별 데이터 활용 방안은 아래와 같습니다.

  • 개발 영역
    • 버그 혹은 크래시율 수집 및 상시 트래킹
    • 이슈 발생 후 롤백 및 대응 등에 대한 의사결정 판단의 근거로 활용
    • 특정 기능에 대한 사용성 진단
  • 마케팅 영역
    • 마케팅 채널별 ROI 진단 및 비용 최적화
    • 배너/프로모션/이벤트 효과 측정
    • 유저 Segmentation, Targeting
  • 기획/디자인 영역
    • 시나리오/기능/디자인에 대한 성과 측정 및 개선 (A/B 테스트)
    • 유저 Journey 경로 분석 및 이탈 구간 개선 (UX/UI 최적화)
    • 유저 Persona 구축 (with 리서치) 및 신규 기능 Ideation
  • 기타 영역
    • 영업 및 CS 관련 대응
    • 사업 및 투자 성과 진단

6. 마치며

개인적으로 데이터가 비로소 그 가치를 발휘하는 순간은 분석 결과가 실제 비즈니스에 적용되어 가시적인 성과를 일으키는 것이라고 생각합니다. 다만 첫술에 배부를 수 없듯이, (작은 규모라도) 반복적인 프로세스로 운영하고 개선이 필요할 경우 기민하게 진행하는 것이 필요하다고 생각합니다. 이를 위해 부서간 기밀한 협업과 업무 프로세스에 대한 공감대 형성이 필요하며, 또 데이터에 대한 적극적이고 열린 태도로 업무를 진행하려는 노력이 필요할 것 같습니다.

더불어, 이를 지원할 수 있는 데이터 전문 인력과 변화에 열려있고 효율성을 추구하는 조직 문화, 유저 친화적인 시스템 등의 기반 역시 필요할 것 같습니다. 비록 데이터나 수치가 모든 비즈니스 문제의 해답을 말해주지 않지만, 문제 해결을 위한 실마리를 제공할 수도 있으니 부담 없이 한번 시도해보는 것은 어떨까요??