게임 로그 분석

로그란

로그의 모습

• 컴퓨터의 처리 내용이나 이용 상황을 시간의 흐름에 따라 기록한 것이다. 
• 개인용 컴퓨터 통신에서 메일등 통신 내용의 기록이며, 그 파일을 로그 파일이라고 한다.
• 통나무 목선 log on, log out에서 유래되었다. 
• 로그 데이터는 JSON, CSV, TSV와 같은 비정형 텍스트로 들어온다. 

로그 기록의 목적은 시스템 보안, 유지 보수 목적으로 사용된다. 

사고가 발생한 경우 데이터의 복원이나 사고 원인의 규명 등에 도움이 된다.    

 

 

게임 로그란

유저가 게임에 로그인을 한 순간부터 로그 아웃을 할 때까지의 모든 활동이 담긴 기록이다. 

게임 로그는 게임에서 실시간으로 진행되고 있는 여러 게임 내 상황들을 나중에 필요할 때 다시 보고, 복기할 수 있도록 육하원칙에 맞춰 자세하게 만들어야 한다. 

육하원칙은 '누가', '언제', '어디서', '무엇을', '어떻게', '왜'로 볼 수 있지만 '왜'는 로깅하는 시점에서 알기 어렵고, 오히려 '왜'에 대해 알기 위해서 로깅하는 것이기 때문에 '왜' 대신 '무엇에게'를 넣어 육하원칙으로 로그를 구축하면 좋다. 

 

육하원칙으로 게임 로그를 구축하면 좋다고 했으니 육하원칙에 맞춰 몬스터를 한 대 때리는 행동에 대해 서술하면 아래와 같다. 

• 누가 플레이어'땡땡땡'의 레벨 '1' 궁수 캐릭터'뚱뚱뚱'이
• 언제 '2020년 5월 20일 14시 30분 11초'에
• 어디서 스테이지 '1-3' '초원'에서
• 무엇을 '물리 데미지' '100'을
• 어떻게 '평타'를 때려서 '크리티컬'로 입혔다
• 무엇에게 NPC 레벨 '1'인 몬스터 캐릭터 '슬라임'에게 

육하원칙으로 로그를 구축하니 간단해 보이지만 실제로 구현하면 그렇지 않을 것이다. 또한 양이 너무 방대하며, 나중에 해석할 때 문제가 생길 수 있다. 효율적으로 분석하기에는 맞지 않아 일반적으로 적용하기도 힘들다. 

 

 

그렇다면 일반적으로 적용하기에는 무엇이 좋을까? 로그 시스템을 4단계로 구분해 보는 것이다. 

로그 시스템 설계 4단계는 아래와 같다. 

1. 객체별로 분류
   플레이어, 캐릭터, 재화 등 게임 내 존재하는 개체들을 나열해서 분류하는 것이다. 데이터베이스 용어로는 엔티티라고도 하는데 게임 내 어떤 유형이나 무형의 개체들에 대해서 서루 의미적으로 구분할 수 있는 정보의 최소 단위를 이야기한다. 
   개체들 사이를 관계도로 그려보는 것이 로그 설계에 도움이 될 수 있다. 
2. 액션별로 분류
   1단계에서 객체별로 분류한 개체들에 대해 개체들이 취할 수 있는 행동이나 가질 수 있는 상태값, 개체들의 상호작용에 의해 변화가 일어날 수 있는 부분들을 생각해서 분류를 나눠볼 수 있다. 
   예를 들어 플레이어라면 회원가입, 로그인, 레벨업, 아이템 판매 등을 말하고, 재화의 경우에는 획득, 소모, 재화의 총량 등이 될 수 있다. 
3. 중요도에 따라 데이터를 더하거나 빼기
   객체별로 분류하고 액션까지 나열하면 그다음에는 각 개체별로 좀 더 중요한 정보와 아닌 정보가 무엇인지 고려해 더하거나 빼는 작업을 한다. 
   
   기본적으로 로그는 자세하게 남길수록 좋다. 그래야 나중에 문제가 생기거나 뭔가 알고 싶을 때 추적할 수 있는 자료가 많아지기 때문이다. 
   하지만 그렇다고 모든 것을 상세하게 기록하기에는 한계가 생기기 때문에 추후 사용 빈도가 높을만한 데이터가 무엇일지, 없어도 되는 데이터가 무엇 일지에 대해 고민을 많이 하는 것이 좋다.
   
   예를 들어 스테이지 플레이 내역을 남길 때 적으로 누가 나왔는지 등의 시나리오 모드라면 이미 개발자들은 다 알고 있으니 굳이 남길 필요가 없을 것이다. 반대로 스테이지에서 플레이어가 어떤 캐릭터를 데려갔는지 등은 플레이어마다 변동이 있을 것이고, 어떤 캐릭터를 선호하는지도 알 수 있기 때문에 자세히 남기면 좋을 것이다. 
4. 로그 구조 확정
   모든 과정을 거치면 대충 전체적인 로그의 구조가 그려지게 된다. 그러면 각 객체에 어떤 정보들을 더 자세히 기록할 것인지 예제들을 적용할 수 있다. 

 

이렇게 구분한 로그 시스템을 추가로 설계하고 운영할 때 세 가지를 염두에 두어야 한다. 세 가지는 아래와 같다.

• 일단 뭐라도 쌓아두면 나중에 다 써먹을 곳이 있다. 
  당장 뭐라도 쌓는 것이 좋다. 
  로그는 자세하고 데이터가 많을수록 좋기 때문이다. 
  일단 지금 간단한 정보라도 바로 데이터로 남기기 시작하는 것이 훨씬 남는 게 많다. 이렇게 쌓은 데이터는 다음 게임을 출시할 때에도 사용할 수 있는 유용한 데이터가 된다. 
• '나중에 어떤 관점에서 로그를 조회하고 분석할 것인가'를 항상 고민하기
  단순이 쌓는 것보다 나중에 이렇게 쌓은 데이터로 무엇을 하고 싶은지 고민하는 것이 좋다. 
  예를 들어 게임 내 경제/물가 관리를 위해 실시간으로 스케일링을 하고 싶다면 앞서 로그 구조를 설계할 때 재화 정보를 자세히 기록하는 편이 좋다. 반면 MD, BM 관리를 하고 싶다면 인앱결제 내역에 대해 최대한 상세히 기록하게 된다. 
• 주기적으로 사용 빈도 파악, 부족한 데이터는 보완 / 필요 없는 데이터는 제거
  좋은 로그, 쓸모 있는 로그라는 것은 우리에게 의미가 있는 부분, 중요도가 높은 부분들을 집중적으로 자세히 기록하는 것이다. 반면에 주기적으로 로그 사용빈도를 파악하여 잘 쓰이지 않는 로그는 제거함으로써 서버 퍼포먼스나 로그 효율을 높여야 한다. 또한 주기적으로 부족한 데이터가 무엇인지, 필요 없는 데이터는 무엇인지 지속적으로 모니터링하면서 로그를 개선한다면 큰 도움이 될 것이다. 

 

 

게임 로그 분석

게임 로그를 쌓았다면 어떤 분석을 할 수 있을까?

일단 대부분 게임에서 가장 먼저 기본적으로 남기는 [로그인]로그를 이용해 동시접속자수나, 순 방문자(Unique Visiter)에 대한 모니터링이 가능하다.

로그인 로그

 

또는 레벨업 로그를 이용해 이탈률을 구할 수 있다. 

로그인 로그에서 계정 정보를 따로 테이블로 만들고, 로그인 테이블에서 최초 로그인 시간과 최종 로그인 시간을 넣은 다음 이탈 기준을 정해 이탈에 해당하는 계정 숫자를 구할 수 있다. 이를 좀 더 활용하면 이탈 후 복귀하는 유저도 구할 수 있다. 

 

 

밸런스도 확인할 수 있다. 

레벨업 로그를 통해 캐릭터가 레벨업 하는 순간의 로그를 보고 그래프를 그려보면 기획에서 설정한 레벨업 타임과 얼마나 차이가 나는지 알 수 있다. 

 

유저들이 기획보다 빨리 레벨업을 하고 있다면 기획에서 놓친 어뷰징 요소가 있다는 것이다. 반대로 레벨업이 느린 유저가 많다면 게임 가이드가 부족해 기획에서 의도한 대로 유저들이 움직이지 못하고 있다는 의미가 된다. 

위 그래프를 보면 기획에서 설정한 빨간 선 중심으로 위쪽과 아래쪽에 각각 유저가 분포하고 있다.

빨간 선의 아래쪽에 있는 유저는 하드코어 유저에 해당되는데 이 유저들의 게임 로그 내역을 보면 어느 컨텐츠에 어뷰징 요소가 있는지 알 수 있다. 

 

유저는 하드코어 유저, 평균 유저, 라이트 유저로 그룹을 나눌 수 있는데 각 그룹의 대표적인 캐릭터를 선택하고, 캐릭터의 성장 패턴을 살펴볼 수 있다. 

 

그래프를 보면 하드코어 유저에 의한 어뷰징도 존재하고, 평균 유저들이 기획보다 상당히 위쪽에 있어 전반적인 가이드가 부족하다고 볼 수 있다. 특히, 라이트 유저 그래프가 3 레벨에서 4 레벨로 넘어가는 구간에 크게 꺾어지고 있는 것을 보니 3 레벨의 컨텐츠 혹은 퀘스트에 문제가 있을 것으로 판단된다. 

 

레벨업 그래프에서 중요하게 볼 것은 각 구간 별 기울기다. 

하드코어 유저를 보면 6 레벨에서 9 레벨 사이의 그래프가 기획과 다른 것을 볼 수 있고 9 레벨에서 10 레벨은 위치상으로 오른쪽에 치우쳐져 있지만 기울기 자체는 기획과 비슷해 문제가 있는 구간은 6 레벨에서 9 레벨 사이라고 볼 수 있다. 

같은 방법으로 평균 유저를 보면 3 레벨에서 7 레벨까지는 레벨업이 느리다가 7 레벨에서 10 레벨까지의 속도가 갑자기 빨라진다.

 

두 그룹 모두 속도가 빠른 것을 보니 7 레벨부터 게임 난이도가 낮아졌거나 캐릭터가 갑자기 강해진 것으로 볼 수 있다. 레벨 디자인에서 몬스터가 약해지거나 게임 난이도가 많이 낮아지지는 않았을 것이니 7 레벨에서 입수하는 아이템이 캐릭터를 강하게 하고 있는 것은 아닌지 가설을 세워볼 수 있다. 만약 이것이 어뷰저의 패턴과 연결된다면 어뷰저들은 이 아이템을 3 레벨에 입수했다고 생각해 볼 수도 있다. 

 

이런 식으로 로그를 통해 게임에 관한 다양한 분석을 할 수 있다.

 

 

게임 로그 분석 시 

분석을 할 때 특정 로그 한 가지로도 할 수 있지만, 대개의 경우 여러 가지 로그를 함께 살펴보는 형태로 진행된다. 방향이 정해지고 나면 데이터를 가공은 시간을 들여 할 수 있기 때문에 다양한 로그를 어떤 형태로 조합하면 원하는 데이터가 나오는지 늘 아이디어를 모으고 고민해야 한다. 

 

 

인사이트

게임 로그 분석이 어떤 것을 위해서 하는지, 어떤 것을 하는지를 알 수 있었다. 

게임을 하면서 나의 모든 것이 어떤 방식으로 기록되는지와 이런 기록들을 가지고 운영에 활용이 되는 것에 대해 새로운 시각으로 볼 수 있는 기회였다. 또한, 만일 내가 회사에 가게 된다면 어떤 분석을 하고 싶은지를 생각해 볼 수 있었다. 

 

 

 

 

참고 자료

• https://velog.io/@sung-ik-je/%EA%B0%9C%EB%85%90-Log
• https://gameqa.tistory.com/88
• https://brunch.co.kr/@tentuplay/28
• https://brunch.co.kr/@tentuplay/29
• https://brunch.co.kr/@tentuplay/30
• https://brunch.co.kr/@tentuplay/31
• https://gameqa.tistory.com/86
• https://sseozytank.tistory.com/31
• https://zzsza.github.io/data/2021/06/13/data-event-log-definition/