지난 글에서는 SAP S/4HANA Public Cloud의 개요와 도입 방법론을 살펴봤습니다. Public Cloud가 제공하는 모듈형 아키텍처, 자동 업그레이드, Fiori UX, 베스트 프랙티스 기반의 표준 프로세스, 그리고 Activate 방법론이 어떻게 ERP 도입을 단순화하고 속도를 높이는지 확인했습니다.
하지만 ERP는 도입 그 자체보다 운영 이후가 훨씬 더 중요합니다. Public Cloud는 SaaS 모델이기 때문에, 구축 이후에도 매년 새로운 기능과 프로세스가 추가되고, 기업은 이를 빠르게 수용하고 안정적으로 운영해야만 가치를 극대화할 수 있습니다. 이번 글에서는 Public Cloud 운영의 본질과 업그레이드 관리, 성공 요인, 확장성 활용, 그리고 실제 연계 시나리오와 FAQ까지 구체적으로 다루겠습니다.
전통적인 온프레미스 ERP는 일단 구축하고 나면 3~5년 단위로 대규모 업그레이드 프로젝트를 따로 진행했습니다. 하지만 이 과정은 비용과 시간이 많이 들고, 업그레이드가 완료되었을 땐 이미 시스템이 다시 뒤처지는 경우가 많았습니다.
반면 SAP S/4HANA Public Cloud는 정기 릴리즈를 통해 끊임없이 진화합니다. 즉, ERP가 더 이상 정적인 시스템이 아니라, 살아 움직이는 플랫폼이 되는 것이죠. 기업 입장에서는 단순히 “ERP를 도입했다”에서 끝나는 것이 아니라, ERP가 매년 발전해가는 속도에 맞춰 조직의 운영 방식도 함께 진화해야 합니다.
Public Cloud는 매년 2월과 8월, 두 차례 정기 릴리즈가 진행됩니다. 업그레이드는 CBC 개발 테넌트 → QA(테스트) 테넌트 → 프로덕션 순으로 순차 적용되며 안정성을 확보합니다.
이 릴리즈에는 크게 세 가지 변화가 포함됩니다.
법규/규제 반영: 예를 들어 한국의 전자세금계산서 제도 변경이 발생하면, Public Cloud는 릴리즈를 통해 이를 자동 반영합니다.
프로세스 개선 및 기능 추가: 기존 재무 회계, 구매, 자산 관리 프로세스가 개선되거나 새로운 기능이 추가됩니다.
UI·앱 교체: 기존 앱이 비활성화되고 새로운 앱으로 대체되기도 합니다.
실제 사례: 자산 관리 모듈에서 기존 감가상각 처리 앱이 교체되면서 새로운 앱이 제공된 적이 있습니다. 이때 고객은 새 앱을 학습하고, 기존 데이터를 매끄럽게 이전해야 했습니다.
따라서 업그레이드는 “자동 제공되는 혜택”이면서 동시에 “철저히 준비해야 할 운영 이벤트”입니다.
변경 영향 분석: SAP의 What’s New Document를 기반으로 변화가 미칠 영향을 파악
테스트 자동화: 반복 가능한 핵심 업무 시나리오를 테스트 케이스로 확보
사용자 교육/커뮤니케이션: 변화된 화면과 기능을 사전에 안내하고 교육
이러한 준비가 없다면 업그레이드는 혁신이 아니라 혼란이 될 수 있습니다.
1. 공동의 목표 의식
프로젝트 매니저, 컨설턴트, 고객 모두가 같은 목표를 바라보고 있어야 합니다.
ERP 도입에서 흔히 발생하는 실패 요인은 이해관계자 간의 우선순위 불일치입니다. KPI를 명확히 정의하고, 모든 참여자가 같은 그림을 공유하는 것이 중요합니다.
2. 표준 프로세스 중심 접근
Public Cloud는 표준화된 프로세스 위에서만 지속적 업그레이드가 가능하기 때문에, 기업은 표준 프로세스를 최대한 수용해야 합니다. 커스터마이징이 많아질수록 업그레이드 충돌 가능성이 높아지고, 클린 코어 원칙도 훼손됩니다.
3. 역량 있는 프로젝트 팀
PM은 프로젝트를 일관성 있게 이끌고, 솔루션 및 이해관계자 간 협업을 조율합니다.
키 유저(Key User)는 클라우드 마인드셋을 가지고 변화를 수용해야 합니다. 데이터 정비, Fit-to-Standard 참여, 신속한 의사결정이 필수입니다.
컨설턴트/개발자는 Public Cloud의 기능과 업그레이드 변화를 파악하고, 이를 고객 프로세스에 세밀하게 반영할 수 있어야 합니다.
4. 기준정보(Master Data) 정비
마스터 데이터 품질은 ERP 성공의 핵심입니다. 데이터가 부정확하면 프로세스 자동화나 보고가 왜곡될 수 있습니다. Public Cloud는 마이그레이션 코크핏이라는 강력한 툴을 제공해 대량의 마스터 데이터를 이행·검증할 수 있습니다.
5. 반복적인 테스트
Public Cloud는 빠르게 변화하기 때문에, 테스트 또한 반복적으로 수행해야 합니다. 인트라 테스트, 통합 테스트, UAT, 사용자 교육을 거치면서 사용자가 점점 시스템에 익숙해지고 신뢰할 수 있게 됩니다. 이는 단순한 검증이 아니라, 현업의 이해도를 높이고 변화 수용을 촉진하는 과정입니다.
Public Cloud는 Clean Core 원칙을 준수합니다. 즉, ERP의 핵심 코드를 수정할 수 없습니다. 대신 SAP은 다양한 확장성을 제공합니다.
Key User Extensibility
화면(UI) 조정, 커스텀 필드 추가, 간단한 비즈니스 로직 설정. 비IT부서 사용자가 로우코드 방식으로 활용 가능.
Developer Extensibility
ABAP RESTful Application Programming(RAP) 모델을 활용해 커스텀 앱이나 API를 개발. 예를 들어 특정 비즈니스 규칙에 따라 주문을 자동 분류하는 앱을 만들 수 있습니다.
Side-by-Side Extensibility
SAP BTP 위에 독립적인 앱이나 서비스를 구축. ERP와 표준 API로 연동되며, 대량 데이터 처리나 AI 기능을 외부에서 구현할 때 적합합니다.
예시: 한 유통 기업은 자사 특화 로열티 프로그램을 운영하기 위해 BTP에 별도 앱을 만들고, S/4HANA Public Cloud와 연동했습니다. 이렇게 하면 ERP 코어를 깨끗하게 유지하면서도 차별화된 기능을 제공할 수 있습니다.
SAP Business Technology Platform(BTP)은 Public Cloud와 외부 시스템을 연결하는 중앙 허브입니다.
커머스 연계: 외부 쇼핑몰 주문 → BTP Integration → S/4HANA Public Cloud (판매 오더 자동 등록)
DRC(Document & Reporting Compliance): 국세청 전자세금계산서 자동 연계
MBC(Multi-Bank Connectivity): 전 세계 은행과 ERP 연결, 송금·잔액 관리 자동화
Concur: 경비 처리 시스템과 Public Cloud 간 직접 연계
이러한 통합 패턴은 ERP를 단순한 회계 시스템에서 벗어나, 기업 디지털 운영의 중심 플랫폼으로 확장시킵니다.
Q. Public Cloud와 Private Cloud의 차이는?
Public Cloud: SaaS 형태, 표준 프로세스 기반, 코어 수정 불가
Private Cloud: 온프레미스와 동일한 기능, 코어 수정 가능, 맞춤형 유연성 제공
Q. Public Cloud에서 커스터마이징은 가능한가요?
코어 수정은 불가능합니다. 대신 확장성(Key User, Developer, Side-by-Side)을 활용해야 합니다.
Q. 온프레미스에서 Public Cloud로 전환은 업그레이드인가요?
아닙니다. 기존 시스템을 그대로 옮길 수 없으며, 신규 구축(그린필드) 방식으로 접근해야 합니다.
Q. Two-Tier 전략은 어떻게 활용하나요?
본사는 Private Cloud, 자회사는 Public Cloud로 운영하는 투티어 모델이 점점 확산되고 있습니다. 이는 비용 효율성과 표준화를 동시에 달성할 수 있는 방법입니다.
기획자: 박진석