Draco 지오메트리 압축

한 줄 요약

Google이 개발한 3D 메쉬 지오메트리 압축 라이브러리. 정점(vertex)과 인덱스 데이터를 압축하여 파일 크기를 줄인다. KTX2가 텍스처를 압축한다면, Draco는 형상(geometry) 자체를 압축한다 — 둘은 경쟁이 아니라 상호 보완 관계다.

Draco가 압축하는 것

3D 메쉬는 크게 두 가지 데이터로 구성된다:

정점 데이터(Vertex Data): 각 정점의 위치(x, y, z), 법선 벡터, UV 좌표(텍스처 매핑용) 등. 정점 하나당 수십 바이트를 차지한다.

인덱스 데이터(Index Data): 어떤 정점 3개를 연결하여 삼각형을 만드는지를 정의하는 데이터.

Draco는 이 두 가지를 양자화(Quantization)와 엔트로피 부호화(Entropy Encoding)로 압축한다.

양자화 (Quantization)

정점 위치를 부동소수점(float32)으로 저장하면 정밀도가 높지만, 그만큼 데이터가 크다. 양자화는 이 부동소수점 값을 더 적은 비트 수의 정수로 변환한다.

예를 들어, 위치를 32비트 float 대신 11비트 정수로 양자화하면, 정밀도는 다소 떨어지지만 데이터 크기가 크게 줄어든다. 양자화 비트 수가 핵심 파라미터다 — 비트 수가 높을수록 정밀하지만 압축률이 낮고, 비트 수가 낮을수록 압축률은 높지만 형상이 뭉개질 수 있다.

엔트로피 부호화 (Entropy Encoding)

양자화된 데이터에서 반복 패턴을 찾아 더 적은 비트로 표현한다. ZIP 압축과 유사한 원리다. 인접한 정점들의 값이 비슷한 경우(평평한 면 등) 압축률이 높아진다.

glTF에서의 사용

Draco는 glTF 2.0의 공식 확장인 KHR_draco_mesh_compression을 통해 glb 파일 내에 적용된다. Cesium.js는 이 확장을 네이티브로 지원하므로, Draco로 압축된 glb를 별도 처리 없이 바로 로드하고 디코딩할 수 있다.

디코딩은 WebAssembly 기반 디코더로 클라이언트(브라우저)에서 수행된다. 서버는 압축된 파일만 전송하면 되므로 네트워크 전송량이 줄고, 클라이언트에서 빠르게 디코딩하여 GPU에 올린다.

압축률과 품질의 트레이드오프

Draco 압축에서 가장 어려운 부분은 "얼마나 압축할 것인가"의 결정이다.

테스트 단계에서는 양자화 비트를 낮추고 공격적으로 압축하면 원본 대비 최대 95%까지 파일 크기가 감소하는 것을 확인했다. 그러나 이 수준에서는 모델의 모서리가 뭉개지거나, 곡면이 각져 보이는 등 시각적 품질 저하가 눈에 띄었다.

반대로 압축을 너무 약하게 하면 파일 크기 절감 효과가 미미하여 압축하는 의미가 줄어든다.

실무에서는 시각적 품질과 파일 크기 사이의 중간 지점을 찾는 것이 핵심이었다. 최종적으로 상용 서비스에서는 65~70% 용량 감소 수준을 선택했다. 이 지점에서는 육안으로 품질 차이를 식별하기 어려우면서도 유의미한 용량 절감 효과가 있었다.

이 트레이드오프는 모델의 특성에 따라 달라진다. 곡면이 많은 모델(파이프, 원통)은 양자화에 민감하고, 직각 위주의 모델(벽, 슬래브)은 공격적 압축에도 시각적 변화가 적다.

KTX2와의 관계: 상호 보완

Draco와 KTX2는 glb 파일 내에서 서로 다른 데이터를 압축한다:

두 압축은 독립적으로 적용된다 — 하나만 적용해도 되고, 둘 다 적용해도 된다. 둘 다 적용하면 지오메트리와 텍스처 모두 최적화되어 파일 크기와 렌더링 성능이 동시에 개선된다.

이 경험에서 추출한 원칙

1. 최대 압축률이 최적 압축률은 아니다. 95% 압축이 가능하다고 해서 그게 정답은 아니다. 상용 서비스에서는 사용자가 품질 저하를 느끼지 않는 범위 내에서 최대한 압축하는 것이 목표이며, 이 지점은 반복적인 테스트를 통해서만 찾을 수 있다.

2. 지오메트리 압축과 텍스처 압축은 별개의 문제다. 둘은 서로 다른 데이터를 대상으로 하며, 서로 다른 원리로 작동하고, 서로 다른 트레이드오프를 가진다. 하나를 이해했다고 다른 하나를 이해한 것이 아니다.