SAP BTP Cockpit 마스터하기: 누구나 따라 할 수 있는 간단한 단계

SAP Business Technology Platform(BTP) Cockpit은 SAP 클라우드 환경을 운영하는 웹 콘솔입니다. 계정, 서비스, 사용자, 보안, 배포된 애플리케이션, 비용을 다룹니다. BTP를 관리하거나, 여기에 배포하거나, 청구서를 승인하는 입장이라면 이 화면이 일터가 됩니다.

접속하려면 해당 지역의 게이트웨이를 여십시오. https://emea.cockpit.btp.cloud.sap, https://amer.cockpit.btp.cloud.sap, https://apac.cockpit.btp.cloud.sap 중 하나입니다(SAP Learning). SAP 사용자 ID가 필요하며, 관리자가 만들어 줄 수 있습니다. 트라이얼 계정은 https://cockpit.hanatrial.ondemand.com/trial/을 사용하며 최대 90일간 유지되고, 30일이 지나면 연장이 필요합니다(SAP Developers).

그다음 아래 순서대로 설정하십시오. 저는 처음에 이 순서를 알아내느라 며칠을 썼습니다. 고생의 대부분은 4단계를 1단계보다 먼저 한 데서 나왔습니다.

모든 것은 계층 구조 안에 있습니다. 글로벌 계정은 SAP와 맺은 계약이며, 구매한 서비스 풀을 보유합니다. 디렉터리는 서브계정을 예를 들어 사업부별로 묶습니다. 서브계정은 실제 작업이 이루어지는 곳으로, 각각 리전, Cloud Foundry나 Kyma 같은 환경, 고유한 사용자, 고유한 서비스 인스턴스를 가집니다.

1. 글로벌 계정SAP와 맺은 계약과 구매한 서비스
   엔타이틀먼트각 서브계정이 가져다 쓰는 유한한 풀
2. 디렉터리서브계정을 묶는 단위, 예를 들어 사업부별

• Finance-Dev개발, 무료 또는 소형 플랜
• Finance-Test테스트, 자체 사용자와 역할 컬렉션
• Finance-Prod운영, 가동 전에 알림 설정

BTP는 애플리케이션 개발과 자동화, 통합, 데이터와 분석, AI의 네 영역을 다룹니다. Cockpit에서 네 영역을 모두 만나게 되지만, 대부분의 프로젝트는 통합과 S/4HANA 확장에서 시작합니다.

새 글로벌 계정에서 제가 따르는 순서입니다. 각 단계에는 자연스러운 담당자가 있습니다.

1. 서브계정 구조와 명명 규칙 합의(플랫폼 오너). 영역별로 개발, 테스트, 운영을 둡니다. 예: Finance-Dev, Finance-Test, Finance-Prod.
2. ID 공급자 연결(보안 책임자). 사용자를 한 명이라도 추가하기 전에 하십시오.
3. 직무별 역할 컬렉션 정의(보안 책임자). 비상용(break-glass) 관리자 컬렉션 하나를 포함합니다.
4. 엔타이틀먼트 배분, 최소한으로 시작(플랫폼 오너). 팀이 필요성을 보여 주면 그때 추가합니다.
5. BTP가 온프레미스 시스템에 접근해야 한다면 Cloud Connector 설치 및 구성(인프라 팀).
6. 알림과 사용량 검토 활성화(플랫폼 오너). 누가 무엇을 얼마나 자주 볼지 정합니다.
7. Cockpit 밖에 모든 것을 기록(아키텍트). 구조, 명명 규칙, 엔타이틀먼트 배분, 그리고 각각의 이유.

서브계정과 엔타이틀먼트

대부분의 팀이 몇 년씩 따라다니는 혼란을 만들어 내는 곳이 여기입니다.

한 고객사는 이름이 제각각인 서브계정이 50개가 넘었고, 아무도 무엇이 어디 있는지 찾지 못했습니다. 프로젝트 도중에 이를 풀어내는 일은 고통스럽습니다. 먼저 하루를 들여 구조를 종이에 그려 보십시오. 여러 리전에서 운영한다면 구조를 리전마다 똑같이 맞추고, 레이블로 관련 서브계정을 묶으십시오.

엔타이틀먼트는 각 서브계정이 어떤 서비스를 얼마나 쓸 수 있는지를 정합니다. 글로벌 계정의 풀은 유한합니다. 저는 최소한으로 시작해 필요에 따라 늘리며, 이 방식 덕분에 고객사들은 쓰지 않는 서비스에 나갈 비용을 수천 단위로 절감했습니다. 많은 서비스에 무료 플랜이 있으며 테스트에는 그것으로 충분합니다.

사용자, 트러스트, 역할 컬렉션

회사에 Microsoft Entra ID나 Okta 같은 ID 공급자가 이미 있다면 BTP 사용자를 직접 관리하지 마십시오. SAP가 권장하는 방법은 SAP Cloud Identity Services 테넌트를 두고 서브계정의 Security > Trust Configuration에서 연결하는 것입니다. 그러면 이 테넌트가 회사 ID 공급자의 프록시 역할을 합니다. 트러스트는 OpenID Connect로 자동 설정할 수 있습니다. 2단계 인증과 접근 정책도 한곳에서 관리됩니다.

역할 컬렉션은 사용자나 그룹에 할당하는 역할 묶음입니다. 제 방식은 다음과 같습니다.

1. 개인이 아니라 직무를 기준으로 만듭니다.
2. 의미가 있을 만큼 구체적이되, 수백 개를 유지해야 할 만큼 잘게 나누지는 않습니다.
3. 비상 상황용 break-glass 관리자 컬렉션을 하나 둡니다.
4. 분기마다 할당을 검토합니다. 사람들은 직무를 바꾸고도 예전 권한을 그대로 가지고 있습니다.

서비스, 인스턴스, 키

서비스 인스턴스를 만들려면 서브계정에서 Services > Service Marketplace를 열고, 서비스를 고른 다음 플랜을 선택합니다. 플랜이 기능과 비용을 모두 좌우합니다. 선택한 설정은 Cockpit 밖 어딘가에 저장해 두십시오. 문제가 생겼을 때 필요합니다.

인스턴스를 애플리케이션에 바인딩하면 BTP가 자격 증명을 주입합니다. BTP 애플리케이션이 아닌 외부 도구에는 서비스 키를 만드십시오. 키 이름은 key1이 아니라 jenkins-deployment처럼 누가 쓰는지 알 수 있게 짓습니다.

런타임 선택

Cockpit은 세 가지 주요 환경을 제공합니다. 팀의 역량을 앞에 놓고 고르십시오.

런타임	적합한 용도	주의할 점
Cloud Foundry	Java, Node.js, Python 앱, SAP Cloud Application Programming Model(CAP) 포함	검증된 기본 선택지이며 대부분의 팀에게 예상 밖의 일이 가장 적음
Kyma	Kubernetes 네이티브 마이크로서비스와 이벤트 기반 확장	많은 SAP 팀이 갖추지 못한 Kubernetes 역량이 필요
ABAP environment	S/4HANA 옆의 ABAP Cloud 확장	ABAP 개발자에게 자연스러운 선택이며 릴리스된 API만 사용

아키텍처 계획에는 맞지만 개발자의 경험에는 맞지 않는 새 환경을 배워야 해서 몇 달씩 지연된 프로젝트를 본 적이 있습니다. 기술적으로 더 나은 런타임이라도 팀이 그 위에서 만들 수 없다면 더 나쁜 선택입니다.

Cloud Foundry에 배포하려면 앱을 manifest.yml에 기술한 다음(메모리, 인스턴스, 빌드팩, 환경 변수) CF CLI나 파이프라인으로 푸시합니다. Cloud Foundry가 빌드팩을 감지하고, 서비스를 바인딩하고, 라우트를 설정합니다.

BTP를 S/4HANA 및 다른 시스템에 연결하기

BTP 작업의 대부분은 통합입니다. 제가 가장 자주 설정하는 패턴은 다음과 같습니다.

시나리오	설정 방법
S/4HANA 온프레미스 또는 Private Edition	사내 네트워크의 Cloud Connector, 서브계정의 destination, 그다음 OData 또는 SOAP API
SuccessFactors 같은 SAP 클라우드 앱	Destination과 Integration Suite 또는 Event Mesh, 확장은 CAP으로
Salesforce나 Workday 같은 비SAP 시스템	Integration Suite 어댑터 또는 커스텀 통합 플로우
자체 API 공개	Integration Suite의 API Management: 설계, 게시, 모니터링

Cloud Connector는 BTP로 나가는 아웃바운드 터널을 열기 때문에 인바운드 방화벽 규칙이 필요 없습니다. BTP가 실제로 필요로 하는 시스템과 URL 경로만 노출하십시오. 통합이 주된 용도라면 제 SAP CPI 글에서 설계 선택지를 더 깊이 다룹니다.

모니터링과 비용 통제

필요해지기 전에 모니터링을 설정하십시오. 저는 매일 아침 커피를 마시며 대시보드를 확인합니다. 이제는 하나의 의식이 되었고, 덕분에 '시스템이 왜 멈췄지?' 하는 상황을 여러 번 피했습니다.

설정할 항목은 다음과 같습니다.

1. 알림. SAP Alert Notification service가 플랫폼 및 애플리케이션 이벤트를 이메일, Slack, 또는 자체 알림 도구로 보냅니다. 제가 주로 쓰는 구성은 중요한 앱은 이메일, 멈추면 안 되는 앱은 Slack 웹훅입니다.
2. 애플리케이션 상태. Cloud Foundry나 Kyma 뷰에서 확인하는 애플리케이션별 응답 시간과 오류율.
3. 사용량과 비용. 각 서브계정의 Usage Analytics, 글로벌 계정 수준의 Costs and Usage. 사용량 값은 24시간마다 갱신됩니다.

쓰지 않는 서비스 인스턴스는 매달 삭제하십시오. 개발 스페이스는 업무 시간 외에 축소하십시오. 갱신 전에 엔타이틀먼트 사용량을 확인하십시오. 사용하지 않는 할당분이 과다 지출의 흔한 원인이기 때문입니다.

자동화와 사용자 지정 도메인

Cockpit을 일일이 클릭하는 방식은 확장되지 않습니다. BTP 명령줄 인터페이스(btp CLI)와 플랫폼 API로 UI가 하는 거의 모든 일을 스크립트로 처리할 수 있습니다. 서브계정 생성, 엔타이틀먼트 할당, 개발자 프로비저닝 등입니다.

한 프로젝트에서 신규 개발자 12명의 환경이 필요했습니다. 하루 종일 Cockpit을 클릭하는 대신 스크립트를 실행하고 커피를 마시러 갔습니다. 돌아오니 모든 것이 준비되어 있었습니다. 배포를 자동화해서 한 프로젝트의 설정 시간을 80퍼센트 줄였고, 서비스 키와 CF CLI를 파이프라인에 연결해 배포가 몇 시간에서 몇 분으로 줄었습니다.

사용자 지정 도메인은 사용자에게 노출되는 앱이라면 공을 들일 가치가 있습니다. Cockpit 메뉴가 아니라 SAP Custom Domain service로 구성합니다. 한 고객사 프로젝트에서는 경영진이 더 전문적인 인상을 곧바로 알아챘습니다.

1. 명명 규칙을 합의하기 전에 서브계정을 만든다.
2. 역할 컬렉션과 그룹이 아니라 개인에게 역할을 할당한다.
3. 개발용 서비스를 운영 규모 플랜으로 돌린다.
4. 첫 장애가 난 뒤로 알림 설정을 미룬다.
5. 계정 구조와 그 이유를 문서화하지 않는다. Cockpit에는 무엇이 저장되지만, 왜는 저장되지 않습니다.

특정 오류에서 막히셨습니까? 제 BTP Cockpit 문제 가이드에서 흔한 사례를 다룹니다. Clean Core 가이드는 S/4HANA 프로젝트에서 BTP 확장이 어디에 들어맞는지 설명합니다.

SAP BTP Cockpit은 무엇에 사용합니까?

SAP Business Technology Platform의 웹 기반 관리 콘솔입니다. 서브계정 생성, 엔타이틀먼트 배분, 사용자와 트러스트 관리, 서비스 인스턴스 생성, 애플리케이션 배포와 모니터링, 사용량과 비용 추적에 사용합니다.

SAP BTP Cockpit 로그인 URL은 무엇입니까?

지역별 게이트웨이를 사용하십시오. 유럽, 중동, 아프리카는 https://emea.cockpit.btp.cloud.sap, 아메리카는 https://amer.cockpit.btp.cloud.sap, 아시아 태평양은 https://apac.cockpit.btp.cloud.sap입니다. 트라이얼 계정은 https://cockpit.hanatrial.ondemand.com/trial/을 사용합니다. 로그인하려면 SAP 사용자 ID가 필요합니다.

SAP BTP에서 서브계정은 어떻게 구성해야 합니까?

처음부터 개발, 테스트, 운영을 각자의 서브계정으로 분리하고, 영역과 단계를 바로 알 수 있도록 Finance-Dev, Finance-Prod처럼 이름을 붙이십시오. 규모가 큰 조직은 사업부별로 디렉터리를 추가합니다. 먼저 종이에 계획하십시오. 서비스가 돌기 시작하면 구조를 바꾸기 어렵습니다.

SAP BTP의 네 가지 축은 무엇입니까?

SAP는 BTP를 애플리케이션 개발 및 자동화, 통합, 데이터 및 분석, 인공지능으로 구분합니다. 대부분의 프로젝트는 통합과 S/4HANA 확장에서 시작하고, 플랫폼이 안정된 뒤에 데이터와 AI 활용 사례를 추가합니다.

ID 공급자를 SAP BTP에 연결하려면 어떻게 합니까?

SAP Cloud Identity Services 테넌트를 설정하고 Security > Trust Configuration에서 서브계정과 트러스트를 구성하십시오. OpenID Connect로 이를 자동화할 수 있습니다. 그다음 Microsoft Entra ID나 Okta 같은 회사 ID 공급자를 그 테넌트에 연결합니다. 이후 사용자와 2단계 인증은 한곳에서 관리됩니다.

BTP 런타임은 Cloud Foundry, Kyma, ABAP environment 중 무엇을 선택해야 합니까?

팀에 맞추십시오. Cloud Foundry는 Java, Node.js, Python 앱에 적합하며 가장 안전한 기본 선택입니다. Kyma는 Kubernetes 네이티브 마이크로서비스에 적합하지만 Kubernetes 역량이 필요합니다. ABAP environment는 ABAP 개발자가 S/4HANA 옆에서 Clean Core 확장을 만들 때 적합합니다.

SAP BTP를 온프레미스 SAP 시스템에 연결하려면 어떻게 합니까?

네트워크 내부에 Cloud Connector를 설치하십시오. BTP로 나가는 보안 아웃바운드 터널이 열리므로 인바운드 방화벽 변경은 필요 없습니다. BTP가 필요로 하는 시스템과 경로만 노출하고, 서브계정의 Connectivity에서 연결을 확인한 다음, 앱과 통합 플로우가 호출할 destination을 만드십시오. 운영에 올리기 전에 전체 경로를 테스트하십시오.