기존 병원정보시스템(HIS)을 클라우드 서버로 옮기면 클라우드 HIS가 된다. 그렇다면 그것으로 충분할까.
병원 전산실에서 운영하던 물리 서버와 데이터베이스를 클라우드의 가상머신(VM)으로 옮기는 방식이 있다. 흔히 '리프트 앤 시프트'(Lift & Shift)라고 부른다. 서버를 직접 구매하고 교체하는 부담을 줄이고 필요한 인프라를 보다 유연하게 확보할 수 있다는 점에서 분명 의미 있는 변화다.
하지만 시스템이 실행되는 장소를 옮겼다고 해서 애플리케이션의 구조까지 바뀌는 것은 아니다.
하나의 거대한 프로그램으로 구성된 HIS, 병원마다 조금씩 달라진 소스코드와 데이터베이스 구조, 수작업 중심의 배포 방식이 그대로라면 서버가 클라우드 위에서 실행되더라도 시스템이 만들어지고 변화하고 운영되는 방식은 과거와 크게 다르지 않다.
바로 이 지점에서 단순한 '클라우드 인프라 전환'과 '클라우드 네이티브'(Cloud Native)의 본질적인 차이가 드러난다.
◇같은 기능인데 왜 병원마다 다시 작업해야 할까
100개 병원이 같은 HIS 제품을 사용한다고 가정해 보자. 병원별 요구를 개별 개발로 반영하다 보면 간호 화면과 처방 규칙, 연계 시스템이 달라진다. 구축 시점에 따라 프로그램 버전과 운영체제, 데이터베이스 환경에도 차이가 생긴다. 시간이 지나면 '하나의 제품을 100개 병원이 사용한다'기보다 '조금씩 다른 100개의 시스템을 운영하는' 상황에 가까워진다.
이 상태에서는 새로운 기능을 한 번 개발했다고 일이 끝나지 않는다. 각 병원의 기존 구조를 분석하고 누적된 커스터마이징과 충돌하지 않는지 확인해야 한다. 필요한 수정과 테스트를 거친 뒤 병원별 일정에 맞춰 배포하는 과정도 반복된다.
반면 공통 코드베이스를 유지하는 구조에서는 핵심 기능을 한 번 개발하고 검증한 뒤 각 병원의 설정과 환경에 맞춰 적용 범위를 넓혀갈 수 있다. 병원별 적용 과정은 남지만 핵심 기능을 병원마다 따로 수정하는 부담은 줄어든다.
클라우드 네이티브가 해결하려는 중요한 문제 가운데 하나가 바로 이 반복이다. 한 번의 개발 성과가 한 병원에 머무르지 않고 제품 전체의 개선으로 축적되도록 만드는 것이다.
◇병원마다 업무가 다른데 어떻게 하나
여기서 당연한 반론이 나온다. “병원마다 진료 프로세스와 업무 방식이 다른데 어떻게 하나의 시스템으로 운영할 수 있는가?”
대학병원과 지역 종합병원의 업무는 다르다. 같은 규모의 병원끼리도 조직 구조와 권한, 승인 절차, 진료 흐름이 서로 다르다. 의료정보시스템에서 이런 차이를 완전히 없애는 것은 현실적이지도 않고 바람직하지도 않다. 핵심은 표준화와 획일화를 구분하는 것이다.
진료·처방·검사·예약과 같은 핵심 기능의 기본 구조와 데이터 모델은 하나의 제품으로 유지하되, 병원마다 다른 화면 구성과 업무 규칙, 권한과 승인 절차는 설정(Configuration)을 통해 수용하는 방식이다. 개별 병원만의 고유한 요구가 반드시 필요한 영역은 정해진 확장 구조를 통해 추가한다.
중요한 것은 병원별 차이를 없애는 것이 아니라, 그 차이가 제품의 핵심 소스코드를 계속 갈라놓지 않도록 관리하는 것이다.
병원별 요구를 모두 별도 개발로 처리하면 처음에는 높은 수준의 맞춤형 시스템처럼 보일 수 있다. 그러나 서로 다른 버전과 코드가 쌓이면 새로운 기능이나 보안 패치를 적용할 때마다 그 차이를 다시 분석해야 한다. 공통 코드베이스를 유지하면서 차이를 설정과 확장으로 관리하는 것은 이러한 부담을 줄이기 위한 접근이다.
병원의 고유한 업무를 수용하면서도 제품 전체는 하나의 방향으로 계속 발전할 수 있어야 한다.
◇수가가 바뀌는 날, 모든 병원이 같은 버전일까
의료 현장에서 이 차이를 쉽게 확인할 수 있는 사례가 건강보험 수가나 제도의 변경이다. 정부가 새로운 수가 기준을 발표하고 특정 날짜부터 적용한다고 가정해 보자. HIS도 그 날짜에 맞춰 바뀌어야 한다.
하지만 병원마다 프로그램 버전과 개별 수정 내용이 다르면 같은 수가 변경을 적용하는 일도 단순하지 않다. 어떤 병원은 바로 패치를 적용하지만, 다른 병원은 이전 버전의 프로그램을 먼저 업데이트해야 한다. 연계 시스템에 미치는 영향을 확인하고 병원 내부의 검수와 승인 절차도 거쳐야 한다.
같은 제도 변경인데도 실제 반영 시점은 병원마다 달라진다.
반면 공통 제품 체계와 중앙화된 배포 구조를 갖추면 공통 기능을 한 번 개발하고 통합 검증한 뒤 여러 병원의 버전과 적용 상태를 일관되게 관리할 수 있다. 병원별 승인과 검증 절차는 유지하면서도 어떤 병원에 어떤 버전이 적용돼 있는지 중앙에서 파악하고, 문제가 발견되면 공통 수정 패치(Hot-fix)를 개발해 빠르게 확산하는 것이다.
개발과 테스트, 배포 과정을 자동화하는 CI/CD 체계 역시 이런 구조를 뒷받침한다. 병원별 검증을 생략하는 것이 아니라, 공통으로 수행할 작업과 기관별로 확인할 작업을 구분해 반복 부담을 줄이는 데 의미가 있다.
새로운 기능을 한 병원에서 끝내지 않고 여러 병원으로 빠르게 확산할 수 있다는 점도 중요하다. 공통 제품 체계에서는 한 기관에서 검증된 기능을 다른 의료기관에도 큰 구조 변경 없이 적용하기가 쉬워진다.
◇작은 기능 하나를 고치기 위해 전체 시스템을 건드려야 할까
클라우드 네이티브를 설명할 때 마이크로서비스아키텍처(MSA), 컨테이너(Container), 쿠버네티스(Kubernetes) 같은 기술 용어가 자주 등장한다. 물론 중요한 기술들이다. 하지만 더 중요한 것은 그 기술들이 실제 운영에서 어떤 차이를 만들어내느냐다.
예를 들어 간호 업무에 새로운 기능 하나를 추가한다고 생각해 보자. 하나의 거대한 단일 프로그램에서는 작은 기능을 수정하더라도 다른 업무에 영향을 주지 않는지 폭넓게 확인해야 한다. 배포할 때도 전체 시스템을 함께 업데이트해야 하는 경우가 많다.
반대로 기능이 적절한 서비스 단위로 나뉘어 있다면 필요한 부분만 수정하고 검증해 배포할 수 있다. 간호 기능을 개선하기 위해 전체 시스템을 다시 배포하는 부담을 줄이는 것이다.
특정 서비스에 사용자가 몰리면 시스템 전체의 서버를 늘리는 것이 아니라 그 서비스에 필요한 자원만 선택적으로 확장할 수 있다. 사용량의 변화에 맞춰 필요한 부분에 자원을 배분하는 방식이다.
장애가 발생했을 때도 마찬가지다. 하나의 기능에서 발생한 문제가 다른 진료 업무까지 번지지 않도록 격리하고, 어느 서비스에서 문제가 생겼는지 빠르게 찾아 복구할 수 있어야 한다.
즉, 클라우드 네이티브의 핵심은 프로그램을 여러 조각으로 나누는 것 자체가 아니다. 필요한 기능을 독립적으로 바꾸고 배포하며, 필요한 만큼 확장하고, 장애가 다른 업무로 확산되지 않도록 만드는 구조가 중요하다.
◇중요한 것은 변화하는 방식이다
앞선 2편에서 살펴봤듯 AI 네이티브 HIS에는 새로운 AI를 지속적으로 받아들이고 교체할 수 있는 기반이 필요하다. 공통 데이터 규칙과 표준화된 API, 인증·권한 체계를 갖추면 AI와 HIS 사이의 핵심 연결 구조를 공통화할 수 있다. 병원별 보안 검증과 업무 적용 절차는 유지하되, 새로운 AI가 등장할 때마다 연결 구조를 처음부터 다시 만드는 일을 줄이는 것이 핵심이다.
결국 클라우드 네이티브의 경쟁력은 어떤 기술을 사용했다는 사실 자체에 있지 않다. 변화하는 기능과 서비스를 얼마나 독립적으로 개선하고, 안전하게 배포하고, 필요한 만큼 확장하며, 여러 의료기관으로 확산할 수 있는가에 있다.
클라우드 전환이 주로 서버와 인프라를 운영하는 방식의 변화라면, 클라우드 네이티브는 HIS를 만들고, 고치고, 배포하고, 운영하며 지속적으로 진화시키는 방식 자체의 변화다.
이 차이는 처음 시스템을 도입하는 순간보다 시간이 지날수록 더 분명해진다. 병원이 늘어나고 제도가 바뀌며 새로운 기능과 AI가 추가될수록 시스템 구조의 차이는 변화의 속도와 확장성, 안정성의 차이로 나타난다.
AI 시대에는 HIS를 클라우드 인프라 위에서 실행하는 것만으로는 충분하지 않다. 새로운 기술과 AI를 지속적으로 받아들이고 여러 의료기관으로 안정적으로 확산할 수 있도록 시스템 자체가 설계돼 있어야 한다. 이것이 단순한 '클라우드 인프라 전환'을 넘어 '클라우드 네이티브 아키텍처'로 나아가야 하는 이유다.
이기혁 분당서울대병원 가정의학과 과장·이지케어텍 사업총괄 겸임 strategy@ezcaretech.com
