에이전트 OS가 정의되고 있다 — 데이터, 판단, 실행이 한 화면에 모이는 이유

Microsoft Agent 365, ServiceNow K26, Google Gemini Enterprise Platform이 같은 시기 '데이터·판단·실행 한 화면 통합'을 선언했다. 빅테크가 동시에 같은 구조를 정의하면 그것은 트렌드가 아니라 카테고리 표준이다. PM이 지금 설계해야 할 에이전트 OS 시대 3가지 변수.

김생근 AI 에이전트 강사·컨설턴트 2026년 5월 26일

에이전트AI PM오케스트레이션플랫폼전략

Microsoft가 Agent 365를 발표했을 때 저는 슬라이드 속 문구를 두 번 읽었습니다.

“데이터·판단·실행 — 한 화면에서.”

처음에는 마케팅 카피라고 생각했습니다. 그런데 같은 주에 ServiceNow도 Knowledge 2026(K26) 통합 AI 플랫폼을 공개하며 정확히 같은 구조를 정의했습니다. 한 달 전에는 Google이 Cloud Next 2026에서 Gemini Enterprise Agent Platform을 통해 “인프라·데이터·보안을 통합한 에이전트 OS”를 공식화했습니다. 그리고 오늘 Perplexity는 Computer Enterprise를 출시하며 Slack 하나로 20개 모델을 오케스트레이션하는 시스템을 발표했습니다.

서로 다른 회사가 같은 결론에 수렴할 때, 그것은 트렌드가 아닙니다. 카테고리 표준입니다.

빅테크 4곳이 같은 구조를 정의한다

각 발표를 개별로 보면 그냥 제품 업데이트입니다. 함께 놓으면 하나의 패턴이 됩니다.

Microsoft Agent 365는 Copilot Studio, Power Platform, Dynamics 365를 하나의 에이전트 운영 레이어로 통합했습니다. 핵심 설계는 단순합니다. 조직 데이터(SharePoint, Teams 대화, ERP 레코드)에 바로 접근하는 에이전트가 결정을 내리고, 그 결정이 같은 화면에서 실행까지 이어집니다. CRM을 업데이트하거나, 계약서 초안을 작성하거나, 구매 오더를 생성하는 행위가 별도의 시스템 전환 없이 하나의 흐름에서 완결됩니다.

ServiceNow K26은 이것을 “Now Platform AI Foundation”이라고 불렀습니다. 기업 데이터가 ServiceNow 안에 있고, AI가 그 위에서 판단하고, 같은 플랫폼에서 ITSM/HRSD/CSM 워크플로우가 실행됩니다. 과거 ServiceNow Context Engine이 “사이드카 방식을 탈피한다”고 했던 바로 그 방향이 K26에서 완성된 형태로 나왔습니다.

Google Gemini Enterprise Agent Platform은 한발 더 나갔습니다. “에이전트 OS”라는 단어를 직접 씁니다. 인프라·데이터·보안이 Gemini 중심으로 통합되는 이 구조는 한국앤컴퍼니가 마케팅·영업·물류·생산·품질관리 전 영역에 적용한 첫 전사 사례로 외부 검증을 받았습니다.

Perplexity Computer Enterprise는 오늘 출시됐습니다. Slack에서 @computer를 호출하면 Snowflake, Salesforce, SharePoint, HubSpot을 20개 모델이 동시에 오케스트레이션합니다. 컨슈머 버전이 나온 지 2주 만에 100개 이상의 기업이 액세스를 요청했습니다.

네 회사가 다른 시장에서 다른 제품을 만들지만, 구조는 같습니다. 데이터가 이미 거기 있고, 에이전트가 그 위에서 판단하고, 실행이 외부 시스템 전환 없이 완결된다.

에이전트 OS는 기술 문제가 아니다

이 구조를 “새로운 기술 스택”으로 이해하면 PM에게 남는 할 일이 없습니다.

에이전트 OS는 조직 설계 문제입니다.

지금까지 대부분의 기업이 에이전트를 도입하는 방식은 이랬습니다. 데이터는 데이터 팀이 별도로 정리하고, 모델은 AI 팀이 파이프라인으로 연결하고, 실행은 다시 개발팀이 시스템 API로 붙입니다. 이 구조에서는 에이전트가 “우리 시스템 맞은편에 있는 도구”입니다. 완전히 도입되어도 부분 자동화에 머뭅니다.

에이전트 OS가 정의하는 구조에서는 순서가 반대입니다. 데이터가 먼저 에이전트의 맥락으로 설계되고, 판단 권한이 어디까지 위임되는지가 명시되며, 실행 경계가 시스템 설계에 포함됩니다.

차이는 통합의 방향입니다.

기존 방식: 에이전트 → 데이터에 접근 → 외부 시스템에서 실행
에이전트 OS: 데이터·판단·실행 레이어가 하나의 설계 단위로 먼저 존재

이것이 왜 기술 팀의 문제가 아니라 PM의 문제냐면, 어떤 데이터를 에이전트가 볼 수 있는지, 어떤 판단을 위임하고 어떤 판단을 사람이 승인하는지, 에이전트의 행동이 어느 시스템에 영향을 미치는지 — 이 세 가지는 기술 스펙이 아니라 제품 설계이기 때문입니다.

PM이 지금 바꿔야 할 설계 3변수

1. 데이터 레이어: “에이전트가 볼 맥락”을 조직 단위로 설계하라

ServiceNow가 Context Engine에서 “사이드카 방식을 탈피한다”고 했을 때, 그 의미는 데이터 통합이 후속 작업이 아니라 1차 아키텍처 결정이 되어야 한다는 것입니다.

많은 기업이 에이전트를 도입할 때 “일단 모델부터 붙이고 데이터는 나중에”라는 순서를 택합니다. 그 결과 에이전트는 문서 요약은 잘 하지만 지난 분기 실제 거래 데이터는 모르고, 고객 대화 요약은 생성하지만 CRM 레코드와 연결되지 않습니다.

에이전트 OS 시대의 PM 질문은 이것입니다: 에이전트가 판단을 내리기 위해 필요한 맥락이 어디에 있는가? 그 맥락이 에이전트의 작동 범위 안에 처음부터 포함되어 있는가?

Dust가 “개인 도구→조직 자산”으로 비전을 잡은 것, 베스핀글로벌이 AI 파운드리를 “여러 AI 모델·에이전트·데이터를 하나의 워크플로우로 연결”하는 방향으로 설계한 것이 같은 답입니다. 데이터 레이어는 에이전트를 연결하는 파이프가 아니라, 에이전트가 거주하는 공간입니다.

2. 판단 레이어: “어디까지 위임하고, 어디서 사람이 검토하는가”

Microsoft Agent 365의 설계에서 주목할 부분은 에이전트가 실행하는 것보다 에이전트가 제안하고 사람이 승인하는 흐름이 명시되어 있다는 점입니다.

Anthropic이 Claude Managed Agents에서 메모리·evals·오케스트레이션을 플랫폼 내부 프리미티브로 흡수한 것도 같은 설계 방향입니다. 에이전트가 독립적으로 판단하되, 그 판단의 품질을 측정하고 조정하는 레이어가 함께 내장됩니다.

PM의 실제 설계 질문은 이렇게 구체화됩니다:

에이전트가 고객에게 직접 보내는 이메일은 무조건 사람 검토를 거치는가?
구매 오더 $1,000 이하는 자동 승인, $10,000 이상은 팀장 승인 — 이 기준이 시스템에 명시되어 있는가?
에이전트가 잘못된 판단을 내렸을 때 그 결과가 어디에 기록되고 누가 검토하는가?

이 질문들에 답이 없으면 에이전트가 아무리 똑똑해도 조직은 그것을 프로덕션에 놓지 못합니다. 판단 레이어 설계가 에이전트 OS 도입의 실질적 병목입니다.

3. 실행 레이어: “에이전트의 행동이 닿는 범위”를 경계로 정의하라

Perplexity Computer Enterprise에서 @computer를 호출하면 Snowflake, Salesforce, SharePoint가 동시에 연동됩니다. 이것이 강점이면서 동시에 가장 큰 설계 리스크입니다.

에이전트의 실행 범위가 넓어질수록, 그 경계를 명시적으로 설계하지 않으면 에이전트는 권한이 닿는 곳까지 모두 실행합니다. 사람이 실수로 권한을 부여한 시스템, 연결은 되어 있지만 아직 검증되지 않은 데이터, 실행하면 되돌리기 어려운 트랜잭션 — 이것들이 에이전트 OS 시대의 실질적 거버넌스 문제입니다.

# 에이전트 실행 범위 설계 예시 (개념적 구조)

agent_permissions:
  data_access:
    - salesforce.opportunities: read
    - slack.channels: read
    - sharepoint.contracts: read_write  # 명시적 쓰기 권한
  
  execution_scope:
    - email.send: requires_human_approval
    - crm.update: auto_allowed_below_$1000
    - purchase_order: requires_manager_approval
  
  audit:
    log_all: true
    retention_days: 90

이 구조가 없으면 “에이전트가 실수로 X를 했다”는 사고가 납니다. 이 구조가 있으면 “에이전트가 X를 하려 했고, 승인이 필요해서 대기 중”이 됩니다.

실행 레이어 설계는 에이전트를 막는 것이 아닙니다. 에이전트가 작동할 수 있는 공간을 명확히 정의하는 것입니다.

에이전트 OS 시대의 PM 책임은 여기 있다

빅테크가 에이전트 OS를 정의하는 이유는 단순합니다. 에이전트가 조직 안에서 실제로 작동하려면, 모델 성능이 아니라 조직의 데이터·판단·실행 구조가 에이전트를 지원해야 하기 때문입니다.

이것을 기술팀에게 맡기면 API 연동과 인프라 설계가 됩니다. 이것을 PM이 설계하면 제품이 됩니다.

데이터 레이어: 에이전트가 볼 맥락을 먼저 설계하라
판단 레이어: 어디까지 위임하고 어디서 검토할지 명시하라
실행 레이어: 에이전트의 행동 범위를 경계로 정의하라

이 세 가지가 에이전트 OS를 빌드하는 회사들이 공통으로 설계에 포함하는 것들입니다.

당신의 제품에서 데이터·판단·실행이 지금 몇 개의 화면에 흩어져 있습니까?

그 숫자가 현재 에이전트 도입의 실질적 병목을 가리킵니다.

이 포스트는 habix.ai의 AI PM 시리즈 일부입니다. Microsoft Agent 365(5/09), ServiceNow K26(5/08), Google Cloud Next 2026(4/27), Perplexity Computer Enterprise(5/19) 발표를 기반으로 작성했습니다.