주제 1.1 — 운영 모델

한 문장으로: 목표 운영 모델(TOM)이란 조직의 전략이 가치 흐름, 역량, 팀, 거버넌스, 기술, 데이터, 공급업체를 거쳐 디지털 보건·돌봄 성과로 이어지는 방식을 의도적으로 설계한 것이며, 그 형태를 제대로 잡았는지에 따라 이후의 모든 것이 빠르고 안전해지거나 느리고 취약해진다.

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

대부분의 디지털 보건 조직은 인재나 기술이 부족해서 실패하지 않는다. 운영 모델이 그들과 싸우기 때문에 실패한다. 자금은 기간이 한정된 프로젝트에 묶여 있고, 의사결정 권한은 모호하며, 모든 팀이 똑같은 로그인, 통합, 감사 배관을 다시 만든다. 그 결과 공적 자금의 비용이 중복되고, 임상 안전이 일관되지 않으며, 통합 돌봄 시스템(ICS) 전반에서 데이터를 공유할 수 없는 서비스가 생긴다.

이 영역에서 운영 모델이 독특한 이유는 서로 경쟁하는 선(善)들을 조화시켜야 하기 때문이다. 트러스트, 지방정부, 일반의 진료소 같은 독립적 조직들의 자율을 존중할 만큼 충분히 연합적이어야 하면서도, 환자에게 그 조직들을 가로지르는 하나의 안전한 경험을 줄 만큼 충분히 일관적이어야 한다. 가동 중단이 돌봄에 영향을 줄 수 있는 상황에서 운영(임상 시스템을 안전하게 가용 상태로 유지하기)과 변화(그것을 개선하기)의 균형을 잡아야 한다. 그리고 비례적으로 지출해야 한다. 공적 책임과 임상 안전을 위해 충분히 무거우면서도 반복을 질식시키지 않을 만큼 가벼운 보증이어야 한다. TOM은 이러한 상충 관계를 우연에 맡기는 대신 명시적으로 결정하는 곳이다.

핵심 개념#

운영 모델의 층. 쓸모 있는 TOM은 각 층이 위의 층을 떠받치는 스택이다.

• 전략과 성과 — 개선하려고 존재하는 측정 가능한 인구 및 서비스 성과(흔히 OKR로 표현됨, 주제 1.3 — 근거 기반 의사결정 참조).
• 가치 흐름 — 사용자에게 가치를 전달하는 종단 간의 흐름, 예컨대 "환자를 의뢰하고, 분류하고, 치료한다". 조직도가 아니라 시민의 여정을 중심으로 조직된다.
• 역량 — 할 수 있어야 하는 일(신원 확인, 예약, 임상 문서화, 분석). 해법이 바뀌어도 역량은 안정적이다.
• 팀 — 역량과 가치 흐름을 전달하도록 조직된 사람들(아래 Team Topologies 참조).
• 거버넌스와 의사결정 권한 — 누가 무엇을 결정하고 보증은 어떻게 적용되는가.
• 기술과 데이터 — 팀이 그 위에 구축하는 플랫폼, 표준, 데이터 아키텍처.
• 공급업체 — 구매하는 시장과 그것을 관리하는 방식.

위에서 아래로(전략 → 가치 흐름 → 역량) 설계하면 팀과 기술이 레거시 구조가 아니라 성과에 정렬된 상태로 유지된다.

중앙집중형 vs 연합형 vs 플랫폼 모델. 중앙집중형 모델은 전달을 하나의 팀이나 독립 기관에 집중시킨다. 일관되고 표준화 비용이 낮지만 병목이 되기 쉽고 지역의 필요와 멀어지기 일쑤다. 연합형 모델은 전달을 트러스트와 지역에 위임한다. 반응이 빠르고 현지가 주인의식을 갖지만 중복과 분기에 빠지기 쉽다. 플랫폼 모델은 이를 조화시키는 패턴이다. 중앙 팀이 공유되고 재사용 가능한 역량(신원, 상호운용성, 호스팅, 디자인 시스템)을 플랫폼으로 제공하고, 연합된 팀이 그 위에서 빠르게 구축한다. 대부분의 성숙한 보건 시스템은 "플랫폼 더하기 연합"으로 수렴한다.

Team Topologies. 이 프레임워크는 네 가지 팀 유형을 명명한다. 스트림 정렬(가치 흐름을 소유), 플랫폼(셀프서비스 역량 제공), 지원(다른 팀이 역량을 끌어올리도록 코칭), 복합 서브시스템(알고리즘과 같은 깊은 전문 작업)이며, 이들 사이의 낮은 마찰의 상호작용을 강조한다. 이는 플랫폼 모델에 깔끔하게 대응한다. 플랫폼 팀은 스트림 정렬 팀의 인지 부하를 줄여 사용자 및 임상적 가치에 집중하게 한다.

운영 vs 변화. 운영은 라이브 서비스를 안전하고 가용한 상태로 유지하는 것이고, 변화는 그것을 개선하거나 구축하는 것이다. 서비스를 구축하면서 운영하기도 하는 제품 팀("만든 사람이 운영한다")은 피드백 루프를 닫고 안전을 개선하지만, 그 균형은 정직하게 자금을 대야 한다. 변화를 위해 운영을 굶기는 것이 임상 시스템이 퇴화하는 방식이다.

가장 얇은 실행 가능 플랫폼(TVP). Team Topologies에서 온 개념으로, 플랫폼은 스트림 팀의 마찰을 실제로 줄이는 공유 서비스의 최소 집합이어야 하며 그 이상이어서는 안 된다. 지나치게 구축된 플랫폼은 그 자체로 병목이자 레거시가 된다. 모든 팀이 진정으로 필요로 하는 소수의 역량(인증, 상호운용성 계층, 호스팅, 디자인 시스템)에서 시작해 입증된 수요에 따라서만 키우라.

모범 사례#

1. 조직도에서 위로가 아니라 성과에서 아래로 모델을 설계하라. 움직여야 할 인구 및 서비스 성과에서 시작해, 그것을 전달하는 가치 흐름을 도출하고, 그 다음에야 팀과 기술을 설계하라. 기존 위계에 닻을 내린 TOM은 현재의 사일로를 자동화할 뿐이다.

2. 플랫폼 더하기 연합의 형태를 채택하라. 공유 역량을 셀프서비스 플랫폼으로 중앙에서 제공하고, 트러스트와 지역의 스트림 정렬 팀이 그 위에 구축하게 하라. 이는 안전과 상호운용성에서 전국적 일관성을, 지역의 속도와 주인의식과 함께 제공한다. 이 영역이 요구하는 조화다.

3. 프로젝트가 아니라 제품에 자금을 대라. 기간이 한정된 프로젝트에서 가치 흐름에 정렬된 지속적으로 자금이 지원되는 제품 팀으로 돈을 옮기라. 프로젝트 자금은 팀이 도메인을 배운 바로 그 시점에 해체하도록 강요하지만, 제품 자금은 보건 서비스에 필요한 안전 지식과 반복을 지속시킨다(주제 5.0 — 제품 중심 업무 참조).

4. 지출 통제를 비례적이고 단계적으로 하라. 근거에 연동된 단계적 자금 조달을 사용하라. 프로그램 전체를 미리 승인하는 대신 디스커버리, 알파, 베타, 라이브 관문에서 돈을 풀라. GDS 방식의 지출 통제와 NHS 보증 경로는 검증되지 않은 아이디어에 대규모 매몰 비용이 드는 것을 막기 위해 존재한다. 이를 일괄적인 관료주의가 아니라 위험과 가치에 맞춰 조정되는 문턱으로 적용하라.

5. RACI 또는 RAPID 지도로 의사결정 권한을 명시하라. 모호한 권한은 전달이 지연되는 가장 흔한 원인이다. 중요한 의사결정 유형마다 누가 실행/책임/자문/통보(RACI)인지, 또는 누가 권고하고, 동의하고, 수행하고, 의견을 내고, 결정하는지(RAPID)를 명명하라. 이를 공개해 팀이 스스로 결정할 권한이 있는 사안을 상향 보고하는 일을 멈추게 하라.

6. 플랫폼을 얇고 수요 주도적으로 유지하라. 둘 이상의 팀이 같은 것을 필요로 한다는 사실이 입증될 때만 공유 역량을 구축하고, 플랫폼을 내부 팀이라는 자체 사용자를 가진 제품으로 다루라. 거대한 플랫폼을 미리 지으려는 충동을 억제하라. 가장 얇은 실행 가능 플랫폼은 채택을 통해 범위를 얻는다.

7. 공급업체를 모델 밖이 아니라 모델의 일부로 관리하라. 어떤 역량이 전략적(구축/소유)이고 어떤 것이 범용(구매)인지 의도적으로 결정하고, 핵심 임상 데이터에 대한 단일 공급업체 종속을 피하며, 계약에서 개방형 표준과 탈퇴 권리를 요구하라. 공급업체는 운영 모델의 한 층이며, 그들의 업무 방식은 여러분의 방식과 양립 가능해야 한다.

8. 의사결정 권한을 명시하라. 운영 모델은 누가 무엇을 결정하는지 사람들이 알아야만 작동한다. 어떤 선택은 제품 팀에, 어떤 것은 임상 안전 당국에, 어떤 것은 이사회에까지 가야 하는지 말이다. 의사결정 권한을 지도화하고 각 결정을 안전하게 감당할 수 있는 가장 낮은 수준으로 내려보내, 불필요한 상향 보고로 전달이 억눌리지 않게 하라. 모호한 권한은 느리고 방어적인 전달의 가장 흔한 원인 중 하나다.

9. 운영 모델을 진화시키는 제품으로 다루라. 목표 운영 모델은 한 번 정해 벽에 걸어 두는 것이 아니다. 수요, 기술, 파트너십이 변함에 따라 점검하고 근거에 따라 조정하라. 업무 흐름, 의사결정까지의 시간, 재작업, 팀 건강 같은 몇 가지 신호를 지켜보고, 구조가 입증 가능하게 방해가 될 때 변경하라. 조직 개편 유행에 반응해서 변경하지 말라.

팀과 논의할 질문#

1. 우리의 운영 모델은 성과와 가치 흐름에서 아래로 설계되었는가, 아니면 기존 조직도와 그 사일로를 그대로 자동화했을 뿐인가? 이 질문은 현재 위계에 닻을 내린 TOM이 이미 가진 사일로를 굳힐 뿐이라는 이 주제의 핵심 경고를 겨냥하며, 어떤 조직 개편에 앞서 탁자에 올릴 만한 가치가 있다. 보건·돌봄 환경에서 이것이 중요한 이유는 가치 흐름이 독립된 조직들을 가로지르는 시민의 여정(의뢰, 분류, 치료)을 따르는 반면 조직도는 제도적 경계를 따르며, 후자에 기반한 모델은 공적 자금으로 파편화되고 상호운용되지 않는 서비스를 계속 만들어 내기 때문이다. 정직하게 논의해야 할 긴장은 성과에서 위에서 아래로 설계하는 일이 실제로 파괴적이라는 점이다. 고위층이 경력을 쌓아 온 부서 소유권, 예산, 보고 라인을 가로지르므로, 제대로 하려면 실질적인 정치적 비용이 따른다. 상위 세 가지 성과를 명명하고 실제 팀 경계와 자금 라인이 그 가치 흐름을 따르는지 부서를 따르는지 추적해서 구체적으로 스스로를 시험하라. 팀이 부서에 깔끔하게 대응한다면 그것이 답이다. 좋은 정직한 답은 모델이 조직도 모양인 곳을 인정하고, 사일로에 나뉘어 있어 해를 끼치는 가치 흐름을 적어도 하나 식별하며, 조직이 기꺼이 다시 그릴 구조적 경계가 어디인지 현실적으로 말한다.

2. 우리의 가장 얇은 실행 가능 플랫폼에는 무엇이 들어가야 하며, 병목이 될 만큼 과하게 구축되거나 모든 팀이 같은 배관을 다시 만들 만큼 부족하게 구축되는 것을 어떻게 막을 것인가? 플랫폼 더하기 연합의 형태는 플랫폼이 얇고 수요 주도적으로 유지될 때만 작동하며, 이 질문은 주제가 명명한 두 가지 실패 양상을 팀이 직시하게 한다. 그 자체로 레거시 병목이 되는 거대한 플랫폼, 그리고 모든 팀이 로그인, 통합, 감사를 다시 만들게 하는 부재다. ICS에서 플랫폼은 사실상 공유 인프라(신원, FHIR 상호운용성 계층, 안전 기준선을 갖춘 호스팅, 디자인 시스템)이며 그 범위를 잘못 정하면 모든 스트림 팀 전반에서 비용이나 마찰이 곱절이 되기 때문에 중요하다. 논의해야 할 상충 관계는 시점과 근거다. 너무 일찍 구축하면 추측이 틀려 병목을 만들고, 너무 늦으면 중복이 이미 굳어 버린다. 그래서 "둘 이상의 팀이 같은 것을 필요로 함이 입증됨"이라는 시험이 핵심이며, 팀은 이 시험을 실제로 적용하는지 아니면 분명히 중심적으로 보이는 것을 그냥 짓는지 스스로 점검해야 한다. 현재 플랫폼으로 취급하는 것과 팀이 다시 만드는 것을 살펴보고, 플랫폼이 내부 사용자와 서비스 수준 목표를 가진 제품으로 운영되는지 모두가 뒤에 서서 기다리는 대기열로 운영되는지 물으라. 정직한 답은 오늘 두 팀 시험을 통과하는 구체적 역량을 명명하고, 나머지를 미리 구축하려는 유혹에 저항하며, 플랫폼 팀의 내부 사용자를 실제 서비스 수준을 가진 실제 고객으로 대하겠다고 약속한다.

3. 우리의 의사결정 권한은 어디서 실제로 모호하며, 오늘 팀이 상향 보고하는 것 중 스스로 결정할 권한을 가져야 하는 것은 무엇인가? 모호한 권한은 전달이 지연되는 가장 흔한 원인으로 지목되며, 이 질문은 공개된 RACI나 RAPID 지도가 없애려는 일상의 마찰을 드러낸다. 지역 팀, ICS 디지털 이사회, 임상 안전, 정보 거버넌스가 모두 결정에 대한 정당한 주장을 가지는 연합된 보건 시스템에서 이것은 특히 절실하다. 경계가 불분명하면 모든 것이 상향 보고되거나, 더 나쁘게는 잘못되기 전까지 아무도 판단을 소유하지 않는다. 탐색할 만한 긴장은 결정을 위임하려면 가드레일 안에서 팀을 신뢰해야 하는데, 고위 리더와 이사회가 임상 안전이나 공적 자금이 걸린 곳일수록 바로 그 신뢰를 거부하곤 한다는 점이다. 그러나 그 신뢰를 거두는 것이 애초에 상향 보고의 교착 상태를 만든다. 최근 상향 보고된 결정 다섯 건을 열거하고 각각에 대해 누가 결정했어야 했는지, 어떤 가드레일이 있었다면 그들이 할 수 있었는지 물어 구체화하라. 패턴은 대개 반복되는 모호한 결정 유형이 소수임을 드러낸다. 좋은 답은 누가 무엇을 결정하는지에 대한 구체적이고 공개 가능한 진술을 만들어 플랫폼 표준, 서비스 설계, 임상 안전 승인을 구별하고, 조직이 실제로 위임할 의향이 있는 결정과 중앙에 두고 이유를 설명할 결정을 정직하게 말한다.

4. 우리는 운영과 변화에 정직하게 자금을 대고 있는가, 아니면 새로운 기능에 돈을 대려고 라이브 서비스 운영을 조용히 굶기고 있는가? 주제는 변화를 위해 운영을 굶기는 것이 임상 시스템이 퇴화하는 방식이라고 직설적으로 말하며, 이 질문은 가동 중단이나 안전 사고가 대신 드러내 주기 전에 그 균형을 공개적으로 꺼내게 한다. 보건·돌봄에서 "운영"은 후방 간접비가 아니라 진료 현장에서 임상의가 의존하는 시스템의 가용성이기 때문에 중요하다. 따라서 줄어든 운영 예산은 불편해진 사용자가 아니라 환자에게 영향을 줄 수 있는 가동 중단으로 나타난다. 상충 관계가 불편한 것은 변화가 눈에 띄고 칭송받는 반면 운영은 실패하기 전까지 보이지 않으므로 이사회와 로드맵이 자연스럽게 새로운 것에 치우치기 때문이다. "만든 사람이 운영한다" 모델은 피드백 루프를 닫아 도움이 되지만, 팀의 운영 시간이 명목상 배정된 뒤 약탈당하지 않고 실제로 보호될 때만 그렇다. 지난 분기 각 제품 팀의 역량 중 서비스를 안전하고 가용하게 유지하는 데 실제로 쓰인 비율과 계획한 비율을 비교하고, 운영 업무가 추적되고 평가받는지 방해 요소로 취급되는지 살펴 구체화하라. 정직한 답은 오늘 운영이 과소 지원되는 곳을 명명하고, 현실적인 운영 배분을 잔여분이 아니라 우선 비용으로 보호하며, 어떤 라이브 서비스가 누적된 운영 위험을 안고 있는지 솔직히 말한다.

5. 우리는 어떤 역량을 구축해 소유하고 어떤 것을 구매할지 의도적으로 선택하고 있는가, 그리고 의도하지 않은 채 핵심 임상 데이터에 대한 종속을 받아들이고 있지는 않은가? 여기서의 모범 사례는 구축 대 구매를 의도적으로 결정하고, 핵심 임상 데이터에 대한 단일 공급업체 종속을 피하며, 공급업체를 운영 모델 밖의 무엇이 아니라 그 한 층으로 취급하는 것이다. 이 질문은 그러한 선택이 실제로 이루어지는지 아니면 기본값으로 굴러가는지 시험한다. 디지털 보건에서 가장 중대한 종속은 임상 기록과 그 데이터를 둘러싼 것이기 때문에 중요하다. 현실적 탈퇴 수단이 없는 독점 저장소는 시스템 전체를 십 년간 가두고 모든 하위 서비스가 할 수 있는 일을 좌우할 수 있다. 긴장은 속도 대 선택지다. 구매는 오늘 더 빠르고 흔히 더 저렴하며 특히 일손이 빠듯한 팀에 그렇지만, 개방형 표준이나 탈퇴 권리가 없는 편리한 구매는 하나하나가 내일의 선택지를 조용히 좁히고, 그 비용은 떠나려 할 때에야 드러난다. 핵심 역량을 열거해 각각을 전략적(구축/소유)인지 범용(구매)인지 표시하고, 범용 역량 뒤의 계약이 개방형 표준(HL7 FHIR, SNOMED CT)과 집행 가능한 탈퇴 권리를 실제로 요구하는지 확인해 구체화하라. 좋은 답은 소수의 진정 전략적인 역량과 안전하게 구매할 수 있는 다수를 구별하고, 조직이 이미 임상 데이터에 종속된 곳을 정직하게 말하며, 가장 중요한 계약에서 개방형 표준과 탈퇴 권리를 약속한다.

6. 운영 모델을 바꿔야 할 때를 어떻게 알며, 유행이나 새 리더의 부임에 따라 조직을 개편하는 대신 어떤 신호가 우리에게 그것을 알려 줄 것인가? 주제는 운영 모델을 벽에 걸린 도표가 아니라 근거에 따라 진화시키는 제품으로 설정하며, 이 질문은 팀에게 모델을 재편하는 것을 정당화할 근거가 무엇일지 미리 정의하도록 요구한다. 보건·돌봄에서 조직 개편은 어렵게 얻은 도메인 및 임상 안전 지식을 해체하는 파괴적이고 비싼 일이지만, 이 분야는 현재 모델이 실제로 방해가 되는지 여부보다 정책 주기와 신규 임명에 이끌린 구조적 변동에 취약하기 때문에 중요하다. 긴장은 안정과 적응 사이에 있다. 모델을 너무 쉽게 바꾸면 팀이 자리를 잡거나 안전 전문성을 쌓지 못하고, 너무 드물게 바꾸면 굳어진 구조가 일에 더는 맞지 않게 된 뒤에도 오래도록 흐름을 억누른다. 업무 흐름, 의사결정까지의 시간, 재작업, 팀 건강 같은 소수의 신호를 지켜보기로 하고, 그 지표의 어떤 움직임이 의도적 재설계를 일으키고 어떤 것이 더 작은 조정을 일으키는지 합의해 구체화하라. 정직한 답은 소수의 선행 지표를 약속하고, 근거에 기반한 변화와 조직 개편 쇼를 구별하며, 모델을 점검하고 신호가 그것이 전달을 방해한다고 말할 때 행동할 책임이 누구에게 있는지 분명히 한다.

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

다섯 개 지역을 아우르는 ICS에서 각 트러스트가 자체 환자 대상 예약 도구를 만들고 있다. 비용은 중복되고, 경험은 갈라지며, 어느 것도 데이터를 깔끔하게 공유하지 못한다. ICS는 운영 모델을 재설계한다.

세 가지 성과(예약 불이행 감소, 피할 수 있는 입원 감축, 접근 형평성 개선)와 그 뒤의 가치 흐름을 정의한다. 네 가지 가장 얇은 실행 가능 역량을 소유하는 작은 플랫폼 팀을 세운다. 공유 신원/로그인, FHIR 기반 상호운용성 계층, 보안 및 임상 안전 기준선을 갖춘 공통 호스팅, 그리고 디자인 시스템이다. 각 지역은 스트림 정렬 팀을 유지하되 이제 처음부터가 아니라 플랫폼 위에 구축한다.

자금 조달은 연간 프로젝트 입찰에서 각 스트림의 상설 제품 예산으로 바뀌고, 디스커버리/알파/베타 관문을 통해 집행된다. 공개된 RAPID 지도는 지역 팀이 플랫폼 및 임상 안전 가드레일 안에서 자신의 서비스 설계를 결정하고 ICS 디지털 이사회가 플랫폼 표준을 결정함을 분명히 한다. 일 년 안에 세 지역이 하나의 예약 역량을 공유하고, 설계 및 안전 기준선이 일관되며, 예전엔 프로젝트 한 주기가 걸리던 새 기능이 몇 주 만에 출시된다. 플랫폼이 차별화되지 않는 힘든 일을 흡수했기 때문이다.

부문별 관점#

운영 모델은 그것이 섬기는 조직의 규모에 맞춰진다. 가치 흐름, 역량, 팀, 거버넌스, 플랫폼, 공급업체라는 같은 층이 스타트업, 대기업, 정부 기관에서는 매우 다르게 그려진다.

스타트업#

소규모 디지털 보건 기업에서 운영 모델은 대부분 암묵적이며 그것으로 괜찮다. 한두 개의 스트림 정렬 팀, 의사결정 권한 대부분을 쥔 창업자, 아직 플랫폼으로 만들 것이 없으므로 플랫폼 팀은 없다. 규율은 몇 안 되는 실제 결정을 일찍 명시하는 것이다. 임상 데이터 저장소를 구축할지 구매할지, 어떤 개방형 표준에 따를지를 정해 오늘의 지름길이 내일의 종속이 되지 않게 한다. 운영과 변화가 같은 사람의 손에 있으므로, 초기 고객을 위해 불을 켜 두는 일이 로드맵을 굶길 위험이 있다. 엔지니어링 시간의 단순하고 정직한 분할이 보호된 운영 예산의 가벼운 대응물이다. 공급업체는 속도 때문에 선택되지만, 스타트업도 핵심 임상 데이터의 종속은 거부해야 한다. 장래의 NHS 구매자가 탈퇴 권리를 요구할 것이기 때문이다.

소규모 사업체#

확립된 소규모 제공자 — 일반의 진료소, 지역 약국, 요양원이나 재가 돌봄 제공자, 단일 사업장 클리닉, 또는 수익 이전 단계를 지난 소규모 보건 기술 공급업체 — 는 실제 환자와 진행 중인 운영이 있지만 플랫폼 팀도, 전담 디지털이나 IT 역량도 없고 현금과 인력의 여유도 거의 없다. 여기서 운영 모델은 대체로 구매한 역량을 이어 붙인 것이므로 결정적인 선택은 공급업체에 관한 것이다. 대형 트러스트의 구매력이나 내부 전문성은 없으면서 같은 상호운용성 및 임상 안전 의무를 지므로, 조달하는 임상 시스템에서 개방형 표준과 탈퇴 권리를 고집해야 한다. 운영과 변화는 돌봄도 제공하는 같은 몇 사람에게 겹쳐 떨어지므로, 정직한 규율은 불을 끄는 일만이 아니라 시스템을 안전하고 최신으로 유지하는 약간의 시간을 보호하는 것이다. 의사결정 권한은 단순하다. 보통 파트너나 소유주 겸 관리자가 결정한다. 하지만 그래서 디지털 결정을 무기한 미루기 쉽고, 따라서 가치는 중요한 몇 가지(어떤 임상 기록, 어떤 지역 공유 플랫폼에 참여할지)를 명명하고 의도적으로 결정하는 데 있다. ICS나 국가 기관이 공유 신원, 상호운용성, 디자인 플랫폼을 제공하는 경우, 소규모 사업체의 최선은 흔히 재발명하는 대신 그 위에 구축하여 스스로 인력을 둘 수 없는 역량을 빌리는 것이다.

대기업#

NHS 트러스트나 ICS는 플랫폼 더하기 연합의 형태가 진가를 발휘하는 곳이다. 환자에게는 하나의 서비스처럼 느껴져야 하는 독립된 조직들이기 때문이다. 어려운 문제는 기술만큼 정치적이다. 기간 한정 프로젝트 입찰에서 상설 제품 예산으로 돈을 옮기는 일, 지역 팀이 자기 소유의 결정을 상향 보고하지 않도록 RACI/RAPID 지도를 공개하는 일이다. 대형 보건 기술 또는 제약 대기업은 플랫폼 엔지니어링의 힘이 있지만, 그 자체로 병목이 되는 거대한 내부 플랫폼을 과도하게 구축할 위험이 있다. 둘 이상의 팀이 같은 것을 필요로 함이 입증되어야 한다는 가장 얇은 실행 가능 플랫폼의 시험이 제동 장치다. 이 규모에서는 의사결정 권한과 자금 흐름이 곧 운영 모델이며, 기술이 제약인 경우는 대개 없다.

정부#

국가 또는 지방 공공기관은 다른 조직들이 들어가 살아야 할 운영 모델을 설계하므로, 표준과 플랫폼에 대한 선택은 사실상 국가 인프라다. NHS England나 DHSC가 공유 신원 계층, 상호운용성 중추, 디자인 시스템을 제공하는 것은 인구 규모에 적용된 플랫폼 패턴이며, 지출 통제와 단계적 보증 관문은 공적 자금을 책임 있게 관리하는 방법이다. 실패 양상은 먼 병목이 되어 모든 지역 맥락에 하나의 해법을 강제하는 중앙집중형 모델이다. 바로잡는 길은 진정으로 공통된 역량은 플랫폼으로 만들고 나머지는 트러스트와 지방정부에 연합시키는 것이다. 의회에 대한 책임은 구축/구매와 공급업체 관리가 공적 기록의 문제임을 의미하므로, 개방형 표준과 탈퇴 권리는 단지 신중한 것을 넘어 기대되는 것이다.

흔한 실패 양상#

• 조직도 자동화. 가치 흐름이 아니라 기존 부서를 중심으로 팀을 설계해 TOM이 사일로를 굳히는 것. 해독제: 성과와 가치 흐름에서 아래로 설계한다.
• 병목이 되는 플랫폼. 모든 요청이 줄 서야 하는 범위가 지나친 중앙 플랫폼 팀. 해독제: 서비스 수준 목표를 가진 제품으로 다루는 가장 얇은 실행 가능 플랫폼.
• 제품 업무에 대한 프로젝트 자금 조달. 만료되는 돈이 해체와 재구성의 소용돌이를 강요한다. 해독제: 단계적 관문을 갖춘 지속적 제품 자금 조달.
• 변화를 먹이려 굶긴 운영. 임상 시스템이 퇴화할 때까지 라이브 서비스 운영을 과소 지원하는 것. 해독제: 운영과 변화에 명시적으로 자금을 대고 운영 예산을 보호한다.
• 주인 없는 결정. 누가 결정하는지 아무도 몰라 모든 것이 상향 보고된다. 해독제: 공개된 RACI/RAPID.
• 기본값으로서의 종속. 핵심 임상 데이터가 탈퇴 수단이 없는 독점 공급업체 시스템에 갇히는 것. 해독제: 모든 전략적 계약에 개방형 표준과 탈퇴 권리.

성숙도 모델#

체크리스트#

• 운영 모델이 기존 위계가 아니라 성과와 가치 흐름에서 설계되어 있다.
• 공유 역량이 가장 얇은 실행 가능 플랫폼으로 제공되고, 스트림 팀이 그 위에 구축한다.
• 제품 팀이 지속적으로 자금을 지원받으며 가치 흐름에 정렬되어 있다.
• 지출 통제가 단계적(디스커버리/알파/베타/라이브 관문)이며 위험과 가치에 비례한다.
• 의사결정 권한이 문서화(RACI 또는 RAPID)되고 공개되어 있다.
• 운영과 변화에 명시적으로 자금이 지원되고 운영 예산이 보호된다.
• 팀 유형(스트림 정렬, 플랫폼, 지원, 복합 서브시스템)이 이해되고 사용된다.
• 구축/구매가 역량별로 의도적인 선택이며, 핵심 임상 데이터는 종속을 피한다.
• 계약이 개방형 표준(예: HL7 FHIR, SNOMED CT)과 탈퇴 권리를 요구한다.

주요 출처#

• Matthew Skelton & Manuel Pais — Team Topologies (스트림 정렬, 플랫폼, 지원, 복합 서브시스템 팀; 가장 얇은 실행 가능 플랫폼).
• GOV.UK Service Manual — 지출 통제와 단계적 보증(디스커버리/알파/베타/라이브); Government Digital Service.
• NHS digital service manual — NHS service standard(service-manual.nhs.uk).
• AXELOS — 포트폴리오 및 프로그램 거버넌스를 위한 Management of Portfolios (MoP) 및 Managing Successful Programmes (MSP).
• Bain & Company — RAPID 의사결정 권한 프레임워크; 그리고 RACI 책임 배정 모델.
• John Doerr — 성과 정의를 위한 Measure What Matters(OKR).

참고문헌#

1. Operating model — Wikipedia — https://en.wikipedia.org/wiki/Operating_model
2. Value stream — Wikipedia — https://en.wikipedia.org/wiki/Value_stream
3. Objectives and key results (OKRs) — Wikipedia — https://en.wikipedia.org/wiki/Objectives_and_key_results
4. Responsibility assignment matrix (RACI) — Wikipedia — https://en.wikipedia.org/wiki/Responsibility_assignment_matrix
5. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
6. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
7. Fast Healthcare Interoperability Resources (HL7 FHIR) — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
8. SNOMED CT — Wikipedia — https://en.wikipedia.org/wiki/SNOMED_CT
9. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton & Manuel Pais, IT Revolution — https://teamtopologies.com/book
10. Spend controls and staged assurance (discovery/alpha/beta/live) — GOV.UK Service Manual, Government Digital Service — https://www.gov.uk/service-manual/agile-delivery
11. NHS service standard — NHS digital service manual, NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
12. Managing Successful Programmes (MSP) and Management of Portfolios (MoP) — AXELOS/PeopleCert — https://www.axelos.com/
13. Measure What Matters (OKRs) — John Doerr — https://www.whatmatters.com/the-book