1. CBT,FGT,OBT를 통한 GAME DATA MINING 기법
By-조찬만
ourlostcity@naver.com

2. 지난번에서는…
• 리텐션의 산출과 활용을 실전에서 활용할 수 있도록 예제를 통해 알아보았
습니다. 그럼 이번 시간에는…
CBT, FGT, OBT 등 각종 테스트를 통해 Data를 얻고 그 Data를
Mining 하는 기법에 대해 알아보도록 하겠습니다.
상당히 다양한 방법들이 있겠지만 시간 관계상 1개만…
Ps. 몇 일 동안 계속 잠 줄여가면서 이 짓 하니 잠이 모자라네요… 어우.. 지금 00시 37분…

3. • 이용자 선정은 최대한 다양한 객체들로 구성하는 편이 Data의 신뢰성을 높
일 수 있습니다. 단, 예외적인 상황이 있는데 이를테면 주 고객 타겟층을 특
정 집단을 겨냥하고 만들어진 게임이라면 그 집단이 형성될 수 있도록 이용
자를 선정해서 모집하는 것이 좋겠죠.
최대한 다양한 객체로 구성 시
: 나이, 성별, 좋아하는 게임 장르, 평균 게임시간, 해본 게임들, 기타 등등
특정 집단 겨냥 (초등학생 겨냥 시)
: 초등학생 50% 중학생~고등학생 30~40% 기타 성인 10~20%

4. DATA라고 하면 Log를 심고 그것을 기반으로 추출된 것만을 Data라고 여기
는 경우도 종종 있는데 사실, 이용자에게 얻을 수 있는 모든 피드백이 Data입
니다.
이번 시간에 다룰 것은 그 중 정량 Data Mining이며 정성 Data는 간략한 소
개만 하고 넘어가겠습니다.

5. 자유게시판, 커뮤니티, 설문지, 모니터링을 통한 관찰 등 이용자들의 ‘말로서 풀
어쓰는 것’, 즉 수치화가 어려운 Data
아래의 특징을 가집니다.
1. 정량화에 소모되는 시간이 매우 큼
2. 이용자의 감정이 포함된 피드백이 가능
3. 게임을 떠나는 이탈자는 피드백을 하지 않는 경우가 일반적
4. 일부 하드코어한 이용자들의 치우쳐진 정보들로 진실이 왜곡 될 수 있음

6. 대표적인 예
이용자들이 남긴 Log를 통해 Data를 수집하고 수치화 하는 것들을 의미합니다.
아래의 특징을 가집니다.
1. 머신, 기술, 리소스 비용이 크다.
2. Data는 거짓말을 못하지만 분석자는 진실을 말하지 않을 수 있다.
3. 개인의 Log가 집단의 Log에 파묻히는 경향이 존재
4. 추측, 추리는 가능하지만 진실된 감정을 알기 어렵다.
5. 분석자에 따라 정치적 수단, 성과 위장 등 악용 가능성이 농후하다.

7. Data는 정성, 정량 두 가지 모두를 종합적으로
보고 분석해야 합니다. 어느 한쪽에 치우치면
의미있는 Data를 얻어내기 힘듭니다.
분석자는 양심적으로 분석해야 합니다.
자신에게 유리한 방향으로 진실을 왜곡하는 것에
능하신 분은 당장 국회로 나가세요.

8. ★ CBT 진행
★ 용량 = 이용자 수

9. Client Data Save
Sever&DB
Mail To
Develop Team
Sever Data Save 방식 Client Data Save 방식
이용자들의 개인 PC에서 Data를
과부하 등 이슈로 인해
쌓고 Mail을 통해 전달받는 방식
한계가 존재하며 클라이언트 배포 시 약관 동의 형태로
세부적인 Data Log 남기기 어려움 진행하여 Mail로 전달해주는 사용자들에게 어
드벤티지를 약속하는 형태

10. 두 방법 모두 일장일단이 존재하지만 기술적 한계가 없다고 하면
Sever&DB Save 방식이 효율적이며
한계가 존재할 경우
Client Save 방식으로 진행하면 됨
Client Save 라면 Data 저장 방식은 Xml로 남기는 편이 마이닝 하기 편합니다.
Sever&DB Save로 한다면 SQL이나 다른 DB를 사용하면 되겠습니다.
(이 부분은 프로그래머와 논의하세요.)
단, Client Save 방식은 로컬에서 Data를 쌓기 때문에 그 Data를
개발사에 전달해주지 않으면 말짱꽝임.

11. 국내에서 널리 알려진 편인 던전&파이터로 예제를 시작하겠습니다.
(참고로 본인은 해당 개발사와 전혀 연관이 없습니다.)

12. 게임 디자인 흐름에 따라 Data를 얻을 영역을 분할하고 Log를 심을
항목들에 대해 구상을 합니다.
던전&파이터는 MORPG 형태의 게임이고 씬을 분리하면
‘마을’과 ‘던전’2가지 상태로 크게 분리가 가능합니다.
따라서 Data 수집 상태를 마을에서 추출 가능한 부분과 던전에서 추출 가능한
부분 크게 2개의 씬으로 구분해서 진행해보도록 하겠습니다.

13. 로그가 찍힌 시각과 UID
Event Log의 분류 이벤트 쿼리별로 남기는 세부
데이터 로그들
캐릭터의 상태 체크

14. Event 중 Move가 있습니다.
Move 이벤트는 약 5초 단위로 로그를 찍습니다.
로그를 찍을 때 Move Event에는 FieldID와 좌표값인 X,Y,Z를 남깁니다.
이 값이 시간 흐름에 따라 계속해서 찍힐 경우 우리는 유저의 ‘이동동선’을
확인할 수 있고, 이 Data는 기획자가 디자인한 이동동선과 실제 유저의 이동동선
을 비교해서 체크해볼 수 있게 만드는 Data가 됩니다.

15. 이벤트 쿼리별로 남기는 세부
Event Log의 분류
데이터 로그들

16. 1. 스킬 사용 빈도 파악
Event 중 Hit enemy 는 MonID로 분류된 오브젝트에 데미지를 가할 때
로그가 찍히게 됩니다. 하위 카테고리에는 SkillID와 Damage가 찍힙니다.
이 Low Data를 Mining하여 실제로 유저가 던전을 플레이 할 때
해당 캐릭터의 어떤 스킬들을 자주 사용하는지를 알 수 있습니다.
빈도수 같은 것을 정확히 예측하고 싶다면 CoolTime 대비 사용 가능 횟수
등까지 고려해서 값을 측정하게 되면 스킬 사용 빈도수를 알 수 있게 되겠죠.
이는 스킬 디자인에 활용할 수 있겠죠
2. 던전 난이도 조절
Kill Event를 확인하면 던전에서 PC들이 얼마나 많이 죽는지를 확인할 수 있고
그를 통해 던전 난이도를 조절할 수 있겠죠.

17. 3. 경제
획득에 대한 쿼리를 이용 Money, Item 등을 Level 별로 누적 재화를 확인 가능
상점 쿼리를 이용해 Spend kind도 확인 가능
4. 이탈 사용자의 마지막 행동
리텐션 부분에서 이탈사용자로 필터
이탈사용자들에 대한 Log를 통해 마지막 행동을 알아봄으로 인해
무엇 때문에 이탈했을지에 대한 추측 가능
5. 기타 등등…
Data를 남기는 양에 따라 그밖에 다양한 상황들을 파악할 수 있음.

18. 이러한 Data 분류는 시간흐름에 따라
유저가 게임상에서 일으킬 수 있는 Event들을
쿼리로 만들어 Log를 찍는 형태입니다.
이를 세분화하면 할수록 유저의 행동 패턴을
Data로 알아보기가 쉬어집니다.
이 단계에서는 가급적 최대한 상세하게 Event들
을 분류해서 Log만으로 유저 Play를 역추적까지
할 수 있는 상태로 만드는 것이 좋습니다.
즉, Data를 통해 유저의 플레이를 재현해서
디자인의 의도대로 흘러가는지에 대한 체크가
가능해지는 것이죠.

19. • 위의 형태처럼 Low Data를 남겼다면 이제 Mining을 진행해야 합니다.
• Mining은 엑셀의 피벗테이블을 사용하면 손쉽게 정리가 가능합니다.
• Data를 남길 때 위의 예시처럼 Low Data의 형태를 엑셀에서 손쉽게
편집이 가능한 형태가 되도록 미리 상의할 필요가 있습니다.
• 피벗 테이블은 매우 사용하기 쉽습니다. 인터넷에 피벗테이블 검색하세요.

20. • 방대한 양의 Data를 통해 ‘유의미 Data’, ‘불의미 Data’ 파악
• 유의미했던 Data들의 정량화 작업
• 실서비스 시 해당 Data들을 언제든 손쉽게 볼 수 있게 정형화
※ Flurry 같이 웹 등에서 손쉽게 볼 수 있는 형태로 변형하면 게임 서비스를 운
영하는데 매우 큰 참고를 할 수 있습니다.

21. 지난 시간에 쭈욱 이야기해왔던 리텐션을 올리는데 이번 시간
에 소개한 Data들이 있다면 많은 활용이 가능해집니다.
또한 유료화 부분을 설계할 때도 유저들이 어떤 시점에서
최초로 결제를 시도하는지 파악도 가능해지죠.
Data를 세분화하고 Mining해서 볼 수만 있다면 전략적 디자
인이 가능해집니다.
다만, 이 디자인은 감각 디자인 후에 후천적으로 파생되는
디자인이라는 점은 잊지 마시고, Data에만 의존하는
바보도 되지 마세요. 결국 Data에 기반하는 디자인도
수 많은 디자인 방법 중 하나일 뿐이니까요.