2026년 4월 SAP의 API 정책 업데이트에서 기업이 먼저 봐야 할 지점은 ‘제3자 도구가 SAP에 전혀 연결될 수 없느냐’가 아니다. 핵심은 SAP가 ERP 데이터와 프로세스에 접근하는 API 사용을 공개 API, 제품 문서, SAP가 승인한 아키텍처, 데이터 서비스 또는 서비스별 지정 경로 안으로 좁히고 있다는 점이다.^[1][7][10]

SAP ERP에 AI 에이전트를 붙이려는 기업에는 이 변화가 단순한 약관 수정이 아니다. 개념검증(PoC), 데이터 플랫폼, RPA, 통합 플랫폼(iPaaS), 추출·변환·적재(ETL), 사내 자동화 흐름을 어떻게 설계할지에 직접 영향을 준다.^[1][13]

무엇이 달라졌나: ‘호출 가능’과 ‘지원 대상’을 구분해야 한다

CIO는 SAP의 설명을 인용해, SAP Business Accelerator Hub 또는 해당 제품 문서에 올라온 인터페이스만 공개 API로 간주된다고 보도했다.^[7] The Register도 새 정책이 API 사용을 ‘SAP가 승인한 아키텍처, 데이터 서비스 또는 서비스별 경로’의 범위 안으로 제한한다고 전했다.^[2][10]

이는 기업이 더 이상 ‘기술적으로 호출할 수 있는 SAP 인터페이스’라면 장기 연동에 써도 된다고 가정하기 어렵다는 뜻이다. 정책 문서에 언급된 API 통제 항목에는 기능·기술 사용량 제한, 쿼터, 폐기 일정, 데이터 유입·유출 쿼터, 대량 추출·복제의 제한과 전제조건, 기타 보안·기술 요구사항이 포함된다.^[9] SAPinsider도 문서화되지 않은 API가 여전히 널리 쓰이지만, 업데이트 이후에는 지원 경계 밖에 놓여 장기 통합과 운영 리스크가 커질 수 있다고 짚었다.^[1]

따라서 이번 변화는 단순한 AI 조항 하나의 문제가 아니다. 어떤 API가 공개 API인지, 어떤 사용 방식이 지원되는지, 어떤 데이터 추출·복제가 별도 조건을 필요로 하는지, 어떤 자동화가 SAP 승인 경로를 거쳐야 하는지를 따지는 ERP 통합 거버넌스의 문제다.^[7][9][13]

왜 AI 에이전트가 특히 민감한가

논란의 중심에는 AI 조항이 있다. 여러 보도는 SAP 정책을 인용해, SAP가 승인한 아키텍처·데이터 서비스·명시 경로를 통하지 않는 한 API를 반자율 또는 생성형 AI 시스템과의 상호작용·통합에 쓰는 것을 금지한다고 전했다. 여기서 말하는 시스템은 API 호출의 순서를 계획하거나, 선택하거나, 실행하는 시스템이다.^[5][10]

이 지점이 전통적 시스템 연동과 에이전트형 AI의 차이다. 기존 연동은 보통 사전에 정의된 절차를 따른다. 예를 들어 한 시스템이 정해진 규칙에 따라 특정 API를 호출하고 단일 업무를 끝내는 식이다. 반면 AI 에이전트는 목표를 받은 뒤 다음 행동을 즉석에서 정할 수 있다. 공급업체 정보를 조회하고, 재고를 확인하고, 구매 제안을 만들고, 승인 요청이나 기록 업데이트까지 이어가는 흐름이 대표적이다.

에이전트가 여러 SAP API 호출을 스스로 고르고 연결한다면, 정책이 말하는 다단계 API 오케스트레이션 범위에 들어갈 수 있다. 실제 준수 여부는 사용한 API, 아키텍처, 데이터 서비스, SAP의 승인 방식에 따라 달라진다.^[5][10]

같은 제한은 스크래핑, 하베스팅, 체계적이거나 대규모의 데이터 추출·복제에도 적용된다.^[5][10] 그래서 영향을 받는 것은 SAP에 쓰기 작업을 하는 에이전트만이 아니다. 외부 AI 플랫폼, 데이터 레이크하우스, 에이전트 오케스트레이션 계층을 위해 SAP 데이터를 대량으로 읽어 가는 설계도 다시 검토해야 한다.^[9][13]

고객 혁신: PoC가 멈춘다기보다 ‘정식 통합 프로젝트’에 가까워진다

혁신 조직, 시스템통합 사업자(SI), 독립 소프트웨어 벤더(ISV) 입장에서 가장 큰 변화는 실험 전에 거쳐야 할 거버넌스 문턱이 높아졌다는 점이다. 과거에는 제3자 AI 에이전트를 ERP에 빠르게 붙여 자동 대사, 구매 보조, 재고 분석, 고객 서비스 자동화 같은 시나리오를 시험할 수 있었다. 이제는 API가 SAP Business Accelerator Hub나 제품 문서에 있는지, 아키텍처가 SAP 승인 경로인지, 사용량이 쿼터나 대량 추출 제한에 걸리는지, 에이전트가 다단계 API 호출을 스스로 계획하는지를 먼저 확인해야 한다.^[5][7][9]

그렇다고 AI PoC가 불가능하다는 뜻은 아니다. 다만 PoC가 더 이상 가벼운 실험만으로 남기 어렵다. API 목록화, 권한 설계, 사용량 추정, 데이터 흐름 검토, 컴플라이언스 확인이 필요해진다. ERP Today는 이번 정책이 기술적 통합 이슈를 더 넓은 ERP 아키텍처 문제로 끌어올렸다고 평가했다. 기존 통합이 공식 문서화되지 않은 인터페이스에 의존할 수 있고, 새 AI 애플리케이션은 기업 데이터와 트랜잭션 워크플로에 통제된 방식으로 접근해야 하기 때문이다.^[13]

불확실성 자체도 혁신 속도를 늦출 수 있다. The Register는 독일어권 SAP 사용자그룹 DSAG가 이번 정책이 불확실성을 낳는다고 비판했다고 보도했다. 같은 보도는 SAP의 승인 인터페이스 목록이 충분히 잘 관리되거나 제때 업데이트되지 않을 수 있다는 비판도 전했다.^[2]

데이터 통제: 소유권보다 ‘어떤 방식으로 접근할 수 있느냐’가 쟁점

이번 논란의 초점은 고객 데이터의 소유권만이 아니다. 고객이 자신이 선택한 AI 플랫폼, 데이터 스택, 자동화 도구로 SAP 데이터와 거래 프로세스에 직접·실시간·지속적으로 접근할 수 있느냐가 더 실무적인 쟁점이다. The Register는 제3자 AI 도구가 고객의 SAP 데이터에서 배제될 수 있다는 우려로 이 문제를 설명했고, ERP Today는 이를 ERP 통합 경로, 데이터 복제, AI 접근 아키텍처의 관점에서 다뤘다.^[10][13]

기업이 SAP 데이터를 외부 데이터 레이크하우스, AI 플랫폼, 에이전트 오케스트레이션 계층, 제3자 자동화 시스템으로 동기화하려 한다면 확인할 항목이 많아진다. 데이터 유입·유출 쿼터, 대량 추출·복제의 전제조건, 공개 API 범위, SAP 승인 경로 필요 여부를 모두 따져야 한다.^[7][9][10]

이런 제한은 성능, 보안, 감사, 거버넌스 통제를 중앙화하는 데 도움이 될 수 있다. 반면 플랫폼 간 AI 아키텍처를 고객이 자유롭게 조합할 여지는 줄어들 수 있다. 특히 SAP 트랜잭션 데이터를 대량으로 읽고 쓰는 사례일수록 그 부담이 커진다.^[9][13]

벤더 종속: 위험은 커졌지만 결론은 아직 열려 있다

벤더 종속 우려는 현실적인 질문에서 나온다. 제3자 AI 에이전트가 SAP API와 자유롭게 상호작용할 수 없다면, 고객은 SAP 승인 아키텍처, 공식 데이터 서비스, SAP가 명시적으로 허용한 통합 방식에 더 의존하게 될 수 있다. The Register는 이번 AI 조항이 일부 제3자 AI 도구를 고객의 SAP 데이터에서 밀어낼 수 있다는 점에서 lock-in 우려를 부른다고 설명했다.^[10]

고객 커뮤니티의 반응도 단순한 기술 논쟁을 넘어선다. E3 Magazine은 DSAG가 문서화되지 않은 용도, 체계적인 대량 데이터 추출, 제3자 자율 생성형 AI 시스템과의 상호작용을 SAP가 강하게 제한하는 것은 받아들이기 어렵다고 봤다고 보도했다.^[11]

다만 벤더 종속이 유일한 결말은 아니다. 앞으로의 영향은 SAP가 승인 경로를 얼마나 명확히 정의하는지, API 목록을 얼마나 완전하고 신속하게 유지하는지, 감사 가능한 예외·승인 절차를 제공하는지, 제3자 공급업체가 명확한 규칙 아래 계속 혁신할 수 있게 하는지에 달려 있다. 승인 목록 관리와 업데이트 속도에 대한 비판이 이미 제기된 만큼, 기업은 구매와 아키텍처 의사결정 과정에서 이 지점을 반드시 확인해야 한다.^[2][7]

기업이 지금 점검할 5가지

1. 모든 SAP 연동을 목록화한다. 각 인터페이스를 공개 API, 제품 문서 내 API, 문서화되지 않은 인터페이스, 대량 추출, 실시간 읽기·쓰기, RPA, iPaaS, 외부 워크플로 또는 에이전트 호출로 구분해야 한다.^[1][7][13]

2. AI 사용 사례를 따로 점검한다. 모델이나 에이전트가 여러 SAP API 호출을 스스로 계획·선택·실행하는 흐름은 먼저 정책 리스크 평가를 거쳐야 한다.^[5][10]

3. 데이터 추출과 복제 구조를 재검토한다. 대규모 추출, 복제, 스크래핑, 하베스팅은 제한 범위에 포함된다. 기존 데이터 레이크, 레이크하우스, BI, AI 학습, 동기화 아키텍처도 쿼터와 전제조건, 허용 경로를 다시 확인해야 한다.^[5][9][10]

4. SAP 또는 구축 파트너에게 서면 확인을 요구한다. 에이전트형 AI, 자동 거래 업데이트, 시스템 간 오케스트레이션, 대량 데이터 반출처럼 리스크가 큰 시나리오는 구두 설명에 의존하면 안 된다. DSAG가 지적한 불확실성은 서면 경계가 왜 중요한지 보여준다.^[2]

5. 아키텍처 선택권을 남긴다. SAP 승인 경로를 쓰더라도 AI 오케스트레이션, 데이터 거버넌스, 권한, 감사 로그, 업무 규칙은 가능한 한 교체 가능한 모듈로 설계하는 편이 안전하다. 혁신 로직 전체가 하나의 경로에 고정되면 이후 협상력과 전환 여지가 줄어든다.

결론

SAP의 2026년 API 정책이 의미하는 바는 ‘AI가 SAP를 쓸 수 없다’가 아니다. 제3자 AI 에이전트가 SAP API를 자유롭게 조합하고 실행할 수 있다고 가정하던 시대가 끝나가고 있다는 뜻에 가깝다. 이 정책은 보안, 성능, 거버넌스의 기준을 높이는 동시에 컴플라이언스 비용, 실험 속도 저하, 벤더 종속 우려를 키운다.^[10][13]

단기적으로 가장 현실적인 대응은 기존 연동을 목록화하고, AI 에이전트의 다단계 API 호출 리스크를 구분하고, SAP 승인 경로를 확인하는 것이다. 동시에 새 아키텍처를 설계할 때는 SAP 생태계 안에서의 준수뿐 아니라 플랫폼 간 선택권을 의도적으로 남겨야 한다.