SAP BDC 데이터 프로덕트, 관리형으로 충분할까 직접 만들어야 할까?
테이블이 아니라 "프로덕트"로 데이터를 다룬다는 것
지난 글에서 AI를 위한 데이터 플랫폼을 다섯 개 층으로 나눴습니다. 맨 아래의 데이터 통합 층에서 SAP Business Data Cloud(BDC)가 내세우는 단위가 데이터 프로덕트입니다.
데이터 프로덕트는 테이블 묶음에 이름을 새로 붙인 것이 아닙니다. 하나의 프로덕트에는 네 가지가 함께 들어 있습니다.
데이터 — 실제 행과 열. 대개 객체 저장소(Object Store)에 Delta 형식으로 놓입니다.
의미 — 필드 설명, 키, 연관 관계를 담은 스키마 정의(CSN). AI가 숫자를 해석할 때 쓰는 2번 층의 재료입니다.
계약 — 누가 만들고 관리하는지, 변경이 어떻게 반영되는지에 대한 약속.
공유 방식 — 복제 없이(Zero-Copy) Datasphere·SAP Databricks·Snowflake 등에서 읽을 수 있는 통로.
이 네 가지를 누가 책임지느냐에 따라 데이터 프로덕트는 크게 둘로 나뉩니다. SAP가 책임지는 관리형(SAP-managed), 그리고 고객이 직접 만드는 커스텀(customer-managed) 입니다.
관리형과 커스텀, 한눈에 비교
2026년 11월 기준 공개 자료와 저희가 테스트 테넌트에서 직접 구성해 본 경험을 합쳐 정리하면 다음과 같습니다. 테스트 데이터의 수치는 실제 기업 환경을 대표하지 않으므로, 데이터 상태를 나타내는 수치는 싣지 않고 실제로 나타난 패턴과 점검 방법만 정리합니다.
구분 | 관리형 데이터 프로덕트 | 커스텀 데이터 프로덕트 |
|---|---|---|
만드는 주체 | SAP (파이프라인·델타 처리·구조 변경 대응까지) | 고객 또는 파트너 |
원천 | 주로 S/4HANA 등 SAP 애플리케이션의 릴리스된 CDS | SAP 원천(커스텀 CDS 포함), BW, 비SAP 데이터 |
수정 | 읽기 전용. 확장은 원천 CDS 확장으로 | 자유. 대신 품질·변경 관리도 직접 |
의미 정보 | SAP 업무 의미가 처음부터 붙어 있음 | 직접 정의해야 함 |
비용 구조 | BDC 라이선스와 별도로 프로덕트 이용료(용량 단위) | 저장·변환에 드는 용량 단위 |
시작 조건 | 원천 시스템 연결 + 솔루션 엔타이틀먼트 | Datasphere 객체 저장소(또는 파일 스페이스) |
잘 맞는 곳 | 표준 프로세스 데이터, 지능형 애플리케이션의 기반 | 회사 고유 지표, 비SAP 결합, AI용 가공 데이터 |
표만 보면 "표준은 관리형, 나머지는 커스텀"으로 정리되지만, 실제로 구성해 보면 경계에서 판단할 일이 꽤 많습니다.
직접 구성하며 확인한 것 ① 관리형은 "켜는 일"이 먼저다
관리형 데이터 프로덕트는 SAP가 다 만들어 준다는 점이 가장 큰 장점입니다. 그런데 처음 막히는 곳은 모델링이 아니라 활성화 조건이었습니다.
엔타이틀먼트가 두 단계입니다. BDC 테넌트를 받았다고 해서 프로덕트가 바로 켜지지 않습니다. 테넌트 프로비저닝과 별도로, 프로덕트가 속한 솔루션 단위의 엔타이틀먼트가 있어야 합니다. 저희 테스트 테넌트에서는 한때 정상 활성화됐던 프로덕트가 엔타이틀먼트 기간이 끝나자 "Entitlement Invalid" 상태로 바뀌었습니다. 데이터나 설정 문제처럼 보이지만 원인은 계약 쪽이었습니다.
원천 쪽 연결이 같이 준비되어야 합니다. 같은 시기에 원천 S/4HANA와의 연결 테스트도 실패했는데, 뿌리는 같았습니다. S/4HANA 측의 BDC 연결 구성이 끝나야 프로덕트가 데이터를 받아올 수 있습니다.
확장 필드는 이제 자동으로 따라옵니다. 예전에는 프로덕트를 활성화한 뒤에 원천 CDS를 확장하면 패키지를 다시 설치해야 했습니다. 2026년 9월부터는 원천 시스템에 추가한 커스텀 필드와 엔터티를 BDC가 자동으로 감지해, 다음 복제 주기에 데이터 프로덕트에 반영합니다. 10월에는 이 증분 확장이 S/4HANA Cloud Private Edition(2025 SP02 이상)까지 넓어졌습니다(2026년 11월 기준 What's New). 순서에 대한 부담은 줄었지만, 어떤 필드를 확장할지는 여전히 설계 단계에서 정해 두는 편이 좋습니다.
정리하면, 관리형은 "만드는 일"이 거의 없는 대신 계약과 연결을 먼저 확인해야 합니다. 이 두 가지가 PoC 일정에서 가장 많이 시간을 잡아먹는 부분이었습니다.
직접 구성하며 확인한 것 ② 커스텀은 원천 선택이 절반이다
관리형 프로덕트를 쓸 수 없던 기간에는 커스텀 프로덕트로 같은 목적을 달성했습니다. 지식그래프 글에서 소개한 손익(CO-PA) 그래프의 마스터와 팩트가 이렇게 만들어졌습니다. 이 과정에서 얻은 교훈은 대부분 "어떤 원천을 고르느냐"에 관한 것입니다.
표준 프로덕트와 같은 원천을 고르면 나중에 갈아타기 쉽습니다. 처음에는 회계 전표 Entry View 계열 CDS를 원천으로 잡았습니다. 표준 관리형 프로덕트가 노출하는 엔터티와 같은 구조라 나중에 소스만 바꾸면 된다는 계산이었습니다. 그런데 확인해 보니 매출 라인에 제품 정보가 거의 붙어 있지 않았습니다. 원장 라인아이템 계열 CDS로 바꾸자 같은 매출 라인의 상당 부분에서 판매 제품과 고객이 채워졌습니다.
같은 "회계 전표"라도 CDS마다 수익성 분석 특성이 파생되어 있는지가 다릅니다. 커스텀 프로덕트를 만들 때는 다음 순서로 원천을 고르는 것을 권합니다.
분석에 꼭 필요한 축(제품, 고객, 조직 등)을 먼저 적는다.
후보 CDS별로 그 축의 채움률을 건수와 금액 두 기준으로 실측한다.
같은 조건이면 표준 관리형 프로덕트가 노출하는 엔터티와 같은 원천을 고른다.
2번에서 금액 기준을 함께 보는 이유가 있습니다. 특정 매출 계정 하나가 대부분의 금액을 차지하면서 제품 없이 전기되는 경우, 건수로는 일부만 비어 있어도 금액으로는 대부분이 비어 있는 것으로 나타납니다. 저희 테스트 환경에서도 이 패턴이 나타났습니다. 건수만 보면 건강해 보이는 데이터가 금액으로는 거의 비어 있을 수 있습니다.
파일 스페이스에는 "성공처럼 보이는 실패"가 있습니다. Datasphere 파일 스페이스의 로컬 테이블로 데이터를 받을 때, 자동 병합(Merge Data Automatically) 옵션을 켜지 않으면 복제 흐름이 완료로 표시되어도 본 테이블은 비어 있고 델타 영역에만 데이터가 쌓입니다. 원천에 데이터가 없다고 오해하기 쉬우므로, 적재 후 본 테이블 건수를 확인하는 단계를 절차에 넣어 두어야 합니다.
직접 구성하며 확인한 것 ③ 소비 경로가 다르다
프로덕트를 만들었다면 어디서 읽을지가 남습니다. 두 프로덕트는 소비 경로가 같지 않습니다.
관리형 프로덕트는 Datasphere뿐 아니라 HANA Cloud로 바로 연결하는 배선을 확인했습니다. 지식그래프처럼 HANA Cloud 엔진을 쓰는 구성에 유리합니다.
커스텀 프로덕트의 공유 대상으로는 Snowflake와 Databricks가 제공되었고, HANA Cloud는 대상에 없었습니다. 오류가 아니라 제공 범위의 차이입니다. 2026년 11월 기준 SAP 문서에도 HANA Cloud로 공유할 수 있는 데이터 프로덕트는 S/4HANA Cloud(Public·Private)와 SuccessFactors가 만든 것으로 한정된다고 명시되어 있습니다.
Snowflake 쪽은 2026년 5월 SAP BDC Zero-Copy 커넥터가 정식 출시되어, 데이터 프로덕트를 카탈로그 연결 데이터베이스로 마운트해 조회하고 반대로 Snowflake 데이터를 BDC로 게시하는 양방향 공유가 가능해졌습니다. 경로별 특징은 SAP–Snowflake 연동 글에 정리했습니다.
소비 경로는 릴리스마다 넓어지고 있으므로, 설계 전에 "이 프로덕트를 어떤 엔진에서 읽을 것인가"를 먼저 적고 현재 테넌트에서 그 경로가 열려 있는지 확인하는 것이 순서입니다.
무엇을 언제 쓰나 — 선택 기준
지금까지의 경험을 질문 다섯 개로 줄이면 다음과 같습니다.
질문 | 예라면 | 아니라면 |
|---|---|---|
필요한 데이터가 표준 관리형 프로덕트 카탈로그에 있는가? | 관리형부터 검토 | 커스텀 |
솔루션 엔타이틀먼트와 원천 연결이 일정 안에 확보되는가? | 관리형 | 커스텀으로 먼저 시작, 이후 전환 |
회사 고유 필드(Z필드)가 필요한가? | 원천 CDS 확장 — 활성화 후 추가분도 자동 반영 | — |
비SAP 데이터나 회사 고유 지표를 결합해야 하는가? | 관리형 위에 커스텀을 얹는다 | 관리형만으로 충분 |
소비 엔진(HANA Cloud·Snowflake·Databricks)에서 해당 프로덕트를 읽을 수 있는가? | 그대로 진행 | 경로부터 재설계 |
핵심은 둘 중 하나를 고르는 문제가 아니라는 점입니다. 실무에서 가장 안정적인 모양은 관리형을 기반층으로 깔고, 그 위에 회사 고유의 가공을 커스텀으로 얹는 구조입니다. 관리형이 원천 변경과 델타 처리를 책임져 주니, 커스텀은 회사만의 의미와 결합에만 집중하면 됩니다.
관리형이 아직 준비되지 않았다면 커스텀으로 먼저 시작해도 됩니다. 다만 이때 위의 원천 선택 원칙을 지켜 두면, 관리형이 열리는 시점에 소스만 교체해 이행할 수 있습니다.
앞으로 달라질 것 — Data Product Studio
SAP는 2025년 TechEd에서 커스텀 데이터 프로덕트를 만들고 관리하는 전용 작업 공간인 Data Product Studio를 발표했습니다. 스키마 정의, SQL 기반 변환, 버전·거버넌스, 수명주기 관리를 한 화면에서 다루는 것이 목표이며, 발표 당시 정식 출시는 2026년 상반기로 계획되었지만, 2026년 11월 기준 SAP 도움말 문서와 BDC 신규 기능 목록(What's New, 10월 30일 항목까지)에는 아직 등재되지 않았고, 10월 말 TechEd 2026 발표에서도 별도 언급은 확인되지 않았습니다. 2026년 5월에는 Joule 에이전트가 자연어로 데이터 프로덕트를 찾고 만드는 기능도 비공개 프리뷰로 소개되었는데, 11월 기준 정식 출시 소식은 확인되지 않았습니다.
이 기능들이 자리 잡으면 커스텀 프로덕트를 만드는 문턱은 낮아질 것입니다. 하지만 어떤 원천을 고르고, 채움률을 금액으로 확인하고, 어떤 엔진에서 읽을지 정하는 판단은 도구가 대신해 주지 않습니다. 출시 시점과 제공 범위는 도입할 때 SAP 문서와 테넌트에서 직접 확인하는 것을 권합니다.
시작 전 체크리스트
필요한 데이터가 관리형 카탈로그에 있는지, 있다면 솔루션 엔타이틀먼트가 포함되어 있는지
원천 S/4HANA 측 BDC 연결 구성 담당과 일정
커스텀 필드 확장 계획 — 어떤 필드를 프로덕트에 실을지(활성화 후 추가분은 다음 복제 때 자동 반영)
커스텀 원천 후보별 핵심 축 채움률(건수·금액) 실측
적재 후 본 테이블 건수 확인 단계(자동 병합 옵션 포함)
소비 엔진별 공유 경로가 현재 테넌트에서 열려 있는지
객체 저장소 용량과 용량 단위(CU) 예산 — 개발 테넌트도 포함
데이터 프로덕트는 통합 층의 단위이지만, 위에서 본 것처럼 그 품질이 곧 의미 층과 관계 층의 품질을 정합니다. BW에서 BDC로 넘어가는 글에서 "무엇을 가져갈지"를 정했다면, 이번 글은 "어떤 형태로 가져갈지"에 대한 답입니다.
다음 회차에서는 의미 층으로 올라가, 원가차이를 자재 단위로 쪼개 마진의 원인을 따라가는 마진 드라이버 트리 설계를 다룹니다.
참고
Snowflake Documentation, SAP® BDC Zerocopy Connector (General availability), 2026-05-04
SAP Community, SAP TechEd 2025 Announces Enhanced Data Product Capabilities
McCoy & Partners, Building and extending Data Products with SAP Business Data Cloud
sovanta, SAP Business Data Cloud: How Data Products are used
SAP Help Portal, What's New in SAP Business Data Cloud (2026-11 확인)
SAP Help Portal, Consuming Data Products in SAP HANA Cloud
글쓴이 Data&AI — ASPN BAC사업부에서 SAP BDC·Datasphere, 지식그래프, Joule·MCP 기반 AI Agent 구축을 다룹니다. 직접 구성하고 검증하며 얻은 실무 경험을 정리해 공유합니다.
기업 데이터, AI 활용을 위한 기반부터 준비하세요.
분산된 데이터의 통합부터 분석 환경 구축, AI 서비스 연계까지.
기업 환경에 맞는 데이터 플랫폼 및 AI 활용 방안을
ASPN과 상담해 보세요.