Agile한 게임 개발이 어려운 3가지 이유 -2/2
요약
- 게임 내 세부 서비스를 특정 주기를 기반으로 운영한다. 특정 주기가 지나면 초기화되는 서비스를 통해 사용자의 행태를 관찰/분석하고, 다음 주기의 서비스에 이를 반영하여 개선한다.
- 사전 데이터 관찰을 통한 밸런싱을 진행한다. 다만, 서비스를 완성해서 사용자에게 보여주지 않고 서비스가 출시되었다는 가정 하에 사용자 데이터를 관찰할 수 있는 대시보드를 만들거나, 필요한 로그를 심는 등의 방법을 사용한다. 이를 통해 기획자가 의도한 밸런스를 가진 피쳐를 최종 완성하고 출시한다.
지난 글에서는 게임, 특히 PvP 라이브 서비스 게임에서 Agile 한 개발 방법의 적용이 어려웠던 이유에 대한 생각을 공유해 보았다. 공정성과 안정성, 그리고 높은 수준의 완성도를 가진 채 스펙을 출시하는 게임의 특성이 Agile 한 개발의 빠른 속도와 지속적인 실험과 개선과는 잘 어울리지 않았다고 생각했다. 하지만 많은 선배 기획자들과 PM들에 의해 소프트웨어 산업의 장점을 살리면서도 PvP 라이브 서비스에 적합한 개발 방법론들이 시행되었고, 이를 보고 배우며 효과를 거둘 수 있다고 생각했다.
본 글에서는 그 방법들 중 두 가지에 대해 소개하고자 한다.
그렇다. 솔직히 Agile 한 개발 방법론을 그대로 적용할 수는 없더라도, 게임도 엄연한 소프트웨어인 만큼 소프트웨어 개발 산업의 1) 사용자 반응을 실시간으로 쉽게 관찰할 수 있는 장점과 2) 제품 출시 이후에도 제품을 개선해 나갈 수 있는 장점을 살릴 수 있다면 더 완성도 있는 게임 서비스를 제공할 수 있을 것이라는 생각이 들었다.
1. 게임 내 세부 서비스를 특정 주기를 기반으로 운영한다.
특정 주기가 지나면 초기화되는 서비스를 통해 한 주기 내의 사용자의 행태를 관찰/분석하고, 다음 주기의 서비스에 이를 반영하여 개선한다. 흔히 '시즌'이라는 주기를 통해 서비스를 운영하는데, PUBG의 경우 3개월 단위의 시즌을 기반으로 랭크와 패스 프로그레션 시스템을 운영하고, League of Legends의 경우 1년 단위로 랭크 시즌을 운영하면서 시즌이 넘어갈 때마다 서비스에 변화와 개선을 준다.
Agile 개발 방법론과도 상당히 유사한 면이 있지만, Agile 방법론이 오래 사는 나무에 영양제를 공급하고 가지치기를 하며 키워나가는 식이라면 위 방식은 해마다 새롭게 자라는 벼를 위해 내년에는 다른 비료를 사용하거나, 모내기 시기를 조절하는 식이다.
예를 들어, 랭크 게임에 참여한 플레이어는 이번 시즌이 끝나면 자신의 랭크를 처음부터 다시 배정받고 올려야 한다. 이 과정에서 지난 시즌에는 실버->골드 랭크의 난이도가 지나치게 어려웠다는 피드백이 많았다면 이번 시즌에서는 좀 더 쉬운 난이도를 통해 게임에 더 큰 재미를 느끼고 오랜 시간 플레이할 수도 있을 것이다.
약 2주 단위로 운영되는 이벤트 시스템 역시 유사하게 작동할 수 있는데, 크리스마스 시즌 리텐션 확보를 위한 출석 체크 이벤트의 보상이 지나치게 평이하여 플레이어 참여도가 낮고 의견도 좋지 않았다면, 설날 출석 체크 이벤트의 경우 보상의 수준을 조금 더 올리는 방식으로 서비스의 조정이 가능하다. 이 경우 이벤트 시스템의 '시즌'은 2주가 되는 셈이다.
주의할 점 : 시즌 단위로 시스템을 변경하기 쉽도록 관리자 환경을 편하게 구성해야 한다.
2. 사전 데이터 관찰을 통한 밸런싱을 진행한다.
이 역시도 데이터 관찰을 통해 사용자의 행태를 관찰/분석하고 서비스를 개선해나가는 점에서 Agile 방법론과 유사한 점이 있지만, 1) 피쳐가 출시되지 않은 상태에서 해당 과정을 진행한다는 점, 2) 그리고 피쳐가 출시되기 전에 기획 의도를 수행할 수 있을 정도의 완성도 있는 Iteration이 진행된다는 점이 차이가 있다.
예를 들어 플레이어 랭크 시스템을 처음 출시하는 초기 단계의 게임의 경우 랭크 밸런싱이 매우 중요하다. 막 뜨고 있는 게임에 랭크 시스템이 엉망이어서 나와 실력이 크게 차이나는 친구가 정작 랭크는 얼마 차이 나지 않는 일이 벌어진다면 랭크 게임의 재미가 크게 반감될 것이다. 이런 현상을 막기 위해 기획자는 랭크 게임 기획 초기에 각 랭크의 플레이어 분포를 기획하고 (예: 실버 랭크는 랭크 점수 1000-1500점, 골드 랭크는 랭크 점수 1500-1800점 ...) 랭크 판별 알고리즘을 기반으로 피쳐 런치 사전에 플레이어 분포를 파악한다. 이때 예상보다 실버 플레이어의 분포가 50%로 더 많다면, 실버 랭크 점수의 폭을 조정하거나, 알고리즘을 조정하는 식의 개선이 이루어진다. 개선이 한 번에 완료되면 좋겠지만, 몇 번의 개선을 통해 기획 의도에 적합한 수치가 관찰되면 그때 피쳐를 출시한다.
주의할 점 : 상당히 긴 기간의 사전 준비 과정이 필요하며, 가시적인 성과 (피쳐 출시) 가 없는 상태에서 Iteration이 진행되기 때문에 해당 업무 진행을 위한 의사결정자와 협업자의 이해가 필요하다.
위의 예시는 F2P PvP 라이브 서비스 게임의 경우이며, PvE 패키지 게임 등 다른 형식의 게임의 경우 그에 맞는 개발 방법론을 적용하고 있을 것으로 생각된다. 혹시 독자분들 중 자신의 경험을 나누어 주실 수 있는 분들이 계시면 언제나 더 완성도 있는 지식을 위해 환영이다! (따봉)
주니어 단계의 기획자/PM으로 이직을 준비하면서 Agile 한 개발 방법론에 대해 깊게 생각해 볼 수 있는 기회였고, 무적의 진리라던가 법칙으로써 Agile 개발 방법론에 접근하기보다는 각 산업과 조직의 특성에 맞게 이를 바꾸면서도 '소프트웨어 제품 개발'의 장점을 최대한 살리고자 하는 핵심을 적용하는 것이 중요하다고 생각했다.
