[AI하스피탈 인사이트]무늬만 클라우드를 넘어, 진짜 클라우드 네이티브로

이기혁 분당서울대병원 가정의학과 과장(이지케어텍 사업총괄 겸임) 기존 병원정보시스템(HIS)을 클라우드 서버로 옮기면 클라우드 HIS가 된다. 그렇다면 그것으로 충분할까. 병원 전산실에서 운영하던 물리 서버와 데이터베이스를 클라우드의 가상머신(VM)으로 옮기는 방식이 있다. 흔히 '리프트 앤 시프트'(Lift & Shift)라고 부른다. 서버를 직접 구매하고 교체하는 부담을 줄이고 필요한 인프라를 보다 유연하게 확보할 수 있다는 점에서 분명 의미 있는 변화다. 하지만 시스템이 실행되는 장소를 옮겼다고 해서 애플리케이션의 구조까지 바뀌는 것은 아니다. 하나의 거대한 프로그램으로 구성된 HIS, 병원마다 조금씩 달라진 소스코드와 데이터베이스 구조, 수작업 중심의 배포 방식이 그대로라면 서버가 클라우드 위에서 실행되더라도 시스템이 만들어지고 변화하고 운영되는 방식은 과거와 크게 다르지 않다. 바로 이 지점에서 단순한 '클라우드 인프라 전환'과 '클라우드 네이티브'(Cloud Native)의 본질적인 차이가 드러난다. 클라우드 네이티브 병원정보시스템(HIS) 플랫폼 ◇같은 기능인데 왜 병원마다 다시 작업해야 할까 100개 병원이 같은 HIS 제품을 사용한다고 가정해 보자. 병원별 요구를 개별 개발로 반영하다 보면 간호 화면과 처방 규칙, 연계 시스템이 달라진다. 구축 시점에 따라 프로그램 버전과 운영체제, 데이터베이스 환경에도 차이가 생긴다. 시간이 지나면 '하나의 제품을 100개 병원이 사용한다'기보다 '조금씩 다른 100개의 시스템을 운영하는' 상황에 가까워진다. 이 상태에서는 새로운 기능을 한 번 개발했다고 일이 끝나지 않는다. 각 병원의 기존 구조를 분석하고 누적된 커스터마이징과 충돌하지 않는지 확인해야 한다. 필요한 수정과 테스트를 거친 뒤 병원별 일정에 맞춰 배포하는 과정도 반복된다. 반면 공통 코드베이스를 유지하는 구조에서는 핵심 기능을 한 번 개발하고 검증한 뒤 각 병원의 설정과 환경에 맞춰 적용 범위를 넓혀갈 수 있다. 병원별 적용 과정은 남지만 핵심 기능을 병원마다 따로 수정하는 부담은 줄어든다. 클라우드 네이티브가 해결하려는 중요한 문제 가운데 하나가 바로 이 반복이다. 한 번의 개발 성과가 한 병원에 머무르지 않고 제품 전체의 개선으로 축적되도록 만드는 것이다. ◇병원마다 업무가 다른데 어떻게 하나 여기서 당연한 반론이 나온다. “병원마다 진료 프로세스와 업무 방식이 다른데 어떻게 하나의 ...