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편의 결정 트리거, 4편의 CBO 3단계 위계, 5편의 데이터소스 3분류 동기화, 6편의 일탈 사례, 7편의 Role-매뉴얼 짝패, 8편의 Cutover 5일 시퀀스, 9편의 Hyper Care 3원칙까지 — 시리즈 안의 모든 메시지는 RISE 묶음을 결정한 회사가 운영에 도달하기까지의 길을 풀어낸 것이다.

다리(10편)와 시즌 2(11~14편)는 같은 RISE 묶음의 BTP 부분을 다룬다. 11편의 라이센스 함정, 12편의 CBO 전환 비용, 13편의 Integration Suite 시행착오, 14편의 CAP 첫 사이클 — 모두 BTP credit을 RISE에 묶어놓고 사용하지 않거나 늦게 사용하는 그룹사가 마주하는 비용과 결정의 풍경이다. 트렌드는 시장의 풍경이고, 시리즈는 그 풍경 안에서 실제 일을 하는 사람의 가이드다. 두 가지가 한 곳에서 만나야 결정이 손에 잡힌다.

다음 12개월의 결정점

2026이 끝날 때 그룹사가 추가로 잡아야 할 결정 세 가지.

첫째, PCE 구축이 끝난 그룹사의 BTP 사이드카 본격 도입 시점. 2025~2026에 PCE를 구축하고 운영을 안착시킨 그룹사는 다음 12개월에 BTP 위 첫 사이드카를 띄울 시점이 온다. 14편의 첫 사이클 함정이 이 시점에서 작동한다. 둘째, RISE 묶음 갱신 시점. RISE는 2~3년 주기로 라이센스 재협상이 있고, 첫 사이클을 마친 그룹사가 다음 사이클의 묶음 구성을 다시 결정한다. 11편의 협상력 메시지가 이 시점에 한 번 더 작동한다. 셋째, AI 기능 확산. SAP Joule과 Generative AI in SAP가 실용 영역으로 들어오는 단계에서, 어떤 업무를 AI에 맡길 것인가의 결정이 새 카테고리로 추가된다.

이 셋이 시즌 2.5(16~18편)의 주제이자 그 너머의 출발점이다. 시장이 빠르게 움직이는 만큼 결정의 시점도 짧아진다 — 2026의 그룹사 IT 의사결정자는 지난 결정의 후처리와 다음 결정의 사전 준비를 동시에 짊어지게 된다. 시리즈는 이 두 가지를 가볍게 만드는 공통 프레임을 제공하는 것이 목적이었다.

한 줄로

2026 SAP 시장은 세 패키지의 조합이 만들고, 시리즈 1~14편은 그 조합을 결정의 무게로 풀어낸 가이드다. 시즌 1·2는 여기서 닫는다. 다음 일정은 보너스 10편(심사 기간 매일 발행)과 시즌 2.5(16~18편) — 16편 PCE+BTP 동시 결정 가이드, 17편 PCE vs RISE 비교, 18편 Configuration 운용 가이드. 1~14편이 결정의 무게를 풀었다면, 시즌 2.5는 결정의 도구를 정리한다. 다음 글에서 다시 만난다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

S/4HANA Cloud PCE 전환 시작 단계, 가장 먼저 바뀌는 3가지

이미지
ERP 클라우드 전환 의사결정이 끝나면, IT 담당자와 PM은 곧장 "이제 뭘 먼저 바꿔야 하나"라는 질문에 부딪힌다. 대부분의 현장에서는 '코어만 바꾸면 되죠.'라는 가정으로 시작한다. 이러한 가정이 이 글을 쓰게 된 이유다. 실제로 일을 시작해보면 가장 먼저 흔들리는 건 코어가 아니라 코어 주변 이다. On-Prem SAP에서 S/4HANA Cloud PCE로 가는 한 그룹사 마이그레이션 프로젝트의 시작 단계에서, 가장 먼저 바뀐 세 가지 고민을  시스템 토폴로지(시스템 간 연결 구조)가 먼저 바뀐다 코어가 바뀌는 게 아니라 코어 주변이 먼저 흔들린다. On-Prem 시절 BW(Business Warehouse)는 단순했다. SAP ERP 한 곳에서 데이터를 받아 모델링하고 리포트로 풀어내면 됐다. 소스시스템은 사실상 하나, 네트워크 경로는 사내, 권한 모델은 통합. S/4HANA Cloud PCE로 옮겨가면 이 전제가 흔들린다. BW가 PCE 환경의 데이터를 어떻게 끌어올지, 기존 On-Prem BW를 그대로 둘지 함께 옮길지, 인터페이스 계정 권한을 어떻게 재설계할지 — 이 문제들이 코어 전환 전에 결판나야 한다. 이 그룹사 프로젝트에서도 BW 분과의 초기 산출물은 "소스시스템 변경(안)" 문서였다. 실제 코어 전환보다 한 단계 앞서, 데이터가 어디서 어디로 흐르는가 의 지도를 다시 그리는 일이 시작된 셈이다. WMS와 외부 결재 시스템 같은 주변 인터페이스도 같은 줄 위에 올라온다. PCE는 사내가 아니라 SAP 데이터센터에 있기 때문에, 네트워크·권한·연결 모델 자체가 새 변수가 된다. Configuration의 자유도가 줄어든다 PCE는 클라우드 옷을 입은 On-Prem이 아니다. On-Prem SAP에서는 클라이언트가 Configuration을 비교적 자유롭게 잡았다. RZ010(설정값 리스트)을 뽑아보면, 회사마다 수년간 누적된 커스텀 설정이 수백 줄씩 나오는 게 보통이...
자세한 내용 보기

S/4HANA Cloud CBO 개발 3단계 — 어디까지 위에서 끝내는가

이미지
1·2·3편을 거쳐 As-is 산출물의 결정 트리거가 작동했다고 치자. CBO List는 BTP / 표준 흡수 / 폐기 로 분류되었고, RZ010은 표준 회귀 / 변형 / 위성 으로 점수가 매겨졌다. 그 다음 질문 — 변형으로 가야 할 항목을 어떻게 개발하는가. PCE는 On-Prem이 아니다. 자유롭게 ABAP을 수정하던 시절의 도구는 일부만 남았다. 한 그룹사 PCE 전환 사례에서, CBO 개발 결정이 어떻게 3단계 위계로 정리됐는지 본다. Key User Extension으로 끝내도 되는 경우 가장 안전한 출발점은 가장 가벼운 도구다. PCE에서 새로 추가하거나 변형해야 할 항목을 받으면, 첫 번째 질문은 항상 같다 — 이걸 Key User Extension으로 풀 수 있는가 . Key User Extension은 비개발자(현업 키 유저)가 UI 도구로 필드를 추가하고, 양식을 바꾸고, 작은 룰을 거는 SAP 공식 확장 방식이다. 화면 하나에 필드 두 개 추가, 송장 양식 마스킹 변경, 사용자 정의 데이터 캡처 — 이런 작은 변형 의 대부분은 여기서 끝나야 한다. 이걸 건너뛰는 것 이 흔한 함정이다. 구관(舊官) ABAP 개발자가 보면 Key User Extension은 권한이 부족한 도구 처럼 보인다. 그래서 일단 Embedded Steampunk나 BTP로 직행한다. 결과는 작은 일에 큰 도구 를 쓴 것 — 변경관리도 무거워지고, 운영도 무거워진다. Key User로 끝낼 수 있는 일을 Embedded로 가져가면, SAP 표준 업그레이드마다 회귀 테스트 부담이 따라온다. PCE의 Clean Core 원칙은 여기서 시작된다. Embedded Steampunk가 필요한 경우 표준 동작을 비틀어야 할 때, 같은 시스템 안에서 푸는 옵션. Embedded Steampunk(in-app extensibility)는 PCE 안에서 ABAP for Cloud로 직접 코드를 작성하는 방식이다. 기존 ABAP 개발자가 가장 적응하기 쉬운 영역 — ...
자세한 내용 보기

SAP QM 검사로트 일괄합격 일탈 — CSV가 놓친 한 가지

이미지
  3편에서 As-is 산출물의 결정 트리거를 정리했고, 4편에서 CBO 개발의 3단계 위계를 다뤘다. 그러나 자료를 결정으로 읽지 못하고 문서로 쌓아둔 결과가 어떻게 나타나는지는 별개의 이야기다. 한 그룹사 PCE 전환 프로젝트가 운영 개시 직후 2026년 1월 초 에 마주한 품질재고 일괄 합격 일탈 사례를 본다. 사건은 GMP 사이트 9곳을 포함한 10개 플랜트에서 동시에 발생했고, 그 원인은 CSV 테스트 단계에서 놓친 한 가지 에 있었다. 일탈의 모습 — 생산오더 빈값에서 시작된 일괄 합격 검사로트 한 건이 전체 플랜트의 검사대기 재고를 끌고 갔다. LIMS(외부 품질관리 시스템)에서 SAP로 시험 결과를 보내면, SAP는 해당 검사로트를 합격으로 판정하고 재고 상태를 품질재고 → 가용재고 로 전환한다. 정상은 해당 검사로트에 대해서만 판정이 적용되어야 한다. 그러나 운영 개시 직후 발생한 일탈은 3~4초 간격으로 동일 시점 검사대기 재고가 일괄 가용으로 전환 되는 현상이었다. 원인의 출발점은 한 가지였다 — 생산오더 값이 빈값(blank)으로 산출된 검사로트 . PCE 마이그레이션 시 생산입고 검사유형(코드 04)의 검사로트는 생산오더와 함께 정상 이관되었다. 그러나 LIMS에서 판정 결과를 수신할 때, 검사로트와 생산오더를 매핑하는 마이그레이션 매핑 테이블 조회에서 일부 로트의 생산오더가 빈값으로 반환됐다. 이 빈값이 다음 단계의 SQL 조회 조건으로 들어가면서, 생산오더가 빈값인 모든 검사로트 가 일괄 합격 처리 대상으로 포함됐다. 한 검사로트의 빈값이 플랜트와 무관하게 전사 검사대기 재고를 끌고 가는 구조가 그 짧은 순간에 작동한 것이다. CSV 테스트가 놓친 한 가지 — 운영 환경 조건 미반영 테스트는 운영의 마이그레이션 상태를 그대로 재현하지 못했다. PCE 전환의 CSV(Computer System Validation) 단계는 2차·3차 테스트로 구성된다. 이 단계의 핵심은 운영에서 발생할 모든 시나리오를 ...
자세한 내용 보기