TIL 2025.01.20 기록

0. 개요

---

오늘은 프로젝트 이후에 첫 수업이었다.

사실 강의를 들으면서 언리얼 공부를 하는 시간이었는데, 강의가 생각보다 알찼고, 튜터님께서 설명을 잘 해주셔서 좋았던 것 같다.

이렇게 느낀 이유는 지금까지 어려움을 느껴왔던 부분에 대해서 미리 설명이 나와있고, 빌드 과정이나 라이브 코딩 설명 등등이 좋았던 것 같다.

 

그 동안 어려웠던 부분은 언리얼 엔진을 사용하기 위한 기본 설정들 및 빌드 방법 등등이었다.

1년 전에 유데미 강의를 보며 공부했을 땐 라이브 코딩으로 빌드를 쭉 진행했었는데, 중간중간 에러 사항이 너무 많았다..

에디터에서 작업을 해뒀던 진행도 일부분이 저장이 안됐거나, 에디터에서 수정한 변수들이 저장이 안되있는 불상사가 발생한다거나 하는 일들이 많았다.

하지만, 이번 수업을 들으면서 그렇게 언리얼 엔진을 사용하면 안됐다.. 라는 생각이 많이 들었고, 언리얼 엔진으로 액터를 생성하기 이전 빌드나 폴더 구조등을 알려주셔서 너무 좋았던 것 같다.

 

그래서 오늘은 전반적으로 언리얼 1,2강 정리글을 올리고 마무리 하겠다.

 

1. 언리얼 엔진 C++ 개발 환경 준비하기

---

1. 언리얼 5.5.x c++ 빌드 에러 방지 (Engine 폴더 읽기 전용 해제)

 

이전에 기록했던 내용에 대한 내용이다.

TIL 2025.01.08 기록

다만 이제 이유에 대해서 알게되었는데,

엔진 빌드 과정에서 엔진 내부 파일을 임시로 수정하거나 접근하는 경우가 있다고 한다.

폴더가 읽기 전용이면 빌드 프로세스에서 파일을 수정하지 못해 컴파일 충돌이 발생할 수 있다.

 

2. Visual Studio 설치 및 워크로드 설치

언리얼의 각 버전마다 설치해야하는 IDE, .net 등의 버전 요구사항을 잘 체크하고 설치해야한다.

ㄴ> 이는 저번에 툴체인 문제를 해결할 때 작성했던 것 처럼 Visual Studio로 프로젝트 솔루션 파일을 열어, 설치가 부족한 부분에 대한 메세지를 확인하고, 설치해주거나 직접 문서를 찾아 엔진 버전에서 필요한 것들을 버전에 맞게 설치해주면 된다.

 

워크로드

: 윈도우 앱개발 도구나 C++을 이용한 개발 툴 셋 등 패키지를 의미한다.

언리얼에서는 위 2가지만 필요하다.

1. C++를 사용한 데스크톱 개발

2. C++를 사용한 게임 개발

 

3. 프로젝트 경로

프로젝트 경로에 한글, 특수문자, 공백 등이 들어가면 나중에 빌드 에러가 발생할 수 있다.

즉, 가능하면 영문 폴더명을 사용해야 한다.

 

4. 언리얼 프로젝트 생성 후 점검할 것

C++로 언리얼 프로젝트를 생성했다면, 가장 처음 확인해야하는 것은 Visual Studio(추후에 Rider)와 프로젝트가 연동이 잘 되어있는지 확인하는 것이다. 언리얼 에디터 “편집”(Editor)탭 -> 에디터 개인 설정(Editor Preferences) -> 일반(General) -> 소스 코드(Source Code) -> 소스 코드 에디터 (Source Code Editor)

 

추후에 Rider를 확인해야 한다고 기술한 이유는 라이더를 이용하더라도 우선 Visual Studio를 이용해 동작을 확인해 툴체인, .Net 등 다양한 설치 파일들이 잘 설치됐는지 확인하는게 좋아보였기 때문이다.

라이더의 경우 잘 안알려준다. (경험상... ;ㅅ;)

 

5. 프로젝트 폴더 내 파일 및 폴더 구성

<프로젝트 폴더 내 폴더 구조>

 

Source	C++ 소스코드가 들어있는 중요한 폴더이다. 구현하는 게임 로직들이 들어가는 폴더이다.
Content	언리얼 에디터의 Content Browser와 연결되어 있다. 에셋, 블루프린트, 머티리얼, 사운드 등이 저장되는 폴더이다. 에디터에서 새 에셋을 만들거나 다른 에셋을 불러오면 이 폴더 안에 파일이 생성된다.
Binaries	빌드를 했을 때 실행파일, dll 파일등이 들어가 있다.
Config	.ini파일이 들어있는데, 설정 파일들이 들어가 있는 공간이다. 에디터의 환경, 게임모드의 기본 값, 키보드 마우스 입력 설정, 렌더링 설정 등이 저장되는 곳이다.
DerivedDataCache	빌드를 할때, 중간 부산물인 임시 파일들이 저장되는 공간이다. 에셋, 쉐이더 등을 빠르게 처리하기 위한 캐시 파일이 저장된다.
Intermediate	빌드를 할때, 중간 부산물인 임시 파일들이 저장되는 공간이다. C++를 컴파일할 때 생성되는 임시 파일들이 저장된다.
Saved	자동 저장 파일, 로그, 크래시 덤프 등이 모여있다. Log가 있는데, 에디터가 비정상적으로 종료가 됐을 때, 로그가 입력되는 파일이 saved의 log에 있다. ㄴ> 해당 폴더 내용들로 진단할 수 있다는 의미이다.
.vs 폴더	Visual Studio가 자동 생성하는 폴더로, 디버깅&솔루션 설정 관련 파일들이 있다. 직접 수정할 일은 거의 없다.

 

<프로젝트 폴더 내 주요 파일>

.sln	C++ 소스 코드와 빌드 설정이 연결된 핵심 파일이다. 더블 클릭하면, Visual Studio 혹은 Rider에서 .cpp, .h 파일을 열어 수정할 수 있다.
.uproject	언리얼 에디터가 프로젝트 설정 (콘텐츠, 맵, 플러그인 등)을 불러올 때 사용하는 파일이다. 더블 클릭 시 언리얼 에디터에서 바로 프로젝트를 열 수 있다.
.vsconfig	Visual Studio Configuration 파일로, Visual Studio 프로젝트에서 사용되는 특정 설정과 구성 요소 설치 요구 사항을 정의한다. 프로젝트를 열 때 Visual Studio가 필요한 워크로드와 구성 요소를 자동으로 감지한다.

 

2. 언리얼 엔진 C++ 빌드 프로세스 이해하기

---

1. Solution Explorer 확인

실제 디스크 폴더 구조는 1강에서 살펴보았던 그 구조가 맞는데, 솔루션 파일에서는 빌드랑 관리를 편하게 하려고 일종의 가상 형태로 재구성을 한 것이다.

이런 구조를 솔루션 구조라 한다.

주의사항

Windows 탐색기의 실제 폴더 구조와 1:1로 대응되지 않을 수 있음을 유의해야 한다.

• Engine 폴더
  • 언리얼 엔진 자체 소스 코드와 리소스가 들어있는 폴더
  • 언리얼 엔진의 코어 코드이다 라고도 부른다.
  • 엔진을 커스터마이징 할때 건들게 된다.
• Games 폴더
  • 우리가 개발하는 게임 로직 등의 소스코드가 들어가있는 폴더이다.
  • 즉, 우리가 만든 프로젝트의 설정과 로직 코드들이 담겨있어 많이 보게될 폴더이다.
  • 내부에는 Source, Config, .uproject 파일 등이 있다.
• Programs 폴더
  • 엔진 동작에 필요한 유틸리티 프로그램이나 서버 모듈이 담겨있는 폴더이다.
• Rules 폴더
  • 엔진과 게임등 각 모듈의 빌드 규칙들이 담겨있는 폴더이다.
  • 모듈 의존성, 플러그인 활성화 여부, 빌드 대상등을 제어한다.
• Visualizers 폴더
  • Visual Studio에서 디버깅할 때, 언리얼 엔진의 관련 자료구조를 보기 편하게하기 위한 설정이 담겨있는 폴더이다.

🧭 가장 중요한건 Engine과 Games 폴더가 어떤 것들이 들어있는지이다.

 

 

2. 프로젝트 루트 폴더

우리 프로젝트와 같은 이름의 폴더를 프로젝트 루트 폴더라고 한다.

게임 개발에 필요한 모든 리소스와 설정 파일이 이곳에 모여있다.

프로젝트 루트 폴더의 하위 폴더

• Config 폴더
  • .ini 파일을 통해 에디터와 게임의 초기 상태를 지정한다.
  • 에디터의 환경, 게임모드의 기본 값, 키보드 마우스 입력 매핑이 담겨있다.
    • DefaultEditor.ini : 에디터 환경 설정 (뷰포트, UI 등)
    • DefaultEngine.ini : 엔진 전반 설정 (렌더링, 네트워크 등)
    • DefaultGame.ini : 게임플레이 관련 설정 (게임 모드, 플레이어 컨트롤러 클래스 등)
    • DefaultInput.ini : 키보드·마우스·패드 등의 기본 입력 바인딩
• Source 폴더
  • 실제 C++ 소스 코드(.cpp, .h)가 들어있다.
  • 프로젝트를 생성하면, 프로젝트의 시작점인 .cpp와 .h파일이 생성된다.
  • 빌드 설정 관련 주요 파일도 포함된다.
    • .Build.cs : 해당 프로젝트에 필요한 모듈, 라이브러리, 종속성 등을 정의 즉, 빌드 설정이 들어가있는 c#으로 작성된 코드이다.
    • .Target.cs, Editor.Target.cs : 각각 게임 실행용, 에디터용 빌드 방식을 정의
• .uproject
  • 언리얼 에디터에서 이 파일을 열면 프로젝트를 직접 실행할 수 있다.
  • 에디터는 이 파일을 통해 “어떤 콘텐츠와 설정을 불러올지”를 판단한다.

3. 빌드 설정 이해하기

코드를 수정했다면, 빌드를 해야 코드가 적용이 된다.

c++ 파일 수정 -> 빌드 (컴파일(Compile) + 링크(Link)) -> DLL 파일이 생성됨. -> 언리얼 에디터쪽에서 가져가서 구동함.

이런 과정을 거쳐야 생성된 DLL이 언리얼 에디터에서 로드되어, 코드 변경점이 게임이나 에디터 내에서 즉시 반영이 된다.

 

빌드 구성 및 플랫폼 확인

빌드 구성(Configuration)를 정하고, 플랫폼(Platform)을 선택하는 드롭다운 메뉴가 있다.

• 빌드 구성 (Configuration) 종류

DebugGame	디버깅을 하기에 최적화되어있는 빌드모드이다. 게임 로직만 디버그 정보를 포함하고, 엔진은 최적화된 상태로 빌드한다. 에디터가 아닌 독립 실행 파일 환경에서 디버깅이 가능하다. 즉, 게임 로직만 디버깅할 수 있게되고, 엔진 코드는 고정이된다. 대신 크기가 무겁다. => 때문에 속도가 느리다.
DebugGame Editor	에디터 환경에서 게임 로직을 디버그 하기 편한 설정이다. 에디터 플레이 중에 C++ 로직을 추적하거나 브레이크 포인트를 걸어볼 수 있다. 대신 크기가 무겁다. => 때문에 속도가 느리다.
Development	디버그 정보를 최소화해 실행 속도를 높인 개발용 빌드이다. 독립 실행 파일 환경 테스트·개발 단계에서 주로 쓰인다. 빨리빨리 테스트하고, 개발할 때 주로 많이 사용한다. 디버그용 코드는 없기 때문에 가벼운 디버깅을하거나, 테스트할 때 사용한다.
Development Editor	에디터에서도 개발·테스트를 원활히 할 수 있도록 구성된 빌드 모드이다. Live Coding 사용 시나리오와 궁합이 좋다.
Shipping	최종 사용자에게 배포할 때 사용하는 릴리즈 빌드이다. 디버그 정보를 제거하고, 성능 최적화가 극대화된다. 즉, 게임을 실행하기 위한 최적화된 상태이다.

• 플랫폼 (Platform) 설정
  • 모바일, 콘솔등으로 빌드하려면 해당 플랫폼용 SDK를 추가로 설치해야 한다.

4. 빌드하기

빌드는 “전체 솔루션 빌드”와 “부분 빌드”로 나누어 빌드할 수 있다.

Visual Studio 기준 Ctrl+shift+B를 눌러서 전체 솔루션 빌드를 하는데, 이는 엔진, 유틸리티, 게임 등 모든 모듈을 통째로 빌드한다.

시간이 오래 걸리기 때문에 매번 변경되지 않은 프로젝트들 까지 함께 빌드하는 것은 시간적으로 비효율적이다.

때문에 보통 부분 빌드를 진행해 작업한다.

솔루션 빌드의 경우 처음에만 오래걸리지 이후에는 수정된 사항이 없다면 그래도 빠른데, 이러한 이유는 중간 부산물들이 있기 떄문이다.

그렇긴 하지만 부분 빌드보다는 느리긴해서.. 작업할 때 필요하지 않다면, 부분 빌드를 사용하는게 좋다.

 

5. 빌드 전후 체크 포인트

• 빌드 시작 전
  • 언리얼 에디터는 가급적 종료하고 빌드하는게 안전하다.
  • 에디터가 실행 중이면 수정된 DLL을 교체하지 못해 빌드 에러가 발생할 수 있다. 이는 빌드된 dll을 붙잡고 있는 경우가 많다고 한다.
• 빌드 진행
  • Visual Studio 하단 Output 창에서 빌드 메세지를 모니터링한다.
  • 에러 메세지를 볼때, 인텔리센스는 제외하고 빌드 에러만 보면 된다.
    • 인텔리센스는 Visual Studio 상에서 훨씬더 코드를 편하게 작성할 수 있도록 제공해주는 기능이다.
    때문에 컴파일러의 빌드와 전혀 상관이 없다. 물론 좋은 코드를 작성하는데 도움은 주지만, 빌드엔 전혀 영향이 없기 때문에 처음에는 인텔리센스의 경고보다 빌드 오류에 집중하는게 좋다고 하신다.
• 빌드 결과
  • 프로젝트 폴더에 바이너리가 생겼을 텐데, 거기에 win64 폴더가 생긴 것을 확인할 수 있다.
  • 이곳에 우리가 계속 이야기했던 dll파일이 있는 것을 확인할 수 있다.
• 빌드 후 실행 대상 설정
  • 이전 DX, WinAPI때 설정했던 시작 프로젝트로 설정하는 세팅
  • set as startup project(시작 프로젝트로 설정)
  • 이렇게 하면, 디버깅 시 실행될 기본 프로젝트로 설정이 가능하다.
  • 프로젝트를 열 때, 런처에서 프로젝트를 여는것보다 이렇게 솔루션 파일을 열어서 하는게 좋다.
    • 이렇게 열게되면 중간에 디버깅을 하기에도 용이하기 때문이다.
    • 더 찾아봐야 하지만.. 라이더에는 굳이 그런 설정 세팅은 없는 것 같음.(?)

6. Live Coding

• 기존 방식
  • “Shift + F5 (에디터 연결 종료) → C++ 코드 수정 → Visual Studio에서 빌드 → F5 (에디터 재연결) → 결과 확인”

그러면 빌드를 할때, 계속 껏다 켰다를 반복해야할까? 이런 불편함을 해소해주기 위해 언리얼에서는 라이브 코딩을 지원한다.

• Live Coding 활용 시
  • “Shift + F5 (에디터 연결 종료) → C++ 코드 수정 → Visual Studio에서 빌드 → F5 (에디터 재연결) → 결과 확인”

즉, 코드를 작성하고 저장했을 때, 굳이 에디터를 끄지 않아도 변경점을 적용시키는 것이다.

<Live Coding 제약사항>

• 간단한 코드 변경 : 함수 내부 로직, 변수 값 변경, 로그 출력 변경 등은 LiveCoding으로 즉 시 반영된다.
• 적용이 안되는 경우 :
  • UCLASS, USTRUCT, UENUM 매크로의 추가·삭제·수정
  • 새로운 C++ 클래스 (.h/.cpp) 생성
  • 엔진 코어 영역 수정
  • **함수 시그니처 (인자, 반환값)**나 클래스 상속 구조 변경
• 이 경우에는 전통적인 빌드 프로세스 (에디터 종료 → Visual Studio 빌드 → 에디터 재실행)가 필요합니다.

Live Coding 기능 활성화

1. 수정한 소스 파일 저장
2. ctrl+alt+f11 < 라이브 코딩 단축키

7. 빌드 문제 복구하기

변경 사항 미반영 문제란?

C++ 코드를 수정하고 빌드를 완료 하였음에도 불구하고, 언리얼 에디터에서 반영이 안되는 경우가 있다.

빌드 캐시나 프로젝트 설정 문제, 혹은 파일 경로가 꼬여서 발생할 수 있으며, 아래와 같은 형태로 나타난다.

• 컴파일 대상 누락 : Visual Studio 혹은 엔진이 수정된 소스를 인식 못 해 빌드 대상에서 누락됨
• DLL 교체 문제 : 빌드가 끝났어도 에디터가 새 DLL을 로드하지 못함
• 캐시 문제 : 이전 빌드 결과물이 남아 새 빌드 결과를 덮어 씌우지 못함
• 파일 경로 문제 : 헤더 파일 경로나 플러그인 설정이 잘못되어 컴파일에 포함되지 않음

빌드가 꼬였을 때 해결하는 방법

1. 에디터 종료
2. visual studio 종료
3. project 폴더에서 빌드 부산물이 저장되는 DerivedDataCache, Intermediate, Saved 폴더 삭제 3-a. 추가적으로 바이너리 폴더까지 삭제해도 된다.
4. 이후 uproject 파일을 우클릭해서 visual studio project 파일 생성 버튼을 눌러 다시 생성해준다. ㄴ> 이러면 솔루션 파일이 재 생성된 것이다.
5. 이후 다시 uproject 파일을 실행해 에디터를 실행해주면 된다. ---- 대부분 60, 70%의 상황에서는 이정도면 해결이 된다.----
6. 빌드에 솔루션 정리를 해서 빌드 했던 것들을 정리해주고, 다시 빌드한다.

3. 마무리

---

사실 이런 정보를 찾기가 코드를 찾는것 보다 더 어려운 것 같았는데, 자새하게 배울 수 있어서 하나하나가 모두 좋았던 것 같다.

아직, 직접적으로 더 찾아봐야할 부분도 남아있지만..

> 나는  라이더를 사용할꺼니까, 라이더 오류 해결 방법이라던지, 라이더의 빌드 부산물 폴더들에 대해서 공부를 할 필요성이 보였다.

 

추가적으로는.. 오늘은 처음으로 조 변경이 있었다.

친해졌던 조원들을 떠나 잘 적응할 수 있을까 한편으로는 걱정이었는데, 조원분들과 튜터님 모두 친근하게 대해주셔서 다행이었다.

아이스 브래이킹도 이전보다 더 빨리 된것 같아 마음이 놓였다.

이번 조에서도 꼭..! 좋은 성과를 내고 싶다.

아쟈뵤! 무조건 걸작..!! 무조건 걸작 만든다..!!!

 

추가적으로 음.. 단순히 코드만 짜는 것보다 모듈화에 대해서 이제는 조금 더 깊게 고민해보려 한다.