휴가지에서 인슐린 펌프가 멈췄을 때 — 의료기기 의존자가 마주하는 디지털 인프라의 민낯

생명을 유지하는 기계가 휴가 중에 죽어버린다면

혹시 "내가 매일 쓰는 기계가 갑자기 멈춰버리면 어떡하지?" 같은 상상을 해본 적 있으세요? 우리가 쓰는 노트북이나 스마트폰이 멈추면 짜증나긴 해도, 며칠 정도는 어떻게든 버틸 수 있잖아요. 그런데 그 기계가 내 췌장 역할을 대신해주는 인슐린 펌프라면 이야기가 완전히 달라집니다. 한 1형 당뇨병 환자가 휴가 도중에 자신의 인슐린 펌프가 고장 났을 때 겪었던 일을 블로그에 남겼는데요, 이게 단순한 "기기 고장 후기"가 아니라 의료기기 산업, 소프트웨어 안정성, 그리고 환자가 의존하는 디지털 인프라의 취약성을 적나라하게 보여주는 이야기여서 개발자 입장에서 한 번쯤 곱씹어볼 만합니다.

인슐린 펌프가 뭐냐면

먼저 배경을 좀 풀어볼게요. 1형 당뇨병은 췌장이 인슐린을 거의 못 만드는 병이에요. 그래서 환자는 외부에서 인슐린을 계속 주입받아야 살 수 있는데, 옛날에는 하루에도 여러 번 주사를 놨지만 요즘은 작은 펌프를 몸에 붙이고 다니면서 자동으로 미세한 양을 계속 흘려보내는 방식이 많이 쓰여요. 이 펌프는 보통 연속 혈당 측정기(CGM)와 연결돼서, 혈당이 오르면 알아서 인슐린을 더 주고, 떨어지면 멈추는 "인공 췌장" 같은 폐쇄 루프 시스템으로 동작합니다. 즉, 펌프 + 센서 + 소프트웨어 알고리즘이 24시간 환자의 생명을 떠받치고 있는 거죠.

문제는 이게 결국 "전자기기"라는 점입니다. 배터리가 다 닳을 수도 있고, 소프트웨어가 멈출 수도 있고, 무선 통신이 끊길 수도 있어요. 그리고 이 환자분처럼 휴가지에서 문제가 터지면 진짜 비상 상황이 됩니다. 평소처럼 단골 병원에 갈 수도 없고, 자신의 보험이 적용되는 약국도 멀고, 시차가 있어서 제조사 고객센터 연결도 쉽지 않거든요.

실제로 벌어진 일

글에서 묘사된 상황을 따라가 보면, 처음엔 그냥 알림 하나로 시작합니다. "펌프 오류" 같은 메시지가 뜨고, 평소대로 재시작하면 될 거라고 생각하죠. 그런데 재시작이 안 되거나, 됐다 싶더니 곧바로 또 멈춰버리는 식의 반복이 일어납니다. 이때부터 환자는 빠르게 머릿속으로 계산을 시작해야 해요. "인슐린을 마지막으로 주입한 게 언제지? 지금부터 몇 시간 안에 다음 분량이 안 들어가면 케톤산증이 시작되지? 가장 가까운 응급실은 어디지? 지금 가진 펜형 주사기로 며칠 버틸 수 있지?"

결국 환자는 제조사에 연락을 시도하는데, 여기서 또 한 겹의 답답함이 추가됩니다. 의료기기 회사들의 고객 지원은 보통 "평일 9시~5시, 본국 시간 기준" 같은 식으로 운영되거든요. 휴가지에선 시차도 문제지만, 보증 처리, 대체 기기 배송, 임시 처방 발급 같은 절차가 국가나 보험에 묶여 있어서 며칠씩 걸립니다. 그동안 환자는 옛날 방식의 다회 주사로 돌아가서 직접 혈당을 재고 인슐린 양을 계산해야 해요. 폐쇄 루프 알고리즘이 자동으로 해주던 일을 손과 머리로 다시 하는 건데, 몇 년 동안 자동화에 익숙해진 사람한테는 생각보다 훨씬 위험하고 힘든 일이에요.

개발자 시각에서 보면 더 무겁게 다가오는 이야기

이 글이 단순한 환자 수기가 아닌 이유는, "우리가 만드는 소프트웨어가 누군가에게는 생명선이 될 수 있다"는 점을 정면으로 보여주기 때문이에요. 일반적인 SaaS는 다운타임 5분이면 SLA 위반이고 사과 메일 한 통이면 끝나지만, 의료기기는 다운타임 5분이 사람의 의식을 잃게 만들 수 있습니다. 그런데도 실제 의료기기 펌웨어와 모바일 앱들의 품질이 일반 IT 업계만큼 빠르게 좋아지고 있느냐 하면, 그렇지 않다는 게 환자들의 공통된 불만이에요. iOS나 안드로이드가 업데이트되면 호환성이 깨져서 갑자기 펌프 앱이 안 켜지는 일도 종종 보고됩니다.

또 흥미로운 건 이런 답답함 때문에 "#WeAreNotWaiting"이라는 환자 주도 오픈소스 운동이 생겼다는 점이에요. OpenAPS, Loop, AndroidAPS 같은 프로젝트들은 환자와 가족 개발자들이 직접 폐쇄 루프 알고리즘을 만들어서 상용 제품보다 먼저, 또는 더 유연하게 자신들을 치료해왔습니다. FDA 승인을 못 받은 채로 시작했지만 지금은 일부가 정식 제품에 영향을 주고 있을 정도예요. "내 생명을 다른 사람의 릴리스 주기에 맡기지 않겠다"는, 정말 묵직한 메시지가 담긴 커뮤니티죠.

한국 개발자에게는 어떤 의미일까

한국도 1형 당뇨 환자와 보호자들이 직접 Loop 같은 오픈소스 시스템을 빌드해서 쓰는 사례가 점점 늘고 있어요. 그런데 국내에서는 의료기기 규제, 인슐린·소모품 수급, 보험 적용 같은 문제가 더 얽혀 있어서 환자가 겪는 마찰이 훨씬 큽니다. 만약 여러분이 헬스케어, IoT, 임베디드 쪽에서 일한다면 이 글이 던지는 질문이 꽤 묵직할 거예요. "우리 제품이 멈췄을 때 사용자는 며칠을 버틸 수 있도록 설계됐나?", "오프라인 fallback은 있나?", "고객지원이 24시간 글로벌로 돌아가나?", "펌웨어 업데이트 롤백 전략은?" 같은 것들이요.

꼭 의료기기가 아니더라도, 우리가 만든 서비스가 누군가의 일상 인프라가 되는 순간 비슷한 질문이 적용됩니다. 모빌리티 앱, 결제 시스템, 출입 통제, 스마트홈, 다 마찬가지예요. "고장 났을 때의 시나리오"를 진지하게 설계 단계에서 다뤄야 한다는 걸 이 글이 환기시켜 줍니다.

마무리

한 줄로 정리하면, "기계에 생명을 맡긴 사람들에게 소프트웨어 품질은 기능이 아니라 윤리다"라는 이야기예요. 여러분이 만약 헬스케어나 안전 관련 시스템을 만든다면, 또는 일반 서비스라도 사용자의 일상에 깊게 들어간 제품을 다룬다면, 마지막으로 한 번 자문해보면 좋겠어요. 내가 만든 시스템이 새벽 3시 외국 휴가지에서 멈췄을 때, 사용자에게 어떤 가이드와 fallback을 줄 수 있나요? 여러분이 일하는 서비스에는 "의료기기급 신뢰성"이 필요한 영역이 어디일지 같이 이야기해 보면 좋겠습니다.