나는 2022년~2023년 1년간 게임 기획자로 근무한 경험이 있다. 게임 기획자로 1년간 근무했었다고 말하면, “게임 기획자는 대체 무엇을 해요?”라고 물어보시는 분이 많았다. 그래서 이번 포스팅에서는 게임 기획자가 하는 일들을 정리하고자 한다.
게임 기획자가 하는 일은 크게 세 가지로 나눌 수 있다. 기획서 작성, 스프린트 관리, 그리고 스프린트 종료 후 지표를 확인하고 이에 따른 의사결정을 내리는 것이다.
- 기획서 작성
- 스프린트 관리
- 지표 확인과 의사결정
기획서 작성
게임에 필요한 각종 기획서를 작성하는 과정이다. 기획서는 크게 아래와 같이 나눌 수 있다.
- 컨셉 기획서: 게임의 전반적인 방향성을 제시하는 문서
- 레벨 디자인/밸런싱: 게임의 난이도, 레벨 설계, 밸런스 조정을 위한 모든 정보를 체계적으로 정리하는 문서
- 시스템 기획서: 새로 추가할 게임 시스템을 상세하게 기술해 모든 팀원이 공통된 이해를 갖게 하는 문서
이 중 가장 중요하고, 가장 많이 썼던 문서는 바로 시스템 기획서다.
시스템 기획서는 먼저 시스템의 역할을 정의한다. 왜 이 기능이 필요한지 그 목적을 기술한 후, 세부 메커니즘이나 규칙, 플로우 등을 상세하게 정의한다. 이에 따라 필요한 UI/UX 설계도 포함된다.
최종적으로 모든 팀원이 시스템에 대해 동일한 이해를 갖게 하는 것이 가장 중요하다. 문서 중에서도 시스템 기획서의 가독성이 특히 중요한 이유다. 팀원 간 이해가 맞지 않으면 바로잡고 나아가는 데 시간이 더 많이 소요되기 때문이다. 그래서 항상 기획서를 쓸 때 어떻게 하면 가독성을 높일 수 있을지 고민했다.
초기에는 기획서를 작성할 때, 시스템 자체를 설명하는 데에만 집중했다. 기획서를 완성한 후에는 모든 팀원 앞에서 기획 리뷰를 진행하며 이해되지 않거나 빠진 부분에 대해 피드백을 듣는데, 기획서에서 해당 시스템이 왜 필요한지에 대한 설명이 부족해 매번 기획 리뷰 때마다 먼저 설득하는 데 오랜 시간이 걸리게 되었다. 이런 일이 반복되자 점차 기획서 구성을 고쳐야겠다는 필요성을 느끼게 되었다.
그래서 기획서를 읽는 사람의 입장이 되어보려고 노력을 했던 것 같다. 계속 읽다 보니 글의 첫 문장에서 의도가 명확하게 드러나고, 이후 글의 흐름이 어떻게 전개될지 예고되어 있으면 훨씬 읽기 편하다는 것을 깨달았다. 그 이후부터는 시스템의 의의와 도입 배경, 그리고 그 근거를 더욱 신경 써서 작성하게 되었다.
다 적은 문서는 본문 내 문단 간 위계를 주어 정리하고, 반복되는 문장과 단어를 줄이며 더 간결하게 쓸 수 없는지 2차 3차 검토를 하면서 계속 잘 읽히는지 확인했다. 경험이 쌓이다 보니 스토리처럼 흐름이 명확한 글이 잘 읽힌다는 것을 알게 되었다. 발단-전개-절정-결말 구조는 비단 소설뿐 아니라 모든 글에 통하는 것을 알게 되었고, 이후 흐름이 끊기지 않은 지 전개가 자연스러운지 계속 체크했다.
이제 와서 생각해 보면, 결국 기획자란 팀원의 생각을 하나로 모으기 위해 가독성이 높은 문서를 작성하는 사람이라고 할 수 있다. 그리고 이를 위해서는 새 시스템이 필요한 이유를 모든 구성원에게 설득할 수 있어야 한다. 결국 기획자가 먼저 해당 시스템이 필요한 이유를 스스로 명확히 알고 있어야 한다. 기획자마저 해당 시스템에 확신이 없다면 어느 구성원이 적극적으로 개발에 임할 수 있겠는가. 따라서 기획 의도를 작성하는 과정은 기획자 자신이 확신을 갖기 위한 가장 중요한 작업이다.
가독성과 잘 읽히는 기획서는 사실 그 이후의 일이다. 물론 이게 중요하지 않다는 건 아니다. 의도를 통한 설득과 가독성 모두 다 가져가야 좋은 기획자라고 할 수 있다.
스프린트 관리
스프린트 관리에 대해 설명하기에 앞서 Stage 개념을 먼저 설명해야 할 것 같다. 이전 회사에서는 게임을 Stage 분류했다.
- Stage 0: 게임 MVP 제작
- Stage 1: 서비스에 필요한 기능을 추가하고 본격적인 시장성 검증 (킥오프)
- Stage 2: 메타 시스템을 추가한 뒤 수익화 테스트 진행
- Stage 3: 마켓 스케일 업
- Stage 4: 라이브 단계
각 단계를 넘어가는 기준은 KPI이다. 각 Stage 별 인게임 KPI와 마켓 KPI, 이 두 가지 모두 충족해야 다음 Stage로 넘어갈 수 있다. 만약 조건을 충족하지 못해 기간이 길어진다면 해당 Stage를 유지한 채 업데이트를 중단했다.
Stage 0 단계에서는 전 직원이 직군과 관계없이 자유롭게 게임 컨셉을 제안한다. 제안된 컨셉들은 리더 회의에서 검토되고, 통과된 컨셉에 한해 MVP를 제작한다.
MVP 제작 시에는 컨셉 기획서에 명시된 메인 플로우를 우선적으로 구현한다. 이렇게 만들어진 MVP는 이후 마켓 테스트를 거쳐 조건이 충족되면 Stage 1으로 넘어간다.
Stage 1 단계부터는 기획자가 투입되고, 추가 개발자와 아트 인력이 합류하면서 본격적으로 스프린트를 진행한다. 스프린트 관리는 1주일 단위로 아래와 같은 단계로 진행된다.
- 피처 선정: 스프린트에 진행할 피처 리스트 목록화
- 스프린트 진행: 피처 리스트별 작업 일정 산정 & 담당자 지정
- 일정 공유: 피처 리스트와 일정, 담당자를 공개 채널에 공유
만약 새로운 시스템 도입이나 시도가 있다면 중간 회의를 진행한다. 중간 회의 시간 전까지 중간 빌드를 뽑은 뒤 중간 회의에서 팀원들과 함께 테스트하고 피드백을 진행한다. 최종 빌드때 이 피드백을 적용한다.
개발 마감일에는 테스트 빌드의 QA를 진행한다. 크리티컬한 버그를 찾고 수정하는 일의 연속이다. 이슈가 발견되지 않으면 업로드 빌드를 진행하고, 최종 QA에서 이상이 없다면 담당 PM에게 알려 서밋을 진행한다.
지표 확인과 의사결정
보통 게임은 금요일에 서밋 된다. 이후 다음 주 월요일에 와서 주말 지표를 확인하고 스프린트 성과를 파악한다. 전 스프린트 지표와 비교하면서 어떤 지표가 떨어지고 올라갔는지 확인하고, 그 이유를 추론한다.
예를 들어 일부 스테이지의 난이도를 낮춘 업데이트를 진행했을 때 전체 게임 플레이 타임이 감소했다면, 쉬워진 난이도로 인해 유저들이 게임의 재미를 느끼지 못해 중도 이탈했다는 가설을 세울 수 있다.
이렇게 세운 가설들을 모아서 검증을 진행한다. 검증은 여러 가지 방법으로 진행할 수 있다. 더 상세한 지표를 확인하는 방법도 있고, 가설을 바탕으로 테스트를 진행할 수 있다.
예를 들어 아래와 같이 진행할 수 있다.
- 상세 지표 확인: 난이도가 높은 스테이지와 낮은 스테이지의 이탈률을 비교하기
- 테스트 진행: 스테이지 난이도가 높은 버전과 낮은 버전 두 개로 A/B 테스트 진행
- 유저풀을 나눠 높은 난이도의 A 버전과 낮은 난이도 B 버전을 테스트한 뒤, 두 버전의 지표를 비교
검증 결과 지표나 테스트가 뒷받침된다면, 그에 따른 해결 방안을 제시한다. 예를 들어 이탈률이 높은 쉬운 스테이지의 난이도를 높이는 업데이트를 다음 스프린트에서 진행할 수 있다.
하지만 가설을 세우고 검증 후 해결 방안을 적용해도 지표가 즉시 개선되지 않는 경우가 많다. 이는 지표 변화에 영향을 미치는 수많은 변수가 있기 때문이다. 예를 들어, 특정 주에 연령층이 높은 유저가 많이 유입되어 단기적으로 난이도가 높은 스테이지를 선호했거나, 난이도가 문제가 아니라 스테이지가 재미가 없는 경우도 있을 수 있다.
이런 식으로 여러 고려 못 한 변수들이 늘 존재하기에 상세 지표를 확인함과 동시에 테스트를 진행하는 것이 안전하다. 두 개를 다 진행해도 100% 확실하지 않지만, 어느 정도 위험 부담은 줄일 수 있다.
개인적으로 이렇게 지표를 바탕으로 가설을 세우고, 다음 스프린트 방향성을 결정하는 일이 모든 업무 중 가장 어려웠다. 회사의 매출이 달린 문제이기도 하고 이런 큰 결정을 맡는다는 것 자체에서 큰 부담을 느꼈다. 그 와중에 내린 결정을 스스로도 100% 확신할 수 없었다.
이런 상황에서 구성원들을 설득하는 것 역시 어려운 일이었다. 내가 할 수 있는 최선은 객관적인 지표를 토대로 가장 합리적인 추론을 하고, 그에 따른 해결책을 제시하는 것뿐이었다. (그래서 매주 업데이트를 할 때마다 지표가 좋기를 기도했다)
그외 일들
컨셉 제안서 작성
컨셉 기획서는 어떤 게임을 만들지 제안하는 문서이다. 게임의 대략적인 플로우와 재미 포인트, 해당 게임이 시장성이 있는 이유 등을 적는다. 레퍼런스 게임 영상을 추가해서 어떤 게임을 만들고 싶은지 명확하게 보여주는 게 중요했다. 컨셉 기획서들은 주기적으로 회의를 거쳐 통과되면 제작에 들어간다.
게임 컨셉 문서는 시간 나는 대로 작성했다. 트렌디한 영상이나 기존 게임을 보면서 이런 걸 어떻게 새 게임으로 재해석하면 재미있을지 고민을 많이 했다. 나는 재직 중 총 19개의 컨셉 제안서를 냈고, 그중 4개가 stage 1 단계로 승급되어 킥오프되었으며 실제로 성과를 내서 stage 2까지 간 게임은 2개였다. 이 두 게임 모두 내가 메인 기획자로 담당했다.
내가 제안한 게임이 실제 서비스되는 것을 보는 경험은 색다른 경험이었다. 서비스 제안부터 킥오프, 그리고 이터레이션을 모두 거치며 중요한 의사결정을 할 수 있는 경험을 얼마나 더 할 수 있을까. 이런 경험 덕분에 서비스가 어떻게 탄생하고, 스프린트가 어떻게 진행되는지, 서비스 사이클 전반에 대한 이해를 얻을 수 있었다.
효율을 높이는 문서 만들기
업무에 익숙해지면서 타인을 둘러볼 여유가 생겼다. 기획팀은 매일 아침에 모여서 짧게 스크럼 시간을 가졌는데, 이때 구성원들의 업무를 파악할 수 있었다. 그러다 보니 공통으로 반복되는 업무가 꽤 많다는 것을 알게 되었다. 나는 내 업무를 마친 후, 반복되는 업무에 드는 시간을 줄이기 위해 노력했다.
두 번 이상 반복되는 업무가 있으면 효율적으로 처리할 방법을 고민했다. 그중 한 사례는 회사 규모가 커지면서 입사하는 기획자와 PM이 많아졌는데, 이들의 온보딩을 내가 대부분 맡게 되어 시간이 많이 소요되었다는 점이다. 그래서 공통 온보딩 자료를 만들어 공유했고, 신입 입사자에게 온보딩 매뉴얼을 제공한 후 Q&A를 진행했다. 그 결과 온보딩에 드는 개인 시간을 확실히 줄일 수 있었다.
그 외에도 테스트 세팅 시간을 줄이기 위한 매뉴얼 제작, 자주 참고하는 문서와 링크 정리, 자주 사용하는 레퍼런스 gif 모음 등을 만들어 업무 효율을 높였다.
사내외 외비나 & 강연 & 세미나
이 외에도 사내 또는 외부 세미나를 진행하기도 했다. 원래 발표를 두려워하고 잘하지 못했지만, 여러 차례 많은 사람들 앞에서 발표하다 보니 어느 정도 자신감을 얻게 되었다. (여전히 긴장은 된다)
내가 배운 것
기획자로 1년간 근무하면서 배운 것들은 아래와 같다.
항상 핵심에 집중하라
스프린트를 이끌고 지표를 확인하면서, KPI를 중심으로 생각하는 법을 배웠다. 핵심 지표를 파악한 후 목표 지표를 설정하고, 그에 맞춰 스프린트 방향성을 결정하는 과정을 반복하며, 무엇이 핵심인지 먼저 판단하고, 이를 위한 백로그를 산출하여 진행하는 법을 익혔다. 이후 어떤 일을 진행할 때도 아래와 같은 과정을 거치게 되었다.
- 핵심을 찾는다.
- 그게 왜 핵심인지 근거를 찾는다.
- 핵심을 달성하기 위한 절차를 세운다.
- 절차를 충실히 따르고, 완성한다.
완벽한 의사결정은 존재하지 않는다.
의사결정은 언제나 옳을 수 없다. 당시 합리적으로 보였던 결정도, 예상과 다른 결과가 나타날 수 있다. (미처 고려하지 못한 변수는 늘 있기 마련이다)
이럴 때 구성원들의 의견을 최대한 듣는 것이 문제 해결에 도움이 된다. 타인은 내가 보지 못한 부분을 볼 수 있기 때문이다. 그래서 타인의 의견이 매우 중요하다는 것을 깨달았다.
또한 객관적이고 명확한 근거가 필요하다는 점도 깨달았다. 구성원을 설득하기 위해서, 그리고 나중에 의사결정 결과에 대해 스스로를 보호하기 위해서라도 말이다.
의사소통은 공개된 곳에서 명확하게
의사소통은 공개된 곳에서 명확하게, 객관적인 근거와 함께 진행해야 한다는 것을 알게 되었다. 특히 기록으로 남기는 것이 중요하다는 교훈을 얻었다. 말로만 한 의사소통은 기록에 남지 않아 증거가 되지 않고, 쉽게 잊힌다. (기록 없이 말로만 합의했다가 모두가 기억하지 못해 어려움을 겪은 경험이 있다)
모두가 쉽게 리마인드할 수 있도록, 그리고 나중에 증거로 사용할 수 있도록 무조건 공개된 채널에서 의사소통해야 나를 보호할 수 있다.
