기획 맛보기 #1 — 게임 기획이란 무엇인가

오늘의 한 문장

게임 기획은 머릿속의 아이디어를 팀이 같은 방향으로 이해하고, 개발자가 실제로 구현하고 테스트할 수 있는 명세로 바꾸는 과정이다.

1. 아이디어와 기획은 다르다

“적을 쓰러뜨리는 재미있는 액션 게임을 만들고 싶다”는 아이디어다. 만들고 싶은 방향은 보이지만, 이것만으로는 개발을 시작하기 어렵다.

개발하려면 적어도 다음 질문에 답할 수 있어야 한다.

• 플레이어는 어떤 행동을 하는가?
• 승리와 실패는 언제 결정되는가?
• 공격이 적에게 적중했는지는 어떻게 판정하는가?
• 적이 죽으면 무엇을 얻는가?
• 획득한 보상은 다음 플레이에 어떤 영향을 주는가?
• 플레이어에게 결과를 어떻게 전달하는가?

Unity 역시 게임 디자인 문서인 GDD를 콘셉트부터 게임 규칙, 조작법, 시각 요소, 개발 일정까지 담는 개발의 청사진으로 설명한다. 동시에 프로젝트의 규모에 따라 문서 형식과 분량은 달라질 수 있다고 안내한다. 즉, 좋은 기획은 문서가 긴가보다 개발에 필요한 판단이 들어 있는가가 중요하다.
Unity Learn — Fill out a game design document

아이디어를 명세로 바꾸는 예시

아이디어:

공격하면 적이 시원하게 날아간다.

구현 가능한 명세:

• 공격 버튼을 누르면 0.2초 후 공격 판정이 발생한다.
• 공격 범위 안의 적에게 20의 피해를 준다.
• 적이 피해를 받으면 공격 방향으로 3m 밀려난다.
• 보스와 슈퍼아머 상태의 적은 밀려나지 않는다.
• 적중 시 타격 이펙트, 효과음, 짧은 화면 흔들림을 출력한다.
• 공격이 빗나가면 적중 효과를 출력하지 않는다.

두 문장은 같은 아이디어를 다루지만, 두 번째 문장에는 입력, 조건, 결과, 예외, 피드백이 있다. 개발자와 아티스트, 사운드 담당자는 이를 바탕으로 작업을 시작할 수 있고, QA 담당자는 정상 작동 여부를 확인할 수 있다.

2. 기획자는 Why를, 개발자는 How를 본다

공부 자료에서 가장 인상적이었던 부분은 다음 구분이었다.

• 기획자는 왜 이런 경험이 필요한가를 생각한다.
• 개발자는 그 경험을 어떻게 작동시킬 것인가를 생각한다.

예를 들어 기획자가 “적의 공격 직전에 붉은 표시를 보여준다”고 정했다면, 그 이유는 단순히 화면을 화려하게 만들기 위해서가 아니다.

플레이어가 공격을 예측하고 회피했다는 성취감을 느끼게 하기 위해서다.

개발자는 이 의도를 바탕으로 경고 표시가 나타나는 시점, 공격 상태 전환, 피격 판정, 애니메이션 연동 방식을 설계한다.

다만 Why와 How를 직군별로 완전히 나누어서는 안 된다. 실제 개발에서는 기획자도 구현 비용과 기술적 제약을 알아야 하고, 개발자도 기능이 만들어야 할 플레이 경험을 이해해야 한다.

MDA 프레임워크는 이를 다음과 같이 설명한다.

규칙과 수치(Mechanics)
        ↓
플레이 중 발생하는 행동(Dynamics)
        ↓
플레이어가 느끼는 경험(Aesthetics)

디자이너는 규칙에서 경험을 향해 설계하지만, 플레이어는 먼저 경험을 느끼고 그 뒤에 있는 행동과 규칙을 발견한다. 따라서 기획자는 “어떤 기능을 넣을까?”보다 “어떤 경험을 만들고, 어떤 규칙으로 그 경험을 발생시킬까?”를 고민해야 한다.
Hunicke·LeBlanc·Zubek — MDA: A Formal Approach to Game Design and Game Research

3. 좋은 기획서의 조건

좋은 기획서는 모든 내용을 길게 설명한 문서가 아니다. 필요한 사람이 필요한 결정을 내릴 수 있게 해주는 문서다.

목적이 분명하다

기능이 존재하는 이유와 만들고자 하는 플레이 경험을 먼저 설명한다.

• 나쁜 예: 구르기 기능을 추가한다.
• 좋은 예: 근접 전투에서 공격을 피하고 곧바로 반격하는 경험을 제공하기 위해 구르기를 추가한다.

동작을 확인할 수 있다

“적절하게”, “자연스럽게”, “재미있게” 같은 표현만으로는 완료 여부를 판단하기 어렵다.

• 입력
• 발생 조건
• 처리 결과
• 성공과 실패
• 예외 상황
• 화면·소리 피드백

위 항목이 구체적일수록 구현과 테스트가 쉬워진다.

읽는 사람에게 맞는 형태를 사용한다

복잡한 흐름은 순서도, 수치 비교는 표, 공간 구조는 그림으로 표현하는 편이 좋다. 모든 정보를 긴 문장으로 적을 필요는 없다.

실제로 《SimCity》 개발에 참여한 Stone Librande는 핵심 아이디어를 팀에 전달하기 위해 3년간 100개가 넘는 한 페이지 문서를 사용했다. 이는 무조건 한 장만 써야 한다는 뜻이 아니라, 하나의 주제를 빠르게 이해할 수 있는 단위로 전달했다는 점이 중요하다.
GDC Vault — Simulating a City, One Page at a Time

변경할 수 있어야 한다

기획서는 처음 작성한 내용을 끝까지 지키는 계약서가 아니다. 프로토타입과 테스트 결과에 따라 계속 수정되는 현재의 기준점이다. Unity도 GDD를 프로젝트의 변화에 맞춰 수정하고 확장해야 하는 동적 문서로 설명한다.

따라서 문서에는 다음 정보가 있으면 좋다.

• 작성자와 최근 수정일
• 현재 확정된 내용
• 아직 검증이 필요한 가설
• 변경된 이유
• 관련 문서와 담당자

4. 레퍼런스는 어떻게 분석해야 할까?

레퍼런스를 찾을 때 단순히 “재미있는 게임”을 고르면 분석 범위가 너무 넓어진다. 내가 만들 게임의 문제를 해결하는 데 도움이 되는 게임을 골라야 한다.

예를 들어 보스전의 공격 예고를 기획한다면 다음처럼 범위를 좁힐 수 있다.

공격을 피할 수 있을 만큼 명확하게 알려주면서도 긴장감을 유지하는 게임

레퍼런스를 분석할 때는 기능의 외형보다 기능과 경험 사이의 인과관계를 찾아야 한다.

레퍼런스 분석 질문

1. 플레이어가 실제로 하는 행동은 무엇인가?
2. 게임은 어떤 규칙과 정보를 제공하는가?
3. 그 규칙 때문에 어떤 플레이 양상이 발생하는가?
4. 플레이어는 어떤 감정을 느끼는가?
5. 이 요소가 해결하는 문제는 무엇인가?
6. 우리 게임에 적용하려면 무엇을 유지하고 무엇을 바꿔야 하는가?

예시

관찰:

보스가 강한 공격 전에 무기를 크게 들어 올린다.

분석:

• 공격 전에 준비 동작을 보여준다.
• 플레이어가 공격 방향과 시점을 예측할 수 있다.
• 공격이 강해도 피할 기회가 있기 때문에 부당하다는 느낌이 줄어든다.
• 회피에 성공하면 자신의 판단과 조작 실력으로 극복했다는 성취감을 느낀다.

적용:

보스의 강한 공격에는 최소 0.8초의 고유한 준비 동작과 전용 효과음을 사용한다. 일반 공격과 실루엣이 겹치지 않도록 한다.

이렇게 분석해야 레퍼런스의 겉모습을 복사하지 않고, 그 기능이 작동하는 원리를 가져올 수 있다.

5. 콘셉트는 한 문장으로 설명할 수 있어야 한다

콘셉트 문장은 팀이 기능을 선택하거나 제거할 때 사용하는 판단 기준이다. 다음 요소를 넣으면 비교적 명확하게 정리할 수 있다.

누가 + 무엇을 반복하며 + 어떤 경험을 얻는 게임인가 + 차별점은 무엇인가

예시:

빛을 잃어가는 숲의 수호자가 낮에 자원을 모으고 밤에 거점을 방어하며, 준비와 생존의 긴장감을 경험하는 로그라이트 디펜스 게임.

이 문장에서는 다음 내용을 확인할 수 있다.

• 플레이어 역할: 숲의 수호자
• 핵심 행동: 자원 수집과 거점 방어
• 핵심 경험: 준비와 생존의 긴장감
• 장르와 구조: 로그라이트 디펜스
• 변형 포인트: 낮과 밤의 역할 변화

반대로 다음 문장은 콘셉트로 사용하기 어렵다.

재미있는 전투와 감동적인 스토리가 있는 액션 게임.

대부분의 게임에 적용할 수 있고, 어떤 기능을 우선해야 하는지 판단할 기준이 없기 때문이다.

Unity의 GDD 학습 자료도 프로젝트 초기에 콘셉트, 장르, 대상 플레이어와 플랫폼을 정리하고, 간단한 게임은 “누가 무엇을 모으면서 무엇을 피하는가” 같은 문장으로 출발하도록 안내한다.
Unity Learn — GDD의 콘셉트 작성 예시

6. 실제 개발에서 기획자는 무엇을 하는가?

《Super Mario 3D Land》 개발진 인터뷰에서 기획 리더는 팀에서 나온 아이디어를 조율하고 제품에 반영하는 다리 역할을 했다고 설명한다. 디렉터는 전반적인 사양과 게임의 균형을 조정했고, 디자인 리더는 Mario의 움직임과 연출 등을 담당했다. 하나의 아이디어를 실제 제품으로 만들기 위해 여러 분야의 판단을 연결한 것이다.
Nintendo — Iwata Asks: Super Mario 3D Land

후속작 《Super Mario 3D World》의 프로듀서는 게임이 전체 콘셉트를 계속 따르고 있는지 확인하는 것이 자신의 주요 역할이었다고 말했다. 당시의 방향은 2D 《New Super Mario》를 좋아하는 사람도 즐길 수 있는 거치형 3D Mario 게임이었다. 콘셉트가 단순한 홍보 문구가 아니라 개발 도중 수많은 선택을 검토하는 기준으로 사용된 사례다.
Nintendo — Iwata Asks: Super Mario 3D World

결국 실제 게임 개발에서 기획자는 다음을 연결한다.

아이디어
  ↓
플레이어에게 주고 싶은 경험
  ↓
필요한 규칙과 기능
  ↓
구현 가능한 명세
  ↓
프로토타입과 테스트
  ↓
결과에 따른 수정

오늘 배운 점

게임 기획은 좋은 아이디어를 많이 내는 일만이 아니다. 아이디어의 의도를 설명하고, 필요한 규칙을 정리하고, 여러 직군이 같은 결과를 상상할 수 있도록 전달하는 일이다.

좋은 기획서는 모든 답을 처음부터 알고 있는 문서가 아니다. 현재의 의도와 가설을 명확하게 보여주고, 구현과 테스트를 거쳐 더 나은 답으로 수정할 수 있는 문서다.

앞으로 기능을 기획할 때는 다음 네 가지부터 확인해야겠다.

1. 이 기능은 왜 필요한가?
2. 플레이어에게 어떤 경험을 주려는가?
3. 개발자가 바로 구현할 만큼 구체적인가?
4. 결과를 플레이해서 검증할 수 있는가?