[NDC 16] 데이터를 이용한 게임 밸런싱, 실험을 통해 적절한 숫자 찾기

게임의 밸런스를 테스트할 때, 좀 더 명확한 지표가 나오는 방법은 없을까. 더 안전하고 돈도 덜 들고 결과도 확실한, 그런 테스트는 사실 모든 기획자가 바라는 부분이다.

하지만 사람의 손으로 밸런스를 조절하는 것과 사람의 손으로 테스트에 참여하는 건 비용적인 면에서나 정확도적인 면에서나 위험도가 따른다. 기획자의 모든 생각이 처음부터 정답으로 연결되는 것도 아니고, 테스터를 모으는 건 그 자체만으로도 비용이 어마어마하게 소모된다.

그렇다면 어떤 방법이 있을까? 바로 데이터를 이용해 컴퓨터로 테스트하는 것이다. 박스앤위스커에서 데이터 분석가로 재직 중인 박장시 강연자가 소개하는 밸런스 테스트 방식에 대해 함께 알아보자. /디스이즈게임 이승운 기자

■ 사람이 정하기엔 너무나 중요한 숫자. 기계가 정할 수는 없을까?

게임을 다르게 표현한다면 '숫자로 가득 찬 세상'이라고 할 수 있다. RPG의 스탯에서 FPS의 총기류에 이르기까지, 게임 내에 구현된 모든 것은 어마어마한 숫자의 조합으로 이루어져 있다.

위 이미지에서 오른쪽의 엑셀은 어느 게임의 총기 밸런스 시트다. 총기 하나당 80칸 정도의 숫자가 들어가는데, 이걸 기획자나 개발자가 한땀한땀 집어넣어 게임으로 구현시키는 것이다. 덕분에 강연자가 그동안 만난 기획자들은 유능할수록 엑셀 장인인 경우가 많았다. 그 많은 숫자를 넣고 관리하는 일을 하니까.

그들 대부분은 스프레드시트에 숫자를 넣고 직접 조절하고 테스트하기를 반복한다. 새로운 제안이 오면 효율을 따져가며 숫자를 바꾸고, 다시 테스트하고.

이 과정을 보면서 박장시 강연자는 이런 의문을 가졌다. "사람이 임의로 숫자를 정해도 되는가?"

실제로 사람이 생각을 하고 직접 손으로 숫자를 입력해 넣는 것은 위험한 조합이다. 이걸로 테스트를 진행한다고 해도 대부분 에러나 버그만 테스트하고, 이게 얼마나 재미있을지, 혹은 유용할지에 대해서는 테스트를 하기가 어렵다.

그렇다면 이걸 기계가 해줄 수는 없을까? 가장 기본적인 숫자는 사람이 넣겠지만, 이걸 기초 값으로 해서 기계가 다른 변수 등을 탐색해줄 수는 없을까?

■ 간단한 실험 : A/B 테스트

그래서 처음에 생각한 것은 A/B 테스트다. 간단하게 아래 그림을 살펴보자.

100명의 테스터와 두 개의 UI를 준비해, 각각 50명씩 조를 나눠 사용하게 했다. 'Learn more' 버튼을 한 쪽은 파란색으로, 한 쪽은 녹색에 화살표 그림을 넣어 배치했다. 그 결과 파란 버튼 쪽은 52%의 클릭율이, 녹색 버튼 쪽은 72%의 클릭율이 나왔다. 오른쪽 예제가 더 클릭을 유도한 셈이다.

이렇게 두 가지 조건을 놓고 만족도를 테스트하는 A/B 테스트가 게임에선 잘 쓰이지 않았다. 그래서 아까의 무수히 많은 숫자를 기계로 테스트해보자는 아이디어가 생겼다.

위는 간단하게 구상해본 게임이다. 52장의 트럼프 카드 중 플레이어와 컴퓨터가 각각 5장씩 가져가서 한 장씩 내는 게임이다. 서로가 카드를 내서 숫자가 높은 쪽이 이긴다는 심플한 방식이다.

여기에 크리티컬 카드라는 확률적인 요소를 추가해 봤다. MMORPG에서 적을 공격하다 크리티컬이 터지는 것처럼, 이 크리티컬 카드가 발동되면 자신의 숫자가 2배로 뻥튀기되는 식이다. 4:7로 지는 상황에서도 이 카드가 나오면 8:7로 역전할 수 있다.

그러면 이제 두 명의 기획자가 이 크리티컬 카드를 가지고 논의를 시작한다. 한 명은 크리티컬 카드의 발동 확률을 10%로 넣자고 하고, 한 명은 이걸 20%로 넣자고 한다. 둘 다 어느 정도 현실적인 확률이므로 쉽게 좋고 나쁘고를 판단하기 어렵다. 보통은 연차가 높은 기획자의 의견을 따르거나 디렉터가 결정하거나 할 것이다.

자, 이걸 직접 테스트해보자. 한 쪽은 발동 확률을 10%로 세팅한 게임, 한 쪽은 20%로 세팅한 게임을 준비한다. 두 그룹 중 어느 쪽이 더 좋은 지표를 나타내는 지 비교할 차례다.

유저는 그룹별로 1,000명씩, 총 2,000명의 가상의 유저를 만들어냈다. 이들은 이제 자신에게 배정된 게임을 플레이하고 Fun Index(재미 지표)를 뽑아낼 것이다. 본래는 없는 용어지만 강연을 위해 이걸 재미 지표라고 임시로 부르도록 하자.

게임에 이기면 재미 지표를 2씩 얻고, 반대로 지면 1씩 내려간다. 그리고 게임을 하다 보면 상대를 압승할 경우도 있고 반대로 처참하게 지는 경우도 있다. 크리티컬이 떠서 다이내믹하게 이길 수도 있을 것이다. 크게 이기면 재미를 더 느낄 것이고, 반대로 크게 지면 재미가 더 떨어지도록 세팅했다. 그래서 점수차에 따라 재미 지표도 달라지도록 세팅했다.

그렇게 2,000명의 가상 유저가 게임을 플레이한 결과가 이 그래프다. 안개처럼 보이는데, 이건 2,000개의 가는 선을 겹쳐놓은 것이다. 빨간색은 10% 확률의 게임, 파란색은 20% 확률의 게임을 플레이한 가상 유저의 재미 지표다.

보면 전체적으로 파란색 그룹의 선이 전체적으로 위쪽에 있는 것을 확인할 수 있다. 이런 각 그룹의 평균을 굵은 선으로 그었더니, 명확한 차이가 드러났다. 200번을 플레이한 결과, 최종적으로 얻는 재미가 이만큼 차이나는 것이다. 10%일 때엔 500 후반대, 20%일 때엔 600 초반대의 결과가 나왔다. 단순하게 이 게임 내에서만 비교하면 20%쪽이 더 나은 셈이다.

물론 실제 유저가 아닌 가상 유저를 대상으로 한 테스트인 만큼 완벽할 수는 없다. 하지만 보통은 여기에서 "20%로 세팅하는 게 더 재미있구나" 하고 테스트를 끝낸다. 20%로 결론을 내리고 게임에 업데이트하는 경우도 있다.

하지만 그렇게 했더니 발생하는 문제가 두 가지 있었다.

하나는 테스트 비용의 낭비다. 위 조건대로 10만 명의 실제 유저에게 테스트를 진행할 경우, 10% 환경에 들어간 유저들은 재미 지수가 44.25만큼 낮게 나온다. 절반의 유저가 안 좋은 경험을 하게 되는 셈이다. 이 차이를 돈으로 환산하면 1점당 1원씩 쳐도 4,425원. 여기에 전체의 절반인 5만 명을 곱하면 약 2억 2천만 원의 손실이 나온다.

처음에 테스트를 했을 땐 정말 좋았다. 그래서 테스트를 아주 활발히 했는데, 나중에 돈으로 환산해 보니 차이가 어마어마했다. 만약 서비스 규모가 더 큰 게임이라면 하루에 몇 천 만원, 일주일에 10억 이상 드는 경우도 있다. 그 비용이 첫 번째 문제다.

두 번째는 '세상이 바뀐다'는 점이다.

일반적으로 테스트를 할 때엔 전통적으로 내려오던 방식을 그대로 답습하는 경우가 많다. 위의 A/B 테스트도 그 중 하나다. 문제는 이 테스트는 대부분 '세상이 바뀌지 않는다'는 가정 하에 이루어진다.

예를 들어 제약 회사에서 새로운 암 치료제를 만들었다고 가정해 보자. 돈을 들여 임상 실험을 하고, 효과가 있다고 판명되면 시판을 한다. 사람의 DNA가 크게 바뀌지 않는 한 이 약은 계속 효과가 있을 것이다.

하지만 게임 환경은 다르다. 실제로 저런 테스트를 거쳐 결과값을 보고 "B 그룹이 재미 지수가 높구나" 했다가 막상 수익 지표를 보면 이상함을 느낀다. 그래서 테스트를 다시 해보면 갑자기 상황이 바뀌어 B 그룹이 추락하고 A 그룹이 올라가 있는 경우도 있는 것이다. 유저의 행동 변화, 다른 요인이 얼마든지 변수로 작용할 수 있다.

이를 보고 '통계적 유의성', 즉, 샘플을 더 많이 확보하고 기간을 오래 잡으면 되는 것이 아니냐는 의견도 나온다. 하지만 그것과는 약간 별개의 문제로, 이 경우는 환경 그 자체가 바뀌는 케이스다. 아무리 많은 사람을 모아 오래 테스트를 해도, 유저가 바뀌면 결과도 뒤집어지는 것이다.

■ 개선된 실험 : MAB 테스트

A/B 테스트를 진행하며 몇 가지 문제가 나왔는데, 그 중 가장 큰 것이 위에서 설명한 '비용'과 '환경 변화'였다.

게다가 테스트를 준비하는 것만 해도 돈이 많이 든다. 개발자는 여러 가지 샘플을 만들어야 하고, 선택지가 A와 B만 있을 거라는 보장도 없다. 경우에 따라 선택지가 10가지가 될 수도 있고, 그러면 개발자들은 10가지 버전을 모두 만들어야 하는 것이다.

내부에서 숫자만 바꾸는 것도 손이 많이 가는데, 여기에 디자인 요소가 들어간다든지 하면 더 일이 커진다. 그리고 테스트가 끝나고 나면 하나의 승리자만 남고, 나머지 패배한 9개는 모두 버려진다. 정말 비합리적인 일이다.

그래서 다시 제안하는 것이 MAB(Multi-Armed Bandit) 테스트다.

MAB의 어원은 One-armed bandit, 즉, '외팔이 날강도'라는 말에서 왔다. 슬롯머신을 가리키는 속어인데, 하나의 레버(암)가 달린 물건이 돈을 어마어마하게 가져가지 않나. 그것이 변형된 용어가 멀티 암드 밴딧, 레버가 여러 개 달린 슬롯머신이라는 뜻의 테스트 용어다.

만약 동전을 들고 이 기계를 플레이한다고 생각해 보자. 돈을 넣고 나면 어떤 레버를 당겨야 할지 정해야 한다. 레버가 1부터 10까지 있다고 치면, 일단 하나씩 당겨봐야 돈이 나오는 것을 확인할 수 있을 것이다.

이제 이 레버를 하나씩 탐색해보기 시작한다. 탐색을 거쳐보니 2번째 레버에서 잘 나오는 것 같다. 그런 생각이 들기 시작하면 이제 2번째 레버만 계속 당기게 된다. 돈을 많이 주는 것을 찾아 큰 돈을 벌고 싶어 하는 것은 누구나 똑같기 때문이다.

그런데 여기에 동전을 한정시켜 보자. 플레이 기회가 한정되기 시작하면 선택의 기로에 놓인다. 탐색을 열심히 하면 돈을 못 벌고, 돈만 계속 벌려면 탐색을 못 한다. 초반에는 적당히 탐색을 하다가도 동전이 줄어들기 시작하면 지금까지의 결과 중 좋았던 것만 당기는 식으로 전략을 세우게 되는 것이다.

어떻게 하면 탐색도 하고 돈도 잘 벌까? 이것이 MAB의 시작점이다.

돈과 탐색 사이의 딜레마를 해결하는 방법은 그동안 여러 방면으로 연구되어 왔다. 당장 위키에서 MAB를 검색하면 알고리즘이 쏟아져나올 정도다. 이번 강연에서는 A/B 테스트의 단점을 보완하기 위해 괜찮았던 알고리즘을 가져와 소개한다. 바로 'Epsilon Greedy'다.

우선 위 그림을 보자. 스타트에서 한 쪽은 Typical A/B test로, 한 쪽은 Best Arm으로 연결된다. 여기에서 테스트하는 유저를 위쪽, Typical A/B test로 보내는 확률을 엡실론이라 부흔다. 이 확률은 0~1 사이에서 사람이 정하는 숫자다. 여기선 0.1, 즉, 10%로 설정하고 테스트해보자.

10%의 확률에 걸려 위쪽 루트로 빠지고 나면, 이번엔 레버1~레버10으로 갈래길이 나뉜다. 각 레버는 저마다 돈을 딸 확률이 다르게 세팅돼 있을 것이다. 유저들은 이곳에서 다시 1/n 확률로 레버 중 하나로 흘러간다. 만약 전체 유저가 1,000명이면 10%인 100명이 테스트에 끌려오고, 여기서 다시 10명씩 10갈래로 나뉘어 각 레버를 테스트하게 되는 셈이다.

그렇게 테스트된 10개 레버의 결과물 중 가장 효과가 좋은 암이 그림의 아래쪽, Best Arm에 적용된다. 그러면 테스트에 끌려가지 않은 90%의 유저는 효과가 검증된 레버로 게임을 즐기게 되는 것이다.

또한, Best Arm은 한 번 정해졌다고 해서 계속 고정되는 게 아니다. 10개의 레버에서 계속 테스트가 돌아가는 동안 여러 가지 요인으로 베스트가 바뀔 수 있다. 만약 3번 레버의 수익률이 갑자기 올라 1위를 빼앗을 경우, Best Arm도 3번 레버로 갱신된다. 유저나 환경의 변화에 따라 유동적으로 대처할 수 있는 식이다.

이 알고리즘은 MAB 알고리즘 중에도 가장 간단하고 구현하기도 쉽다. 엡실론이라는 수를 사람 손으로 정해야 한다는 점이 단점이지만, 이건 게임의 트래픽과 레버의 갯수를 파악하고 있다면 쉽게 정할 수 있다. 샘플성이 확보되려면 그만큼 수가 많아야 하므로, 적절한 사이즈를 생각해서 엡실론을 정하면 된다.

이제 이걸로 본격적으로 테스트를 돌리고 결과값을 내봤다. 아까와 같은 그래프는 필요하지 않다. 확인할 부분은 트래픽 분배가 잘 됐는가다.

4,000명의 가상 유저로, 엡실론을 20%로 설정해 테스트한 결과 984명이 A/B test로 빠졌고 재미 지수 578.12를 기록했다. Best Arm에서 좋은 결과만 뽑아먹은 3,016명은 재미 지수 621.50을 기록했다.

엡실론을 20%로 설정했던 만큼 나머지 80% 정도가 Best Arm에서 뽑아먹기를 기대했는데, 실제로 뽑아먹은 유저는 80%에 미치지 못했다. 초반에는 각 레버에 할당되는 유저가 적었던 만큼 실제 성능 검증이 정확하지 않았던 게 원인이었다. 그래서 초반에 굉장히 갈팡질팡하는 모습을 보였다. 어느 정도 테스트가 진행되고 나면 이제 각 레버의 성능 검증이 되었으므로 Best Arm이 잘 바뀌지 않았다.

그러면 이제 비용 얘기로 돌아와 보자. A/B 테스트로 끌려간 유저의 경우 1명당 재미 지수 43.38만큼 손해가 발생한 부분은 아까의 테스트와 비슷하다. 하지만 이번엔 A/B 테스트로 빠진 인원이 적어진 만큼 비용은 약 1억 1천만 원. 아까와 비교하면 1억이 넘는 지출을 줄인 셈이다.

A/B 테스트의 단점으로 지목한 비용과 환경 변화 중 비용에 대한 부분이 해결됐으니 다음은 환경 변화를 검증할 차례다.

위 그래프는 A, B, C 그룹을 나눈 뒤 일부러 플레이 환경을 마구 바꿔가면서 테스트한 것이다. 각 그룹이 가진 퍼포먼스를 미리 설정해 뒀다가, 일정 주기로 설정을 확 바꿨다. 각 그룹이 얼마나 잘 따라가는지를 확인하기 위한 테스트다.

그래프를 보면 각각의 그룹이 환경 변화에 어떻게든 적응하면서 움직이는 모습을 볼 수 있다. 단순히 A/B 테스트만 진행했을 때 고정된 환경에서 테스트가 잘 진행되도 그 후에 바뀌는 세상에 적응하지 못했던 것과는 대조적인 모습이다.

이 테스트에서 중요한 점은, 이렇게 '세상이 바뀌는 타이밍'에 테스트를 끝내선 안 된다는 점이다. 세상은 픽스되어 있지 않고 언제나 유동적으로 움직인다. 그래서 MAB 테스트를 가지고 꾸준히 실험을 하는 게 무엇보다 중요하다.

실제로 모 쇼핑 업체에서 비슷한 실험을 진행해 봤다. 이곳에선 시간에 따라 환경이 바뀌었다. 결과를 보니 오전 10시에 잘 팔리는 상품이 있었고, 점심시간에 잘 팔리는 상품이 따로 있었다. 덕분에 해당 시간대가 되면 클릭율이 높았던 상품을 바로바로 띄워주는 장치를 개발했더니 매출 증가로 연결됐다.

MAB 테스트는 비용을 줄이면서 계속 탐색을 하고 바뀌는 유저 환경에 적응할 수 있다는 것이 큰 장점이다. 탐색을 하는 방법은 굳이 엡실론 그리디가 아니더라도 상황에 맞는 알고리즘이 마련돼 있다. 기획자가 seed 수치만 잘 넣어주면 기계가 힘든 테스트를 대신 해준다는 점이 포인트다.

그렇다면 이것을 게임에서 테스트한다면? 사실 시스템적인 부분보다 유저의 반응이 더 이슈가 큰 부분이다. 유저는 자신이 불이익을 받을 수도 있는 콘텐츠에 민감하기 때문이다. 시뮬레이터가 잘 된 게임이라면 이게 유용하게 쓰이겠지만, 만약 실제 유저를 대상으로 테스트를 해야 한다면 먼저 유저에게 솔직하게 내용을 공개하거나, 아예 기획 단계에서 유저 불이익을 최소화시키는 방법 뿐이다.