코드 리팩토링에서 AI를 제대로 쓰는 프롬프트 설계 팁
AI에게 리팩토링을 맡길 때 변경 범위와 보존해야 할 동작을 명확히 전달하는 방법을 정리합니다. Unity와 C++ 프로젝트에 바로 적용할 수 있는 프롬프트 예제도 함께 제공합니다.
AI 리팩토링의 핵심은 요구사항을 좁히는 일
이 글은 AI에게 코드 분석과 반복 수정을 요청할 때 사용할 프롬프트와 검증 절차를 제안합니다. 이 코드 리팩토링해 줘처럼 범위를 정하지 않은 요청의 결과에는 의도하지 않은 설계 변경, API 변경, 동작 회귀가 포함될 수 있습니다. 실제 시간 절감 여부는 분석·수정·리뷰·회귀 수정에 든 시간을 함께 측정해야 합니다.
좋은 리팩토링 프롬프트는 세 가지를 분명히 합니다.
- 바꾸려는 대상과 범위
- 반드시 유지해야 할 동작
- 결과물의 형태와 검증 방법
먼저 문제를 설명하고 수정은 다음 단계로 나눈다
한 번의 요청으로 분석과 대규모 수정을 모두 시키기보다 분석 결과를 먼저 받는 편이 안전합니다. 특히 게임플레이 코드에서는 작은 변경도 입력 처리, 애니메이션, 네트워크 동기화에 영향을 줄 수 있습니다.
flowchart TD
A[대상 코드와 제약 조건 제공] --> B[문제점과 변경 후보 분석 요청]
B --> C[변경 범위 확정]
C --> D[작은 단위로 리팩토링 요청]
D --> E[컴파일·테스트·리뷰]
E --> F{회귀 또는 부작용?}
F -->|예| C
F -->|아니오| G[변경 반영]예를 들어 Unity의 플레이어 이동 코드를 정리하려면 처음에는 다음처럼 요청할 수 있습니다.
다음 Unity C# 코드를 분석해 줘.
목표는 가독성 개선과 중복 제거다. 동작 변경이나 새 기능 추가는 하지 마.
입력 방식, 이동 속도 계산, public 필드 이름은 유지해야 한다.
먼저 다음만 답해 줘.
1. 중복 또는 책임 분리 문제가 있는 부분
2. 안전하게 나눌 수 있는 리팩토링 단위
3. 각 변경에서 발생할 수 있는 회귀 위험
아직 코드를 수정하지 마.이 단계에서 제안이 과도하다면 범위를 줄일 수 있습니다. 예를 들어 상태 머신 도입 제안이 필요 없다면 명시적으로 제외합니다.
보존 조건을 테스트 가능한 문장으로 쓴다
기능을 유지해 줘는 해석의 여지가 큽니다. 대신 관찰 가능한 결과를 적어야 합니다. 게임 코드에서는 프레임 처리, 직렬화 필드, 외부 호출부가 대표적인 보존 대상입니다.
다음 제약 조건을 반드시 지켜라.
- 기존 public 메서드 시그니처를 바꾸지 않는다.
- Inspector에 직렬화된 필드 이름을 바꾸지 않는다.
- Update에서 이동 입력을 읽는 시점은 유지한다.
- 대각선 이동 속도 보정 결과를 바꾸지 않는다.
- 할당을 새로 만들지 않는다.
- 수정 후 변경 이유와 동작 보존 근거를 항목별로 설명한다.C++ 코드라면 소유권과 성능 조건도 함께 적는 편이 좋습니다.
C++17 범위에서만 수정해라.
- 공개 헤더의 API는 변경하지 않는다.
- 핫 패스에서 heap allocation을 추가하지 않는다.
- 예외를 사용하지 않는다.
- raw pointer의 소유권 의미를 바꾸지 않는다.
- 수정 전후의 시간 복잡도와 메모리 할당 차이를 설명한다.이런 조건은 AI를 위한 지시이면서 사람 리뷰어를 위한 변경 기준이기도 합니다.
한 번에 고칠 파일 수를 제한한다
변경 파일 수만으로 리팩토링의 위험을 판단할 수는 없습니다. 영향 범위와 의존성, 테스트 가능성을 함께 확인해야 합니다. 검토 범위를 좁히려면 처음에는 하나의 클래스나 하나의 함수군으로 제한하는 방법을 고려할 수 있습니다.
다음 요청은 범위가 비교적 명확합니다.
PlayerMovement.cs의 Move(), ApplyGravity(), UpdateFacing()만 리팩토링해 줘.
다른 파일은 수정하지 마.
목표:
- 중복된 방향 벡터 계산을 한 곳으로 모은다.
- 각 함수의 책임이 드러나는 이름으로 지역 변수를 정리한다.
제약:
- 메서드 이름과 접근 제한자는 유지한다.
- 수치 상수와 계산 순서는 바꾸지 않는다.
- diff 형식으로 결과를 제시한다.
- 수정 뒤에 컴파일 오류 가능성과 수동 확인 항목을 적는다.계산 순서는 바꾸지 않는다 같은 조건은 부동소수점 연산이나 프레임 의존 로직에서 확인할 보존 조건입니다. 부동소수점 연산에는 반올림이 개입하므로 수학적으로 같은 식도 연산 순서를 바꾸면 결과가 달라질 수 있습니다. 예를 들어 일반적인 IEEE 754 배정밀도 계산에서 (1e16 + -1e16) + 1은 1이고 1e16 + (-1e16 + 1)은 0입니다. Microsoft의 부동소수점 설명도 이진 표현에 따른 반올림 오차를 설명합니다.
원하는 결과 형식을 지정한다
변경을 검토할 수 있도록 출력 형식을 요청합니다. 아래 템플릿은 변경 의도, diff, 검증 항목을 분리해 받는 예시입니다. 형식을 지정해도 결과의 적용 가능성이나 정확성이 보장되지는 않으므로 실제 파일과 대조해야 합니다.
다음 형식으로만 응답해라.
1. 변경 요약: 3개 이내의 항목
2. unified diff
3. 동작 보존 체크리스트
4. 컴파일 또는 테스트 시 확인할 위험 요소
확신할 수 없는 프로젝트 규칙은 추측하지 말고 질문으로 남겨라.특히 마지막 문장은 확인되지 않은 프로젝트 규칙을 드러내기 위한 조건입니다. Update와 FixedUpdate에 어떤 작업을 배치했는지, Unreal 리플렉션 매크로를 어떻게 사용했는지, 자체 메모리 할당자가 있는지 등을 실제 프로젝트에서 확인하도록 요청합니다. 엔진 API의 규칙과 프로젝트가 정한 사용 관례를 구분해 검토해야 합니다.
리팩토링 후에는 AI의 설명도 검증한다
AI가 제시한 설명은 검토의 출발점일 뿐입니다. 다음 항목은 실제 도구와 코드 리뷰로 확인해야 합니다.
- 컴파일 오류와 경고가 새로 생기지 않았는가
- 기존 단위 테스트와 플레이 모드 테스트가 통과하는가
- 직렬화 데이터와 블루프린트·프리팹 참조가 유지되는가
- 프레임 타임, GC 할당, 메모리 사용량이 악화되지 않았는가
- 수정하지 말아야 할 API와 파일까지 바뀌지 않았는가
AI에게 테스트 코드를 요청할 수도 있지만 테스트가 실제 기존 동작을 검증하는지 별도로 살펴야 합니다. 변경한 구현에 맞춰 테스트까지 함께 바꾸면 회귀를 놓칠 수 있습니다.
바로 쓸 수 있는 최종 프롬프트 템플릿
아래 코드를 제한된 범위에서 리팩토링해 줘.
[목표]
- {가독성 개선 / 중복 제거 / 책임 분리 중 구체적인 목표}
[수정 범위]
- {수정 가능한 파일, 클래스, 함수}
- 이 범위 밖의 파일과 API는 수정하지 않는다.
[반드시 보존할 동작]
- {입력, 계산 순서, 직렬화 필드, 네트워크 동작 등}
[기술 제약]
- {Unity 버전, C++ 표준, 엔진 규칙, 성능 조건}
[출력 형식]
1. 변경 계획
2. unified diff
3. 동작 보존 근거
4. 실행할 테스트와 수동 확인 항목
정보가 부족해 확신할 수 없는 부분은 코드를 추측해 수정하지 말고 질문으로 표시해라.
[코드]
{코드 또는 관련 파일 내용}수정할 범위와 보존할 동작을 함께 적고 각 변경을 실제 프로젝트에서 검증합니다. 프롬프트가 요구한 조건을 결과물이 지켰는지 확인한 뒤 변경을 반영하는 절차로 활용하세요.
