게임 기획서 양식: 한 페이지로 시작하기

게임 기획서 양식은 한 페이지에 들어가야 하고, 게임이 필요로 할 때만 길어져야 해요. 일곱 개 블록으로 시작하세요. 피치, 핵심 루프, 플레이어 동사, 세계관, 시스템, 범위, 열린 질문입니다. 저녁 한 번이면 채울 수 있어요. 이번 달 프로토타입으로 검증할 수 없는 내용은 잘라내세요. 이 글의 나머지는 바로 그 양식과, 대부분의 가이드가 빼먹는 부분이에요.

기획서 대부분이 2주를 못 넘기는 이유는?

40쪽짜리 기획서를 떠올려 보세요. 멋진 표지, 목차, 아무도 요청하지 않은 설정 챕터가 있어요. 2주가 지나면 프로토타입은 방향이 틀어지고, 문서는 화석이 됩니다.

진짜 실패는 빠진 섹션이 아니에요. 더 이상 사실이 아닌 파일이 문제죠. 기획서는 설정집보다 변경 기록에 가까운 작업 도구입니다. 문서와 빌드가 어긋나면 문서가 지고, 사람들은 더 이상 열지 않게 돼요.

그래서 질문을 바꿔야 해요. "게임 기획서에 무엇이 들어가야 할까?"가 아니라 "내가 실제로 계속 정직하게 유지할 수 있는 가장 짧은 문서는 무엇일까?"입니다.

한 페이지짜리 게임 기획서 양식

이 개요를 그대로 복사하세요. 각 블록은 처음에는 두 줄에서 다섯 줄 정도로 씁니다. 처음부터 더 길게 쓰지 마세요.

1. 피치. 낯선 사람도 따라 말할 수 있는 한 문장. "비가 올 때마다 지도가 다시 그려지는 협동 항구 마을."

2. 핵심 루프. 플레이어가 1분 안에 계속 반복하는 행동. 동사들의 원으로 그려 보세요.

3. 플레이어 동사. 5~8개의 행동. 기능이 아니라 동사예요. 오르기, 거래하기, 숨기, 분기하기, 수리하기.

4. 세계관. 장소, 분위기, 언제나 참인 규칙 세 개. 날씨도 규칙이 될 수 있어요.

5. 시스템. 동사를 흥미롭게 만드는 두세 개의 메커니즘. 경제, 잠입, 제작 등 루프를 떠받치는 것.

6. 범위. 무엇을 출시하고, 무엇을 자르고, 무엇을 욕심으로 남길지. 각 항목 옆에 날짜를 적으세요.

7. 열린 질문. 아직 모르는 것들의 솔직한 목록. 이 블록이 페이지에서 가장 가치 있어요.

빠진 항목도 눈여겨보세요. 수익화 계획, 마케팅 계획, 캐릭터 배경 챕터는 없어요. 이것들은 프로토타입이 루프를 증명했을 때 따로 쓰는 파일에 들어갑니다. 시중의 대부분 템플릿은 이것들로 시작하는데, 바로 그래서 그 문서들은 끝까지 완성되지 않아요.

팀의 승인이 필요하다면 GitBook의 게임 기획서 작성 가이드가 고전적인 챕터 목록을 정리해 두었어요. 한 페이지 버전에서 시작해 프로토타입이 입증하는 만큼 세부를 더하라는 조언은 그대로 따를 만합니다.

핵심 루프 섹션에는 무엇을 써야 할까?

형용사는 빼세요. 루프는 타이머가 달린 문장으로 쓰세요.

40초 동안 잔해 수집 -> 부두로 옮기기 -> 업그레이드 하나와 교환 -> 조수가 바뀌고 지도가 변함 -> 반복

소리 내어 읽어 보세요. 한 단계가 죽어 있으면 그게 첫 프로토타입 과제예요. 모든 단계가 괜찮은데 플레이어가 왜 돌아오는지 말할 수 없다면, 루프에 이유가 빠진 겁니다. 문단 속에 묻지 말고 열린 질문으로 옮기세요.

제가 좋아하는 테스트가 하나 있어요. 루프 문장은 한 줄에 들어가야 해요. 문단이 필요하다면 루프가 둘이고, 지금 게임도 둘을 설계하는 중입니다.

과감하게 빼도 되는 섹션은 무엇일까?

과감해지세요. 혼자 또는 둘이서 하는 프로젝트라면 첫날부터 아래 항목을 뺄 수 있어요.

• 캐릭터 상세 바이오. 이름, 욕구, 결점 하나만 남기세요. 빌드에 등장할 때 더 쓰면 돼요.

• 레벨 상세 묘사. 방이 아니라 레벨의 규칙을 적으세요.

• 플랫폼과 수익화 챕터. 루프가 작동할 때까지 보류하세요.

• 아트 바이블. 참고 이미지 세 장과 팔레트면 충분해요.

72시간 안에 잼 게임을 출시한다면 피치, 루프, 동사가 문서 전체입니다. 퍼블리셔가 있거나, 콘솔 인증 절차가 있거나, 한밤중에 질문을 받을 수 없는 외주 팀원이 있다면 전체 목록을 유지하는 편이 낫습니다.

Unity 게임 기획서 양식 PDF는 팀이 생기면 메카닉과 오브젝트 동작을 어떻게 적는지 보기 좋은 참고 자료예요. 체크리스트가 아니라 카탈로그로 읽으세요.

문서는 어디에 두고, 엔진은 무엇을 바꾸나?

매일 편집하는 곳에 두세요. 당연해 보이지만, 아무도 변경 이력을 볼 수 없는 PDF에 기획서가 갇혀 있는 경우가 얼마나 많은지 보면 놀라워요.

제목, 작업용 데이터베이스, 버전 기록을 제공하는 도구를 고르세요. 열린 질문과 범위 목록이 메모의 글머리 기호가 아니라 추적되는 항목이 될 수 있으니, 데이터베이스 기반 노트 앱이 잘 맞아요.

저장소 안의 일반 마크다운도 좋은 답이에요. 코드 곁에 있고, 변경 비교가 깔끔하며, 풀 리퀘스트 때 업데이트를 잊기 어려워요. 단점은 기획을 맡지 않은 팀원이 건드리지 않는다는 점이에요.

어떤 걸 고르든 한 페이지 요약을 맨 위에 두고 더 깊은 파일로 링크하세요. 페이지는 지도이고, 파일은 영토예요.

엔진은 조금 바꿉니다. 엔진이 어떤 동사가 저렴하고 어떤 동사가 비싼지 정하니까, 시스템과 범위 블록에 그걸 분명히 적어야 해요.

완전한 3D 엔진에 대형 에셋 파이프라인을 쓴다면, 범위에는 에셋 카테고리마다 한 줄씩 필요해요. 콘텐츠는 일정이 죽는 곳이니까요.

로열티 계산을 따로 할 필요가 없는 오픈소스 엔진을 쓴다면 범위 블록은 더 단순해집니다. 라이선스 줄은 없어도, 직접 만들 기능이 무엇인지에 대한 솔직한 메모가 필요해요.

2D에 촘촘한 메카닉이라면 루프 섹션이 거의 모든 걸 담아요. 작고 읽기 쉬운 게임에는 작고 읽기 쉬운 문서가 어울립니다.

여기서 승자를 고르는 게 목적은 아니에요. "엔진과 도구"는 버릴 한 줄이 아니라는 게 핵심이에요. 엔진이 쉽게 만드는 것, 힘들게 만드는 것, 그리고 절대 만들지 않을 것을 적어야 합니다.

스스로 만들어지는 세계의 기획서는 어떻게 쓸까?

대부분의 템플릿에서 빠진 부분이 바로 이 지점이에요. 모든 나무를 손으로 배치한다고 가정하니까요.

프롬프트로 세계가 만들어지면 기획서의 모양이 바뀝니다. 방을 명세하는 게 아니라 제약을 명세하게 돼요. 엔진이 만들 수 있는 모든 세계에서 반드시 참이어야 하는 것과, 달라도 되는 것이 무엇인지 적는 거예요.

한 페이지 요약에 블록 두 개를 더하세요.

• 세계 제약. 절대 깨지면 안 되는 규칙. "모든 정착지에서 2분 안에 물에 닿을 수 있다." "막다른 퀘스트 위치는 없다."

• 프롬프트 씨앗. 실제로 쓴 정확한 프롬프트를 문서의 일부로 저장하세요.

씨앗은 이렇게 생겼어요.

안개 낀 항구 마을, 썰물 때, 등대 하나, 좁은 계단, 지붕 사이를 잇는 밧줄 다리, 아직 아무도 없음

프롬프트를 저장하고, 나온 결과도 저장하고, 무엇을 분기할지 메모하세요. 프롬프트는 명세이자 변경 기록입니다. 하나만 바꿔서 분기하고, 무슨 일이 생기는지 본 다음, 그 차이를 문서에 적으세요. 이 습관이 생성된 세계를 논리적으로 다룰 수 있게 만들고, 팀원에게 막연한 느낌이 아니라 비판할 구체적인 대상을 줍니다.

주의할 점도 있어요. 생성 품질은 도구마다 크게 다르고, 일부 기능은 업계 전체에서 아직 베타예요. 씨앗마다 도구 버전과 날짜를 함께 적으세요. 그래야 결과가 반복 가능한지, 운 좋게 나온 결과인지 알 수 있어요.

더 쓰기 전에 루프를 검증하는 빠른 방법

새 아이디어에 제가 실제로 돌려 보는 저녁 워크플로우예요.

1. 한 페이지 요약을 30분 안에 쓰세요. 그리고 고치지 마세요.

2. 피치와 세계 규칙 세 개를 프롬프트로 바꿔서, 공간의 첫 번째 결과물을 생성하세요.

3. 그 공간에서 핵심 루프를 손으로, 혹은 러프한 프로토타입으로 따라가 보세요.

4. 죽은 느낌이 든 모든 단계를 표시하세요. 그것들은 열린 질문으로 들어갑니다.

5. 동사 하나를 잘라내세요. 언제나 하나는 잘라내세요.

사람들이 가장 자주 건너뛰는 부분이 바로 이 자르기예요. 늘어나기만 하는 기획서는 희망 목록일 뿐입니다. 동사 하나를 빼면 남은 동사들이 더 많은 무게를 져야 하고, 실제로 일을 하던 시스템이 무엇인지 드러나요.

2주 뒤에도 문서를 살아 있게 두려면?

세 가지 습관이면 충분해요. 영웅적일 필요는 없어요.

열린 질문에 날짜를 붙이세요. 질문이 3주가 넘었는데 아직 열려 있다면 답하거나, 피하고 있다는 걸 인정하세요.

빌드와 같은 자리에서 문서를 고치세요. 나중에 고치면 화석이 생겨요. 세션 끝에 두 줄 고치는 건 1분이면 돼요.

맨 아래에 "버린 아이디어" 목록을 두세요. 같은 메카닉을 매달 다시 토론하지 않게 해 주고, 안 하겠다고 말한 만큼 실제로 얼마나 많이 출시했는지 보는 것도 묘하게 힘이 돼요.

새 사람이 프로젝트에 들어오면 한 페이지 버전부터 건네고, 어디서 헷갈리는지 지켜보세요. 헷갈리는 질문 하나하나가 문서에서 빠진 한 줄이에요.

그래서 저라면 무엇을 쓸까요? 혼자이거나 둘이라면 한 페이지 요약과 프롬프트 씨앗 목록이면 첫 달은 충분해요. 팀이라면 한 페이지를 현관으로 두고, 프로토타입이 정당화할 때 시스템과 콘텐츠용 파일을 따로 추가하세요. 퍼블리셔가 있다면 긴 버전을 주되, 신뢰하는 버전은 한 페이지짜리로 남겨 두세요.

오늘 밤 빈 페이지를 열고 피치를 쓰세요. 한 문장이면 됩니다. 그다음 타이머를 단 루프를 쓰세요. 30분 안에 끝나지 않는다면 아이디어는 아직 꿈이에요. 한 달을 쓰기 전에 그걸 아는 것도 쓸모가 있어요.