2026-03-17 TIL (16일차)

Posted Mar 17, 2026 Updated Mar 17, 2026

By BAEK MUSONG(백무송)

21 min read

Unreal

💡 [Tip]

언리얼 핵심 라이팅(Lighting) 컴포넌트

언리얼 엔진에서 야외 환경을 구성하기 위한 5가지 핵심 라이팅 요소입니다.

핵심 컴포넌트 요약
컴포넌트 핵심 역할 비유
Directional Light 직사광선. 무한히 먼 곳에서 평행하게 쏟아지는 빛입니다. 태양
Sky Light 간접광. 하늘 전체에서 반사되어 내려오는 은은한 빛. 그림자 부분을 밝혀줍니다. 하늘의 반사광
Sky Atmosphere 대기 효과. 공기 입자에 빛이 산란되는 물리 현상을 시뮬레이션하여 푸른 하늘이나 노을을 만듭니다. 지구의 대기권
Exponential Height Fog 안개. 멀리 있는 물체를 흐릿하게 만들어 거리감을 줍니다. 아래로 갈수록 농도가 짙어집니다. 새벽 안개/미세먼지
Volumetric Cloud 입체 구름. 빛과 반응하는 실제 3D 구름입니다. 구름 사이로 빛이 비치는 연출이 가능합니다. 진짜 구름

컴포넌트	핵심 역할	비유
Directional Light	직사광선. 무한히 먼 곳에서 평행하게 쏟아지는 빛입니다.	태양
Sky Light	간접광. 하늘 전체에서 반사되어 내려오는 은은한 빛. 그림자 부분을 밝혀줍니다.	하늘의 반사광
Sky Atmosphere	대기 효과. 공기 입자에 빛이 산란되는 물리 현상을 시뮬레이션하여 푸른 하늘이나 노을을 만듭니다.	지구의 대기권
Exponential Height Fog	안개. 멀리 있는 물체를 흐릿하게 만들어 거리감을 줍니다. 아래로 갈수록 농도가 짙어집니다.	새벽 안개/미세먼지
Volumetric Cloud	입체 구름. 빛과 반응하는 실제 3D 구름입니다. 구름 사이로 빛이 비치는 연출이 가능합니다.	진짜 구름

레벨 디자인 필수 단축키: `END` 키

액터를 공중에 띄워 놓은 상태에서 END 키를 누르면, 액터의 콜리전(Collision)이 바닥에 닿을 때까지 수직으로 자동 낙하합니다.

활용 레벨 디자인을 할 때 맵에 배치된 소품(Prop)들이 공중에 떠 있는 상황을 방지하려면 사용해야 하는 단축키입니다.

비주얼 스튜디오에서 `F5`로 엔진을 실행해야 하는 이유

디버깅(Debugging)의 주도권 확보 비주얼 스튜디오에서 F5를 눌러 실행하면, 비주얼 스튜디오가 에디터의 ‘감시자’ 역할을 하게 됩니다.

만약 소스코드를 잘못 작성하여 에디터가 꺼지더라도(Crash), 비주얼 스튜디오가 에러가 발생한 코드를 보여줍니다.
따로 켜게 되면 에디터가 꺼졌을 때 왜 꺼졌는지 알 방법이 없습니다.

코드와 데이터의 완벽한 동기화

빌드 후 실행: F5를 누르면 “변경된 코드가 있는지”를 먼저 확인하고, 있다면 빌드를 마친 뒤 갱신한 버전의 에디터를 띄워줍니다.
혼선 방지: 에디터를 미리 켜둔 상태에서 코드를 고치면, 현재 켜진 에디터가 예전 코드인지 새 코드인지 헷갈리는 상황(라이브 코딩 오류 등)이 생길 수 있습니다. F5로 실행하는 습관은 혼선을 차단합니다.

Visual Studio 솔루션 구성(Solution Configuration)

솔루션 구성의 기능
언리얼 엔진은 규모가 큽니다. 상황에 따라 “엔진 에디터를 띄울 것인지”, “결과물처럼 게임만 띄울 것인지”, 또는 “속도는 느려도 버그를 잡기 편하게 할 것인지”를 결정해야 합니다.

설정을 잘못 맞췄을 때 발생하는 문제
코드를 수정하고 빌드했는데 에디터에 반영이 안 됨.
게임을 실행했는데 프레임 속도가 비정상적으로 느림.
디버깅 중단점이 잡히지 않고 무시됨.

● 핵심 키워드
솔루션 구성의 명칭은 기본적으로 [상태(빌드 스타일)] + [대상(실행 환경)]의 조합으로 이루어져 있습니다.

● 상태 (빌드 스타일)

Debug: 최적화를 전혀 하지 않습니다. 버그 잡기에는 최적이지만 실행 속도가 느립니다.
Development: 적절한 최적화와 디버깅을 허용합니다. 개발 중 많이 쓰는 기본값입니다.
Shipping: 최고 수준의 최적화를 진행하며 디버깅 기능을 제거합니다. 유저에게 배포할 때 사용합니다.

● 대상 (실행 환경)

Editor: 언리얼 엔진 에디터 자체를 함께 실행합니다. (언리얼 창)
이름 없음 (Standalone): 에디터 없이 게임만 단독 프로세스로 실행합니다.

항목별 상세 설명 및 용도

솔루션 구성 명칭	특징 및 용도	비유
DebugGame Editor	에디터에서 내 게임 코드를 아주 정밀하게 디버깅하고 싶을 때 씁니다. 엔진 코드는 최적화되어 있고, 내가 짠 코드만 디버그 상태가 됩니다.	돋보기를 들고 에디터 안을 들여다보기
Development Editor	언리얼 C++ 개발자의 기본값. 에디터를 띄워서 작업하고 테스트할 때 씁니다. 속도와 디버깅의 밸런스가 좋습니다.	평상시 주행 모드
DebugGame	에디터 없이 실제 게임 창만 단독으로 띄워서 버그를 잡을 때 씁니다.	실제 필드에서 돋보기 들기
Development	에디터 없이 실제 게임만 띄워 전반적인 성능을 확인해볼 때 씁니다.	실제 필드에서 달리기 테스트
Shipping	모든 디버깅 도구(로그, 콘솔창 등)를 빼고 실행 속도를 극대화합니다. 실제 출시용입니다.	결승선 통과용 (최종 결과물)

실전 팁

상황별 구성
1. 방금 C++ 코드를 고쳤고, 에디터 켜서 확인해보고 싶을 때 -> Development Editor를 선택하고 F5
2. 코드가 크래시 나는데, 변수 값을 추적하고 싶을 때 -> DebugGame Editor로 바꾸고 F5
3. “게임 다 만들고 제출용 실행파일(.exe)을 뽑는 경우” -> Shipping으로 바꾸고 패키징

특정 구간만 최적화 끄기

Development Editor 모드에서 특정 구간만 상세히 디버깅하고 싶을 때 사용하는 매크로입니다.

사용 이유
언리얼의 Development 빌드 구성은 실행 속도를 높이기 위해 컴파일러가 코드를 최적화합니다.

최적화로 인한 디버깅 한계와 해결책
문제점: 최적화가 되면 컴파일러가 코드를 임의로 재배치하거나 불필요하다고 판단한 변수를 생략해버립니다.
현상: 디버깅 시 실행 줄이 제멋대로 튀거나, 변수 값에 마우스를 올려도 최적화되어 값을 확인할 수 없습니다라는 메시지가 뜹니다.
해결책: 프로젝트 전체를 느린 Debug 모드로 바꾸는 대신, 딱 필요한 함수만 최적화를 꺼서 변수 값을 명확하게 확인합니다.

매크로 사용법 및 정리

매크로 명칭	역할	위치
`UE_DISABLE_OPTIMIZATION`	이후에 나오는 코드의 최적화를 중단함.	확인하고 싶은 코드나 함수의 시작 윗부분
`UE_ENABLE_OPTIMIZATION`	최적화를 다시 활성화함.	확인하고 싶은 코드나 함수의 끝나는 아랫부분

  
// 이 위쪽은 최적화되어 빠르게 작동합니다.

UE_DISABLE_OPTIMIZATION  // 여기서부터 최적화 해제

void AMyActor::MyComplexFunction() {
    int32 CriticalValue = 100; // 이제 디버깅 시 이 값이 정확히 보입니다.
    // ... 복잡한 로직 ...
}

UE_ENABLE_OPTIMIZATION   // 여기서부터 다시 최적화 시작

// 이 아래쪽은 다시 최적화되어 빠르게 작동합니다.

Git

git 기본 세팅 파일

.gitignore
● 핵심 역할 .gitignore 파일이 위치한 폴더를 기준으로, 내부에 작성된 경로의 파일 및 폴더들을 탐색하여 업로드 대상에서 완전히 제외합니다.
● 파일 위치 (매우 중요) 파일이 있는 곳이 탐색의 기준점이 되므로, 반드시 .uproject나 .sln 파일이 있는 프로젝트의 최상위 폴더에 위치해야 합니다.
● 사용 방법 텍스트 에디터로 열고 제외할 파일의 이름이나 폴더 경로를 작성합니다. (예: 임시 폴더인 Intermediate/, Saved/ 등)

.gitattributes (대용량 파일 및 속성 제어)
● 핵심 역할 Git에게 “이 특정 확장자를 가진 파일들은 이런 방식으로 다뤄줘”라고 명시하는 지시서입니다.
● Git LFS 연동 .gitattributes에 기록된 규칙을 바탕으로 Git LFS가 작동합니다. 무거운 실제 파일 대신 아주 가벼운 가짜 포인터 파일만 깃허브에 올리고, 원본은 별도 서버에 보관하여 관리 효율적으로 합니다.
● 주요 사용처 용량이 큰 동영상(mp4), 사운드(wav), 이미지(png), 3D 에셋(uasset) 등을 처리할 때 사용합니다.

Git 협업 상황

팀원이 업데이트했을 때 (내려받기)
핵심: 팀원의 코드를 내 컴퓨터로 내려받는 상황입니다.
상황: 팀원으로부터 “커밋 푸시 했습니다!”라는 알림을 받음.
액션: [Fetch origin] 클릭 → [Pull origin] 클릭.
결과: 내 로컬 폴더에 팀원의 최신 코드가 안전하게 합쳐집니다.

나만 작업했을 때
핵심: 작업 공간에 나밖에 작업을 안하고 있을 때
상황: 내가 작업을 시작하고 끝낼 때까지 리모트(GitHub) 서버에 다른 변화가 없음.
액션: [Commit] 작성 → [Push origin] 클릭.
결과: 내 코드가 서버에 즉시 반영됩니다. (별도의 풀/머지 과정 생략)

서로 다른 파일을 작업했을 때 (자동 머지)
핵심: 서로 각각 다른 파일을 작업하고 있기에 겹치는 파일이 없을 경우 알아서 하나로 합쳐주는 상황
상황: 팀원이 먼저 코드를 올렸지만, 나와 수정 내역이 겹치지 않음. (예: 팀원은 Player.cpp, 나는 Enemy.cpp 수정)
액션: [Commit] → [Fetch/Pull origin] (이때 깃이 자동으로 코드를 합쳐줌) → [Push origin] 클릭.
결과: 팀원 코드와 내 코드가 섞여서 서버에 올라갑니다.

같은 파일을 작업했을 때 (충돌 해결 - Conflict)
핵심: 서로 같은 곳을 수정하여 깃이 “누구의 코드를 남길까?”라고 물어보는 주의가 필요한 상황입니다.
상황: 같은 파일의 같은 줄을 수정하여 Conflict(충돌) 발생.
액션:
[Fetch/Pull] 시도 시 “Conflict” 알림 발생.
[Open in Visual Studio] 등의 에디터 버튼 클릭.
코드에서 <<<< HEAD와 >>>> 사이를 확인하고, 팀원과 상의하여 최종 코드를 남기고 특수 기호들을 지움.
갈등 해결 후 [Commit Merge] → [Push origin] 클릭.
결과: 충돌을 해결된 최종본이 서버에 기록됩니다.

Fetch를 먼저 해야 하는 이유

Pull은 코드를 가져오는 즉시 내 코드와 합쳐버리지만, Fetch는 “원격 저장소에 어떤 변화가 있는지” 정보만 안전하게 가져옵니다.

● 업데이트 내역 사전 확인
어떤 팀원이 어떤 파일을 수정했는지 미리 확인이 가능합니다.
내 코드를 합치기 전에 팀원의 작업 로그를 읽어볼 수 있습니다.
● 충돌 예방 및 대비
Pull을 바로 했다가 갑자기 수백 개의 충돌이 터질 수도 있습니다.
Fetch를 하면 내 현재 작업 위치와 팀원의 위치 차이를 시각적으로 확인할 수 있어, 내가 작업 중인데 팀원도 수정했네? 하고 미리 충돌에 대비할 수 있습니다.
● 병합 전략 선택 가능
단순히 합칠 것인지(Merge), 아니면 내 작업 기록을 팀원의 최신 코드 뒤로 붙일 것인지(Rebase) 선택권이 생깁니다.
Pull은 기본 설정된 방식으로 강제 병합을 시도하지만, Fetch 후에는 상황에 맞는 최적의 방식을 내가 직접 결정할 수 있습니다.

SourceTree Pull 옵션 기능

충돌이 없으면 묶어서 바로 커밋

의미: 팀원 코드와 내 코드를 합칠 때, 서로 건드린 파일이 달라서 충돌이 없다면 별도의 확인 절차 없이 병합(Merge) 커밋을 생성하겠다는 뜻입니다.
사용 상황: 일반적인 상황에서 사용합니다.

병합 커밋에 있는 메시지들을 첨부하세요

의미: 합쳐지는 팀원의 커밋 메시지 내용(예: “플레이어 점프 기능 추가”, “버그 수정”)을 내가 새로 만들 병합 커밋 메시지에 자동으로 리스트업 해주는 옵션입니다.
사용 상황: 나중에 히스토리를 볼 때 병합으로 인해 어떤 기능들이 한꺼번에 들어왔는지를 파악하고 싶을 때 유용합니다.

fast-forward가 가능해도 새 커밋으로 생성

의미: Git은 원래 선이 하나로 이어질 수 있다면(Fast-forward) 별도의 ‘합쳐짐’ 표시 없이 선을 길게 늘립니다. 이 옵션을 체크하면 강제로 “여기서 두 코드가 합쳐졌음”이라는 동그란 병합 지점(Merge Bubble)**을 만듭니다.
사용 상황: 프로젝트의 줄기가 언제 나뉘었다가 합쳐졌는지 기록을 남기고 싶을 때 사용합니다. 협업 시 “기능 단위”로 기록을 남기기 위해 체크합니다.

병합 대신 재배치
의미: ‘병합(Merge)’이 두 갈래 길을 하나로 합치는 것이라면, ‘재배치(Rebase)’는 내가 작업한 내용을 팀원이 작업해둔 최신 코드 끝으로 떼어내서 다시 붙이는 작업입니다.
장점: 히스토리가 갈래길 없이 일직선으로 남아서 보기에 깔끔해집니다.
주의사항 (푸시되지 않은 변경 사항 확인): 아직 서버에 올리지 않은 내 작업물이 있을 때만 써야 안전합니다. 이미 서버에 올린 내용을 재배치하면 팀원들의 히스토리가 다 꼬이는 일 발생할 수 있습니다.

커밋/머지 전 체크리스트

안전한 병합을 위한 4단계
빌드 및 실행 후 게임플레이 잘되는지 확인하기
언리얼 에디터 종료 후 소스트리 F5 새로고침
변경사항 꼼꼼히 읽어보기
머지 직전에 반드시 Fetch/Pull 하기

TIL(Today I Learned), 2026-03-17

This post is licensed under CC BY 4.0 by the author.