게임 빌드 용량 최적화: 2GB에서 500MB로 줄이는 실전 다이어트 방법

빌드 용량은 감으로 줄이지 말고 파일 단위로 계측해야 합니다. 먼저 용량 상위 항목을 분류한 뒤 텍스처, 오디오, 중복 에셋, 플랫폼별 불필요 파일을 순서대로 제거하면 품질 저하를 통제하면서 큰 폭으로 줄일 수 있습니다. 목표는 ‘압축률’이 아니라 다운로드 크기와 설치 후 디스크 사용량을 각각 예산 안에 넣는 것입니다.

게임 빌드 용량은 왜 빠르게 커지는가?

빌드가 2GB에 도달하는 가장 흔한 이유는 코드가 아니라 원본에 가까운 대용량 콘텐츠입니다. 특히 고해상도 텍스처, PCM 또는 높은 비트레이트의 오디오, 중복 참조된 에셋 번들, 런타임에 사용하지 않는 플랫폼 리소스가 대부분을 차지합니다.

빌드 크기는 다음처럼 분해해 봐야 합니다.

S_{build}=S_{texture}+S_{audio}+S_{mesh}+S_{video}+S_{bundle}+S_{runtime}+S_{duplicate}

여기서 중요한 점은 압축 파일의 크기만 보지 않는 것입니다. 모바일 환경에서는 APK/AAB 다운로드 크기, 설치 후 앱 크기, 첫 실행 시 내려받는 콘텐츠 크기를 함께 확인해야 운영 리스크를 줄일 수 있습니다.

점검 대상	용량이 커지는 원인	우선 대응
텍스처	4K 원본, 무압축 포맷, 밉맵 남용	최대 해상도와 플랫폼 압축 포맷 조정
오디오	WAV/PCM, 긴 BGM, 스테레오 음성	Vorbis/AAC 적용, 샘플레이트·채널 조정
에셋 번들	중복 의존성, 잘못된 번들 분할	공유 에셋 분리, 중복 분석
동영상	높은 비트레이트와 해상도	재인코딩, 스트리밍 여부 검토
런타임 파일	미사용 플러그인, 디버그 심볼	플랫폼별 플러그인과 심볼 분리

빌드 리포트에서 텍스처와 오디오가 용량 상위를 차지하는 예시

빌드 용량 최적화는 어떻게 시작할까?

1. 빌드 리포트로 상위 파일을 먼저 고정한다

Unity라면 BuildReport와 Editor.log를 활용해 빌드 결과를 파일별로 수집합니다. Unreal Engine이라면 UnrealPak의 목록과 패키징 로그를 사용해 .pak 내부 파일을 확인합니다. 엔진과 관계없이 ‘상위 20개 파일이 전체의 몇 퍼센트를 차지하는가’를 먼저 계산하세요.

using UnityEditor;
using UnityEditor.Build.Reporting;

public static class BuildSizeReporter
{
    [MenuItem("Build/Report Size")]
    public static void ReportSize()
    {
        BuildReport report = BuildPipeline.BuildPlayer(
            new[] { "Assets/Scenes/Boot.unity" },
            "Builds/Android",
            BuildTarget.Android,
            BuildOptions.None);

        Debug.Log($"Build size: {report.summary.totalSize / (1024f * 1024f):F1} MB");
    }
}

이 단계에서 바로 압축 설정을 바꾸지 마세요. 예를 들어 1.2GB가 텍스처에 집중되어 있다면 코드 스트리핑으로는 목표를 달성할 수 없습니다. 상위 항목과 담당 에셋 경로를 표로 남기면 이후 변경의 효과도 비교하기 쉽습니다.

2. 텍스처와 오디오에 용량 예산을 적용한다

대형 텍스처는 아트 품질을 해치지 않는 범위에서 최대 해상도를 내리고 플랫폼 전용 GPU 압축을 적용합니다. Android는 ASTC 또는 ETC2, iOS는 ASTC를 우선 검토할 수 있습니다. 알파 채널이 필요 없는 이미지에 RGBA 포맷을 강제하지 않는 것도 기본 점검 항목입니다.

오디오는 효과음과 음성, BGM을 같은 기준으로 처리하면 안 됩니다. 짧은 효과음은 로딩 지연과 반복 재생을 고려하고 긴 BGM은 스트리밍과 비트레이트 절감 효과를 비교해야 합니다. 음성 파일은 실제 소스 품질이 허용한다면 모노 변환과 44.1kHz 이하 샘플레이트를 검토할 수 있습니다.

에셋 유형	확인 항목	검증 방법
UI 텍스처	밉맵 필요 여부, 알파 채널	화면 확대와 메모리 프로파일링
3D 텍스처	최대 해상도, ASTC 블록 크기	기기별 품질 비교 스크린샷
효과음	모노 변환, 압축 품질	반복 재생 시 잡음 확인
BGM	스트리밍, 비트레이트	전환 구간과 첫 재생 지연 확인

플랫폼별 텍스처 압축 설정과 실제 기기 품질을 비교하는 화면

3. 중복 에셋과 미사용 파일을 제거한다

에셋 번들 또는 Addressables를 쓸 때 가장 큰 함정은 여러 번들이 공통 의존성을 각각 포함하는 경우입니다. 공통 머티리얼, 셰이더, 폰트, 캐릭터 공용 텍스처는 공유 그룹으로 분리하고 의존성 분석 결과로 중복 포함 여부를 확인합니다.

또한 다음 항목은 빌드 직전에 자동 점검하는 편이 좋습니다.

릴리스에 쓰지 않는 씬, 테스트 데이터, 구형 언어 리소스를 제외합니다.
대상 플랫폼과 무관한 네이티브 플러그인을 비활성화합니다.
개발용 로그, 디버그 심볼, 샘플 에셋이 배포물에 포함되지 않는지 확인합니다.
의도치 않게 Resources 폴더에 들어간 대형 파일을 찾아 필요한 경우 Addressables나 원격 콘텐츠로 옮깁니다.

flowchart TD
    A[릴리스 빌드 생성] --> B[파일별 용량 리포트 수집]
    B --> C{예산 초과?}
    C -- 아니오 --> D[회귀 검증 후 배포]
    C -- 예 --> E[상위 에셋과 중복 의존성 분석]
    E --> F[압축·해상도·번들 구성 조정]
    F --> G[실기기 품질과 로딩 시간 테스트]
    G --> B

2GB에서 500MB로 줄일 때 권장하는 우선순위는?

효율이 큰 작업부터 진행하면 되돌림 비용이 적습니다. 실제 프로젝트마다 비율은 다르지만 아래 순서는 재현성과 검증 편의성이 좋습니다.

빌드 리포트에서 상위 파일과 중복 파일을 식별합니다.
텍스처 해상도, 밉맵, 알파 채널, 플랫폼 압축 포맷을 조정합니다.
오디오를 유형별로 재인코딩하고 긴 콘텐츠의 스트리밍 방식을 검증합니다.
번들 의존성을 정리하고 공유 에셋의 중복 패키징을 제거합니다.
미사용 플러그인, 샘플, 테스트 리소스, 디버그 산출물을 제외합니다.
저사양 실기기에서 그래픽 품질, 메모리, 로딩 시간, 크래시를 회귀 테스트합니다.

500MB 목표를 맞추기 위해 모든 텍스처를 과도하게 낮추거나 오디오 품질을 일괄 하향하면 플레이 경험이 무너질 수 있습니다. 용량 절감률과 품질 영향, 로딩 시간 변화를 변경 단위마다 기록하는 것이 안전합니다.

빌드 용량 회귀는 CI에서 어떻게 막을까?

한 번 줄인 빌드가 다음 콘텐츠 업데이트에서 다시 커지는 일이 더 흔합니다. CI에서 기준 빌드와 현재 빌드의 파일 목록을 비교하고 총량과 핵심 디렉터리별 예산을 초과하면 경고 또는 실패 처리하세요.

예시는 다음과 같은 정책으로 충분합니다.

전체 다운로드 산출물은 500MB 이하를 유지합니다.
단일 신규 파일이 50MB를 넘으면 PR에 원인과 승인 사유를 남깁니다.
텍스처와 오디오 디렉터리는 이전 기준 대비 5% 이상 증가하면 리포트를 생성합니다.
릴리스 후보 빌드는 실제 기기에 설치해 설치 후 용량과 첫 실행 시간을 기록합니다.

CI 검증은 개발자의 작업을 막기 위한 장치가 아니라 어느 변경에서 용량이 늘었는지 빠르게 찾는 관측 장치입니다. 파일 경로, 이전 크기, 현재 크기, 증감률을 PR 댓글이나 빌드 아티팩트로 남기면 원인 추적 시간이 크게 줄어듭니다.

자주 묻는 질문 (FAQ)

압축률이 높으면 항상 빌드 용량 최적화에 유리한가?

아닙니다. 다운로드 파일은 줄어도 설치 후 압축 해제 크기나 런타임 메모리가 늘 수 있습니다. 다운로드 크기, 설치 크기, 메모리를 분리해 측정해야 합니다.

텍스처를 전부 ASTC로 바꾸면 되는가?

대상 기기 지원 범위와 ASTC 블록 크기, 품질을 함께 확인해야 합니다. 지원이 제한된 기기까지 배포한다면 ETC2 등 대체 포맷과의 호환성도 검증해야 합니다.

Addressables를 도입하면 앱 용량이 자동으로 줄어드는가?

자동으로 줄지 않습니다. 초기 설치물에서 원격 다운로드로 옮길 수는 있지만 중복 의존성을 관리하지 못하면 총 콘텐츠 용량은 오히려 커질 수 있습니다.

정리

빌드 사이즈 다이어트의 핵심은 큰 파일을 찾고 플랫폼에 맞게 압축하며 중복 패키징과 미사용 콘텐츠를 제거한 뒤 CI로 회귀를 막는 것입니다. 2GB에서 500MB로 줄이는 목표는 단일 옵션 변경이 아니라 계측과 품질 검증을 반복하는 운영 프로세스로 달성해야 안정적으로 유지됩니다.