Jump to section

마이크로서비스가 의료 부문에서 IT 통합을 지원하는 방식

URL 복사

마이크로서비스는 의료 및 기타 업종의 개발자가 탄력적으로 결합된 서비스로 구성된 애플리케이션을 만들 수 있도록 지원하므로 개발자는 더 쉽게 개발, 테스트, 배포, 업그레이드를 수행할 수 있습니다. 이러한 이점으로 인해 의료 부문 개발자는 이전 세대의 IT 통합 기술인 엔터프라이즈 서비스 버스(ESB)보다 마이크로서비스를 수용하고 있습니다.

모든 대기업과 마찬가지로 의료 기관의 IT 환경은 미션 크리티컬 데이터를 공유해야 하는 다양한 시스템이 과도하게 확장되어 결합된 형태입니다. 입원/퇴원 및 이송 시스템(ADT), 예약 시스템, 랩 시스템, 방사선 진단 시스템, 청구 시스템 등 몇 가지만 보더라도 모두 통신 기능이 필요하며 이러한 시스템에서 발생하는 데이터는 응급 상황에서 생명과 직결될 수 있습니다.

디지털 시대를 맞아 의료 기관은 전자의무기록(EHR)을 도입했지만 이 데이터를 그러한 여러 애플리케이션 간에 공유할 수 없다면 EHR의 가치는 제한적일 수밖에 없습니다. 의료 시스템 통합이라는 과제는 수십 년 전인 1987년으로 거슬러 올라갑니다. 당시 의료 분야에서 사용되는 애플리케이션 간 임상 및 관리 데이터 전송을 위한 전 세계 표준인 HL7(Health Level Seven)이 확립되었습니다. 이러한 공용어가 확립된 후 의료 산업에서는 HL7을 통해 통신할 수 있도록 애플리케이션을 연결하는 방법이 필요했습니다.

수년 전에 IT 실무자들은 각 애플리케이션 간 직접적인 포인트 투 포인트 연결이 비실용적이며 기업이 성장할수록 더 해결하기 어려운 과제가 된다는 것을 알게 되었습니다. 또한 HL7이 범용 형식을 제공하긴 했지만 필드를 해석할 공통된 방식이 없었으므로 의료 시스템 간 통신을 지원하려면 연결성뿐만 아니라 데이터 트랜스포메이션이 필요했습니다.

의료 기관이 도입한 최초의 통합 기술은 병원 내 모든 시스템 사이에서 허브 역할을 하는 서버인 인터페이스 엔진(IE)이었습니다. 각 시스템은 IE에 연결되고, IE는 데이터를 변환하여 필요에 따라 다른 시스템으로 라우팅하는 방식입니다. 그리고 약 20년 전 엔터프라이즈 서비스 버스(ESB)가 등장했습니다. IE와 마찬가지로 ESB는 의료 애플리케이션 간에 주로 HL7을 사용해 데이터를 교환하는 허브의 역할을 합니다. ESB는 손쉬운 관리 및 모니터링 기능뿐 아니라 데이터 변환, 프로토콜 변환, 라우팅, 웹 서비스 지원, JMS, HTTP, SOAP도 제공합니다. ESB는 지난 20년간 의료 부문뿐 아니라 다른 업종에서도 가장 인기 있는 통합용 솔루션이었습니다.

ESB 도입 후 애플리케이션 개발은 상당히 발전했습니다. 가장 중요한 변화 중 하나는 ESB를 넘어 애자일 개발 및 DevOps로 전환한 것이었습니다.

DevOps 파이프라인은 점진적 변화와 지속적인 자동화 테스트에 기반을 둔 개발 라이프사이클입니다. DevOps 시대에는 한때 ESB의 장점으로 여겨졌던 특성들이 오히려 장애가 되고 있습니다. ESB는 모든 통합을 하나의 모놀리스에 배포하는 방식입니다. 이런 방식은 과거에는 장점이었지만 지금은 ESB가 DevOps와 호환되지 않게 만드는 문제점이 되었습니다.

현대적인 개발 환경에서 ESB는 다음과 같은 한계가 있습니다.

  • 애자일 개발자 및 DevOps 툴과의 비호환성: 오늘날 대학을 갓 졸업한 신규 개발자 중 다수는 DevOps 환경에서 교육을 받습니다. 이러한 애자일 개발자들은 최근에 출시된 DevOps 솔루션을 선호하며 이 툴을 사용할 때 생산성이 가장 높지만, ESB는 이러한 툴을 지원하도록 설계되지 않았습니다.
  • 전체 시스템에 영향을 주는 변경 사항: 약간이라도 ESB에 관한 규칙을 변경해야 하는 경우 전체 엔진을 일시 정지해야 합니다. 이는 운영 중단을 초래하는 비생산적인 다운타임이 ESB와 상호 작용하는 모든 애플리케이션에 발생한다는 의미입니다. 이와 마찬가지로 변경 사항으로 인해 발생하는 오류는 모든 통합에 영향을 미칠 가능성이 있습니다. 그 결과, 팀 내에 업그레이드와 수정을 거부하는 비생산적인 분위기가 형성될 수 있습니다.
  • 단일 장애 지점: 모든 통합이 동일한 허브를 통해 라우팅되기 때문에 ESB는 전체 엔터프라이즈를 위한 단일 장애 지점이 됩니다. ESB가 다운되면 모든 통합이 다운됩니다.
  • 자동화된 테스트 불가능: 자동화된 테스트는 DevOps의 핵심 구성 요소입니다. DevOps 파이프라인에서 모든 업데이트는 독립적으로 테스트되므로 개발 프로세스에 지장을 주지 않습니다. 테스트는 자동화를 통해 수행되지만, ESB는 독점 GUI 및 버전 관리로 인해 자동화가 불가능합니다.

다른 업종과 마찬가지로 의료 부문은 새로운 개발 사례인 마이크로서비스, DevOps, 애자일을 수용해 왔습니다. 또한 이러한 수용이 의료 서비스 통합으로 확장됨에 따라 새로운 애플리케이션 및 디지털 접점은 HL7, REST 및 기타 프로토콜로 통합되어야 합니다. 의료 부문의 마이크로서비스 개발자는 자신이 개발하는 다른 코드(예: 데이터, 스트리밍, GUI, 명령 및 제어 등)와 함께 통합을 제어하고 CICD를 통해 이동하는 배포 가능 유닛에 모든 변경 사항을 패키징하고 싶어 합니다. 앞서 언급한 제약 때문에, 다른 코드가 포함된 통합 코드를 지원하는 CICD의 이러한 목표를 달성하기가 어렵습니다.

마이크로서비스가 주요 개발 방식이 되어가고 있지만, ESB는 이와 호환되지 않습니다. ESB는 모놀리식인 반면, 마이크로서비스는 그 반대이므로 개발자는 느슨히 결합된 서비스의 구성 요소를 사용해 애플리케이션 및 통합을 생성할 수 있습니다. 애플리케이션을 독립적인 모듈로 분할하면 개발, 테스트, 변경, 재테스트, 수정, 배포, 프로덕션 단계의 테스트, 업그레이드 등을 더 쉽게 할 수 있습니다.

마이크로서비스는 자동화된 테스트를 지원하므로 DevOps가 가능합니다. 마이크로서비스는 작은 구성 요소에 해당하므로 컨테이너에 쉽게 맞출 수 있습니다. 따라서 테스트 프로세스를 자동화하고 지속적 통합 및 지속적 제공(CI/CD)을 촉진할 수 있습니다. 반면, 모놀리식 ESB는 너무 커서 컨테이너에 맞출 수 없고, 구성 요소로 분할할 수 없으므로 동일한 방식으로 테스트할 수 없습니다.

하지만 마이크로서비스 기반 통합을 도입해야 하는 가장 중요한 이유는 애자일 개발자가 선호하는 DevOps 툴을 사용하도록 지원할 수 있다는 점입니다. 이러한 상황에서 ESB를 제거하면 개발자는 자신이 선호하는 익숙한 애자일 개발 환경에서 자유롭게 작업할 수 있습니다. ESB가 없으면 개발자는 독점 시스템에서 교육을 받지 않아도 됩니다. 그 대신 더 생산적인 개발 방식에 집중할 수 있습니다.

또한 마이크로서비스는 ESB 전문가로 구성된 고립된 팀으로 통합을 제한하기보다는 개발자가 자신의 통합 요구 사항을 탐색하도록 지원하여 보다 자유로운 통합을 가능하게 합니다. 애플리케이션 개발자만큼 애플리케이션의 데이터 요구 사항을 잘 아는 사람은 없기 때문에 이런 방식이 훨씬 합리적입니다.

또한 마이크로서비스는 API 관리도 지원하므로 필요한 경우 API 기반 통합이 가능합니다.

한편, 마이크로서비스 기반 통합은 그래픽 변환, 엔터프라이즈 내 데이터 흐름에 관한 상세 규칙을 생성하는 로직 등 ESB와 동일한 이점을 제공합니다. 예를 들어 ESB의 그래픽 개발 캔버스를 좋아하는 경우 마이크로서비스 기반 통합을 지원하는 유사한 환경을 활용할 수 있습니다.

마이크로서비스 기반 통합에는 다음과 같은 몇 가지 핵심 장점이 있습니다.

  • 통합 모니터링 및 관리: 마이크로서비스를 애자일 개발자가 선호하는 최신 툴(즉 Kibana, Elasticsearch, Grafana, Prometheus 등)로 모니터링하여 장애 지점을 파악함으로써 비즈니스에 영향을 줄 정도로 문제가 커지기 전에 해결할 수 있습니다.
  • 자동화된 테스트: 마이크로서비스와 DevOps의 최대 장점 중 하나는 자동화된 테스트를 수행할 수 있다는 점입니다. 각 통합은 해당 애플리케이션 또는 다른 애플리케이션의 다른 구성 요소에 지장을 주지 않고 테스트 과정을 통과하면서 독립적 구성 요소로 취급됩니다.
  • 탁월한 소프트웨어 품질: 결국 더 효율적인 프로세스와 향상된 테스트는 소프트웨어 품질을 한층 높여줍니다.
  • 개발 기간 단축: DevOps 및 자동화로 통합 개발 프로세스를 간소화하고 수작업으로 진행되던 프로세스를 제거함으로써 개발 라이프사이클이 단축됩니다.
  • 확장성 강화: 애플리케이션은 독립적인 모듈로 구성되므로 각 서비스를 애플리케이션의 나머지 요소에 영향을 미치지 않으면서 독립적으로 확장할 수 있습니다.
  • 첨단 혁신: 마이크로서비스와 DevOps는 개발자가 혁신적인 통합 솔루션을 개발하도록 지원하므로, 조직은 새로운 서비스를 도입하고 고객에게 더 나은 서비스를 제공할 수 있습니다.
  • 비즈니스 민첩성: 애자일 개발은 시장의 변화에 신속히 대응할 수 있는 비즈니스 민첩성 획득으로 자연스럽게 이어집니다. 예를 들어, 애자일 개발 팀이 마이크로서비스를 활용해 비즈니스 관계를 지원하는 데 필요한 통합을 신속하게 구축하므로 데이터 공유가 필요한 새로운 파트너 또는 벤더는 신속히 온보딩될 수 있습니다.
  • 고객 경험 개선: 의료 기관의 기본적인 목표는 매일 의료 서비스를 이용하는 환자인 고객에게 서비스를 제공하는 것입니다. 프로세스를 개선하고 시스템과 부서 간에 원활하게 데이터를 공유하면 궁극적으로 환자의 만족도가 높아집니다.

통합을 마이크로서비스로 마이그레이션하는 태스크가 상당히 어렵게 느껴질 수 있습니다. 그런데 왜 변화가 필요할까요? IT 팀은 수년간 의존해온 독점적인 ESB에 이미 익숙해져 있는데, 바로 거기에 문제가 있습니다. ESB 전문가 한두 명이 조직을 떠나면 어떤 일이 생길까요? 기술 수준을 회복하기 위해 어떤 대가를 치러야 할까요?

이러한 모놀리식 ESB를 넘어서는 것이 너무나 어려운 일처럼 보인다는 사실 자체가 바로 이 문제를 해결해야 하는 이유입니다. ESB의 한계에서 벗어나게 되면 완전히 새로운 차원의 통합이 주는 이점을 누릴 수 있습니다.

이벤트 메쉬 활용 사례

이벤트 기반 아키텍처는 이벤트 메쉬와 함께 다양한 애플리케이션 스택을 사용해 복잡한 멀티클라우드 광역 분산 토폴로지 전반에 걸쳐 배포된 광범위한 활용 사례를 지원할 수 있습니다. 다음은 여러 가지 잠재적 이벤트 메쉬 활용 사례 중에서 뽑은 샘플입니다.

마이크로서비스 통합

이벤트 메쉬는 레거시 기술을 비롯해 마이크로서비스 기반 애플리케이션을 서로 손쉽게 연결합니다.

전자상거래

이벤트 메쉬는 트랜잭션을 신속히 처리할 수 있도록 지원하여 웹사이트 및 애플리케이션을 통한 빠르고 안정적인 고객 상호 작용을 보장합니다.

고객 지원

이벤트 메쉬는 고객 상호 작용 데이터를 신속히 제공하도록 지원하므로, 지원 팀은 고객의 요청에 실시간으로 응답하고 맞춤형 경험을 구현할 수 있습니다.

금융 서비스

이벤트 메쉬는 금융 서비스 제공업체가 실시간 트레이딩 데이터를 동기화하는 데 걸리는 대기 시간을 단축할 수 있도록 지원합니다. 또한 이벤트 메쉬는 의심스러운 트랜잭션에 대한 정보를 실시간으로 전달하여 사기를 감지할 수 있도록 해줍니다.

IoT 연결성

이벤트 메쉬는 백엔드 시스템에 신뢰할 수 있고 확장 가능한 사물 인터넷(IoT) 연결성을 제공하므로 거의 모든 센서에서 메트릭을 처리할 수 있습니다.

이벤트 메쉬는 비즈니스에 다음과 같은 실질적 이점을 제공합니다.

실시간 응답성

비즈니스 성공 여부는 변화에 대응하는 능력에 달려 있습니다. 이벤트 메쉬의 주요 이점 중 하나는 데이터를 이벤트 기반 아키텍처를 통해 이벤트 스트림으로 실시간 제공하므로 때맞춰 대응할 수 있다는 것입니다. 이벤트 메쉬는 이벤트 생성자와 이벤트 소비자 간 최단 경로를 결정하여 메시징 대기 시간을 사실상 제거하므로 매우 효율적입니다. 이를 통해 비즈니스 이해관계자가 긴급한 의사 결정을 요구하는 중대한 문제에 민첩하고 신속히 대응할 수 있도록 합니다.

고객 경험 개선

이벤트 메쉬는 고객 대면 팀과 전자 상거래 기술에 사용하는 데이터를 실시간으로 제공하도록 지원하므로 궁극적으로 조직은 서비스를 통해 고객 경험을 개선할 수 있습니다.

운영 비용 절감

이벤트 메쉬는 제조, 영업, 재고, 배송 상황을 실시간으로 파악할 수 있게 해주므로 조직은 운영을 최적화하고, 효율성을 높이고, 비용을 줄일 수 있습니다.

개발자 생산성

애플리케이션 개발자는 다양한 유형의 환경, 메시징 시스템, 프로토콜에 구애받지 않는 이벤트 메쉬의 지원을 받아 최적의 기술을 사용해 비즈니스 로직을 구현하는 데 집중할 수 있습니다. 이를 통해 개발자는 개발 환경, 메시징 플랫폼, 클라우드 유형에 대한 제한 없이 복잡한 데이터 분산 네트워크를 개발하지 않고도 자유롭게 혁신 역량을 발휘할 수 있습니다.

Keep reading

문서

마이크로서비스가 의료 부문에서 IT 통합을 지원하는 방식

마이크로서비스는 의료 및 기타 업종의 개발자가 탄력적으로 결합된 서비스로 구성된 애플리케이션을 만들 수 있도록 지원하므로 개발자는 더 쉽게 개발, 테스트, 배포, 업그레이드를 수행할 수 있습니다.

문서

마이크로서비스란?

마이크로서비스란 애플리케이션을 구축하기 위한 아키텍처 기반의 접근 방식으로 애플리케이션의 각 요소가 독립적으로 작동합니다.

문서

서비스 메쉬란 무엇일까요?

서비스 메쉬는 애플리케이션에 구축된 인프라 레이어로, 서비스 상호작용을 통해 보다 손쉽게 통신을 최적화하고 다운 타임을 줄이는 방법을 기록합니다.

마이크로서비스 상세 정보

제품

Red Hat OpenShift

자동화된 풀스택 오퍼레이션으로 하이브리드 클라우드, 멀티클라우드 및 엣지 배포를 관리하는 엔터프라이즈급 쿠버네티스 컨테이너 플랫폼입니다.

리소스

웨비나

100% 비대면으로 진행하는 Red Hat OpenShift PoC 활용 가이드 온라인 세미나 1일차 : 클라우드 네이티브

웨비나

100% 비대면으로 진행하는 Red Hat OpenShift PoC 활용 가이드 온라인 세미나 2일차: 디지털 트랜스포메이션

교육

무료 교육 과정

Developing Cloud-Native Applications with Microservices Architectures

Illustration - mail

유용한 콘텐츠 더 보기

Red Hat Shares 뉴스레터를 구독해 보세요(무료).