[React] NIfTI 압축의 두 갈래.nii.gz vs Zarr

Format Deep Dive

NIfTI 압축의 두 갈래
.nii.gz vs Zarr

gzip 단일 파일 압축과 청크 기반 Zarr 포맷의 구조적 차이부터, NIfTI 데이터에 적용했을 때 웹 뷰어에서 발생하는 문제점과 기술 적용 방식까지 완전 분석합니다.

gzip vs Zarr 청크 기반 스트리밍 HTTP Range Request 멀티해상도 피라미드 NIfTI-Zarr (nii.zarr) 웹 뷰어 적용

01 · Background

왜 지금 이 비교가 중요한가

NIfTI(.nii.gz)는 신경영상 연구의 표준 포맷으로, 수십 년간 단순하고 안정적이었습니다. 하지만 AI 모델 출력물, 대형 뇌영상, 고해상도 의료 볼륨이 일상화되면서 단일 파일 gzip 압축 방식의 한계가 드러나고 있습니다. 특히 웹 브라우저에서 대용량 볼륨을 실시간으로 렌더링하는 시나리오에서, .nii.gz는 구조적으로 불리합니다.

Zarr는 기후·천문·유전체 분야에서 페타바이트급 배열 데이터를 클라우드로 서빙하던 기술입니다. 최근 신경영상 커뮤니티가 이를 NIfTI에 접목한 NIfTI-Zarr(nii.zarr) 스펙을 제안하면서 웹 의료 영상 뷰어와의 접점이 생겼습니다.

1개

.nii.gz 파일 단위

N개

Zarr 독립 청크 수

전체

.gz 최소 다운로드

1슬라이스

Zarr 최소 다운로드

02 · .nii.gz 구조

gzip 압축의 동작 방식

gzip은 스트림 기반 압축 알고리즘입니다. 데이터를 순서대로 읽으면서 반복 패턴을 LZ77 알고리즘으로 압축합니다. .nii.gz는 NIfTI 헤더 + 볼륨 전체를 하나의 gzip 스트림으로 묶은 단일 파일입니다.

✅

.nii.gz 장점

• 단일 파일 — 관리·배포·공유 간단
• 높은 압축률 (의료 데이터 3~5:1)
• 모든 NIfTI 도구 완벽 호환
• 순차 처리에 최적 (AI 학습 등)
• 구현 복잡도 낮음

❌

.nii.gz 단점

• 임의 접근 불가 — 전체 해제 필요
• 웹 스트리밍 불가 (gzip은 스트림)
• 병렬 처리 불가 (순차 의존)
• 멀티해상도 저장 불가
• 대용량 초기 로딩 수십 초

03 · Zarr 구조

Zarr의 청크 기반 아키텍처

Zarr는 N차원 배열을 독립적인 청크(chunk) 단위로 분할 저장하는 포맷입니다. 각 청크는 개별 파일(또는 객체)로 저장되고, 독립적으로 압축되어 있어 특정 청크만 HTTP 요청으로 가져올 수 있습니다. 디렉토리 기반 구조이며 JSON 메타데이터가 자기 서술적(self-describing)으로 포함됩니다.

✅

Zarr 장점

• 임의 접근 — 특정 청크만 HTTP GET
• 병렬 처리 — 청크 동시 fetch 가능
• 멀티해상도 피라미드 내장
• Progressive 렌더링 (청크 도착순)
• 클라우드(S3, GCS) 네이티브
• 정적 HTTP 서버만으로 서빙 가능
• 다양한 압축 알고리즘 선택

❌

Zarr 단점

• 파일 수 폭발 (수백~수천 개 청크)
• 기존 NIfTI 도구 미호환
• 변환(전처리) 파이프라인 필요
• 메타데이터 동기화 관리 필요
• 소형 볼륨에서는 오버헤드
• NIfTI qform/sform 저장 불표준

04 · 핵심 비교

.nii.gz vs Zarr — 항목별 대조

항목	.nii.gz	Zarr	웹 뷰어 영향
저장 단위	단일 파일	청크 디렉토리	Zarr가 슬라이스 단위 fetch 가능
임의 접근	불가	가능 (청크 단위)	Zarr만 현재 슬라이스 즉시 표시
압축 알고리즘	gzip 전용	gzip, zstd, blosc, lz4 등 선택	Zarr+blosc/zstd: 해제 속도 5~10×↑
압축 범위	파일 전체 단일 압축	청크별 독립 압축	필요한 청크만 해제, CPU 절약
멀티해상도	없음	피라미드 내장	Zarr: 저해상도 먼저 → 고해상도 순
병렬 fetch	불가	가능 (청크 독립)	여러 청크 동시 요청 가능
서버 요구사항	Range Request 지원 필요	정적 HTTP만으로 가능	Zarr: S3/CDN 직결 서빙 가능
첫 렌더 시간	전체 다운로드 후	해당 청크 도착 즉시	대용량에서 수십 초 vs 수 초 차이
도구 호환성	완벽 호환	전용 라이브러리	기존 NIfTI 파이프라인 수정 필요
파일 수	1개	수백~수천 개	파일시스템 관리 복잡도 증가
변환 필요	불필요	nii→zarr 전처리	서버 파이프라인 구성 필요

압축/해제 속도 비교 (1024×1024×300 볼륨 기준)

.nii.gz (gzip) 압축 해제

기준 1×

Zarr + gzip 청크

~1.5× 빠름

Zarr + zstd 청크

~3× 빠름

Zarr + Blosc/LZ4 청크

~8× 빠름

* 전체 볼륨 기준이 아닌 단일 슬라이스 해당 청크 해제 기준 / 실환경 차이 존재

05 · NIfTI + Zarr

NIfTI에 Zarr를 적용한다면 — NIfTI-Zarr

신경영상 커뮤니티는 두 포맷의 장점을 결합한 NIfTI-Zarr(nii.zarr) 스펙을 제안했습니다. OME-Zarr를 기반으로 하되 NIfTI 헤더(qform/sform 등)를 Zarr 내부에 raw bytes로 보존하여, 기존 NIfTI 메타데이터와 Zarr의 청크 접근을 동시에 지원합니다.

📐 NIfTI-Zarr는 OME-Zarr 완전 호환입니다. 기존 OME-Zarr 뷰어(Neuroglancer, napari 등)에서 그대로 열리며, NIfTI 헤더는 별도 보존되어 nibabel로도 읽을 수 있습니다. nifti-zarr PyPI 패키지(nii2zarr)로 변환 가능합니다.

청크 크기 선택 전략

청크 크기는 Zarr에서 가장 중요한 성능 결정 요소입니다. 너무 작으면 HTTP 요청 수가 폭발하고, 너무 크면 gzip과 다를 바 없어집니다.

청크 크기	HTTP 요청 수 (슬라이스 1장)	장점	단점	추천 시나리오
16×16×16	~16개 요청	세밀한 부분 접근	요청 수 폭발, 오버헤드 큼	비권장
64×64×64	~4개 요청	균형적 성능	일부 불필요 데이터 포함	3D 뷰어 권장
1×512×512	1개 요청	슬라이스 단위 완벽 접근	Z방향 접근 시 다수 요청	2D MPR 권장
512×512×1	1개 요청	Axial 뷰 최적	Sagittal/Coronal 비효율	Axial 전용

06 · 기술 적용 방식

웹 뷰어에서의 Zarr 적용 아키텍처

Cornerstone3D + NIfTI-Zarr 조합에서 데이터가 브라우저에 도달하는 전체 흐름입니다. 기존 .nii.gz 방식과 달리 각 슬라이스 요청이 독립적인 HTTP 청크 fetch로 대체됩니다.

1

서버: .nii.gz → .nii.zarr 변환 (전처리)

AI 추론 완료 후 또는 저장 시점에 nii2zarr 도구로 변환합니다. 멀티해상도 피라미드 생성 + 64×64×64 청크 분할 + zstd 압축을 자동으로 수행합니다. S3, GCS, Nginx 등 정적 서버에 업로드합니다.

nii2zarr --chunk 64 --levels 4 --compressor blosc brain.nii.gz brain.nii.zarr/

2

브라우저: zarr.json 메타데이터 fetch (1회)

볼륨 shape, chunk 크기, 해상도 레벨, dtype, 압축 알고리즘 정보를 JSON으로 가져옵니다. 이 단계에서 픽셀 데이터는 전혀 없습니다. 응답 크기 수 KB, 수십 ms 내 완료됩니다.

3

해상도 레벨 선택 (멀티해상도 활용)

첫 표시는 가장 낮은 해상도(level 3: 128×128×37)를 fetch합니다. 전체 볼륨을 수 KB~수십 KB로 표현하므로 거의 즉시 렌더링됩니다. 사용자가 줌인하거나 특정 슬라이스를 선택하면 해당 영역의 고해상도(level 0) 청크를 추가 fetch합니다.

4

현재 슬라이스 청크 병렬 fetch

뷰포트에 필요한 청크 좌표를 계산하고 해당 청크 파일들을 병렬 HTTP GET으로 요청합니다. 64×64×64 청크 기준으로 512×512 슬라이스는 약 4~8개 청크가 필요합니다. 청크 도착 즉시 해당 영역 렌더링을 업데이트합니다.

5

Prefetch (인접 슬라이스 청크)

현재 슬라이스 렌더링 완료 후 인접 슬라이스의 청크를 백그라운드에서 프리패치합니다. 스크롤 시 이미 캐시된 청크는 즉시 렌더링됩니다.

Cornerstone3D 커스텀 Image Loader 구현

Cornerstone3D에는 Zarr 공식 로더가 없으므로, 커스텀 ImageLoader를 구현해야 합니다.

// zarr-image-loader.ts — 커스텀 Zarr 청크 기반 Image Loader
import * as zarr from 'zarrita';  // 또는 zarr-js
import { imageLoader } from '@cornerstonejs/core';

let zarrStore: zarr.Array | null = null;

// 1. Zarr 스토어 초기화 (zarr.json 읽기)
export async function initZarrStore(url: string) {
  const store = new zarr.FetchStore(url);
  zarrStore = await zarr.open(store, { kind: 'array' });
}

// 2. 슬라이스 단위 ImageLoader 등록
export function zarritaImageLoader(imageId: string) {
  const sliceIndex = parseSliceIndex(imageId);  // zarr://url#150

  const promise = (async () => {
    // 해당 슬라이스의 청크만 fetch (zarrita가 자동으로 청크 좌표 계산)
    const sliceData = await zarr.get(zarrStore, [sliceIndex, null, null]);

    return {
      imageId,
      minPixelValue: min(sliceData),
      maxPixelValue: max(sliceData),
      rows: sliceData.shape[0],
      columns: sliceData.shape[1],
      getPixelData: () => new Float32Array(sliceData.data),
    };
  })();

  return { promise };
}

// 3. Cornerstone3D에 등록
imageLoader.registerImageLoader('zarr', zarritaImageLoader);

07 · 예상 문제점

Zarr 도입 시 예상되는 문제점

1

파일 수 폭발 — 스토리지 관리 복잡도 급증

1024×1024×300 볼륨을 64×64×64 청크로 분할하면 청크 수 = ceil(1024/64) × ceil(1024/64) × ceil(300/64) = 16 × 16 × 5 = 1,280개 파일. 멀티해상도 4레벨 포함 시 약 1,700개+. S3에서는 파일 수 과금이 없지만, 로컬 파일시스템에서는 inode 소진 위험이 있습니다.

대응: Zarr v3의 Sharding 기능으로 여러 청크를 하나의 shard 파일로 묶어 파일 수를 획기적으로 줄입니다. 또는 ZIP 기반 Zarr store(.ome.zarr.zip)로 단일 파일로 패키징합니다.

2

CORS 정책 — 청크 fetch 시 브라우저 차단

브라우저에서 다른 도메인의 Zarr 청크를 fetch하면 CORS 오류가 발생합니다. 정적 서버(S3, Nginx)에 반드시 CORS 헤더를 설정해야 합니다. 청크마다 preflight 요청이 발생할 수 있어 성능 저하가 생깁니다.

대응: 서버에 Access-Control-Allow-Origin: * + Access-Control-Allow-Headers: Range 설정. 동일 도메인 서빙으로 CORS 자체를 제거하는 것이 최선입니다.

3

NIfTI 좌표계 메타데이터 보존 문제

표준 OME-Zarr는 NIfTI의 qform/sform 행렬을 저장하는 공간이 없습니다. NIfTI-Zarr(nii.zarr) 스펙이 이를 해결하지만, Cornerstone3D의 nifti-volume-loader는 현재 nii.zarr 포맷을 직접 지원하지 않습니다. 커스텀 ImageLoader에서 NIfTI 헤더를 별도 파싱해 MetaData Provider에 수동 등록해야 합니다.

대응: zarr.json 속성에 NIfTI 헤더 정보를 JSON으로 추가 저장하고, ImageLoader 초기화 시 MetaData Provider에 등록하는 유틸리티 함수를 구현합니다.

4

청크 경계 아티팩트 (렌더링 이음새)

청크 크기가 슬라이스 크기와 맞지 않으면 청크 경계에서 보간 아티팩트가 발생할 수 있습니다. 특히 Volume Rendering에서 청크 경계가 밝은 선으로 보이는 현상이 나타납니다.

대응: 슬라이스 축(Z) 방향의 청크 크기를 1로 설정(1×512×512)하면 슬라이스 단위 청크가 되어 MPR 뷰어에서 아티팩트가 없습니다. Volume Rendering에는 64×64×64 입방형 청크가 적합합니다.

5

HTTP 요청 수 증가 → 레이턴시 누적

슬라이스 하나에 4~8개 청크 요청이 발생하면, HTTP 연결 오버헤드가 누적됩니다. 특히 고레이턴시 환경(해외 클라우드)에서는 청크 수×RTT가 체감 속도에 영향을 줍니다.

대응: HTTP/2 멀티플렉싱으로 병렬 요청을 단일 연결에 묶어 해결합니다. 청크 크기를 키우거나(128×128×128) Zarr v3 Sharding을 사용해 요청 수를 줄입니다.

6

변환 파이프라인 구축 비용

AI 모델이 .nii.gz로 결과를 출력하는 경우, 웹 서빙 전 Zarr 변환 단계를 파이프라인에 추가해야 합니다. 1024×1024×300 볼륨 변환 시 CPU 30초~수 분이 소요됩니다.

대응: AI 추론 완료 후 비동기 백그라운드 작업(Celery, AWS Lambda)으로 변환하고, 변환 완료 전에는 .nii.gz 원본을 제공합니다. 최종적으로 AI 모델이 직접 Zarr로 출력하도록 파이프라인을 수정합니다.

08 · 전환 전략

실제 도입 로드맵 — 단계별 전환

모든 데이터를 한 번에 Zarr로 전환하는 것은 위험합니다. 기존 .nii.gz와 Zarr를 공존하는 단계적 전환 전략을 권장합니다.

1단계

병렬 제공 (현재 .nii.gz 유지)

신규 AI 출력물에 한해 Zarr 변환 파이프라인을 추가합니다. 클라이언트가 Accept: application/zarr 헤더로 Zarr를 요청하면 Zarr 스토어 URL을 응답하고, 그렇지 않으면 기존 .nii.gz URL을 반환합니다. 기존 시스템을 전혀 건드리지 않아 안전합니다.

2단계

웹 뷰어 커스텀 ImageLoader 개발 및 검증

Zarr 청크 기반 커스텀 ImageLoader를 개발하고, 실제 볼륨으로 좌표계(LPS 변환), W/L 자동 계산, 청크 캐싱 동작을 검증합니다. A/B 테스트로 .nii.gz와 Zarr의 로딩 시간을 비교합니다.

3단계

멀티해상도 + 점진적 렌더링 구현

첫 렌더에 저해상도(level 3)를 표시하고, 백그라운드에서 고해상도(level 0)를 채우는 Progressive 렌더링을 구현합니다. 사용자 줌 레벨에 따라 자동으로 해상도 레벨을 선택하는 LOD(Level of Detail) 로직을 추가합니다.

4단계

AI 파이프라인 직접 Zarr 출력으로 전환

변환 오버헤드를 제거하기 위해 AI 모델이 결과를 직접 Zarr 스토어로 저장합니다. Python zarr 라이브러리로 청크 단위 쓰기가 가능하므로, 추론이 완료되는 슬라이스부터 즉시 Zarr에 저장하면 추론 완료와 동시에 웹 뷰어가 접근 가능합니다.

# 서버 사이드: NIfTI → Zarr 변환 파이프라인 (Python)
from niizarr import nii2zarr
import zarr
import nibabel as nib

# 방법 1: nii2zarr CLI 도구
# nii2zarr --chunk 64 --levels 4 --compressor blosc input.nii.gz output.nii.zarr

# 방법 2: Python API로 직접 변환
img = nib.load('brain.nii.gz')
data = img.get_fdata()

store = zarr.open('brain.nii.zarr', mode='w')
# 청크: Z축 1슬라이스 = MPR 최적, X/Y는 전체
arr = store.require_dataset(
    'data',
    shape=data.shape,
    chunks=(1, data.shape[1], data.shape[2]),  # 1×H×W
    dtype=data.dtype,
    compressor=zarr.Blosc(cname='zstd', clevel=3, shuffle=zarr.Blosc.BITSHUFFLE)
)
arr[:] = data

# NIfTI 헤더를 zarr.json 속성에 저장
store['data'].attrs['nifti_header'] = {
    'pixdim': img.header['pixdim'].tolist(),
    'sform_code': int(img.header['sform_code']),
    'srow_x': img.header['srow_x'].tolist(),
    'srow_y': img.header['srow_y'].tolist(),
    'srow_z': img.header['srow_z'].tolist(),
}

09 · Conclusion

결론 — 언제 .nii.gz를, 언제 Zarr를 선택해야 하나

시나리오	.nii.gz	Zarr
AI 학습 데이터 처리 (순차 읽기)	적합	오버헤드
로컬 분석 도구 (FSL, FreeSurfer)	완벽 호환	별도 변환 필요
웹 뷰어 대용량 볼륨 서빙	초기 로딩 느림	청크 단위 즉시 표시
클라우드(S3) 저장 & 서빙	Range Request 필요	정적 HTTP 바로 가능
멀티해상도 점진적 렌더링	불가	피라미드 내장
소용량 볼륨 (512×512×50 이하)	간단하고 충분	전환 비용 대비 이득 적음
1024×1024+ 고해상도 볼륨	gzip 해제 수분 소요	필요 청크만 수 초
실시간 협업 / 병렬 접근	단일 스트림	청크 병렬 처리

🧭 권장 이중 전략: AI 학습 파이프라인과 기존 분석 도구에는 .nii.gz를 유지하고, 웹 뷰어 서빙 전용으로만 Zarr로 변환합니다. 동일 볼륨을 두 포맷으로 저장하더라도, 대용량 볼륨에서 사용자 경험 향상이 스토리지 비용보다 훨씬 큽니다. 특히 1024×1024 이상의 고해상도 볼륨에서 Zarr의 멀티해상도 + 청크 스트리밍은 .nii.gz와 비교할 수 없는 UX를 제공합니다.

⚠️ 현재 Cornerstone3D는 Zarr를 공식 지원하지 않으므로, 커스텀 ImageLoader 개발이 필요합니다. NIfTI-Zarr(nii.zarr) 스펙은 아직 RC 단계이므로 프로덕션 도입 전 스펙 안정성을 확인하세요. 대안으로 Zarr 변환 + 커스텀 REST API로 슬라이스 단위 PNG를 제공하는 하이브리드 방식도 현실적인 선택입니다.

참고: NIfTI-Zarr 스펙 · Zarr 공식 문서 · nifti-zarr PyPI · OME-Zarr 논문

2026 · NIfTI Viewer 프로젝트 — .gz vs Zarr 기술검토