Claude Code, Cursor, Copilot을 갈아타도 작업이 이어지는 Unity 인수인계 규칙 5가지

Claude Code로 구조를 고치고, Cursor에서 코드를 탐색한 뒤, Copilot으로 반복 구현을 채우는 식의 혼합 워크플로우가 늘고 있다. 문제는 도구마다 이전 대화와 판단 근거를 공유하지 않는다는 점이다. 같은 설명을 반복하거나, 이미 폐기한 설계를 다른 도구가 다시 제안하기도 한다.

해결책은 긴 채팅 기록을 복사하는 것이 아니다. 목표, 수정 범위, 검증 방법을 저장소 안의 작은 작업 패킷으로 만드는 것이다. 다음 다섯 규칙을 적용하면 어느 도구를 열어도 같은 지점에서 작업을 이어갈 수 있다.

1. 목표 한 줄과 변경 금지선을 먼저 고정한다

첫 번째 규칙은 작업 목표를 결과 형태로 적는 것이다. “인벤토리를 개선해 줘”보다 “아이템 이동 후 슬롯 중복이 없고 기존 저장 데이터를 읽을 것”이 훨씬 강한 지시다.

두 번째 규칙은 수정 가능한 경계를 명시하는 것이다. 예를 들어 Inventory 폴더와 테스트만 허용하고 저장 포맷, 공개 API, 프리팹은 변경하지 못하게 한다. AI가 주변 구조까지 정리하다가 변경량을 키우는 일을 막아 준다.

public readonly record struct InventoryTaskContract(
    int MaxSlotCount,
    bool PreserveSaveFormat,
    bool AllowPrefabChanges);

public static class InventoryTask
{
    public static readonly InventoryTaskContract Contract = new(
        MaxSlotCount: 40,
        PreserveSaveFormat: true,
        AllowPrefabChanges: false);
}

이 계약은 런타임 설정이라기보다 사람과 AI가 함께 보는 기준점이다. 프로젝트가 최신 C# 문법을 지원하지 않는다면 동일한 내용을 일반 struct나 문서로 표현해도 된다.

2. 설명 대신 실행 가능한 완료 조건을 건넨다

세 번째 규칙은 완료 조건을 테스트로 만드는 것이다. “정상 동작해야 한다”는 도구마다 해석이 다르지만, 실패하는 테스트는 해석의 여지가 없다.

네 번째 규칙은 테스트 이름에 요구사항을 그대로 남기는 것이다. 새 도구가 대화 없이 테스트 목록만 읽어도 의도를 복구할 수 있다.

using NUnit.Framework;

public sealed class InventoryTests
{
    [Test]
    public void MoveItem_DestinationOccupied_DoesNotDuplicateItem()
    {
        var inventory = new Inventory(40);
        inventory.Add(0, new Item("Potion"));
        inventory.Add(1, new Item("Sword"));

        inventory.Move(0, 1);

        Assert.That(inventory.Count("Potion"), Is.EqualTo(1));
        Assert.That(inventory.Count("Sword"), Is.EqualTo(1));
    }
}

AI에게는 “이 테스트를 통과시켜라”만 지시하지 말고 기존 테스트 유지, 컴파일 성공, 새 경고 금지까지 함께 요구한다. 그러면 구현만 바꾸고 회귀 문제를 남기는 결과를 줄일 수 있다.

3. 마지막에는 대화 요약이 아니라 변경 증거를 남긴다

다섯 번째 규칙은 도구를 바꾸기 전에 인수인계 스냅샷을 작성하는 것이다. 내용은 변경 파일, 결정한 설계, 실행한 검증, 남은 실패 네 가지면 충분하다.

목표: 슬롯 이동 시 아이템 중복 방지
변경: Inventory.Move, InventoryTests
결정: 점유 슬롯이면 두 아이템을 교환
검증: EditMode 테스트 18개 통과
남은 작업: 저장 데이터 버전 2 회귀 테스트 추가
금지: SaveData 구조와 프리팹 수정

새 도구에는 전체 채팅 대신 이 스냅샷과 현재 diff를 먼저 읽게 한다. 이후 “구현하지 말고 계약 위반과 누락된 테스트만 찾아라”라고 요청하면 독립 검토자로도 활용할 수 있다. 작성 도구와 검토 도구를 분리하면 같은 가정을 반복하는 위험도 낮아진다.

정리하면 다음과 같다.

• 목표는 기능명이 아니라 관찰 가능한 결과로 작성한다.
• 수정 가능 범위와 변경 금지선을 함께 고정한다.
• 완료 조건은 실행 가능한 테스트와 검증 명령으로 남긴다.
• 도구 전환 시 채팅보다 diff, 테스트 결과, 남은 실패를 전달한다.