Frontend Engineer · Healthcare Imaging

의료영상 플랫폼의 복잡한 흐름을 제품 구조로 정리하는 프론트엔드 개발자

IT 헬스케어 분야에서 의료영상 플랫폼을 개발하는 6년차 프론트엔드 개발자입니다. React와 TypeScript 기반의 서비스 리뉴얼, 레거시 전환, 결제·배포 자동화 경험을 바탕으로 복잡한 의료 데이터 흐름을 사용자가 이해하기 쉬운 제품 구조로 개선해왔습니다.

Focus
의료영상 UX
Stack
React · TypeScript
Scope
UI · 결제 · DevOps

Selected Projects

핵심 프로젝트

02

3D Viewer

의료영상 3D 시각화 웹 서비스

CT 단층영상 기반 3D 시각화 서비스를 개발하고 PACS 시스템에 연동하며 UI 워크플로우를 개선했습니다. vtk.js 셰이더 커스터마이징으로 보간 기법을 적용해 렌더링 품질을 개선했고, Vanilla JS 기반 구조를 React로 마이그레이션했습니다.

  • vtk.js
  • Shader
  • React

03

Filmbox

의료영상 판독 웹 서비스

병원 전문가용 웹 기반 의료영상 판독 서비스입니다. 약 20,000줄 규모의 전역 스코프 기반 레거시 코드를 모듈화하고 Redux를 도입해 상태 관리 체계를 정비하며 React 전환 기반을 마련했습니다.

  • Legacy
  • Redux
  • Migration
사례 3으로 이동

Problem Solving Cases

문제 해결 사례

01

HScan 프론트엔드 리뉴얼 및 아키텍처 전환

화면 단위 개선으로는 해결하기 어려웠던 인증, 결제 callback, 공유 링크, 다국어, 디자인 정책 문제를 라우팅과 스타일 시스템 수준에서 정리했습니다.

문제의 배경

HScan은 로그인, 영상 요청, 병원 선택, 결제, 공유, 고객지원, 다국어 화면이 한 서비스 안에 연결되어 있어 화면 단위 수정만으로는 일관된 사용자 경험을 만들기 어려웠습니다.

  • 기존 스타일 체계가 MUI, styled-components, 개별 CSS로 분산되어 리뉴얼 이후에도 화면마다 UI 정책이 달라질 위험이 컸습니다.
  • 결제 callback, 공유 링크, QR처럼 인증 상태와 무관하게 진입하는 외부 경로가 많아 인증 가드와 라우팅 예외 처리가 화면 곳곳에 흩어져 있었습니다.
  • 페이지 진입, 본인인증 전환율, 공유·저장 사용률을 수집하지 못해 UI 개선 방향을 판단할 근거가 부족했습니다.
  • Webpack 기반 dev server cold start가 20초 이상 걸려 화면 수정이 잦은 리뉴얼 작업의 피드백 루프가 느렸습니다.

대안 검토

스타일 체계는 MUI 유지와 테마 커스터마이징, styled-components 통일, Tailwind CSS와 커스텀 디자인 토큰 도입을 비교했습니다. 라우팅은 React Router 유지와 TanStack Router 전환을 비교했고, 빌드 도구는 Webpack 캐시 튜닝과 Vite 전환을 같은 로컬 환경에서 직접 측정했습니다.

  • MUI는 리뉴얼 시안과 컴포넌트 구조 차이가 커 override 비용이 컸습니다.
  • styled-components는 런타임 CSS-in-JS 비용과 별도 토큰 체계 구축 부담이 있었습니다.
  • Tailwind v4는 @theme로 토큰 정의와 스타일 적용을 한 체계로 묶을 수 있어 선택했습니다.
  • TanStack Router는 타입 안전한 route 정의와 route tree 기반 인증 가드 계층화가 외부 진입 경로가 많은 서비스 구조에 적합했습니다.

해결 과정

React 19, Vite, TanStack Router, Tailwind CSS v4를 도입하고 라우팅, 스타일 토큰, 공통 컴포넌트 체계를 함께 재정비했습니다. public route, protected route, 외부 공유·QR·결제 callback route를 TanStack Router의 route tree로 분리하고 인증 상태와 앱 레이아웃을 계층화했습니다.

  • Tailwind @theme에 색상, 타이포그래피, spacing 기준을 정의해 커스텀 디자인 토큰을 만들었습니다.
  • Keycloakify 기반 인증 화면을 리뉴얼 방향에 맞춰 관리해 로그인·회원가입·인증 화면의 UI 일관성을 유지했습니다.
  • GA 이벤트 유틸을 만들어 페이지뷰, 본인인증 성공 여부, 버튼 클릭, 공유·저장 이벤트를 코드 레벨에서 추적할 수 있게 했습니다.
  • pnpm, Vite, Vitest, GitHub Actions build check를 구성해 의존성 설치와 빌드 검증을 CI에 포함했습니다.

얻은 효과

기능 단위 디렉터리와 공통 컴포넌트·토큰 구조를 정리해 리뉴얼 이후 신규 기능을 같은 UI 정책으로 확장할 수 있게 했습니다. TypeScript·TSX 파일이 273개에서 311개로 늘었지만 기능 도메인 디렉터리는 29개에서 28개로 유지해, 코드가 늘어도 책임 경계가 흐트러지지 않는 구조를 만들었습니다.

  • 인증, 결제 callback, 공유 링크, QR 등 외부 진입 경로를 라우팅 구조 안에서 관리해 예외 플로우의 유지보수성을 높였습니다.
  • GA 이벤트 기반으로 본인인증 전환율과 공유·저장 사용률을 추적해 이후 UI 개선 우선순위를 데이터 기반으로 판단할 수 있는 토대를 마련했습니다.
동일 로컬 환경 기준 개발 환경 개선 결과
항목 기존 개선 후 향상률
의존성 설치 66초 4초 약 94% 단축
production build 31초 10초 약 68% 단축
dev server cold start 20.857초 0.577초 약 97% 단축

02

HScan 영상 요청·결제 플로우와 병원별 과금 정책 처리

병원별로 다른 가격 정책과 비동기 파일 크기 조회가 결제 화면에 섞이지 않도록 플로우와 계산 책임을 분리했습니다.

문제의 배경

사용자가 여러 병원에서 영상을 조회하고 선택한 뒤 결제하는 흐름은 병원 선택, 본인 확인, 검사 목록 조회, 기간·검사 종류 필터, 실패 영상 제외, 전달 병원 선택, 결제 콜백이 서로 영향을 주는 복잡한 상태 흐름이었습니다.

  • 병원별 가격 정책이 정액제, 검사 수 기준, 이미지 수 기준, 용량 구간 기준, 용량 단위 조합 기준처럼 달랐습니다.
  • 의료영상은 실제 파일 크기 조회가 필요한 경우가 있어 선택 상태와 가격 계산이 비동기 데이터 로딩과 함께 동작해야 했습니다.

대안 검토

용량 단위 조합형 가격 계산은 완전 탐색, 그리디, 우선순위 큐 기반 탐색을 비교했습니다. 완전 탐색은 조합 수 증가에 취약했고, 그리디는 금액과 면세 금액을 함께 고려할 때 최적화를 보장하지 못해 우선순위 큐 기반 탐색을 선택했습니다.

  • 화면 컴포넌트 내 처리와 별도 계산 유틸 분리를 비교했고, 정책 추가·변경이 잦은 도메인 특성상 단일 계산 구조가 변경 비용이 낮다고 판단했습니다.
  • 우선순위 큐 기반 탐색은 금액이 낮은 후보부터 확장해 목표 용량을 충족하는 시점에 최적 조합을 얻을 수 있어 선택했습니다.

해결 과정

의료영상 발급을 병원 선택, 영상 선택, 결제의 3단계 플로우로 나누고 단계별 상태와 뒤로가기, 재시도, 다른 병원 추가 동작을 분리했습니다. 영상 선택 단계에서는 기간 필터, 검사 종류 필터, 선택 복원, 실패 영상 제외, 병원별 선택 목록 병합을 처리했습니다.

  • 용량 기반 예상 과금이 필요한 경우 선택된 검사 파일 크기를 별도로 조회하고 로딩·에러 상태에 따라 금액 노출 조건을 제어했습니다.
  • 가격 계산 로직을 화면 컴포넌트에서 분리해 정액제, 검사 수, 이미지 수, 용량 구간, 용량 단위 조합 정책을 일관된 구조로 처리했습니다.
  • 용량 단위 조합형 과금 정책은 우선순위 큐 기반 탐색으로 구현해 목표 용량을 충족하는 조합 중 금액과 면세 금액을 함께 고려한 최적 가격을 계산했습니다.

얻은 효과

병원별 정책 추가·변경 시 화면 컴포넌트가 아닌 계산 유틸에서 대응할 수 있게 되었고, UI 상태 변경과 가격 정책 변경이 서로 직접 영향을 주지 않는 구조를 만들었습니다.

  • 사용자 선택 상태, 필터 상태, 결제 상태를 단계별로 분리해 오류 재현과 수정 범위를 명확히 했습니다.
  • 3단계 발급 플로우와 병원별 과금 정책을 분리해 관리하면서 상태 변경과 정책 변경의 영향 범위를 좁혔습니다.

03

Filmbox 레거시 판독 도구 모듈화 및 상태 정리

운영 중인 판독 도구를 전면 재작성하지 않고, 기존 동작을 유지하면서 전역 변수와 script 로딩 순서 의존을 줄였습니다.

문제의 배경

Filmbox는 오래 운영된 웹 기반 의료영상 판독 도구로, 일부 로직이 전역 변수와 HTML script 로딩 순서에 의존하고 있었습니다. 기능별 책임이 명확히 분리되어 있지 않아 특정 동작을 수정할 때 관련 코드 위치를 찾기 어렵고 다른 기능에 영향을 줄 위험이 있었습니다.

  • 운영 중인 판독 도구였기 때문에 기존 기능을 유지하면서 점진적으로 구조를 정리해야 했습니다.

대안 검토

React 기반 전면 재작성과 점진적 모듈화를 비교했습니다. 운영 중인 도구를 한 번에 재작성하면 검증 범위가 전체 기능으로 확대되어 리스크가 컸기 때문에 단계적 정리를 선택했습니다.

  • 상태 관리는 Redux Toolkit과 자체 상태 객체 유지를 비교했습니다.
  • 비-React 레거시 코드에서도 store에 접근·구독해야 했기 때문에 getState, subscribe, devtools 추적이 가능한 Redux store가 전환기 구조에 적합했습니다.

해결 과정

레거시 JavaScript 코드 일부를 기능 단위로 분리하고 파일 간 의존성을 명시적인 import/export 구조로 정리했습니다. 도구바 위치, 썸네일 위치, 화면 표시 옵션, 재생 옵션처럼 사용자 설정 성격의 상태를 Redux Toolkit 기반 store로 분리했습니다.

  • 전역 변수로 관리되던 판독 도구 내부 상태 일부를 별도 상태 객체로 옮기고, 기존 레거시 코드가 해당 상태를 참조하도록 점진적으로 수정했습니다.
  • 모듈화와 상태 정리 과정에서 드러난 중복 선언, 잘못된 참조, 기존 브라우저 전역 객체 의존 문제를 함께 정리했습니다.

얻은 효과

기능별 코드 위치와 의존 관계가 이전보다 명확해져 유지보수 시 변경 범위를 파악하기 쉬워졌습니다. 전역 변수와 script 로딩 순서에 의존하던 부분을 줄여 이후 React 기반 구조로 점진 전환할 수 있는 기반을 마련했습니다.

  • 판독 화면 설정 상태가 Redux store 한 곳으로 모이면서, 이전에는 코드 전체에서 전역 변수를 추적해야 했던 설정 관련 수정이 store 모듈 확인만으로 가능해졌습니다.
  • 신규 화면 옵션도 같은 패턴으로 추가할 수 있게 되었습니다.

04

HScan CI/CD 및 설치·테스트 환경 자동화

프론트엔드 빌드만이 아니라 인증 서버, 배포 파이프라인, 테스트 환경, 온프레미스 설치 절차까지 제품 운영 흐름으로 연결했습니다.

문제의 배경

HScan 계열 서비스는 프론트엔드, 백엔드, 인증 서버, 데이터 저장소, 메시징, 모니터링 등 여러 서비스가 함께 동작해야 했습니다. 클라우드 Kubernetes 환경과 온프레미스 설치 환경을 모두 고려해야 했기 때문에 단순히 프론트엔드 빌드만 자동화하는 것으로는 운영 안정성을 확보하기 어려웠습니다.

  • 개발, 테스트, 운영 환경마다 이미지 빌드, 배포 파라미터, 인증 설정, 의존 서비스 구성이 달라 반복 가능한 배포·설치 절차가 필요했습니다.

대안 검토

클라우드 배포 방식은 kubectl로 직접 배포하는 방식과 GitHub Actions에서 ArgoCD 기반 GitOps를 비교했습니다. CI에서 직접 배포하면 클러스터 자격 증명을 CI에 노출해야 하고 배포 상태를 선언적으로 관리하기 어려운 반면, ArgoCD는 Git을 단일 기준으로 배포 상태를 동기화하고 롤백이 쉬워 GitOps 방식을 선택했습니다.

  • 온프레미스 설치는 경량 Kubernetes 도입과 Docker Compose + shell script 구성을 비교했습니다.
  • 병원 설치 환경의 운영 인력과 인프라 제약을 고려해 Kubernetes 운영 부담이 과하다고 판단하고 Compose 기반으로 정리했습니다.

해결 과정

ArgoCD와 Kubernetes를 이용해 dev/live 배포를 자동화하기 위해 각 서비스의 GitHub Actions에서 Docker image build/push를 수행하고 배포 workflow와 연결했습니다. branch별 개발·운영 환경, container registry, build args, 배포 파라미터를 분리해 환경별 배포 설정을 관리했습니다.

  • 클라우드 Kubernetes 환경에서 필요한 애플리케이션, 인증, 네트워크, 모니터링, 데이터 저장소 관련 리소스를 별도 설정으로 분리해 관리했습니다.
  • Docker Compose profile과 shell script를 이용해 온프레미스 환경에서 주요 서비스를 설치·업데이트할 수 있도록 정리했습니다.
  • 인증 서버와 mock DB 등을 포함한 로컬 테스트 서버 구성을 만들어 통합 테스트와 운영 전 검증 환경을 마련했습니다.

얻은 효과

프론트엔드 변경이 이미지 빌드, registry 업로드, ArgoCD 기반 Kubernetes 배포까지 이어지는 dev/live 배포 흐름을 표준화했습니다. 환경별 배포 설정을 분리해 개발·운영 배포 과정에서 발생할 수 있는 설정 혼선을 줄였습니다.

  • 온프레미스 설치 절차를 재실행 가능한 script와 Docker Compose 구성으로 정리해 설치 실패와 환경 편차를 줄일 수 있게 했습니다.
  • 화면 구현에 그치지 않고 인증 서버, 배포 파이프라인, 테스트 환경까지 직접 구축·운영하며 프론트엔드뿐 아니라 DevOps 영역까지 담당할 수 있음을 보여주는 사례로 정리했습니다.

Contact

조다솜

Frontend Engineer · React · TypeScript · Healthcare Imaging