ORIGINAL FICTION
제65화 — 훈련
지난 화 끝부분 다시 보기
12주째.
첫 지역 재난대응 모의훈련.
가상의 상황은 대형 공연장 구조물 붕괴였다.
환자 67명.
중증 14.
중등도 31.
경증 22.
현장 구급대는 실제 무전절차를 사용했다.
병원도 훈련상황판을 운영했다.
Helioxen 시스템은 실시간으로 데이터를 받았다.
이름은 아직 없었다.
그냥 `Regional Response Pilot`.
대니얼은 통제실 뒤쪽에 앉았다.
앞에는 의료 네트워크 담당자.
구급대 디스패처.
병원 연락관.
미나도 있었다.
그녀는 의료분류팀 쪽.
훈련 시작.
첫 5분.
현장 정보 부족.
시스템 추천 없음.
대니얼이 초조해졌다.
“왜 안 나옵니까?”
개발자가 말했다.
“중증도 입력이 아직.”
“위치만으로 우선 추천—”
미나가 고개를 돌렸다.
대니얼이 입을 다물었다.
임상정보 없이 병원만 찍어주는 건 위험하다.
7분.
첫 환자 그룹 입력.
시스템 추천.
병원 A.
B.
A.
C.
디스패처가 일부 승인.
하나 변경.
이유: `road congestion`.
시스템 반영.
교통데이터 업데이트.
두 번째 추천부터 경로가 달라졌다.
15분.
병원 A 수술실 하나 사용중.
가용능력 하락.
시스템이 중증환자 둘을 B와 D로 분산.
좋았다.
20분.
문제.
병원 B가 갑자기 CT 대기시간을 45분으로 보고했다.
모델은 C를 추천하기 시작했다.
그런데 C의 실제 CT는 훈련상 ‘고장’ 이벤트가 들어왔다.
정보 입력이 6분 늦었다.
그 6분 동안 시스템은 잘못된 추천 세 건을 만들었다.
디스패처 한 명이 두 건을 수동으로 바꿨다.
한 건은 그대로 진행.
미나는 말했다.
“이게 실제면 중간에 다시 바꿔야 해요.”
대니얼의 표정이 굳었다.
데이터 지연.
모델이 아무리 좋아도 입력이 늦으면 과거를 최적화한다.
“상태정보 유효시간 표시.”
개발자가 바로 메모했다.
“몇 분 넘으면 경고?”
대니얼이 미나를 봤다.
이번에는 자기가 숫자를 정하지 않았다.
병원팀과 구급대가 논의했다.
자원별 다르게.
수술실.
CT.
병상.
혈액.
변화속도가 다르다.
30분.
환자 유입 최고점.
병원 A가 예상보다 빨리 과부하.
원인.
중증도가 아니라 경증환자 가족과 자가내원 환자가 훈련 이벤트로 추가됐다.
시스템에는 구급차 환자만 있었다.
대니얼이 말했다.
“Walk-in 수요.”
의료진이 고개를 끄덕였다.
실제 재난에서는 구급차만 오는 게 아니다.
사람들이 스스로 병원에 온다.
미나가 말했다.
“그리고 가족도요.”
“가족은 환자가 아니잖아요.”
“그래도 공간과 사람을 씁니다.”
대니얼은 또 멈췄다.
환자만 모델링하면 병원 전체를 못 본다.
정보문의.
가족.
경찰.
언론.
모두 현장부하.
첫 훈련은 90분 만에 끝났다.
결과.
시스템 사용 시 병원별 최대 과부하 편차는 기존 계획 대비 감소.
평균 이송시간도 소폭 개선.
좋았다.
그러나 잘못된 추천 7건.
그중 5건은 사람이 수정.
2건은 데이터 지연 때문에 늦게 수정.
완벽과는 멀었다.
프로젝트 책임자가 말했다.
“그래도 유용했습니다.”
대니얼은 만족하지 않았다.
“잘못된 추천이 너무 많습니다.”
미나가 말했다.
“훈련이라 발견한 거죠.”
“실전이면.”
“그래서 사람 승인 남겨뒀잖아요.”
대니얼은 화면을 봤다.
사람이 다섯 건을 고쳤다.
시스템이 사람을 대체했다면 실패.
사람과 같이 썼기 때문에 일부 실패를 흡수했다.
이선은 이 자리에 없었다.
그래도 그의 말이 떠올랐다.
Single point of failure.
모델도 단일 판단점이 되어선 안 된다.
훈련 리뷰.
구급대 디스패처가 말했다.
“좋은 점은 병원 전체 상황을 한 화면에 본 겁니다.”
병원 연락관.
“우리 병원만 보던 습관이 줄었습니다.”
미나.
“추천 이유가 보여서 바꾸기 쉬웠어요.”
대니얼이 물었다.
“나쁜 점은?”
미나가 바로 말했다.
“숫자가 너무 많아요.”
개발자가 놀랐다.
“필요한 정보인데.”
“재난 중에는 논문 읽을 시간 없어요.”
화면에는 병상.
CT.
수술실.
혈액.
거리.
예상시간.
신뢰도.
그래프.
너무 많았다.
대니얼이 웃었다.
또 같은 문제.
정보를 많이 보여주는 게 좋은 시스템이 아니다.
“그럼 뭐만 보여요?”
디스패처가 대답했다.
“지금 어디로 보내면 되는지.”
“그리고?”
“왜 그런지 한 줄.”
“그리고?”
미나가 말했다.
“뭘 모르는지도.”
세 가지.
추천.
이유.
불확실성.
대니얼은 마음에 들었다.
다음 버전 UI는 화면 절반이 사라졌다.
첫 화면.
환자 임상분류 입력.
추천 병원 1~3.
예상 이송.
핵심 이유.
주의: `CT status stale 8 min`.
필요하면 상세보기.
미나가 새 화면을 보고 말했다.
“훨씬 낫네요.”
대니얼이 물었다.
“이번엔 몇 점?”
“제가 언제 점수 줬어요?”
“늘 평가하잖아요.”
미나가 웃었다.
“합격은 아니고 다음 훈련 가능.”
대니얼도 웃었다.
그 정도면 충분했다.
첫 훈련은 성공도 실패도 아니었다.
정확히 필요한 종류의 결과였다.
어디서 틀리는지 보여줬다.
그리고 사람과 시스템이 같이 있을 때 서로의 실수를 줄일 수 있다는 걸 보여줬다.
그날 Helioxen은 계약 2단계 승인을 받았다.
돈은 크지 않았다.
하지만 프로젝트가 연구실을 떠나 실제 운영훈련으로 들어갔다.
Daniel은 처음으로 의료시스템에서도 ‘상업적으로 real’에 가까워지는 감각을 느꼈다.
훈련 중반에는 시스템이 한 번 너무 자신 있게 틀렸다.
병원 B 추천.
화면에는 녹색.
이송 11분.
수술실 가능.
ICU 가능.
문제 없어 보였다.
현장 의료지휘가 화면을 보자마자 말했다.
“B 안 됩니다.”
“왜?”
디스패처가 물었다.
“헬리패드 쪽 공사 때문에 응급진입 동선 좁아졌어요.”
훈련 시나리오에만 있는 조건이 아니었다.
실제로 그 주 진행 중인 공사.
병원 데이터에는 등록되지 않았다.
시스템은 자신 있게 추천했다.
대니얼은 화면의 녹색 표시를 오래 봤다.
“이 색 바꿉시다.”
개발자가 물었다.
“왜요?”
“확실한 것처럼 보입니다.”
“조건상은 정상인데요.”
“우리가 모르는 조건이 있을 수 있습니다.”
모든 추천에 확률을 붙일 수도 있다.
하지만 숫자확률도 근거가 부족하면 가짜정밀도가 된다.
결국 단순한 상태로 바꿨다.
`recommended`
그리고 옆에 데이터 상태.
`verified / partially verified / stale`
추천과 확신을 분리했다.
미나가 말했다.
“좋네요.”
“뭐가?”
“모델이 모르는 척할 수 있어서.”
대니얼이 웃었다.
“모른다고 인정하는 게 그렇게 중요합니까?”
“환자 앞에서는요.”
“공학에서도.”
그는 A1을 떠올렸다.
모르는 걸 확신으로 채우면 비용이 커진다.
의료에서는 그 비용이 훨씬 무겁다.
훈련 후 개발팀은 화면에서 녹색 체크 표시를 절반 이상 없앴다.
예전 같으면 제품이 덜 완성돼 보인다고 싫어했을 것이다.
이번에는 오히려 신뢰가 갔다.
불확실성을 숨기지 않는 인터페이스.
그게 Response Grid의 핵심 특징이 되기 시작했다.
또 하나.
훈련을 관찰하던 간호사가 말했다.
“병원 추천이 바뀔 때 왜 바뀌었는지 소리로도 알려주면 좋겠어요.”
개발자가 물었다.
“알림음?”
“화면 계속 못 봐요.”
현장에서는 손이 바쁘다.
눈도.
귀가 남을 때가 있다.
대니얼은 접근성처럼 생각했다가 곧 수정했다.
이건 단순 UI 취향이 아니다.
업무환경.
시스템이 사람에게 맞아야 한다.
알림은 단순하게.
병원추천 변경.
데이터 stale.
중요 경고.
모든 걸 소리 내면 또 경보피로.
지원팀에서 배운 문제였다.
결국 세 종류만.
훈련 2차.
사람들이 화면을 덜 보면서도 중요한 변화는 놓치지 않았다.
의료시스템과 서버운영이 서로의 교훈을 주고받고 있었다.
대니얼은 그게 Helioxen의 강점이 될 수 있다고 느꼈다.
산업 하나에서 배운 시스템원리를 다른 산업에 옮긴다.
단, 그대로 복사하지 않는다.
사람과 환경이 다르니까.
읽은 화로 기록했습니다. 다음 화는 바로 이어집니다.