on
ai 주식투자
- Get link
- X
- Other Apps
목표: 게임이 개발에서 실제 배포로 나아가기 위해서는, 코드보다 중요한 세 가지 역량 — 빌드(Build), 프로파일링(Profiling), 최적화(Optimization) — 를 이해해야 합니다. 본 장에서는 유니티 프로젝트를 효율적으로 빌드하고, 성능 병목을 분석하며, 실무 수준의 최적화를 수행하는 방법을 다룹니다.
유니티의 빌드 과정은 단순히 “게임 실행 파일을 만드는 단계”가 아닙니다. 프로젝트 설정, 플랫폼별 리소스 변환, 압축, 코드 스트리핑 등 다양한 프로세스가 통합되어 있습니다.
File → Build Settings에서 다음을 설정합니다:
| 플랫폼 | 특징 | 최적화 포인트 |
|---|---|---|
| PC/콘솔 | 고해상도, 고성능 GPU | 텍스처 스트리밍, LOD |
| 모바일 | 메모리 제약, 저전력 | 드로우콜 최소화, 압축 포맷 사용 |
| WebGL | 브라우저 기반 | 빌드 크기 축소, HTTP 압축 |
using UnityEditor; using UnityEditor.Build.Reporting;
public class BuildAutomation {
[MenuItem("Build/Windows")]
public static void BuildWindows() {
string path = "Builds/Windows/MyGame.exe";
BuildReport report = BuildPipeline.BuildPlayer(
EditorBuildSettings.scenes,
path,
BuildTarget.StandaloneWindows64,
BuildOptions.None
);
Debug.Log("빌드 완료: " + report.summary.result);
}
}
이 방식은 CI/CD 환경(GitHub Actions, Jenkins 등)에서도 자동화 빌드가 가능합니다.
프로파일링은 최적화의 출발점입니다. “느리다”라는 감각이 아닌, 숫자 기반의 병목 분석이 진짜 성능 개선을 이끕니다.
using UnityEngine; using Unity.Profiling;
public class PerformanceTest : MonoBehaviour {
static readonly ProfilerMarker marker = new ProfilerMarker("CustomLogic");
void Update() {
using (marker.Auto()) {
// 특정 로직 측정 구간
}
}
}
ProfilerMarker를 사용하면 커스텀 코드 구간의 실행 시간을 추적할 수 있습니다.
렌더링 과정을 단계별로 시각화하여, 드로우콜(Draw Call)과 오버드로우(Overdraw) 문제를 찾는 데 사용됩니다.
최적화는 “빠르게 만드는 것”이 아니라, 필요한 만큼만 계산하게 하는 것입니다. 코드, 그래픽, 메모리, 로드 타임 등 다양한 영역별로 접근해야 합니다.
public class ObjectPool : MonoBehaviour { public GameObject prefab; private Queue pool = new(); public GameObject Get() { if (pool.Count > 0) return pool.Dequeue(); return Instantiate(prefab); } public void Release(GameObject obj) { obj.SetActive(false); pool.Enqueue(obj); } } 최적화는 반복적인 사이클입니다. “느리다”는 감각적 피드백이 아닌, 측정 가능한 수치 기반 프로세스를 구축해야 합니다.
이 과정을 “한 번” 하는 것이 아니라, 빌드 주기마다 자동 검증하도록 CI에 포함하는 것이 이상적입니다.
성능만큼 중요한 것이 안정성입니다. 게임은 끊기지 않아야 하며, 예측 가능한 결과를 보여야 합니다.
void OnApplicationQuit() { Debug.Log("프로세스 종료 - 세션 시간: " + Time.realtimeSinceStartup); } 빌드는 결과물이 아니라 “출발점”이고, 프로파일링은 “측정의 습관”이며, 최적화는 “설계의 철학”입니다. 빠른 코드를 쓰는 것보다, 측정 가능한 성능 구조를 설계하는 것이 더 중요합니다.
결국 최적화는 기술이 아니라 ‘사고의 효율성’입니다.
Comments
Post a Comment