SAP이 ERP에 AI 에이전트를 심었다, 자율 기업의 조건
SAP Sapphire 2026의 Autonomous Enterprise 발표는 ERP, 데이터, 거버넌스 안에서 AI 에이전트가 행동하는 엔터프라이즈 전환점입니다.
- 무슨 일: SAP이 Sapphire 2026에서
Autonomous Enterprise와SAP Business AI Platform을 공개했습니다.- SAP BTP, Business Data Cloud, Business AI를 하나의 거버넌스 환경으로 묶고 Joule agents를 업무 프로세스 안에 배치하는 전략입니다.
- 핵심 숫자: 50개 이상 Joule Assistants, 200개 이상 특화 에이전트, 1억 유로 파트너 펀드가 함께 발표됐습니다.
- 의미: 에이전트 경쟁이 채팅 UI에서 ERP, 데이터 계층, 권한, 감사 로그를 포함한 실행 플랫폼으로 이동하고 있습니다.
- Anthropic, NVIDIA, AWS, Microsoft, Google Cloud, n8n, Palantir가 SAP의 에이전트 생태계 안에 포지셔닝됐습니다.
- 주의점: SAP의 강점은 업무 맥락이지만, 실제 도입은 클라우드 전환, 권한 설계, 프로세스 정비, ROI 검증에 묶입니다.
SAP이 2026년 5월 12일 SAP Sapphire에서 Autonomous Enterprise를 공개했습니다. 발표의 표면은 SAP다운 대형 엔터프라이즈 비전입니다. 하지만 이번 발표를 단순한 "ERP 회사의 AI 기능 추가"로 보면 중요한 변화가 가려집니다. SAP은 AI 에이전트를 챗봇이나 업무 보조 기능으로만 두지 않고, 기업의 시스템 오브 레코드 안에서 실제 프로세스를 실행하는 계층으로 끌어들이려 합니다.
핵심 제품은 SAP Business AI Platform입니다. SAP은 이 플랫폼이 SAP Business Technology Platform, SAP Business Data Cloud, SAP Business AI를 하나의 통제된 환경으로 묶는다고 설명했습니다. 여기에 SAP Knowledge Graph가 고객의 SAP 환경에 있는 비즈니스 엔터티, 프로세스, 관계를 구조화하고, Joule Studio가 엔터프라이즈 에이전트와 에이전틱 워크플로를 만드는 빌더가 됩니다. 말하자면 SAP은 모델 경쟁에 직접 뛰어들기보다, 모델이 기업 업무 안에서 "무엇을 알아야 하고, 무엇을 해도 되며, 어떤 흔적을 남겨야 하는가"를 쥐려 합니다.
이번 발표가 흥미로운 이유는 숫자보다 위치입니다. SAP은 50개 이상의 도메인별 Joule Assistants, 200개 이상의 특화 에이전트, 7개 산업별 자율 솔루션, 1억 유로 파트너 펀드를 내세웠습니다. 숫자는 엔터프라이즈 행사에서 자주 보이는 장식처럼 보일 수 있습니다. 그러나 이 숫자들이 놓인 자리가 ERP, HR, 조달, 공급망, 재무, 고객경험이라는 점이 중요합니다. AI 에이전트가 기업의 실제 결산, 구매, 재고, 인사, 고객 응대 흐름 안에 들어가는 순간, 문제는 "답변을 잘 생성하는가"에서 "권한과 책임을 견딜 수 있는가"로 바뀝니다.

챗봇 다음 단계는 업무 실행 계층입니다
지난 2년 동안 엔터프라이즈 AI의 가장 흔한 형태는 코파일럿이었습니다. 사용자는 자연어로 질문하고, AI는 문서를 요약하거나, 이메일을 쓰거나, 보고서를 만들어 줍니다. 이 단계에서 AI의 가치는 개인 생산성에 가까웠습니다. 한 사람이 더 빨리 읽고, 더 빨리 쓰고, 더 빨리 초안을 만들 수 있었습니다.
하지만 기업이 정말로 원하는 것은 개인의 글쓰기 속도만이 아닙니다. 결산이 늦어지는 이유를 찾고, 공급 지연을 감지하고, 구매 승인 예외를 처리하고, 직원 휴가 규정을 확인한 뒤 실제 워크플로를 넘기고, 고객 서비스 이슈를 관련 주문과 계약 데이터에 연결해야 합니다. 이 작업은 단순한 텍스트 생성이 아니라 시스템 간 실행입니다. 그리고 이 실행에는 권한, 데이터 계보, 감사 로그, 정책, 예외 처리가 따라옵니다.
SAP의 Autonomous Enterprise 발표는 이 지점을 정면으로 겨냥합니다. SAP은 Joule Work를 통해 사용자가 개별 애플리케이션 화면을 오가며 데이터를 입력하는 대신, 원하는 비즈니스 결과를 설명하면 Joule이 적절한 워크플로, 데이터, 에이전트 조합을 오케스트레이션하는 경험을 제시했습니다. 이것은 "ERP에 챗봇을 붙였다"가 아닙니다. 사용자의 주 인터페이스가 화면 묶음에서 업무 목표로 이동한다는 주장입니다.
물론 이 주장은 아직 검증되어야 합니다. 기업 업무는 데모보다 훨씬 지저분합니다. 예외적인 승인 경로, 오래된 커스터마이징, 부서별 데이터 정의, 지역별 규제, 사용자 권한의 잔재가 모두 얽혀 있습니다. 그래서 SAP의 접근은 모델 성능보다 업무 맥락과 통제 계층을 강조합니다. 거대 언어 모델이 똑똑해져도 기업 프로세스의 의미를 모르면 행동할 수 없고, 행동하더라도 신뢰받기 어렵기 때문입니다.
SAP Business AI Platform이 묶으려는 세 가지
SAP Business AI Platform의 첫 번째 축은 데이터와 의미입니다. SAP은 Knowledge Graph가 고객의 SAP landscape에서 비즈니스 엔터티, 프로세스, 관계를 구조화한다고 설명합니다. 에이전트가 "이 공급업체 주문을 우회하라"는 요청을 받았을 때, 단순히 문장을 이해하는 것만으로는 부족합니다. 공급업체가 어떤 계약에 묶여 있는지, 대체 공급처가 어떤 승인 정책을 거쳐야 하는지, 재고와 납기, 비용 영향이 어디로 이어지는지를 알아야 합니다. Knowledge Graph는 이런 업무 문맥을 모델에게 연결하는 시도입니다.
두 번째 축은 빌더입니다. Joule Studio는 SAP의 에이전트 개발 환경입니다. SAP은 no-code, pro-code, 그리고 개발자가 선택한 AI 프레임워크를 지원한다고 말했습니다. 이 메시지는 중요합니다. 엔터프라이즈 에이전트는 중앙 AI 팀만 만들 수 없습니다. 실제 프로세스를 아는 재무, 조달, HR, 공급망 담당자가 요구사항을 내고, IT와 개발자가 이를 통제 가능한 워크플로로 만들어야 합니다. SAP은 이 경계를 Joule Studio 안에서 연결하려 합니다.
세 번째 축은 실행과 거버넌스입니다. SAP은 NVIDIA OpenShell을 Joule Studio의 신뢰할 수 있는 보안 런타임으로 언급했습니다. NVIDIA 블로그에 따르면 OpenShell은 자율 에이전트를 안전하게 개발하고 배포하기 위한 오픈소스 런타임이며, 격리된 실행 환경, 파일시스템과 네트워크 수준의 정책 집행, 인프라 수준의 containment를 제공합니다. SAP은 여기에 엔터프라이즈 역할, 프로세스 맥락, identity, auditability를 붙여 "이 행동이 기술적으로 안전한가"와 "이 행동이 업무적으로 허용되는가"를 나눠 다루려 합니다.
이 세 축을 합치면 SAP의 메시지는 명확해집니다. 모델은 여러 공급자 중 하나일 수 있습니다. 하지만 비즈니스 데이터, 업무 의미, 권한, 감사, 배포, 파트너 생태계는 SAP 안에 묶겠다는 것입니다. 이는 Salesforce Agentforce, ServiceNow AI Agents, Microsoft Copilot Studio와 같은 엔터프라이즈 에이전트 플랫폼 경쟁과 같은 방향이지만, SAP은 ERP와 핵심 업무 시스템이라는 더 깊은 지점을 출발점으로 삼습니다.
Claude는 추론 엔진, NVIDIA는 실행 안전장치입니다
이번 발표에서 SAP은 파트너를 대거 전면에 세웠습니다. 가장 눈에 띄는 파트너는 Anthropic과 NVIDIA입니다. SAP과 Anthropic은 Claude를 SAP Business AI Platform의 주요 추론 및 에이전틱 역량으로 확장하는 계획을 발표했습니다. SAP은 Claude가 Joule agents를 통해 분기 결산, 직원 휴가 질문, 공급 주문 우회 같은 복잡한 업무를 처리하도록 돕는다고 설명했습니다. SAP이 모든 모델을 자체 개발하겠다는 메시지가 아니라, 외부 프런티어 모델을 SAP의 업무 맥락과 통제 안으로 끌어오겠다는 메시지입니다.
NVIDIA와의 협력은 다른 층입니다. 모델이 "무엇을 할지" 판단한다면, 런타임은 "어떻게 안전하게 실행할지"를 다룹니다. NVIDIA는 SAP이 OpenShell을 SAP Business AI Platform에 내장하고, SAP engineers가 OpenShell의 오픈소스 코드베이스에 런타임 하드닝, 정책 모델링, 엔터프라이즈 identity 통합, 감사와 거버넌스 hooks 중심으로 기여한다고 밝혔습니다. SAP 고객이 직접 만든 Joule Studio 에이전트도 이 실행 계층을 타게 된다는 설명입니다.
이 조합은 에이전트 시대의 현실적인 분업을 보여줍니다. 엔터프라이즈 기업은 가장 좋은 모델 하나만 고르면 끝나는 것이 아닙니다. 모델은 바뀔 수 있고, 비용과 데이터 정책에 따라 여러 모델을 써야 할 수 있습니다. 더 중요한 것은 어떤 모델을 쓰든 에이전트가 파일, 네트워크, API, 인증 정보, 업무 데이터에 접근할 때 손상을 제한하고, 정책을 집행하고, 누가 무엇을 승인했는지 남기는 계층입니다. SAP과 NVIDIA가 OpenShell을 강조하는 이유가 여기에 있습니다.
파트너 지도는 SAP의 약점도 드러냅니다
SAP의 파트너 목록은 넓습니다. Anthropic은 Claude, AWS는 SAP Business Data Cloud와 Amazon Athena의 zero-copy 데이터 통합, Google Cloud와 Microsoft는 Joule과 외부 agent framework 간 양방향 agent-to-agent 상호운용, Mistral AI와 Cohere는 SAP cloud infrastructure 위 sovereign model 옵션, n8n은 Joule Studio 안의 시각적 AI workflow orchestration, Palantir와 Accenture는 복잡한 데이터 마이그레이션, Conduct는 AI 기반 cloud ERP migration으로 등장했습니다.
이 명단은 SAP의 강점과 약점을 동시에 보여줍니다. 강점은 SAP이 기업 업무 데이터와 프로세스의 중심에 있다는 점입니다. 수많은 기업에서 재무, 조달, 공급망, HR의 핵심 데이터는 SAP에 있습니다. 에이전트가 실제 업무를 하려면 이 데이터와 프로세스에 붙어야 합니다. 약점은 SAP 혼자서는 모델, 런타임, 워크플로 빌더, 클라우드 데이터 통합, 마이그레이션 자동화, 산업별 구현을 모두 해결하기 어렵다는 점입니다.
그래서 이번 발표는 SAP 생태계 재편 선언에 가깝습니다. SAP은 파트너를 단순 연동 목록으로 두지 않고, Business AI Platform 안에 역할을 배정하고 있습니다. Claude는 추론, OpenShell은 실행 격리, n8n은 시각적 워크플로, hyperscaler는 데이터와 agent interoperability, Palantir와 Accenture는 전환 프로젝트를 맡습니다. 고객 입장에서는 선택지가 넓어 보이지만, 동시에 더 복잡한 플랫폼 의존성이 생깁니다.
| 역할 | SAP 발표의 구성 요소 | 실무 질문 |
|---|---|---|
| 업무 의미 | SAP Knowledge Graph, Business Data Cloud | 우리 조직의 커스터마이징과 예외 규칙까지 구조화되는가 |
| 에이전트 빌드 | Joule Studio, n8n orchestration | 업무 담당자와 개발자가 같은 수명주기를 공유할 수 있는가 |
| 추론 | Claude, Mistral, Cohere 등 모델 선택지 | 데이터 위치, 비용, 규제 요구에 따라 모델을 바꿀 수 있는가 |
| 실행 안전 | NVIDIA OpenShell, Joule Studio runtime | 권한, 네트워크, 파일, API 접근이 정책과 감사로 통제되는가 |
| 전환 | RISE, GROW, migration tooling, partner fund | AI 도입이 클라우드 전환 압박으로만 작동하지 않는가 |
개발자에게 중요한 이유
개발자 관점에서 이번 발표는 SAP 전용 뉴스로만 볼 일이 아닙니다. 많은 기업에서 AI 에이전트의 실제 병목은 모델 호출 코드가 아니라 시스템 통합입니다. 에이전트가 주문을 바꾸고, 결재를 올리고, 재고를 조회하고, 계약 조건을 확인하고, 공급망 예외를 처리하려면 결국 기존 업무 시스템과 연결되어야 합니다. 이 연결은 API만으로 끝나지 않습니다. 권한, 데이터 품질, 트랜잭션 경계, 감사, 오류 복구가 함께 필요합니다.
SAP Business AI Platform은 이 문제를 플랫폼 차원에서 흡수하려는 시도입니다. 개발자는 Joule Studio에서 에이전트와 워크플로를 만들고, 외부 AI 프레임워크를 연결하고, SAP-managed infrastructure 위에서 실행할 수 있다는 약속을 받습니다. 동시에 이 약속은 개발자의 자유도를 제한할 수 있습니다. SAP의 데이터 모델과 권한 체계, 클라우드 전환 로드맵, 파트너 런타임에 맞춰야 하기 때문입니다.
이것은 새로운 형태의 플랫폼 락인입니다. 과거 ERP 락인은 데이터와 프로세스에서 왔습니다. 에이전트 시대의 락인은 데이터, 프로세스, 모델 선택, 워크플로 빌더, 런타임, 감사 로그까지 포함합니다. 반대로 말하면, 기업이 이 락인을 감수할 만큼 충분한 신뢰성과 생산성을 얻는다면 SAP은 AI 시대에도 핵심 업무 계층을 지킬 수 있습니다. 실패하면 Joule은 또 하나의 비싼 챗봇으로 남을 수 있습니다.
개발팀이 봐야 할 질문은 세 가지입니다. 첫째, 에이전트가 실제 업무 트랜잭션을 실행할 때 실패를 어떻게 되돌리는가. 둘째, 에이전트가 사용한 데이터와 판단 근거를 감사 가능한 형태로 남기는가. 셋째, 특정 모델이나 파트너가 바뀌어도 에이전트 워크플로와 정책이 유지되는가. 이 질문에 답하지 못하면 엔터프라이즈 에이전트는 데모를 넘어가기 어렵습니다.
SAP 커뮤니티의 반응은 신중합니다
공식 발표는 강합니다. 그러나 커뮤니티 반응은 더 복잡합니다. Reddit r/SAP의 Sapphire 2026 키노트 recap 글에서는 이번 발표를 SAP이 전통적 소프트웨어 회사에서 비즈니스 AI 운영 계층으로 이동하려는 신호로 해석하는 의견이 있었습니다. 동시에 "경영 컨설팅식 방향 찾기"라는 냉소적 반응과, 과거 SAP이 클라우드 전환을 크게 약속했던 경험을 떠올리는 회의론도 함께 보였습니다.
이 반응은 중요합니다. SAP 고객과 실무자는 새로운 비전에 익숙합니다. 대형 엔터프라이즈 벤더의 발표는 언제나 포괄적이고 장기적입니다. 현장의 질문은 다릅니다. 지금 쓰는 ECC와 S/4HANA 환경에서 무엇이 언제 가능해지는가, 커스터마이징이 많은 조직도 쓸 수 있는가, 기존 권한 모델과 충돌하지 않는가, 컨설팅 비용이 얼마나 늘어나는가, 실제 업무 시간이 줄어드는가입니다.
SAP은 이 의심을 알고 있는 듯합니다. 발표에는 RISE with SAP와 GROW with SAP에 Joule Assistants 접근을 포함하고, SAP S/4HANA on-premises와 SAP ECC 고객도 클라우드 ERP 전환을 약속하면 일부 AI 시나리오에 접근할 수 있다는 내용이 들어 있습니다. 즉 AI 혁신은 클라우드 전환 로드맵과 강하게 묶입니다. 이 점은 SAP 입장에서는 합리적입니다. 오래된 온프레미스 커스터마이징 환경에 자율 에이전트를 안정적으로 넣기는 어렵기 때문입니다. 그러나 고객 입장에서는 AI가 또 다른 전환 압박으로 느껴질 수 있습니다.
경쟁은 ERP 안팎에서 동시에 벌어집니다
SAP만 이 방향으로 가는 것은 아닙니다. Salesforce는 Agentforce를 CRM과 업무 데이터에 붙이고, ServiceNow는 IT와 운영 프로세스 안에서 AI agents를 밀고 있으며, Microsoft는 Copilot Studio와 Microsoft 365, GitHub, Azure를 연결합니다. UiPath는 자동화 런타임과 거버넌스를 코딩 에이전트에 붙이려 하고, Honeycomb은 에이전트가 프로덕션에서 무엇을 했는지 보는 관측성 계층을 만들고, Endor는 코딩 에이전트와 패키지 공급망의 보안 통제를 강조합니다.
SAP의 차별점은 시스템 오브 레코드입니다. 재무 마감, 조달 승인, 공급망 예외, HR 정책, 고객 서비스 프로세스처럼 기업 운영의 깊은 곳에 있는 업무는 SAP 위에 놓인 경우가 많습니다. 에이전트가 이런 업무를 실제로 수행한다면 SAP은 강력한 위치에 있습니다. 반대로 이 깊이가 도입 난도가 됩니다. CRM이나 협업 도구보다 변경 비용이 크고, 실수의 비용도 큽니다. 엔터프라이즈 에이전트의 승부는 "누가 더 멋진 데모를 보여주는가"가 아니라 "누가 더 위험한 업무를 더 안전하게 자동화하는가"가 될 가능성이 큽니다.
SAP은 Autonomous Close Assistant 예시를 들었습니다. 재무 마감 과정을 주 단위에서 일 단위로 줄이고, journal entries, reconciliation, error resolution을 자동화한다는 설명입니다. 이런 사례가 실제로 작동하면 기업은 강한 ROI를 느낄 수 있습니다. 하지만 이 영역은 감사와 내부 통제가 가장 강한 곳이기도 합니다. 에이전트가 제안한 분개를 누가 승인했는지, 어떤 데이터에 근거했는지, 오류 발생 시 어떤 책임 경로를 타는지 명확해야 합니다. 바로 이 때문에 SAP은 거버넌스와 OpenShell 같은 실행 안전 계층을 앞세웁니다.
결론
SAP의 Autonomous Enterprise 발표는 AI 업계의 익숙한 에이전트 열풍을 ERP와 기업 업무의 중심부로 끌고 들어간 사건입니다. 발표에는 과장도 있고, 실제 도입까지 넘어야 할 장벽도 많습니다. 하지만 방향 자체는 중요합니다. AI 에이전트는 더 이상 채팅창에서 답을 주는 도구로만 평가되지 않습니다. 이제는 업무 시스템 안에서 데이터를 읽고, 프로세스를 움직이고, 정책 안에서 행동하고, 감사 가능한 흔적을 남길 수 있어야 합니다.
SAP이 유리한 지점은 비즈니스 맥락입니다. SAP 고객의 핵심 데이터와 프로세스는 이미 SAP 안에 있습니다. SAP이 불리한 지점도 같은 곳입니다. 그 환경은 복잡하고, 느리며, 규제가 많고, 고객별로 다릅니다. 따라서 이번 발표의 성패는 Claude나 OpenShell 같은 파트너 이름보다, SAP이 이 복잡성을 얼마나 제품 안에서 흡수하느냐에 달려 있습니다.
개발자와 AI 팀이 지금 봐야 할 것은 "SAP도 AI를 한다"가 아닙니다. 에이전트 플랫폼의 경쟁 기준이 바뀌고 있다는 점입니다. 앞으로 중요한 질문은 어떤 모델이 가장 똑똑한가만이 아닙니다. 어떤 플랫폼이 업무 의미를 이해하고, 어떤 런타임이 실행을 제한하고, 어떤 거버넌스가 책임을 남기며, 어떤 생태계가 실제 기업 프로세스를 바꿀 수 있는가입니다. SAP은 그 질문에 ERP 회사다운 답을 내놓았습니다. 이제 남은 것은 고객 현장에서 그 답이 비용과 리스크를 넘어설 만큼 작동하는지 확인하는 일입니다.
출처
- SAP News Center: SAP Unveils the Autonomous Enterprise
- SAP News Center: SAP and Anthropic Plan to Bring Claude to SAP Business AI Platform
- SAP News Center: SAP and NVIDIA Co-Define Enterprise-Grade Agent Execution
- NVIDIA Blog: NVIDIA and SAP Bring Trust to Specialized Agents
- SiliconANGLE: SAP recasts Joule as the front door to autonomous enterprise AI
- Reddit r/SAP: SAP Sapphire 2026 Keynote Recap