실제 업무에서 성과를 내려면 모델을 둘러싼 워크플로우와 오케스트레이션이 함께 설계되어야 합니다.
완전 자율 AI에만 집중할 필요는 없습니다
완전히 자율적으로 작동하는 AI에 관심이 쏠리면서, 기업이 이미 보유한 업무 시스템과 프로세스의 가치를 놓치는 경우가 많습니다. 흔히 AI 에이전트라고 하면 상황을 파악하고, 무엇을 해야 할지 판단한 뒤, 전체 프로세스를 독립적으로 실행하는 디지털 워커를 떠올립니다. 물론 이런 방식이 유용한 경우도 있습니다. 하지만 에이전틱 AI가 반드시 이런 방식으로만 구현되어야 하는 것은 아니며, 많은 엔터프라이즈 프로세스에 가장 적합한 접근이라고 보기도 어렵습니다.
AI 에이전트가 비즈니스 결과를 만들기 위한 모든 업무를 직접 맡을 필요는 없습니다. 전체 프로세스는 사전에 설계된 워크플로우가 담당하고, 에이전트는 그 안에서 필요한 역할만 수행하면 됩니다. 예를 들어 비정형 문서를 해석하고, 모호한 상황을 평가하며, 미리 정의된 여러 경로 중 적절한 선택지를 판단할 수 있습니다.
Massimo Pezzini는 「To Succeed With Agentic AI, You Need an Orchestration Strategy」에서 이 차이를 설명합니다. 에이전트는 불확실한 상황에서 스스로 판단하며 오케스트레이션을 수행할 수도 있지만, 구조화된 비즈니스 프로세스 안에서 하나의 작업 단위로 참여할 수도 있습니다.
기업 AI에서는 후자의 방식에 더 주목할 필요가 있습니다. 효과적인 엔터프라이즈 AI 아키텍처는 에이전트가 모든 일을 처리하도록 설계하지 않습니다. 대신 에이전트가 필요한 지점과 워크플로우가 처리해야 할 지점을 명확히 나눕니다.
능동적인 AI는 모델만으로 만들어지지 않습니다
시스템이 능동적으로 작동한다고 해서 모든 판단이 AI에서 시작되어야 하는 것은 아닙니다. 핵심은 전체 프로세스를 어떻게 오케스트레이션하느냐에 있습니다. 이벤트 감지, 정보 수집, 판단, 실행이 적절히 나뉘어 작동하면 사용자는 충분히 능동적인 시스템을 경험할 수 있습니다.
예를 들어 일반적인 워카토 레시피는 특정 비즈니스 이벤트를 감지합니다. 이벤트가 발생하면 레시피가 관련 정보를 수집하고, AI 에이전트에게 다음 조치를 판단하도록 요청합니다. 에이전트가 판단을 내리면, 레시피는 관련 엔터프라이즈 시스템 전반에서 필요한 작업을 실행합니다. 이벤트 감지는 정해진 규칙에 따라 이루어지고, 판단에는 AI 추론이 활용되며, 실행은 다시 자동화된 워크플로우가 처리합니다.
이런 구조는 기능을 줄인 방식이 아니라, 역할을 더 명확하게 나눈 방식입니다. 많은 경우 이러한 역할 분담이 더 안정적이고 실용적입니다.
Genie 워크플로우도 같은 방식으로 작동합니다. 정해진 도구와 스킬을 활용해 정보를 수집하고 사전 처리하며, 반복적인 사례를 걸러내고 중요한 항목을 식별합니다. 판단, 책임, 정책 검토, 예외 처리가 필요한 경우에만 담당자가 확인하도록 설계할 수도 있습니다. 이후 Genie는 사용자에게 어떤 맥락과 추천 사항을 보여줄지 결정합니다. 사용자는 먼저 움직이는 시스템을 경험하지만, 모든 단계가 생성형 AI로 처리되는 것은 아닙니다.
능동적으로 작동하는 경험은 개별 AI 기능이 아니라 시스템 전체에서 만들어집니다. 모든 구성 요소가 지능적으로 보일 필요는 없습니다.
에이전트에게 필요한 정보를 처음부터 직접 찾게 만들지 마세요
오래되었거나 불완전한 정보를 바탕으로 작동하는 에이전트는 겉보기에는 그럴듯한 답을 내놓을 수 있지만, 실제로는 잘못된 판단을 할 수 있습니다. 에이전트에 대해 이야기할 때 필요한 정보가 필요한 순간에 자연스럽게 준비되어 있을 것처럼 가정하는 경우가 많습니다. 하지만 실제 업무 환경에서는 그렇지 않습니다.
에이전트가 고객, 공급업체, 인보이스, 거래, 직원에 대해 판단하려면 먼저 관련 데이터가 CRM, ERP 같은 실제 업무 시스템에서 조회되어야 합니다. 이 데이터는 동기화, 정합성 확인, 변환, 필터링 과정을 거쳐 에이전트가 사용할 수 있는 형태로 정리되어야 합니다.
예를 들어 신뢰할 수 있는 고객 정보를 제공하려면 관련 운영 데이터를 Salesforce로 동기화해야 할 수 있습니다. ERP에서 현재 상태를 조회하고, 이를 CRM 데이터와 매칭하고, 정책 저장소를 확인한 뒤, 이미 승인 절차가 진행 중인지 판단해야 할 수도 있습니다. 또한 현재 업무에 필요한 정보만 선별해 에이전트가 불필요하게 많은 정보를 받지 않도록 해야 합니다.
에이전트가 제대로 판단하려면, 모델이 호출되기 전에 필요한 데이터가 정리되고 업무 맥락이 갖춰져 있어야 합니다. Massimo의 오케스트레이션 프레임워크도 이 점을 분명히 보여줍니다. 엔터프라이즈 AI에는 최신 정보, 이벤트 전달, 재사용 가능한 엔터프라이즈 기능, 그리고 에이전트를 사전에 설계된 프로세스 안에 연결할 수 있는 구조가 필요합니다. 이러한 맥락 제공 아키텍처가 제대로 설계되어 있지 않다면, 에이전트의 추론 능력만으로는 그 한계를 보완할 수 없습니다.
이미 정해진 프로세스를 모델이 다시 판단하게 만들지 마세요
에이전트의 추론과 사전에 설계된 실행 흐름을 어디서 나눌지는 안정성뿐 아니라 비용에도 영향을 줍니다. 모델 가격이 낮아져도 불필요한 추론까지 경제적으로 바뀌는 것은 아닙니다. 반복적인 단계는 워카토 레시피가 더 안정적이고 낮은 비용으로 처리할 수 있습니다. 따라서 이런 업무까지 매번 모델이 다시 판단하도록 만들 필요는 없습니다.
「저렴해진 토큰, 더 커진 청구서: AI 에이전트 비용이 계속 늘어나는 이유」에서도 AI 에이전트의 경제성은 모델 가격뿐 아니라 실행 아키텍처에 의해 결정된다고 설명합니다. 에이전트가 수행하는 모든 시스템 작업을 각각 별도의 툴로 노출하면, 모델은 매 단계마다 이미 정해진 방식을 다시 추론하느라 토큰을 낭비하게 됩니다.
같은 문제는 엔터프라이즈 아키텍처에서도 반복될 수 있습니다. 세분화된 작업을 모든 에이전트에 그대로 노출하면 포인트 투 포인트 연동이 다시 만들어질 수 있습니다. 더 큰 문제는 기업이 이미 업무 프로세스 안에 담아둔 조율 로직까지 모델이 매번 다시 구성하게 된다는 점입니다. 그 결과 아키텍처는 더 파편화되고, 불필요한 추론, 지연 시간 증가, 과도한 컨텍스트, 더 높은 비용이 발생합니다.
이런 설계에서는 모델이 실행될 때마다 이미 정해진 비즈니스 프로세스를 다시 구성해야 할 수 있습니다. 같은 정보를 반복해서 불러오고, 업무에 필요한 것보다 더 많은 컨텍스트를 유지하며, 반복적인 애플리케이션 호출을 조율하는 데 추론 역량을 사용하게 됩니다. 그만큼 불일치나 실패가 발생할 가능성도 커집니다.
더 중요한 아키텍처 질문은 단순히 모델 호출 한 번의 비용을 어떻게 줄일 것인가가 아닙니다.
이 단계에서 정말 모델을 다시 호출해야 할까요?
모델은 판단이 실제 결과를 개선하는 지점에 사용해야 합니다. 반복적인 조율은 모델이 아니라 워크플로우가 처리하는 편이 더 적절합니다.
AI는 판단이 필요한 순간에 사용해야 합니다
모델은 해석이나 판단이 실제로 필요한 단계에 사용해야 합니다. 기업이 이미 실행 방법을 알고 있는 부분까지 모델이 매번 다시 구성할 필요는 없습니다.
그 경계는 프로세스에 따라 달라집니다. AI는 이례적인 상황을 평가하거나 예외를 분류하는 것처럼, 불확실성이 큰 업무에 가장 적합합니다. 방향이 정해지면 사전에 설계된 오케스트레이션이 이어받아 작동합니다. 이미 검증된 실행 워크플로우를 적용해 원하는 결과를 만들어내는 방식입니다. 이후 프로세스 중간에 다시 해석이나 판단이 필요한 상황이 생기면, 그때 모델을 다시 호출하면 됩니다.
전체 워크플로우를 “AI” 또는 “비AI”로 나눌 필요는 없습니다. 각 단계의 성격에 따라 AI가 맡을 부분과 워크플로우가 실행할 부분을 나누면 됩니다.
이는 「저렴해진 토큰, 더 커진 청구서: AI 에이전트 비용이 계속 늘어나는 이유」에서 설명한 원칙과도 같습니다. 모델은 의도를 해석하고, 모호함을 해결하며, 그 능력이 결과를 개선하는 지점에서 사용해야 합니다. 반면 정해진 순서, 비즈니스 규칙, 승인, 재시도, 복구 같은 업무는 모델이 매번 다시 추론하도록 만들 필요가 없습니다.
이 원칙은 에이전트가 더 넓은 오케스트레이션을 담당하는 경우에도 적용됩니다. 덜 구조화된 업무에서는 Genie가 어떤 전문 기능을 호출할지 동적으로 판단할 수 있습니다. 에이전트의 판단이 가치를 더하는 영역은 에이전트가 맡고, 이미 정해진 비즈니스 작업은 원시 애플리케이션 호출을 조합하는 방식이 아니라 거버넌스가 적용된 기능을 통해 실행하는 것이 좋습니다.
에이전트는 목표를 해석할 수 있지만, 그 목표를 달성하기 위한 모든 기술적 단계를 하나하나 추론할 필요는 없습니다. 이렇게 설계하면 전체 프로세스가 더 예측 가능해지고, 거버넌스 적용, 재사용, 성과 측정도 쉬워집니다.
좋은 AI 워크플로우일수록 AI가 필요한 곳에만 쓰입니다
엔터프라이즈 AI는 프로세스의 얼마나 많은 부분을 모델이 통제하는지로 평가해서는 안 됩니다. 중요한 것은 판단, 안정성, 비용, 속도, 책임성을 적절히 조합해 원하는 결과에 도달하는 것입니다. 때로는 AI를 덜 사용하는 것이 더 지능적인 결과로 이어집니다.
Genie는 더 큰 업무 결과를 오케스트레이션하면서, 범위가 명확한 업무를 재사용 가능한 전문 기능으로 작동하는 다른 Genie에 위임할 수 있습니다. 이미 정해진 프로세스를 실행하는 레시피를 호출할 수도 있습니다. 워크플로우는 이벤트를 감지하고, 컨텍스트를 구성한 뒤, 에이전트에게 필요한 판단을 요청하고 실행을 이어갑니다. 이때 에이전트가 모든 애플리케이션 호출을 직접 조율할 필요는 없습니다.
이러한 방식들은 서로 분리된 접근이 아닙니다. 하나의 엔터프라이즈 프로세스 안에서 함께 작동할 수 있습니다. AI 추론, 사전에 설계된 자동화, 데이터 오케스트레이션, 애플리케이션 연동, 전문 Genie, 사람의 승인은 모두 같은 프로세스를 구성하는 요소입니다.
워카토를 활용하면 “AI 워크플로우가 필요한가, 일반 워크플로우가 필요한가”라는 구분에 갇히지 않아도 됩니다. 같은 프로세스 안에서도 AI가 가치를 더하는 지점에는 AI를 사용하고, 그 외의 영역에는 기존 오케스트레이션을 적용하면 됩니다.
앞서 살펴본 것처럼, 에이전트가 곧 아키텍처는 아닙니다. 에이전트가 전체 워크플로우를 모두 담당할 필요도 없습니다. 에이전트는 비즈니스 결과를 만들기 위해 설계된 더 큰 시스템 안에서 하나의 역할을 수행합니다.
하지만 에이전트가 실제로 행동을 취할 수 있게 되면, 반드시 확인해야 할 질문들이 생깁니다. 이 에이전트는 누구의 권한으로 행동하는가? 무엇을 할 수 있는가? 기업은 실제로 어떤 일이 일어났는지 증명할 수 있는가?
이 질문들은 단순히 인상적인 AI 경험과, 실제로 책임 있게 운영할 수 있는 엔터프라이즈 시스템을 구분하는 기준이 됩니다.
🎬 YouTube채널 바로가기
Youtube 채널에서도 워카토코리아 관련 다양한 콘텐츠를 만나보실 수 있습니다.