Workday Agent Passport, HR·재무 에이전트에 검증 도장

AI 요약

• 무슨 일: Workday가 DevCon 2026에서 Developer Agent, Agent-Ready Tools, Agent Passport를 공개했습니다.
  • Developer Agent와 Agent-Ready Tools는 Extend Professional early access 고객에게 열렸고, GA 목표는 2026년 하반기입니다.
• 작동 방식: Codex, Claude Code, Cursor 같은 agentic tool이 Workday HR·finance 데이터를 MCP guardrail 안에서 다루게 합니다.
• 검증 장치: Agent Passport는 OWASP LLM Top 10, NIST AI RMF, MITRE ATLAS 기준과 Cisco AI Defense attestation을 연결합니다.
  • Passport 자체는 2026년 하반기 early access, 2026년 말 전 GA가 Workday의 현재 일정입니다.
• 주의점: Reddit의 Workday 실무자들은 Extend Pro license, flex credit, 수리 가능성, 미숙한 vibe coding을 함께 걱정합니다.

Workday가 2026년 6월 2일 DevCon에서 Workday Build를 에이전트 개발 플랫폼으로 다시 포장했습니다. 발표의 이름은 길지만 구성은 세 가지입니다. Developer Agent는 Claude Code, Cline, Codex, Cursor, Google Antigravity 같은 agentic development tool 안에서 Workday 앱과 에이전트를 자연어로 만들게 합니다. Agent-Ready Tools는 HR·finance 데이터에 접근하는 agent action을 Model Context Protocol, Workday 권한 모델, business process control, audit trail 안에 묶습니다. Agent Passport는 Cisco AI Defense를 첫 attestation partner로 두고 agent가 production에 들어가기 전 어떤 보안·컴플라이언스 검사를 통과했는지 signed record로 남기겠다는 제품입니다.

이 발표가 일반적인 "AI로 앱을 빠르게 만든다"는 홍보 문장보다 더 볼 만한 이유는 Workday가 다루는 데이터의 성격입니다. Workday는 HR, finance, IT를 자기 플랫폼의 중심으로 설명합니다. 회사 조직도, payroll, benefits, approval, ledger, expense policy는 실수 비용이 낮은 demo 데이터가 아닙니다. Workday 발표문은 payroll mistake, employee data exposure, regulatory fine을 예로 들며 agent development tool이 코드 작성 속도만 높여서는 충분하지 않다고 말합니다. Workday가 이번에 팔려는 것은 생성 속도보다 "agent가 조직도와 장부를 만질 때 누가 허락했고, 어떤 기준으로 검사했고, 실패하면 어디서 멈추는가"에 가깝습니다.

Developer Agent의 설계는 새 IDE를 강요하지 않는 쪽입니다. Workday는 이 agent가 Claude Code, Cline, Codex, Cursor, Google Antigravity 같은 도구에 붙는다고 밝혔습니다. 개발자는 "이번 분기에 부서가 예산을 초과할 추세이면 finance 팀에 알리는 agent를 만들어 달라"는 식으로 요청하고, Developer Agent는 필요한 Workday Agent-Ready Tools, 데이터, 서비스, 문서, 예제를 고른다는 설명입니다. Workday는 이 작업이 며칠짜리 setup을 몇 분으로 줄인다고 주장합니다. 이 수치는 benchmark가 아니라 제품 설명이므로, 글에서는 "몇 분"이라는 데모 단위로만 읽어야 합니다.

Workday가 새 도구의 대상자로 잡은 사람은 범용 앱 개발자보다 Workday Extend 개발자에 더 가깝습니다. 공식 발표는 Developer Agent와 Agent-Ready Tools가 Workday Extend Professional early access 고객에게 제공되고, 일반 출시는 2026년 하반기로 예정돼 있다고 적습니다. Agent Passport는 한 단계 늦습니다. Workday는 Passport를 2026년 하반기 early access로 열고 2026년 말 전 GA를 목표로 둡니다. 따라서 2026년 6월 3일 기준으로 이 발표는 "지금 모든 Workday 고객이 쓸 수 있는 완제품"이라기보다, Extend Professional 고객을 시작점으로 삼은 agent 개발·검증 roadmap입니다.

Agent-Ready Tools는 이번 발표에서 가장 실무적인 계층입니다. 기존 enterprise API는 보통 system integration과 data movement를 위해 설계됩니다. Workday는 Agent-Ready Tools가 autonomous agent의 record lookup, benefit update, approval trigger 같은 action을 위해 만들어졌다고 구분합니다. 발표문은 수백 개 Agent-Ready Tools가 Workday 전반에 걸쳐 MCP 같은 open standard로 연결되고, agent가 Workday의 security, delegation model, business process control, audit trail을 상속한다고 설명합니다. 이 상속이 제대로 동작하면 agent는 "권한 없는 사용자가 채팅으로 payroll을 바꿨다"는 위험을 줄일 수 있습니다. 반대로 이 상속 경계가 불명확하면 agent tool layer는 기존 API보다 더 빠르게 잘못된 행동을 전파할 수 있습니다.

Agent Passport는 Workday가 이번 발표에서 내세운 governance 카드입니다. PRNewswire에 게재된 별도 발표는 Passport가 Workday-built agent와 third-party agent를 production 전 test·verify하고 이후에도 monitor한다고 설명합니다. attestation은 OWASP LLM Top 10, NIST AI RMF, MITRE ATLAS 같은 public standard에 연결됩니다. 보안팀 입장에서는 "이 agent는 안전합니다"라는 vendor 내부 label보다 "어떤 기준의 어떤 항목을 누가 검사했는가"가 더 감사 가능한 기록입니다. Workday는 이 signed record를 통해 agent from any vendor를 같은 조건으로 비교할 수 있다고 주장합니다.

Passport의 세부 구조도 흥미롭습니다. Workday는 record가 세 층으로 나뉜다고 설명합니다. 첫째는 공격 방어, runtime safe behavior, human oversight 같은 Workday 정의의 trust area입니다. 둘째는 known attack technique에 대한 resistance처럼 public standard와 연결되는 testable claim입니다. 셋째는 Cisco처럼 verified attestor가 수행한 signed result입니다. 이 구분은 agent marketplace가 커질 때 필요합니다. agent 제작자와 agent 검증자가 같은 회사이면 "safe" label의 이해상충을 피하기 어렵습니다. Workday는 Cisco AI Defense를 첫 partner로 세워 독립 검증이라는 단어를 제품 문장 안에 넣었습니다.

Cisco AI Defense가 맡는 범위는 prompt injection, data leakage, jailbreak, unsafe action입니다. PRNewswire 발표는 Cisco가 Workday 안에서 실행되는 agent를 deployment 전 검사하고 runtime에도 보호한다고 설명합니다. Workday의 Dean Arnold는 enterprise agent가 onboarding employee, processing payment 같은 민감한 업무를 맡기 시작했다고 말했습니다. 그 조건에서 하나의 insecure agent가 employee data leak, compliance break, reputational damage를 만들 수 있다는 설명입니다. 이 인용은 마케팅 표현이 섞여 있지만, HR·finance agent의 실패 모드를 꽤 직접적으로 짚습니다. agent가 단순히 답변을 잘못하는 수준을 넘어 실제 action을 실행하면 prompt injection은 보안 사고와 업무 사고 사이의 경계를 흐립니다.

Workday의 agent 전략은 2026년 5월 28일 Google Cloud 발표와도 맞물립니다. Workday와 Google Cloud는 Sana Self-Service Agent from Workday를 Gemini Enterprise에 early access로 제공한다고 발표했습니다. 직원은 Gemini Enterprise에서 time-off balance, personal information, payslip, tax withholding, leave request 같은 질문과 요청을 처리할 수 있습니다. manager에게는 team goal review, bulk timesheet approval, performance review 시작 같은 작업을 맡길 수 있다는 설명입니다. 같은 발표에서 Workday는 Agent-to-Agent, Agent-to-UI, MCP 접근을 언급했습니다. Workday가 6월 2일 Developer Agent와 Agent-Ready Tools를 공개한 것은 이 agent surface를 employee experience에서 developer experience로 넓힌 셈입니다.

AWS 쪽 발표도 데이터 계층을 보강합니다. Workday는 2026년 6월 2일 Workday Data Cloud integration with AWS를 발표했습니다. 설명에 따르면 developer는 AWS tools와 AI services에서 Workday의 governed HR·finance data에 bi-directional zero-copy로 접근할 수 있습니다. 별도 pipeline을 만들거나 데이터를 복제하지 않고, Workday Agent Gateway를 통해 AWS에서 만든 AI agent가 payroll, benefits, financial data에 접근하되 기존 governance, permissions, audit controls를 유지한다는 주장입니다. Google Cloud와 AWS 발표를 함께 읽으면 Workday의 방향은 하나입니다. agent가 어디서 만들어지든 Workday data와 business rules는 Workday 쪽 control plane에 남기려 합니다.

이 접근은 Microsoft Work IQ APIs나 Salesforce Agentforce와 비교할 만합니다. Microsoft는 Microsoft 365 context와 tool calling을 enterprise agent 안으로 끌어들이고, Salesforce는 CRM record와 workflow를 agent action으로 묶습니다. Workday는 조직도, payroll, benefits, financial planning이라는 더 좁지만 민감한 도메인을 잡았습니다. 범용 knowledge worker agent 경쟁에서는 OpenAI Codex, Microsoft Copilot, Google Gemini Enterprise가 더 넓은 표면을 가집니다. Workday의 차별점은 "모든 일을 다 하는 agent"가 아니라 "HR·finance system of record를 다루는 agent가 어떤 권한과 감사 기록을 남기는가"입니다.

커뮤니티 반응은 발표문보다 덜 매끈합니다. Reddit r/workday의 DevCon thread에서 한 사용자는 Developer Agent가 Workday Extend developer를 겨냥한 것으로 보이고 Cursor, Claude, Codex, Cline, Antigravity 같은 tool을 통해 앱을 몇 분 안에 만들 수 있다고 정리했습니다. 댓글 중 하나는 숙련된 Extend developer에게 app과 agent building을 강화하겠지만, 구조를 이해하지 못한 고객이 vibe coding으로 붙이면 혼란이 생길 수 있다고 봤습니다. 다른 사용자는 "망가지면 고칠 줄 알아야 한다"는 점을 먼저 떠올렸다고 말했습니다. Workday 도메인에서 이 반응은 가볍게 넘길 수 없습니다. payroll과 approval workflow는 생성 결과가 그럴듯한지보다 장애 시 원복과 책임 소재가 먼저입니다.

다른 DevCon discussion thread에서는 Developer Agent를 "Workday 기술에서 가장 큰 도약"으로 보는 의견과 license·credit 혼란을 지적하는 의견이 함께 나왔습니다. 한 사용자는 Flowise가 scalable하지 않았고 Workday가 Developer Agent로 pivot한 점을 긍정적으로 봤습니다. 다른 사용자는 Orchestrate 기능이 인상적이었지만 Extend Pro license와 flex credit 경계가 헷갈린다고 적었습니다. 이 반응은 제품 adoption의 실무 병목을 보여줍니다. agent 기능이 유용해도 사용량 과금, API request 비용, Extend Professional entitlement, third-party connector 비용이 분리되어 있으면 개발팀은 PoC 이후 budget model을 다시 계산해야 합니다.

개발팀이 지금 확인할 첫 번째 항목은 artifact의 형태입니다. Developer Agent가 Workday app이나 agent를 만든다면 생성물은 사람이 review할 수 있는 config, code, workflow definition, tool declaration으로 남아야 합니다. Codex나 Claude Code에서 생성한 일반 codebase라면 git diff, test, CI, rollback이 있습니다. Workday Extend 안에서 생성된 artifact도 같은 수준의 review 단위를 제공해야 운영팀이 신뢰할 수 있습니다. 발표문은 "문서와 예제를 끌어와 setup을 줄인다"는 장점을 말하지만, 생성된 app이 어떤 repository, tenant, approval path, deployment history에 남는지는 고객이 early access에서 확인해야 합니다.

두 번째 항목은 tool action의 권한 분리입니다. Agent-Ready Tools가 hundreds of tools로 제공된다면 각 tool은 read, write, approval trigger, notification, external connector action을 분명히 나눠야 합니다. MCP server 하나가 너무 넓은 권한을 가지면 agent는 "benefit 정보를 조회한다"는 요청에서 "benefit record를 수정한다"는 행동으로 미끄러질 수 있습니다. Workday는 delegation model과 audit trail 상속을 강조하지만, 개발팀은 실제로 어떤 prompt, 어떤 user role, 어떤 approval state에서 tool이 block되는지 test case로 확인해야 합니다. HR·finance agent의 QA는 benchmark score가 아니라 permission matrix와 exception path입니다.

세 번째 항목은 Agent Passport의 검증 주기입니다. 한 번 받은 stamp가 agent lifecycle 전체를 보증하지는 않습니다. 모델이 바뀌고, tool schema가 바뀌고, Workday business process가 바뀌고, Pipedream connector가 추가되면 기존 attestation의 적용 범위도 바뀝니다. PRNewswire 발표는 runtime monitoring과 revocation을 언급합니다. agent가 task를 실행하려 할 때 allow, block, route를 결정하고 문제가 발견되면 affected agents를 회사 policy에 따라 stop, limit, restrict할 수 있다는 설명입니다. 이 부분이 실제 제품에서 얼마나 세밀한지에 따라 Passport는 단순 badge가 될 수도 있고, agent fleet 운영의 control point가 될 수도 있습니다.

Workday 발표의 강점은 agent hype를 HR·finance 업무의 통제 언어로 번역했다는 데 있습니다. Developer Agent는 Codex와 Claude Code 같은 외부 개발 표면을 받아들이고, Agent-Ready Tools는 MCP와 Workday 권한 모델을 엮고, Agent Passport는 public standard와 third-party attestation을 붙입니다. 약점은 현재 제공 범위가 early access와 미래 GA 일정에 걸쳐 있다는 점입니다. 2026년 6월 현재 고객이 바로 검증할 수 있는 것은 Developer Agent와 Agent-Ready Tools의 early access 범위이고, Passport는 하반기 early access를 기다려야 합니다. 공개 발표만으로는 실제 latency, hallucination reduction, audit completeness, license cost를 판단하기 어렵습니다.

AI 개발자에게 이 뉴스가 주는 직접 영향은 Workday가 coding agent를 enterprise SaaS 안으로 끌어들이는 방식입니다. 지금까지 Codex, Claude Code, Cursor는 주로 repository, shell, browser, design artifact를 다루는 도구로 이야기됐습니다. Workday의 Developer Agent는 이 도구들이 HR·finance platform의 생성·배포 surface가 될 수 있다고 말합니다. 이 전환은 매력적이지만, agent에게 더 많은 system access를 주는 일입니다. 개발팀은 "agent가 만들 수 있는가"보다 "agent가 만든 것을 누가 승인하고, 어떤 data를 건드렸고, 어떤 기준으로 검증됐고, 사고가 나면 한 번에 회수할 수 있는가"를 먼저 물어야 합니다.

Workday가 실제로 풀려는 병목은 AI 앱 개발 속도가 아니라 enterprise agent의 책임 경계입니다. HR·finance 업무에서 agent는 채팅 답변자가 아니라 record, approval, payment, policy를 움직이는 실행자입니다. Agent Passport라는 이름은 이 점을 꽤 노골적으로 드러냅니다. 여권이 있으면 이동할 수 있지만, 발급 기관, 입국 심사, 만료일, 취소 절차가 따라옵니다. Workday는 agent에게 그런 검증 도장을 붙이겠다고 말합니다. 이제 early access 고객이 봐야 할 것은 도장의 디자인이 아니라, 실제 Workday tenant에서 잘못된 agent action을 막고 설명하고 되돌리는 데 그 도장이 충분한지입니다.