프로젝트 기획과 설계

핵심 콘셉트와 실현 가능성을 검토하고 GDD·기술 설계·프로토타입으로 프로젝트 범위를 구체화합니다.

이전 장에서 우리는 언리얼 엔진의 고급 주제와 최신 기술들인 플러그인 개발, 에디터 확장, AI와 행동 트리, 그리고 머신러닝과 실시간 렌더링에 대해 알아보았습니다.

이제 실제 게임 프로젝트를 시작하기 위한 프로젝트 기획과 설계 기준을 정리합니다.

아무리 훌륭한 아이디어나 기술을 가지고 있더라도, 체계적인 기획과 설계 없이 시작된 프로젝트는 표류하거나 실패할 가능성이 높습니다.

이번 절에서는 게임 개발 프로젝트를 시작하기 전에 반드시 거쳐야 할 기획 및 설계 단계의 핵심 요소들을 알아보고, 각 단계에서 고려해야 할 사항들과 구체적인 방법론을 제시하겠습니다.

프로젝트 기획의 중요성

프로젝트 기획은 게임 개발의 나침반과 같습니다.

명확한 기획은 다음과 같은 이점을 제공합니다.

목표 명확화: 무엇을 만들 것인지, 누구를 위한 게임인지, 어떤 경험을 제공할 것인지에 대한 명확한 비전을 수립합니다.
자원 효율성: 필요한 인력, 시간, 예산 등 자원을 효과적으로 배분하고 낭비를 줄입니다.
방향성 제시: 개발 과정 중 발생하는 수많은 의사결정의 기준을 제공하여 일관성을 유지합니다.
위험 관리: 잠재적인 문제를 미리 식별하고 대비하여 프로젝트 실패 위험을 줄입니다.
팀 목표 공유: 모든 팀원이 동일한 목표와 비전을 공유하고 협력할 수 있는 기반을 마련합니다.

처음부터 전투·인벤토리·AI·멀티플레이어를 모두 만들기보다, 한 가지 값이 입력과 화면, 저장을 거쳐 이어지는 작은 목표를 정하겠습니다. 단일 로컬 Standalone(독립 실행)에서 플레이어가 탄약 Pickup 하나를 주워 HUD의 숫자가 바뀌고, 저장한 뒤 새 실행에서도 그 값으로 돌아오는 흐름입니다. Pickup은 플레이어가 접촉해 얻는 아이템을 뜻합니다.

최대 탄약은 30, 최초 탄약은 0, Pickup 한 개의 지급량은 10으로 설계합니다. 목표 결과는 0/30 → 10/30 → 저장 → 새 실행에서 10/30입니다. 이는 이번 프로젝트에서 만들 목표이며, 앞선 예제가 이미 이 흐름을 구현했다는 뜻은 아닙니다. HUD 예제의 캐릭터는 생성자와 BeginPlay에서 현재 탄약을 최댓값으로 채워 기본적으로 30/30으로 시작합니다. 다음 절에서는 생성자와 BeginPlay의 탄약 초깃값을 0으로 바꾸고, 유효한 저장값은 그 초기화 뒤에 적용합니다.

이 목표의 저장 데이터는 탄약 숫자 하나입니다. 플레이어 위치, Pickup의 소모 여부, 월드 전체는 저장하지 않습니다. 전투·GAS·AI·제작·네트워크와 출시·운영은 작은 루프 뒤에 선택할 확장으로 남깁니다. 아래의 큰 게임 기획 예시는 확장할 때 참고하고, 첫 완료 기준과 구별하세요.

이 절은 작은 목표와 범위를 정합니다. 다음 절에서는 이미 조작 가능한 C++ 프로젝트를 바탕으로 탄약 습득·HUD·저장·복원을 연결할 코드와 에셋 설정 순서를 제공합니다. 프로젝트·에셋 파일 자체는 배포하지 않으므로 사용하는 프로젝트의 실제 클래스와 입력 설정에 합쳐야 합니다.

기획 단계: 게임 아이디어 구체화

핵심 아이디어 및 콘셉트 (High-Concept)

한 문장으로 요약: 게임의 핵심을 한 문장으로 압축하여 설명할 수 있어야 합니다. (예: 포스트 아포칼립스 세계에서 자원을 수집하고 기지를 건설하여 생존하는 멀티플레이어 크래프팅 게임)
타겟 플레이어: 게임을 즐길 주요 연령대, 성별, 취향 등 타겟 유저를 정의합니다.
핵심 게임플레이 루프: 플레이어가 게임에서 반복적으로 경험할 핵심 활동은 무엇인지 정의합니다. (예: 탐험 -> 자원 수집 -> 제작 -> 건설 -> 생존)
장르 및 플랫폼: 어떤 장르(RPG, FPS, 퍼즐 등)이고, 어떤 플랫폼(PC, 모바일, 콘솔)에서 서비스할 것인지 결정합니다.

콘셉트 문서 (Concept Document)

핵심 아이디어를 바탕으로 좀 더 상세한 콘셉트 문서를 작성합니다.

게임 개요: 게임의 전체적인 모습과 플레이어 경험을 설명합니다.
핵심 판매 포인트 (Unique Selling Points, USP): 다른 게임과 차별화되는 요소는 무엇인가?
플레이어 캐릭터/아바타: 플레이어가 어떤 역할을 수행하며, 어떤 능력을 가지는가?
세계관 및 배경: 게임이 진행될 세계의 특징, 역사, 분위기 등을 설정합니다.
아트 스타일: 게임의 시각적 분위기와 스타일(카툰, 사실적, 픽셀아트 등)을 정합니다.
사운드/음악 콘셉트: 게임의 분위기에 맞는 사운드와 음악의 방향을 설정합니다.
잠재적 시장 분석: 유사 게임 분석, 경쟁사 분석, 시장 규모 등을 간략히 조사합니다.

Feasibility Study (실현 가능성 연구)

아이디어가 기술적, 예산적, 시간적으로 실현 가능한지 평가하는 중요한 단계입니다.

기술적 도전 과제: 구현하려는 기능 중 언리얼 엔진에서 구현하기 어려운 부분이 있는지, 어떤 기술적 제약이 있는지 파악합니다. (예: 대규모 월드 스트리밍, 복잡한 물리 시뮬레이션, 특정 네트워크 모델)
팀 역량: 현재 팀의 기술 스택과 인력으로 해당 게임을 만들 수 있는지 평가합니다. 필요하다면 외부 전문가나 새로운 팀원 충원을 고려합니다.
예상 개발 기간 및 비용: 콘셉트를 바탕으로 대략적인 개발 기간과 필요한 예산을 추산합니다.
리스크 분석: 프로젝트 진행 중 발생할 수 있는 주요 위험 요소(기술적 문제, 인력 이탈, 예산 부족 등)를 식별하고, 각 위험에 대한 완화 전략을 수립합니다.

설계 단계: 상세 계획 수립

기획 단계에서 수립된 콘셉트를 바탕으로, 게임의 각 시스템을 구체적으로 정의하는 단계입니다.

게임 디자인 문서

게임 디자인 문서 (Game Design Document, GDD)는 게임의 모든 시스템과 기능에 대한 상세한 청사진입니다.

변경 이유와 검증 결과에 따라 갱신하는 공통 기준 문서입니다.

핵심 게임플레이
- 코어 루프: 플레이어가 반복적으로 수행할 행동들을 더욱 상세히 정의합니다.
- 게임 모드: 싱글플레이어, 멀티플레이어, 협동, 경쟁 등 다양한 게임 모드를 설명합니다.
- 승리/패배 조건: 게임의 목표와 끝을 명확히 합니다.
캐릭터 / 엔티티
- 플레이어 캐릭터: 능력, 스킬, 성장 시스템, 커스터마이징 등을 상세히 정의합니다.
- NPC: 역할, AI 행동 패턴 (행동 트리, 스테이트 머신), 능력, 외형 등을 정의합니다.
- 적: 종류, 공격 패턴, 약점, 드롭 아이템 등을 정의합니다.
월드 / 레벨 디자인
- 맵 구조: 게임 세계의 전체적인 지형, 지역별 특징, 중요 지점 등을 계획합니다.
- 레벨 구성: 각 레벨의 목표, 난이도 곡선, 배치될 오브젝트, 이벤트 등을 상세히 설계합니다. (플레이 흐름은 플로우 차트, 제작 일정은 간트 차트로 구분)
- 내비게이션: AI 경로, 플레이어 이동 경로 등을 고려합니다.
시스템 디자인
- UI/UX: 인게임 UI (HUD), 메뉴 화면, 인벤토리, 상점 등 모든 UI 요소의 기능과 디자인을 설계합니다. 사용자 경험(UX) 흐름을 고려합니다.
- 컴뱃 시스템: 공격, 방어, 스킬 사용, 데미지 계산, 상태 이상 등을 상세히 정의합니다.
- 인벤토리/아이템 시스템: 아이템의 종류, 속성, 획득/사용/버리기 로직, 슬롯 수 등을 설계합니다.
- 퀘스트/미션 시스템: 퀘스트의 종류, 진행 방식, 보상, 연동되는 다른 시스템 등을 설계합니다.
- 세이브/로드 시스템: 어떤 데이터를 저장하고 언제 저장할 것인지, 오류 시 복구 방안 등을 설계합니다.
- 네트워크 시스템 (멀티플레이어): 네트워크 모델(클라이언트-서버, P2P), 동기화 방식, 지연 시간 처리, 치트 방지 등을 상세히 설계합니다.
- 경제 시스템 (있는 경우): 게임 내 재화, 인게임 구매, 화폐 유통 등을 설계합니다.
오디오/비주얼
- 사운드 이펙트: 어떤 상황에서 어떤 사운드가 재생될지, 사운드의 속성(볼륨, 피치) 등을 정의합니다.
- 음악: 배경 음악, 특정 이벤트 음악 등을 정의하고 분위기를 명시합니다.
- 시각 효과 (VFX): 파티클 효과, 후처리 효과 등을 정의합니다.
기술 스택: 언리얼 엔진의 어떤 기능(나나이트, 루멘, 행동 트리, Niagara 등)을 사용할 것인지, 외부 라이브러리/플러그인 사용 여부 등을 명시합니다.

기술 설계 문서

기술 설계 문서 (Technical Design Document, TDD)는 GDD를 기반으로, 개발팀이 실제로 구현할 기술적인 세부 사항을 다룹니다.

아키텍처 설계: 게임의 주요 시스템 간의 관계, 데이터 흐름, 모듈 구성 등을 정의합니다. (클래스 다이어그램, 컴포넌트 다이어그램 등)
데이터베이스 스키마: 필요한 데이터베이스의 구조, 테이블, 관계 등을 정의합니다.
네트워크 프로토콜: 멀티플레이어 게임의 경우, 클라이언트-서버 간 통신 프로토콜, 메시지 형식 등을 상세히 정의합니다.
성능 목표: 목표 프레임 속도, 메모리 사용량, 로딩 시간 등 구체적인 성능 목표를 설정합니다.
툴 및 워크플로우: 개발에 사용될 커스텀 툴, 에디터 확장 기능, 아트/애니메이션 파이프라인 등을 설계합니다.
빌드 및 배포 계획: 플랫폼별 빌드 과정, 업데이트 전략, 서버 인프라 계획 등을 명시합니다.

산출물	결정할 내용	검증할 질문
Concept	핵심 경험·대상·플랫폼	팀이 같은 게임을 설명하는가?
GDD	플레이 규칙·승패·콘텐츠 범위	기능이 핵심 경험을 지원하는가?
TDD	상태 소유자·모듈·성능 예산	구현 방식이 제약을 만족하는가?
Prototype	위험한 가정의 작은 실험	유지·수정·폐기할 근거가 있는가?

프로토타이핑 (Prototyping)

기획 및 설계 단계에서 불확실한 기술적 요소나 핵심 게임플레이 아이디어를 검증하기 위해 빠르고 간단한 프로토타입을 만들어 보는 것이 중요합니다.

목적: 핵심 게임플레이의 재미 검증, 기술적 난이도 평가, 아이디어 시각화.
진행 방식: 최소한의 리소스로 핵심 기능만 구현합니다. 검증하려는 질문과 무관한 UI·아트의 완성도는 낮춰도 됩니다. 가독성이나 조작감 자체를 검증한다면 해당 품질은 확보해야 합니다.
결과 활용: 프로토타입을 통해 얻은 피드백을 바탕으로 기획과 설계를 수정하고 개선합니다.

예시: 첫 완료 기준을 작은 관찰로 바꾸기

이 절의 목표를 GDD와 TDD에 나누어 적어 봅시다. GDD에는 최대 탄약 30·Pickup 지급량 10·실제 증가했을 때 한 번 소모·새 실행에서 탄약 숫자만 복원을 플레이 규칙으로 둡니다. TDD에는 Character가 현재값을 소유하고 Pickup은 증가를 요청하며, Controller가 HUD로 전달하고 GameMode가 최초 읽기·저장 요청을 관리한다는 연결을 적습니다. 저장 파일의 유무와 읽기 실패를 같은 새 게임으로 취급하지 않는 것도 구현 기준입니다.

프로토타입의 첫 확인은 새 슬롯의 0/30, 한 번 습득한 getter와 HUD의 10/30, 같은 슬롯을 읽은 새 실행의 10/30입니다. 각 확인에 실제 클래스·맵·슬롯·입력 조건을 함께 남깁니다. 보이는 숫자 하나만 확인하면 저장 파일과 캐릭터 상태가 연결됐는지 놓칠 수 있습니다. 아직 만들지 않는 전투·월드 저장·멀티플레이어는 이 완료 기준에 끼워 넣지 않습니다.

새 실행에서 저장 탄약 10을 복원한 뒤 레벨에 다시 나타난 Pickup을 주워 20이 됐습니다. 현재 설계의 실패인가요? 반대로 첫 실행의 저장 성공 표시만 보이고 새 실행의 복원을 확인하지 않았다면 작은 목표가 모두 완료됐나요? Pickup 소모 상태도 유지하라는 요구가 추가되면 무엇을 바꿔야 할까요?

원 범위의 완료와 새 요구를 구별하기

현재는 Pickup 소모·월드를 저장하지 않으므로 새 실행의 재습득과 10→20은 범위에 맞습니다. 저장 성공 표시만으로 새 실행 복원까지 완료됐다고 판정할 수는 없습니다. Pickup 소모도 유지하려면 저장할 상태와 재식별·복원 규칙, 새 실행에서의 배치·표시·습득 조건 및 확인 사례를 추가해야 합니다. 기존 포인터를 그대로 저장하거나 탄약 숫자만 늘리는 것으로 그 요구가 충족되지는 않습니다. 첫 목표의 조건은 유지하고 별도 확장으로 설계하세요.

애자일(Agile) 개발과 반복적인 설계

현대의 게임 개발은 예측 불가능한 요소가 많으므로, 처음부터 모든 것을 완벽하게 설계하기 어렵습니다.

반복적 설계: 초기 GDD는 고정된 것이 아니라, 개발 과정 중 피드백과 테스트 결과를 바탕으로 지속적으로 업데이트되고 개선됩니다.
스프린트(Sprint): 짧은 개발 주기(1~4주) 동안 특정 목표를 달성하고, 결과물을 검토하여 다음 스프린트 계획에 반영합니다.
문서의 유연성: 모든 것을 문서화하기보다, 핵심적인 부분에 집중하고 빠르게 변경될 수 있는 부분은 가볍게 유지합니다.

프로젝트 기획과 설계는 성공적인 게임 개발의 가장 중요한 첫걸음입니다.

명확한 핵심 아이디어를 구체화하고, 콘셉트 문서와 GDD를 통해 게임의 모든 측면을 상세하게 정의하며, TDD를 통해 기술적인 구현 계획을 수립해야 합니다.

또한, 실현 가능성을 평가하고 프로토타이핑으로 불확실한 가정을 찾아 위험을 줄입니다. 결과에 따라 목표와 설계를 다시 조정하세요.

이 기준이 잡혀야 이후 구현 단계에서 변경 비용을 줄일 수 있습니다.

프로젝트 기획과 설계에서는 범위, 핵심 루프, 기술 리스크, 검증 가능한 프로토타입 기준을 함께 점검합니다.