오라클이 에이전트 오케스트레이션을 ERP 안에 넣었다, 그리고 그것은 거버넌스의 계산법을 바꾼다

오라클이 Fusion Claw를 출시했다. 오라클은 이를 주요 ERP 플랫폼 안에 직접 내장된 최초의 네이티브 AI 에이전트 오케스트레이션 계층이라고 설명한다. 이 제안은 범위가 좁고, 그래서 더 시사적이다. 별도의 콘솔에서 에이전트를 실행하면서 회사 정책을 준수하기를 바라는 대신, Fusion Claw는 조직이 표준 운영 절차, 리스크 임계값, 의사결정 권한을 비즈니스 로직이 이미 자리한 Fusion Applications 안에서 정의할 수 있게 해준다.

바로 그 위치가 핵심이다. 지난 2년간 에이전트에 관한 논의는 역량, 즉 모델이 그 작업을 완수할 수 있는가에 관한 것이었다. 이번 달에 나온 주목할 만한 출시들은 다른 질문에 답한다. 기업이 에이전트가 작동하기 시작한 뒤에도 계속 지켜볼 수 있는가 하는 질문이다.

모두가 계속 언급하는 격차

이 변화를 설명하는 수치들은 이제 익숙하다. 대기업의 약 85%가 AI 에이전트를 실험하고 있지만, 에이전트 기술을 실제 운영 환경으로 옮긴 곳은 약 5%에 불과하며, 파일럿이 확장되는 비율은 대략 11~14%다. 가트너는 2027년까지 에이전트형 AI 프로젝트의 40% 이상이 취소될 것으로 전망하며, 그 원인을 모델 품질이 아니라 통합과 조정 문제로 돌린다. 반대로 IDC는 2028년까지 전 세계적으로 약 13억 개의 AI 에이전트가 사용될 것으로 예상한다.

이 둘을 함께 놓으면 병목이 이동한다. 모델은 많은 작업에 충분히 좋다. 빠진 것은 배관이다. 아이덴티티, 권한, 감사 추적, 그리고 스스로 행동하는 소프트웨어에 대응하도록 설계된 적 없는 시스템들 사이의 조정이다.

제품 카테고리로 출시된 거버넌스

오라클은 놀랄 만큼 많은 에이전트 거버넌스 인프라가 쏟아져 나온 한 달의 참가자 중 하나다. OpenAI는 Presence를 출시했다. 이는 정의된 업무 범위, 제한된 지식 접근, 승인된 행동을 갖춘 음성 및 채팅 에이전트를 배포하기 위한 운영 계층으로, 청구 지원, 보험 청구, 직원 IT 요청을 겨냥한다. Classie Supervise는 이와 함께 등장해 이미 운영 중인 에이전트에 대한 실시간 추적과 회계 처리를 기업에 제공한다.

Salesforce와 AWS는 Agentforce 360 for AWS를 발표했다. 이 공동 플랫폼의 Atlas Reasoning Engine은 Amazon Bedrock을 통해 Anthropic의 Claude 모델에서 실행되며, 특히 모든 에이전트 의사결정에 대해 변경 불가능한 감사 추적을 생성한다. CrowdStrike가 얼리 어답터로 이름을 올렸는데, 보안과 함께 조달의 단순함을 이유로 들었다. 이는 하나를 사는 것이 다섯 개를 조립하는 것보다 낫다는 것을 기업다운 방식으로 표현한 것이다.

다른 곳에서는 OneTrust가 AI Control Plane과 Governance Command Center로 플랫폼을 확장했으며, ChatGPT, Claude, Copilot, Glean과의 통합을 제공한다. Red Hat은 에이전트가 행동을 실행할 수 있게 되면 모델 수준의 안전장치로는 불충분하다고 주장하며, 아이덴티티, 런타임, 네트워킹, 인프라 전반에 걸친 심층 방어를 요구해 왔다. Nvidia는 100개 이상의 파트너와 함께 구축한 Open Agent Safety Platform을 선보였는데, 이는 통제를 벗어난 에이전트를 밀리초 단위로 격리하도록 설계되었다.

이 제품들은 각기 다른 고도에서 같은 문제를 공략한다. 오라클의 베팅은 감사 추적이 병행 로그가 아니라 트랜잭션 자체여야 한다는 것이다. 에이전트의 승인된 행동이 ERP 내부의 규칙으로 정의된다면, 에이전트가 내리는 모든 결정은 이미 재무 및 컴플라이언스 팀이 다른 모든 업무에 사용하는 통제, 권한, 보고 체계의 적용을 받게 된다.

ERP가 자연스러운 거처인 이유

거버넌스 비중이 큰 영역이 프로덕션 에이전트의 첫 거처로 적합한 이유는 대안이 더 나쁘기 때문이다. 재무 팀은 기록 시스템 밖에 존재하고, 설명할 수 없는 행동을 하며, 다른 도구에 로그를 남기는 에이전트에게 인보이스 처리를 맡기는 것을 정당화할 수 없다. 오케스트레이션을 ERP에 내장하면 에이전트는 나머지 워크플로가 이미 갖고 있는 역할 기반 접근 제어, 직무 분리, 감사 태세를 그대로 물려받는다.

오라클의 행보가 경쟁사에 압박이 되는 이유도 여기에 있다. 오케스트레이션 계층이 핵심 플랫폼의 기능이 된다면, 독립형 에이전트 게이트웨이는 사고, 보호하고, 조정해야 할 추가 구성 요소처럼 보인다. 구매자들은 하나 또는 두 개의 내장 계층으로 표준화하는 것이 또 하나의 외부 통제 평면을 추가하는 것보다 낫다는 결론에 이를 수 있다.

회의적인 시각

거버넌스라는 프레이밍은 타당하며, 결코 출시되지 않은 파일럿에 데인 구매자들이 많은 시장에서 좋은 마케팅이기도 하다. 어떤 평가에서든 염두에 둘 만한 몇 가지 주의점이 있다. 감사 추적은 누군가 그것을 읽을 때만 도움이 되며, 에이전트의 결정에 대한 변경 불가능한 로그는 애초에 잘못된 결정을 막는 통제와 같지 않다. 한 벤더의 플랫폼에 오케스트레이션을 내장하는 것은 새로운 종류의 종속을 낳기도 한다. 에이전트의 이력과 정책이 이제 애플리케이션 스위트 안에 존재하기 때문이다. 그리고 취소 통계는 양방향으로 작용한다. 에이전트 배포를 쉽게 만들어 주는 플랫폼이 조정 문제를 저절로 해결하지는 못한다. 그 문제는 소프트웨어만큼이나 프로세스 소유권에 달려 있다.

이것을 어떻게 활용할 것인가

이번 달 출시들에서 나오는 실무적 조언은 일관된다. 인보이스 처리나 접근 권한 검토처럼 좁고 가치가 높은 프로세스 하나로 시작하고, 엄격한 로깅과 승인 체계를 갖춘 기존 시스템 안에 단일 에이전트를 배치하라. 핵심 벤더들이 Fusion Claw에 어떻게 대응하는지 지켜보라. 그들이 자체 오케스트레이션 계층을 내놓는다면, 그중 하나나 둘로 표준화하는 것이 또 하나의 외부 게이트웨이를 추가하는 것보다 더 중요해질 가능성이 크다.

더 큰 변화는 발표들이 서로 비슷하게 들리기 때문에 놓치기 쉽다. 에이전트 역량은 더 이상 헤드라인이 아니다. 이제 헤드라인은 에이전트에게 업무와 예산, 그리고 목줄을 줄 수 있는지, 그리고 기업이 사후에 그것이 정확히 무엇을 했는지 입증할 수 있는지다.

통합의 문제

개별 출시에서 한 걸음 물러나면 구조적인 질문이 떠오른다. 모든 주요 플랫폼이 자체 오케스트레이션 계층을 내놓는다면, 구매자들은 결국 서로 겹치는 여러 통제 평면을 갖게 된다. 각각 자체 정책 언어, 자체 감사 로그, 에이전트가 무엇을 할 수 있는지 설명하는 자체 방식을 갖는다. 이는 거버넌스가 제공해야 하는 것과 정반대다. 표준 기관과 오픈소스 프로젝트들은 이미 이식 가능한 에이전트 아이덴티티와 권한 부여를 연구하고 있지만, 상업적 유인은 반대 방향으로 흐른다. 독점적 통제 평면은 떠나지 않을 강력한 이유이기 때문이다.

오라클이 계층을 ERP에 내장하기로 한 결정은 이를 구체화한다. Fusion Applications를 운영하는 기업은 내장 오케스트레이션을 사용할 분명한 이유가 있고, 그와 조정되어야 할 두 번째 외부 계층을 불신할 똑같이 분명한 이유가 있다. 벤더들은 이를 안다. 문제는 고객이 스위트마다 하나의 통제 평면을 두는 파편화된 거버넌스 스택을 받아들일지, 아니면 그 모두를 아우르며 감사할 수 있는 무언가를 요구할지다.

가장 유력한 단기적 답은 하이브리드다. ERP와 CRM 같은 핵심 시스템은 이미 관리하고 있는 프로세스에 대한 오케스트레이션을 소유하게 될 것이다. 감사 추적은 트랜잭션 옆에 있어야 하기 때문이다. 여러 시스템에 걸친 에이전트를 포함한 나머지 모든 것은 이들 모두와 대화하려는 독립형 계층에 의존하게 될 것이다. 플랫폼을 평가하는 팀은 두 가지를 모두 염두에 두고, 시장이 통합될 경우 정책 정의를 다시 표현할 수 있도록 설계해야 한다.

판매자들이 말하지 않는 것

두 가지 주장은 검증이 필요하다. 첫째는 감사 추적이 책임성과 같다는 것이다. 에이전트가 내린 모든 결정을 기록하는 로그는 사고 이후에 가치가 있으며, 사고를 막는 통제와 같지 않다. 변경 불가능한 기록과 예방적 가드레일은 서로 다른 제품인데, 이번 출시들은 이 둘을 흐리는 경향이 있다. 둘째는 플랫폼이 거버넌스를 출시하면 그것이 해결된 문제라는 것이다. 이번 달에 언급된 실패 사례 대부분은 잘못 구성된 권한, 불분명한 소유권, 그리고 어떤 팀도 에이전트가 따를 수 있을 만큼 정확히 설명하지 못한 프로세스와 관련되어 있었다. 소프트웨어는 정책을 강제할 수 있다. 하지만 비즈니스가 실제로 원하는 정책이 무엇인지는 결정하지 못한다.

실험 단계를 지난 팀에게 유용한 행동은 구매 전에 답을 적어 두는 것이다. 에이전트가 어떤 프로세스를 건드릴 수 있는가, 그 범위 안에서 할 수 있는 최악의 행동은 무엇인가, 그런 일이 벌어지면 누구에게 알림이 가는가, 에이전트가 접근 권한을 요청할 때 어떻게 식별되는가. 현재의 조언대로 엄격한 로깅과 승인을 갖춘 기존 시스템 안에 단일 에이전트를 배포하면 이 네 가지 답을 한 번에 시험하게 된다. 플랫폼은 그 시험을 더 쉽게 실행하도록 해 줄 것이다. 대신 실행해 주지는 않는다.