[부록] 3-6. 라이브 코딩 vs 빌드

부록 안내

이 내용은 부록으로, 진행에 직접 영향을 주지는 않습니다. 다만 C++ 코드를 수정한 뒤 그 변경을 에디터에 어떻게 반영하는지는 개발 속도와 직결되므로, 한 번쯤 정확히 이해해 두면 큰 도움이 됩니다.

언리얼에서 C++ 코드를 수정한 뒤 결과를 확인하는 방법은 크게 풀 빌드(Build) 와 라이브 코딩(Live Coding) 두 가지로 나뉩니다. 과거에는 그 사이에 핫 리로드(Hot Reload) 라는 방식도 있었습니다. 각각이 무엇을 하는지, 그리고 “언제 라이브 코딩으로 충분하고 언제 에디터를 닫고 풀 빌드해야 하는지”를 정확히 구분하는 것이 이 문서의 목표입니다.

Build(빌드)란

빌드는 UBT(UnrealBuildTool) 가 C++ 소스 코드를 컴파일해 실행 가능한 모듈(에디터용 DLL 등) 로 만드는 과정입니다. 우리가 작성한 .h / .cpp 파일은 그대로는 엔진이 실행할 수 없고, 컴파일과 링크를 거쳐 바이너리 모듈로 바뀌어야 에디터와 게임에서 사용할 수 있습니다.

일반적으로 빌드는 다음 두 가지 흐름 중 하나로 이루어집니다.

IDE에서 빌드

• Visual Studio / Rider 등에서 직접 빌드
• 구성: Development Editor, 플랫폼: Win64
• 에디터를 켠 채로도, 닫고서도 가능

에디터를 닫고 빌드

• 에디터를 완전히 종료한 뒤 빌드
• DLL 파일이 잠겨 있지 않아 가장 안전
• 구조/리플렉션 변경 후 권장

참고

구성 이름의 의미를 간단히 정리하면, Development는 디버깅 정보가 일부 포함되면서도 실행 속도가 적당한 일반 개발용 구성이고, Editor는 결과물이 에디터에서 동작하는 모듈이라는 뜻입니다. 즉 “에디터에서 쓸 개발용 모듈”을 만드는 가장 흔한 조합이 Development Editor / Win64 입니다.

Hot Reload(핫 리로드) — 과거 방식

핫 리로드는 에디터가 실행 중인 상태에서 컴파일된 모듈 DLL을 통째로 교체하던 과거의 방식입니다. 새 DLL을 새로운 이름으로 만들어 메모리에 다시 로드하는 구조였는데, 객체 인스턴스와 리플렉션 데이터의 정합성이 깨지는 등 불안정한 문제가 잦았습니다.

주의

핫 리로드는 현재 권장되지 않으며 사실상 폐기된 방식입니다. 최신 워크플로에서는 아래의 라이브 코딩이 이 역할을 대체합니다. 옛 자료나 오래된 프로젝트에서 용어가 등장하면 “지금의 라이브 코딩 이전 방식” 정도로 이해하면 됩니다.

Live Coding(라이브 코딩) — 현재 권장 방식

라이브 코딩은 현재 언리얼이 권장하는 방식으로, 내부적으로 Live++ 기술을 사용합니다. 핵심 차이는 DLL을 통째로 교체하는 대신, 변경된 부분만 패치해서 이미 실행 중인 에디터에 반영한다는 점입니다. 덕분에 함수 본문을 고치는 정도의 작업은 매우 빠르고 강력하게 적용됩니다.

에디터를 켠 채로 다음 방법 중 하나로 실행할 수 있습니다.

• 단축키 Ctrl + Alt + F11
• 에디터 우하단의 Compile 버튼

라이브 코딩이 잘 맞는 작업

이미 존재하는 함수의 구현(본문) 수정 입니다. 예를 들어 계산식을 바꾸거나, 로그를 추가하거나, 분기 조건을 조정하는 등 “선언은 그대로 두고 내부 동작만 바꾸는” 변경에 특히 강합니다.

// 이런 함수 "본문"만 고치는 경우 → 라이브 코딩으로 빠르게 반영
void AMyActor::UpdateScore()
{
    // 예: 점수 계산 로직만 수정
    Score += 10;            // 변경 전
    Score += 25;            // 변경 후 (본문 수정 → Live Coding OK)
}

Live Coding의 한계 (가장 중요)

라이브 코딩은 함수 구현 변경에는 탁월하지만, 클래스의 구조나 리플렉션에 영향을 주는 변경에는 반영되지 않거나 불안정하게 동작할 수 있습니다. 아래 대비표를 기준으로 삼으면 헷갈리지 않습니다.

라이브 코딩으로 충분

• 기존 함수의 본문(구현) 수정
• 지역 변수, 계산식, 분기 로직 변경
• 로그/디버그 출력 추가
• 리플렉션과 무관한 내부 동작 조정

에디터를 닫고 풀 빌드 권장

• 새 UPROPERTY / UFUNCTION / UCLASS 추가
• 멤버 변수 추가, 함수 시그니처 변경
• 리플렉션에 영향을 주는 헤더 변경
• 새 .h / .cpp 파일 추가
• .Build.cs, 모듈 의존성 변경

주의

헤더(.h) 변경과 리플렉션 변경은 라이브 코딩이 다루기 어려운 대표적인 영역입니다. 멤버를 추가하면 객체의 메모리 레이아웃이 바뀌고, 새 UPROPERTY/UFUNCTION은 UHT(Unreal Header Tool) 가 다시 생성해야 하는 리플렉션 코드를 동반하기 때문입니다. 이런 변경은 에디터를 닫고 풀 빌드(또는 재시작) 해야 안전합니다.

아래는 라이브 코딩만으로는 안전하게 반영되지 않는 변경의 예시입니다.

UCLASS()
class AMyActor : public AActor
{
    GENERATED_BODY()

public:
    // 새 UPROPERTY 추가 → 리플렉션/레이아웃 변경
    UPROPERTY(EditAnywhere)
    int32 BonusScore = 0;   // 멤버 추가 → 풀 빌드 필요

    // 새 UFUNCTION 추가 또는 시그니처 변경도 마찬가지
    UFUNCTION(BlueprintCallable)
    void ResetScore();      // 선언 변경 → 풀 빌드 필요
};

언제 무엇을 쓰는가

판단 기준은 단순합니다. “코드의 내용만 바뀌는가, 아니면 클래스의 모양(구조)이 바뀌는가” 를 물어보면 됩니다.

| 변경 종류 | 권장 방식 | | --- | --- | | 작은 로직 / 함수 본문 수정 | Live Coding | | 멤버·시그니처 등 클래스 구조 변경 | 풀 빌드 | | 리플렉션(UPROPERTY/UFUNCTION/UCLASS) 변경 | 풀 빌드 | | 새 .h / .cpp 파일 추가 | 풀 빌드 | | .Build.cs / 모듈 의존성 변경 | 풀 빌드 |

팁

정리하면 함수 안쪽만 고쳤다면 라이브 코딩, 클래스의 선언부나 파일 구성·빌드 설정을 건드렸다면 풀 빌드라고 기억하면 대부분의 상황을 깔끔하게 처리할 수 있습니다.

실무 팁

리플렉션이나 클래스 구조를 변경한 직후 에디터 동작이 이상하다면, 라이브 코딩이 변경을 제대로 반영하지 못한 것이 원인일 가능성이 높습니다. 이럴 때는 추측하지 말고 에디터를 닫고 풀 재빌드로 깨끗한 상태를 만든 뒤 다시 확인하는 것이 가장 확실합니다.

참고

빌드가 실제로 어떤 단계를 거쳐 진행되는지 — UBT와 UHT가 각각 무슨 일을 하고 모듈이 어떻게 만들어지는지 — 는 다음 문서 3-7. 빌드 파이프라인에서 더 자세히 이어집니다. 이 문서에서 “무엇을 언제 쓰는가”를 잡았다면, 3-7에서는 “그 빌드가 내부적으로 어떻게 돌아가는가”를 보게 됩니다.