BTP 서브계정 초기 설정 놓치는 5가지 #shorts #SAP #BTP

📖 개요: 프로젝트 첫 주에 결정한 것들이 1년을 좌우합니다

SAP BTP 프로젝트는 첫 2주 안에 내린 결정(리전, 서브계정 구조, 권한 모델)이 이후 운영 전체를 지배합니다. 문제는 이 결정들이 나중에 바꾸기 매우 어렵다는 점입니다. 예를 들어 서브계정의 리전은 생성 후 변경할 수 없고, 잘못 설계된 역할 컬렉션은 감사(audit) 시점에 큰 부담이 됩니다. 이 글은 "놓치면 나중에 후회하는 초기 설정"을 중심으로, 초급 개발자·컨설턴트가 킥오프 전에 점검할 항목을 실제 설정 예제와 함께 정리합니다.

서브계정/디렉터리 구조를 환경(개발·검증·운영) 단위로 설계할 수 있다
엔타이틀먼트와 쿼터를 배정하고 부족분을 미리 파악할 수 있다
역할 컬렉션 기반 권한 모델을 JSON으로 정의할 수 있다
Destination·커넥티비티, CI/CD 전략의 초기 함정을 피할 수 있다

📚 미리 알아두면 좋은 배경

클라우드 계정 개념(글로벌 계정 vs 서브계정), REST API와 JSON 문법, 그리고 Cloud Foundry 또는 Kubernetes에 대한 기초 이해가 있으면 좋습니다. ABAP 경험만 있어도 따라올 수 있도록 온프레미스 개념(클라이언트, 트랜스포트)과 비교하며 설명합니다. SAP BTP 콕핏(Cockpit)에 한 번이라도 로그인해 봤다면 충분합니다.

🔧 환경과 준비물

이 글의 예제는 다음 환경을 기준으로 합니다.

SAP BTP 엔터프라이즈 계정 (트라이얼과 달리 디렉터리·커스텀 IdP 기능 제한이 없음. 무료로 실습하려면 Free Tier 플랜 사용 가능)
Cloud Foundry 환경 + cf CLI v8 이상
btp CLI 2.x — 서브계정·엔타이틀먼트를 코드로 관리할 때 필수
글로벌 계정 관리자(Global Account Administrator) 권한 — 킥오프 전에 반드시 확보해야 합니다. 이 권한이 없어 첫 주를 통째로 대기하는 프로젝트가 실제로 많습니다

가상의 시나리오로 제조사 노바플랜트(NovaPlant)가 설비 점검 앱 plant-audit를 BTP에 구축한다고 가정합니다.

💡 핵심 개념: 계정 구조는 건물의 골조입니다

BTP 계정 모델은 글로벌 계정 → 디렉터리 → 서브계정 → 스페이스(CF)의 계층입니다. 건물에 비유하면 글로벌 계정은 대지, 디렉터리는 동(棟), 서브계정은 층, 스페이스는 호실입니다. 골조를 잘못 올리면 인테리어(앱 개발)를 아무리 잘해도 소용없습니다.

초기에 반드시 이해해야 할 네 가지 축:

리전(Region) — 서브계정 생성 시 확정되며 변경 불가. 연동할 S/4HANA나 사용자 위치와 가까운 리전(한국이면 일반적으로 ap12 서울)을 선택해야 레이턴시와 데이터 주권 문제를 피할 수 있습니다.
엔타이틀먼트/쿼터 — "이 서브계정이 어떤 서비스를 얼마나 쓸 수 있는가"의 계약. 배정하지 않으면 콕핏에서 서비스 인스턴스 생성 버튼 자체가 비활성화되어, 개발 착수일에 아무것도 못 하는 상황이 생깁니다.
런타임 선택 — Cloud Foundry는 진입 장벽이 낮고 CAP/UI5와 궁합이 좋아 초급 팀에 일반적으로 권장됩니다. Kyma(Kubernetes)는 이벤트 기반·마이크로서비스에 강하지만 운영 지식이 필요합니다. 둘 다 켜면 쿼터를 이중으로 소모하니 초기에는 하나만 선택하는 편이 안전합니다.
권한 모델 — BTP는 역할(Role)을 묶은 역할 컬렉션(Role Collection)을 사용자·IdP 그룹에 매핑합니다. 개인별로 하나씩 부여하면 퇴사·이동 시 관리가 무너지므로, 처음부터 IdP 그룹 매핑으로 설계하는 것이 핵심입니다.

환경 분리는 온프레미스의 DEV/QAS/PRD 시스템 라인과 같습니다. BTP에서는 스페이스가 아니라 서브계정 단위로 분리하는 것이 일반적으로 권장됩니다. 스페이스 분리만으로는 Destination, 역할 컬렉션, 구독 서비스가 서브계정 레벨에서 공유되어 운영 데이터가 개발 권한에 노출될 수 있기 때문입니다.

💻 실전 예제: 3단계로 만드는 초기 세팅

1단계 — 서브계정 구조와 엔타이틀먼트를 코드로 만들기

콕핏 클릭 대신 btp CLI로 만들면 구조가 기록으로 남습니다. 환경별 서브계정 3개를 디렉터리 아래에 생성합니다.

# 목표 구조 (설계 문서에 먼저 그려두기)
global-account: novaplant-ga
└── directory: plant-audit-dir
    ├── subaccount: np-audit-dev   (region: ap12)
    ├── subaccount: np-audit-qas   (region: ap12)
    └── subaccount: np-audit-prd   (region: ap12)

// btp CLI: 개발 서브계정 생성 + 엔타이틀먼트 배정
// btp create accounts/subaccount --display-name "np-audit-dev" \
//   --region ap12 --subdomain np-audit-dev
// btp assign accounts/entitlement --to-subaccount <ID> \
//   --for-service hana-cloud --plan hana --amount 1
{
  "entitlements": [
    { "service": "hana-cloud", "plan": "hana", "amount": 1 },
    { "service": "destination", "plan": "lite" },
    { "service": "xsuaa", "plan": "application" }
  ]
}

2단계 — 역할 컬렉션과 Destination: 놓치면 감사에서 걸리는 부분

권한은 앱의 xs-security.json에서 시작합니다. 점검 담당자(Inspector)와 승인자(Approver)를 분리한 예입니다.

{
  "xsappname": "plant-audit",
  "tenant-mode": "dedicated",
  "scopes": [
    { "name": "$XSAPPNAME.AuditRead",  "description": "점검 결과 조회" },
    { "name": "$XSAPPNAME.AuditApprove", "description": "점검 승인" }
  ],
  "role-templates": [
    { "name": "Inspector", "scope-references": ["$XSAPPNAME.AuditRead"] },
    { "name": "Approver",
      "scope-references": ["$XSAPPNAME.AuditRead", "$XSAPPNAME.AuditApprove"] }
  ],
  "role-collections": [
    { "name": "NP_Audit_Approver", "role-template-references": ["$XSAPPNAME.Approver"] }
  ]
}

여기서 흔히 놓치는 것이 IdP 그룹 매핑입니다. 콕핏에서 역할 컬렉션 → Identity Provider 그룹(예: AD-NP-AUDIT-APPROVER)을 매핑해 두면, 인사 이동 시 AD 그룹만 바꾸면 끝납니다. 온프레미스 백엔드 연동용 Destination은 다음과 같이 정의하고, 반드시 Cloud Connector 설치·위치 ID(Location ID)를 프로젝트 초반에 인프라팀과 협의해야 합니다. 방화벽 개방에 보통 수 주가 걸리기 때문입니다.

{
  "Name": "NP_ERP_ONPREM",
  "Type": "HTTP",
  "URL": "http://nperp.internal:44300",
  "ProxyType": "OnPremise",
  "Authentication": "PrincipalPropagation",
  "CloudConnectorLocationId": "NP_LOC_SEOUL",
  "HTML5.DynamicDestination": "true"
}

PrincipalPropagation(사용자 신원 전파)을 쓸지 기술 사용자(BasicAuthentication)를 쓸지는 초기에 결정해야 합니다. 나중에 바꾸면 백엔드 권한 설계를 다시 해야 합니다.

3단계 — 운영 준비: CI/CD, 비용 알림, 트랜스포트

운영 반영을 수동 cf push로 하면 언젠가 사고가 납니다. MTA 기반 빌드와 SAP Cloud Transport Management(cTMS)를 초기에 연결해 두는 것이 일반적으로 권장됩니다.

# mta.yaml 핵심부 — 환경별 값은 확장 파일로 분리
ID: plant-audit
version: 1.0.0
modules:
  - name: plant-audit-srv
    type: nodejs
    path: gen/srv
    requires:
      - name: plant-audit-uaa
      - name: plant-audit-db
resources:
  - name: plant-audit-uaa
    type: org.cloudfoundry.managed-service
    parameters:
      service: xsuaa
      service-plan: application
      path: ./xs-security.json

# mtaext-prd.mtaext — 운영 전용 확장 (스케일·메모리)
_schema-version: "3.1"
ID: plant-audit.prd
extends: plant-audit
modules:
  - name: plant-audit-srv
    parameters:
      instances: 2
      memory: 512M

비용 폭탄 방지를 위해 글로벌 계정의 Usage Analytics를 첫 주에 확인하고, Alert Notification 서비스로 쿼터 초과 임박 알림을 걸어 두면 월말 정산 때 놀랄 일이 줄어듭니다. HANA Cloud 인스턴스는 개발 서브계정에서 야간 자동 중지를 설정해 비용을 크게 줄일 수 있습니다.

⚠️ 흔한 실수와 트러블슈팅 FAQ

Q1. 서비스 인스턴스 생성 버튼이 회색으로 비활성화되어 있어요.
십중팔구 엔타이틀먼트 미배정입니다. 글로벌 계정 → Entitlements → Edit에서 해당 서브계정에 서비스 플랜을 배정하세요. 배정할 수량 자체가 없다면 계약(쿼터) 문제이므로 계정 담당자와 협의해야 하고, 이 절차에 시간이 걸리므로 킥오프 전에 확인하는 것이 안전합니다.

Q2. Destination 연결 테스트는 성공하는데 앱에서 백엔드 호출이 실패합니다.
Cloud Connector의 접근 제어(Access Control)에 해당 경로(예: /sap/opu/odata)가 노출되어 있는지, Destination의 Location ID와 Cloud Connector의 Location ID가 일치하는지 확인하세요. 콕핏의 "Check Connection"은 터널 연결만 확인할 뿐 경로 권한까지 검증하지 않습니다.

Q3. 로그인은 되는데 앱 화면에서 403 Forbidden이 발생합니다.
역할 컬렉션이 사용자에게 매핑되지 않았거나, 매핑 후 재로그인(토큰 재발급)을 하지 않은 경우입니다. 권한 변경은 기존 토큰에 반영되지 않으므로 로그아웃 후 다시 로그인해야 합니다.

Q4. 개발/운영을 스페이스로만 나눴는데 문제가 되나요?
Destination·구독·역할 컬렉션이 서브계정 레벨에서 공유되므로 개발자가 운영 자원에 접근할 수 있게 됩니다. 규모가 작아도 운영만큼은 별도 서브계정 분리가 일반적으로 권장됩니다.

🚀 이후에 살펴볼 주제

초기 체크리스트를 통과했다면 다음 주제로 확장해 보세요. (1) CAP(Cloud Application Programming Model)으로 plant-audit 서비스 실제 구현, (2) SAP Cloud Identity Services(IAS)로 커스텀 IdP 구성과 MFA 적용, (3) Terraform Provider for SAP BTP로 이 글의 서브계정 구조를 완전한 IaC로 전환, (4) Alert Notification + Job Scheduling을 활용한 운영 자동화. 특히 Terraform 전환은 이 글의 btp CLI 예제와 자연스럽게 이어집니다.

✅ 킥오프 전 자가진단 체크리스트

아래 8개 항목에 모두 "예"라고 답할 수 있다면 초기 설정 리스크는 대부분 걷어낸 상태입니다. 하나라도 "아니오"가 나온다면 그 항목부터 먼저 해결하고 개발에 착수하는 편이 후반부 리스크를 줄입니다.

글로벌 계정 관리자 권한을 이미 확보했는가?
서브계정을 환경(개발·검증·운영) 단위로 분리했는가, 아니면 스페이스로만 나눴는가?
선택한 리전이 연동 백엔드·사용자 위치와 맞는지 확인했는가? (변경 불가 항목이므로 재확인 필수)
필요한 서비스의 엔타이틀먼트/쿼터를 미리 배정했는가?
역할 컬렉션을 개인이 아닌 IdP 그룹 단위로 설계했는가?
Cloud Connector 설치·방화벽 개방을 인프라팀과 초반에 협의했는가?
MTA/cTMS 기반 배포 파이프라인을 운영 반영 전에 준비했는가?
Usage Analytics와 Alert Notification으로 비용 초과 알림을 걸어 두었는가?

이 체크리스트는 노바플랜트 사례처럼 규모가 작은 프로젝트에서도 동일하게 적용됩니다. 초기 며칠을 이 항목들에 투자하면, 프로젝트 후반에 구조를 다시 짜야 하는 훨씬 큰 비용을 피할 수 있습니다.

댓글 0