SAP 구축이란 무엇인가? 절차, 단계, 프로세스

SAP 구축은 기업의 재무, 구매, 공급망, 영업, 인사를 하나의 SAP 시스템으로 옮기는 프로그램입니다. 오늘날 그 시스템은 대개 SAP S/4HANA입니다. SAP Activate의 6단계(Discover, Prepare, Explore, Realize, Deploy, Run)를 거쳐 진행되며, 성패는 누군가 무엇이든 설정하기 전에 프로세스, 데이터, 사람에 관한 작업을 얼마나 해 두었는지에 달려 있습니다.

짧게 답하면, SAP 구축 프로젝트는 따로 놀던 레거시 시스템을 하나의 시스템과 하나의 데이터 모델로 바꾸는 일입니다. 절차는 여섯 단계입니다. 사업 타당성을 확인하고, 팀을 꾸리고, SAP 표준에 맞춰 설계하고, 구축하고 테스트하고, Go-Live하고, 안정화한 뒤 인계합니다. 제 경험상 GROW with SAP는 6~9개월, RISE with SAP는 9~18개월이 걸리며, 단계별 세부 내용은 제 SAP 구축 일정 가이드에서 다룹니다.

제가 이끌었거나, 구해 냈거나, 옆길로 새는 것을 지켜본 21개의 SAP 프로그램에서 패턴은 같았습니다. SAP를 소프트웨어 설치로 여기는 기업은 고전합니다. 프로세스를 먼저 재설계하고 설정을 나중에 하는 기업은 이사회에 약속한 것을 해냅니다.

이 글은 SAP 구축을 앞둔 경영진과 프로그램 리더를 위한 것입니다. 한 섹션만 읽으신다면 ‘설정을 시작하기 전의 계획’을 읽으십시오.

S/4HANA는 SAP의 현행 ERP로, SAP HANA 인메모리 데이터베이스에서 실행됩니다. 아직도 이전 세대인 SAP ECC를 쓰는 기업이 많지만, ECC 메인스트림 유지보수는 2027년 12월 31일에 종료됩니다. 더 높은 비용을 내면 2030년 말까지 연장 유지보수를 선택할 수 있습니다.

대부분의 구축에서 가장 먼저 다루는 핵심 모듈은 다음과 같습니다.

모듈	관리 대상
FI(재무회계)	총계정원장, 매입채무, 매출채권, 자산회계
CO(관리회계)	코스트 센터, 손익 센터, 내부 오더, 관리 보고
MM(자재관리)	조달, 재고, 자재 이동, 공급업체 관리
SD(영업 및 유통)	주문에서 수금까지, 가격 결정, 출하, 청구
PP(생산계획)	생산 오더, 능력 계획, MRP
HCM(인적자원관리)	인사 마스터 데이터, 급여, 근태 관리

대부분의 기업은 FI/CO와 한두 개의 운영 모듈로 시작합니다. 나머지는 이후 릴리스에서 구축합니다.

구축과 마이그레이션은 같은 것이 아닙니다. 이미 SAP ECC를 쓰고 있다면 SAP 시스템을 전환하거나 다시 구축하는 것이며, 그린필드, 브라운필드, 선택적 전환 경로는 제 ECC에서 S/4HANA로의 마이그레이션 가이드에서 다룹니다.

SAP Activate는 SAP의 구축 방법론입니다. 이전의 ASAP 방법론을 대체했으며, 6개의 단계가 있고 각 단계에는 다음으로 넘어가기 전에 통과해야 하는 게이트가 있습니다.

SAP Activate의 여섯 단계

1. 01

   Discover

   사업 타당성을 확인하고 우선순위 프로세스를 체험판이나 데모 시스템에서 검증합니다.

2. 02

   Prepare

   착수: 팀, 거버넌스, 범위 문서, 계획, 시스템 접근 권한.

3. 03

   Explore

   프로세스 오너와 Fit-to-Standard 워크숍을 진행합니다. 설정, 인터페이스, 확장 기능의 백로그를 만듭니다.

4. 04

   Realize

   설정, 확장, 데이터 마이그레이션, 테스트. 가장 긴 단계입니다. 종료하려면 깨끗한 회귀 테스트 결과가 필요합니다.

5. 05

   Deploy

   실제 프로세스로 사용자를 교육하고, 컷오버를 리허설하고, 워룸을 갖춘 상태에서 Go-Live합니다.

6. 06

   Run

   하이퍼케어, 최적화, Centre of Excellence로의 인계.

이 표는 제가 프로그램 사무실 벽에 붙여 두는 버전입니다. 각 단계가 무엇을 만들어야 하는지, 누가 책임지는지, 다음 단계를 시작하기 전에 무엇이 충족되어야 하는지 보여 줍니다.

단계	산출물	책임자	다음 단계로 가는 게이트
Discover	사업 타당성, 목표 범위, 배포 방식 선택	스폰서와 CFO	예산 승인
Prepare	범위 문서, 계획, 거버넌스, 팀 구성	프로그램 디렉터	스폰서의 범위 서명
Explore	Fit-to-Standard 결과, 백로그, 확장 결정	솔루션 아키텍트와 프로세스 오너	미해결 갭 없음
Realize	설정과 테스트를 마친 시스템, 마이그레이션된 테스트 데이터	기능 리드와 기술 리드	깨끗한 회귀 테스트, 데이터 대사 일치
Deploy	교육받은 사용자, 리허설한 컷오버, Go/No-Go 자료	컷오버 매니저	3일간의 결산 리허설 통과
Run	하이퍼케어 로그, CoE 인계, 2단계 백로그	서비스 딜리버리 리드	미해결 P1/P2 없음, CoE 인수

각 단계의 템플릿은 제 SAP Activate 템플릿 가이드에 있습니다.

5단계인가, 6단계인가?

사람들이 ‘SAP 구축 5단계’를 검색하는 이유는 SAP의 이전 ASAP 방법론이 5단계였기 때문입니다. 프로젝트 준비, 비즈니스 블루프린트, 실현, 최종 준비, Go-Live와 지원이었습니다.

SAP Activate는 같은 논리를 유지하면서 맨 앞에 Discover, 맨 끝에 Run을 더했습니다. 보통 Prepare부터 Deploy까지를 핵심 수행 단계로 봅니다. 아직 ‘블루프린트’라고 말하는 팀은 대개 Explore를 뜻합니다.

3일간의 결산 리허설 게이트

Realize와 Deploy 사이의 게이트는 일정 압박 속에서 팀이 가장 자주 건너뛰는 게이트입니다. 저는 모든 프로그램에서 3일간의 결산 리허설을 준비 완료 게이트로 씁니다. 새 시스템에서 재무가 장부를 마감하지 못한다면, IT가 뭐라고 하든 데이터 마이그레이션은 준비되지 않은 것입니다.

그 게이트를 건너뛰면, 게이트가 일으켰을 지연보다 더 큰 비용을 치릅니다.

순서가 중요합니다. 설정에 관한 결정을 하나라도 내리기 전에 해야 할 일이 네 가지 있습니다.

1. 01현행 프로세스 파악우회 방식까지 포함해 실제로 돌아가는 그대로
2. 02표준인지 확장인지 결정거의 언제나 표준이 더 빠릅니다
3. 03데이터 품질 점검데이터 마이그레이션을 시작하기 전에
4. 04팀을 꾸린 뒤 범위 확정누가 있느냐가 무엇을 해낼 수 있는지를 정합니다

그때 비로소 설정을 시작합니다

제가 보는 가장 큰 실수는 처음에 제대로 계획하지 않는 것입니다. 예산은 Explore에서 초과됩니다. 워크플로, 보고서, 인터페이스, 데이터 변환, 기능 확장, 양식(WRICEF) 목록이 늘어나고, 범위를 고객이 아니라 벤더가 쥐게 될 때입니다. 그것이 예산에 어떤 결과를 낳는지는 제 SAP 구축 비용 분석에서 보여 드립니다.

현행 프로세스를 실제로 돌아가는 그대로 파악하기

프로세스가 어떠해야 하는지가 아닙니다. 우회 방식까지 포함해 실제로 어떠한지입니다.

2023년 유럽의 한 금융 서비스 프로그램에서, 저는 재무 부서가 관계사 간 거래를 스프레드시트로 대사하고 있던 블루프린트 세션에 앉아 있었습니다. 아무도 적어 두지 않은 요구사항은 그런 우회 방식 속에 숨어 있습니다.

프로세스별로 표준인지 확장인지 결정하기

SAP 표준 기능으로 커버되는 프로세스와 확장이 필요한 프로세스를 구분합니다. 거의 언제나 표준이 더 빠릅니다. 확장 하나하나가 테스트 사이클, 업그레이드 위험, 유지보수를 늘리기 때문입니다.

SAP의 Clean Core 지침 아래에서는 확장마다 어디에 둘지도 의도적으로 정해야 합니다. 그래서 이 결정은 가벼워지는 것이 아니라 더 무거워집니다.

데이터 마이그레이션 전에 데이터 품질 점검하기

데이터는 가장 과소평가되는 워크스트림입니다. 제 경험상 데이터 마이그레이션은 구축 공수의 30~40%를 차지합니다.

한 고객사에는 중복된 고객 데이터가 18,000건이 넘었습니다. 이를 Go-Live 이후에 바로잡느라 청구 업무가 몇 주 동안 차질을 빚었습니다. 데이터는 일찍 프로파일링하고 원천 시스템에서 정제하십시오. 방법은 제 SAP 데이터 마이그레이션이 실패하는 이유 가이드에서 다룹니다.

팀을 먼저 꾸리고 범위는 그다음에 확정하기

해낼 수 있는 범위는 각 워크스트림에서 설정하고, 테스트하고, 책임질 수 있는 사람이 누구인지에 달려 있습니다. 범위를 먼저 정하고 사람을 나중에 구하는 팀은 과하게 약속한 것을 다시 짜느라 몇 달을 씁니다.

SAP 구축 프로젝트에는 다음 역할마다 이름이 정해진 담당자가 필요하며, 대부분은 파트너가 아니라 귀사 쪽 사람이어야 합니다.

1. 경영진 스폰서. 사업 타당성을 책임지고 의견이 갈릴 때 결론을 냅니다. 보통 CFO나 COO입니다.
2. 프로그램 디렉터. 계획, 예산, 운영위원회를 운영합니다. 귀사 소속이거나 파트너와 독립된 사람이어야 합니다.
3. 프로세스 오너. 영역(재무, 구매, 영업, 생산)마다 한 명입니다. 설계를 승인하고 Go-Live 이후의 결과를 책임집니다.
4. 솔루션 아키텍트. 전체 설계를 쥐고 모든 확장을 어디에 둘지 결정합니다.
5. 기능 리드와 기술 리드. 설정하고, 개발하고, 테스트합니다. 보통 파트너 팀입니다.
6. 데이터 마이그레이션 리드. Realize가 아니라 Prepare에서 임명합니다.
7. 변화관리 및 교육 리드. Explore부터 최종 사용자와 이야기를 시작합니다.
8. 컷오버 매니저. Go-Live 런북과 Go/No-Go 자료를 책임집니다.

이 목록보다 더 중요한 규칙이 하나 있습니다. 실제 작업을 수행할 파트너가 귀사의 사업 타당성 보고서를 써서는 안 됩니다.

그들의 동기는 시작하는 것입니다. 귀하의 동기는 끝내는 것입니다.

거의 모든 프로그램에서 보는 문제와 각각의 대응책입니다.

문제	어떻게 나타나는가	어떻게 대응하는가
범위 확대	‘하는 김에 이것도 추가해 주세요…’ 같은 요청이 쌓입니다	첫날부터 공식적인 변경 통제를 하고 모든 요청에 영향 평가를 붙입니다
데이터 품질	마이그레이션 과정에서 아무도 몰랐던 불일치가 드러납니다	데이터를 일찍 프로파일링하고 원천 시스템에서 정제합니다
사용자 저항	Go-Live 후 2주 안에 사용자들이 Excel로 돌아갑니다	Explore부터 최종 사용자를 설계에 참여시킵니다
연계 실패	UAT에서 외부 시스템과의 연결이 끊어집니다	Explore에서 인터페이스를 정리하고 일찍 실제와 비슷한 물량으로 테스트합니다
테스트 사이클 축소	일정을 맞추려고 회귀 테스트를 줄입니다	테스트 단계를 지킵니다. 개발 지연이 테스트를 압축해서는 안 됩니다
팀 피로	마지막 구간에서 분위기가 가라앉고 결함률이 올라갑니다	간단한 주간 심리 지수로 추적합니다

팀 피로에 대해서는 간단한 주간 심리 지수를 추적합니다. 팀의 25%를 넘는 인원이 버겁다고 답하면 테스트 결함률이 치솟습니다.

2024년 GCC의 한 제조업 프로그램에서, 팀은 일정 3주를 만회하려고 회귀 테스트를 건너뛰었습니다. 그 뒤 재무는 핵심 보고서를 대사하지 못했고, 몇 달에 걸친 뒷정리가 이어졌습니다. 시스템 결함이 아니라 피할 수 있었던 결정이었습니다.

Go-Live 전, 중, 후

Go-Live 전에는 결산 리허설을 하고, 마이그레이션된 데이터를 대사 보고서로 검증하고, 데모 시나리오가 아닌 실제 프로세스로 교육하십시오. 롤백 계획도 테스트합니다. 운영위원회와 Go/No-Go 기준을 하나씩 짚고, 암묵적인 끄덕임이 아니라 명시적인 승인을 받으십시오.

Go-Live 중에는 모니터링을 강화하고, 처음 72시간 동안은 컷오버 팀이 24시간 대응할 수 있게 하십시오. 그 몇 시간 동안 내린 결정이 하이퍼케어가 자신감 속에 시작될지, 쌓인 요청 속에 시작될지를 가릅니다.

Go-Live 후에는 최소 4주 동안 하이퍼케어를 운영하고 지원 티켓을 범주별로 추적하십시오. 티켓은 교육이 어디서 부족했고 설정을 어디서 조정해야 하는지 알려 줍니다.

2024년 유럽의 한 제조업 프로그램에서, 고객사는 원자재가 계속 바닥났습니다. 구매 부서는 계획 담당자를 탓했고, 계획 담당자는 아무도 믿지 않는 스프레드시트를 탓했습니다. 저희는 그 구조를 S/4HANA로 바꾸고, MRP를 제대로 설정한 SAP PP에 크게 의존했습니다.

재고 수준은 짐작에서 실시간 데이터로 바뀌었고, 구매 오더는 필요에 따라 생성되었습니다. 첫 6개월 동안 원자재 부족은 50% 이상 줄었습니다. 이 성과는 설정에 앞선 프로세스 재설계에서 나왔습니다. 프로세스 작업 없이 PP만 들였다면 틀린 답을 더 빨리 냈을 뿐입니다.

2024년 영국의 한 전문 서비스 프로그램에서는 재무가 문제였습니다. 월 마감에 2주가 넘게 걸렸고, 보고서는 손으로 다시 만들었습니다. 저희는 현장에 깊이 관여하는 운영위원회 아래에서 SAP Finance를 단계적으로 도입했습니다.

월 마감은 1주를 조금 넘는 수준으로 줄었습니다. CFO는 제게 숫자가 ‘믿을 만하게 느껴졌다’고 말했습니다.

2022년을 기준으로 쓴 가이드는 2026년의 구매자 앞에서 버티지 못합니다. 킥오프부터 설계에 반영해야 할 변화가 세 가지 있습니다.

클라우드 에디션이 기본이 되었습니다

SAP는 현재 두 가지 클라우드 ERP 에디션을 판매합니다. SAP Cloud ERP(퍼블릭 에디션, 이전의 S/4HANA Cloud Public Edition)와 SAP Cloud ERP Private(프라이빗 에디션)입니다. RISE with SAP는 프라이빗 에디션에 SAP가 운영하는 서비스와 SAP Signavio, SAP LeanIX, SAP Cloud ALM을 포함한 도구 세트를 묶은 패키지입니다. GROW with SAP는 퍼블릭 에디션을 쓰는 중견기업을 위한 패키지입니다.

이제 에디션 결정이 예전의 도입 방식 논쟁보다 위에 있습니다. 빅뱅인지 단계적 도입인지, 그린필드인지 브라운필드인지 선택적 전환인지는 에디션 안에서 고르는 것이지, 에디션 대신 고르는 것이 아닙니다.

Clean Core는 이분법이 아니라 등급입니다

2025년 8월 SAP는 A부터 D까지 네 가지 Clean Core 레벨을 도입했습니다. 레벨 A는 릴리스되어 안정된 API만 씁니다. SAP BTP에서의 사이드 바이 사이드 확장이든, ABAP Cloud를 이용한 시스템 내부 확장이든 마찬가지입니다. 레벨 B는 여전히 클린하다고 보는 클래식 API를 허용하고, 레벨 C는 특별한 조치가 필요하며, 레벨 D는 클린하지 않습니다.

퍼블릭 에디션은 레벨 A 확장만 허용합니다. 프라이빗 에디션과 온프레미스는 클래식 확장을 허용하므로, 그곳에서의 규율은 플랫폼의 차단이 아니라 거버넌스에서 나옵니다. Explore에서 모든 확장의 레벨과 위치를 정하고, 안 된다고 말할 수 있는 사람을 지정하십시오.

딜리버리 팀 안의 AI

Joule은 이제 SAP Activate Roadmap Viewer와 SAP Cloud ALM 안에 들어가 있으며, 작업에 관한 질문에 답하고 방법론을 바탕으로 콘텐츠 초안을 씁니다. 2024년부터 정식 제공된 SAP Build Code는 Joule을 사용해 SAP BTP의 Java 및 JavaScript 확장을 위한 애플리케이션 로직, 데이터 모델, 테스트를 생성합니다. SAP는 ABAP 개발자를 위한 비슷한 생성형 AI 지원도 추가했습니다.

제 견해는 이렇습니다. SAP 프로그램에서 AI는 실재하지만, 가치를 결정하는 것은 데이터 품질입니다. 깨끗한 프로세스 문서와 깨끗한 마스터 데이터는 쓸모 있는 결과를 내고, 더러운 데이터는 자신만만한 소음을 냅니다. 그 어느 것도 각 결정을 책임지는 사람의 필요를 없애 주지는 않습니다.

단계는 여전히 유효하고, 작업 순서도 여전히 중요합니다. 에디션 결정, 확장 규율, 새 도구를 킥오프 때 받아들인 프로그램은 이것들을 설계 제약 조건으로 다룹니다. 이를 무시한 프로그램은 처음 3개월을 무엇이 바뀌었는지 알아내는 데 쓰며, 대개 파트너의 변경 요청을 통해 알게 됩니다.

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

SAP 구축이란 쉽게 말해 무엇인가요?

재무, 구매, 영업, 인사 같은 기업의 핵심 프로세스를 하나의 시스템과 하나의 데이터 모델에서 운영하도록 SAP 소프트웨어를 구축하는 프로젝트입니다. 프로세스 설계, 설정, 데이터 마이그레이션, 테스트, 교육, Go-Live를 포함하며, 보통 SAP의 Activate 방법론을 따릅니다.

SAP 구축 5단계는 무엇인가요?

5단계는 SAP의 이전 ASAP 방법론에서 나왔습니다. 프로젝트 준비, 비즈니스 블루프린트, 실현, 최종 준비, Go-Live와 지원입니다. SAP Activate는 ASAP을 대체했으며, 맨 앞에 Discover, 맨 끝에 Run을 더한 6단계를 씁니다.

SAP Activate의 6단계는 무엇인가요?

Discover(사업 타당성과 적합성), Prepare(팀, 거버넌스, 계획), Explore(Fit-to-Standard 워크숍과 백로그), Realize(설정, 확장, 마이그레이션, 테스트), Deploy(교육, 컷오버 리허설, Go-Live), Run(하이퍼케어와 Centre of Excellence로의 인계)입니다.

SAP 구축과 SAP 마이그레이션은 어떻게 다른가요?

구축은 SAP를 새로 들이는 것으로, 보통 SAP가 아닌 시스템이나 레거시 시스템을 대체합니다. 마이그레이션은 기존 SAP ECC 시스템을 S/4HANA로 옮기는 것으로, 시스템 전환(브라운필드), 신규 구축(그린필드), 선택적 데이터 전환 중 하나로 진행합니다. 둘 다 SAP Activate의 단계를 따릅니다.

SAP 구축 팀에는 누가 있어야 하나요?

경영진 스폰서, 프로그램 디렉터, 영역별 프로세스 오너, 솔루션 아키텍트, 기능 리드와 기술 리드, 데이터 마이그레이션 리드, 변화관리 및 교육 리드, 컷오버 매니저입니다. 스폰서, 프로세스 오너, 데이터 리드는 파트너가 아니라 귀사 쪽에서 나와야 합니다.

SAP 구축이 실패하는 가장 흔한 이유는 무엇인가요?

문제가 생긴 프로그램에는 거의 언제나 세 가지 근본 원인이 있습니다. 프로세스 작업을 건너뛰고, 데이터 품질을 컷오버 때까지 방치하고, 변화관리를 교육으로만 취급합니다.

새로운 원인도 하나 있습니다. Clean Core 계획 없이 확장을 만드는 파트너입니다. 그것은 부채로 남아 첫 번째 대규모 업그레이드 때 드러납니다.

적합한 SAP 구축 파트너는 어떻게 고르나요?

귀사와 비슷한 규모에서의 업계 경험이 있고, 실제로 전화해 볼 수 있는 레퍼런스가 있는 곳을 찾으십시오. 제안 자리에 나온 사람이 프로그램을 이끌어야 합니다. SAP BTP와 ABAP Cloud 확장을 몇 개나 만들었는지 묻고, 직접 보여 달라고 하십시오.

RISE with SAP는 무엇이며 우리 조직에 맞을까요?

RISE with SAP는 SAP Cloud ERP Private을 위한 SAP의 구독 패키지입니다. 소프트웨어, SAP가 관리하는 인프라와 운영, 그리고 프로세스 분석, 아키텍처, 수명주기 관리를 위한 도구 세트가 포함됩니다. 구축 자체는 여전히 파트너가 수행합니다.

ECC에서 옮겨 가면서 플랫폼과 운영을 SAP와의 계약 하나로 묶고 싶은 대규모 조직에 맞습니다. 표준에 가깝게 운영할 수 있는 중견기업이라면 퍼블릭 에디션의 GROW with SAP를 살펴보십시오.