AI에게 Unity 성능 실험 루프 맡기기: 로그 수집부터 패치 후보까지

게임 개발에서 AI 도구가 가장 잘하는 일은 "대신 생각해 주기"보다 "반복 작업을 빠르게 닫아 주기"에 가깝다. 특히 Unity 프로젝트에서 성능 문제를 잡을 때는 원인 추정, 계측 코드 추가, 로그 비교, 작은 패치 작성이 계속 반복된다. Claude Code, Cursor, Copilot을 잘 쓰면 이 루프를 꽤 짧게 만들 수 있다.

핵심은 AI에게 막연히 "최적화해 줘"라고 맡기지 않는 것이다. 대신 실험 단위를 작게 자르고, 계측 기준을 코드로 고정하고, AI가 읽을 수 있는 로그를 남겨야 한다. 그러면 AI는 감이 아니라 증거를 바탕으로 수정 후보를 제안한다.

1. 먼저 계측 지점을 코드로 고정한다

성능 개선의 첫 단계는 "어디가 느린지"를 매번 같은 방식으로 재는 것이다. Unity에서는 ProfilerMarker를 작게 심어 두면 AI가 로그와 코드를 함께 읽고 병목 위치를 훨씬 정확히 짚는다.

using Unity.Profiling;
using UnityEngine;

public sealed class EnemySensorSystem : MonoBehaviour
{
    private static readonly ProfilerMarker SensorTickMarker =
        new("EnemySensorSystem.Tick");

    [SerializeField] private EnemySensor[] sensors;

    private void Update()
    {
        using var _ = SensorTickMarker.Auto();

        foreach (var sensor in sensors)
        {
            sensor.Scan();
        }
    }
}

여기서 중요한 점은 마커 이름이다. Tick, Scan, BuildCache처럼 AI와 사람이 모두 이해하기 쉬운 이름을 붙이면 좋다. 나중에 Claude Code에게 "EnemySensorSystem.Tick이 프레임마다 4ms 이상 나온 원인을 찾아라"라고 지시할 수 있다.

2. AI에게 줄 로그 형식을 단순하게 만든다

AI 도구는 거대한 Profiler 캡처 파일보다 짧고 일관된 텍스트 로그를 잘 다룬다. 개발 빌드에서 특정 구간의 평균 시간과 호출 횟수를 남기면 Cursor나 Claude Code가 변경 전후를 비교하기 쉬워진다.

using System.Diagnostics;
using UnityEngine;

public sealed class FrameCostSampler : MonoBehaviour
{
    private readonly Stopwatch watch = new();
    private int samples;
    private long totalTicks;

    public void Begin() => watch.Restart();

    public void End(string label)
    {
        watch.Stop();
        totalTicks += watch.ElapsedTicks;
        samples++;

        if (samples == 120)
        {
            double ms = totalTicks * 1000.0 / Stopwatch.Frequency / samples;
            UnityEngine.Debug.Log($"[PerfSample] {label} avgMs={ms:F3} samples={samples}");
            samples = 0;
            totalTicks = 0;
        }
    }
}

이런 로그가 쌓이면 AI에게 다음처럼 요청한다.

아래 PerfSample 로그와 관련 C# 파일을 보고,
1. 가장 의심되는 할당 또는 반복 계산 지점을 찾아라.
2. 동작을 바꾸지 않는 최소 패치를 제안하라.
3. 수정 후 다시 확인할 로그 기준을 적어라.

이 프롬프트의 장점은 결과물이 명확하다는 것이다. AI는 추상적인 조언 대신 파일 단위 패치, 검증 기준, 남은 위험을 내놓게 된다.

3. Copilot은 작성 보조, Cursor는 주변 맥락, Claude Code는 패치 루프

세 도구를 같은 방식으로 쓰면 효율이 떨어진다. Copilot은 현재 파일 안에서 반복 코드를 빠르게 채우는 데 좋다. 예를 들어 샘플러 호출, null 체크, 작은 캐시 필드 추가 같은 작업에 적합하다.

Cursor는 여러 파일을 열어 둔 상태에서 "이 시스템이 어디서 호출되는지"를 따라갈 때 좋다. Unity 프로젝트에서는 MonoBehaviour, ScriptableObject, Addressables, 입력 시스템이 얽히기 쉬우므로 주변 맥락 검색이 중요하다.

Claude Code는 조금 더 큰 루프에 맞다. 예를 들어 "계측 코드 추가, 테스트 실행, 로그 요약, 최소 수정"처럼 터미널과 파일 수정이 같이 필요한 작업에 강하다. 단, 한 번에 전체 시스템을 고치게 하기보다 작은 목표를 준다.

목표: EnemySensorSystem.Update의 평균 시간을 줄인다.
제약: 게임플레이 결과는 바꾸지 않는다.
허용: 캐싱, 임시 리스트 재사용, 불필요한 LINQ 제거.
금지: 센서 판정 반경, 레이어 규칙, 호출 주기 변경.
검증: PerfSample avgMs가 20퍼센트 이상 감소해야 한다.

4. AI 패치는 항상 검증 명령까지 같이 받는다

AI가 제안한 코드는 그럴듯해 보여도 Unity 생명주기나 에디터 전용 API를 놓칠 수 있다. 그래서 패치만 받지 말고 확인 명령도 함께 받아야 한다. 최소한 컴파일, 플레이 모드 테스트, 로그 비교 기준을 묶는다.

#if UNITY_EDITOR
using UnityEditor;
#endif
using UnityEngine;

public static class BuildGuard
{
    [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSceneLoad)]
    private static void Check()
    {
#if UNITY_EDITOR
        if (EditorApplication.isPlayingOrWillChangePlaymode)
        {
            Debug.Log("[BuildGuard] Play mode validation active");
        }
#endif
    }
}

이런 전처리 조건 하나만 빠져도 플레이어 빌드가 깨질 수 있다. AI에게 "에디터 전용 네임스페이스가 런타임 어셈블리에 새지 않았는지 확인하라"라고 적어 두면 실수를 줄일 수 있다.

결론

AI 보조 게임 개발 워크플로우의 핵심은 도구 이름이 아니라 반복 구조다. 계측 지점을 만들고, 짧은 로그를 남기고, AI에게 최소 패치와 검증 기준을 함께 요구한다. Copilot은 작성 속도를 올리고, Cursor는 주변 맥락을 찾고, Claude Code는 수정과 검증 루프를 닫는 역할로 나누면 생산성이 안정적으로 오른다. 성능 최적화도 결국 감이 아니라 측정, 수정, 재측정의 반복이다. AI는 이 반복을 빠르게 만드는 도구로 쓸 때 가장 강하다.