웹 환경에서 대용량 DICOM 의료영상을 안정적으로 조회/표시하기 위해
전송 단위 설계 + 디코딩 실패 케이스 분리 + 인증/운영 구성까지 포함해 구현한 프로젝트입니다.
- Period: 2025.08 ~ 2025.09 (2 months)
- Team: 3
- Goal
- 기존
studyId기준 시리즈 전체 단일 로딩 구조에서 발생하는 지연/실패 개선 - 사용자가 실제로 보는 흐름에 맞춰 전송 단위/요청 흐름을 재설계
- Transfer Syntax 등 다양한 입력 특성에서 디코딩 실패 원인 분류 및 대응 기준 정리
- 인증/권한 제어와 운영 환경 안정성까지 함께 확보
- 기존
- Frontend(Viewer): Cornerstone.js (or your viewer library)
- Backend: Java, Spring Boot, REST API
- Auth: JWT, Redis (token 운영 편의 목적)
- DB: Oracle + MariaDB (Multi datasource)
- Docs/Tools: Swagger(OpenAPI), Postman
- Collaboration: Git, GitHub
- DICOM 조회/전송 REST API 설계 및 구현 (대용량 전송 안정화 포함)
- 기존 “시리즈 전체를 한 번에 가져오는 방식” 병목 분석 및 전송 구조 개선
- Transfer Syntax 기반 디코딩 실패 케이스 분리 및 대응 기준 정리
- JWT 인증/인가 적용, Redis로 토큰 운용 편의성 확보
- Oracle + MariaDB 멀티 데이터소스 구성 및 운영 이슈 대응
- Issue:
studyId기준으로 시리즈 전체를 한 번에 내려받아 용량이 커질수록 로딩 지연/실패 증가 - Cause: 네트워크/메모리/디코딩 부담이 급격히 증가하고, 실패 시 화면이 바로 깨짐
- Fix:
- 사용자 뷰잉 흐름에 맞춰 전송 단위를 재정의 (예: 이미지 단위/프레임 단위/청크 등 실제 구현 기준)
- 요청-응답 흐름을 안정적으로 유지하도록 API 구조를 정리
- Result: 초기 로딩 지연과 실패 빈도가 감소, 큰 파일에서도 뷰잉 흐름이 안정적으로 유지
- Issue: Transfer Syntax에 따라 브라우저 디코딩이 실패하는 케이스 발생
- Fix:
- 실패 케이스를 Transfer Syntax/포맷 기준으로 분류
- 뷰어 로더 흐름을 따라가며 실패 지점(단계)을 좁혀 원인 추적
- 지원 가능/불가능 범위를 구분하고, 실패 시 사용자 안내/에러 처리 흐름 정리
- Result: 디코딩 실패가 “원인 불명 오류”로 남지 않고, 장애 대응과 안내가 쉬워짐
- Issue: 의료영상은 접근 권한이 중요하고 인증 문제는 운영 장애로 직결
- Fix:
- JWT 기반 인증/인가 적용
- Redis를 활용해 토큰 운용을 관리하여 운영 편의성 확보 (실사용 범위 기준으로 표현)
- Result: 인증 흐름이 표준화되고 운영 환경에서 추적/대응이 쉬워짐
- Issue: 멀티 DB 환경에서 연결/조회/트랜잭션 흐름이 복잡해질 수 있음
- Fix:
- 데이터소스 분리 설정 및 접근 계층 책임 분리
- 로그 기반으로 장애 원인을 좁혀 대응
- Result: 멀티 DB 환경에서도 조회/저장 흐름이 유지되도록 구성
- 대용량 파일 서비스는 기능 구현보다 먼저 전송 단위 설계와 실패 복구 흐름을 잡아야 UX가 무너지지 않습니다.
- 입력 데이터 특성이 다양한 환경(Transfer Syntax 등)은 실패 케이스를 분류하고 지원 범위/대응 기준을 정리하는 게 운영에 중요합니다.
- 인증/권한, 멀티 DB 같은 운영 요소까지 포함해 “돌아가는 기능”을 “운영 가능한 서비스”로 만드는 과정이 필요했습니다.