직원 입장에서는 Sana 에이전트가 일상적인 HR 문의를 처리하는 셀프서비스 비서처럼 작동한다. 예를 들어 다음과 같은 작업을 Copilot 채팅에서 바로 수행할 수 있다.
이 모든 작업을 Microsoft 365를 벗어나지 않고 처리할 수 있어, 직원은 업무 흐름을 끊지 않고 필요한 정보를 얻을 수 있다.
관리자에게는 일상적인 승인 작업을 간소화하는 기능이 제공된다.
대표적인 예가 직원 타임시트 검토 및 승인이다. 요청은 Copilot에서 시작되지만 실제 승인 프로세스는 여전히 Workday에서 진행된다.
따라서 다음 요소는 기존과 동일하게 유지된다.
즉 인터페이스만 바뀌었을 뿐, 핵심 HR 시스템의 통제 구조는 그대로 유지된다.
Sana 에이전트는 HR뿐 아니라 재무 관련 직원 서비스도 지원한다.
대표적인 예는 다음과 같다.
이 역시 Workday의 재무 워크플로와 직접 연결되기 때문에 기존 재무 규칙과 승인 절차가 동일하게 적용된다.
기업 입장에서 가장 중요한 부분은 AI 인터페이스가 기존 통제 체계를 우회하지 않는가다.
Workday와 Microsoft는 이를 해결하기 위해 Copilot이 Workday 데이터를 직접 처리하지 않도록 설계했다. 대신 Copilot은 Workday 에이전트를 호출하는 역할만 수행한다.
그 결과 다음 구조가 유지된다.
또한 통합을 위해서는 Workday 관리자 측에서 보안 설정, 통합 사용자, 인증 정책 등을 구성해야 한다.
이 통합은 완전히 새 AI 챗봇을 개발해야 하는 방식이 아니다.
Microsoft는 Employee Self‑Service(ESS) 에이전트 프레임워크와 **Workday 확장 패키지(extension pack)**를 제공한다. 조직은 이를 설치하고 설정하는 방식으로 통합을 진행한다.
일반적인 배포 단계는 다음과 같다.
Workday 관리자와 보안 검토 과정은 필요하지만, 대부분의 연결 구조가 미리 정의되어 있어 맞춤형 통합 개발 부담이 크게 줄어든다.
이번 기능은 단순한 제품 연동 이상의 의미를 가진다. Workday와 Microsoft는 이미 기업용 AI 에이전트 생태계 구축을 목표로 협력하고 있다.
예를 들어 Microsoft의 Azure AI Foundry나 Copilot Studio로 만든 AI 에이전트를 Workday의 **Agent System of Record(ASOR)**에 등록해 관리할 수 있는 구조가 준비되고 있다.
이 모델에서 두 회사의 역할은 비교적 명확하다.
Sana 에이전트의 Copilot 통합은 이 전략이 실제 제품 형태로 구현된 첫 사례 중 하나로 볼 수 있다.
기업 소프트웨어의 방향도 바뀌고 있다. 과거에는 직원이 여러 시스템을 오가며 작업해야 했다면, 이제는 AI 에이전트가 여러 시스템 위에 대화형 인터페이스를 제공하는 구조가 등장하고 있다.
이 모델에서는 Microsoft 365 같은 생산성 도구가 사용자 인터페이스 층, Workday 같은 플랫폼이 데이터와 업무 실행을 담당하는 시스템 오브 레코드 역할을 맡는다.
Sana 셀프서비스 에이전트는 바로 그 모델을 보여주는 사례다. 직원은 자연어로 업무를 요청하고, 기업 시스템은 기존 거버넌스를 유지한 채 작업을 처리한다.