Rider 없이 언리얼 개발하기: AI 에이전트와 터미널 빌드 워크플로우

Unreal Engine 5.6 × Antigravity | 트러블슈팅 Dev Log

무거운 IDE, 정말 매번 켜야 하는 걸까?

언리얼 엔진으로 C++ 개발을 하다 보면 라이더(Rider)나 비주얼 스튜디오(Visual Studio) 같은 IDE를 당연하게 사용한다.

코드 수정 한 줄을 확인하기 위해 메모리를 많이 잡아먹는 IDE를 켤 때마다 불편함을 느꼈다...

 

이 글은 AI 코딩 에이전트인 안티그래비티(Antigravity)를 활용해, IDE를 열지 않고도 터미널에서 직접 빌드하고 에디터를 제어하는 워크플로우를 구축한 과정을 다룬다. 실제로 GAS(Gameplay Ability System)를 구현하면서 이 워크플로우를 세팅하고 검증했다.

 

이 글을 읽고 나면 다음을 얻을 수 있다.

• 무거운 IDE 없이 언리얼 C++ 빌드를 수행하는 구체적인 방법
• AI 에이전트의 슬래시(/) 명령어 기반 워크플로우 설계 과정
• 설계 → 수정 → 빌드 → 확인을 하나의 창에서 완결하는 실전 협업 루프

---

문제 정의: 무거운 IDE

문제의 핵심은 컨텍스트 스위칭(Context Switching, 작업 도중 다른 환경으로 전환하면서 발생하는 집중력 손실)이었다.

당시 작업은 GAS 기반 발소리 시스템 구축이었다. GS_FootstepDataAsset을 새로 만들고, GS_FootManagerComponent에 데이터 에셋을 연결하고, CharacterAnimInstance에서 GameplayTag 기반으로 발소리 이벤트를 동기화하는 작업이었다.

 

이 과정에서 여러 번 코드 수정과 빌드 확인이 반복되었고, 매번 IDE를 오가는 것이 병목이 되었다.

증상	상세
빌드 한 번에 수십 초의 대기	IDE가 프로젝트 인덱싱을 마칠 때까지 기다려야 한다
창 전환의 반복	AI에이전트 코드 수정 → IDE → 언리얼 에디터
에러 분석의 수동성	빌드 실패 시 로그를 직접 읽고, 원인을 직접 추적해야 한다
환경 무게	라이더 또는 비주얼 스튜디오가 점유하는 메모리와 CPU가 상당하다

---

원인 분석: 왜 IDE가 기본값이 되었는가

언리얼 엔진의 C++ 빌드는 내부적으로 UBT(UnrealBuildTool, 언리얼 전용 빌드 시스템)를 통해 수행된다.

IDE는 이 UBT를 감싸는 껍데기 역할을 하면서 인텔리센스(자동완성), 디버거, 빌드 버튼 등의 편의 기능을 제공한다.

 

핵심을 정리하면 이렇다.

빌드 자체는 IDE가 아니라 UBT가 수행한다.

 

단순 코드 수정과 컴파일 확인에는 IDE의 전체 기능이 필요하지 않다.

인텔리센스나 디버깅이 필요 없는 작업에서 IDE는 과잉 도구가 된다.

그리고 UBT는 커맨드라인에서 직접 실행할 수 있다. 즉, 터미널만으로 빌드가 가능하다는 뜻이다.

 

여기서 떠오른 생각은 하나였다.

“터미널에서 UBT를 직접 호출하되, 복잡한 인자값을 매번 외우지 않아도 되는 방법은 없을까?”

 

그 답이 AI 코딩 에이전트를 워크플로우 컨트롤러로 활용하는 것이었다.

AI 에이전트를 선택한 이유는 세 가지다.

이유	설명
컨텍스트 유지	코드를 수정하는 창에서 설계/수정/빌드/확인이 모두 가능하다
자동 에러 분석	빌드 실패 시 AI가 로그를 즉시 읽고 원인을 분석해 수정 제안을 해준다
가벼운 환경	무거운 IDE 대신 에디터와 AI 채팅창만으로 충분하다

---

해결 과정: AI 에이전트 기반 터미널 빌드 워크플로우 구축

Step 1. 엔진 경로 및 프로젝트 정보 파악

가장 먼저 사용 중인 엔진 버전과 핵심 실행 파일의 경로를 확인하여 AI 에이전트에게 전달했다.

Engine Path : F:\Epic Games\UE_5.6
UBT 경로     : ...\Engine\Binaries\DotNET\UnrealBuildTool\UnrealBuildTool.exe
Binary 경로  : ...\Engine\Binaries\Win64\UnrealEditor.exe

이 정보가 있어야 AI 에이전트가 정확한 경로로 빌드 명령을 구성할 수 있다.

경로가 틀리면 빌드 자체가 실행되지 않기 때문에 이 단계를 생략하면 안 된다.

---

Step 2. 슬래시(/) 명령어 기반 워크플로우 생성

AI 에이전트 내부의 .agent/workflows/ 디렉토리에 마크다운 형식의 실행 스크립트를 저장했다.

이를 통해 복잡한 PowerShell 명령어를 외울 필요 없이, 슬래시 명령어 한 줄로 빌드와 실행을 제어할 수 있게 되었다.

다른 방법도 고려했다. .bat 배치 파일을 만들어 두는 전통적인 방식이 있지만, 에러 발생 시 로그 분석을 수동으로 해야 한다.

 

마크다운 기반 워크플로우를 선택한 이유는 디렉토리에 마크다운 형식의 실행 스크립트도 지원하고, 이를 통해 쉽게 PowerShell 명령어를 외울 필요 없이 간단한 명령어로 선택할 수 있게 되기 때문이다.

1) /run — 빌드 후 에디터 실행

빌드가 성공했을 때만 에디터를 띄워주는 통합 워크플로우다.

/run이 수행하는 작업을 자동으로 수행하면 세 가지 일이 순서대로 일어난다.

• 먼저 UBT 빌드로 소스 코드 전체를 새로 컴파일한다.
• 성공 시 에디터를 자동 실행하고, 빌드가 성공했을 때 아직 에디터가 열리지 않은 상태라면 에디터를 새로 띄운다.
• 실패 시 리포트로 빌드 에러가 나면 AI가 로그를 즉시 읽어 에러를 분석해 보고한다.

실제 워크플로우의 핵심 PowerShell 로직은 다음과 같다.

$ubt = "F:\Epic Games\UE_5.6\Engine\Binaries\DotNET\UnrealBuildTool\UnrealBuildTool.exe"
$editor = "F:\Epic Games\UE_5.6\Engine\Binaries\Win64\UnrealEditor.exe"
$project = "F:\Unreal Project\GuardianAndSeeker\GAS.uproject"

Write-Host "--- Starting Build: GASEditor Win64 Development ---" -ForegroundColor Cyan
& $ubt GASEditor Win64 Development $project -waitmutex

if ($LASTEXITCODE -eq 0) {
    Write-Host "--- Build Succeeded! Launching Unreal Editor ---" -ForegroundColor Green
    Start-Process $editor -ArgumentList "$project"
} else {
    Write-Host "--- Build Failed. Check the logs above. ---" -ForegroundColor Red
    exit $LASTEXITCODE
}

$LASTEXITCODE(직전 명령어의 종료 코드, 0이면 성공)를 체크하여 빌드 성공 시에만 에디터를 실행하는 구조다.

실패 시에는 빨간색으로 경고를 출력하고 종료 코드를 반환한다.

---

2) /compile — 빠른 코드 검증 (라이브 코딩 호환)

에디터가 이미 켜져 있을 때, 터미널에서 빠르게 컴파일만 수행하여 문법 오류를 잡는다.

에러가 발생하면 AI가 즉시 로그를 읽어 원인을 분석한다.

 

이 명령어의 핵심 가치는 라이브 코딩(Live Coding, 에디터를 끄지 않고 코드 변경을 실시간 반영하는 기능)과의 호환이다. /compile로 문법 검증을 마친 뒤, 에디터에서 라이브 코딩 버튼(Ctrl+Alt+F11) 하나만 누르면 결과가 반영된다.

$ubt = "F:\Epic Games\UE_5.6\Engine\Binaries\DotNET\UnrealBuildTool\UnrealBuildTool.exe"
$project = "F:\Unreal Project\GuardianAndSeeker\GAS.uproject"

Write-Host "--- Starting Quick Compile: GASEditor Win64 Development ---" -ForegroundColor Cyan
& $ubt GASEditor Win64 Development $project -waitmutex

if ($LASTEXITCODE -eq 0) {
    Write-Host "--- Compilation Successful! ---" -ForegroundColor Green
} else {
    Write-Host "--- Compilation Failed. Review error logs. ---" -ForegroundColor Red
    exit $LASTEXITCODE
}

/run과 /compile의 차이를 정리하면 다음과 같다.

명령어	용도	에디터 실행	사용 시점
/run	전체 빌드 + 에디터 실행	✅ 빌드 성공 시 자동 실행	처음 작업 시작할 때
/compile	빠른 코드 검증만	❌ 에디터에 직접 영향 없음	코드 수정 후 문법 확인할 때

---

💡 실전 활용: 협업 루프(Loop)

구축한 워크플로우의 실전 사용 흐름을 보여주는 것이 가장 설명이 빠르다.

 

실제 GAS 발소리 시스템을 구현하면서 사용한 플로우는 다음과 같았다.

• 1단계 — 코드 수정.
  • AI에이전트에게 DataAsset 통합 및 거리 기반 최적화를 요청한다. AI가 코드를 수정한다.
• 2단계 — 빌드 검사.
  • AI가 스스로 /compile을 수행해 문법 에러를 진단한다. 에러가 있으면 AI가 로그를 읽고 즉시 수정한 뒤 다시 컴파일한다.
• 3단계 — 확인.
  • 사용자는 언리얼 에디터에서 반영된 결과를 확인한다.

💡 Tip: 라이더는 "디테일한 리팩토링"이나 “깊이 있는 디버깅/대규모 구조 변경” 시에만 켜면 될 거 같다.단순 로직 작업이나 반복적인 코드 수정은 AI 에이전트와 터미널 조합이 압도적으로 빠르다.

 

---

결과 및 개선 효과

Before vs After

항목	Before (IDE 기반)	After (AI 에이전트 + 터미널)
빌드 실행	IDE 실행 → 프로젝트 로드 → 빌드 버튼 클릭	/run 한 줄 입력
에러 분석	빌드 로그를 직접 읽고 수동 추적	AI가 로그를 자동 분석, 수정 제안까지
컨텍스트 스위칭	에디터 ↔ IDE ↔ 에디터 반복	단일 창에서 전체 흐름 완결
환경 부하	IDE가 수 GB 메모리 점유	에디터 + AI 채팅창만으로 충분
학습 비용	UBT 인자값(Win64, Development, Target 등) 숙지 필요	슬래시 명령어만 기억하면 됨

• 학습 곡선 단축 — 복잡한 UnrealBuildTool 인자값(Win64, Development, Target 등)을 신경 쓸 필요가 없다. /run과 /compile 두 단어만 알면 된다.
• 비용 효율성 — 슬래시 명령어 기반 워크플로우는 소량의 토큰만 소모하면서 시스템 제어 권한을 온전히 활용한다. 복잡한 빌드 파이프라인을 AI에게 맡기는 것이 아니라, 정해진 스크립트를 실행하는 가벼운 트리거 역할만 부여하기 때문이다.
• 에러 수정의 자동화 — 가장 체감이 큰 변화다. 기존에는 빌드 실패 → 로그 확인 → 원인 추적 → 수동 수정이라는 4단계를 거쳤다면, 지금은 빌드 실패 → AI가 로그를 읽고 수정안 제시 → 자동 재컴파일이라는 흐름으로 단축되었다. 개입할 부분이 최소화된다.

---

마무리

"라이더를 꼭 켜야 하나?"라는 질문에서 시작한 이 워크플로우는, 결국 '도구의 용도'와 '작업의 복잡도'를 일치시키는 것이 핵심이었다. 인텔리센스와 디버거가 필요한 깊은 작업에는 여전히 IDE가 최선(+ 브랜치를 바꾸고 나서 처음으로 작업할 때는 IDE로 빌드하는 게 안정적인 것인 거 같다)이다. 하지만 단순 로직 작성, 리팩토링, 빠른 프로토타이핑에는 AI 에이전트와 터미널 조합이 압도적으로 빠르다.

 

워크플로우 파일 위치는 .agent/workflows/에 build.md, run.md, compile.md로 정리했다.

이제 이 세 파일만 있으면 터미널 하나로 언리얼 C++ 개발의 핵심 루프가 완성된다.