첫 유니티 게임을 만들면서 느낀 Claude Code의 장단점
What Claude Code was good at (and bad at) while I built my first Unity game
핵심 요약
Claude Code를 활용해 유니티 게임을 개발하며 겪은 효율적인 작업 방식과 시각적 피드백의 한계를 공유합니다.
- 코드 작성 효율성 — 혀, 상점 로직 등 독립적인 시스템 구현에는 매우 효과적임
- 시각적 디버깅 한계 — 플레이 모드에서만 발생하는 오류는 Claude가 파악하기 어려움
- 데이터 참조 중요성 — 인스펙터 값과 씬 구조를 명확히 전달해야 정확한 수정이 가능함
- 피드백 루프 — 오류 발생 시 스크린샷과 상세 데이터를 제공하는 방식이 필수적임
FrogPop은 내가 처음으로 만든 게임이야. 처음엔 Bubble Trouble 스타일의 작은 프로토타입으로 시작했는데, 만들다 보니 업그레이드, 유물, 상점, 함정, 보스까지 들어간 2D 아케이드 로그라이트가 돼버렸네.
프로젝트 내내 Claude Code를 썼어. 보통은 메커니즘 하나를 설명하고 관련 Unity 스크립트를 짚어주면, 알아서 C# 코드를 수정하게 시키는 식으로 했지. 혀 조작이나 버블 분열, 웨이브, 상점 로직 같은 독립적인 시스템에는 이게 아주 잘 먹혔어.
근데 플레이 모드에서만 이상하게 돌아가는 것들은 좀 골치 아프더라. 보스 하나가 벽을 뚫고 다니면서 약점을 노출하는 패턴이 있는데, Claude가 공격 상태랑 히트박스 로직은 잘 짜도 자꾸 엉뚱한 데서 오브젝트가 튀어나오거나 공격 끝났는데도 활성화돼 있는 문제가 생기는 거야. 결국 내가 직접 테스트해서 무슨 일이 일어났는지 정확히 캡처한 다음, 그 좁은 문제만 딱 집어서 Claude한테 다시 던져주는 게 제일 확실하더라고.
그리고 씬이나 인스펙터에 직렬화된 값들이 코드만 보면 다 알 수 있는 게 아니라는 것도 배웠어. 프로젝트 규모가 커지니까, Claude한테 수정시키기 전에 실제 오브젝트랑 직렬화된 설정을 먼저 확인하게 하는 게 훨씬 낫더라. 안 그러면 자신만만하게 틀린 수정안을 내놓는 경우가 많거든.
지금 10웨이브까지 있는 데모 영상인데, 브라우저에서 바로 돌릴 수 있어:
다른 Unity 유저들은 플레이 모드에서 Claude한테 시각적인 피드백 줄 때 어떻게 하고 있어?
