주제 4.0 — 기술 아키텍처, 클라우드 및 레거시

보건·돌봄에서 기술 아키텍처는 수년 앞서 내려지는 임상 안전, 보안, 공적 자금의 결정이다. 세우는 플랫폼과 그대로 두는 레거시는, 그것을 선택한 사람들이 떠난 뒤에도 오랫동안 돌봄이 안전하고, 연결되고, 감당할 만할 수 있는지를 조용히 결정한다.

보건·돌봄에서 이것이 중요한 이유#

아키텍처는 디지털 서비스 밑에 있는 오래 지속되는 구조적 선택의 집합이다. 무엇이 어디서 실행되는지, 구성 요소가 어떻게 연결되는지, 무엇을 만들고 무엇을 살지, 과거의 무엇을 계속 살려 둘지다. 이러한 선택은 환자나 임상의에게 거의 보이지 않고 이사회에는 거의 흥미롭지 않다. 그러나 그 위에 놓인 모든 것을 형성한다. 잘 설계된 자산은 새 서비스를 빠르게 추가하고, 데이터를 안전하게 공유하며, 무언가 고장 났을 때 빠르게 복구하게 해 준다. 잘못 설계된 자산은 모든 변경을 느리게, 모든 통합을 취약하게, 모든 인시던트를 더 나쁘게 만든다.

보건·돌봄에서는 시스템이 중대한 결과를 낳으므로 위험이 크다. 노후한 환자 행정 시스템이 무너지면 구급차가 우회하고 클리닉이 취소된다. 지원이 끝난 운영체제가 악용되면 기밀 기록이 노출되고 서비스가 멈춘다. NHS가 2017년 더 이상 패치할 수 없는 소프트웨어를 실행하던 기기를 통해 WannaCry 랜섬웨어 공격이 퍼졌을 때 배운 것처럼 말이다. 그 중단은 영리하고 표적화된 공격이 아니었다. 핵심 시스템에 쌓인 기술 부채의 예견된 결과였다. 따라서 아키텍처 결정은 누가 그렇게 규정하든 말든 안전 결정이다.

그것은 형평성과 신뢰의 결정이기도 하다. 데이터를 공유할 수 없는 레거시 시스템은 여러 서비스에 닿는 가장 복잡한 환자들에게 가장 파편화된 기록을 남긴다. 단일 공급업체에 가두는 폐쇄형 플랫폼은 돌봄에 재원을 댈 수 있는 돈을 빼앗는다. 그리고 대중은 NHS가 현대적이고, 안전하고, 잘 유지되는 기술로 운영되기를 당연히 기대하며, 그 기대와 실제 자산 사이의 간극은 그 자체로 신뢰에 대한 위험이다.

마지막으로, 여기는 많은 공적 자금이 아주 오랫동안 약속되는 곳이다. 시스템의 가장 비싼 부분은 구매가 아닌 경우가 드물다. 뒤따르는 십 년의 호스팅, 라이선싱, 유지보수, 결국의 교체다. 아키텍처를 "기술 팀이 알아서 하는 것"으로 다루는 리더는 조직이 내리는 가장 크고 오래가는 재정적 약속 일부를 위임하는 것이다. 이 주제는 엔지니어가 아니어도 그러한 결정에 책임을 물을 수 있도록 쓰였다.

핵심 개념#

전사적 아키텍처는 조직의 업무 프로세스, 정보, 애플리케이션, 기술을 우연히 자라나는 대신 전략을 일관되게 지원하도록 정렬하는 학문이다. 조직 전체의 관점을 취한다. 어떤 역량이 필요한지, 어떤 시스템이 이를 제공하는지, 격차와 중복이 어디에 있는지다. 솔루션 아키텍처는 특정 서비스를 어떻게 구축하고 더 넓은 자산에 어떻게 맞출지 설계하는 더 좁은 프로젝트 수준의 학문이다. 둘 다 구성 요소, 인터페이스, 동작이 어떻게 결합해 작동하는 전체가 되는지의 구조 모델인 시스템 아키텍처라는 더 넓은 개념에 속한다. 리더가 이 학문들을 실천할 필요는 없지만 그것들이 존재하도록 고집해야 한다. 그 부재가 자산이 관리할 수 없게 되는 방식이기 때문이다.

아키텍처는 아키텍처 원칙, 곧 "구매하기 전에 재사용, 만들기 전에 구매"나 "개방형 표준에 맞춰 구축"처럼 모든 선택을 상향하지 않고도 일관된 결정이 가능하게 하는 짧고 합의된 진술의 집합이 이끈다. 원칙은 중요한 기술 결정을 검토하는 소규모 그룹인 설계 위원회(design authority)가 가볍게 시행한다. 건전한 설계 위원회는 막지 않고 가능하게 한다. 피할 수 있는 해악과 중복을 막기 위해 존재하며, 팀을 늦추거나 그 자체를 위해 문지기가 되려고 존재하지 않는다.

클라우드 컴퓨팅은 서버, 스토리지, 데이터베이스, 네트워킹 같은 컴퓨팅을 자신의 건물에 있는 소유 하드웨어가 아니라 인터넷을 통한 온디맨드 서비스로 제공하는 것이다. 퍼블릭 클라우드는 제3자 제공자가 운영하며 많은 고객이 공유하고, 프라이빗 클라우드는 한 조직 전용이며, 하이브리드 클라우드는 둘을 결합해 흔히 일부 워크로드는 기존 인프라에 두고 다른 일부는 밖으로 옮긴다. 영국을 포함한 많은 정부가 "클라우드 우선" 정책을 채택했는데, 팀이 다른 선택지보다 먼저 퍼블릭 클라우드를 고려하고 사용하지 않는 이유를 정당화해야 한다는 뜻이다. 클라우드는 한 번 사는 것이 아니라 소비량으로 청구되므로, 그 지출을 통제하는 일이 자체 학문이 되었다. 엔지니어링과 재무를 한데 모아 팀이 클라우드 사용의 실제 비용을 보고 책임지게 하는 실천인 FinOps다. 애플리케이션 계층에서 서비스형 소프트웨어(SaaS)는 공급업체가 호스팅하고 유지하는 완성된 애플리케이션을 웹으로 제공하므로 직접 운영하지 않고 구성한다. 시스템이 물리적으로 어디서 어떻게 실행되는지인 인프라와 호스팅이 이 모든 밑에 있으며, 점점 결정에 들어가야 할 탄소 비용을 지닌다(주제 8.5 — 지속가능성 및 넷제로 참조).

레거시 시스템은 노후했지만 여전히 의존하는, 바꾸기 어려운 시스템으로, 흔히 보안 패치가 더 이상 나오지 않는 지원 종료 소프트웨어를 실행한다. 레거시는 과거에 내린 임시방편적 선택의 미래 비용인 기술 부채로 쌓인다. 약간의 부채는 정상이고 심지어 현명하지만, 규모에서 관리되지 않은 부채는 안전과 보안의 부채가 된다. 대부분의 사람이 의존하는 시스템이 아무도 감히 건드리지 못하는 시스템이 되기 때문이다. 이를 관리하는 일이 애플리케이션 포트폴리오 관리다. 모든 애플리케이션의 비용, 상태, 업무 가치에 대한 명확한 목록을 유지하여, 자산을 합리화하고(폐기, 교체, 통합) 오래된 것을 조용히 계속 돌리는 대신 안전하게 폐기할 수 있게 한다.

현대의 자산은 한 시스템이 다른 시스템에 역량을 제공하는 정의된 인터페이스인 애플리케이션 프로그래밍 인터페이스(API)로 묶여 있다. 잘 설계된 API는 구성 요소를 느슨하게 결합되고 교체 가능하게 유지하면서 플랫폼, 곧 많은 팀이 위에 쌓는 재사용 가능한 서비스를 조립하게 해 준다. 여기서 유용한 규율은 "가장 얇은 실행 가능한 플랫폼"이다. 다른 이들의 일을 진정으로 줄이는 공유 역량만 구축하고 그 이상은 하지 않는다. 안전한 설계의 밑바탕은 보안을 나중에 덧붙이는 대신 처음부터 내장하는 원칙인 설계 단계 보안(secure by design)이다. 그리고 이 모든 것의 재무적 틀이 총 소유 비용(TCO), 곧 구매 가격이 아니라 시스템의 전 수명 비용이며, 구축/구매/구성 선택과 공급업체 종속의 위험을 판단하는 렌즈다.

모범 사례#

1. 짧은 아키텍처 원칙 집합에 합의하고 그것으로 결정하라. 명확하고 기억하기 쉬운 원칙 몇 가지를 적으라. 구매 전 재사용, 구축 전 구매, 개방형 표준에 맞춰 구축, 말이 되는 곳에서는 클라우드, 설계 단계 보안, 돌봄 경로 전체를 위한 설계다. 그리고 팀이 이를 적용해 대부분의 결정을 스스로 내리게 하라. 원칙은 실제로 예와 아니오를 말하는 데 쓰일 때만, 그리고 기억할 만큼 적을 때만 작동한다. 이는 원칙이 섬기는 방향을 정하는 주제 1.1 — 운영 모델 및 주제 1.2 — 디지털 전략 및 로드맵 수립과 직접 이어진다.

2. 막지 않고 가능하게 하는 설계 위원회를 운영하라. 비싸거나, 되돌리기 어렵거나, 많은 서비스에 영향을 주거나, 안전 및 보안 위험을 지닌 중요한 기술 결정을 검토할 소규모의 고위 다학제 그룹을 세우라. 일상적 선택이 거기에 끌려 들어가지 않도록 빠르고 가벼운 경로를 주고, 서비스 표준에 따르게 하라. 단지 거부하지 않고 팀이 좋은 답을 찾도록 도와야 한다. 병목이 된 설계 위원회는 우회되며, 그림자 아키텍처는 없는 것보다 나쁘다.

3. 클라우드를 구호가 아니라 워크로드별로 신중하게 채택하라. "클라우드 우선"을 모든 것을 옮기라는 지시가 아니라 따져 볼 기본값으로 다루라. 각 워크로드를 적합성, 데이터 거주, 회복탄력성, 규모에서의 비용, 이전 노력에 대해 평가하고, 바꾸지 않은 레거시 애플리케이션의 리프트 앤 시프트는 흔히 문제를 더 높은 비용으로 옮길 뿐임에 정직하라. 어디서 어떻게 호스팅하는지가 배출에 영향을 주므로 탄소 차원을 명시적으로 따지고(주제 8.5 — 지속가능성 및 넷제로 참조), 나중에 제공자 사이를 옮길 수 있도록 이식성을 위해 설계하라.

4. 살아 있는 애플리케이션 포트폴리오를 유지하고 기술 부채를 명명된 위험으로 관리하라. 모든 애플리케이션의 업무 소유자, 비용, 지원 가능성, 지닌 위험의 정확한 목록을 유지하고 정기적으로 검토하라. 기술 부채와 지원 종료 소프트웨어를 임상이나 재무 위험과 같은 진지함으로 기업 위험 등록부에 올리라. 실제로 그렇기 때문이다. 볼 수 없는 것은 재원을 대거나, 우선하거나, 안전하게 폐기할 수 없으며, 한 번도 목록화되지 않은 자산이 경고 없이 실패하는 바로 그 자산이다.

5. 자산을 합리화하고 안전하게 폐기하라. 중복되고, 낡고, 수명이 끝난 시스템을 "혹시 몰라서" 남겨 두지 말고 적극적으로 폐기하라. 라이브 시스템마다 공격 표면, 라이선스 비용, 유지보수 부담이기 때문이다. 폐기는 그 자체로 하나의 프로젝트다. 명확한 보존 규칙에 따라 데이터를 이전하거나 보관하고, 아무것도 그 시스템에 여전히 의존하지 않음을 확인하고, 사용자에게 알리고, 끄기 전에 검증하라. 잘하면 합리화는 돈을 풀어 주고 위험을 줄이며, 부주의하게 하면 기록을 파괴하거나 아무도 문서화하지 않은 의존성을 깬다.

6. 개방형 표준, API, 느슨하게 결합된 구성 요소를 선호하라. 역량이 문서화되고 버전이 매겨진 API를 통해 노출되도록 설계하여, 한 구성 요소를 그 주변 모든 것을 다시 만들지 않고 교체할 수 있게 하라. 이는 주제 4.3 — 상호운용성 및 데이터 표준에서 논의하는 상호운용성의 아키텍처적 토대이며 종속에 대한 주된 방어다. 직접 하드와이어된 연결보다 초기에 약간 더 비용이 들지만, 공급업체를 바꾸거나 서비스를 추가해야 하는 첫 번째 순간에 몇 배로 보답한다.

7. 가장 얇은 실행 가능한 플랫폼을 만들고, 그 이상은 하지 말라. 다른 이들이 위에 쌓을 공유 플랫폼을 만들 때, 첫날부터 포괄적으로 만들려는 충동에 저항하라. 팀의 일을 진정으로 덜어 주는 가장 작은 재사용 가능한 역량을 제공하고, 쓰임을 증명하고, 실제 수요에 응해 키워 나가라. 과도하게 만들어진 플랫폼은 그 자체가 레거시가 된다. 비싸고, 경직되고, 원망받는다. 반면 잘 운영되는 얇은 플랫폼은 채택을 얻고 필요와 함께 진화한다.

8. 보안 아키텍처와 설계 단계 보안을 타협할 수 없게 하라. 보안적 사고를 출시 전 관문이 아니라 첫 스케치부터 설계에 들이라. 공격 표면을 최소화하고, 최소 권한을 적용하고, 네트워크를 분할하며, 구성 요소가 탐침당할 것으로 가정하라. 보건·돌봄에서 이는 임상 안전과 정보 거버넌스(주제 1.6 — 임상 안전 및 위험 관리, 주제 1.7 — 정보 거버넌스, 데이터 보호 및 사이버 보안)와 떼어낼 수 없다. 침해는 데이터 해악이면서, 시스템을 멈추면 환자 안전 사건이기 때문이다. 지원되지 않고 패치할 수 없는 소프트웨어는 기본적으로 내리고 있는 보안 결정이므로, 의도적으로 완화책과 함께 내리거나 아예 하지 말라.

9. 구축, 구매, 구성은 표시 가격이 아니라 총 소유 비용으로 결정하라. 각 역량에 대해 맞춤 구축, 제품 구매, 기존 플랫폼 구성을 호스팅, 라이선싱, 통합, 지원, 업그레이드, 결국의 퇴출을 포함한 전 수명 비용으로 비교하라. 초기 가격이 아니다. 일반적인 필요에는 구매나 구성을 선호하고 구축은 진정한 차별화에 남겨 두며, 각 선택이 만드는 종속을 따지라. 상업 담당 동료와 함께 이를 따져 보라(주제 6.3 — 조달 및 상업 계약 참조). 개방형 인터페이스와 퇴출 권리를 확보하기에 가장 저렴한 때는 서명 전이기 때문이다.

10. 클라우드 지출을 엔지니어링과 재무의 공동 규율(FinOps)로 다루라. 클라우드 자원을 소유자에게 태깅하여 팀이 서비스가 얼마의 비용이 드는지 명확히 보게 하고, 실제 사용량에 맞춰 인스턴스 크기를 조정하며, 유휴 또는 과잉 프로비저닝된 자원을 매달 값을 치르는 대신 꺼라. 서비스를 운영하는 팀이 그 운영 비용에 책임지게 하여 낭비를 줄일 가장 좋은 위치에 있는 사람들이 청구서를 보게 하라. 이 규율 없는 종량제 클라우드는 돌봄에 재원을 대야 할 예산을 조용히 소비하며, 그 표류는 청구서가 질문을 강제하기 전까지 알아채기 어렵다.

11. 비용을 탄소와 회복탄력성에 견주어 따지는 일급 비기능 요구사항으로 아키텍처하라. 비용을 성능, 보안, 가용성처럼 다루라. 의도적으로 설계하고, 구축 전에 추정하고, 사용량이 늘면서 검토하는 속성이다. 탄소(주제 8.5 — 지속가능성 및 넷제로 참조)와 회복탄력성에 명시적으로 견주어 따지라. 세 가지는 함께 움직이는 경우가 많다. 그러나 안전, 복구 가능성, 환자 결과를 희생하며 가장 낮은 청구서를 쫓지 말라. 올바른 답은 따로 떼어 본 가장 싼 선택이 아니라 임상 안전과 회복탄력성 의무를 여전히 충족하는 가장 낮은 비용이다.

팀과 논의할 질문#

1. 우리의 핵심 시스템 중 오늘 지원되지 않거나 패치할 수 없는 것은 무엇이며, 하나가 공격받거나 실패하면 실제 노출은 어떠한가? 임상 및 운영 서비스가 진정으로 없이는 기능할 수 없는 시스템에서 시작하여, 어느 것이 더 이상 보안 업데이트나 공급업체 지원을 받지 않는 소프트웨어를 실행하는지 구체적으로 밝히라. 각각이 랜섬웨어에 당하거나 그냥 멈추면 환자, 직원, 데이터에 무슨 일이 일어나고 복구에 얼마나 걸릴지 물으라. 완화책을 마련해 의식적으로 위험을 수용한 시스템과 누구도 취약성을 평가하지 않은 시스템을 구별하라. 이 노출이 기업 위험 등록부에 보이는지, 이사회가 본 적 없는 스프레드시트에 묻혀 있는지 생각하라. WannaCry를 돌아보라. 해악은 정교함이 아니라 핵심 시스템의 알려졌으나 다뤄지지 않은 부채에서 왔다. 증거로 이에 답할 수 없다면, 그 간극 자체가 가장 시급한 발견이다. 이름을 붙이지 않은 위험에는 재원을 댈 수 없기 때문이다.

2. 우리는 어디에 종속되어 있으며, 가장 큰 플랫폼을 떠나는 데 실제로 얼마가 들겠는가? 많은 조직이 폐쇄형 시스템의 진짜 가격을 바꾸려고 시도할 때야 발견한다. 가장 큰 임상 또는 기업 플랫폼에서 옮겨 가는 데 실제로 무엇이 필요한지 따져 보라. 데이터를 사용 가능한 표준 형태로 추출할 수 있는지, 어떤 독점 인터페이스를 풀어야 하는지, 계약이 소유권과 퇴출에 대해 무엇을 말하는지다. "클라우드"가 조용히 다른 종류의 종속이 되었는지, 데이터와 도구가 한 제공자에 너무 얽혀 떠나기 비현실적인지 생각하라. 이를 대안의 개방성, 그리고 대신 재사용할 수 있는 국가 플랫폼과 견주어 따지라. 이는 공급업체를 계속 바꾸라는 주장이 아니라, 다음에 협상하기 전에 자신의 영향력을 이해하고 한 공급업체의 로드맵이 유일한 선택지가 되지 않게 하라는 것이다.

3. 우리는 새롭고 눈에 띄는 것에만 투자하는가, 이미 가진 것을 유지하고 합리화하는 데도 충분히 투자하는가? 새 시스템은 재원과 주목을 끌지만, 패치, 업그레이드, 통합, 안전한 폐기라는 화려하지 않은 업무는 좀처럼 그렇지 못하며, 이것이 바로 부채가 쌓이는 방식이다. 디지털 예산의 몇 퍼센트가 기존 자산을 안전하고 최신으로 유지하는 데 가고 몇 퍼센트가 새로운 것을 만드는 데 가는지, 누군가 그 균형을 의도적으로 소유하는지 물으라. 폐기에 제대로 자원이 배정되는지, 끄는 것이 아무의 일도 아니어서 오래된 시스템이 그냥 남는지 논의하라. 조직 전반에서 같은 일을 하는 중복된 애플리케이션과, 이를 통합하는 데 무엇이 필요한지 생각하라. 개별 프로젝트가 아니라 자산 전체의 건강에 대해 이사회 수준에서 누가 책임지는지 생각하라. 새로운 것에만 재원을 대는 조직은 자신의 미래 안전을 담보로 빌리고 있으며, 상환은 늘 가장 나쁜 순간에 닥친다.

4. 우리 클라우드 비용이 얼마이고, 그 청구서를 누가 소유하며, 지출이 통제되는지 실제로 아는가? 종량제 클라우드는 돌봄에 재원을 대야 할 예산을 조용히 소비할 수 있고, 그 표류는 청구서가 질문을 강제하기 전까지 거의 알아채지 못한다. 클라우드 자원이 소유한 팀과 서비스에 태깅되어 있는지, 누군가 실제 사용량에 맞춰 인스턴스 크기를 조정하는지, 유휴 또는 과잉 프로비저닝된 자원을 끄기는 하는지 물으라. 서비스를 운영하는 사람들이 그 운영 비용을 보고 답하는지, 아니면 클라우드 지출이 아무도 분해할 수 없는 중앙 예산의 설명 없는 한 줄로 떨어지는지 논의하라. 비용이 구축 전에 추정되고 사용량이 늘면서 검토되는 일급 비기능 요구사항으로 다루어지는지, 사후에야 발견되는지 생각하라. 엔지니어링 자율성과 재무 통제 사이의 긴장, 그리고 가장 낮은 청구서를 쫓는 대신 비용을 탄소와 회복탄력성에 견주어 따지는 것에 대해 정직하라. 정직한 답은 누가 FinOps 규율을 쥐는지 명명하고, 클라우드가 현대적이라서 더 싸다고 가정하는 대신 그것이 작동한다는 증거를 보여 준다.

5. 새 역량이 필요할 때, 구축할지, 구매할지, 이미 가진 것을 구성할지 어떻게, 어떤 근거로 결정하는가? 맞춤 구축하려는 본능이나 최고의 시연을 가진 제품을 사려는 본능이 전 수명 비용을 비교하기도 전에 이기는 경우가 많다. 최근의 중요한 선택 몇 가지가 실제로 어떻게 내려졌는지 따져 보라. 호스팅, 라이선싱, 통합, 지원, 업그레이드, 결국의 퇴출이 고려되었는지, 초기 가격만 고려되었는지다. 구축은 진정한 차별화에 남겨 두고 일반적인 필요에는 구매나 구성을 기본으로 하는지, 아니면 한 팀이 선호했다는 이유로 맞춤 구축이 조용히 늘어나는지 물으라. 이 결정에 누가 참석하는지 — 엔지니어뿐 아니라 상업 및 임상 동료 — 와, 각 선택이 만드는 종속이 서명 전에 평가되는지 나중에 발견되는지 생각하라. 아키텍처 원칙("구매 전 재사용, 구축 전 구매")이 이러한 선택을 진정으로 구속하는지 조용히 무시되는지 돌아보라. 정직한 답은 표시 가격이 아니라 총 소유 비용이 결과를 바꾼 실제 결정을 가리킬 수 있다.

6. 우리 결정을 스스로 붙들 아키텍처 역량이 내부에 있는가, 아니면 책임을 물어야 할 공급업체에 의존하고 있는가? 아키텍처는 가장 크고 오래가는 약속이 이루어지는 곳이지만, 많은 조직이 그것을 잘 내리는 데 필요한 바로 그 역량을 속 비워 놓고, 평가 중인 제품의 공급업체에게 무엇이 좋은지 알려 달라고 의존한다. 우리 쪽에 신뢰할 만한 전사적 및 솔루션 아키텍처 기술이 있는지, 설계 위원회가 팀을 가능하게 하도록 인력이 있는지 단지 고무도장을 찍는지 물으라. 중대하고 되돌리기 어려운 결정이 합의된 원칙에 비추어 진정으로 시험되는지, 문제에 가장 가까운 공급업체에 사실상 위임되는지 논의하라. 이의를 제기할 독립적 전문성이 없다면 나쁜 아키텍처 권고를 어떻게 알아볼 수 있을지 생각하라. 이 역량을 구축하고 유지하는 비용을 그 부재가 낳는 종속과 재작업의 훨씬 더 큰 비용에 견주어 따지라. 정직한 답은 진정으로 소유할 수 있는 결정과 현재 신뢰에 맡기고 있는 결정을 구별한다.

실제 사례: 보건·돌봄 예시#

한 급성기 병원 트러스트의 기술 자산은 20년 동안 유기적으로 자랐다. 그 중심에는 공급업체가 18개월 전 지원을 중단한 운영체제에서 실행되는 환자 행정 시스템이 있고, 그 주위에는 이백 개가 넘는 애플리케이션이 있다. 많은 것이 부서별로 구매되었고, 여럿이 겹치는 일을 하며, 완전한 목록을 쥔 사람이 없다. 설계보다 운에 가까운 방식으로 막힌 랜섬웨어 시도라는 아차 사고가 이사회로 하여금 한 번도 던진 적 없는 질문을 하게 한다. 우리는 정확히 무엇을 운영하고 있으며 얼마나 노출되어 있는가?

최고 디지털 정보 책임자는 단일한 영웅적 "전부 교체" 프로그램을 시작하려는 본능에 저항하고, 지루한 일을 먼저 한다. 트러스트는 살아 있는 애플리케이션 포트폴리오를 구축한다. 모든 시스템, 업무 소유자, 지원 가능성, 비용, 위험이다. 그림은 냉정하다. 애플리케이션의 5분의 1이 지원 종료 소프트웨어에 있고, 열두 개는 다른 곳에 이미 있는 역량을 중복한다. 그러나 처음으로 그것이 보이고, 가장 나쁜 노출은 곧바로 이사회가 볼 수 있는 기업 위험 등록부에 올라간다.

그 목록에서 트러스트는 합의된 소수의 아키텍처 원칙에 이끌려 의도적 선택을 한다. 지원 종료된 환자 행정 시스템은 교체 우선순위가 되고, 트러스트가 다시 종속되지 않도록 개방형 API와 데이터 추출 권리를 계약에 명시한 구성 가능한 제품으로 조달한다. 적합한 워크로드는 구호가 아니라 하나씩 평가하여 퍼블릭 클라우드로 옮기며, 비용과 함께 탄소와 이식성을 따진다. 소규모 설계 위원회가 중요한 결정을 검토하고 일상적 결정은 빠르게 처리한다. 겹치는 부서 애플리케이션 열두 개가 세 개로 통합되고, 폐기된 시스템은 제대로 해체된다. 명확한 보존 규칙에 따라 데이터를 이전하고, 의존성을 확인하고, 사용자에게 알린 뒤에야 끈다.

이 어느 것도 헤드라인이 되지 않는다. 그러나 18개월 뒤 트러스트는 무엇을 운영하는지 알고, 가장 위험한 부채는 희망으로 사라지기를 바라는 대신 재원이 있는 계획으로 갚아 나가고 있으며, 교체 시스템이 개방형 API를 노출하기 때문에 새 공유 진료 기록 통합이 몇 주 만에 전달된다. 아차 사고는 트러스트가 아키텍처에 의해 관리되는 것을 멈추고 아키텍처를 관리하기 시작한 순간이 되었다.

부문별 관점#

스타트업#

디지털 보건 스타트업은 레거시가 거의 없는 사치를 누리며 이를 맹렬히 지켜야 한다. 처음부터 클라우드 네이티브로 구축하고, 개방형 API를 노출하며, 설계 단계 보안을 나중의 비용이 아니라 핵심 기능으로 다루라. 신중한 NHS 구매자가 보안 아키텍처와 데이터 추출 조건을 면밀히 검토할 것이기 때문이다. 자체의 가장 얇은 실행 가능한 플랫폼을 진정으로 얇게 유지하고, 아직 필요 없는 규모를 위해 과잉 설계하려는 유혹에 저항하라. 치명적인 기술 부채를 쌓는 가장 빠른 길은 투자자 압박 아래 임시방편 코드를 출시하고 한 번도 갚지 않는 것이므로, 어떤 부채를 질지 의도적이고 눈에 보이는 선택을 하라. 역설적으로, 고객이 데이터를 추출하고 떠날 수 있도록 설계하는 것이 그들을 붙들어 두는 신뢰를 얻는 길이다.

소규모 사업체#

확립된 소규모 제공자 — 일반의 진료소, 지역 약국, 요양원, 단일 사업장 클리닉, 또는 스타트업 단계를 지난 소규모 보건 기술 공급업체 — 는 대형 트러스트와 같은 의무를 지지만 자원은 일부이고 전담 IT 역량은 거의 없다. 여기서 아키텍처는 대체로 잘 사는 규율이다. 직접 인력을 둘 수 없는 호스팅, 패치, 보안을 공급업체가 지도록 평판 좋은 서비스형 소프트웨어를 선호하고, 서명 전에 계약의 데이터 추출 및 퇴출 권리를 읽으라. 영향력이 없을 때 종속이 가장 세게 물기 때문이다. 의존하는 소수의 시스템에 대한 단순한 목록을 유지하고 어느 것이 여전히 지원되는지 알라. 작은 자산도 진료소를 멈추게 하는 패치되지 않은 기기를 숨길 수 있다. 보안을 처음부터 평가하려 하지 말고, 공급업체가 Data Security and Protection Toolkit 같은 인정된 표준을 충족하도록 요구하라. 현금이 빠듯할 때 청구서를 피하려고 오래된 지원 종료 시스템을 계속 돌리고 싶은 유혹이 있지만, 그것은 표류가 아니라 의도적으로 내려야 할 안전 결정이다.

대기업#

대형 트러스트나 공급업체는 수십 년 치 누적된 시스템을 짊어지고 있어 그냥 새로 시작할 수 없다. 현실적인 전략은 규율 있는 진화다. 살아 있는 포트폴리오를 유지하고, 남아야 하는 것 앞에 개방형 API 기반 계층을 두며, 가장 위험한 부채를 가끔의 공황 속에서가 아니라 재원이 있고 우선순위가 정해진 계획으로 갚아 나가라. 막아서 두려움을 사는 것이 아니라 딜리버리를 가능하게 해서 존중받는 설계 위원회를 운영하고, 기술 부채를 지정된 소유자가 있는 상설 이사회 수준 위험으로 만들라. 갱신마다 종속을 경계하고, 폐기를 사후 고려가 아닌 실제로 자원이 배정된 업무로 다루라. 이는 주제 5.4 — 전사적 자원 관리(ERP)에서 핵심 운영 플랫폼을 다스리는 같은 재사용과 개방형 인터페이스의 규율이다.

정부#

국가 및 지역 기관은 분야 전체가 운영되는 조건을 정하며, 그 아키텍처 선택은 바깥으로 파급된다. 정부가 할 수 있는 가장 가치 있는 일은 개방형 표준을 의무화하고, 지역 조직이 한 번만 구축하도록 재사용 가능한 국가 플랫폼을 제공하며, 모든 곳의 바닥을 높이는 클라우드, 보안, 지속가능성 기대를 정하는 것이다. 결정적으로, 정부는 어떤 단일 조직도 혼자 재원을 대지 않지만 모두가 의존하는 화려하지 않은 국가적 업무 — 레거시 시정, 용어 유지, 폐기 지원 — 에 재원을 대야 한다. 널리 재사용되는 엄격히 시행된 충분히 좋은 표준이 일관성 없게 구현된 이론적으로 우월한 표준보다 낫다. 이러한 청지기 역할은 주제 9.1 — 지방 및 중앙 정부와의 협력, 그리고 주제 9.0 — 협력 기관과의 협업에서 파트너가 협력하는 방식과 이어진다.

흔한 실패 양상#

• 보이지 않는 자산. 정확한 목록 없이 수백 개 애플리케이션을 운영하여 노출이 알려지지 않고, 중복이 눈에 띄지 않으며, 취약성의 첫 신호가 장애나 침해다.
• 이사회에 숨겨진 부채. 지원 종료 소프트웨어와 기술 부채를 명명된 기업 위험이 아니라 기술적 각주로 두어, 실패할 때까지 재원이 마련되지 않는다.
• 구호로서의 클라우드. 원칙이라며 바꾸지 않은 레거시를 퍼블릭 클라우드로 리프트 앤 시프트하여 문제를 더 높은 비용으로 옮기거나, 데이터와 도구를 한 제공자에 너무 깊이 얽어 새로운 종속이 되게 한다.
• 병목으로서의 설계 위원회. 아키텍처 거버넌스가 팀이 우회하는 느린 관문이 되어, 없는 것보다 나쁜 문서화되지 않은 그림자 아키텍처를 낳는다.
• 구성해야 할 때 구축. 일반적인 필요에 총 소유 비용이 아니라 표시 가격을 근거로 맞춤 구축을 택하고, 예산에 없던 십 년의 유지보수를 물려받는다.
• 폐기 없음. 오래된 시스템을 "혹시 몰라서" 계속 돌려, 각각이 공격 표면, 라이선스 비용, 아무도 소유하지 않는 유지보수 부담이 된다.
• 덧붙여진 보안. 보안을 설계 입력이 아니라 출시 전 관문으로 다루어, 누군가 평가하기 한참 전에 공격 표면이 정해진다.
• 기본값으로서의 종속. 개방형 인터페이스나 데이터 추출 권리 없이 플랫폼에 서명하고, 떠나려 할 때야 함정의 비용을 발견한다.

성숙도 모델#

체크리스트#

• 살아 있는 애플리케이션 포트폴리오가 모든 시스템의 소유자, 비용, 지원 가능성, 위험을 기록하고 정기적으로 검토된다.
• 지원되지 않고 패치할 수 없는 핵심 시스템이 식별되어 기술 스프레드시트가 아니라 기업 위험 등록부에 있다.
• 짧고 합의된 아키텍처 원칙 집합이 결정을 내리고 정당화하는 데 진정으로 쓰인다.
• 설계 위원회가 중대하고 되돌리기 어려운 결정을 검토하고 일상적 결정은 빠르게 처리하며, 막지 않고 가능하게 한다.
• 클라우드 채택을 거주, 회복탄력성, 비용, 이식성, 탄소를 따져 워크로드별로 평가한다.
• 기술 부채에 지정된 소유자와 재원이 있는 시정 계획이 있으며, 가끔의 불 끄기만이 아니다.
• 중복되고 낡은 시스템을 합리화하고, 폐기에 데이터 이전, 보존, 의존성 확인으로 자원이 배정된다.
• 새 역량이 개방형이고 버전이 매겨진 API를 노출하여 그 주변을 다시 만들지 않고 구성 요소를 교체할 수 있다.
• 보안이 최소 공격 표면, 최소 권한, 분할로 처음부터 설계에 내장되며, 출시 전에 덧붙이지 않는다.
• 구축/구매/구성 결정이 총 소유 비용과 종속을 근거로 내려지며, 서명 전에 퇴출 및 데이터 추출 권리가 확보된다.

주요 출처#

• NHS England — 클라우드 전략, 기술 표준, Data Security and Protection Toolkit.
• National Cyber Security Centre (NCSC) — 안전한 설계 원칙과 클라우드 보안 지침.
• UK Government (GDS/CDDO) — Technology Code of Practice와 클라우드 우선 정책.
• National Audit Office — NHS 레거시 시스템, WannaCry 공격, IT 기반 프로그램에 관한 보고서.
• The Open Group — TOGAF, 전사적 아키텍처 프레임워크.
• Government Digital Service — GOV.UK 서비스 매뉴얼과 디자인 커뮤니티의 "가장 얇은 실행 가능한 플랫폼" 개념.

참고문헌#

1. Enterprise architecture — Wikipedia — https://en.wikipedia.org/wiki/Enterprise_architecture
2. Solution architecture — Wikipedia — https://en.wikipedia.org/wiki/Solution_architecture
3. Systems architecture — Wikipedia — https://en.wikipedia.org/wiki/Systems_architecture
4. Cloud computing — Wikipedia — https://en.wikipedia.org/wiki/Cloud_computing
5. Software as a service — Wikipedia — https://en.wikipedia.org/wiki/Software_as_a_service
6. Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
7. Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
8. Application portfolio management — Wikipedia — https://en.wikipedia.org/wiki/Application_portfolio_management
9. Application programming interface — Wikipedia — https://en.wikipedia.org/wiki/Application_programming_interface
10. Total cost of ownership — Wikipedia — https://en.wikipedia.org/wiki/Total_cost_of_ownership
11. Secure by design — Wikipedia — https://en.wikipedia.org/wiki/Secure_by_design
12. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
13. Cloud strategy — NHS England — https://www.england.nhs.uk/long-read/cloud-centre-of-excellence/
14. Secure design principles — National Cyber Security Centre — https://www.ncsc.gov.uk/collection/cyber-security-design-principles
15. Technology Code of Practice — UK Government (CDDO) — https://www.gov.uk/guidance/the-technology-code-of-practice
16. Investigation: WannaCry cyber attack and the NHS — National Audit Office — https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/
17. TOGAF Standard — The Open Group — https://www.opengroup.org/togaf
18. Service Manual: cloud and platforms — Government Digital Service — https://www.gov.uk/service-manual