NDC Replay

데이터를 이용한 게임 밸런싱
박장시
박스앤위스커
2008년부터 넥슨에서 데이터 분석가로 근무하였고, 2013년부터 프리랜서 분석가로 다수의 데이터 분석 프로젝트에 참여하였음. 현재 박스앤위스커(boxnwhis.kr)라는 데이터 분석 전문 기업에서 데이터 분석가로 일하고 있음.
적절한 게임 밸런싱을 위해 정해야 할 숫자들(parameters)을 로그 데이터로 결정하는 방법을 소개합니다. 간단한 예시 게임을 통하여, 어떻게 실험을 설정하고 결과를 확인하여 밸런싱을 조정하는지 구체적인 과정을 설명합니다. 효율적인 실험을 위해 MAB(multi-armed bandit) 알고리즘을 이해하고, 자동화된 게임 밸런싱의 가능성을 알아봅니다. 발표 세션의 모든 수치 작업은 R 스크립트로 설명 후에 공유할 예정입니다.
[새 창에서 슬라이드 보기]
네 안녕하세요. 저는 박장시라고합니다. 박스앤위스커라는 분석 회사에서 지금 데이터 분석가로 일을 하고 있고요. 오늘 데이터를 이용한 게임 밸런싱이라는 주제로 발표를 하도록 하겠습니다.

오늘 제가 말씀드릴 내용은 크게 세 가진데요. 일단 첫 번째는 정확한 아이디어죠. 그래서 일단 중요한 숫자들이 게임에 굉장히 많은데 “이거를 사람이 다 일일이 정하지 않고 기계가 정할 수 없을까?”라는 게 저의 기본적인 화두고요. 그래서 그 두 가지를 어쨌든 생각은 확실하니까 그리고 누군가는 아마도 계속 그걸 시도하고 있을 거예요. 많은 사례들을 해외에서도 많이 봤었고요. 그렇기 때문에 그걸 어떻게 잘 구현하느냐가 중요한데 그 구현하는 방법에 대해서 두 가지 예시를 가져왔습니다. 그래서 오늘은 하나의 아이디어와 그 아이디어를 구현하기 위한 세 가지, 아니 두 가지 실례에 대해서 말씀을 드리도록 하겠습니다.

일단 저한테 게임은 숫자로 가득 찬 세상입니다. 제가 처음에 사회생활을 시작할 때도 통계학을 전공했는데요. 그런데 게임 회사가 제일 끌리더라고요. 왜냐하면 이 안에 무수히 많은 숫자가 있다는 걸 제가 알고 있었거든요. 왜냐하면 게임을 굉장히 좋아했기 때문에 보시면 그 흔한 RPG 게임들 보면 어마어마한 스탯들을 가지고 있죠. 그다음에 저 오른쪽에 있는 엑셀은 모 게임 회사의 총기 밸런스 시트에요. 그래서 지금 총 하나에 들어가는 아마 숫자가 80개 정도라고 그 당시 기획자한테 들었거든요. 총 하나의 소총 하나를 규정짓는 숫자 자체가 한 80여개 정도가 되고 이걸 기획자들 혹은 개발자들이 한 땀 한 땀 한 셀 한 셀 집어넣어서 뭔가 구현이 되고 있죠. 

그래서 제가 만나본 대부분의 기획자들은 유능할수록 엑셀의 장인들이셨습니다. 보시면 굉장히 액셀을 잘 쓰시더라고요. 특히 기획자분들은. 왜냐하면 이렇게 많은 숫자들을 집어넣고 계속 관리를 해야 되기 때문이죠. 그래서 스프레드시트에다 어떤 숫자를 직접 집어넣는 모습을 굉장히 많이 봤어요. 특히 패치를 하거나 큰 업데이트를 하거나 무언가 새로운 아이템이 들어오면 그 영향 관계를 따져서 계속 숫자들을 바꿔줘야 돼요. 그다음에 테스트를 돌려보죠. 그런 식으로 스프레드시트에 어마어마하게 많은 숫자들을 집어넣는데

저는 이 과정을 보면서 약간 의문이 들었던 게 뭐였냐면 이렇게 사람이 임의로 숫자를 막 정해도 되냐는 거죠. 사실 막 정하는 게 아니라는 걸 알고 있어요. 저도 막 정하는 게 아니라는 건 알고 있지만 실제로 데이터 분석을 할 때 이 세 개의 조합을 굉장히 무섭게 생각하거든요. 사람이 고민을 해서 손가락으로 직접 키보드에 뭔가 숫자를 집어넣는 행위 자체를 굉장히 위험하게 생각을 해요. 왜냐하면 사람은 일단 실수를 할 수가 있고요. 물론 테스트로 걸러낸다고 하지만 테스트는 실제로 어..네, 에러가 안 나거나 버그가 안 나는 것만을 상정해서 테스트를 돌리지 이게 얼마나 재미있거나 얼마나 의미 있는지에 대해서는 따지지 않죠. 대부분의 테스트가. 그래서 사람이 이렇게 임의로 숫자를 정해서 넣는데 이걸 기계가 정해줄 순 없나. 사실 정확하게는 사람이 일단 집어넣긴 집어넣겠죠. 집어넣긴 하겠지만 “그걸 Seed 값으로 해서 기계가 아주 잘 탐색을 해 줄 수 있지 않을까?”라고 생각한 게 기본적인 아이디업니다.

그래서 어떻게 방법을 생각을 해봤냐면 굉장히 간단한 A/B 테스트에요. 실제로 보시면 네 지금 위키피디아에서 가져온 그림인데 A/B 테스트는 익히 들어서 알고 계실 거예요. 만약에 100명의 유저가 있으면 한 쪽에는 네 지금 바뀐 게 왼쪽은 Learn more라는 버튼이 파란색으로 돼있고요. 오른쪽은 초록색 Learn more에다가 버튼 화살표 하나가 더 들어갔어요. 이렇게 해가지고 왼쪽에 50명, 오른쪽에 50명을 각각 무작위 할당을 해서 집어넣습니다. 유저를. 그다음에 내 Clic Rate을 여기서 보니까 여기는 52%, 오른쪽은 72%. 오른쪽이 더 많으니까 ‘이게 더 좋구나.’라고 선택을 하자는 거죠. A/B 테스트는 통계학에서 얘기하는 기본적인 무작위 할당의 그다음에 통제 실험 두 가지 조건을 만족한 실험에 들어가요. 그래서 웹에서 굉장히 많이 사용을 하는데 왜 게임에서는 사용을 안 하냐는 거죠. 그래서 이걸 가지고 아까 얘기한 ‘무수히 많은 셀에 들어있는 숫자들을 사람이 아니라 실험으로 정해보자.’라는 게 아이디어입니다.

그래서 간단한 예시를 만들었는데요. 굉장히 간단한 게임을 그냥 생각을 해봤어요. 처음에는 아주 복잡하고 몇 대 몇으로 사람이 싸우는 굉장히 큰 게임을 생각했는데 너무 복잡하더라고요. 그래서 아주 간단한 게임을 생각을 했는데 일단은 플레이어랑 사람이랑 그다음 컴퓨터랑 둘이 싸워요. 둘이 싸우는데 아주 간단해요. 그냥 52장의 카드 중에서 그냥 다섯 장 사람이 받고 다섯 장 컴퓨터가 받은 다음에 한 장씩 내요. 다섯 장을. 한 장씩 내서 한 판 한 판 단판 승부로 다섯 번을 겨룹니다. 그래서 더 높은 쪽이 승리하는 거죠. 굉장히 단순한 게임이라서 누가 이기는지 누가 어떻게 이기는지가 아주 명확해요.

거기에다가 기획자가 있다라면 뭔가를 집어넣겠죠. 그래서 전 뭘 집어넣냐면 크리티컬 카드라는 걸 요소를 집어넣었어요. 크리티컬 카드는 뭐냐면 한 장 뽑아서 낸다고 했잖아요. 컴퓨터랑 플레이어랑 한 장씩 뽑아서 내놓는데 여기서 Critical Rate이라는 게 있겠죠. 마치 RPG 게임에서 보면 계속 때리다 보면 내 크리티컬 확률로 한 번씩은 대미지가 크게 들어가잖아요. 그거랑 똑같다고 생각하면 돼요. 이 유저가 지금 플레이어가 지금 첫 번째 스페이드 2를 냈는데 이때 만약 크리티컬 확률에 의해서 크리티컬 카드가 발동이 되면 2가 아니라 4가 되겠죠. 실제로 시뮬레이션 할 때는 2도 집어넣고 3도 집어넣고 곱하기를 굉장히 다른 확률로 집어넣지만 어쨌든 기본적인 아이디어는 크리티컬 카드라는 걸 집어넣어서 약간 확률을 가미하자. 게임 속에. 이게 간단한 아이디어고요.

그래서 문제는 이거죠. 기획자가 둘이 있어요. 그러면 크리티컬 확률을 도대체 얼마로 해야 되냐는 거예요. 실제로 대부분은 아주 잘 정해요. 대부분의 기획자들의 감은 굉장히 뛰어납니다. 실제. 테스트를 해보거나 해도 감에 의해서 결정하는 건 굉장히, 아주 얼토당토않은 숫자들이 나오진 않는데 이런 경우가 있죠. A랑 B랑 둘이 싸워서 한 쪽은 10%가 맞다고 하고 한 쪽은 20%가 맞다고 하면 사실 굉장히 애매해요. 이럴 때는 기획자들끼리 싸우면 이럴 때는 보통 연차가 높은 기획자의 말을 듣거나 디렉터가 정해주거나 이런 식이 되겠죠. 그래서 이 두 가지를 가지고 A/B 테스트를 한번 해보자는 거죠. 

A/B 테스트 설계는 굉장히 간단해요. 실제로 이 게임을 만들어서 A/B 테스트를 한다면 유저들이 들어올 테고 여기서 반반 나눠서 한쪽은 A 쪽으로 들어가서 10%의 크리티컬 확률 환경 하에서 게임을 할 거고요. 그다음에 나머지 절반은 B의 환경에 들어가서 20%의 크리티컬 확률을 갖는 환경에 들어가서 게임을 하겠죠. 그래서 그 사람, 그 양 그룹의 어떤 좋은 것, 좋은 지표가 어디가 더 높은지를 비교할 텐데 지금 이 게임은 제가 상상으로 만들어서 시뮬레이션을 하려고 해요. 시뮬레이션을 한다는 건 실제로 사람을 들어와서 이 게임을 하게 하는 게 아니라 제가 유저를 각각 그룹별로 천명씩 만들었어요. 천명씩 가상의 유저를 프로그래밍을 해서 만들고 나서 이 사람들이 각각 200번씩 게임을 하도록 시뮬레이션을 했습니다. 그래서 물론 컴퓨터 내부에는 제가 A에는 10%의 크리티컬 확률, B에는 20%의 크리티컬 확률을 집어넣어 놨지만 이 시뮬레이션을 하는 이 2000명의 유저, 가상의 유저들이죠. 얘네들은 어디가 뭔지 몰라요. 그냥 무작위로 할당된 다음에 들어가서 플레이를 한 다음에 제가 만든 Fun Index라는 어떤 지표를 계속 뱉어내요. 이건 뭐냐면 Fun Index라는 건 실제로 이걸 만약에 A/B 테스트를 실제로 하면 유저가 들어와서 “아, 재밌네. 계속해야지.” 또는 “아, 재미없네. 그만 해야지.”라는 반응을 보일 텐데 이건 시뮬레이션이니까 유저가 그렇게 느낄만한 재미에 대해서 Function을 하나 만들었어요. Function은 구체적으로 이건데요. 게임을 이기면 재미가 있고 게임을 지면 재미없다. 그래서 게임을 한번 이기면 +2점 게임을 지면 -1점 그다음에 게임을 적당히 크게 이기면....

아까 게임 설계를 보시면 2가 있고 5가 있잖아요. 무슨 얘기냐면 게임을 크게 이긴다. 적당히 크게 이긴다는 건 크리티컬 확률이 발동을 했어요. 제가 만약에. 크리티컬 확률이 발동을 해서 두 번째 판을 보면 7, 9기 때문에 제가 져요. 플레이어가 지는 상황인데 이게 들어가게 되면 제가 14가 되죠. 그래서 14-9 정도로 해서 어느 정도 range 안에 들어오는 어떤 확률에 의해서 이기면 기분이 좋을 거라고 가정을 한 거예요 Fun Index에서.

대신 반대의 경우도 있죠. 굉장히 재미없게 너무 크게 아주 너무 크게 이기는 경우도 있을 수 있어요. 아주 쉽게 이기면 또 재미가 없기 때문에 이것도 마이너스 어느 정도를 집어넣었고요. 그다음에 게임을 너무 크게 지면 정말 재미가 없겠죠. 그래서 한 -6, -7점 정도 제가 집어넣었어요. 그래서 천명이 200번씩 게임을 하면서 계속 이런 과정을 거쳐요. 그래서 아 게임이 이거는 어떻게 저기했으니까 이 Fun Index는 어떻게 계산되고 이런 걸 계속 계산을 했죠. 그래서 A/B 테스트를 했습니다.

유저 없이 시뮬레이션으로. 그래서 보시면 지금 빨간 선이 지금 잘 보이실지 모르겠는데 아주 가늘게 표현된 이 선 하나가 유저 한 명이에요. 제가 아까 가상으로 만든 유저 한 명이 게임이 200번 진행되잖아요. 그때마다 아까 Fun Index라는 걸 게임 승패마다 그리고 또 어떻게 이겼는지 어떻게 졌는지에 따라서 Fun Index를 계속 계산해서 첫 번째 1번 게임부터 200번째 게임까지 Fun Index를 다 계산을 했어요. 그래서 이것들이 이 라인 하나가 한 명의 유저가 되는 거죠. 이렇게 해서 2000명이 시뮬레이션을 돌렸더니 네, 이거는 굉장히 알파 값을 많이 줘가지고 그나마 옅게 해서 보이게 겹친 그림이고요. 실제로 보시면, 어쨌든 눈으로 봐도 파란색 쪽이 어쨌든 좀 더 위쪽이 있는 걸 알 수가 있고요. 빨간색 쪽이 어쨌든 좀 더 아래에 있는 게 보여요. 그리고 제가 더 확연하기 위해서 스무딩 라인을 그렸어요. 이 파란색 굵은 색 혹은 빨간색 굵은 색 라인, 어 굵은 색 선은 지금 이 천명의 유저를 대표하는 어떤 하나의 선입니다. 그래서 명확하게 보면 어쨌든 200번째 게임이 끝나고 나서는 이만큼 차이가 나요. 끝에 가서. 그럼 이 차이가 얼만지 요기만 뜯어다가 박스 플롯을 그린 게 오른쪽 그림이에요. 보시면 Critical Prob.이 10% 일 때는 네, 한 중위수거든요 중위수가 한 500후반대고요. 그다음에 20%로 했을 때는 600초반대가 되는 게 보여요. 그래서 이걸로 봤을 때는 어쨌든 10%와 20%를 비교했을 때 20%가 더 낫다는 거죠. 이 게임에서는. 실제로 이렇게 될 건지 안 될 건지는 사실은 몰라요. 왜냐하면 제가 지금 이거는 유저한테 직접 대상으로 실험을 한 게 아니라 어떤 가상의 유저들 2000명을 만들어서 테스트를 한 거기 때문에. 그러면 이렇게 하고 나서 우리는 결론을 내리는 게 어쨌든 “20%가 더 좋더라.”라고 하고 테스트를 끝내죠. 실제로 이렇게 A/B 테스트를 게임 내에서 해보자는 게 지금 제 얘기고요. 실제로 많은 게임에서는 조금씩 하고 있어요. 몇 번 같이 해 본적도 있고 해서 이런 식으로 결과가 나오면 네 이렇게 해서 이제 뭐냐 하면 기획자들끼리 20%가 더 좋다라고 결론을 내리고 20%로 이제 업데이트를 하는 거죠. 이런 과정을 계속 거치는데 그렇게 하다 보니까 문제가 생기더라고요. 어떤 문제가 생기냐 하면

일단 테스트 비용이 발생해요. 테스트 비용이 발생을 하는 게 아까 그 그림 그대로 가져왔는데 코스트가 44.25가 차이가 나요. 이쪽이 안 좋은 쪽이죠. 안 좋은 그룹이랑 좋은 그룹, 그러니까 여기서는 크리티컬 확률이 10%랑 20% 일 때 44.25만큼이 차이가 나는데 이 얘기는 뭐냐면 테스트를 계속 진행을 하면 유저 한 명당 10% 크리티컬 확률이 10%인 환경, 게임 환경에 들어갔던 유저들은 어쨌든 Fun Index가 44.25만큼 적게 발생하고 있잖아요. 그러니까 이거 자체가 한 명당 손해인 거죠. 이걸 만약에 10만 명 단위였던 게임에다가 실험을 참여하게 해서 이게 만약 돈으로 바꿔본다면 매출로 바꿔서 1점당 100원으로 바꿔줬어요 제가. 그래서 이렇게 하면 4425원인데 10만 명의 그룹이 두 개잖아요. 두 개로 쪼개지니까 이쪽만 손해를 보고 있으니까 2로 나누면 약 2.2억 원의 테스트 비용이 발생을 합니다. 실제로 테스트를 모 게임사에서 같이 해보면 처음엔 되게 좋아하세요. 왜냐하면 그동안 계속 갑론을박하면서 싸우던 걸 어쨌든 깔끔하게 데이터가 해결을 해주니까 그래서 테스트를 아주 활발하게 했는데 이걸 나중에 돈으로 다 바꿔봤어요. 돈으로 다 바꿔봤더니 어마어마하더라고요. 실제로 제가 2.2억 원이 보시기에 많다라고 생각하실지 모르겠지만 서비스 규모에 따라서는 2.2억이 굉장히 적은 수치에요. 실제로 게임이 아니라 무슨 웹사이트나 홈쇼핑몰에서 이런 메인에다 대고 이런 A/B 테스트를 하면 하루에 몇천만 원해서 일주일 정도 하면 10억 이상 테스트 비용이 발생하는 경우도 있어요. 그래서 테스트 비용이 실제보다 굉장히 크다는 게 일단 첫 번째 문제고요.

두 번째 문제는 뭐냐면 세상이 바뀌어요. 우리가 보통 얘기하는 그 전통적인 실험 있잖아요. 영가설 검정이라고 얘기하는, 통계학 교과서에 보면 뭐 가설 검정이라고 해서 나오는 부분이 있어요. 그걸 그대로 따라요. A/B 테스트 그걸 그대로 따르는데 문제는 뭐냐면 그 테스트에서 가정이 “세상이 바뀌지 않는다.”에요. 예를 들면 제가 제약회사에서 신약을 개발했어요. 이번에 암을 획기적으로 잘 치료할 수 있는 어떤 약을 개발했으면 임상실험을 하죠. 그래서 대규모의 테스트를 해요. 돈을 굉장히 많이 들여가지고. 그다음에 이번에 새로 만든 약이 확실히 효과가 있다고 하면 사람의 DNA나 어떤 환경이 급격하게 바뀌지 않는 이상 그 약은 앞으로도 계속 효과가 있을 거라고 생각을 할 수가 있어요. 그런 전재가 있기 때문에 테스트를 어느 정도 하고 나서 끝내고 “아, 이 약은 효과가 있습니다.”라고 얘기를 하지만 실제로 게임이나 웹 서비스나 이런 경우에는 테스트를 쭉 했어요. B 군이, B 그룹이 더 좋아요. A 그룹보다. 이 경우엔 아까 A가 크리티컬 확률이 10%였죠. 10%인 경우보다는 20%인 경우가 좋다라고 해서 테스트가 이 시점에 끝났는데 실제 유저들이 조금 더 게임을 하다 보니까 Fun Index가 바뀔 수가 있어요. 이거는 유저의 행동 변화 혹은 다른 요인이 있을 수도 있고요. 그래서 이렇게 바뀌는 경우가 굉장히 자주 있어요. 그래서 실제로 게임이나 이런 쪽에다가 테스트를 하고 나서 아 이번에 테스트가 끝났으니까 이제 우리는 무조건 아까 얘기로 하면 크리티컬 확률 20%로 간다고 못을 박아놓고 조금 있다가 나중에 지표를 계속 보잖아요. 근데 좀 이상해요. ‘이거 좀 이상한 거 같은데 오히려 하고 나서 이전보다 더 안 좋은 것 같은데’라고 해서 테스트를 다시 하죠. 테스트를 다시 해보면 상황이 바뀌어 있어요. 여기에서 이 얘기를 듣고 통계적 유의성에 대해서 말씀을 하실 수도 있어요. 이게 실험을 충분히 오래, 충분히 오래 한다는 건 샘플 사이즈를 충분히 확보한다는 거거든요. 만약에 “유저가 10만 명이 아니라 20만 명이 필요했던 것 아니냐?”라는 얘기를 할 수 있는데 그 얘기랑은 좀 달라요. 그 얘기는 실험 샘플 사이즈가 작아서 그 실험이 반복을 했을 때도 같은 결과가 나올 것이라고 얘기를 못하는 경우고 이 경우는 아예 그 실험하는 환경, 유저의 행동이나 이런 게 아예 바뀌는 경우기 때문에 아무리 테스트가 끝나는 동안에 아주 오랫동안 아주 많은 샘플 사이즈를 가지고 테스트를 했더라도 유저가 바뀌면 그냥 다시 바뀌는 거예요. 그래서 통계적 유의성의 문제랑은 좀 다르고요. 그래서 이 두 가지 문제, 사실 A/B 테스트하면 더 많은 문제도 있는데 제일 많이 문제가 됐던 건 이 두 가지였어요. 그래서 테스트 비용이 어마어마하게 비싸다. 생각보다. 그다음에 세상이 바뀐다. 그리고 아까 테스트 비용에 말씀을 안 드렸지만 테스트를 한 번 실행하는데 들어가는 비용도 꽤 들어가요. 개발자들이 공수를 드려서 뭔가 바꾸고 어쨌든 A/B로 만들잖아요. 벌을 여러 벌 만드는데 A랑 B만 의견이 있다는 보장이 없어요. 실제로 테스트를 해보면 A/B가 아니라 A/B/C/D/E/F/G인데 뭐 열 개 가지고 테스트할 때도 있고 이러는데 이러면은 어쨌든 벌을 다른 벌을 열 개를 만들어야 되잖아요. 이게 지금 숫자만 이렇게 바꾸는 거면 이렇게 내부에서 숫자만 바꾸는 것만 해도 굉장히 공수가 많이 들어가는데 만약에 이 테스트를 디자인에 적용한다거나 하면 똑같은 캐릭터 디자인을 열 벌을 다르게 뽑아내야 돼요. 이런 작업들은 굉장히 공수가 많이 들어가죠. 그런데 그렇게 해놓고 나서 테스트 한 번 끝나면 나머지 진 애들은 다 버려버려요. 그리고 나서 ‘위너만 앞으로 계속 간다.’라는 식인데 사실 그것도 굉장히 비합리적이죠. 그래서 대안으로 제시하는 게 

MAB에요. Multi-Armed Bandit 문제인데요. 뭐 아시는 분들도 많을 것 같아요. 왜냐하면 이 문제가 나온 지가 굉장히 오래됐더라고요. 저는 처음에 이걸 보고 아 되게 좋은 생각이다라고 생각을 했는데 아주 오래돼서 깜짝 놀랐거든요. 혹시 모르는 분들 위해서 좀 자세히 설명을 드리면 일단 무슨 뜻이냐면 One-Armed Bandit이 슬롯머신의 속어에요. 그러니까 One-Armed가 팔이 하나라는 뜻이잖아요. 그러니까 팔이 하나인 Bandit은 날강도라는 뜻이거든요. 팔 하나, 외팔이 날강도라는 뜻인데 슬롯머신이 그렇잖아요. 이 레버 달린 슬롯머신 아시죠. 이게 ‘팔이 하나 달려있는데 얘가 내 돈을 계속 가져간다.’라고 해서 슬롯 머신에 대한 속언데 이제 Multi-Armed Bandit이잖아요. 이 얘긴 뭐냐면 레버가 굉장히 여러 개 달린 슬롯머신이에요. 무슨 얘기냐면 레버가 굉장히 여러 개 달린 슬롯머신에 가면 제가 코인을 들고 가요. 그다음에 어느 슬롯머신에 돈을 넣고 레버를 당길지 결정을 해야 되는데 제가 하고 싶은 건 뭐냐면 만약에 열 개의 슬롯, Arm이 있어요. 팔을 이제 Arm이라고 표현해서 여기에서는 Multi-Armed Bandit 이론에서는 Arm이라고 표현을 해요. 아까 A/B 있었잖아요 variation이. 그거랑 똑같이 여기에서는 용어를 Arm이라고 해요. 그래서 뭐 첫 번째 Arm, 두 번째 Arm, 세 번째 Arm 그래서 만약에 열 번째 Arm까지 만약에 있다라고 하면 제가 동전을 들고 들어가서는 그 여러 개의 Arm들 중에 일단 땡겨 봐야 어디서 돈이 나올지 알잖아요. 그래서 처음에 들어가서 1번부터 10번까지 넣어봐요. 그리고 땡겨서 탐색을 계속해요. 탐색을 여러 번 하다가 보면 “아, 나 여기에서 보니까 두 번째 Arm에서 돈이 잘 나오는 것 같애.”라고 하면 그때부터 거기다 코인을 계속 집어넣는 거죠. 문제는 뭐냐면 네, 이거예요. 그래서 제가 지금 얘기한 것처럼 탐색을 해야 되고 exploitaion, 이게 번역하기 굉장히 어려운데 저는 뽑아먹기라고 표현을 하거든요. 그래서 탐색하기와 뽑아먹기의 딜레마가 있어요. 그래서 돈 많이 주는 곳도 찾고 싶은데 난 돈도 많이 벌고 싶어요. 이 두 가지 딜레마가 있어서 탐색을 열심히 하면 돈을 잘 못 벌고요. 돈만 밝히면 탐색을 못하는 경우가 생기죠. 게다가 굉장히 많은 제약조건들이 있는 게 코인이 무한하지 않아요. 코인이 만약에 제가 100개밖에 없다라고 하면 실제로 전략을 다르게 해야 될 수도 있어요. ‘초반에는 탐색을 굉장히 많이 하다가 코인이 50개 정도 남았으면 그다음부터는 지금까지 아는 탐색했던 결과 중에서 제일 좋았던 슬롯머신에다가 코인을 넣어야 된다.’라는 식으로 뭐 어떤 전략들을 굉장히 많이 세워야 되는데 이 문제 자체 “어떻게 하면 탐색도 하면서 돈도 잘 벌까?” 이 문제를 네 Multi-Armed Bandit Problem이라고 해요. 이 문제 자체를 이렇게 MAB 문제라고 부르고요. 그러면 이 딜레마를 해결할 수 있게 해주는 여러 가지 방법들이 있어요. 굉장히 많아요. 위키피디아에서 MAB로 그냥 검색하시면 알고리즘이 굉장히 쏟아질 정도로 많이 나오는데 그중에 몇 가지를 실제로 사용을 해서 아까 했던 실험을 해보려고 해요. 이 실험을 하는 이유는 아까 얘기했던 A/B 테스트의 어떤 단점들을 얘들이 보완해 줄 수 있을 거라는 생각이 들기 때문이죠.

그래서 MAB 중에서 제일 간단한 Epsilon-Greedy라는 알고리즘을 간략하게 설명을 드리려고 해요. 굉장히 간단한데요. Epsilon이라는 숫자를 하나 정해야 돼요 사람이. 이 실험을 하려면 Epsilon이라는 숫자를 하나 정하는데 0부터 1사이의 숫자에요. 만약에 제가 Epsilon이 0.1이라고 선택을 해요. 그다음에 이제 이걸 가지고 테스트를 해요. 그럼 여기 보면 이제 Arm이 1번부터 n개의 Arm까지 있어요. 아까 제가 했던 A/B 테스트를 따지면 Arm이 1번부터 2번까지 있는 거죠. 그래서 처음에 유저가 들어오면 다트를 던져요. 다트를 던져서 0.1보다 아래 숫자가 나오면 그러니까 0.1의 확률만큼은 그냥 A/B 테스트를 해요. 그래서 얘는 뭐 하냐면 그냥 A/B 테스트를 하니까 1/n의 확률로 찢어지죠. 그냥. 동등하게. 여기는 A/B 테스트에요 진짜. 실제 A/B 테스튼데 Epsilon에 의해서 여기에 들어갈 트래픽, 유저의 비율이 결정이 되는 거예요. 그래서 10%라고 만약에 Epsilon을 정하면 백 명 중에 열 명은 A/B 테스트하는데 들어가서 각각의 Arm에 1/n의 확률로 찢어지죠. 그래서 여기에서는 이제 실제 Score 아까는 제가 Funny Index였는데 일반적으로 MAB 이론에서는 뭔가 특정하고 싶은 좋은 것, 많아지면 좋은 걸 Score라고 통칭해서 계산을 해요. 그래서 여기서 Score를 계산한 다음에 제일 좋은 Arm을 항상 여기다 갖다 놓죠. 그러면 10%의 확률로 여기 들어갔던 애들은 그냥 A/B 테스트 당했어요. 어떻게 보면 마루타죠. 어디가 좋은지 얘네들 갖고 테스트를 하고 싶었던 거고 실제로 여기서 알게 된 정보들을 가지고 90%의 트래픽, 90%의 유저는 여기 와서 제일 좋은 Arm에 들어갑니다. 아까 저희가 했던 A/B 테스트 얘기를 여기서 섞어서 얘기를 하면 아까 20% 크리티컬 확률인 경우가 제일 좋았잖아요. 제일이라고 하긴 그렇지만 두 개 밖에 없었으니까. 그러면 Best Arm에 항상 아까 그 아이가 와 있었겠죠. 그래서 여기는 20%인 크리티컬 확률이 20%인 게임 환경이고 여기는 Arm 1번 10% 그리고 20% 해서 두 개가 계속 실험을 하면서 탐색을 여기서 하고 있고 여기서는 뽑아먹는 부분이 되죠. Eplsilon-Greedy 알고리즘은 MAB 알고리즘 중에서 제일 간단해요. 제일 간단하고 구현도 굉장히 쉽고요. Epsilon이라는 모수를 하나 집어넣어야 된다는 게 단점이기는 하지만 이것도 들어오는 트래픽의 양을 알면 그리고 내 Arm의 개수가 몇 개인지 알면 아주 똑똑하게 정해줄 수 있어요. 왜냐하면 만약에 백 명이 들어오는데 여기서 10%로 하면 여긴 열 명밖에 없잖아요. 열 명밖에 없고 만약에 Arm이 2개다 하면 1/2씩 들어가니까 다섯 명씩 각 Arm에 테스트가 들어간다는 뜻이거든요. 근데 이거를 아까 통계적 유의성 얘기를 했는데 샘플 사이즈가 어느 정도 확보가 돼야지 통계적으로 유의한 결과가 떨어져요. MAB에서 똑같이 테스트를 하기 때문에. 그래서 그런 어떤 적절한 사이즈들을 생각을 해서 Epsilon들을 정하면 아주 간단하게 구현이 가능합니다. Epsilon-Greedy는. 이거보다 훨씬 똑똑하고 기발한 방법들이 굉장히 많아요. MAB에 보면. 일단 우리는 맛보기 차원에서 제일 간단한 알고리즘을 소개를 드렸고요.

그래서 아까랑 똑같은 테스트를 하는데요. 바뀐 건 없어요. 바뀐 건 없는데, 바뀐 건 없는데 이제 추가된 게 있죠. 일단 아까 유저가 여기 천 명이었고 여기도 천 명이었어요. 그런데 이번에는 몰라요. 왜냐하면 얘네들이 A로 들어갈지 B로 들어갈지 안 정했거든요. 정하지 않고 MAB 알고리즘에 의해서 Epsilon에 의해서 다트를 던진 다음에 걔가 어떻게 될지 선택을 할 거예요. 무작위로. 그렇기 때문에 어쨌든 2000명이 게임을 하는 건 똑같아요. 2000명이하는 건 똑같지만 각각 그룹에 몇 명이 속할진 모르겠고요. 똑같이 200번씩 게임을 하고요 Fun Index는 아까랑 똑같이 설정을 했어요. 그 대신 Epsilon이 들어가죠. Epsilon을 20%로 잡았는데 이 얘긴 뭐냐면 전체 트래픽, 전체 유저 중에서 20%에 대해서는 어느 Arm이 더 좋은지, A가 좋은지 B가 좋은지 탐색을 하겠다는 얘기가 되고요. 나머지 80%, 총 트래픽의 0.8만큼은 그냥 뽑아 먹겠다는 거예요. 좋은 게 정해지면 계속 뽑아먹겠다는 거예요.

아까 잠시만 말씀을 안 드렸는데 이 Best Arm이라는 게 한 번에 딱 정해주고 끝나는 게 아니고요. 이게 Flow잖아요. 일종의. 그래서 유저들이 계속 들어오면 그때마다 여기 들어와서 계속 갱신이 돼요. 그래서 항상 이 Score들이 Arm 1의 Score가 있고 Arm 2에 Score가 있고 Arm 3의 Score가 있고 Arm n의 Score가 있겠죠. n개의 Score가 있어서 매 순간마다 Score가 갱신될 때마다 어떤 Score가 제일 높은지 뽑아서 Best Arm을 계속 갱신을 해요. 실제로 게임이 계속 돌아가고 있으면 테스트가 계속 돌아가고 있으면 이 Arm의 성적에 따라서 Best Arm이 계속 바뀝니다. 

그래서 물론 지금 저희가 아까 했던 테스트는 얘가 지금 B가 크리티컬 확률이 20% 일 때 이긴다는 걸 이미 알고 있잖아요. 그래서 ‘MAB를 해도 시시할 것 같다.’라는 생각이 들지만 실제로 이걸 모르고 있고 변하는 세상이라고 하면 굉장히 유리한 조건이죠. 네 그래서 “80%만큼은 뽑아먹겠다.”가 지금 생각이고요. 그래서 이걸 가지고 

테스트를 돌렸어요. 아까 뭐 그 복잡한 실타래 같은 애는 필요 없어요. 왜냐하면 테스트를 미리 해봤기 때문에 누가 더 우수한지 우리는 이미 알고 있고요. 여기에서 알고 싶은 건 뭐죠? 네 ‘이 트래픽이 잘 분배가 됐느냐?’에요. 실제로. 지금 그냥 얘네가 지금 A variation 여기가 10%고요. 크리티컬 확률, 여기는 20%고요. 여기에서 유저의 숫자가 4000명이에요 합이. 4000이었는데 아까 여기 2000, 2000 이렇게 들어갔다라고 하면 여기에서는 조금 덜 들어갔죠. 왜냐하면 MAB 알고리즘에 의해서 20%만 탐색을 하고 나머지들은 다 뽑아먹기에 들어갔기 때문이에요. 그래서 B가 더 좋았기 때문에 여기에 더 많은 유저들이 들어갔고요. 그러면 이 비율이 실제로 이 3000명이라는 게 0.8이 되냐 왜냐면 아까 1-Epsilon을 0.8로 설정했잖아요. Epsilon을 0.2로 설정을 해서 그래서 0.8만큼 내가 뽑아먹겠다고 했는데 실제로 그렇게 뽑아먹지 못했어요. 왜냐하면 실제로 알고리즘이 돌아가는 걸 실시간으로 쳐다보고 있으면

초반에는 여기에서 굉장히 갈팡질팡해요. 왜냐하면 데이터가 이게 이제 충분한 샘플 사이즈가 쌓여야 된다고 말씀을 드리는 이윤데 샘플 사이즈가 여기에 각각 할당된 유저 수가 적으면 실제로 얘의 성능이 얼만지 정확하게 알 수가 없어요. 그래서 초반에는 굉장히 갈팡질팡해요. 그래서 Best Arm이 우리 예시, 간단한 A/B 테스트 예시를 보면 A가 됐다가 B가 됐다가 초반에는 굉장히 엇갈려요. 그러다가 어느 정도 테스트가 이루어지고 나면 Best Arm이 잘 안 바뀌어요. 왜냐하면 성능이 한쪽 Arm이 확실히 좋다는 게 아까 A/B 테스트에서 저희는 확인을 했죠. 그렇기 때문에 그때는 Best Arm이 안 바뀌죠. 하지만 그전에는 계속 바뀝니다.

그렇게 해서 0.8까지는 안 나왔고요. 0.8까지는 안 나왔는데 이걸 만약에 그냥 A/B 테스트를 했을 때랑 MAB를 했을 때랑 비교를 해보자는 거죠. 비교를 해보면 아까랑 똑같이 43.38 차이가 나왔어요. 이 두 개가. Fun Index가. 그래서 100원씩이라고 생각을 해주고요. 그러면 4338원씩 10만 명인데 그냥 A/B 테스트를 했으면 여기에 0.5죠. 왜냐하면 이 안 좋은 A에다가 절반을 줬을 테니까 5만 명을 줬겠죠. 그래서 아까처럼 똑같이 2.2억 원이 나오는데요. 실제로 이번에는 MAB를 해서 여기가 지금 0.754니까 여기에 안 좋은 A variation 그러니까 크리티컬 확률이 0.1인 곳에 들어간 유저의 수는 0.246밖에 안 돼요. 그래서 얘기를, 계산을 해보면 1.1억 원 약 두 개를 빼면 약 1억 정도 이익을 본 거죠. 비용이 덜 들어갔으니까 실제로 이익을 본 거예요. 뭐 돈이 생긴 건 아니에요 실제. 회사 입장에서 돈이 생긴 건 아닌데 안 잃어도 될 돈을 잃지 않았기 때문에 결론적으론 돈을 번 거죠. 그렇게 해서 테스트를 했더니 ‘어쨌든 그냥 A/B 테스트를 할 때보다는 훨씬 비용이 덜 든다.’라는 걸 알 수 있었고요. 아까 A/B 테스트 두 가지 이야기했었는데 안 좋았던 것 두 가지 중에 하나가 ‘비용이 너무 많다.’였고 그다음에 ‘무빙 월드에 잘 대응을 못 한다.’인데 

MAB는 그런 면에서도 굉장히 좋아요. 이거는 제가 다른 세팅으로 일부러 세상을 바꿔본 건데요. 무슨 얘기냐 하면 어 이 제가 천 번째 이천 번째 삼천 번째마다 일부러 각 A 그다음에 B, C 얘네들의 세상을 막 바꿨어요. 무슨 얘기냐면 얘네들이 원래 갖고 있는 퍼포먼스를 정해놨어요. 정해놨다가 이 순간이 되는 순간 제가 확 바꿔버렸어요. 여기에서는 원래 얘 퍼포먼스가 80점 정도 되는 앤데 얘를 한 25점 정도로 바꿨어요. 바꿨을 때 얼마나 잘 따라가느냐를 보고 싶었어요. 그래서 제가 그렇게 입력을 해놓고 나서 이 MAB에 의해서 Score가 얼마나 실제로 잘 쫓아가는지를 시뮬레이션을 돌린 거예요. 그래서 이 MAB 입장에서는 제가 뭘 바꿨는지 모르죠. 당연히. 그래서 들어가서 추적을 하다 보면 각각의 어떤 변곡점이 생길 때마다 어떤 세상이 변할 때마다 굉장히 잘 따라가요. 굉장히 잘 따라가고 있는데 이 얘기는 뭐냐면 아까 A/B 테스트를 했을 땐 어땠죠? 

A/B 테스트 그때로 잠깐 다시 돌아가 보면 네 이거였죠. 테스트를 끝내요. 테스트를 끝내고 나서 여기까지 잘 따라왔다고 쳐도 테스트 끝내면 다음에 바뀐 세상에 대해선 대응을 못하죠. 

그런데 이 그림 같은 경우에는 대응을 하죠. 대응을 하는데 중요한 건 뭐냐면 이 시점에 테스트를 끝내면 안 돼요. 이 시점 전에 테스트 끝내면 이렇게 해서 A가 최고하고 끝나잖아요. 근데 실제로 세상이 그렇게 잘 딱 Fix돼있지 않다고 생각이 든다면 MAB 가지고 실험을 계속하는 게 유리해요. 계속한다는, “계속하면 아까 테스트 비용이 그렇게 많다는데 해도 되냐?”라고 할 수 있는데 실제로 해도 돼요. 해보니까 하는 게 훨씬 이익이더라고요. 특히 여기에서 보시면 이건 좀 극단적인 예긴 하지만 A가 최고로 좋았다가 나중에 A가 제일 나빠지거든요. 이런 경우가 실제로 생기면 어 이런 경우 이렇게 해서 A가 제일 성능이 제일 떨어지면 이 경우에 어떻게 하냐면 실제로 MAB에서는 이 C에다가 트래픽을 거의 다 몰아줘요. 아까 Epsilon-Greedy 알고리즘을 그대로 쓴다고 하면 Epsilon을 10%라고 할게요. 그런데 실제로 10%로 할 필요도 없고요. 굉장히 트래픽이 많은 서비스 같은 경우는 5%만 해도 돼요. Epsilon을. 탐색에 들어가는 트래픽을 아주 작게 해놓고 그럼 나머지 95%는 얘가 다 먹어요. 얘가 다 먹고 그래서 실제로 그럼 이렇게 자주 변하냐 세상이. 이 커머스 업체에서 이런 비슷한 실험을 해봤어요. 실험을 해봤는데 되게 재밌는 게 거긴 시간대별로 다르더라고요. 10시에 많이 클릭하는 상품이랑 점심때 많이 클릭하는 상품이 전혀 달라요. 그래서 클릭을 많이 하는 상품을 최대한 위로 빨리빨리 올려주는 어떤 장치를 만들었거든요. 그렇게 했더니 훨씬 성능이 좋아지더라고요. 성능이 좋아진다는 건 클릭을 더 많이 하고 돈을 더 많이 번다는 거죠. 그래서 그런 식으로 MAB를 이용하면 변화하는 세상에 대해서도 잘 따라갈 수 있다는 얘기를 할 수 있고요. 그러려면 테스트를 계속해야 되죠. 그러면 장점이 뭐냐면 여기에는 Score만 가지고 나와서 그렇지만 트래픽을 얘기하면 이 둘의 트래픽 있잖아요. 맨 마지막에 가서 B, C의 트래픽은 거의 없다시피 하거든요. 이게 아주 큰 장점인 게 게임 기획하다가 얼토당토않은 기획안을 누가 내놨어요. 말도 안 되는 아까 그 크리티컬 확률 “우리 그냥 90%로 한 번 해봅시다.”라고 말할 수 있잖아요. 누군가가. “야 그건 말도 안 돼.”라고 하지만 MAB를 돌리고 있으면 할 수 있어요. 왜냐하면 90%를 집어넣고 이 성능이 아주 안 좋잖아요? 그러면 놀라울 정도로 빠른 속도로 트래픽을 다 뺏겨버려요. 처음에는 5%에서 또 1/n로 나눠서 들어가겠지만 그다음부터는 얘는 Score가 앞으로 올라올 가능성이 거의 없기 때문에 아주 빠르게 성능이 좋지 않다는 게 증명이 되고 아주 빠르면 실제로 이 그림 자체가 아까 어떤 그 기획자가 “90%로 합시다.”라고 들어왔는데 얘가 바닥을 깔고 있어요. 바닥을 깔면서 쭉 가고 있으면 이거는 계속 테스트를 할 필요가 없죠. 이런 경우에는 variation을 그냥 빼는 거예요. MAB를 하고 있으면 제일 좋은 게 variation을 집어 넣었다가 혹은 뺐다가 그래서 굉장히 실험적인 기획안을 집어넣거나 빼거나 할 수 있다는 장점이 있어요. 그리고 테스트를 이렇게 계속한다는 가정하에서. 그러면 MAB에 단점은 없냐?

네 단점이 있어요. 제일 요즘에 골치 아픈 단점인데요. 실제로 아까 제가 Score 계산을 할 때 보면 MAB 이론에서 이걸 trial이라고 해요. Arm을 한 번 땡기는 걸 trial이라고 하는데 그럼 게임에서는 10% 크리티컬 확률에서 게임을 한 판 딱 했어요. 그게 MAB 이론에서 한 번 땡긴 거거든요. 그래서 trial을 했는데 문제는 뭐냐면 저는 trial하고 나서 게임을 하자마자 그 결론에 의해서 저는 Fun Index를 계산해버렸잖아요. 근데 실제로 내가 높이고 싶은 거 이걸 가지고 내가 얼마나 효과가 있는지 알고 싶은 거는 만약에 리텐션이에요. 이 사람이 다음에 들어오는지 안 들어오는지. 그러면 문제가 뭐가 생기냐면 trial이랑 reward 사이에 Delay가 생겨요. 그래서 이걸 Delayed Feedback 문제라고 하는데 이렇게 되면 아까 MAB에서 보면 Score를 계속 갱신해가지고 Best Arm을 계속 앞으로 보내줬어야 되잖아요. Epsilon-Greedy로 따지면. 거기에서 문제가 생겨요. 그래서 trial해주고 나서 이 간격 동안 이 Score를 어떻게 갱신해줘야 되는가가 굉장히 큰 이슈더라고요. 실제로 작업을 해보니깐. 물론 여기에 대해서도 굉장히 많은 이론들이 또 나와있어요. 이걸 어떻게 해결하면 좋다. 이런 얘기가 나와있는데 아직 실무에서 저희가 못 써봐서 이렇다 할 대안이라고 말씀드리기에는 그런 방법은 아직까진 모르겠고요. 어쨌든 이 부분을 만약에 적용을 하신다라고 하면 실제로 아마도 네 게임에서 똑같이 있을 거예요. Delayed Feedback 문제가. 그래서 이 부분이 제일 유의할 점이고요.

그래서 제가 앞으로 바라는 실험이라는 건 뭐냐? 실제로 “기획자는 이제부터 숫자 만들지 마.” 이런 얘기가 아니에요. 실제로 기획자들의 감이 되게 좋거든요. 그럼 이거는 제 생각에 아주 좋은 Seed 값이라는 거죠. 처음에 어떤 Seed를 딱 줄 수 있는 사람이 기획자에요. 그래서 이런 사람들이 아까는 지금 10%냐? 20%냐? 가지고 싸웠잖아요. 저 같으면 사실 제일 바라는 모양은 이건데 “야, 그냥 10%랑 20% 사이일 것 같아.” 정도만 기획자가 정해줘요 컴퓨터한테. 컴퓨터한테 정해주면 얘가 A/B 테스트 첫 번째는 아 그러면 절반에서 뭐 설마 크리티컬 확률을 14.52% 뭐 이렇게 정하진 않을 거잖아요. 물론 그게 중요하면 그렇게 하면 되겠지만 일단 한 3개 정도 갖고 A/B 테스트를 해봐요. 해보다가 얘가 떨어져요. MAB를 돌렸더니 얘가 떨어지면 얘를 탈락시키고 그다음에 두 번째는 새로운 애를 가지고 와서 variation을 집어넣어서 테스트를 계속하는 거죠. 이런 식으로 테스트를 계속하면 어딘가에 가서 아마 멈출 거예요. 어딘가에 가서 멈춰서 아 지금 현 상태에서는 이 수치가 어쨌든 제일 좋다라는 식으로 계속 탐색을 할 수 있고요. 이걸 MAB를 통해서 하면 아까 말씀드린 것처럼 비용을 계속 줄이면서 계속 탐색을 하고 또 바뀌는 유저 행동에 대해서도 잘 대응을 할 수가 있어요. 그래서 “이런 식으로 하는 게 좋지 않을까?”라는 생각이 들어요. 이걸 탐색하는 방법은 굉장히 여러 가지가 있을 거예요. 실제로 저는 그냥 제 머릿속으로 그냥 간략하게 생각한 거지만 이걸 아마 이 구간에서 정보를 잘 탐색하는 방법은 알고리즘에서 흔히 얘기하는 알고리즘에서 굉장히 많은 조건들이 있을 거라고 생각을 하고요. 그래서 제가 생각하는 실험은 기획자가 좋은 Seed 값을 주면 기계가 잘 탐색을 하자는 거죠. 그리고 반대로 Feedback을 기획자도 얻을 수 있는 게 데이터 분석이 꼭 의사 결정을 잘 하기 위해서만 있는 게 아니라 의사결정을 하기 위해서 이런 데이터들을 얻잖아요. 얻고 나면 반대로 기획자는 배울 수가 있어요. 왜 기획자들의 Seed 값이 좋냐면 이 사람들은 굉장히 많은 경험을 쌓았거든요. 그 경험 자체를 실제로 아까 10%라고 고정해놓고 그냥 지나가버렸으면 이런 건 몰랐겠죠. 그런데 이런 데이터를 계속 받고 이렇게 기계가 탐색하면서 그 과정을 기획자가 역으로 보면 기획자도 내 데이터를 보고 더 감을 키울 수 있죠. 그리고 더 많은 학습을 할 수 있고요. 그래서 상호보완적인 관계가 가능할 거라고 생각합니다.

그럼 현실적인 문제. 게임에서 테스트가 갖는, 제가 제일 많이 듣는 얘기에요. ‘A/B 테스트를 한다.’라고 하면 실제로 유저한테 이쪽은 확률이 떨어지게 하고 저쪽은 확률을 좋게 해야 되잖아요. 여기에 대해서 굉장히 반감이 심해요. 유저도 심하지만 기획자들도 심하고요. 그래서 어제 황찬주님이 발표한 거 보니까 밤새 시뮬레이터 돌려놓고 집에 갔다 온다고 하는데 시뮬레이터가 잘 되어 있는 게임이면 이거 하기 굉장히 좋을 것 같아요. 시뮬레이터 돌려놓고 MAB가 같이 돌아가면 뭐가 제일 좋은지 딱 떨어져 나와있겠죠. 그걸 할 수 있고요. 혹은 정 ‘이걸 해야 된다.’라고 생각하면 저는 유저한테 그냥 솔직하게 공개하는 게 맞다고 생각해요. “이번에 우리 무슨 테스트할 건데 테스트 범위는 여기서부터 여기까지일 거고 이것 때문에 불이익을 당할 수도 있지만 그건 랜덤이다.” 이렇게 얘기할 수 있고요. 아예 기획적으로 특정 숫자를 랜덤으로 바꾸는 경우도 가능하죠. 그건 뭐 게임마다 다 다르겠지만 어쨌든 이거를 사람이 한 번 숫자를 박아놓고 바꾸려고 하면 어마어마하게 힘든데 차라리 그걸 기획적으로 “아, 이건 여기서부터 이 사이에서 왔다 갔다 하는 수치입니다.”라고 기획을 해놓고 이제 MAB가 계속 돌아가면서 숫자를 바꿔줄 수 있으면 굉장히 좋을 거라고 생각합니다.

그래서 결론은 사람이 꼭 해야 하는 일, 저는 기획자가 제일 잘 하는 일은 이거 같아요. 아까 그 엑셀 시트 있잖아요. 그 시트의 칸 만드는 거. 무슨 얘기냐면 “여기에 뭐가 필요하고 무슨 기획 요소가 필요하고 그래서 여기에 적절한 숫자를 써넣어야 된다”.라고 얘기하는 건 기계가 못해요 실제로. 이런 건 못하고 사람밖에 못 하죠. 기계가 잘 하는 건 그 빈칸에 쓰인 숫자를 잘 조정해 줄 수 있습니다. 사람이 “한 10% 정돈 거 같아.”라고 하면 “10% 정돈 거 같아.”라고 해서 넣어놓으면 거기서 양옆으로 한 3개 정도 탐색하다가 계속 옮겨가면서 탐색을 할 수 있겠죠. 그래서 ‘둘이 합쳐서 더 재밌는 게임을 만들 수 있겠다.’라는 게 저의 결론이고요.

막간을 이용해서 제 PR을 잠깐 하자면 제가 일하고 있는 회사에서 테스트 엔진을 지금 만들고 있어요. 그래서 아주 간략한 MAB는 가능한 테스트를 하고 있습니다. 실제로 웹 서비스에서는 서비스를 하고 있고 잘 돌아가는 것까지 확인을 했는데 사실 저는 게임에서 이런 테스트를 해보고 싶거든요. 왜냐하면 실제 분석을 한 것도 게임에서 시작을 했고 게임만큼 분석이 재밌는 분야가 없는 것 같아요. 제일 분석이 재밌는 쪽이 게임인데 아직까지 네 이 MAB를 게임 쪽에 정확하게 대입해서 사례를 만든 적이 없어요. 그래서 혹시라도 여기에 관심이 있고 좀 도움이 필요하다라고 생각이 드시면 저희한테 연락을 주시면 최대한 열심히 도와드리도록 하겠습니다. 

네, 제 발표는 여기까지고요. 지금까지 경청해주셔서 감사합니다.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
