"우리도 AI 도입해 보자"는 과제를 받은 기획자(9)

오케스트레이션 워크 플로우

by 피넛

Oct 11. 2025

지난 화에서는 AI챗봇과 AI에이전트에 대해서 알아보았다.

AI에이전트는 단순히 답변을 해주는 것을 뛰어넘어 고객의 의도를 파악해 행동하는 AI를 의미한다.

고객의 질문에서 의도를 파악하고 → 무엇을 해야 할지 계획하고 → 실행한 후에 → 검증까지 한다.

이러한 과정을 '오케스트레이션 워크플로우(Orchestration Workflow)'라고 부른다.

AI는 인간의 행동양식을 모방한다고 했다. 인간에게서 학습된 것이기 때문이다.

잘 살펴보자.. 이해하고 → 계획하고 → 실행하고 → 검증한다.. 는 과정이 어디서 많이 본 것 같지 않은가..?

기획자들이라면 한 번은 들어봤을 것이다.

바로, PDCA. Plan → Do → Check → Act

일을 계획하고(Plan), 실행하고(Do), 결과를 점검하고(Check), 개선한다(Act)

이과정을 AI가 스스로 처리한다. 그것이 '오케스트레이션 워크플로우'다.

사람이 해야 할 일을 알아서 척척 스스로 처리한다고..?

살짝 기대되는 한편, 지금까지 AI가 모든 것을 알아서 해줄 것이라 생각했지만 의외로 사람이 해야 할 일이 많다는 것도 알고 있기 때문에 조심스럽게 더 파봐야겠다는 생각을 한다.

조금 더 구체적으로 오케스트레이션 워크플로우를 구축하기 위해, 고객이 원하는 바를 행동시키기 위해 해야 할 일들을 살펴보겠다.

오케스트레이션 워크플로우를 실행 중인 AI봇

'오케스트레이션 워크플로우'라는 이름에 압도당하지 말자.

뭔가 새로운 개념인 것 같지만 사실 우리는 이 플로우를 만들기 위한 대부분의 것들을 알고 있다.

AI 챗봇을 만들 때 배웠던 개념들을 조금 더 연결만 하고 AI가 자동화할 수 있게 보완만 해주면 된다.

새로운 개념은 크게 4가지다.

1. Planner Layer

2. Execution Layer

3. Verification Layer

4. Coordinator Layer

Layer라는 것은 각 과정을 구분하기 위해 계층을 나눴다는 의미로 사용했다.

실제로 현업에서도 코드나 API호출 흐름을 모듈화 해서 관리하기 위해 이런 식으로 계층을 나눠두기도 한다.

조금 추상적인 개념이기도 하지만, 이렇게 그룹핑해서 보는구나.. 정도로 이해하자.

이제 하나씩 각 계층을 알아보겠다.

1. Planner Layer

고객의 요청을 이해하고, 문제를 해결하기 위해 무엇을 어떤 순서로 계획을 하는 단계이다.

기획자는 이 단계에서 고객들이 어떤 요청을 할 수 있는지, 플래너가 달성해야 할 목표는 무엇인지, 각 단계별로 어떤 API 또는 MCP 툴을 호출할지, 실패했을 때 어떻게 재처리할지에 대해 정의를 해줘야 한다.

챗봇을 설계할 때 대부분 해둔 부분이다! 고객의 요청(배송문의, 교환문의, 환불문의... 같은 거 했죠?)에 따라 어떤 문서 또는 API를 호출할지 RAG와 펑션콜링을 배웠고 어떻게 답변할지도 다 정의한 게 있다.

이것을 순서대로 이렇게 정리해 주면 된다.

문의 내용: 불량상품 반품 접수
목표: 불량 원인을 파악하고 반품을 접수한다.
처리 순서:
1. 고객 정보를 확인한다
2. 문의한 주문을 조회한다
3. 반품 정책을 조회한다
4. 반품을 접수한다

처리 순서별로 어떤 정보가 필요한지, 답변은 어떻게 나갈지, 주문정보가 확인되지 않거나 반품 불가할 때에는 어떻게 처리하면 될지 예외 처리에 대한 정의도 해주면 좋다.

실패 처리:
고객 정보 조회 → 고객 ID 없음 → 재입력 요청, 최대 1회
주문 정보 조회 → 주문내역 없음 → 상담원 연결
반품 정책 확인 → 반품 불가 → 고객 안내, 종료
반품 접수 → API 오류 → 재시도 1회 후 실패 시 상담원 연결

이미 다 정의해 둔 게 있어서 어렵지 않다.

문제를 정의하고, 어떻게 처리할지는 우리가 현업에서 계속해오던 일이다.

여기까지는 쉬운(?)것 같다.

다음으로 넘어가자.

2. Execution Layer

플래너가 세운 계획을 실제 행동으로 수행하는 단계이다.

위의 플래너가 처리해야 할 항목들을 정리했다.

1. 고객 정보를 확인한다
2. 문의한 주문을 조회한다
3. 반품 정책을 조회한다
4. 반품을 접수한다

실행 단계에서는 구체적으로 위의 할 일들을 어떻게 수행해야 할지를 정의하면 된다.

이런 식으로.

1. 고객 정보를 확인한다 (get_customer_info)
2. 문의한 주문을 조회한다 (get_recent_orders)
3. 반품 정책을 조회한다 (check_return_policy)
4. 반품을 접수한다 (create_return_request)

각 단계별 실패 처리도 이미 정의해 둔 게 있으므로 사실상 플래너 레이어에서 어떤 툴(MCP 툴에서 RAG문서와 API가 다 포함되어 있다고 하겠다)을 호출할지 작성해 두면 그것을 실행만 하면 된다.

이 단계에서는 기존의 서비스 로직을 구현하는 기획자와 백엔드 개발자들과 소통이 많이 필요하다.

어떤 서비스에서 어떤 정책서가 있는지 어떤 API의 어떤 항목을 호출하면 되는지 알아야 하기 때문이다.

조금 규모가 큰 회사라면 각 도메인 영역별로 조직이 나눠져 있을 것이라 이리저리 사람들을 모아 정책을 확인하고 API 명세서를 확인해야 한다. 혹은 MCP 툴을 관리하는 조직이 있다면 감사할 일이다.

각 담당자들과 이야기를 많이 나누고 협조를 받아야 한다.

3. Verification Layer

정상적으로 수행되었는지 확인하는 단계이다.

위의 플래너 단계에서 실패 처리를 어떻게 해야 할지 이미 정의했기 때문에 이에 대해서 검증 레이어에서 자동으로 검증을 하게 될 것이다.

여기서는 AI가 자동으로 검증을 해주기 때문에 에러로그를 심어 두고 같은 문제가 반복되지 않는지, 계획대로 AI가 실행을 잘하고 있는지 실시간 또는 주기적으로 모니터링을 해주면 좋을 것 같다.

4. Coordinator Layer

AI 에이전트 전체 워크플로우를 조율하고 통제하는 단계이다.

기본적으로 플래너 레이어에서 무엇을 해야 할지 다 정의는 했지만, 여기서는 단편적으로 이런 질문에는 이렇게 처리하는 것에 대한 가이드만 정의되었다(단일턴). 플래너 레이어는 각 질문이나 단일 요청에 대해서 무엇을 할지 계획을 세우지만, 전체 대화 흐름이나 멀티턴 연결은 고려하지 않는다.

그러나 현실은? 당연하지만 질문과 답변이 계속 이어진다. 코디네이터 레이어는 이 대화를 이어가는 역할 전반을 통제한다. 멀티턴 대화에서 고객이 질문을 이어가는 경우, 이전 단계에서 어떤 상태였고, 어떤 계획이 진행 중이었는지 저장하고 다음 단계를 처리하도록 그 흐름을 연결하는 역할이다.