SAP BW/4HANA·SAC 환경에서 데이터 모델링을 해본 실무자라면 Palantir Foundry의 Ontology를 처음 접했을 때 “이거 InfoCube랑 비슷한 거 아닌가” 하는 생각이 먼저 듭니다. 골격은 실제로 비슷합니다. 다만 두 플랫폼은 애초에 풀려던 문제가 다르고, 그 차이가 아키텍처 전반에 퍼져 있습니다. 이 글은 SAP BW 경험이 있는 실무자를 대상으로, 개념 대응표와 제조 현장(설비 관리) 예시를 통해 두 플랫폼의 차이와 공존 전략을 정리합니다.
비교 배경: 왜 두 플랫폼을 나란히 봐야 하는가
SAP를 전사 기간계로 쓰는 조직이 Palantir Foundry를 도입할 때 가장 먼저 부딪히는 질문은 “SAP BW를 대체하는 건가, 아니면 다른 걸 하는 건가”입니다. 결론부터 말하면 대체 관계가 아닙니다. SAP는 재무·정합성이 생명인 전사 단일 진실 공급원(Single Source of Truth) 역할을 유지하고, Foundry는 그 위에서 운영·워크플로우·AI를 얹는 계층으로 붙는 하이브리드 구조가 일반적입니다. 이 구조를 이해하려면 먼저 두 플랫폼의 정체성 차이를 짚어야 합니다.
비교 기준: 정체성과 핵심 자산
| SAP BI (BW/4HANA·SAC·BO) | Palantir Foundry | |
|---|---|---|
| 정체성 | 전사 보고·분석 중심의 데이터 웨어하우스 | 분석 + 의사결정 + 실행(Writeback)을 아우르는 운영 플랫폼 |
| 핵심 자산 | InfoObject, ADSO, CompositeProvider, BEx | Dataset, Pipeline, Ontology(Object Type/Link Type/Action Type) |
| 강점 | ERP(ECC/S4) 네이티브 통합, 재무 정합성 | 온톨로지 기반 시맨틱 모델, 전체 데이터 계보(Lineage), AIP 통합 |
이 표에서 가장 중요한 줄은 정체성입니다. SAP BI는 데이터를 “보는” 플랫폼입니다. ERP 데이터를 복제·집계해 대시보드로 소비하고, 실제 실행(발주 승인, 설비 배정 등)은 다시 ERP 화면으로 돌아가야 하는 분리된 시스템입니다. 반면 Foundry는 데이터로 “행동하는” 플랫폼입니다. Action Type을 통해 객체 상태를 직접 변경하고 원천 시스템에 Writeback하면서, 분석→결정→실행이 하나의 캔버스 안에서 통합됩니다.
데이터 아키텍처 흐름 비교
| 단계 | SAP BW | Foundry |
|---|---|---|
| 소스 | ECC/S4 | Connector |
| 추출 | Extractor | Sync (Snapshot/Incremental) |
| 스테이징 | PSA/ADSO | Processed (Pipeline) |
| 통합 | Composite | Output (Dataset) |
| 종착지 | 리포팅(SAC/BEx) | Ontology + 앱(Workshop) |
핵심 차이는 종착지에 있습니다. BW의 종착지는 “쿼리(리포트)”인 반면, Foundry의 종착지는 의미를 가진 “운영 객체(Ontology)”입니다. BW 파이프라인의 최종 산출물은 사람이 읽는 리포트지만, Foundry 파이프라인의 최종 산출물은 Workshop 앱과 AIP Agent가 조회·실행 양쪽에 재사용하는 Object Type입니다.
개념 대응표 (Rosetta Stone)
SAP BW 경험을 Foundry 학습에 그대로 활용하려면 아래 대응표가 출발점이 됩니다.
| SAP Legacy (AS-IS) | Palantir Foundry (TO-BE) |
|---|---|
| [추출 구조] DataSource | Data Connection Source |
| [적재 실행] InfoPackage (Full/Delta) | Sync (Snapshot/Incremental) |
| [저장 단위] ADSO | Dataset (Parquet 기반) |
| [분석 모델] InfoCube | 비정규화 Output + Ontology |
| [마스터 데이터] InfoObject (0MATERIAL 등) | Ontology Object Type |
| [변환 로직] Transformation / AMDP | Pipeline Builder / PySpark |
파이프라인을 구축해본 경험 자체는 그대로 자산이 됩니다. 달라지는 것은 도구의 언어와, 조회 패러다임 하나입니다.
조회 패러다임: 스타 스키마에서 온톨로지 네트워크로
SAP BW의 스타 스키마는 쿼리 성능을 위해 최적화된 경직된 물리적 조인 구조입니다. Fact Table(예: 생산 실적)을 중심에 두고 시간·조직·자재·고객 같은 Dimension을 방사형으로 연결합니다.
Foundry는 비정규화 파이프라인 산출물 위에 업무 의미를 직접 모델링하는 유연한 객체 그래프를 씁니다. Customer, Order, Material 같은 Object Type이 Parquet 기반 Dataset 위에서 Link Type으로 서로 연결되며, 차원(Dimension)이라는 개념 대신 “Object” 자체가 1급 시민이 됩니다.
온톨로지 설계 4원칙
SAP 데이터를 Foundry Ontology로 옮길 때 실무에서 반복 적용되는 규칙은 네 가지입니다.
| 원칙 | 내용 |
|---|---|
| 1. 명사 → Object Type | 셀 수 있는 실체를 정의(예: 작업자, 설비, 주문) |
| 2. 속성 + PK 정의 | 실체를 설명하는 Property와, 행을 식별하는 고유값(Primary Key)을 지정 |
| 3. 동사 → Link Type | “[A]가 [B]를 ~한다” 형태로 방향성을 가진 관계를 정의 |
| 4. 카디널리티 → 구현 | 1:N은 외래키(FK), N:M은 독립된 “연결 오브젝트(Link Object)”로 구현 |
업무 문장 도출 공식은 단순합니다: 작업자(명사)가 설비(명사)를 운영(동사)한다.
카디널리티 구현 예시
1:N 관계(별도 데이터 불필요) — 작업자 1명이 여러 주문을 담당하는 관계는 주문(Order) 쪽에 FK(담당자사번)를 두는 것으로 충분합니다.
N:M 관계(독립 데이터셋으로 승격) — 작업자와 설비는 다대다로 얽힙니다(한 작업자가 여러 설비를 다루고, 한 설비를 여러 작업자가 교대로 씁니다). 이 경우 “설비운영배정”이라는 연결 오브젝트(Link Object)를 별도로 만들어 FK(사번, 설비ID)와 함께 배정일자·교대조·가동시간 같은 관계 자체의 속성을 담습니다.
실전 SAP 데이터 매핑
실제 SAP 테이블을 Ontology로 옮길 때의 매핑 예시입니다.
| SAP Raw Data | Ontology Semantics |
|---|---|
| EQUI (EQUNR) | [Object PK] 설비.설비ID |
| AUFK (AUFNR) | [Object PK] 주문.주문번호 |
| LFA1 (LIFNR) | [Object PK] 공급업체.공급업체코드 |
| AFRU (RUECK/PERNR/AUFNR) | [Link Object] 설비운영배정 |
운영 룰: 의미 필드명 변환(예: EQUNR → 설비ID)은 하위 파이프라인이 아닌, 최상위 Ontology 계층에서만 수행합니다. 파이프라인 중간 단계에서 필드명을 임의로 바꾸면 Lineage 추적이 끊기고, 같은 원천 필드가 여러 이름으로 흩어지는 문제가 생깁니다.
이렇게 매핑된 결과를 종합하면, 작업자·공급업체·설비가 주문(Order)을 허브로 연결되고, 설비운영배정·설비정비계약 같은 N:M 연결 오브젝트가 더해지면서 사일로화된 테이블들이 실제 업무 방식을 모사하는 하나의 디지털 트윈 생태계로 결합됩니다.
조회를 넘어 실행으로: Action 기반의 거버넌스된 쓰기
BW/SAC가 “보는” 플랫폼에서 멈추는 지점에서, Foundry는 Action Type으로 한 걸음 더 나갑니다. Action은 4단계로 구성됩니다.
- 파라미터(입력) — 사용자 또는 AI Agent가 입력하는 초기 값
- 규칙(검증/권한) — 데이터 정합성 검사 및 권한 보유자 관문
- 효과(쓰기) — 실제 객체의 생성·수정·삭제 수행
- Function(확장) — 로직 계산, 승인 워크플로우, Webhook 알림으로 확장
예를 들어 Workshop 화면에서 설비 담당자를 배정하는 시나리오라면, 사용자는 작업자·교대조·날짜를 선택하고 “실행” 버튼을 누릅니다. 이 버튼은 규칙(권한·정합성 검증)을 통과한 안전한 N:M 객체(설비운영배정) 생성을 트리거합니다. SAP BW/SAC에는 대응하는 개념이 없는 계층입니다 — BEx 쿼리는 조회로 끝나고, 실행은 다시 ECC/S4 트랜잭션 화면으로 돌아가야 합니다.
AIP & Agent 통합: 행위자가 되는 AI
| Foundry AIP Agent | SAP Joule & AI Core | |
|---|---|---|
| 동작 방식 | 조회 → 분석 → 조치(Action 호출)의 폐쇄 루프 사이클 | 기존 화면의 사이드카 |
| 역할 | 온톨로지 중심에 안착해 스스로 Action을 호출하는 환각 없는 운영 행위자 | 단순 자연어 질의 및 보조 역할 수행 |
이 차이는 Ontology가 Object Type뿐 아니라 Action Type까지 포함한다는 점에서 비롯됩니다. Agent가 호출할 수 있는 “행동”이 온톨로지 안에 이미 정의되어 있기 때문에, AIP Agent는 답변을 생성하는 데서 그치지 않고 검증된 Action을 실제로 실행할 수 있습니다.
상황별 선택 가이드: 대체가 아닌 공존
| 상황 | 권장 방향 |
|---|---|
| 재무 마감, 회계 정합성이 최우선인 리포트 | SAP BW/SAC를 단일 진실 공급원으로 유지 |
| 여러 시스템(ERP, MES, IoT)을 엮어 운영 의사결정을 내려야 하는 경우 | Foundry Ontology로 통합 모델링 |
| 조회 결과를 바탕으로 즉시 실행(배정, 승인, 발주)까지 이어져야 하는 경우 | Foundry Action Type으로 Writeback 구현 |
| SAP 데이터를 AI Agent가 자연어로 다루게 하려는 경우 | SAP를 소스로 두고 Foundry Ontology를 시맨틱 레이어로 브릿지 |
종합하면 네 가지로 요약됩니다.
- 골격은 유사 — BW 경험은 Foundry 학습의 강력한 자산이다.
- 목적이 갈린다 — Read 중심(SAP) vs Read+Write 통합(Foundry).
- 온톨로지가 분수령 — Object에 Action이 붙는 순간 “행동 가능한 디지털 트윈”이 된다.
- 완벽한 공존 — SAP의 원천 신뢰도와 Foundry의 운영 유연성은 대체가 아니라 온톨로지 변환 브릿지로 이어진다.
마무리
SAP BW/SAC와 Palantir Foundry는 경쟁 관계가 아니라 역할이 다른 두 계층입니다. SAP는 전사 단일 진실 공급원으로 재무·정합성을 지키고, Foundry는 그 위에서 여러 시스템을 온톨로지로 통합해 조회·의사결정·실행을 하나로 묶습니다. BW에서 익힌 모델링 감각은 그대로 옮겨 쓸 수 있으니, InfoObject를 Object Type으로, Transformation을 Pipeline Builder로 번역하는 로제타스톤부터 시작하는 것이 가장 빠른 학습 경로입니다.