완성 가능한 첫 게임 목표 세우기

첫 게임은 대표작이 아니라 완주 훈련이다

첫 게임을 만들 때 가장 흔한 실수는 "내가 정말 만들고 싶은 게임"으로 시작하는 것이다. 오픈월드, 성장 시스템, 온라인 협동, 다양한 무기, 긴 스토리, 보스전까지 넣고 싶어진다. 하지만 첫 프로젝트의 목적은 인생작을 만드는 것이 아니다. 끝까지 만들어 출시 가능한 형태로 닫는 경험을 얻는 것이다.

게임 개발은 생각보다 많은 작은 작업으로 이루어진다. 캐릭터가 움직이는 것만으로 끝나지 않는다. 시작 화면, 일시정지, 실패 처리, 재시작, 사운드, 옵션, 빌드, 버그 수정, 스토어 이미지, 설명문까지 필요하다. 그래서 초보 개발자는 처음부터 재미있는 아이디어보다 완성 가능한 크기를 먼저 정해야 한다.

첫 게임의 좋은 목표는 다음 문장으로 설명할 수 있어야 한다.

"이 게임은 5~15분 안에 핵심 재미를 경험할 수 있고, 한 가지 조작과 한 가지 규칙을 중심으로 끝까지 플레이할 수 있다."

이 기준에 맞지 않으면 아직 첫 게임으로는 너무 큰 편이다. 만들고 싶은 것을 포기하라는 뜻이 아니라, 첫 프로젝트에서 감당할 수 있는 크기로 잘라야 한다는 뜻이다.

AI 생성 이미지

현실적인 첫 프로젝트 범위

첫 프로젝트는 작아야 한다. 단순히 "작게 만들자"가 아니라 숫자로 제한해야 한다. 숫자가 없으면 개발 중에 기능이 계속 늘어난다. 처음에는 "스테이지 조금", "적 몇 종류", "짧은 플레이"라고 생각해도, 막상 만들다 보면 하나씩 붙어 결국 감당하기 어려운 크기가 된다.

초보 개발자에게 권장하는 첫 게임 범위는 다음과 같다.

예를 들어 플랫포머라면 "이동, 점프, 장애물 회피"까지만 첫 버전에 넣는다. 벽타기, 대시, 스킬 성장, 장비, 보스 패턴은 나중이다. 슈팅 게임이라면 "이동, 발사, 적 피하기"만으로 시작한다. 무기 강화, 탄막 패턴 20개, 캐릭터 해금은 첫 목표가 아니다.

처음에는 너무 짧아 보일 수 있다. 하지만 10분짜리 게임도 실제로 완성하려면 생각보다 많은 결정이 필요하다. 적이 어디에서 나오는지, 실패하면 어떻게 되는지, 난이도는 어떻게 올라가는지, 사운드는 언제 재생되는지, 마지막에 어떤 화면을 보여줄지 정해야 한다. 짧은 게임은 쉬운 게임이 아니라 끝까지 다듬을 수 있는 게임이다.

최소 완성 버전부터 정한다

개발 중 가장 위험한 말은 "이것도 있으면 좋겠다"이다. 좋은 아이디어처럼 보이지만, 대부분 일정과 체력을 빼앗는다. 그래서 첫 프로젝트에서는 기능을 세 가지로 나누어야 한다.

• 필수 기능: 없으면 게임이 성립하지 않는 기능

• 개선 기능: 있으면 좋아지지만 없어도 출시 가능한 기능

• 보류 기능: 언젠가 넣고 싶지만 이번 버전에서는 제외할 기능

예를 들어 2D 퍼즐 게임을 만든다고 하자.

여기서 중요한 것은 필수 기능을 아주 냉정하게 고르는 것이다. "내가 넣고 싶은 기능"이 아니라 "없으면 게임이 플레이되지 않는 기능"만 필수로 둔다. 첫 출시 버전은 부족해 보여도 괜찮다. 부족한 게임과 끝나지 않는 게임 중에서는 부족해도 완성된 게임이 낫다.

최소 완성 버전을 정할 때는 다음 질문을 사용하자.

• 이 기능이 없어도 플레이어가 시작하고 끝낼 수 있는가?

• 이 기능이 없어도 핵심 재미가 전달되는가?

• 이 기능을 넣으면 테스트해야 할 경우의 수가 크게 늘어나는가?

• 이 기능을 빼면 일정이 얼마나 줄어드는가?

• 출시 후 업데이트로 추가해도 늦지 않은가?

대답이 애매하면 일단 보류한다. 첫 프로젝트에서는 기능을 추가하는 능력보다 기능을 자르는 능력이 더 중요하다.

입문에 적합한 장르 비교

장르마다 쉬운 부분과 어려운 부분이 다르다. 겉보기에는 단순해 보여도 실제 제작 난이도는 다를 수 있다. 첫 게임 장르는 "내가 좋아하는 장르"와 "내가 완성할 수 있는 장르" 사이에서 선택해야 한다.

첫 프로젝트로 피하는 편이 좋은 형태도 있다. 온라인 멀티플레이, 대규모 RPG, 오픈월드, 복잡한 인벤토리와 장비 시스템, 정교한 물리 기반 게임은 초보자에게 부담이 크다. 이런 장르는 재미가 없어서가 아니라, 완성 전에 해결해야 할 문제가 너무 많기 때문이다.

만약 꼭 큰 장르를 만들고 싶다면 장르 전체를 만들지 말고 한 조각만 떼어내야 한다. RPG를 만들고 싶다면 마을, 필드, 던전, 장비, 퀘스트를 모두 만들지 않는다. "전투 한 번이 재미있는가?"만 검증하는 작은 전투 게임으로 시작한다. 로그라이크를 만들고 싶다면 수십 개 아이템이 아니라 방 5개와 아이템 3개만 만든다.

내 조건에서 규모를 역산하기

프로젝트 규모는 의욕이 아니라 조건에서 나온다. 사용할 수 있는 시간, 기술 수준, 예산을 먼저 보고 거꾸로 목표를 정해야 한다.

가장 단순한 계산은 다음과 같다.

실제 개발 가능 시간 = 주당 작업 가능 시간 × 개발 주수 × 0.6

여기서 0.6을 곱하는 이유는 모든 시간이 순수 개발에 쓰이지 않기 때문이다. 막히는 시간, 자료 찾는 시간, 버그 수정, 컨디션 저하, 일정 변경이 반드시 생긴다. 주당 10시간씩 8주를 쓸 수 있다면 80시간이 아니라 약 48시간을 실제 작업 시간으로 보는 편이 안전하다.

이 시간을 기준으로 작업을 배분한다.

48시간 프로젝트라면 핵심 기능 구현에 쓸 수 있는 시간은 약 17시간이다. 이 시간 안에 온라인 기능, 저장 시스템, 복잡한 AI, 컷신 연출을 모두 넣기는 어렵다. 그래서 목표를 줄여야 한다. 계산은 꿈을 꺾기 위한 것이 아니라, 완성 가능한 선택을 하기 위한 도구다.

기술 수준도 함께 봐야 한다. 아직 엔진 사용법을 배우는 단계라면 개발 시간의 절반 이상이 학습에 들어갈 수 있다. 이 경우 첫 게임 목표는 더 작아야 한다. 이미 간단한 프로토타입을 여러 번 만들어 봤다면 조금 더 복잡한 구조를 시도할 수 있다.

예산도 마찬가지다. 돈이 거의 없다면 직접 만들 수 있는 아트 스타일을 선택해야 한다. 픽셀 아트, 단색 도형, 무료 에셋, 간단한 아이콘 중심의 UI가 현실적이다. 예산이 조금 있다면 사운드, 폰트, 배경음악처럼 완성도를 빠르게 높이는 요소에 먼저 쓰는 편이 좋다. 단, 외주를 맡긴다고 해서 관리 부담이 사라지는 것은 아니다. 요청서 작성, 피드백, 수정 확인에도 시간이 든다.

첫 게임 목표 문장 만들기

이제 목표를 한 문장으로 줄여보자. 좋은 목표 문장은 장르, 기간, 플레이 시간, 핵심 행동, 콘텐츠 범위를 포함한다.

나쁜 예시는 다음과 같다.

"귀여운 캐릭터가 나오는 로그라이크 액션 RPG를 만들겠다."

무엇을 언제까지 얼마나 만들지 알 수 없다. 반면 좋은 예시는 이렇게 쓴다.

"8주 동안 2D 탑다운 방식의 5분 생존 슈팅 게임을 만들고, 적 3종과 무기 2종, 단일 맵 1개로 완성한다."

이 문장은 판단 기준이 있다. 적이 4종으로 늘어나면 범위 초과라는 것을 알 수 있다. 맵을 3개 만들고 싶어져도 첫 목표와 다르다는 것을 확인할 수 있다.

목표 문장을 만들 때는 다음 형식을 사용하자.

"나는 [기간] 동안 [장르/시점] 게임을 만들고, 플레이어가 [핵심 행동]을 통해 [플레이 시간] 안에 끝까지 경험할 수 있게 한다. 콘텐츠는 [스테이지/적/아이템 수]로 제한한다."

예시는 다음과 같다.

• "6주 동안 한 화면 퍼즐 게임을 만들고, 플레이어가 블록을 밀어 10분 안에 5개 스테이지를 클리어하게 한다."

• "4주 동안 2D 플랫포머를 만들고, 이동과 점프만으로 3개 짧은 스테이지를 통과하게 한다."

• "8주 동안 간단한 방치형 게임을 만들고, 자원 2개와 업그레이드 5개로 15분 안에 성장 흐름을 경험하게 한다."

목표가 작을수록 초라한 것이 아니다. 작아야 테스트하고 고칠 수 있다. 고칠 수 있어야 완성도가 생긴다.

범위 확장을 막는 규칙

개발 중에는 반드시 새 아이디어가 생긴다. 그 자체는 좋은 신호다. 하지만 모든 아이디어를 바로 넣으면 프로젝트가 무너진다. 그래서 처음부터 범위 확장 규칙을 정해둔다.

첫째, 새 기능은 바로 만들지 말고 "나중 목록"에 적는다. 둘째, 필수 기능이 모두 끝나기 전에는 개선 기능을 만들지 않는다. 셋째, 일정의 70% 지점에서 새 기능 추가를 멈춘다. 남은 30%는 버그 수정, 난이도 조절, 사운드, 빌드 문제 해결에 사용한다.

특히 마지막 20~30%를 가볍게 보면 안 된다. 게임은 기능이 작동한다고 완성되는 것이 아니다. 플레이어가 처음 실행했을 때 무엇을 해야 하는지 알 수 있어야 하고, 실패해도 다시 시작할 수 있어야 하며, 끝났다는 느낌을 받아야 한다. 이 마무리 작업이 없으면 거의 다 만든 게임도 미완성처럼 보인다.

새 아이디어가 정말 좋아 보인다면 목표 문장과 비교해 보자. 목표 문장 안에 없는 기능이라면 이번 버전의 필수 기능이 아닐 가능성이 높다. 이런 아이디어는 버리는 것이 아니라 보류하는 것이다. 첫 게임에서는 "언젠가 넣을 것"과 "지금 넣어야 할 것"을 구분하는 습관이 가장 큰 자산이 된다.

이번 장의 실행 체크리스트

첫 게임 목표를 정했다면 아래 항목을 확인하자.

• 전체 플레이 시간이 5~15분 안에 들어오는가?

• 핵심 시스템이 1~2개로 제한되어 있는가?

• 스테이지, 적, 아이템 수를 숫자로 정했는가?

• 필수 기능과 보류 기능을 분리했는가?

• 개발 가능 시간을 현실적으로 계산했는가?

• 일정의 최소 20~30%를 테스트와 마무리에 남겼는가?

• 목표 문장을 한 문장으로 설명할 수 있는가?

• 새 아이디어를 바로 넣지 않을 규칙이 있는가?

첫 게임의 성공 기준은 판매량이나 화려한 그래픽이 아니다. 정한 범위 안에서 시작, 플레이, 실패, 재시작, 클리어가 모두 가능한 형태로 닫는 것이다. 이 경험을 한 번 얻으면 다음 프로젝트에서 훨씬 정확한 판단을 할 수 있다.

첫 게임은 작게 끝내야 한다. 그래야 두 번째 게임을 더 잘 만들 수 있다.