게임 프로듀서는 아이디어보다 전환점을 관리하는 사람에 가깝다
프로듀서를 “일정 관리하는 사람” 정도로만 생각하면 중요한 본질을 놓치기 쉽다. 실제로 프로듀서가 계속 판단해야 하는 것은 일정표 자체보다 지금 프로젝트가 어느 단계에 있고, 다음 단계로 넘어가도 되는가에 가깝다. 같은 게임이라도 아이디어 단계와 프로토타입 단계, 버티컬 슬라이스 단계, 출시 준비 단계에서 던져야 하는 질문은 전혀 다르다.
이 구분이 흐려지면 프로젝트는 자주 꼬인다. 프로토타입에 완성품 수준의 퀄리티를 요구하거나, 버티컬 슬라이스를 단순한 데모로 오해하거나, 베타 직전인데 스토어 준비를 하나도 안 해 두는 식이다. 그래서 프로듀서에게 중요한 것은 “좋은 게임을 믿는 사람”이 되는 것보다 단계별 전환점을 정확히 관리하는 사람이 되는 쪽이다.
인디 게임 개발자이자 강연자인 Rami Ismail이 정리한 개발 마일스톤 구분은 이 점을 이해하는 데 꽤 유용하다. 그가 제시하는 흐름은 아이디어 단계(ideation), 프로토타이핑(prototyping), 버티컬 슬라이스(vertical slice), 프로덕션(production), 알파(alpha), 베타(beta), 출시(release)다. 이 구분은 완벽한 표준이라기보다, 팀이 지금 무엇을 증명해야 하는지 다시 묻게 해주는 기준선에 가깝다.
1단계. 아이디어: 무엇을 만들지보다 무엇을 검증할지 정리한다
아이디어 단계에서 가장 위험한 실수는 콘셉트를 이미 확정된 계획처럼 다루는 것이다. 실제로 이 시점의 게임은 아직 가설에 가깝다.
프로듀서가 이 단계에서 붙잡아야 하는 것은 보통 세 가지다.
- 누구를 위한 게임인가
- 어떤 차별점이 있는가
- 무엇이 아직 불확실한가
이 단계에서 일정표를 촘촘하게 짜는 것보다 더 중요한 것은, 이후 프로토타입이 답해야 할 질문을 정리하는 일이다. 아이디어를 살리는 것보다 아이디어를 검증 가능한 질문으로 바꾸는 일이 먼저다.
2단계. 프로토타입: 게임이 되어야 하는지가 목표다
Rami Ismail은 프로토타입의 목적을 “이 게임을 만들어야 하는가”를 판단하는 데 둔다. 이건 매우 실무적인 구분이다. 프로토타입은 예쁜 데모를 만드는 단계가 아니라, 핵심 루프와 조작, 콘셉트 충돌 여부 같은 질문에 빠르게 답하는 단계다.
그래서 프로토타입에 필요한 기준은 품질보다 속도와 정확도다.
- 핵심 재미가 실제로 성립하는가
- 가장 큰 리스크가 무엇인지 드러나는가
- 버려도 아깝지 않을 만큼 가벼운가
이 단계에서 프로듀서가 해야 할 일은 “더 완성도 있게”를 외치는 것이 아니라, 무엇을 검증했고 무엇은 아직 모르는지를 문서화하는 것이다.
3단계. 버티컬 슬라이스: 이 팀이 실제로 만들 수 있는지가 목표다
버티컬 슬라이스는 자주 오해된다. 많은 팀이 이것을 “조금 더 발전한 프로토타입” 정도로 생각한다. 하지만 Rami Ismail은 버티컬 슬라이스를 디자인 프로토타입이 아니라 프로덕션 프로토타입으로 구분한다. 즉, 게임이 재미있는지보다 이 팀이 그 품질을 실제로 생산할 수 있는지 확인하는 단계다.
이 단계에서 프로듀서가 봐야 할 것은 이런 것들이다.
- 한 덩어리 콘텐츠를 처음부터 끝까지 만들 수 있는가
- 아트, 코드, 사운드, 레벨 디자인 파이프라인이 연결되는가
- 첫 번째 결과물보다 두 번째 결과물이 더 빨라지는가
버티컬 슬라이스가 중요한 이유는 “이 게임이 좋아 보인다”를 넘어서 “이 팀이 이걸 반복 생산할 수 있다”를 증명하기 때문이다. 프로듀서는 이 단계에서 팀의 생산 속도와 병목을 읽어야 한다.
4단계. 프로덕션: 생산 파이프라인을 굴리고 범위를 지키는 단계다
프로덕션 단계에 들어가면 질문이 바뀐다. 이제는 게임이 될지 여부보다, 얼마나 안정적으로 계속 만들 수 있는가가 중요해진다.
여기서 프로듀서가 가장 자주 해야 하는 일은 범위를 지키는 것이다.
- 콘텐츠 생산 속도와 남은 분량을 비교한다
- 병목이 아트인지, 툴인지, 의사결정인지 분리한다
- 추가 요구가 일정과 품질에 주는 비용을 계산한다
이 단계에서 가장 위험한 것은 “좋아 보이는 추가 아이디어”다. 버티컬 슬라이스로 검증한 생산 파이프라인을 스스로 흔들기 쉽기 때문이다. 프로듀서의 역할은 팀의 열정을 꺾는 것이 아니라, 무엇을 지금 넣으면 전체 일정이 무너지는지를 투명하게 보이게 하는 것이다.
5단계. 알파: 기능 완성을 진짜 기준으로 둔다
Rami Ismail이 설명하듯 알파는 보통 feature complete, 즉 기능 완성 단계다. 여기서 중요한 것은 “대충 다 들어간 것 같다”가 아니라, 핵심 기능이 모두 연결되어 실제 플레이 가능한 상태인지다.
알파 단계에서 프로듀서는 다음을 명확히 해야 한다.
- 아직 빠진 기능이 무엇인지
- 남은 일의 대부분이 새 기능인지, 안정화인지
- QA와 수정 루프가 실제로 돌 수 있는지
알파를 선언해 놓고도 계속 큰 기능이 추가된다면, 프로젝트는 실질적으로 아직 프로덕션 단계에 머물러 있는 셈이다. 프로듀서가 지켜야 할 것은 일정표보다 단계 정의의 엄격함이다.
6단계. 베타: 콘텐츠 완성과 출시 준비를 함께 묶어 본다
베타는 보통 content complete에 가깝다. 주요 콘텐츠가 구현되어 있고, 남은 일은 폴리시, QA, 최적화, 로컬라이제이션, 스토어 준비, 운영 계획 정리에 가까워진다.
이 시점부터는 게임 내부만 보아서는 안 된다. Steamworks 문서를 보면 출시 전 스토어 페이지와 빌드는 Valve의 리뷰를 거쳐야 하고, 트레일러 업로드도 출시 과정의 일부다. 즉, “게임은 거의 다 됐다”와 “출시 준비가 됐다”는 같은 말이 아니다.
프로듀서는 베타 단계에서 이런 체크리스트를 묶어 봐야 한다.
- 스토어 페이지와 메타데이터
- 트레일러와 스크린샷
- 출시 빌드 안정성
- 고객 지원 및 커뮤니티 대응 준비
- 가격과 할인 정책
크라우드펀딩을 병행한다면 이 시점보다 더 앞에서 준비가 필요하다. Kickstarter도 프리런치 페이지를 최소 일주일 전에는 열어 커뮤니티 관심을 모으는 것을 권한다. 출시 전 시장 준비는 출시 후에 대체할 수 없다.
7단계. 출시: 판매가 아니라 피드백 루프의 시작으로 본다
출시는 종료가 아니라 운영 시작점이다. Steamworks 문서는 유저 리뷰가 스토어 페이지에 노출되고, 최근 30일과 전체 기간의 리뷰 점수가 표시된다고 설명한다. 또한 출시 후 주요 업데이트가 있으면 Update Visibility Round를 통해 기존 유저와 위시리스트 보유자에게 다시 노출될 수 있다.
이 말은 곧 출시 직후 프로듀서가 봐야 할 것이 단순 매출이 아니라는 뜻이다.
- 리뷰가 실제 기대치와 어긋나는 지점은 무엇인가
- 유저가 반복해서 지적하는 문제는 무엇인가
- 다음 업데이트가 제품 신뢰를 회복하거나 강화하는 데 어떤 역할을 하는가
출시 이후의 판단이 중요한 이유는, 지금의 플랫폼 환경에서는 첫 인상뿐 아니라 출시 후의 대응 능력도 제품의 일부로 읽히기 때문이다.
포스트모템은 8단계가 아니라 모든 단계 뒤에 붙는 습관이다
포스트모템을 맨 마지막 행사처럼 생각하면 늦는 경우가 많다. 실제로는 각 단계가 끝날 때마다 작은 포스트모템이 있어야 다음 단계 품질이 올라간다.
- 프로토타입은 무엇을 답했고 무엇을 못 답했는가
- 버티컬 슬라이스에서 어디가 막혔는가
- 알파가 늦어진 진짜 이유는 무엇이었는가
- 베타에서 출시 준비가 왜 밀렸는가
프로듀서가 축적해야 하는 자산은 일정표가 아니라 이런 전환점의 기록이다.
핵심 정리
게임 프로듀서의 역할은 아이디어를 믿는 데 있지 않다. 더 중요한 일은 각 단계가 무엇을 증명해야 하는지 분명히 하고, 아직 다음 단계로 넘어갈 준비가 안 된 상태를 구분해 내는 것이다. 아이디어 단계에서는 질문을 정리하고, 프로토타입에서는 게임이 되어야 하는지를, 버티컬 슬라이스에서는 팀이 실제로 만들 수 있는지를, 프로덕션에서는 생산 속도를, 알파와 베타에서는 완성과 출시 준비의 기준을 엄격하게 관리해야 한다.
출시는 끝이 아니라 피드백 루프의 시작이다. 그래서 프로듀서는 일정 관리자이기 전에, 프로젝트의 전환점을 관리하는 사람에 더 가깝다.
마치며
좋은 프로듀싱은 모든 문제를 미리 없애는 기술이 아니다. 지금 단계의 질문과 다음 단계의 질문을 섞지 않도록 계속 정리하는 기술에 더 가깝다.
프로젝트가 자주 무너지는 이유도 대개 같은 곳에 있다. 프로토타입에 완성도를 요구하고, 버티컬 슬라이스를 홍보 영상으로만 쓰고, 알파와 베타를 선언해 놓고도 기능 추가를 멈추지 않기 때문이다. 단계의 이름보다 중요한 것은, 그 단계가 무엇을 증명해야 하는지 팀이 공유하고 있는가다.
참고 자료
- Rami Ismail, Prototypes & Vertical Slice: https://ltpf.ramiismail.com/prototypes-and-vertical-slice/
- Rami Ismail, Milestones: https://ltpf.ramiismail.com/milestones/amp/
- Steamworks Documentation, Store Presence: https://partner.steamgames.com/doc/store
- Steamworks Documentation, User Reviews: https://partner.steamgames.com/doc/store/reviews
- Steamworks Documentation, Update Visibility Rounds: https://partner.steamgames.com/doc/marketing/visibility/update_rounds
- Kickstarter, How to Craft a Pre-Launch Page: https://updates.kickstarter.com/how-to-craft-a-pre-launch-page/