AI 에이전트 오케스트레이션 설계: 협업 패턴부터 승인·비용 통제까지

AI 에이전트 오케스트레이션을 제대로 설계하려면 에이전트를 늘리기 전에 다음 단계를 누가 책임질지 정해야 합니다. 요청 접수부터 조사, 초안 작성, 승인까지 핵심 판단을 다루는 패턴은 4가지입니다. 리드 에이전트와 작업 에이전트의 협업, 전문 에이전트 간 핸드오프, 체크포인트를 갖춘 그래프, 그리고 에이전트 전체를 감싸는 내구성 있는 워크플로입니다. 메시지 발송, 지출, 레코드 변경 권한은 모델의 재량에 맡기지 않아야 합니다.

아래 문서와 인프라 요금은 2026년 10월 13일에 확인했습니다. 업무 사례는 제안하는 설계안이며, 실제 도입 사례나 성능 벤치마크가 아닙니다.

AI 에이전트 오케스트레이션이란 무엇인가요?

오케스트레이션은 다음에 어떤 에이전트가 일할지, 어떤 정보를 받을지, 그 결과를 실제 실행으로 옮기기 전에 무엇을 거쳐야 할지 결정합니다. 에이전트는 모델에 지침과 툴을 결합한 구성입니다. 오케스트레이터는 그 주변에서 책임 주체, 공유 상태, 허용된 전환, 종료 조건을 관리합니다.

요청 접수 에이전트 하나만으로도 두서없는 요청을 유용한 업무 개요로 정리할 수 있습니다. 여기에 조사 담당과 작성 담당을 추가하면 새로운 문제가 생깁니다. 근거가 충돌할 때는 누가 판단할까요? 승인자는 어느 버전의 초안을 검토했을까요? 이메일 서비스가 타임아웃됐다면 메시지는 발송된 걸까요? 이런 문제는 프로세스를 설계할 때 풀어야 합니다.

어떤 책임을 분리해야 하는지에 따라 패턴을 선택합니다.

이 패턴들은 중첩해서 사용할 수 있습니다. 내구성 있는 워크플로가 그래프를 호출하고, 그래프의 한 단계인 노드가 리드 에이전트에게 조사를 배분하도록 요청할 수 있습니다. 각 계층에는 고유한 역할이 있어야 합니다. 책임 구분 없이 계층만 늘리면 디버깅할 곳만 많아집니다.

단일 에이전트 구성에서 달라지는 핵심은 책임 소재입니다. 운영 책임자는 담당자와 다음 조치가 표시된 업무 대기열이 필요합니다. 엔지니어링 책임자는 저장된 상태와 복구 가능한 실행이 필요합니다. 구매 담당자는 선택한 서비스가 이 책임 중 어디까지 운영하고, 어디부터 직접 맡아야 하는지 알아야 합니다.

리드와 작업 에이전트: 최종 책임자는 하나로 둡니다

전문가별 작업이 도움이 되면서도 일관된 하나의 답이 필요할 때는 리드와 작업 에이전트 패턴을 사용합니다. 제안서 책임자가 동료들에게 근거를 요청한 뒤 이를 모아 제안서를 완성하는 방식입니다. 동료들은 자료를 보태지만 고객에게 독자적으로 약속하지는 않습니다.

영업 운영 요청이라면 리드가 고객사 조사와 내부 제품 적합성 검토를 각각 맡기고, 결과를 종합해 초안 작성용 개요를 만들 수 있습니다.

1. 1

   리드에게 목표와 권한 범위를 제시합니다

   목표는 근거를 갖춘 제안서 초안입니다. 허용되는 업무는 조사와 작성입니다. 제안서 발송, 할인 약속, 고객 레코드 갱신은 별도 작업으로 남겨 둡니다.

2. 2

   범위를 정한 조사 업무를 배분합니다

   각 작업 에이전트에게 관련 자료, 허용된 툴, 기대하는 출력, 종료 조건을 전달합니다. 서로 독립적인 조사는 동시에 진행하고, 다른 작업의 결과가 실제로 필요한 경우에는 기다립니다.

3. 3

   근거를 돌려받은 뒤 종합합니다

   출처, 조사 결과, 미해결 질문을 함께 제출하도록 합니다. 리드는 모순되는 내용을 조정하고 초안을 만듭니다. 출처가 없다면 없는 상태로 남겨야 합니다. 요약 과정을 거쳤다고 근거 없는 내용이 단정적인 문장으로 바뀌어서는 안 됩니다.

4. 4

   결과물을 승인 대상으로 제출합니다

   고객사 담당자가 발송할 메시지, 수신자, 약속하는 내용을 검토합니다. 애플리케이션이 제어하는 발송 단계는 승인된 결과물만 실행에 옮깁니다.

Anthropic의 프로그래밍 가능한 에이전트 런타임인 Claude Agent SDK는 서브에이전트로 이 패턴을 구현합니다. 서브에이전트는 각자의 지침, 컨텍스트, 툴 접근 권한을 가진 별도 에이전트 인스턴스입니다. agents 옵션으로 정의하면 메인 에이전트가 Agent 툴을 통해 호출합니다. 포크 방식이 아닌 일반 서브에이전트는 부모의 대화 기록을 받지 않으므로, 작업 프롬프트에 필요한 맥락을 담아야 합니다. 부모는 최종 보고서를 받습니다. Claude 서브에이전트 문서.

이때 유용한 구분 기준은 어떤 근거를 제출해야 하는지 미리 정하는 것입니다. 조사 담당은 권고안과 이를 뒷받침하는 원문 구절을 함께 반환할 수 있습니다. 주의할 한계: 컨텍스트가 분리되면 고객의 필수 조건도 빠질 수 있습니다. 그 조건을 명시적으로 전달하고, 뒷받침하는 자료를 검토할 수 있도록 보관합니다.

역할별 에이전트와 작업을 구성하는 프레임워크인 **CrewAI**는 manager_llm 또는 manager_agent를 사용하는 계층형 프로세스를 제공합니다. 매니저가 계획을 세우고, 업무를 배분하고, 결과를 검토합니다. 순차형 프로세스는 작업 목록의 순서를 따르며 앞선 결과를 컨텍스트로 활용합니다. CrewAI 프로세스 문서.

업무 배분에 판단이 필요하면 계층형을 선택합니다. 조사가 항상 작성보다 먼저여야 한다면 순서를 명시하는 편이 점검하기 쉽습니다. 주의할 한계: 매니저의 검토도 자동화된 판단입니다. CrewAI의 작업 옵션 human_input은 최종 답변에 대한 사람의 검토를 요청합니다. 중요한 데이터 변경이 이뤄진 뒤에야 검토하게 되는 일을 막으려면 조사와 작성 작업에는 읽기 전용 기능만 부여해야 합니다. CrewAI 작업 문서.

핸드오프: 다음 판단을 전문 에이전트에게 넘깁니다

다른 전문 에이전트가 다음 응답이나 후속 업무를 책임져야 할 때는 핸드오프를 사용합니다. 상담 이력을 첨부해 지원 건을 청구 담당자에게 이관하는 것과 비슷합니다. 자신이 담당자로 남은 채 청구 담당자에게 질문만 하는 것과는 다릅니다.

에이전트 애플리케이션용 라이브러리인 OpenAI Agents SDK는 이 책임 구분을 명확히 합니다. 핸드오프는 전문 에이전트에게 제어권을 넘기고, 에이전트를 툴로 제공하는 방식은 매니저가 응답 책임을 유지합니다. JavaScript의 agent.asTool()이 후자를 지원합니다. 핸드오프에는 구조화된 메타데이터나 필터링한 대화 기록을 포함할 수 있습니다. OpenAI 오케스트레이션 문서.

고객 운영팀의 수신함에서는 다음 순서로 구성할 수 있습니다.

1. 요청 접수 에이전트가 청구 이의 제기임을 파악하고 관련 계정과 청구서 참조 정보를 수집합니다.
2. 고객의 요청, 확인된 사실, 미해결 질문, 허용된 다음 조치와 함께 해당 건을 청구 전문 에이전트에게 넘깁니다.
3. 청구 전문 에이전트가 조사하고 해결안 초안을 작성합니다. 접수 에이전트에게 조사 메모를 돌려주는 대신 다음 응답을 책임집니다.
4. 환불이나 계정 변경안은 해당 툴을 실행하기 전에 사람이 승인합니다.

주의할 한계: 핸드오프가 넘기는 것은 제어권이지 업무상 권한이 아닙니다. 접수 에이전트가 요청을 전달했다는 이유만으로 수신 에이전트에 환불 권한이 생겨서는 안 됩니다. 환불 툴이 실행되는 지점에서 실행 정책을 강제해야 합니다.

전문 에이전트가 해당 건을 다시 돌려보낼 수 있는지도 정합니다. 사유를 명시한 에스컬레이션은 허용하되 반복 이관 횟수에는 상한을 둡니다. 그렇지 않으면 모호한 요청이 전문 에이전트 사이를 맴돌며 진전 없이 모델 호출만 소모할 수 있습니다.

SDK의 승인 수명주기는 애플리케이션에서 검토할 수 있도록 중단 정보와 재개 가능한 상태를 반환합니다. 판단이 늦어질 때를 대비해 이 상태를 영속 저장하고 동일한 실행을 재개합니다. 입력 가드레일은 첫 번째 에이전트에, 출력 가드레일은 최종 출력을 내는 에이전트에 적용됩니다. 이 바깥쪽 검사만으로 모든 내부 작업이 점검된다고 가정하지 말고 민감한 툴 주위에 검사를 배치해야 합니다. OpenAI 사람 검토 문서.

체크포인트를 갖춘 그래프: 다음 경로를 명시합니다

어느 에이전트가 즉석에서 계획을 세우느냐보다 허용된 진행 경로가 중요할 때는 그래프를 사용합니다. 그래프는 규칙으로 연결한 단계들의 집합입니다. 체크포인트는 프로세스를 멈췄다가 나중에 이어갈 수 있도록 저장한 진행 기록입니다.

상태를 유지하는 에이전트 워크플로용 프레임워크인 **LangGraph**는 분기와 병렬 작업을 포함해 워크플로 경로를 명시할 수 있게 합니다. 체크포인터는 스레드의 그래프 상태를 저장하고, interrupt()는 외부 입력을 기다리며 실행을 일시 중지합니다. 중단된 스레드는 Command(resume=...)으로 재개합니다. LangGraph 워크플로 패턴, 중단 기능 문서.

공급업체 추천안을 준비하는 구매팀이라면 다음과 같이 구성합니다.

1. 1

   업무 건을 구조화된 상태로 저장합니다

   요청, 근거 참조 정보, 누락된 정보, 초안 위치, 검토 상태를 각각 이름이 있는 필드에 보관합니다. 대화 기록을 함께 둘 수는 있지만 현재 상태가 대화 기록에만 남아 있어서는 안 됩니다.

2. 2

   허용된 경로를 정의합니다

   필수 필드가 채워지면 접수에서 조사로 넘어갑니다. 정보가 부족하면 요청자에게 돌려보냅니다. 조사 결과는 초안 작성으로 이어지고, 근거를 점검하다 필요하면 특정 사항을 더 조사하도록 되돌릴 수 있습니다.

3. 3

   체크포인트를 저장하고 검토를 기다립니다

   추천안을 저장하고 승인이 필요한 작업 전에 실행을 중단합니다. 구매 담당 책임자는 실행에 사용할 바로 그 결과물과 근거, 요청된 조치를 검토합니다.

4. 4

   허용된 분기로 재개합니다

   승인되면 제출을 허용합니다. 수정 요청이 오면 작성 단계로 돌아가며 기존 승인은 무효화합니다. 반려되면 사유를 기록하고 해당 건을 종료합니다.

주의할 한계: LangGraph의 중단된 실행을 재개하면 중단 지점이 포함된 노드가 처음부터 다시 시작됩니다. 중단 지점 앞의 코드도 다시 실행됩니다. 중요한 데이터 변경은 별도로 제어하는 단계에 두고, 반복될 수 있는 작업에는 멱등성을 보장해야 합니다. 즉, 논리적으로 동일한 요청을 반복해도 추가 효과가 생기지 않아야 합니다. LangGraph의 중단 규칙.

예를 들어 공급업체 레코드를 제출한 뒤 승인을 요청하는 노드는 이미 실행 경계를 넘어선 상태입니다. 재개할 때 다시 제출할 수도 있습니다. 먼저 변경안을 준비하고, 승인을 받은 다음, 일관되게 유지되는 작업 식별자로 승인된 변경을 실행해야 합니다.

프로덕션에서는 영속적인 체크포인트 저장소를 선택합니다. LangGraph의 인메모리 저장기는 프로세스를 재시작하면 체크포인트를 잃습니다. 계속 유지되는 스레드 식별자와 데이터베이스에 저장하는 상태도 복구 설계에 포함됩니다. LangGraph 영속성 문서.

내구성 있는 워크플로: 에이전트 실행이 끝나도 업무는 이어집니다

에이전트 호출이 끝나거나 워커가 재시작되거나 외부 응답이 지연돼도 업무 프로세스가 유지돼야 한다면 내구성 있는 워크플로를 사용합니다. 워크플로는 시작, 대기, 재시도, 재개, 완료, 에스컬레이션에 이르는 전체 수명주기를 관리합니다. 에이전트는 그 안에서 일하는 참여자입니다.

내구성 있는 다단계 실행 서비스인 **Cloudflare Workflows**는 단계의 실행 상태를 영속 저장하고 재시도를 설정할 수 있게 합니다. 작업에는 step.do, 외부 결정을 기다릴 때는 step.waitForEvent, 대기 중인 인스턴스에 결정을 전달할 때는 instance.sendEvent를 사용합니다. Cloudflare Workflows, 이벤트 문서.

맞춤형 서비스 요청을 처리하는 운영팀이라면 다음 순서로 구성할 수 있습니다.

1. 요청이 들어오면 업무 레코드와 일관되게 유지되는 워크플로 식별자를 생성합니다.
2. 조사 에이전트를 호출하고 근거 자료를 영속 저장한 다음, 그 자료를 전달해 작성 에이전트를 호출합니다.
3. 응답 초안을 저장하고 운영 책임자의 승인 이벤트를 기다립니다. 승인 화면에는 업무 건과 결과물 버전이 모두 명확히 표시돼야 합니다.
4. 결정을 검증하고, 승인된 발송이나 레코드 갱신을 별도 단계에서 실행합니다.
5. 외부 시스템의 처리 확인 정보를 기록하고 해당 건을 완료합니다. 완료 여부가 불확실하면 다시 쓰기를 요청하기 전에 외부 시스템과 처리 결과를 대조합니다.

주의할 한계: 내구성 있는 실행을 도입해도 외부 서비스의 작업을 자동으로 안전하게 반복할 수 있는 것은 아닙니다. Cloudflare는 멱등성을 갖춘 API 호출, 세분화된 단계, 결정론적인 단계 이름을 명시적으로 권장하며, step.do 밖에서 외부 상태를 바꾸는 작업을 하지 말라고 안내합니다. 서비스가 발송 요청을 수락했지만 응답이 유실됐다면, 중복 방지 없이 재시도할 때 다시 발송될 수 있습니다. Workflows 실행 규칙.

재시도는 요청을 바꾸지 않아도 해소될 수 있는 일시적 실패에 맞춰 설정합니다. 인증 실패, 승인 거절, 유효하지 않은 업무 지시는 대개 개입이 필요합니다. Cloudflare는 재시도 설정과 함께, 더 이상 재시도하면 안 되는 실패를 위한 NonRetryableError를 제공합니다. 재시도 문서.

영속 체크포인트를 사용하는 LangGraph 애플리케이션에는 이미 복구 기능이 있습니다. 별도 워크플로 엔진은 여러 서비스, 콜백, 에이전트 런타임을 아우르는 더 넓은 수명주기를 맡을 때 의미가 있습니다. 두 계층이 비용을 발생시키거나 외부 상태를 바꾸는 동일 작업을 각자 재시도하지 않도록 합니다. 이 책임 구분은 관리형 에이전트의 결과, 웹훅, Cloudflare 워크플로 비교에서 더 자세히 다룹니다.

사람의 승인은 실제 실행 직전에 확인합니다

중요한 영향을 미치는 작업은 실행할 바로 그 내용에 대해 사람이 사전에 승인해야 합니다. 자연스럽게 작성된 초안을 검토했더라도 다른 에이전트가 나중에 수신자, 금액, 첨부 파일을 바꿀 수 있다면 충분하지 않습니다.

제안서 검토 화면에는 수신자, 최종 메시지, 첨부 문서, 거래 조건에 관한 약속, 불확실한 주장을 뒷받침하는 근거를 보여줘야 합니다. 승인 기록에는 검토자의 신원을 해당 결과물 버전 및 실행 인자와 연결해 남겨야 합니다.

실행기는 실제 작업 직전에 이 기록을 확인하도록 설계합니다. 승인 후 초안이나 발송 대상이 바뀌었다면 다시 검토 단계로 돌려보냅니다. 권한 있는 사람이 내린 명시적인 승인 결정을 사용하고, 의견이나 수정 제안은 승인 결정과 구분합니다.

CrewAI Flows는 @persist로 상태를 영속 저장하고 @human_feedback으로 피드백을 기다리며 일시 중지할 수 있습니다. 중요한 작업에서는 한 가지 세부 동작을 알아야 합니다. emit 결과값을 설정하면 피드백 메커니즘이 언어 모델로 자유 형식 의견을 해석해 결과값으로 변환합니다. 이렇게 해석한 의견만으로 실행을 허용하지 말고, 별도로 검증한 승인 필드를 권한 확인에 사용해야 합니다. CrewAI Flows 문서.

프로세스에서 새로운 구매가 발생할 수 있는 곳마다 별도의 권한 경계를 둡니다. 연결 실패를 재시도하는 것과 에이전트가 완성된 결과를 마음에 들어 하지 않아 새 결과물을 구매하는 것은 서로 다른 결정입니다. 후자는 정해진 지출 한도나 새로운 승인이 필요합니다. 이 실패 유형은 AI 에이전트 재시도에 사람의 승인을 적용하는 방법에서 다룹니다.

무엇을 기록하고 어디에 상한을 둘까요?

업무 건을 재구성할 수 있을 만큼 기록하고, 추가 작업을 시작하기 전에 상한을 적용합니다. 매끄러운 최종 응답만으로는 잘못된 결과물이 발송됐거나 예산을 초과한 이유를 설명할 수 없습니다.

업무 레코드와 실행 이벤트에 다음 필드 그룹을 사용합니다.

• 식별 정보와 실행 계보: 업무 건 ID, 워크플로/실행 ID, 부모 및 자식 실행 ID, 에이전트 역할, 현재 단계와 시도 차수입니다. 작업 에이전트의 실패를 원래 업무 요청과 연결하는 정보입니다.
• 입력과 구성: 입력 자료의 참조 정보와 버전, 모델 식별자, 프롬프트/구성 버전, 허용된 툴 목록입니다. 실행 사이에 무엇이 바뀌었는지 파악할 수 있습니다.
• 결정과 근거: 라우팅 결정, 선택한 목적지, 출처, 검증 결과, 누락된 정보입니다. 관찰 가능한 결정과 간결한 사유를 기록하며, 모델의 비공개 추론에 의존하지 않습니다.
• 승인: 검토자, 결정, 타임스탬프, 결과물 다이제스트, 실행 인자, 만료 시점입니다. 다이제스트는 검토한 콘텐츠를 식별하는 지문입니다.
• 실행과 복구: 툴 이름, 민감 정보를 가린 인자, 작업/멱등성 키, 외부 요청 ID, 처리 확인 정보, 실패 유형, 예정된 재시도입니다. 결과를 알 수 없을 때는 불확실 상태를 명시적으로 유지합니다.
• 사용량과 결과: 모델 토큰 유형별 사용량, 추정 지출과 대조를 마친 지출, 유료 툴 사용량, 경과 시간, 검토 대기 시간, 최종 상태, 사람이 결과를 수용했는지 여부입니다.

이 로그를 열람할 수 있는 사람을 제한합니다. 비밀 정보는 넣지 않고 고객 데이터는 최소화합니다. 전체 내용을 복사하면 불필요한 노출이 생기는 경우에는 접근 제어가 적용된 자료의 참조 정보만 사용합니다.

OpenAI Agents SDK의 트레이싱은 모델 호출, 툴 호출, 핸드오프, 가드레일을 기록합니다. 이 기술 추적 정보를 업무 레코드와 연결합니다. 고객 대상 작업이 승인됐는지에 대한 업무상 판단 근거를 추적 정보 하나에만 맡겨서는 안 됩니다. OpenAI 트레이싱 문서.

AI 에이전트 오케스트레이션 툴에는 강제할 수 있는 상한이 필요합니다

업무 건 전체 지출, 에이전트 턴 수, 툴 호출 수, 동시 작업 에이전트 수, 위임 깊이, 핸드오프 횟수, 재시도 횟수, 실제 경과 시간에 제한을 둡니다. 실제 실행 기한과 사람의 검토 기한을 분리합니다. 수치는 업무에서 감당할 수 있는 비용과 지연을 기준으로 정해야 합니다. 어디에나 안전하게 적용되는 기본값은 없습니다.

동시 작업을 배분하기 전에 예산을 미리 확보하고, 각 호출이 끝나면 정산합니다. 그렇지 않으면 모든 작업 에이전트가 같은 잔여 예산을 보고 각자 지출할 수 있습니다. 재개한 실행도 동일한 업무 건의 예산에 합산합니다.

Claude Agent SDK는 TypeScript의 maxBudgetUsd, Python의 max_budget_usd를 비롯한 쿼리 지출 제어 기능과 서브에이전트 깊이 및 동시 실행 제어 기능을 제공합니다. 설치한 버전에 적용되는 요구사항은 서브에이전트 문서에서 확인합니다.

집계 범위를 정확히 알아야 합니다. usage 필드에는 서브에이전트 활동이 빠지지만 modelUsage 또는 model_usage에는 포함됩니다. total_cost_usd도 서브에이전트를 포함하지만 클라이언트 측 추정값입니다. 쿼리의 지출 상한은 해당 호출 자체의 지출에 적용되며, 재개한 세션에서 복원한 이전 지출까지 포함하지는 않습니다. 업무 건 단위의 원장을 유지하고 추정값을 공식 사용량 기록과 대조합니다. Claude 비용 추적 문서.

SDK의 예산 설정이 최종 청구액의 정확한 상한을 보장하는 것도 아닙니다. 문서에 제시된 상한 적용 결과는 기준값에 도달하거나 이를 넘긴 상태로 끝날 수 있습니다. 진행 중인 작업을 위한 여유를 남기고, 업무 예산을 모두 쓰기 전에 추가 배분을 멈춥니다.

오케스트레이션 비용은 업무 건 전체로 계산합니다

실패한 작업과 검토까지 포함해, 업무 결과를 완성하는 데 드는 비용을 예산에 반영합니다. 에이전트를 늘리면 독립적인 조사를 더 빨리 마칠 수 있지만 컨텍스트를 반복해서 전달하고, 종합을 위한 호출이 늘고, 수정이 반복될 수도 있습니다. 추가 비용을 감당할 만큼 수용 가능한 결과의 품질이 개선되는지가 도입 타당성을 결정합니다.

월 비용은 다음 모형으로 계산합니다.

프로세스 비용 = 모델 사용료 + 유료 툴 + 워크플로 인프라 + 상태 및 로그 저장 + 사람의 검토 + 운영.

이 비용을 에이전트 실행 횟수가 아니라 승인된 결과 수로 나눕니다. 실패한 건과 폐기한 초안의 비용도 분자에 포함됩니다. 같은 결과 수용 기준과 인건비 가정을 적용해 현재 프로세스의 비용과 비교합니다. 이 입력값 없이는 신뢰할 수 있는 절감률을 산출할 수 없습니다.

인프라 비용의 구체적인 기준으로 Cloudflare가 공개한 요금은 다음과 같습니다.

출처: Workers 요금, Workflows 요금. 계정 최소 요금은 인프라 비용이며, 에이전트 비용을 모두 포함한 가격이 아닙니다. 요청, CPU 시간(프로세서 작업), 모델 호출, 기타 서비스도 별도로 계산해야 합니다. 과금 공지에 따르면 단계와 저장 공간 과금은 빨라도 2026년 8월 10일부터 적용됩니다. 다만 공개 문구만으로는 개별 계정에서 과금이 활성화됐는지 확인할 수 없습니다.

직접 계산하면: 공개 요금 $0.80을 100,000으로 나누면 다른 요금을 제외한 실효 단가는 추가 단계당 $0.000008입니다. 이는 공개 요금의 단위를 환산한 값이며, 특정 워크로드의 비용 추정이나 실제 청구액 측정치가 아닙니다. 공개된 단계 요금.

대기하는 동안 모델을 계속 호출할 필요는 없습니다. Cloudflare는 API 대기, 절전, 유휴 시간에는 CPU 시간이 부과되지 않는다고 설명합니다. 상태 저장과 단계 수에 대한 과금은 별개입니다. 승인자가 응답했는지 에이전트에게 반복해서 묻는 대신, 업무 상태를 영속 저장하고 이벤트를 기다립니다. Workflows 요금.

AI 에이전트 오케스트레이션 프레임워크는 프로세스에 맞춰 고릅니다

멀티 에이전트 시스템을 설계할 때는 프레임워크보다 먼저 조정 책임의 경계를 정합니다. 결과를 종합해야 하면 책임자를 하나로 유지하고, 다음 전문 에이전트가 독립적으로 처리해야 하면 책임을 넘깁니다. 허용된 전환이 중요하면 그래프를 사용하고, 호출이 끝난 뒤에도 업무가 이어져야 하면 내구성 있는 수명주기 제어를 추가합니다.

프레임워크별 선택 기준은 AI 에이전트 프레임워크 비교에서 다룹니다. 명시적인 그래프 상태와 역할별 에이전트 팀 중 어느 쪽을 고를지 고민하는 단계라면 LangGraph와 CrewAI 비교를 참고합니다.

엔지니어링 책임자는 상태 영속성, 실행 권한, 복구 책임을 명확히 해야 합니다. 운영 책임자는 결과 수용 기준, 승인자, 에스컬레이션, 허용 지출을 정해야 합니다. 구매 담당자는 누가 이 통제를 운영하는지, 기록은 어디에 저장되는지, 실패 후 일시 중지된 건을 어떻게 복구하는지 확인해야 합니다.

플랫폼은 인프라 운영을 대신할 수 있습니다. 하지만 조직에서 어떤 환불을 승인된 것으로 볼지, 제안서의 어떤 주장을 근거 있는 것으로 인정할지, 어떤 추가 구매를 허용할지는 대신 정할 수 없습니다.

과장된 기대는 무엇인가요?

에이전트가 많다고 결과가 더 좋아지는 것은 아닙니다. 에이전트를 나눌 때는 서로 다른 출처, 툴, 책임을 부여합니다. 서로 대체 가능한 에이전트에게 반복해서 상호 비평을 시키면 근거는 늘지 않은 채 예산만 소모할 수 있습니다.

그래프를 그렸다는 사실만으로 내구성이 입증되는 것도 아닙니다. 실패 후 무엇이 살아남는지는 저장된 상태, 영속 저장 백엔드, 재실행 동작에 달려 있습니다. 마찬가지로 프롬프트에 "보내기 전에 물어보세요"라고 적는다고 발송 정책이 강제되지는 않습니다. 실행기가 권한을 확인해야 합니다.

마지막으로 모델이 주도하는 계획 수립은 범위가 정해진 작업 안에 둡니다. 조사 담당이 관련 출처 중 다음으로 살펴볼 대상을 고르게 할 수는 있습니다. 비공개 데이터 공개, 비용 승인, 고객 메시지 발송은 애플리케이션의 접근 및 승인 규칙에 따라 결정해야 합니다.

다음 업무일에 바로 시작할 일

프로세스 하나를 골라 꼭 필요한 최소한의 책임 구분부터 추가합니다. 이미 잘 작동하는 에이전트는 유지합니다. 입력, 출력 결과물, 툴, 담당자, 성공 조건, 종료 조건을 적은 뒤 부족한 조사나 작성 역할을 더합니다.

고객에게 영향을 미치는 데이터 변경을 허용하기 전에, 실제 업무를 대표하면서 민감 정보가 없는 입력으로 실패 상황을 점검합니다. 초안을 저장한 뒤 실행을 중단하고, 승인을 중복 전달하고, 제안서를 반려하고, 승인된 결과물을 변경하고, 예산을 소진하고, 외부 쓰기는 이뤄졌지만 응답이 유실된 상황을 재현합니다. 각 건이 기록된 상태에 도달하고 다음 조치가 명확한지 확인합니다.

업무가 전문 담당자 사이를 오가거나, 승인을 기다리거나, 신뢰할 수 있는 복구가 필요하다면 지금 적용합니다. 현재 문제의 원인이 부실한 원천 데이터나 불명확한 수용 기준이라면 에이전트 추가는 미룹니다. 이런 책임 분리가 필요 없고 단일 에이전트 프로세스가 안정적이라면 그대로 유지해도 됩니다.

프로세스 책임자가 자주 묻는 질문

에이전트 하나가 이미 잘 작동해도 AI 에이전트 오케스트레이션 플랫폼이 필요한가요?

기존 애플리케이션에 없는 조정 기능이나 운영 기능이 필요할 때만 도입합니다. 우선 부족한 책임이 무엇인지 정합니다. 전문 담당자에게 책임을 넘기는 기능인지, 진행 상황 저장인지, 늦게 도착하는 승인 처리인지, 복구인지 구체화합니다. 이 요구사항에 따라 라이브러리, 워크플로 서비스, 소량의 애플리케이션 코드 중 무엇을 추가할지 결정합니다.

한 프로세스에서 이 패턴들을 함께 사용할 수 있나요?

가능합니다. 내구성 있는 워크플로가 업무 건을 관리하는 동안 그래프는 검토 경로를 제어하고 리드 에이전트는 조사를 배분할 수 있습니다. 각 계층에 명확한 책임을 부여하고, 같은 작업에 대한 재시도 정책이 겹치지 않게 합니다.

초안을 승인하면 유료로 한 번 더 시도하는 것도 승인한 셈인가요?

승인 범위에 그 지출이 명시적으로 포함된 경우에만 그렇습니다. 결과물 사용 승인과 추가 시도 구매 권한은 별도로 기록해야 합니다. 초안이 바뀌었다면 중요한 후속 작업을 실행하기 전에 다시 검토해야 합니다.

승인자가 끝내 응답하지 않으면 어떻게 해야 하나요?

정해진 정책에 따라 대기 중인 결정의 기한을 만료시키고, 담당 책임자에게 알린 뒤 해당 건을 보류하거나 종료합니다. 나중에 검토할 수 있도록 충분한 맥락을 저장합니다. 응답이 없다는 이유로 자동 승인돼서는 안 됩니다.

AI로 업무 워크플로를 구축하고 운영하는 실무 가이드는 뉴스레터 구독으로 받아볼 수 있습니다.