Samsung SDS

Executive Summary

• 차세대 ERP 전환은 신규 구축만이 정답이 아닙니다. SAP는 System Conversion을 기준선으로 먼저 평가한 뒤 다른 경로를 비교하도록 안내합니다.
• Conversion은 기간·비용·업무 연속성 측면에서 효율적일 수 있지만, 시스템 규모와 데이터 품질, Custom Code, 전환 후 혁신 역량을 함께 따져야 합니다.
• doC 등 다운타임 최적화 기술은 데이터 변환 일부를 Uptime으로 옮겨 업무 중단을 줄입니다. 다만 사전 정비, 운영 제약, 반복 테스트가 필요합니다.
• 삼성전기 사례는 내부 기준선 142시간에서 최종 Business Downtime 34시간으로 줄였습니다. 공개 자료에는 기준 시간이 약 140시간으로 제시돼 있어 세부 내부 수치의 공개 승인을 확인해야 합니다.

차세대 ERP, 프로세스 재설계 기반의 신규 구축만이 정답은 아닙니다

최근 삼성SDS가 수행했던 차세대 ERP 전환 프로젝트의 성공적인 완료를 정리하는 자료에는 최종 Business Downtime이 34시간으로 적혀 있었습니다^[1]. 얼마 후 해당 고객사는 업무 비가동 최소화 기반 차세대 ERP Open이라는 보도 자료를 통해 성공적인 시스템 전환을 발표 했습니다. 대용량 DB의 System Conversion에 대한 Downtime 제약이 극복되고 차세대 ERP 전환의 새로운 성공 방식이 확인된 것입니다.

이 글은 아직 SAP ECC를 운영하면서 차세대 ERP 전환을 검토하는 기업을 위해, 삼성SDS의 사업 수행 경험을 바탕으로 작성했습니다. 많은 기업이 차세대 ERP 전환은 업무 프로세스를 새롭게 설계해 신규 구축하는 프로젝트로 바라보고, 그래야 전환 효과가 극대화되어 성공이 보장되는 것으로 이해합니다. 그러나 SAP가 공식 문헌에서 권고하는 출발점은 그 반대입니다. 이 글에서는 SAP의 공식 지침과 삼성SDS가 직접 수행한 프로젝트의 실측 데이터를 근거로, System Conversion이 왜 다수 기업에게 더 효율적인 선택이 될 수 있는지, 그럼에도 New Implementation으로 가야 하는 조건은 무엇인지, 그리고 Conversion의 오랜 약점이었던 Downtime과 기술 제약이 어떻게 해소되고 있는지를 차례로 살펴 보겠습니다.

한정된 시간이 선택지를 좁히고 있습니다

현재 시점 기준 차세대 ERP 전환 논의를 시작하는 회의에서 가장 먼저 등장하는 것은 신기술의 매력이 아니라 주어진 기간입니다. 최근 대부분의 차세대 ERP 프로젝트의 추진 배경 자료에는 EOS(End of Support, 지원 종료)가 현안으로 등장합니다. 기술 노후화나 경영정보의 적시 제공 같은 이슈는 미룰 수 있지만, ERP SW의 기술 지원 종료는 더 이상 미룰 수 없기 때문입니다.

SAP는 Business Suite 7 코어의 표준 유지보수를 2027년 12월 31일에 종료하고, 2030년 말까지는 유지보수 기준요율에 2%의 프리미엄을 붙인 선택적 연장을 제공*합니다. 덜 알려졌지만 실무적으로 더 시급한 이슈도 있습니다. 온프레미스 S/4HANA의 Compatibility Pack 사용권 대부분이 2026년 5월 31일에 이미 만료되었고, 일부 항목과 클라우드 구독 계약만 2030년 말까지 유효합니다**. 전환이 늦어질수록 기존 방식으로 쓰던 기능을 그대로 쓸 수 있는 여지가 함께 사라지는 구조입니다.
* SAP Note 1648480 : Maintenance Strategy for SAP S/4HANA and SAP Business Suite 7 ** SAP Note 2269324 : Compatibility Scope Matrix for SAP S/4HANA (on-premise)

시점과 내용 정보가 담겨있는 표

시점	내용
2026.05.31	온프레미스 S/4HANA의 Compatibility Pack 사용 기간 대부분 만료 (CS/LE-TRA/PP-PI 및 클라우드 구독 계약은 2030.12.31까지)
2027.12.31	SAP Business Suite 7 코어(SAP ERP 6.0 EHP 6~8 포함) 표준 유지보수 종료
2028.01 ~ 2030.12	선택적 연장 유지보수 (유지보수 기준요율 +2%p 프리미엄)
2031 이후	고객별 개별 유지보수만 제공. 신규 법규 대응 패치 기본 미제공

[표 1] SAP ERP Maintenance Stragegy (출처: SAP Note 1648480: Maintenance Strategy for SAP S/4HANA and SAP Business Suite 7)

시한만이 이유는 아닙니다. 최근 2년간 차세대 ERP 전환에 대한 논의의 중심은 신기능 구현에서 Clean Core(표준 코어는 수정하지 않고 확장 기능은 분리해 두는 원칙)로 옮겨갔고, 그 압력을 실질적인 것으로 만든 계기는 AI였습니다. AI가 업무 프로세스 안에서 작동하려면 데이터가 연결되고 맥락 화되어야 하는데, 수십 년간 쌓인 커스터마이징 위에서는 이것이 성립하지 않습니다. SAP가 ERP에 내장된 Business AI 활용 사례를 수백 개 규모로 빠르게 늘리고, 생성형 AI 코파일럿 Joule을 Cloud ERP Private의 새 사용자 인터페이스로 탑재하는 흐름^[2]도 같은 맥락에 있습니다. 2026년 9월 기준 표준 유지보수 종료까지는 약 15개월이 남았습니다. 질문은 이미 '갈 것인가'에서 '어떻게 갈 것인가'로 옮겨갔고, 남은 시간이 전환 방식의 선택지를 실질적으로 제약하기 시작했다는 점이 이 논의를 지금 해야 하는 이유입니다.

SAP가 제시하는 출발점은 신규 구축이 아닙니다

SAP社의 ERP 솔루션을 사용하는 기업에게 차세대 ERP 전환은 곧 S/4HANA로 전환을 의미합니다.

그리고 S/4HANA로 전환하는 방법은 크게 세 가지입니다. 기존 ECC(SAP ERP Central Component, 현행 SAP ERP) 시스템의 설정, 마스터, 거래 이력 데이터와 Custom 개발 Object를 그대로 S/4HANA로 변환하는 System Conversion(Brownfield), 신규 시스템에서 프로세스를 새로 설계·개발하고 미결(Open) 데이터 등 일부만 이관하는 New Implementation(Greenfield), 그리고 두 방식을 조합해 과거 이력은 유지하되 데이터를 선택적으로 이관하는 Selective Data Transition(SDT, Bluefield)입니다.

이 가운데 SAP의 권고는 명확합니다. 우선 System Conversion이 적합하다고 가정하고 시작하되, 이 옵션을 기준선(baseline)으로 먼저 평가함으로써 어떤 경로가 최선인지 판단하라는 것입니다^[3]. Conversion이 기본값이고, 다른 경로는 특정 조건이 성립할 때 선택하는 예외라는 뜻입니다.

여기서 중요한 것은 판단의 근거가 선입견이 아니라 실측이어야 한다는 점입니다. SAP Readiness Check는 가상의 설계안이 아니라 실제 운영 중인 시스템을 분석해 Simplification Item(S/4HANA에서 변경·폐지된 기능 목록), Custom Code 분석, Add-on Component 호환성, 재무 데이터 품질, CVI(Customer Vendor Integration, 고객·공급업체 마스터를 Business Partner로 통합하는 필수 사전 작업) 준비도, Downtime 예측을 산출합니다^[4]. 추정이나 선입견이 아니라 확인된 사실을 근거로 Conversion 적합 여부를 판단할 수 있게 해 주는 도구입니다. 반면 신규 구축에는 이에 상응하는 증거 기반 사전 진단 수단이 없고, 구축 범위는 별도의 PI(Process Innovation, 프로세스 혁신) 프로젝트를 통해 정의됩니다.

시장이 실제로 어느 쪽을 택했는지도 일반적인 예상과는 다릅니다. SAP가 약 3년간 1만 건에 가까운 S/4HANA 프로젝트를 집계한 결과는 System Conversion 48%, New Implementation 50%, SDT 2%였습니다^[5]. 미주 SAP 사용자 그룹인 ASUG(Americas' SAP Users' Group)의 2024년 회원 설문에서도 Brownfield 34%, Greenfield 33%, 하이브리드 20%로 어느 한 방식이 다수를 차지하지 않았습니다^[6]. 이처럼 국내외 시장에서 Conversion과 신규 구축은 어느 한쪽으로 수렴하기보다, 각 기업의 시스템 현황과 전환 목표에 따라 함께 검토되는 선택지로 자리 잡고 있습니다.

차세대 ERP 전환은 곧 신규 구축으로 일반화하는 통념은 실제 데이터로 뒷받침되지 않습니다. 즉 신규 구축이 '정석'이고 Conversion이 '차선'이라는 인식은 시장 실태와 거리가 있습니다.

전환기간·비용·Risk 측면에서 Conversion이 효율적인 이유

전환기간: 삼성SDS의 사업실행 경험으로 보면 Conversion은 6~10개월, 신규 구축은 12~15개월입니다. 다만 SAP의 Pocket Guide에 따르면 Conversion은 8~9개월, 신규 구축은 9~15개월로 제시합니다^[3]. 이는 사업규모 및 사전프로젝트 기간에 합산 여부로 일부 차이가 있을 수 있지만, 일반적으로 System Conversion이 신규 구축 대비 짧은 기간으로 수행됩니다.

다만 이 수치는 단순한 단일 시스템을 전제한 밴드입니다. SAP의 PCE(Private Cloud Edition) 실무 가이드는 DB 5TB 초과, 모듈 8개 초과, Custom Code 조정 3,000건 초과 같은 조건마다 기간을 가산하는 영향계수를 제시하는데^[7], 이를 실제 대기업 조건에 대입하면 Conversion도 12개월을 넘길 수 있습니다. 기간은 밴드가 아니라 자사 조건을 대입한 산정으로 접근할 필요가 있습니다.

비용: 신규 구축 사업 케이스에서 가장 흔한 오류는 기존에 사용하던 CBO(Customer Bolt-On, 고객 자체 개발 프로그램) Object를 버리므로 CBO 정비 비용이 절감된다는 가정입니다. 하지만 SAP는 Custom Code를 신규 구축 시스템으로 그대로 옮기지 말 것을 권고하면서, 어느 경로를 택하든 정리(Cleansing)와 조정(Adjustment) 같은 S/4HANA 최적화 과정은 동일하게 필요하다고 설명합니다^[8].

구조적 비대칭은 여기서 생깁니다. Conversion에서 Custom Code는 '기본 승계, 예외적 제거'입니다. 실제 사용 통계로 미사용 코드를 식별하고 전환 과정에서 자동으로 제거할 수 있습니다. 반대로 신규 구축은 '기본 소멸, 예외적 재구축'이므로 업무상 필수인 확장 기능을 하나하나 다시 요건 정의하고 개발하고 테스트해야 합니다. 규모를 체감하실 수 있도록 실제 수치를 덧붙이면, 뒤에서 살펴볼 사례에서 전환 대상이 된 CBO 조정 개발은 수천본, STD Modification(표준 프로그램 수정) 조정은 수백 건이었습니다. 이 자산을 신규 구축에서 재구축한다면 무엇을 남기고 무엇을 버릴지 판단하는 일부터 다시 시작해야 합니다. 인터페이스 재개발과 별도의 데이터 Migration Task 역시 SAP가 신규 구축의 추가 부담으로 지목하는 항목입니다^[8]. 결국 신규 구축은 재개발로 기간이 길어지고 투입 공수가 늘어나며, 그만큼 구축 비용이 상승하게 됩니다.

Risk: Conversion의 업무 중단 Risk는 'Cut-Over Downtime Window'라는 유한한 값으로 정의되고, 운영 복제본의 테스트 시스템으로 반복 측정되며, 기술적 롤백이 존재합니다. 반면 신규 구축의 System Open Risk는 데이터 이관 완전성, 기초 잔액 정합, 인터페이스 재구성, Open 첫날의 사용자 숙련도에 종속되며 이 중 어느 것도 기술적 롤백의 대상이 아닙니다. Transaction History와 Audit의 연속성도 다릅니다. SAP 역시 신규 구축에서는 History 데이터가 이관되지 않으므로, Open 이전의 데이터가 반드시 필요하다면 Conversion이나 SDT를 고려하는 편이 낫다고 안내합니다^[8]. 법정 보존기간 동안의 레거시 병행 운영 비용은 승인 시점의 사업 케이스에 반영되지 않는 경우가 대부분입니다. 변화관리 부담 또한 비대칭입니다. Conversion에서는 사용자의 조작 숙련도가 유지되고 Fiori(SAP의 신규 사용자 인터페이스) 도입을 단계적으로 진행할 수 있지만, 프로세스 재설계를 동반한 신규 구축은 새로운 프로세스와 새로운 UI를 전 사용자에게 동시에 재교육해야 합니다. 변화관리에서 가장 통제하기 어려운 두 변수를 한꺼번에 바꾸는 셈입니다.

그럼에도, 신규 구축이 선택이 아닌 필수가 되는 조건은 무엇일까요?

Conversion이 항상 효율적이라고 주장할 수는 없습니다. 신규 구축이 훨씬 유리한 조건이 될 수 있는 경우는 분명히 존재합니다. 전략적 성장 영역에서 프로세스 재설계 자체가 프로젝트의 목표인 경우, 현재 시스템이 Best Practice 를 활용하지 못하거나 오래된 낡은 기능에 의존하여 신기술 기반으로 조정이 어려운 경우, 오랜 기간동안 복잡하게 생성한 다수의 시스템들이 M&A 등을 통해 시스템 통합/분리가 필요한 경우, 그리고 회사코드 단위의 단계적 롤아웃이 확고한 제약인 경우입니다^[3]. 복수의 ECC 시스템 통합이나 분할, 조직구조/통화/회계연도 변경이 동시에 필요하다면 SDT가 현실적인 대안이 됩니다.

국내 시장도 이 기준을 따라 이분화되어 있습니다. 최상위 대기업은 프로세스 혁신을 선행한 뒤 PCE 기반 재구축을 택하는 경향이 뚜렷합니다. SPC그룹은 13개 계열사 전환에 Greenfield 방식을 명시적으로 채택했고, S-OIL도 Greenfield로 프로세스를 재설계했습니다^[9]. 반면 삼성SDS가 수행한 사업 기준으로 중견기업군은 비용과 기간을 이유로 Conversion을 택했습니다. 어느 쪽이 옳으냐가 아니라 자사의 조건이 어느 쪽에 해당 하느냐를 먼저 확인하는 일이 중요합니다.

SAP가 남긴 두 가지 단서는 특히 새겨둘 만합니다. 첫째, IT 프로젝트에서 비즈니스 전환을 시작하기는 매우 어렵다는 것입니다^[3]. 프로세스 혁신을 ERP 프로젝트의 부산물로 기대하기는 어렵다는 뜻입니다. 둘째, 다년 계획을 지속적으로 실행할 역량이 부족하다고 판단하는 기업에게는 신규 구축이 S/4HANA의 가치를 온전히 거둘 수 있는 유일한 기회라는 것입니다^[7]. 결국 판단의 핵심은 기술이 아니라, 전환 이후의 혁신을 실제로 이어갈 조직의 지속성에 있습니다.

Conversion의 오랜 약점, Downtime은 어떻게 해소되고 있을까요?

Conversion의 가장 큰 약점은 오랫동안 Downtime이었습니다. SAP도 Conversion이 Downtime 부담이 가장 큰 전환 시나리오로 설명하면서, 바로 그 때문에 이 시나리오에 가장 진보된 Downtime 최적화 접근과 Tool을 활용할 수 있도록 발전되고 있다고 설명합니다^[13]. 일반적으로 협상 가능한 Cut-Over Downtime Window는 8시간(1개 공장 교대)에서 60시간(금요일 저녁부터 월요일 새벽)까지이며, 여기에는 실제 Technical Downtime뿐 아니라 비상 상황의 롤백 버퍼, 업무 검증, 램프업까지 Cut-Over 절차 전체가 포함됩니다^[7]. 현장에서 업무 부서와 협상할 때 이 범위를 먼저 공유하면 논의가 훨씬 빨라집니다.

기술이 발전해 온 방향은 한 가지입니다. Downtime에 수행하던 작업을 Uptime(사용자가 시스템을 쓰고 있는 시간)으로 옮기는 범위를 넓히는 것입니다. Conversion은 SAP의 표준 전환 도구인 SUM(Software Update Manager, 업그레이드와 데이터 변환을 실행하는 도구)으로 수행하며, DB까지 함께 옮길 때는 SUM에 포함된 DMO(Database Migration Option, DB 이관 옵션)를 사용합니다. 표준 Conversion은 DB Migration → Software Upgrade → Data Conversion을 모두 Downtime에 수행합니다. do-DMO(downtime-optimized DMO)는 대형 테이블의 Migration을 Uptime으로 옮기고, doC(downtime-optimized Conversion)는 한 걸음 더 나아가 애플리케이션 Data Conversion까지 Uptime에 미리 수행합니다. 그사이 발생한 변경분을 CRR(Change Record and Replay, 변경분을 기록해 두었다가 재적용하는 기술) 기반의 DB 트리거로 기록해 마지막 단계에 반영합니다^[10]. doC는 SUM 2.0 SP17(2023년 5월) 이후 일반 제공되고 있으며, 삼성SDS는 뒤에 소개할 삼성전기 프로젝트에서 doC (국내에서 처음으로 확인된 적용 사례^[11])를 적용하여 Downtime 한계를 극복했습니다.

기술, 핵심 원리, 적용 판단 정보가 제공되는 표

기술	핵심 원리	적용 판단
표준 Conversion (SUM + DMO)	DB Migration → Software Upgrade → Data Conversion을 단일 절차로 결합하되 모두 Downtime에 수행	5TB 미만 소형 시스템. 아카이빙 선행 시 표준만으로도 목표 Downtime 달성 가능
do-DMO	대형 애플리케이션 테이블의 Migration을 Uptime에 수행. Data Conversion은 Downtime에 수행	DB 규모는 크지만 STD 재무전표 등 Conversion 대상은 상대적으로 적은 경우
doC Data C	onversion까지 Uptime에 수행하고 변경분은 CRR 기술로 로깅후 적용. SUM 2.0 SP17 부터 정식 출시	대용량 DB 및 Downtime 요구가 엄격한 경우. 재무 전표 항목 10억 건 초과 시 사실상 필수
NZDT (Near Zero Downtime)	SAP 엔지니어링 컨설팅 서비스. 통상 24시간 Cut-Over 윈도우 달성	40TB 초과 초대형 시스템이면서고비용 SAP 컨설팅 서비스 투자가 가능한 경우

[표 2] Conversion 방식별 Downtime 최적화 기술과 적용 기준 (출처: 삼성SDS)

다만 doC 적용에는 일부 업무 제약과 조건이 따릅니다. SAP는 인증 교육을 받은 전문가, 소스 시스템의 사전 정비, 표준 방식보다 복잡한 기술 절차, 일부 테이블 Freezing과 Asset 등 일부 업무 수행 제약, SUM Uptime 실행 중 대량 변경 작업 금지, 그리고 운영시스템 복제본을 사용한 수차례의 반복 테스트를 조건으로 명시*합니다^[10]. Downtime 단축은 사전 제약과의 교환이며, 이 제약 자체가 전환 테스트를 통해 Risk를 사전에 제거하는 장치이기도 합니다.
* SAP Note 3669180 : Executing and Monitoring Downtime-optimized Conversion to SAP S/4HANA with SUM 2.0 SP 25 (2026.04.01)

활용하는 단축 기술보다 준비가 먼저라는 원칙은 다른 기술 활용에도 그대로 적용됩니다. Custom Code 조정은 ATC(ABAP Test Cockpit, SAP ABAP 코드 점검 도구)의 Quick fix 기능으로 전형적 사용 사례의 상당 부분이 자동화되고, 고객·공급업체 및 재무 데이터의 품질은 CVI Cockpit과 Readiness Check로 프로젝트 이전에 정비할 수 있으며, 전환 이후의 값 검증은 DTV(Data Transition Validation, 전환 전후 데이터를 자동 비교하는 검증 도구)가 담당합니다^[4][10].

결국 doC를 비롯한 Downtime 최적화 기술의 관건은 이제 ‘적용할 수 있는가?’가 아니라, 사전정비와 업무 조율을 ‘얼마나 준비했는가?’ 입니다.

Conversion 활용 Downtime 최적화 사례 — 142시간에서 34시간까지

국내 공개 사례는 대부분 수주나 착수 시점의 보도이고, 전환 방식이나 Downtime, DB 볼륨 같은 정량 정보는 거의 공개되지 않습니다. 그래서 여러 사례를 나열하는 대신, 삼성SDS가 수행하고 필자가 직접 리딩하여 프로젝트 이슈 및 주요 성공 요인에 대한 검증이 가능하고, 최신 기법인 doC를 활용하여 Conversion의 Downtime 제약 한계를 극복한 사례 하나를 상세하게 살펴보고자 합니다.

삼성전기는 SAP ECC 6.0 EHP 8과 BW/4HANA 2.0 온프레미스 환경을 삼성 클라우드 플랫폼 위의 SAP S/4HANA 2023 PCE로 전환했습니다^[11]. 2025년 7월 착수, 2026년 2월 Open까지 34주가 소요되었고, 방식은 Technical Conversion(Brownfield)으로 Cloud 인프라 변경, DB Migration, ERP Solution Upgrade를 하나의 차세대 ERP 전환으로 수행했습니다.

이 프로젝트에서 가장 먼저 결정해야 했던 것은 전환 방식이 아니라 허용 가능한 Downtime이었습니다. 고객사 내부 목표는 Business Downtime 48시간이었지만, 표준 Conversion으로 수행한 Pilot 전환의 실측 Baseline은 142시간이었고, 고비용 서비스인 NZDT(Near Zero Downtime)는 초기 검토에서 이미 제외된 상태였습니다. 즉 앞에서 언급한 Conversion의 가장 큰 약점 Downtime 이 프로젝트의 가장 큰 이슈로 부각된 것입니다. 특히 생산 라인을 멈출 수 없는 제조기업에게 Downtime은 곧 생산과 출하의 차질로 이어지기 때문에, SDS의 사업 수행 경험으로도 제조 현장을 가진 고객이 Conversion을 검토할 때 가장 크게 고려하는 부담입니다.

그러나 이 프로젝트는 Conversion 방식 선택을 주저하게 했던 Downtime이 관리 가능한 범위 안으로 들어올 수 있음을 확인한 계기가 되었습니다. SAP코리아도 보도자료에서 이 프로젝트를, DoC 방식으로 시스템 비가동 시간을 최초 예상 대비 75% 이상 줄이고 제조 라인 운영을 이어가며 전환한 사례로 소개했습니다^[12]. Conversion으로도 차세대 ERP 전환을 성공적으로 수행할 수 있음을 보여 준 것입니다.

전환 검증 단계에서만 8회의 인프라 전환 테스트가 수행되었습니다. 표준 Conversion에서 DVM + do-DMO로 넘어가며 78시간이 줄었고, doC 적용으로 다시 19.5시간, 세부 튜닝으로 10.5시간이 추가로 줄었습니다. 단축이 한 번의 기술 도입으로 이뤄지지 않았다는 점이 중요합니다. 앞서 정리한 기술 계층을 한 단계씩 올라가며 실측하고 튜닝하는 과정이었고, 최신 기법으로 한 번에 건너뛰지 않았다는 점이 오히려 안정성의 근거가 되었습니다.

업무 제약과 복잡한 절차에 대한 SAP의 실행 제어 등 doC 활용에 대한 대가도 실재했습니다. 약 95시간의 SUM Uptime 구간에서 자산 관련 트랜잭션은 Lock 되고, Customizing 테이블 변경은 통제되었으며, 대량 데이터 변경 작업은 최대 2배, 조회는 최대 1.3배까지 느려졌습니다. R3load(SUM에서 데이터 이관 시 사용하는 SAP 프로세스) 개수를 50 이하로 유지해 성능 저하를 1.5배 수준으로 완화하는 등의 튜닝이 뒤따랐습니다. 업무 중단이 불가능한 제조 현장에는 별도의 대응이 필요했습니다. ERP가 멈춘 34시간 동안에도 생산 라인은 가동되어야 했기 때문에, HSR(HANA System Replication, HANA DB 실시간 복제 기능)로 복제한 임시 서버로 MES(Manufacturing Execution System, 제조실행시스템)의 연계 경로를 전환하고, 그 기간에 변경된 데이터는 점검 시간에 신규 시스템으로 이관했습니다. 프로젝트 과정에서 고객사와의 의사결정을 통해 기술적으로 가능한 것과 현장이 받아들일 수 있는 것 사이에서 조정이 이루어졌으며, 이런 제약을 기술팀만의 결정으로 진행하면 Uptime 구간에서 반드시 충돌하기 때문에 업무 부서와 사전에 합의해야 하는 사항입니다.

2026년 2월 Cut-Over 실적은 Business Downtime(업무 중단 시간) 34시간, Technical Downtime(시스템 중단 시간) 25.5시간, SUM Downtime(SUM 도구 실행 구간) 6.5시간이었습니다. 당초 목표 48시간보다 14시간, Baseline 142시간보다 108시간을 줄인 결과입니다. 전환 후 ERP 전체 평균 응답속도는 20% 이상 개선되었고, 안정화 기간을 통해 발생한 결함은 전체 조치 완료되어 응답속도 저하 없이 안정적인 운영에 들어갔습니다^[11].

삼성전기 사례는 Downtime 부담 때문에 Conversion을 주저해 온 대기업도 Conversion으로 성공할 수 있음을 보여줍니다. 다만 기존 그대로 전환한 것은 아닙니다. 재무, 구매, 생산, 물류 핵심 프로세스를 사전에 정비 및 표준화해 전환 개발 규모를 줄였고, 손익체계 개선과 BI 환경 개선 등 5개 개선과제를 전환과 함께 수행했습니다. 'Conversion 후 혁신'과 '프로세스 재설계' 사이에서 실무적 절충을 찾은 접근으로 볼 수 있습니다.

맺음말 - Conversion은 프로세스 혁신의 포기가 아니라 순서의 변경입니다

차세대 ERP 전환은 프로세스를 재설계하고 시스템을 새롭게 구축하여 업무 혁신을 달성해야 하는 것으로 바라보는 시각은 여전히 강합니다. 그러나 SAP 자신의 공식 지침과 삼성SDS의 사업 수행경험을 기반으로 반대에서 출발하는 것을 검토해 볼 필요가 있습니다.

우선 Conversion이 적합하다고 가정하고, Readiness Check로 실제 시스템을 진단한 뒤, 프로세스 전면 재설계, 시스템 통합, 조직구조 변경 같은 조건이 확인될 때 다른 방식을 검토하는 것이 효과적일 수 있습니다. 전환 기간, 비용 및 Risk에서 Conversion이 갖는 구조적 강점과, 최대 약점이던 Downtime은 doC를 비롯한 최적화 기술을 통해, 대부분의 대용량 환경에서 주말 단위 Cut-Over Window 안으로 들어올 수 있게 되었습니다. 40TB 를 넘어서는 초대형 시스템은 여전히 SAP 의 Minimized Downtime Service 검토가 필요하지만, 적어도 「볼륨이 커서 Conversion 은 불가능하다」는 명제는 더 이상 성립하지 않습니다.

차세대 ERP 전환을 검토하시는 기업이라면 전환 경로를 결정하기 전에 다음 다섯 가지를 순서대로 점검할 수 있습니다.

단계, 고려 사항, 시점 정보가 제공되는 표

단계	고려 사항	시점
Readiness Check 선행	운영시스템 데이터 기준으로 S/4HANA Simplification Item 점검, Custom Code 분석, Add-on 호환성, 재무 데이터 품질, Downtime 소요시간 예측을 확보. 전환 경로 결정은 이 결과 이후로 미루는 편이 안전	프로젝트 시작 최소 6개월 전
사전 정비 규모 산정	CVI, New G/L, New Asset, 재무 데이터 품질 정비 공수를 산정해 Conversion 총원가를 확정하고 신규 설계 비용과 비교.	경로 결정 직전
데이터 볼륨 정비	DVM, 미사용 Custom Code 정리, HANA NSE(Native Storage Extension, 저빈도 데이터를 메모리 밖에 두는 기능) 검토. 이 단계가 Downtime과 클라우드 비용을 동시에 좌우	설계와 병행
Conversion 실행 Scenario 선택	표준 DMO, do-DMO, doC 중 시스템 규모와 Downtime요구에 맞는 기법을 선택하고, 시스템 전환 테스트를 반복하며 회차마다 실측 및 튜닝 진행	구현 단계 내
전환 후 최적화 로드맵 수립	Clean Core, Fiori 확산, Embedded Analytics, Business AI 적용을 전환 후 별도 과제로 정의. Conversion이 혁신의 포기가 아니라 순서의 변경임을 로드맵으로 제시	가동 후 12~24개월

[표 3] Conversion 추진 단계와 핵심 고려사항 (출처: 삼성 SDS)

Conversion을 선택한다는 것은 프로세스 혁신을 포기하는 것이 아니라 잠시 뒤로 미루는 것입니다. 따라서 Conversion 이후의 최적화 과제와 실행 계획도 함께 마련해야 합니다. 전환 후 최적화를 실제로 실행할 조직역량과 의지가 있는지는 차세대 ERP 전환을 고려하는 기업 스스로에게 물어봐야 합니다. 이 질문에 자신 있게 답할 수 있다면 Conversion은 가장 효율적인 경로가 되고, 그렇지 않다면 신규 구축의 비용은 정당한 대가일 수 있습니다.

한 가지는 분명합니다. 남은 15개월은 이 질문을 충분히 숙고할 만큼 길지 않습니다. Readiness Check는 지금 실행할 수 있고, 그 결과는 어떤 벤치마크보다 설득력 있는 의사결정 근거가 될 수 있습니다.

References

• 삼성SDS 보도자료, 삼성전기 차세대 ERP 구축 완료 (2026.04.20) https://www.samsungsds.com/kr/news/se-260420.html
• SAP, SAP Business AI / Joule for SAP Cloud ERP Private 공식 자료 https://www.sap.com/korea/products/financial-management/s4hana-cloud-private-edition-joule.html
• SAP Community, SAP S/4HANA Transformation Pocket Guide https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/sap-s-4hana-transformation-pocket-guide/ba-p/13791072
• SAP Help Portal, SAP Readiness Check for SAP S/4HANA https://help.sap.com/docs/SAP%20Fiori%20Apps%20Reference%20Library/187a50cf8191418ab7b52505fcef1789/fcdc52a8e5f04742be05f0faa222530b.html?locale=en-US&q=SAP+Readiness+Check+for+SAP+S/4HANA#loiofff68dc235424e52bbbcd071d681718f
• SAP Learning, Implementing SAP S/4HANA Cloud Private Edition – Analysis of Customer Transition https://learning.sap.com/courses/implementing-sap-s-4hana-cloud-private-edition-ko/sap-s-4hana-cloud-private-edition%EC%9C%BC%EB%A1%9C%EC%9D%98-%EA%B3%A0%EA%B0%9D-%EC%A0%84%ED%99%98-%EA%B2%BD%EB%A1%9C-%EC%9D%B4%ED%95%B4_b8aa0951-21d6-44d0-b9f5-81cd24b2b8bb_ko-KO
• ASUG, SAP S/4HANA Journeys (2024, n=208) 및 Evolving SAP S/4HANA Journeys (2025) https://info.asug.com/s4hana-research-2024, https://www.asug.com/insights/2025-research-report-evolving-sap-s-4hana-journeys-beyond-deadlines-to-measurable-value
• SAP SE, Mapping your journey to SAP S/4HANA Cloud Private Edition – A practical guide for senior IT leadership https://www.sap.com/korea/documents/2019/05/44b3ebd5-4b7d-0010-87a3-c30de2ffd8ff.html
• SAP Learning, Evaluating Between a System Conversion or a New Implementation https://learning.sap.com/learning-journeys/practicing-clean-core-extensibility-for-sap-s-4hana-cloud/
• SAP, “S-OIL: Embracing cloud ERP to position the business for future growth and innovation,” https://www.sap.com/korea/asset/dynamic/2025/09/82a9ea05-1e7f-0010-bca6-c68f7e60039b.html
• SAP Support Portal, Downtime-optimized Conversion Approach of SUM, SAP Help Portal, Software Update Manager 2.0 – Downtime-Optimized Conversion https://support.sap.com/en/tools/software-logistics-tools/software-update-manager/downtime-optimized-conversion-approach.html
• 삼성SDS 보도자료, 삼성전기 차세대 ERP 구축 완료 (2026.04.20) https://www.samsungsds.com/kr/news/se-260420.html
• SAP 코리아: 삼성전기, ‘SAP 프리미엄 서플라이어’ 기반 S/4HANA 전환 구축 완료 https://news.sap.com/korea/2026/04/%EC%82%BC%EC%84%B1%EC%A0%84%EA%B8%B0-sap-%ED%94%84%EB%A6%AC%EB%AF%B8%EC%97%84-%EC%84%9C%ED%94%8C%EB%9D%BC%EC%9D%B4%EC%96%B4-%EA%B8%B0%EB%B0%98-s4hana-%EC%A0%84%ED%99%98-%EA%B5%AC%EC%B6%95/

FAQ

※ 이 아티클은 AI를 활용하여 기획, 제작되었습니다.
    - 리서치 자료 정리 및 원고 톤앤매너 보정 : Claude
    - 데이터 시각화(그림 1, 그림 2) 제작 : Claude