거버넌스, 게이트키핑이 아니라: SAP가 AI 연결성에 엔터프라이즈급 안전성을 제공하는 방법
Source: VentureBeat
번역할 전체 텍스트를 제공해 주시겠어요? 텍스트를 받으면 한국어로 번역해 드리겠습니다.
SAP 제공
엔터프라이즈 소프트웨어 산업은 근본적인 변화를 겪었으며, 벤더들은 이를 이용하는 고객을 보다 잘 보호하기 위해 접근 방식을 조정하고 있습니다. 수년 동안, 멀티테넌트 클라우드 인프라를 운영하는 모든 글로벌 플랫폼 벤더는 문서화된 속도 제한, 사용 제어 및 문서화되지 않은 내부 인터페이스 사용에 대한 제한을 유지해 왔습니다.
Typical Platform Controls
- CRM platforms – 조직당 일일 API 호출 제한, 플랫폼 계층 제한, 그리고 대량 데이터 API와 트랜잭션 REST 인터페이스 간의 엄격한 구분.
- Productivity & collaboration suites – 제한된 그래프 API; 대량 작업은 해당 부하를 위해 설계된 전용 데이터 접근 채널로 리다이렉트됩니다.
- HR & workforce‑management platforms – 동시 요청 제한 및 세션당 데이터 조회 상한.
- IT service‑management platforms – 사용자당 속도 제한 및 인스턴스 수준 제한.
- Hyperscalers – 인프라 계층에서 적용되는 서비스별 할당량 공개; SDK가 아니거나 공개되지 않은 인터페이스에 대한 호출을 명시적으로 금지.
These are baseline hygiene for enterprise‑grade software platforms operating shared infrastructure at scale. For more than a decade these measures have been in place without serious objection.
SAP의 통합 API 정책이 새로운 제한이 아닌 이유
SAP가 클라우드에서 고객의 핵심 업무 워크로드를 보호하는 책임을 맡게 되면서, 사용량 제어가 명확히 정의된 통합 API 정책은 제한이 아니라 엔터프라이즈 수준의 관리 책임을 표현하는 것입니다.
- 이 정책은 새로운 제한을 도입하는 것이 아니라, 수년간 개별 SAP 제품 전반에 걸쳐 존재해 온 제어 방식을 명명하고 통합할 뿐입니다.
- SAP는 API 거버넌스를 새롭게 만든 것이 아닙니다. SAP SuccessFactors, SAP Ariba, SAP LeanIX 등과 같은 솔루션은 이미 문서화된 속도 제한 및 사용 제어를 시행하고 있습니다.
- SAP 노트와 SAP 문서는 과거부터 API 사용에 대한 정의를 제공해 왔습니다.
최근 정책이 하는 일은 기존 관행을 통합하여 하나의 포트폴리오 전반 표준으로 만드는 것입니다. 이는 SAP가 전적으로 지원하고자 하는 자율적이고 에이전트 기반의 활용이 등장함에 따라 시급해진 조치입니다. 이러한 에이전트는 대규모 자동 오케스트레이션 및 데이터 추출을 위해 설계되지 않은 API 표면에 전혀 다른 성능, 안정성 및 보안 부하를 가합니다.
Custom Interfaces: What SAP’s API Policy Does & Does Not Restrict
Customer‑Developed APIs
- 고객이 자체 네임스페이스(Z 네임스페이스)에서 확장성, 통합 및 마이그레이션을 위해 만든 맞춤형 API는 고객 개발 인터페이스입니다.
- 정책에서 비공개 API에 대한 제한은 이러한 맞춤형 서비스에 대한 철거 명령이 아닙니다.
Scope of the Policy
- 초점은 SAP 자체 내부 인터페이스에 있으며, 이 인터페이스는 절대 공개되지 않았고, 고객 사용을 위해 문서화되지 않았으며, 통합을 위한 신뢰할 수 있는 기반으로 제공되지 않았습니다.
- 대부분의 맞춤형 코드는 이러한 내부에 접근하지 않으며 그대로 유지됩니다. 내부에 접근하는 경우에도 위험은 기존에 존재했으며, 정책은 이를 명명했을 뿐 새롭게 만든 것이 아닙니다.
Explicitly Prohibited Interfaces
- ODP‑RFC는 금지된 인터페이스의 작은 클래스에 속합니다. 이는 SAP 네임스페이스에 존재하는 내부, 비공개 인터페이스로, SAP가 고객 또는 제3자 사용을 “허용되지 않음”으로 명시한 것입니다(SAP Note 3255746 참조).
이러한 인터페이스는 노트와 자동화 도구에서 금지된 것으로 표시되어, 배포 또는 운영 단계에서 늦게 발견되는 것이 아니라 초기에 식별될 수 있도록 합니다.
Note: Clean Core는 API Policy와는 별개이지만 같은 방향을 가리킵니다. 고객들은 대안 접근 방식으로 인한 업그레이드 비용을 경험한 후 Clean Core 권고를 반복적으로 요청했습니다. 에이전시 시대—SAP가 미션 크리티컬 ERP를 서비스로 운영하는 시점—에서 Clean Core 권고와 API Policy는 클라우드 운영이 가능하게 하는 엔터프라이즈 급 신뢰성의 조건입니다.
AI 에이전트가 SAP 시스템에서 API 사용 패턴을 바꾸는 방법
일부 논평가들은 이 정책이 주로 상업적 움직임이라고 주장하지만, 기술적 증거는 다른 이야기를 보여줍니다.
전통적인 트랜잭션 인터페이스
- 요청‑응답 상호작용을 위해 설계됨: 판매 주문을 조회하고, 물품 수령을 전송하며, 결제 실행을 트리거합니다.
- 일반적으로 인간이 만든 통합 흐름에 의해 예측 가능한 빈도로 호출되어 정의된 비즈니스 목적을 수행합니다.
자율 AI 오케스트레이션
- AI 에이전트는 비즈니스 모델에 대한 의미적 컨텍스트를 추출하기 위해 이러한 API에 수천 개의 순차 호출을 수행합니다.
- 이 패턴은 클린 코어 통합 접근 방식이 아닙니다.
아키텍처 구분
- 전통적인 통합 도구: 판매 주문을 읽고, 대상 스키마로 변환한 뒤 전달합니다. SAP의 데이터 모델은 일시적인 해석 단계입니다.
- AI 에이전트: 전혀 다른 작업을 수행합니다. 단순히 값을 조회하는 것이 아니라, 데이터를 해석하고, 연관시키며, 원래 API 설계에서 예상하지 못한 방식으로 동작합니다.
AI 에이전트가 API 표면에 고주파, 고볼륨, 컨텍스트 풍부 워크로드를 부과하기 때문에, 통합 API 정책은 새로운 에이전트 시대에 성능, 안정성 및 보안을 유지하는 데 필수적입니다.
Understanding the SAP Data Model
에이전트는 라인‑아이템 데이터를 읽고 개별 항목이 주문과 어떻게 연결되는지 학습합니다. 순가치를 읽고 이 숫자가 문서 통화와 쌍을 이룰 때만 의미가 있음을 이해합니다. 판매 주문이 배송, 청구, 그리고 최종적으로 회계 원장으로 이동하는 경로를 추적하면서 SAP가 운영과 재무를 비즈니스‑오브젝트 모델 내에서 어떻게 조정하는지 내재화합니다.
에이전트는 고객의 트랜잭션 데이터를 단순히 소비하는 것이 아니라 semantic ontology도 소비하고 있습니다:
- 비즈니스‑오브젝트 정의
- 엔터티 간 관계
- SAP가 5십년 동안 기업 지식 인코딩을 통해 구축하고 다듬어 온 개념적 아키텍처
SAP는 고객 데이터에 대한 트랜잭션 접근을 가능하게 하는 것과 기본 온톨로지를 추출하거나 복제하는 것 사이를 오래전부터 구분해 왔습니다. 정책이 이 경계를 만드는 것이 아니라 이미 존재하던 경계입니다. 자율 에이전트는 이를 재정의하기보다 그 경계를 계속 존중해야 합니다.
제3자 MCP 구현의 보안 위험
그런 다음 보안 관점이 있으며 이는 추상적이지 않습니다. 이 정책이 발표된 같은 주에 Mini Shai‑Hulud라는 공급망 공격—npm 웜의 변종—이 수백 개의 소프트웨어 패키지를 조용히 손상시켰습니다. SAP 생태계 npm 패키지가 손상되었으며, 우리는 이를 고객에게 보안 안내로 대응했습니다. 이는 이론적인 위협 모델이 아니라, 커뮤니티에서 구축한 MCP 서버가 미션 크리티컬 비즈니스 프로세스를 실행하는 생산 SAP 시스템에 연결되는 활성 위협 환경입니다.
OWASP MCP Top 10은 취약점 클래스를 체계적으로 문서화합니다:
- 도구 오염
- 프롬프트 인젝션
- 범위 확대로 인한 권한 상승
- 토큰 관리 부실
- 공급망 타협
수천 개의 MCP 구현을 분석한 최근 연구에 따르면 대부분이 정적 장기 인증 정보를 사용하거나 식별 가능한 보안 문제를 가지고 있습니다. MCP 생태계에서 하나의 패키지가 손상되면 수십만 개의 노출된 개발 환경으로 연쇄적으로 퍼질 수 있습니다.
VentureBeat는 지난 주에
com.mand실행 결함으로 인해 200,000개의 MCP 서버가 취약해졌다고 보도했습니다.
이를 실제 상황에서 어떻게 해석할 수 있을까요? SAP 데이터 모델의 의미 구조를 방금 내재화하고 커뮤니티 MCP 서버를 통해 작동하는 AI 에이전트는 생산성 도구를 넘어 위험이 고조된 카테고리로 이동합니다. 이는 광범위한 시스템 접근 권한과 아직 진화 중인 공격 표면을 결합한 상황입니다.
왜 MCP만으로는 SAP 비즈니스 프로세스를 실행할 수 없는가
MCP 논쟁은 기업 아키텍트가 직접 직면해야 할 기술적 현실을 가려버렸습니다.
- Model Context Protocol (MCP) 은 배관 역할을 합니다. AI 모델이 도구를 호출하는 방식을 정의합니다.
- 도구가 비즈니스 맥락에서 무엇을 하는지, 어떤 순서로 도구를 호출해야 하는지, 특정 API 호출이 어떤 부수 효과를 일으키는지, 혹은 잘못된 매개변수의 결과에 대해서는 전혀 언급하지 않습니다.
SAP OData 서비스에 연결된 순진한 MCP 구현은 도구를 호출할 수는 있지만 비즈니스 프로세스를 실행할 수는 없습니다.
토큰‑소모 예시
| 구현 | 사용된 토큰 | 대략적인 비용* |
|---|---|---|
| Standard MCP | 565,000 | $1.70 |
| Context‑aware | 80,000 | $0.24 |
*단일 작업에 대한 일반적인 LLM 가격 모델을 기준으로 한 비용.
표준 MCP 구현은 자동화가 아니라 복잡한 쿼리에서는 실패하고, 설계되지 않은 트래픽으로 API 표면을 과부하시키는 비용이 많이 드는 자동화 근사에 불과합니다.
SAP’s Architecture for Open Third‑Party AI Integration via A2A
SAP의 이러한 과제에 대한 대응은 생태계를 폐쇄하는 것이 아니라 열린 생태계를 위한 올바른 인프라를 구축하는 것입니다. 이 차이는 충분히 강조할 가치가 있습니다.
핵심 요소
- API Policy – 문서화되고 공동 설계된 아키텍처에 컴플라이언스를 고정합니다.
- Agentic Interoperability Reference Architectures – 주요 기술 파트너와 공동 개발하고, SAP Architecture Center에 게시하며, 고객 수요에 따라 우선순위를 정하고, 새로운 패턴이 검증될 때마다 업데이트됩니다.
- Bi‑directional Integration of SAP Joule and Microsoft 365 Copilot – 서로 다른 공급업체의 두 AI 시스템이 각자의 애플리케이션 표면을 통해 상호 작동하면서 상대방의 보안 모델을 우회하지 않는, 실제 운영 중인 공동 설계 에이전트 통합의 가장 눈에 띄는 사례입니다.
- Agent Gateway via the A2A protocol – 외부 AI‑에이전트가 SAP에 접근하기 위한 권장 경로입니다.
- Reference AI Golden Path – SAP Architecture Center에서 제공됩니다.
- SAP Knowledge Graph, Open Resource Discovery (ORD) specification for metadata, and SAP BDC data products – 프로토콜 연결을 비즈니스가 활용 가능한 상호작용으로 변환하는 컨텍스트 레이어를 제공합니다.
- Governed MCP servers – CAP, UI5, Fiori Elements용이며, ABAP을 포함한 추가 개발 환경으로 확장할 의도를 가지고 있습니다.
이것들은 닫힌 문이 아니라 올바른 문입니다.
표준 커뮤니티 참여
- SAP는 활동적인 기여자이며, 문을 잠그는 게이트키퍼가 아닙니다.
- Linux Foundation 산하 Agent‑to‑Agent (A2A) protocol의 런치 파트너입니다.
- Agentic AI Foundation에서 Gold‑level membership을 보유하고 있으며, Agent Identity and Trust 워크스트림을 공동 주재하고 있습니다. 이 워크스트림은 AI 에이전트가 기업 경계를 넘어 인증·인가·상호운용되는 방식을 정의하는 조직들과 협력합니다.
A2A와 MCP는 SAP가 마지못해 수용하는 외부 제약이 아니라, SAP가 내부적으로 사용하고 표준 작업을 통해 적극적으로 강화하고 있는 프로토콜입니다. 커뮤니티와 오픈‑소스 프레임워크가 이러한 강화된 표준을 충족하면, 기업은 SAP 환경 전반에 걸쳐 AI 에이전트를 안전하고 확장 가능하게 활용할 수 있는 경로를 얻게 됩니다.
Enterprise Security and API Openness
엔터프라이즈 배포에 필요한 보안 기준이 마련되면, 외부 통합 경로가 뒤따르게 됩니다. SAP에서 발표한 API 정책이 개방성의 끝을 의미하지는 않습니다. 업계는 지난 2년간 엔터프라이즈 시스템에 AI 에이전트를 배치하면서, 엔터프라이즈 보안 커뮤니티가 아직 강화하지 않은 프로토콜을 사용하고, 자율 오케스트레이션을 위해 설계되지 않은 API에 접근했으며, 공격자들이 이미 악용 방법을 익힌 커뮤니티 도구를 활용해 왔습니다. 거버넌스는 선택 사항이 아니라 시기적절한 것이었습니다.
Anirban Majumdar는 SAP CTO실장입니다.
스폰서 콘텐츠 공개
스폰서 기사란 게시비를 지불하거나 VentureBeat와 비즈니스 관계가 있는 회사가 제작한 콘텐츠이며, 항상 명확하게 표시됩니다. 자세한 내용은 sales@venturebeat.com 으로 문의하십시오.