Godot을 100시간 써보고 느낀 장단점 — Unity 사용자 관점의 솔직한 사용기

이 글은 한 개발자가 Godot을 주력 엔진으로 약 100시간 사용한 뒤 정리한 경험담을 한국어로 재구성한 것이다.

중요한 전제가 하나 있다. 원본 영상은 Godot 4.0 이전 시점의 경험을 바탕으로 한다. 영상 제작자 역시 자신이 지적한 여러 문제가 이미 Godot 4.0에서 바뀌고 있거나 이후 해결될 수 있다고 반복해서 강조한다. 따라서 아래 내용은 최신 Godot의 절대적인 평가가 아니라, 당시 한 Unity 사용자가 Godot을 배우면서 실제로 무엇을 편하게 느꼈고 어디에서 막혔는지를 보는 자료로 읽는 편이 좋다.

1. 왜 100시간을 따로 투자했나

제작자는 Unity를 중심으로 게임 개발을 배우고 있었고, Godot도 예전부터 잠깐씩 만져봤다. 하지만 Unity, Unreal, Godot을 동시에 익히려 하니 어느 것도 제대로 배우기 어려웠다.

그래서 다른 엔진 학습을 잠시 멈추고 Godot에 100시간을 집중 투자하기로 했다.

그 시간 동안 단순히 튜토리얼만 본 것이 아니라 다음을 직접 해봤다.

여러 튜토리얼 따라하기
작은 프로토타입 제작
게임잼 참가
기존 게임의 간단한 리메이크
2D와 3D 실험
VR 관련 테스트

그 과정에서 계속 메모를 남겼고, 이 영상은 그 기록을 정리한 결과다.

2. 첫인상: Godot은 놀라울 정도로 가볍고 명확하다

제작자가 Godot에서 가장 먼저 좋아한 것은 기능 목록보다 프로그램 자체의 사용감이었다.

실행이 빠르고, 프로젝트도 빠르게 열린다. 인터페이스는 비교적 작고 정돈되어 있으며 각 오브젝트와 노드가 색상과 아이콘으로 구분된다.

Unity에서는 이미 알고 있는 메뉴가 아니라면 잘못 건드릴까 조심하게 되는데, Godot에서는 인터페이스만 훑어봐도 무엇이 어디에 있는지 어느 정도 이해되는 느낌을 받았다고 한다.

특히 다음과 같은 작은 UX 요소를 높게 평가한다.

값이 기본값에서 바뀌면 리셋 버튼이 나타난다.
어떤 노드에 스크립트가 붙어 있는지 쉽게 보인다.
토글이 켜졌는지 꺼졌는지 명확하다.
라벨과 입력값의 관계가 보기 쉽다.
노드의 종류와 계층이 시각적으로 잘 구분된다.

이런 특성 때문에 새로운 기능을 실험하다가 망가뜨릴 것 같은 두려움이 적다.

제작자는 Godot의 장점을 한마디로 clarity, 즉 명확성이라고 표현한다.

3. 노드와 씬 구조는 처음에는 낯설지만 금방 강점이 된다

Unity에서는 거의 모든 것이 GameObject이고, 여기에 Component를 붙여 기능을 만든다.

Godot에서는 모든 것이 Node를 중심으로 구성된다. 그리고 여러 노드의 묶음을 Scene으로 저장해 다시 사용할 수 있다.

처음에는 이 구조가 낯설지만, 익숙해지면 상당히 자연스럽게 느껴졌다고 한다.

각 노드가 역할을 명확하게 가지고 있기 때문이다.

예를 들어 캐릭터 하나를 만들더라도 이동, 충돌, 스프라이트, 카메라, 애니메이션 등을 서로 다른 노드로 구성하고 이를 트리 형태로 묶을 수 있다.

Unity의 컴포넌트 시스템과 완전히 다른 철학이라고 보기는 어렵지만, Godot에서는 계층 구조 자체가 설계의 중심에 훨씬 가까운 느낌을 준다.

4. 에디터는 빠르고 편하지만 실시간 디버깅은 아쉽다

Godot 에디터의 반응 속도와 전반적인 사용성은 좋은 평가를 받는다.

다만 Unity에서 익숙했던 일부 기능은 그리웠다고 한다.

대표적으로 플레이 중 Scene View를 보며 오브젝트를 직접 움직이고 변화를 확인하는 흐름이다. Godot에도 실행 중 노드를 확인하는 Remote Scene 기능이 있지만, 제작자가 사용한 버전에서는 Inspector를 통한 값 조정에 더 가까웠고 Unity만큼 시각적으로 즉각적인 디버깅 경험을 주지는 못했다.

그래서 문제가 생겼을 때 print_debug 같은 출력 기반 디버깅을 자주 사용하게 됐다고 한다.

5. GDScript는 전반적으로 좋지만 자동완성은 큰 불만이었다

GDScript 자체에 대한 최종 평가는 긍정적이다.

언어가 단순하고 Godot 구조와 밀접하게 연결되어 있으며, 작은 게임을 빠르게 만드는 데 잘 맞는다.

하지만 영상 당시 자동완성 기능은 상당한 불만 요소였다.

Unity와 Visual Studio에서는 몇 글자만 입력해도 메서드, 변수, 타입 등 가능한 후보가 풍부하게 나타나고 각각이 무엇인지 비교적 명확하게 알 수 있다. 반면 Godot에서는 다음과 같은 문제가 있었다고 한다.

자동완성 목록에서 자주 쓰는 항목을 찾기 어렵다.
작은 오타가 있으면 추천이 거의 사라진다.
메서드인지 변수인지 명확하지 않을 때가 있다.
다른 노드의 멤버를 참조할 때 자동완성이 안정적으로 나오지 않는다.
때로는 코드를 다시 입력해야 추천 목록이 나타난다.

결국 “Godot에 당연히 있어야 할 기능이 없는 줄 알았는데, 검색해보니 실제로는 있었다”는 경험을 여러 번 했다고 한다.

즉 기능 부족보다 기능 발견성이 문제였던 경우도 많았다.

6. 노드 참조 방식도 당시에는 불편하게 느껴졌다

Unity에서는 public 변수나 직렬화된 필드에 오브젝트를 드래그해서 넣는 흐름이 흔하다.

제작자가 사용한 Godot 버전에서는 다른 노드를 가져오기 위해 계층을 따라 get_parent()나 get_node()를 사용하는 일이 많았고, exported NodePath 방식도 타입 안정성이나 편의성 면에서 아쉽다고 느꼈다.

그래서 필요한 노드 참조를 한곳에 모으는 AutoLoad 싱글턴을 직접 만들어 사용하기도 했다.

다만 영상에서도 이 부분은 곧 개선될 기능을 소개받았다고 언급한다. Godot은 빠르게 바뀌고 있어 불만을 정리하는 동안에도 기능이 개선된다는 점을 여러 번 강조한다.

7. 변수와 API 이름에는 일관성이 부족하게 느껴지는 부분이 있었다

제작자는 Unity와 비교하면서 Godot API의 일부 이름이 직관적이지 않다고 느꼈다.

예를 들어 2D와 3D에서 위치를 다루는 방식이나 로컬/글로벌 좌표를 표현하는 이름이 서로 달라 처음 배우는 입장에서는 헷갈릴 수 있었다.

또 특정 메서드의 반환값을 사용하지 않거나, 기본 제공 인자를 사용하지 않을 때 경고가 나타나는 방식도 처음에는 번거롭게 느꼈다.

다만 이런 부분은 대부분 엔진에 익숙해지면 적응할 수 있는 수준의 불편으로 본다.

8. Signals는 Godot 코딩 경험의 강력한 장점

반대로 Signals는 매우 높게 평가한다.

Signal은 어떤 노드에서 사건이 발생했다는 것을 다른 노드에 알리는 방식이다.

예를 들어 다음과 같은 이벤트를 전달할 수 있다.

타이머가 끝났다.
충돌이 발생했다.
애니메이션이 끝났다.
버튼이 눌렸다.

이를 에디터에서 다른 메서드와 연결할 수 있어 노드끼리 직접 강하게 참조하지 않아도 된다.

제작자는 객체들이 서로 손을 잡고 있어 하나가 무너지면 다른 객체까지 끌려가는 구조를 강한 결합으로 설명하고, Signal은 필요한 순간에 “하이파이브만 하고 헤어지는 것”에 비유한다.

Godot의 노드 구조와 Signal을 함께 사용하면 느슨하게 결합된 시스템을 만들기 쉬워진다는 것이 큰 장점이다.

9. 물리 시스템: 쓸 수는 있지만 감각적으로 불안정한 순간이 있었다

물리 시스템에 대한 평가는 혼합되어 있다.

작은 스케일에서 충돌이 미세하게 떨리거나, 충돌 관련 Signal이 기대대로 작동하지 않는 경우를 경험했다. Unity에서 만들었던 이동과 발사 물리를 Godot으로 옮겼을 때도 아무리 조정해도 움직임의 감각이 조금 이상하게 느껴졌다고 한다.

다만 본인 설정 문제일 가능성도 인정한다.

반대로 인상적이었던 기능도 있다.

비볼록 형태의 Collider를 물리 객체에서 사용했는데 예상보다 안정적으로 작동했고, 움직이는 우주선 위에서 캐릭터가 뛰어다니는 장면도 큰 문제 없이 구현할 수 있었다.

불편한 부분은 주로 코드 측면이었다.

_physics_process와 _integrate_forces처럼 물리 값을 다루는 위치가 나뉘며, 어떤 값은 한쪽에서만 정상적으로 바꿀 수 있어 처음에는 혼란스러웠다고 한다.

10. 3D 에디터 조작은 의외로 마음에 들었다

제작자는 Godot의 3D 기능에 대해 예상보다 긍정적으로 평가한다.

에디터 카메라 움직임은 Unity보다 덜 부드럽게 느껴졌지만, 오히려 시작과 정지가 명확해 원하는 오브젝트를 지나쳐버리는 일이 적었다. 대부분의 조작 방식도 Editor Settings에서 변경할 수 있다.

오브젝트 선택 방식도 좋게 본다.

선택 모드가 분리되어 있어 실수로 다른 오브젝트를 잡을 일이 적다.
한 위치에 겹친 여러 오브젝트 목록을 열어 선택할 수 있다.
자식의 Mesh나 Collider를 클릭해도 부모를 선택하도록 설정할 수 있다.
위치, 회전, 스케일 스냅 기능이 있다.
바닥에 맞춰 배치하는 기능도 유용하다.

11. WorldEnvironment와 셰이더는 창작 욕구를 자극한다

후처리, 톤 매핑, 안개, 환경 관련 기능은 WorldEnvironment 노드에 모여 있다.

셰이더에서도 투명도, 그림자, unshaded, triplanar mapping, diffuse/specular 모드, billboard, 거리 기반 fade 등 다양한 옵션을 쉽게 찾을 수 있었다.

제작자는 모든 기능이 반드시 필요한 것은 아니지만, 기능이 눈에 잘 보이기 때문에 “이걸 한번 써보고 싶다”는 생각이 든다고 말한다.

즉 Godot의 3D 기능은 단순히 기능을 제공하는 데서 끝나지 않고 실험을 유도하는 UI를 가진다는 점을 좋아했다.

VR 역시 깊게 사용하지는 않았지만, 간단한 테스트 수준에서는 비교적 쉽게 작동했다고 한다.

12. 3D 자산 Import 과정은 번거로웠다

3D 쪽에서 가장 불편했던 부분 중 하나는 모델 Import와 재Import였다.

모델을 가져온 뒤 별도의 씬으로 열고 저장하고, 다시 실제 게임 오브젝트의 자식으로 붙이는 식의 과정이 필요해 파일 구조가 복잡해질 수 있었다.

모델 파일을 수정해 다시 가져왔을 때 에디터와 게임에 변경사항이 반영되기까지 시간이 걸리는 경우도 있었다.

더 번거로운 점은 Mesh에서 만든 Collision이었다.

모델이 바뀌어도 기존 Collision이 자동으로 다시 만들어지지 않아 직접 재생성해야 했다.

반면 현재 씬과 자식 노드를 glTF로 Export하여 Blender에서 참고 모델로 사용할 수 있는 기능은 매우 유용하게 평가한다. 플랫폼 게임을 만들 때 Godot에서 먼저 거리와 크기를 테스트한 뒤 씬을 Blender로 가져가 모델링 기준으로 사용했다고 한다.

13. 2D는 Godot의 DNA에 들어 있는 느낌

2D에 대한 평가는 매우 좋다.

Unity의 2D가 기존 3D 엔진 위에 추가된 기능처럼 느껴지는 반면, Godot은 처음부터 2D를 중요한 사용 사례로 고려한 엔진처럼 느껴졌다고 한다.

특히 저해상도·픽셀 스타일 게임에서 화면 스케일링 설정이 편리했다.

게임을 낮은 내부 해상도로 렌더링하면서 모니터 전체를 채우는 방식이 2D와 3D 모두에 자연스럽게 적용된다. 픽셀 스타일 게임에서 모든 요소를 같은 해상도 감각으로 유지하기 좋았다.

14. UI 시스템은 기능이 많지만 복잡하다

Godot의 UI는 Control 계열 노드를 중심으로 구성된다.

버튼, 슬라이더, 스크롤바, 진행바, 리스트, 탭, 비디오 플레이어, 각종 Container 등 선택지가 매우 많다.

기본 기능을 빠르게 만들 때는 편했지만, Anchor, Margin, Grow Direction 등 배치와 반응형 크기 조절을 세밀하게 건드리기 시작하면 복잡하게 느껴졌다.

제작자 스스로 UI 설계를 원래 어려워한다고 인정하기 때문에 이 부분을 Godot만의 문제라고 단정하지는 않는다.

그럼에도 이전에는 메뉴 제작 자체를 거의 하지 않을 정도로 싫어했는데, Godot에서는 UI를 만드는 과정이 꽤 재미있었다고 한다.

15. 문서 자체보다 ‘검색했을 때 나오는 답의 양’이 약점이었다

Godot 공식 문서를 무조건 나쁘다고 보지는 않는다.

설명량이 부족하거나 세부 기능이 빠진 곳이 있지만, 다른 게임 엔진 문서도 비슷한 문제가 있다고 본다. 오히려 구조는 잘 정리되어 있고 웹 검색으로 원하는 페이지를 찾기 쉽고, Godot 에디터 안에서도 관련 문서를 바로 열어볼 수 있어 편리했다.

진짜 차이는 커뮤니티 규모에서 느꼈다.

Unity는 문제가 생기면 검색 결과가 매우 많이 나오지만, Godot은 특히 3D 관련 질문에서 다음 문제가 있었다.

답변이 없는 글이 많다.
예전 버전을 기준으로 한 답변이 나온다.
잘못된 답변도 있다.
검색하면 Godot보다 Unity 해결책이 더 많이 보인다.

그래도 결국 원하는 기능을 구현할 방법은 대부분 찾았다고 한다.

검색으로 해결되지 않을 때는 Discord 커뮤니티에서 도움을 많이 받았으며, Godot 커뮤니티가 초보자에게 상당히 친절하고 지원적이라는 인상을 받았다.

16. 튜토리얼은 Unity보다 적지만 학습에는 충분했다

Godot 튜토리얼의 절대량은 Unity에 비할 수준은 아니지만, 엔진을 익히기에는 충분했다고 평가한다.

초반에는 GDQuest의 3D 입문 자료와 HeartBeast의 Action RPG 시리즈 등을 활용했고, 이후에는 필요한 기능이 생길 때마다 셰이더, 저장·불러오기 같은 개별 주제를 찾아보는 식으로 학습했다.

다른 엔진 경험이 있었기 때문에 튜토리얼 중심의 학습 기간은 비교적 짧았다.

17. 플랫폼 Export: 데스크톱은 괜찮고 콘솔은 구조적 제약이 있다

영상 당시 경험 기준으로 Windows Export는 매우 좋았다고 한다. 파일 몇 개만으로 실행 가능한 빌드가 만들어지는 단순함에 놀랐다.

Linux 빌드도 게임잼에서 별다른 문제 제보를 받지 않았다.

반면 macOS에서는 그래픽 효과가 많아질수록 문제가 생기는 경우가 있었고, WebGL 역시 무거운 그래픽 설정에서는 불안정했다. 특히 자신의 테스트에서는 Mac과 WebGL 조합에서 게임이 제대로 실행되지 않는 문제를 겪었다.

콘솔은 다른 문제다.

Godot이 오픈소스인 반면 콘솔 SDK는 보통 NDA와 비공개 조건을 요구한다. 이 때문에 Godot 본체에 PlayStation이나 Nintendo의 비공개 SDK를 그대로 포함시킬 수 없다.

따라서 콘솔 출시가 불가능한 것은 아니지만, 개발자가 플랫폼사와 직접 계약하거나 별도의 포팅 업체와 협력하는 과정이 필요할 수 있다.

18. 결론: 불평을 많이 했지만 가장 계속 쓰고 싶은 엔진이었다

영상의 결론은 의외로 단순하다.

제작자는 Godot을 매우 좋아한다.

영상 절반 가까이를 단점 이야기로 채웠지만, Unity보다 Godot에서 자신의 프로젝트를 더 잘 통제하고 있다는 느낌을 받았다.

Unity에서는 패키지, deprecated 기능, 서로 겹치는 여러 시스템 때문에 프로젝트가 취약하게 느껴졌다. 어느 날 프로젝트를 열었을 때 기존 기능이 깨지거나 다른 시스템으로 교체되어 있을 것 같은 불안감이 있었다.

Unreal은 본인의 컴퓨터와 머리가 감당하기에는 너무 크고 복잡하게 느껴졌다.

반면 Godot은 다음 이유로 계속 쓰고 싶었다.

작고 빠르다.
인터페이스가 명확하다.
워크플로가 단순하다.
자신의 게임을 직접 통제하고 있다는 느낌이 든다.
오픈소스 프로젝트라 사용자와 개발자 사이의 거리가 가깝게 느껴진다.
커뮤니티가 친절하고 협력적이다.

특히 “소프트웨어를 만드는 사람과 쓰는 사람이 같은 공동체 안에 있다”는 감각을 중요하게 본다.

1인·인디 개발자 관점에서 읽을 때 중요한 점

이 100시간 사용기의 핵심은 “Godot이 Unity보다 좋다”가 아니다.

오히려 엔진을 선택할 때 무엇을 중요하게 보는지가 사람마다 얼마나 다른지를 잘 보여준다.

대형 스튜디오의 방대한 기능과 검증된 파이프라인이 필요한 개발자에게는 제작자가 단점으로 느낀 Unity의 복잡성이 오히려 장점일 수 있다. 반대로 작은 팀이나 1인 개발자에게는 빠른 실행, 단순한 구조, 2D 친화성, 라이선스 자유도가 더 중요한 가치가 될 수 있다.

또 하나 중요한 점은 100시간 정도는 써봐야 엔진의 진짜 장단점이 보이기 시작한다는 것이다.

첫날의 인상이나 기능 비교표보다, 실제로 작은 게임 하나를 끝까지 만들어보면서 다음을 확인하는 편이 훨씬 유용하다.

내가 가장 자주 하는 작업이 편한가?
디버깅할 때 스트레스가 적은가?
프로젝트 구조가 머릿속에 잘 들어오는가?
필요한 자료를 찾을 수 있는가?
배포하려는 플랫폼을 지원하는가?
몇 달 뒤에도 이 프로젝트를 내가 이해할 수 있을 것 같은가?

결국 좋은 엔진은 가장 많은 기능을 가진 엔진이 아니라, 내가 실제 게임을 끝까지 만들 수 있게 해주는 엔진이다.