게임기획은 시스템, 레벨, 콘텐츠, 밸런스처럼 세부 직무가 나뉘어 있어 처음에는 어디로 가야 할지 헷갈립니다. 입문 단계에서 각 분야 문서를 한 번씩 써 보고…
프로토타입이 기획자에게 왜 중요해졌을까
프로토타입은 기획의 핵심 재미가 실제로 작동하는지 확인하기 위해 빠르게 만든 시험판입니다. 그래픽이나 완성도는 신경 쓰지 않고, 규칙 하나가 재미있는지만 확인합니다. 문서로는 그럴듯해 보이던 아이디어가 막상 해 보면 지루하거나, 반대로 별것 아닌 규칙이 의외로 재미있는 경우가 많기 때문에 개발 초기에 자주 활용됩니다.
최근에는 엔진과 도구가 쉬워지면서 기획자가 직접 간단한 프로토타입을 만드는 경우가 늘었습니다. 프로그래머의 시간을 빌리지 않고도 아이디어를 시험해 볼 수 있으니 회의가 빨라지고, 말로 설득하는 대신 플레이로 보여 줄 수 있습니다. 이런 흐름 때문에 채용 공고의 우대 사항에 엔진 활용 경험이 들어가는 경우도 보입니다.
프로토타입이 없어도 불리하지 않은 경우
모든 기획 분야가 프로토타입을 똑같이 요구하지는 않습니다. 라이브 서비스 중인 게임의 콘텐츠 기획, 밸런스 기획, 시나리오 기획처럼 기존 구조 위에서 일하는 분야는 엑셀과 문서 작성 능력이 더 중요하게 평가되는 경우가 많습니다. 이미 만들어진 시스템에 새 콘텐츠를 채우는 일에서는 프로토타입보다 데이터 정확성과 일정 관리가 핵심입니다.
또 규모가 큰 회사는 역할이 잘게 나뉘어 있어 프로토타입 제작을 별도 인력이 맡기도 합니다. 이런 곳에서는 기획자가 직접 만드는 능력보다, 프로토타입 담당자에게 무엇을 검증하고 싶은지 정확히 전달하는 능력이 더 필요합니다. 그러니 프로토타입을 못 만든다고 해서 지원 자체를 포기할 이유는 없습니다. 지원하려는 팀이 어떤 단계의 프로젝트를 하는지, 공고에 엔진 관련 요건이 있는지만 확인해도 준비의 무게를 정할 수 있습니다.
프로토타입이 없으면 불리해지는 경우
반면 신작 개발 초기 팀, 작은 규모의 스튜디오, 레벨 디자인 직무에서는 직접 만들어 보는 능력이 큰 차이를 만듭니다. 사람이 적은 팀에서는 기획자가 아이디어를 스스로 검증해 오기를 기대하는 경우가 많고, 레벨 디자이너는 엔진에서 공간을 직접 배치하는 것이 업무의 일부입니다.
- 새 게임의 핵심 재미를 찾는 초기 개발 팀
- 기획자가 여러 역할을 겸하는 작은 스튜디오나 인디 팀
- 엔진 작업이 기본인 레벨 디자인 직무
- 전투 감각이나 조작감처럼 문서로 설명하기 어려운 영역을 다루는 직무
특히 마지막 항목이 중요합니다. 공격이 맞았을 때의 느낌, 점프의 높이와 체공 시간처럼 손으로 느껴야 하는 요소는 문서만으로 전달하기 어렵습니다. 이런 분야를 지망한다면 간단한 프로토타입으로 감각을 보여 줄 수 있어야 경쟁력이 생깁니다.
엔진을 몰라도 시작할 수 있는 검증 방법
프로토타입이 반드시 게임 엔진으로 만든 실행 파일일 필요는 없습니다. 핵심 규칙이 재미있는지 확인하는 것이 목적이라면, 더 쉬운 방법부터 시작해도 충분합니다.
- 종이 프로토타입: 카드, 주사위, 말로 규칙을 만들어 친구와 직접 해 보기
- 엑셀 시뮬레이션: 전투나 성장 규칙을 수식으로 만들어 결과 확인하기
- 화면 흐름 프로토타입: UI 디자인 도구로 버튼을 눌러 화면이 넘어가는 흐름 만들기
- 엔진 기본 프로토타입: 튜토리얼 수준의 기능으로 핵심 규칙 하나만 구현하기
종이 프로토타입은 의외로 강력합니다. 턴 구조, 자원 관리, 카드 조합 같은 규칙은 종이로도 재미를 검증할 수 있고, 친구들과 해 보며 나온 반응을 기록하면 그대로 포트폴리오 자료가 됩니다. 이 단계에서 익숙해지면 엑셀, UI 도구, 엔진 순으로 범위를 넓혀 가면 됩니다. 어느 방법이든 '한 번에 하나의 질문만 확인한다'는 원칙을 지키면 작업이 커지지 않습니다.
포트폴리오에서 프로토타입을 보여 주는 방법
프로토타입을 만들었다면 결과물만 보여 주기보다 '무엇을 검증하려 했고, 무엇을 알게 됐는가'를 함께 정리해야 합니다. 평가자가 보고 싶은 것은 화려한 결과물이 아니라 기획자가 가설을 세우고 확인하는 방식입니다.
좋은 정리 방식은 짧습니다. 검증하려던 질문 한 줄, 만든 방법과 범위, 테스트한 결과, 그 결과 바뀐 기획 내용을 순서대로 적고 짧은 플레이 영상을 덧붙이면 됩니다. 실패한 프로토타입도 괜찮습니다. '이 규칙은 생각보다 재미가 없어서 이렇게 바꿨다'는 기록은 오히려 기획자의 판단력을 잘 보여 줍니다.
영상은 길 필요가 없습니다. 핵심 규칙이 작동하는 장면만 짧게 담고, 화면에 무엇을 보고 있는지 한 줄 설명을 붙이면 충분합니다. 평가자가 실행 파일을 직접 내려받아 실행하는 경우는 드물기 때문에, 영상과 요약만으로 이해되도록 구성하는 것이 좋습니다. 실행 파일을 함께 제공한다면 실행 방법과 조작 키를 간단히 안내해 두어야 합니다.
문서 실력이 먼저, 프로토타입은 그다음입니다
프로토타입이 유리한 것은 맞지만, 문서 실력이 부족한 상태에서 프로토타입부터 만들면 순서가 뒤집힙니다. 무엇을 검증할지 문서로 정리하지 못하면 프로토타입도 방향을 잃기 쉽습니다. 먼저 기획서를 탄탄하게 쓰고, 그 기획서의 핵심 규칙 하나를 프로토타입으로 확인하는 흐름이 가장 자연스럽습니다.
지금 쓴 기획서에서 어떤 부분을 프로토타입으로 확인하면 좋을지, 어떤 도구부터 익히면 될지 막막하다면 SBS아카데미게임학원 게임기획 과정 상담에서 기획 문서와 Unity 기능 구현을 어떤 순서로 연결할지 함께 정리해 볼 수 있습니다.
자주 묻는 질문
프로토타입은 어느 엔진으로 만드는 게 좋나요?
지원하려는 회사가 주로 쓰는 엔진을 고르는 것이 실용적입니다. 처음이라면 자료가 많은 엔진의 기본 튜토리얼부터 시작하면 됩니다.
AI 도구로 만든 프로토타입도 포트폴리오에 넣어도 되나요?
넣을 수 있지만 도구를 썼다는 사실과 내가 설계한 부분을 분명히 밝히는 것이 좋습니다. 평가자는 결과물보다 검증 과정과 판단을 봅니다.
가까운 캠퍼스에서 게임기획 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.