DevDuck은 풀타임 소프트웨어 엔지니어로 일하면서 수년째 혼자 게임 Dolphin을 만들고 있다. 프로그래밍뿐 아니라 픽셀 아트와 음악까지 직접 하고, 개발 과정을 유튜브에 꾸준히 기록한다.
이 인터뷰에서 흥미로운 지점은 “어떻게 그렇게 부지런할 수 있는가”보다 오히려 장기 개인 프로젝트를 어떻게 삶 속에 남겨두는가에 있다. 그는 무작정 시간을 갈아 넣는 방식보다, 게임 개발을 계속 좋아할 수 있는 속도로 유지하는 것을 중요하게 여긴다.
1. 게임 개발은 두 번째 직업이 아니라 창작의 탈출구다
DevDuck에게 본업의 프로그래밍과 개인 게임 개발은 같은 코딩이어도 성격이 완전히 다르다.
본업에서는 요구사항과 티켓에 맞춰 정확하게 구현해야 한다. 반면 개인 프로젝트에서는 자신이 만들고 싶은 것을 자유롭게 실험할 수 있다. 그래서 게임 개발은 단순한 부업이 아니라 창작 욕구를 해소하는 공간에 가깝다.
그는 현재 게임 개발 시간의 상당 부분을 즐기고 있다고 말한다. 코드가 가장 재미있지만, 익숙하지 않은 픽셀 아트나 음악을 직접 완성했을 때의 만족도 크다. 잘 못하는 분야라고 외주부터 주기보다, 스스로 배우면서 프로젝트 전체에 자신의 취향을 넣는 것을 즐긴다.
이 태도는 솔로 개발의 장점과 단점을 동시에 보여준다.
- 코딩, 아트, 음악을 모두 직접 다뤄야 하므로 속도는 느리다.
- 대신 프로젝트 전체가 한 사람의 취향과 판단으로 일관된다.
- 각 분야에서 전문가 수준이 아니어도, 결과를 보고 무엇이 좋은지 판단하는 감각이 중요하다.
인터뷰에서는 이를 일종의 큐레이션 능력으로 표현한다. 모든 것을 최고 수준으로 직접 생산하는 능력보다, 어떤 결과가 게임에 어울리는지 선택하고 계속 다듬는 감각이 중요하다는 이야기다.
2. 출근 전 90분이 핵심 개발 시간이다
DevDuck의 평일 루틴은 상당히 단순하다.
그는 보통 오전 5시에 일어난다. 영상 작업이나 Dolphin 개발을 하다가 오전 7시쯤 운동을 하고, 아침 식사를 한 뒤 본업을 시작한다. 실제로 깊게 개발하는 시간은 대략 오전 5시 30분부터 7시까지 약 1시간 30분이다.
중요한 것은 하루에 엄청난 시간을 확보하는 것이 아니다. 오히려 가장 방해받지 않는 시간을 먼저 개인 프로젝트에 배정한다.
개발이 잘 풀리는 날에는 7시가 되어도 멈추기 어렵다. 거의 해결한 문제를 두고 운동하러 가야 할 때 특히 그렇다. 실제로 운동을 건너뛴 적도 있다고 한다. 그러나 기본 구조는 바꾸지 않는다.
이 방식에서 얻을 수 있는 핵심은 다음과 같다.
- 개인 프로젝트를 “남는 시간에 하는 일”로 두지 않는다.
- 하루 중 에너지가 가장 안정적인 시간대를 고정한다.
- 한 번에 오래 하기보다 매일 다시 프로젝트에 진입할 수 있게 만든다.
직장인 솔로 개발자에게 8시간짜리 개발일을 만드는 것은 현실적이지 않다. 대신 매일 다시 프로젝트를 여는 시스템을 만드는 쪽이 훨씬 중요하다.
3. ‘No Zero Days’ — 불씨를 꺼뜨리지 않는다
DevDuck이 장기 프로젝트를 유지하는 데 중요하게 생각하는 개념이 No Zero Days다.
그렇다고 매일 몇 시간씩 코딩해야 한다는 뜻은 아니다.
컨디션이 좋은 날에는 1시간 반 동안 몰입해서 구현한다. 피곤한 날에는 커피를 마시며 노트에 15분 정도 아이디어만 적기도 한다. 집중력이 거의 없는 날에는 미리 정리해둔 작은 버그 하나만 고칠 수도 있다.
핵심은 매일 프로젝트와 아주 조금이라도 접촉하는 것이다.
며칠, 몇 주 동안 완전히 멀어지면 다시 시작하는 심리적 비용이 커진다. 반면 작은 행동이라도 계속 이어가면 프로젝트가 머릿속에서 사라지지 않는다.
인터뷰에서는 이를 “pilot light를 계속 켜둔다”, 즉 보일러의 작은 불씨를 꺼뜨리지 않는 것에 비유한다.
장기 개인 프로젝트에서 연속성은 하루의 작업량보다 중요할 수 있다.
4. Dolphin이 5년 넘게 걸린 가장 큰 이유: 스코프 크리프
DevDuck은 프로젝트가 오래 걸린 이유를 꽤 솔직하게 인정한다.
초기에는 게임의 중심 설계가 명확하지 않았다. 샤워 중 떠오른 재미있는 아이디어를 곧바로 백로그에 넣고, 그것이 전체 게임과 어떤 관계가 있는지 충분히 고민하지 않은 채 구현하곤 했다.
그 결과 프로젝트의 범위가 계속 커졌다.
그는 이것을 사실상 scope creep에 당한 것이라고 표현한다.
솔로 개발의 위험한 점은 누구도 “그 기능은 만들지 말자”고 제지해주지 않는다는 것이다. 회사 프로젝트에서는 PM, 클라이언트, 일정, 예산이 자연스럽게 제약을 만든다. 혼자 만드는 게임에는 그런 장치가 없다.
그래서 최근에는 아이디어가 떠올라도 즉시 구현하지 않고 다음 질문을 거친다.
- 이 기능은 게임의 핵심 경험과 연결되는가?
- 기존 시스템과 어떤 의존성을 만드는가?
- 재미있어 보인다는 이유만으로 추가하는 것은 아닌가?
- 완성 시점을 얼마나 늦추는가?
좋은 아이디어를 많이 만드는 능력보다 좋은 아이디어를 버리는 능력이 완성에 더 중요하다는 이야기다.
5. 번아웃을 피하기 위해 일부러 느리게 간다
DevDuck은 본업과 개인 개발을 동시에 극단적으로 밀어붙였던 시기에 번아웃을 경험했다. 결국 긴 휴식이 필요했다.
그래서 지금은 의도적으로 자신의 속도를 조절한다.
저녁에 시간이 남아도 반드시 Dolphin을 만들지는 않는다. 게임을 하거나 그냥 쉬기도 한다. 외부에서 보면 개발 속도가 지나치게 느려 보일 수 있지만, 본인에게 가장 중요한 것은 프로젝트를 완전히 포기하지 않고 계속 이어가는 것이다.
이 지점은 “열심히 하면 빨리 완성된다”는 단순한 생산성 논리와 다르다.
개인 프로젝트는 며칠짜리 스프린트가 아니라 수년짜리 장거리 달리기가 될 수 있다. 너무 높은 강도로 달리다가 몇 달 쉬는 것보다, 감당 가능한 강도로 계속 가는 편이 실제 총 작업량에서는 더 많을 수 있다.
6. 유튜브는 마케팅보다 먼저 ‘책임 장치’였다
DevDuck이 유튜브를 시작한 이유도 흥미롭다.
그는 예전부터 게임 아이디어를 시작했다가 한두 달 뒤 새로운 아이디어로 갈아타는 패턴을 반복했다. 이번에는 무언가를 실제로 끝내고 싶었고, 다른 사람들에게 개발 과정을 공개하면 스스로에게 책임감이 생길 것이라고 생각했다.
즉 유튜브는 처음부터 성장 채널이나 수익 사업으로 시작한 것이 아니라 개인 프로젝트를 끝내기 위한 공개 로그였다.
결과적으로 채널은 예상보다 훨씬 크게 성장했다. 유튜브를 하면서 얻은 것도 많다.
- 개발을 계속할 외부적 동기가 생겼다.
- 댓글을 통해 반복적인 피드백을 받았다.
- 자신의 코드를 설명하기 위해 여러 번 녹화하면서 말하기 능력이 좋아졌다.
- 게임을 알릴 수 있는 잠재적인 플레이어층이 생겼다.
- 개발 과정 자체가 하나의 콘텐츠 자산이 됐다.
반면 인기가 커지면서 부정적인 댓글과 외부 평가에 적응해야 했다. 그래서 그는 유튜버라는 정체성이 자신의 중심이 되지 않도록 거리를 두는 편이다.
솔로 개발자에게 콘텐츠 제작은 단순 홍보 수단을 넘어 개발 지속성을 높이는 시스템이 될 수 있다는 점이 중요하다.
7. Dolphin은 어린 시절의 경험에서 출발했다
Dolphin의 핵심은 단순히 “바다를 탐험하는 게임”이 아니다.
DevDuck은 버지니아의 호수 근처에서 자랐다. 여름이면 수영, 스노클링, 카약, 낚시를 하며 거의 매일 물에서 살다시피 했다. 대학에 들어갈 때만 해도 해양생물학자가 되는 것을 생각했지만, 이후 컴퓨터과학과 프로그래밍 쪽으로 진로를 바꿨다.
그 경험이 Dolphin의 기반이 됐다.
게임에는 자연과 해양 생태계, 인간이 환경에 미치는 영향에 대한 문제의식이 들어 있다. 다만 이를 플레이어에게 직접 설교하기보다, 섬과 생물을 탐험하는 경험 속에서 자연스럽게 느끼게 하고 싶어 한다.
그에게 중요한 목표는 게임 개발자로 전업하는 것보다 우선 이 프로젝트를 완성해 세상에 내놓는 것이다.
8. 절차 생성은 플레이어에게 무한 랜덤 맵을 주기 위한 것이 아니다
Dolphin에는 절차 생성 기술이 들어가지만, 일반적인 로그라이크처럼 플레이할 때마다 섬이 랜덤 생성되는 구조는 아니다.
DevDuck은 큰 섬을 픽셀 아트로 처음부터 직접 그리는 데 어려움을 느꼈다. 그래서 Godot 안에서 파라미터를 바꾸면 섬의 기본 형태를 만들어주는 자체 툴을 작성했다.
이렇게 생성된 섬을 다시 수작업으로 수정해 최종 맵을 만든다.
따라서 최종 게임에서 모든 플레이어는 같은 섬을 본다.
그 이유도 명확하다. 그는 플레이어들이 같은 장소를 기억하고 이야기할 수 있기를 원한다. 랜덤 생성 월드가 주는 무한한 변화보다, Stardew Valley처럼 “모두가 알고 있는 장소”가 만들어내는 공동의 기억과 장소성을 더 중요하게 본다.
반면 물속 탐험에서는 실제 절차 생성을 활용한다.
플레이어가 특정 퀘스트 지점에서만 잠수하는 것이 아니라, 바다 어디서든 잠수할 수 있게 만들고 싶었기 때문이다. 플레이어가 잠수한 위치의 환경 정보에 따라 산호나 생물 등이 포함된 수중 장면을 생성한다.
즉 Dolphin은 절차 생성을 목적이 아니라 디자인 문제를 해결하는 도구로 사용한다.
9. Unity에서 Godot으로 옮긴 이유
DevDuck은 처음에는 Unity로 모바일 게임을 만들었다.
당시 Unity는 모바일 사례가 많았고 광고 플러그인과 학습 자료도 풍부했다. 하지만 더 큰 PC 프로젝트를 만들기로 하면서 엔진을 다시 평가했다.
Godot이 끌렸던 이유는 다음과 같다.
- 오픈소스다.
- 프로젝트가 매우 가볍고 빠르게 실행된다.
- 2D 작업이 엔진의 중심 기능으로 느껴진다.
- 픽셀 아트 기반 게임에 잘 맞았다.
- 라이선스나 수익 배분에 대한 부담이 적다.
- 노드와 씬 중심 구조가 직관적으로 느껴졌다.
반대로 Unity에서는 업데이트 이후 프로젝트가 깨지는 경험, 여러 세대의 시스템이 동시에 존재하는 복잡성, 렌더 파이프라인·입력 시스템처럼 같은 목적을 위한 여러 ‘공식 방식’이 존재하는 점에 피로를 느꼈다고 한다.
Godot이 모든 면에서 우월해서 옮긴 것이 아니라, 자신이 만들려는 2D 솔로 프로젝트의 성격과 더 잘 맞았기 때문에 선택한 것이다.
10. GDScript와 Godot의 씬 구조
DevDuck은 현재 GDScript를 선호한다.
C#에 익숙한 개발자라 처음 Godot을 평가했을 때는 .NET 계열 빌드를 사용했지만, 지금은 GDScript가 씬 트리와 노드 시스템에 밀접하게 통합되어 있다는 점을 장점으로 본다. 별도 IDE 대신 Godot 내장 스크립트 편집기도 사용한다.
Dolphin 프로젝트를 보면 하나의 섬 씬 아래에 카메라, 타일맵, 생물, 날씨 컨트롤러, 시간 컨트롤러, 스포너 등이 노드로 구성된다. 배 역시 자체적으로 큰 노드 트리를 가진 별도 씬이다.
Godot에서는 이렇게 작은 씬을 다시 더 큰 씬에 조합할 수 있다. Unity의 프리팹과 비슷한 면이 있지만, Godot에서는 “씬 자체가 재사용 가능한 구성 단위”라는 감각이 훨씬 강하다.
Dolphin의 날씨, 배, 수중 탐험, 생물 배치 같은 시스템도 이 구조 위에서 조립되어 있다.
11. 픽셀 아트에서 배운 가장 단순하지만 중요한 규칙
Dolphin의 초기 피드백 중 반복적으로 나온 것이 픽셀 크기를 통일하라는 것이었다.
예전 프로젝트에서는 서로 다른 크기의 픽셀이 섞여 있었지만, Dolphin에서는 모든 그래픽의 픽셀 크기를 의도적으로 맞춘다.
동시에 폭풍이 불 때 나무가 흔들리거나, 오브젝트와 상호작용할 때 미세하게 움직이는 셰이더 효과처럼 현대적인 연출도 일부 사용한다.
여기에서도 목표는 복고 그래픽을 그대로 복제하는 것이 아니다. 전체적인 시각 언어는 유지하면서, 플레이 감각을 좋아지게 만드는 효과는 선택적으로 받아들인다.
12. Godot의 약점도 분명하다
인터뷰 후반에는 Godot의 콘솔 지원 문제가 언급된다.
Godot은 오픈소스이기 때문에 Nintendo나 PlayStation처럼 비공개 SDK를 요구하는 플랫폼의 도구를 엔진에 그대로 포함하기 어렵다. 콘솔 출시를 위해서는 제3자 업체와 협력하거나 별도의 포팅 경로를 사용해야 할 수 있다.
이런 불확실성 때문에 어떤 개발자는 더 무겁고 복잡하더라도 Unity처럼 이미 여러 플랫폼 지원 체계가 확립된 엔진을 선택할 수 있다.
즉 엔진 선택은 철학이나 팬덤의 문제가 아니라 프로젝트의 요구사항과 리스크의 문제다.
솔로 개발자가 가져갈 만한 핵심
이 인터뷰를 솔로 개발자의 관점에서 압축하면 다음과 같다.
매일 많이 할 필요는 없다. 대신 자주 다시 들어가라
하루 15분이어도 프로젝트와 연결이 끊기지 않는 것이 중요하다.
가장 위험한 것은 구현 난이도보다 스코프다
혼자 만들 때는 모든 아이디어를 구현할 자유가 있다. 바로 그 자유가 완성을 방해할 수 있다.
재미를 잃으면 시스템 자체가 무너진다
개인 게임 개발은 본업과 다르다. 장기적으로 계속하려면 의도적으로 휴식과 여유를 남겨야 한다.
공개 개발은 강력한 책임 장치가 될 수 있다
유튜브, 블로그, 개발일지, 디스코드 등 무엇이든 “다른 사람에게 보여주는 구조”는 프로젝트 지속성에 도움이 된다.
도구는 목적에 맞춰 고른다
Godot, Unity, Unreal 중 무엇이 최고인가를 따지는 것보다 자신이 만들 게임의 규모, 그래픽 방식, 플랫폼, 팀 규모에 맞는지를 보는 편이 낫다.
완성하고 싶은 이유가 기술보다 중요하다
Dolphin이 오랫동안 살아남은 가장 큰 이유는 Godot이나 생산성 기법이 아니다. 어린 시절의 경험과 자연에 대한 관심처럼 DevDuck이 정말 표현하고 싶은 주제가 있기 때문이다.
수년짜리 프로젝트에서는 결국 그 이유가 다시 작업창을 열게 만든다.