알아두면 정말 유용한 유니티 텍스쳐 압축
프로젝트를 빌드하고 게임을 실행한 지 몇 분 지나지 않아 크래시가 났다. 프로파일러를 열어 메모리 점유율을 들여다보니 답답한 장면이 펼쳐졌다. 수백 MB를 먹어치우는 정체불명의 데이터. 처음엔 메시 정보 때문인 줄 알았는데, 범인은 따로 있었다. 바로 텍스쳐였다.
당시 나는 압축에 대해 제대로 이해하지 못했다. 이미지 파일이 필요하면 그냥 넣으면 되는 거라 생각했다. 하지만 게임 메모리와 일반적인 이미지는 완전히 다르게 작동한다. 이 차이를 모르면 나처럼 같은 실수를 반복하게 된다.
왜 이렇게 메모리를 많이 차지할까
포토샵에서 1024×1024 PNG를 저장하면 용량은 보통 1MB 정도다. 하지만 유니티에서 임포트해서 게임이 실행되는 순간, 상황이 달라진다. GPU에서 사용할 때는 원본 해상도 그대로를 메모리에 올려야 하기 때문이다. 1024×1024를 RGB 채널에 각 8비트씩(총 32비트)로 저장하면 약 4MB가 된다. PNG는 저장 용량을 줄이기 위한 압축이고, GPU가 필요한 건 다른 형태의 압축이다.
PNG나 JPG는 처음부터 끝까지 순차적으로 읽지만, 게임의 셰이더는 특정 좌표(UV)에 즉시 접근해야 한다. 이를 ‘랜덤 액세스’라고 하는데, 이 때문에 전용 압축 방식이 필요하다. 모든 블록이 같은 크기여야만 원하는 위치에 바로 도달할 수 있기 때문이다.
게다가 모바일에선 메모리가 더 제한적이다. 처음엔 각 이미지가 크지 않다고 생각했는데, 누적되면 돌이킬 수 없는 수준의 메모리 압박이 생긴다.
압축의 원리, 간단히 말하면
압축은 블록 단위로 진행된다. 전체 이미지를 4×4 픽셀 블록으로 잘게 쪼갠 후, 각 블록마다 핵심 정보만 뽑아 저장한다.
예를 들어 한 블록이 주로 빨강과 검은색 두 가지라면, 두 색상의 RGB 값만 저장한 뒤 각 픽셀이 어느 색에 가까운지를 인덱스로 표시하면 된다. 그러면 한 픽셀당 4비트만 필요해진다. 원래 32비트에서 4비트로 줄어드는 셈이다.
다만 블록 내 색상 변화가 많을수록 품질이 떨어진다. 3가지 이상 완전히 다른 색이 한 블록에 들어가면 실제로는 없는 색깔이 튀어나올 수도 있다.
| 상황 | 압축 효율 | 품질 |
|---|---|---|
| 단색 또는 2색상 | 매우 높음 | 우수 |
| 3~4색상 | 높음 | 양호 |
| 5개 이상 + 복잡한 그라데이션 | 낮음 | 저하 |
포맷 선택, 어떤 걸 써야 할까
DXT (Direct3D Texture Compression)
PC와 콘솔에서 오래 사용해온 표준 포맷이다. 블록당 64~128비트를 사용하며 색상 압축이 단순하다. DXT1은 투명도가 없는 경우, DXT5는 알파 채널까지 지원한다.
호환성이 뛰어나지만 색상이 복잡한 이미지에선 블록 경계가 눈에 띈다는 게 단점이다.
PVRTC (PowerVR Texture Compression)
애플이 아이폰에서 사용하던 포맷이다. DXT처럼 작동하되 블록 경계를 흐릿하게 처리해 시각적으로 더 부드럽다. 다만 정사각형 해상도(512, 256, 128 같은 2의 거듭제곱)만 지원한다.
UI 요소를 압축할 땐 피하는 게 낫다. 텍스트나 선이 흐릿해질 수 있기 때문이다.
ETC (Ericsson Texture Compression)
안드로이드에서 널리 지원하는 포맷이다. 흥미로운 점은 사람의 눈이 명도 변화에는 민감하지만 색상 변화에는 둔감하다는 특성을 이용한다는 것. 기본 색상은 저해상도로, 밝기 정보는 고해상도로 유지하는 방식이다.
만화풍이나 색상이 명확하게 구분되는 이미지에선 예상 밖의 색이 나타날 수 있다. ETC2는 더 나은 품질을 제공한다.
ASTC (Adaptive Scalable Texture Compression) ← 이게 정답이다
블록 크기를 선택할 수 있다는 게 핵심이다. 알베도처럼 세밀한 디테일이 필요한 곳은 4×4, 파티클이나 이펙트처럼 대략적인 표현만 필요한 곳은 12×12으로 조정한다. 같은 용량으로도 퀄리티를 훨씬 잘 조절할 수 있다.
ASTC로 바꾼 후 정말 놀랐다. 노멀맵의 경우 341KB에서 85KB로 줄어들었다. 알베도도 비슷한 절감 효과를 봤다.
| 포맷 | 최적 용도 | 해상도 제약 | 품질 |
|---|---|---|---|
| DXT | PC/콘솔 | 없음 | 중상 |
| PVRTC | 구 iOS | 2의 거듭제곱만 | 중상 |
| ETC | 안드로이드 | 없음 | 중 (ETC2는 중상) |
| ASTC | 현대 모바일 | 없음 | 상 |
ASTC를 선택한 이유
프로파일링 결과를 본 후 가장 먼저 든 생각은 이것이었다: 이미지 데이터를 줄여야 한다.
그럼 어떻게 할까. 세 가지 방법이 있다.
- 해상도 자체를 낮춘다 (256×256으로 다운샘플링 등)
- 개수를 줄인다 (아트팀과 협의)
- 압축 포맷과 압축률을 최적화한다
1, 2번은 아트팀의 동의가 필요했다. 당시 프로젝트는 모바일 게임이었고 시각 퀄리티도 중요했다. 그래서 3번을 먼저 시도했다.
처음엔 ETC2를 사용 중이었다. 그다음 ASTC로 바꿔보자는 제안이 나왔다. 당시 가장 큰 걱정은 호환성이었다. 구형 기기에서 ASTC를 지원하지 않을 수 있다는 생각 때문이었다. 하지만 확인해보니 2023년 기준으로 안드로이드의 77% 이상이 지원하고 있었다. 우리 게임의 타겟(동아시아, 북미)이라면 충분히 괜찮은 수준이었다.
결정을 내리고 ASTC 4×4로 모든 알베도와 노멀 이미지를 압축했다. 파티클은 12×12으로 좀 더 공격적으로 압축했다. 결과는:
- 전체 메모리: 약 600MB → 250MB (58% 감소)
- 크래시 빈도: 거의 없어짐
- 로딩 시간: 약간 단축
- 시각적 품질: 게임플레이에 영향 없음 (거의 구분 불가)
아트팀의 반발도 없었다. 최종 게임을 봐도 압축 전후 차이를 느낄 수 없었기 때문이다.
압축률 조정 시 체크리스트
블록 사이즈를 줄일수록(4×4 < 6×6 < 8×8 < 12×12) 용량은 더 줄어들지만 품질도 떨어진다. 각 이미지별로 최적의 지점을 찾아야 한다.
- 알베도/디퓨즈 → ASTC 4×4 시작 (가장 보이는 부분)
- 노멀맵 → ASTC 6×6 시작 (명도 변화가 중요)
- 파티클/UI → ASTC 8×12 또는 12×12 (낮은 해상도)
- 마스크/ID → 8비트 그레이스케일 고려
- 압축 후 실기기에서 직접 확인 (에디터와 기기 렌더링이 다를 수 있음)
프로그래머와 아트팀이 함께 결정하는 게 중요하다. 프로그래머만 절감을 외치고 아티스트가 품질 저하를 겪는 상황을 피해야 한다.
마치며
압축은 단순히 용량을 줄이는 게 아니라, 제한된 자원 속에서 최고의 시각 경험을 만드는 균형이다. 무작정 해상도를 높이거나 압축을 피했다면 메모리 크래시로 게임 자체가 불가능했을 것이다. ASTC 덕분에 250MB의 여유 공간이 생겼고, 그 덕분에 다른 최적화에 더 집중할 수 있었다. 특히 모바일 게임을 만든다면, 이런 압축 포맷을 아는 것은 생존 스킬이나 다름없다.
자주 묻는 질문
Q. PNG나 JPG로 저장해야 하나요, 아니면 처음부터 압축된 포맷으로 작업해야 하나요?
원본 파일 형식은 상관없습니다. 유니티에서 임포트할 때 자동으로 선택한 포맷으로 변환됩니다. 아트팀은 편한 형식(PSD, PNG 등)으로 작업하면 됩니다.
Q. ASTC가 안 보이는 블록 경계가 생기진 않나요?
4×4 블록은 거의 눈에 띄지 않습니다. 6×6부터는 세심하게 확인이 필요하고, 12×12는 파티클 같은 저해상도에만 권장합니다. 항상 실기기에서 직접 게임을 플레이하며 확인하세요.
Q. 구형 기기는 ASTC를 지원하지 않는데, 폴백은 어떻게 하나요?
유니티에서 플랫폼별로 다른 포맷을 빌드할 수 있습니다. iOS는 PVRTC, 안드로이드는 ETC2/ASTC 혼용, PC는 DXT 같이 설정하면 됩니다.
Q. 해상도는 줄이지 않으면서 메모리만 줄 수 있나요?
네, 압축 포맷 선택과 블록 사이즈 조정만으로도 상당히 줄 수 있습니다. 다만 한계가 있으므로 최종적으로는 해상도 최적화와 함께 진행하는 게 낫습니다.
Q. 크런치 압축은 뭔가요?
추가 압축 단계입니다. 디스크 용량을 더 아낄 수 있지만 로딩 시간이 늘어납니다. 빌드 용량이 문제라면 고려할 만한데, 로딩 속도가 중요하면 피하는 게 좋습니다.
참고 자료
유니티 TIPS | 효율적인 텍스처 압축 이해하기 & 꿀팁