게임은 어떻게 만들어질까: 기획부터 출시·업데이트까지
아이디어 한 줄이 실제 게임이 되기까지 기획, 프로토타입, 제작, 알파·베타 테스트, 출시 심사, 출시 후 업데이트로 이어지는 게임 개발 과정을 단계별로 설명합니다.
게임 한 편이 나오기까지는 생각보다 많은 단계를 거칩니다. 화면에서 보이는 것은 완성된 결과뿐이지만, 그 뒤에는 수없이 버려진 아이디어와 시험판, 고쳐진 버그가 있습니다. 혼자 몇 달 만에 만드는 작은 게임도 있고, 수백 명이 몇 년에 걸쳐 만드는 대작도 있지만 거치는 흐름은 의외로 비슷합니다.
이 글에서는 게임 개발을 기획, 프리프로덕션과 프로토타입, 본 제작, 테스트와 마일스톤, 출시 준비와 심사, 출시 후 운영이라는 순서로 나눠 살펴봅니다. 각 단계에서 누가 무엇을 하는지, 왜 그 단계가 필요한지에 초점을 맞췄습니다.
게임을 만드는 사람들
먼저 누가 게임을 만드는지 보겠습니다. 팀 규모에 따라 한 사람이 여러 역할을 맡기도 하지만, 기본적인 역할은 대체로 다음과 같습니다.
| 역할 | 하는 일 |
|---|---|
| 기획자(디자이너) | 규칙, 시스템, 레벨, 밸런스, 이야기 설계 |
| 프로그래머 | 게임 로직, 엔진, 서버, 도구 개발 |
| 아티스트 | 캐릭터, 배경, UI, 애니메이션, 이펙트 |
| 사운드 | 음악, 효과음, 음성 |
| QA(테스터) | 버그 찾기, 재현 절차 정리, 품질 확인 |
| 프로듀서 | 일정, 인력, 예산 관리와 팀 사이의 조율 |
큰 프로젝트에서는 여기에 개발을 돈으로 지원하고 마케팅·유통을 맡는 퍼블리셔가 더해집니다. 퍼블리셔는 단계별 목표(마일스톤)를 정하고, 개발사가 이를 달성할 때마다 다음 단계 비용을 지급하는 경우가 많습니다.
1단계: 아이디어와 기획
모든 게임은 "이런 게임이 있으면 재미있겠다"는 한 줄에서 시작합니다. 이를 하이 콘셉트라고 부르는데, 게임의 핵심을 짧은 문장으로 설명한 것입니다. 이후 이 아이디어를 투자자나 퍼블리셔, 또는 팀 내부에 설명하는 피치를 거쳐, 장르, 목표 플랫폼, 대상 플레이어, 핵심 재미, 대략적인 규모를 정리합니다.
이 단계에서 중요한 질문은 "플레이어가 반복해서 하게 될 행동이 무엇이고, 그것이 왜 재미있는가"입니다. 퍼즐 게임이라면 한 판을 푸는 과정, 액션 게임이라면 적과 싸우는 몇 초가 여기에 해당합니다. 이 핵심 반복 구조를 흔히 코어 루프라고 부릅니다.
기획 내용은 게임 디자인 문서(GDD)로 정리합니다. 예전에는 수백 쪽짜리 문서를 처음에 다 쓰는 경우도 있었지만, 요즘은 개발하면서 계속 고쳐 나가는 살아 있는 문서로 쓰는 편이 많습니다.
2단계: 프리프로덕션과 프로토타입
본격적으로 많은 사람과 돈을 투입하기 전에, 아이디어가 실제로 재미있는지 확인하는 단계입니다. 여기서 만드는 것이 프로토타입입니다. 그래픽은 네모와 동그라미뿐이어도 괜찮습니다. 목적은 예쁜 화면이 아니라 핵심 재미를 검증하는 것입니다.
프로토타입을 해 보고 재미가 없으면 방향을 바꾸거나 과감히 접기도 합니다. 이 시점에 포기하는 것이 몇 년 뒤 실패하는 것보다 훨씬 싸기 때문입니다. 이 단계에서는 어떤 게임 엔진을 쓸지, 아트 스타일은 어떻게 갈지, 일정과 인원은 얼마나 필요한지 같은 큰 결정도 함께 내립니다.
프로토타입 이후에는 흔히 퍼스트 플레이어블이나 버티컬 슬라이스를 만듭니다. 게임의 일부분, 예를 들어 한 스테이지만큼을 최종 품질에 가깝게 완성해 보는 것입니다. 이것을 보면 완성품이 어떤 모습일지, 나머지를 만드는 데 얼마나 걸릴지 가늠할 수 있습니다.
3단계: 본 제작(프로덕션)
방향이 정해지면 가장 긴 단계인 본 제작이 시작됩니다. 기획자는 레벨과 수치를 채우고, 프로그래머는 기능을 구현하며, 아티스트는 캐릭터와 배경을 대량으로 만들고, 사운드 팀은 음악과 효과음을 붙입니다.
이 단계의 어려움은 각 분야의 작업이 서로 맞물려 있다는 점입니다. 캐릭터 모델이 나와야 애니메이션을 붙일 수 있고, 시스템이 완성되어야 밸런스를 맞출 수 있습니다. 그래서 대부분의 팀은 짧은 주기로 목표를 정하고 결과를 점검하는 방식으로 일합니다. 매번 실제로 실행 가능한 빌드를 만들어 팀 전체가 같은 상태를 확인하는 것도 중요합니다.
제작 중에도 기획은 계속 바뀝니다. 만들어 보니 재미없는 부분은 빼고, 시간이 부족하면 우선순위가 낮은 기능을 덜어 냅니다. 무엇을 넣을지보다 무엇을 뺄지 결정하는 일이 더 어렵다는 말이 나오는 이유입니다.
4단계: 알파, 베타, 그리고 테스트
개발 진행 상황은 보통 몇 가지 마일스톤으로 구분합니다.
- 알파: 주요 기능이 모두 들어가 처음부터 끝까지 플레이할 수 있는 상태입니다. 그래픽이나 음향은 아직 덜 완성되었을 수 있고, 기능도 테스트 결과에 따라 바뀔 수 있습니다.
- 베타: 기능과 콘텐츠가 모두 들어간 상태로, 이제 새 기능을 넣기보다 버그를 고치는 데 집중합니다.
- 골드 마스터(릴리스 후보): 출시용으로 확정한 최종 빌드입니다. 실물 패키지 시절에는 이 빌드로 디스크를 찍어 냈습니다.
QA 팀은 이 과정 내내 게임을 반복해서 플레이하며 버그를 찾고, 어떻게 하면 다시 일어나는지 정리합니다. 한 부분을 고쳤더니 다른 곳이 망가지는 일도 흔해서, 이미 확인한 부분을 다시 점검하는 회귀 테스트도 중요합니다. 외부 플레이어를 모아 하는 비공개·공개 베타 테스트에서는 버그뿐 아니라 난이도, 서버 부하, 플레이어 반응도 확인합니다.
출시 일정이 다가오면 많은 일이 한꺼번에 몰리면서 장시간 근무, 이른바 크런치가 생기기도 합니다. 업계에서도 오래 문제로 지적되어 왔고, 일정에 여유를 두고 범위를 조절하려는 노력이 이어지고 있습니다.
5단계: 출시 준비와 플랫폼 심사
게임이 완성되었다고 바로 팔 수 있는 것은 아닙니다. 출시하려는 플랫폼과 나라의 절차를 거쳐야 합니다.
- 플랫폼 심사: 콘솔 게임은 제조사의 기술 요구 사항을 통과해야 합니다. 모바일 게임은 애플 앱스토어 심사 지침과 구글 플레이 정책을 지켜야 하고, 위반하면 출시가 거절될 수 있습니다.
- 연령 등급: 나라별 등급 기관이나 IARC 설문을 통해 연령 등급을 받습니다.
- 현지화: 여러 언어로 출시한다면 번역뿐 아니라 문화에 맞게 표현을 다듬는 작업이 필요합니다.
- 상점 페이지와 마케팅: 소개 문구, 스크린샷, 영상, 출시일 공지를 준비합니다.
요즘은 정식 출시 전에 일부 플레이어에게 먼저 파는 앞서 해보기(얼리 액세스)도 흔합니다. 스팀은 2013년 3월 이 프로그램을 시작했고, 이후 많은 인디 게임이 플레이어 의견을 받아 가며 게임을 완성하는 방식을 택했습니다. 모바일 게임은 일부 국가에만 먼저 내놓는 소프트 런칭으로 반응을 살피기도 합니다.
6단계: 출시 이후, 업데이트와 라이브 운영
예전에는 디스크를 찍어 내면 개발이 끝났습니다. 지금은 출시가 끝이 아니라 새로운 시작인 경우가 많습니다. 실제 플레이어 수만 명이 하면 테스트에서 찾지 못한 버그가 나오기 마련이라 출시 직후에는 패치가 이어집니다.
온라인 게임이나 부분 유료화 게임은 출시 후 운영이 개발만큼 중요합니다. 새 콘텐츠와 이벤트를 정기적으로 추가하고, 플레이 데이터를 보고 밸런스를 조정하며, 커뮤니티 의견에 대응합니다. 이렇게 서비스를 계속 이어 가는 방식을 라이브 운영이라고 부릅니다. 반대로 이야기 중심의 게임은 버그 수정과 추가 콘텐츠 몇 개로 마무리하기도 합니다.
정리: 만들고, 시험하고, 고치는 일의 반복
게임 개발 과정을 단계로 나누어 설명했지만, 실제로는 한 방향으로만 흐르지 않습니다. 제작 중에 기획으로 돌아가기도 하고, 베타 테스트 결과를 보고 핵심 시스템을 다시 만들기도 합니다. 결국 게임 개발은 "만들어 보고, 시험해 보고, 고치는 일"을 끝없이 반복하는 과정입니다.
좋아하는 게임의 엔딩 크레디트가 길게 이어지는 것도 이 때문입니다. 다음에 게임을 할 때, 지금 눌러 보는 버튼 하나와 지나가는 화면 하나에도 이런 과정이 쌓여 있다는 점을 떠올려 보면 게임이 조금 다르게 보일 것입니다.