SAP ECC에서 S/4HANA로의 마이그레이션: 중동 유통업체 사례 연구

제가 가장 아끼는 사례 연구입니다. 패션과 소비재를 다루는 중동의 이름난 유통업체가 SAP ECC 6.0에서 S/4HANA로 전환했습니다. 직원은 약 18,000명, 7개국에 걸쳐 1,200개 이상의 매장이 있었고, 이커머스 채널도 커지고 있었습니다. 수년간 ECC를 운영해 왔고 시스템 오브젝트의 44%가 커스터마이징되어 있었습니다. 우리는 선별적 재설계를 곁들인 브라운필드 컨버전을 택했습니다. 월 마감은 주말까지 이어지던 것에서 점심 전에 끝나는 것으로 바뀌었고, 커스텀 코드는 거의 절반으로 줄었습니다.

커스터마이징이 심한 ECC를 운영하면서 그중 얼마나 가져가야 할지 고민 중이라면, 한 프로그램이 그 질문에 어떻게 답했는지 보여 드리겠습니다.

커스터마이징은 급한 수정이 하나씩 쌓이며 서서히 불어났습니다. 우리가 시작했을 즈음에는 사소한 업데이트에도 위험이 따랐습니다. 통합은 취약했습니다. 재무의 작은 변경이 소매 운영의 무언가를 깨뜨릴 수 있었습니다. 비즈니스는 유연성과 속도를 원했습니다. IT는 불 끄기에 정신이 없었습니다. 양쪽 모두 서로 엇갈려 일하고 있었다고 인정했습니다.

공급망 팀이 “핵심” 보고서 수십 개를 이제는 거의 열어 보지 않는다고 인정하며 조금 웃던 세션이 기억납니다. 그것들을 걷어 내는 일은 실용적이면서도 묘하게 후련했습니다.

계기는 ECC 메인스트림 유지보수 종료였습니다. 인핸스먼트 패키지 6~8의 SAP ERP 6.0은 2027년 말에 메인스트림 유지보수가 끝납니다(SAP News). 진짜 동인은 더 깊은 곳에 있었습니다. 재무는 월 마감마다 수작업으로 데이터를 추출했습니다. 매장은 야간 배치 잡으로는 줄 수 없는 재고 가시성이 필요했습니다. IT의 노력 대부분이 커스텀 코드를 살려 두는 데 들어갔습니다.

SAP Readiness Check는 우리가 짐작한 바를 확인해 주었습니다. 커스터마이징이 심한 시스템이고, 앞으로 상당한 보정 작업이 필요하다는 것이었습니다. Simplification Item List는 표준 S/4HANA가 커스텀 ECC 코드가 하던 일을 이미 해 주는 부분을 보여 주었습니다. 재무 팀은 오랫동안 유지해 온 일부 커스텀 보고서가 이제는 중복이라는 것을 알게 되었습니다. 그 회의에서 안도하는 분위기가 역력했습니다.

단순한 기술적 컨버전은 문제를 앞으로 떠밀기만 했을 것입니다. 전면 그린필드 재구축은 10년치 잘 돌아가는 구성을 내다 버렸을 것입니다. 선별적 재설계를 곁들인 브라운필드가 그 균형점이었습니다. 탄탄한 것은 유지하고, 정리가 필요한 것은 정리하고, 깨진 것만 다시 만듭니다. 제 ECC에서 S/4HANA로의 마이그레이션 가이드가 그 경로들을 어떻게 저울질하는지 설명합니다.

단순 컨버전선별적 재설계를 곁들인 브라운필드전면 그린필드 재구축

유지되는 구성단순 컨버전전부, 문제까지 포함선별적 재설계를 곁들인 브라운필드탄탄했던 부분전면 그린필드 재구축없음, 10년의 작업이 폐기됨

커스텀 오브젝트 44%단순 컨버전그대로 가져감선별적 재설계를 곁들인 브라운필드각각 폐기, 교체, 재정비로 분류전면 그린필드 재구축가져가지 않음

의미하는 바단순 컨버전문제가 S/4HANA로 옮겨 감선별적 재설계를 곁들인 브라운필드정리할 것은 정리하고 깨진 것만 다시 만듦전면 그린필드 재구축작동하던 모든 프로세스를 처음부터 다시 구축

과제	우리가 한 일
커스터마이징된 오브젝트 44%	비즈니스와 IT가 함께 오브젝트마다 폐기, 교체, 재정비로 분류. 단계별 품질 게이트
취약한 통합	POS, WMS, 재무, HR, 벤더 포털을 아우르는 회귀 테스트 계획. 포인트 투 포인트 연결을 SAP Integration Suite 패턴으로 이전
데이터 품질	SLA를 가진 기능별 데이터 스튜어드. 일일 결함 추적. QA 전에 정제 완료
국가 간 정착	역할 기반 업무 가이드, Go-Live 임박 시점의 현장 순회 지원, 실제 업무에 맞춘 교육

대규모 커스텀 코드

Readiness 결과가 필터 역할을 했습니다. 비즈니스와 IT가 함께 앉아 모든 오브젝트에 태그를 달았습니다. 일부는 분명히 중복이었습니다. 실행한 기억조차 없는 보고서 같은 것들입니다. 나머지는 정말로 고유한 소매 프로세스를 뒷받침했기 때문에 신중한 재설계가 필요했습니다. 팀들은 미루지 않고 결정해야 했습니다. SAP Signavio는 모범 사례에 맞춰 새 프로세스를 정의하는 데 도움이 되었고, smartShift는 자동화된 코드 스캔과 가치가 낮은 수정을 맡아 시니어의 시간을 재설계에 쓸 수 있게 했습니다. 지금 제가 커스텀 코드를 어떻게 분류하는지는 Clean Core 가이드에서 다룹니다.

통합

ECC는 판매 시점 관리(POS) 시스템, 창고 관리 시스템(WMS), 재무, HR, 여러 벤더 포털과 연결되어 있었습니다. 우리는 그 모두를 아우르는 회귀 테스트 계획을 세우고, 마지막에만이 아니라 중요한 구성 변경이 있을 때마다 테스트했습니다. 야간 배치 잡은 S/4HANA에서 더 빨리 끝나야 했습니다. 그렇지 않으면 창고의 아침 보고서가 준비되지 않을 터였습니다.

데이터 품질

중복된 벤더 레코드와 오래된 마스터 데이터가 테스트를 질질 끌었습니다. 해법은 구조적이었습니다. 각 기능마다 데이터 스튜어드를 두고, 해결에 SLA를 적용했습니다. QA 시작 시점까지 데이터가 깨끗하지 않으면 스튜어드에게 되돌려 보냈습니다. 컷오버가 다가오자 적재를 처음부터 끝까지 리허설하고 결함을 매일 추적했습니다. 이 단순한 루틴이 어떤 화려한 대시보드보다 잘 통했고, 지금도 놀랍습니다. SAP 데이터 마이그레이션이 실패하는 이유에 관한 제 글이 이 패턴을 다룹니다.

정착

교육은 직원 26,000명에게 닿았습니다. 재무와 소매 운영은 우선순위가 달랐고, 이는 초기 워크숍에서 드러나 교육 설계를 바꿨습니다. Go-Live가 가까워 압박이 커지자 역할 기반 업무 가이드와 현장 순회 지원을 활용했습니다. 한 매장 리더는 나중에 두 쪽짜리 가이드가 어떤 타운홀보다 중요했다고 말했습니다. 저는 그 말을 믿었습니다.

SAP Activate 기반의 단계별 딜리버리. 핵심 재무와 공급망이 먼저 이전하고, HR과 벤더 포털은 나중에 이전해 지원 팀에 과부하가 걸리지 않게 했습니다. 환경마다 하나의 역할이 있었습니다. 샌드박스는 경로를 검증하고 범위를 확정했습니다. 개발은 트랜스포트를 안정화했습니다. QA는 실제 업무 물량으로 돌리며 잡을 튜닝했습니다. 사전 운영 환경은 진짜 드레스 리허설이었습니다. 배포 일자는 소매업의 성수기와 비수기에 맞춰 조정했습니다.

비즈니스와 함께하는 테스트. 재무와 공급망 리더들이 실제 기간 마감과 프로모션 주기를 기준으로 테스트했고, 스크립트는 시스템 로직이 아니라 비즈니스 현실에 맞춰 작성했습니다. 야간 실행에서 타이밍 문제가 드러났습니다. 몇 주 동안 답답했던 끝에 두 번째 실행이 매끄럽게 끝나자 웃음을 짓던 창고 리더가 기억납니다.

컷오버 리허설. 모든 태스크의 시간을 재고, 줄이거나 합쳤습니다. 드라이런만으로도 스프레드시트로는 드러나지 않던 몇 시간을 아꼈습니다. 복구 계획은 한 장짜리 유인물에 담았고, 사람들은 그 단순한 목록이 어떤 대시보드보다 스트레스를 줄여 줬다고 말했습니다. 매장 파일럿이 더 넓은 롤아웃 전에 POS와 WMS의 안정성을 입증했습니다.

하이퍼케어. IT와 비즈니스가 함께 쓰는 워룸, 명확한 SLA, 일일 조치 로그. 주말 근무는 돌아가며 맡았고, 지원 인수인계는 분 단위로 각본을 짰습니다. 사람들은 보통 숫자를 기억합니다. 저는 처음으로 조용했던 밤이 가장 기억에 남습니다.

재무 마감. 팀들은 월 마감이 이제 점심 전에 끝난다고 했습니다. 예전에는 주말까지 밀렸습니다. CFO는 보고서를 훨씬 빨리 받게 된 점을 가장 반겼습니다. 한 재무 리더는 시스템이 마침내 “커피 머신보다 빠르게” 돌아간다고 농담했습니다. 이런 순간이 어떤 발표 자료보다 더 큰 신뢰를 쌓습니다.

커스텀 코드. 거의 절반으로 줄었고, 이로써 장기적인 지원 부담과 이후 모든 업그레이드의 회귀 리스크가 낮아졌습니다.

리포팅과 사용자 경험. 매장 관리자들은 예전 트랜잭션 화면에서 SAP Fiori 앱으로 옮겨 갔습니다. 앱이 사람들이 기대하는 방식대로 동작했기 때문에 교육 시간이 줄었습니다. 한 관리자는 “신선하다”고 했습니다.

통합. POS, WMS, 재무 연결이 더 안정되었고 야간 잡이 더 일찍 끝났습니다.

모든 것이 고르게 안착한 것은 아닙니다. 일부 팀은 더 나은 보고서가 있는데도 예전 보고서를 붙들었습니다. 일부는 워크숍이 너무 길고 리허설이 반복적이라고 느꼈습니다. 돌이켜보면 그 단계들이 안전망이었습니다.

교훈	있었던 일	다음에는 이렇게 하겠습니다
일찍 조율하라	한 워크숍에서 매장 관리자들이 리포팅 요구가 재무와 매우 다르다고 말했습니다. 일찍 드러나서 조정했지만, 나중이었다면 컷오버에서 터졌을 것입니다	설계를 시작하기 전에 구조화된 조율 세션을 잡겠습니다
코드 리뷰는 첫날부터 시작하라	Go-Live 임박 시점에 압박 속에서 재작업된 오브젝트가 여럿 있었습니다	킥오프부터 폐기, 교체, 재정비를 결정하겠습니다
데이터를 비즈니스의 일로 만들라	중복된 벤더 레코드가 테스트를 지연시켰습니다	첫 주에 SLA를 가진 기능별 데이터 스튜어드를 지정하겠습니다
필요하다고 느끼는 것보다 더 많이 리허설하라	드라이런에서 아무도 예상하지 못한 POS와 WMS 간 순서 충돌이 드러났습니다	리허설을 추가로 계획하겠습니다. Go-Live 직전 마지막 리허설은 지루하게 느껴져야 합니다

같은 프로그램을 지금 시작한다면 세 가지가 달라질 것입니다. 이런 처지의 대부분의 기업은 이제 온프레미스에 머무르기보다 RISE with SAP 아래의 S/4HANA Cloud Private Edition을 살펴볼 것입니다. 폐기, 교체, 재정비 결정은 SAP의 Clean Core 레벨 A~D를 기준으로 구성할 것입니다. 변경과 배포 추적은 SAP Cloud ALM에서 진행할 것입니다. Solution Manager 7.2의 메인스트림 유지보수가 2027년 말에 끝나기 때문입니다. 데이터 스튜어드, 리허설, 공동 워룸, 두 쪽짜리 가이드는 모두 그대로 유지할 것입니다. 사람 쪽에 관해서는 SAP 교육 전략에 관한 제 가이드를 참고해 주십시오.

기업은 왜 SAP ECC에서 S/4HANA로 옮깁니까?

2027년 ECC 메인스트림 유지보수 종료가 계기입니다. 더 강력한 이유는 운영상의 것입니다. 실시간 리포팅, 더 빠른 마감, 커스텀 코드와 취약한 통합을 살려 두는 데 드는 노력의 감소입니다. 이 사례에서 비즈니스는 실시간 소매 분석과 더 짧은 월 마감을 원했습니다.

이 사례에서 SAP Readiness Check는 무엇을 보여 주었습니까?

오브젝트의 44%가 커스터마이징되어 있고 그중 다수가 수년간 쓰이지 않았다는 것을 확인해 주었습니다. 그 덕에 커스텀 코드 작업의 구조가 바뀌었습니다. 먼저 폐기하고, 가능하면 표준으로 교체하고, 실제 비즈니스 가치가 있는 것만 재정비했습니다. Simplification Item List는 표준 S/4HANA가 중복으로 만든 보고서도 보여 주었습니다.

왜 선별적 재설계를 곁들인 브라운필드를 택했습니까?

단순한 기술적 컨버전은 모든 문제를 그대로 가져갔을 것이고, 전면 그린필드 재구축은 10년치 잘 돌아가는 구성을 버렸을 것입니다. 선별적 재설계는 탄탄한 것을 유지하고, 표준이 커스텀 로직을 대체할 수 있는 곳에서는 SAP Signavio로 새 프로세스를 정의했으며, 깨진 것만 다시 만들었습니다.

데이터 정제를 너무 늦게 하면 어떻게 됩니까?

테스트가 늘어지고, 리허설이 실패하고, Go-Live가 밀립니다. 이 사례에서는 중복된 벤더 레코드와 오래된 마스터 데이터가 테스트에서 몇 주간의 마찰을 일으켰습니다. 해법은 SLA를 가진 기능별 데이터 스튜어드였고, 정제를 프로그램 건전성 지표로 추적했습니다.

마이그레이션 중 통합은 어떻게 다뤘습니까?

먼저 모든 연결을 맵핑했습니다. POS, WMS, 재무, HR, 벤더 포털입니다. 회귀 테스트 계획이 그 모두를 아울렀고, 중요한 구성 변경이 있을 때마다 테스트했으며, 매장 파일럿이 더 넓은 롤아웃 전에 POS와 WMS의 안정성을 입증했습니다. 그런데도 드라이런에서 아무도 예상하지 못한 POS와 WMS 간 순서 충돌이 발견되었습니다.

S/4HANA Go-Live 이후 좋은 하이퍼케어는 어떤 모습입니까?

IT와 비즈니스가 함께 쓰는 워룸, 명확한 SLA, 일일 조치 로그, 그리고 백로그에 쌓아 두지 않고 빠르게 닫는 이슈입니다. 역할 기반 가이드와 현장 순회 지원은 정식 교육보다 지원 문의를 더 빨리 줄입니다. 주말 근무는 돌아가며 맡고 인수인계는 각본을 짜 두어 팀이 소진되지 않게 하십시오.