Godot 4 + Claude Code로 인디게임 만들기 2부 – 제작소 6종 완성과 전투 시스템 설계

Godot 4 + Claude Code로 인디게임 만들기 2부 – 제작소 6종 완성과 전투 시스템 설계

📅 2026년 7월  |  ⏱️ 읽는 시간 약 13분  |  🏷️ Godot, ClaudeCode, 인디게임개발, 바이브코딩, 개발일지, 카드포지

💡 이 글에서 얻을 수 있는 것
1부에서 카드 포지의 데이터 구조와 제작소 로직 3종 세트, 메인 UI까지 다뤘습니다. 2부에서는 남은 제작소 시설(용광로·수리대·분해기)을 완성해 6개 시설 전체를 마무리하고, 이어서 게임의 핵심이라 할 수 있는 전투 시스템을 설계하기 시작한 과정을 정리합니다. 실제로 겪은 버그와 QA 체크포인트도 함께 기록했습니다.

📋 목차

1. 1부 요약 – 어디까지 왔나
2. 실전에서 만난 버그 – RichTextLabel 정렬 이슈
3. QA 체크포인트로 검증하기
4. 분해기(Salvage Mill) 구현
5. 제작소 6종 완성
6. 전투 시스템 설계 시작
7. 턴 구조 결정하기
8. 2부에서 얻은 교훈
9. 다음 단계 예고

1. 1부 요약 – 어디까지 왔나

1부에서는 Godot MCP 연동, CLAUDE.md 작성, 데이터 구조(CardData·EffectData·MaterialData), 제작소 로직 3종 세트(ForgeManager·InventoryManager·EffectRegistry), 그리고 제작소 메인 화면까지 구현했습니다.

제작소 시설	1부 종료 시점 상태
작업대	✅ 완료
효과부여대	✅ 완료
용광로	🔄 진행 예정
수리대	🔄 진행 예정
분해기	⏳ 미착수
덱편성대	🔄 진행 예정

2부 시작 시점에는 용광로, 수리대, 덱편성대까지 거의 완성된 상태였고, 마지막으로 분해기만 남아있었습니다.

2. 실전에서 만난 버그 – RichTextLabel 정렬 이슈

여러 시설 씬을 작업하던 중, Godot의 RichTextLabel 노드에 존재하지 않는 프로퍼티를 사용해 오류가 발생한 적이 있습니다.

⚠️ 발생한 문제: RichTextLabel에 horizontal_alignment 프로퍼티를 설정하려 했지만, 이 프로퍼티는 RichTextLabel에 존재하지 않습니다. (일반 Label 노드에만 있는 프로퍼티입니다.)

해결 방법 – BBCode로 정렬 처리
존재하지 않는 프로퍼티를 지우고, 대신 텍스트 자체에 BBCode 태그를 삽입해 가운데 정렬을 구현했습니다.

## 수정 전 (오류 발생) $RichTextLabel.horizontal_alignment = HORIZONTAL_ALIGNMENT_CENTER ## 수정 후 (BBCode 방식) $RichTextLabel.text = "[center]" + card_name + "[/center]"

💡 배운 점: Godot의 UI 노드마다 지원하는 프로퍼티가 다릅니다. Label과 RichTextLabel처럼 비슷해 보이는 노드도 실제 API는 다르므로, Claude Code가 만든 코드라도 에디터에서 F5로 직접 실행해 확인하는 과정이 꼭 필요했습니다.

3. QA 체크포인트로 검증하기

여러 시설을 한꺼번에 만들다 보면 "다 됐다"는 보고만 믿고 넘어가기 쉽습니다. 그래서 시설이 완성될 때마다 구체적인 체크포인트를 세워 F5로 직접 확인하는 습관을 들였습니다.

용광로·수리대 QA 체크리스트

1. 용광로: 카드 선택 → 부족 재료가 빨갛게 보이는지 → 승급 버튼 정상 동작하는지 2. 수리대: 손상 카드만 필터링되는지 → "수리" vs "전체 수리" 버튼 동작 차이 확인 3. 재료 차감: 용광로/수리대 이용 후 제작소로 복귀 → 하단 재료 바 수량이 실제로 줄었는지 확인

💡 재료 차감 확인이 특히 중요했습니다. 시설 안에서는 정상으로 보여도, 제작소 메인으로 돌아왔을 때 InventoryManager의 material_changed 시그널이 제대로 발생하지 않으면 재료 바가 갱신되지 않는 버그가 생길 수 있기 때문입니다.

4. 분해기(Salvage Mill) 구현

마지막 남은 시설인 분해기를 구현했습니다. 분해기는 카드를 재료로 되돌리는 기능으로, 실패한 조합이나 필요 없어진 카드를 처리할 수 있게 해줍니다.

분해기 화면 구조 요청 프롬프트

"분해기를 만들어줘. scenes/forge/salvage_mill.tscn + scripts/forge/salvage_mill.gd 화면 구조 (1280x720): - 상단: HBoxContainer (← 제작소 / '분해기') - 중앙: HBoxContainer (2분할) 좌측 '카드 선택' (ScrollContainer > VBoxContainer): - InventoryManager.cards 목록 - '[화염] 검술 (희귀)' 형식 - 전설 카드는 '(분해 불가)' 표시하되 선택은 가능 - 클릭 시 selected_card 저장 + 우측 미리보기 갱신 우측 '분해 결과' (PanelContainer): - 카드 미선택: '카드를 선택하세요' - 전설 카드: '전설 등급 카드는 분해할 수 없습니다' - 일반/희귀/영웅: 돌아오는 재료 표시 - 하단: Button '분해' (전설은 disabled) 클릭 시: 1. ForgeManager.salvage_card() 호출 2. InventoryManager.add_material()로 재료 추가 3. InventoryManager.remove_card()로 카드 제거 4. 카드 목록 갱신 + selected_card 초기화"

설계에서 신경 쓴 디테일

디테일	이유
전설 카드도 목록에는 표시, 버튼만 비활성화	전설 카드가 목록에서 아예 사라지면 "카드가 없어졌나?" 하는 혼란 방지
분해 전 결과 미리보기 제공	어떤 재료가 몇 개 나올지 미리 알아야 되돌릴 수 없는 선택을 신중히 함
분해 후 selected_card 초기화	이미 사라진 카드를 계속 선택 상태로 두면 참조 오류 발생 가능

✅ 분해기 씬(salvage_mill.tscn)과 스크립트가 생성되고, forge_main.gd의 분해기 버튼 연결까지 완료되었습니다.

5. 제작소 6종 완성

분해기가 완성되면서 제작소의 6개 시설이 모두 동작하게 되었습니다.

제작소 메인
  ├─ 작업대 (카드 제작) ✅
  ├─ 효과부여대 (효과 장착/교체) ✅
  ├─ 용광로 (카드 승급) ✅
  ├─ 수리대 (카드 수리) ✅
  ├─ 분해기 (카드 분해) ✅
  └─ 덱편성대 (덱 구성) ✅

💡 도감 시스템은 필수 기능이 아니라고 판단해 우선순위에서 뒤로 미뤘습니다. 게임의 핵심 루프(제작 → 전투 → 재료 획득)를 완성하는 것이 먼저였고, 도감처럼 수집 동기를 강화하는 부가 기능은 나중에 추가해도 되는 영역이었기 때문입니다.

제작소 UI 최종 레이아웃

┌─────────────────────────────────┐ │ [도감] [출발→던전] │ │ │ │ [분해기] [용광로] │ │ │ │ ┌──[작업대]──┐ │ │ │ (중앙) │ │ │ └────────────┘ │ │ │ │ [수리대] [효과부여대] [덱편성] │ │ │ │ [재료 인벤토리 바] │ └─────────────────────────────────┘

💡 작업대를 중앙에 배치하고 나머지 5개 시설을 주변에 배치한 것은, 가장 자주 쓰는 기능(카드 제작)을 화면 중심에 두어 클릭 동선을 최소화하기 위해서였습니다. 하단에는 재료 인벤토리 바를 상시 표시해 "이 재료로 뭘 만들 수 있지?"라는 생각을 자연스럽게 유도하도록 설계했습니다.

6. 전투 시스템 설계 시작

제작소가 완성되자 다음 단계를 정할 시점이 왔습니다. 도감, 전투 시스템, 설계서 v3 업데이트 중에서 전투 시스템 MVP를 선택했습니다.

📌 왜 전투부터인가: 아무리 제작소가 잘 만들어져도, 던전에서 전투를 치러야 재료가 떨어지고 게임의 핵심 루프(제작 → 전투 → 재료 획득 → 다시 제작)가 완성됩니다. 전투가 없으면 제작소는 "예쁜 화면"에 그칠 뿐입니다.

전투는 게임에서 가장 중요한 시스템이기 때문에, Claude Code로 바로 구현을 요청하지 않고 먼저 설계를 문서화하는 절차를 거쳤습니다.

전투 시스템 기초 설계 항목

설계 항목	확인 필요 내용
턴 구조	플레이어 턴(카드 선택→사용) → 적 턴(공격) 반복
리소스	HP(체력), 에너지(카드 사용 자원) 필요 여부
카드 사용 규칙	핸드 사이즈, 턴당 드로우 수, 카드별 코스트
효과 발동	기본 대미지 계산 후 확률 효과(예: 화상 30%) 발동 방식

MVP 범위 확정

전투 시스템 MVP 범위

• 플레이어 vs 단일 몬스터 (1:1 전투)
• 턴제 (플레이어 턴 → 적 턴 반복)
• 기본 대미지만 우선 구현 (효과는 이후 단계)
• 승리 조건: 적 HP 0 / 패배 조건: 플레이어 HP 0

💡 "효과는 나중에" 결정이 핵심이었습니다. 카드 포지는 15종 효과 시스템이 게임의 재미 요소지만, 전투의 뼈대(턴 진행, 대미지 계산, 승패 판정)가 먼저 안정적으로 돌아가야 그 위에 효과를 얹을 수 있습니다. 처음부터 모든 걸 한 번에 구현하려 하지 않고 단계적으로 복잡도를 쌓아가는 방식을 택했습니다.

7. 턴 구조 결정하기

전투 시스템에서 가장 먼저 확정해야 할 것은 턴 구조와 리소스 시스템이었습니다. 카드 게임에서 이 부분이 게임의 전략성을 결정짓는 핵심이기 때문에, 신중하게 옵션을 비교했습니다.

옵션	방식	장점	단점
1. 간단한 턴제	코스트 없이 매턴 카드 1장 선택	구현 쉬움, 진입장벽 낮음	전략성 낮음
2. 에너지 기반	매턴 에너지 회복, 카드마다 코스트	덱빌딩 전략성 높음 (슬레이 더 스파이어 스타일)	구현 복잡도 증가

📌 카드 포지는 덱빌딩이 핵심 장르이기 때문에, 최종적으로는 에너지 기반 시스템 쪽으로 설계가 이어질 가능성이 높은 상황에서 다음 세션으로 논의가 이어지고 있습니다.

8. 2부에서 얻은 교훈

교훈 1 – 노드별 API 차이는 실행해봐야 안다
Label과 RichTextLabel처럼 비슷해 보이는 노드도 지원 프로퍼티가 다릅니다. Claude Code가 코드를 작성했다고 끝이 아니라, F5로 직접 실행해서 오류를 확인하는 과정이 항상 필요했습니다.

교훈 2 – "다 됐다" 보고보다 QA 체크리스트
여러 시설을 연달아 만들 때는 "부족 재료 빨간 표시 확인", "재료 차감 후 메인 화면 갱신 확인"처럼 구체적인 체크포인트를 세워야 놓치는 부분 없이 검증할 수 있었습니다.

교훈 3 – 되돌릴 수 없는 액션은 미리보기 필수
분해기처럼 카드를 잃는 액션은 실행 전 결과를 미리 보여주는 것이 사용자 경험에서 중요했습니다.

교훈 4 – 핵심 시스템은 설계 먼저, 구현은 나중
전투처럼 게임의 중심이 되는 시스템은 Claude Code에게 바로 "만들어줘"라고 하지 않고, 턴 구조·리소스·MVP 범위를 먼저 문서로 확정한 후 구현에 들어가는 순서가 시행착오를 크게 줄여줬습니다.

9. 다음 단계 예고

Phase	내용	상태
Phase 1	데이터 구조 (Custom Resource 정의)	✅ 완료
Phase 2	제작소 UI (6개 시설 전체)	✅ 완료
Phase 3	전투 시스템 프로토타입	🔄 설계 진행 중
Phase 4	던전 루프 연결	⏳ 예정
Phase 5	밸런싱 & 폴리싱	⏳ 예정

제작소 6개 시설이 모두 완성되면서 게임의 "준비 단계"가 마무리되었습니다. 3부에서는 턴 구조(간단한 턴제 vs 에너지 기반)를 최종 확정하고, 실제 전투 씬을 Godot에서 구현하는 과정을 다룰 예정입니다. 이후 던전 노드 시스템(전투 노드·보물상자·이벤트 노드·휴식 노드·보스 노드)까지 연결하면 게임의 핵심 루프가 완성됩니다.

📌 Godot + Claude Code 개발 일지 시리즈
1부: 프로젝트 기획 + MCP 연동 + 제작소 로직/UI
2부: 제작소 6종 완성 + 전투 시스템 설계 ← 현재 글
3부: 전투 시스템 구현 & 던전 루프 (예정)