오케스트레이션이란 무엇인가 — AI를 지휘하는 지휘자
시리즈 «RoundPrep» · 등장인물·타임라인 요약: 편집용
blog/docs/ORCHESTRATION_ROUNDPREP_BIBLE.md.
금요일 오후, 소회의실
내과 레지던트 김서진은 화이트보드 앞에서 마커를 내려놓지 못했다. 한 줄만 적혀 있다. 「회진 전 브리핑, 짧게」. 임상정보 담당 이혜준은 노트북을 열어 FHIR 샌드박스 URL을 띄운 채 말했다. “일단 EMR에서 당직 기록이랑 야간 Lab만 긁어오면…” 서진이 끼어들었다. “그다음에 요약만 하면 되지 않아?”
방금 전 교육과장실에서 들은 말이 귓속을 맴돈다. “요즘 AI 한 번이면 다 되잖아요. 챗GPT에 붙이면 끝 아닌가?” 서진은 반박하고 싶었다. 끝이 아니다. DB에 손도 못 대는 창 하나, PDF는 올릴 수 없다는 보안, 그리고 야간에 올라온 K가 올랐는지를 챗 한 번에 믿을 수 없다는 것. 그런데 그걸 어떻게 한 문장으로 설명하지?
혜준이 조용히 말했다. “우리가 만들려는 건 답 생성기가 아니라 일의 순서야. 수집이 먼저고, 이상 징후는 규칙이 잡을 수도 있고, 요약은 그다음이고, 처치 제안은…” 서진이 고개를 끄덕였다. “교수님 손 안 거치면 안 되지.” 그렇다. 이건 한 번의 프롬프트가 아니라 여러 단계와 사람이 얽힌 일이다. 그걸 지휘하는 층을, 업계에선 흔히 오케스트레이션이라 부른다.
이 글은 그 지휘 층이 무엇인지, 의사·임상 IT가 같은 단어로 대화하려면 무엇을 공유해야 하는지 정리한다. 특정 제품 튜토리얼이나 EMR 계약은 다루지 않는다.
테제
“AI 한 번이면 되나?”에 노(No)라고 답하려면, 오케스트레이션이 뭔지 한 장으로 말할 수 있어야 한다. 모델을 키우는 게 아니라, 단계·의존성·상태·복구를 설계하는 것이다.
스테이크
서진에게 걸린 것은 시간이다. 환자 10명이면 숙련자도 회진 전 준비만 30~40분. 레지던트는 60분이 흔하다. 그 시간이 줄지 않으면 PoC는 “재미있는 데모”로 끝나고, 교육과장실의 한 마디에 다시 밀린다. 신뢰도 걸려 있다. 한 번이라도 근거 없는 제안이 오더로 흘러가면 RoundPrep은 끝이다.
한줄 요약
오케스트레이션은 여러 AI·도구·에이전트가 각자의 역할을 하면서 하나의 목표를 달성하도록 단계·의존성·상태·오류 복구를 지휘하는 기술(및 운영)이다.
본문
단일 AI의 한계를 처음 실감하는 순간
RoundPrep 팀이 상부에 던졌던 예시가 있다. “지난달 외래 통계를 분석해서 PDF 보고서로.” 챗봇 앞에서 시연하려다 보면 같은 벽에 부딪친다.
- 병원 DB에 접근하는 도구가 없다
- 실시간 데이터를 가져올 수 없다
- PDF를 직접 생성할 수 없다
이건 AI가 무능해서가 아니다. 단일 언어모델 호출의 구조적 한계다. 텍스트를 받아 텍스트를 내놓는 계약을 넘는 행동은 외부 도구와 다단계 흐름이 필요하고, 그 흐름을 정의·실행·감시하는 층이 오케스트레이션이다.
RoundPrep에 대입하면: “회진 브리핑”도 결국 EMR·Lab·간호기록·투약을 도구로 긁어오고, 그 결과를 모아 요약·정렬하고, 처치 제안 앞에 사람 승인을 두는 다단계다. 한 번의 생성으로 끝날 수 없다.
레지던트에게 “다 해줘”라고 말하면 어떻게 될까
신입 레지던트에게 “이 환자 전부 정리해줘”라고 하면 막막해한다. 무엇부터 해야 할지, 어디서 어떤 정보를 가져와야 할지, 결과를 어떻게 정리해야 할지.
경험 있는 시니어 레지던트는 다르다. 이 작업을 분해한다.
- EMR에서 최근 기록 조회
- Lab 수치 확인 및 추세 분석
- 현재 투약 목록 검토
- SOAP 노트 형식으로 정리
그리고 병렬로 처리할 수 있는 것(Lab 조회와 투약 목록 조회는 동시에 가능)과 순차로 해야 하는 것(분석은 데이터 수집 후에 가능)을 구분한다.
오케스트레이션은 AI 시스템에 이 시니어의 머릿속 체크리스트를 코드·그래프·정책으로 옮기는 일에 가깝다.
RoundPrep에 대입하면: 서진이 머릿속으로 하던 순서를 파이프라인으로 박아 두면, “어디서 실패했는지”와 “누가 승인했는지”를 나중에 설명할 수 있다. 그게 박과장이 원하는 근거에 가깝다.
오케스트레이션의 4가지 핵심 요소
태스크 분해 (Task Decomposition)
복잡한 목표를 더 작은 단계로 나눈다. “환자 안전 개선 보고서 작성”은 한 번의 생성으로 끝나지 않는다. 데이터 수집, 분석, 벤치마크 비교, 권고안 작성, 보고서 구성으로 나눠야 한다.
의존성 관리 (Dependency Management)
어떤 단계가 다른 단계의 결과를 필요로 하는지 파악한다. 데이터 수집 전에 분석을 시작할 수 없다. 반면 여러 데이터 소스 수집은 서로 의존성이 없으면 동시에 할 수 있다.
상태 관리 (State Management)
여러 단계를 거치는 동안 중간 결과와 컨텍스트를 유지한다. 5단계 작업 중 3단계에서 실패하면, 처음부터 다시 하는 것이 아니라 3단계부터 재시도·분기할 수 있어야 한다.
오류 복구 (Error Recovery)
에이전트나 도구가 실패했을 때 재시도, 우회, 부분 결과 반환, 사람에게 넘기기(Human-in-the-Loop) 중 무엇을 택할지 정책으로 박아 둔다.
RoundPrep에 대입하면: 네 가지 중 하나라도 “아직 안 정했어요”로 남으면, 장애 났을 때 팀은 서로 눈만 마주친다. 특히 복구와 HITL은 교수님 설득의 핵심이다.
전환점 — “한 방에 되겠지”가 터지는 지점
가상이지만 흔한 시나리오다. 누군가 데모용으로 “야간 기록만 붙여서 요약해줘”는 프로토타입을 만든다. 잘된다. 그런데 실제 병동에 올리려면 Lab PDF, 간호 자유기술, 응급 알림 분기가 붙는 순간 한 줄기 스크립트는 깨진다. 그때 필요한 말이 “모델 바꿉시다”가 아니라 “단계를 쪼갭시다”다.
단순 파이프라인과 무엇이 다른가
단순 파이프라인은 흐름이 고정이다.
A → B → C → DA가 실패하면 전체 실패. 분기 없음. 조건 없음.
오케스트레이션은 유연하다.
┌→ B ─┐
A ──────┤ ├──→ D
└→ C ─┘
(B, C 병렬 실행)
A 실패 시 → E로 우회동적 분기, 병렬 실행, 실패 처리, 조건부 흐름. 실제 업무가 이렇게 생겼기 때문에 오케스트레이션 층이 필요하다.
의료 현장에서 오케스트레이션이 특히 필요한 영역
임상 의사결정 지원
”이 환자 치료 방향 제안해줘”에 단일 호출로 답하면 학습 코퍼스 기반 일반론에 머무르기 쉽다. 오케스트레이션은 이 환자의 실제 데이터(EMR, Lab, 투약)를 허용된 경로로 수집하고, 가이드라인·약물 상호작용 확인 등을 단계로 묶어 통합 권고를 만든다.
의무 기록 자동화
구술 → 환자 데이터 대조 → SOAP 구성 → 의사 검토 → EMR 저장처럼 여러 시스템과 사람이 끼는 흐름이다.
임상 연구 지원
코호트 추출, 문헌 검색, 예비 분석이 서로 다른 시스템에 있을 때, 중간 산출물을 유지하며 이어 붙이는 설계가 필요하다.
근거 한 줄
멀티스텝·도구 사용·에이전트를 그래프나 상태머신으로 모델링하려는 흐름은 2023~2024년경 커뮤니티와 프레임워크 문서에서 공통 주제로 정리됐다. 예를 들어 LangGraph는 순환·분기·상태를 명시적으로 다루는 이유를 제품 문서 수준에서 설명한다(LangGraph 개요 — 버전·URL은 발행 이후 바뀔 수 있음).
반례 — 이 패턴이 틀리는 경우
한 단계 요약·한 번의 검색으로 끝나는 요청에는 오케스트레이션이 과하다. 예: “이 영상 설명을 환자용 쉬운 말로만 바꿔줘.” 여기에 멀티 에이전트·그래프를 얹으면 지연·비용·디버깅만 늘고 품질 이득이 거의 없다.
실무 체크리스트
- 이 목표를 2문장 이내로 쪼갠 하위 단계 목록을 적었는가?
- 각 단계의 입력·출력 데이터 형식을 정했는가?
- 의존성(순차 vs 병렬)을 표나 그림으로 적었는가?
- 단계 실패 시 재시도 횟수·우회·중단 중 무엇을 택할지 정했는가?
- 임상·개인정보가 섞이면 사람 승인 지점(HITL)을 어디에 둘지 정했는가?
- 운영 중 로그·추적 ID로 어느 단계에서 깨졌는지 찾을 수 있는가?
다음 회의 한 줄
서진·혜준이 말할 수 있는 문장: “RoundPrep은 챗 한 번이 아니라, 수집 → 탐지 → 요약 → 교수님 승인까지 단계가 있고, 각 단계마다 실패와 로그를 정해 두는 설계입니다.”
다음 화에서 생기는 갈등
같은 방에서 다음 질문이 터진다. “그럼 에이전트 여러 마리 쓰면 되는 거야, 아니면 오케스트레이션이 먼저야?” — 오케스트레이션 vs 에이전트
더 읽기
편집 초안(cu2604021138). 프레임워크 URL·API·병원 정책은 발행일 이후 바뀔 수 있으니 공식 문서와 내부 규정을 기준으로 확인한다.
더 알고 싶다면
🔗 관련 글
- AI 워크플로우 패턴 5가지 — 오케스트레이션 설계에 쓰이는 5가지 패턴 비교
- 오케스트레이션 vs 에이전트 — 단일 에이전트와 멀티 에이전트, 무엇을 먼저 쓸까
- LangGraph 입문 — 오케스트레이션 구현의 대표 도구
- 의료 오케스트레이션 케이스 스터디 — 실제 회진 준비 시스템에 적용한 사례