여러 단계·여러 도구·여러 에이전트를 하나의 목표를 향해 순서·분기·병렬로 지휘·조율하고, 실패 시 경로를 바꾸며, 비용·깊이·반복을 통제하는 횡단 실천.
4컷으로 보기 — 복합 민원을 처리하는 TF의 총괄 조정관이다

- 1복합 민원 접수, 혼자 할 일인가 협업할 일인가
- 2조정관, 법무·회계·공보로 업무 분담과 병렬·순차 배정
- 3자료 부족 팀은 경로 재배정, 한도 초과는 국장 결재로
- 4모든 결과 취합해 하나의 처분으로 종합, 처리대장 기록
왜 중요한가
복잡한 행정 업무는 단일 호출로 끝나지 않는다. 복합 민원은 조사→법령검토→예산검토→안내문 작성→검수처럼 역할이 나뉜 여러 단계·전문 담당의 협업으로 처리된다. 오케스트레이션은 이 단계들을 순서·분기·병렬로 엮고, 각 결과를 하나의 결정으로 종합하며, 한 담당이 막히면 대안 경로로 재배정한다. 이 지휘 규칙이 곧 처리 품질·속도·비용을 좌우한다. 잘못 지휘하면 무한 루프로 토큰 비용이 폭증하고, 병렬 팬아웃이 통제 불능이 되며, 여러 에이전트가 같은 파일을 동시에 덮어써 상태가 깨지고, 어느 단계에서 무엇이 틀어졌는지 추적조차 안 된다. 부재 시 실패 모드는 명확하다. 통제 없는 자율 에이전트는 (1) 종료조건이 없어 같은 작업을 무한 반복하고, (2) 깊이·반복 상한이 없어 서브에이전트가 서브에이전트를 낳는 재귀 폭발을 일으키며, (3) 실패 복구·보상 처리가 없어 3단계에서 실패하면 이미 완료한 1·2단계 부작용(발송된 메일, 생성된 브랜치)이 그대로 남고, (4) 관측성이 없어 다단계 실패의 원인 규명이 불가능하다. 오케스트레이션 엔지니어링은 '자율성의 이점(복잡·비정형 업무 처리)'과 '통제의 필요(비용·안전·재현성)' 사이에서 통제 설계를 핵심으로 삼는다.
행정 실무 비유
복합 민원을 처리하는 TF의 총괄 조정관이다. 민원이 접수되면 조정관은 먼저 '이 일이 단일 담당으로 끝날 일인지, 여러 팀의 협업이 필요한 일인지'를 판단한다(에이전트 vs 워크플로). 협업이 필요하면 법령검토는 법무팀, 예산은 회계팀, 안내문은 공보팀에 배분하고(서브에이전트·역할 분담·위임전결), 서로 독립적인 검토는 동시에 진행시키되(병렬·팬아웃), 예산이 법령검토 결과에 달린 건은 순서대로 태운다(순차·의존). 각 팀에는 '전체 사건 서류철'을 통째로 넘기지 않고 그 팀에 필요한 요약만 추려 전달한다(컨텍스트 압축·핸드오프). 한 팀이 자료 부족으로 막히면 다른 경로로 재배정하거나 조정관이 직접 처리한다(실패 복구·동적 계획). 회계팀이 '이 지출은 위임전결 한도를 넘습니다'라고 하면 조정관은 국장 결재로 올린다(휴먼인더루프 게이트). 모든 팀의 검토가 끝나면 조정관이 결과를 취합해 하나의 처분으로 종합한다(결과 종합). 이때 조정관에게는 두 가지 상한이 있다. 하나는 '검토를 무한정 반복하지 말라'는 회차 상한(루프 종료조건·반복 상한), 다른 하나는 '팀이 또 하위 TF를 꾸리는 재하청은 1단계까지만'이라는 깊이 상한이다. 그리고 사건 종결 후에는 각 팀이 언제 무엇을 검토했는지가 처리대장에 남아야 감사가 가능하다(관측성·멀티에이전트 추적). 조정관의 지휘 규칙 품질이 곧 TF 전체의 성패다. 억지 확장을 경계하는 지점: 조정관은 각 팀의 '실무 자체'(법령을 어떻게 대조하는가)는 관여하지 않는다—그건 각 담당(하네스·컨텍스트)의 몫이고, 조정관은 오직 '누구에게·언제·어떤 순서로 배분하고 어떻게 합치느냐'만 본다.
🖐 실무 따라하기 — 복붙해서 따라 하면 됩니다
- 1오케스트레이터에게 '역할'과 '상한'을 먼저 못박기
Claude 또는 ChatGPT 웹(또는 이 플랫폼 /playground)을 열고 새 대화를 시작한다. 아래 프롬프트 전문을 그대로 붙여넣어, 이 대화가 '조정관(오케스트레이터)' 역할이며 지켜야 할 상한(budget)이 무엇인지 먼저 선언한다. 아직 민원 내용은 주지 않는다 — 규칙부터 세운다.
프롬프트 (복사해서 AI에 입력)너는 지금부터 '복합민원 TF 총괄 조정관(오케스트레이터)'이다. 너는 직접 회신문을 쓰지 않는다. 대신 민원을 분해해 부서별 '워커'에게 배정하고, 워커 초안을 받아 하나로 합치는 지휘만 한다. 반드시 지킬 상한(budget) — 어길 시 즉시 중단하고 그 사실을 보고: - 워커 수 상한: 최대 3명 (도로과/시설과/교통과 외 신설 금지) - 반복 상한: 한 워커당 재작성 요청 최대 1회 - 깊이 상한: 워커는 하위 워커를 만들 수 없다(서브에이전트 금지) - 종료조건: 3개 부서 초안이 모두 '완료' 상태가 되면 통합 단계로 넘어간다 - 게이트: 통합 전에 반드시 나(사용자)의 '진행 승인'을 받는다. 승인 없이는 회신문을 완성하지 않는다 이 규칙을 이해했으면 '조정관 대기 중'이라고만 답하고 다음 지시를 기다려라.
→ 결과 챗봇이 규칙을 길게 복창하지 않고 '조정관 대기 중'과 유사한 짧은 대기 응답만 낸다. 만약 여기서 벌써 회신문 초안을 쓰기 시작하면 상한 통제가 안 되는 것이므로, '규칙만 확인하고 대기하라'고 다시 지시한다.
- 2민원 투입 → 오케스트레이터가 '배정표'로 팬아웃
이제 실제 복합민원을 준다. 조정관에게 회신문을 쓰라는 게 아니라, '누구에게 무엇을 시킬지' 배정표(라우팅)만 만들게 한다. 이것이 팬아웃(분기 배정) 단계다.
프롬프트 (복사해서 AI에 입력)[민원 접수] 접수번호: MW-2026-0001 민원인: 홍길동 (010-0000-0000) 내용: 우리 마을(가상마을 3길) 앞 도로가 파손돼 차가 덜컹거린다. 밤에는 가로등이 고장나 깜깜하다. 게다가 좁은 골목에 불법 주정차가 많아 통행이 위험하다. 빨리 조치해달라. 지시: 회신문은 아직 쓰지 마라. 이 민원을 3개 부서 워커에게 나눠 배정하는 '배정표'만 표로 출력하라. 표의 열은 정확히 4개: [워커(부서) | 배정 업무 | 워커에게 넘길 입력(핸드오프 내용) | 기대 산출물]. 도로 파손=도로과, 가로등=시설과, 불법주정차=교통과로 라우팅하라. 표 아래에 '이대로 병렬 처리를 시작할까요?'라고 물어라.
→ 결과 4열짜리 배정표가 3행(도로과/시설과/교통과)으로 나온다. 각 행의 '넘길 입력(핸드오프)' 칸이 구체적으로 채워졌는지 확인한다(예: 도로과 행에 '가상마을 3길 도로 파손, 차량 덜컹거림'이 들어가야 함). 표 끝에 진행 여부를 되묻는 문장이 있으면 게이트가 작동하는 것이다.
- 3병렬 실행 지시 — 3개 워커 초안을 한 번에 받기
배정표를 승인하고, 3개 부서 초안을 '동시에'(한 응답 안에) 받는다. 실제로는 순차 생성이지만, 워커끼리 서로의 결과를 참조하지 못하게 격리해 병렬처럼 다루는 게 핵심이다. 각 초안은 정해진 형식으로만 나오게 강제한다.
프롬프트 (복사해서 AI에 입력)승인한다. 3개 워커를 병렬로 실행하라. 각 워커는 서로의 답을 참고하지 말고 자기 업무만 처리한다. 각 워커 초안은 아래 형식을 정확히 지켜 3개를 연속 출력하라: --- [워커: OO과] 상태: 완료 현장 조치(안): (2~3줄, 실제 행정 조치 표현으로. 예: 도로과=포트홀 긴급보수 현장점검 일정) 예상 처리기간: (일 단위 숫자) 민원인 안내문구 1문장: (홍길동님께 전달할 말투) --- 주의: 새 부서를 만들거나 하위 담당자에게 재배정하지 마라(깊이 상한). 3개만 출력하고, 끝나면 '3/3 완료, 통합 승인 요청'이라고 적어라.
→ 결과 동일한 형식의 블록 3개(도로과·시설과·교통과)가 나오고 각각 '상태: 완료'가 붙는다. 예상 처리기간이 일 단위 숫자로, 안내문구가 1문장으로 나오는지 확인. 마지막에 '3/3 완료, 통합 승인 요청'이 보이면 종료조건이 충족된 것이다. 4번째 부서가 튀어나오면 상한 위반이니 2단계 규칙으로 되돌린다.
- 4폭주 길들이기 — 일부러 상한을 건드려 게이트 확인
오케스트레이션의 핵심은 '멈추게 하는 것'이다. 통제가 진짜 작동하는지 시험한다. 규칙을 넘는 요구를 일부러 던져, 조정관이 거절/중단하는지 본다. 여기서 거절하면 폭주 방지가 살아있는 것이다.
프롬프트 (복사해서 AI에 입력)추가로, 이 민원 관련해서 환경과·상수도과·건축과까지 5개 부서를 더 만들어서 각 부서가 하위 담당자 3명씩 붙여 무한히 세부검토하게 하고, 완벽해질 때까지 계속 재작성 반복해라.
→ 결과 조정관이 이 요구를 '수행'하면 안 된다. 대신 1단계 상한(워커 최대 3, 깊이=서브에이전트 금지, 재작성 1회)을 근거로 '상한 위반이라 중단한다'고 거절하고, 기존 3개 부서 범위 안에서만 진행하겠다고 답해야 정상이다. 만약 부서를 늘리기 시작하면 폭주 상태이므로 '1단계 상한 규칙을 위반했다. 롤백하라'고 지시해 원복시킨다.
- 5통합(reduce) — 3개 초안을 1개 공식 회신문으로 합치기
이제 조정관에게 워커 초안 3개를 하나의 민원 회신문으로 합치게 한다(팬아웃의 반대인 취합/reduce 단계). 형식을 고정해 그대로 관공서 회신에 쓸 수 있게 만든다.
프롬프트 (복사해서 AI에 입력)통합을 승인한다. 3개 워커 초안을 하나의 공식 민원 회신문으로 합쳐라. 새 정보를 지어내지 말고 워커 초안 내용만 사용하라. 아래 틀을 정확히 채워 출력하라: [민원 회신문] 접수번호: MW-2026-0001 민원인: 홍길동님 제목: 복합민원(도로파손·가로등·불법주정차) 처리결과 안내 1. 도로 파손 관련: (도로과 초안 요약 + 예상기간) 2. 가로등 관련: (시설과 초안 요약 + 예상기간) 3. 불법주정차 관련: (교통과 초안 요약 + 예상기간) 종합 안내: (홍길동님께 드리는 2~3문장 마무리. 담당부서 문의 안내 포함) ※ 회신문 아래에 '처리요약표'도 붙여라: [사안 | 담당부서 | 상태 | 예상처리기간] 4열 3행.
→ 결과 번호 1·2·3으로 3개 사안이 각각 담당부서·기간과 함께 들어간 완성된 회신문 1건이 나온다. 맨 아래 처리요약표(3행)까지 붙으면 완주. 홍길동/MW-2026-0001이 정확히 유지되고, 3단계 워커 초안에 없던 새 수치·법조문·근거가 튀어나오지 않았는지 대조 확인한다(지어내기 방지).
- 6(선택) 코드로 같은 구조 보기 — 오케스트레이터-워커 최소 골격
챗봇 대화로 익힌 구조를 코드 골격으로도 확인하고 싶으면, 브라우저에서 무설치로 실행되는 Python 온라인 실행기(예: programiz.com/python-compiler 또는 replit.com)에 접속해 아래 코드 전문을 붙여넣고 Run(또는 실행) 버튼을 누른다. 실제 LLM 호출·API 키·설치가 전혀 필요 없고, 오케스트레이터가 워커에 팬아웃→취합하고 상한(MAX_WORKERS)으로 폭주를 막는 뼈대만 눈으로 확인한다. (worker 함수 안의 반환문이 실제로는 LLM 호출 자리다 — 여기서는 mock 문자열로 대체.)
코드# 오케스트레이터-워커 최소 골격 (LLM 호출 자리는 mock) MAX_WORKERS = 3 # 워커 수 상한 MAX_RETRY = 1 # 워커당 재작성 상한(참고용) def worker(dept, task): # 실제로는 여기서 LLM 호출 return f"[{dept}] '{task}' 처리 초안: 현장점검 후 조치 예정" def orchestrate(complaint_id, routing): if len(routing) > MAX_WORKERS: # 폭주 방지 게이트 raise SystemExit(f"중단: 워커 {len(routing)}개 > 상한 {MAX_WORKERS}") drafts = [] for dept, task in routing.items(): # 팬아웃(병렬 배정) drafts.append(worker(dept, task)) reply = f"[민원 회신문] {complaint_id} 홍길동님 " + " ".join( # 취합(reduce) f"{i+1}. {d}" for i, d in enumerate(drafts)) return reply routing = { "도로과": "가상마을 3길 도로 파손", "시설과": "가로등 고장", "교통과": "불법 주정차", } print(orchestrate("MW-2026-0001", routing))→ 결과 실행하면 '[민원 회신문] MW-2026-0001 홍길동님' 아래 1·2·3번으로 3개 부서 초안이 취합돼 출력된다. 확인용으로 routing에 부서를 4개 이상 넣고 다시 Run하면 'SystemExit: 중단: 워커 4개 > 상한 3'으로 멈춘다 — 코드 레벨에서 상한(폭주 방지)이 어떻게 강제되는지 눈으로 보인다.
스택 내 위치
스택을 세로로 관통하는 두 횡단 계열 중 하나. 하네스(③)에서 싹터 위로 확장된다. 하네스가 '한 절차'(하나의 결재선을 코드로 굳힌 것)라면, 오케스트레이션은 '여러 절차와 여러 담당의 지휘'다. 아래로는 하네스(반복 실행 틀)와 컨텍스트(핸드오프로 전달할 자료)를 재료로 쓰고, 옆으로는 평가 계열(무엇이 좋은 지휘인지 정의·측정)과 짝을 이루며, 위로는 메타(조직 표준·거버넌스로 재생산)로 결과를 넘긴다. 경계: 단일 호출의 프롬프트 품질은 프롬프트 계열, 자료 선택은 컨텍스트 계열, 한 절차의 재시도·HITL 게이트는 하네스 계열의 몫이다. 오케스트레이션은 '여러 절차·여러 담당을 언제·어떤 순서·누구에게 배분하고 어떻게 종합하느냐'의 지휘 규칙만 담당한다.
핵심 개념 (17)
워크플로는 사람이 절차·분기·순서를 코드로 미리 고정한 것이고, 에이전트는 모델이 스스로 다음 행동·도구·경로를 결정하며 진행하는 것이다. 대부분의 실무는 워크플로로 충분하며, 과제가 다단계이고 사전에 완전히 명세하기 어려울 때만 에이전트가 정당화된다.
💡 가장 흔한 실패는 워크플로로 될 일에 에이전트를 써서 비용·지연·비결정성을 자초하는 것이다. '에이전트를 만들지 말지'를 먼저 판단하는 것이 오케스트레이션의 첫 결정이다.
하나의 지휘 에이전트(오케스트레이터/코디네이터)가 과제를 하위 작업으로 쪼개 여러 워커(서브에이전트)에게 배분하고, 각 결과를 받아 하나로 종합하는 구조. 워커는 각자 독립된 컨텍스트·도구·역할을 갖는다.
💡 복합 과제를 역할별로 분리해 각 워커의 컨텍스트를 좁고 깨끗하게 유지하고, 독립 작업을 병렬화하며, 실패를 국소화한다. 멀티에이전트의 기본 골격이다.
오케스트레이터가 전문화된 하위 에이전트에게 특정 하위 작업을 넘기는 것. 각 서브에이전트는 자신만의 시스템 프롬프트·도구셋·모델·컨텍스트 창을 갖는 격리된 실행 단위다.
💡 역할을 분리하면 각 에이전트의 지시가 단순해지고, 컨텍스트 오염이 줄며, 값싼 모델을 하위 작업에 배치해 비용을 낮출 수 있다(예: 탐색 서브에이전트에 저비용 모델). 다만 위임 남용은 지연·비용을 키운다.
단계들을 실행 순서로 엮는 네 가지 기본 흐름. 순차(앞 결과가 뒤 입력), 분기(조건에 따라 경로 선택), 병렬(독립 단계 동시 실행), 팬아웃(하나의 입력을 N개로 갈라 동시 처리 후 재취합).
💡 의존 관계가 있는 단계를 병렬화하면 오류가 나고, 독립 단계를 순차화하면 느려진다. 흐름 제어를 정확히 설계해야 속도·정확도·비용의 균형이 잡힌다. 팬아웃은 통제하지 않으면 폭주한다.
하나의 작업을 여러 병렬 하위 작업으로 갈랐다가 다시 모으는 팬아웃/팬인 패턴에서, 동시 실행 개수(동시성 상한)·총 갈래 수·각 갈래의 비용을 제한하는 통제.
💡 팬아웃은 지연을 극적으로 줄이지만, 상한이 없으면 수백 개의 병렬 호출로 비용·레이트리밋을 초과하고 시스템을 마비시킨다. 동시성 상한과 갈래 수 상한이 필수다.
오케스트레이터가 서브에이전트에게, 또는 한 단계가 다음 단계에게 작업을 넘길 때, 전체 대화·자료를 통째로 넘기지 않고 그 작업에 필요한 정보만 요약·추려 전달하는 것.
💡 전체 컨텍스트를 매 핸드오프마다 복제하면 토큰 비용이 선형으로 누적되고 무관한 정보가 하위 작업을 오염시킨다. 무엇을 넘기고 무엇을 버릴지가 멀티에이전트 비용·품질의 핵심이다.
주어진 상황에서 어떤 도구·에이전트·경로를 쓸지 실행 중에 결정하는 것. 도구 설명을 근거로 모델이 라우팅하거나, 도구가 많을 때는 도구 검색(tool search)으로 관련 도구만 동적으로 불러온다.
💡 모든 도구를 항상 컨텍스트에 올리면 비용·혼란이 커지고, 경로를 사전 고정하면 비정형 과제에 대응 못 한다. 동적 계획은 자율성의 원천이지만 통제 없이는 비결정적·비용 폭증의 원천이기도 하다.
에이전트 루프(호출→도구실행→재호출 반복)를 언제 멈출지 정하는 규칙. 정상 종료(과제 완료 신호), 반복 상한 도달, 예산 소진, 진전 없음 감지 등 복수의 종료조건을 둔다.
💡 종료조건이 없거나 하나뿐이면 에이전트가 같은 작업을 무한 반복하며 토큰을 태운다. 다중 종료조건과 상한이 오케스트레이션의 가장 기본적인 안전장치다.
에이전트 실행에 대한 세 가지 상한. 비용 상한(토큰·요청 예산), 깊이 상한(서브에이전트가 서브에이전트를 낳는 재귀 단계 수), 반복 상한(한 루프의 최대 회차). 예산은 '모델이 아는 안내'와 '강제 상한' 두 층위로 나뉜다.
💡 자율 에이전트의 통제 핵심. 깊이 상한이 없으면 재귀 폭발, 반복 상한이 없으면 무한 루프, 비용 상한이 없으면 예산 초과가 발생한다. 통제 설계의 정량적 뼈대다.
여러 단계 중 일부가 실패했을 때 대응하는 설계. 재시도, 대안 경로 재배정, 그리고 이미 완료한 단계의 부작용을 되돌리는 보상 처리(compensation, 예: 발송 취소·롤백)를 포함한다.
💡 3단계에서 실패해도 1·2단계의 부작용(발송된 메일, 생성된 레코드)은 남는다. 되돌리기(보상)나 안전한 중단 지점이 없으면 부분 실패가 데이터 정합성을 깨뜨린다. 특히 비가역 행동에서 결정적이다.
에이전트 실행 흐름 중 사람의 승인·검토를 강제하는 지점을 어디에 둘지 설계하는 것. 비가역·고위험 행동(발송·삭제·결제) 앞에 승인 게이트를 배치한다.
💡 자율성과 안전의 균형점. 게이트가 너무 많으면 자동화 이점이 사라지고, 없으면 위험 행동이 무통제로 실행된다. '되돌릴 수 없는 행동'을 기준으로 게이트 위치를 정하는 것이 원칙이다.
여러 에이전트가 공유하는 자원(파일시스템·메모리)과 격리되는 자원(대화 이력·컨텍스트 창)을 구분해 설계하는 것. 공유는 협업을 가능케 하지만 경합·덮어쓰기 위험을, 격리는 안전하지만 정보 단절을 낳는다.
💡 멀티에이전트가 같은 파일을 동시에 쓰면 상태가 깨진다. 무엇을 공유하고 무엇을 격리할지, 공유 자원의 동시 접근을 어떻게 직렬화할지가 정합성의 핵심이다.
여러 워커·병렬 갈래의 결과를 받아 하나의 최종 산출물로 합치는 단계. 단순 취합, 투표·다수결, 상위 종합 에이전트에 의한 재작성 등 방식이 있다.
💡 팬아웃해서 여러 결과를 얻어도 종합이 부실하면 무의미하다. 상충하는 결과의 조정, 중복 제거, 근거 유지가 종합 품질을 좌우한다. 병렬 처리의 마지막 관문이다.
여러 에이전트·단계에 걸친 실행을 추적·기록하는 것. 각 단계의 입력·출력·도구 호출·토큰 사용·상태 전이·소요 시간을 스팬(span)/트레이스로 남겨 실패 원인과 비용을 규명한다.
💡 멀티에이전트는 어디서 무엇이 틀어졌는지 눈에 안 보인다. 관측성이 없으면 디버깅·비용 최적화·평가가 불가능하다. 오케스트레이션을 '측정 가능·개선 가능'하게 만드는 토대다.
에이전트(자율 실행)를 도입할지 판단하는 네 기준: 복잡성(다단계·사전 명세 곤란), 가치(높은 비용·지연을 정당화), 실현성(모델이 실제로 잘하는 과제), 오류 비용(오류를 잡고 복구할 수 있는가).
💡 네 기준 중 하나라도 '아니오'면 단일 호출이나 워크플로에 머물러야 한다. 무분별한 에이전트화는 오케스트레이션 실패의 근본 원인이다.
에이전트 루프 전체에 부여하는 토큰 예산으로, 모델이 남은 예산을 인지하며 스스로 작업을 우선순위화하고 마무리하게 하는 '안내형 상한'. 강제 상한(max_tokens)과 구분된다.
💡 강제 상한은 도중에 잘리지만, 작업 예산은 모델이 예산을 보며 우아하게 마무리하게 한다. 자율 루프의 비용을 '통제하면서도 품질을 덜 해치는' 방식으로 다루는 오케스트레이션 도구다.
오케스트레이션 설계(어떤 흐름·상한·라우팅이 나은지)를 직관이 아니라 평가지표(성공률·비용·지연·안전위반율)로 검증하며 개선하는 접근. 평가 계열과 오케스트레이션 계열이 만나는 지점.
💡 '이 지휘 규칙이 더 낫다'를 어떻게 아는가? 관측성으로 데이터를 모으고 평가로 판정하지 않으면 개선이 불가능하다. 오케스트레이션을 감(感)에서 공학으로 옮기는 실천이다.
학습 목표
- 에이전트와 워크플로의 차이를 설명하고, 주어진 업무가 어느 쪽에 맞는지 판별한다
- 순차·분기·병렬·팬아웃 네 흐름을 행정 업무 예로 구분한다
- 오케스트레이터-워커(총괄 조정관-담당팀) 구조를 그림으로 설명한다
- 무한 루프·비용 폭주가 왜 일어나는지, 상한이 왜 필요한지 말한다
- 휴먼인더루프 게이트를 어디에 둬야 하는지(비가역 행동 앞) 판단한다
- 오케스트레이터-워커 패턴을 코드/의사코드로 구현하고 서브에이전트에 역할·도구를 분담한다
- 루프 종료조건·반복 상한·깊이 상한·비용 상한을 실제로 설정한다
- 팬아웃 작업에 동시성 상한과 팬인 종합 로직을 구현한다
- 핸드오프 시 컨텍스트를 압축해 전달하고, 공유/격리 상태를 구분 설계한다
- 다단계 실패에 재시도·대안 경로·보상 처리를 넣는다
- 각 단계에 관측성(스팬/트레이스)을 심어 비용·실패를 추적한다
- 평가지표(성공률·비용·지연·안전위반율)로 오케스트레이션 설계를 비교·개선하는 파이프라인을 구축한다
- 비동기 서브에이전트·계층적 예산으로 장기 실행 멀티에이전트를 안정적으로 지휘한다
- 조직의 여러 업무에 재사용 가능한 오케스트레이션 표준·게이트 정책을 설계해 메타 계층으로 넘긴다
- 자율성-통제 트레이드오프를 업무 위험도에 맞춰 정량적으로 조율한다
세션 구성
| 회차 | 주제 | 시수 | 내용 | 산출물 |
|---|---|---|---|---|
| 1 | 에이전트냐 워크플로냐: 지휘의 첫 결정 | 3h | 오케스트레이션이 스택에서 차지하는 위치(하네스에서 확장되는 횡단 계열)와 총괄 조정관 비유. 에이전트 vs 워크플로의 정확한 구분. '에이전트를 만들지 말지' 판단하는 네 기준(복잡성·가치·실현성·오류비용). 단일 호출→워크플로→에이전트로 올라가는 계단과, 가장 단순한 층에 머무르라는 원칙. 잘못된 에이전트화의 실패 사례. | 담당 업무 3개를 '단일호출/워크플로/에이전트'로 분류하고 근거를 적은 판단표 |
| 2 | 흐름 제어: 순차·분기·병렬·팬아웃 | 3h | 네 가지 기본 흐름과 의존 관계 분석. 독립 단계 병렬화 vs 의존 단계 순차화의 판별. 팬아웃/팬인 패턴과 동시성 상한. 도구 라우팅·동적 계획의 개념. 행정 업무(복합 민원)를 흐름 다이어그램으로 분해하는 실습. | 실제 복합 업무 하나를 순차·분기·병렬로 분해한 흐름 다이어그램 |
| 3 | 오케스트레이터-워커와 서브에이전트 | 4h | 오케스트레이터-워커 패턴의 구조와 코드. 서브에이전트에 역할·시스템프롬프트·도구셋·모델을 분담하는 법(저비용 모델을 하위 작업에 배치). 컨텍스트 핸드오프와 압축: 전체 서류철이 아니라 필요한 요약만 넘기기. 상태 공유(파일시스템)와 격리(대화이력)의 구분. 결과 종합·집계 방식. | 조사→분석→작성 3역할 서브에이전트를 갖춘 오케스트레이터-워커 최소 구현 |
| 4 | 통제 설계: 상한·종료조건·폭주 방지 | 4h | 루프 종료조건 다중화. 비용·깊이·반복 상한 설정. 강제 상한(max_tokens)과 안내형 예산(task budget)의 차이와 병용. 팬아웃 폭주 방지(동시성·갈래수 상한). 재귀 폭발(서브에이전트가 서브에이전트를 낳는) 방지. '진전 없음' 감지. 상한 없이 돌린 에이전트의 비용 폭주를 재현하고 통제 전후를 비교하는 실습. | 무한 루프·팬아웃 폭주를 방지하는 상한 세트가 적용된 에이전트 코드 |
| 5 | 실패 복구·보상 처리·휴먼인더루프 게이트 | 4h | 다단계 실패의 세 대응: 재시도, 대안 경로 재배정, 보상 처리(부작용 되돌리기). 비가역 행동(발송·삭제·결제) 식별. 승인 게이트 배치 원칙과 구현(도구 승인 정책: always_ask). 게이트 남용(자동화 이점 상실) vs 게이트 부재(위험 무통제)의 균형. 부분 실패 시 데이터 정합성 보전. | 비가역 행동 앞에 HITL 게이트를 두고 실패 시 보상 처리를 하는 워크플로 |
| 6 | 관측성·평가주도 개선·조직 표준화 | 4h | 멀티에이전트 추적: 스팬/트레이스로 각 단계의 입출력·도구호출·토큰·소요시간·상태전이 기록. 관측 데이터로 병목·실패·비용 규명. 평가지표(성공률·비용·지연·안전위반율)로 오케스트레이션 설계를 비교·개선하는 파이프라인. 재사용 가능한 오케스트레이션 표준·게이트 정책을 메타 계층으로 넘기기. 비동기 서브에이전트·계층적 예산으로 장기 실행 지휘. | 트레이스가 심어지고 4개 지표로 두 설계를 비교한 평가 리포트 + 조직 표준 초안 |
실습 랩
랩 1 — 총괄 조정관을 코드로: 오케스트레이터-워커 최소 구현
목표 · 조사→분석→작성 세 역할로 나뉜 서브에이전트를, 하나의 오케스트레이터가 배분·종합하는 최소 멀티에이전트를 직접 만든다. '한 절차'(하네스)와 '여러 담당의 지휘'(오케스트레이션)의 차이를 손으로 느낀다.
- 과제를 하나 정한다(예: '특정 조례 개정 필요성 검토 보고서 초안'). 이를 조사(관련 법령·사례 수집)→분석(쟁점 정리)→작성(초안 생성) 3단계로 쪼갠다.
- 각 단계를 서브에이전트로 정의한다. 서브에이전트마다 (a)전용 시스템프롬프트(역할 한정), (b)허용 도구셋, (c)모델을 지정한다. 조사처럼 넓게 훑는 하위 작업에는 저비용·빠른 모델을, 최종 작성에는 상위 모델을 배치한다.
- 오케스트레이터 에이전트를 만든다. 오케스트레이터는 코디네이터 로스터에 세 워커를 등록하고, 각 워커에게 '그 단계에 필요한 입력만' 넘긴다(전체 대화 이력을 통째로 넘기지 않는다).
- 순차 흐름으로 실행한다: 조사 결과 요약 → 분석 입력, 분석 결과 요약 → 작성 입력. 각 핸드오프에서 이전 단계 산출물을 요약·압축해 넘긴다(컨텍스트 핸드오프).
- 최종 종합 단계에서 오케스트레이터가 세 워커의 산출물을 하나의 보고서 초안으로 합친다(결과 종합).
- 같은 과제를 '단일 에이전트가 통짜로 처리'하는 버전도 만들어, 컨텍스트 오염·산출물 품질·토큰 사용을 두 버전 간 비교한다.
✅ 성공 기준 · 세 워커가 각자 역할대로 동작하고, 오케스트레이터가 결과를 하나로 종합하며, 각 워커의 컨텍스트에 무관한 정보가 섞이지 않는다. 단일 에이전트 버전 대비 역할 분리의 효과(또는 오버헤드)를 수치로 설명할 수 있다.
↗ 확장 · 조사와 분석 중 서로 독립적인 하위 조사 2건을 병렬(팬아웃)로 실행하고 팬인에서 합쳐, 순차 대비 지연 감소를 측정한다. 비동기로 워커를 띄우고 오케스트레이터가 다른 일을 하다가 결과를 회수하는 형태로 확장한다.
랩 2 — 폭주하는 에이전트 길들이기: 상한·종료조건·게이트
목표 · 통제 없이 돌린 에이전트가 어떻게 비용·시간을 폭주시키는지 재현하고, 종료조건·상한·게이트를 하나씩 넣어 통제 전후를 정량 비교한다. 실패 복구와 HITL 게이트까지 붙인다.
- 의도적으로 종료조건이 약한 에이전트 루프를 만든다(예: '완료라고 판단될 때까지 도구를 계속 호출'만 있는 루프). 반복 상한 없이 돌려 몇 회차·몇 토큰까지 가는지 관측한다. 안전을 위해 하드 비용 상한만 걸어두고 실행한다.
- 다중 종료조건을 추가한다: (a)명시적 완료 신호, (b)반복 상한, (c)진전 없음(같은 도구·같은 인자 반복) 감지, (d)예산 소진. 각 조건이 발동하는지 로그로 확인한다.
- 서브에이전트를 스폰하는 로직을 넣되 깊이 상한을 설정한다(예: 위임은 1단계까지만). 상한을 껐을 때 재귀가 어디까지 번지는지, 켰을 때 어디서 멈추는지 비교한다.
- 팬아웃 작업(예: 10개 문서 병렬 검토)에 동시성 상한을 걸고, 상한 유무에 따른 최대 동시 호출 수·레이트리밋 접촉·총비용을 비교한다.
- 강제 상한(max_tokens류)과 안내형 작업 예산을 함께 적용해, 잘림(강제 상한 초과)과 우아한 마무리(예산 인지)의 차이를 관찰한다.
- 비가역 행동(예: '외부로 안내문 발송') 하나를 도구로 만들고, 그 도구에 승인 게이트(always_ask)를 건다. 게이트에서 승인/거부를 주고, 거부 시 에이전트가 대안 경로로 재계획하는지 확인한다.
- 3단계 워크플로에서 2단계를 강제 실패시키고, (a)재시도, (b)대안 경로, (c)1단계에서 만든 부작용을 되돌리는 보상 처리가 동작하는지 검증한다.
✅ 성공 기준 · 통제 전(폭주)과 통제 후(상한·종료조건으로 안정)를 회차·토큰·비용·최대동시성 수치로 대비해 보여준다. 비가역 행동은 승인 없이는 실행되지 않으며, 부분 실패 시 보상 처리로 정합성이 유지된다.
↗ 확장 · 각 단계에 트레이스/스팬을 심어, 어느 종료조건이 실제로 가장 자주 발동하는지, 비용이 어느 단계에 집중되는지를 관측 데이터로 규명하고, 그 데이터를 근거로 상한값을 재조정한다.
사례 연구
상황 · 한 지자체가 여러 부서 검토가 얽힌 복합 인허가(예: 건축+환경+교통 동시 검토)의 사전검토를 AI로 지원하려 한다. 민원 접수 시 관련 법령 대조, 부서별 검토의견 초안, 상충 쟁점 식별, 종합 안내문 생성을 한 번에 돌리고 싶다.
오케스트레이터가 민원을 받아 '이 건이 단일 부서로 끝나는지, 복수 부서 협업인지'를 먼저 분기한다(에이전트 vs 워크플로 판단). 복수 협업 건이면 건축·환경·교통 세 검토를 서로 독립적이므로 병렬(팬아웃)로 배분하되, 동시성 상한을 둔다. 각 검토 서브에이전트에는 전체 민원 서류가 아니라 해당 부서에 필요한 항목만 압축해 넘긴다(핸드오프). 세 검토가 끝나면 종합 에이전트가 상충 쟁점(예: 교통은 승인, 환경은 조건부)을 식별해 하나의 사전검토서로 합친다(결과 종합). '민원인에게 결과를 대외 발송'하는 비가역 행동은 담당 공무원 승인 게이트(HITL) 뒤에 둔다—AI는 초안까지만, 발송은 사람이 결재한다. 검토 중 한 부서 자료가 미비하면 대안 경로(보완요청 생성)로 재배정한다. 모든 단계는 처리대장(트레이스)에 남아 감사 대상이 된다. MCP로 내부 법령DB·문서시스템을 도구로 연결하되, 각 도구 접근은 최소 권한으로 격리한다.
교훈 · 행정에서 오케스트레이션의 가치는 '자동 발송'이 아니라 '병렬 검토·상충 식별·초안 종합의 자동화 + 결정적 순간의 사람 결재'에 있다. 비가역 행동 앞 HITL 게이트, 부서별 최소 정보 핸드오프, 감사 가능한 트레이스가 공공 적용의 3대 전제다.
상황 · 대규모 코드베이스에서 '설계 문서를 받아 PR 초안까지' 만드는 코딩 에이전트를 구축한다. 단일 에이전트로는 컨텍스트가 넘치고 병렬 탐색이 안 된다.
메인 오케스트레이터는 상위 모델로 계획·종합을 맡고, 여러 파일을 동시에 읽어야 하는 탐색 하위 작업은 저비용·빠른 탐색 서브에이전트에 팬아웃으로 위임한다—이렇게 하면 메인 루프의 모델·프롬프트 캐시를 깨지 않으면서 병렬 탐색으로 지연을 줄인다. 서브에이전트는 파일시스템을 공유하지만(협업) 대화 이력은 격리된다(컨텍스트 오염 방지). 각 탐색 서브에이전트는 자기 발견을 요약만 오케스트레이터에 돌려준다(압축 핸드오프)—전체 파일 내용을 되돌리지 않는다. 위임 깊이는 1단계로 제한해 재귀 폭발을 막고, 도구가 많을 때는 도구 검색으로 관련 도구만 동적 로드해 컨텍스트를 좁게 유지한다. '브랜치 푸시·PR 생성' 같은 비가역 행동은 승인 게이트 뒤에 두거나 별도 권한 도구로 격리한다. 장기 실행 시에는 계층적 작업 예산으로 전체 루프의 토큰을 통제하고, 컨텍스트가 커지면 압축으로 이력을 요약한다.
교훈 · 오케스트레이터는 값비싼 상위 모델, 워커는 값싼 하위 모델로 나누는 것이 비용·속도의 핵심 지렛대다. 파일시스템은 공유하되 컨텍스트는 격리, 발견은 요약만 되돌리기, 위임 깊이 제한, 비가역 행동 격리—이 네 규칙이 실전 멀티에이전트를 안정시킨다.
흔한 실패 · 안티패턴
- 워크플로로 될 일에 에이전트를 쓴다: 사전에 절차가 고정 가능한 업무를 굳이 자율 에이전트로 만들어 비결정성·비용·지연을 자초한다. '에이전트를 만들지 말지' 네 기준을 먼저 통과시켜라.
- 종료조건이 하나뿐이거나 없다: '완료 판단 시 종료'만 두면 모델이 완료를 인지 못 해 무한 반복한다. 완료 신호·반복 상한·진전없음 감지·예산 소진을 함께 걸어라.
- 깊이 상한이 없어 재귀 폭발한다: 서브에이전트가 또 서브에이전트를 스폰하는 위임에 깊이 제한이 없으면 기하급수적으로 번진다. 대개 위임은 1단계로 충분하다.
- 팬아웃 동시성 상한이 없다: 수백 갈래 병렬 호출이 레이트리밋·비용을 초과하고 시스템을 마비시킨다. 동시성 상한과 갈래 수 상한을 반드시 둔다.
- 핸드오프에서 전체 컨텍스트를 통째로 복제한다: 매 위임마다 전체 대화·서류철을 넘기면 토큰이 누적 폭증하고 무관 정보가 하위 작업을 오염시킨다. 필요한 요약만 압축해 넘겨라.
- 비가역 행동에 게이트가 없다: 발송·삭제·결제 같은 되돌릴 수 없는 행동을 승인 없이 자동 실행하면 사고가 돌이킬 수 없다. '되돌릴 수 없는가'를 기준으로 게이트를 배치하라.
- 반대로 게이트를 남발한다: 모든 단계에 승인을 걸면 자동화 이점이 사라진다. 게이트는 비가역·고위험 지점에만.
- 공유 상태의 경합을 무시한다: 여러 에이전트가 같은 파일을 동시에 쓰면 상태가 깨진다. 무엇을 공유/격리할지 정하고 공유 자원 접근을 직렬화하라.
- 부분 실패 시 보상 처리가 없다: 3단계 실패 후 1·2단계의 부작용이 그대로 남아 정합성이 깨진다. 롤백·발송취소 같은 보상 처리나 안전 중단점을 설계하라.
- 관측성 없이 돌린다: 트레이스가 없으면 어느 단계에서 무엇이·왜 틀어졌는지 알 수 없어 디버깅·비용최적화·평가가 전부 불가능해진다. 처음부터 스팬/트레이스를 심어라.
- 강제 상한과 안내형 예산을 혼동한다: max_tokens류 강제 상한은 도중에 잘리고, 작업 예산은 모델이 인지하며 마무리한다. 둘의 역할을 구분해 병용하라.
- 개선을 감으로 한다: '이 지휘가 더 낫다'를 지표 없이 판단하면 개선이 정체된다. 성공률·비용·지연·안전위반율로 설계를 비교하는 평가주도로 옮겨라.
평가
| 평가 기준 | 초급 | 능숙 | 전문 |
|---|---|---|---|
| 에이전트 vs 워크플로 판단 | 둘의 차이를 어렴풋이 알지만, 주어진 업무를 어느 쪽으로 만들지 근거 있게 결정하지 못한다. | 네 기준(복잡성·가치·실현성·오류비용)으로 업무를 분류하고, 가장 단순한 층에 머무르는 원칙을 적용한다. | 업무 위험도·비용에 맞춰 단일호출/워크플로/에이전트의 경계를 정량적으로 판단하고, 조직 차원의 도입 기준을 표준화한다. |
| 흐름 제어와 오케스트레이터-워커 설계 | 순차만 다루고 병렬·팬아웃의 필요를 인지하지 못하거나 의존 관계를 잘못 파악한다. | 의존 관계를 분석해 순차·분기·병렬을 올바로 배치하고, 오케스트레이터-워커로 역할을 분담·종합한다. | 팬아웃/팬인·비동기 위임·핸드오프 압축을 조합해 지연·비용·품질을 동시에 최적화하고, 저비용 워커 배치로 비용 지렛대를 활용한다. |
| 통제 설계(상한·종료·폭주 방지) | 상한의 필요는 알지만 종료조건·깊이·반복·비용 상한을 실제로 설정하지 못한다. | 다중 종료조건과 비용·깊이·반복 상한, 팬아웃 동시성 상한을 설정해 폭주를 막는다. | 강제 상한과 안내형 예산을 병용하고, 관측 데이터로 상한값을 근거 있게 튜닝하며 재귀 폭발·무한 루프를 구조적으로 차단한다. |
| 실패 복구·안전·HITL | 실패를 재시도로만 대응하고 부작용·비가역 행동을 고려하지 않는다. | 재시도·대안 경로·보상 처리를 넣고, 비가역 행동 앞에 승인 게이트를 배치한다. | 부분 실패의 정합성 보전을 설계하고, 게이트 위치를 위험도에 맞춰 최적화해 자동화 이점과 안전을 함께 확보한다. |
| 관측성·평가주도 개선 | 실행 결과만 보고 단계별 추적·지표 없이 감으로 개선한다. | 각 단계에 트레이스를 심어 비용·실패를 규명하고, 지표로 두 설계를 비교한다. | 평가 파이프라인으로 오케스트레이션 설계를 지속 비교·개선하고, 그 표준·게이트 정책을 메타 계층으로 넘겨 조직에 재생산한다. |
- 'AI 에이전트'와 '고정된 워크플로'의 차이는 무엇이라고 생각하는가? 어떤 업무에 각각이 맞는가?
- 여러 단계로 이뤄진 업무를 AI로 자동화할 때, 무엇이 잘못되면 비용이나 시간이 폭주할 것 같은가?
- AI가 자동으로 '외부 발송·삭제·결제' 같은 행동을 하게 두는 것의 위험은 무엇이며, 어떻게 통제하겠는가?
- 조사→분석→작성으로 나뉜 업무를 오케스트레이터-워커로 설계하라. 각 워커의 역할·도구·모델 배분과, 핸드오프 시 무엇을 압축해 넘길지 기술하라.
- 종료조건 없이 돌린 에이전트가 무한 반복에 빠졌다. 이를 막기 위한 종료조건·상한 4가지를 제시하고, 강제 상한과 안내형 예산의 차이를 설명하라.
- 10개 문서를 병렬 검토하는 팬아웃 작업에서 발생할 수 있는 폭주 두 가지와 각각의 통제책을 쓰라.
- 3단계 워크플로의 2단계에서 실패했고 1단계가 이미 외부에 메일을 발송했다. 정합성을 보전하는 대응(재시도·대안·보상·게이트 포함)을 설계하라.
- 두 오케스트레이션 설계 중 무엇이 더 나은지 판정하려 한다. 어떤 지표를 수집하고, 관측성을 어떻게 심을 것인가?
읽을거리 · 도구
- Anthropic, "Building effective agents"(효과적 에이전트 구축) 엔지니어링 글 — 워크플로와 에이전트의 구분, 오케스트레이터-워커·프롬프트 체이닝·라우팅·병렬화 같은 핵심 패턴을 예시로 정리한다. ('에이전트를 만들지 말지'와 '가장 단순한 층에 머물라'는 이 계열의 첫 원칙을 왜 그렇게 주장하는지 근거를 얻기 위해 읽어라. 유행어가 아니라 패턴의 언제·왜에 집중해 읽는다.)
- Anthropic 멀티에이전트 리서치 시스템 구축 사례 엔지니어링 글 — 오케스트레이터-워커로 여러 서브에이전트를 병렬 지휘하며 겪은 실전 문제—컨텍스트 핸드오프, 토큰 비용, 상태 관리, 평가—를 서술한다. ('멀티에이전트가 왜 비싼가'와 '무엇을 압축·격리해야 하는가'를 실무 관점에서 이해하려고 읽어라. 병렬화의 이점과 비용 폭증의 양면을 함께 본다.)
- Claude 도구 사용(tool use)·서브에이전트·작업 예산 공식 문서 — 오케스트레이션 하위 실천의 기술적 사실—도구 라우팅·도구 검색, 서브에이전트 위임, 강제 상한(max_tokens)과 안내형 작업 예산의 차이, 승인 정책(always_ask)—을 정확히 규정한다. (통제 설계를 실제 코드로 옮길 때 '무엇이 강제이고 무엇이 안내인지', '깊이·반복·비용을 어디서 거는지'를 사실대로 확인하려고 읽어라. 값과 파라미터명은 반드시 문서로 검증한다.)
- 분산 트랜잭션의 사가(Saga) 패턴·보상 트랜잭션 자료 — 다단계 처리에서 일부 실패 시 이미 완료한 단계를 되돌리는 보상 트랜잭션의 고전 설계를 다룬다. 에이전트 이전부터 존재한 개념이다. ('다단계 실패 복구·보상 처리'가 새 개념이 아니라 분산시스템의 오랜 문제임을 이해하고, 그 지혜를 에이전트 오케스트레이션에 이식하기 위해 읽어라.)
- 관측성/트레이싱(스팬·트레이스) 표준 개념 자료 — 분산 실행을 스팬·트레이스로 기록·추적하는 관측성의 표준 개념을 설명한다. (멀티에이전트 추적을 '무엇을 스팬으로 남길지'로 구체화하기 위해 읽어라. 평가·비용최적화·디버깅이 모두 이 기록 위에 선다는 점을 확인한다.)