처맞은 불곰의 개발이야기

Tiny Reign을 만들면서 유닛 수가 늘어날수록 한 가지가 계속 신경 쓰였다. 스탯이 코드에 박혀 있다는 것. 전사 공격력을 바꾸려면 .gd 파일을 열고 숫자를 찾아서 고쳐야 했다. 유닛이 네 종류일 때도 이미 귀찮았는데, 앞으로 더 늘어나면 어떻게 하나 싶었다.

CSV 하나로 시작했다

unit_stats.csv 파일 하나에 유닛 종류별로 행을 나눴다. 열은 unit_type, hp, atk, speed, detection_range, attack_range, attack_cooldown 같은 식이다. 이걸 Autoload 싱글턴인 UnitStatsDB에서 게임 시작할 때 한 번 읽어서 딕셔너리로 들고 있는다.

실제로 유닛이 스탯을 가져올 때는 UnitStatsDB.get_stats(“warrior”) 한 줄이면 된다. CSV 파싱도 Godot의 FileAccess로 충분했다. 복잡한 라이브러리 없이도 됐다.

써보니 좋았던 것들

가장 좋은 건 밸런싱이 쉬워졌다는 거다. 전사 체력이 너무 강하다 싶으면 CSV 열어서 숫자 바꾸고 저장하면 끝이다. 코드를 건드릴 필요가 없으니 실수도 줄었다.

AI 협업할 때도 편했다. “warrior의 attack_range를 155로 바꿔줘”라고 하면 AI가 CSV를 직접 수정해준다. 코드 구조를 설명할 필요가 없다. 숫자가 어디 있는지 명확하니까.

Red팀 유닛을 추가할 때도 Blue팀 CSV를 복사해서 수치만 조금 바꿨다. 행 하나 추가하는 게 전부였다.

주의할 점

CSV는 타입 정보가 없다. 파싱할 때 int()나 float()로 직접 변환해야 한다. 이걸 빠뜨리면 숫자인데 문자열로 들어와서 비교가 안 되는 버그가 생긴다. 처음에 이걸 몰라서 공격 판정이 왜 안 되는지 한참 헤맸다.

열 순서가 바뀌면 파서가 깨질 수 있으니 헤더 이름 기반으로 읽는 게 안전하다. Godot에서 CSV 첫 줄을 키로 쓰는 방식으로 구현하면 나중에 열을 추가해도 기존 코드가 안 깨진다.

발사체 데이터도 같은 방식으로 ProjectileStatsDB를 따로 만들었다. 화살 속도, 데미지, 관통 횟수 같은 것들. 데이터 파일이 분리되어 있으니 나중에 찾기도 쉬웠다.

정리하자면

데이터 주도 설계(data-driven)라는 거창한 말이 있는데, CSV 파일 하나가 그 출발점이 될 수 있다. 하드코딩 제거, 밸런싱 편의, AI 협업 모두에서 효과를 봤다. 규모가 커지면 JSON이나 DB로 교체하기도 어렵지 않다. 게임 스탯을 아직 코드에 박아두고 있다면 CSV부터 시작해보는 걸 추천한다.

Tiny Reign을 만들면서 Claude Code를 써온 지 꽤 됐는데, 쓰다 보니 잘 되는 것과 안 되는 것이 점점 명확하게 나뉘더라.

잘 됐던 것

코드를 짜기 전에 먼저 대화를 나눴다. 왕국 자원 시스템을 만들어야 할 때, 바로 “이거 만들어줘” 하지 않고 어떻게 동작해야 하는지, 어떤 데이터가 필요한지, 어떤 상황에서 어떻게 처리해야 하는지 같은 구현 사항을 먼저 AI랑 정리했다.

이렇게 하면 실제 코드 작업에서 원하는 결과가 한 번에 나오는 경우가 많았다. 반대로 대화 없이 바로 만들어달라고 하면 뭔가 하나씩 빠져 있거나 구조가 내가 생각한 것과 달라서 수정을 여러 번 하게 됐다. 결국 미리 대화하는 시간이 전체 작업 시간을 줄여주는 셈이었다.

이게 되는 이유는 단순한 것 같다. 코드는 어차피 논리로 이루어져 있고, 그 논리를 말로 설명할 수 있으면 AI가 그대로 구현해준다. 대화 자체가 설계 과정이 되는 거다.

잘 안 됐던 것

타일 같은 비주얼 작업은 달랐다. 게임 맵에 들어갈 타일셋을 AI로 만들어보려고 MCP 설정해서 PixelLab도 연동해봤다. 처음엔 될 것 같았는데, 실제로 여러 번 시도해봐도 원하는 퀄리티가 안 나왔다.

색감이 게임 분위기랑 안 맞거나, 타일끼리 붙였을 때 어색하거나, 뭔가 하나씩 마음에 안 드는 게 생겼다. 프롬프트를 더 자세하게 써봤는데도 크게 달라지진 않았다. 코드처럼 “이렇게 해줘”라고 말로 정확하게 전달이 안 되는 영역이라 그런 것 같다. 아직 더 다양한 시도가 필요하고, 좋은 방법을 찾으면 따로 글로 정리할 생각이다.

정리하자면

코드나 설계처럼 말로 설명할 수 있는 작업은 AI가 잘 처리한다. 비주얼이나 감각적인 판단이 필요한 부분은 아직 사람 손이 많이 간다. 이 두 영역을 구분해서 쓰는 게 지금으로선 제일 효율적인 것 같다.

억지로 모든 걸 AI에게 맡기려 하기보다, 어디에 쓰면 효과적인지 파악하면서 쓰는 게 바이브코딩을 잘 쓰는 방법인 것 같다는 생각이 든다.

이번엔 바이브코딩으로

이전에 유니티로 캐주얼 게임을 하나 만들어서 출시까지 해봤다. 처음부터 끝까지 직접 코드를 짜는 방식이었는데, 이번엔 다른 방식으로 해보고 싶었다.

바이브코딩이라는 방식이 눈에 들어왔다. AI에게 만들고 싶은 걸 설명하면 코드를 짜주는 방식인데, 작업 속도가 빠르다는 얘기를 많이 봤다. 바이브코딩으로 게임을 어디까지 만들 수 있는지도 궁금했다. 일단 런칭을 목표로 해볼 수 있는 데까지 해보기로 했다.

바이브코딩 도구는 평소에 커서(Cursor)를 쓰고 있었는데, 요즘 Claude Code를 쓰는 사람이 많이 보여서 이번 프로젝트는 Claude Code로 작업해보기로 했다.

---

엔진은 고도(Godot)로

이번엔 유니티 대신 고도(Godot)를 써보기로 했다. 바이브코딩에 어떤 엔진이 잘 맞는지 찾아봤는데 고도가 괜찮다는 얘기가 많았다.

이유가 있었다. 고도는 씬 파일(.tscn)이 텍스트 형식으로 저장된다. 덕분에 AI가 에디터를 직접 열지 않아도 씬 파일을 읽고 쓰는 게 가능하다. 유니티는 씬 파일 구조가 복잡해서 AI가 건드리기 까다로운데, 고도는 그 부분이 훨씬 자유롭다. 엔진을 크게 건드리지 않고도 대부분의 작업을 코드로 처리할 수 있다는 게 바이브코딩과 잘 맞는 이유였다. AI 도구는 Claude Code를 쓰기로 했다.

---

만들 게임: Tiny Reign

만들 게임은 캐주얼 왕국 전략 게임이다.

비주얼은 마음에 드는 픽셀아트 리소스를 골라서 쓰기로 했다. 다만 그 리소스만으로는 제작에 한계가 있을 것 같아서, 필요한 부분은 비슷한 스타일의 리소스를 찾거나 AI로 직접 만드는 것도 염두에 두고 진행할 생각이다.

---

폴더 구조 잡기

본격적으로 시작하기 전에 폴더 구조부터 잡았다.

고도를 써보니 유니티와 다른 점이 있었다. 고도는 모든 게 씬으로 구성되고, 씬마다 스크립트가 붙는 구조다. 스크립트와 씬을 완전히 분리하기가 애매하다.

그래서 이렇게 나눴다.

• scenes/ — 씬 파일과 해당 씬에서 쓰는 스크립트
• shared/ — 씬 없이 스크립트만으로 동작하는 로직

씬이 필요한 건 scenes/에, 여러 곳에서 공통으로 쓰는 로직은 shared/에 넣는다. 새 유닛을 추가할 때 shared/를 건드리지 않아도 되도록 경계를 잡아뒀다.

Cursor로 개발을 시작하면서 제일 먼저 든 고민이 이거였다.

AI가 코드를 척척 짜주는데, 나는 이걸 다 읽고 이해해야 하나?

게임 개발할 때는 당연히 내가 짠 코드니까 전부 알고 있었다. 근데 Cursor가 짜주는 코드는 양도 많고, 내가 생각하지 못한 방식으로 구현된 경우도 많았다. AI를 써봐야겠다 싶어서 그전에 파이썬을 좀 봤는데, 기초적인 문법 흐름 정도는 파악이 됐지만 100% 이해하는 건 아니었다. 그 상태로 Cursor가 짜주는 코드를 보고 있으면 읽히긴 읽히는데 온전히 내 것이라는 느낌이 없었다.

이걸 다 이해하려고 하면 개발 속도가 확 떨어진다. 그렇다고 아예 무시하고 넘어가자니 나중에 뭔가 터졌을 때 손댈 수가 없을 것 같았다.

결국 방향을 바꿨다

고민하다가 내린 결론은 이거였다. 코드를 100% 이해하는 건 포기하자. 대신 내가 원하는 기능이 제대로 동작하는지 테스트를 훨씬 꼼꼼하게 하자.

AI한테 코드를 맡기는 대신, 나는 결과물을 검증하는 역할에 집중하는 거다. 직접 개발할 때는 코드를 보면서 흐름을 파악했다면, 지금은 실제로 기능을 써보면서 엣지 케이스를 찾는 데 시간을 더 쓴다.

이게 맞는 방식인지는 아직도 모르겠다. 근데 적어도 지금은 이 방식이 나한테 맞더라. 코드를 다 이해하지 못해도 내가 만든 기능이 제대로 동작하고 있으면, 그게 결과적으로 더 중요한 거 아닐까 싶다.

AI 코딩 툴을 처음 쓰는 사람이라면 아마 비슷한 고민을 할 것 같다. 다 이해하려고 너무 애쓰지 않아도 된다. 일단 돌아가게 만들고, 모르는 부분은 조금씩 채워가면 된다.

게임 소개

게임명	스페이스 러쉬
장르:	캐주얼 레이싱
개발툴	Unity (C#)
개발 기간:	약 3달
출시 플랫폼:	Android

일직선으로 이루어진 경로에 각종 장애물과 아이템을 사용하여 목적지까지 도달해 스테이지를 클리어하는 캐주얼 레이싱 게임입니다.

제작 의도

처음엔 진짜 간단하게 만들어보자로 시작

처음부터 끝까지 개발해 런칭까지 하는건 처음이다 보니 전체사이클을 경험해보자에 의의를 두고 게임자체는 캐주얼한 게임을 만들기로 결정을 하고 진행을 했습니다. 그러면 캐주얼게임으로 어떤 것이 적당한가에 대해서 고민을 하다가 예전에 도스용으로 즐겼던 스카이로드가 생각이 났습니다. 우주선이 간단한 발판을 달리는 게임이었지만 생각보다 장애물을 피하는 긴장감과 속도감이 느껴졌던 게임으로 기억이 났습니다. 그래서 기본응 골자는 스카이로드처럼 일직선에 장애물을 놓고 거기에 진행에 도움을 주는 몇가지 아이템을 더 추가하여 제작을 하기로 결정했습니다.

게임의 차별화

생각해보니 몇가지 아이템으로는 크게 차별화가 된 느낌이 들지 않아서 조금 더 시스템을 추가하기로 했습니다. 스카이로드에서도 속도가 빠른 구간에서는 속도감이 느껴지는 했으나 이번에 만든 게임에서 조금더 이 속도감이 나기를 원했습니다. 그래서 찾아본것이 쿠타의 운석피하기 게임입니다. 운석피하기는 속도가 점차 증가하여 최고속도에 도달하게 되면 운석을 보고 다음위치를 잡는 시간이 점차 짧아지며 속도감과 긴장감을 동시에 느낄 수 있는 게임이다보니 서브 모드로서 추가하면 좋을 것 같다는 생각이 들었습니다.

게임 구현

우주선의 움직임 충돌체크는 크게 어려운 부분은 없었고 조금 고민을 했던 부분이 맵구성이었습니다. 맵은 우선 스테이지 진행방식이라 스테이지별 난이도가 균형이있어야 하기때문에 이부분을 랜덤으로 배치를 할 수는 없었기에 스테이지별 맵을 파일로 구성하고 그 구성파일을 게임 월드상에 배치하는 방식으로 진행하기로 합니다

맵 구현의 문제점

중요한 것은 스테이지당 3분을 달려야 한다면 타일 맵으로 구성을 한다면 화면에 뿌려지는 오브젝트의 개수가 너무 많아지기 떄문에 이부분을 조절을 할 오브젝트 풀링이 필요했습니다. 장애물과 아이템을 가로행 기준으로 그룹화 시켴 재사용이 가능하도록 구성하여 우주선이 움직이는 거리에따라 이미 지나가 화면에 보이지 않는 오브젝트들을 오브젝트 플에 저장하고 앞으로 지나갈 자리에 배치를 시켜 적은 오브젝트수로 플레이가 가능하도록 하였습니다. 아마 이부분은 대부분의 게임에 추가하는 시스템이라 크게 특이한 부분은 없기는 합니다.

한 싸이클(?) 의 경험은 중요하다

기획적인 부분과 레벨 난이도같은 부분은 도움을 받았지만 해당 프로젝트의 모든 부분은 경험을 해보니 어떤것을 진행하는 저의 선택이 필요하고 거기에 대한 고민이 동반되는 부분이 많았습니다. 처음부분에서부터는 유니티 버전의 선택부터 시작해서 개발 중반부에서는 오브젝트 풀링을 어떤 방식으로 어떻게 해결해야할지 또는 리소스는 어떤것이 적절한지 등등 모든 것들이 선택이 필요했던 것같습니다. 힘들었던 부분도 있었지만 좋은 경험이 됬던것 같습니다.

다음에는 아마 스페이스 러시에서 서브 모드로 만들었던 운석피하기 게임을 뜯어서 웹게임으로 가볍게 컨버팅을 해볼 생각입니다.