검색을 사례로 알아보는 온라인 서비스 분석 방법론
지난 글에서 언급한 온라인 서비스 분석 현장의 어려움은 검색 서비스 분석에도 그대로 적용된다. 1) 개별 질의어 및 사용자에 따라 평가가 달라질 수 있으며 2) 같은 질의어라도 시간에 따라 좋은 품질의 정의가 달라지며 3) 검색 서비스로서 사용자를 만족시켜야 하는 동시에 기업으로서 비즈니스 목표에도 관심을 가져야 하며 4) 검색 품질 자체에도 관련성, 신뢰성, 시의성 등 다양한 평가 척도가 존재하기 때문이다. 네이버 서치와 같이 다양한 팀으로 구성된 큰 조직에서는 모든 팀과 구성원이 동일한 목표를 갖고 움직이는 협응성(alignment)이 추가적인 과제가 된다.
이런 분석 과제에 대응할 수 있는 플랫폼, 지표, 프로세스의 총체를 분석 프레임워크로 정의하자. 분석 프레임워크의 목표는 이런 과제에 대응하여 서비스 조직 전체가 검색 품질에 대한 일관된 관점과 목표를 갖고 서비스 개발에 임할 수 있도록 하는 것이다. 이를 위해 분석 프레임워크는 다수의 조직 목표와 서비스 품질의 기준을 포괄적으로 측정할 수 있는 다양한 분석 방법과 지표를 포함해야 한다. 여기에는 사용자 로그에 기반한 온라인 분석, 레이블 및 서베이 기반의 오프라인 분석이 포함된다. 이런 다양한 수단을 병행하여 사용함으로써 개별 지표의 약점 및 편향을 보완하고, 분석 결과에 대한 교차 검증을 가능하게 한다.
분석 업무의 확장성과 지속적인 개선을 위해서는 분석 결과 만큼이나 분석이 수행되는 과정도 중요하다. 분석 자체를 수행하는 비용을 최소화하고, 필요에 따라 심층 분석이 가능한 해석가능한 결과를 제때 제공하여 개발팀이 신속하게 움직일 수 있도록 지원해야 할 것이다. 이를 위해서는 잘 문서화된 데이터 파이프라인과, 반복되는 분석 결과를 템플릿화하여 제공할 수 있는 분석 플랫폼, 분석 팀과 여러 파트너가 효과적으로 일할 수 있도록 지원하는 프로세스가 필요하다. 아래 그림은 이런 다섯가지 조건을 요약한다.
이제 분석 프레임워크의 구성 요소를 상세히 살펴보자. 우선 분석 결과를 제공하기 위한 데이터를 수집하고, 이에 대한 적절한 처리 및 분석을 수행하여 이해당사자에게 제공하는 데이터 및 분석 플랫폼, 분석 플랫폼의 내용물로서 분석 결과를 구성하는 다양한 지표와 질의군별/사용자군별 심층 분석을 지원하기 위한 분류 속성을 살펴보자. 마지막으로 분석 프레임워크의 존재 이유가 되는 다양한 분석 유형 및 프로세스를 살펴보자.
이제 이런 다양한 분석을 지원하기 위한 플랫폼을 살펴보자. 우선 검색 품질 평가를 위한 플랫폼의 경우 데이터의 유형에 따라 온라인 / 오프라인으로 나눌 수 있다. 오프라인 평가는 사용자 대상의 온라인 테스트를 하기 전에 UI 및 랭킹 모델의 적합성을 크라우드소싱을 통하 수집한 레이블을 가지고 평가하며, 온라인 테스트는 흔히 말하는 서비스 로그 기반의 A/B 테스트를 가리킨다. 두 플랫폼 모두 근간에는 각종 데이터 수집 인프라가 있고, 이를 바탕으로 평가 실험과 KPI 지표 관리 및 결과 분석을 위한 대시보드 형태의 UI를 제공한다.
네이버 서치에서는 최근에 Data&Analytics 및 관련 조직의 협업으로 온라인 (AB) 및 오프라인 평가 플랫폼이 개발되어, 네이버 서치의 다양한 팀이 필요로 하는 다양한 평가 실험 및 지표를 확장가능한 형태로 제공한다. 이미 네이버 서치의 모든 개선 과제를 평가 대상으로 다양한 실험을 진행 중이며, 향후 기대 효과로 조직 전체가 하나의 플랫폼을 공통으로 사용함으로써 일관된 기준, 툴, 프로세스에 근거한 평가를 수행할 수 있으며, 향후 플랫폼 고도화의 성과를 모든 조직이 공유할 수 있을 것이다. 자체 개발이 어려운 경우에는 최근에 다양한 AB Test 및 Crowdsourcing 플랫폼이 나와있으니 참고 바란다.
또한 대시보드와 같은 UI로 대응하기 어려운 다양한 커스텀 분석을 지원하기 위해 노트북 형태의 분석 템플릿을 개발하고 공유할 수 있는 환경을 지원하는 것도 현업 실무에서는 필수적인 부분이다. 네이버 서치에서는 최근 평가 및 기타 데이터 사이언스 업무를 뒷받침하기 위해 다양한 단위로 (페이지뷰별 / 세션별 / 질의별 / 사용자별) 평가 및 기타 분석에 필요한 속성을 모은 표준 데이터 파이프라인, 및 이를 기반으로 다양한 유형의 분석을 지원하는 JupyterHub 기반의 분석 환경을 개발하여 사용하고 있다. 평가 플랫폼과 마찬가지로 표준 데이터 및 분석 인프라의 사용은 조직 전체에 걸쳐 일관된 데이터 및 방법론을 활용한 분석 결과를 도출하는 것을 가능하게 한다.
이제 서비스 평가에 사용되는 다양한 지표를 알아보자. 우선 이들 지표는 사용 목적에 따라 나눠볼 수 있는데, 단일 지표로 모든 필요를 충족시킬 수 없기에 아래와 같이 다양한 특성을 갖는 지표들의 포트폴리오를 구성한다. 우선 Goal지표는 조직 전체의 목표가 되는 지표로, 사용자 수 혹은 서비스 사용량을 늘리는 형태로 정의되는 것이 보통이다. 하지만 이런 Goal 지표를 개별 서비스 변화로 곧바로 달성하는 것은 쉽지 않기에, Goal을 움직이는 핵심 동인으로서의 Driver 지표를 별도로 두고, 이를 서비스 변화시마다 그 가치를 평가하는 지표로 사용하는 것이 필요하다.
조직의 목표는 Goal및 Driver 지표로 상징되는 서비스 목표를 달성하는 것이지만, 이를 위해서 몇 가지 추가적인 지표가 필요하다. 이들 중 우선 Guardrail 지표는 Goal 및 Driver지표 달성 과정에서 발생가능한 부작용(side-effect)을 측정하는 것을 목표로 설정된다. 예컨대 아무리 좋은 변화라도 사용자의 체감 성능(페이지 로딩 타임)이나 페이지 내 다른 피쳐의 지표를 심각하게 훼손한다면 실서비스 적용 이전에 이부분이 고쳐져야 할 것이다. 마지막으로 Debugging지표는 문자 그대로 앞서 소개한 지표들의 움직임을 더 잘 이해하기 위한 보조 지표다. 아래 표에서 목표별 지표를 몇가지 사례와 함께 소개한다.
지표를 분류하는 데에는 이외에도 지표의 수학적인 특성 및 단위 (count, time, ratio), 측정하고자 하는 품질의 단편 (volume, quality, performance), 시간적인 선후관계 (leading or lagging), 지표가 계산되는 데이터 소스 (user log or survey data) 등에 따라 다양한 기준이 있다. 이런 세부 분류들은 향후 좀더 설명할 기회가 있기를 바라며, 여기서는 린 분석이나, 최근에 지표 개발에 대해 쓰인 논문 및 튜토리얼을 소개하는 것으로 갈음하고자 한다. 현대적인 온라인 서비스의 복잡성과 변화 속도를 고려할때 서비스의 성장 단계 및 특성에 맞는 다양한 지표의 개발의 중요성은 아무리 강조해도 지나치치 않다.
또한 지표 개발 만큼이나 중요한 부분이 분석을 위한 분류 속성의 개발이다. 온라인 서비스 분석을 위한 속성은 크게 사용자 (demographic, usage level, personal), 세션 (device, location, timing), 페이지뷰 (homepage, listing, item) 단위로 생각해볼 수 있으며, 검색 서비스의 경우 여기에 질의어의 주제 및 의도와 같은 다양한 유형이 추가된다. 온라인 서비스의 성장에 따라 서비스 변화가 개별 사용자나 시나리오에 따라 다른 영향을 끼치는 경우가 많기 때문에, AB테스트나 KPI 분석에서 이런 속성들을 사용하여 지표의 움직임을 세부적으로 분석하는 과정이 반드시 필요하다. (관련 논문)
위에서 소개한 지표 및 분류 속성의 정의 및 역할은 조직 전체가 일관된 방향으로 움직이기 위한 핵심 지식임을 기억하자. 따라서 이 역시 평가 플랫폼과 마찬가지로 최대한 표준화된 형태로 관리되어야 하며, 개별 지표 및 속성의 의미를 포함하는 관련 메타데이터도 역시 조직 구성원 누구나 쉽게 찾아볼 수 있는 형태로 관리되어야 한다. 이런 노력을 통해 조직 내 팀들이 같은 이름의 지표나 속성을 서로 다른 의미로 사용하거나, 비슷한 의미의 지표나 속성이 중복 개발 및 관리되는 데서 오는 혼란과 비효율을 최소화할 수 있다. 관련해서 최근에 다양한 메타데이터 관리 및 데이터 카탈로그 솔루션이 개발되고 있다. (관련 링크)
위에서 설명한 분석 플랫폼과 지표가 실제로 적재적소에 사용되며, 관련 플랫폼 및 지표에 대해서도 지속적인 업데이트 및 개선이 이루어지기 위해서는 분석 유형에 따른 다양한 업무 프로세스가 정의되어야 한다. 이를 연단위로 살펴보면 1) 연간 목표 설정 & 점검 2) 지속적인 피쳐 런치를 통한 제품 개선 3) 지속적인 Incident Tracking & Recovery 4) 연중 꾸준히 지표 및 플랫폼 개선 순으로 나열할 수 있다. 다음은 여기에 포함되는 주요 분석 유형 및 프로세스에 대한 간략한 설명이다.
데이터 사이언스라는 개념이 생기기 전에도 조직의 목표와 관련된 주요 지표(Key Performance Indicators: KPI)를 설정하고 이를 트레킹 하는 업무에는 데이터가 사용되어 왔다. 관련된 업무는 조직의 비즈니스 사이클(주로 1년)에 따라 결정되는데, 우선 연초에 조직 방향 설정과 함께 KPI 및 목표 수치를 구성원의 합의에 바탕을 두고 결정한다. 목표 대비 달성도는 꾸준히 추적하며, 관련해서 발생하는 이슈는 관련된 조직과 함께 최대한 신속히 대응한다. 연말에는 조직 리더들과 목표 달성 정도를 수치화하고 이를 차기 계획 수립에 반영한다.
서비스 개발 과정에서 요구되는 분석 플랫폼 및 지표의 주 역할은 현재 서비스 대비 제안된 알고리즘 및 UX 변화가 얼마나 더 나은지를 평가하는 것이다. 이를 위해 분석 조직은 서비스 개발 / 기획 조직과의 긴밀한 협의를 통해 개별 검색 피쳐에 적절한 평가 방법을 정의하고 이를 수행하여 결론을 도출한다. 이 과정이 효율화 및 표준화될수록 더 많은 변화가 공정하게 평가되고, 이들 변화가 실제로 서비스 개선에 기여할 수 있다. 또한, 평가 지표는 보통 KPI와 연계되어, 더 많은 제품 개선이 이루어질수록 KPI 개선에도 연계되도록 한다.
서비스 변화에 대한 평가 이외에도, 서비스에 대한 사용자의 반응에 이상 징후는 없는지, 혹은 서비스 장애와 같은 문제가 없을지 상시적으로 모니터링하고, 이슈가 발생할 때 이를 심층 분석하는 프로세스가 필요하다. 이를 위한 지표와 플랫폼은 기본적으로 평가를 위한 플랫폼과 동일하지만, 실제 서비스의 지표 변화 혹은 실제 서비스와 경쟁사의 비교에 초점을 맞춘다는 차이가 있다. 이를 지원하기 위해 기술적으로는 False Positive와 False Negative간의 균형을 맞춘 시계열 분석 및 이상 탐지 등이 필요하다. (관련 논문)
온라인 서비스를 둘러싼 여러 환경은 끊임없이 변화하며, 따라서 분석 플랫폼 및 지표 역시 지속적인 업데이트를 필요로 한다. 조직 전체가 목표로 삼는 KPI 지표의 경우 특히 지속적으로 조직 방향 및 검색 사용 패턴에 비추어 그 정합성을 리뷰하여 필요에 따라 업데이트해야 한다. 또한 온라인/오프라인 평가 지표의 경우에도 평가 대상 피쳐의 특성에 맞춘 업데이트가 필요하다. 이 과정에는 플랫폼과 지표 개발을 담당하는 조직 이외에도 개발 및 기획 조직 각 부문의 리더들의 피드백이 포함되어야 한다.
이번 글에서는 온라인 서비스 분석의 큰 그림을 플랫폼, 지표, 프로세스의 관점에서 소개했다. 오늘 살펴본대로 온라인 서비스 분석에서 발생하는 다양한 어려움은 다양한 지표와 이를 뒷받침하는 플랫폼, 그리고 이런 분석 결과를 실제 업무와 연결짓는 프로세스를 통해 해결할 수 있을 것이다. 다음 글에서는 각각의 구성요소를 좀더 상세히 살펴보자.