한국 게임 개발자 노트

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

인디 게임이나 소규모 스튜디오에서 현지화(Localization)는 항상 마지막에 몰려서 처리하는 항목이다. 기획이 어느 정도 완성된 뒤에야 "아, 영어도 넣어야지"가 나오는 경우가 대부분이고, 그 결과로 번역 파일 관리는 엑셀·노션·구글 시트가 뒤섞인 상태가 된다. Unity에 실제 반영할 때마다 누가 어느 키를 빠뜨렸는지 찾느라 반나절이 날아가는 건 흔한 풍경이다.Unity는 공식 Localization Package를 제공한다. 키-값 테이블 기반으로 String Table과 Asset Table을 관리하고, CSV 임포트/익스포트도 지원한다. 구조는 탄탄한데 문제는 번역 데이터를 채우는 과정이다. 지원 언어가 5개라면 같은 키 집합을 5배로 관리해야 하고, 용어 일관성까지 신경 쓰면 손이 몇 배로..

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

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