처맞은 불곰의 개발이야기

처음에 유닛 충돌 처리를 CharacterBody2D의 CollisionShape2D 하나로 다 했다. 이동 충돌이랑 피격 판정이 같은 도형에 섞여 있으니까 뭔가 이상한 일이 계속 생겼다. 공격 범위가 이동 충돌과 간섭하거나, 팀 구분 없이 아군끼리도 피격 처리되는 식이었다.

역할을 나눴다

정리를 해보니 충돌에는 두 가지가 있었다. 이동할 때 벽이나 지형과 막혀야 하는 물리 충돌, 그리고 공격이 닿았을 때 데미지를 받는 피격 판정. 이걸 분리하기로 했다.

CollisionShape2D는 이동 전용으로만 남겼다. 피격 판정은 Hurtbox라는 Area2D를 따로 만들고, 공격 판정은 Hitbox라는 Area2D를 따로 만들었다. Hurtbox는 “나를 때릴 수 있는 영역”이고, Hitbox는 “내가 때리는 영역”이다.

팀 기반 레이어 설정

Area2D를 분리해도 아군끼리 피격되는 문제가 남았다. 이걸 해결한 게 collision layer/mask 동적 설정이다.

Godot에서는 Physics Layer를 비트마스크로 관리한다. ALLY 팀은 레이어 1, ENEMY 팀은 레이어 2로 정했다. Hurtbox는 자기 팀 레이어에 올리고, Hitbox는 상대 팀 레이어만 감지하도록 설정했다. 유닛이 생성될 때 team 값에 따라 동적으로 layer와 mask를 설정해주면 된다.

이렇게 하니까 코드에서 “상대방인지 확인” 같은 조건 없이도 Hitbox.body_entered 시그널이 항상 적군만 감지했다.

화살 관통도 자연스럽게

이 구조에서 화살 관통(pierce_count) 처리도 깔끔해졌다. Projectile에도 Hitbox를 붙이고 같은 레이어 규칙을 적용했다. 충돌할 때마다 pierce_count를 줄이고, 0이 되면 제거한다. Hurtbox/Hitbox 분리가 되어 있으니까 발사체도 같은 팀 충돌 규칙을 그대로 재사용했다.

정리하자면

이동 충돌과 피격 판정을 같은 Shape으로 처리하면 책임이 섞여서 나중에 고치기 어려워진다. Hurtbox/Hitbox로 분리하고 팀 기반 레이어를 설정하는 게 처음엔 번거로워 보여도, 이후 모든 전투 관련 기능을 훨씬 단순하게 만들어준다.

아처가 활을 쏠 때 화살이 언제 나가야 하는지가 생각보다 까다로운 문제였다. 처음엔 공격 애니메이션이 시작되는 순간 화살을 발사했는데, 비주얼이 이상했다. 활시위를 당기는 모션이 아직 진행 중인데 화살이 튀어나가 버렸다.

애니메이션 프레임과 타이밍을 맞춰야 한다

해결 방법은 애니메이션의 특정 프레임에서 화살을 발사하는 거다. AnimationPlayer의 애니메이션에 커스텀 트랙을 추가하거나, frame_changed 시그널을 연결해서 특정 프레임 번호일 때 발사 로직을 실행하면 된다.

Tiny Reign에서는 AnimatedSprite2D를 쓰고 있어서 frame_changed 시그널을 활용했다. 아처 공격 애니메이션에서 활시위가 완전히 당겨지는 프레임 번호를 찾아서, 그 프레임에서만 발사 함수를 호출하도록 했다.

구현 방법

AnimatedSprite2D의 frame_changed 시그널을 연결하고, 현재 animation이 “attack”이면서 frame 번호가 공격 판정 프레임일 때만 처리한다. 프레임 번호는 CSV에서 attack_frame으로 관리해서 유닛마다 다르게 설정할 수 있게 했다.

근거리 유닛은 같은 방식으로 Hitbox Area2D를 활성화한다. 검을 휘두르는 애니메이션에서 칼날이 닿는 프레임에 Hitbox를 켜고, 다음 프레임에 끈다. 이렇게 하면 공격 판정이 비주얼과 딱 맞아떨어진다.

여러 번 발동되는 문제

주의할 점이 있다. frame_changed는 매 프레임 호출된다. 공격 판정 프레임에서 발사 함수를 호출했는데, 같은 프레임에 시그널이 두 번 오는 경우가 있었다. 이미 발사했으면 무시하는 플래그를 두거나, attack_cooldown으로 중복 발사를 막아야 한다.

정리하자면

공격 판정을 코드 타이머로 처리하면 애니메이션 속도가 바뀔 때마다 타이밍을 다시 맞춰야 한다. 프레임 기반으로 처리하면 애니메이션 자체가 기준이 되니까 훨씬 직관적이다. 비주얼과 게임 로직이 일치하는 건 생각보다 플레이 느낌에 큰 영향을 준다.

아처 유닛을 만들면서 화살 발사체를 어떻게 구현할지 고민했다. 일단 화살 하나만 필요했지만, 나중에 마법 투사체나 다른 발사체가 생길 수도 있었다. 그래서 Projectile 베이스 클래스를 만들고 Arrow가 상속받는 구조로 갔다.

베이스 클래스에는 공통 로직만

Projectile은 발사체가 공통으로 가져야 할 것들만 담았다. 이동, 팀 정보, 공격력, 목표 설정, 충돌 처리가 그것이다. 충돌이 일어나면 상대방 CombatComponent를 찾아서 데미지를 넣고, 피격 처리 후 발사체를 제거한다.

이동 방식이나 애니메이션은 자식 클래스에서 구현하도록 _move() 같은 가상 함수를 열어뒀다. Arrow에서 이걸 오버라이드해서 포물선 이동을 구현했다.

포물선 이동

화살이 직선으로 날아가면 심심하다. 포물선을 주고 싶었다. 구현은 생각보다 단순하다. 발사 시점과 목표 지점을 기준으로 진행 비율(t)을 0에서 1로 올리면서, Y축에 포물선 오프셋을 더해준다.

오프셋은 sin(t * PI) * arc_height로 계산했다. t가 0이면 0, 0.5면 최대 높이, 1이면 다시 0이 된다. arc_height를 CSV에서 받아오니까 화살마다 다른 궤도를 줄 수 있었다.

관통 처리

화살에 pierce_count를 추가했다. 충돌할 때마다 1씩 줄이고, 0이 되면 제거한다. 기본값은 1이고, 특수 화살은 2나 3으로 설정하면 여러 유닛을 관통한다.

이 기능을 베이스 클래스에서 처리해뒀으니까 Arrow뿐 아니라 다른 발사체를 추가해도 관통 로직을 다시 짤 필요가 없다.

스폰은 팩토리에서

화살을 발사할 때마다 인스턴스를 생성하면 성능 문제가 생길 수 있다. CharacterFactory Autoload에서 발사체 풀을 관리하게 했다. 사용하지 않는 발사체를 재사용하는 방식이다.

정리하자면

발사체 베이스 클래스 하나를 제대로 잡아두니까 나중에 새 발사체를 추가할 때 공통 로직을 다시 짜지 않아도 됐다. 상속 구조가 항상 좋은 건 아니지만, 발사체처럼 공통점이 많은 경우엔 효과적이었다.

유닛 AI를 어떻게 구현할지 고민을 꽤 했다. 상태 머신(State Machine)이 첫 번째 선택지였는데, 상태가 늘어날수록 전환 조건이 복잡해지는 게 걱정됐다. 찾아보다가 LimboAI라는 Godot 플러그인을 알게 됐고, 비헤이비어 트리(Behavior Tree)를 써보기로 했다.

비헤이비어 트리가 뭔가

비헤이비어 트리는 AI 행동을 트리 구조로 표현한다. 루트부터 시작해서 조건을 검사하고, 성공/실패에 따라 다음 노드로 넘어간다. Selector는 자식 중 하나가 성공하면 멈추고, Sequence는 모든 자식이 성공해야 다음으로 넘어간다.

Tiny Reign 유닛의 기본 흐름은 이렇다. 적이 감지 범위 안에 있으면 추격하고, 공격 범위 안에 들어오면 공격한다. 감지된 적이 없으면 깃발 위치로 이동하거나 대기한다. 이 흐름을 비헤이비어 트리로 표현하면 코드보다 훨씬 읽기 쉽다.

커스텀 태스크 작성

LimboAI에서 AI 행동 하나하나는 BTTask를 상속받아 구현한다. BTDetectEnemy, BTChaseEnemy, BTAttackEnemy 같은 식으로 각각 파일을 만들었다.

태스크는 _tick() 함수에서 매 프레임 실행되고 SUCCESS, FAILURE, RUNNING 중 하나를 반환한다. RUNNING을 반환하면 다음 프레임에도 계속 실행된다. BTChaseEnemy는 목표까지 이동하는 동안 RUNNING을 반환하고, 목표에 도달하면 SUCCESS를 반환하는 식이다.

유닛마다 트리를 바꿀 수 있다

몽크는 공격 대신 힐을 써야 해서 일반 유닛과 행동이 다르다. LimboAI에서는 .tres 파일로 비헤이비어 트리를 저장하고 유닛마다 다른 트리를 붙일 수 있다. archer_bt.tres, monk_bt.tres 이런 식으로 분리했다.

새 유닛을 추가할 때 기존 태스크를 재사용하면서 트리 구조만 바꾸면 된다. 코드를 복사할 필요 없이 트리 에디터에서 노드를 조합하면 됐다.

정리하자면

비헤이비어 트리는 처음 배우는 데 시간이 좀 걸린다. 그런데 일단 구조를 이해하고 나면 AI 행동을 추가하거나 수정하기가 상태 머신보다 훨씬 편하다. LimboAI는 Godot 4 에디터 안에서 트리를 시각적으로 편집할 수 있어서 더 좋았다. 여러 유닛 AI를 관리해야 한다면 추천한다.

그냥 켜면 안 된다

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