2026년 4월 SAP가 API Policy를 업데이트한 뒤, 서드파티 AI 에이전트가 SAP API를 직접 호출해 업무를 수행할 수 있는지는 더 이상 단순한 기술 연결 문제가 아니게 됐다. 이제는 기업 아키텍처, 계약상 권리, 데이터 거버넌스까지 함께 따져야 하는 이슈다.^[5][6][10]

SAP의 API Policy는 API의 가용성과 제한을 설명하고, 솔루션의 건전성 및 보안 보호, 공정한 접근, API 오남용 방지를 위한 통제 장치를 마련하는 문서라고 밝힌다.^[9] 논란의 중심은 이 정책에 포함된 AI 관련 조항이다. 외부 분석과 보도에 따르면 API Policy v4/2026의 2.2.2절은 API 호출 순서를 스스로 계획하거나 선택하거나 실행하는 반자율 또는 생성형 AI 시스템을 겨냥한다. SAP가 인정한 아키텍처, 데이터 서비스 또는 서비스별 지정 경로를 통하지 않는 경우, 이런 API 상호작용이나 통합은 금지될 수 있다는 해석이다.^[6][8][10]

핵심 구분: 조언하는 AI인가, 실행하는 AI인가

이번 정책을 ‘SAP가 AI 사용을 전면 금지했다’고 이해하면 과하다. 더 정확히는 SAP API를 서드파티 AI 에이전트가 자유롭게 조합해 쓰는 실행 계층으로 삼는 설계를 SAP가 강하게 제한하기 시작했다는 뜻에 가깝다.^[6][8][10]

예를 들어 어떤 도구가 이미 승인된 방식으로 추출된 데이터를 요약하거나, 수요 예측을 돕거나, 담당자에게 권고안을 제시하는 수준이라면 가장 민감한 에이전트형 AI 조항에 바로 걸린다고 보기는 어렵다. 반대로 AI가 재고를 조회하고, 주문을 수정하고, 구매요청이나 구매오더를 만들고, 승인 흐름을 진행하거나, 마스터 데이터를 갱신한다면 상황이 달라진다. 이런 설계는 여러 API 호출을 묶어 업무 상태를 바꾸는 형태에 가까워 정책상 위험이 크게 올라간다.^[6][8][10]

새 정책이 만든 네 가지 실무 경계

1. 서드파티 AI 에이전트는 SAP가 인정한 경로를 확인해야 한다

The Register는 새 조항을 두고 SAP가 자사가 인정한 아키텍처 밖에서 외부 AI 시스템과 API를 통합하는 것을 금지하고 있으며, 이 때문에 서드파티 AI 도구가 고객의 SAP 데이터에서 배제될 수 있다는 우려가 나왔다고 보도했다.^[10] Fivetran도 이번 정책이 API 호출 순서를 스스로 계획·선택·실행하는 반자율 또는 생성형 AI 시스템을 명시적으로 지목한다고 설명했다.^[8]

즉, 기술적으로 SAP API에 연결할 수 있다는 사실만으로 정책상 허용된다는 뜻은 아니다. 기업이 서드파티 AI 에이전트로 SAP 업무를 자동화하려면 해당 방식이 SAP-endorsed architecture, data service, 또는 service-specific pathway에 해당하는지 먼저 확인해야 한다.^[10]

2. Published API와 문서화된 API가 기본 전제가 됐다

SAPInsider는 이번 업데이트가 시스템 접근을 published, documented API로 좁히며, 문서화되지 않은 API는 지원 경계 밖에 놓여 장기 통합과 운영 리스크가 커진다고 지적했다.^[5] SAP API Policy도 Published API를 SAP Business Accelerator Hub, 즉 API Hub에 게시되었거나 제품별 문서에서 식별된 API로 설명한다.^[9]

오래된 커스텀 연동, 레거시 커넥터, 공식 문서에 명확히 잡히지 않은 인터페이스에 의존해 온 기업이라면 기존 연결 방식을 다시 점검해야 한다. 지금 작동하는 통합이라도 향후 지원, 감사, 업그레이드 과정에서 불확실성이 커질 수 있다.^[5][9]

3. 대규모 데이터 추출과 복제도 별도 위험 영역이다

새 정책은 AI 에이전트의 API 오케스트레이션만 겨냥하지 않는다. Fivetran과 The Register는 정책이 scraping, harvesting, 그리고 체계적이거나 대규모인 데이터 추출·복제도 다룬다고 설명한다. SAP가 통제하거나 인정한 아키텍처와 경로를 통하지 않으면 이런 방식 역시 제한될 수 있다.^[8][10]

따라서 SAP 데이터를 외부 데이터 레이크, 데이터 웨어하우스, 또는 비SAP AI 플랫폼으로 대량 복제하려는 프로젝트는 처리량과 비용만 따져서는 부족하다. API Policy, 계약상 권리, API limit, 감사 요건, SAP가 인정한 데이터 경로를 함께 확인해야 한다.^[8][9][10]

4. SAP의 자체 AI 생태계가 더 자연스러운 선택지가 된다

SAP 공식 문서는 SAP BTP에서 AI 에이전트를 구축할 수 있고, 이 에이전트가 SAP의 중앙 AI 코파일럿인 Joule 및 SAP BTP 기반 AI 인프라와 통합된다고 설명한다. 또한 SAP Cloud SDK for AI는 LangChain 등 어댑터를 통해 일반적인 에이전트 프레임워크와 연결될 수 있다.^[1]

SAP는 SAP Knowledge Graph도 Joule 및 AI 에이전트를 포함한 다른 AI를 지원하는 기능으로 소개한다. SAP 애플리케이션에 담긴 비즈니스 맥락을 바탕으로 AI 답변의 정확성과 관련성을 높이기 위한 접근이다.^[4]

이 말이 모든 서드파티 솔루션이 불가능하다는 뜻은 아니다. 다만 정책 경계가 좁아진 상황에서는 SAP가 공식적으로 인정하거나 통제하는 경로가 기업 아키텍처팀, 법무팀, 리스크 관리 조직의 승인을 받기 더 쉬운 선택지가 될 가능성이 크다.^[1][4][10]

어떤 AI 프로젝트가 가장 영향을 받나

사용 시나리오	영향 수준	이유
승인된 방식으로 추출한 데이터를 BI, 리포트, 오프라인 분석에 활용	낮음~중간	AI가 SAP API를 직접 조합해 실행하지 않는다면 에이전트형 AI 조항에 닿을 가능성은 상대적으로 낮다. 다만 대규모 추출·복제라면 별도 검토가 필요하다.[8][10]
챗봇이 권고만 제공하고 최종 실행은 사람이 SAP에서 수행	낮음	정책의 핵심 표적은 API 호출 순서를 계획·선택·실행하는 AI 시스템이다. 단순 조언형 흐름과 직접 실행형 에이전트는 다르게 봐야 한다.[6][8]
AI가 재고 조회, 주문 수정, 구매오더 생성, 승인, 마스터 데이터 갱신을 자동 수행	높음	여러 API 호출, 쓰기 작업, 업무 상태 변경이 결합되는 경우가 많아 정책이 우려하는 에이전트형 AI 패턴에 가깝다.[6][8][10]
SAP 데이터를 외부 플랫폼으로 대량 복제해 AI에 사용	높음	정책은 scraping, harvesting, 체계적 또는 대규모 데이터 추출·복제도 명시적으로 다룬다.[8][10]
문서화되지 않은 API에 의존하는 레거시 커넥터나 커스텀 통합	중간~높음	SAPInsider는 문서화되지 않은 API가 지원 경계 밖에 놓였다고 설명했고, SAP Policy도 Published API를 API Hub 또는 제품 문서에서 식별된 API로 정의한다.[5][9]

혁신에 미치는 영향: PoC 전 단계부터 아키텍처 검토가 필요하다

플랫폼 운영 관점에서 보면 SAP가 외부 에이전트의 무제한적인 핵심 ERP API 호출을 제한하려는 이유는 있다. 특히 쓰기 작업, 거래 프로세스, 시스템 성능에 영향을 주는 영역에서는 통제가 중요하다. SAP API Policy도 통제 목적을 솔루션 건전성, 보안, 공정한 접근, API 오남용 방지라고 설명한다.^[9]

다만 개발팀 입장에서는 AI PoC의 초기 비용이 올라간다. 과거에는 API 권한을 얻고 커넥터를 만들고 흐름을 시험하면 됐던 실험도, 이제 AI가 다음 단계를 스스로 판단해 여러 SAP API를 호출한다면 SAP가 인정한 아키텍처, 데이터 서비스, 서비스별 지정 경로에 해당하는지 먼저 확인해야 한다.^[8][10]

결론적으로 혁신이 멈춘다기보다, 혁신 전에 거버넌스가 앞당겨진다. 자체 개발 에이전트, 파트너 제품, 서드파티 AI 플랫폼 모두 기술적으로 SAP API와 연결할 수 있더라도 계약 검토, 아키텍처 검토, 데이터 거버넌스 검토를 더 일찍 거쳐야 한다.^[5][8][10]

데이터 통제의 의미: 데이터를 볼 수 있다고 해서 즉시 조작할 수 있는 것은 아니다

이번 정책은 API 가용성, API 제한, 통제 조치를 다루는 문서이지, 데이터 소유권 전체를 선언하는 문서는 아니다.^[9] 하지만 에이전트형 AI에서는 통제권의 의미가 단순한 데이터 다운로드 여부를 넘어선다. 누가 SAP 시스템을 실시간으로 읽고, 쓰고, API 호출 순서를 정하고, 그 결과로 업무 상태를 바꿀 수 있는지가 핵심이 된다.^[6][8][10]

외부 분석은 이를 기업 데이터 통합을 다시 점검하게 만드는 사건으로 해석했다. 기업은 이제 ‘SAP 데이터에 접근할 수 있는가’뿐 아니라 ‘우리가 선택한 AI 에이전트가 그 데이터에 직접 행동을 취할 수 있는가’를 물어야 한다.^[6]

공정하게 보자면, Kai Waehner의 외부 분석은 SAP CEO Christian Klein의 설명을 인용해 정책의 의도가 고객의 자기 데이터 접근을 막는 것이 아니라 SAP의 도메인 노하우를 보호하고 성능 저하를 방지하는 데 있다고 전했다.^[6] 기업 실무에서는 이런 설명을 계약 문구, API Policy, 인정된 아키텍처 목록, 개별 유스케이스별 허용 범위로 구체화하는 일이 중요하다.^[6][9][12]

벤더 락인의 초점은 데이터가 아니라 프로세스 오케스트레이션일 수 있다

AI 에이전트 시대의 벤더 락인은 데이터가 전혀 반출되지 않는 형태로만 나타나지 않는다. 더 현실적인 잠금 지점은 프로세스 오케스트레이션 계층일 수 있다. 가장 안전하고 논란이 적으며 컴플라이언스 검토를 통과하기 쉬운 AI 자동화 경로가 SAP BTP, Joule, SAP AI Core, SAP Knowledge Graph와 연결된 방식이라면 기업의 장기 AI 아키텍처는 자연스럽게 SAP 생태계에 더 의존하게 된다.^[1][4][10]

The Register는 새 AI 조항이 서드파티 AI 도구의 SAP 데이터 및 프로세스 접근을 어렵게 만들 수 있다는 점에서 lock-in 우려를 낳았다고 보도했다.^[10] Fivetran도 기업이 AI 에이전트로 ERP 데이터에 접근하려 할 때 이번 정책이 AI 전략의 리스크와 선택지를 더 무겁게 만든다고 봤다.^[8]

기업이 지금 점검해야 할 다섯 가지

1. AI 유스케이스를 세분화한다. 읽기 전용인지, 쓰기 작업이 있는지, 사람이 최종 확인하는지, AI가 여러 단계를 스스로 실행하는지부터 나눠야 한다. 정책 리스크는 보통 후자에 가까울수록 급격히 높아진다.^[6][8][10]
2. SAP 또는 시스템 통합사에 인정 경로를 확인한다. 각 시나리오가 SAP-endorsed architecture, data service, service-specific pathway, 또는 SAP BTP·Joule 관련 구조로 구현 가능한지 명확히 물어야 한다.^[1][10]
3. 사용 중인 API가 published, documented API인지 확인한다. 기존 통합이 문서화되지 않은 API에 의존한다면 리팩터링과 지원 리스크를 예산과 일정에 반영해야 한다.^[5][9]
4. 데이터 권리와 책임을 계약 및 거버넌스 문서에 적는다. 서드파티 AI 사용, 데이터 추출·복제, API limit, 감사, 장애·보안 사고 책임, AI가 SAP에 쓰기 작업을 할 때의 책임 경계를 명확히 해야 한다.^[8][9][10]
5. SAP FAQ와 정책 업데이트를 계속 추적한다. SAP의 FAQ 문서는 API Policy와 관련된 일반 질문에 답하며, 수시로 업데이트될 수 있다고 명시한다. 일회성 구두 설명에만 의존해서는 안 된다.^[12]

결론

SAP의 새 API 정책이 던지는 메시지는 분명하다. 서드파티 AI 에이전트는 더 이상 SAP API를 마음대로 조합해 직접 업무를 실행할 수 있다고 가정해서는 안 된다. 리포트, 오프라인 분석, 사람이 최종 확인하는 조언형 AI에는 영향이 제한적일 수 있다. 하지만 AI가 SAP 핵심 프로세스를 직접 조작하거나 ERP에 쓰기 작업을 하거나 SAP 데이터를 대규모로 외부 플랫폼에 복제하려는 프로젝트라면, 이는 아키텍처와 계약, 데이터 거버넌스 차원의 중대한 점검 대상이다.^[8][10]

이미 SAP BTP, Joule, SAP AI Core에 무게를 두고 있는 기업에는 공식 경로가 더 선명해질 수 있다.^[1][4] 반대로 ERP, CRM, 공급망, 데이터 플랫폼을 가로지르는 개방형 AI 에이전트 계층을 만들려는 기업이라면 개발에 들어가기 전에 SAP가 인정한 아키텍처, API 사용 권한, 데이터 추출 경계를 먼저 확인해야 한다. 그렇지 않으면 기술적으로는 성공한 PoC가 실제 운영 단계에서 정책과 계약의 벽에 막힐 수 있다.^[5][10]