LINE 유저 행동 분석 플랫폼
120가지 사용자 행동 분석을 자동화할 수 있는 ‘데이터 제품’ 만들기
'데이터 제품을 소개합니다' 매거진에 제가 PM을 맡아 참여한 프로젝트를 간단히 소개해보려 합니다. 이전 직장이었던 라인에서 'LINE User Activity Analytics (LUA Analytics)' 라는 프로젝트입니다.
2년이 훌쩍 넘은 프로젝트인데, 회사 기술블로그에 남겨두고 브런치에는 옮겨둔 적이 없었습니다. 돌이켜보면 이 프로젝트를 진행하면서 앞으로 데이터 분석가의 역할은 무엇일지에 대해 많은 생각을 하게 되었던 것 같습니다.
LUA Analytics는 표면적으로는 다양한 서비스의 유저 행동에 대해 여러가지 지표로 분석할 수 있는 대시보드입니다. 그 이면에는 대시보드에서 제공하는 '행동'과 '지표'를 쉽고 빠르게 확장할 수 있는 프로세스가 설계되어 있습니다. 동일한 내용을 아래 라인 엔지니어링 블로그 링크를 통해 읽어보실 수도 있습니다.
들어가며
안녕하세요. LINE에서 데이터 분석을 맡고 있는 Insight Planning 팀의 박용재입니다. 이번 글에선 LINE의 통합 대시보드인 LINE User Activity Analytics(이하 LUA Analytics)가 개발된 과정을 소개하겠습니다.
LINE은 채팅과 SNS, 영상 통화 등 서로 다른 다양한 성격의 서비스를 탑재하고 있는 플랫폼입니다. KPI를 추적하기 위해 각 서비스별로 10가지 이상의 대시보드를 개발해 운영하고 있으며, 각 대시보드를 지탱하기 위해 700가지가 넘는 데이터베이스를 운영하고 있습니다. LUA Analytics는 이렇게 많은 대시보드와 데이터베이스를 통하지 않고도 LINE 전반을 아우르는 사용자 행동을 하나의 플랫폼에서 추적할 수 있도록 만들기 위한 대시보드 통합 프로젝트입니다. 데이터 분석 팀과 데이터 엔지니어링 팀이 함께 문제를 풀어나간 과정을 정리했습니다.
LINE의 데이터 분석을 ‘제품화’하려면?
Google이 데이터 분석 소프트웨어에 3조 원을 투입한 이유는?
작년 6월, Google은 약 3조 원을 투자해 Looker를 인수했습니다. 같은 시기에 Salesforce는 무려 18조 원을 들여 Tableau를 인수했습니다. 두 회사는 모두 빅데이터를 분석할 수 있는 소프트웨어를 만드는 회사입니다. 특히 Tableau는 LINE에서 활발히 사용하고 있는 도구이기도 하죠. 저는 Google과 Salesforce가 거액을 들여 이 회사들을 인수한 이유가 궁금했는데요. Looker의 CDO(Chief Data Officer)가 작성한 짧은 글을 통해 조금이나마 배경을 이해할 수 있었습니다. 그중 일부를 옮겨 보았습니다.
“데이터 분석가는 늘 다른 조직으로부터 많은 과제를 요청받고, 분석가는 각 요청의 우선순위를 따져 대응합니다. 그런데 이런 방식은 회사 데이터의 크기나 쓰임새가 적을 때에나 가능한 방식입니다. 요즘의 데이터 환경에선 이런 업무 방식이 잘 작동할 수 없습니다. 하나하나 대응하기에는 분석 요청이 너무 많고, 이 모든 요청에 능숙하게 대응하기 위해 분석가들이 알아야 할 데이터도 너무 많습니다. 이런 상황을 해결하기 위해 필요한 것이 바로 ‘데이터 제품’입니다.”
요약하면 ‘데이터 분석’ 또한 사람의 역량이 아닌 ‘제품’으로 만들어서 다뤄야 한다는 것을 이야기하고 있습니다.
분석 지표를 바로 확인할 수 있는 제품을 만들자!
LUA Analytics가 시작된 배경도 글로벌 기업들의 행보와 맥락을 같이 합니다. 오랫동안 ‘LINE의 서비스별 주요 지표를 한눈에 비교하고 분석하고 싶다’는 요청이 있었습니다. LINE의 수십 가지 서비스에서 KPI 대시보드를 개별적으로 운영하고 있기 때문입니다. 개별 대시보드에서 제공하는 지표들은 공통적인 부분이 많습니다. 하지만 데이터 출처도 다르고 로그 정의가 복잡해서, 같은 지표로 두 가지 이상의 서비스를 비교 분석하려면 상당히 많은 과정을 거쳐야 합니다. 더군다나 글로벌 사용자가 남기는 로그의 양이 아주 많기 때문에 데이터 처리에 상당히 많은 시간이 소요되기도 합니다.
LUA Analytics는 데이터 분석에 필요한 기초적인 지식이 없더라도 ‘데이터로부터 인사이트를 얻을 수 있는 제품’을 목표로 합니다. 널리 사용되는 제품에 비교한다면 App Annie Intelligence와 유사합니다. App Annie Intelligence는 모바일 앱의 전 세계 다운로드 수와 사용량, 평점 추이 등을 제공합니다. 이를 통해 앱 생태계의 인사이트를 얻을 수 있는데요. App Annie Intelligence로 다양한 지표를 활용하고 싶을 때, 사용자는 ‘칼럼’이나 ‘피벗’, ‘디멘젼’과 같은 가장 기초적인 분석 용어도 알 필요가 없습니다.(각주 1)
제품화를 위한 핵심 문제 정의하기
작년 9월, 서비스별 주요 지표를 빠르게 모아서 비교하는 과제를 급히 진행하게 되었습니다. 흩어진 대시보드와 원천 데이터에서 직접 지표를 수집해가며 페이지를 채워 나갔는데요. 이렇게 1주일을 소요해 작성한 페이지의 반응이 꽤 좋았습니다. 많은 사람들이 ‘앞으로도 이렇게 한눈에 볼 수 있으면 좋겠다’는 피드백을 주었고, ‘새로운 서비스도 같이 볼 수 있는가?’ 혹은 ‘이 지표도 추가로 확인 가능한가?’라는 질문도 함께 주었습니다.
이런 배경에서 파일럿 프로젝트를 시작하게 되었습니다. 파일럿 프로젝트는 많은 사람들이 의사결정 상황에서 데이터를 쉽고 빠르게 활용하고 싶어 한다는 니즈에 집중했습니다. 현실적으로 모든 기획자와 디자이너, 마케터, 서비스 운영자가 코드나 쿼리로 데이터를 추출하고 분석할 수 있는 스킬을 보유하는 것은 불가능합니다. 따라서 개발이나 데이터 분석 조직의 도움 없이도 바로 분석 결과를 확인할 수 있는 완성된 형태의 대시보드를 제공해야 했습니다. 약 2개월간 진행한 파일럿 프로젝트를 통해 다음 네 가지의 핵심 문제점을 정의했습니다.
새로운 서비스나 새로운 피처에 빨리 대응하기 어렵다
초기에 범위를 설정한 이후, 지속적으로 서비스나 피처를 대시보드에 추가하는 것은 데이터 전문 조직만의 역량으로는 커버할 수 없습니다. 의미 있는 사용자 행동을 파악하기 위해서는 각 서비스에 대한 이해가 선행되어야 합니다. 또한 현재 데이터 카탈로그에 등록된 700개가 넘는 데이터베이스 중 어떤 테이블과 어떤 조건으로 분석해야 하는지 알아내는 것은 더 어렵습니다. 지속적으로 추적이 필요한 주요 사용자 행동을 정의 내리는 것부터 각 서비스 담당자의 참여가 필수입니다.
비정기적으로 테이블이 변경되고, 모든 변경 건을 추적할 수 없다
서비스별로 효율적인 분석을 위해 원천 데이터를 1차 가공하여 관리하는 중간 테이블이 있습니다. 종종 성능을 개선하거나 새로운 이슈에 대응하기 위해 내부적으로 중간 테이블을 교체하기도 하고 쿼리 조건을 변경하기도 하는데요. 이를 하나의 데이터 분석 조직에서 모두 추적하기란 불가능합니다. 1번 문제점과 마찬가지로 각 서비스 데이터 담당자의 참여가 필요합니다.
예상되는 분석 요청에 자동화된 대시보드로 대응할 수 있어야 한다
예상 가능한 범위의 분석 요청에 대해서 선제적으로 결과를 제공할 수 있어야 합니다. 예를 들어 A 서비스는 성연령 분포에 대해 문의합니다. B 서비스는 신규 사용자의 규모에 대해 요청합니다. C 서비스는 특정 사용자 행동이 급증한 경우에 어뷰징(abusing)이 있는지에 대한 확인을 요청합니다. 하지만 상황에 따라 A 서비스도 신규 사용자 규모나 어뷰징 판별 분석을 요청할 수 있습니다. 즉, 각각의 분석 주제는 시기만 다를 뿐 어느 서비스든 문의할 수 있는 것입니다. 그래서 서비스 간 교집합을 찾기보다는 각 요청을 아우르는 공통분모를 커버할 수 있어야 합니다.
데이터 연산 시간이 지속적으로 증가하여 배치(batch) 작업이 불안정하다
대시보드를 안정적으로 운영하기 위해서 매일 수백억 건의 로그를 처리하는 과정을 거칩니다. 그리고 분석 지표를 연산하는 과정은 로그 처리보다 더 긴 시간이 소요됩니다. 매월 지표가 갱신되는 일정이 지연되거나 일정하지 않다면, 대시보드를 활용하는 사용자가 큰 불편을 겪을 수 있습니다. 분석해야 할 대상은 더 늘어나므로, 데이터 처리 과정을 지속적으로 개선해야 합니다.
이렇게 정의한 문제점을 바탕으로 작년 12월 LUA Analytics 프로젝트가 시작됐습니다. 서비스와 지표를 유연하게 추가할 수 있도록 전체 구조를 확장 가능하게 설계하고, 각 서비스의 데이터 공급 부담을 최소화하는 협업 체계를 구축하는 것을 가장 높은 우선순위에 두었습니다.
LUA Analytics 작동 원리
LUA Analytics는 최초의 로그 데이터에서부터 대시보드에 서빙하기까지 아래와 같이 크게 세 단계를 거쳐 작동합니다.
그림 1. LUA Analytics 파이프라인위 그림과 함께 각 단계를 살펴보겠습니다.
Step 1 – ‘공통 데이터 포맷’으로 집계하기
각 서비스에서 수집하는 데이터는 범위와 칼럼명, 데이터 타입 등의 형태가 서로 다릅니다. 이를 하나의 분석 테이블로 통합하기 위해 공통 포맷으로 사용자별 특징을 1차 집계합니다. 각 서비스 공간에 쌓인 데이터는 LUA Analytics 데이터베이스에 월 단위로 통합합니다.
Step 2 – ‘지표 생성 모듈’을 통해 하나의 ‘액티비티별 지표 테이블’ 만들기
공통 포맷으로 집계된 모든 일별, 월별 테이블을 지표 생성 모듈에 밀어 넣습니다. 지표 연산이 완료되면 하나의 테이블에 요약하는데요. 예를 들어 ‘메시지 전송 – 평균 이용일수 23.8일’, ‘그룹 통화 참여 – 2개월 내 복귀 유저 비율 56%’와 같이 서비스 및 액티비티별 지표 결과만 모아서 저장합니다.
Step 3 – ‘통합 대시보드’ 제작하기
대시보드는 지표 결과만 통합된 하나의 테이블을 대상으로 제작합니다. 이 테이블은 크기가 작고 가볍기 때문에 이를 기반으로 대시보드에 여러 지표를 빠르게 표현할 수 있습니다.
이 중 Step 1과 Step2의 핵심인 ‘공통 데이터 포맷’과 ‘지표 생성 모듈’, ‘액티비티별 지표 테이블’, 이 세 가지 구성 요소에 대해 조금 더 상세히 설명하겠습니다.
공통 데이터 포맷
아래 그림과 같이 ‘어느 국가의, 누가, 어느 기기로, 언제, 무엇을(activity), 몇 번 했는가?’와 같은 방식으로 하루의 활동을 6가지 칼럼으로 집계합니다.
그림 2. 공통 데이터 포맷 예시액티비티를 정의하고 공통 테이블에 데이터를 쌓는 것은 각 서비스의 기획자와 데이터 엔지니어가 담당합니다. 반드시 추적해야 할 사용자 행동이 무엇인지 가장 잘 알고 있고, 간혹 발생하는 테이블 변경사항이나 신규 API 조건 추가 등의 서비스별 상황에 가장 정확하게 대응할 수 있기 때문입니다. 이렇게 공통화된 일별-사용자 테이블은 LUA Analytics가 작동하는 근간이 됩니다.
공통 테이블에서 ‘국가’와 ‘기기 정보’를 제거하면 ‘일별(언제)-사용자별(누가)-액티비티별(무엇을)-행동 횟수(얼마나)’ 형태가 남습니다. 이러한 테이블 구조는 모바일 앱 외에 다른 분야에서도 널리 쓰이는 범용적인 포맷입니다. 예를 들어, 신용 카드사는 ‘일별(언제)-회원별(누가)-카드 종류별(무엇을)-결제금액(얼마나)’, 커머스 회사는 ‘일별(언제)-고객별(누가)-상품 카테고리별(무엇을)-주문금액(얼마나)’ 형태로 사용자 특성 정보를 요약하여 저장합니다. LUA Analytics는 이런 범용적인 포맷을 사용하기 때문에 요구 사항을 단순하고 명료하게 전달할 수 있습니다. 또한 개별 사용자 단위로 데이터를 보존하기 때문에 다양하고 새로운 지표를 생성할 수 있는 확장성도 확보했습니다.
지표 생성 모듈
공통 데이터 포맷으로 수집된 데이터는 LUA Analytics 데이터베이스에 월 단위로 통합됩니다. ‘지표 생성 모듈’은 통합 테이블을 기준으로 모든 지표를 생성합니다. 즉, 각 서비스에 추가로 데이터 수집 요청을 하지 않더라도 새로운 지표를 개발하고 대시보드에 반영할 수 있습니다. 모든 서비스가 통합된 테이블을 대상으로 연산하기 때문에 이 과정에서 꽤 많은 컴퓨팅 자원이 필요합니다. 그래서 쿼리 최적화와 데이터 병렬 처리 방식 재설계 등 지속적으로 ‘지표 생성 모듈’의 성능을 개선해야 합니다. 프로젝트 초반에 전체 지표 연산 시간을 측정한 결과 약 4~5일가량 소요됐는데요. 현재, 서비스와 지표가 더 늘어나 매월 350억 건 가량의 레코드를 대상으로 지표를 생성하고 있음에도 불구하고 소요 시간을 1일 미만으로 단축해냈습니다. 덕분에 매월 2일에는 전월의 모든 액티비티에 대한 분석 지표를 조회할 수 있습니다.
액티비티별 지표 테이블
‘액티비티별 지표 테이블’은 각 액티비티의 특징을 압축 및 요약하는 테이블입니다. 여기에 매월 동일한 포맷의 데이터가 국가와 OS 유형별로 누적된다는 점을 반영하면, 테이블 구조는 액티비티 축 – 지표 축 – 비교 기준 축을 가진 3차원 배열로 간단히 표현할 수 있습니다. 액티비티 축을 따라가면 여러 서비스 간 비교가 가능하고, 지표 축을 따라가면 특정 액티비티를 다각적으로 분석할 수 있으며, 비교 기준 축을 따라가면 특정 액티비티-지표의 월별 트렌드 혹은 국가나 OS 유형별 차이를 확인할 수 있습니다.
그림 3. 액티비티별 지표 테이블액티비티와 지표가 무엇을 의미하는지 살펴보겠습니다.
액티비티: 서비스의 성공을 측정할 수 있는 사용자 행동, 또는 서비스가 사용자에게 기대하는 행동을 가리킵니다. 서로 다른 서비스에 속해 있지만 같은 기준으로 데이터를 수집하고 비교할 수 있는 기본 측정 단위가 됩니다. 예를 들어, ‘LINE Timeline 포스트에 좋아요 누르기’나 ‘오픈챗 대화방에 참여하기’, ‘대화방에서 동영상 보내기’, ‘생성한 아바타를 프로필에 등록하기’, ‘콘텐츠를 LINE Keep에 저장하기’, ‘그룹방에 등록된 노트 리스트 보기’, ‘스토리 생성하기’ 등이 서비스에서 추적하고 있는 액티비티입니다.
지표: 분석을 통해 하나의 숫자로 요약되는 결과값입니다. ‘MAU’나 ‘사용자당 이용 횟수’와 같이 단순한 과정으로 측정할 수 있는 지표도 있지만, ‘상위 핵심 사용자의 기여도’와 같이 비교적 복잡한 로직을 거쳐야 하는 지표도 있습니다. LUA Analytics는 사용자 분석을 통해 지표화할 수 있는 모든 숫자를 제공하는 것을 목표로 합니다.
현재 LUA Analytics는 12가지 서비스와 120가지 액티비티, 20가지 분석 지표(각주 2)를 제공하고 있습니다. 올해 안으로 2가지 서비스와 25개 액티비티, 3~4가지 지표를 추가로 제공할 예정인데요. LUA Analytics는 유연하게 확장할 수 있어서, 공통 포맷 테이블과 지표 생성 모듈에 새로운 액티비티와 지표를 추가하기만 하면 됩니다.
어떻게 활용할까?
훨씬 빨라진 분석 요청 대응
지난 8월, LUA Analytics 베타 버전 구축 이후 분석 팀은 아래와 같은 여러 가지 질문들을 빠르게 해결할 수 있었습니다. 과거엔 답을 찾는 데 1주일이 걸렸던 질문을 1분 내로 해결한 것도 있었고, 데이터 서버가 분리되어 있어 해결할 수 없던 질문도 해결할 수 있었습니다.
LINE의 120가지 액티비티 중 10대가 가장 많이 하는 액티비티는 무엇인가요?
최근 6개월 내 ‘개인 간 영상 통화’를 이용해 본 경험이 있지만 ‘그룹 영상 통화’는 한 번도 이용한 적이 없는 사용자는 얼마나 되나요?
5월에 서비스 MAU가 급격히 증가한 후 6월에는 동일한 수준을 유지하고 있는데요. 5월 사용자들의 리텐션 비율이 얼마나 될까요?
통합 검색 출시 이후 MAU가 성장하고 있습니다만, 소수 사용자들만 집중적으로 이용하는 것은 아닌지 확인할 수 있을까요?
인앱 카메라 기능은 iOS와 Android 사용자 간 사용성 수준에 큰 차이가 있을까요?
최근 출시한 LINE 아바타의 초기 서비스 진단에도 LUA Analytics를 매우 효과적으로 활용했습니다. 대부분의 경우 대시보드를 통해 즉시 지표를 확인할 수 있었고, 아래와 같이 원래 지표 범위에 포함되어 있지 않는 분석 주제도 ‘공통 포맷 사용자 단위 테이블’과 ‘액티비티별 지표 테이블’을 조합해서 유연하고 빠르게 대응할 수 있었습니다.
성연령 분포가 가장 유사한 기존 서비스는 어떤 것들이 있을까요?
주요 액티비티 7가지 중 2가지 이상을 수행한 사용자는 얼마나 되나요?
국가별, 성연령별 액티비티 조합은 어떻게 다를까요?
‘A 액티비티’와 ‘B 액티비티’는 흐름상 선후 관계에 있어 퍼널(funnel) 분석 대상이 됩니다. 국가별 전환율이 어떻게 차이 날까요?
기대 효과와 가능성
이 프로젝트의 최종 목표는 모든 LINE 구성원의 데이터 활용 수준을 향상시키는 것입니다. 이를 위해서는 ‘질문의 맥락’에 ‘분석 속도’를 맞출 수 있어야 합니다. 누군가가 분석과 관련된 질문을 던질 때, 바로 숫자로 응답하는 것이 이 프로젝트의 핵심 과제입니다.
더불어 데이터 분석 조직의 자원을 더욱 효율적으로 활용할 수 있게 되는 것도 기대하고 있습니다. 데이터 추출 및 가공에 소요되는 시간과 자원을 대폭 줄이면서 더 긴급하고 중요한 과제를 위한 기회를 확보할 수 있도록 돕는 것입니다. 실제로 LINE Timeline 팀에서는 핵심 사용자 활동에 대한 지표 분석은 가급적 LUA Analytics에 맡기고, 조직 내부에서는 분석 과제에 집중할 수 있는 환경을 조성해 나가고 있습니다.
또한 공통 포맷으로 통합한 데이터베이스는 그 자체로 잘 정제된 데이터 자산입니다. 사용자들이 LINE 플랫폼 위에서 얼마나 다양하게 활동하고 있는지 수준을 파악할 수 있습니다. 사용자별-액티비티별 활동량 데이터는 사용자 세그먼테이션의 기준이 되거나 그 자체로 기계 학습 데이터 셋으로 유용하게 활용할 수 있습니다.
마치며
높이가 8,848미터에 이르는 에베레스트산은 많은 산악가들이 도전하는 세계에서 가장 높은 산입니다. 1921년부터 2018년까지 4,833명이 정상 고지를 밟았는데요(각주 3). 기록을 살펴보면 특이한 점이 있습니다. 2018년 한 해에만 802명이 등반에 성공했다는 점입니다. 100년의 기록에서 17%에 가까운 기록이 2018년 한 해에 만들어졌다는 건데요. 과거와 비교해 갑자기 성공 횟수가 늘어난 이유는 5,364미터에 베이스캠프가 설치된 덕분입니다. 높이 설치된 베이스캠프로부터 숙박과 물자를 지원받으며 도전한 덕분에 성공 횟수가 급격하게 늘어나게 된 것이죠.
데이터에서 인사이트를 찾는 과정은 에베레스트산 등반에 비유할 수 있습니다. 인사이트를 얻는 고지가 데이터가 있다고 해서 누구나 올라갈 수 있는 고지가 아니라는 점에서 그렇고, 튼튼한 베이스캠프가 높이 설치된다면 더욱 많은 사람들이 정복할 수 있는 고지라는 점에서도 그렇습니다. 앞으로 더욱 많은 LINE 구성원들이 LUA Analytics라는 베이스캠프를 활용해 보다 쉽고 빠르게 데이터에서 인사이트를 얻어 의사 결정에 접목할 수 있기를 기대합니다.
각주)
1. Microsoft Excel 또는 Google Analytics에서 사용하는 용어입니다. LUA Analytics는 많은 사람들에게 익숙한 Google Analytics와는 조금 성격이 다른데요. Google Analytics는 웹에서 수집한 로그를 기반으로 ‘사용자가 직접 자기 입맛에 맞게 분석 화면을 구성하고 공유할 수 있는 도구’인 반면, LUA Analytics는 ‘서비스에 대한 분석이 완료된 지표와 시각화 결과물을 제공하는 도구’입니다. 이런 점에서 App Annie Intelligence와 더 유사합니다.
2. 지표는 4가지 영역(Volume, Retention, Demo, Heavy User)으로 구성됩니다.
Volume: ‘얼마나 많은 사용자가, 얼마나 많은 액티비티를 하는가? 또한 LINE 전체 사용자 대비 비율은 얼마나 되는가?’에 대한 답을 찾아가는 영역입니다. ‘MAU(Monthly Active Users)’, ‘DAU(Daily Active Users)’, ‘사용자당 액티비티 횟수’, ‘서비스 사용률(adoption)’ 등이 있습니다.
Retention: ‘사용자가 지속적으로 혹은 반복적으로 수행하는 액티비티인가?’를 측정합니다. 비슷한 MAU 규모의 서비스라도 리텐션 사용자 구성에는 큰 차이가 있을 수 있습니다. ‘월평균 활동 일수’, ‘활동 일수별 분포’, ‘Stickiness(DAU/MAU)’, ‘기간별 복귀 사용자 비율’ 등이 있습니다.
Demo: 성연령 구성 비율을 확인할 수 있습니다. 사용자 기준과 활동 횟수 기준으로 구분하여 제공됩니다. 실제 사용자는 50대가 많더라도, 활동 횟수는 10대 사용자가 월등히 많은 액티비티가 상당히 많습니다.
Heavy User: 소수의 상위 사용자가 얼마나 높은 비율로 기여하는지 알 수 있습니다. 특히 신규 론칭한 서비스에 대해 소수의 얼리어답터만 많이 사용하고 있는지, 시간이 지날수록 상위 사용자에 편중되는 이용량이 줄어드는지를 확인할 수 있습니다.
앞으로 ‘액티비티 간 교차 이용 규모 및 관련성’, ‘활동 기반 사용자 세그먼테이션’ 등 다양한 분석 결과를 지표로 제공할 예정입니다.
3. 출처: Himalayan Database
