HOUSE DUCK · KOREAN ORIGINAL
바이브코딩으로 게임 만들기, 내가 유니티 대신 Godot(고도)를 선택한 이유 | Quirky Ball
결론부터 말하자면,
Godot이 유니티보다 무조건 좋은 엔진이라서 선택한 건 아니다.
내가 가진 맥북에서,
혼자 AI와 게임을 만들고 계속 고쳐나가기에는
Godot이 가장 현실적이었기 때문이다.
나는 개발자가 아니다.
산업디자인을 전공했고,
게임 QA로 3년 정도 일했다.
그러다가 지금은 독일에서
Quirky Ball이라는 모바일 퍼즐게임을 만들고 있다.
유니티와 언리얼도 써봤다. 그런데 무거웠다.
게임을 만들겠다고 마음먹었을 때
유니티나 언리얼을 몰랐던 건 아니다.
둘 다 예전에 만져봤다.
정보도 많고,
완성된 게임도 셀 수 없이 많고,
좋은 엔진이라는 사실은 굳이 내가 증명할 필요도 없다.
문제는 내 상황이었다.
내가 가진 장비는 M2 맥북 에어다.
고성능 데스크톱도 아니고,
팀 단위로 큰 3D 게임을 만드는 것도 아니었다.
AI에게 수정을 요청하고,
엔진에서 바로 실행하고,
이상하면 다시 고치는 일을 하루에도 계속 반복해야 했다.
그런데 유니티와 언리얼은
내가 원하는 이 짧은 반복에서 꽤 무겁게 느껴졌다.
엔진을 켜는 것부터 부담스러우면
게임을 만드는 게 아니라
엔진을 모시는 기분이 들기 시작한다.
Godot은 내 맥북과 작업 방식에 잘 맞았다.
Godot을 처음 열었을 때 가장 먼저 든 생각은
의외로 별것 없다는 것이었다.
이건 단점처럼 들리지만,
나한테는 오히려 장점이었다.
프로젝트를 열고,
고치고,
실행하고,
결과를 확인하는 흐름이 빨랐다.
Quirky Ball은 거대한 3D 오픈월드 게임이 아니다.
세로 화면에서 구슬을 떨어뜨리고,
부딪히는 움직임과 UI를 계속 다듬는
2D 모바일 퍼즐게임이다.
그러니 내가 쓰지도 않을 거대한 기능보다
지금 고친 화면을 빨리 확인하는 편이 더 중요했다.
Godot 공식 문서에서도 macOS의 Apple Silicon을 지원 대상으로 명시하고 있다.
실제로 M2 맥북 에어에서 편집기와 게임을 오가며 작업하는 데 큰 불편이 없었다.
참고: https://docs.godotengine.org/en/4.7/about/system_requirements.html
System requirements
This page contains system requirements for the editor and exported projects. These specifications are given for informative purposes only, but they can be referred to if you're looking to buil...
docs.godotengine.org
바이브코딩과 Godot이 잘 맞았던 이유
내가 말하는 바이브코딩은
AI에게 “게임 하나 만들어줘”라고 말하고 끝내는 방식이 아니다.
Codex가 코드를 작성하면,
나는 직접 게임을 실행해본다.
버튼이 이상한지,
구슬 움직임이 재미없는지,
글자가 잘리는지,
처음 하는 사람이 규칙을 이해할 수 있는지를 본다.
그리고 다시 구체적으로 수정시킨다.
개발자 역할을 AI가 많이 가져갔다면,
나는 기획자와 디자이너,
그리고 QA 역할을 한 셈이다.
이 과정에서 중요한 건
한 번에 완벽한 코드를 받는 게 아니었다.
작게 수정하고,
빠르게 실행하고,
눈으로 확인하는 속도였다.
Godot은 그 반복을 덜 피곤하게 만들어줬다.
무료라는 점도 1인 개발자에게는 무시하기 어렵다.
Godot은 MIT 라이선스의 무료 오픈소스 엔진이다.
상업적으로 사용할 수 있고,
내가 만든 게임의 콘텐츠와 권리는 내 쪽에 남는다.
참고: https://godotengine.org/license/
License – Godot Engine
Godot Engine is free and open source software released under the permissive MIT license.
godotengine.org
물론 공짜라서 무조건 좋은 것은 아니다.
하지만 아직 수익이 없는 1인 개발자가
엔진 비용이나 정책 변경을 먼저 걱정하지 않아도 된다는 건
분명 마음이 편한 부분이었다.
그 돈과 신경을
게임을 한 번이라도 더 고치는 데 쓸 수 있으니까 말이다.
그렇다고 Godot이 모든 부분에서 편했던 건 아니다.
여기까지만 쓰면
무슨 Godot 전도사처럼 보일 수 있다.
하지만 모바일 게임을 실제로 출시하려고 하니
불편한 부분도 확실히 있었다.
광고,
인앱결제,
로그인,
Android와 iOS의 네이티브 기능은
게임 화면 하나 만드는 것과는 전혀 다른 문제였다.
플러그인 버전을 맞추고,
각 플랫폼에서 따로 확인하고,
엔진 안에서는 멀쩡한데 실제 기기에서는 다른 문제를 찾는 일이 반복됐다.
유니티처럼 사용자가 훨씬 많은 엔진과 비교하면
막혔을 때 바로 맞아떨어지는 자료를 찾기 어려운 순간도 있었다.
AI가 코드를 대신 써준다고 해서
이런 문제까지 마법처럼 사라지는 건 아니었다.
오히려 내가 모르는 코드가 빠르게 늘어나는 만큼
직접 실행하고 확인하는 QA가 더 중요해졌다.
그래도 다시 Quirky Ball을 만든다면 Godot을 고를까?
이 게임이라면 다시 고를 것 같다.
정확히는,
M2 맥북 에어 한 대로
AI와 함께 2D 모바일 게임을 빠르게 만들고 고치는 조건이라면 그렇다.
반대로 대규모 3D 게임이나,
특정 상용 SDK를 잔뜩 붙여야 하는 프로젝트라면
나도 다른 엔진을 먼저 비교할 것이다.
엔진 선택은 종교가 아니다.
유명한 엔진을 고르는 문제가 아니라
내가 끝까지 만들 수 있는 엔진을 고르는 문제에 가깝다.
나에게 그 답이 Godot이었다.
그리고 지금은
엔진을 골랐다는 사실보다
Quirky Ball을 실제로 출시하는 것이 훨씬 중요하다.
자주 묻는 질문
- 코딩을 몰라도 Godot으로 게임을 만들 수 있나?
AI의 도움으로 시작 장벽은 많이 낮아졌다.
다만 코드를 전혀 보지 않아도 된다는 뜻은 아니다.
무엇이 잘못됐는지 설명하고,
직접 실행해서 결과를 판별하는 능력은 여전히 필요하다.
- 바이브코딩에는 Godot이 가장 좋은가?
프로젝트마다 다르다.
나는 가벼운 2D 모바일 게임과 빠른 반복 작업 때문에 Godot을 골랐다.
에셋 생태계나 특정 SDK가 더 중요하다면 Unity가 더 편할 수도 있다.
- M2 맥북 에어로 Godot 게임 개발이 가능한가?
Quirky Ball 같은 2D 모바일 게임은 충분히 작업할 수 있었다.
다만 이건 내 프로젝트 기준의 경험이다.
무거운 3D 그래픽과 빌드 규모가 커지면 결과는 달라질 수 있다.
다음 글에서는
산업디자인 전공자인 내가 왜 게임 에셋을 직접 하나도 만들지 않았는지,
그런데도 어떤 방식으로 Quirky Ball의 디자인을 완성해갔는지 적어보려고 한다.