리팩토링은 시작하기가 귀찮다. 고치고 싶은 코드는 눈에 보이는데, 지금도 게임은 돌아간다. 괜히 건드렸다가 잘 되던 기능까지 망가질까 싶어서 다음으로 미룬다. 당장 만들어야 할 기능이 있으면 더 그렇다.
총알 코드가 딱 그런 식으로 커지기 쉽다. 처음에는 앞으로 날아가는 총알 하나면 된다. 나중에 퍼지는 총알을 넣고, 적을 따라가는 미사일을 넣는다. 빨리 확인하려고 기존 코드를 복사해 수정하다 보면 이동하는 부분만 다른 클래스가 몇 개씩 생긴다. 데미지 처리나 수명 관리도 그 안에 같이 들어 있다.
Unity Korea의 Unity CLI 리팩토링 영상에서 관심이 갔던 것도 이런 코드였다. 새로운 게임을 한 번에 만드는 시연보다, 이미 돌아가는 프로젝트를 어떻게 손보는지가 더 궁금했다. 이 글에서는 그 사례를 바탕으로 내가 코드 정리를 맡길 때 중요하게 보는 부분을 적어보려 한다.
고치는 것보다 확인하는 일이 번거롭다
AI에게 코드 몇 개를 보여주고 중복을 줄여 달라고 하는 건 이전에도 가능했다. 문제는 수정안을 받은 다음이다. 프로젝트에 넣고, 컴파일을 기다리고, 에러를 다시 전달해야 한다. 에러가 없어도 프리팹 참조가 빠졌는지, 총알이 여전히 같은 속도로 날아가는지는 따로 봐야 한다.
Unity CLI에서 기대하는 부분은 이 왕복을 줄이는 것이다. 에이전트가 프로젝트 상태를 읽고, 코드를 바꾼 뒤, 연결된 도구로 결과를 확인할 수 있다면 사람이 에러 메시지를 옮겨 주는 일이 줄어든다.
다만 CLI를 설치하는 것과 에디터를 제어할 준비가 되는 것은 구분해야 한다. 공식 사용 문서에서는 에디터 제어에 Unity Pipeline 패키지 설정이 필요하다고 안내한다. CLI만 설치했다고 씬 조작이나 모든 검증이 곧바로 가능해지는 것은 아니다. 문서상 아직 experimental 단계이기도 하다.
또 Unity에 자동 빌드나 배치 실행이 없었던 것은 아니다. 이번 도구에서 볼 부분은 기존 자동화의 유무보다, 에이전트가 그 기능들을 얼마나 편하게 호출하고 결과를 읽을 수 있느냐에 가깝다. Pipeline이라는 이름 때문에 작업 계획이나 Git 커밋까지 알아서 관리해 준다고 생각하기도 쉬운데, 작업을 나누고 커밋하는 방식은 에이전트에 별도로 정해 줄 일이다.
처음부터 전략 패턴으로 바꿔 달라고 하지는 않겠다
Bullet과 HomingMissile이 따로 있다고 해서 무조건 합쳐야 하는 것은 아니다. 이름은 비슷해도 하나는 충돌 즉시 사라지고, 다른 하나는 폭발 범위를 계산하거나 목표를 다시 찾을 수 있다. 겉으로 닮은 코드만 보고 묶으면 나중에 예외 분기가 더 늘어날 수 있다.
그래서 처음에는 수정보다 설명을 요청하는 편이 낫다고 본다.
아직 코드를 수정하지 말고 Bullet과 HomingMissile이 각각 맡고 있는 일을 정리해줘. 중복되는 부분과 동작이 다른 부분을 나눠서 설명하고, 두 클래스를 참조하는 코드도 찾아줘. 씬이나 프리팹 참조까지 확인하지 못했다면 그 부분은 따로 알려줘.
클래스 다이어그램도 이때 도움이 된다. 다만 그림이 있어야 해서 만드는 건 아니다. 총알을 누가 생성하고, 누가 데미지를 받고, 수명이 끝났을 때 누가 회수하는지 알고 싶은 것이다. 관계가 단순하면 짧은 설명으로도 충분하다.
분석 결과 이동 방식만 다르고 나머지는 정말 같다면, 그때 이동 부분을 분리하는 방안을 검토할 수 있다. Bullet에는 수명과 충돌 처리를 남기고, 직진이나 추적 이동은 IBulletMotion 같은 별도 역할로 나누는 식이다.
이렇게 나누면 새 이동 방식을 추가할 때 데미지 코드까지 건드릴 일이 줄어든다. 대신 파일과 연결 지점은 늘어난다. 총알 종류가 두 개뿐이고 앞으로 달라질 일도 없다면 작은 중복을 남기는 쪽이 읽기 편할 수도 있다. 인터페이스가 생겼다는 사실보다 다음 수정이 쉬워졌는지를 보고 싶다.
정리하다가 동작까지 바꾸기 시작하면 헷갈린다
구조를 들여다보면 고치고 싶은 것이 계속 나온다. 이 변수 이름도 바꾸고 싶고, 이 물리 처리도 이상해 보이고, 안 쓰는 것 같은 코드도 눈에 들어온다. 한꺼번에 처리하면 나중에 게임이 달라졌을 때 원인을 찾기 어렵다.
예를 들어 FixedUpdate에 있던 이동을 Update로 옮기는 것은 단순히 메서드 위치를 정리하는 일이 아니다. 호출 주기가 달라진다. Rigidbody와 함께 쓰고 있었다면 물리 동작에도 영향을 줄 수 있다. 이런 변경은 중복 제거와 분리해서 확인하는 게 좋다.
AI에게도 그 경계를 구체적으로 알려줄 필요가 있다.
이번에는 이동 로직의 중복만 정리해줘. 속도, 발사 간격, 충돌 판정, Update와 FixedUpdate의 사용 방식은 유지해줘. 버그로 의심되는 부분이 있으면 수정에 섞지 말고 근거와 함께 따로 적어줘.
“더 좋은 코드로 바꿔줘”보다 요구가 좁다. 그만큼 결과를 확인하기도 쉽다. 직진탄이 전과 같은 거리를 이동하는지, 유도탄이 목표를 잃었을 때 같은 행동을 하는지 비교하면 된다. 컴파일 성공만으로 끝내기 어려운 이유다.
코드가 멀쩡해도 인스펙터 값은 봐야 한다
유니티에서 특히 놓치기 싫은 부분은 직렬화된 값이다. 코드에서는 변수 이름 하나를 바꿨을 뿐인데, 프리팹에 설정했던 값이 이어지지 않을 수 있다.
가령 기존 필드가 아래와 같았다고 하자.
[SerializeField] private float speed = 10f;
이름을 moveSpeed로 바꾸려면 기존 이름으로 저장된 값을 옮기는 방법도 함께 고려해야 한다.
using UnityEngine;
using UnityEngine.Serialization;
public sealed class Bullet : MonoBehaviour
{
[FormerlySerializedAs("speed")]
[SerializeField] private float moveSpeed = 10f;
}
위 코드는 필드 이름 변경을 설명하기 위한 예제다. FormerlySerializedAs는 이런 경우에 사용할 수 있지만, 필드 타입을 바꾸거나 다른 컴포넌트로 옮기는 변경까지 해결해 주지는 않는다.
확인할 때는 기본값이 아닌 프리팹 하나를 골라 두면 좋다. 원래 속도가 17이던 프리팹이 변경 후에도 17인지 보는 식이다. 기본값 10인 프리팹만 보면 값이 초기화돼도 알아채기 어렵다. 씬에 배치된 인스턴스의 override도 함께 봐야 한다.
“안 쓰는 코드”를 지우는 일도 비슷하다. C# 참조 검색에서 안 나온다고 바로 지우기는 어렵다. UnityEvent나 애니메이션 이벤트에서 이름으로 호출할 수도 있고, 씬이나 프리팹에 붙어 있을 수도 있다. 검색 결과가 없다는 것과 실제로 쓰지 않는다는 것은 다르다.
한 번에 맡길 범위를 작게 잡는 편이 좋겠다
이런 작업에 AI를 쓰는 이유는 반복해서 읽고 정리하는 부담을 덜기 위해서다. 그래서 처음부터 프로젝트 전체를 고쳐 달라고 하기보다는, 중복이 분명한 부분 하나를 골라 끝까지 확인해 보고 싶다.
작업 전 상태를 Git에 남기고, 총알 이동만 정리한 뒤 플레이해 본다. 직진탄과 유도탄을 각각 쏴 보고, 목표가 사라지는 경우도 확인한다. 프리팹 값과 씬 변경 내용을 확인한 다음에야 그 변경을 하나로 남긴다. 테스트용으로 생성한 오브젝트가 들어 있으면 그때 빼면 된다.
코드를 나누면 토큰 비용도 줄 것이라는 기대는 있지만, 그것까지 당연한 이득으로 보지는 않는다. 파일이 늘면 에이전트가 더 많은 파일을 읽을 수도 있다. 실제 사용량을 비교하기 전에는 알 수 없는 부분이다. 내게 더 중요한 것은 다음에 총알 하나를 추가할 때 어디를 수정해야 하는지 쉽게 알 수 있느냐다.
Unity CLI가 반가운 이유도 그 정도다. 미뤄 둔 코드를 다시 열어볼 만한 도구가 하나 생겼다. 우선 총알 두 종류부터 정리해 보고, 확인할 수 있는 만큼씩 맡기는 쪽으로 시작하면 좋겠다.