BW에서 BDC로 — 무엇을 버리고 무엇을 가져가나
2027년, 결정을 미룰 수 없는 이유
SAP BW 7.5의 메인스트림 유지보수는 2027년에 끝나고, 추가 비용을 내는 확장 유지보수도 2030년까지입니다. 반면 BW/4HANA는 2040년까지 유지보수가 제공됩니다. 날짜만 보면 "BW/4HANA로 올리면 된다"는 결론이 나오지만, 현장의 질문은 조금 다릅니다.
"BW에 십수 년 쌓아 온 리포트와 로직을, 앞으로도 BW라는 그릇에 담아 둘 것인가?"
SAP가 2025년에 내놓은 Business Data Cloud(BDC)는 이 질문에 대한 SAP의 답입니다. BDC는 Datasphere, SAP Analytics Cloud, BW(Private Cloud Edition), 그리고 SAP가 관리하는 데이터 프로덕트를 하나의 플랫폼으로 묶습니다. BW 고객에게 SAP가 제시하는 경로는 세 단계입니다.
단계 | 하는 일 | 의미 |
|---|---|---|
Lift | 기존 BW를 BW/4HANA Private Cloud Edition(PCE)으로 옮김 | 운영 안정성 확보, 인프라 현대화 |
Shift | BW 객체(ADSO, CompositeProvider 등)를 데이터 프로덕트로 노출 | Datasphere·Databricks 등에서 BW 데이터를 재사용 |
Innovate | 핵심 데이터 흐름을 SAP 관리형 데이터 프로덕트로 교체 | BW 의존도 자체를 줄임 |
이 세 단계는 순서라기보다 선택지의 조합입니다. 실제 프로젝트에서는 리포트와 데이터 흐름마다 다른 단계를 적용하게 됩니다.
전환의 단위는 "시스템"이 아니라 "리포트"다
BW 전환을 시스템 마이그레이션으로 보면 범위가 끝없이 커집니다. 저희가 BW 전환 공수를 산정하면서 가장 먼저 하는 일은 리포트 단위로 운명을 정하는 것입니다.
1. 사용 실적부터 본다
BW 통계(쿼리 실행 이력)를 뽑아 보면 대개 리포트의 상당수가 최근 1년간 거의 실행되지 않습니다. 이 리포트들은 옮길 대상이 아니라 폐기 후보입니다. 폐기 결정은 IT가 아니라 현업이 해야 하므로, 사용 실적 표를 들고 현업과 한 번 정리하는 것만으로 전환 범위가 크게 줄어듭니다.
2. 남은 리포트를 세 갈래로 나눈다
분류 | 판단 기준 | 전환 대상 |
|---|---|---|
정형 경영 리포트 | 형식이 고정, 엑셀로 내려받아 가공 | Analysis for Office(AO) 또는 SAC 정형 화면 |
탐색형 분석 | 드릴다운·필터 위주 | SAC 스토리 + Datasphere 분석 모델 |
ERP 원천 조회 | 사실상 ERP 데이터를 그대로 보여 줌 | S/4HANA CDS 뷰 / Embedded Analytics로 이관 (BW 불필요) |
세 번째 분류가 의외로 많습니다. BW 도입 당시 ERP에 분석 기능이 약해서 BW로 옮겼던 리포트 중 상당수는, S/4HANA의 CDS 뷰로 충분히 대체됩니다.
3. "로직"과 "화면"을 분리해서 센다
공수를 좌우하는 것은 리포트 개수가 아니라 그 뒤에 숨은 변환 로직입니다. 같은 100본이라도 BEx 쿼리 계산식과 화면만 옮기는 경우와, 트랜스포메이션 ABAP·고객 Exit·프로세스 체인까지 재구현해야 하는 경우는 공수가 몇 배 차이 납니다. 견적을 낼 때는 리포트 목록과 별개로 로직 인벤토리(트랜스포메이션, 커스텀 ABAP, 변수 Exit)를 따로 만드는 것을 권합니다.
버릴 것과 가져갈 것
가져갈 것
현업이 합의한 지표 정의 — "매출총이익에 원가차이를 포함하는가" 같은 정의는 BW 쿼리 안에 수년간 녹아 있습니다. 화면은 다시 만들 수 있지만 이 합의는 다시 만들기 어렵습니다. 전환 전에 반드시 문서로 꺼내 두어야 합니다.
검증된 이력 데이터 — 특히 ERP 전환 이전 시점의 데이터는 원천이 사라졌을 수 있습니다.
버릴 것
쓰지 않는 리포트, 중복된 InfoProvider
ERP가 이미 제공하는 데이터를 BW에 복제해 둔 흐름
특정 담당자만 이해하는 하드코딩 로직 — 옮기지 말고 재정의하는 편이 낫습니다
실무에서 부딪히는 지점
BDC와 Datasphere 환경을 직접 구성하면서 겪은 것 중, 계획 단계에서 미리 알았으면 좋았을 것들을 정리합니다.
데이터 프로덕트 엔타이틀먼트는 두 층이다. SAP 관리형 데이터 프로덕트를 쓰려면 BDC 자체 계약 외에 해당 솔루션의 엔타이틀먼트가 별도로 필요합니다. 화면에 프로덕트가 보여도 활성화 단계에서 막힐 수 있으므로, 쓰려는 프로덕트 목록을 계약 단계에서 확인해야 합니다.
S/4HANA 쪽 준비도 필요하다. 관리형 프로덕트는 소스 시스템 측 BDC 연결 구성이 선행되어야 합니다. BDC 테넌트만 열어 놓고 연결 테스트가 실패하는 경우, 원인은 대개 소스 쪽에 있습니다.
고객 데이터 프로덕트의 공유 대상은 제한이 있다. 직접 만든 데이터 프로덕트를 어디로 내보낼 수 있는지는 대상 플랫폼별로 다릅니다. 아키텍처를 그리기 전에 "이 데이터를 최종적으로 어디서 소비할 것인가"를 먼저 정해야 합니다.
Datasphere SQL 뷰는 하나씩 만든다. 여러 개의 CREATE VIEW를 한 스크립트로 붙여넣으면 일부만 생성되거나 실패합니다. 전환 스크립트를 자동화할 계획이라면 뷰 단위 배포를 전제로 설계해야 합니다.
콘솔에서 되는 질의가 외부 접속에서도 되는 것은 아니다. Datasphere SQL 콘솔은 스페이스 권한으로 동작하지만, 외부 도구가 쓰는 Open SQL 사용자는 권한 범위가 다릅니다. 외부 소비가 필요한 테이블은 노출용 뷰를 따로 두는 것이 안전합니다.
정리 — 결정 순서
사용 실적으로 폐기 대상을 먼저 걷어낸다
남은 리포트를 "정형 / 탐색 / ERP 원천" 세 갈래로 나눈다
리포트 수가 아니라 로직 인벤토리로 공수를 센다
지표 정의를 문서로 꺼낸다
그 다음에 Lift·Shift·Innovate 중 어떤 조합으로 갈지 정한다
BW 전환은 기술 이전이 아니라 분석 자산의 재고 정리에 가깝습니다. 정리가 잘 되면 BDC로 가든 BW/4HANA로 가든 이후의 선택은 훨씬 쉬워집니다.
참고
SAPinsider, Modernizing SAP BW: The Path to Business Data Cloud
McCoy & Partners, What does the end of SAP BW 7.5 in 2027 mean for your organization?
글쓴이 Data&AI — ASPN BAC사업부에서 SAP BDC·Datasphere, 지식그래프, Joule·MCP 기반 AI Agent 구축을 다룹니다. 직접 구성하고 검증하며 얻은 실무 경험을 정리해 공유합니다.