벽이 무너졌을 때 — Safety-II로 의료 시스템을 설계하다

무시되는 95%

2014년, Erik Hollnagel은 안전 과학자들의 사고방식을 조용히 바꾼 한 권의 책을 출간했습니다^[1]. 그의 주장은 단순하면서도 불편했습니다. 안전 분야가 수십 년간 일이 잘못되는 소수의 사례만 연구해 왔으며, 일이 잘 되는 압도적 다수의 사례는 거의 완전히 무시해 왔다는 것입니다.

그는 전통적 접근법을 Safety-I이라 불렀습니다. 실패 모드를 식별하고, 방어선을 구축하고, 나쁜 결과를 예방하는 방식입니다. 모든 체크리스트, 모든 안전장치, 모든 "정말 하시겠습니까?" 확인창의 근간입니다. 그리고 이 방식은 효과적입니다. 효과적이지 않을 때를 제외하면.

대안인 Safety-II는 다른 질문에서 출발합니다. 왜 일이 가끔 실패하는지를 묻는 대신, 왜 대개 성공하는지를 묻습니다. 그 답은 "좋은 방벽을 세웠기 때문"이 아닙니다. "사람들이 적응하기 때문"입니다. 간호사는 즉흥적으로 대응합니다. 의사는 프로토콜이 맞지 않을 때 프로토콜에서 벗어납니다. 물류 담당자는 아무도 계획하지 않은 우회책을 찾아냅니다.

Safety-I은 이 변동을 문제로 취급합니다. Safety-II는 이를 회복탄력성(resilience)의 핵심 원천으로 취급합니다.

Safety-I 사고를 무너뜨린 시나리오

저희는 xGrid를 개발하고 있었습니다. Raspberry Pi 장치에서 오프라인으로 작동하는 재난 의료 물류 플랫폼입니다. 초기 개발 단계에서 저희의 설계는 철저히 Safety-I이었습니다. 바코드 스캔, 신원 확인, 다단계 확인 대화상자, 역할 기반 접근 제어.

그러다 도상 훈련을 실시했습니다. 시나리오는 다음과 같습니다.

8개 의료 스테이션 중 3개가 동시에 강제 대피해야 합니다. 대피 시점에 다음 작업이 진행 중이었습니다:

• 엄격한 보관 연속성(chain of custody) 요건이 있는 수혈
• 중단 후 다른 곳에서 재개해야 하는 수술
• 스테이션 간 이송 중인 의약품으로 재배분이 필요한 상태

저희의 Safety-I 시스템은 개별 점검은 잘 처리했습니다. 처리하지 못한 것은 상황 그 자체였습니다. 시스템은 안정적인 운영 조건을 전제했습니다. 현실은 정반대를 제공했습니다.

정상 조건에서 오류를 방지하는 것뿐 아니라, 비정상 조건에서 사람들이 성공하도록 적극적으로 돕는 무언가가 필요했습니다.

배운 네 가지 원칙

1. 불확실성을 가시화하라

소프트웨어 설계의 본능은 깨끗하고 확신에 찬 정보를 제시하는 것입니다. 한정어 없는 숫자. 초록 아니면 빨강인 상태 표시기, 결코 노란색은 아닙니다.

재난 시나리오에서 이 확신은 위험합니다. 재고 데이터가 3일간 동기화되지 않았는데 마지막으로 확인된 수량을 마치 현재인 것처럼 표시하면 잘못된 결정으로 이어집니다. 간호사는 시스템이 12단위라고 표시하기 때문에 실물 확인을 건너뛸 수 있습니다. 실제로는 4단위일 수 있습니다.

xGrid는 모든 데이터 포인트에 신선도 메타데이터(freshness metadata)를 태깅합니다. 동기화가 임계값을 초과하면 인터페이스에 stale(오래됨) 표시가 나타납니다. 이것은 오류 표시가 아닙니다. 정직함의 신호입니다. 운영자에게 "이 숫자가 틀릴 수 있습니다. 행동하기 전에 확인하십시오"라고 알려줍니다.

불확실성을 인정하는 시스템이 이를 숨기는 시스템보다 더 신뢰할 만합니다. 사용자는 시스템이 데이터를 신뢰하지 말아야 할 때를 알려주기 때문에 오히려 시스템을 신뢰하게 됩니다.

2. 허용적이 아니라 우아하게 기능을 저하시켜라

시스템이 비상 모드에 들어가면 설계자는 딜레마에 직면합니다. 모두 잠그고 핵심 업무 차단 위험을 감수할 것인가, 아니면 모두 열고 오류 위험을 감수할 것인가.

대부분의 시스템은 한쪽 극단을 선택합니다. xGrid는 어느 쪽도 선택하지 않습니다.

비상 모드에서는 비필수 입력 항목을 제거합니다. 주소란, 보험 번호, 상세 알레르기 문서 — 모두 건너뛸 수 있습니다. 그러나 세 가지 확인 단계는 시스템 상태와 무관하게 의무적으로 유지됩니다:

• 환자 신원 확인
• 약물 이름 및 용량 확인
• 혈액 제제 교차적합시험(cross-match) 확인

설계 철학은 이렇습니다. 압박 하에서 사람들은 자연스럽게 단계를 건너뜁니다. 이것은 인간 행동의 결함이 아니라 적응입니다. 시스템의 역할은 기다릴 수 있는 단계는 건너뛰게 하면서, 기다릴 수 없는 단계는 건너뛸 수 없게 만드는 것입니다.

3. 기록은 학습을 위해 설계하라, 책임 추궁이 아니라

xGrid에서의 모든 인수인계는 기록을 생성합니다. 모든 약물 불출, 모든 이송, 모든 재고 이동입니다. 데이터는 완전한 이벤트 타임라인을 재구성할 수 있을 만큼 상세합니다.

그러나 저희는 대부분의 감사 시스템이 놓치는 특정 목적을 위해 기록 시스템을 설계했습니다. 성공에서 배우는 것이지, 실패에서만 배우는 것이 아닙니다.

다음 사례를 살펴보십시오. 유난히 원활했던 대피 후, 기록을 보니 한 간호사가 대피 명령이 내려지기 3분 전에 혈액 제제 데이터를 자신의 휴대폰에 미리 스캔해 두었습니다. 이것은 어떤 프로토콜에도 없었습니다. 즉흥적 판단이었습니다. 그리고 수용 스테이션에서 재스캔하는 시간을 15분 절약했습니다.

Safety-I은 이것을 절대 발견하지 못합니다. Safety-I은 무언가가 잘못되었을 때만 조사하기 때문입니다. Safety-II는 일상적으로 조사합니다. 성공의 원인은 실패의 원인만큼이나 이해할 가치가 있기 때문입니다. 그 간호사의 즉흥적 대응은 현재 권장 워크플로의 일부가 되었습니다.

4. 규칙을 깨는 합법적인 방법을 제공하라

일반적인 약물 불출 과정: 의사가 처방하고, 약사가 검증하고, 간호사가 확인하고, 불출합니다. 세 개의 관문입니다. 견고한 Safety-I입니다.

재난 현실: 의사는 스무 명의 환자를 분류하고 있습니다. 약사는 다른 스테이션에 있습니다. 환자에게 출혈이 있습니다. 간호사는 지혈제가 당장 필요합니다.

시스템이 "처방 없이는 불출 없음"이라고 하면, 간호사는 우회할 방법을 찾을 것입니다 — 종이 메모, 구두 지시, 약장 직접 접근. 약물은 투여됩니다. 시스템에는 아무것도 기록되지 않습니다.

xGrid는 24시간 긴급 오버라이드(break-glass)를 제공합니다. 간호사는 긴급 승인을 발동할 수 있습니다. 시스템은 해당 행위를 기록하고, 긴급 승인으로 태그하며, 사후 검토 대상으로 표시합니다. 완전한 감사 추적과 함께 업무가 계속됩니다.

이것은 안전 우회가 아닙니다. 안전 기능입니다. 시스템이 할 수 있는 가장 위험한 일은 사람들을 시스템 밖에서 일하도록 강제하는 것입니다. 그렇게 되면 모든 가시성을 잃기 때문입니다. 합법적이고 기록된 규칙 위반이 보이지 않는 우회책보다 무한히 안전합니다.

검증 결과: Patient I

저희의 E2E 테스트 스위트에는 Patient I — 통합 테스트(Consolidation Test)가 포함되어 있습니다. 가장 가혹한 조건에서 검증하도록 설계되었습니다.

설정: 8개 스테이션, 3개 동시 강제 대피. 대피 중 진행 중이던 상황:

• 수혈 중 (보관 연속성 유지 필수)
• 수술 진행 중 (중단, ISBAR 인수인계 기록, 이송, 재개 필수)
• 스테이션 간 의약품 이송 중 (생존 스테이션으로 재배분 필수)

결과:

검증 항목	결과
이송 과정에서 환자 신원이 보존됨	통과
혈액 보관 연속성 유지, 새 스테이션에서 교차적합시험 완료	통과
완전한 ISBAR 인수인계 기록과 함께 수술 재개	통과
통합된 모든 스테이션 간 재고 대조 완료	통과
34단계 실행, 34단계 통과, 데이터 손실 제로	통과

이것이 실전에서의 Safety-II입니다. 시나리오는 "대피를 막는 것"이 아닙니다 — 그것은 불가능합니다. 시나리오는 "대피를 성공시키는 것"입니다. 모든 데이터 포인트가 살아남았습니다. 모든 인수인계가 기록되었습니다. 모든 안전 게이트가 중요한 곳에서는 유지되었고, 양보가 필요한 곳에서는 양보했습니다.

대체가 아닌 보완

Safety-II는 방벽에 반대하지 않습니다. xGrid에는 여전히 바코드 스캔, 신원 확인, 용량 점검, 역할 기반 접근 제어가 있습니다. 이러한 Safety-I 메커니즘은 예방 가능한 오류를 방지합니다.

Safety-II는 나머지 모든 것을 다룹니다 — 조건이 너무 열악하여 정상 절차를 따를 수 없는 경우, 프로토콜이 보유하지 않은 자원을 전제로 하는 경우, 교과서적 답이 눈앞의 상황에 맞지 않는 경우입니다.

안정적인 환경에서는 Safety-I이 대개 충분합니다. 재난 환경에서는 필요하지만 충분하지는 않습니다.

벽은 반드시 무너집니다. 중요한 질문은 그다음에 무슨 일이 일어나느냐입니다.

---

관련 글: 워크어웨이 테스트 — 개발자가 사라져도 살아남는 소프트웨어 설계

---

참고 문헌

1. Hollnagel E. Safety-I and Safety-II: The Past and Future of Safety Management. Ashgate Publishing; 2014. DOI