우리가 작성한 코드가 하드웨어가 이해하는 실제 명령어로 변환되는 과정인 컴파일을 이해한다.
컴파일 언어와 인터프리터 언어의 실행 효율 차이를 분석하여 왜 엔진 개발에 C++이 필수적인지 파악한다.
시각적 도구인 블루프린트가 내부적으로 어떤 중간 단계를 거쳐 컴퓨터에게 전달되는지 그 과정을 분석한다.
🟧 1. 컴파일(Compile): 기계라는 로봇을 위한 번역서 제작
🟦 소스 코드와 기계어의 관계 (비유: 로봇 요리사)
우리가 작성하는 C++ 코드는 사람이 이해하기 쉬운 언어로 쓰인 요리 레시피다.
하지만 실제 하드웨어라는 로봇 요리사는 0과 1이라는 전기 신호(기계어)밖에 알아듣지 못한다.
컴파일은 이 영어 레시피를 로봇 요리사가 이해할 수 있는 동작 명령어(Instruction)로 완벽하게 번역해 주는 과정이다.
번역이 끝나면 실행 파일(Binary)이라는 결과물이 나오며, 이는 보조기억장치 창고에 보관되어 있다가 게임을 시작하면 메모리(RAM)라는 주방 작업대로 옮겨진다.
🟧 2. 컴파일 언어 vs 인터프리터 언어
🟦 실행 방식의 차이 (비유: 완조리 밀키트 vs 즉석 요리)
컴파일 언어(C++, Rust) : 손님이 오기 전에 이미 주방에서 모든 재료를 손질하고 조리법을 기계어로 번역해둔 '완조리 밀키트'와 같다. 준비 시간(빌드)은 오래 걸리지만, 손님이 주문(실행)하면 즉시 서빙되므로 하드웨어 성능을 극한으로 쓰는 하이엔드 게임에 최적화되어 높은 성능 지표 $P$를 유지한다.
인터프리터 언어(Python, JS) : 손님이 주문을 하면 그때서야 레시피를 한 줄씩 읽어가며 요리하는 '즉석 요리' 방식이다. 별도의 준비 시간은 없어서 개발하기는 편하지만, 요리하는 중간중간 레시피를 해석하는 시간이 필요하므로 컴파일 언어보다 처리 속도가 느리다.
언리얼 엔진이 굳이 어려운 C++을 주력으로 사용하는 이유는 실시간으로 수만 개의 연산을 처리해야 하는 게임 환경에서 이 $P$값의 차이가 프레임 유지에 결정적이기 때문이다.
🟧 3. 블루프린트의 컴파일 과정
🟦 노드 그래프에서 바이트코드까지 (비유: 동시통역사)
블루프린트는 그림 형태의 레고 블록 같지만, 실제로는 가상 머신(Blueprint VM)이라는 중간 통역사를 거쳐 하드웨어에 전달된다.
1단계 - 분석(Parsing) : FKismetCompilerContext라는 검사관이 노드 연결 상태를 보고 논리적으로 고장 난 곳이 없는지 확인한다.
2단계 - 바이트코드(Bytecode) 생성 : 그림을 기계가 바로 이해할 수 있는 언어는 아니지만, 통역사가 읽기 편한 전용 암호인 바이트코드로 바꾼다.
3단계 - 실행 단계 : 게임이 돌아가면 가상 머신이 이 암호를 실시간으로 읽어 하드웨어에 0과 1의 명령을 내린다.
이때 UCLASS나 UPROPERTY 같은 매크로들은 엔진이 이 데이터가 무엇인지 기억할 수 있도록 붙여두는 이름표 역할을 수행한다.
🟧 핵심 요약 및 주의사항
통역사 비용 : 블루프린트는 중간에 가상 머신이라는 통역사를 한 명 더 거치므로, 하드웨어에 직접 말하는 C++보다 실행 비용이 높다. 따라서 매 프레임 연산되는 Tick 로직은 가급적 C++로 구현하는 것이 효율적이다.
안전장치 : 컴파일 에러는 하드웨어가 명령어를 이해하지 못해 게임이 터지는 상황을 미리 막아주는 고마운 안전장치다.
모델 갱신 : 설계도인 클래스 구조가 바뀌면 CDO라는 기본 모델도 다시 구워야 하므로, 내용을 바꾼 뒤에는 반드시 컴파일 버튼을 눌러 하드웨어에게 새로운 명령을 알려줘야 한다.
