처맞은 불곰의 개발이야기

그냥 켜면 안 된다

avoidance_enabled = true로 설정하면 끝인 줄 알았는데, 실제로 켰더니 유닛들이 이상하게 진동하거나 벽에 끼는 문제가 생겼다. 이유를 찾아보니 몇 가지를 같이 설정해야 했다.

먼저 유닛마다 CollisionShape2D 대신 원형 콜리전을 써야 Avoidance 계산이 제대로 된다. Avoidance는 에이전트를 원형으로 취급하기 때문에 사각형 콜리전과 계산이 맞지 않는다. 반지름 값도 실제 유닛 크기에 맞게 조정해야 했다.

velocity를 직접 써야 한다

NavigationAgent2D에서 avoidance를 쓰면 velocity_computed 시그널이 생긴다. 이걸 연결해서 계산된 velocity를 받아 써야 한다. 내가 계산한 방향으로 바로 이동시키면 avoidance가 무시된다.

흐름은 이렇다. 목표 지점 방향으로 velocity를 계산하고 NavigationAgent2D.set_velocity()로 넘긴다. 그러면 avoidance 계산이 돌아가고 velocity_computed 시그널로 보정된 velocity가 돌아온다. 그걸 CharacterBody2D.velocity에 넣고 move_and_slide()를 호출한다.

motion_mode 설정도 중요하다

CharacterBody2D의 motion_mode를 FLOATING으로 바꿔야 했다. 기본값인 GROUNDED 모드에서는 중력 방향 처리가 개입해서 2D 탑다운 게임에서 유닛이 이상하게 움직인다. FLOATING으로 바꾸고 나서야 안정적으로 됐다.

그리고 게임 시작 시점에 NavigationAgent2D의 초기 target_position을 유닛 자신의 위치로 설정해줘야 한다. 안 하면 첫 프레임에 (0, 0)으로 이동하려는 경로가 잡혀서 유닛이 맵 구석으로 튀어가는 버그가 생긴다.

정리하자면

Godot Avoidance는 제대로 설정하면 꽤 잘 동작한다. 핵심은 세 가지다. 원형 콜리전 쓰기, velocity_computed 시그널 연결하기, motion_mode를 FLOATING으로 바꾸기. 이 세 가지만 챙겨도 유닛들이 서로 겹치지 않고 자연스럽게 이동한다.

Godot 4에서 유닛 이동을 처음 구현할 때 타일맵 내장 네비게이션을 썼다. TileMap에 네비게이션 레이어를 추가하고 NavigationAgent2D를 붙이면 되니까 처음엔 간단해 보였다. 그런데 실제로 써보니 문제가 하나씩 나왔다.

타일맵 내장 방식의 문제

타일마다 네비게이션 폴리곤을 직접 설정해야 한다. 타일셋에서 각 타일을 골라서 네비게이션 영역을 그려줘야 하는데, 타일 종류가 많아지면 이게 꽤 번거롭다. 그리고 타일맵을 수정할 때마다 네비게이션이 제대로 반영됐는지 확인해야 했다.

더 큰 문제는 Y-sort와 함께 쓸 때였다. 유닛이 Y축 기준으로 렌더링 순서가 바뀌어야 하는데, 타일맵 내장 네비게이션에서 이 부분이 예상대로 안 됐다. 레이어 구조를 맞추는 게 복잡했다.

NavigationRegion2D로 바꿨다

방법은 생각보다 단순하다. NavigationRegion2D 노드를 씬에 추가하고, NavigationPolygon을 직접 그려주면 된다. 타일맵과 분리된 별도 노드니까 타일맵을 바꿔도 네비게이션은 독립적으로 유지된다.

에디터에서 폴리곤을 직접 그리는 방식이라 “이 지역은 못 지나간다”를 시각적으로 확인하면서 설정할 수 있다. 장애물 영역을 StaticBody2D 대신 NavigationObstacle2D로 추가하는 것도 직관적이었다.

Y-sort 문제 해결

NavigationRegion2D로 바꾸면서 씬 구조도 정리했다. TileMap은 렌더링 전용으로 두고, 네비게이션은 완전히 별도 레이어로 분리했다. 유닛들은 Y-sort가 활성화된 노드 아래에 배치해서 Y축 기준 렌더링 순서가 자동으로 적용되도록 했다.

이렇게 하니까 타일맵 위를 걷는 유닛이 타일 뒤에 가려지거나 앞에 나오는 게 자연스럽게 됐다. 2D 게임에서 2.5D 느낌을 내려면 Y-sort가 핵심인데, 네비게이션을 분리하고 나서야 제대로 동작했다.

정리하자면

타일맵 내장 네비게이션은 작은 맵이나 단순한 구조에서는 괜찮다. 하지만 Y-sort가 필요하거나 맵을 자주 바꿀 계획이라면 NavigationRegion2D로 분리하는 게 낫다. 초반에 구조를 제대로 잡는 게 나중에 고치는 것보다 훨씬 덜 힘들다는 걸 직접 경험했다.

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

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

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

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