PATH 병리 이미지(WSI) 분석 플랫폼: 뷰어 개발과 납품 전 보안 점검

배경

고객 의료기관명과 내부 시스템명은 익명화했고, 고객사의 보안 검토 내용은 포함하지 않았습니다. 기법과 진행 과정은 실제와 동일합니다.

PATH는 병리 슬라이드 이미지(WSI, Whole Slide Image)를 업로드 → 타일링 → 분석 엔진 파이프라인에 태워, 그 결과를 병리 전문의가 검토하는 플랫폼입니다. AD3와는 완전히 별개의 제품으로, 저는 이 파이프라인의 프론트엔드 — 특히 뷰어·인터랙션 UI — 를 담당했습니다.

• OpenSeadragon 기반 딥줌 뷰어로 기가픽셀급 슬라이드 이미지를 타일 단위로 렌더링
• Jotai로 뷰어 상태(줌·팬·오버레이 토글)를 관리하고, React Hook Form으로 분석 파라미터·계정 설정 폼을 처리
• TanStack Query로 분석 결과(hotspot, ESD/ICI/TME 분석 등) 조회와 캐싱을 관리

이 제품은 국내 대형 의료기관에 온프레미스로 납품되는 것을 목표로 개발됐습니다 — 병원 자체 네트워크 안에 설치되어 운영되는 형태입니다.

문제

의료기관 온프레미스 납품은 일반적인 SaaS 배포와 다릅니다. 고객 기관이 자체 보안 검토를 수행하고, 그 결과가 납품 일정에 직접 영향을 줍니다. 즉 보낸 뒤에 지적을 받는 것과 보내기 전에 우리가 먼저 확인하는 것의 비용 차이가 큽니다.

그런데 당시 팀에는 인증 흐름이 OWASP 기준에서 어떻게 보이는지를 우리 손으로 확인할 수단이 없었습니다. 보안은 "아마 괜찮을 것"이라는 추정 위에 놓여 있었고, 그 추정을 검증하는 절차는 존재하지 않았습니다.

진행한 작업

1. 납품 전 OWASP 기반 점검 절차 도입

OWASP ZAP(Zed Attack Proxy)을 설치·설정해서, 납품 전에 주요 인증 플로우를 스캔하는 절차를 만들었습니다. 목적은 외부 감사를 대체하는 게 아니라 — 그건 도구 하나로 되는 일이 아니니까요 — 기관에 보내기 전에 우리가 먼저 알고 있는 상태를 만드는 것이었습니다.

React SPA라 셋업에서 실제로 걸리는 지점들이 있었습니다:

• 일반 Spider로는 크롤링이 안 됩니다. JS를 실행하지 않아 어떤 URL이든 index.html만 반환되고, 로그인도 폼 submit이 아니라 JS fetch POST라 스파이더가 인증 상태를 만들지 못합니다 → AJAX Spider로 전환
• 인증 상태를 스캔에 태우는 설정이 별도로 필요했습니다. 프록시를 경유하는 브라우저로 직접 로그인해 세션을 만들고, 그 상태를 ZAP이 이어받도록 구성
• dev 서버가 아니라 프로덕션 빌드를 대상으로 스캔했습니다. dev 빌드는 소스맵·개발용 헤더 때문에 노이즈가 많아 결과를 신뢰하기 어렵습니다

2. 점검 결과 반영 후 납품

스캔에서 확인된 항목은 백엔드 담당자와 함께 정리해 조치한 뒤 납품했습니다. 구체적인 점검 내용은 고객 기관의 보안 사안이라 여기에 적지 않습니다.

3. 뷰어 인터랙션 안정화

납품 준비와 병행해 뷰어 쪽 작업도 진행했습니다 — 줌/팬 상태를 Jotai atom으로 일원화해 여러 오버레이 패널(ROI, hotspot 결과)이 뷰어 좌표계와 어긋나지 않도록 동기화하고, 분석 파라미터 입력 폼의 유효성 검증을 React Hook Form 스키마로 정리했습니다.

결과

항목	이전	이후	변화
납품 범위	사내 스테이징까지	의료기관 온프레미스 배포	납품 완료
납품 전 보안 점검	절차 없음	OWASP ZAP 기반 인증 플로우 스캔	절차 도입
점검 근거	"아마 괜찮을 것"	스캔 결과를 확인하고 납품	추정 → 확인

온프레미스 납품은 고객 기관의 보안 검토가 일정에 직접 영향을 주는 구조라, "보내기 전에 우리가 먼저 확인한다"는 절차의 유무가 크게 작용합니다. 도구를 하나 들여온 것보다, 확인하지 않고 보내던 상태에서 확인하고 보내는 상태로 옮긴 것이 실질적인 변화였습니다.

관련 케이스 스터디

사내 프론트엔드 제품 전반의 릴리즈·테스트 파이프라인은 DevSecOps 파이프라인 케이스 스터디에서 다룹니다.