1부가 나간 지 무려 4개월이 지났습니다. "2026년 한 해 동안 이어갈 장기 프로젝트"라고 호기롭게 시작했지만, 2부를 마저 작성하기가 어려웠습니다. 변명을 좀 하자면, 게으름 때문만은 아니었습니다. 사실 저는 이 프로젝트를 거의 포기하고 있었습니다.
이유는 단순합니다. 러버블로 만든 '탭탭 카피바라'가, 제대로 작동하지 않았습니다.
일단 버그가 나옵니다. 그걸 러버블에게 "이거 고쳐줘"라고 합니다. 그럼 "네, 고쳤습니다!"라고 당당하게 답합니다. 그런데 안 고쳐져 있습니다. 다시 "안 됐는데?"라고 합니다. "죄송합니다, 이번엔 확실히 고쳤습니다!"라고 합니다. 그런데 또 안 됩니다.
이 무한 루프가 며칠을 반복됐습니다. 도대체 어디서부터 어디까지가 잘못된 건지 알 수가 없습니다. 게다가 저는 고칠 능력도 없습니다.
사실 버그보다 더 근본적인 문제도 있었습니다.
바이브 코딩으로 "클리커형 게임을 만들어줘"라고 명령하면, AI는 그럴듯하게 굴러가는 것처럼 보이는 결과물을 내놓습니다. 화면도 멀쩡하고, 버튼도 눌리고, 뭔가 작동하는 것 같습니다. 그래서 '오, 내가 지금 바이브 코딩으로 게임을 만들고 있는 건가?' 싶어집니다.
하지만 실제로는 아닙니다.
이건 마치 AI에게 집을 지어달라고 하는 것과 같습니다. "집 지어줘" 했더니, 집 모양이 얼추 나옵니다. 그런데 문을 열고 들어가 보면, 배수 시설도 없고, 전기 배선도 안 되어 있고, 그냥 껍데기만 집 모양인 겁니다. 겉보기엔 멀쩡한데, 사람이 살 수 있는 집은 아닌 거죠. 제가 만든 카피바라가 딱 그 짝이었습니다. 귀엽게 발은 구르는데, 그 안에 게임이라고 부를 만한 알맹이가 없었습니다.
유튜브에서 만난 '진짜' 바이브 코딩
그렇게 카피바라를 마음 한구석에 묻어두고 지내던 어느 날이었습니다. 인터넷을 떠돌다, 바이브 코딩으로 게임을 만드는 영상을 하나 보게 됐습니다. 이 사람은 바이브 코딩으로 슈퍼 마리오를 만들고 있었는데, 원래 개발자 출신이어서 그런지 완성도가 남달랐습니다. 제가 만든 '껍데기 집'과는 차원이 다른, 진짜 사람이 살 수 있는 집을 뚝딱 지어내고 있었습니다.
무엇보다 이 사람이 게임을 만드는 과정이 처음부터 차례대로 담겨 있었습니다. 보면서 생각했습니다. '저 순서를 따라가면, 나도 되지 않을까?' 오랫동안 시도하고 포기하고를 반복했던 프로젝트, 다시 한 번 도전할 용기를 얻었습니다. 그리고 그 영상에서, 저는 게임 만들기의 중요한 원칙 몇 가지를 배웠습니다.
STEP 1
좋은 AI를 써야 한다
성능 좋은 AI는 유저가 일일이 말하지 않아도 알아서 해주는 부분이 많습니다. 반대로 성능이 떨어지는 AI는, 쓰는 사람이 그만큼 빈틈을 메워줘야 합니다. 좋은 AI를 써야 한다
러버블이 일을 못한 건 아니었지만, 제가 게임을 만들던 시점 기준으로 '최고의 성능'을 가진 도구는 아니었습니다. 러버블은 프로토타입을 빠르게 뽑는 건 잘했습니다. 그런데 복잡한 로직이 들어가거나 코드 구조를 섬세하게 다듬어야 하는 순간이 오면, 한계가 보였습니다. 무엇보다 제가 원하는 걸 AI가 '알아서' 해주는 느낌이 잘 안 났습니다.
1부를 쓴 이후 4개월이 흐르는 동안, AI도 그만큼 빠르게 발전했고, 그래서 새로운 도구를 쓰기로 했습니다.
그게 바로 '클로드(Claude)'입니다. 코딩을 도와주는 AI 도구는 정말 많이 있었는데 12종이 넘는 AI 코딩 에이전트 중에서 코딩 분야에서 좋은 평가를 받기 시작했던 건 '클로드'부터였던 걸로 기억합니다. 실제로 클로드는 2024년 말까지 AI 엔지니어들이 가장 선호하는 모델 자리를 유지했고, 클로드를 전용 모델로 채택한 코딩 에이전트들이 출시 4주 만에 월 매출 400만 달러를 달성할 정도로. 개발자들의 사랑을 받았다고 합니다. (그런데 지금은 또 다른 AI 코딩 툴이 '클로드'보다 더 좋은 평가를 받고 있으니 세상이 참 빠르게 변합니다.)
제미나이, 그록, 등 다양한 툴을 써보았는데 같은 코드를 돌렸을 때 '클로드'의 결과물이 확실히 좋았습니다. 단순히 코드가 돌아가는 수준이 아니라, 제가 원하는 맥락을 더 잘 이해하고, 에러가 나면 스스로 검색해서 문서를 찾아보고, 긴 코드베이스를 끝까지 일관성 있게 유지했습니다.
STEP 2
좋은 게임 기획서가 있어야 좋은 게임이 나온다
유튜브 영상에서 배웠던 핵심 중 하나였습니다. 게임 기획서는 집을 지을 때의 설계 도면 같은 거라고 합니다. 도면이 있어야 기초부터 끝까지 탄탄하게 빠짐없이 지을 수 있습니다. 1부의 제가 '카피바라'라는 클리커형 게임을 단 몇줄 짜리 프롬프트로 껍데기 집을 지었던 걸 떠올리면, 제가 그 때 얼마나 잘 몰랐는지 새삼 떠올랐습니다.
먼저 클로드에게 물었습니다. "네가 만들 수 있는 웹게임 종류를, 쉬운 것부터 어려운 것까지 난이도순으로 리스트업해줘." 그랬더니 쭉 답을 내놓았습니다. 가장 쉬운 건 테트리스 같은 것들이었는데, 이왕이면 그것보단 좀 더 어려운 걸 만들고 싶었습니다. 그래서 난이도 '중급'에 속한 장르 중에서, 예전에 재밌게 했던 디펜스 게임을 골랐습니다.
물론 저는 디펜스 게임을 만들 때에는 어떤 것들이 필요한지 모릅니다. 주변에 아는 디펜스 게임 정보를 일단 모아서 클로드에게 넘겨주고, "이걸 토대로 기획서를 만들어줘"라고 했습니다.
결과는 놀라웠습니다. 클로드는 디펜스 게임에 대한 꽤 그럴듯한 퀄리티의 기획서를 만들어냈습니다. 그리고 이 기획서를 기반으로 게임을 만들어달라고 했더니, 처음부터 제법 그럴듯한 게임이 나오는 겁니다. 와. 카피바라로 벽에 막혀 머리를 쥐어뜯던 때와 비교하면, 놀라울 정도로 쉽게 게임이 만들어졌습니다.
‘게임 기획서’ 유무의 차이가, 이렇게 큽니다.
STEP 3
세 번째로 배운 건, 그래픽을 입히기 전에 로직부터 완성하라는 것이었습니다. 찰흙 형태든 폴리곤 덩어리든 상관없이, 일단 게임이 제대로 돌아가게 만드는 게 먼저라는 겁니다. (1부에서 캐릭터 외형부터 붙잡고 버전 12까지 헤맸던 제가 들었어야 할 말입니다.)그래픽보다 로직이 먼저다
다행히 프로토 타입의 게임이 작동이 잘 됐습니다. 제가 원하는 형태로 몬스터들이 길을 따라 움직였고, 유닛들이 공격을 했습니다. 여기서부터 세부 조정에 들어갔습니다. 맵에 유닛을 놓는 방법, 유닛을 조합하는 방법, 새로운 몬스터 추가, 승리·패배 조건 설정… 하나하나 손봐 나갔습니다.
과정은 어려웠지만, 굉장히 재미있었습니다. '어떤 게 있어야 게임다워질까?' 고민하면서 필요한 기능들을 하나씩 넣었습니다. 유닛을 추가하기도 하고, 몬스터를 추가하기도 하고, BGM을 넣어보기도 하고, 특수효과와 각종 이펙트들을 하나하나씩 추가하였습니다.
시간이 지날수록 게임이 완성되어 가는 게 눈에 보이니 만족감이 들어 시간이 가는 줄 모르고 코딩을 하게 됩니다.
더욱 인상적이었던 건, 코딩을 모르는 제가 이런 저런 명령을 내려도 '클로드'가 알아서 작업을 해낸다는 것입니다. 또, '클로드'에게 "이 게임을 밸런스 적인 측면은 제외하고, 게임 완성도를 높일 수 있는 것들을 제안해줘"라고 부탁하니 다양하고 아주 유용한 제안들을 하면서 게임을 만들어줬습니다.
그렇게 열심히 개발에 집중하다 보니 어느새 저는 정말 게임 개발자가 된 것 같은 착각이 들었습니다.
STEP 4
그래픽을 입히다
네 번째는 그래픽 작업입니다.
이게 생각보다 만만치 않았습니다. 우선 원하는 그래픽을 얻으려고 여러 툴에 이런저런 그림을 요청해봤고, 그걸 제가 원하는 형태로 다듬기 위해 직접 포토샵으로 편집하는 과정이 필요했습니다. 캐릭터 하나하나를 직접 따내서 입력하는 걸 수기로 해야 했습니다. 만약 포토샵을 다룰 줄 몰랐다면 불가능했을 작업입니다.
이미지 프롬프트만으로 해결하기에는 AI가 못 알아듣는 경우가 많았고, 세부 디테일을 조정한답시고 토큰을 계속 쏟아붓는 건 효율적이지 않았습니다. (이건 1부 카피바라 때 뼈저리게 배운 교훈입니다.)
진짜 어려운 건 그다음이었습니다. 실제로 굴러가는 게임에 그래픽을 입히자, 그림이 잘린다거나, 몬스터의 동선과 그래픽이 안 맞는다거나 하는 문제들이 쏟아졌습니다. 이건 실제 게임 안에서 어떻게 보이는지 직접 적용해봐야만 알 수 있는 것들이었습니다. 그런 부분들을 클로드와 상의해가며 하나씩 수정했고, 여기에도 적지 않은 시간이 들었습니다.
개인적으로 이 과정에서 재미있는 경험도 있었습니다. 코딩은 클로드, 그래픽은 제미나이로 역할을 나눠 작업했는데, 흐름이 꽤 그럴싸했거든요. 클로드에게 필요한 디자인 스펙을 정리하게 한 뒤, 그 내용을 제미나이에게 넘겨 그래픽을 받고, 완성된 이미지를 다시 클로드에 적용하면서 피드백을 받는 식이었습니다. 어느 순간 제가 개발팀과 디자인팀을 오가며 일정을 조율하는 PM이 된 듯한 기분이 들더군요. 실제로는 혼자 앉아서 채팅창 두 개를 왔다 갔다 하고 있었는데도요.
그렇게 이미지 작업을 마치고 나니, 확실히 '게임스럽다'는 느낌이 들기 시작합니다. 뿌듯하고 보람도 차오르니, 자연스럽게 게임 개발에 쏟는 시간도 늘어납니다. 내가 원하는 대로 즉각즉각 업데이트가 이뤄지니, 토큰 할당량을 순식간에 써버리고 멈췄다가, 다시 작업했다가 하는 일이 점점 잦아졌습니다.
STEP 5
예상하지 못했던 색다른 어려움, 밸런스 잡기
마지막은 밸런스 조정이었습니다.
실제로 게임을 플레이하면서 레벨 디자인을 하는 작업인데, 혼자 하다 보니 이게 정말 쉽지가 않았습니다. 혼자 테스트를 하는데, 게임에 랜덤 요소가 많다 보니 잘 깨질 때는 '너무 쉬운가?' 싶고, 어려울 때는 '내가 밸런스를 잘못 짠 건가?' 싶은 생각이 계속 드는 겁니다. 보다 못해 주변 지인에게 테스트를 부탁했는데, 이것도 사람마다 게임 이해도가 다르고, 디펜스 게임에 랜덤 요소가 크다보니 결과가 제각각입니다.
그래서 이 게임의 밸런스를 조정하면서, '아, 왜 게임이 출시될 때 밸런스가 잘 잡혀있지 않은 경우가 있는지 알겠다'라는 생각이 들기도 했습니다. 그렇게 열 두 차례의 밸전스 조정을 거쳤고,
어찌저찌 게임이 완성됐습니다.
코딩 0점 문과생이 게임을 만들었습니다
코딩이라곤 하나도 모르는 제가, 어쨌든 실제로 작동하는 게임을 만들어냈다는 사실이 놀랍기도 하고 만족스럽기도 합니다. 그리고 게임을 만드는 일이 이렇게나 재미있는 일이구나, 하는 것도 알게 됐죠.
만들면서 느낀 것도 많았습니다. 그래픽을 입히는 과정에서는 마치 개발실에서 디자이너에게 피드백을 주듯, 프롬프트를 정리해 요청을 거듭했습니다. 그게 결코 쉽지 않다는 것도 배웠고, 밸런스 조정이 얼마나 고된 작업인지도 느꼈습니다. 코딩을 몰라도 게임은 만들 수 있었지만, '게임을 만든다는 것'에는 코딩 말고도 넘어야 할 산이 이렇게나 많았던 겁니다.
이 모든 걸 직접 게임을 만들며 느낄 수 있었다는 것만으로도, 저에게는 얻은 게 많은 프로젝트였습니다.
그리고 무엇보다 코딩을 하나도 모르는 제가 '바이브코딩'만으로 게임을 이렇게까지 만들었다는 것에 대해 한 켠으로는 무섭다는 생각이 들기도 합니다. 4개월 전 '러버블'과 비교하면 AI가 얼마나 빠르게 발전하고 있는지, 그리고 실제 현업에 있는 개발자 분들께서 느끼실 감정은 어떠실지, 그런 세상에서 살아간다는 게 어떤 의미인지에 대해, 복잡하고 여러 가지 생각을 하게 되었습니다.
4개월 전, 멱살을 잡았던 카피바라는 결국 떠나보냈지만, 저는 끝내 제 손으로 굴러가는 게임 하나를 만들어냈습니다. 코딩 0점 문과생의 무모한 도전은, AI 발전 덕분에 성공할 수 있었습니다.
Haao@inven.co.kr 
