처음에는 간단한 게임 하나도 오래 걸렸어요
더 게이트를 만들기 전에도 여러 사이드 프로젝트를 진행했는데요. 특히 2024년 무렵 AI 두들 디자인에서 소기의 성과를 얻으면서, 조금 더 복잡한 프로젝트도 해볼 수 있겠다는 생각이 들었어요. 그러다 오래 미뤄뒀던 게임 만들기가 떠올랐습니다.
30년 넘게 게임을 해왔으니 취향은 꽤 분명했어요. 여기에 프로덕트 디자이너로 일하면서 쌓은 경험을 더하면 어떨까 싶었습니다. 플레이어가 무엇을 선택하고 어떤 보상을 받는지, 다음에는 무엇을 하고 싶어질지 제 방식으로 설계해보고 싶었거든요.
2024년에는 게임 엔진 Godot과 그록을 활용해 개발을 시작했습니다. 막상 해보니 당시 제가 AI와 함께 할 수 있는 일은 많지 않더라고요. 아주 간단하게 돌아가는 게임 하나를 만드는 데도 엄청나게 오래 걸렸어요. 그렇게 한 번 해본 경험으로 끝날 뻔했죠.
다음 해에는 Figma Make를 만나 다시 시도했습니다. 이번에는 꽤 그럴듯한 미니 게임을 만들 수 있었어요. 분명 전보다 나아졌지만, 제 세계관을 담고 긴 플레이 시간 동안 계속 재미를 느낄 만한 게임까지 만들기는 여전히 어려워 보였어요.
Fable로 만든 첫 프로토타입은 달랐어요
2026년에 클로드의 Fable을 활용한 여러 사례를 접하면서 다시 해볼 때가 왔다고 느꼈는데요. 이번에는 상세하게 설계하면 제대로 된 게임을 만들 수 있겠다는 기대가 생겼어요. 클로드와 대화하면서 설계 문서를 다듬고 첫 프로토타입을 만들었습니다.
처음 플레이했을 때는 정말 인상적이었어요. 공격하고, 회피하고, 적의 공격을 받아치는 패링도 할 수 있었거든요. 제가 주문한 보스가 나오고, 쓰러뜨리면 보상까지 이어졌고요. 그래픽은 부족했지만 머릿속으로 그리던 전투를 직접 해보고 있었어요.
그때부터 제가 원하는 게임으로 조금씩 살을 붙였어요. 이 무렵에는 실무에서도 AI를 적극적으로 활용하고 실제 코드에 기여하고 있었는데요. 어떻게 설명하고 무엇을 확인해야 원하는 결과에 가까워지는지 겪어본 경험이 게임을 만들 때도 도움이 됐습니다.
제가 만들고 싶었던 게임은 우리가 사는 현대의 도시에서 시작합니다. 세계 곳곳에 정체를 알 수 없는 게이트가 나타나고, 그 안에서 몬스터들이 나와요. 주인공은 사람들을 돕고 지역의 보스를 물리치면서 게이트가 왜 나타났는지 조금씩 알아갑니다.
귀여운 픽셀 캐릭터로 싸우되, 여러 번 플레이할수록 처음에는 보이지 않았던 이야기가 드러나면 좋겠다고 생각했어요. 전투가 재미있어서 시작했다가 이 세계가 궁금해서 더 해보게 만들고 싶었거든요.
처음 프로토타입에서 지금 모습까지 오는 동안, 생각하지 못했던 문제들을 꽤 많이 만났어요.
친구에게 보여주니 난이도부터 달랐어요
가장 많이 한 일은 역시 플레이였어요. 제가 해보고 친구들에게도 해보라고 하면서 어디에서 막히는지 지켜봤습니다. 그런데 같은 게임을 두고 반응이 크게 갈렸어요.
이런 게임에 익숙하지 않은 친구는 첫 맵의 보스도 깨지 못하고 여러 번 죽었어요. 반대로 로그라이크나 조작이 어려운 게임에 익숙한 친구는 매번 리더보드에 최고점을 올릴 정도로 잘했습니다. 각자 쌓아온 게임 경험도, 조작 실력도 달랐던 거예요.
제게 적당한 난이도를 기준으로 삼으면 안 되겠더라고요. 어려워하는 친구는 스토리를 더 보고 싶어도 전투 때문에 멈추게 되고, 잘하는 친구는 익숙해진 전투를 계속할 이유가 필요했어요.
노비스 모드에서는 공격을 맞았을 때 받는 보호와 혜택을 늘렸어요. HP와 공격력도 플레이어에게 유리하게 보정했습니다. 클리어의 부담을 줄여서 이야기에 집중할 수 있게 하고 싶었어요.
숙련자를 위한 높은 난이도에서는 몬스터의 공격력, 공격 속도, 이동 속도와 투사체 발사 빈도를 조정했어요. 표준 모드보다 피하기 어렵게 만들고, 맞은 직후 잠깐 피해를 받지 않는 무적 시간도 없앴습니다. 가장 높은 점수는 가장 어려운 난이도에서 도전해야 얻을 수 있게 했고요.
수치만 바꿔도 체감 난이도가 꽤 크게 달라졌지만, 한 번 정했다고 끝나지는 않았어요. 직접 해보고 다른 사람의 플레이도 보면서 계속 조정해야 했습니다.
그래서 밸런스를 수정하는 별도의 어드민을 만들었어요. HP, 공격력, 공격 속도, 이동 속도처럼 자주 바꾸는 값을 관리 화면에서 직접 조정하고, 에이전트에게 매번 수정을 요청하지 않아도 제가 배포할 수 있게 했습니다. 플레이하다가 느낀 문제를 바로 고치고 다시 확인하고 싶었거든요.
한 번 클리어한 다음에도 다시 하고 싶으려면
난이도와 함께 계속 고민한 건 다음 판을 할 이유였어요. 짧은 전투 장면 하나만 보면 게임이 꽤 그럴듯해 보일 때가 있거든요. 하지만 실제로 플레이하면 보스를 쓰러뜨린 뒤에도 할 일이 이어져야 하잖아요. 무엇을 보상으로 주고, 어디로 이동시키고, 다음 행동을 어떻게 알려줄지까지 정해야 했어요.
여러 도시를 돌아보며 이야기를 모으도록
더 게이트에서는 한 번의 도전에서 전체 여덟 개 맵 중 세 개를 골라 플레이합니다. 지역의 보스를 물리칠 때마다 진실의 조각을 얻고, 세 지역에서 모은 조각으로 차원문에 가는 길을 엽니다. 그곳에서 문지기와 싸우면 한 번의 도전이 끝나요.
그러면 아직 가보지 않은 도시가 남아 있는데요. 다른 맵을 해금하고 새로운 몬스터와 보스의 공격 패턴을 만나면서, 모르는 이야기도 더 찾아볼 수 있어요. 여덟 맵을 모두 클리어하면 게이트가 나타난 더 근본적인 이유에도 접근하게 됩니다.
이런 흐름은 하데스에서 많은 영감을 받았어요. 플레이어의 선택에 따라 경험이 달라지면서도, 여러 번의 플레이가 하나의 진실을 향해 이어지는 방식이 좋았거든요. 더 게이트에서도 처음에는 지나쳤던 단서를 다시 보고, 그동안 모은 정보를 연결하면서 스스로 이야기에 도달하게 하고 싶었어요.
공격도 직접 써본 다음에 고르게 했어요
이야기만으로 모든 사람이 다시 플레이하지는 않을 거예요. 첫 한두 판만 해보는 사람도 전투 자체를 재미있게 느끼면 좋겠다고 생각했어요. 그래서 타격감과 공격 방식을 선택하는 과정에도 신경을 많이 썼습니다.
처음에는 기본 직업인 용사로 시작합니다. 약한 공격은 가까이 있는 적을 때리고, 강한 공격은 투사체를 날려요. 강한 공격은 한 번씩 누르거나 모아서 사용할 수 있어요. 처음부터 설명만 보고 직업을 정하기보다 두 종류의 공격을 직접 써보는 셈이죠.
플레이하면서 차원석이라는 재화를 모으면 전직할 수 있어요. 가까이 붙어 싸우는 게 좋았다면 근접 공격을 강화한 전사로, 투사체를 활용하는 게 좋았다면 마법사로 바꿀 수 있습니다. 무기와 직업을 선택하면서 같은 전투도 다른 전략으로 풀어보기를 바랐어요.
누군가는 이야기를 더 알고 싶어서, 누군가는 다른 직업을 써보고 싶어서, 또 누군가는 리더보드 기록을 높이고 싶어서 다시 해보면 좋겠다고 생각했어요. 앞으로 그래픽이 많이 바뀌더라도 타격감과 이 전직 시스템은 계속 유지하고 싶어요.
움직이기 시작하니 그래픽의 문제가 보였어요
게임을 계속 플레이하다 보니 처음에 코드로 만든 그래픽도 점점 신경 쓰였어요. 작동하는지 확인하기에는 충분했지만, 제가 원한 건 픽셀 기반의 귀엽고 매력적인 캐릭터였거든요. 그 모습으로 움직이고 싸워야 제가 상상하던 세계에 더 몰입할 수 있을 것 같았어요.
사이드 프로젝트인데 제가 좋아하는 모습만큼은 포기하고 싶지 않았어요. 그래서 페이블 프로토타입 초안 이후에는 픽셀 게임 에셋을 생성하는 PixelLab을 사용했습니다.
초기 그래픽보다 훨씬 나은 캐릭터를 만들 수 있었는데요. 하지만 여전히 캐릭터의 방향을 바꾸니 인상이 달라지고, 그 상태로 동작까지 시키면 손이나 몸이 과하게 틀어지기도 했어요. 한 방향으로 서 있을 때 괜찮아 보여도 다른 방향으로 걷고 공격하는 모습까지 같은 캐릭터여야 했으니까요.
한 장씩 보면 괜찮았던 애셋이 시퀀스로 움직일 때는 이 불일치가 더 크게 느껴져서, 마음에 드는 이미지를 만드는 데서 끝낼 수가 없었어요.
Codex에서 코드와 이미지를 함께 다루기 시작했어요
이 무렵 Codex의 Sol 출시가 제 작업에 또 한 번 중요한 계기가 됐습니다. 높아진 모델파워와 함께 Codex만으로도 에이전트와 함께 의미 있는 개발을 진행할 수 있겠다고 느꼈고, 같은 에이전트 환경에서 이미지 생성까지 네이티브로 할 수 있는 점이 매력적이었어요.
저는 이 때쯤 캐릭터와 맵, 세계관과 스토리를 더 구체화하고 싶었던 시기라 코덱스로 작업을 옮겼어요. 이후 솔, 루나맥스, 최근에는 아스트라까지 활용하고 있고요. 원하는 스타일과 설계를 유지하면서 코드와 그래픽을 함께 발전시키고 싶었습니다.
우선 캐릭터와 맵, 스토리, 게임 전체의 비주얼 기준을 상세하게 잡았습니다. 기준이 되는 이미지를 만든 뒤, 같은 캐릭터를 여러 방향에서 본 모습을 먼저 준비했어요. 그 모습을 바탕으로 걷거나 공격하는 동작의 각 장면을 모은 스프라이트 시트를 만들도록 했고요.
이 작업을 반복하려고 여러 스킬과 제작 절차를 만들고, 에셋을 다루는 애셋 랩과 맵을 다루는 맵 랩도 운영했어요. 게임에 넣을 결과물을 계속 만들고 확인할 환경이 필요했거든요. 이 과정을 통해 초기보다 컷씬과 스토리텔링 퀄리티를 훨씬 높일 수 있었어요.
그래도 한두 픽셀이 빠지거나 특정 동작에서 어색한 부분이 튀어나오는 문제는 남았는데요. 그런 부분은 제가 보고 직접 고칠 수 있게 하고 싶었어요.
그래서 혼자 쓸 피그마 플러그인과 픽셀 편집 환경도 만들었습니다. 스프라이트 시트를 캔버스에 가져와 픽셀 에디터처럼 필요한 부분을 짚어 수정할 수 있게요 준비했어요. 어디가 어색한지는 디자이너로서 판단할 수 있으니, 익숙한 도구에서 손보면 좋겠다고 생각했거든요. 작은 도구를 직접 만드는 부담도 전보다 줄었고요.
석촌호수를 만들다가 방법을 바꿨어요
맵에서도 비슷한 문제가 생겼어요. 픽셀 크기와 형태를 맞춰 다양한 크기의 에셋을 만들었는데, 하나씩 볼 때는 괜찮아도 게임 화면에 모아놓으면 통일성이 깨지더라고요.
처음에는 에셋들을 모듈처럼 준비하고 AI에게 조합해서 전체 맵을 설계해달라고 했는데요. 그중 가장 황당했던 결과가 석촌호수 맵이었어요.
함께 만든 에셋으로 석촌호수를 구성해달라고 했더니, 호수 안쪽에 가운데 손가락을 들어 올린 것 같은 모양이 나왔어요. 맵도 조악했지만 왜 하필 그런 모양인지 어이가 없더라고요.
이유를 물으니 AI는 롯데월드를 저작권 때문에 표현하기 어려워서 부지만 따로 표현했다고 설명했어요. 손가락처럼 튀어나온 부분은 롯데월드로 이어지는 다리라고 했고요. 그런데 다리라면 호수 바깥 땅까지 이어져야 하잖아요. 중간에서 끝나 있으니 설명을 들어도 납득이 안 됐어요.
시간을 더 들이면 모듈을 조합하는 방식도 개선할 수 있다고 생각했어요. 다만 그때는 우선 게임을 공개해서 게임성을 검증하고 싶은 마음이 더 컸거든요. 맵 제작 방식을 완벽하게 만드는 데 계속 시간을 쓰기보다, 지금 쓸 맵을 완성할 방법을 찾아야 했습니다.
그래서 순서를 바꿨어요. 맵 한 판을 고해상도 이미지로 먼저 만들고, 그 위에 실제 게임에 필요한 정보를 벡터로 배치하기로 했습니다.
캐릭터가 벽을 뚫고 지나가지 못하도록 충돌 영역을 지정하고, 몬스터가 나타날 위치와 열리거나 닫혀야 하는 곳, 보물상자가 나오는 곳도 따로 정했습니다. 그림을 보면서 그 안에서 무엇이 어디까지 움직일 수 있는지 맞춰갔어요.
이렇게 하면 맵 그래픽이 바뀔 때마다 그 위에 배치한 정보도 다시 편집해야 해요. 모듈식 에셋을 조합하는 방식보다 수정할 일이 많아지는 단점이 있었습니다. 그래도 당시 준비한 맵 열 개를 이 방식으로 작업하면 공개할 수 있겠다고 판단했어요.
시간을 들여 하나씩 맞췄고, 지금도 이 방식으로 서비스하고 있습니다. 앞으로는 맵 에셋마다 충돌 영역처럼 필요한 정보를 담아서 모듈식으로 조합하고 싶어요. 당장 완벽하게 풀지 못했어도 사람들이 플레이할 게임은 내놓고 싶었거든요.
게임이 커지니 일하는 방식도 바뀌었어요
전투를 고치고 그래픽을 바꾸고 새로운 기능을 붙이다 보니, 에이전트에게 요청하는 일도 계속 늘어났어요. 저는 가급적 어떤 상황인지, 무엇이 불편한지, 어떻게 개선하고 싶은지를 상세하게 설명하면서 작업해요.
하지만 저장소는 하나인데 여러 일을 동시에 진행해야 했어요. 작은 문제도 고쳐야 하고 큰 기능도 만들어야 했습니다. 방향을 분석하고 조언을 구할 때도 있었고요. 모든 일을 한 세션에서 다루기는 어려웠어요.
여러 세션을 만들어 자잘한 이슈를 고치는 역할, 큰 기능을 만드는 역할, 저와 분석하고 의논하는 역할로 나눴어요. 모델별로도 역할을 부여했습니다. 이렇게 일을 맡기려면 소프트웨어 개발이 어떻게 돌아가는지, 각 세션에 무엇을 어느 범위까지 요청할지 저도 알아야 했어요.
그런데 예전에 이야기한 요청이 빠지거나, 여러 일을 한꺼번에 부탁했을 때 일부가 누락되는 일이 생겼어요. 작업했다고 답했는데 실제로는 반영하지 않은 경우도 있었습니다. 요청이 수십 개를 넘어 수천 개 수준으로 쌓이니 제 기억에도 한계가 왔어요.
어떤 문제를 언제 발견했고 어디에 전달했는지 전부 기억할 수는 없더라고요. 이미지와 설명을 붙여놓고 나중에 다시 판단할 공간도 필요했어요. 지금 바로 고치지 않더라도, 다시 봤을 때 당시의 문제를 이해할 수 있어야 했습니다.
그래서 사람과 일할 때처럼 GitHub에 프로젝트와 이슈 보드를 만들었습니다. 요청을 각각의 이슈로 남기고 상황과 스펙을 구체적으로 정리했습니다. 대화가 지나가도 다시 찾아볼 수 있는 기록이 생기니, 제 기억과 에이전트의 답변에만 의존하지 않아도 됐어요.
이렇게 작업을 구체화하면서 실제 서비스에 계속 배포하고 운영하는 과정도 더 안정적으로 이어갈 수 있었어요.
잘 돌아가는 줄 알았던 리더보드에도 문제가 있었어요
UX나 그래픽, 직접 플레이하면서 느끼는 재미는 비교적 판단하기 쉬웠어요. 어디가 어색한지 보고 원하는 방향을 설명한 다음, 고친 결과를 확인하면 됐거든요.
보안이나 CDN, 서버와 리소스 비용, 개발 안정성은 달랐어요. 평소 디자이너로 일하면서 깊게 다루지 않던 영역이라 무엇을 개선해야 하는지조차 모를 때가 있었는데요. 이때 개발자 친구들의 조언이 큰 도움이 됐습니다.
처음 리더보드는 게임을 클리어한 브라우저에서 점수를 서버에 기록하고, 닉네임을 입력하면 다른 사람과 순위를 비교하는 식으로 만들었습니다. 제가 보기에는 필요한 기능이 잘 돌아가고 있었어요.
그런데 개발자 친구가 다른 경로로 접근하면 점수와 닉네임을 마음대로 바꿀 수 있다고 알려줬어요. 그 지적을 바탕으로 AI와 함께 문제를 고쳤습니다. 혼자 만들고 혼자 확인했다면 알아채기 어려웠을 거예요.
기록을 높이는 재미를 주려고 리더보드를 만들었는데, 그 기록을 믿을 수 있는지도 챙겨야 했어요. 게임을 공개하고 운영하려면 제가 잘 보지 못하는 부분도 확인해야 하더라고요.
아직 아쉽지만, 계속 만들 수 있게 됐어요
아직도 제가 지금 그래픽에 점수를 준다면 10점 만점에 6점 정도예요. 방향과 동작 사이의 일관성도 더 좋아져야 하고, 맵을 만드는 방식도 개선하고 싶어요. 모델과 제 작업 방식이 발전하면서 나아질 거라고 기대하지만 아직 완전히 풀지는 못했어요.
그래도 만드는 동안 정말 신나고 즐거웠어요. 머릿속에서만 일어나던 일을 이 정도로 가깝게 구현하고 제가 직접 플레이할 수 있었으니까요. 고치고 싶은 부분이 생기면 다시 손볼 수 있었고요.
불과 1년 전만 해도 새로운 설계가 실제 제품에 반영되려면 많은 논의와 기술 검토, 이해관계 조율이 필요했어요. 결과를 보고 판단하거나 개선하기까지 오래 걸릴 수밖에 없었고요.
더 게이트에서는 원하는 일을 직접 시도하고, 아직 잘 모르는 부분은 AI와 함께 물어보면서 진행할 수 있었는데요. 그 과정 자체가 재미있어서 휴일에도 계속 게임을 붙잡게 됐어요. 결과적으로 2025년에 깃허브 컨트리뷰션이 1개였던 제가 상반기에만 3천 개가 넘는 컨트리뷰션을 하고 있더라고요.
처음에는 단순히 내 취향의 게임을 직접 만들어 보고 싶어서 시작한 사이드 프로젝트가, 플레이어가 다음 행동을 이해하는 방식부터 다시 도전할 이유, 오래 플레이한 사람이 발견할 이야기, 캐릭터와 맵, 배포와 운영까지 설계하고 있었어요. 하나의 큰 디지털 제품을 제 뜻대로 만들고 개선해볼 수 있었습니다.
