유니티 사화 리팩토링

문제

시스템의 범위를 아무도 말할 수 없었습니다.

출시작은 기능이 필요할 때마다 매니저 클래스를 하나씩 늘리는 방식으로 커졌습니다. 그 결과:

• 새 기능을 넣을 때 어느 클래스에 붙여야 하는지 판단할 근거가 없음 — 매번 즉흥적으로 결정
• 매니저끼리 서로를 직접 참조해, 한 곳을 고치면 어디까지 영향이 가는지 알 수 없음
• Assets 루트에 스크립트·프리팹·터레인·머티리얼이 그대로 쌓여 71개 파일이 방치됨
• 같은 역할의 코드가 여러 폴더에 흩어져 있어, 고칠 곳을 찾는 데만 시간이 들었음

리팩토링을 시작하면서 가장 먼저 부딪힌 문제는 코드 품질이 아니라 “무엇을 기준으로 좋고 나쁨을 판정할 것인가” 였습니다. 기준이 없으면 리팩토링은 취향 싸움이 됩니다.

접근

규칙을 먼저 문서로 확정하고, 코드는 그 다음에 썼습니다.

시스템의 정의를 물리적인 것으로 고정했습니다.

시스템 경계 = Assets/1.Code/Scripts/ 바로 아래 폴더 하나. 하위 폴더(PlayerSystem/Movement 등)는 그 시스템의 모듈이지 독립 시스템이 아니다.

폴더 하나가 시스템 하나이므로, “이건 어느 시스템인가”에 대한 답이 항상 하나로 나옵니다. 그리고 시스템마다 아래 항목을 Docs/SystemUsageGuide.md에 채웠습니다.

## <시스템명>
- 상태: 확정 | 미확정
- 역할: 한 줄
- 진입점: 외부에서 이 시스템을 쓸 때 건드리는 타입
- 사용법:
  - 호출 예시 한 줄
- 외부 연결:
  - <쓰는 외부 시스템> — <무엇을 위해, 어떤 타입으로 어떻게 받는지>
- 설계 규칙:
  - 이 시스템 코드를 작성할 때 지켜야 할 규칙

핵심은 상태 항목입니다. 미확정인 항목이 하나라도 있으면 클래스 단위 평가를 진행하지 않도록 못 박았습니다. 확정되지 않은 규칙으로 코드를 판정하면 그 판정 자체가 오염되기 때문입니다.

수치를 어디 둘 것인가

시스템 경계와 함께 전역 규칙 하나를 더 세웠습니다. 매직넘버가 코드 곳곳에 박히는 것이 출시작의 고질적인 문제였기 때문입니다.

튜닝 대상이 되는 값은 둘 중 하나에만 둡니다.

• ScriptableObject로 뺀다 — 게임 규칙·밸런스 값(대시 거리, 무적 시간, 쿨타임). 바꿀 때 모든 개체가 같이 바뀌어야 하는 값
• [SerializeField]로 둔다 — 그 개체의 배치·개성(순찰 반경, 문 열림 각도, 추종 오프셋)

판별 기준은 한 줄입니다. “이 값을 바꿀 때 다른 개체도 같이 바뀌길 원하나?” — 예면 SO입니다.

판단이 서지 않으면 임의로 정하지 않고 결정을 남깁니다. // 개체별 주석이 붙어 있으면 이미 판단이 끝난 값이라는 표시라, 다음에 볼 때 같은 고민을 반복하지 않습니다.

한계도 함께 적었습니다

각 항목에는 한계(다음 프로젝트에서 해결) 칸을 두고, 지금 구조가 못 하는 일을 그대로 적었습니다. 예를 들어 의존성 주입은 씬 Awake 1회뿐이라 런타임에 스폰한 프리팹이 주입을 못 받는데, 이를 감추지 않고 우회 지점(Enemy.cs:156, WisuSpawnPhase.cs:12)까지 파일·라인으로 남겼습니다.

문서가 자기 자랑이 되면 다음에 읽을 때 쓸모가 없어집니다. 못 하는 일을 적어 둬야 다음 판단이 빨라집니다.

결과

• 12개 시스템(DI · Audio · Camera · Combat · Enemy · GameState · Gimmick · Input · Language · Player · Save · Settings · UI)의 규칙이 문서로 확정됐습니다.
• Assets 최상위를 1.Code / 2.Level / 3.Content / 4.Plug-in / 5.Data로 재편해, 루트 직속 파일이 71개에서 0개가 됐습니다.
• 코드를 쓰기 전에 해당 시스템 항목을 읽고 시작하는 순서가 고정됐습니다. 새 코드가 규칙을 어겼는지는 취향이 아니라 문서 대조로 판정됩니다.

문제

시스템끼리 서로를 직접 붙잡고 있었습니다.

출시작의 참조 방식은 세 가지였습니다.

• public static PlayerController instance; 같은 싱글톤 — 코드 전체에서 11개
• 인스펙터에 오브젝트를 끌어다 놓는 [SerializeField] 연결
• FindObjectOfType · GetComponent 호출 — 177곳

각각의 문제는 이렇습니다.

• 싱글톤: 어디서든 접근 가능하니 호출 지점을 추적할 수 없고, 구체 클래스에 직접 묶여 교체가 불가능합니다.
• 인스펙터 드래그: 씬이 늘어날 때마다 같은 연결을 반복해야 하고, 하나 빠뜨려도 NullReferenceException이 나기 전까지 모릅니다.
• FindObjectOfType: 비용도 문제지만, 비활성 오브젝트를 못 찾는다는 점이 더 문제였습니다.

이 문제는 출시 당시 실제 사고로 이어진 적이 있습니다. 빌드 발표 당일 실행 파일에서 입력이 먹지 않던 문제의 뿌리도, 참조가 코드 밖(에셋 경로·인스펙터)에 있어서 컴파일 시점에 검증되지 않는 구조였습니다.

public static CameraController instance;      // Camera/Control/CameraController.cs
public static CameraData Instance             // Camera/Data/CameraData.cs
public static CoroutineManager Instance       // Manager/CoroutineManager.cs
public static LanguageManager Instance;       // Manager/LanguageManager.cs
public static PlatformSwitcher instance;      // Manager/PlatformSwitcher.cs
public static SaveManager instance;           // Manager/SaveManager.cs
public static SceneSwitcher instance;         // Manager/SceneSwitcher.cs
public static TextManager Instance            // Manager/TextManager.cs
public static MobileInput instance;           // Player/Control/MobileInput.cs
public static PlayerController instance;      // Player/Control/PlayerController/PlayerController.cs
public static MaskChange instance;            // Player/Control/PlayerController/PlayerMaskChange.cs

왜 직접 만들었나

Zenject·VContainer 같은 검증된 컨테이너가 있는데도 직접 만든 이유는, 이 프로젝트의 목적이 게임 출고가 아니라 설계 학습이었기 때문입니다. 남이 만든 컨테이너를 쓰면 “주입이 왜 이 시점에 일어나는가”를 끝까지 따질 일이 없습니다.

대신 직접 만드는 대가로 한계를 정확히 아는 것을 목표로 잡았습니다. 실제로 아래 「남은 한계」 항목은 전부 만들면서 부딪힌 것들입니다.

구현

사용하는 쪽 코드는 어트리뷰트 한 줄입니다.

// 필수 의존 — 없으면 LogError
[Preserve, Inject] private ISaveService _saveService;

// 선택 의존 — 없으면 LogWarning만 남기고 계속 동작
[Preserve, Inject(true)] private ISoundSettings _settings;

주입기는 세 단계로 동작합니다.

1단계 — 타입 수집 (게임 시작 시 1회)

// [왜] 런타임 리플렉션 비용을 감소시키기 위해, 어셈블리 로드 이후(Awake 이전) 1회만 타입을 훑어 캐싱한다
[RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.AfterAssembliesLoaded)]
public static void CollectType()
{
    IEnumerable<Type> allTypes = Assembly.GetExecutingAssembly().GetTypes()
        .Where(t => t.Namespace == "Refactoring" && t.IsClass && !t.IsAbstract);
    // ...
}

리플렉션은 느리다는 이유로 흔히 기피되지만, 느린 것은 매번 훑을 때입니다. 어셈블리 로드 직후 한 번만 훑어 static 딕셔너리에 캐싱해 두면, 이후 씬 전환에서는 캐시를 읽기만 합니다.

2단계 — 씬 인스턴스 등록 (씬마다 Awake)

씬마다 존재하는 오브젝트가 다르므로 등록은 씬 단위로 다시 합니다. Script Execution Order를 -100으로 두어 다른 Awake보다 먼저 돌게 했습니다. 여기서 두 가지를 보장합니다.

• 비활성 오브젝트도 스캔해 등록합니다. FindObjectOfType이 못 하던 일입니다.
• 인터페이스·부모 타입뿐 아니라 구체 클래스 타입으로도 등록합니다. 한 시스템 안에서 한 곳에만 연결되는 참조까지 인터페이스를 강제하면 인터페이스만 늘어나기 때문에, 시스템 내부 결합은 의도적으로 허용했습니다.

3단계 — 주입

캐싱된 필드 목록을 돌며 등록된 인스턴스를 꽂습니다. 없으면 Inject는 LogError, Inject(true)는 LogWarning을 남깁니다. 조용히 null로 남지 않는 것이 이 시스템의 핵심입니다. 출시작에서 참조 누락이 런타임에야 터졌던 문제를 여기서 막았습니다.

규칙으로 고정한 것

주입기만 만들어 두면 결국 예전처럼 쓰게 되므로, 사용 규칙을 SystemUsageGuide에 함께 못 박았습니다.

• 다른 시스템을 참조할 땐 [Inject]를 쓴다. [SerializeField]는 자기 GameObject의 컴포넌트나 인스펙터 조정값에만 쓴다.
• 참조가 없으면 핵심 기능이 안 도는 의존은 [Inject], 없어도 일단 도는 의존은 [Inject(true)]
• 부모 클래스의 [Inject] 필드는 반드시 protected로 둔다. private는 자식 스캔에서 안 잡혀 경고도 없이 null로 남는다.
• 씬을 넘겨 값을 유지할 때 DontDestroyOnLoad를 쓰지 않는다. 씬 사본과 함께 2개가 등록된다. static 값만 남긴다.

마지막 두 줄은 둘 다 실제로 하루씩 잡아먹은 뒤 규칙으로 승격시킨 것입니다.

남은 한계

문서에 그대로 적어 둔 미해결 항목입니다.

• 주입은 씬 Awake 1회뿐이라 런타임에 스폰한 프리팹은 주입을 못 받습니다. 지금은 스포너가 미리 받아 넘기는 방식으로 개별 우회 중입니다(Enemy.cs:156, WisuSpawnPhase.cs:12).
• 다음 단계로는 스폰 직후 호출할 InjectTo(object)를 진입점으로 두는 방향을 검토 중입니다.
• 같은 타입 구현이 2개 이상이면 첫 번째만 주입되고 LogWarning만 남습니다(AttributeInjector.cs:196). 키 기반 구분이 없는 것이 현재 설계의 명확한 결함입니다.

결과

• 싱글톤 static Instance가 11개에서 1개(주입기 자신)로 줄었습니다.
• 79개 필드가 [Inject]로 연결되며, 대부분 구체 클래스가 아닌 인터페이스를 받습니다.
• 참조 누락이 런타임 예외가 아니라 시작 시점 로그로 드러납니다.

문제

캐릭터를 하나 늘리면 스킬 클래스를 통째로 복제해야 했습니다.

출시작의 플레이어 코드는 마스크(캐릭터) 종류별로 스킬 클래스를 따로 두는 구조였습니다.

세 클래스가 하는 일은 거의 같습니다. 애니메이션을 재생하고, 특정 타이밍에 히트박스를 켜고, 이펙트를 뿌리고, 사운드를 내고, 카메라를 흔듭니다. 다른 것은 어느 타이밍에 무엇을 켜는가 하는 수치뿐이었습니다.

그런데 그 수치가 코드 안에 박혀 있으니:

• 스킬 하나의 타격 타이밍을 0.1초 옮기려면 코드를 고치고 다시 컴파일해야 함
• 캐릭터가 늘면 1,000줄짜리 클래스가 하나 더 생김
• 공통 로직을 고치면 세 파일을 똑같이 세 번 고쳐야 함

1차 시도 — 상속 계층

처음에는 교과서적인 방향으로 갔습니다. CharacterBaseState<EState, ECharacter> 추상 클래스를 두고, 상태마다 자식 클래스를 만들어 StateKey·AnimationName을 override하는 구조였습니다.

public abstract class CharacterBaseState<EState, ECharacter> where EState : Enum where ECharacter : Enum
{
    public abstract bool CanReenter { get; }
    public abstract EState StateKey { get; }
    public abstract ECharacter CharacterType { get; }
    protected abstract string AnimationName { get; }
    // ...
}

만들고 나서 자식 클래스들을 다시 봤더니, 자식이 override하는 것이 전부 값이었습니다. 로직은 단 한 줄도 없었습니다. 상태마다 클래스 파일을 하나씩 만들면서 얻는 것이 “상수 몇 개를 선언할 자리”뿐이었던 것입니다.

이 지점에서 방향을 뒤집었습니다.

왜 상속구조 삭제?: 자식 클래스(상태)에 로직이 존재하지 않기 때문. 자식 클래스에 존재하는 데이터를 상태 데이터 SO에 포함시킴

2차 설계 — 상태는 데이터, 실행은 하나

상태를 클래스가 아니라 ScriptableObject 에셋으로 정의했습니다.

[CreateAssetMenu(fileName = "StateData", menuName = "Data/StateData")]
public class StateData : ScriptableObject
{
    [SerializeField] private PlayerStateType stateType;  // 상태 정체성. 자식 클래스 override 대신 인스펙터에서 지정
    [SerializeField] private bool isLooping;
    [SerializeField] private float cooldown;

    // 시간 구간형 — "언제부터 언제까지"
    [SerializeField] private IntervalDataEntry[] inputBlock;
    [SerializeField] private IntervalDataEntry[] inputBuffer;
    [SerializeField] private IntervalDataEntry[] superArmor;
    [SerializeField] private IntervalDataEntry[] invincible;
    [SerializeField] private IntervalDataEntry[] cameraLock;

    // 시점형 — "이 진행도에서 무엇을"
    [SerializeField] private SkillMoveDataEntry[] skillMove;
    [SerializeField] private SkillEffectDataEntry[] effect;
    [SerializeField] private HitboxDataEntry[] hitbox;
    [SerializeField] private AudioDataEntry[] audio;
    [SerializeField] private CameraShakeDataEntry[] cameraShake;
    [SerializeField] private CameraZoomDataEntry[] cameraZoom;
    [SerializeField] private FinishDataEntry[] finish;
    [SerializeField] private ObjectToggleDataEntry[] objectToggle;
}

그리고 이 데이터를 읽어 실행하는 클래스는 StateRunner 하나뿐입니다. 상속이 없습니다.

// 역할: 상태를 관찰하고 무엇을 할지 신호(의도)를 보낸다.
public class StateRunner
{
    public void Enter()
    {
        _tracker.Begin();
        Animator.CrossFade(StateKey.ToString(), 0.1f, 0, 0f);
        RaiseEvent(0f);
    }

    public void Update()
    {
        _tracker.Update();
        RaiseEvent(_tracker.Progress);
    }
}

StateRunner는 애니메이션 진행도(0~1) 만 추적하고, 데이터에 적힌 progress를 넘어설 때마다 해당 카테고리의 이벤트를 올립니다. 초 단위가 아니라 진행도 기준이라, 애니메이션 길이를 바꿔도 타이밍 비율이 유지됩니다.

핵심은 StateRunner가 무엇을 하라고 지시하지 않는다는 점입니다. “지금 히트박스 카테고리의 시점을 지났다”는 신호만 보냅니다. 실제로 히트박스를 켜는 것은 그 신호를 구독한 쪽입니다.

신호를 받는 쪽 — 이벤트 채널

상태를 아는 쪽과 상태에 반응하는 쪽을 채널로 끊었습니다.

• PlayerStateEventChannel — 상태 진행 중 발생하는 이벤트(히트박스·이펙트·사운드·카메라)
• PlayerStateTriggerChannel — 상태 전이를 요청하는 신호
• PlayerCurrentStateChannel — 현재 상태를 읽기 전용으로 노출

각 채널은 올리는 쪽(IPlayerStateEventRaiser)과 받는 쪽(IPlayerStateEventSubscriber) 인터페이스가 나뉘어 있습니다. 구독자는 자기가 필요한 카테고리만 듣습니다. 그래서 새 연출을 붙일 때 상태 시스템 코드를 건드리지 않습니다. 구독자 하나를 추가하면 끝입니다.

에디터 쪽 처리

데이터 항목이 15종이라 인스펙터가 복잡해질 수 있었습니다. 이건 커스텀 에디터로 해결했습니다.

많으면 복잡하지 않는가?: 없는 변수들을 Inspector에서 가려지도록 Editor에서 처리함. 복잡해 보이는 것은 실제로 변수들이 많기 때문이고, Editor로 원하는 것만 보이도록 구현가능

또 플레이 모드에서 SO의 progress 값을 실시간으로 고치면 다음 진입부터 반영되도록, Enter()에서 UNITY_EDITOR 한정으로 이벤트를 재정렬합니다. 게임을 껐다 켜지 않고 타이밍을 잡을 수 있어야 튜닝 속도가 나오기 때문입니다.

public void Enter()
{
#if UNITY_EDITOR
    // 에디터 플레이모드에서 SO progress를 런타임 수정하면 다음 진입부터 반영되도록 재정렬한다.
    SortEvents(_data);
    IsLooping = _data.IsLooping;
#endif
    // ...
}

진행 중 배운 것

작업 일지에 남긴 문장 하나가 이 설계의 기준이 됐습니다.

처음 계획한 지점에서, 코드를 크게 안 고치고도 기능을 추가하거나 바꿀 수 있어야 한다. 딱 거기까지만 설계하는 것. 하나하나 디테일하게 설계하는 것도 일이고, 수정은 자주 일어난다. 결국 “수정하기 쉽게 짜는 것”을 기본으로 두어야 한다. 어차피 또 고칠 테니까.

실제로 SkillMove를 만들 때 “플레이어·몬스터·기믹 공용 시스템으로 키우자”는 계획이 나왔지만 취소했습니다. 기본 기능을 다 만든 뒤에 해도 늦지 않고, 지금 의도와 다른 설계를 미리 하는 것은 시간을 버리는 일이기 때문입니다.

결과

• 플레이어 시스템 코드가 8,854줄(36파일) → 3,542줄(82파일)로 줄었습니다. 파일 수가 늘어난 것은 한 파일이 한 가지만 하도록 쪼갠 결과입니다.
• 스킬을 추가할 때 클래스를 만들지 않습니다. StateData 에셋을 하나 만들고 애니메이션과 타이밍을 채우면 끝입니다.
• 관련해 해결한 버그: 캐릭터 전환 시 콤보가 끊기던 문제, 대시 중 공격 스킬을 쓰면 대시 이동이 스킬에 그대로 얹히던 문제.

문제

혼자 하는 리팩토링에는 반대하는 사람이 없습니다.

출시작을 다시 짜기로 했을 때 가장 걱정한 것은 실력이 아니라 판단의 편향이었습니다.

• 내가 짠 코드는 내가 읽기 쉽습니다. 그래서 “읽기 쉬운가”를 스스로 판정할 수 없습니다.
• 리팩토링은 끝이 없어서, 어디서 멈출지 정해 주는 사람이 없으면 계속 고치게 됩니다.
• 팀 프로젝트에서는 리뷰어가 걸러 주던 것들이 1인 프로젝트에서는 전부 통과합니다.

AI를 쓰기로 한 이유가 여기 있습니다. 코드를 빨리 뽑기 위해서가 아니라, 반대할 사람을 만들기 위해서 였습니다.

원칙 — 사용자 편을 들지 말 것

프로젝트 CLAUDE.md 최상단에 규칙을 박았습니다.

- 사용자 편을 절대로 들지 말 것. 중립적이면서 기계적으로 근거에 의한 답변을 제시할 것.
- 파일 생성/삭제/변경은 진행하기 전 무조건 질문할 것.

AI는 기본적으로 사용자에게 동의하려는 경향이 있습니다. 그 상태로는 리뷰어 역할을 못 합니다. 그래서 동의 금지를 규칙의 첫 줄로 올리고, 평가 커맨드에도 엄격하고 진지하게, 중립적으로 판단한다를 반복해 넣었습니다.

두 번째 규칙(변경 전 질문)은 주도권을 지키기 위한 것입니다. AI가 파일을 알아서 고치기 시작하면 설계 판단이 제 손을 떠납니다. 설계는 제가 하고, AI는 검사와 근거 조사를 합니다.

커맨드로 고정한 8가지

매번 프롬프트로 설명하면 기준이 흔들리므로, 반복되는 판정을 전부 슬래시 커맨드로 만들었습니다.

평가 기준을 추상 원칙에서 떼어냈습니다

클래스 평가에서 SOLID 같은 원칙을 점수 항목으로 두지 않았습니다. 원칙 이름으로 판정하면 결국 해석 싸움이 되기 때문입니다.

좋은 코드의 기준: 읽기 쉽고 유지보수가 싼가. 그래서 추상 원칙(SOLID 등)을 점수 항목으로 두지 않고, “유지보수가 싼가”라는 결과만 본다.

대신 관찰 가능한 냄새로 축을 짰습니다.

1. 변경 파급 — 이거 하나 고치면 몇 군데가 깨지나 (본문의 new·Find·GetComponent·싱글톤 직접 호출, 깊은 체이닝, 같은 규칙 복붙)
2. 이해 비용 — 처음 보는 사람이 30초에 흐름을 따라가나 (인자 3개 초과, bool 플래그로 모드 가르기, 이름에 없는 사이드 이펙트)
3. 교체/삭제 용이 — 기능 하나 빼거나 갈아끼울 때 깔끔히 떨어지나 (새 종류마다 기존 switch에 분기 덧대기)
4. 과설계 없음 — 구현 1개뿐인 인터페이스, 호출 1곳뿐인 레이어, 안 올 확장의 선구현
5. 유니티 함정 — OnEnable 구독과 OnDisable 해제의 짝이 맞나 등

그리고 억지 평가를 금지했습니다. 냄새가 안 보이면 그 행은 해당없음으로 적습니다. 지적할 것을 억지로 찾으면 리뷰가 노이즈가 됩니다.

순서를 강제한 장치

커맨드끼리 선행 조건을 걸어 두었습니다. 클래스 평가의 0번 절차입니다.

대상 파일이 속한 시스템, 그리고 그 파일이 참조하는 외부 시스템 중 Docs/SystemUsageGuide.md에서 상태: 미확정인 것이 하나라도 있으면 평가를 진행하지 않는다. 미확정 N개: <시스템명 나열>. system-evaluation으로 먼저 확정할 것.만 출력하고 멈춘다.

확정되지 않은 규칙으로 코드를 판정하면 그 판정이 오염됩니다. 그래서 시스템 규칙 확정 → 클래스 평가 순서를 도구 차원에서 못 박았습니다. 제가 순서를 건너뛰고 싶어도 커맨드가 멈춥니다.

근거와 추측을 분리했습니다

AI를 쓸 때 가장 위험한 것은 그럴듯한 추측을 근거처럼 받는 것입니다. 그래서 조사 커맨드에 별도 규칙을 뒀습니다.

근거와 추측을 절대 섞지 않는다. (근거가 추측처럼, 추측이 근거처럼 보이면 안 된다) 근거가 없는 내용을 들고오면 폐기 대상이다. 빈손을 감추려 추측을 근거처럼 포장하지 말 것.

이 규칙 덕에 실제로 걸러진 사례가 있습니다. 모바일 GPU 분석에서 Shader Variant 트래킹이 Terrain 셰이더를 못 잡는 문제를 확인했을 때, 원인을 추측으로 채우는 대신 “Unity의 알려진 한계로 확인, 이 부분은 미해결” 로 보고서에 남겼습니다. 빌드 용량 분석에서도 Play Asset Delivery를 검토한 뒤 “PAD가 나쁘다는 뜻이 아니라 이번 문제의 원인과 규모에 맞지 않았다”고 판단 근거를 분리해 적었습니다.

AI가 한 일과 제가 한 일

커밋 로그에도 이 경계가 남아 있습니다. AI 평가를 적용한 커밋에는 어떤 커맨드를 돌렸고 무엇이 바뀌었는지, 그리고 핵심 기능은 건드리지 않았다는 사실을 함께 적었습니다.

[DISystem] AttributeInjector.cs 평가 적용
- ai를 통한 설계 평가(code-convention, comment-convention, system-evaluation, code-evaluation)를
  적용하여 일부 주석 및 코드 수정됨(핵심 기능 수정 X)

규칙은 계속 다듬었습니다

처음부터 잘 돌아간 것은 아닙니다. 커맨드 자체를 여러 번 고쳤습니다.

• 코드 평가 규칙 대폭 간소화 — 항목이 많으면 판정이 흐려집니다
• 더 단순하게 평가하기 위해 규칙 수정
• 규칙 단호하게 수정 — 애매한 표현을 남기면 AI가 사용자 편으로 기웁니다
• 코드 평가 경각심 담긴 문장 추가

규칙을 만드는 것 자체가 설계 작업이었습니다. 무엇을 나쁜 코드로 볼 것인지 문장으로 못 쓰면, 그 기준은 제 머릿속에도 없는 것이었습니다.

결과

• 판정 기준이 문서로 고정돼, 코드 리뷰가 취향 논쟁이 아니라 문서 대조 작업이 됐습니다.
• 혼자서 5개월 · 384개 커밋 규모의 전면 재설계를 완주했습니다. AI 없이 같은 기간에 같은 범위를 검사까지 하며 진행하기는 어려웠을 것이라 봅니다.
• 부수 효과로, 규칙을 문장으로 쓰는 과정에서 제 판단 기준이 정리됐습니다. 이 문서화 습관은 SystemUsageGuide와 활동 일지로도 이어졌습니다.