Workday ASOR와 Gemini, HR 에이전트 승인선 경쟁

AI 요약

• 무슨 일: Workday와 Google Cloud가 Sana Self-Service Agent를 Gemini Enterprise에 연결했습니다.
  • 발표일은 2026년 5월 28일이며, eligible Workday 고객 대상 early access로 시작합니다.
• 핵심 구조: Gemini는 기본 모델이 되고, Workday ASOR가 HR·finance agent의 권한과 승인선을 잡습니다.
• 개발자 영향: enterprise agent 설계가 UI보다 system of record, approval chain, zero-copy data access로 이동합니다.
  • 발표문은 A2A, A2UI, MCP를 agent handoff 방식으로 함께 언급했습니다.
• 주의점: Workday Data Cloud는 early adopter 단계이고, unreleased 기능은 계획대로 제공되지 않을 수 있다는 면책이 붙었습니다.

Workday와 Google Cloud가 2026년 5월 28일 전략적 파트너십 확대를 발표했습니다. 발표의 첫 문장은 HR과 finance agent를 직원이 이미 쓰는 애플리케이션 안으로 가져오겠다는 내용입니다. 더 구체적으로는 Workday의 Sana Self-Service Agent가 Gemini Enterprise에 들어가고, Gemini가 Sana for Workday의 기본 AI 모델이 됩니다.

이 뉴스는 "Workday가 Gemini를 붙였다"는 통합 발표로만 읽으면 금방 지나갑니다. 개발자와 AI 제품팀이 봐야 할 부분은 agent가 답변을 넘어 action을 시작하는 위치입니다. 직원이 Gemini Enterprise에서 휴가 잔여일을 묻고, 급여 명세를 보고, 세금 원천징수 정보를 확인하고, 휴가 신청을 만들 수 있다면 agent는 단순 검색 도구가 아닙니다. HR과 finance system of record 위에서 권한, 승인, 감사 로그를 따라 움직이는 업무 실행자가 됩니다.

Workday가 이 발표에서 앞세운 단어는 Agent System of Record, 줄여서 ASOR입니다. 발표문은 Workday ASOR와 Google Cloud agent platform, Gemini 모델을 하나로 묶습니다. 목표는 Workday, Google Cloud, third-party agents가 실제 HR·finance workflow에서 함께 작동하는 foundation입니다. 모델 성능보다 먼저 등장하는 단어가 governance와 security라는 점이 이 발표의 방향을 보여줍니다.

HR 에이전트의 실제 동작 범위

Google Cloud Press Corner와 Workday 투자자 발표문은 같은 시나리오를 제시합니다. 직원은 Gemini Enterprise 안에서 time-off balance를 확인하고, personal information을 업데이트하고, payslip을 보고, tax withholding 정보를 검토하고, leave request를 한 대화 흐름에서 처리할 수 있습니다. 매니저는 team goals를 확인하고, timesheet를 bulk approve하고, performance review를 시작하고, payroll input을 제출하는 흐름을 받습니다. Finance 사용자는 expense와 travel policy, corporate card eligibility, request 또는 case 생성 안내를 묻습니다.

이 목록은 평범해 보이지만 위험도가 낮지 않습니다. 휴가 잔여일 조회는 읽기 권한입니다. 개인정보 업데이트는 쓰기 권한입니다. timesheet bulk approval은 팀원의 급여와 근태 기록에 영향을 줍니다. performance review 시작은 HR 프로세스를 열고, payroll input 제출은 재무 및 규정 리스크를 만듭니다. agent가 같은 대화 UI 안에서 이 작업들을 처리하려면 "누가 어떤 action을 할 수 있는가"가 모델 prompt가 아니라 시스템 권한으로 보장돼야 합니다.

Workday는 이 지점을 자사 강점과 연결합니다. 발표문은 Sana for Workday가 CHRO, CFO, managers, employees에게 질문하고 workflow를 trigger하고 Workday agents와 일하는 single place를 제공한다고 설명합니다. 동시에 Workday의 security, business rules, approval chains가 Gemini의 reasoning, multilingual support, multimodal capabilities 위에 얹힌다고 말합니다. 제품 문장처럼 들리지만, enterprise agent 설계에서는 이 순서가 중요합니다. 모델이 먼저 움직이고 나중에 보안이 따라오는 구조가 아니라, 기존 Workday 권한 모델 안에서 agent action이 허용돼야 합니다.

ASOR가 왜 전면에 나오나

system of record는 오래된 엔터프라이즈 소프트웨어 용어입니다. 급여, 인사, 재무, 계약처럼 회사의 공식 상태를 보관하는 시스템입니다. AI agent가 system of record 옆에 붙으면 역할이 달라집니다. 챗봇이 "휴가 정책은 이렇습니다"라고 답하는 단계에서는 출처와 최신성이 중요합니다. agent가 "휴가 신청을 넣겠습니다"라고 움직이는 단계에서는 승인권자, 휴가 유형, 지역별 정책, 대체 근무자, payroll cut-off, 감사 로그가 함께 필요합니다.

Workday ASOR는 이 지점을 agent 시대 용어로 다시 포장한 것입니다. 발표문은 ASOR와 Workday agent roadmap을 Google Cloud의 enterprise-ready agent platform과 결합한다고 설명합니다. 여기서 ASOR는 agent inventory만 뜻하지 않습니다. Workday가 가진 사용자 권한, business process framework, data model, approval chain을 agent 실행의 기준점으로 삼겠다는 의미입니다. HR과 finance에서는 agent가 틀린 답을 하는 것보다, 권한 없는 action을 맞는 형식으로 실행하는 사고가 더 비쌉니다.

개발팀 입장에서는 integration 순서가 바뀝니다. 일반적인 SaaS agent prototype은 먼저 LLM에 API tool을 붙이고, 나중에 permission check와 audit log를 보강합니다. Workday와 Google이 말하는 구조에서는 반대로 system of record가 먼저 있고, agent는 그 위의 action layer입니다. 이 구조가 실제로 지켜지면 agent app은 프롬프트 관리 도구가 아니라 policy enforcement surface가 됩니다.

A2A, A2UI, MCP가 함께 나온 이유

이번 발표에서 눈에 띄는 문장은 A2A, A2UI, MCP를 함께 언급한 부분입니다. Workday와 Google Cloud는 이 partnership이 Agent-to-Agent, Agent-to-UI, Model Context Protocol approaches를 지원해 AI agents가 정보를 공유하고 task를 autonomously hand off할 수 있게 한다고 설명했습니다. 프로토콜 이름을 세 개나 적은 이유는 HR·finance 업무가 단일 agent 호출로 끝나지 않기 때문입니다.

예를 들어 출장비 정책을 묻는 직원에게 agent가 답변만 해주면 검색 문제입니다. 하지만 해당 직원의 직급, 비용 센터, 출장 지역, corporate card eligibility, manager approval, finance case 생성까지 이어지면 여러 agent와 UI, system API가 함께 움직입니다. Gemini Enterprise는 사용자와 대화하는 표면이고, Sana agent는 Workday workflow를 알고, finance policy agent는 지출 규칙을 해석하고, Workday ASOR는 action 가능 여부를 결정합니다. 이 사이의 handoff를 독자 connector로만 만들면 agent가 늘어날수록 유지보수 비용이 커집니다.

MCP는 외부 도구와 데이터 연결을 위한 표준으로 이미 개발자 생태계에서 빠르게 퍼졌습니다. A2A는 agent 간 위임과 협업을, A2UI는 agent가 UI 상태와 사용자 상호작용을 다루는 경로를 겨냥합니다. 이번 발표는 세 프로토콜을 구체 구현 세부사항까지 공개하지 않았습니다. 그래도 Workday 같은 system of record vendor가 공식 발표문에서 이 이름들을 함께 썼다는 사실은 enterprise agent 시장이 "한 챗봇"이 아니라 여러 agent와 UI, tool server가 얽힌 운영 문제로 이동했다는 신호입니다.

zero-copy 데이터 연결이 필요한 이유

Workday와 Google Cloud는 Data Cloud와 BigQuery를 묶은 zero-copy access도 함께 발표했습니다. 문장은 명확합니다. Workday Data Cloud와 Google Cloud Lakehouse 사이에서 데이터를 이동하거나 복제하지 않고 query할 수 있고, 각 시스템은 데이터가 있는 곳에서 읽으며 security permissions와 business rules를 유지한다는 설명입니다. Workday Data Cloud는 early adopter 고객에게 제공 중이고 2026년 later this year 일반 제공 예정입니다.

HR과 finance 데이터는 복제 비용보다 통제 비용이 큽니다. 직원 급여, 세금, 근태, 성과, 비용 청구 데이터가 분석을 위해 다른 lakehouse로 복제되면 데이터 lineage, residency, retention, masking, access review가 모두 늘어납니다. agent가 conversational analytics를 제공하려면 데이터 접근이 빠르고 넓어야 하지만, HR 데이터는 가장 넓게 열기 어려운 데이터입니다. zero-copy 주장은 이 모순을 줄이려는 설계입니다.

이 부분은 개발자에게 직접적인 설계 질문을 남깁니다. agent가 "지난 분기 특정 조직의 overtime risk를 알려줘"라고 요청할 때 어떤 데이터가 어디에서 query되는가. query 결과가 agent memory나 trace에 남는가. Gemini Enterprise, Workday Data Cloud, BigQuery 사이의 permission model이 충돌하면 어느 쪽이 우선하는가. 발표문은 "permissions and business rules remain fully intact"라고 설명하지만, 실제 구현에서는 identity mapping, row-level security, audit event correlation이 핵심이 됩니다.

Gemini가 기본 모델이 된다는 의미

Gemini가 Sana for Workday의 기본 AI 모델이 된다는 문장도 작지 않습니다. Workday는 Sana가 multiple AI models를 지원하므로 고객이 다른 모델을 선택할 수 있다고 덧붙였습니다. 기본값은 강합니다. 엔터프라이즈 SaaS에서 default model은 품질 기준, 비용 구조, support 책임, data processing agreement, regional availability, latency expectation을 사실상 결정합니다. 고객이 바꿀 수 있다고 해도 첫 integration과 GSI playbook은 기본 모델을 중심으로 만들어집니다.

Google Cloud 입장에서는 Gemini Enterprise의 위치가 강해집니다. 발표문은 직원이 Gemini Enterprise에서 질문하면 Workday에서 직접 끌어온 개인화된 답을 받을 수 있고, 올바른 policies와 permissions가 적용된다고 설명합니다. Google은 모델 제공자이면서 agent workplace의 UI 제공자가 됩니다. Workday는 system of record와 HR·finance workflow를 붙잡습니다. 둘의 접점이 넓어질수록 agent 경쟁은 모델 호출 API보다 "어느 업무 화면 안에서 action이 승인되는가"로 이동합니다.

이 구조는 Microsoft와도 부딪힙니다. Workday는 2026년 5월 13일 Sana Self-Service Agent가 Microsoft Copilot에서도 제공된다고 발표한 바 있습니다. 이번 Google 발표는 Gemini Enterprise 경로를 넓히는 사건입니다. Workday는 단일 assistant에 종속되기보다 여러 enterprise AI surface에 자기 agents를 배포하고, ASOR로 권한과 승인선을 유지하려는 쪽에 가깝습니다. Google과 Microsoft는 각자 employee workflow의 앞문이 되려 합니다.

업무별 agent 표면이 갈라진다

이 표에서 보듯 업무별 agent는 같은 conversational UI를 쓰더라도 완전히 다른 permission surface를 갖습니다. 직원 self-service agent는 본인 데이터와 요청 생성이 중심입니다. 매니저 agent는 타인의 근태와 평가 프로세스를 건드립니다. Finance agent는 비용 정책과 지급 절차에 연결됩니다. Admin agent는 Workday tenant 자체를 관리할 가능성이 있습니다. 이름은 모두 agent지만 사고 비용은 다릅니다.

그래서 enterprise agent 도입 지표도 바뀌어야 합니다. 답변 정확도와 latency만으로는 부족합니다. action별 approval rate, rejected action의 원인, permission denial 로그, user confirmation step, bulk action rollback, policy source freshness를 같이 봐야 합니다. Workday와 Google의 발표가 developer tools 뉴스처럼 보이는 이유가 여기에 있습니다. agent가 업무 시스템에 들어갈수록 제품팀은 LLM prompt보다 workflow state machine과 audit event schema를 더 많이 다루게 됩니다.

GSI가 필요한 발표라는 사실

발표문은 Accenture, Deloitte, KPMG를 명시합니다. 이 회사들이 stakeholder, governance, technical, business process knowledge를 제공한다고 설명합니다. 보도자료에 흔히 들어가는 partner paragraph처럼 보이지만, HR·finance agent에서는 이 문장이 현실적입니다. 각 회사의 휴가 정책, 지출 승인, payroll calendar, local compliance, union rule, cost center 구조는 다릅니다. 같은 Sana agent라도 enterprise tenant마다 안전한 action boundary가 달라집니다.

KPMG 인용에는 Financial Close Companion이 등장합니다. Workday와 Google은 KPMG용 month-end closing assistant를 이미 소개했고, 이번 발표는 그 흐름을 HR self-service와 finance workflow로 넓힙니다. 이 시장에서 GSI는 단순 구축 파트너가 아니라 agent action catalog와 approval policy를 업무별로 번역하는 역할을 맡게 됩니다. 개발자가 만든 agent framework만으로는 각 회사의 인사·재무 프로세스 차이를 자동으로 해결할 수 없습니다.

이 점은 비용에도 영향을 줍니다. AI agent가 SaaS 라이선스 수를 줄인다는 논의가 있지만, 실제 enterprise rollout은 GSI 컨설팅, 데이터 권한 정리, business process redesign, security review, change management 비용을 동반합니다. CIO Dive는 Workday가 SaaS 시장 압박과 AI 전환 속에서 고객 유지와 workflow 통합을 겨냥한다고 해석했습니다. 제품 발표 이면에는 "AI가 SaaS 좌석을 줄일 것인가, 아니면 system of record vendor가 agent 운영면으로 다시 과금할 것인가"라는 사업 모델 질문이 있습니다.

아직 확인해야 할 것

첫째, early access의 실제 범위입니다. 발표문은 Sana Self-Service Agent in Gemini Enterprise가 eligible Workday customers에게 early access로 제공된다고 말합니다. Workday Data Cloud도 early adopter 상태이며 일반 제공은 later this year로 적혔습니다. 따라서 지금 당장 모든 Workday 고객이 같은 기능을 쓸 수 있다고 보면 안 됩니다. 구매 결정에는 현재 사용 가능한 기능과 향후 제공될 수 있는 기능을 구분해야 합니다.

둘째, 비용과 계약 구조입니다. Workday 사용자 커뮤니티에서는 agent dashboard와 ASOR 접근에 uMSA, Flex Credit Agreement 같은 계약 요소가 필요하다는 이야기가 나옵니다. 이 반응은 공식 발표의 기능 설명과 별개로 실무자가 먼저 만나는 벽입니다. agent가 employee workflow에 붙으면 사용량이 seat, credit, model token, marketplace procurement 중 어디로 잡히는지 확인해야 합니다.

셋째, multi-model flexibility의 실제 한계입니다. Workday는 Sana가 multiple AI models를 지원한다고 설명했습니다. 하지만 Gemini가 default가 되면 reference implementation, support 문서, GSI template, performance tuning은 Gemini 중심이 될 가능성이 큽니다. 다른 모델을 쓰는 고객은 품질, latency, compliance, region, tool compatibility를 별도로 검증해야 합니다. "선택 가능"과 "동등하게 운영 가능"은 다른 말입니다.

넷째, protocol support의 구체성입니다. A2A, A2UI, MCP가 발표문에 함께 등장했지만 어떤 endpoint, schema, permission model, failure handling이 공개되는지는 별도 문서가 필요합니다. protocol 이름만으로 agent handoff가 안전해지는 것은 아닙니다. 누가 task를 넘겼는지, 어떤 권한으로 tool을 호출했는지, 중간 agent가 사용자 confirmation을 생략할 수 있는지까지 정해야 합니다.

개발팀이 가져갈 질문

이 발표를 Workday 고객만의 소식으로 축소하면 놓치는 것이 있습니다. enterprise agent의 다음 경쟁은 "모델이 어떤 업무를 이해하는가"보다 "어느 system of record가 action을 승인하는가"에 가깝습니다. HR과 finance처럼 오류 비용이 높은 영역에서는 agent runtime이 아무리 좋아도 공식 데이터와 승인 체계 밖에서 움직일 수 없습니다. Workday는 그 경계를 ASOR로 부르고, Google은 Gemini Enterprise를 employee-facing agent surface로 밀고 있습니다.

개발팀은 세 가지 질문을 먼저 던져야 합니다. 첫째, 우리 agent의 source of truth는 어디인가. 둘째, 각 tool call은 기존 업무 시스템의 role과 approval chain을 그대로 따르는가. 셋째, agent가 만든 action과 사람이 만든 action을 감사 로그에서 구분할 수 있는가. 이 질문에 답하지 못하면 agent는 데모에서는 빠르고, 운영에서는 위험합니다.

AI agent를 기업 업무에 넣는 일은 이제 챗 인터페이스 제작이 아닙니다. Workday와 Google Cloud 발표가 보여준 실체는 데이터가 있는 곳, 승인이 일어나는 곳, 직원이 일하는 곳을 한 workflow 안에 묶는 작업입니다. 그 작업의 중심에는 모델 이름보다 ASOR, zero-copy data access, A2A/A2UI/MCP handoff, GSI가 정리하는 업무 규칙이 놓입니다.