기업 AI 팀은 자사의 에이전트 시스템이 어디서 실행될지에 대해 전략적 결정을 내리고 있는 것으로 보인다. 점점 더 대형 모델 제공업체의 플랫폼 위에서다. 하지만 VentureBeat Pulse Research의 새로운 설문 묶음은 더 어려운 문제는 이제 플랫폼 선택이 아니라고 주장한다. 실제 에이전트 배포, 통제, 운영 규율을 그 야망에 맞게 끌어올리는 일이다.

VentureBeat AI가 공개한 2026년 6월의 4개 설문 파동에 걸쳐, 응답자들은 Anthropic, OpenAI, Microsoft, Google 같은 회사들의 provider-native 스택을 중심으로 시장이 표준화되고 있지만, 자율 소프트웨어를 실제 운영에서 유용하게 만드는 기반에는 여전히 어려움을 겪고 있다고 설명했다. 이러한 약점은 오케스트레이션, 검색, 평가, 보안 전반에서 드러난다.

가장 선명한 결과는 오케스트레이션 설문에서 나왔다. 기업의 71%는 배포된 “에이전트”의 4분의 1 이하만이 단순한 챗봇 래퍼가 아니라 실제로는 여러 단계를 거치는 오케스트레이션 워크플로라고 답했다. 이는 같은 응답자들이 오케스트레이션 성공을 챗봇 UX가 아니라 신뢰할 수 있는 작업 완료와 다단계 워크플로 관리로 판단한다고 밝힌 것과 맞물린다. 다시 말해, 많은 팀이 현재 운영 중인 대부분의 것이 아직 진정한 의미의 에이전트라고 보기 어려운데도 에이전트형 시스템을 구매하고 계획하고 있는 셈이다.

네 개의 설문을 종합하면 광범위한 기업 패턴이 드러난다. 팀들은 Anthropic, OpenAI, Microsoft, Google 같은 프런티어 모델 플랫폼에 딸려오는 통합 제어와 인프라를 받아들이는 데는 익숙하지만, 아이덴티티, 컨텍스트 거버넌스, 현실 세계 평가, 비용 집행에서는 훨씬 덜 성숙하다. 구축자와 구매자에게 주는 시사점은 분명하다. 다음 경쟁 우위는 또 다른 오케스트레이션 프레임워크보다, 에이전트가 신뢰할 수 있고 측정 가능하며 통제 가능하다는 것을 증명하는 데서 나올 수 있다.

네 개의 계층을 관통하는 하나의 이야기

오케스트레이션 보고서는 100명 이상의 직원을 둔 101개 기업을 대상으로 했으며, Anthropic의 Claude가 응답자의 40%에게 가장 중요한 오케스트레이션 플랫폼이었고, Microsoft가 18%, OpenAI가 13%로 뒤를 이었다. VentureBeat는 이 수치들이 시장점유율이 아니며, 자가 선택된 표본의 방향성 스냅샷으로 읽어야지 지출 가중 산업 조사로 봐서는 안 된다고 명확히 경고했다.

그러한 단서를 감안해도, 이 패턴은 나머지 세 설문과도 일치한다. 검색 및 컨텍스트 인프라에서는 OpenAI 파일 검색과 Google Vertex AI Search가 특화 벡터 데이터베이스보다 실제 운영 사용을 이끌었다. 보안에서는 OpenAI의 가드레일과 Google, Microsoft의 통제가 현재 배포를 지배했다. 평가에서는 OpenAI의 네이티브 evals와 traces가 현장을 선도했고, 전용 평가 도구를 전혀 사용하지 않는다고 답한 응답자와 비슷한 수준이었다.

이 일관성은 중요하다. 기업 팀이 이미 사용하는 기반 모델 및 클라우드 스택에 가장 가까운 도구를 기본값으로 선택하고 있음을 시사한다. VentureBeat는 이를 오케스트레이션에서의 “모델 중력”과 다른 계층에서의 provider-native 기본값이라고 표현했다. 실무적 해석은 더 단순하다. 구매자는 적어도 첫 번째 생산 시스템에서는 더 적은 이동 요소, 더 빠른 배포, 더 강한 통합을 원한다.

하지만 같은 팀들이 장기적인 깊은 충성도를 보이는 것은 아니다. 설문에 따르면 68%는 1년 안에 오케스트레이션 플랫폼을 도입, 추가 또는 교체할 계획이었고, 57%는 검색 제공업체를 바꾸거나 추가할 계획이었으며, 64%는 평가 도구 변경을 예상했고, 59%는 에이전트 보안 도구 변경을 계획했다. 표준화는 진행 중이지만, 스택은 아직 유동적이다.

챗봇이라는 꼬리표가 소프트웨어 현실을 앞서가고 있다

오케스트레이션 데이터는 마케팅 언어와 운영 현실 사이의 간극을 가장 명확히 보여준다. 조사에 따르면 배포된 “에이전트”의 절반 이상이 진짜 다단계 오케스트레이션 워크플로라고 답한 기업은 10%에 불과했다. 대다수는 포트폴리오가 여전히 단일 프롬프트 비서에 의해 지배되고 있다고 인정했다.

이 결과는 “AI 에이전트”가 광범위한 제품의 기본 라벨이 된 시점에 나왔다. VentureBeat 데이터는 많은 기업 배포가 여러 단계를 거쳐 도구, 메모리, 정책을 조정하는 자율 시스템이라기보다 엔터프라이즈 커넥터가 붙은 고급 챗봇으로 보는 편이 더 낫다는 점을 시사한다.

이 구분은 단지 의미론적 잔가지가 아니다. 아키텍처, 테스트, 보안, 예산에 영향을 미친다. 챗봇 래퍼는 좋은 프롬프트, 그라운딩, UX 다듬기가 필요할 수 있다. 진짜 다단계 에이전트는 런타임 권한, 롤백 경로, 추적성, 지출 통제, 지속 상태, 작업 결과에 맞춘 평가, 그리고 종종 특정 모델 벤더 위에 놓이는 하이브리드 컨트롤 플레인이 필요하다.

응답자들은 그 격차를 이해하고 있는 듯하다. 2026년 말까지 51%는 provider-native 시스템과 외부 오케스트레이션을 결합한 하이브리드 컨트롤 플레인을 예상했다. 완전히 벤더 관리형 서비스에 의존하겠다는 응답은 6%에 불과했다. 설문에 따르면 그 주요 이유는 벤더 종속성이었고, 35%가 제어가 모델 제공업체 플랫폼 내부에 있을 때 가장 큰 위험이라고 꼽았다.

그래서 이 이야기는 단순히 “제공업체가 이기고 있다”가 아니다. 그들은 현재의 배포 기본값을 차지하고 있지만, 기업들은 동시에 탈출구도 만들고 있다.

보안, 컨텍스트, 평가는 여전히 배포를 따라가지 못한다

세 가지 보조 설문은 오케스트레이션 격차가 더 넓은 배포 성숙도 문제의 한 조각에 불과하다는 점을 보여준다.

보안에서는 107개 기업을 대상으로 한 VentureBeat 설문에서 54%가 확인된 AI 에이전트 보안 사고 또는 아찔한 근접 사고를 보고했다. 모든 에이전트에 자체 범위 아이덴티티가 있다고 답한 비율은 32%에 불과했으며, 69%는 플릿 어딘가에서 자격 증명이 공유되고 있다고 보고했다. 가장 고위험 에이전트를 샌드박스에 격리하는 곳은 30%뿐이었다. VentureBeat는 scoped identity와 낮은 사고율 사이의 연관성은 시사적이지만, 특히 표본이 작고 자가 선택된 점을 고려하면 인과관계를 증명하는 것은 아니라고 지적했다.

컨텍스트 인프라에서는 별도의 101개 기업 설문에서 57%가 불충분하거나 일관되지 않은 비즈니스 컨텍스트 때문에 에이전트가 자신감은 있지만 틀린 답변을 내놓는 것을 보았다고 답했다. 검색 증강 생성은 38%에게 주요 컨텍스트 소스였고, 실제 사용에서는 provider-native 도구가 앞섰다. 동시에 58%는 거버넌스된 시맨틱 계층을 운영 중이거나 구축 중이라고 답해, 많은 조직이 이제 단순 검색만으로는 충분하지 않고 더 강한 비즈니스 정의 계층이 필요하다고 보고 있음을 시사한다.

평가에서도 경고 신호는 뚜렷했다. 조사된 157개 기업의 절반은 내부 평가를 통과하고도 고객 앞에서 실패한 에이전트 또는 LLM 기능을 출시했다고 답했다. 자동 평가를 지금 완전히 신뢰한다고 답한 비율은 5%에 불과했다. 그럼에도 66%는 이미 저위험 에이전트에 대해 사람 개입 없는 배포를 허용하거나 그 방향으로 구축하고 있었다.

이 조합은 아마도 이 클러스터에서 가장 중요한 신호일 것이다. 기업은 더 많은 결정을 자동화하기 전에 완벽한 확신을 기다리고 있지 않다. 자율성을 높이면서도 그 자율성을 검증하기 위한 통제가 불완전하다는 점을 인정하고 있다.

증거가 무엇을 증명하고, 무엇을 증명하지 않는가

네 개의 원천 항목은 모두 기업 제출자료, 제품 문서, 광범위한 독립 시장 데이터가 아니라 VentureBeat AI의 Pulse Research 프로그램에서 나왔다. 이는 현재 구매자 행동의 방향성 지표로는 유용하지만, 결정적인 시장 측정치는 아니다.

VentureBeat는 한계도 반복해서 밝힌다. 표본은 자가 선택적이었고, 여러 설문에서 중견 조직에 편향되어 있었으며, 통합된 종단 패널이 아니라 2026년 6월의 단일 조사 파동에서 나온 것이다. 오케스트레이션 설문에서는 응답자에게 단 하나의 주요 플랫폼을 묻기 때문에, 다층적 사용이나 지출의 전체 그림이 아니라 현재 선호의 스냅샷을 제공한다.

즉, Claude, OpenAI, Microsoft, Google, Vertex AI Search, LangChain/LangGraph에 대한 플랫폼별 수치는 신중하게 다뤄야 한다. 이는 해당 집단이 어디에 주요 베팅을 했다고 말하는지 보여줄 뿐, 업계 전체 순위표는 아니다.

그럼에도 더 넓은 패턴은 네 개의 설문 전반에서 반복되기 때문에 무시하기 어렵다. provider-native 도구가 오케스트레이션, 검색, 보안, 평가에서 앞서는 것으로 보인다. 기업들은 상당한 사고와 실패율을 보고하고 있다. 그리고 큰 다수가 1년 안에 스택을 재검토할 계획이다. 개별 퍼센트는 다른 표본에서 달라질 수 있지만, 구조적 이야기는 더 견고해 보인다.

이것이 구축자와 기업 구매자에게 의미하는 것

에이전트 시스템을 만드는 제품팀에게 이 클러스터는 오케스트레이션이 이제 단순한 프레임워크 선택이 아니라 컨트롤 플레인 문제로 변하고 있음을 시사한다. Claude, OpenAI, Microsoft에 올라타는 것은 초기 배포를 가속할 수 있지만, 거버넌스된 컨텍스트, 런타임 아이덴티티, 운영 평가, 비용 차단의 필요성을 없애지 못한다.

인프라 스타트업에게 기회는 “플랫폼을 대체하라”보다 좁을 수 있지만, 처음 보이는 것보다 더 크다. 설문은 특화 벤더의 현재 침투율은 낮지만, 네이티브 스택이 완전히 해결하지 못하는 계층을 추가하려는 의지는 강하다고 보여준다. 이는 비인간 아이덴티티, 시맨틱 거버넌스, 실시간 품질 모니터링, 지출 관리에 특히 중요하다.

엔터프라이즈 AI 구매자에게는 내부 “에이전트” 포트폴리오가 באמת 자율 워크플로인지, 아니면 주로 보조형 채팅 인터페이스인지를 살펴보라는 메시지다. 후자라면 다음 투자처는 또 다른 오케스트레이션 추상화가 아닐 수 있다. 워크플로가 진정으로 자율화될 때 신뢰할 수 있게 만드는 운영 규율일 수 있다.

설문은 또한 많은 조직이 여전히 편의성을 보고 구매한 뒤, 정확성은 나중에 모니터링한다는 점을 시사한다. 그 순서는 실험 단계에서는 작동한다. 그러나 에이전트가 내부 시스템 전반에서 행동하거나 인간 승인 없이 변경 사항을 배포할 수 있게 되면 더 위험해진다.

다음에 주목할 것

가장 분명한 후속 신호는 provider-native 우위가 굳어지는지, 아니면 정체되는지다. OpenAI, Anthropic, Microsoft, Google이 오케스트레이션, 검색, 평가, 보안을 하나의 스택으로 계속 흡수한다면, 기업은 현재 원한다고 말하는 것보다 더 많은 락인을 받아들일 수 있다.

두 번째 신호는 하이브리드 컨트롤 플레인이 표명된 의도에서 실제 배포 아키텍처로 이동하는지다. LangChain/LangGraph, 맞춤 오케스트레이션, 아이덴티티 통제 주변의 외부 계층이 실제 운영 비중을 얻는다면, 구매자는 모델 접근을 위해서는 제공업체를 원하지만 완전한 통제까지는 원하지 않는다는 것이 확인된다.

셋째, 기업 예산이 워크플로 도구에서 설문이 시사한 덜 보이는 계층으로 이동하는지 지켜볼 필요가 있다. 즉, 시맨틱 거버넌스, 범위가 제한된 아이덴티티, 실시간 출력 모니터링, 프로그래밍 방식의 비용 집행이다. 이것들은 헤드라인용 기능은 아니지만, 응답자들이 보고한 실패와 가장 직접적으로 연결된 역량이다.

마지막으로 가장 큰 운영 시험은 정의의 문제다. 기업이 더 많은 시스템을 운영에 투입할수록, 시장은 챗봇 인터페이스, 도구를 사용하는 어시스턴트, 완전히 오케스트레이션된 AI 에이전트를 더 명확히 구분해야 한다. 지금은 라벨이 구현보다 앞서 있다.

Creati.ai 관점

이 이야기에서 가장 드러나는 부분은 기업들이 좋은 에이전트가 무엇을 해야 하는지 헷갈려 보이지 않는다는 점이다. 그들은 신뢰할 수 있는 다단계 실행, 통제된 권한, 정확한 컨텍스트, 실제 결과를 예측하는 평가를 원한다고 말한다. 격차는 현재 배포가 구매와 플랫폼 선택이 앞서가는 동안에도 그 기준에 미치지 못하는 경우가 많다는 데 있다.

그래서 이것은 플랫폼 전쟁이라기보다 운영상의 결산처럼 보인다. 모델 제공업체들은 기본 출발점이 될 권리를 얻었지만, 더 어려운 상업적 문제는 여전히 풀리지 않았다. LLM 기반 워크플로를 신뢰할 수 있는 소프트웨어 시스템으로 바꾸는 일이다. 이 격차를 가장 먼저 메우는 팀들은 더 나은 데모가 아니라 더 나은 통제와 더 명확한 정의로 그것을 해낼 가능성이 높다.