기본 콘텐츠로 건너뛰기

S/4HANA Cloud BW 데이터 연계 — 데이터소스 3분류 동기화

1편에서 PCE 전환 시 BW가 가장 먼저 흔들린다는 점을 짚었다. 5편은 그 흔들림이 어디서 어떻게 작동하는지를 본다. PCE 마이그레이션의 기본 전제 하나 PCE에는 Open Item만 이관된다. 과거 데이터는 BW에 남거나 별도 백업으로 보관된다. 이 전제가 BW 데이터 연계를 단순 마이그레이션이 아니라 데이터소스 성격에 따른 동기화 전략 분기 문제로 만든다. BW의 동기화 영역과 비동기화 영역을 처음부터 다른 전략으로 접근해야 한다.

CBO 데이터소스 — 기간 기준 동기화가 가능한 영역

회사가 직접 만든 데이터소스는 가장 다루기 쉬운 영역이다.

CBO 데이터소스(ZBIF_KNA1_001, ZSD_A701_001 같은 Z 접두사로 시작하는 generic D/S)는 회사가 직접 정의했기 때문에 추출 시점, 추출 키, 데이터 적재 기간을 직접 통제할 수 있다. 본 프로젝트의 데이터소스 현황 산출물에서 CBO 데이터소스는 80여 개가 잡혀 있고, 대부분 SDI 기반(SDIEABA100, SDIBABA100)이다. SDI(Smart Data Integration)는 HANA에서 외부 시스템 데이터를 가상 또는 복제 방식으로 연결하는 방식이고, 이 위에서 만든 generic D/S는 추출 로직이 회사 손 안에 있다.

이 영역의 동기화 전략은 단순하다. PCE의 데이터 적재 기간을 고려하여 기간 기준으로 동기화. "이 시점부터 이 시점까지의 데이터를 가져와라"는 명령이 그대로 통한다. 여기서 막히는 일은 거의 없다. 기간만 정확히 잡으면 데이터는 원하는 대로 들어온다. CBO 데이터소스의 정의 자체가 동기화 가능성의 첫 번째 자산이다. 회사가 자기가 만든 것은 자기가 끌어올 수 있다. PCE 전환 직전 80여 개 CBO 데이터소스 중 무엇을 살리고 무엇을 폐기할지가 시작 단계에 정리돼 있어야 이 동기화가 실제로 가볍게 끝난다.

STD-FCM 데이터소스 결산 사이클이 제약 조건

표준 데이터소스 중 회계 영역은 결산 사이클을 따라 움직인다.

STD 데이터소스(SAP Business Content Template, BCT)는 SAP가 정의한 것이라 회사 마음대로 시점을 바꿀 수 없다. 이 중 FCM(Financial) 영역은 결산 진행 상태가 동기화의 제약이다. 본 프로젝트 BW 분과의 데이터 동기화 방안 보고서에 26년 1월 중에는 데이터 불일치, ERP에서 결산 진행중이라는 메모가 명시돼 있다. 즉 회계 결산이 진행 중인 동안에는 BW로 끌어가는 데이터 자체가 움직이는 표적이다.

전략은 두 단계로 갈린다. Delta 방식을 기간단위로 변경하여 동기화하되, 본격 동기화는 26년 2월 결산 종료 후. 결산 사이클이 끝나기 전에 데이터를 끌어오면 과정 데이터만 들어오고, BW 리포트는 조정 전 숫자를 그리게 된다. FCM 동기화 시점을 결산 종료 이후로 미루는 결정이 BW 리포트의 신뢰도를 지킨다. 이 결정은 BW 자체의 이슈가 아니라 연계 시스템의 비즈니스 사이클이 동기화 시점을 강제하는 사례다. BW 일정은 ERP 결산 일정에 맞춰져야 한다.

STD-SCM 데이터소스, 동기화 불가, 재적재로 결정

물류·구매 영역은 Open 시점의 문서 이관 구조 때문에 동기화 자체가 막힌다.

SCM(물류·구매·산업부문) 영역의 STD 데이터소스는 Delta 방식을 기간단위로 변경 불가다. PCE 오픈 시점(26.1.1~1.4)에 회사별 Open 문서가 서로 다른 일정으로 이관되고, 시스템 오픈 기간이 회사별로 다르기 때문에 단일 기간 기준 동기화가 성립하지 않는다. 즉 시점을 맞출 수 없는 데이터다.

결정은 무겁다. 26년 2월 결산 종료 후 PCE 기준으로 재 적재. 과거 이력 없이 25년 12월부터 history를 다시 쌓는다. BW 분석가 입장에서 과거 이력 손실은 큰 비용이지만, 동기화가 작동하지 않는 영역을 억지로 끌고 가다가 데이터가 깨지는 것보다는 안전한 결정이다. 불가능한 동기화를 시도하기보다 새로 시작하는 결정이 결과적으로 운영 안정성을 높인다. 이 영역의 동기화 실패가 통합 테스트(CSV) 단계에서 어떻게 다른 이슈로 번졌는지는 6편에서 따로 다룬다.

데이터소스동기화 가능성전략시점
CBO (Z·SDI)가능기간 기준 직접 동기화오픈 직후
STD-FCM조건부Delta 기간단위 + 결산 후 동기화26.2 (결산 종료 후)
STD-SCM불가재 적재 (과거 이력 없이)26.2 (결산 종료 후)

한 줄로

같은 BW이지만 데이터소스의 성격이 동기화 전략을 가른다. CBO는 회사가 통제하니 기간으로 풀고, STD FCM은 결산 사이클을 기다리고, STD SCM은 재적재로 다시 시작한다. 동기화 가능성이라는 한 가지 기준을 데이터소스마다 측정해두지 않으면, BW 오픈 직후의 한 달 동안 분석가들은 왜 이 숫자가 안 맞는가를 매일 추적하게 된다.  여기서 가장 어려운 부분은 기술적인 문제보다 과거 이력을 포기하는 결정을 납득시키는 일이었다. 그래서 이 분류 작업이 As-is 분석 단계에 데이터소스 현황 산출물로 잡혀 있어야 한다. 결정이 늦어질수록 설득해야 할 상대가 많아진다.

라벨:

댓글

댓글 쓰기

이 블로그의 인기 게시물

SAP Joule과 Generative AI in SAP / 2026 AI 카테고리의 진입

15편에서 2026 한국 SAP 시장의 풍경 과 다음 12개월의 결정점 세 가지 를 정리했고, 그 셋째가 AI 기능 확산 이었다. 20편은 그 셋째 결정점을 단독으로 들여다본다 SAP Joule이라는 어시스턴트 제품과, 그 너머의 Generative AI in SAP 카테고리. 이 글은 작가가 직접 운영해본 영역이 아닌 시장 자료와 SAP 공식 발표 기반의 트렌드 정리 다. 실제 적용 케이스가 누적되면 보강 글을 따로 낸다. SAP Joule 어시스턴트 카테고리의 등장 SAP Joule은 SAP 제품군 전반에 대화형 인터페이스 를 얹는 어시스턴트다. S/4HANA Cloud, SuccessFactors, BTP, Ariba 등 SAP 주요 제품에 공통 채팅 UI 가 들어가는 그림이다. 사용자가 자연어로 질문하면 Joule이 해당 제품의 트랜잭션이나 데이터를 가져다 답하는 흐름이다. SAP Sapphire 2023~2025의 발표에서 Joule은 전 제품 통합 어시스턴트 로 자리매김했다. Joule의 의미는 어시스턴트 자체 보다 카테고리의 등장 에 있다. SAP는 기존에 트랜잭션 코드(T-code) + Fiori 의 두 인터페이스 층을 가졌다. Joule은 그 위에 제3의 층 을 얹는다. 어떤 업무가 이 제3의 층 으로 넘어갈지, 어떤 업무는 여전히 Fiori·T-code에서 처리될지의 분류 결정 이 새로 추가된다. 시리즈 4편의 Clean Core 위계와 같은 결정 구조가 AI 카테고리에도 작동하게 된다. Generative AI in SAP Joule을 넘어선 카테고리 Joule은 어시스턴트 한 축이고, Generative AI in SAP는 그보다 넓은 카테고리다. BTP의 AI Core·AI Launchpad·Document Information Extraction 같은 기능형 AI 서비스 가 같은 카테고리에 들어간다. 어시스턴트 외에 문서 자동 처리, 마스터 데이터 자동 정제, 코드 생성 보조 같은 영역이 같은 우산 아래 묶이는 그...
댓글 쓰기
자세한 내용 보기

BTP CAP 첫 개발 사이클 PCE 관성을 깨는 결정 3가지

13편에서 Integration Suite는 도구가 아니라 재설계 결정 3가지 라고 짚었다. 같은 본질이 BTP CAP 첫 개발 사이클에서 다른 모습으로 작동한다. 14편은 그룹사가 PCE 안에서 익숙하게 일하다가 BTP 위에서 CAP 첫 사이클을 시작할 때 마주하는 3가지 함정 을 정리한다. 이 글도 13편처럼 자료 누적형 예상 패턴 글이다. 작가 일반 지식과 시리즈 4·12·13편 자료를 기반으로 했고, 실제 CAP 사이클이 진행되면 보완 글을 따로 낸다. 언어 선택의 함정 PCE의 관성에서 벗어나기 CAP의 언어는 Node.js와 Java 둘이지만, 진짜 결정 은 언어가 아니라 관성이다. CAP(Cloud Application Programming Model)은 BTP 위에서 작동하는 SAP의 표준 개발 프레임워크다. Node.js 와 Java 양쪽을 지원하고, 같은 CDS(Core Data Services) 모델 위에서 두 언어가 동등하게 동작한다. 그룹사 첫 사이클에서 이 둘 중 하나를 고를 때, 흔한 함정은 기존 ABAP 개발자가 익숙해 보이는 쪽 을 고르는 것이다. 일반적으로 Java가 문법적으로 더 친숙 해 보여서 그쪽으로 기울고, 그 결정이 팀 역량 분석 없이 굳어진다. 이 결정의 진짜 비용은 코드 라인이 아니라 런타임의 무게 에서 나온다. BTP의 Cloud Native 환경에서 Node.js는 경량 스타트업과 작은 메모리 footprint 를 만들고, Java는 엔터프라이즈 패턴과 큰 컴퓨트 사용량 을 만든다. 12편의 누적 비용 모델이 여기서 작동한다. 작은 CAP 앱을 Java로 짜면 컴퓨트 사용량 이 비례 이상으로 늘어난다. 언어 선택은 팀 역량과 Cloud Native 적합도 의 균형으로 결정해야 한다. ABAP 관성이 Java 관성으로 바뀌고, Java 관성이 학습 미완료 상태의 운영 으로 이어지는 흐름이 가장 흔한 첫 사이클 실패다. 데이터 모델 함정 CDS의 자체성을 살리는 결정 PCE의 데이터 모델을 그...
댓글 쓰기
자세한 내용 보기

2026 SAP 도입 동향 GROW·RISE·BTP의 한국 풍경

14편에서 PCE의 관성 이 BTP의 본질을 가린다고 짚었다. 그러나 이 관성도 시장의 풍경 이 바뀌면서 함께 움직인다. 15편은 시즌 1·2의 마지막 글이다. 한 그룹사 PCE 전환 사례에서 출발한 14편의 이야기를 2026 한국 SAP 시장의 풍경 속에 위치시키고, 다음 12개월의 결정점을 정리한다. 2026 한국 SAP 시장의 풍경 GROW · RISE · BTP 2026의 한국 SAP 시장은 세 가지 패키지 가 재편하고 있다. 첫째, GROW with SAP . 중견기업과 신규 도입 대상에 맞춰진 Public Cloud 기반 패키지다. 표준 프로세스를 받아들이는 대신 도입 속도와 비용 예측 가능성이 높다. 한국 시장에서는 그룹사가 아닌 단일 법인 중견기업 의 진입로로 자리 잡는 추세다. 둘째, RISE with SAP . 그룹사와 대기업의 마이그레이션 묶음 이다. S/4HANA Cloud(주로 PCE)와 BTP credit 이 함께 묶이는 구조라, 시즌 2의 11~12편이 다룬 라이센스 함정 과 CBO 전환 비용 의 시장 배경이 정확히 여기다. 셋째, BTP 단독 도입 . 기존 SAP 시스템 위에 BTP만 얹어 확장 측면 만 가져가는 모델이다. 그룹사 디지털 전환의 두 번째 단계 에서 흔히 선택된다. 한국 그룹사가 2026에 가장 많이 가는 길은 RISE 묶음 이다. 그 묶음 안에 PCE와 BTP가 어떻게 엮이는가 이게 시즌 2의 시그니처 메시지가 출발한 자리다. 2026의 의사결정자는 세 패키지 중 하나 가 아니라 세 패키지를 어떻게 조합하는가 를 결정한다. 단일 패키지를 고르는 시대는 지났고, 조합과 시점이 결정의 본체가 됐다. 이 풍경 속에서 시리즈 1~14편이 닿는 곳 시리즈 1~14편이 다룬 모든 결정이 2026 풍경의 디테일 이다. 시즌 1의 1~9편은 PCE 구축의 풀 라이프사이클 을 다뤘다 . RISE 묶음을 받은 그룹사가 마주하는 9개월의 실제 작업 이다. 1편의 코어보다 주변이 먼저 흔들린다 에서 시작해, 3편의 결...
댓글 쓰기
자세한 내용 보기