프로젝트 기획과 설계
핵심 콘셉트와 실현 가능성을 검토하고 GDD·기술 설계·프로토타입으로 프로젝트 범위를 구체화합니다.
좋은 아이디어와 기술이 있어도, 무엇을 어디까지 만들지 정하지 않고 시작한 프로젝트는 쉽게 길을 잃습니다. 전투를 만들다 보니 인벤토리가 필요하고, 인벤토리를 만들다 보니 저장이 필요해지는 식으로 범위가 계속 늘어나, 어느 것 하나 끝나지 않은 채 시간만 흐르기 쉽습니다. 그래서 실제 프로젝트를 시작하기 전에는 목표와 범위, 그리고 무엇을 확인하면 완료인지를 먼저 정해야 합니다.
11장까지 언리얼 C++의 여러 기능을 살펴봤으니, 12장에서는 그것을 모아 작은 실전 프로젝트를 만듭니다. 이 글에서는 첫 프로젝트의 작은 목표를 정하고, 큰 게임을 기획할 때 쓰는 콘셉트, 실현 가능성 검토, 게임 디자인 문서(GDD), 기술 설계 문서(TDD), 프로토타입의 역할을 정리한 뒤, 작은 목표를 이 문서들에 나눠 적어 봅니다.
기획이 하는 일
프로젝트 기획은 게임 개발의 나침반과 같습니다. 무엇을 만들지, 누구를 위한 게임인지, 어떤 경험을 줄지에 대한 분명한 목표를 세우면, 인력, 시간, 예산 같은 자원을 효과적으로 나누고 낭비를 줄일 수 있습니다. 개발 중에 생기는 수많은 결정에 기준을 주어 일관성을 지키고, 생길 수 있는 문제를 미리 찾아 대비해 실패 위험을 줄입니다. 그리고 팀원 모두가 같은 목표를 함께 보고 협력할 바탕이 됩니다.
첫 프로젝트의 작은 목표
처음부터 전투, 인벤토리, AI, 멀티플레이어를 모두 만들기보다, 값 하나가 입력과 화면, 저장을 거쳐 이어지는 작은 목표를 정합니다. 단일 로컬 독립 실행(Standalone)에서 플레이어가 탄약 픽업(Pickup) 하나를 주우면 HUD의 숫자가 바뀌고, 저장한 뒤 새로 실행해도 그 값으로 돌아오는 흐름입니다. 픽업은 플레이어가 닿으면 얻는 아이템을 뜻합니다.
최대 탄약은 30, 처음 탄약은 0, 픽업 한 개가 주는 양은 10으로 정합니다. 목표는 0/30 → 10/30 → 저장 → 새 실행에서 10/30입니다. 이것은 이번 프로젝트에서 만들 목표이며, 앞선 예제가 이미 이 흐름을 구현했다는 뜻은 아닙니다. 예를 들어 데이터 바인딩과 HUD 시스템의 캐릭터는 생성자와 BeginPlay에서 현재 탄약을 최댓값으로 채우므로 기본적으로 30/30에서 시작합니다. 다음 글에서는 생성자와 BeginPlay의 탄약 초기값을 0으로 바꾸고, 유효한 저장값은 그 초기화가 끝난 뒤에 적용합니다.
이 목표에서 저장하는 데이터는 탄약 숫자 하나입니다. 플레이어 위치, 픽업을 이미 먹었는지, 월드 전체는 저장하지 않습니다. 전투, 게임플레이 능력 시스템(GAS), AI, 제작, 네트워크, 출시와 운영은 이 작은 흐름을 마친 뒤 고를 확장으로 남깁니다. 아래에서 다룰 큰 게임의 기획 예시는 확장할 때 참고하고, 첫 완료 기준과는 구별합니다.
이 글은 작은 목표와 범위를 정합니다. 다음 글 게임 시스템 구현에서는 이미 조작할 수 있는 C++ 프로젝트를 바탕으로 탄약 습득, HUD, 저장, 복원을 잇는 코드와 에셋 설정 순서를 제공합니다. 프로젝트나 에셋 파일 자체는 배포하지 않으므로, 쓰는 프로젝트의 실제 클래스와 입력 설정에 합쳐야 합니다.
기획 단계: 아이디어를 구체화하기
핵심 아이디어와 콘셉트 (High-Concept)
게임의 핵심은 한 문장으로 설명할 수 있어야 합니다. 예를 들어 "포스트 아포칼립스 세계에서 자원을 모아 기지를 짓고 살아남는 멀티플레이어 크래프팅 게임"처럼요. 그다음 게임을 즐길 주요 연령대와 취향 같은 대상 플레이어를 정하고, 플레이어가 게임에서 되풀이할 핵심 활동인 게임플레이 루프를 정의합니다. 앞의 예라면 탐험, 자원 수집, 제작, 건설, 생존이 이어지는 흐름입니다. 장르(RPG, FPS, 퍼즐 등)와 서비스할 플랫폼(PC, 모바일, 콘솔)도 이 단계에서 정합니다.
콘셉트 문서 (Concept Document)
핵심 아이디어를 바탕으로 더 자세한 콘셉트 문서를 씁니다. 게임의 전체 모습과 플레이어 경험을 설명하는 개요, 다른 게임과 차별되는 핵심 판매 포인트(Unique Selling Points, USP), 플레이어가 맡는 역할과 능력, 세계관과 배경, 카툰풍이나 사실풍, 픽셀 아트 같은 아트 스타일, 분위기에 맞는 사운드와 음악의 방향을 정리합니다. 비슷한 게임과 경쟁작, 시장 규모도 간단히 조사합니다.
실현 가능성 검토
아이디어가 기술, 예산, 시간 면에서 실현할 수 있는지 평가하는 단계입니다. 대규모 월드 스트리밍, 복잡한 물리 시뮬레이션, 특정 네트워크 모델처럼 언리얼에서 구현하기 어려운 부분이나 기술적 제약이 있는지 파악합니다. 지금 팀의 기술과 인력으로 만들 수 있는지 평가하고, 필요하다면 외부 전문가나 새 팀원을 검토합니다. 콘셉트를 바탕으로 대략의 개발 기간과 예산을 추산하고, 기술 문제, 인력 이탈, 예산 부족 같은 주요 위험을 찾아 각각의 대비책을 세웁니다.
설계 단계: 자세한 계획 세우기
기획 단계의 콘셉트를 바탕으로 게임의 각 시스템을 구체적으로 정의합니다. 기획 단계가 무엇을 만들지 정했다면, 설계 단계는 그것이 어떤 규칙으로 동작하고 어떻게 구현할지를 정합니다. 그래서 아래의 두 문서는 읽는 사람이 다릅니다. 게임 디자인 문서는 플레이 규칙과 콘텐츠를, 기술 설계 문서는 그 규칙을 구현할 구조와 성능 목표를 적습니다. 마지막의 프로토타이핑은 두 문서에 적은 가정 가운데 확신이 없는 것을 작은 실험으로 먼저 확인하는 일입니다.
게임 디자인 문서
게임 디자인 문서(Game Design Document, GDD)는 게임의 시스템과 기능을 자세히 담은 설계도이며, 바꾼 이유와 확인 결과에 따라 계속 갱신하는 공통 기준 문서입니다.
GDD는 먼저 핵심 게임플레이를 다룹니다. 플레이어가 되풀이할 코어 루프를 더 자세히 정의하고, 싱글플레이어, 멀티플레이어, 협동, 경쟁 같은 게임 모드와 승리, 패배 조건을 분명히 합니다. 캐릭터와 개체에 대해서는 플레이어 캐릭터의 능력, 스킬, 성장, 꾸미기를, NPC의 역할과 행동 트리나 스테이트 머신으로 만들 AI 행동, 능력, 외형을, 적의 종류, 공격 패턴, 약점, 떨어뜨리는 아이템을 정의합니다.
월드와 레벨 디자인에서는 게임 세계의 전체 지형, 지역별 특징, 중요한 지점을 계획하고, 레벨마다의 목표, 난이도 곡선, 배치할 물체와 이벤트를 자세히 설계합니다. 플레이 흐름은 플로 차트로, 제작 일정은 간트 차트로 나눠 그리며, AI의 경로와 플레이어의 이동 경로도 고려합니다.
시스템 디자인에서는 HUD, 메뉴, 인벤토리, 상점 같은 UI 요소의 기능과 디자인을 사용자 경험(UX)의 흐름과 함께 설계합니다. 공격, 방어, 스킬, 피해 계산, 상태 이상을 정하는 전투 시스템, 아이템의 종류와 속성, 얻고 쓰고 버리는 로직, 슬롯 수를 정하는 인벤토리 시스템, 퀘스트의 종류와 진행, 보상을 정하는 퀘스트 시스템을 설계합니다. 저장 시스템에서는 어떤 데이터를 언제 저장하고 오류가 나면 어떻게 복구할지를, 멀티플레이어라면 네트워크 모델, 동기화 방식, 지연 처리, 치트 방지를, 재화가 있다면 경제 시스템을 정합니다.
오디오와 비주얼에서는 어떤 상황에 어떤 효과음이 볼륨과 피치를 어떻게 해서 나올지, 배경 음악과 이벤트 음악의 분위기, 파티클과 후처리 같은 시각 효과(VFX)를 정합니다. 마지막으로 나나이트, 루멘, 행동 트리, 나이아가라 같은 언리얼의 어떤 기능을 쓸지, 외부 라이브러리나 플러그인을 쓸지 같은 기술 스택을 적습니다.
기술 설계 문서
기술 설계 문서(Technical Design Document, TDD)는 GDD를 바탕으로 개발팀이 실제로 구현할 기술적 세부를 다룹니다. 클래스 다이어그램이나 컴포넌트 다이어그램으로 주요 시스템 사이의 관계, 데이터 흐름, 모듈 구성을 정의하고, 필요한 데이터베이스의 구조와 테이블, 관계를 정합니다. 멀티플레이어라면 클라이언트와 서버 사이의 통신 규칙과 메시지 형식을 자세히 정의합니다. 목표 프레임 속도, 메모리 사용량, 로딩 시간 같은 구체적인 성능 목표를 세우고, 개발에 쓸 커스텀 도구와 에디터 확장, 아트와 애니메이션 파이프라인, 그리고 플랫폼별 빌드, 업데이트 전략, 서버 인프라 계획도 적습니다.
각 산출물이 무엇을 정하고 무엇으로 확인하는지 정리하면 다음과 같습니다.
| 산출물 | 정할 내용 | 확인할 질문 |
|---|---|---|
| 콘셉트 | 핵심 경험, 대상, 플랫폼 | 팀이 같은 게임을 설명하는가? |
| GDD | 플레이 규칙, 승패, 콘텐츠 범위 | 기능이 핵심 경험을 뒷받침하는가? |
| TDD | 상태를 가진 쪽, 모듈, 성능 예산 | 구현 방식이 제약을 만족하는가? |
| 프로토타입 | 위험한 가정을 시험하는 작은 실험 | 유지할지, 고칠지, 버릴지 판단할 자료가 있는가? |
프로토타이핑
기획과 설계 단계에서 불확실한 기술 요소나 핵심 게임플레이 아이디어는 빠르고 간단한 프로토타입으로 확인합니다. 핵심 게임플레이가 재미있는지, 기술적으로 얼마나 어려운지, 아이디어가 어떻게 보이는지를 확인하는 것이 목적입니다. 최소한의 자원으로 핵심 기능만 만들고, 확인하려는 질문과 상관없는 UI나 아트의 완성도는 낮춰도 됩니다. 다만 가독성이나 조작감 자체를 확인하려는 것이라면 그 품질은 갖춰야 합니다. 프로토타입에서 얻은 피드백으로 기획과 설계를 고치고 다듬습니다.
작은 목표를 문서에 나눠 적기
이 글의 작은 목표를 GDD와 TDD에 나눠 적어 봅시다. GDD에는 최대 탄약 30, 픽업 한 개의 지급량 10, 탄약이 실제로 늘었을 때만 픽업을 한 번 소모, 새 실행에서는 탄약 숫자만 복원이라는 플레이 규칙을 둡니다. TDD에는 캐릭터가 현재 값을 가지고, 픽업은 증가를 요청하고, 컨트롤러가 HUD로 전달하고, 게임 모드가 처음 읽기와 저장 요청을 관리한다는 연결을 적습니다. 저장 파일이 없는 경우와 읽기에 실패한 경우를 똑같이 새 게임으로 취급하지 않는다는 것도 구현 기준으로 적어 둡니다.
프로토타입에서 처음 확인할 것은 세 가지입니다. 새 슬롯에서 0/30으로 시작하는지, 한 번 주운 뒤 getter와 HUD가 모두 10/30인지, 같은 슬롯을 읽은 새 실행에서 10/30으로 돌아오는지입니다. 각 확인에는 실제 클래스, 맵, 슬롯, 입력 조건을 함께 기록합니다. 화면에 보이는 숫자 하나만 확인하면, 저장 파일과 캐릭터의 상태가 실제로 이어졌는지를 놓칠 수 있습니다. 아직 만들지 않을 전투, 월드 저장, 멀티플레이어는 이 완료 기준에 끼워 넣지 않습니다.
애자일과 반복적인 설계
요즘의 게임 개발은 예측하기 어려운 요소가 많아 처음부터 모든 것을 완벽하게 설계하기 어렵습니다. 그래서 처음의 GDD를 고정하지 않고, 개발 중의 피드백과 시험 결과에 따라 계속 갱신하고 다듬습니다. 1주에서 4주의 짧은 개발 주기인 스프린트(sprint) 동안 특정 목표를 이루고, 결과를 검토해 다음 스프린트의 계획에 반영합니다. 애자일과 스크럼에서 스프린트를 어떻게 계획하고 검토하는지는 방법론과 반복 개발에서 더 자세히 다룹니다. 모든 것을 문서로 남기기보다 핵심적인 부분에 집중하고, 빠르게 바뀔 부분은 가볍게 유지합니다.
정리
- 기획은 목표와 범위, 자원 배분, 결정의 기준을 정해 프로젝트가 길을 잃지 않게 합니다.
- 첫 프로젝트는 탄약 하나가
0/30 → 10/30 → 저장 → 새 실행에서 10/30으로 이어지는 작은 흐름으로 정하고, 위치, 픽업 소모 상태, 월드는 저장하지 않습니다. - 기획 단계에서는 한 문장 콘셉트, 대상, 코어 루프, 콘셉트 문서를 만들고 실현 가능성과 위험을 검토합니다.
- GDD는 플레이 규칙과 콘텐츠를, TDD는 상태를 가진 쪽, 모듈, 성능 예산 같은 구현을 정하며, 둘 다 계속 갱신합니다.
- 프로토타입은 위험한 가정을 작게 시험하며, 확인할 항목과 실제 조건을 함께 기록합니다.
- 애자일 방식으로 짧은 주기마다 결과를 검토해 설계를 고쳐 갑니다.
연습 문제
1. 다시 주웠더니 20이 되었다
새 실행에서 저장된 탄약 10을 복원한 뒤, 레벨에 다시 나타난 픽업을 주웠더니 20이 되었습니다. 지금 설계의 실패일까요?
해설 보기
실패가 아닙니다. 지금 범위에서는 픽업을 먹었는지와 월드 상태를 저장하지 않으므로, 새 실행에서 픽업이 다시 나타나고 그것을 주워 10에서 20이 되는 것이 정한 범위에 맞는 동작입니다.
2. 저장 성공 표시만 보았다면
첫 실행에서 저장에 성공했다는 표시만 확인하고, 새 실행에서 복원되는지는 확인하지 않았습니다. 작은 목표를 모두 마쳤다고 할 수 있을까요?
해설 보기
할 수 없습니다. 목표의 마지막 단계는 새 실행에서 10/30으로 돌아오는 것이므로, 저장 성공 표시만으로는 저장 파일이 실제로 읽히고 캐릭터에 적용되는지 알 수 없습니다. 같은 슬롯을 읽은 새 실행에서 getter와 HUD가 모두 10/30인지 확인해야 완료입니다.
3. 픽업 소모 상태도 남기려면
새 실행에서도 이미 먹은 픽업이 다시 나타나지 않도록 해 달라는 요구가 추가되었습니다. 무엇을 바꿔야 할까요?
해설 보기
저장할 상태와, 픽업을 실행이 바뀌어도 알아볼 수 있는 식별 규칙, 그리고 새 실행에서 그 상태를 복원하는 규칙을 더해야 합니다. 새 실행에서 픽업을 어떻게 배치하고, 보여 주고, 주울 수 있게 할지도 정하고, 확인할 사례도 추가합니다.
기존 픽업의 포인터를 그대로 저장하거나 탄약 숫자만 늘리는 것으로는 이 요구를 채울 수 없습니다. 데이터 직렬화와 역직렬화에서 본 것처럼 안정적인 ID로 다시 찾아야 하며, 첫 목표의 조건은 그대로 두고 별도의 확장으로 설계합니다.
다음 글 게임 시스템 구현에서는 이 작은 목표를 실제 코드로 만들어, 탄약 픽업과 HUD, 저장과 복원을 하나의 흐름으로 잇습니다.