한국 게임 개발자 노트

AI 코딩 도구를 새 코드 짜는 데만 쓰고 있다면 절반만 쓰는 셈이다. Claude Code, Copilot, Cursor는 이미 작성된 코드를 읽고 문제를 짚어내는 데도 강하다. 특히 게임 코드처럼 "컴파일은 멀쩡히 되는데 프레임을 갉아먹는" 함정이 많은 영역에서 AI 리뷰는 사람이 눈으로 놓치기 쉬운 부분을 잘 잡는다.문제는 기본 상태의 AI 리뷰가 너무 일반적이라는 점이다. 변수명, 널 체크, 예외 처리 같은 웹 백엔드식 지적만 잔뜩 내놓고, 정작 게임에서 치명적인 매 프레임 힙 할당이나 박싱은 그냥 지나친다. 게임 코드 리뷰는 게임의 룰로 한 번 길들여야 비로소 쓸모가 생긴다.이 글에서는 Claude Code를 예로, 게임 전용 리뷰 기준을 파일로 박아두고 매 커밋 diff에 AI 리뷰어를 자동으..

AI 코딩 도구를 게임 개발에 써보면 곧바로 벽에 부딪힌다. 가장 큰 맹점은 AI가 "결과를 못 본다"는 것이다. Claude Code가 적 컴포넌트 코드를 멀쩡하게 짜줘도, 정작 실행 중인 씬에서 그 프리팹의 체력이 왜 0인지, Light가 몇 개나 켜져 있는지, NavMeshAgent의 speed가 어떻게 세팅됐는지는 전혀 모른다. 그래서 우리가 매번 인스펙터 값을 손으로 복사해 채팅창에 떠먹여 줘야 한다. 이 왕복이 생산성을 갉아먹는다.2024년 말 등장한 MCP(Model Context Protocol)가 바로 이 간극을 메운다. MCP는 AI 클라이언트가 외부 도구를 표준화된 방식으로 호출하게 해주는 프로토콜이다. 이걸로 Claude Code를 "실행 중인 Unity 에디터"에 직접 연결하면, ..

게임 프로젝트가 커질수록 기획 팀과 개발 팀 사이의 데이터 전달 마찰이 쌓인다. 기획자는 Google Sheets나 Excel에서 적 스탯, 아이템 가격, 스킬 쿨다운을 관리하고, 개발자는 그 CSV를 열어 하나하나 Unity ScriptableObject에 손으로 옮긴다. 중간에 오탈자 하나면 버그다.더 큰 문제는 이 과정이 반복된다는 점이다. 밸런스 패치가 있을 때마다, 열이 추가될 때마다, 새로운 적 타입이 생길 때마다 임포터 코드와 SO 클래스를 같이 수정해야 한다. 이 반복 작업을 AI 도구에 맡기면 어떻게 되는지 단계별로 살펴본다.Claude Code는 파일 시스템에 직접 접근해 에디터 스크립트를 작성하고 즉시 프로젝트에 배치할 수 있다. CSV 헤더 한 줄만 넘기면 ScriptableObje..

셰이더 코드는 게임 개발자가 가장 기피하는 작업 중 하나다. HLSL 문법, URP/HDRP 파이프라인 차이, 버텍스-프래그먼트 연결, SubShader 블록 구조... 처음 한 번만 헤매는 게 아니라, 프로젝트마다 매번 헤맨다. 예전에 짰던 셰이더 파일을 열어서 복붙하고, 어디서 읽었던 블로그 포스팅을 찾아 헤매고, Unity 문서에서 Properties 블록 문법을 다시 확인하는 반복이 이어진다.Cursor나 Claude Code 같은 AI 코딩 어시스턴트를 셰이더 작업에 적극 활용하기 시작한 뒤로 이 반복이 거의 사라졌다. "URP Lit 기반으로 림 라이트 추가해줘"라고 말하면 작동하는 코드가 나온다. 물론 그대로 쓰지는 않는다. 하지만 빈 파일에서 시작하는 것과, 80% 완성된 코드에서 20%를..

AI 코딩 도구를 게임 개발에 붙여보면 한 가지 벽에 부딪힌다. 웹 백엔드 코드는 AI가 기가 막히게 짜주는데, 게임플레이 로직은 자꾸 미묘하게 틀린다. 데미지 계산식이 한 끗 어긋나고, 쿨다운이 프레임 단위로 새고, 상태 전이가 엣지 케이스에서 무너진다. 그럴듯해 보이지만 돌려보면 다른 코드. 이게 게임 개발자가 AI 도구에 정을 못 붙이는 가장 큰 이유다.원인은 명확하다. 게임플레이 로직은 "맞는지"를 눈으로 확인하기 어렵다. 웹은 응답 JSON만 보면 되지만, 게임은 플레이 모드 들어가서 직접 때려봐야 안다. AI가 짠 코드가 맞는지 검증하는 비용이 너무 비싸니, 결국 사람이 다시 다 읽게 되고 생산성 이득이 증발한다.해결책은 의외로 고전적이다. 검증을 사람 눈이 아니라 테스트 코드에 맡기는 것. ..