PNG 파일은 작은데 게임에서 텍스처 메모리를 많이 차지하는 경우가 있습니다. 파일 압축과 GPU가 읽는 텍스처 포맷이 다르기 때문입니다. 원본 파일을 더 작게 저장하는 것만으로 실행 중 메모리가 줄지는 않습니다.
그래서 텍스처를 줄일 때는 파일 탐색기보다 Unity의 플랫폼별 Import Settings부터 봅니다. 어떤 해상도와 포맷으로 빌드에 들어가는지 알아야 계산이 맞습니다.
1024×1024 한 장은 얼마일까
비압축 RGBA32는 빨강·초록·파랑·알파 각각 8비트, 한 픽셀에 4바이트입니다. 1024 × 1024 × 4 = 4,194,304바이트, 즉 4MiB입니다. RGB만 각각 8비트라면 합계는 24비트이며, RGBA32와 혼동하면 안 됩니다.
아래 값은 1024×1024, 기본 밉 레벨만 있는 텍스처의 이론적 데이터 크기입니다. 측정 결과나 앱 전체 메모리가 아닙니다.
| 포맷 | 계산 | 크기 |
|---|---|---|
| RGBA32 | 1024 × 1024 × 4바이트 | 4MiB |
| ASTC 4×4 | 256 × 256블록 × 16바이트 | 1MiB |
| ASTC 8×8 | 128 × 128블록 × 16바이트 | 0.25MiB |
ASTC는 블록 하나가 128비트입니다. 블록 크기를 키우면 같은 16바이트로 더 넓은 영역을 표현하므로 용량이 줄고, 세부 표현은 손실될 수 있습니다. 임의의 해상도에서는 가로·세로 블록 개수를 각각 올림해서 계산합니다.
완전한 밉 체인은 큰 텍스처에서 기본 레벨 대비 대략 3분의 1 정도를 더 사용합니다. 압축 블록의 최소 크기와 작은 밉의 패딩 때문에 정확히 같은 비율은 아닙니다. 런타임 CPU 복사본, 드라이버 정렬, 스트리밍 상태도 실제 메모리에 영향을 줍니다.
ASTC를 고르기 전에 기기부터 본다
ASTC는 블록 크기를 조절할 수 있어 편리하지만 모든 대상 기기와 그래픽 API에서 같은 방식으로 지원되는 것은 아닙니다. 지원하지 않는 포맷이 런타임에 비압축으로 풀리면 예상보다 메모리가 늘 수 있습니다. 플랫폼별 포맷 문서와 실제 대상 기기에서 선택된 포맷을 함께 확인해야 합니다.
UI 아이콘과 흐릿한 파티클에 같은 설정을 적용할 이유도 없습니다. 얇은 외곽선이나 알파 경계는 큰 블록에서 쉽게 무너집니다. 노말맵은 일반 색상 이미지와 달리 방향 데이터이므로 Normal Map 타입과 해당 셰이더의 디코딩 경로를 맞춰야 합니다.
한 장부터 비교하면 원인이 보인다
먼저 문제가 잘 보이는 텍스처 하나를 고릅니다. 카메라 거리와 화면 해상도를 고정하고, Max Size를 그대로 둔 채 압축 포맷이나 블록 크기만 바꿉니다. 확대 화면뿐 아니라 실제 게임에서 보이는 크기로도 비교합니다. 멀리 있는 배경의 미세한 손실과 버튼 글자의 깨짐은 받아들일 수 있는 범위가 다릅니다.
그다음 대상 기기 빌드에서 로드된 텍스처의 크기를 확인합니다. Import Settings의 예상값만 보고 완료하지 않습니다. Read/Write가 필요 없이 켜져 있는지도 봅니다. CPU에서 픽셀을 읽거나 수정하지 않는다면 복사본을 유지할 이유가 없는 경우가 많습니다.
포맷을 바꿨는데도 메모리가 줄지 않았다면 중복 로드, 아틀라스에 남은 미사용 이미지, 압축 미지원에 따른 폴백을 따로 조사합니다. 이미지를 흐리게 만드는 것보다 로드하지 않아도 될 에셋을 찾는 편이 나을 때도 있습니다.
수정 기록과 참고
2026-09-22: RGB와 RGBA의 비트 수를 바로잡고, 측정 조건이 없던 절감 수치를 이론 계산 예제로 교체했습니다.