SAP Business AI Platform 공개: ERP 에이전트 시대를 준비하는 방법
SAP Sapphire 2026 발표를 국내 SAP 사용자 관점에서 다시 정리했습니다.
SAP Business AI Platform 공개: ERP 에이전트 시대를 준비하는 방법
SAP Business AI Platform autonomous enterprise 발표는 새 챗봇 하나를 더한다는 이야기보다 SAP BTP, SAP Business Data Cloud, SAP Business AI/AI Foundation을 묶어 ERP 맥락을 이해하는 기업용 AI 에이전트 기반을 만들겠다는 쪽에 가깝습니다.
SAP은 2026년 5월 SAP Sapphire에서 SAP Business AI Platform을 자율형 엔터프라이즈 전략의 중심에 놓았습니다. 제가 보기에는 제품명보다 구조가 더 중요합니다. AI가 ERP 화면 옆에서 답만 주는 단계에서, 업무 데이터·프로세스·권한·거버넌스를 이해한 뒤 제한된 범위에서 제안하거나 실행하는 방향으로 SAP의 설명이 이동했기 때문입니다.
한국 사용자 입장에서는 이 발표를 "우리 회사도 곧바로 완전 자동화되는가"로 읽으면 곤란합니다. 공식 자료에는 일반 제공, Early Adopter Care, Q3 2026 계획, H2 2026 계획이 함께 들어 있습니다. 지금은 구매 결정보다 먼저 현재 S/4HANA, SAP BTP, 데이터 거버넌스, 승인 흐름이 에이전트를 받아들일 만큼 정리되어 있는지 살피는 쪽이 현실적입니다.
> 실무적으로는 AI 기능 추가보다 ERP 자동화의 책임 범위를 다시 그리는 발표에 가깝습니다.
이 글은 SAP Business AI Platform autonomous enterprise 발표를 국내 SAP 사용자와 엔터프라이즈 개발자 관점에서 다시 정리한 글입니다. 무엇이 발표됐는지, 기존 BTP와 무엇이 다른지, 어떤 업무부터 시험해야 하는지, 아직 도입을 미뤄야 할 조건은 무엇인지 순서대로 보겠습니다.
SAP Sapphire 2026 발표 타임라인: 무엇이 언제 나왔나
2026년 5월 12일 SAP은 Autonomous Enterprise와 SAP Business AI Platform을 공식 발표했고, 5월 13일 키노트 보도에서 이를 ERP 에이전트 전략의 기반으로 설명했습니다. 다만 SAP Domain Models와 일부 Business Data Cloud 생태계 기능은 예정 일정이 있어 현재 기능과 분리해서 읽어야 합니다.
이 발표는 하루짜리 제품 공지가 아니라 여러 공식 글에 나뉘어 나왔습니다. 날짜를 나눠 보면 무엇이 현재 기능이고 무엇이 로드맵인지 조금 덜 헷갈립니다.
| 날짜 | 발표 내용 | 읽을 때의 기준 |
|---|---|---|
| 2026-05-12 | SAP이 Autonomous Enterprise와 SAP Business AI Platform을 공식 발표 | 플랫폼 전략의 출발점 |
| 2026-05-12 | SAP과 NVIDIA가 OpenShell 기반의 안전한 에이전트 실행 방향을 설명 | 샌드박스, 정책 통제, 감사 가능성 확인 |
| 2026-05-13 | SAP Sapphire 키노트 보도에서 Business AI Platform을 ERP 맥락형 AI 기반으로 설명 | 이 글에서 가장 많이 참조한 원문 |
| 2026-05-13 | SAP Korea가 한국어 발표를 게시 | 국내 독자의 용어 확인에 유용 |
| 2026-05-13 | Joule Studio, SAP BDC, SAP Domain Models 관련 상세 글이 공개 | 개발·데이터·로드맵을 나눠 확인 |
실제로 확인할 부분은 "발표됨"과 "우리 테넌트에서 바로 운영 가능함"의 차이입니다. 예를 들어 SAP AI Agent Hub는 일반 제공으로 언급되지만, SAP Domain Models는 Early Adopter Care와 Q3 2026 일반 제공 계획을 같이 봐야 합니다. SAP Business Data Cloud의 오픈 데이터 생태계 확장에도 H2 2026 계획이 포함되어 있습니다.
따라서 이 플랫폼을 도입 검토 안건으로 올릴 때는 제품명보다 기능별 가용성 표를 먼저 만드는 편이 낫습니다. SAP 담당자나 파트너에게 던질 질문도 "있습니까"가 아니라 "우리 리전, 라이선스, 테넌트, 데이터 소스에서는 어느 범위까지 가능한가"에 가까워야 합니다.
무엇이 달라졌나: BTP, Business Data Cloud, AI Foundation을 한 플랫폼으로 묶는 이유
이번 변화는 SAP가 AI를 개별 앱의 부가기능이 아니라 ERP 데이터와 업무 프로세스를 이해하는 운영 플랫폼으로 재배치했다는 데 있습니다. BTP는 확장·운영 기반, Business Data Cloud는 데이터 기반, Joule Studio와 AI Foundation은 에이전트 개발·실행 경험에 가깝습니다.
SAP Business AI Platform이라는 이름만 보면 완전히 별개의 새 제품처럼 느껴질 수 있습니다. 다만 SAP의 설명을 따라가면 기존의 BTP, Business Data Cloud, Business AI, AI Foundation을 하나의 아키텍처로 묶어 에이전트가 업무 맥락을 잃지 않게 하겠다는 쪽에 더 가깝습니다.
| 구성요소 | 이 발표에서의 역할 | 도입 전 확인할 것 |
|---|---|---|
| SAP BTP | 확장, 통합, 운영 기반 | 글로벌 계정, 서브어카운트, 서비스 권한 |
| SAP Business Data Cloud | 에이전트가 참조할 신뢰 데이터 기반 | 데이터 제품, 마스터 데이터, 외부 데이터 연결 범위 |
| SAP AI Core / AI Foundation | AI 자산 실행과 운영 계층 | generative AI hub, 모델 접근, 프롬프트·런타임 관리 |
| Joule Studio | 에이전트와 스킬을 만들고 관리하는 개발 경험 | agent builder, skill builder, CLI, MCP 서버 설정 가능 여부 |
| SAP Knowledge Graph | ERP 객체와 관계를 설명하는 의미 계층 | 업무 객체, 권한, 프로세스 관계의 품질 |
제가 보기에는 여기서 가장 큰 메시지가 "AI 모델을 무엇으로 고를까"가 아닙니다. 오히려 "AI가 읽을 수 있는 회사의 업무 지도를 갖고 있는가"에 가깝습니다. 일반 LLM은 문서를 요약할 수 있지만, ERP 에이전트는 공급업체, 구매오더, 전표, 승인권자, 예외 규칙의 관계를 알아야 합니다.
SAP Business AI Platform 도입 논의가 시작되면 개발팀만 부르는 것으로는 부족합니다. 아키텍처, 보안, 재무, 구매, 데이터 거버넌스 담당자가 같이 들어와야 합니다. 에이전트가 어떤 데이터를 읽는지, 어떤 추천은 허용되는지, 어떤 실행은 사람 승인 뒤에만 가능한지를 처음부터 나눠야 합니다.
의미 계층: SAP Knowledge Graph와 SAP Domain Models가 하는 일
SAP Knowledge Graph와 SAP Domain Models는 에이전트가 단순 텍스트가 아니라 고객, 공급업체, 전표, 주문, 승인 같은 ERP 업무 객체와 관계를 이해하도록 돕는 의미 계층입니다. 특히 SAP Domain Models는 Early Adopter Care와 Q3 2026 일반 제공 계획을 함께 확인해야 합니다.
AI 에이전트가 ERP에서 쓸모 있으려면 테이블명 몇 개를 아는 수준으로는 부족합니다. 예를 들어 "이 공급업체 지급이 왜 지연됐는가"라는 질문에는 송장, 구매오더, 검수, 지급 조건, 승인 단계, 예외 코드가 함께 걸립니다. SAP Knowledge Graph는 이런 업무 엔티티와 관계를 구조화해 에이전트가 맥락을 놓치지 않게 돕는 장치로 설명됩니다.
SAP Domain Models는 한 단계 더 구체적인 흐름입니다. SAP은 이 모델들이 SAP 코드, 고객 데이터, 메타데이터, 비즈니스 프로세스에 기반한다고 설명합니다. 하지만 현재 글을 쓰는 시점에는 Early Adopter Care와 Q3 2026 일반 제공 계획을 함께 언급해야 합니다. "이미 모든 고객이 같은 방식으로 쓰는 기능"이라고 단정하기 어렵습니다.
한국 기업이 여기서 먼저 볼 부분은 마스터 데이터입니다. 벤더 코드가 중복되어 있고, 제품 계층이 오래된 조직도 기준으로 남아 있고, 승인 흐름이 현업 예외 처리에 기대고 있다면 에이전트는 그 혼란까지 같이 가져갑니다. 모델 성능만큼이나 데이터 의미가 얼마나 정리되어 있는지가 결과를 좌우합니다.
왜 중요한가: 일반 LLM과 ERP 에이전트의 차이
ERP 에이전트는 질문에 답하는 것보다 권한, 승인, 감사, 데이터 출처를 지키며 업무를 제안하거나 실행하는 것이 중요합니다. SAP의 메시지는 깨진 데이터 모델 위에 AI를 얹기보다 비즈니스 의미 계층과 거버넌스 위에서 에이전트를 운영하자는 쪽입니다.
일반 LLM 도입은 보통 문서 요약, 번역, 검색 보조에서 시작합니다. 반면 SAP ERP AI 에이전트는 실수의 비용이 훨씬 큽니다. 잘못된 답변 하나보다 잘못된 구매오더, 잘못된 지급 추천, 승인 없는 전표 게시가 더 큰 문제입니다.
SAP은 50개 이상의 도메인별 Joule Assistants와 200개 이상의 전문 에이전트를 언급했습니다. 재무 영역에서는 Autonomous Close Assistant를 예로 들며 전표, 대사, 오류 해결을 자동화해 마감 흐름을 줄이는 시나리오도 제시했습니다. 다만 이 사례를 모든 고객의 보장 효과로 읽으면 안 됩니다. 데이터 품질, 프로세스 범위, 권한 설계, 구현 수준에 따라 결과가 달라집니다.
여기서 조심할 점은 "에이전트가 얼마나 똑똑한가"보다 "에이전트가 어디까지 해도 되는가"가 먼저라는 사실입니다. SAP과 NVIDIA의 OpenShell 협력도 샌드박스, 파일시스템·네트워크 접근 정책, 런타임 격리, 감사 가능성 같은 실행 통제를 강조합니다. 엔터프라이즈 AI에서 중요한 것은 멋진 데모가 아니라 문제가 생겼을 때 누가 멈추고, 어디까지 되돌리고, 어떤 로그로 설명할 수 있는가입니다.
도입 전 시뮬레이션: 첫 테스트는 어디서 시작할까
첫 테스트는 전표 생성, 지급, 벤더 마스터 변경처럼 위험한 실행 작업보다 문서 검색, 조달 문의 응답, 공급업체 리스크 요약, 비게시 재무 대사 보조처럼 사람이 검토할 수 있는 저위험 업무가 적합합니다. 테넌트 권한, Joule Studio 접근, SAP BTP 서비스, SAP Business Data Cloud 연결 가능 여부를 먼저 확인해야 합니다.
SAP Business AI Platform 도입을 검토한다면 처음부터 "자율 실행"을 목표로 잡지 않는 편이 낫습니다. 제가 추천하는 첫 파일럿은 읽기 중심, 추천 중심, 승인 대기 중심입니다.
1. SAP BTP 글로벌 계정과 서브어카운트에서 필요한 서비스 권한을 확인합니다.
2. Joule Studio의 agent builder, skill builder, code editor, Joule Studio CLI 접근 가능 여부를 확인합니다.
3. SAP Business Data Cloud 또는 승인된 문서 저장소에서 작은 데이터 범위를 고릅니다.
4. 첫 업무는 조달 문서 조회, 내부 정책 Q&A, 공급업체 리스크 요약, 비게시 재무 대사 보조 중 하나로 제한합니다.
5. 에이전트 응답에는 출처, 사용 데이터, 사람이 승인할 단계, 실행 금지 범위를 남깁니다.
이 흐름은 설치형 오픈소스 도구의 `npm install`과 다릅니다. SAP Business AI Platform autonomous enterprise는 기업 테넌트, 라이선스, 권한, 데이터 연결, 감사 정책이 붙는 플랫폼 업데이트입니다. 실제 첫 단계는 명령어 실행이 아니라 SAP 계정팀 또는 파트너와 테넌트별 가능 범위를 확인하는 일입니다.
작게 성공을 보려면 "에이전트가 정답을 맞혔는가"보다 "허용된 데이터만 읽었는가", "모르는 내용을 꾸며내지 않았는가", "승인이 필요한 지점에서 멈췄는가"를 봐야 합니다. 이 세 가지가 흔들리면 더 큰 자동화로 넓히기 어렵습니다.
운영 모델: 읽기, 추천, 실행 범위를 나눠야 한다
SAP Business AI Platform 도입은 에이전트가 무엇을 읽을 수 있는지, 무엇을 추천만 하는지, 어떤 작업은 사람 승인 뒤 실행하는지를 분리하는 데서 시작해야 합니다. 각 행동은 SAP 역할, 승인 정책, 감사 로그, 데이터 분류와 연결되어야 합니다.
에이전트 운영 정책은 간단한 3단계로 나누면 실무 대화가 쉬워집니다.
| 범위 | 예시 | 운영 원칙 |
|---|---|---|
| 읽기 | 구매계약, 송장, 정책 문서 조회 | 허용 데이터 소스와 로그를 고정 |
| 추천 | 공급업체 리스크 요약, 마감 오류 원인 제안 | 사람이 검토하고 수정 가능해야 함 |
| 실행 | 전표 게시, 벤더 변경, 지급 요청 | 첫 파일럿에서 제외하거나 승인·롤백 필수 |
이 표를 두고 업무별로 표시해 보면 논쟁이 줄어듭니다. 현업은 "빨리 자동화"를 말하고, 보안팀은 "막아야 한다"고 말하기 쉽습니다. 하지만 어떤 행동은 읽기만 허용하고, 어떤 행동은 초안 작성까지만 허용하며, 어떤 행동은 결재 뒤 표준 SAP/Fiori 프로세스로 넘긴다고 합의하면 파일럿 범위가 선명해집니다.
운영 중에는 릴리스 타이밍도 봐야 합니다. SAP Domain Models의 Q3 2026 계획, SAP Business Data Cloud 오픈 생태계의 H2 2026 계획처럼 일정이 붙은 기능은 프로젝트 계획에 게이트로 넣어야 합니다. 한국 리전 가용성, 가격, 고객별 라이선스도 공식 발표만으로 확정할 수 없으므로 별도 확인 항목으로 남기는 편이 안전합니다.
스킵 조건과 리스크: 아직 도입하지 말아야 할 경우
권한 모델, 승인 흐름, 감사 로그, 마스터 데이터 품질, 데이터 소유자가 정리되지 않았다면 자율 실행형 에이전트 도입은 미루는 편이 낫습니다. 결제, 급여, 법적 약정, 개인정보, 직접 전표 게시 같은 고위험 업무는 human-in-the-loop와 롤백 계획 없이는 첫 파일럿으로 삼지 않는 것이 안전합니다.
흥미로운 발표인 것은 맞지만 모든 조직에 같은 속도로 맞지는 않습니다. 특히 기존 ERP 권한이 사람 중심으로만 설계되어 있고, SoD 통제가 문서상으로만 남아 있으며, 감사 로그가 여러 시스템에 흩어져 있다면 에이전트는 운영 리스크를 키울 수 있습니다.
스킵하거나 미뤄야 할 조건은 비교적 명확합니다. SAP BTP 서비스 권한과 Joule Studio 접근을 확인할 수 없거나, SAP Business Data Cloud에 연결할 신뢰 데이터 범위가 없거나, 마스터 데이터 중복과 의미 불일치를 해결할 책임자가 없다면 파일럿부터 다시 설계해야 합니다. 결제, 벤더 마스터 변경, 급여, 법적 계약, 규제 개인정보 처리, 직접 전표 게시도 첫 실험으로는 무겁습니다.
반대로 이미 S/4HANA 전환, 클린 코어, BTP 확장, 데이터 거버넌스를 준비 중인 기업이라면 이번 발표를 로드맵 점검용으로 쓸 만합니다. "어떤 에이전트를 살까"보다 "우리 데이터와 프로세스가 에이전트에게 설명 가능한가"를 묻는 편이 더 실용적입니다.
자주 묻는 질문
Q. SAP Business AI Platform은 기존 SAP BTP와 무엇이 다른가요?
A. SAP BTP를 대체한다기보다 SAP BTP, SAP Business Data Cloud, SAP Business AI/AI Foundation을 묶어 ERP 맥락형 에이전트를 만들고 운영하는 상위 아키텍처로 보는 편이 맞습니다. BTP는 여전히 확장·통합·운영 기반이고, 새 발표는 그 위에 데이터·AI·거버넌스를 더 강하게 연결한 방향입니다.
Q. SAP Business AI Platform autonomous enterprise는 지금 모든 SAP 고객이 바로 쓸 수 있나요?
A. 그렇게 단정하면 안 됩니다. 공식 발표에는 일반 제공 기능, Early Adopter Care, Q3 2026 계획, H2 2026 계획이 섞여 있습니다. 고객별 라이선스, 리전, 테넌트 권한, SAP BTP 서비스, Joule Studio 접근 여부를 SAP 또는 파트너와 따로 확인해야 합니다.
Q. 첫 테스트는 어떤 업무가 적합한가요?
A. 조달 문서 검색, 내부 정책 Q&A, 공급업체 리스크 요약, 비게시 재무 대사 보조처럼 읽기와 추천 중심 업무가 좋습니다. 전표 게시, 지급 실행, 벤더 마스터 변경, 급여, 법적 계약처럼 되돌리기 어려운 업무는 첫 파일럿에서 제외하는 편이 안전합니다.
Q. SAP Knowledge Graph와 SAP Domain Models는 왜 중요한가요?
A. ERP 에이전트가 단순 문서 요약을 넘어 고객, 공급업체, 주문, 전표, 승인, 예외 규칙의 관계를 이해해야 하기 때문입니다. SAP Knowledge Graph는 비즈니스 객체와 관계를 구조화하는 역할로 설명되고, SAP Domain Models는 Early Adopter Care와 Q3 2026 일반 제공 계획을 함께 확인해야 합니다.
Q. 비SAP 데이터도 연결할 수 있나요?
A. SAP은 SAP Business Data Cloud를 통해 Snowflake, Databricks, Google BigQuery, Microsoft Fabric 같은 파트너 생태계와의 연결 방향을 설명했습니다. 다만 실제 연결 범위는 고객 환경, 라이선스, 데이터 보안 승인, 제품 가용성에 따라 달라집니다. 발표만 보고 확정하기에는 이른 부분입니다.
Q. 국내 SAP 사용 기업은 무엇부터 준비해야 하나요?
A. S/4HANA 전환 여부와 별개로 마스터 데이터 품질, 권한 모델, 승인 흐름, 감사 로그, SAP BTP 서비스 권한, SAP Business Data Cloud 연결 후보를 먼저 점검해야 합니다. 에이전트 구매보다 먼저 "AI가 읽어도 되는 데이터와 절대 실행하면 안 되는 작업"을 정하는 것이 우선입니다.
Q. 언제 도입을 미뤄야 하나요?
A. 데이터 소유자, 승인 정책, SoD 통제, 감사 로그, 롤백 계획이 없으면 미루는 편이 낫습니다. 또한 단순 문서 요약이나 일반 챗봇 수준의 요구라면 SAP ERP 맥락형 플랫폼보다 가벼운 RAG 도구나 기존 생산성 도구가 더 빠르고 저렴할 수 있습니다.
함께 읽으면 좋은 글
- Bing Copilot Answer API 등장: AI 검색 결과를 JSON으로 분석하는 방법 — AI UPDATES
- Claude 사용량 2배 확대 총정리 + Anthropic 10GW 컴퓨트 파트너십 현황 — AI UPDATES
참조 링크
- SAP Unveils Business AI Platform to Power the Autonomous Enterprise — 2026-05-13 키노트 원문으로 SAP Business AI Platform과 Autonomous Enterprise 메시지의 중심 출처입니다.
- SAP Unveils the Autonomous Enterprise — SAP Sapphire 2026 공식 발표와 Joule Assistants·전문 에이전트 수치 확인에 사용했습니다.
- SAP, SAP Sapphire 2026서 자율형 엔터프라이즈 공개 — 국내 독자용 공식 한국어 발표와 용어 확인에 참고했습니다.
- Announcing New Joule Studio for Enterprise Scale Agentic Development — Joule Studio의 에이전트 개발 경험, 개발자 도구, 파트너 생태계 설명에 참고했습니다.
- Joule Studio | AI Agent and Skill Builder — agent builder, skill builder, code editor, CLI, MCP 서버, human-in-the-loop 기능 확인에 사용했습니다.
- Accelerate the Autonomous Enterprise with SAP Business Data Cloud — SAP Business Data Cloud, HANA Cloud, 외부 데이터 생태계와 H2 2026 계획 확인에 사용했습니다.
- The Future of the Enterprise Is Autonomous — SAP Domain Models, Early Adopter Care, Q3 2026 일반 제공 계획, AI Agent Hub 관련 확인에 사용했습니다.
- Shaping the Future of Secure AI Agents: How SAP and NVIDIA Are Co-Defining Enterprise-Grade Agent Execution — NVIDIA OpenShell, 샌드박스, 정책 통제, 감사 가능성 관련 리스크 설명에 참고했습니다.
- What Is SAP AI Core? — SAP BTP 기반 AI 자산 실행과 generative AI hub 운영 계층을 설명하는 공식 문서입니다.