Cursor와 GitHub Copilot 프롬프트로 게임 코드 자동화하기

자동화의 목표는 코드 생성이 아니라 작업 단위 완성이다

Cursor와 GitHub Copilot은 함수 몇 줄을 빠르게 작성하는 데 유용하지만 게임 프로젝트에서는 맥락을 잃지 않는 것이 더 중요합니다. 플레이어 이동처럼 여러 시스템과 연결된 기능은 입력 처리, 상태 전환, 물리 갱신, 애니메이션 파라미터, 테스트 조건을 함께 고려해야 합니다.

좋은 프롬프트는 모델에게 단순히 “코드를 작성해 달라”고 요청하지 않습니다. 변경 범위와 준수해야 할 규칙, 완료 조건을 전달해 사람이 검토할 수 있는 작은 작업으로 구체화합니다.

flowchart LR
    A[작업 목표 정의] --> B[관련 파일과 규칙 제공]
    B --> C[작은 변경 요청]
    C --> D[컴파일 및 플레이 모드 검증]
    D --> E[검토 및 수정 요청]
    E -->|문제 발견| C
    E -->|통과| F[커밋 가능한 상태]

이 흐름에서 AI는 구현을 지원하지만 범위 설정과 최종 검증은 개발자의 역할로 남습니다. 특히 게임 로직은 실행 중에만 드러나는 문제가 많으므로 컴파일 통과만을 완료 조건으로 삼아서는 안 됩니다.

프롬프트에 반드시 포함할 정보

프롬프트 품질은 문장의 화려함보다 맥락의 구체성에 좌우됩니다. 다음 네 가지를 포함하면 결과가 안정적입니다.

목적: 무엇을 왜 바꾸는지
범위: 수정 대상 파일과 건드리지 말아야 할 영역
제약: 프로젝트의 코딩 규칙, 성능 조건, 기존 API
완료 조건: 컴파일, 테스트, Inspector 설정 등 확인 기준

예를 들어 “대시 기능을 만들어 줘”는 범위가 너무 넓습니다. 대시가 스태미나를 소비하는지 Rigidbody를 사용하는지 공중에서 사용할 수 있는지에 따라 구현이 크게 달라집니다.

Unity 플레이어 대시 기능의 입력, 상태, 물리 처리를 구분해 표시한 코드 구조 예시

모호한 요청과 개선된 요청

다음처럼 요청하면 기존 구조를 무시하거나 필요 이상으로 많은 파일을 바꿀 가능성이 큽니다.

Unity 플레이어에 대시를 추가해 줘.

대신 현재 구조와 완료 조건을 함께 제공합니다.

Unity 6 프로젝트의 PlayerMovement.cs에 지상 대시 기능을 추가해 줘.

조건:
- 입력은 새 Input System의 Dash 액션을 사용한다.
- Rigidbody의 velocity를 직접 대입하지 말고 기존 Move 메서드를 재사용한다.
- 대시 시간은 0.18초, 재사용 대기시간은 0.5초로 SerializeField에서 조절 가능해야 한다.
- 공중과 기절 상태에서는 시작할 수 없다.
- 기존 점프와 이동 동작을 바꾸지 않는다.

먼저 수정 계획과 영향을 받는 멤버를 설명한 뒤 PlayerMovement.cs만 변경해 줘.

핵심은 구현 방법을 모두 대신 결정하는 것이 아닙니다. 프로젝트에 이미 있는 규칙을 알려 주고 바꿔도 되는 경계를 분명히 하는 것입니다.

Cursor에서는 코드베이스 맥락을 좁혀서 지정한다

Cursor 같은 코드베이스 중심 도구는 여러 파일을 함께 읽고 수정할 수 있습니다. 이때 프로젝트 전체를 막연히 참조하게 두기보다 필요한 파일부터 지정하는 편이 좋습니다.

예를 들어 적 AI의 피격 반응을 고칠 때는 다음 순서가 효과적입니다.

EnemyHealth.cs, EnemyStateMachine.cs, 관련 상태 파일을 먼저 지정합니다.
현재 버그를 재현할 수 있는 조건을 설명합니다.
원인 분석과 변경 계획을 먼저 요청합니다.
계획이 맞는지 확인한 뒤 실제 수정을 요청합니다.

분석과 수정을 한 번에 요청할 수도 있지만 상태 머신이나 저장 시스템처럼 영향 범위가 넓은 영역에서는 두 단계로 나누는 편이 안전합니다.

@EnemyHealth.cs @EnemyStateMachine.cs @EnemyHitState.cs

적이 피격 중 사망하면 Hit 상태에 남아 애니메이션이 멈춥니다.
현재 상태 전환 경로를 분석하고 사망 시 Hit 상태를 거치지 않도록 하는 최소 변경 계획을 작성해 줘.
코드는 아직 수정하지 마.

계획이 적절하다면 다음 요청으로 넘어갑니다.

방금 제안한 계획을 적용해 줘.
EnemyHealth.cs와 EnemyHitState.cs만 수정하고 변경한 분기와 그 이유를 코드 주석 없이 응답에서 요약해 줘.

파일 범위를 제한하면 의도하지 않은 리팩터링을 줄이고 검토할 분량도 줄일 수 있습니다.

GitHub Copilot에서는 현재 코드의 동작 규칙을 먼저 보여 준다

GitHub Copilot의 채팅과 인라인 제안은 현재 열어 둔 파일과 선택 영역의 영향을 크게 받습니다. 따라서 긴 자연어 요청만 입력하기보다 인터페이스, 호출부, 주석을 통해 코드의 입력·출력 규칙과 동작 기준을 명확히 제시하는 것이 도움이 됩니다.

아래 인터페이스가 있다면 구현을 요청할 때 반환 규칙을 명시할 수 있습니다.

public interface IDamageable
{
    /// <summary>
    /// 피해가 실제로 적용되었으면 true를 반환한다.
    /// 무적 상태이거나 이미 사망했으면 false를 반환한다.
    /// </summary>
    bool TryTakeDamage(int amount, GameObject source);
}

그다음 메서드 본문을 선택한 뒤 다음처럼 요청합니다.

이 인터페이스의 반환 규칙을 지켜 TryTakeDamage를 구현해 줘.
HealthChanged 이벤트는 피해가 적용된 경우에만 호출한다.
사망 처리와 이벤트 구독 해제는 기존 Die 메서드에 위임한다.
불필요한 할당을 만들지 않는 단순한 구현으로 작성해 줘.

이 방식은 AI가 새 시스템을 발명하는 대신 이미 정해진 인터페이스의 동작 규칙 안에서 구현하도록 유도합니다.

반복 작업은 템플릿 프롬프트로 표준화한다

게임 개발에는 직렬화 필드, 이벤트 연결, 로그 정리, XML 문서화처럼 반복되는 작업이 많습니다. 이런 작업은 매번 새로 설명하지 말고 팀에 맞는 템플릿으로 정리하면 효율적입니다.

Unity 컴포넌트 골격 생성 템플릿

다음 규칙으로 Unity C# MonoBehaviour 컴포넌트 골격을 작성해 줘.

- 클래스 이름: [클래스명]
- 책임: [한 문장 설명]
- Inspector 설정: [필드 목록]
- 외부 의존성: [컴포넌트 또는 서비스 목록]
- 공개 API: [메서드 목록]
- 금지 사항: Update에서 Find 계열 API 호출 금지, 매 프레임 GC 할당 금지
- 초기화 실패 시 동작: [로그 또는 비활성화 정책]

필드는 역할별로 묶고 Awake와 OnEnable의 책임을 분리해 줘.

템플릿은 결과를 완전히 고정하는 도구가 아닙니다. 팀의 네이밍, 예외 처리, 로그 정책처럼 반복해서 설명해야 하는 기준을 빠뜨리지 않도록 돕는 도구입니다.

생성 후에는 검토 전용 프롬프트를 사용한다

AI가 작성한 코드를 다시 AI에게 검토해 달라고 요청하는 과정도 유용합니다. 다만 “버그를 찾아 줘”라고만 하기보다 관점을 나누어 요청해야 실제 검토에 가까운 결과를 얻을 수 있습니다.

아래 PlayerDash 코드만 검토해 줘.

다음 항목을 각각 확인하고 문제가 있으면 재현 조건과 수정 방향을 설명해 줘.
1. 입력을 해제한 뒤에도 대시가 계속되는지
2. 비활성화 후 재활성화할 때 이벤트가 중복 구독되는지
3. Time.timeScale이 0일 때의 동작
4. Rigidbody가 없는 프리팹에서의 실패 처리
5. 반복 대시에서 발생할 수 있는 GC 할당

확실하지 않은 항목은 추측하지 말고 확인이 필요한 코드 위치를 말해 줘.

이 프롬프트의 장점은 단정적인 정답을 요구하지 않는다는 데 있습니다. 검토 결과를 가설로 받아들이고 실제 프로젝트의 호출 흐름, Unity Profiler, 플레이 모드 테스트를 통해 확인해야 합니다.

실패하기 쉬운 사용 패턴

한 번의 요청으로 대규모 변경을 맡기는 경우

“인벤토리 시스템 전체를 리팩터링해 줘” 같은 요청은 파일 간 계약을 깨뜨릴 위험이 큽니다. 기능 단위로 나누고 각 단계에서 컴파일과 동작을 확인해야 합니다.

존재하지 않는 API나 패키지 이름을 그대로 믿는 경우

AI는 그럴듯하지만 프로젝트에 없는 API를 제안할 수 있습니다. Unity 버전, 사용 중인 패키지, 현재 코드의 실제 시그니처를 기준으로 검증해야 합니다.

성능 요구를 수치 없이 전달하는 경우

“최적화해 줘”는 판단 기준이 없습니다. 대상 플랫폼, 호출 빈도, 허용 가능한 메모리 할당량, 프로파일링 결과를 함께 제시해야 합니다.

이 코드 경로는 Android 기기에서 프레임마다 최대 200회 호출된다.
Update와 FixedUpdate에서 관리 힙 할당이 발생하지 않도록 검토해 줘.
성능 개선을 위해 가독성을 크게 해치거나 공개 API를 바꾸지는 마.

실무용 체크리스트

AI에 구현을 요청하기 전에는 다음 항목만 확인해도 결과의 품질이 크게 달라집니다.

변경할 파일과 건드리지 말아야 할 파일을 정했는가
기존 클래스의 책임과 공개 API를 설명했는가
플랫폼, Unity 버전, 패키지 같은 환경 정보를 제공했는가
컴파일 외에 확인할 플레이 모드 시나리오를 적었는가
생성된 코드를 그대로 붙여 넣지 않고 diff와 호출부를 검토했는가

Cursor와 GitHub Copilot은 개발자의 판단을 대신하는 도구라기보다 반복 구현과 탐색 비용을 줄여 주는 협업 도구에 가깝습니다. 작업을 작게 나누고 맥락과 완료 조건을 분명히 전달하면 게임 코드의 일관성을 지키면서 자동화의 이점을 얻을 수 있습니다.