비용이 큰 실수를 피하는 최선의 SAP 구축 전략

최선의 SAP 구축 전략은 비즈니스에 맞고 팀이 지속할 수 있는 전략입니다. 세 가지 결정으로 귀결됩니다. 어떤 배포 모델인가: S/4HANA Cloud Public Edition(대개 GROW with SAP를 통해), Private Edition(대개 RISE with SAP를 통해), 또는 온프레미스. 어떤 마이그레이션 경로인가: 그린필드, 브라운필드, 블루필드. 그리고 어떤 롤아웃 방식인가: 빅뱅, 단계적, 하이브리드. 이 가이드는 S/4HANA 접근 방식을 고르는 CIO, 프로그램 디렉터, 스폰서를 위한 것입니다. 아래 다섯 가지 질문에 답하고, 배포 모델을 먼저 결정한 다음, 비교표와 의사결정 트리로 나머지 두 가지를 정하십시오.

제가 참여한 21개 프로그램에서 패턴은 일관됩니다. 전략 선택은 실제로 중요하지만, 결정의 작은 절반일 뿐입니다. 더 큰 절반은 옵션 비교 스프레드시트를 치워 놓은 뒤 14개월의 실행 기간 동안 팀이 규율을 지킬 수 있느냐입니다.

목표는 가장 빠르거나 가장 저렴한 옵션이 아닙니다. 구조, 문화, 속도, 규제 프로파일, 장기 목표 등 비즈니스에 맞는 접근 방식입니다.

먼저 답해야 할 다섯 가지 질문

1. 구조가 얼마나 복잡합니까? 단일 법인, 다중 법인, 다국가?
2. 팀에게 적응할 시간이 필요합니까, 아니면 지금 변화할 준비가 되어 있습니까?
3. 여러 레거시 시스템에서 옮겨 갑니까, 하나의 ERP에서 옮겨 갑니까, 아니면 백지에서 시작합니까?
4. 사내에 SAP 전문 역량이 있습니까, 아니면 파트너에 의존하게 됩니까?
5. Go-Live 때 어느 정도의 업무 중단을 감수할 수 있습니까?

보편적인 정답은 없습니다. 전략은 다른 곳의 성공 사례가 아니라 여러분의 현실을 반영해야 합니다.

2023년에서 2026년 사이에 달라진 것

RISE와 GROW가 클라우드 S/4HANA를 구매하는 표준 방식이 되었습니다. RISE with SAP는 소프트웨어(대개 Private Edition), SAP가 운영하는 인프라와 기술 운영, BTP 크레딧을 하나의 구독으로 묶습니다. GROW with SAP는 표준 프로세스를 쓰는 중견기업을 위해 Public Edition을 패키지로 제공합니다. 라이선스를 구매한 뒤 구축하는 전통적인 방식은 온프레미스용으로 여전히 존재하지만, 새 논의는 대부분 RISE나 GROW에서 시작합니다.

Clean Core가 조언에서 아키텍처가 되었습니다. Public Edition에서는 코어를 수정할 수 없습니다. 확장은 ABAP Cloud를 쓰는 온스택 방식이나 SAP BTP를 쓰는 사이드바이사이드 방식으로 릴리스된 API를 사용합니다. Private Edition과 온프레미스에서는 여전히 수정할 수 있지만, 수정은 건건이 업그레이드 작업을 늘리기 때문에 SAP의 가이드는 수정을 최후의 수단으로 봅니다. Clean Core 경험이 없는 파트너는 첫 주부터 기술 부채를 만듭니다.

AI가 구축 도구에 들어왔습니다. SAP Joule for Consultants(2025년 5월부터 정식 제공)는 SAP 자체 콘텐츠로 구성 관련 질문에 답합니다. SAP Cloud ALM은 Fit-to-Standard 워크숍 녹취록에서 요구사항 초안을 작성할 수 있습니다. SAP Build Code(2024년 3월부터 정식 제공)는 Joule을 사용해 Java와 JavaScript 확장을 생성하고, Joule for developers는 2024년 말부터 ABAP 코드 생성과 설명 기능을 추가했습니다. 어느 것도 전략적 선택을 바꾸지는 않습니다. 어떤 선택을 하든 그 안의 비용과 시간을 바꿀 뿐입니다.

전략이 성공하거나 실패하는 곳

선택보다 실행이 더 중요합니다. 어떤 접근 방식을 골랐든 네 가지 실패 패턴이 나타납니다.

1. 사라지는 경영진의 참여. 한 은행의 S/4HANA 구축에서 CEO는 모든 주요 회의에 참석해 좋은 질문을 던지고 팀을 지지했습니다. 프로젝트는 일정대로 끝났고 계획보다 적게 썼습니다. 한 유통 체인의 경영진은 킥오프 후 모든 것을 넘겨 버렸습니다. 아무도 의사결정을 하지 못해 프로젝트는 몇 달 동안 멈췄습니다.
2. IT 업무로 취급된 데이터 마이그레이션. 한 고객은 제품 마스터 데이터가 “충분히 깨끗하다”고 우겼습니다. 첫날 이 회사 창고에는 3년 전에 단종된 제품의 주문이 들어왔습니다. 정리에는 몇 주가 걸렸고 주요 고객 한 곳을 잃었습니다. 데이터 마이그레이션에는 현업의 책임 있는 소유가 필요합니다.
3. 생략되거나 서둘러 끝낸 교육. SAP 가동 2주 뒤에 한 사무실을 방문했습니다. 회계팀 모니터마다 기본 업무를 상기시키는 포스트잇이 붙어 있었고, 교육은 하루뿐이었습니다. 팀장이 말했습니다. “그냥 버티고 있는 겁니다.” 그 회사는 첫해에 지원 비용으로 20만 달러를 더 썼습니다.
4. 시스템을 우회하는 사람들. 교육이면 충분하다고 생각한 공장과 일한 적이 있습니다. 작업자들은 새 시스템을 신뢰하지 않고 스프레드시트로 돌아갔습니다. Go-Live 후에 이를 바로잡는 데는 큰 비용이 들었습니다. 변화 관리는 커뮤니케이션, 참여, 현업 안의 챔피언이며, 교육은 그 일부일 뿐입니다.

두 가지 주요 롤아웃 방식

빅뱅

• 한 번의 컷오버로 모든 것을 가동
• 표준화된 프로세스에 가장 빠르게 도달
• 초기 비용은 낮고, 첫날 리스크는 높음
• 철저한 리허설과 깨끗한 데이터가 필요

단계적

• 모듈, 지역, 기능별로 웨이브를 나눠 가동
• 웨이브 사이에 방향을 수정할 여유가 더 많음
• 지원 비용이 더 오래 들고, 유지할 연계가 더 많음
• 지속적인 규율과 거버넌스가 필요

빅뱅

한 제조 기업의 SAP Go-Live에 참여한 적이 있는데, 모든 것이 한 주말에 전환되었습니다. 재무, 구매, 영업, 제조가 모두 월요일 아침에 가동되었습니다. 격렬했지만, 명확함이 강력했습니다. 모두가 함께 움직였고, 어느 시스템과 어느 데이터를 믿어야 하는지 혼란이 없었습니다.

성공 요인은 이렇습니다. 팀은 컷오버를 여러 번 리허설했고, 몇 주 전에 데이터를 정리했으며, 실제 테스트 케이스로 사용자를 교육했습니다. 장점은 더 빠른 정렬과 더 빠른 성과입니다. 단점은 실수할 여지가 없다는 것입니다. 첫날 영업 오더에 가격 문제가 생겼을 때, 그 문제는 모든 지역을 덮쳤습니다.

적합한 경우: 프로세스가 표준화되어 있고, 팀이 준비되어 있으며, 경영진이 범위를 지켜 낼 때.

단계적

한 유통 체인의 다른 프로젝트에서는 단계적으로 진행했습니다. 재무, HR, 구매를 먼저 하고, 이어서 물류와 POS를 했습니다. 1년 넘게 걸렸지만 팀들에게 숨 쉴 여유를 주었습니다. HR 팀은 다른 모든 사람을 교육하기 전에 첫 한 달 동안 워크플로를 정리했습니다. 빅뱅에서는 불가능했을 일입니다.

절충점은 지원 기간이 더 길어진다는 것이며, 이미 가동된 시스템과 아직 가동되지 않은 시스템 사이를 흐르는 데이터는 더 세심한 관리가 필요합니다.

적합한 경우: 조직이 크거나 분산되어 있고, 지역별로 프로세스가 다르거나, 경영진이 방향을 수정할 여유를 원할 때.

하이브리드

때로는 답이 둘 다입니다.

제가 함께 일한 영국의 한 가전 유통업체는 재무와 구매를 빨리 가동해야 했습니다. 의존 관계가 너무 많아 물류 창고는 준비되지 않았습니다. 그래서 재무와 구매가 먼저 가고, 물류와 창고가 뒤따랐습니다. 한 영역은 빅뱅, 다른 영역은 단계적이었습니다.

하이브리드는 조율 작업을 늘립니다. 구매는 SAP에 있고 영업은 아직 아니라면, 둘 사이의 데이터 동기화를 신중하게 설계해야 하고 거버넌스는 내내 날카롭게 유지되어야 합니다.

적합한 경우: 사업 부문마다 속도가 다르거나, 일부 부서가 더 빨리 움직여야 하거나, 계절적 성수기 때문에 특정 Go-Live 날짜를 쓸 수 없을 때.

세 가지를 비교하면 다음과 같습니다.

기준	빅뱅	단계적	하이브리드
일정	가장 짧음: 모든 것이 한 번에	더 긺: 웨이브에 걸쳐 분산	중간: 일부 영역은 빠르게, 나머지는 더 느리게
업무 중단	Go-Live에 문제가 생기면 큼	더 작음: 변화가 점진적	첫 웨이브는 큼, 이후는 작아짐
리스크	문제가 비즈니스 전체를 덮침	문제가 한 단계 안에 머묾	빅뱅 부분에 집중
비용	초기 비용은 낮고, 실수는 비쌈	총비용은 더 높고, 긴급 상황은 적음	그 중간, 조율이 변수
데이터 마이그레이션	한 번의 기간에 완료해야 함	적재를 나눠서 단계마다 양이 적음	가동된 시스템과 가동 전 시스템 사이의 인터페이스가 어려운 부분
사용자 도입	어려움: 하룻밤에 바뀜	쉬움: 점진적 노출	첫 웨이브가 개척자 역할, 이후 웨이브는 그들에게서 배움
가장 적합한 경우	규모가 작은 조직, 표준 프로세스, 높은 준비도	프로세스가 다양한 대규모 분산 기업	일부 부문은 준비되었고 나머지는 아닌 다부문 조직

Decide

어떤 마이그레이션 경로가 상황에 맞습니까?

레거시가 파편화되어 있고 프로세스를 재설계하고 싶다

→그린필드

프로세스가 건전하고 ECC가 안정적이며 이력을 유지해야 한다

→브라운필드

다중 법인이고 일부 재사용과 선택적 데이터를 원한다

→블루필드

그린필드: 새로 시작

인수합병으로 빠르게 성장해 시스템이 파편화된 한 유통 기업의 프로젝트에서 이 접근 방식을 보았습니다. 깨끗한 상태에서 시작해 S/4HANA 위에 통합된 프로세스를 설계했습니다. 각자의 방식에 익숙한 팀들은 처음에는 반발했습니다. 결과는 지역 간 더 높은 일관성, 더 깔끔한 리포팅, 서로 대화하는 시스템이었습니다.

적합한 경우: 레거시 시스템이 너무 파편화되었거나 커스터마이징이 많아 깔끔하게 마이그레이션할 수 없고, 비즈니스가 낡은 습관을 디지털화하는 대신 일하는 방식을 다시 생각하고 싶을 때.

브라운필드: 변환과 업그레이드

초기 프로젝트 중 한 제조 기업의 사례에서는 브라운필드가 옳은 선택이었습니다. 고객사는 ECC 시스템을 크게 커스터마이징했고, 처음부터 다시 하는 것은 너무 위험해 보였습니다. 우리는 S/4HANA로의 기술적 변환에 집중했습니다. 사용자는 더 빨리 적응했고 Go-Live도 더 빨랐지만, 재설계했어야 할 어색한 워크플로를 그대로 가져갔습니다.

적합한 경우: 기존 프로세스가 건전하고 문서화되어 있고, 감사나 컴플라이언스를 위해 트랜잭션 이력이 중요하며, 예산이나 시간이 빠듯하고, 조직이 구조 개편 중이 아닐 때.

블루필드: 선택적 전환

블루필드(선택적 데이터 전환)는 모든 것이 아니라 특정 회사 코드, 사업 부문, 기간 범위를 옮깁니다. 인수합병이나 분사로 형성된 기업, 아무도 필요로 하지 않는 수년 치 데이터를 안고 있는 시스템에 맞습니다. 유지하기로 한 부분에는 브라운필드식 연속성을, 프로세스에는 그린필드식 자유를 얻습니다. 제 ECC에서 S/4HANA로의 마이그레이션 가이드에서 세 가지 경로와 일정을 더 깊이 다룹니다.

2018년에는 롤아웃 방식과 마이그레이션 경로가 전략의 전부였습니다. 2026년에는 세 번째 결정이 있고, 이것이 나머지 둘을 제한합니다. 어떤 에디션의 S/4HANA를 쓰고 어떻게 구매하느냐입니다.

1. 03롤아웃 방식빅뱅, 단계적, 하이브리드. 얼마나 큰 업무 중단을 흡수할 수 있는지로 결정
2. 02마이그레이션 경로그린필드, 브라운필드, 블루필드. 에디션이 지원하는 범위 안에서
3. 01배포 모델Public Edition, Private Edition, 온프레미스. 이것을 먼저 결정

S/4HANA Cloud Public Edition(대개 GROW with SAP를 통해 구매하며, SAP는 SAP Cloud ERP라는 이름으로 마케팅합니다). 멀티테넌트 SaaS, SAP 표준 프로세스, 6개월마다 업그레이드, 코어 수정 불가. 그린필드만 가능합니다. 가치 실현이 가장 빠르고 유연성은 가장 낮습니다. SAP 표준을 기꺼이 받아들이는 중견기업에 가장 적합합니다. 프로세스가 크게 달라야 한다면 잘못된 답입니다.

S/4HANA Cloud Private Edition(대개 RISE with SAP를 통해 구매). 싱글테넌트, SAP가 운영하는 인프라, 2년마다 새 릴리스와 7년의 메인스트림 유지보수, 구성과 확장의 여지가 더 많습니다. 브라운필드, 그린필드, 선택적 전환을 지원합니다. 대부분의 대기업 프로그램에서 기본값입니다.

S/4HANA 온프레미스. 직접 또는 하이퍼스케일러가 인프라를 운영합니다. 확장성과 통제력이 가장 크고 업그레이드 주기는 가장 느립니다. Clean Core는 권장되지만 강제되지는 않습니다. 엄격한 데이터 상주 요건이 있는 경우와 강력한 사내 Basis 팀을 가진 조직에 맞습니다. SAP의 새로운 기능은 점점 클라우드 에디션에 먼저 도달합니다.

그다음 롤아웃 방식과 마이그레이션 경로는 선택한 에디션 안에 놓입니다. Public Edition 프로젝트는 정의상 그린필드입니다. 크게 커스터마이징된 ECC 시스템을 변환하는 Private Edition 프로그램은 대개 브라운필드나 블루필드이고, 대규모에서는 대개 단계적입니다. RISE와 GROW의 상업적 측면은 제 GROW with SAP 및 RISE with SAP 페이지를 보십시오.

목요일 아침, 설계 워크숍 중간이었습니다. IT 리드가 SAP 표준 주문-수금(order-to-cash) 프로세스 시연을 막 끝낸 참이었습니다. 영업 쪽의 누군가가 말했습니다. “그런데 우리는 그렇게 안 하는데요.” 방 안이 조용해졌습니다. 이 순간은 거의 모든 프로젝트에서 일어납니다.

Fit-to-Standard

표준 SAP를 유지하면 구축 시간과 장기 유지보수가 줄어듭니다. 존재하지 않는 커스텀 로직은 업그레이드로 깨질 수 없습니다. 제가 참여한 한 유통 프로젝트에서 Fit-to-Standard는 고객사가 6개월이 채 되지 않아 Go-Live하도록 도왔습니다. 움직이는 부품이 적고, 오가는 일이 적고, 앞으로의 업그레이드에 더 깔끔한 시스템이었습니다.

경험칙: 규제가 요구하거나 프로세스가 실질적인 경쟁 우위를 줄 때만 커스터마이징하십시오. “원래 그렇게 해 왔으니까”라는 이유로는 절대 안 됩니다.

실무에서의 Clean Core

모든 파트너에게 릴리스된 API나 SAP BTP 위에 구축한 확장 사례를 요청하십시오. 답이 모호하면 위험 신호로 보십시오. 클라우드 프로그램에 온프레미스 습관을 가져오는 파트너는 첫 스프린트부터 기술 부채를 쌓습니다.

코드가 불가피할 때

일부 커스텀 개발은 필요합니다. SAP Build Code와 Joule for developers 같은 AI 도구는 코드를 작성하는 비용을 낮춰 줍니다. 유지보수하는 비용은 낮춰 주지 않습니다.

문서화되지 않은 커스텀 로직은 아무도 손대고 싶어 하지 않는 로직이 되고, 이후 모든 변경을 지연시킵니다. 어떤 AI 도구도 이를 해결하지 못합니다. 문서화 규율이 해결합니다. 반드시 커스터마이징해야 한다면 처음부터 문서화하고, 릴리스된 API나 BTP 위에 구축하고, 코어와 분리해 두십시오. 깔끔한 커스터마이징에는 회수할 수 있는 실제 비용이 있습니다. 깔끔하지 않은 커스터마이징에는 계속 치러야 하는 비용이 있습니다.

2026년 미국 시장에서 제가 보는 S/4HANA 총 프로그램 비용 범위입니다. 범위, 복잡성, 산업, 파트너, 에디션에 따라 달라집니다. 견적이 아니라 예산 계획의 기준점으로 쓰십시오.

전략과 범위	일반적인 총 프로그램 비용
중견기업 브라운필드, 단계적	500만 달러에서 1,500만 달러
중견기업 그린필드, 빅뱅	800만 달러에서 2,000만 달러
중견기업 GROW with SAP(구독과 구축)	200만 달러에서 600만 달러
대기업 브라운필드, 단계적	2,500만 달러에서 8,000만 달러
대기업 그린필드, 빅뱅	3,500만 달러에서 1억 2,000만 달러
대기업 RISE with SAP(구독과 구축)	2,000만 달러에서 8,000만 달러
글로벌 다지역, 모든 조합	1억 달러에서 3억 달러 이상

배포 모델은 가장 자주 과소평가되는 비용 변수입니다. 다년 약정을 합산하면 RISE와 GROW 구독은 온프레미스 라이선스보다 저렴하지 않습니다. 그 가치는 인프라 책임의 이전, 더 빠른 가치 실현, 예측 가능한 구독 비용에 있습니다. RISE나 GROW를 택하는 이유가 총비용인 경우는 드뭅니다. 운영 모델입니다.

SAP 구축 전략이란 무엇입니까?

기업이 SAP를 도입하는 접근 방식입니다. 범위, 방법론, 배포 모델, 마이그레이션 경로, 롤아웃 방식, 일정을 포함합니다. 2026년의 주요 선택지는 배포 모델(Public Edition, Private Edition 또는 온프레미스), 마이그레이션 경로(그린필드, 브라운필드 또는 블루필드), 롤아웃 방식(빅뱅, 단계적 또는 하이브리드)입니다.

중요한 것은 그 조합이 조직의 준비도, 프로세스 복잡성, 규제 프로파일, 업무 중단에 대한 감내력에 맞느냐입니다.

빅뱅 구축은 언제 효과가 있습니까?

프로세스가 이미 표준화되어 있고, 사용자가 충분히 교육받았고, 마이그레이션 전에 데이터를 정리했고, 경영진이 범위를 지켜 낼 때입니다. 이 중 하나라도 빠지면, 특히 깨끗한 데이터와 사용자 준비도가 없으면 도박입니다.

Go-Live 때의 문제는 한꺼번에 모든 곳을 덮칩니다. 준비가 되어 있으면 감당할 수 있습니다. 준비가 없으면 위기입니다.

그린필드와 브라운필드 SAP 구축은 어떻게 다릅니까?

그린필드는 레거시 구성을 가져오지 않고 새 시스템으로 시작합니다. SAP 표준을 기준으로 프로세스를 처음부터 설계합니다. 브라운필드는 기존 시스템을 변환하며 트랜잭션 이력과 구성을 유지합니다.

그린필드는 초기 비용이 더 들고 더 깔끔하며 미래 지향적인 시스템을 만듭니다. 브라운필드는 더 빠르고 업무 중단이 적지만 우회책과 커스텀 코드를 그대로 가져갑니다. 블루필드는 중간 경로로, 선택한 법인과 데이터만 선택적으로 마이그레이션합니다.

RISE with SAP와 GROW with SAP는 어떻게 다릅니까?

RISE with SAP는 대기업을 위한 SAP의 구독 상품으로, 대개 S/4HANA Cloud Private Edition 기반이며 SAP가 운영하는 인프라와 기술 운영이 하나의 계약에 들어 있습니다. 미국 시장에서는 구축 비용을 포함해 총 프로그램이 대개 2,000만 달러에서 8,000만 달러입니다.

GROW with SAP는 중견기업을 겨냥하며 SAP 표준 프로세스를 쓰는 S/4HANA Cloud Public Edition에서 실행됩니다. 구축 비용을 포함해 대개 200만 달러에서 600만 달러입니다.

기업 규모와 프로세스가 SAP 표준에서 얼마나 달라야 하는지가 둘 중 무엇을 고를지 결정합니다.

SAP의 Fit-to-Standard란 무엇이며 왜 이제 더 중요합니까?

Fit-to-Standard는 현재 일하는 방식에 맞춰 SAP를 커스터마이징하는 대신, 프로세스를 SAP의 표준 기능에 맞추는 것을 뜻합니다. 구축을 단축하고, 유지보수를 줄이며, 업그레이드를 깔끔하게 만듭니다.

Clean Core 때문에 지금 더 중요합니다. Public Edition에서는 코어 수정이 아예 불가능합니다. Private Edition과 온프레미스에서는 수정할 때마다 업그레이드 작업이 늘어납니다. 물어야 할 것은 표준 SAP가 해결할 수 없는 실질적인 비즈니스 사유가 있는지, 있다면 파트너가 릴리스된 API나 SAP BTP 위에 확장을 구축할 수 있는지입니다.

SAP Activate 방법론의 단계는 무엇입니까?

SAP Activate는 6개 단계로 이루어집니다. Discover(SAP 제품 탐색과 비즈니스 케이스), 그다음 네 가지 핵심 구축 단계인 Prepare(계획, 거버넌스, 팀 구성), Explore(Fit-to-Standard 워크숍과 백로그), Realize(스프린트로 구성, 확장, 테스트), Deploy(컷오버, Go-Live, 하이퍼케어)가 이어집니다. Run은 Go-Live 이후의 운영을 다룹니다.

Realize는 대부분의 프로젝트가 시간을 잃는 단계이며, 특히 테스트에서 데이터 품질 문제가 드러나거나 커스터마이징 범위가 커질 때 그렇습니다. Realize 내내 범위 기준선을 단단히 유지하는 것이 일정대로 Go-Live하는 프로젝트와 표류하는 프로젝트를 가릅니다.

SAP 구축은 왜 실패합니까?

실패의 대부분은 네 가지 원인으로 설명됩니다. 킥오프 후 사라지는 경영진의 참여, IT 업무로 취급되는 데이터 마이그레이션, 교육 매뉴얼에 그치는 변화 관리, 그리고 첫 업그레이드 때 드러나는 기술 부채를 만드는 Clean Core 경험이 없는 파트너입니다.

기술이 실패하는 경우는 드뭅니다. 의사결정이 이루어지지 않을 때, 더러운 데이터가 새 시스템으로 들어갈 때, 사용자가 우회로를 찾을 때, 커스터마이징을 다시 만들어야 할 때 프로그램이 실패합니다. 전략은 중요합니다. 실행 규율이 더 중요합니다.