비용이 큰 실수를 피하는 최선의 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에서는 코어를 수정할 수 없습니다. 확장은 릴리스된 API를 사용하며, ABAP Cloud로 온스택 방식으로 하거나 SAP BTP에서 사이드 바이 사이드 방식으로 합니다. 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 이후 이를 바로잡는 데 큰 비용이 들었습니다. 변화 관리는 소통, 참여, 그리고 조직 내부의 챔피언이며, 교육은 그 일부입니다.

두 가지 주요 전개 방식

빅뱅

1. 01한 번의 전환으로 모든 것을 가동
2. 02표준화된 프로세스로 가는 가장 빠른 길
3. 03초기 비용은 낮지만 첫날 리스크는 높음
4. 04철저한 리허설과 깨끗한 데이터가 필요

단계적

1. 01모듈, 지역, 기능별로 차례로 가동
2. 02단계 사이에 궤도를 수정할 여지가 큼
3. 03지원 비용이 길어지고 유지할 연계가 늘어남
4. 04지속적인 규율과 거버넌스가 필요

빅뱅

한 제조 기업의 SAP Go-Live에 참여했을 때, 모든 것이 한 주말에 전환되었습니다. 재무, 구매, 영업, 제조가 모두 월요일 아침에 가동되었습니다. 긴장감이 컸지만 그 명확함은 강력했습니다. 모두가 함께 움직였고, 어떤 시스템이나 데이터를 믿어야 할지 혼란이 없었습니다.

성공 요인은 팀이 전환 리허설을 여러 번 하고, 몇 주 전에 데이터를 정리하고, 실제 테스트 케이스로 사용자를 교육한 것이었습니다. 장점은 더 빠른 정렬과 더 빠른 성과입니다. 단점은 실수할 여지가 없다는 것입니다. 첫날 가격 문제가 판매 오더에 영향을 주자 모든 지역이 영향을 받았습니다.

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

단계적

한 소매 체인과의 다른 프로젝트에서는 단계적으로 진행했습니다. 재무, 인사, 구매를 먼저, 그다음 물류와 POS였습니다. 1년 넘게 걸렸지만 팀에 숨 돌릴 여유가 생겼습니다. 인사팀은 첫 한 달 동안 워크플로를 정리한 뒤 다른 모든 사람을 교육했습니다. 빅뱅에서는 불가능했을 일입니다.

트레이드오프는 지원 기간이 길어진다는 점이며, 가동된 시스템과 아직 가동되지 않은 시스템 사이를 오가는 데이터에는 각별한 주의가 필요합니다.

효과적인 경우: 조직이 크거나 분산되어 있고, 지역마다 프로세스가 다르거나, 경영진이 궤도 수정의 여지를 원할 때.

하이브리드

때로는 둘 다가 답입니다.

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

하이브리드는 조율 작업을 늘립니다. 구매는 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 프로그램 총비용 범위입니다. 금액을 좌우하는 것은 전략보다 기업 규모와 범위입니다. 견적이 아니라 예산 계획의 기준점으로 쓰시고, 전체 내역은 제 2026년 SAP 구축 비용 범위를 참고하십시오.

기업 규모	일반적인 프로그램 총비용
소기업(직원 200명 미만)	8만~50만 달러
중견기업(직원 200~1,000명)	50만~200만 달러
대기업(직원 1,000~10,000명)	200만~1,000만 달러 이상
글로벌 그룹(직원 10,000명 이상)	1,000만~5,000만 달러 이상

전략은 범위 안에서 위치를 바꿀 뿐, 범위를 넘나들게 하지는 않습니다. 그린필드는 브라운필드보다 초기 비용이 더 들고, 빅뱅은 낮은 초기 비용과 높은 첫날 리스크를 맞바꿉니다. 여기에 10~20퍼센트의 예비비를 더 확보하고, 구축 서비스가 전체의 35~50퍼센트를 차지한다고 예상하십시오.

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

이 가이드는 비즈니스 케이스부터 가동까지 모든 주제를 연결한 SAP 구축 가이드의 일부입니다.

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가 운영하는 인프라와 기술 운영을 하나의 계약에 담습니다. 제가 보는 프로그램 총액은 구축을 포함해 대기업이 보통 200만~1,000만 달러 이상, 글로벌 그룹이 1,000만~5,000만 달러 이상이며 기간은 9~18개월입니다.

GROW with SAP는 중견기업을 대상으로 하며 SAP 표준 프로세스를 갖춘 S/4HANA Cloud Public Edition에서 운영됩니다. 중견기업의 경우 구축을 포함해 보통 50만~200만 달러, 기간은 약 6~9개월입니다.

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

SAP의 Fit-to-Standard란 무엇이며 왜 지금 더 중요한가요?

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

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

SAP Activate 방법론의 단계는 무엇인가요?

SAP Activate에는 여섯 단계가 있습니다. Discover(SAP 오퍼링과 비즈니스 케이스 탐색)에 이어 네 개의 핵심 구축 단계가 있습니다. Prepare(계획, 거버넌스, 팀 구성), Explore(Fit-to-Standard 워크숍과 백로그), Realize(스프린트 단위의 구성, 확장, 테스트), Deploy(전환, Go-Live, 하이퍼케어)입니다. Run은 Go-Live 이후의 운영을 다룹니다.

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

SAP 구축은 왜 실패하나요?

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

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