개발 도구와 엔진 선택하기

도구 선택은 완성 전략이다

개발 도구를 고를 때 가장 위험한 기준은 "요즘 많이 쓴다"이다. 좋은 엔진은 유행하는 엔진이 아니라 내 게임을 끝까지 만들 수 있게 해주는 환경이다. 같은 아이디어라도 어떤 엔진을 쓰느냐에 따라 구현 속도, 빌드 난이도, 필요한 컴퓨터 사양, 외주 인력 확보, 에셋 구매 가능성이 달라진다.

먼저 질문을 바꿔야 한다.

• 이 게임은 2D인가, 3D인가?

• 목표 플랫폼은 PC, 모바일, 웹, 콘솔 중 어디인가?

• 팀이 이미 다룰 줄 아는 언어와 툴은 무엇인가?

• 핵심 재미를 2주 안에 실행 가능한 빌드로 만들 수 있는가?

• 출시 직전 문제가 생겼을 때 해결할 자료와 커뮤니티가 충분한가?

엔진 선택은 취향 투표가 아니다. 앞으로 몇 달 동안 매일 열어야 할 작업장의 문을 고르는 일이다.

AI 생성 이미지

Unity, Unreal Engine, Godot 비교하기

Unity, Unreal Engine, Godot는 모두 인디게임 제작에 쓰인다. 하지만 잘 맞는 프로젝트가 다르다. Unity는 모바일과 크로스플랫폼, Unreal Engine은 고품질 3D, Godot는 가벼운 2D와 작은 팀의 빠른 반복에 강점이 있다는 평가가 많다. 다만 기능과 가격 정책은 계속 바뀌므로, 실제로 선택하기 전에는 반드시 각 엔진의 공식 페이지를 한 번 더 확인해야 한다.¹²³

첫 게임이라면 "무엇이 가장 강력한가"보다 "내가 가장 빨리 실패를 확인하고 고칠 수 있는가"가 중요하다. Unreal Engine의 그래픽은 강력하지만, 단순한 2D 퍼즐을 만들기 위해 무거운 3D 제작 환경을 감당할 필요는 없다. 반대로 사실적인 조명과 고품질 배경이 게임의 판매 포인트라면 Godot만으로 밀어붙이기 전에 목표 그래픽, 성능, 빌드 과정을 더 꼼꼼히 검증해야 한다.

간단한 기준은 다음과 같다.

• 2D 중심, 1인 개발, 빠른 반복: Godot 또는 Unity

• 모바일 출시, 광고·인앱결제·분석 도구 필요: Unity

• 고품질 3D 그래픽이 핵심 판매 포인트: Unreal Engine

• 이미 특정 엔진을 3개월 이상 써봤고 막히지 않는다: 그 엔진을 우선 검토

• 웹 기반 짧은 게임이나 매우 단순한 2D: Construct, GameMaker 같은 더 작은 도구도 후보

큰 엔진이 항상 좋은 선택은 아니다. 첫 게임의 목표는 엔진 기능을 모두 배우는 것이 아니라, 하나의 게임을 완성하는 것이다.

코딩 경험이 적을 때 도구를 쓰는 법

코딩이 약한 개발자는 비주얼 스크립팅, 템플릿, 에셋 스토어에 끌린다. 잘 쓰면 시간을 줄여준다. 그러나 잘못 쓰면 프로젝트가 남의 코드와 플러그인 위에 얹힌 불안정한 구조가 된다.

비주얼 스크립팅은 "코딩을 안 해도 된다"가 아니다. 코드를 글자로 쓰지 않을 뿐, 조건, 변수, 이벤트, 순서 제어는 그대로 필요하다. 노드가 10개일 때는 쉬워 보이지만, 노드가 200개가 되면 오히려 읽기 어려워진다. 핵심 규칙은 짧게 유지하는 것이다.

• 플레이어 이동

• 점수 계산

• 승패 판정

• 저장과 불러오기

• 인벤토리 같은 복잡한 데이터 처리

이런 기능은 나중에 반드시 수정된다. 그래서 최소한 "어디서 값이 바뀌는지"는 이해해야 한다. 복사해서 붙인 블루프린트나 노드를 설명할 수 없다면, 아직 내 기능이 아니다.

템플릿도 마찬가지다. 플랫폼 게임 템플릿, FPS 템플릿, RPG 템플릿은 시작을 빠르게 해준다. 하지만 템플릿의 구조를 모르면 게임을 템플릿에 맞춰 바꾸게 된다. 내가 만들고 싶은 게임이 아니라 템플릿이 허락하는 게임을 만들게 되는 것이다.

에셋 스토어를 사용할 때는 다음 네 가지를 확인한다.

1. 라이선스: 상업 게임에 써도 되는가? 크레딧 표기가 필요한가?

2. 엔진 버전: 현재 사용하는 버전에서 정상 작동하는가?

3. 수정 가능성: 색, 크기, 코드, 애니메이션을 바꿀 수 있는가?

4. 스타일 통일성: 다른 에셋과 섞어도 어색하지 않은가?

초보 팀은 플러그인을 많이 사는 것으로 제작 속도를 높이려 한다. 하지만 플러그인이 많을수록 업데이트 충돌도 늘어난다. 첫 게임에서는 외부 플러그인을 3개 이하로 제한하는 것이 안전하다. 특히 저장 시스템, 네트워크, 인앱결제처럼 게임의 뼈대가 되는 기능은 "샀으니 끝"이 아니라 "문제가 생기면 내가 추적할 수 있는가"를 기준으로 판단해야 한다.

버전 관리와 백업은 첫날부터 한다

많은 초보 개발자는 게임이 어느 정도 만들어진 뒤에 버전 관리를 도입하려고 한다. 늦다. 프로젝트가 작을 때 시작해야 습관이 된다.

실제 개발에서 자주 벌어지는 사고는 거창하지 않다.

첫 번째 사고는 노트북 고장이다. 한 달 동안 만든 프로젝트가 바탕화면 폴더 하나에만 있었다. 저장 장치가 망가지자 최신 파일을 복구하지 못했다. 남은 것은 친구에게 보낸 오래된 실행 파일뿐이다. 실행 파일은 소스가 아니다. 다시 개발할 수 없다.

두 번째 사고는 덮어쓰기다. 팀원이 최종, 최종_수정, 진짜최종 폴더를 주고받다가 누군가의 최신 작업을 오래된 파일로 덮었다. 누가 언제 무엇을 바꿨는지 기록이 없으니 복구도 어렵다.

세 번째 사고는 출시 직전 빌드 실패다. 에디터에서는 잘 돌아가는데 Windows 빌드나 Android 빌드가 실패한다. 원인은 엔진 버전 업데이트, 플러그인 충돌, 누락된 SDK, 잘못된 경로 설정일 수 있다. 이 문제를 출시 전날 처음 만나면 일정은 무너진다.

최소 환경은 다음 정도면 충분하다.

• Git 저장소를 만든다.

• GitHub, GitLab, Bitbucket 같은 원격 저장소에 올린다.

• 이미지, 사운드, 3D 모델처럼 큰 바이너리 파일은 Git LFS 사용을 검토한다.

• 엔진별 .gitignore를 적용해 임시 파일은 제외한다.

• 매주 한 번은 실행 가능한 빌드를 따로 보관한다.

• 프로젝트 폴더를 클라우드 동기화 하나에만 의존하지 않는다.

Git이 어렵다면 처음에는 "작업 전 커밋, 작업 후 커밋"만 기억해도 된다. 커밋 메시지는 길 필요가 없다.

• player movement added

• enemy collision fixed

• stage 1 clear condition added

중요한 것은 돌아갈 지점을 만드는 것이다. 버전 관리는 전문가만 쓰는 도구가 아니라, 실수를 되돌리기 위한 안전망이다.

빌드 환경도 초기에 확인해야 한다. 첫 주 안에 목표 플랫폼으로 빈 프로젝트라도 빌드해보자. Windows 게임이면 Windows 실행 파일을 만들고, Android 게임이면 실제 휴대폰에 설치해본다. "나중에 빌드하면 되겠지"라는 생각은 위험하다. 빌드는 개발의 마지막 단계가 아니라 개발 내내 반복해야 하는 확인 절차다.

엔진 버전도 마찬가지다. 최신 버전이 항상 가장 안전한 버전은 아니다. 출시까지 오래 걸리지 않는 첫 프로젝트라면, 중간에 큰 이유 없이 엔진을 올리기보다 안정적으로 빌드되는 버전을 정해두고 유지하는 편이 낫다.

그래픽, 사운드, 협업 도구는 최소 조합으로 시작한다

도구가 많아지면 작업이 전문적으로 보인다. 하지만 첫 프로젝트에서는 도구가 많을수록 관리할 것도 늘어난다. 파일 형식, 내보내기 설정, 폴더 구조, 버전 충돌이 모두 부담이 된다.

프로젝트 규모별 최소 조합은 다음처럼 잡을 수 있다.

무료 또는 저렴한 도구만으로도 첫 게임은 충분히 만들 수 있다. 문제는 도구의 가격보다 일관성이다. 예를 들어 2D 게임이라면 해상도, 타일 크기, 색상 팔레트, 파일 이름 규칙을 먼저 정해야 한다. 3D 게임이라면 모델 단위, 텍스처 크기, 폴리곤 수준, 애니메이션 내보내기 규칙을 정해야 한다.

사운드도 처음부터 복잡하게 갈 필요가 없다. 효과음은 짧고 명확하면 된다. 발걸음, 피격, 성공, 실패, 버튼 클릭처럼 플레이어 행동을 확인시켜주는 소리부터 넣는다. 배경음악보다 효과음이 먼저다. 조작 피드백이 없는 게임은 완성도가 낮게 느껴진다.

협업 도구는 하나로 줄인다. 대화는 Discord, 작업 관리는 Trello, 파일은 Git처럼 역할을 나눈다. 같은 내용을 카카오톡, 이메일, 노션, 구글 드라이브에 흩뿌리면 나중에 아무도 최신 결정을 찾지 못한다. 작은 팀일수록 "최종 결정이 적히는 장소"가 필요하다.

엔진을 정하기 전 마지막 체크리스트

도구를 고르기 전에 아래 질문에 답해보자.

• 이 엔진으로 목표 플랫폼 빌드를 직접 만들어봤는가?

• 핵심 조작을 1~2주 안에 구현할 수 있는가?

• 팀원 모두가 같은 버전의 엔진을 설치할 수 있는가?

• 필요한 에셋과 플러그인의 라이선스를 확인했는가?

• 문제가 생겼을 때 검색할 자료와 예제가 충분한가?

• 프로젝트 파일을 Git과 원격 저장소에 올릴 수 있는가?

• 그래픽·사운드 파일의 원본과 내보낸 파일을 구분해 보관할 수 있는가?

• 엔진 업데이트 없이도 출시까지 갈 수 있는 버전을 정했는가?

하나라도 답하기 어렵다면, 아직 도구 선택이 끝난 것이 아니다. 엔진은 한 번 정하면 바꾸기 어렵다. 개발 중반에 엔진을 갈아타는 것은 대부분 새 프로젝트를 시작하는 것과 비슷하다.

첫 게임에서는 강력한 도구보다 익숙한 도구가 낫다. 익숙하지 않더라도 가볍게 배울 수 있고, 빌드가 잘 되고, 문제가 생겼을 때 해결할 길이 보이는 도구가 좋다. 완성 가능한 게임은 화려한 엔진 소개 영상에서 나오지 않는다. 매일 조금씩 만들고, 저장하고, 빌드하고, 고치는 환경에서 나온다.

참고

¹Unity Plans & Pricing

²Unreal Engine licensing options

³Complying with licenses — Godot Engine documentation