의료 오케스트레이션 케이스 스터디 — 회진 준비 30분을 3분으로
RoundPrep 제16화 — 중간 정리. 화이트보드에 스티커가 빼곡하다. “병렬”, “상태”, “HITL”, “RAG”… 박과장이 묻는다. “한 장으로 말해줘요. 오늘 아침에 뭐가 어디까지 자동이에요?” 서진은 숨을 고른다. 이 글은 그 한 장을 그리기 위한 다이어그램 초안이다.
화요일 저녁, 다시 화이트보드
김서진은 마커로 네모를 그렸다. 가로축은 시간, 세로축은 환자. 이혜준은 스티커를 붙였다. “7시 스케줄러”, “FHIR 읽기”, “규칙 엔진”, “요약 LLM”, “푸시”, “교수님 승인”. 교수님(가상 시나리오)이 지난주에 했던 말이 아직 남아 있다. “제안은 제안일 뿐이야. 오더는 내가 찍는다.” 그 한 마디가 없으면 RoundPrep은 아이디어에서 끝난다.
이 글은 회진 준비를 데이터 수집 → 이상 탐지 → 요약 → 의사 검토 → 실행 전 승인의 다단계로 나누고, 병렬·규칙/LLM 혼합·장애 시나리오까지 한 줄기로 묶는 사고 실험이다. 특정 EMR 화면 캡처는 다루지 않는다.
테제
회진 준비 자동화의 핵심은 “더 똑똑한 요약”이 아니라, 승인·책임·로그가 붙은 오케스트레이션이다.
스테이크
담당 환자 10명, 숙련 주치의도 준비만 30~40분. 한 번이라도 승인 없는 제안이 현장에 흘러가면 PoC는 중단이다. 반대로, 야간 K 상승 같은 신호를 규칙으로 잡을 수 있는데 LLM만 믿으면 비용·지연만 커진다.
한줄 요약
회진 준비 자동화는 단일 AI로는 불가능하다. 데이터 수집 → 이상 탐지 → 요약 → 의사 검토 → 실행 전 승인까지, 오케스트레이션이 필요한 이유가 여기 있다.
본문
아침 7시 병동의 현실
내과 병동 주치의라면 알 것이다. 회진 전 준비가 얼마나 소모적인지.
담당 환자가 10명이면 각 환자마다 EMR을 열고, 어젯밤 활력징후를 확인하고, 새로 올라온 Lab 결과를 보고, 간호 기록을 읽고, 투약 기록을 확인한다. 응급 변화가 있었는지 먼저 파악하고, 그게 없으면 오늘 처치 방향을 생각한다.
10명 기준으로 숙련된 의사도 30~40분은 걸린다. 레지던트라면 60분.
이 과정에서 실수가 일어나기도 한다. 야간에 올라온 중요한 검사 결과를 지나치거나, 활력징후의 추세 변화를 못 보는 것. 지쳐있는 아침에 쏟아지는 정보를 수동으로 처리하다 보면 생기는 일이다.
AI 오케스트레이션으로 무엇을 자동화할 수 있나
이 과정의 핵심은 세 가지다:
- 데이터 수집 — 여러 시스템에서 최신 정보를 가져온다
- 이상 탐지 — 주의해야 할 변화를 찾는다
- 요약 생성 — 의사가 빠르게 파악할 수 있도록 정리한다
이 세 가지는 동시에 여러 환자에게 적용돼야 하고, 각 단계는 이전 단계의 결과에 의존한다. 단일 AI 호출로 할 수 없는 이유다.
근거 한 줄
환자·관찰·검사 결과 등 임상 데이터를 API로 주고받는 공통 표준으로 HL7 FHIR(예: R4의 Patient, Observation, MedicationRequest 리소스)이 널리 쓰인다(HL7 FHIR — 버전·국가 프로파일은 기관마다 다름). 이 글의 “여러 시스템에서 수집”은 FHIR(또는 병원이 허용한 다른 인터페이스) 위에서 파이프를 놓는다는 전제를 깔고 읽는 것이 안전하다.
전체 흐름
오전 7시 자동 실행
↓
담당 환자 목록 수집 (오늘 내 병동 환자 전원)
↓
[모든 환자 병렬 처리 시작 — 환자별 독립 워크플로우]
↓
각 환자별:
① 데이터 수집 (활력징후 + Lab + 간호기록 + 투약) — 4개 동시
② 이상 탐지 (규칙 기반 + AI 패턴 분석)
③ 1페이지 요약 생성
↓
[통합] 전체 환자 요약 + 우선순위 정렬
↓
주치의 모바일에 푸시 알림
↓
[Human-in-the-Loop] 의사 검토 및 응답
↓
승인된 항목만 → 처치 계획 실행단순해 보이지만 각 단계의 설계 원칙이 중요하다.
승인·책임이 붙는 시간축 (RoundPrep 가정)
| 시각(가정) | 단계 | 자동/사람 | 책임·로그에 남겨야 할 것 |
|---|---|---|---|
| D-1 23:00~ | 야간 기록·Lab 유입 | 대부분 자동 수집 | 어떤 소스에서 읽었는지, 지연(SLA) |
| 07:00 | 스케줄러 가동·병렬 수집 | 자동 | 환자별 trace ID |
| 07:01~ | 규칙 이상 탐지 | 자동(규칙) + 선택적 LLM | 임계값 버전, 모델 버전(쓴 경우) |
| 07:02~ | 1페이지 요약 생성 | 자동(LLM) | 입력 필드 범위, 프롬프트 해시 |
| 07:03 | 주치의 푸시 | 자동 전달 | 수신 여부(선택) |
| 회진 전 | Human-in-the-Loop | 주치의 승인/수정/거부 | 누가·언제·무엇을 바꿨는지 |
| 승인 후 | 오더·처치 계획 반영 | 사람 주도(EMR) | AI가 오더를 직접 쓰지 않음 |
설계 원칙 1 — 병렬 처리로 시간 단축
환자 10명의 데이터를 순차적으로 수집하면 각 환자당 3초씩 총 30초다. 병렬로 수집하면 3초면 끝난다.
각 환자의 처리는 독립적이므로 병렬화가 자연스럽다.
한 환자 내에서도 병렬화가 가능하다. 활력징후, Lab 결과, 간호 기록, 투약 기록은 서로 의존성이 없으므로 4개를 동시에 가져온다.
설계 원칙 2 — 규칙 기반과 AI 기반 혼용
이상 탐지는 두 층으로 한다.
규칙 기반 (빠르고 확실한 것)
수치가 기준을 벗어나면 즉시 알림:
- 수축기 혈압 > 180 mmHg → 긴급
- K⁺ > 6.0 mEq/L → 위험
- SpO₂ < 90% → 즉시 대응 필요
이런 건 AI가 판단하지 않아도 된다. 미리 정해진 기준이 있으니 규칙으로 처리한다.
AI 기반 (패턴이 필요한 것)
수치 하나가 기준을 넘지 않아도 12시간 추세가 우려스러운 경우, 또는 여러 지표를 종합했을 때 조기 경보가 필요한 경우. 이건 AI가 더 잘한다.
규칙으로 잡을 수 있는 건 규칙으로, AI가 필요한 경우만 AI를 쓴다. 속도와 비용 모두 효율적이다.
설계 원칙 3 — 요약의 구조
의사가 회진 전 3분 안에 10명의 상황을 파악해야 한다면, 요약은 구조화되어야 한다.
각 환자 요약의 형식:
[환자명] 60세 남성 / 입원 5일차 / 진단: 만성심부전 급성악화
● 오늘의 핵심 (2줄)
어젯밤 이후 부종 악화. BNP 상승 추세 지속.
● 주의사항
- K⁺ 4.8 (어제 4.2 → 상승 추세, 이뇨제 증량 전 재확인 필요)
- SpO₂ 야간 최저 93% (기록됨)
● 제안 처치 [검토 후 승인 필요]
- 이뇨제 용량 조정 고려
- 심장내과 협진 검토
- 내일 BNP 재검 오더
● 추적 관찰 항목
- 섭취량/배설량 비교
- 오전 체중 측정 결과“제안 처치” 섹션은 반드시 의사 승인을 거쳐야 실행된다. AI는 제안만 한다.
설계 원칙 4 — 의사의 검토가 병목이 아닌 안전장치
자동화의 목적이 의사를 배제하는 것이 아니다. 반복적인 수작업을 줄여서 의사가 판단에 집중할 수 있게 하는 것이다.
잘 설계된 Human-in-the-Loop는:
- AI가 준비해둔 정보를 의사가 30초 안에 검토하고 승인/수정/거부할 수 있다
- 의사가 확인하지 않으면 AI가 처치를 실행하지 않는다
- 응급 상황은 AI가 먼저 담당 간호사에게 알리고, 의사에게도 동시에 알림을 보낸다
실제로 구현할 때 부딪히는 현실적 문제들
EMR 연동
대부분의 병원 EMR은 HL7 FHIR API를 지원하지만, 실제로는 병원마다 구현 수준이 다르다. 일부 검사 결과는 PDF로만 제공되고, 일부 간호 기록은 자유 텍스트다. AI가 처리하기 전에 데이터 정제 단계가 필요하다.
개인정보 보호
AI가 처리하는 데이터에 환자 식별 정보가 포함된다. 병원 내부 서버에서 처리하거나, 외부 LLM API를 쓴다면 전송 전에 식별 정보를 제거하는 익명화 단계가 필수다.
책임 소재
AI가 제안한 처치를 의사가 승인하고 실행했는데 문제가 생겼다면 누가 책임지는가. 의료 AI 시스템은 AI의 판단 근거와 의사의 검토 이력을 모두 기록으로 남겨야 한다.
AI 장애 시 대응
AI가 다운됐을 때 병동이 마비되면 안 된다. AI는 보조 도구이고, 의사는 AI 없이도 기존 EMR로 직접 확인할 수 있어야 한다. AI가 없어도 병동이 돌아가는 것이 기본이다.
이 시스템이 완성되면
주치의는 회진 전에 모바일로 전체 환자 요약을 받는다. 긴급 환자가 먼저 정렬되어 있다. 각 환자별로 “오늘의 핵심”을 30초 안에 파악하고, 제안된 처치를 스와이프로 승인하거나 수정한다.
실제 회진 시간이 짧아지고, 전날 밤 변화를 놓치는 실수가 줄어든다. 의사는 데이터 수집이 아닌 환자와의 대화와 판단에 시간을 쓴다.
30~60분이 걸리던 회진 준비가 3분으로 줄어드는 것이 이 시스템의 목표다.
전환점 — v0.1이 터지는 지점
가정 시나리오: 데모에선 “요약만” 잘됐다. 그런데 프로덕션 논의에서 “제안 처치”가 승인 없이 간호 호출까지 흘러갔다는 오해가 생기면 교수님은 한 번에 문을 닫는다. 그래서 위 표의 HITL 행은 장식이 아니라 제품의 경계다.
반례 — 이 설계가 통하지 않는 병동
데이터가 FHIR·구조화 필드로 오지 않고 스캔 PDF·자유서술만 쌓이는 병동에서는 수집 단계에서 이미 막히고, LLM을 앞에 두면 비용·환각 리스크만 커진다. 또 야간 인력이 극소인 병동에서 AI 알림을 과다하게 쏘면 알림 피로만 남는다. 이때는 먼저 데이터 파이프·알림 임계값·Triage 정책을 고치고 나서 오케스트레이션을 논한다.
실무 체크리스트
- 데이터 소스마다 SLA·지연을 적었는가? (야간 배치 vs 실시간)
- 규칙 엔진과 LLM 요약의 책임 경계를 문서화했는가?
- 제안 처치는 항상 의사 승인 전에는 오더에 쓰이지 않는가?
- 감사 로그에 모델 버전·프롬프트 해시·입력 필드 범위를 남기는가?
- AI 장애 시 동일 정보를 EMR만으로 확인하는 절차가 훈련돼 있는가?
이 시스템에서 의사 승인을 기다리는 구조를 어떻게 설계하는가 → Human-in-the-Loop
이런 시스템을 운영할 때 무엇을 모니터링해야 하는가 → 오케스트레이션 모니터링
다음 회의 한 줄
서진: “한 장으로 말하면, 7시에 자동으로 모이는 건 데이터와 알림이고, 처치는 교수님 승인 전엔 절대 EMR에 안 갑니다. 장애 나면 EMR만으로도 회진은 갑니다.”
다음 화
다이어그램은 그렸다. 박과장의 다음 질문은 단순하다. “그럼 이걸 어떻게 증명하지? 시나리오 테스트?” — 오케스트레이션 테스트 전략
편집 초안(cu2604021138). 사례는 설계 연습용이며, 실제 임상·법적 효력을 대체하지 않는다. 도입 전 병원 윤리·정보보호·의료기기 해당 여부를 확인한다.
더 알고 싶다면
🔗 관련 글
- 오케스트레이션이란 — 회진 시스템 설계의 기초 개념
- Human-in-the-Loop — 의사 최종 승인 흐름 설계 원칙
- 오케스트레이션 테스팅 — 케이스 시나리오 테스트 방법
- 오케스트레이션 보안 — 의료 데이터와 처방 시스템 보안