'온라인 테스트'에 해당되는 글 2건

  1. 2016.06.07 데이터 과학자의 실체
  2. 2015.11.11 테스트 및 평가 자동화
Share           Pin It

지난주 금요일에 제주에서 대한인간공학회 춘계학술대회가 있었습니다. 프로그램을 준비하시는 분께서 '전문가 세션 > 빅데이터'에 발표해줄 연사가 필요하다고 해서 흔쾌히(?) 수락했습니다. 처음에는 단순히 다음이나 카카오에서 했던 다양한 분석 사례정도만 모아서 '카카오에서의 빅데이터 분석 및 활용' 정도로 발표하면 쉽게 될 거라 생각했습니다. 그런데 청자들이 데이터 분석을 담당하거나 적어도 프로그래머/개발자라면 쉬울 수 있는데, 대부분 인간공학 전공자들이라서 단순히 사례들만 모아서 장광설을 펼치면 죽도 밥도 안 될 것 같다는 두려움이 생겼습니다. 발표자료를 준비할 시간이 겨우 한달정도밖에 없었는데, 여러 고민을 하다가 인간공학을 전공하는 학생들에게도 도움이 될 수 있는 테스팅 방법론을 중심으로 준비하기로 마음을 정했습니다. 온라인 A/B 테스트에서부터 MAB (Multi-Armed Bandit)까지 다루면 될 것 같았습니다. 그런데 또 막상 자료를 준비하다보니 원래 취지가 '빅데이터'인데, 너무 지협적인 문제만을 다루는 듯해서 조금 일반화시켜서 '데이터 과학자의 삶: 신화와 실체'라는 제목으로 정했습니다. 발표자료에서는 '온라인 테스팅'을 중심으로 다뤘지만, 데이터 과학에서 가장 감추고 싶은 실체는 데이터 준비와 정제인데, 이 내용은 말미에 짧게 넣었습니다.

 
슬라이드에 설명이 없으니 짧게 정리하면..

데이터 과학자은 수학/통계 지식과 프로그래밍 능력을 활용해서 데이터에서 비즈니스적 가치를 찾는 사람이다. 그래서, 수학 통계 지식도 필요하고 프로그래밍 스킬도 필요하다. 뿐만 아니라, 도메인 지식이 필요하다. 그러면 데이터 과학자는 슈퍼맨인가? 아니다. 실제 데이터 과학자들이 하는 일은 SQL을 잘 짜서 데이터를 뽑는 일만 한다. 그것도 무한 반복해서... 요즘 회사에 출근해서 가장 많이 보는 화면이 Hue 시스템이다. 그나마 터미널에서 작업하지 않는 것과 Hive 때문에 자바 등의 직코딩을 안해도 되는 것이 참 행복하다.

중요한 파트라서 화면을 캡쳐했는데... 실제 데이터 과학자들은 'SQL과 Data' 사이의 왔다갔다함이 일의 대부분이다. 여기서 인사이트를 얻으면 구현해서 테스트하고 배포한다. 아주 가끔 회귀분석이나 클래시피케이션 같은 고급 알고리즘을 사용하기도 한다. (KR = Knowledge Representation)

'김제동의 톡투유' 장면을 캡쳐했는데, 일반인들이 '빅데이터'에 대해서 생각하는 게 이런 화면이다. 많은 다양한 데이터를 모아서 빨리 가공해서 단어의 출현 빈도나 트렌드, 또는 키워드맵을 만드는 정도... 그러나 데이터에서 가치를 찾아내는 것이 요즘은 더 중요하다. 그래서 빅데이터보다는 스마트데이터로 변하고 있다. 단순히 엔지니어링 문제를 과학으로 바꾸는 것은 결국 분석력이다.

데이터 과학이 과학인 이유는 '과학적 방법'을 사용하기 때문이다. 과학적 방법은 1. 이론으로 증명하든지 2. 실험으로 검증하든지... 그런데 이론은 어렵다. 발표는 테스팅에 집중한다.

보통 과학에서의 실험은 문제에 대한 가설을 세우고 실험해서 실패하면 다시 가설을 세우고 다시 실험하고 이 과정을 반복하다가 실험이 성공하면 가설대로 논문을 작성해서 졸업하면 되지만, 서비스에서는 가설과 검증보다는 관찰과 테스트/비교를 거친다. 그리고 테스트가 성공해서 성공적으로 서비스를 런칭하더라도 다시 처음부터 관찰과 테스트를 무한반복한다. 그리고 온라인 테스트와 오프라인 테스트를 분리해서 진행하는 점도 특이하다. (넷플릭스는 일주일 단위로 '코드 배포 - 오프라인 테스트 - 온라인 테스트 - 서비스 배포'를 반복한다. 넷플릭스 개발자의 발표에서 직접 들은 것)

온라인 테스트는 A/B 테스트 또는 버킷 Bucket 테스트라고 한다. 파란 약과 빨간 약을 실제 사용자들에게 선택하라고 두고 많이 선택하는 걸로 정하면 된다. (인간공학회라서) 아이트래킹으로 비교할 수도 있다. 그런데 나는 데이터 과학자니 데이터로 확인한다. (같은 광고를 다른 타겟 사용자들에게 노출시키고 반응을 확인함)

A/B 테스트를 할 때 트래픽 기반으로 할 수도 있고 사용자 기반으로 할 수가 있다. (귀찮아서 그냥 글로 표현함)

50:50으로 실험군과 비교군을 만들 수 없다. 처음 런칭하는 서비스라면 괜찮지만, 이미 운영중인 서비스의 50%의 트래픽에 검증이 안/덜된 화면을 보여줄 수 없기 때문에 일부 (보통 5~10%)만을 실험군으로 정한다. 바이어스를 없애기 위해서 랜덤군도 둔다. 실험해야할 것들은 산적해있는데 매번 A/B로 나눠서 테스트하는 것은 여러모로 리소스 낭비이므로 실험군을 여러 개를 동시에 적용하고 모니터링 한다.

여담으로 네이버의 상징색이 녹색이듯이 다음의 상징색은 파란색이다. 처음에는 빨간색으로 하자는 의견도 있었지만 실제 사용자 반응에서 파란색으로 했을 때 PV나 클릭률 등이 더 높았다. (입사하기 전에 했던 전설로 들려오는 사례). 여담2. 외국의 경우 보통 엔지니어 중심으로 서비스가 만들어져서 데이터 기반으로 UI/UX를 정하는 것이 좀 일반적인데, 국내의 경우 처음부터 기획자나 디자이너가 함께 일하기 때문에 데이터 기반으로 화면을 구성하는 것이 오히려 더 낯선 풍경이다. (이미 기획자 및 디자이너들은 전문성이 있기 때문에 단순한 수치로 그들의 전문성에 의문을 제기하기는 어렵다. 그래서 UI/UX보다는 랭킹 관련된 곳에만 보통 온라인 A/B 테스트가 적용된다.)

서두에 말했듯이... 데이터 과학자는 마치 꽃길만을 걸을 것 같지만 그렇지 않다. 그리고 데이터 과학에서 알고리즘보다는 데이터가 더 중요하다. 포브스의 기사에 이게 잘 나타나있다. 데이터 과학자들의 업부에서 20%는 데이터를 정의하고 수집하는데, 그리고 60%는 데이터를 정제하는데 사용한다. 그리고 이걸 가장 싫어한다. 그러나 이게 데이터 과학자들의 숙명이다. 이걸 얼마나 잘하느냐가 데이터 과학의 성패를 결정한다. 알고리즘은 중요하다. 그러나 데이터가 나쁘면 알고리즘은 그냥...

정리하면, 데이터 과학은 비즈니스 골을 획득하기 위해서 데이터를 해킹하는 것인데, '바른 데이터 > 바른 평가 > 바른 알고리즘'이다. 나는 데이터 과학자/해커지만, 여러분들은 이런 방법론이나 데이터를 사용해서 '인간 해커'가 되기를 바란다. 그리고 제주에서 즐거운 시간을...

=== Also in...


댓글을 달아 주세요

Share           Pin It

지난 글 '데이터 문제 접근하기'에서 마지막 단계인 테스트가 중요하다고 적었습니다. 테스트와 관련해서 팀내에 공유했던 글이 있어서, 블로그/일반에 맞게 조금 수정해서 올립니다.

===

최근 구글의 데이터 사이언스에서 개설한 Unofficial Google Data Science 블로그에 가장 최근에 올라온 Experiment Design and Modeling for Long-term Studies in Ads의 주요 논문과 이 논문에 엮인 참조논문들을 보면서 (모든 논문을 제대로 읽은 것은 아님^^) (온라인) 테스트를 이해하는 도움글이 필요할 것같아서 간단히 글을 남깁니다.

테스트의 목적이야 새로 추가/개선된 기능이 실제 효과가 있는지를 미리 확인해보는 것입니다. 인터넷 업계에서는 새로운 기능을 모든 사용자들에게 한꺼번에 오픈하는 것이 아니라, 소수의 사용자들에게 먼저 적용해서 반응을 본 후에 전체에 공개하는 것이 일반적입니다. 당연히 반응이 나쁘면 기존 것을 유지하거나 새로운 개선안을 다시 테스트 합니다. 여러 대안이 있다면 그것들 중에서 가장 좋은 것을 선택하는 방법으로 테스트를 진행할 수도 있습니다. 여러 측면에서 테스트를 구분할 수가 있습니다.

오프라인 테스트와 온라인 테스트
오프라인 테스트는 새로운 기능이나 설정값을 실 사용자들에게 보여주고 반응을 추적하지 않고, 기존에 쌓아뒀던 로그 데이터를 이용해서 신규 기능이 적용됐을 때 어떻게 작동하고 어느 정도의 성능을 낼 것인가?를 미리 예측/시뮤레이션해보는 것입니다. 오프라인 테스트의 전제 조건이 충분한 (로그) 데이터입니다. 제대로 된 오프라인 테스트를 위해서 현재 로깅하는 것보다 훨씬 더 많은 데이터를 쌓아놓아야 하는데, 이게 현실적으로 불가능한 경우가 많습니다. 그래서 (정성적으로 확인이 됐다면) 오프라인 테스트를 스킵하는 경우도 종종 발생하고, 원래 봐야하는 평가 지표가 아닌 다른 2차, 3차 지표로 원래 지표를 확인해서 원래 지표를 가늠하는 수준에서 진행되는 경우도 있습니다.

오프라인 테스트가 기존의 데이터를 바탕으로 성능을 유추하는 것이라면, 온라인 테스트는 변경된 기능을 소수의 사용자들에게 실제 노출시켜서 반응을 보는 것입니다. 뒤에서 설명하겠지만 흔히 말하는 버킷테스트나 A/B 테스트가 온라인 테스트를 의미하는 경우가 많습니다. 제한된 사용자지만 실 사용자들의 반응을 확인함으로써 전체 적용 시의 효과를 미리 확인할 수 있습니다. 소수 (보통 5%나 10%)의 제한된 사용자들에게만 변경된 것을 노출시키기 때문에 성능이 더 나쁘더라도 전체의 성능 크게 떨어뜨리지 않는 방법입니다. 

버킷 테스트, A/B 테스트
온라인 테스트를 흔히 버킷 테스트라고 부르는데, 이는 특정 버킷 (선택된 제한된 사용자군)에게만 새로운 기능/설정이 적용되어서 (즉, 나머지 사용자들은 현재 설정대로 노출) 그들의 행동을 확인하기 때문에 버킷 테스트라고 부릅니다. 그리고 A/B 테스트라고도 부르는데, 이는 A그룹과 B그룹으로 나눠서 다른 것을 보여주기 때문입니다. A/B 테스트는 '현재 vs 신규'로 구분하는데, 경우에 따라서 'A, B, C, D...' 등으로 더 많은 그룹으로 세분화해서 동시에 테스트를 진행해서 가장 성능이 좋은 그룹/설정을 선택할 수도 있습니다. 실험에서 A그룹은 대조군 Control 또는 comparison으로 현재 상태를 그대로 적용한 그룹이고, B그룹은 실험군 Experiment로 새로 적용된 기능을 보여주는 그룹입니다.

구글이나 페이스북같이 수천만, 수억명의 사용자가 사용하는 서비스라면 1%미만의 버킷을 설정해도 됩니다. 테스트 버킷이 너무 적으면 결과의 신뢰성이 떨어지고, 너무 크면 실 서비스 지표에 영향을 주기 때문에 늘 그렇듯 적당히 (과학적인 글에서 비과학적인 표현이지만) 정하면 됩니다. 사용자나 PV가 적은 서비스라면 50% 버킷을 정해도 좋고, 아니면 특정 기간 (몇 시간, 하루 ~ 일주일 등)을 정해서 100% 버킷을 정해도 됩니다. 단, 기간으로 버킷을 정할 때는 계절/요일 등의 외부 요소에 의해서 서비스 지표가 달라진다는 점을 염두에 둬야 합니다. 온라인 테스트는 상시 진행되는 것이므로 버킷의 사이즈를 정하는 테스트를 먼저 진행하는 것도 필요할 수도 있습니다.

버킷 구분: 트래픽 기준과 사용자 기준
이런 버킷 또는 B그룹을 선택할 때 트래픽 기준으로 구분할 수도 있고, 사용자 기준으로 구분할 수도 있습니다. 트래픽 기준이라면 현재 들어오는 트래픽 중에 임의로 10%의 트래픽에는 신규 기능을 노출시키는 것입니다. 예를들어, 랜덤함수를 사용해서 0.1보다 작으면 신규 기능을, 0.1보다 크면 기존의 것을 그대로 보여주는 형태입니다. 이렇게 하면 구현 자체는 쉬울 수 있지만, 로그에 A/B그룹을 명시해줘야하는 불편함이 발생하고, 또 모든 사용자들에게 임의로 10%가 노출된다는 점이 장점이면서 단점일 수도 있습니다.

이에 비해서 사용자 기준의 경우, 10%의 사용자를 실험군으로 설정해서 그들에게만 신규 기능을 노출시키는 방법입니다. 보통 사용자 ID나 쿠키 정보를 활용해서 사용자를 구분합니다. ID를 사용하면 좋은 점은 ID가 시간이 변해도 바뀌지 않는다는 점이지만, 모든 사용자가 매번 로그인해서 사용하지 않는다는 단점이 있고, 쿠키 기반의 경우 쿠키가 변경되면 데이터 추적이 불가능하다는 단점이 있습니다. (특별한 경우가 아니면 쿠키가 변경될 가능성은 매우 낮음) 그리고, 사용자 기반의 경우 테스트 기간 동안 실험군을 고정시킬 수도 있고, 특정 주기마다 다른 사용자를 실험군으로 설정할 수도 있습니다. 특히 테스트의 편향성 bias를 체크하기 위해서 (알고리즘이 미적용된 깡통 서비스가 제공되는) 임의 random 버킷을 설정하는 경우가 있는데, 특정 사용자가 항상 임의 그룹에 속하게 되면 그 사용자들에게 늘 나쁜 서비스만 제공되기 때문에, 임의 버킷의 경우 주기적으로 (매시간/매일) 변경해주는 것이 좋습니다.

보통 ID체계를 숫자로 표시했을 때, 'ID mod 버킷수'로 해서 특정 나머지값을 가지는 그룹을 실험군으로 선택합니다. 예를들어, ID가 10153159337581569라면 10153159337581569 % 100하면 나머지가 69이므로, 이 사용자는 69번 버킷에 속하게 됩니다. 10153159337581569 % 10으로 해서 9번 버킷에 속할 수도 있습니다. 이런 식으로 버킷을 구분해서 원하는 비율만큼 실험군으로 정하면 됩니다. %100인 경우, 69번 버킷만 실험군으로 사용하겠다면 실험군은 1%가 되는 것이고, 68번 69번을 사용하겠다면 2%가 되고... 60(6#)번대를 모두 사용하겠다 또는 9로 끝나는 (#9)를 모두 사용하겠다고 하면 10% 버킷이 만들어 집니다. %1000으로 하면 더 세부적인 그룹이 만들어집니다. 그런데, 임의의 버킷을 만들기 위해서 ID체계도 임의적으로 적용돼야 한다는 점은 중요합니다. '1로 끝나는 모든 ID는 남성이고, 2로 끝나면 여성이다' 이런 식의 규칙이 있다면 임의 버킷을 만들 수가 없습니다. 물론, 필요에 따라서 성별, 연령 등을 구분해서 버킷을 만드는 경우도 있습니다.

A/B 테스트를 적용할 때, 트래픽 또는 사용자 기준 외에도 시간 기준으로도 적용할 수가 있습니다. 하루동안 모든 사용자에게 적용하고 롤백한다와 같이 모든 트래픽/사용자가 시간 기준으로' A그룹 - B그룹 (하루) - 다시 A그룹'이 되는 식입니다. 그런데 이건 참 위험한 방법입니다. 특히 B그룹이 적용됐을 때 예상치 못한 외부 효과 때문에 더 좋게/나쁘게 결과가 나올 가능성이 많기 때문입니다. 이런 외부효과에 영향을 받지 않기 위해서 같은 기간 동안 A/B그룹을 나눠서 함께 보고 비교하는 것이 일반적입니다. 보통 A/B 테스트를 진행한 후에 그냥 성능이 더 좋은 쪽 (예를들어, B)이 있으면 모든 사용자에게 그냥 B (신규 기능)을 적용하는 것이 일반적인데, 서두에 소개한 구글 블로그의 논문에서는 A/A - A/B - A/A 과정을 거치는 것을 추천합니다. 뒤쪽에 A/A를 진행하는 이유는 테스트 기간동안 B그룹에 속했던 사용자들이 신규 기능에 학습돼서 테스트 후에도 이상행동을 보이는지를 확인하기 위해서라고 합니다. 예를들어, 새로운 기능 B가 사용자들을 실망시켜서 테스트 기간 이후에 B그룹에 속했던 사용자들이 서비스에서 이탈해버리는 경우도 발생할 수 있습니다. 단기적으로 성능이 좋은 것도 중요하지만, 장기적으로 사용자의 학습에 의한 효과도 같이 보기 위해서라고 합니다. (자세한 것은 첫번째 논문 참고)

테스트에서 중요한 것 중에 하나가 편향성 bias이 없어야 한다는 점입니다. 앞서 말한 임의 ID 체계가 필요한 이유도 편향성을 막기 위한 것입니다. 그리고, 편향성을 막기 위해서 실험계획 Design of Experiment (DOE) 또는 Experimental Design이라는 게 필요한데, 이건 따로 공부하세요.

테스트에서 어쩌면 가장 중요한 것은 평가 지표입니다. IMPRESSION (광고에서 노출을 impression이라고 함)을 높일 것인가? 아니면 CTR을 높일 것인가? 등의 지표가 명확해야 합니다. 그리고, 1차 지표 외에도 다른 2차, 3차 지표도 함께 고려될 필요가 있습니다. 광고의 경우 CTR도 높아야 하지만, CTR이 높아졌다고 해서 전체 수익이 낮아지면 안되는 것과 같이, 실험 전에 1차지표 외에 2, 3차 지표도 함께 고민해야 합니다.

평가지표에서 (예를 들어, CTR) 테스트 기간을 거쳐서 단순히 B의 평균 CTR이 A의 평균 CTR보다 높아고 해서 그냥 B가 더 낫다라고 결론을 내리면 안 됩니다. 분산을 함께 봐야지 평균의 함정에서 벗어날 수 있습니다. A의 CTR이 10%이고, B의 CTR이 11%였는데, A와 B의 CTR분산이 모두 2~3%였다면 사실 A와 B가 다르지 않다라고 봐도 무관합니다. 이때 사용하는 방법이 ANOVA (Analysis of Variance)인데, 실험계획을 공부하면 실제 실험계획보다는 ANOVA를 더 중요하게 다룬다는 불편한 진실이...

ANOVA는 가설검증의 방법으로 주로 사용됩니다. 가설검증이란 귀무가설 (Null Hypothesis 또는 H0, A와 B는 같다)를 검증하는 것입니다. A와 B가 평균은 다르지만, 분산 때문에 신뢰구간 내에서 겹칠 수도 있다면 귀무가설을 기각합니다. 즉, 통계적 유의미성을 판단하는 방법입니다. 엑셀에서 ANOVA를 실행해보면 P-value, F-value 등이 나오는데, 이것들을 보고 통계적 유의미성을 판단합니다. 그런데, '과학적인 방법: 통계적 오류들'에서 설명하듯이 P밸류로 유의성을 판단하는 것이 항상 옳은 것은 아니라고 합니다. (참고 원문)

그리고, 온라인 테스트에서 가장 효과적인 검증을 위해서 수치를 그래프로 비쥬얼라이즈해주는 것이 가장 직관적으로 바로 판단할 수 있습니다. 테스트의 설계에서 비쥬얼라이제이션까지 모두 고려돼야... 숫자보다는 눈으로 보는 게 더 감이 오니까...


댓글을 달아 주세요