[React] SEG NIfTI, 왜 버렸나 병목의 해부와 BBox 전환 배경

1편 / 3편

SEG NIfTI, 왜 버렸나
병목의 해부와 BBox 전환 배경

BE에서 Seg NIfTI를 받아 VTK로 오버레이하던 방식이 왜 문제였는지, 그리고 BBox JSON이라는 선택이 어떻게 그 모든 문제를 한번에 해결했는지 설명합니다.

NIfTI Seg 병목 Web Worker BBox JSON 아키텍처 전환 데이터 흐름

🗂 시리즈: SEG NIfTI에서 BBox JSON으로

1

SEG NIfTI의 문제와 BBox JSON 전환 배경 ← 현재

2

BBox JSON API 설계와 Canvas 오버레이 구현

3

VTK 좌표계에서 3개 뷰 동시에 BBox 그리기

01 · Background

무엇이 문제였나

VTK.js 기반 의료 영상 뷰어에서 세그멘테이션 오버레이는 오랫동안 "SEG NIfTI를 받아서 VTK ImageSlice로 렌더링"하는 방식으로 구현되어 있었습니다. 동작 자체는 문제없었지만, 사용자 경험 측면에서 두 가지 문제가 반복적으로 보고되었습니다.

하나는 로딩 시간이었고, 다른 하나는 저사양 기기에서의 메모리 압박이었습니다. 두 문제 모두 원인을 파고들면 같은 곳을 가리키고 있었습니다 — SEG NIfTI 파일 자체.

+10s

SEG 로딩 추가 대기

×2

메모리 추가 점유

수 KB

BBox JSON 응답 크기

0 MB

SEG 관련 메모리 (전환 후)

02 · Before — 기존 파이프라인

기존 방식이 느렸던 이유

기존 SEG 렌더링 파이프라인은 다음 단계를 순서대로 거쳐야 했습니다. 각 단계가 완료되어야 다음 단계가 시작되는 순차적 블로킹 구조였습니다.

1

fetchAxialSegVolume() — 네트워크

BE에서 SEG NIfTI(.nii.gz)를 ArrayBuffer로 수신합니다. 압축 상태에서도 수십 MB 이상. 네트워크 상태에 따라 수 초~수십 초 소요됩니다. Base 볼륨과 병렬 fetch는 되지만, 이 단계가 끝나야 다음으로 진행합니다.

2

parseNifti() — gzip 압축 해제

nifti-reader-js의 decompress()로 gzip을 해제합니다. JavaScript 싱글스레드에서 실행되므로, 해제가 완료될 때까지 메인 스레드가 블로킹됩니다. 해제 후 볼륨이 수백 MB로 팽창합니다.

3

Web Worker — 리샘플링 + RGBA 변환

SEG 스칼라를 라벨별 색상 RGBA 배열로 변환하는 작업을 Web Worker에서 수행합니다. Base 볼륨과 해상도가 다를 경우 리샘플링이 추가됩니다. Float32Array → Uint8Array RGBA 변환으로 메모리가 다시 4배로 증가합니다.

4

createSegVtkImageData() + GPU 업로드

4채널 RGBA VTK ImageData를 생성하고 GPU 텍스처에 업로드합니다. CPU에는 RGBA 배열이, GPU에는 텍스처가 동시에 올라가 메모리가 2중으로 점유됩니다.

메모리 누적 구조

각 단계를 거칠수록 같은 SEG 데이터가 여러 형태로 메모리에 쌓입니다.

① 압축 ArrayBuffer

~30 MB

② 해제 후 스칼라

~300 MB

③ RGBA (×4)

~600 MB

④ GPU 텍스처 추가

~1.2 GB+

* 512×512×300 SEG 볼륨, Float32 → RGBA 변환 기준 추정

🚨 내장 GPU 환경과 16GB RAM 노트북 테스트에서 SEG 로딩 중 브라우저 탭 크래시가 발생했습니다. Base(1.2GB) + SEG RGBA(1.2GB) + GPU 텍스처가 동시에 올라가면서 탭 메모리 한도를 초과했습니다.

03 · Root Cause

근본 원인 — 포맷 선택의 불일치

문제를 한 줄로 요약하면 이렇습니다.

💡 "우리가 화면에 그려야 하는 정보"와 "우리가 실제로 받고 있던 데이터" 사이의 간극이 너무 컸습니다.

화면에 그려야 하는 것은 단순합니다. 각 슬라이스에서 어느 픽셀 좌표에, 어떤 색의 박스(또는 윤곽선)를 그릴 것인가입니다. 이 정보를 표현하는 데 필요한 데이터 크기는 겨우 수 KB입니다.

그런데 NIfTI SEG는 그 수 KB짜리 정보를 표현하기 위해 수백 MB의 3D 복셀 볼륨을 전달합니다. 대부분의 복셀은 0(배경)이고, 실제 레이블이 있는 복셀은 전체의 1~5%에 불과합니다.

04 · The Decision

해결책 — BBox JSON으로의 전환

검토된 대안은 세 가지였습니다.

대안	접근 방식	메모리	구현 복잡도	채택
Sparse Zarr SEG	SEG NIfTI → Zarr 변환, 청크 단위 fetch	개선됨	높음 (커스텀 로더)	미채택
서버사이드 슬라이스 렌더링	BE에서 PNG로 렌더링, 슬라이스마다 요청	최소	중간	미채택
BBox/Contour JSON	BE에서 좌표 계산, FE Canvas에서 그리기	최소 (~0)	낮음	✓ 채택

BBox JSON 방식이 채택된 핵심 이유는 세 가지 문제를 동시에 해결하면서 구현 복잡도는 오히려 줄어들었기 때문입니다.

📦

메모리 문제 해결

SEG 관련 메모리가 사실상 0이 됩니다. JSON 응답 자체가 수 KB이고, Canvas 2D로 그리므로 GPU 텍스처 업로드도 없습니다.

⚡

로딩 시간 해결

수십 MB gzip 다운로드 → 수 KB JSON. gzip 해제, Worker, VTK ImageData 생성 단계가 모두 사라집니다. Base 볼륨과 병렬로 즉시 완료됩니다.

🧹

코드 단순화

fetchAxialSegVolume, Web Worker 파이프라인, createSegVtkImageData, createSegPlanarSlices 등 수백 줄의 복잡한 코드가 제거됩니다.

📐

3뷰 지원 가능

BBox 좌표에서 3D 바운딩 박스를 재구성하면 Axial뿐 아니라 Sagittal, Coronal 뷰에서도 투영 박스를 그릴 수 있습니다. (3편에서 상세 설명)

05 · After — 새 파이프라인

변경 후 파이프라인

Before

fetchAxialSegVolume()
  → NIfTI ArrayBuffer (~30MB)
  → parseNifti() gzip 해제
  → Web Worker 리샘플 + RGBA
  → createSegVtkImageData()
  → createSegPlanarSlices()
  → VTK GPU 텍스처 업로드
  → renderWindow.render()

총 시간: +10~30초 (Base 이후)
메모리: +600MB~1.2GB

After

fetchAxialBBox()
  → JSON (~수 KB)
  → response.json() 파싱
  → bboxAnnotations state 저장
  → Canvas 2D drawBBoxOverlay()

총 시간: Base와 동시 완료
메모리: ~0 (JSON 외 추가 없음)

06 · Code Removed

제거된 것들 — 사라진 복잡성

이번 전환에서 삭제된 코드와 의존성 목록입니다. 새로 추가된 것보다 제거된 것이 훨씬 많습니다.

구분	제거된 항목	이유
API 함수	fetchAxialSegVolume(), fetchSegVolume()	BBox JSON으로 대체
유틸리티	createSegVtkImageData(), createSegPlanarSlices(), createSegCrossSlices()	VTK SEG 파이프라인 전체 제거
Web Worker	SegProcessRequest, SegProcessResponse, resample 로직	JSON은 파싱만으로 끝남
import	vtkDataArray, SegProcessRequest, fetchSegVolume 등 다수	미사용
상태	segImageData, segDims, segOriginalScalars (MapperRegistry)	더 이상 VTK SEG 상태 불필요
MapperRegistry	setSegMappers(), applySegColorMap(), segOriginalScalars	SEG VTK 렌더링 제거

🧹 복잡한 코드를 추가하지 않고 제거함으로써 성능이 개선되었습니다. 메모리 절감, 로딩 속도 향상, 탭 크래시 방지 — 세 가지 모두 코드 삭제에서 비롯됩니다. 가장 좋은 최적화는 실행하지 않는 것입니다.

07 · Summary

1편 요약

항목	Before	After
SEG 데이터 형식	NIfTI gzip (~30MB+)	JSON (~수 KB)
SEG 로딩 시간	Base 이후 +10~30초	Base와 동시 완료
SEG 메모리 사용	+600MB~1.2GB	~0 MB
Web Worker	리샘플 + RGBA 변환	불필요
GPU 텍스처	SEG RGBA 텍스처 추가	추가 없음
렌더링 방식	VTK ImageSlice	Canvas 2D
3뷰 지원	Axial만 (Seg overlay)	Axial + Sagittal + Coronal

📌 2편 예고: BBox JSON API가 어떻게 설계되었는지, FE에서 어떻게 Canvas에 직접 그리는지, AxialGridViewer와 BBoxOverlay 컴포넌트의 구체적인 구현을 다룹니다.

다음 글

2편 — BBox JSON API 설계와 Canvas 오버레이 구현

2편 보기 →

NIfTI Viewer 프로젝트 · SEG → BBox 전환 시리즈 1편 · 2026