BPC와 Group Reporting, 연결 엔진은 무엇이 다른가 ② 아키텍처
연재: SAP BPC vs Group Reporting 연결 엔진 비교 (2/5) ① 비교의 틀 · ② 아키텍처 · ③ 데이터 모델 · ④ 프로세스 · ⑤ 시사점과 용어 대응표
지난 회차에서 두 엔진의 차이를 '유연성 대 정합성'이라는 한 문장으로 요약했습니다. 이번 회차에서는 그 차이가 어디에서 시작되는지, 즉 연결 엔진이 어디에서, 무엇으로 실행되는지를 다섯 가지 측면에서 살펴봅니다.
1. 플랫폼 포지셔닝: 모든 차이의 출발점
BPC는 ERP 외부의 BW 위에서, GR은 S/4HANA Universal Journal 위에서 동작합니다. 이 위치 차이가 이후에 다룰 거의 모든 차이의 출발점입니다.
비교 항목 | BPC (Standard) | GR (Public Cloud) |
|---|---|---|
실행 플랫폼 | SAP BW(BW/4HANA) 위의 EPM 애플리케이션. 연결 전용 시스템으로 별도 구축 | S/4HANA에 내장된 연결 기능. 별도 연결 시스템 없음 |
원장과의 관계 | ERP 원장과 분리된 저장소. 적재 시점 기준의 데이터 사본 | 개별 원장(ACDOCA)과 연결 원장(ACDOCU)이 같은 시스템 안에 공존 |
마스터 데이터 | BPC Dimension으로 별도 관리. ERP 마스터와의 동기화는 운영 절차에 의존 | 연결 마스터는 별도이나 회사·G/L 계정과 매핑으로 연계 |
운영·업그레이드 | 연결 시스템 단독으로 운영·업그레이드 일정 결정 | S/4HANA Public 릴리스 주기에 맞춰 연결 기능도 함께 업그레이드 |
BPC 경험자가 GR을 볼 때: 연결 데이터가 원장과 같은 시스템에 있으므로 별도의 추출·적재 설계가 필요 없습니다. 원장이 바뀌면 Release Task를 다시 실행해 연결에 반영합니다.
GR 경험자가 BPC를 볼 때: BPC의 연결 데이터는 ERP와 분리된 사본입니다. 원장과 연결 데이터가 서로 맞는지는 적재 절차와 대사를 통해 따로 확인해야 합니다.
2. 데이터 저장과 흐름: 추출·적재 계층의 유무
BPC에서는 개별 법인 데이터가 연결 엔진에 도달하기까지 여러 단계를 거칩니다.
[BPC] ECC·S/4HANA 원장 → BW 추출(DataSource) → DM Package 변환·적재 → BPC 연결 Model
[GR] ACDOCA 개별 원장 → G/L 계정 → FS Item 매핑 → Release Task(델타 반영) → ACDOCU 연결 원장GR에서도 데이터는 ACDOCA에서 ACDOCU로 넘어갑니다. 즉 연결 원장에 별도로 쌓인다는 점은 같습니다. 차이는 다른 시스템으로 데이터를 옮기는 추출·적재 계층이 없다는 것입니다.
GR의 Release는 한 번 실행하고 끝나는 작업이 아닙니다. 회계 원장에서 조정이 일어날 때마다 다시 실행할 수 있고, 직전 릴리스와 비교해 바뀐 부분만 델타로 반영합니다. 회계 기간이 마감되면 마지막으로 한 번 실행한 뒤 해당 Task를 차단하는 것이 일반적인 운영 방식입니다.
비교 항목 | BPC (Standard) | GR (Public Cloud) |
|---|---|---|
비통합 법인 데이터 수집 | Input Schedule 또는 Flat File 업로드 후 DM Package로 적재 | Flexible Upload로 ACDOCU에 직접 반영 (YTD 누적 입력 지원) |
원장 변경 반영 | 원장 수정 시 추출과 DM Package를 다시 실행해야 연결 데이터에 반영됨 | 원장 수정 시 Release Task를 다시 실행하면 변경분만 반영됨 |
BPC 경험자가 GR을 볼 때: DM Package의 Transformation·Conversion에서 처리하던 계정 매핑은 GR에서 'G/L 계정 → FS Item 매핑'이라는 연결 마스터 설정으로 옮겨갑니다.
GR 경험자가 BPC를 볼 때: BPC 연결 데이터의 품질은 적재 로직(Transformation·Conversion)에 좌우됩니다. 수치에 이상이 있으면 원장보다 적재 로직부터 확인하는 것이 효율적입니다.
3. 연결 로직 실행 엔진: '작성'과 '구성'
BPC는 Business Rule, Script Logic, BAdI로 연결 로직을 작성합니다. GR은 Task, Method, Rule로 연결 로직을 구성합니다.
비교 항목 | BPC (Standard) | GR (Public Cloud) |
|---|---|---|
로직 정의 | Business Rule 테이블(환산, IC Booking, US Elim, 연결 방법) + Script Logic | Method(환산, 제거, 재분류, 투자자본 상계)와 Rule을 구성 |
커스텀 로직 | Script Logic 또는 BAdI(ABAP)로 표준 외 계산을 플랫폼 안에 추가 | 표준 Task 안에 사용자 로직을 넣는 구조가 아님. 확장은 RAP로 별도 구현 |
실행 단위 | DM Package가 Rule·Script를 호출. 실행 순서는 Package·BPF 설계에 의존 | Method를 Task에 할당하고 Task Group 순서로 실행. 실행 순서가 구성으로 고정 |
변경 영향 | 스크립트 수정이 즉시 결과에 반영. 변경 이력·검증은 운영 절차에 의존 | 표준 설정 앱에서 구성을 변경. 영향 범위가 Method·Task 단위로 한정 |
BPC 경험자가 GR을 볼 때: Script Logic으로 처리하던 예외 계산을 GR에서 같은 방식으로 찾으면 없습니다. 먼저 표준 Method로 표현할 수 있는지 확인하고, 불가능한 부분만 확장으로 분리해야 합니다.
GR 경험자가 BPC를 볼 때: BPC의 연결 결과는 Business Rule에 더해 Script Logic과 BAdI가 함께 만든 것입니다. Business Rule 설정만 보고 로직 전체를 판단하면 안 됩니다.
4. UI와 리포팅 계층: 한 시트인가, 분리된 계층인가
BPC에서는 Excel(EPM Add-in)이 데이터 조회와 레이아웃을 함께 담당합니다. GR에서는 CDS 기반 쿼리가 데이터 계층을 맡고, Fiori나 SAC 같은 표현 계층은 분리되어 있습니다.
계층 | BPC (Standard) | GR (Public Cloud) |
|---|---|---|
표현 계층 | EPM Add-in (Excel). 조회·입력·레이아웃·수식을 한 시트에서 처리하고, Local Member와 Excel 수식으로 셀 단위 가공 | Fiori 앱, SAC 등 표현 도구 |
조회 로직 | (위와 같은 시트에서 처리) | CDS 분석 쿼리와 FS Item 계층구조 (계정 정렬·소계·계산 정의) |
데이터 계층 | BPC 연결 Model (BW Cube) | ACDOCU (연결 원장) |
BPC 경험자가 GR을 볼 때: 보고서 양식 변경이 Excel 수정으로 끝나지 않습니다. 계정 정렬과 소계는 FS Item 계층구조에서, 계산은 쿼리에서 정의해야 합니다.
GR 경험자가 BPC를 볼 때: BPC 보고서의 수치는 시트 안의 수식과 Local Member로 가공된 결과일 수 있습니다. 시스템 데이터와 같다고 바로 단정하면 안 됩니다.
5. 확장 아키텍처: 표준이 지원하지 않는 요구를 어디서 해결하는가
어느 엔진이든 표준 기능만으로 모든 요구를 충족할 수는 없습니다. 대표적인 예가 투자자본 이력 관리(취득, 추가 취득, 처분, 단계 취득 등)입니다. 두 엔진 모두 표준 기능으로는 투자 이벤트 이력을 관리하지 않습니다. 차이는 그 공백을 어디에서, 어떤 방식으로 메우느냐입니다.
비교 항목 | BPC (Standard) | GR (Public Cloud) |
|---|---|---|
확장 위치 | BPC 플랫폼 내부 (같은 Environment) | 같은 테넌트의 on-stack 확장 영역. 표준 객체는 수정 불가 (Clean Core) |
데이터 저장 | 별도 Model 추가 (예: 투자자본 이력 Model) | 커스텀 테이블 (Z 테이블 또는 CBO) |
로직 구현 | Script Logic, BAdI | RAP 비즈니스 객체 + ABAP Cloud |
표준 연동 | Model 간 데이터 이동 (DM Package, Script) | Released API로 연결 분개 전기 및 데이터 조회 |
여기서 on-stack은 S/4HANA Public 테넌트 안에서 ABAP Cloud 기반으로 개발하는 Developer Extensibility를 말합니다. 별도의 BTP 환경에서 개발하는 side-by-side 방식과는 구분됩니다.
BPC 경험자가 GR을 볼 때: BPC에서 Model 하나를 추가하던 수준의 확장이 GR에서는 개발 과제가 됩니다. 대신 확장이 표준과 분리되어 있어 업그레이드 영향을 통제할 수 있습니다.
GR 경험자가 BPC를 볼 때: BPC의 투자자본 관리는 표준 기능이 아니라 고객별 커스텀 Model과 로직입니다. 전환이나 유지보수를 맡게 되면 해당 로직부터 분석해야 합니다.
이번 회차 정리
BPC는 ERP 밖의 BW에, GR은 S/4HANA 안에 있습니다. 이 위치 차이가 데이터 흐름, 로직 실행, 보고, 확장 방식의 차이로 이어집니다.
GR에서 사라지는 것은 연결 원장 자체가 아니라 별도 시스템으로의 추출·적재 계층입니다.
두 엔진 모두 표준의 공백은 확장으로 메웁니다. BPC는 플랫폼 안에서, GR Public은 Clean Core 원칙에 따라 Core 밖에서 확장합니다.
다음 회차에서는 이 아키텍처 차이가 데이터 모델에 어떤 영향을 주는지 살펴보겠습니다.
참고 자료