3주 동안 아무도 눈치채지 못했던 병원 청구 시스템 오류

소개

지난 봄, 중서부 지역의 한 병원 시스템은 평소와 같은 변경 절차를 통해 스케줄링 패치를 적용했습니다. 별다른 문제는 없었습니다. 퇴원 시간과 청구 모듈의 연동 방식을 업데이트하는 일상적인 작업이었죠. 3주 후, 미수금 담당자 중 한 명이 타임스탬프 불일치로 인해 일괄적으로 반송된 청구 건들을 발견했습니다. IT 부서가 원인을 추적해 냈을 때, 이 수정 작업은 이미 400명이 넘는 환자의 보험 청구 건에 영향을 미친 후였습니다. 엄밀히 말해 누구도 잘못한 것은 없었습니다. 이 업데이트는 체크리스트에 명시된 모든 테스트를 통과했습니다. 단지 올바른 체크리스트가 아니었을 뿐입니다.

이 이야기가 제 머릿속에 깊이 남아 있는 이유는, 이 이야기가 사실 병원에 관한 것이 아니기 때문입니다. 이는 조직의 배경에서 조용히 작동하는 시스템들이 정기적인 점검이 필요한 ‘살아있는 인프라’가 아니라 완성된 제품으로 취급될 때 어떤 일이 벌어지는지에 대한 이야기입니다.

2년 전에 구축한 자동화 시스템은 여러분이 생각하는 그 자동화 시스템이 아닙니다

대부분의 기업은 구체적이고 눈에 띄는 골칫거리를 해결하기 위해 첫 번째 워크플로 자동화 시스템을 구축합니다. 인사팀은 휴가 신청서를 수동으로 전달하는 데 지쳐 있고, 영업 운영 담당자는 영업 사원들이 유리한 건만 골라 처리하는 것을 막기 위해 리드 배정을 자동화합니다. 이러한 시스템은 Power Automate와 유사한 자동화 도구를 사용하여 구축되는데, 구성하기 빠르고, 관리할 의향이 있는 사람이라면 누구에게나 쉽게 넘길 수 있으며, 일단 작동하기 시작하면 대부분 눈에 띄지 않게 됩니다.

문제는 “일단 작동하기 시작하면” 그 상태가 영구화된다는 점입니다. 아무도 검토 일정을 잡지 않습니다. 시스템을 구축한 사람은 다른 팀으로 이동하거나 회사를 떠납니다. 그 사이 비즈니스 환경은 자동화 시스템 주변에서 변화합니다. 새로운 CRM 필드가 추가되거나, 승인 계층 구조가 바뀌거나, 합병으로 인해 원래 절반의 부하를 감당하도록 설계된 시스템을 통해 처리되는 업무량이 두 배로 늘어나기도 합니다. 자동화 시스템은 설계된 대로 정확히 계속 작동하는데, 바로 이것이 문제입니다. 이 시스템은 더 이상 그 형태 그대로 존재하지 않는 회사를 위해 설계된 것이기 때문입니다.

한 물류 회사가 공급업체가 API 필드 이름을 변경한 탓에 자동화된 예외 처리 흐름이 11개월 동안 아무도 모르게 오작동하고 있었다는 사실을 발견한 사례를 본 적이 있습니다. 해결책은 무엇이었을까요? 누군가가 일회성 문제라고 가정하고, 아무에게도 알리지 않은 채 오류가 발생한 사례를 수동으로 다시 입력해 온 것이었습니다. 이는 도구의 결함이 아닙니다. 모두가 안정적이라고 여겼던 시스템을 재검토하지 못한 조직의 실패입니다.

병원도 동일한 위험을 안고 있지만, 그 위험의 대가는 훨씬 더 큽니다

같은 패턴을 병원의 임상 및 행정 시스템에 적용해 보면, 실수 허용 범위는 극도로 좁아집니다. 병원 소프트웨어 개발은 일반적으로 적응성보다 규정 준수 및 가동 시간을 우선시해 왔습니다. 배포 실패가 새벽 2시에 간호사가 투약 이력을 조회하지 못하게 될 수 있다는 점을 고려하면 이해할 수 있는 일입니다. 하지만 이러한 과도한 신중함 때문에 레거시 시스템은 본래 있어야 할 기간보다 훨씬 더 오랫동안 운영 환경에 남아 있으며, 재구축보다는 임시방편으로 패치만 반복됩니다. 아무도 핵심 기능을 망가뜨리는 사람이 되고 싶어 하지 않기 때문입니다.

그 결과, 아무도 기억하지 못하는 결정들이 쌓여 있는 아키텍처가 만들어집니다. 일정 관리 모듈은 2016년에 구축된 통합 기능을 통해 청구 시스템과 연동되는데, 이 통합 기능은 병원이 2019년에 사용을 중단한 공급업체를 위해 만들어진 것입니다. 여전히 대부분은 작동합니다. 하지만 ‘대부분’이라는 말은 환자 데이터와 관련해서는 결코 원치 않는 표현입니다.

서서히 변화하고 있는 점은, 의료 IT 분야의 복원력이 단순히 변화를 피하는 것이 아니라, 규정이 변경되거나 새로운 EHR 모듈이 추가될 때마다 기적 같은 일이 일어나지 않아도 변화를 흡수할 수 있을 만큼 유연한 시스템을 구축하는 것이라는 인식입니다.

왜 “고장 나지 않았다면”이라는 기준이 잘못된 것인지

두 시나리오 모두에 공통된 점은 이렇습니다. 시스템은 고장 나지 않았습니다. 설정된 대로 정확히 작동하고 있었습니다. 바로 그 때문에 아무도 그 시스템들을 살펴보지 않았던 것입니다.

고장 난 시스템은 정의상 주목을 받습니다. 누군가 불만을 제기하거나, 무언가가 중단되거나, 지원 요청이 접수되기 때문이죠. 위험한 시스템은 겉으로는 잘 작동하는 것처럼 보이지만, 조직이 실제로 필요로 하는 것과 조용히 동떨어져 가는 시스템들입니다. 여전히 실행되지만 잘못된 부서로 전달되는 워크플로우 자동화. 여전히 데이터를 전송하지만, 하류 시스템이 이제 의존하고 있는 필드를 제거해 버리는 병원 인터페이스 등이 그 예입니다.

감사 작업은 화려하지 않지만, 대안도 마찬가지입니다.

해결책은 개념적으로는 복잡하지 않지만, 실제로는 지루할 수 있습니다. 과거에 얼마나 잘 작동했는지와 상관없이, 무인 상태로 운영되는 모든 시스템에 대해 정기적인 검토 일정을 잡으십시오. 현재 누가 그 시스템을 관리하는지 물어보십시오. 시스템이 구축된 이후 상류 및 하류에서 무엇이 바뀌었는지 물어보십시오. 내일 그 시스템이 조용히 작동을 멈추더라도 누군가 눈치챌지 물어보십시오.

대부분의 조직은 이를 생략합니다. 이는 발전이라기보다 유지보수처럼 느껴지기 때문이며, 유지보수는 예산이나 찬사를 거의 받지 못하기 때문입니다. 하지만 이를 생략할 때 발생하는 비용은 사라지지 않습니다. 단지 미수금 담당자가 숫자가 맞지 않는다는 사실을 알아차릴 때까지 조용히 기다릴 뿐입니다.