Live Coding과 에디터를 닫고 빌드하는 시점

Live Coding은 실행 중 바이너리를 갱신한다

C++ 함수 구현을 조금씩 고치면서 결과를 확인할 때마다 에디터를 종료하면 반복 시간이 길어진다. Live Coding은 실행 중인 애플리케이션의 코드를 빌드하고 패치하는 기능으로 이런 작업을 돕는다. 사용 여부는 변경 범위와 프로젝트의 상태에 맞게 판단하며, 안정성을 이유로 모든 프로젝트에서 항상 꺼야 하는 기능은 아니다.

중요한 것은 변경 범위다. 이미 존재하는 함수의 작은 계산 변경과, 클래스 구조·생성자·모듈 의존성을 바꾸는 작업은 검증 조건이 다르다. 패치가 성공했다는 메시지만으로 새 실행과 같은 상태가 만들어졌다고 가정하면 문제를 놓치기 쉽다.

두 설정은 같은 스위치가 아니다

Epic의 5.8 문서에서 Enable Live Coding을 끄면 에디터의 컴파일 방식은 Hot Reload로 돌아간다. 따라서 Live Coding을 끈 것만으로 모든 실행 중 재컴파일을 금지한 것은 아니다. Automatically Compile Newly Added C++ Classes는 새 C++ 클래스 추가 시 자동 컴파일을 요청할지 정하는 설정이지, 모든 소스 파일 변경을 감시하는 전역 스위치가 아니다.

또한 Object Reinstancing은 구조가 달라진 객체를 교체해 변경을 반영하는 장치다. 따라서 헤더 변경이 모두 Live Coding으로 불가능하다고 단정하지 않는다. 지원 기능이 있더라도 프로젝트가 자체 포인터 캐시나 플러그인 상태를 유지한다면 새 객체와 기존 참조의 정합성을 별도로 검증해야 한다.

작업 종류별로 확인하기

입문 단계에서는 작은 변경은 Live Coding으로 반복하고, 구조를 크게 바꾸거나 원인을 알 수 없는 상태가 생기면 종료 후 일반 빌드로 기준 상태를 다시 확인하는 절차가 이해하기 쉽다. 이때 '빌드'와 '전체 리빌드'도 구분한다. 문제가 없는데 매번 모든 엔진 산출물을 지울 필요는 없다.

1. 작업을 저장하고 현재 코드 변경 내용을 확인한다. 함수 내부 수정인지, 클래스·모듈 구조 변경인지 구분한다.
2. 작은 구현 변경은 Live Coding으로 반영한 뒤 해당 기능을 다시 실행해 본다.
3. 생성자 기본값을 바꾼 경우 기존 인스턴스에 값이 남아 있는지 확인한다. 에셋에서 덮어쓴 값도 따로 확인한다.
4. 구조 변경 뒤 동작이 의심스럽다면 에디터를 정상 종료하고 프로젝트의 Editor 타깃을 빌드한 뒤 다시 연다.
5. 새 실행에서도 재현되는지 확인하고, 실패하면 최초 컴파일 오류와 재현 순서를 기록한다.

삭제보다 상태 확인이 먼저다

Saved, Intermediate, Binaries 폴더를 한꺼번에 지우는 것은 기본 해결 절차가 아니다. 저장되지 않은 작업, 로그, 복구 자료를 잃거나 불필요하게 큰 빌드를 만들 수 있다. 먼저 어떤 프로세스가 어떤 바이너리를 사용 중인지, 컴파일이 정말 성공했는지, 현재 연 프로젝트가 맞는지부터 확인한다.