올해 2분기, 전혀 다른 업종의 두 기업이 같은 결론을 내놓았다.

Microsoft는 Agent 365를 공개하며 에이전트가 데이터 소스에 직접 접근하고, 그 자리에서 판단하고, 즉시 실행까지 마치는 단일 화면을 플랫폼의 기본 단위로 정의했다. ServiceNow는 Knowledge 2026(K26) 컨퍼런스에서 ITSM·HR·재무 워크플로우를 하나의 통합 AI 플랫폼 위에 올린다고 발표했다. 생산성 소프트웨어와 엔터프라이즈 워크플로우, 출발점이 완전히 다른 두 기업이 같은 아키텍처로 수렴했다.

두 독립 수렴이 의미하는 것은 하나다. 카테고리가 닫혔다.

5월에 이 블로그에 에이전트 OS가 정의되고 있다는 글을 썼다. 그때 행위자는 Dust와 베스핀글로벌 같은 특수 플레이어들이었다. 스타트업과 MSP가 카테고리를 그려가는 단계였다.

그 단계는 끝났다.

5월과 지금의 차이는 행위자의 체급이다. Microsoft 365와 ServiceNow는 전 세계 기업의 일하는 방식 자체다. 두 회사가 에이전트 OS 아키텍처를 플랫폼 기본값으로 내장한다는 건, 이 아키텍처를 따르지 않는 제품이 비표준 위치에 선다는 뜻이다. 선택지의 문제가 사라지고 출발점의 문제가 된다.

분리된 레이어가 왜 실패를 낳는지부터 짚어야 한다.

에이전트의 데이터 접근·판단·실행이 각자 다른 레이어로 나뉘어 있으면 컨텍스트가 경계마다 끊긴다. 데이터 레이어는 현재 상태를 알고, 판단 레이어는 무엇을 해야 하는지 알고, 실행 레이어는 어떻게 하는지 안다. 세 층이 동시에 같은 현실을 보지 않는다는 게 문제다.

구체적인 시나리오를 보자. IT 지원 에이전트가 사용자 티켓을 받아 해결책을 실행하는 도중에, 권한 레코드가 다른 프로세스에 의해 갱신되고 있다고 하자. 실행 레이어가 참조하는 권한 정보와 데이터 시스템이 쓰고 있는 정보가 서로 다른 시점을 가리킨다. 분리된 구조에서 이 타이밍 불일치는 에러를 낳고, 에러는 운영자가 수동 개입할 때까지 방치된다. 에이전트를 도입한 이유가 수동 개입을 줄이는 것이었다면, 이 에러 루프는 도입 효과를 지운다.

ServiceNow K26이 “단일 플랫폼 위에서 읽고, 판단하고, 실행한다”를 기조로 내건 이유가 여기에 있다. 레이어 간 정합성 비용을 아키텍처 수준에서 없애는 것이 에이전트 OS의 핵심이다.

Microsoft가 Copilot Studio에서 Agent 365로 명칭을 바꾼 것도 같은 방향이다. Copilot은 사람 옆에서 제안하는 구조다. Agent는 데이터를 직접 보고 판단하고 실행 결과를 되먹임한다. 이름이 바뀌었다는 건 내부 아키텍처가 바뀌었다는 기표다.

에이전트 제품을 만들고 있는 PM이라면 지금 세 가지 질문 앞에 서 있다.

첫째, 우리 에이전트의 데이터·판단·실행이 같은 컨텍스트 위에 놓여 있는가. 세 레이어가 각자 다른 버전의 현실을 보고 있다면 에러 시나리오는 언제나 “운영자가 수동으로 메운다”로 수렴한다. 이것이 스케일링의 하드 리밋이 된다.

둘째, 빅테크 플랫폼이 이 아키텍처를 기본값으로 제공하는 세상에서 우리의 차별화 포인트는 어디인가. 인프라가 디폴트로 주어진다면 경쟁의 축은 이동한다. 11년 치 도메인 데이터, 특정 산업의 규칙 체계, 한 분야의 감사 요건을 이미 내장한 플레이어가 에이전트 OS 위에서 다음 경쟁을 시작한다. 도메인 깊이가 아키텍처 우위를 넘는 시점이다.

셋째, 우리가 지금 ’에이전트 OS를 만든다’는 포지셔닝이라면 실제로 누구와 싸우는 건지 알고 있는가. 스타트업이 Microsoft와 ServiceNow와 같은 레이어에서 정면 경쟁하는 건 2010년대 초에 Salesforce와 같은 레이어에서 CRM을 만들던 것과 닮았다.

Dust는 “워크플레이스 AI OS”를 표방해왔다. 올해 두 빅테크가 같은 포지셔닝을 기본값으로 내장하면서 Dust의 경쟁 상대는 다른 스타트업이 아니라 플랫폼 자체가 됐다. 카테고리 개척자가 카테고리 탈환자가 되는 전환점이 지금이다. 베스핀 AI 파운드리 같은 국내 플레이어도 같은 질문 앞에 서 있다.

OS 레이어가 빅테크 디폴트가 된 다음에는 버티컬이 남는다.

당신이 만드는 에이전트, 빅테크 플랫폼이 절대 가질 수 없는 도메인 데이터나 규칙이 한 가지 있습니까?