SAP가 Claude, NVIDIA를 사자, 30년 해자가 드러났다

Eleanor · May 18, 2026, 11:58am

지난 5월 12일 SAP Sapphire 2026에서 SAP은 Autonomous Enterprise 비전을 공개했습니다. 50+ Joule Assistants가 200+ Joule Agents를 오케스트레이션, foundation 모델로 Anthropic Claude 채택, NVIDIA OpenShell이 보안 런타임, Palantir가 산업 데이터 레이어. non-SAP 시스템 통합은 MCP 표준.

대부분의 글로벌 헤드라인은 “SAP × Anthropic” 조합에 몰렸습니다. 그런데 이 발표를 이 조합으로 읽게 되면, SAP의 진짜 베팅을 놓치게 됩니다. SAP은 Claude·NVIDIA·Palantir 셋 다 commodity로 다뤘고, 차별화 자산은 200+ Joule Agents 안에 인코딩된 30년치 ERP 운영 패턴에 있습니다.

TL;DR

commodity와 차별화의 분리: SAP은 foundation 모델(Claude), 보안 런타임(OpenShell), 데이터 레이어(Palantir) 셋 다 단독 lock-in 없이 commodity로 다뤘습니다. foundation 모델 자체를 만들지 않겠다는 의사결정이고, 이건 OpenAI도 Microsoft도 Salesforce도 안 한 베팅입니다.
30년 자산의 모듈화: 200+ Joule Agents의 의미는 SAP이 1972년 창업 이후 글로벌 대기업의 재무, 공급망, HR, CRM, 영업 운영 데이터를 모듈화한 결과물이라는 점입니다. Claude·OpenShell·Palantir가 외부 부품이라면, 200+ Agents 안의 도메인 패턴이 SAP만의 자산입니다.
한국 SI의 정렬 가능 자리: SAP Joule Agents가 글로벌 평균 운영 패턴이라면 한국 SI는 한국 컨텍스트 운영 레이어(결재 시스템, 그룹웨어, K-ISMS, 한국 회계 기준)를 위에 얹을 수 있는 영역이 보입니다. 단순 SAP 재판매가 아닌 새 자리예요.

1. SAP은 셋 다 commodity로 다뤘다

발표를 자세히 읽어보면 SAP의 의사결정 패턴이 명확합니다.

foundation 모델: Anthropic Claude를 채택했지만 단독이 아닙니다. SAP은 발표 자료에서 Claude를 "foundation models 중 하나"로 명시했어요. Claude 외에도 다른 모델을 채택하거나 교체할 수 있는 구조라는 의미입니다. 모델 자체를 만드는 건 수십억 달러 비용이 드는데, SAP은 그 길로 가지 않겠다고 선언한 거죠.

보안 런타임: NVIDIA OpenShell이 200+ Agents의 실행 환경을 담당합니다. 권한 정의, 데이터 접근 제어, 보안 경계가 OpenShell에 위임됐어요. 이것도 SAP이 자체 개발하지 않고 NVIDIA에 맡긴 영역입니다.

산업 데이터 레이어: Palantir가 산업별 데이터 통합을 담당합니다. SAP은 데이터 통합 자체를 자기 핵심 자산으로 가져가지 않고 Palantir에 맡겼어요.

세 영역 모두 SAP이 자체 개발 가능했을 텐데 외부에서 가져왔습니다. 이게 우연이 아니라 명확한 의사결정이라고 봐야 합니다. SAP은 자신이 진짜 잘 아는 영역(도메인 운영 패턴)에 집중하고 나머지는 commodity로 처리하겠다는 베팅을 한 거예요.

2. 200+ Joule Agents 안에 무엇이 들어있나

그렇다면 SAP이 진짜 자산으로 본 게 무엇인지가 핵심입니다.

200+ Joule Agents는 단순 AI 챗봇 기능 추가가 아닙니다. 각 Agent는 SAP이 1972년 창업 이후 글로벌 대기업과 일하면서 본 특정 도메인의 운영 패턴을 모듈화한 것입니다. 재무 마감(Autonomous Close Assistant가 weeks→days로 압축한다는 약속), 공급망 최적화, HR 프로세스, 영업 사이클 관리 등 각 영역마다 SAP은 누구보다 많은 기업 운영 데이터를 봤습니다.

이 lived experience를 Agent 안에 인코딩하는 게 200+라는 숫자의 의미예요. Claude는 일반 언어 모델, OpenShell은 일반 런타임, Palantir는 일반 데이터 통합. 다 외부에서 살 수 있는 commodity입니다. 그런데 "글로벌 대기업이 재무 마감을 어떻게 하는지 정확한 패턴"은 SAP만 가지고 있어요.

이게 SAP의 진짜 자산입니다. 차별화는 모델도 런타임도 데이터도 아닌, 도메인 expertise 모듈에 있는 거죠.

3. 다른 ERP 벤더가 같은 길로 갈 수 있을까

이 분석이 맞다면 흥미로운 질문이 따라옵니다. Oracle, Workday, Salesforce가 같은 베팅을 할 수 있을까요.

Oracle은 자체 클라우드와 자체 데이터베이스 자산이 있어서 commodity로 다루기보다 자기 인프라로 가져가는 경향이 강합니다. Workday는 HR·재무 영역에서는 SAP과 비슷한 도메인 expertise 자산을 가졌지만 ERP 전 영역을 커버하지 않아요. Salesforce는 CRM·고객 데이터 영역에선 강하지만 ERP 핵심 영역(재무, 공급망)은 SAP보다 얕습니다.

SAP만 ERP 전 영역에서 30년치 운영 데이터를 모듈화할 수 있는 위치에 있는 거예요. 200+라는 숫자가 의미하는 게 그것입니다. 다른 벤더가 비슷한 발표를 하더라도 Agent 수와 깊이에서 차이가 날 가능성이 큽니다.

다만 검증 시점은 아닙니다. Joule Agents가 진짜 expertise를 정확히 인코딩한 건지, 마케팅 wrapper인지는 6-12개월 후 운영 데이터로 확인돼야 합니다. 글로벌 대기업이 실제로 자동화된 운영을 신뢰하느냐가 핵심 시험대인 것이죠.

4. 운영 레이어 thesis가 ERP에서도 작동

지난 분석들에서 짚어 온 패턴이 이번에도 같습니다. 원자재가 commodity로 떨어지는 동안 그 위 운영 레이어가 새 마진 영역이 됩니다.

지난 IREN-Mirantis 분석에서 GPU 자체가 commodity로 떨어지는 동안 운영 레이어(Mirantis)가 새 마진이 된다고 짚었습니다. Backstage 분석에서도 OSS 자체가 commodity로 떨어지는 동안 운영 레이어(Roadie, Port, Cortex)가 마진을 만든다고 정리했어요. 이번 SAP 사례도 같은 패턴입니다.

AI 시대 ERP에서의 layer 구조는 이렇게 정리됩니다.

commodity (가장 아래): foundation 모델(Claude, GPT, Gemini 등)
인프라 (중간): 보안 런타임(OpenShell), 데이터 레이어(Palantir), 통합 표준(MCP)
운영 레이어 (위): 도메인 expertise 모듈(SAP의 200+ Joule Agents)
결과물: Autonomous Enterprise UI(Joule Work)

SAP은 자신을 운영 레이어 정의자로 재포지셔닝하고 있습니다. 다른 ERP 벤더가 따라올 수 있는 자리는 인프라(중간 레이어)이지만, 운영 레이어는 도메인 데이터 자산이 없으면 만들 수 없는 영역입니다. SAP의 moat가 여기에 있어요.

5. 한국 SI는 무엇을 해야하는가?

한국 대기업 SI는 SAP 도입을 오랫동안 "글로벌 표준 ERP 도입"으로 프레임해 왔습니다. SI 입장에서 SAP 라이선스 재판매와 구축 컨설팅이 매출 모델이었거든요. AI 시대에 이 frame이 약해집니다. SAP Autonomous Enterprise가 가져오는 가치는 ERP 자체가 아니라 200+ Joule Agents 안에 인코딩된 글로벌 운영 패턴이에요.

한국 대기업 도입 시 검토해야 할 새 질문은 이렇게 바뀝니다. “Joule Agents 안의 운영 패턴이 한국 비즈니스 컨텍스트에 맞는가.” 글로벌 평균 운영 패턴이 한국 SI/대기업 결재 시스템, 한국형 그룹웨어, K-ISMS 통합, 한국 회계 기준(K-IFRS), 한국 노동법 기반 HR 프로세스에 정확히 맞을 가능성은 낮습니다.

여기에 한국 SI가 안착할 수 있는 영역이 보입니다. SAP Joule Agents 위에 한국 컨텍스트 운영 레이어를 얹는 자리예요. 단순 SAP 재판매가 아니라 SAP commodity 위에 한국 도메인 expertise를 자체 모듈화하는 구조입니다. SAP이 글로벌 패턴 인코더라면, 한국 SI는 한국 패턴 인코더로 자리 잡을 수 있는 시점이에요.

세 가지 구체 경로가 있습니다. 첫째, 한국 컨텍스트 Joule Agents 자체 개발. SAP과 파트너십 맺어 한국 특화 Agent를 SAP 생태계 안에 공급하는 길. 둘째, 한국 통합 레이어 솔루션. Joule Agents 출력을 한국 결재·그룹웨어·K-ISMS와 연결하는 미들웨어 솔루션. 셋째, 한국 도메인 자체 Agent 생태계. SAP 모델을 참고하되 한국 SI가 자체 도메인 expertise를 인코딩한 독립 Agent 플랫폼.

세 경로 중 한국 SI 자산과 가장 정렬되는 건 둘째와 셋째예요. 셋째가 가장 큰 그림이지만 SAP과의 경쟁 부담이 크고, 둘째가 단기 정렬 가능한 자리입니다.

6. 오늘의 체크리스트

SAP 도입 검토 조직: foundation 모델(Claude, GPT 등) 선택이 아니라 200+ Joule Agents 안의 도메인 운영 패턴이 자기 비즈니스 컨텍스트에 맞는지를 평가 기준으로. 모델 lock-in 우려는 SAP이 이미 commodity로 다뤘으니 약화
AI 에이전트 인프라 의사결정자: foundation 모델, 런타임, 데이터 레이어를 commodity로 가정. 차별화는 어떤 expertise를 모듈화하느냐에 있음. 자기 조직이 인코딩할 수 있는 도메인 자산이 무엇인지 명확히 정의
한국 SI Pre Sales: SAP 재판매 frame 재검토. SAP Agents 위 한국 컨텍스트 운영 레이어를 자체 자산으로 설계할 수 있는 영역 탐색. 단기 매출보다 5년 자산 구축 관점에서 의사결정
ERP·기업 SW 시장 분석가: SAP의 commodity vs differentiation 분리 베팅을 Oracle, Workday, Salesforce 후속 발표와 비교 추적. 6-12개월 안에 다른 벤더가 같은 길로 갈지 다른 길로 갈지가 시장 구조 결정
CFO·경영진: AI 투자 ROI 평가에서 foundation 모델 라이선스 비용보다 도메인 expertise 인코딩 자산을 별도 항목으로 추적. 단기 비용보다 5년 누적 자산 관점

알고 보면 좋은 분석 포인트

이 글의 분석 포인트는 세 가지입니다.

SAP은 셋 다 commodity로 다뤘다는 점을 짚었습니다. Claude는 채택한 foundation 모델 중 하나, OpenShell은 외부 보안 런타임, Palantir는 외부 데이터 레이어. SAP은 자체 개발 가능했을 영역들을 의도적으로 외부에 맡기고 자신은 도메인 expertise 인코딩에 집중하는 선택을 했어요. 이게 OpenAI도 Microsoft도 안 한 베팅이지요. foundation 모델 만들기 경쟁에서 빠지고, 자기가 진짜 잘 아는 영역에 집중하는 의사결정이거든요.
30년치 ERP 운영 데이터가 200+ Agents 안에 모듈화됐다는 점이 핵심 자산입니다. Claude·OpenShell·Palantir는 시장에서 살 수 있지만, "글로벌 대기업이 재무 마감을 어떻게 하는지 정확한 패턴"은 SAP만 가지고 있어요. 이게 commodity와 차별화를 분리하는 베팅의 토대인 것이지요. 다만 200+ Agents가 진짜 expertise를 정확히 인코딩한 건지, 마케팅 wrapper인지는 6-12개월 운영 데이터로 검증돼야 합니다. 명제 자체는 강하지만 검증 시점은 아니에요.
한국 SI에게 정렬 가능한 자리가 운영 레이어 위 한국 컨텍스트 운영 레이어라는 점입니다. 단순 SAP 재판매가 아니라 SAP commodity 위에 한국 도메인 expertise를 자체 모듈화하는 구조예요. 한국 SI Pre Sales 패턴이 단기 매출 중심에서 5년 자산 구축 중심으로 재설계되면 SAP 발표가 위협이 아닌 기회로 작동합니다. 비판 직접 톤으로 짚었지만, 한국 SI의 platform engineering 신뢰도를 보호하는 방향이라고 봅니다.

이 분석을 정리하다가 한 가지가 떠올랐습니다. 얼마 전 @Christian_Dussol 이 자신의 시리즈 “From Prompts to Packages” Part 5에서 정리한 명제가 있었어요. “The model is the processor. MCP is the bus. Skills are the applications.” 모델은 프로세서, MCP는 버스, Skills는 애플리케이션. 한 명의 platform engineer가 Kyverno governance 영역에서 세 개 Skill을 빌드하며 도달한 통찰이었습니다. 그 글에서 Dussol이 CloudBro를 헌사로 언급해 주셨는데, 오늘 SAP 분석을 정리하다가 같은 명제가 글로벌 ERP 벤더 스케일에서 어떻게 작동하는지 보였습니다. 작은 스케일 검증과 글로벌 베팅이 같은 방향이라는 게 흥미롭더라구요