[언리얼] 라이브 코딩(Live Coding)이란?

라이브 코딩(Live Coding)이란?

라이브 코딩은 언리얼 에디터를 켠 상태에서 C++ 코드를 컴파일하고 그 결과를 에디터에 즉시 반영하는 기능이다. UE5에선 기본적으로 활성화되어 있으며, Ctrl + Alt + F11 단축키를 누르거나 에디터 창에서 오른쪽 아래에 위치한 아이콘을 눌러 실행한다.(아래 사진 참고)

라이브 코딩의 탄생 배경

기존의 문제점 - 소스 코드를 적용하려면 에디터를 껐다 켜야 한다.

 

언리얼 에디터는 기본적으로 변경된 게임 코드를 적용하기 위해 프로세스를 껐다 다시 켜야 한다. 왜냐하면 언리얼 에디터 “프로세스”가 DLL(동적 링크 라이브러리) 파일로 컴파일된 게임 코드(“UE5Editor-MyGame.dll”같은)를 자신의 프로세스 메모리에 올린 상태로 돌아가기 때문. 게임 DLL이 에디터 프로세스 메모리 공간에서 돌아가고 있는데 이걸 갱신 또는 교체하려고 하면 OS가 막기 때문에(윈도에서 프로세스가 DLL을 로드하는 순간 “사용 중인 파일”이 되어 갱신 또는 교체에 대해 락이 걸린다) 프로세스를 껐다 켜야지 교체가 가능하다.

 

 

문제점을 해결한 기술 “핫 리로드(Hot Reload)” - 하지만 하자가 있는

 

이 문제점을 해결하기 위해 UE4에 등장한 기술이 바로 "핫 리로드(Hot Reload)"이다.

 

핫 리로드는 이름과 달리 기존 DLL을 갱신하는 방식은 아니고, 새 DLL 파일을 “추가로” 로드하는 방식이다. 예를 들어 기존 DLL 파일의 이름이 “UE4Editor-MyGame-1234.dll”이었다면 새 DLL 파일을 “UE4Editor-MyGame-5678.dll”와 같이 넘버링만 달리하여 에디터 메모리에 추가로 올리는 것이다. 그런 다음 엔진이 들고 있던 클래스 참조들을 새 DLL 쪽으로 갈아 끼워서 마치 리로드 된 것처럼 작동하는 것이다.

 

이런 핫 리로드는 에디터를 끄지 않고 갱신된 게임 코드를 에디터에 반영할 수 있도록 해주었지만 부작용이 많았다.

 

핫 리로드는 엔진과 살아있는 객체들이 기존 DLL 내부를 깊게 참조하고 있는 상황에서 이미 생성된 객체들의 클래스 정보를 런타임에 새 버전으로 연결하려고 한다. 그런데 이때 전부 연결하지 못하고 일부분만 연결되어 어떤 건 기존 DLL을, 어떤 건 새 DLL을 가리키는 어정쩡한 상태가 되면서 1) 변경이 반영이 안 되거나, 2) 에셋이 깨지거나, 3) 심하면 파일이 오염되는 문제가 발생한다.

 

게다가 핫 리로드는 dll이 계속 쌓이는 불편함도 있다. 기존 DLL 파일은 지워지지 않고 그대로 남아있기 때문에 시간이 좀 지난 뒤 DLL 폴더를 들어가면 쌓인 DLL 파일로만 몇십 GB를 차지하고 있는 꼬락서니도 볼 수 있다.

 

이렇듯 핫 리로드 방식은 굉장히 문제가 많았기 때문에 결국 UE5에 오면서 deprecated 되었다.

 

그래서 등장한 기술 “라이브 코딩(Live Coding)”

 

UE5에서 핫 리로드가 deprecated 되면서 대체재로 나온 기술이 바로 “라이브 코딩(Live Coding)”이다.

라이브 코딩은 DLL을 교체하지 않는다. 대신 바뀐 부분이 있다면 해당 부분만 컴파일해서 메모리에 덧붙인 다음, 기존 DLL에 있던 원래 함수의 맨 앞에 “이제부터는 저기로 가리”는 점프(jump) 명령 한 줄을 심어둔다. 이렇게 하면 기존 DLL을 계속 사용하면서 바뀐 내용을 그대로 반영할 수 있다.

 

이런 작동 방식은 기존 핫 리로드에서 발생했던 대부분의 문제를 해결해 준다. 핫 리로드에서 발생했던 문제의 대부분이 새 DLL로 교체할 때 참조가 제대로 교체되지 않았던 것이 원인이었는데, 라이브 코딩은 DLL 교체 작업 자체가 없기 때문에 함수 주소가 바뀌거나 클래스 레이아웃이 밀리거나 객체가 깨지는 등의 문제는 발생하지 않는다.

게다가 바뀐 부분만 컴파일하기 때문에 전체를 컴파일하는 핫 리로드 방식과 비교했을 때 컴파일 시간이 크게 단축된다는 장점도 있다.

 

 

라이브 코딩의 한계

그럼 라이브 코딩은 항상 옳을까? 모든 경우에서 핫 리로드보다 편하고 좋을까? 라이브 코딩을 안 지 얼마 안 되었을 때는 당연히 그럴 거라 생각했지만, 라이브 코딩은 라이브 코딩 나름대로 한계가 있었다. 한계들을 나열하자면 아래와 같다.

 

첫째, 구조 변경 시 사용이 불가능하다.

라이브 코딩은 함수 본문을 변경하는 건 잘 되지만, 구조를 변경했을 땐 작동하지 않는다. 멤버 변수를 새로 추가하거나, UPROPERTY 매크로 내부를 바꾸거나, 새 함수를 선언하는 등 헤더 파일 자체를 수정하면 라이브 코딩으로 커버할 수 없다는 것이다. 이때는 어쩔 수 없이 기존 방식처럼 에디터를 껐다가 다시 켜야 한다.(세상 답답하지 않을 수 없다)

 

왜 라이브 코딩은 구조 변경 시 사용이 불가능할까? 이유는 간단하다. 라이브 코딩은 그저 “함수 구현부에 대한 주소를 리다이렉팅” 할 뿐, 기존 DLL을 그대로 사용하기 때문이다. 기존 DLL을 사용하는 이상 “이미 만들어진 객체의 크기와 구조”를 바꿀 수 없기 때문에 기존 클래스 메모리 레이아웃 바꾸는 작업을 했다면 라이브 코딩은 이를 처리할 수 없다.

 

둘째, 디버그가 이상해진다.

첫 번째 한계에서 언급했듯 라이브 코딩은 기존 DLL 위에서 돌아간다. 여기서 패치를 덧대어 리다이렉팅을 하는 방식으로 돌아가는데 이런 방식이 디버거를 붙인 상태에서 어긋나는 모습을 보여준다. 인라인 함수, 템플릿처럼 컴파일 타임에 코드가 펼쳐지는 경우 특히 문제가 생긴다고 한다.

 

라이브 코딩 사용 시 워크플로우는 어떻게?

 

핫 리로드는 싫고, 그렇다고 매번 에디터를 끄는 건 더 싫어서 결국 라이브 코딩을 사용하긴 해야 한다. 한계점이 명확해도 장점도 많아(컴파일 빠르지, 에디터 안 꺼도 되지… 그냥 작업 속도가 빠르다) 쓰긴 할 텐데 정확히 어떤 식으로 써야 할지 좀 헷갈린다. 그래서 찾아보니 위와 같은 워크플로우로 진행하면 된다고 한다.

 

왼쪽 경로, 즉 cpp 파일에서 함수 본문만 고친 경우 라이브 코딩을 사용하면 된다. 게임플레이 로직, 수치 조정, 리플렉션 함수가 아닌 것들만 수정했다면 에디터를 끄지 않고 라이브 코딩으로 에디터에 반영시킬 수 있다. 구조만 잡히면 대부분의 반복 작업이 이 cpp를 바꾸는데 시간을 쓰기 때문에 이런 작업의 경우 라이브 코딩이 빛을 발한다고 할 수 있다.

 

오른쪽 경로, 즉 헤더를 건드렸거나 리플렉션과 관련된 요소(UPROPERTY 멤버 추가, UFUNCTION 시그니처 변경 등)를 바꾼 경우, 에디터를 끄고 컴파일해야 한다. 컴파일의 경우 IDE에서 해도 되고, 에디터에게 맡겨도 되는데(컴파일 안 한 상태로 다시 키면 재빌드 할 거냐고 뜬다) IDE에서 컴파일하는 게 더 좋은 습관이기 때문에 웬만하면 IDE로 컴파일하는 게 좋다.

 

 

결론 및 요약

• 라이브 코딩은 에디터가 켜진 상태로 컴파일하기 위해 쓰는 기능이다.
• 핫 리로드라는 비슷한 역할을 하는 기능도 있는데 UE5로 넘어온 지금 라이브 코딩이 권장된다.
• 라이브 코딩은 함수 구현부를 수정할 때만 유효하다. 헤더 파일을 수정했다면 에디터를 껐다 켜자.