ORIGINAL FICTION
제67화 — 12분
지난 화 끝부분 다시 보기
사고 사후검토는 일주일 뒤 열렸다.
모든 사람이 피곤해 보였다.
구급대.
병원 연락관.
응급의학.
IT.
Helioxen.
벽에는 실전 타임라인이 떠 있었다.
7:42 첫 신고.
7:47 다중환자 단계.
7:54 첫 시스템 추천.
8:03 첫 병원 과부하 조정.
8:29 도로폐쇄 반영.
8:31 CT 상태오류.
10:18 상황단계 종료.
대니얼은 숫자 하나를 표시했다.
12분.
“이건 뭡니까?”
네트워크 책임자가 물었다.
“첫 신고부터 병원 분산추천이 안정되기까지.”
미나가 말했다.
“그 숫자 별로 의미 없어요.”
대니얼이 그녀를 봤다.
“왜?”
“첫 신고 때는 환자 규모를 몰랐으니까.”
“그래도 시스템 반응시간은—”
“시스템이 뭘 반응할 정보가 없었죠.”
대니얼이 입을 다물었다.
또 숫자.
측정은 했지만 의미가 애매했다.
“그럼 어디부터 봐야 합니까?”
미나가 화면에서 한 지점을 짚었다.
첫 현장 의료분류 데이터가 들어온 시점.
“여기.”
그 이후 첫 유효추천.
3분 40초.
대니얼이 고개를 끄덕였다.
“이게 낫네요.”
“그리고 이것도.”
미나는 다른 구간을 짚었다.
병원 C CT 장애.
실제 장애 시점과 시스템 인지시점.
11분.
대니얼의 표정이 굳었다.
“이게 더 중요하네요.”
“네.”
실전에서 가장 큰 위험은 모델 계산속도가 아니었다.
현실 변화가 시스템에 들어오는 속도.
11분 동안 모델은 과거 세계를 보고 있었다.
IT담당이 말했다.
“CT 시스템 직접연계는 쉽지 않습니다.”
“왜?”
“장비 공급사 인터페이스가 제한적입니다.”
“그럼 수동확인.”
“사람이 매번?”
“상태변경 때.”
미나가 말했다.
“근데 사람은 바쁠 때 입력을 제일 늦게 해요.”
정확한 문제.
가장 정보가 필요한 위기 때 정보를 입력할 사람이 가장 바쁘다.
대니얼은 서버 운영을 떠올렸다.
장애 때 수동 보고는 늦는다.
자동감시.
그러나 의료장비는 Helioxen 서버처럼 마음대로 센서를 붙일 수 없다.
“간접신호는?”
개발자가 물었다.
“예약대기 증가, 검사결과 중단 같은.”
의료진이 고개를 끄덕였다.
완벽한 연계가 아니어도 이상징후를 잡을 수 있다.
단, 자동으로 ‘고장’이라고 단정하면 안 된다.
`status uncertain`.
불확실성을 올린다.
대니얼이 말했다.
“추천점수 낮추고 경고.”
미나가 고개를 끄덕였다.
“그 정도면.”
두 번째 큰 주제.
사람 override.
실전에서 총 14건.
그중 9건은 현장정보가 시스템보다 나았다.
3건은 의료진 개인선호였지만 결과상 큰 차이 없음.
2건은 사후검토에서도 이유가 불명확.
대니얼이 물었다.
“불명확 두 건은 문제 아닙니까?”
미나가 말했다.
“사람이 그 순간 왜 그랬는지 기억 못 할 수도 있어요.”
“그럼 학습 못 하잖아요.”
“그래서 기록방식이 중요하죠.”
현재 override 이유 선택은 너무 복잡했다.
목록 17개.
현장에서는 고를 시간이 없었다.
디스패처가 말했다.
“기타 누르고 넘어갑니다.”
대니얼이 화면을 봤다.
또 너무 많은 선택지.
“5개로 줄입시다.”
현장정보.
의료능력.
도로/이송.
환자특성.
기타.
상세는 나중에 음성 또는 메모.
훈련에서 배운 ‘첫 화면 단순화’가 다시 돌아왔다.
세 번째.
병원 A 자가내원.
미나가 실제 영상을 보여주진 않았다.
대신 상황을 설명했다.
환자보다 가족 문의가 더 빨리 늘었다.
전화.
입구.
주차.
보안.
대니얼이 물었다.
“이걸 모델에 넣을 수 있습니까?”
“일부는.”
“가족 수?”
“그걸 어떻게 예측해요.”
“과거 데이터.”
미나가 웃었다.
“또 모델부터.”
대니얼도 웃었다.
“습관입니다.”
“먼저 할 건 안내체계예요.”
웹.
전화번호.
가족대기구역.
병원별 메시지.
정보를 잘 주면 불필요한 이동이 줄어든다.
대니얼은 잠깐 놀랐다.
계산이 아니라 커뮤니케이션.
그게 응급실 부하를 줄일 수 있다.
“그럼 시스템이 병상만 조정하는 게 아니네요.”
“재난대응이 원래 그렇죠.”
미나가 말했다.
“사람은 정보 없으면 움직여요.”
대니얼은 노트에 적었다.
Information is a resource.
전력.
병상.
혈액.
구급차.
정보.
모두 부족하면 시스템이 흔들린다.
검토 끝 무렵, 구급대 책임자가 말했다.
“한 가지는 좋았습니다.”
모두 그를 봤다.
“예전에는 각 병원이 자기 병상만 말했습니다.”
그가 화면을 가리켰다.
“이번에는 왜 다른 병원으로 보내는지 같이 봤어요.”
공유상황.
자기 조직만의 최적이 아니라 지역 전체 상황.
병원 A가 여유를 조금 남기는 이유.
B가 중증환자를 더 받는 이유.
설명되면 협력이 쉬워졌다.
대니얼은 이 점을 중요하게 봤다.
행성방어도 국가마다 자기 자원과 위험을 볼 것이다.
전체상황을 공유하지 않으면 각자 합리적인 선택이 전체를 망칠 수 있다.
지금은 다섯 병원.
나중에는 수십 개 국가.
규모만 다르다.
회의가 끝난 뒤 미나가 물었다.
“또 먼 데 갔죠?”
대니얼이 정신을 차렸다.
“뭐가요?”
“표정.”
“그 표정 얘기하는 사람 많네요.”
“다들 같은 걸 보나 보죠.”
둘은 회의실을 나왔다.
미나가 말했다.
“12분보다 11분이 더 중요했다는 거 기억하세요.”
대니얼이 웃었다.
“네.”
측정하기 쉬운 숫자보다 실제로 위험을 만든 숫자.
그걸 고르는 일도 시스템 설계였다.
사후검토가 끝난 뒤 대니얼은 그날 override를 가장 많이 한 구급대 디스패처를 따로 찾아갔다.
“질문 하나 해도 됩니까?”
“네.”
“도로폐쇄 정보는 어디서 먼저 아셨습니까?”
“현장 무전.”
“시스템보다 몇 분 빨랐죠?”
디스패처가 기록을 봤다.
“대략 4분.”
“왜 시스템에 바로 안 넣었습니까?”
상대가 웃었다.
“그때 전화 세 개 받고 있었어요.”
대니얼은 바로 이해했다.
정보를 가진 사람과 입력할 사람이 같은 사람.
가장 바쁠 때 업데이트가 늦는다.
“그럼 별도 입력요원이 있으면?”
“재난 규모 크면 도움이 되죠.”
“자동 음성인식?”
디스패처가 눈썹을 올렸다.
“무전 다 자동으로 읽게요?”
대니얼은 잠깐 미래를 봤다.
언젠가는 가능하다.
지금은 정확도가 문제.
“아직은 아니네요.”
“네.”
둘이 웃었다.
대신 간단한 방법을 만들었다.
무전 중 중요 상태변화를 버튼 하나로 표시.
`road blocked`
`hospital limitation`
`resource change`
상세내용은 나중.
먼저 신호만 시스템에 들어간다.
정확한 설명은 사람이 여유 생겼을 때.
대니얼은 이 구조가 마음에 들었다.
정보의 완성도를 기다리지 않고, 위험이 바뀌었다는 사실부터 빠르게 공유한다.
서버 장애 경보와 비슷하다.
원인을 몰라도 ‘정상 아님’을 먼저 알린다.
그 다음 진단.
사고 검토 중 또 하나 드러났다.
시스템 추천을 따랐지만 현장에서 의료진이 불편했다고 느낀 케이스.
이유.
추천병원이 지리적으로 멀진 않았지만 구급대가 익숙하지 않은 진입로였다.
몇 분 차이.
모델에는 없는 마찰.
대니얼이 말했다.
“익숙함도 변수입니까?”
디스패처가 고개를 끄덕였다.
“재난 중에는요. 운전자가 길 찾느라 헤매면 숫자 다 소용없죠.”
GPS는 있었다.
그래도 현장경험은 다르다.
대니얼은 모든 걸 모델에 넣고 싶어졌다.
곧 멈췄다.
모든 인간경험을 변수로 만들 수는 없다.
그래서 override가 필요하다.
시스템이 완벽해져 override를 없애는 게 목표가 아니다.
좋은 override가 빠르게 가능하도록 만드는 것.
대니얼은 그 결론이 점점 마음에 들었다.
의료 프로젝트가 Helioxen 조직철학까지 다시 바꾸고 있었다.
대니얼은 그날부터 override 수보다 override에서 새로 발견된 정보의 종류를 더 중요하게 보기 시작했다.
검토가 끝난 뒤 디스패처는 대니얼에게 말했다.
“시스템이 우리보다 똑똑해지는 건 괜찮습니다.”
대니얼이 웃었다.
“그런데요?”
“우리 말을 안 듣기 시작하지만 않으면요.”
대니얼은 그 문장을 메모했다.
좋은 자동화는 현장을 침묵시키는 게 아니라, 현장의 판단을 더 빨리 공유하게 해야 했다.
읽은 화로 기록했습니다. 다음 화는 바로 이어집니다.