한국 게임 개발자 노트

Unity 에디터 도구 설정이 재컴파일마다 초기화될 때, ScriptableSingleton 저장 위치부터 확인하세요

서론빌드 경로, 개발 빌드 여부, 마지막으로 선택한 플랫폼처럼 에디터 도구가 기억해야 할 값이 있다. 이를 EditorWindow 필드나 static 변수에만 넣으면 스크립트 재컴파일과 에디터 재시작 뒤에 값이 사라진다.EditorPrefs로 옮기면 저장은 되지만 프로젝트별 설정과 사용자 개인 설정이 섞이기 쉽다. Unity의 ScriptableSingleton을 사용하면 에디터 전용 상태를 직렬화하고, 저장 위치까지 명시적으로 결정할 수 있다.1. static 필드가 해결책이 아닌 이유static은 접근하기 편하지만 영속 저장소가 아니다. Domain Reload가 발생하면 초기화되며, Reload Domain을 꺼도 에디터 재시작까지 버티지는 못한다.Unity 공식 문서에 따르면 ScriptableS..

Unity에서 시간차 연출이나 비동기 로딩을 구현할 때 가장 먼저 떠오르는 도구는 코루틴이다. 하지만 작업이 여러 단계로 이어지면 yield return이 중첩되고, 반환값과 예외를 다루기도 불편해진다.Unity의 Awaitable은 이런 흐름을 C#의 async와 await 문법으로 표현한다. 다음 프레임, 물리 프레임, 지정 시간뿐 아니라 메인 스레드와 백그라운드 스레드 전환도 명시할 수 있다. 특히 로딩 화면, 절차적 데이터 생성, 복잡한 UI 연출처럼 순서가 중요한 코드에서 효과가 크다.코루틴을 프레임 단위 Awaitable로 바꾸기다음 코드는 오브젝트가 파괴되거나 플레이 모드가 종료될 때 자동으로 중단되는 페이드 처리다.using System.Threading;using UnityEngine;p..

AI 코딩 도구를 게임 개발에 붙일 때 가장 위험한 작업은 의외로 새 기능 구현이 아니라 리팩터링이다. Claude Code, Cursor, Copilot 같은 도구는 파일을 빠르게 읽고 고치지만, 게임 프로젝트에서는 작은 구조 변경 하나가 프리팹 참조, 직렬화 필드, Addressables 키, 애니메이션 이벤트까지 건드릴 수 있다.그래서 AI에게 “이 코드 정리해줘”라고 던지는 방식은 좋지 않다. 대신 변경 범위, 금지 영역, 검증 명령을 먼저 정해두고, AI가 그 안에서만 움직이게 만드는 워크플로우가 필요하다. 핵심은 AI를 똑똑한 개발자로 믿는 것이 아니라, 빠른 작업자에게 명확한 작업 계약서를 주는 것이다.1. 리팩터링 전에 변경 범위 계약서를 만든다AI에게 바로 코드를 수정시키기 전에 짧은 작..

게임 프로젝트가 커질수록 문제는 코드보다 콘텐츠에서 먼저 터집니다. 씬에 비활성화된 테스트 오브젝트가 남아 있거나, 라이트가 누락되거나, 프리팹 이름 규칙이 깨진 상태로 머지되면 빌드 직전까지 아무도 모르는 경우가 많습니다.이때 AI 보조 도구를 단순 코드 작성기가 아니라 반복 점검 봇 제작 도우미로 쓰면 효과가 큽니다. 사람이 “우리 팀 씬 규칙은 이렇다”고 설명하면, AI가 Unity BatchMode에서 돌릴 수 있는 Editor 스크립트 초안을 만들고, 우리는 그 결과를 팀 규칙에 맞게 다듬습니다.핵심은 Unity Editor를 열지 않고도 명령줄에서 씬을 검사하고, JSON 리포트를 남기는 구조입니다. CI에 붙이기도 쉽고, 매일 아침 자동 실행해 콘텐츠 품질을 확인하기도 좋습니다.1. AI에게..

Unity 프로젝트가 커질수록 빌드는 단순히 Build 버튼을 누르는 일이 아니게 됩니다. 개발 빌드인지, 릴리즈 빌드인지, 서버 주소는 맞는지, 버전 번호는 올렸는지, 테스트용 씬이 섞이지 않았는지까지 확인해야 합니다.문제는 이런 체크가 사람 손에 맡겨지면 언젠가는 빠진다는 점입니다. 특히 팀 프로젝트에서는 한 명은 Android, 한 명은 Windows, 한 명은 QA 빌드를 만들면서 설정이 조금씩 달라지기 쉽습니다.이럴 때 Unity의 BuildPlayerWindow.RegisterBuildPlayerHandler를 쓰면 기본 Build 버튼을 우리 팀 전용 빌드 파이프라인으로 바꿀 수 있습니다. 오늘은 에디터에서 버튼을 누르는 순간 검증, 경로 생성, 빌드 옵션 적용까지 한 번에 처리하는 구조를 ..

게임 개발에서 AI 도구가 가장 잘하는 일은 "대신 생각해 주기"보다 "반복 작업을 빠르게 닫아 주기"에 가깝다. 특히 Unity 프로젝트에서 성능 문제를 잡을 때는 원인 추정, 계측 코드 추가, 로그 비교, 작은 패치 작성이 계속 반복된다. Claude Code, Cursor, Copilot을 잘 쓰면 이 루프를 꽤 짧게 만들 수 있다.핵심은 AI에게 막연히 "최적화해 줘"라고 맡기지 않는 것이다. 대신 실험 단위를 작게 자르고, 계측 기준을 코드로 고정하고, AI가 읽을 수 있는 로그를 남겨야 한다. 그러면 AI는 감이 아니라 증거를 바탕으로 수정 후보를 제안한다.1. 먼저 계측 지점을 코드로 고정한다성능 개선의 첫 단계는 "어디가 느린지"를 매번 같은 방식으로 재는 것이다. Unity에서는 Prof..

게임 코드에서 콜백을 다룰 때 우리는 습관적으로 Action이나 Func 같은 delegate를 꺼낸다. 이벤트 버스, 상태 머신, 명령 큐, 데미지 계산 파이프라인까지 거의 모든 곳에 delegate가 들어간다. 문제는 이게 매 프레임 수천 번 도는 뜨거운 경로(hot path)에 올라타는 순간이다.delegate는 생각보다 무겁다. 람다가 지역 변수를 캡처하면 힙에 객체가 하나 생기고, 멀티캐스트면 호출 목록(invocation list)을 따라가며 간접 호출이 일어난다. 한두 번이면 무시할 만하지만, 1만 개 유닛이 매 프레임 각자 콜백을 부르면 이야기가 달라진다. GC 압박이 쌓이고 프레임이 튄다.C# 9부터 들어온 함수 포인터(delegate*)는 이 문제를 정면으로 푼다. 객체도 캡처도 없이 ..

2026년 게임 산업의 한 흐름은 꽤 분명하다. 라이브서비스와 크로스플랫폼, 경쟁형 멀티플레이어가 매출의 중심이 되면서, 올해 GDC와 Unite의 멀티플레이어 세션마다 빠지지 않고 등장한 키워드가 하나 있다. 바로 server-authoritative, 우리말로 "서버 권위" 구조다.한때는 P2P나 클라이언트 권위 방식으로 일단 빠르게 출시하던 시절이 있었다. 구현이 단순하고 서버 비용도 적게 들기 때문이다. 그런데 치팅 신고가 곧장 매출과 평판으로 직결되고, PC와 콘솔과 모바일이 한 서버에서 같이 노는 크로스플레이가 기본값이 되면서, "최종 판단은 무조건 서버가 한다"는 구조가 다시 표준으로 올라왔다.문제는 서버 권위가 공짜가 아니라는 점이다. 모든 결정을 서버가 내리면 입력이 화면에 반영되기까지 ..

라이브 서비스 게임을 운영하다 보면 세이브 데이터 구조는 한 번도 가만히 있지 않는다. 새 스탯이 붙고, 인벤토리 포맷이 바뀌고, 안 쓰는 필드가 빠진다. 문제는 업데이트 시점에 이미 수만 명의 플레이어가 구버전 포맷으로 저장된 세이브를 들고 있다는 점이다. 패치 한 번에 누군가의 진행도가 날아가면 그건 단순 버그가 아니라 사고다.그래서 세이브 마이그레이션 코드를 짠다. v1을 v2로, v2를 v3로 옮기는 변환 코드다. 그런데 이 작업은 지독하게 지루하면서 동시에 실수 비용이 크다. 필드 하나 매핑을 빠뜨리면 골드가 0으로 초기화되고, 타입 변환을 잘못하면 파싱이 통째로 깨진다. 패턴은 뻔하고, 분량은 많고, 틀리면 유저 데이터가 증발한다. 딱 AI 코딩 에이전트에게 위임하기 좋은 형태다.다만 핵심은 ..

Unity 에디터 도구를 만들 때 오랫동안 표준이었던 OnGUI 기반 IMGUI는 단점이 뚜렷하다. 매 프레임 전체 UI를 다시 그리고, 레이아웃 코드와 로직 코드가 뒤섞이며, 복잡한 UI일수록 유지보수가 기하급수적으로 어려워진다. "이 슬라이더 위에 레이블 하나 얹으려면 GUILayout 세 줄을 수정해야 한다"는 상황이 낯설지 않을 것이다.Unity 2021.1부터 안정화된 UI Toolkit(구 UIElements)은 이 문제를 구조적으로 해결한다. HTML에 해당하는 UXML로 레이아웃을 선언하고, CSS에 해당하는 USS로 스타일을 분리하며, C# 코드는 이벤트 처리와 데이터 바인딩만 담당한다. 역할이 명확히 나뉘어 UI 디자이너와 프로그래머가 같은 화면을 동시에 작업할 수 있고, Unity 6..