게임 디자인 문서 템플릿: 한 페이지에서 시작하는 법

게임 디자인 문서 템플릿은 처음엔 한 페이지로 시작하고, 게임이 그만큼의 분량을 얻어냈을 때만 늘리는 편이 좋아요. 시작은 다섯 개 블록이면 충분해요. 기획 요약, 디자인 필러, 핵심 루프, 시스템 목록, 미해결 질문이죠. 로어부터 레벨 메모까지는 플레이테스트가 메커니즘이 실제로 작동한다고 증명한 뒤에 추가하세요. 아래는 테이블 RPG와 인디 비디오 게임 프로젝트에서 쓰는 방식이고, 각 섹션이 어디서 썩기 쉬운지도 함께 적었어요.

왜 대부분의 게임 디자인 문서는 3주를 못 넘길까?

실패의 원인은 대개 욕심이에요. 빈 파일을 열고, 포럼에서 본 20개 섹션짜리 목차를 그대로 붙여 넣고, 아직 한 번도 테스트하지 않은 메커니즘 칸을 주말 내내 채우죠. 3주차가 되면 게임은 이미 방향이 바뀌었는데 문서는 그대로예요. 아무도 문서를 열지 않고, 아무도 그걸 인정하지 않아요.

Game Dev Beginner의 GDD 가이드도 문제를 분명하게 짚어요. 지나치게 상세한 대형 문서는 초기 작업 부담이 크고, 거의 항상 낡아 있으며, 디자인이 아직 흔들리는 단계에서는 발목을 잡는다는 거예요. 해결책은 단계를 나누는 것입니다. 처음엔 한 페이지, 게임 형태가 잡히면 열 페이지, 콘텐츠를 실제로 만들 때 전체 버전을 쓰라고 권해요.

테이블 RPG 디자이너에게는 이 단계 나누기가 비디오 게임 팀보다 더 중요해요. 혼자서 작가, 시스템 담당, 플레이테스터 역할을 함께 맡는 경우가 많고, 명세서를 기다리는 엔지니어도 없으니까요. 그래서 문서가 해야 할 일은 하나예요. 4회차 세션과 40회차 세션 사이에서 나 자신과 모순되지 않도록 붙잡아 주는 것.

혼자 작업한다면 40페이지짜리 템플릿은 건너뛰세요. 어차피 유지하지 못해요. 게임 디자인 문서의 표준 정의도 GDD를 살아 있는 문서라고 부르는데, 첫날부터 완성될 거라고 기대하지 않는다는 뜻이에요.

사람들이 실제로 여는 게임 디자인 문서 템플릿에는 무엇이 들어갈까?

한 달 정도의 초기 작업은 거의 모든 프로젝트에서 이 다섯 블록으로 충분해요. 각 블록은 2분이면 한 페이지를 다 읽을 수 있을 만큼 짧게 유지하세요.

1. 기획 요약. 두 문장. 누가 플레이하고, 무엇을 하며, 이미 가진 게임과 무엇이 다른지.

2. 디자인 필러. 세 개에서 네 개의 문장. 이후의 모든 결정이 이 기준에 비춰 검증돼요. "모든 전투는 무언가를 영구히 잃게 만든다"는 필러예요. "재미있고 몰입감 있게"는 필러가 아니에요.

3. 핵심 루프. 플레이어가 반복하는 행동. 던전 크롤이라면 탐험, 선택, 위험 감수, 소모일 수 있어요. 정치 캠페인이라면 음모, 영향력, 결과, 여파가 될 수 있고요.

4. 시스템 목록. 이름과 한 줄 설명만. 아직 숫자는 적지 마세요.

5. 미해결 질문. 이 페이지에서 가장 쓸모 있는 섹션인데, 대부분의 템플릿에서 빠져 있어요. 아직 모르는 것을 적고, 날짜를 붙이세요.

맨 아래에는 변경 기록도 넣으세요. 일주일에 한 줄이라도 괜찮아요. 플레이테스트에서 아이디어가 죽었다면, 죽였다는 사실과 이유를 기록하세요. 그러지 않으면 미래의 나는 같은 아이디어를 또 시도할 거예요.

반박할 수 있는 디자인 필러는 어떻게 쓸까?

필러는 무언가를 거부할 수 있을 때만 제 역할을 해요. 이 필러가 거절할 기능을 하나도 떠올릴 수 없다면, 그건 장식이에요.

컷 리스트로 필러를 시험해 보세요. 가장 아끼는 기능 세 개를 골라 각각이 어떤 필러를 위해 존재하는지 물어보는 거예요. 어떤 필러도 위하지 않는 기능은 "나중에" 목록으로 옮기고, 그 목록은 길어져도 괜찮아요. 이 시간이 전체 과정에서 가장 힘든 한 시간이지만, 어떤 템플릿 섹션보다 가치가 커요.

예를 하나 들어볼게요. 중심에 역병이 있는 캠페인 설정이에요. 필러 1: 자원 부족은 눈에 보여야 한다. 그래서 모든 치료 자원을 테이블 위에서 추적한다. 필러 2: 세력마다 원하는 치료법이 달라서, 어떤 단일 치료도 모든 문제를 해결하지 못한다. 필러 3: 지도가 줄어들어서, 이야기가 진행될수록 이동 비용이 올라간다. 이제 부활 주문 제안이 들어왔다고 해요. 필러 1이 이 제안을 거부합니다. 40분짜리 토론 대신 10초 만에 결정이 나요.

참고로 필러는 마케팅 문구가 아니에요. 내부용이라 날카롭고, 어느 정도 불편하게 들릴 수도 있어요. 그래도 괜찮아요.

로어는 GDD의 어디에 두고, 어디서 방해가 될까?

로어는 가장 빨리 자라고 가장 적게 읽히는 섹션이에요. 대부분의 문서는 로어를 맨 아래 "스토리" 제목 밑에 묻어 두거나, 문서 전체를 집어삼키게 내버려 둬요. 둘 다 잘 안 돼요.

로어를 무슨 역할을 하는지에 따라 나누세요. 세력의 원한이 퀘스트를 열거나 직업을 규정하는 저주처럼 플레이를 바꾸는 로어는 그 로어가 영향을 주는 시스템 안에 두세요. 분위기만 만드는 로어는 별도의 Codex 페이지에 두면 됩니다. 디자인 결정을 내릴 때 그 페이지를 열 필요가 없는 식으로요. 판별법은 간단해요. 이 단락을 지워도 메커니즘, 주사위 굴림, 플레이어의 선택이 하나도 안 바뀐다면, 그건 Codex에 속해요.

이렇게 나누면 설정의 정합성도 지킬 수 있어요. 같은 사실이 두 곳에 있으면 결국 어긋나요. 사실마다 집을 하나만 정하고, 나머지 곳에서는 그 집으로 링크를 거세요. 설정의 정합성은 약속이고, 모순 하나가 그 약속을 깨뜨려요.

서사 중심 게임을 만드는 디자이너들은 짧은 연표 페이지와 "누가 무엇을 아는가" 목록을 함께 두는 경우가 많아요. 둘 다 만드는 데 비용이 적고, 후반의 반전이 제대로 먹히도록 다시 손보는 데 드는 시간을 아껴 줘요.

템플릿을 Notion, Obsidian, 일반 문서 중 어디에 둘까?

도구보다 중요한 건 문서가 이미 쓰고 있는 작업 공간에 있느냐예요. 한 번도 열지 않는 탭에 있는 문서는 죽은 문서예요.

소규모 팀에게는 Notion이 기본 선택이에요. 페이지끼리 링크가 걸리고, 데이터베이스로 아이템과 세력을 관리할 수 있고, 협업자가 따로 설정할 필요도 없으니까요. 컨트롤, 게임 루프, 레벨 디자인, 규칙 섹션이 갖춰진 Notion의 GDD 템플릿도 있어요. 단점은 특정 도구에 묶이는 것과, 굳이 데이터베이스가 필요 없는 것까지 데이터베이스로 만들고 싶어지는 유혹이에요.

Obsidian은 순수 Markdown 파일을 내 컴퓨터에 두고 싶은 1인 디자이너에게 맞아요. 백링크가 실제로 일을 해요. 세력을 등장하는 모든 장면에 링크해 두면, 설정 정합성 검사를 공짜로 얻는 셈이죠. 프로젝트가 몇 년 이어져도 특정 서비스가 사라지는 상황에 덜 흔들려요.

GitBook은 문서를 공개하거나 반공개로 열어야 할 때 좋아요. 플레이테스트 그룹이나 크라우드펀딩 후원자 페이지가 그런 경우예요. 게임 잼이라면 평범한 Google 문서도 충분해요. 권한 체계가 복잡한 도구는 퍼블리셔가 요구하지 않는 한 피하세요.

무엇을 고르든 규칙은 하나만 정하세요. 모든 플레이테스트가 끝나면, 집에 가기 전에 문서를 업데이트합니다. 10분이면 돼요. 예외는 없어요.

프로토타입이 플레이테스트를 버티면 무엇을 더할까?

실제 플레이어와 서너 번 세션을 거치고 나면, 한 페이지짜리 문서가 다음 층을 가질 자격이 생겨요. 아래 순서로, 고통이 실제로 드러날 때만 추가하세요.

시스템 상세. 숫자, 표, 예외 상황. 시스템을 확정할 때 함께 적고, 그 전에 미리 쓰지 마세요. 테이블 RPG라면 행동 경제, 피해 범위, 자원 소모와 실제 규칙 문장이 여기에 들어가요. 비디오 게임이라면 엔지니어가 읽을 데이터 테이블을 넣으세요.

콘텐츠 목록. 아이템, 적, 세력, 장소. 항목마다 한 줄씩 있는 표를 쓰고, 각 항목이 어떤 필러를 위해 존재하는지 열을 하나 두세요. 아무 필러도 위하지 않는 행은 잘라낼 후보예요.

인터페이스와 흐름. 테이블 RPG라면 캐릭터 시트 배치, 디지털이라면 화면 흐름이에요. 글로 설명하기 전에 손으로 먼저 스케치해 보세요.

제작 노트. 마일스톤, 범위, 위험 요소, 첫 출시에 들어가는 것과 빠지는 것. DriveThruRPG나 Itch.io에서 판매할 계획이라면, 페이지 문구와 가격 가정도 여기서 시작돼요.

기획 요약이나 마케팅 섹션은 다른 독자를 위한 별도 문서예요. 퍼블리셔와 후원자는 시장 맥락과 차별점을 원하고, 플레이테스터는 규칙을 원하죠. 한 파일에 섞으면 어느 쪽에도 쓸모없는 파일이 돼요.

AI가 게임 디자인 문서를 도와줄 수 있을까, 어디서 부족할까?

지루한 부분의 초안에는 도움이 되고, 중요한 부분에서는 부족해요. 시스템 목록을 엣지 케이스 표로 늘려 달라고 하면 1분 만에 쓸 만한 첫 초안이 나와요. 필러를 골라 달라고 하면 다른 게임들과 똑같이 들리는 필러가 나오죠. 생성은 빠르지만, 결정에는 사람의 검토가 필요해요.

실용적인 쓰임새는 일관성 검사예요. Codex와 시스템 목록을 함께 넣고, 두 페이지가 어디서 서로 모순되는지 물어보세요. Novelcrafter처럼 긴 호흡의 스토리 바이블을 위해 만들어진 도구는 이런 교차 확인에 맞게 설계돼 있어요. 결과는 판결이 아니라 용의자 목록으로 받아들이고, 표시된 항목마다 직접 페이지를 확인하세요.

지켜야 할 원칙이 하나 있어요. 미해결 질문 섹션은 모델에게 맡기지 마세요. 그 페이지는 내가 무엇을 모르는지에 대한 솔직한 목록이고, 넘기는 순간 의미가 사라집니다.

무엇을 건너뛰고 무엇을 남겨야 할까?

긴 템플릿은 메커니즘이 실제 세션을 최소 세 번 버틸 때까지 건너뛰세요. 실제 플레이어 다섯 명을 떠올릴 수 없다면 "대상 독자" 에세이도 건너뛰세요. 루프를 찾지 못한 게임에 수익화 섹션을 깊게 쓰는 것도 건너뛰세요. 동료에게 소리 내어 읽어 줄 상상이 안 되는 섹션은 모두 건너뛰세요.

남길 것은 필러, 미해결 질문, 변경 기록이에요. 이 세 가지가 거의 모든 일을 해요. 이것만 있는 문서라도 매주 업데이트되면, 3월 이후 아무도 열어보지 않은 30페이지짜리 완성본보다 낫습니다.

템플릿은 무엇을 왜 결정했는지에 대한 미래의 나와의 약속이에요. 그 약속을 지킬 수 있을 만큼 짧게 유지하세요.