주제 3.8 — 서비스 관리 및 라이브 운영

보건·돌봄에서 서비스의 수명, 비용, 임상 위험의 대부분은 가동 이후에 있으므로, 라이브 서비스를 어떻게 운영하고, 모니터링하고, 지원하는가는 사무실 뒤편의 사후 고려가 아니라 환자 안전의 결정이다.

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

출시는 끝이 아니라 시작이다. 디지털 서비스는 몇 달 동안 만들어지고, 성공하면 몇 년 또는 수십 년 동안 운영되며, 돈의 대부분이 가는 곳이자 해악이 실제로 일어나는 곳이 운영이다. 공유 진료 기록, 전자 처방 시스템, 산과 기록 플랫폼은 가동 중이고, 정확하고, 반응할 때만 가치를 전달한다. 저하되거나 실패하면 결과는 불편이 아니라 치료 지연, 놓친 알레르기, 취소된 클리닉, 압박 속에서 낯선 종이 우회책으로 돌아가는 임상의다.

보건·돌봄은 하루 24시간, 주 7일 운영되며 멈출 수 없다. 슈퍼마켓의 계산 시스템이 고장 나면 고객이 기다리고, 병원의 환자 행정 시스템이 고장 나면 구급차가 우회하고 선택 수술 명단이 연기될 수 있다. 이는 라이브 운영에 독특한 무게를 준다. 다운타임은 임상 안전 사건이며, 이를 어떻게 탐지하고, 상향 보고하고, 소통하고, 복구할지에 대한 계획은 돌봄의 의무의 일부다. 수천 건의 NHS 예약과 수술 취소를 낳은 2017년 WannaCry 랜섬웨어 공격은 운영 실패가 환자 안전과 대중 신뢰의 위기로 번지는 방식의 기준 사례다(주제 1.7 — 정보 거버넌스, 데이터 보호 및 사이버 보안 참조).

리더는 라이브 운영에도 정직하게 재원을 대고 인력을 배치해야 한다. 보건 기술에서 끈질긴 실패는 가동을 축하하고, 팀을 해산하고, 운영 중인 서비스를 "끝난" 것으로 취급하는 것이다. 상설 팀도, 모니터링도, 대기 근무도 없는 라이브 서비스는 비용을 아끼는 것이 아니라 크게 실패하는 날까지 임상 위험을 조용히 쌓고 있는 것이다. 서비스 관리는 라이브 서비스를 안전하게 지키는 규율이며, 구축과 같은 엄밀성을 받을 자격이 있다.

핵심 개념#

서비스 관리와 "라이브" 단계. IT 서비스 관리(ITSM)는 IT 서비스를 전 생애에 걸쳐 설계하고, 운영하고, 지원하고, 개선하는 실천의 집합이다. GOV.UK와 NHS 단계 모델에서 라이브는 서비스가 폐기될 때까지 지속적으로 운영되는 단계로, 여전히 반복되고, 재원을 받고, 소유된다(주제 3.5 — 딜리버리 수명주기 참조). 라이브는 쉬는 상태가 아니다. 수명주기에서 가장 길고 가장 비싼 부분이다.

ITIL 4. ITIL은 가장 널리 쓰이는 ITSM 프레임워크다. 현재 판인 ITIL 4는 더 프로세스가 무거웠던 이전 판을 "서비스 가치 시스템"과 유연한 실천을 중심으로 재구성하며, 애자일, DevOps, 린과 경쟁하지 않고 나란히 놓이도록 설계되었다. ITIL을 통째로 들여올 관료제가 아니라 비례적으로 채택할 어휘와 실천의 체크리스트로 다루라.

인시던트, 문제, 변경 관리. 인시던트 관리는 계획되지 않은 중단 후 가능한 한 빨리 정상 서비스를 복원한다. 우선순위는 진단이 아니라 복구다. 문제 관리는 재발을 막기 위해 하나 또는 여러 인시던트의 근본 원인을 조사하고 알려진 오류와 우회책의 기록을 유지한다. 변경 관리(ITSM 의미에서)는 라이브 자산에 대한 변경이 어떻게 평가되고, 승인되고, 릴리스되는지 통제하여 한 가지를 고치다 다른 것을 깨뜨리지 않게 한다. 이 세 가지 실천이 운영의 핵심이며 서로 맞물린다. 인시던트가 문제를 제기하고, 그 해결책이 변경으로 전달될 수 있다.

중대 인시던트 관리와 업무 연속성. 중대 인시던트는 트러스트 전체에서 임상 시스템이 다운되는 것 같은 고영향 사건으로, 정의된 인시던트 지휘관, 소통, 임상 리더십이 있는 선언되고 조율된 대응이 필요하다. 업무 연속성 계획(BCP)은 시험된 임상 다운타임 절차(안전한 종이 대비책)와 재해 복구를 포함하여 중단 중에도 허용 가능한 수준으로 돌봄을 계속 제공하는 더 넓은 역량이다. 보건·돌봄에서 이것들은 선택이 아니다. 시스템이 다운된 동안 환자를 안전하게 지키는 것이 요점 전체다.

사이트 신뢰성 엔지니어링, SLI, SLO, SLA, 오류 예산. Google에서 시작된 사이트 신뢰성 엔지니어링(SRE)은 운영에 소프트웨어 엔지니어링의 규율을 적용한다. 신뢰성을 가용성이나 지연 같은 지표인 서비스 수준 지표(SLI)로 측정하여, 그 지표에 대한 내부 목표인 서비스 수준 목표(SLO)와 견준다. 서비스 수준 협약(SLA)은 외부의, 흔히 계약상의 약속으로, 보통 내부 SLO보다 느슨하게 정한다. 100%와 SLO 사이의 간극이 오류 예산이다. 기능 출시를 멈추고 안정화해야 하기 전까지 쓸 수 있는 불안정의 양이다. 임상 시스템에서 SLO는 임상의와 함께 정해야 한다. "허용 가능한" 다운타임은 단지 엔지니어링이 아니라 안전의 판단이기 때문이다.

관측 가능성과 모니터링. 관측 가능성은 로그, 지표, 트레이스라는 외부 출력으로부터 시스템의 내부 상태를 이해하는 능력으로, 이상적으로는 사용자가 알기 전에 문제를 탐지하고 진단할 수 있다. 모니터링과 경보는 그 데이터를 대기 근무자를 위한 적시의 신호로 바꾼다. 볼 수 없는 서비스를 안전하게 운영할 수는 없다.

대기 근무, 순번, 서비스 데스크. 대기 근무 순번은 유능한 사람이 24시간 경보에 대응하게 한다. 24/7 돌봄 환경에서 필수이며 인간적이고 지속 가능해야 한다. 서비스 데스크(또는 헬프 데스크)는 로그인할 수 없는 임상의, 예약 화면이 멈춘 접수 직원 같은 최종 사용자의 단일 연락 창구로, 지원을 제공하고, 인시던트를 기록하고, 다음으로 보낸다.

DevOps, 구성 관리, CMDB. DevOps와 SRE 원칙 "만든 사람이 운영한다"는 서비스를 만든 팀이 운영도 맡게 하여 개발과 운영 사이의 간극을 닫는다. 구성 관리는 서비스를 이루는 구성 요소와 그 관계의 정확한 기록을 유지하며, 흔히 구성 관리 데이터베이스(CMDB)에 둔다. 이것이 없으면 인시던트 중에 "이 변경은 무엇에 영향을 주는가?"에 안전하게 답할 수 없다.

운영 대 구축, 그리고 폐기. 조직은 구축 재원(새 역량 만들기)과 운영 재원(있는 것을 운영하기)을 분리한다. 운영에 재원을 덜 대는 것이 대부분의 운영 실패의 구조적 뿌리다. 그리고 모든 서비스는 결국 폐기에 이른다. 보존법에 따라 데이터를 이전하거나 보관하고 사용자를 안내하는 안전한 은퇴이며, 이는 그 자체로 운영 규율이다.

모범 사례#

1. "운영"에 재원을 대고 인력을 배치하는 것을 남은 일이 아니라 일급 약속으로 삼으라. 서비스의 운영 수명 — 모니터링, 대기 근무, 서비스 데스크, 보안 패치, 지속적 반복 — 을 가동 전에 예산에 반영하고, 다음 번쩍이는 구축이 털어 가지 못하게 보호하라. 시스템을 운영하는 데 드는 비용이 평생에 걸쳐 만드는 데 드는 비용보다 훨씬 크다는 업계의 경험칙은 보건에서도 맞는다. 구축 재원은 있고 운영 재원이 없는 서비스는 출시일이 있는 임상 위험이다.

2. "운영팀에 벽 너머로 던지기" 안티패턴을 피하라. 프로젝트 팀이 서비스를 만든 뒤 만드는 것을 본 적 없는 별도의 운영 팀에 넘기게 두지 말라. "만든 사람이 운영한다"를 적용하라. 서비스를 이해하는 팀이 그 신뢰성에 책임지게 하거나, 최소한 공유된 대기 근무와 보증 기간이 있는 의도적이고 문서화된 서비스 전환을 운영하라. 구축과 운영 사이의 벽이 지식, 소유권, 안전이 새는 곳이다.

3. 임상의와 함께 SLO를 정하고 오류 예산을 관리하라. 각 서비스에 대해 "충분히 신뢰할 만하다"가 무엇을 뜻하는지 측정 가능한 SLI와 SLO로 정의하고, 그 결과를 감당하는 임상의와 공동으로 정하라. 응급실 시스템의 가용성 목표는 순수하게 기술적인 선택이 아니다. 기능 출시와 안정성 유지 사이의 영원한 긴장을 중재하는 데 오류 예산을 사용하라. 신뢰성이 소진되면 멈추고 안정화하라. 약속을 어기기 전에 행동할 여지가 있도록 외부 SLA를 내부 SLO보다 느슨하게 유지하라.

4. 서비스를 키우기 전에 관측 가능하게 만들라. 로깅, 지표, 트레이싱을 계측하고, 서버 건전성만이 아니라 사용자와 임상의의 경험을 반영하는 대시보드와 경보를 구축하라. 밑바닥의 모든 일시적 이상이 아니라 중요한 증상(환자를 예약할 수 없음)에 경보를 걸어, 대응자가 호출을 무시하도록 길들이는 경보 피로를 피하라. 실패를 화난 임상의로부터 아는 서비스를 안전하게 지킬 수는 없다.

5. 규율 있는 인시던트, 문제, 변경 관리를 — 비례적으로 운영하라. 인시던트에 명확한 심각도 수준, 대응 목표, 중대 건에는 인시던트 지휘관, 대응 중의 단일 진실 원천을 부여하라. 심각한 인시던트를 비난 없는 사후 검토와, 서버를 반복해서 재시작하는 대신 근본 원인을 고치는 문제 관리 프로세스에 투입하라. 변경은 적정 규모의 프로세스로 통제하라. 일상적인 저위험 업무에는 가볍고 표준이며 사전 승인된 변경을, 진정으로 위험한 변경에만 변경 자문 검토를 적용하여, 거버넌스가 안전을 지키면서 사람들이 우회하고 싶게 만드는 병목이 되지 않게 하라.

6. 중대 인시던트와 임상 다운타임을 문서화만 하지 말고 연습하라. 업무 연속성과 임상 다운타임 절차를 작성하고, 시험하고, 정기적으로 훈련하라. 돌봄이 종이로 어떻게 계속되는지, 시스템이 다운되었음을 직원에게 어떻게 알리는지, 복구 시 데이터를 어떻게 대조하는지, 누가 중대 인시던트를 선언하고 지휘하는지다. 시험되지 않은 계획은 당일에 실패한다. 이를 임상 위험 관리와 위해 요인 로그에 명시적으로 연결하라(주제 1.6 — 임상 안전 및 위험 관리 참조). 다운타임은 연습할 수 있는 완화책이 있는 임상 위해 요인이기 때문이다.

7. 사후 학습을 비난 없이 체계적으로 다루라. 모든 중대한 인시던트 뒤에, 누구를 탓할지가 아니라 시스템이 어떻게 그 실패를 허용했는지 묻는 검토를 실행하라. 비난은 보고를 지하로 몰아넣고 해악을 반복하기 때문이다. 조치를 기록하고, 소유자를 지정하며, 종결까지 추적하고, 패턴을 문제 관리와 설계에 되먹이라. 학습 문화는 임상 인시던트 보고의 "공정한 문화(just culture)"를 반영하는 환자 안전 통제다.

8. 정확한 구성 기록을 유지하고 자산 전체를 관리하라. 무엇이 운영되는지, 무엇이 무엇에 의존하는지, 어떤 버전이 배포되었는지, 각 서비스를 누가 소유하는지 CMDB나 동등한 목록으로 유지하여, 인시던트 중에 "이것이 무엇에 영향을 주는가?"에 몇 분 안에 답할 수 있게 하라. 이는 안전한 변경, 보안 패치, 라이선싱을 떠받치며 대부분의 큰 NHS 자산이 가장 약한 곳이다. 알려지지 않고 패치되지 않은 시스템은 장애이자 일어날 사이버 보안 사건이다(주제 1.7 참조).

9. 대기 근무를 지속 가능하게 하고 지원을 인간적으로 하라. 충분한 인력이 배치되고, 공정하게 보상받고, 인간적인 대기 근무 순번을 명확한 상향 보고와 현실적인 기대와 함께 설계하라. 소진된 대응자는 가장 중요한 바로 그 순간에 느리고 오류가 잦은 결정을 내린다. 서비스 데스크에는 24/7 임상 인력의 실제 수요만큼 자원을 대고, 일선 직원에게 문제를 보고할 빠르고 존중받는 경로를 주라. 지원의 질이 서비스에서 직원이 경험하는 돌봄의 질이다.

10. 폐기를 통제된 운영으로 계획하라. 서비스가 라이브인 동안 결국 어떻게 폐기될지 정하라. 기록 보존법에 따른 데이터 이전 또는 보관, 사용자 안내, 임상의 통지, 위해 요인 로그와 감사 추적의 보존이다. 계획되지 않은 폐기는 데이터와 사용자를 좌초시키고 법정 보존 의무를 위반할 수 있다. 계획된 폐기는 대체물이 도착할 때의 허둥지둥이 아니라 감사 가능한 운영 프로젝트다.

팀과 논의할 질문#

1. 공휴일 새벽 3시에 핵심 임상 시스템이 다운되면 정확히 누가 무엇을 하며 — 그것을 시험해 본 적이 있는가? 이 질문은 문서화된 계획과 실제 역량의 차이를 강제한다. 보건·돌봄에서 다운타임은 임상 사건이다. 실무적 질문은 누가 호출되는지, 얼마나 빨리 대응하는지, 누가 중대 인시던트를 선언할 권한이 있는지, 임상 직원이 다운타임 절차로 전환하라는 지시를 어떻게 받는지, 환자가 종이 위에서 어떻게 안전을 유지하는지, 복구 시 데이터를 어떻게 대조하는지다. 대기 근무 순번이 사회적으로 불편한 시간대와 공휴일에도 실제로 유능한 인력을 두는지, 위험이 가장 높을 때 탈진한 한 사람으로 줄어드는지 토론하라. 임상의가 다운타임 절차를 알고 연습해 본 적이 있는지, 아무도 열어 본 적 없는 바인더에 있는지 생각하라. 좋고 정직한 답은 장애를 한 번도 만난 적 없는 정책 문서가 아니라 명명된 역할, 지난 1년 안의 실제 훈련, 조치된 교훈과 함께 시험된 대응을 설명한다. 정직한 답이 "사실 잘 모른다"라면, 그것이 이사회에 드러내야 할 가장 중요한 발견이다.

2. 우리는 "운영"에 진정으로 재원을 대고 인력을 배치하고 있는가, 아니면 가동을 축하하고 조용히 떠났는가? 서비스 비용과 임상 위험의 대부분은 출시 후에 있지만, 재원 모델은 새로운 것을 만드는 데 보상하고 오래된 것을 운영하는 데는 굶긴다. 토론할 긴장은 구축 재원의 구조적 끌림 대 라이브 서비스를 몇 년 동안 모니터링하고, 패치하고, 지원하고, 반복하는 화려하지 않지만 필수적인 업무다. 라이브 자산을 정직하게 보라. 지명된 소유자, 재원이 있는 팀, 최신 보안 패치, 작동하는 모니터링을 가진 서비스가 몇 개이고, 아무도 책임지지 않은 채 지원 종료된 소프트웨어 위에서 운영되는 고아가 된 서비스가 몇 개인가? "운영팀에 벽 너머로 던지기" 패턴과, 각 서비스를 운영하는 사람들이 그것이 어떻게 만들어졌는지 이해하는지 생각하라. 좋은 답은 보호된 운영 예산, 운영 수명 동안의 지명된 서비스 소유자, 방치가 아닌 의도적 서비스 전환을 가리킬 수 있고, 고아가 된 서비스를 정직하게 명명하여 실패하게 두지 않고 입양, 교체, 폐기할 수 있게 한다.

3. "충분히 신뢰할 만하다"가 무엇을 뜻하는지 어떻게 결정하며 — 누가 발언권을 갖는가? 신뢰성은 공짜가 아니며, 가용성의 아홉 하나를 더 쫓는 것이 막는 해악보다 비쌀 수 있다. 그러나 임상 시스템에서 "허용 가능한" 다운타임은 엔지니어 혼자 내릴 수 없는 안전의 판단이다. 이 질문은 명시적인 SLI와 SLO가 있는지, 그 결과를 감당하는 임상의와 운영 리더와 함께 정했는지, 개선 출시와 안정성 유지의 균형을 잡는 데 오류 예산 같은 것을 쓰는지 묻는다. 관리하는 내부 목표와 약속하는 외부 SLA의 차이, 그리고 모니터링이 서버가 보고하는 것만이 아니라 임상의가 실제로 경험하는 것을 측정하는지 토론하라. "우리는 99.9%를 목표로 한다"에 이빨이 있는지 생각하라. 정의된 측정, 위반 시의 결과, 조치하는 소유자다. 좋은 답은 신뢰성 목표를 임상 안전 근거에 연결하고, 지표가 측정되고 소유됨을 보여 주며, 아무도 맞추어 관리하지 않는 슬라이드 속 숫자가 아니라 예산이 소진되었을 때 팀이 무엇을 다르게 하는지 설명한다.

4. 우리가 무엇을 운영하는지 실제로 아는가 — 그리고 인시던트 한가운데서 "이 변경은 무엇에 영향을 주는가?"에 답할 수 있는가? 대부분의 큰 보건·돌봄 자산은 바로 가장 아픈 곳에서 가장 약하다. 무엇이 운영되는지, 무엇이 무엇에 의존하는지, 어떤 버전이 배포되었는지, 각 서비스를 누가 소유하는지에 대한 정확하고 현재의 그림을 아무도 갖고 있지 않다. 이 질문은 구성 기록 — CMDB 또는 동등한 것 — 을 유지하는지, 아니면 그 지식이 소수의 머릿속과 십 년 치 문서화되지 않은 통합에 있는지 탐색한다. 실제 결과를 토론하라. 하류 시스템을 조용히 깨뜨리는 변경, 무엇을 건드릴지 아무도 몰라 적용할 수 없는 보안 패치, 고장 나거나 악용될 때야 발견되는 지원 종료된 서버다. 긴장은 구성 관리가 화려하지 않고, 결코 끝나지 않으며, 미루기 쉽지만, 안전한 변경, 패치, 라이선싱, 사이버 회복탄력성을 모두 떠받친다는 점이며, WannaCry를 위기로 바꾼 바로 그 맹점이다. 정직한 답은 사람들이 신뢰하고 인시던트 중에 쓰는, 소유자와 의존성이 있는 유지되는 목록을 설명하고, 어떤 큰 조직도 진정으로 갖지 못한 완전성을 주장하는 대신 여전히 어두운 자산의 부분을 명명한다.

5. 무언가 잘못되었을 때 우리는 배우는가, 아니면 탓할 사람을 찾는가? 인시던트 검토의 문화가 같은 해악이 반복되는지를 결정한다. 이 질문은 심각한 인시던트가 시스템이 어떻게 실패를 허용했는지 묻는 비난 없는 체계적 검토를 촉발하는지, 아니면 조용히 탓할 개인을 찾아 보고를 지하로 몰아넣고 반복을 보장하는지 묻는다. 아차 사고와 작은 실패가 표면화되기는 하는지, 숨기기에는 너무 큰 장애만 표면화되는지, 검토 조치에 소유자가 지정되고 종결까지 추적되는지 적어 두고 잊히는지, 패턴이 문제 관리와 설계에 되먹여지는지 토론하라. 임상 인시던트 보고와 "공정한 문화"와의 유사성을 생각하라. 같은 조직이 환자 안전 사건에는 성숙하고 비난 없는 입장을, IT 실패에는 징벌적 입장을 갖거나 그 반대일 수 있다. 좋은 답은 증거가 있는 학습 문화, 곧 시스템을 바꾼 검토, 종결된 조치, 줄어드는 재발을 보여 주고, 두려움이 여전히 보고를 억누르는 곳을 정직하게 인정한다. 학습 문화는 그 자체로 환자 안전 통제이며 부드러운 덤이 아니기 때문이다.

6. 서비스가 아직 살아 있어 계획할 수 있을 때, 이 서비스를 결국 어떻게 폐기할지 정했는가? 모든 서비스는 결국 교체되거나 꺼지지만, 폐기는 거의 언제나 사후 고려이며 후속 시스템이 도착하고 옛 시스템이 이미 장애물이 되었을 때 허둥지둥한다. 이 질문은 각 라이브 서비스에 대해 안전한 폐기 계획이 있는지 묻는다. 기록 보존법에 따라 이전되거나 보관된 데이터, 안내된 사용자, 통지받은 임상의, 보존된 위해 요인 로그와 감사 추적이다. 이를 잘못했을 때의 구체적인 보건·돌봄 위험을 토론하라. 법정 보존 의무를 위반하는 좌초된 기록, 아무도 접근할 수 없는 고아 데이터, 그 끝을 아무도 소유하지 않아 패치되지 않은 채 몇 년씩 남는 "임시" 레거시 시스템이다. 국가 및 대기업 자산에서는 수십 년 치 임상 기록이 법적으로 요구되는 기록 하나도 잃지 않고 폐기되어야 하는 시스템 안에 있을 수 있음을 생각하라. 정직한 답은 폐기를 가동 때부터 계획된, 이름이 있고, 재원이 있고, 감사 가능한 운영으로 다루지 나중에 발견될 비용으로 다루지 않으며, 수명 종료가 미뤄지지 않고 이미 정해진 서비스를 적어도 하나 가리킬 수 있다.

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

한 통합 돌봄 시스템(ICS)이 한 지역의 병원 임상의, 일반의, 지역사회 팀, 시간외 서비스가 쓰는 공유 진료 기록을 운영한다. 2년 전 가동되었고, 구축 프로그램은 종료되었으며, 상설 제품-운영 팀이 이제 이를 소유한다. 이 팀은 서비스 관리를 어렵게 배웠다.

초기에 기록은 서버 가동 시간만 모니터링했다. 어느 겨울 저녁, 서버는 "녹색"이었는데 실패하는 통합이 일반의의 약물 업데이트 흐름을 조용히 멈추게 했고, 병원 임상의들은 약사가 알아채고 서비스 데스크에 전화하기까지 몇 시간 동안 낡은 약물 목록을 보았다. 사후 검토는 비난이 없고 체계적이었다. 진짜 문제는 임상의의 경험을 반영하는 SLI의 부재임을 발견했다. 팀은 종단 간 관측 가능성, 임상 안전 책임자와 공동으로 합의한 데이터 신선도 SLO, 업데이트가 안전 임계를 넘어 지연되면 대기 근무자를 호출하는 경보를 추가했다. 이 위해 요인은 임상 위험 위해 요인 로그(주제 1.6)에 추가되었다.

그런 다음 실천을 적정 규모로 맞췄다. 일상적이고 저위험인 구성 업데이트는 빠른 롤백이 있는 자동화 파이프라인으로 출시되는 표준 사전 승인 변경이 되었고, 진정으로 위험한 변경만 임상 대표가 참여하는 주간 변경 검토로 간다. 인간적인 대기 근무 순번이 밤과 공휴일을 맡고, 실제 24/7 수요에 맞춰 자원을 갖춘 서비스 데스크가 뒷받침한다. 결정적으로, 임상 다운타임 절차를 작성하여 이제 연 2회 연습한다. 주요 기록의 읽기 전용 캐시 사본, 종이 대비책, 시스템이 저하되었음을 임상의에게 알리는 SMS 연쇄, 복구 시 대조 단계다. 지난봄 데이터센터 전원 장애로 주 시스템이 40분 동안 오프라인이 되었을 때 돌봄은 시험된 대비책 위에서 계속되었고, 인시던트 지휘관은 차분하고 조율된 대응을 이끌었으며, 환자는 해를 입지 않았다. 이사회는 모호한 안심이 아니라 임상 안전 지표에 묶인 신뢰성 보고를 보았고, 서비스에 대한 소유권은 결국 폐기까지 이름이 있고 재원이 마련되어 있다.

부문별 관점#

스타트업#

소규모 보건 기술 기업은 흔히 별도의 운영 기능이 없으므로 "만든 사람이 운영한다"는 열망이 아니라 기본이다. 코드를 쓴 같은 엔지니어가 호출기를 든다. 장점은 빠른 피드백과 일을 던질 벽이 없다는 것이고, 위험은 지속 가능하지도 안전하지도 않은 두 명의 대기 근무 순번과 "서버가 켜져 있는가?"에서 멈추는 모니터링이다. 스타트업은 첫 NHS 고객부터 SLO, 기본 관측 가능성, 비난 없는 사후 검토, 서면 다운타임 절차를 채택해야 한다. 임상 장애가 계약과 회사를 모두 끝낼 수 있기 때문이다. ITIL의 의식이 없어도 그 의도 — 서비스를 보고, 빨리 대응하고, 체계적으로 학습하고, 실패할 때 환자를 안전하게 지킨다 — 는 보건에서 타협할 수 없다.

소규모 사업체#

확립된 소규모 제공자 — 일반의 진료소, 지역 약국, 요양원, 단일 사업장 클리닉 — 는 매일 라이브 임상 시스템을 운영하지만 보통 전담 IT 기능이 없고 서비스 관리가 직무인 사람이 없다. 여기서 "운영"은 임상 및 행정 업무의 가장자리에 끼워 넣어지고, 대기 근무는 사실상 "진료소 관리자의 휴대전화"이며, 모니터링은 임상의가 예약 화면이 멈춘 것을 알아차리는 것이다. 실용적 우선순위는 환자를 안전하게 지키는 몇 가지다. 서면으로 작성되고 연습된 다운타임 절차(진료소가 종이로 어떻게 진료하고 나중에 대조하는지), 호스팅된 시스템이 실패할 때 각 공급업체로 상향 보고하는 알려진 경로, 그 공급업체가 실제로 어떤 SLA를 빚지고 있는지에 대한 명확성이다. 스타트업 단계를 지난 소규모 독립 보건 기술 공급업체는 거울상의 문제에 직면한다. 실제 고객이 의존하지만 운영 대응은 얇다. 빠듯한 현금에도 신뢰할 만한 지원 시간과 인시던트 대응을 제공해야 한다. 돌봄의 의무는 대형 트러스트와 같지만 자원은 그렇지 않으므로, 규율은 ITIL의 완전성보다 안전이 중요한 기본을 철저히 우선하는 것이다.

대기업#

NHS 트러스트나 대형 공급업체는 서비스 관리를 가장 완전한 형태로 운영한다. 공식 서비스 데스크, ITIL에 맞춘 인시던트/문제/변경 실천, 변경 자문 위원회, 중대 인시던트 및 업무 연속성 계획, 흔히 24/7 운영 센터다. 특징적인 과제는 구성 기록이 약하고, 패치되지 않은 시스템이 있으며, 소유권이 불분명한 방대한 레거시 자산으로, WannaCry를 위기로 바꾼 바로 그 조건이다. 고전적 실패는 직원이 우회할 만큼 무거운 변경 프로세스와, 다음 구축에 재원을 대려고 끊임없이 굶는 "운영"이다. 대기업은 관측 가능성, 지속 가능한 대기 근무, 시험된 연속성을 제대로 할 자원이 있으므로, 과제는 실천을 비례적으로 유지하고 거짓 보증을 주는 서류의 의례가 아니라 진정으로 임상적으로 소유하게 하는 것이다.

정부#

국가 기관은 수백만 명에게 닿을 수 있는 서비스를 운영하므로 장애는 의회와 대중 신뢰의 결과를 낳는 국가적 사건이며, 신뢰성 목표는 공적 책임의 문제다. 정부 딜리버리는 ITSM을 라이브 서비스가 가동 때 얼어붙지 않고 제대로 운영, 모니터링, 반복되어야 한다는 GOV.UK Service Manual의 기대와, 기록 보존과 사이버 보안(NCSC, DSPT)에 관한 법정 의무와 결합한다. 지출 통제와 다년 재원 합의가 "운영" 재원의 모습을 형성하며, 방대한 규모는 업무 연속성, 조율된 중대 인시던트 대응, 수십 년 치 기록을 가진 국가 레거시 시스템의 안전한 폐기에 대한 위험을 높인다. 상충 관계는 보증과 회복탄력성 대 속도와 비용이며, 감시 아래 공개적으로 해소된다.

흔한 실패 양상#

• 운영팀에 벽 너머로 던지기. 구축 팀이 만드는 것을 본 적 없는 운영 팀에 서비스를 넘기고, 지식, 소유권, 안전이 틈새로 샌다. 해독제: "만든 사람이 운영한다", 또는 보증 기간과 공유된 대기 근무가 있는 의도적 전환.
• 고아가 된 라이브 서비스. 프로젝트가 종료되고, 팀이 해산하고, 운영 재원이 증발하여, 서비스가 썩고, 패치되지 않으며, 임상 및 사이버 위험이 소리 없이 쌓인다. 해독제: 운영 수명 동안 지명된 서비스 소유자와 보호된 운영 예산.
• 서비스가 아니라 서버만 모니터링. 임상의가 낡거나 누락된 데이터를 보는데 모든 것이 "녹색"이다. 해독제: 사용자와 임상의의 경험을 반영하는 SLI와 중요한 증상에 대한 경보.
• 시험되지 않은 연속성 계획. 임상 다운타임 절차가 종이 위에는 있지만 연습된 적 없어 당일에 실패한다. 해독제: 중대 인시던트와 다운타임 계획을 정기적으로 훈련하고 깨진 것을 고치라.
• 비난 중심의 인시던트 검토. 잘못 찾기가 보고를 지하로 몰아넣고 해악을 반복한다. 해독제: 조치가 추적되는 비난 없는 체계적 사후 학습.
• 변경 프로세스 연극. 팀이 우회할 만큼 무겁거나, 위험한 변경이 점검 없이 출시될 만큼 가벼운 변경 위원회. 해독제: 적정 규모화 — 표준 변경은 사전 승인하고, 검토는 진정으로 위험한 것에 남겨 두라.
• 구성 기록 없음. 인시던트 중에 아무도 "이 변경은 무엇에 영향을 주는가?"에 답할 수 없다. 해독제: 소유권과 의존성이 있는 CMDB 또는 동등한 것을 유지하라.

성숙도 모델#

체크리스트#

• 모든 라이브 서비스에 지명된 소유자와 운영 수명 동안의 보호된 운영 예산이 있다.
• 각 서비스를 운영하는 팀이 그것이 어떻게 만들어졌는지 이해한다(또는 보증 기간과 공유된 대기 근무가 있는 문서화된 전환이 있다).
• SLI와 SLO가 정의되어 있고, 임상 시스템의 목표는 임상의와 함께 정했으며, 외부 SLA는 내부 SLO보다 느슨하다.
• 관측 가능성(로그, 지표, 트레이스)과 증상 기반 경보가 서버 건전성만이 아니라 임상의와 사용자의 경험을 반영한다.
• 인시던트 관리에 심각도 수준, 대응 목표, 인시던트 지휘관 역할, 대응 중의 단일 진실 원천이 있다.
• 문제 관리가 근본 원인을 고치며, 사후 검토는 비난이 없고 그 조치는 종결까지 추적된다.
• 변경 관리가 적정 규모이다: 표준 변경은 사전 승인되고 자동화되며, 위험한 변경만 임상 입력과 함께 검토된다.
• 업무 연속성과 임상 다운타임 절차가 작성되어 위해 요인 로그에 연결되고 적어도 연 1회 연습된다.
• 대기 근무 순번에 충분한 인력이 배치되고, 인간적이며, 공정하게 보상받고, 서비스 데스크는 실제 24/7 수요에 맞춰 자원을 갖춘다.
• 구성 기록(CMDB 또는 동등한 것)이 구성 요소, 의존성, 버전, 소유자를 나열하고 보안 패치를 지원한다.
• 폐기 계획이 보존법에 따른 데이터 이전/보관, 사용자 안내, 안전 및 감사 기록의 보존을 다룬다.

주요 출처#

• ITIL 4 — 서비스 가치 시스템과 관리 실천(인시던트, 문제, 변경, 서비스 데스크, 서비스 수준 관리) — PeopleCert / AXELOS.
• Google — Site Reliability Engineering과 The Site Reliability Workbook (SLI, SLO, 오류 예산, 대기 근무, 비난 없는 사후 분석).
• GOV.UK Service Manual — 라이브 서비스의 운영과 반복; 서비스 상태 모니터링; 출시 후 서비스 유지.
• NHS England — 임상 위험 관리 표준 DCB0129/DCB0160과 시스템 다운타임을 임상 위해 요인으로 다루기(주제 1.6 참조).
• NHS England / NCSC — 사이버 보안 운영, Data Security and Protection Toolkit (DSPT), 2017년 WannaCry 사건의 교훈(주제 1.7 참조).
• ISO/IEC 20000 (IT 서비스 관리)과 ISO 22301 (업무 연속성 관리 시스템).
• DevOps Research and Assessment (DORA) — 딜리버리와 운영 성과(모니터링, 변경, 신뢰성)를 연결하는 역량.
• 리더십에 대한 운영 및 신뢰성 보고를 위한 OKR과 KPI (주제 10.0 — 목표와 핵심 결과(OKR) 참조).

참고문헌#

1. IT service management — Wikipedia — https://en.wikipedia.org/wiki/IT_service_management
2. ITIL — Wikipedia — https://en.wikipedia.org/wiki/ITIL
3. Incident management — Wikipedia — https://en.wikipedia.org/wiki/Incident_management
4. Change management (ITSM) — Wikipedia — https://en.wikipedia.org/wiki/Change_management_(ITSM)
5. Business continuity planning — Wikipedia — https://en.wikipedia.org/wiki/Business_continuity_planning
6. Site reliability engineering — Wikipedia — https://en.wikipedia.org/wiki/Site_reliability_engineering
7. Service-level agreement — Wikipedia — https://en.wikipedia.org/wiki/Service-level_agreement
8. Service-level objective — Wikipedia — https://en.wikipedia.org/wiki/Service-level_objective
9. Service level indicator — Wikipedia — https://en.wikipedia.org/wiki/Service_level_indicator
10. Observability (software) — Wikipedia — https://en.wikipedia.org/wiki/Observability_(software)
11. DevOps — Wikipedia — https://en.wikipedia.org/wiki/DevOps
12. Configuration management database — Wikipedia — https://en.wikipedia.org/wiki/Configuration_management_database
13. Help desk — Wikipedia — https://en.wikipedia.org/wiki/Help_desk
14. Site Reliability Engineering (SRE book) — Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy (eds.), Google — https://sre.google/books/
15. ITIL 4 Foundation and service management practices — PeopleCert / AXELOS — https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-foundation-2565
16. Service Manual: operating a service and monitoring its status — Government Digital Service, GOV.UK — https://www.gov.uk/service-manual/technology/monitoring-the-status-of-your-service
17. Clinical risk management standards DCB0129 and DCB0160 — NHS England (Clinical Safety) — https://digital.nhs.uk/services/clinical-safety
18. Investigation: WannaCry cyber attack and the NHS — National Audit Office — https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/
19. ISO/IEC 20000-1 — IT service management systems — International Organization for Standardization — https://www.iso.org/standard/70636.html
20. ISO 22301 — Security and resilience: business continuity management systems — International Organization for Standardization — https://www.iso.org/standard/75106.html
21. DevOps Research and Assessment (DORA) capabilities — Google Cloud / DORA — https://dora.dev/