게임 디자인 도큐먼트(GDD) 마인드맵
인디 개발자에게 100페이지 GDD는 사치입니다. 설계 의도를 한 화면에 응축하는 GDD 마인드맵을 정리했습니다.
인디 게임 개발자에게 100페이지 GDD는 사치입니다. 핵심은 설계 의도를 한 화면에 응축하는 것. 마인드맵 GDD가 가장 효율적인 답입니다.
"게임 GDD" 마인드맵의 1단계 가지 구조 예시 — 중심 주제에서 핵심 카테고리를 방사형으로 펼친 뒤 각 가지에 세부 항목을 추가합니다.
1. 핵심 루프(Core Loop)를 중심에
모든 게임은 핵심 루프에서 시작됩니다. "행동 → 보상 → 강화"라는 한 사이클을 중심 노드에 적고, 이 루프가 30초·5분·30분 단위에서 어떻게 변주되는지를 가지로 펼칩니다.
예를 들어 로그라이크라면 30초 루프는 "공격 → 적 처치 → 골드 획득", 5분 루프는 "스테이지 클리어 → 아이템 선택 → 빌드 강화", 30분 루프는 "런 완료 → 메타 화폐 → 캐릭터 잠금 해제"입니다. 세 층위가 모두 가지로 시각화되어 있어야 디자이너·기획자가 "어느 층위의 보상이 약한가"를 회의에서 즉시 짚을 수 있습니다. Hades, Slay the Spire, Vampire Survivors 같은 레퍼런스 게임의 30초/5분/30분 루프를 옆 가지에 적어두면 비교 분석도 한 장에서 끝납니다. 빈 가지가 있는 층위가 곧 설계 구멍입니다.
2. 시스템 가지
전투, 성장, 경제, 사회 등 게임의 시스템을 1단계 가지로 두고, 각 시스템 아래에 핵심 규칙을 적습니다. 시스템 간 의존성은 색으로 표시합니다.
의존성 색은 빨강(강한 의존)·노랑(부분 의존)·회색(독립)으로 통일하세요. 전투 시스템이 경제 시스템에 빨강으로 묶여 있다면, 경제 밸런스만 손대도 전투 난이도가 바뀐다는 신호입니다. 이런 빨강 연결이 5개 이상이면 시스템이 너무 얽혀 있다는 경고입니다. 각 시스템 가지 아래에는 입력(input) → 처리(processing) → 출력(output) 3구획을 두고 규칙을 정리하면 누락이 없습니다. 전투라면 입력은 컨트롤 키맵, 처리는 데미지 공식, 출력은 시각·청각 피드백이 됩니다. 캔버스에서 이 구조를 템플릿으로 저장해 두면 새 시스템 추가 시 10분 안에 가지 한 줄을 완성할 수 있습니다.
3. 세계관과 톤
게임의 정서적 톤은 시스템만큼 중요합니다. "비주얼", "사운드", "내러티브"를 별도 가지로 펼치고, 레퍼런스 게임을 노드로 적어두세요.
레퍼런스는 단순 나열이 아니라 "X처럼 보이고 Y처럼 들리며 Z처럼 읽힌다" 식의 짧은 한 문장으로 정리합니다. 예: "Hollow Knight처럼 보이고, Celeste처럼 들리며, Disco Elysium처럼 읽힌다". 비주얼 가지에는 컬러 팔레트 6색의 hex 코드와 무드보드 이미지 URL, 사운드 가지에는 BGM BPM·악기·믹스 톤을, 내러티브 가지에는 1인칭/3인칭·시제·존댓말 여부 같은 화법 규칙을 적어 두세요. 톤이 흔들릴 때 이 가지를 다시 펼쳐 "초기 합의와 어디가 어긋났는지" 확인하면 회의 시간을 절반으로 줄일 수 있습니다.
4. 출시 후 콘텐츠 로드맵
출시는 끝이 아니라 시작입니다. "1개월 후, 3개월 후, 6개월 후"의 콘텐츠 업데이트를 마인드맵에 그려두면, 출시 직후 유저 유입이 떨어지는 시점에 무엇을 풀어낼지 명확해집니다.
일반적으로 인디 게임은 출시 14일이 지나면 신규 유저 유입이 70% 이상 감소합니다. 따라서 D+30 업데이트는 "리텐션 회복"을, D+90은 "신규 유입 재점화"를, D+180은 "DLC·확장팩"을 목표로 가지를 구분하세요. 각 시점 아래 "추가 콘텐츠·밸런스 패치·신규 모드"를 3개 하위 가지로 두면 한 화면에 6개월 로드맵이 펼쳐집니다. Steam·Nintendo eShop의 알고리즘은 정기적 업데이트가 있는 타이틀에 가산점을 주기 때문에, 마인드맵 위에 미리 일정을 박아두는 것만으로도 가시성이 달라집니다.
5. 플레이테스트 피드백 가지
플레이테스트 후 받은 피드백을 "튜토리얼", "밸런스", "재미 포인트"로 분류해 가지로 정리하세요. 비슷한 피드백이 3건 이상 쌓이는 가지가 우선 수정 대상입니다. 데이터를 가지에 직접 표시해두면 어떤 수정이 가장 임팩트가 큰지 명확히 보입니다.
실전에서는 피드백 한 건을 받을 때마다 가지 옆에 ✓ 마크를 추가하는 식으로 빈도를 시각화합니다. "보스 2페이즈 패턴이 어렵다"가 ✓✓✓ 이상이면 즉시 수정, ✓✓는 일주일 관찰, ✓는 메모만. Discord 베타 테스트 채널의 의견이나 itch.io 리뷰를 그대로 복사해 가지에 붙이는 것이 가장 빠릅니다. 피드백 가지 옆에는 항상 "수정 비용"(시간·리소스)을 적어 두세요. ✓✓✓이지만 수정 비용이 2주를 넘으면 출시 후로 미루고, ✓ 1개라도 수정 비용이 30분이면 즉시 적용하는 식의 의사결정이 가능해집니다.
6. 흔히 빠지는 함정 5가지
- 핵심 루프 없이 시스템부터 설계 — 멋진 시스템 10개가 있어도 루프가 약하면 30분 안에 지루해집니다. 루프 한 사이클이 안 그려지면 시스템 가지를 만들지 마세요.
- 레퍼런스 게임을 너무 많이 나열 — 5개 이상이면 정체성이 흐려집니다. "어느 한 측면에서 X처럼"으로 한정하고 3개 이내로 줄이세요.
- 아트 가지에 텍스트만 적기 — 비주얼은 텍스트 설명만으론 합의가 안 됩니다. 노드 메모에 무드보드 URL·hex 코드·스크린샷을 반드시 첨부하세요.
- 출시 후 로드맵을 출시 임박에 그리기 — 출시 3개월 전부터 D+30 콘텐츠가 준비되어야 합니다. 로드맵은 알파 단계에서 첫 가지를 그리는 게 정상입니다.
- 피드백을 모두 동등하게 취급 — 신규 유저 5명의 "어렵다"와 고인물 1명의 "쉽다"는 다른 가지로 분리해야 합니다. 타깃별 가지를 색으로 나누세요.
7. 90일 실전 적용 사례
가상 사례: 2인 인디팀 G스튜디오의 첫 액션 로그라이크 — 기획 문서가 노션 페이지 30개로 흩어져 있어 회의 때마다 "이 시스템 어디서 본 것 같은데"가 반복되었습니다. GDD를 마인드맵 한 장으로 옮긴 첫 30일에 핵심 루프 3층 + 시스템 6가지 + 톤 3축이 한 화면에 정리되었습니다.
두 번째 30일은 친구 12명을 대상으로 플레이테스트를 3회 진행했습니다. 피드백 가지에 ✓ 마크로 빈도를 표시했고, 수정 비용도 옆에 적었습니다. "보스 2페이즈가 너무 길다"가 ✓✓✓✓로 최다 표를 받았고 수정 비용 4시간으로 즉시 처리, "골드 인플레이션"이 ✓✓✓에 수정 비용 2일로 다음 스프린트에 배정되었습니다.
세 번째 30일은 출시 D+30~D+180 로드맵을 채웠습니다. 신규 캐릭터 1종(D+30), 신규 보스 1종(D+60), DLC 초안(D+90)을 가지에 그려 두고 Steam Next Fest 데모 출품을 준비했습니다. 90일 후 데모 출품 결과 위시리스트가 1주일에 2,400건 추가되었고, 팀원이 가장 크게 체감한 변화는 "기획 회의 시간이 평균 2시간에서 40분으로 줄었다"는 점이었습니다. 마인드맵 한 장이 노션 30페이지보다 강력했던 셈입니다.
한 줄 요약
- 핵심 루프 — 30초·5분·30분 변주
- 시스템 가지 — 의존성을 색으로 시각화
- 세계관/톤 — 비주얼·사운드·내러티브 3축
- 출시 후 로드맵 — 유입 유지 콘텐츠 계획
- 테스트 피드백 — 3건 이상 = 우선 수정
* Toi & Toh(2009), Farrand et al.(2002) 등 마인드맵 학습 효과 연구 종합 인용
📊 줄글 vs 마인드맵 — 어떻게 다른가요?
| 비교 항목 | 줄글 노트 | 마인드맵 |
|---|---|---|
| 구조 파악 | 처음부터 끝까지 읽어야 함 | 한 화면에 즉시 보임 |
| 수정·확장 | 중간 삽입 시 전체 재구성 | 가지 추가만으로 확장 |
| 복습 속도 | 전체 정독 필요 | 키워드 5분 훑기 |
| 관계 시각화 | 표현 어려움 | 자동으로 표현 |
| 기억 유지 | 선형 정보로 빠른 망각 | 시각·연관 기억 강화 |
✅ 마인드맵 시작 전 체크리스트
- 이번 마인드맵의 한 줄 목적은 무엇인가? (예: "이번 주 회의 정리")
- 중심 노드에 들어갈 핵심 주제를 한 단어로 적을 수 있는가?
- 1단계 가지의 3~5개 카테고리를 미리 떠올렸는가?
- 가지마다 들어갈 색상 규칙이 일관성 있는가?
- 완성 후 JSON으로 백업할 계획이 있는가?
- 다음 점검 시점(D+1, D+3, D+7)을 캘린더에 표시했는가?
가지를 너무 펼치지 마세요. 한 부모 노드에 5~7개 이내의 가지가 황금 비율입니다. 이를 넘으면 한눈에 잡히지 않아 마인드맵의 가장 큰 장점인 "한 화면 시각화"가 무너집니다. 가지가 많아진다면 한 단계 상위 카테고리로 묶어 트리를 다시 정리하세요.
💡 핵심 인사이트
마인드맵의 진짜 가치는 "그림 그리기"가 아니라 구조화된 사고를 강제한다는 점에 있습니다. 트리 모양의 빈 공간 자체가 "여기에 무엇을 넣을 것인가?"라는 질문을 끊임없이 던지기 때문에, 무엇을 모르는지가 시각적으로 드러납니다.
이 글의 방법론을 한 번 적용하고 끝나는 것이 아니라, 7일·30일·90일 단위로 같은 마인드맵을 다시 펼쳐 보세요. 시간이 지나면서 가지가 채워지고, 색이 바뀌고, 새 연결이 생깁니다. "살아있는 마인드맵"이 만들어지는 순간 진짜 효과가 시작됩니다.
새 게임 아이디어, 한 장으로 응축
핵심 루프가 흔들리지 않는 GDD가 좋은 게임을 만듭니다.
MindMap Studio 열기 →자주 묻는 질문
퍼블리셔에 제출하는 GDD도 마인드맵으로 충분한가요?
퍼블리셔 제출용은 마인드맵을 기반으로 워드/PDF 문서로 변환하는 것이 좋습니다. 마인드맵은 내부 설계용으로 가장 강력합니다.
1인 개발자도 GDD가 필요한가요?
1인 개발일수록 GDD가 필요합니다. 흔들리는 자기 결정에 대한 닻 역할을 합니다. 마인드맵 한 장이면 충분합니다.
아트팀·사운드팀과 어떻게 공유하나요?
전체 GDD 마인드맵의 "비주얼"과 "사운드" 가지만 따로 추출해 공유하세요. 각 팀이 필요한 정보만 보게 되어 협업 마찰이 줄어듭니다. 캔버스에서 가지를 선택해 PNG로 내보내거나 노션·Figma 보드에 임베드하면 매주 동기화 부담이 사라집니다.
GDD가 너무 자주 바뀌는데 마인드맵으로 버틸 수 있나요?
오히려 변경에 가장 강한 형식이 마인드맵입니다. 가지 추가·삭제만으로 구조가 즉시 갱신되고, 색·아이콘으로 "최근 2주 안에 바뀐 노드"를 표시해 두면 팀원이 변경분만 빠르게 확인할 수 있습니다. 워드 문서처럼 전체 페이지를 다시 인쇄·배포할 필요가 없습니다.
유니티·언리얼 엔진과 연동되나요?
직접 연동되는 도구는 적지만, 마인드맵을 JSON으로 내보낸 뒤 ScriptableObject나 데이터 테이블로 변환하는 워크플로우를 짜는 팀이 늘고 있습니다. 시스템 가지 아래에 적힌 스탯·확률 값을 그대로 게임 내 밸런스 시트로 옮기면 디자인-구현 사이의 동기화 오차가 사라집니다.
모바일 캐주얼 게임에도 같은 구조가 통하나요?
네, 오히려 더 잘 맞습니다. 모바일 캐주얼은 30초 루프가 게임 전체이기 때문에 핵심 루프 가지를 더 깊게 파고 메타 진행 가지는 가볍게 두면 됩니다. 광고 보상 슬롯·IAP 패키지·일일 미션 같은 수익화 구조도 별도 가지로 그려 두면 출시 후 A/B 테스트의 기준점이 됩니다.