Skip to content

Posts A-B testing online games #
Find similar titles

(이 글은 박스앤위스커 홈페이지강규영 개인 블로그에 중복으로 게재되었습니다.)

A/B 테스팅 개념을 소개하고, 온라인 게임에서 A/B 테스팅을 하는 방법, 주의할 점, 점진적으로 테스팅을 도입하는 전략, 단점들에 대해 생각하는 바를 정리해보았다.

A/B 테스팅이란 #

보통 A/B 테스팅(A-B testing)이라고 하면 웹 사이트 방문자를 임의로 두 집단으로 나누고, 한 집단에게는 기존 디자인을 보여주고 다른 집단에게는 새로운 디자인을 보여준 다음, 두 집단 중 어떤 집단이 더 높은 성과를 보이는지 측정하여, 새 디자인이 기존 디자인에 비해 좋은지를 정량적으로 평가하는 방식을 말한다. 여기에서 성과란 새 디자인이 목표로 했던 바에 따라 다른데, 보통은 회원 가입율, 재방문율, 구매전환율 등의 지표를 본다.

과학에서 통제 실험이라고 부르는 방법을 인터넷 마케팅 분야에서는 이르는 용어라고 생각하면 된다.

왜 하나 #

A/B 테스팅을 하는 이유는 상관관계로부터 인과관계 - 정확히 말하면 인과관계일 가능성이 높은 것 - 를 찾아내기 위한 것이다. 그래야만 우리가 "원인"에 해당하는 요소에 개입을 하여 "결과"에 해당하는 요소가 우리가 원하는 방향으로 변화되도록 할 수 있다. 혹은 이미 "결과"에 변화가 생겼을 때 이 변화의 "원인"이 우리가 했던 그 개입 때문이 맞는지 아닌지 판단할 수 있다.

간단한 예를 들어보자. 물놀이 사고를 줄이는 것이 우리의 목표라고 가정하자. 이런저런 조사를 해보니 아이스크림 판매량과 물놀이 사고의 빈도 사이에 높은 양의 상관이 있다는 사실을 찾아냈다. 아이스크림 판매량이 높아지면 물놀이 사고 빈도도 높아지고, 아이스크림 판매량이 낮아지면 물놀이 사고 빈도도 낮아지는 식이다.

이 상관관계를 아래와 같은 인과관계로 해석하면...

#!dot/s
"아이스크림 판매량" -> "물놀이 사고 빈도";

...물놀이 사고를 줄이기 위해 우리가 해야할 일은 명확하다. 아이스크림 가격을 올리는 등 다양한 방법을 써서 아이스크림의 판매량을 줄이는 것이다.

하지만 모든 상관관계가 인과관계인 것은 아니다. "Correlation does not imply causation"이라는 유명한 문구가 바로 위와 같은 상황을 이르는 말이다.

XKCD

(http://xkcd.com/552/)

아이스크림 판매량 증가는 물놀이 사고 빈도 증가의 원인이 아니다. 아마도 숨어있는 원인이 있을 것이다:

#!dot/s
"날씨" -> {"아이스크림 판매량" "물놀이 사고 빈도"};

아이스크림 판매량이 물놀이 사고의 원인이거나 물놀이 사고가 아이스크림 판매량의 원인인 것이 아니라, 날씨라고하는 또다른 요인이 아이스크림 판매량과 물놀이 사고에 공통으로 영향을 주는 원인인 것이다.

이 예시는 누구나 이해할 수 있을만큼 명백하지만, 우리가 현실에서 겪게 될 대부분의 문제는 이보다 복잡하다.

어떤 쇼핑몰 웹 사이트가 있다고 가정하자. 3개월에 걸쳐 디자인 개편 프로젝트를 진행하였고, 지난주에 성공적으로 새 디자인을 적용하였다. 그랬더니 갑자기 그 전에 비해 일 매출이 10% 증가했다고 치자.

매출 증가가 디자인 덕분이라고 할 수 있을까?

#!dot/s
"디자인 개편" -> "매출 증가";

직전의 아이스크림 예시에서 살펴본 바와 같이 두 사건이 함께 일어난다고 해서 하나의 사건이 다른 사건의 원인이라고 가정하는 것은 위험하다. 예를 들면 새 디자인이 적용된 바로 그 날, 하필이면 경쟁 쇼핑몰이 문을 닫았을 수도 있다. 이 경우 매출 증가의 원인은 외부 요인에 있다. 또는 새 디자인이 적용된 바로 그 날, 경쟁력 있는 상품이 입고되었을 수도 있다. 이 경우 매출 증가의 원인은 내부에 있으나 그 성과는 디자인팀이 아니라 영업팀 덕으로 돌려야 한다. 심지어는 갑자기 경기가 좋아졌기 때문일 수도 있다. 다른 쇼핑몰들을 일 매출이 15% 씩 향상되었는데 만약 우리 쇼핑몰만 10% 향상된 것이라면 새 디자인이 매출에 악영향을 준 것일지도 모른다.

A/B 테스팅을 하면 방문자를 "임의로" A, B 두 집단으로 나누고 A 집단의 방문자에게는 기존 디자인을 보여주고, B 집단의 방문자에게만 새 디자인을 보여준다.

새 디자인을 적용하기 전의 매출과 새 디자인을 적용한 후의 매출을 비교하는 대신, A 집단과 B 집단의 매출을 비교하면 시간의 흐름에 따라 발생하는 다른 요인들(경쟁 쇼핑몰 부도, 신상품 입고, 경기 변동 등)을 통제할 수 있기 때문에 순수하게 디자인 변화로 인한 매출 차이만을 가려낼 수 있다. A 집단에 비해 B 집단에서 매출 증가가 있었다면 "디자인 개편"과 "매출 증가" 사이에는 인과관계가 성립할 가능성이 대단히 크다고 말할 수 있다.

이 때 가장 중요한 것은 방문자를 "임의로" 두 집단으로 나누어야 한다는 점이다. 예를 들어

  • 남성은 A 집단, 여성은 B 집단
  • 짝수 시간대 방문자는 A 집단, 홀수 시간대 방문자는 B 집단
  • 첫 일주일 동안 방문한 사용자는 A 집단, 그 다음 일주일 동안 방문한 사용자는 B 집단

등 임의적이지 않은 방식을 사용할 경우(즉, random assignment 실패) 올바른 A/B 테스팅이라 할 수 없다.

게임에서의 A/B 테스팅 #

전통적으로 A/B 테스팅이라고 하면 주로 아래와 같은 것들을 떠올린다:

  • 가입이나 구매 버튼의 위치, 색상, 문구 등을 바꿔보기
  • 이메일 메시지나 푸시 메시지의 제목/본문을 바꿔보기
  • 회원 가입 양식, 주문 양식 등에서 각종 필드의 순서나 필수여부 등 바꿔보기
  • 사이트 네비게이션 UI 구성이나 레이블 바꿔보기
  • 상품 배치나 종류 바꿔보기

게임에서도 위에 나열된 범주에서 A/B 테스팅을 수행할 수 있겠지만, 이런 것들은 게임의 핵심적인 요소라고 보기 어렵다. 물론 UI 디자인, 마케팅, 아이템 판매 등도 중요하겠지만 게임이라고 한다면 핵심은 "재미"가 아닐까. 무엇이 더 재미있는가에 대한 A/B 테스팅을 할 수 있어야 게임에서의 A/B 테스팅이라고 말할 수 있을 것이다.

이를테면 다음과 같은 것들을 생각해볼 수 있겠다:

  • 아이템 드랍률이 적절한가
  • 스테이지별 난이도가 적절하게 증가하는가
  • 특정 인던의 난이도가 지나치게 쉬운가
  • 레벨 디자인의 특정 요소가 플레이어로 하여금 기대한 행동을 하도록 잘 유도하는가
  • 몹이 리스폰되는 장소나 간격이 적절한가
  • 몬스터 AI가 지나치게 똑똑한가
  • 플레이어 실력 평가 및 매치매이킹 알고리즘이 적절한가
  • 새로 기획한 유료 아이템의 성능이 지나치게 좋지는 않은가

이 중에서 "스테이지별 난이도가 적절하게 증가하는가"라는 문제를 좀 더 구체적으로 생각해보자. 총 10개의 스테이지가 있다. 스테이지 1에서 시작해서 순차적으로 진행하여 스테이지 10을 클리어하면 게임이 끝난다고 치자.각 스테이지 n에 대하여 \( n ^ 2 \) 시간만큼이 소요되게 하는 것이 디자이너의 의도였다. 즉 스테이지 1에서는 1시간, 스테이지 2에서는 2시간, 스테이지 3에서는 4시간, ... 스테이지 10에서는 1024시간이 걸려야 한다.

로그를 분석해보니 나머지 스테이지는 의도대로 구현이 되었는데, 스테이지 3에 플레이어들의 평균 체류 시간이 예상했단 4시간 보다 33분 높은 4시간 33분이었다고 치자.

스테이지 3의 난이도를 낮추는 패치를 적용하고 이에 대한 A/B 테스트를 아래와 같이 수행할 수 있을 것이다.

  • 이미 스테이지 3에 머물고 있던 플레이어들에게는 패치를 적용하지 않는다.
  • 패치가 적용된 후 스테이지 3에 진입한 플레이어 중 90%는 A 집단, 나머지 10%는 B 집단으로 배정한다.
  • A 집단에는 패치를 적용하지 않는다.
  • B 집단에는 패치를 적용한다.

A 집단에 비해 B 집단의 평균 체류 시간이 낮아졌다면 패치의 방향이 적절했다고 볼 수 있다. 원하는 결과를 얻었으면 패치를 전체 집단에게 적용하면 된다.

이때 몇 가지 주의할 점이 있다.

우선, 모든 패치는 잘못된 가능성이 있다. 이를테면 체류 시간이 2시간으로 줄어버린다거나 하는 식으로 난이도가 지나치게 하향되거나, 예상치 못했던 이유로 인해 오히려 난이도가 상향될 수 있을 것이다. 따라서 실험군과 대조군을 1:1 비율로 나누기 보다는 1:9와 같이 편향되게 나누는 것이 안전하다.

두번째 고려할 점은 난이도 조절 방식이다. 예를 들어 스테이지 3 보스의 HP를 10% 낮추어 난이도 하향을 했다고 치자. 하지만 보스의 HP는 UI 상에 표시되는 요소이기 때문에 플레이어들이 이를 쉽게 인식할 수 있다. 게다가 각종 커뮤니티를 통해 캡쳐화면을 올리며 "아무개는 보스 HP가 10% 낮더라"는 사실을 공유할 수도 있다. 플레이어들이 실험에 대해 인지하고 자신이 어떤 집단에 속해 있는지 생각하기 시작하면 욕을 먹는 것은 물론이고, 실험에도 편향이 발생하게 된다. 블라인드 테스트(blind test)를 해야하는 이유이다. 이를테면 대놓고 HP를 수정하는 것 보다는 보스 AI를 조정하는 식으로 접근하는 것이 좋다.

(실험자가 피험자에게 영향을 미칠 소지가 있다면 이중맹검법(double-blind test)을 적용하는 것이 맞지만 온라인 테스트의 경우 고려하지 않아도 된다.)

테스트 서버 #

잠깐, 만약 테스트 서버가 있는 상황이라면 온갖 극단적인 실험들을 테스트 서버에서 비교적 안전하게 할 수 있지 않나? 뭐하러 저렇게 해야하나?

통제 실험이 제대로 되려면 임의성 측면에서 두 가지가 만족되어야 하는데 하나는 임의적 추출(random selection)이고 다른 하나는 임의적 할당(random assignment)이다. 앞에서 임의적 할당에 대해서는 설명했으니 넘어가자.

임의적 추출이란 실험에 참가할 대상을 선택할 때 이들이 전체 집단(모집단)의 성격을 대표할 수 있는 방식으로, 편향 없이 추출하는 것을 의미한다. 예를 들어 초등학교 학생들을 대상으로 한 실험의 결과를 초중고등학교 학생 모두에게 적용하거나, 페이스북 사용자를 대상으로 한 실험의 결과를 트위터에 적용하거나 하면 추출된 집단의 성격과 모집단의 성격에 차이가 있기 때문에 기대와 다른 결과가 나올 수 있다.

테스트 서버도 마찬가지인데, 테스트 서버에서 플레이하는 플레이어들과 일반 서버에서 플레이하는 플레이어들은 균일한 집단이 아닐 가능성이 매우 높다.

이와 비슷하게 "실험적 패치가 있습니다. 미리 체험해보시겠습니까?" 라는 식으로 물어보는 방식도 실험 설계라는 관점에서는 적절하지 못한데, 도전을 즐기는 성향의 플레이어들만 편향적으로 실험에 참가하게 되기 때문이다.

Verification, Validation #

A/B 테스팅을 통해 안전하게 그리고 확신을 갖고 패치를 적용할 수 있게 되었다. 그럼 이제 이 방식을 계속 반복하면 되는건가? 생각해야할 문제가 몇 가지 더 있다.

좀 전의 A/B 테스팅은 "(패치가) 디자이너의 의도대로 되었는가?"라는 질문에 대한 답을 주었다. 하지만 또다른 중요한 질문이 남아있다. "디자이너의 의도가 올바른가?"라는 질문을 던져야한다. 소프트웨어 공학에서 말하는 Verification and Validation 문제이다. Barry Boehm의 표현을 빌자면 다음 두 질문으로 요약할 수 있다:

  • Verification: Are we building the product right? (우리가 제품을 맞게 만들었는가?)
  • Validation: Are we building the right product? (우리가 맞는 제품을 만들었는가?)

조금 전의 난이도 패치 사례에 맞게 고쳐보면 아래와 가다:

  • Verification: 패치로 인해서 스테이지 3의 체류시간이 4시간에 맞춰졌는가?
  • Validation: 스테이지 3의 체류시간이 4시간이어야 게임이 가장 재미있어지는가?

예를들어 스테이지 10을 생각해보자. 디자이너의 의도에 의하면 스테이지 10을 클리어하기 위해서는 1024시간 동안 플레이를 해야한다. 주말도 쉬지 않고 하루 8시간씩 약 네 달을 달려야만 클리어가 가능하다. 개막장 하드코어 인생 퇴갤 게임을 만들고 싶은게 아니라면 분명 문제가 있다. 의도대로 구현되었는가(verification)보다 의도 자체가 올바른가(validation)가 훨씬 중요해보인다.

스테이지 10의 체류시간이 어느 정도여야 게임이 가장 재미있을까?

재미라는 것은 직접 측정하기 쉽지 않으니 재미와 관련이 있을 것으로 보이는 지표 중 측정이 가능한 후보들을 찾아야 한다. 이를테면 각 스테이지별 포기율(abandonment rate)도 괜찮은 후보 중 하나일 것이다. 해당 스테이지에 진입한 플레이어 수를 해당 스테이지를 클리어하지 못한 플레이어 수로 나눈 값을 포기율로 정의할 수 있을 것이다. 예를 들어 스테이지 1에 진입한 100명 중 10명이 스테이지 1을 클리어하지 못하고 게임을 중단했다면 스테이지 1의 포기율은 0.1, 즉 10%이다. "중단" 혹은 "이탈"을 무엇으로 정의할지도 고민을 해야하는데 이에 대해서는 다음 글들을 참고하자:

이제 포기율을 측정할 수 있게 되었다. 포기율이 높으면 해당 스테이지가 지나치게 어려워서 재미가 덜할 것이라고 가정하자.

그 다음 단계는 패치 예시와 동일하다. A/B 테스트를 진행하며 포기율이 낮아지는 방향으로 점진적으로 패치를 하는 것이다.

물론 이 예시에는 문제가 있다. 위와 같은 방식으로 포기율을 정하고 이걸 "재미"에 대한 간접 지표로 사용한다면 각 스테이지가 1초만에 클리어되는 게임이 가장 재밌는 게임이다. 사실 플레이어 혹은 사용자가 얼마나 긍정적으로 참여하고 있는가 - positive engagement - 를 측정하는 것은 쉽지 않은 문제이다. 예를들어 "오토"를 켜놓고 꾸벅꾸벅 졸며 플레이하는 모습을 흔히 볼 수 있는데, 이게 정말 재미있는 것인지, 올바른 것인지에 대한 고민을 하기 시작하면 끝이 없다. 하지만 게임 업계 종사자라면 고민하지 않을 수 없는 문제이기도 하다. 이에 대해서는 별도의 글이 필요할 것 같다.

다시 현실로 돌아와서 이 섹션(validation 문제)에 대해 소결론을 내리자면, 단순한 포기율 측정과 "진정한 재미"를 측정하는 것 사이에는 수많은 점진적 단계들이 있다는 것이다. 진정한 재미를 측정할 수 없으니 포기율이나 보고 말아야지 혹은 진정한 재미를 측정할 수 없으니 다 의미없구나 등등은 별로 생산적이지 못한 생각이다. "진정한 재미"는 아니지만 포기율보다는 똑똑한 지표를 각 게임의 상황에 맞게 얼마든지 찾아낼 수 있다.

기존 플레이어와 신규 플레이어 #

또 다른 문제에 대해 생각해보자.

더 효율적인 HUD UI에 대한 아이디어가 떠올랐다고 치자. 이 HUD UI를 도입하면 등 뒤에 있는 적들의 위치를 더 빠르게 파악할 수 있을 것으로 기대한다. A/B 테스팅을 해보면 좋을텐데, 위와 동일한 방식으로 하면 될까? (후방에 있는 적에 의해 HP가 소모된 양을 측정하면 평가 지표로 쓸 수 있을 것 같다)

의식적이건 무의식적이건 새로운 UI에는 학습 비용이 있다는 점을 고려해야 한다. 기존 HUD에 익숙한 플레이어들은 일시적으로 퍼포먼스가 떨어질 수 있다.

UI 자체는 개선된 것이 맞지만 학습 비용 때문에 일시적으로 퍼포먼스가 떨어진 것인지, UI 자체가 문제인지 알아내려면 테스트 결과를 평가할때 기존 플레이어와 신규 플레이어를 나누고 신규 플레이어 중에서 A 집단과 B 집단의 차이를 비교하면 UI 자체가 개선되었는지 여부를 알 수 있을 것이다.

게임 디자인에 통합하기 #

앞에서 살펴본 바와 같이, 플레이어가 인지하기 어려운 범주 내에서만 테스팅을 하려고 하면 제약이 크다. 이 문제를 완화할 수 있는 좋은 방법 중 하나는 디자인 단계에서부터 테스트를 고려하는 것이다.

이브 온라인(EVE online)은 2009년 Apocrypha 패치에서 "웜홀"이라는 개념을 도입했다. 웜홀에는 여러 종류가 있는데 몇몇 종류는 이미 알려진 두 공간(k-spaces) 사이를 이어주는 역할을 하고, 몇몇 종류는 알려지지 않은 공간(w-spaces)으로 진입하는 통로 역할을 한다. 그리고 웜홀은 구조적으로 불안정하기 때문에 일정 시간이 지나거나, 웜홀을 통해 지나치게 많은 물질(mass)이 통과하면 닫혀버린다.

이브 온라인의 디자이너가 어떤 의도를 가지고 이런 시스템을 설계했는지 알 수 없으나, 마음놓고 여러가지 실험을 할 수 있는 대단히 좋은 장치이다. 일단 지나치게 많은 물질이 통과할 수 없다는 제약으로 인해 게임 내 경제에 미치는 영향을 안전하게 제한할 수 있고, 시간이 지나면 닫힌다는 제약으로 인해 일시적인 아이디어나 새로운 밸런스 등을 자주 테스트해볼 수 있다.

MMORPG가 아니더라도 여러 아이디어를 생각해볼 수 있다. MORPG(방게임)에서 랜덤맵을 골랐을 때 공식적으로 선택할 수는 없는 실험적인 맵이 낮은 빈도로 나온다거나(레벨 디자인 테스트), 영화 헝거 게임에서 스폰서가 보내주는 아이템 상자(!)처럼 일회성으로 사용할 수 있는 새로운 실험적 아이템 같은 것이 하늘에서 간혹 떨어진다거나 하는 식으로 게임 디자인 자체에 실험을 용이하게 해주는 개념들을 녹여 넣으면 좋을 것이다.

점진적 도입 전략 #

그럴듯한 이야기들인데, 막상 적용하려고 하면 항상 시간과 비용이 문제다. 다음 방법들을 추천한다.

첫째, 테스팅을 하려면 측정이 선행되어야 하는데, 직접 수집 기능을 구현하기 보다는 구글 애널리틱스를 사용할 것을 추천한다. 월 1천만 건의 데이터가 넘지 않는다면 무료로 쓸 수 있다. 1천만 건을 넘는다면 데이터를 샘플링하여 보내는 방식으로 여전히 무료로 쓸 수 있다. 구글 애널리틱스로 게임 데이터를 분석하는 방법에 대해서는 다음 글을 참고하기 바란다:

둘째, 그래픽 에셋이나 UI를 건드리는 테스트보다는 각종 수치(확률 테이블, 능력치 테이블 등) 혹은 알고리즘을 건드리는 테스트와 같이 글자 몇 개만 바꾸면 빠르게 해볼 수 있는 테스트를 먼저 시도하는 식으로 낮은 과일을 먼저 따먹고(성과를 내고), 점진적으로 확장하는 방식으로 접근하면 좋을 것이다.

셋째, 실제 테스트를 진행하려면? 역시나 Google Analytics를 추천한다. Measurement Protocol, Content Experiments API 등을 활용하면 간단하게 테스트를 수행하고 결과를 평가해볼 수 있다.

넷째, 서버측이 아니라 클라이언트측에서 테스트에 따른 변화를 처리해야한다면? 테스트를 할 때마다 앱스토어에 다시 승인을 받으려면 답이 없다. Google Tag Manager SDK를 활용하면 재승인 없이 테스트와 관련된 각종 설정 데이터를 클라이언트로 재배포할 수 있다. 특히 Google Analytics와 연동이 잘 되기 떄문에 더욱 좋다.

이런 시도들도 작고 빠르게 성공 사례를 만들고 경험을 쌓은 후에 자체적인 테스트 플랫폼을 구축하거나 좀 더 고도화하는 방식이 안전할 것이다.

A/B 테스팅의 단점 #

글을 마치기 전에 단점에 대해 써보자. 세 가지 정도가 떠오른다.

첫째, 테스트를 많이/자주하면 단기적으로 손해가 발생할 수 있다. 예를 들어 아이템 샵과 관련하여 테스팅을 진행한다고 치자. 2주 동안 전체 플레이어를 50:50으로 나눠 기존 아이템 샵과 새로운 아이템 샵에서의 매출 차이를 테스트하는 것이 목표다. 테스트를 3일 쯤 진행했는데, 새로운 아이템 샵에서의 매출이 기존 아이템 샵에서의 매출에 비해 절반 밖에 나오지 않는 상황이다. 테스트를 2주동안 진행하려면 막심한 매출 손해를 감수해야한다.

둘째, A/B 테스팅의 결과는 계절 변화나 플레이어의 취향 변화 등 시간의 흐름에 따라 바뀔 수 있다. 작년 겨울에 A/B 테스팅을 하여 얻은 결론은 언제까지 유효할까? 통제실험은 시공간의 보편성(universality)에 대한 가정을 깔고 있다. 이 가정은 물리학이나 화학 수준에서는 대단히 확실히 보장되고, 생물학을 거쳐 사회과학 분야로 가면서 점점 약해지며, 비즈니스 맥락에서는 대단히 약해진다. 어제의 세상과 오늘의 세상이 다르고, 미국과 한국이 다르다.

결국 확실성을 유지하기 위해서는 실험을 지속적으로 반복해서 해야하는데 첫번째 단점(비용 문제)과 엮어서 생각해본다면 곤란한 얘기가 된다.

셋째, A/B 테스팅만 해서는 지역최적점에 머물게 될 위험이 있다. A/B 테스팅이라는 것은 기존 상태에서 적은 변화(되도록 하나의 변수만 살짝 바꾸기)를 가하며 점진적으로 더 나은 상태를 찾아가는 방식으로 진행된다. 하지만 이 방식으로는 지역최적점에 수렴할 수 있을 뿐 전역적인 최적점을 찾을 수 없다.

이 중 첫번째와 두번째 문제에 대해서는 Multi-armed Bandit 알고리즘이라고 불리는 효과적인 해결책이 있다. 이에 대해서는 A-B Testing의 단점과 개선안을 참고하기 바란다.

세번째 단점에 대해서는 별도의 글이 필요할 것 같다.

Suggested Pages #

Other Posts #

0.0.1_20140628_0