SAP 구축이란 무엇인가? 단계별 가이드

SAP 구축은 기업의 재무, 구매, 공급망, 영업, HR을 하나의 SAP 시스템, 보통은 S/4HANA 위로 옮기는 프로젝트입니다. SAP의 Activate 방법론에 따라 6단계로 진행되며, 성패는 누군가 구성을 시작하기 전에 해 둔 일에서 갈립니다. 프로세스 설계, 데이터 품질, 그리고 적합한 팀입니다.

이 가이드는 구축을 막 시작하려는 경영진과 프로젝트 리드를 위한 글입니다. 각 단계의 내용, 각 단계가 만들어 내야 하는 산출물, 먼저 해야 하는 계획, 지금 시작하는 프로젝트에서 달라진 점을 차례로 다룹니다. 한 섹션만 읽으신다면 '구성을 시작하기 전의 계획'을 읽으십시오.

ERP를 구축해 온 25년 동안 같은 패턴을 거듭 봤습니다. 구축을 소프트웨어 설치로 여기는 기업은 고전합니다. 프로세스 작업을 먼저 하고 시스템을 마지막 단계로 여기는 기업은 일정대로 끝내고, 이사회에 약속한 성과를 얻습니다.

S/4HANA는 SAP의 현재 ERP이며 SAP HANA 인메모리 데이터베이스에서 실행됩니다. 기존 ECC 시스템을 여전히 운영하는 기업도 많지만, ECC 표준 유지보수는 2027년 12월 31일에 종료되며 더 높은 비용으로 2030년 말까지 선택적 연장 유지보수를 받을 수 있습니다.

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

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

대부분의 기업은 FI/CO와 한두 개의 운영 모듈에서 시작합니다. 나머지는 이후 단계에서 확장합니다.

SAP Activate는 이전의 ASAP 방법론을 대체했습니다. 6단계로 구성되며, 각 단계에는 통과해야 다음으로 넘어갈 수 있는 관문이 있습니다.

SAP Activate의 6단계

1. 01

   Discover

   비즈니스 케이스를 확정하고 우선순위 프로세스를 트라이얼 또는 데모 시스템에서 검증합니다.

2. 02

   Prepare

   착수 단계입니다. 팀, 거버넌스, 범위 문서, 계획, 시스템 접근 권한을 갖춥니다.

3. 03

   Explore

   프로세스 오너와 함께 Fit-to-Standard 워크숍을 진행합니다. 구성, 통합, 확장의 백로그를 만듭니다.

4. 04

   Realize

   구성, 확장, 데이터 이관, 테스트를 수행합니다. 가장 긴 단계입니다. 종료하려면 회귀 테스트를 깨끗하게 통과해야 합니다.

5. 05

   Deploy

   실제 프로세스로 사용자를 교육하고, 전환(cutover)을 리허설하고, 워룸을 갖춘 채 가동합니다.

6. 06

   Run

   하이퍼케어, 최적화, 그리고 Center of Excellence로의 인계입니다.

아래 표는 제가 프로젝트 사무실 벽에 붙여 두는 버전입니다. 각 단계가 무엇을 만들어 내야 하는지, 누가 책임지는지, 다음 단계가 시작되기 전에 무엇이 충족되어 있어야 하는지를 담았습니다.

단계	산출물	담당	통과 기준
Discover	비즈니스 케이스, 목표 범위, 도입 방식 결정	스폰서와 CFO	예산 승인
Prepare	범위 문서, 계획, 거버넌스, 구성된 팀	프로젝트 디렉터	스폰서의 범위 서명
Explore	Fit-to-Standard 결과, 백로그, 확장 결정	프로세스 오너와 함께하는 솔루션 아키텍트	미해결 갭 없음
Realize	구성하고 테스트한 시스템, 이관된 테스트 데이터	기능 및 기술 리드	회귀 테스트를 깨끗하게 통과, 데이터 정합성 일치
Deploy	교육을 마친 사용자, 리허설한 전환, 가동 승인(go/no-go) 자료	전환 관리자	3일 마감 리허설 통과
Run	하이퍼케어 로그, CoE 인계, 2단계 백로그	서비스 딜리버리 리드	미해결 P1/P2 없음, CoE 인수

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

3일 마감 리허설 관문

Realize와 Deploy 사이의 관문은 일정 압박 속에서 팀이 가장 자주 건너뛰는 관문입니다. 저는 실제 가동 전에 3일간의 마감 리허설을 실행하라고 권합니다. 재무팀이 새 시스템에서 장부를 마감하지 못한다면, IT가 뭐라고 하든 데이터 이관은 준비되지 않은 것입니다. 그 관문을 건너뛰어서 치르는 비용은, 관문 때문에 생겼을 지연보다 큽니다.

순서가 중요합니다. 구성 결정을 하나라도 내리기 전에 네 가지를 끝내야 합니다.

1. 01현행 프로세스 매핑우회 방법까지 포함해 실제로 돌아가는 그대로
2. 02표준 또는 확장 결정표준이 거의 언제나 더 빠릅니다
3. 03데이터 품질 감사데이터 이관이 시작되기 전에
4. 04팀 구성 후 범위 확정누가 가용한지가 무엇을 만들어 낼 수 있는지를 정합니다

이제야 구성이 시작됩니다

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

프로세스가 이래야 한다고 정해진 모습이 아닙니다. 우회 방법까지 포함해 실제로 돌아가는 모습입니다. 아무도 적어 두지 않은 요구사항은 그 우회 방법 속에 숨어 있습니다.

프로세스별로 표준과 확장 중 무엇을 쓸지 결정하기

SAP 표준 기능이 어떤 프로세스를 커버하고 어떤 프로세스에 확장이 필요한지 식별하십시오. 표준이 거의 언제나 더 빠릅니다. 확장이 하나 늘 때마다 테스트 사이클, 업그레이드 리스크, 유지보수 부담이 따라붙습니다. SAP의 Clean Core 가이드라인에서는 모든 확장을 의도한 위치에 배치해야 하므로, 이 결정은 더 가벼워지는 것이 아니라 더 무거워집니다.

데이터 이관이 시작되기 전에 데이터 품질 감사하기

가장 과소평가되는 워크스트림입니다. 오래된 고객 레코드를 검증 없이 올린 탓에 몇 달씩 보고서를 고치는 기업을 봤습니다. 한 고객사는 중복된 고객 레코드가 18,000건이 넘었고, 가동 후에 이를 바로잡는 동안 청구 업무가 몇 주 동안 흔들렸습니다.

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

만들어 낼 수 있는 범위는 각 워크스트림을 구성하고, 테스트하고, 책임질 사람이 누구인지에 달려 있습니다. 범위를 먼저 정하고 인력을 나중에 구하는 팀은 과하게 약속한 것을 다시 만드는 데 몇 달을 씁니다.

과제	어떤 모습인지	대응 방법
범위 확대(scope creep)	'이왕 건드린 김에 이것도 추가해 주세요' 요청이 쌓임	첫날부터 공식 변경 통제를 운영하고, 모든 요청에 영향도 평가를 거침
데이터 품질	이관 과정에서 아무도 몰랐던 불일치가 드러남	가동 6개월 전에 데이터를 프로파일링하고, 원천 시스템에서 정제
사용자 저항	가동 후 2주 안에 사용자가 Excel로 돌아감	Explore 단계부터 최종 사용자를 설계에 참여시킴. 교육만이 아니라 참여가 필요
통합 실패	UAT에서 서드파티 연동이 깨짐	Explore에서 인터페이스를 매핑하고, 현실적인 데이터 볼륨으로 일찍 테스트
테스트 사이클 축소	일정을 맞추려고 회귀 테스트를 단축	테스트 단계를 지킬 것. 구축 지연이 테스트를 압박하게 두지 않음
팀 피로	막바지에 사기가 떨어지고 결함률이 오름	주간 사기 지수로 피로도를 추적. 제 경험상 이 값이 25%를 넘으면 테스트 결함률이 급증

한 회사가 일정을 앞당기려고 작은 회귀 테스트를 건너뛴 사례가 기억납니다. 일주일 뒤 재무팀은 핵심 보고서를 대조하지 못했습니다. 몇 달에 걸친 정리 작업이 이어졌습니다. 시스템의 중대한 결함이 아니라, 피할 수 있었던 소홀함 때문이었습니다.

가동 전, 가동 중, 가동 후

가동 전: 마감 리허설을 실행하고, 정합성 보고서로 이관 데이터를 검증하고, 데모 시나리오가 아니라 실제 프로세스로 교육하고, 롤백 계획을 테스트하십시오. 운영위원회에 가동 승인(go/no-go) 기준을 설명하고, 고개만 끄덕이는 암묵적 동의가 아니라 명시적인 승인을 받으십시오.

가동 중: 모니터링을 강화하고, 처음 72시간 동안 전환 팀이 24시간 대기하도록 유지하십시오. 그 시간 동안 내리는 결정이 하이퍼케어를 자신 있게 시작할지, 쌓인 문의로 시작할지를 가릅니다.

가동 후: 하이퍼케어를 최소 4주간 운영하십시오. 지원 티켓을 카테고리별로 추적하십시오. 교육이 어디서 실패했고 구성을 어디서 조정해야 하는지를 티켓이 알려 줍니다. 안정된 기준선에서 2단계를 계획하십시오. 18개월 전에 미뤄 둔 범위는 지금 비즈니스에 필요한 것과 다시 대조해야 합니다.

한 중견 제조업체는 원자재가 계속 바닥났습니다. 구매 부서는 플래너를 탓했고, 플래너는 아무도 믿지 않는 스프레드시트를 탓했습니다. 저희는 그 구조를 S/4HANA로 바꾸고, 제대로 된 MRP 구성을 갖춘 SAP PP에 크게 의존했습니다. 재고 수준은 추측에서 실시간 데이터로 바뀌었고, 구매 오더는 필요에 따라 발생했으며, 6개월 뒤 부족 사태는 50% 넘게 줄었습니다. 회의적이던 사람들조차 놀랐습니다. 이 결과는 구성에 앞서 진행한 프로세스 재설계에서 나왔습니다. 프로세스 작업 없는 PP는 틀린 답을 더 빨리 내놓았을 뿐일 것입니다. 재무도 이득을 봤습니다. 월 마감이 빨라졌고, CFO는 오랜만에 처음으로 숫자가 '믿을 만하게 느껴진다'고 말했습니다.

한 글로벌 전문 서비스 기업은 문제가 달랐습니다. 국가마다 자체 재무 플랫폼을 운영했고, 아무것도 대조되지 않았으며, 보고서는 매달 수작업으로 다시 만들어졌습니다. 저희는 적극적으로 관여하는 운영위원회 아래에서 SAP Finance를 단계적으로 도입했습니다. 월 마감은 두 주 넘게 걸리던 것이 한 주 남짓으로 줄었고, 지역별 보고서가 마침내 서로 일치했으며, 감사인들의 우려도 줄었습니다.

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을 포함한 전환 툴체인과 함께 패키지로 제공합니다. SAP GROW는 퍼블릭 에디션을 쓰는 중견기업을 위한 패키지입니다.

에디션 결정이 이제 예전의 롤아웃 논쟁보다 위에 놓입니다. 빅뱅 대 단계적 전환, 그리고 그린필드 대 브라운필드 대 선택적 전환은 에디션을 대체하는 선택이 아니라 에디션 안에서 하는 선택입니다. 아직 ECC를 쓰고 있고 시간이 더 필요하다면, SAP는 2031년부터 2033년까지 ERP 프라이빗 에디션 전환 옵션을 판매하지만, SAP 스스로 이는 유상 전환 제안이지 유지보수 연장이 아니라고 분명히 밝힙니다.

Clean Core는 이분법이 아니라 등급제

2025년 8월 SAP는 A부터 D까지 네 가지 Clean Core 레벨을 도입했습니다. 레벨 A는 릴리스된 안정적인 API만 사용하며, SAP BTP에서의 사이드바이사이드 방식이든 ABAP Cloud를 이용한 시스템 내부 방식이든 상관없습니다. 레벨 B는 여전히 클린한 것으로 간주되는 기존 API와 기술을 허용합니다. 레벨 C는 별도의 조치가 필요합니다. 레벨 D는 클린하지 않습니다.

퍼블릭 에디션은 레벨 A 확장만 허용합니다. 프라이빗 에디션과 온프레미스는 기존 방식의 확장을 허용하므로, 그 환경에서의 규율은 플랫폼이 막아 주는 것이 아니라 거버넌스에서 나옵니다. 프로젝트에 적용할 실무 포인트는 이렇습니다. Explore 단계에서 모든 확장의 레벨과 위치를 정하고, 안 된다고 말할 수 있는 책임자를 지정하십시오. SAP BTP와 ABAP Cloud 경험이 없는 파트너는 첫 주부터 레벨 C와 D의 부채를 만들어 냅니다.

딜리버리 팀 안의 Joule과 SAP Build Code

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

솔직한 견해는 이렇습니다. SAP 프로젝트에서 AI는 실제로 쓸 만하지만, 그 가치를 결정하는 것은 데이터 품질입니다. 정리된 프로세스 문서와 깨끗한 마스터 데이터는 쓸 만한 결과를 냅니다. 지저분한 데이터는 자신만만한 잡음을 냅니다. 어느 것도 각 결정을 책임지는 사람이 필요하다는 사실을 없애 주지는 않습니다.

지금 시작하는 프로젝트에 이것이 의미하는 바

플레이북은 여전히 통합니다. 단계는 그대로 적용되고 작업의 순서도 여전히 중요합니다. 달라진 것은 에디션 결정, 확장에 대한 규율, 팀을 위한 도구입니다. 이를 착수 시점에 흡수하는 프로젝트는 그것을 설계 제약으로 다룹니다. 무시하는 프로젝트는 처음 3개월 동안 무엇이 바뀌었는지를 알아내느라 시간을 쓰는데, 대개 파트너의 변경 요청을 통해서 알게 됩니다.

비용 측면에서 같은 결정들을 보려면 제 SAP 구축 비용 분석을 참고하십시오. 아직 ECC를 사용 중이라면 ECC에서 S/4HANA로의 이관 가이드가 전환 경로를 다룹니다.

SAP는 무엇에 사용합니까?

SAP는 핵심 업무 기능(재무, 구매, 공급망, HR, 영업)을 하나의 시스템, 하나의 데이터 모델에서 운영합니다.

실제로는 입고가 재고를 갱신하고, 매입채무 프로세스를 트리거하고, 재입력 없이 관리 보고로 흘러갑니다. 보고의 정확도는 그 아래 트랜잭션의 정확도만큼만 나오기 때문에, 구성보다 프로세스 설계와 데이터 품질이 더 중요합니다.

SAP 구축에는 얼마나 걸립니까?

일정을 가장 크게 좌우하는 변수는 범위와 팀입니다. 단일 회사에서 FI/CO와 운영 모듈 하나를 다루는 집중형 S/4HANA 구축은 6개월에서 9개월이 걸릴 수 있습니다. 다수의 법인, 모듈, 언어에 걸친 글로벌 롤아웃은 18개월에서 36개월이 걸립니다.

일정을 늘리는 요인은 뒤늦게 발견된 데이터 문제, 일정 조정 없이 추가된 범위, 파트타임으로 채워진 핵심 역할, 앞선 지연을 만회하려고 줄인 테스트 사이클입니다. 모두 계획 단계에서 통제할 수 있습니다.

SAP Activate의 6단계는 무엇입니까?

Discover(비즈니스 케이스와 적합성), Prepare(팀, 거버넌스, 계획), Explore(Fit-to-Standard 워크숍과 백로그), Realize(구성, 확장, 이관, 테스트), Deploy(교육, 전환 리허설, 가동), Run(하이퍼케어와 Center of Excellence로의 인계)입니다.

SAP 구축이 실패하는 가장 흔한 이유는 무엇입니까?

어려움을 겪는 거의 모든 프로젝트에서 세 가지 근본 원인이 나타납니다. 프로세스 작업을 건너뛰어서 망가진 기존 프로세스에 맞춰 SAP를 구성하는 것. 전환 시점까지 데이터 품질을 방치해서 제대로 고칠 시간이 없는 것. 변경 관리를 교육으로 착각하는 것. 교육은 클릭하는 법을 알려 주고, 변경 관리는 사람들이 그렇게 하고 싶게 만듭니다.

네 번째는 비교적 새로운 원인입니다. Clean Core 계획 없이 확장을 만드는 파트너가 첫 대규모 업그레이드 때 드러나는 부채를 남깁니다.

적합한 SAP 구축 파트너는 어떻게 고릅니까?

귀사 규모에서의 업종 경험, 그리고 실제로 연락해 볼 수 있는 레퍼런스입니다. 시니어 인력의 실명 투입입니다. 제안 자리에 나온 사람이 프로젝트를 이끌어야 합니다. 독립성입니다. 라이선스나 구독 판매로 수익을 얻는 파트너는 더 많은 범위를 권하고 싶은 유인이 있습니다. Clean Core 경험입니다. SAP BTP와 ABAP Cloud 확장을 몇 건이나 만들어 봤는지 묻고, 실물을 보여 달라고 하십시오.

규칙이 하나 더 있습니다. 구축을 수행할 파트너가 귀사의 비즈니스 케이스를 써서는 안 됩니다. 그들의 유인은 시작하는 것이고, 귀사의 유인은 끝내는 것입니다.

가동 후에는 무슨 일이 일어납니까?

하이퍼케어는 최소 4주간 운영되며, 전체 팀이 대기하고 미해결 이슈를 매일 검토합니다. 첫 주의 티켓 카테고리는 교육이 어디서 부족했고 구성이 어디서 잘못됐는지를 가장 솔직하게 보여 주는 신호입니다.

하이퍼케어가 끝나면 Center of Excellence가 개선 사항, 업그레이드 계획, 신규 입사자 교육, 변경 거버넌스를 넘겨받습니다. 프로젝트 기간 중에 CoE 구축을 건너뛴 기업은 대개 이후 2년 동안 사내에서 해야 할 일을 컨설턴트에게 비용을 주고 맡기게 됩니다.

RISE with SAP란 무엇이며 우리 조직에 맞습니까?

RISE with SAP는 SAP Cloud ERP Private용 SAP 구독 패키지입니다. 소프트웨어, SAP가 관리하는 인프라와 운영, 프로세스 분석, 아키텍처, 라이프사이클 관리를 위한 툴체인이 포함됩니다. 구축은 여전히 귀사의 파트너가 수행합니다.

ECC에서 벗어나려는 대규모 조직이 플랫폼과 운영에 대해 SAP 계약 하나로 가고 싶을 때 맞습니다. 표준에 가깝게 운영할 수 있는 중견기업은 퍼블릭 에디션의 SAP GROW를 검토해야 합니다. 규제상 고객이 직접 관리하는 인프라가 필요하거나, 과도한 커스텀 코드를 주어진 시간 안에 정리할 수 없는 경우에는 RISE가 덜 맞습니다.