게임아카데미게임·웹툰·AI 진로 상담
기획서는 길게 쓴다고 좋은 문서가 아닙니다. 프로그래머가 읽고 질문 없이 구현할 수 있고, 그래픽 팀이 필요한 리소스 목록을 바로 뽑을 수 있어야 합니다. 수…
프로토타입은 '되는지 보는' 시험품입니다
프로토타입은 팀 안에서 질문 하나에 답하려고 만듭니다. '이 점프 조작이 손맛이 있을까', '카드를 뒤집는 규칙이 이해하기 쉬울까' 같은 질문입니다. 그래서 그래픽은 네모 상자와 동그라미로 대신하고, 메뉴나 저장 기능도 없는 경우가 많습니다.
요리에 비유하면 메뉴를 내기 전에 주방에서 소스 맛만 따로 보는 것과 같습니다. 접시 장식이나 가게 인테리어는 아직 신경 쓰지 않습니다. 맛이 없다는 결론이 나오면 미련 없이 버리고 다른 소스를 시험합니다. 프로토타입의 가치는 완성도가 아니라 빠르게 버릴 수 있다는 데 있습니다.
형태도 다양합니다. 종이와 주사위로 규칙만 시험하는 종이 프로토타입, 엔진에서 조작감만 확인하는 디지털 프로토타입, 화면 흐름만 클릭해 볼 수 있게 만든 UI 프로토타입이 있습니다. 확인하려는 질문에 맞는 가장 싼 방법을 고르는 것이 요령입니다.
MVP는 '팔릴지 보는' 최소 제품입니다
MVP는 Minimum Viable Product의 약자로, 우리말로는 최소 기능 제품이라고 부릅니다. 프로토타입이 팀 내부 확인용이라면, MVP는 실제 유저가 내려받아 플레이하는 제품입니다. 핵심 재미 하나를 중심으로 꼭 필요한 기능만 담아 시장에 내놓고 반응을 봅니다.
여기서 '최소'는 대충 만든다는 뜻이 아닙니다. 기능 수는 적어도, 들어간 기능은 유저가 불편 없이 쓸 수 있을 만큼 다듬어져 있어야 합니다. 버그투성이 MVP를 내면 유저가 재미가 없어서 떠났는지, 불편해서 떠났는지 구분할 수 없기 때문입니다.
인디 게임이나 모바일 게임에서는 일부 지역에만 먼저 출시하는 소프트 런칭이나 앞서 해보기 형태로 MVP를 공개하는 경우가 있습니다. 유저가 얼마나 오래 플레이하는지, 어디서 그만두는지를 보고 다음 개발 방향을 정합니다.
한눈에 보는 프로토타입과 MVP의 차이
| 기준 | 프로토타입 | MVP |
|---|---|---|
| 확인하려는 것 | 재미있는가, 만들 수 있는가 | 유저가 찾고 계속 쓰는가 |
| 보여 주는 대상 | 팀원, 소수 테스터 | 실제 유저 |
| 완성도 | 임시 그래픽, 기능 일부만 | 핵심 기능은 다듬어진 상태 |
| 수명 | 확인 후 버리는 경우가 많음 | 이후 업데이트로 이어짐 |
| 실패했을 때 | 다른 아이디어로 빠르게 교체 | 방향 수정 또는 개발 중단 판단 |
흐름으로 보면 보통 여러 개의 프로토타입으로 아이디어를 거른 뒤, 살아남은 아이디어로 MVP를 만듭니다. 순서를 거꾸로 하면 확인되지 않은 재미에 많은 시간과 돈을 쓰게 됩니다. 반대로 프로토타입만 끝없이 만들고 MVP로 넘어가지 못하는 것도 문제입니다. 팀 안의 반응과 실제 유저의 반응은 다를 수 있어서, 어느 시점에는 밖으로 내놓고 확인해야 합니다.
게임 기획자가 두 개념을 쓰는 장면
기획자는 프로토타입 단계에서 '무엇을 확인할지'를 정하는 역할을 맡습니다. 확인 질문, 성공 기준, 테스트 방법을 짧은 문서로 정리하면 프로그래머가 필요한 것만 빠르게 만들 수 있습니다. 질문 없이 만든 프로토타입은 다 만들고 나서도 무엇을 알게 됐는지 말하기 어렵습니다.
MVP 단계에서는 '무엇을 빼야 할지'를 결정하는 일이 중요해집니다. 하고 싶은 기능은 늘 많지만, 핵심 재미와 직접 관련 없는 기능은 다음 업데이트로 미룹니다. 이때 기능마다 핵심 재미와의 관계를 설명할 수 있어야 팀을 설득할 수 있습니다.
신입 기획 포트폴리오에서도 이 개념은 쓸모가 있습니다. 완성 기획서만 보여 주기보다, 직접 만든 간단한 프로토타입과 그것으로 무엇을 확인했고 어떻게 고쳤는지 정리해 두면 검증할 줄 아는 기획자라는 인상을 줍니다.
작은 아이디어로 직접 해 보는 검증 순서
- 아이디어를 한 문장으로 적고, 그중 가장 불확실한 부분을 고릅니다.
- 그 부분을 질문 형태로 바꾸고, 어떤 반응이 나오면 성공인지 미리 정합니다.
- 질문에 답할 수 있는 가장 싼 방법으로 프로토타입을 만듭니다.
- 다른 사람에게 설명 없이 시켜 보고, 막히는 지점과 표정을 기록합니다.
- 결과를 보고 유지, 수정, 폐기 중 하나를 고릅니다.
- 살아남은 아이디어로 MVP에 꼭 들어갈 기능 목록을 짧게 추립니다.
두 번째 단계에서 성공 기준을 미리 정하는 것이 중요합니다. 테스트가 끝난 뒤에 기준을 정하면 아이디어가 아까워 결과를 좋게 해석하기 쉽습니다. '열 명 중 대부분이 설명 없이 규칙을 이해한다'처럼 확인 가능한 문장으로 적어 두세요.
네 번째 단계에서는 옆에서 설명하고 싶은 마음을 참아야 합니다. 실제 유저는 기획자의 설명을 듣지 못합니다. 테스터가 헤매는 모습 자체가 가장 값진 결과입니다.
처음 배울 때 헷갈리는 점
첫째, 프로토타입을 너무 공들여 만드는 경우입니다. 그래픽을 예쁘게 다듬기 시작하면 결과가 나빠도 버리기 아까워집니다. 확인할 질문에 필요 없는 부분은 일부러 거칠게 두는 편이 좋습니다.
둘째, MVP를 '데모'와 같은 것으로 보는 경우입니다. 데모는 보여 주기 위한 일부 구간이고, MVP는 유저가 실제로 계속 쓸 수 있는 제품입니다. 게임 행사에서 보여 주는 짧은 시연판은 MVP라기보다 홍보용 데모에 가깝습니다.
셋째, 코딩을 못 하면 프로토타입을 만들 수 없다는 생각입니다. 종이 카드, 보드게임 말, 슬라이드 클릭 화면으로도 많은 질문에 답할 수 있습니다. 엔진을 다룰 수 있으면 더 좋지만, 확인하는 습관이 먼저입니다.
지금 가진 게임 아이디어가 있다면 확인하고 싶은 질문 하나만 정해 종이로 먼저 시험해 보세요. 질문을 고르고 결과를 문서로 정리하는 과정을 연습하고 싶다면, SBS아카데미게임학원 게임기획 과정 상담에서 아이디어를 검증 계획으로 바꾸는 방법을 이야기해 보실 수 있습니다.
자주 묻는 질문
버티컬 슬라이스는 프로토타입과 같은 말인가요?
다릅니다. 버티컬 슬라이스는 게임의 짧은 구간을 최종 품질에 가깝게 만들어 완성된 모습을 미리 보여 주는 것으로, 투자나 내부 승인용으로 많이 씁니다.
프로토타입은 보통 얼마나 걸려 만드나요?
확인하려는 질문에 따라 다르며, 몇 시간짜리 종이 프로토타입부터 몇 주 걸리는 디지털 프로토타입까지 폭이 넓습니다. 짧게 끝낼수록 더 많은 아이디어를 시험할 수 있습니다.
가까운 캠퍼스에서 게임기획 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.