"IAS 테넌트가 몇 개예요?"라고 물어보면, 답이 하나가 아닌 고객사가 생각보다 많아요. 프로젝트마다, 솔루션마다 따로 만들다 보니 어느 순간 테넌트가 여러 개가 되어 있는 거죠. 그런데 2026년을 기점으로 이 상황이 심각한 문제가 됩니다. Joule 활성화, SuccessFactors 인증 체계 전환, BTP 연동 — 이 세 가지가 동시에 IAS 단일 테넌트를 전제로 설계되어 있거든요.
오늘은 SAP 공식 문서와 실무 커뮤니티 자료를 기반으로, IAS 테넌트가 왜 단일화되어야 하고, 어떻게 접근해야 하는지 정리해 드릴게요.
1. SAP IAS가 뭔지 먼저 짚고 가요
SAP Cloud Identity Services는 크게 두 가지로 구성돼요. IAS(Identity Authentication Service)는 인증 담당, IPS(Identity Provisioning Service)는 사용자 프로비저닝 담당이에요. 원래는 별개였는데, 지금은 하나의 통합 테넌트 안에서 함께 동작하는 구조예요.
| 구성요소 | 역할 | 접근 URL 패턴 |
|---|---|---|
| IAS | SSO, 인증, IdP 프록시, 앱 등록 | https://<tenant>.accounts.ondemand.com |
| IPS | 사용자 동기화, 프로비저닝 잡 관리 | IAS Admin Console 내 통합 |
| CIS 테넌트 | IAS + IPS가 통합된 현재 표준 테넌트 | https://<tenant>/admin |
2. 테넌트가 여러 개인 게 왜 문제인가요?
과거에는 SAP 솔루션을 추가 도입할 때마다 IAS 테넌트를 새로 만드는 경우가 있었어요. SuccessFactors 프로젝트 때 하나, BTP 프로젝트 때 또 하나. 당장은 문제없어 보이지만, 이 구조가 점점 발목을 잡습니다.
"Having multiple IAS tenants is not a recommended model as it would result in reduced SSO capabilities"
"SAP explicitly warns against mixing systems from different IAS tenants into one Joule Formation"
3. 지금 당장 움직여야 하는 이유 — 2026년 11월 데드라인
이건 유예 연장이 없는 하드 데드라인이에요. SAP는 2025년 6월 2일에 이미 유지보수를 종료했고, 2026년 11월 1일이 되면 기존 방식으로 로그인하려는 사용자는 접속 자체가 차단됩니다.
"IAS adoption will become mandatory by November, 2026"
KBA 3472405 — Deprecation of Basic Authentication and Third-Party Corporate IdP Direct Integration
4. SAP의 공식 테넌트 원칙 — 1 Productive + 1 Test
SAP는 테넌트 발급에 대해 명확한 원칙을 갖고 있어요. 계약 수, 솔루션 수에 관계없이 프로덕티브 테넌트 1개, 테스트 테넌트 1개가 기본이에요.
아니에요. 추가 솔루션을 구매해도 테넌트가 추가로 발급되지 않아요. 단, CPEA(Cloud Platform Enterprise Agreement) 계약 고객은 BTP 서브어카운트를 통해 추가 테넌트 발급을 요청할 수 있는 예외 경로가 있어요. 하지만 이것도 단일화 원칙 예외가 아니라, 아키텍처 결정이 필요한 별도 케이스예요.
"If you already have a tenant and purchase additional SAP cloud solutions, you will not get additional tenants."
5. 테넌트 통합 전략 — 어떤 구조로 갈까요?
테넌트 통합 방식은 크게 두 가지 접근이 있어요. 어느 쪽이 맞는지는 현재 SF 테넌트 구성과 사용자 분포에 따라 달라져요.
| 구분 | 1 IAS per 1 SF 방식 | Shared IAS 방식 |
|---|---|---|
| 개념 | SF 테넌트마다 IAS 테넌트 1:1 연결 | 여러 SF 테넌트가 하나의 IAS 공유 |
| 장점 | 사용자 분리 명확, 설정 단순 | 테넌트 관리 부담 감소, SSO 범위 최대화 |
| 단점 | 테넌트 수 증가, SSO 범위 제한 | 사용자 매칭 로직·IPS 변환 규칙 복잡 |
| 권장 케이스 | SF 테넌트별 사용자가 완전히 다른 경우 | 동일 사용자가 여러 SF 테넌트에 걸쳐 있는 경우 |
Shared IAS 구성 시 — 사용자 충돌 방지 핵심 패턴
여러 SF 테넌트를 하나의 IAS에 물릴 때 제일 많이 막히는 게 사용자 접근 분리예요. SF1 사용자가 SF2에 들어가면 안 되는데, IAS에 사용자가 한 곳에 모여 있으니까요. 이걸 IPS Transformation + IAS 조건부 인증으로 해결해요.
Group_SF1 그룹 자동 할당 (IPS Transformation 규칙)
Group_SF2 그룹 자동 할당
Group_SF1 사용자는 SF2 앱 접근 차단
Leading System of Records: 사용자를 IAS에 CREATE하는 시스템은 하나여야 하며, 나머지는 UPDATE만 가능
6. Neo IPS → CIS 인프라 마이그레이션 절차
구버전 IPS 테넌트(Neo 환경)를 사용 중이라면 CIS 인프라로 이전해야 해요. 마이그레이션 자체는 Wizard가 제공되지만, 사전 조건을 놓치면 낭패예요.
7. Joule 연동 시 IAS 구성 원칙
IAS 단일화가 왜 지금 더 중요해졌냐면, SAP Joule 때문이기도 해요. Joule 활성화 아키텍처는 IAS 구성에 직접적으로 의존하거든요.
참조 공식 문서: "Integrating Joule with SAP Solutions" (SAP Help Portal PDF)
8. 지금 당장 확인할 것들 — 체크리스트
https://iamtenants.accounts.cloud.sap/ 접속해서 할당된 테넌트 전체 목록 확인
테넌트 목록 확인:
https://iamtenants.accounts.cloud.sap/
마무리 — IAS 단일화는 SAP 클라우드 전환의 기초 공사
SAP 클라우드 여정에서 IAS 테넌트 단일화는 선택이 아니에요. Joule, SuccessFactors 인증 의무화, BTP 연동 — 이 모든 게 단일 IAS 테넌트를 기반으로 설계되어 있어요.
지금 당장 할 일은 복잡한 마이그레이션 계획을 세우는 것보다,
현재 IAS 테넌트가 몇 개인지부터 파악하는 것이에요.
iamtenants.accounts.cloud.sap에서 5분이면 현황을 볼 수 있어요.
거기서 시작하면 됩니다.
help.sap.com/docs/cloud-identity-services)
'SAP BC' 카테고리의 다른 글
| [SAP] Cloud ALM 설정 관련 최신 정보 공유 (0) | 2026.06.29 |
|---|---|
| [SAP] Joule AI 또 다시 정리 (1) | 2026.06.28 |
| [SAP] Joule AI 두번째 (0) | 2026.05.11 |
| [SAP] BDC 란 무엇인가? BW의 진화 (0) | 2026.05.08 |
| [SAP] Cloud ALM 활용 전략 (0) | 2026.05.07 |