피해야 할 ERP 현대화 실수 10가지

가장 아픈 ERP 현대화 실수는 기술적인 것이 아니라 전략적인 것입니다. Go-Live를 결승선으로 여기고, 레거시 프로세스를 새 시스템에 복사하고, 데이터와 변화 관리 작업을 너무 늦게 시작하고, 모든 것을 ERP 안에 구축하고, 5년짜리 모델 없이 라이선스에 서명하는 것입니다. 이런 실수는 실시간으로 드러나는 일이 드뭅니다. 약속한 효율은 나오지 않고 우회 방법이 돌아오는 Go-Live 이후에 드러납니다.

이 글은 S/4HANA 또는 다른 ERP 현대화를 계획하거나 되살리려는 CIO, CFO, 프로그램 디렉터를 위한 것입니다. 아래 실수마다 실제로 어떤 모습인지와 해법을 담았고, 이어서 한 페이지짜리 조기 경고 체크리스트와 2026년 SAP 변화가 의미하는 바를 다룹니다.

저는 자금이 넉넉하고 경험 많은 팀과 든든한 자문단까지 갖춘 프로젝트가 그래도 기대에 못 미치는 것을 지켜보았습니다. 원인은 시스템인 경우가 드뭅니다. 서로 의존하는 결정을 내리는 팀들 사이의 책임 소재, 연동 계획, 소통의 공백입니다.

1. Go-Live를 결승선으로 여긴다

시스템이 가동되면 많은 팀은 힘든 일이 끝났다고 가정합니다. 그때부터 진짜 압박이 시작됩니다. 일상 업무, 달라지는 요구사항, 실제 사용자 행동이 설계를 밀어붙입니다.

저는 Go-Live 직후에 운영위원회가 해산하는 프로젝트를 본 적이 있습니다. 6개월 뒤 활용도는 제자리이고 백로그를 책임지는 사람은 아무도 없습니다.

해법: Go-Live 후 6~12개월의 거버넌스 기간에 예산을 배정하십시오. 운영위원회의 위임 기간을 연장하십시오. 가동 시간만이 아니라 프로세스 활용도를 모니터링하십시오. 지정된 책임자와 함께 Go-Live 후 품질 게이트를 설정하십시오.

2. 레거시 프로세스를 다시 생각하지 않고 옮긴다

관련된 사람의 절반이 현재 프로세스와 무관한데도 승인 체인 전체가 그대로 재구축되는 것을 본 적이 있습니다. 그 단계가 아직 필요한지 아무도 묻지 않았습니다. 그 결과는 낡은 워크플로를 돌리는 현대적인 ERP, 즉 이미 갖고 있던 것의 더 비싼 버전이었습니다.

S/4HANA에서 나타나는 형태는 이렇습니다. 더 이상 존재하지 않는 테이블 구조를 바탕으로 만든 커스텀 배치 잡을 ECC에서 그대로 옮깁니다. 마이그레이션은 기술적으로 깔끔합니다. 비즈니스 로직은 깨집니다.

해법: 구축 전에 프로세스를 재설계하십시오. 운영, 재무, 딜리버리 팀이 함께 각 워크플로를 짚어 가며 모든 단계에 의문을 제기하십시오.

레거시 영역	흔히 잘못되는 점	대신 해야 할 일
ECC의 커스텀 코드	쓰지 않는 커스텀 코드를 S/4HANA로 이전	사용 분석과 SAP의 커스텀 코드 점검을 실행하고, 쓰지 않는 코드는 폐기
오래된 워크플로	이제 자동화가 가능한데도 승인 플로를 재구축	현업 오너와 다시 검토하고, 표준 Fiori 앱이나 SAP Build Process Automation 활용
비표준 마스터 데이터	유연한 레거시 설정이 S/4HANA 검증을 통과하지 못함	마이그레이션 전에 정제하고 표준화하며, 적합한 곳에는 SAP MDG 활용
레거시 테이블 기반 리포트	직접 테이블 접근이 S/4HANA 데이터 모델과 맞지 않음	CDS 뷰 기반으로 재구축
숨은 수작업 우회 방법	Go-Live 후 사이드 프로세스가 다시 등장	마이그레이션 전에 프로세스 마이닝을 사용하고 빈틈을 디지털화

3. 데이터 마이그레이션을 너무 늦게 시작한다

나쁜 데이터를 새 ERP로 옮기는 것은 아무것도 버리지 않고 이사하는 것과 같습니다. 잡동사니가 함께 따라오고, 일단 구조화된 시스템 안에 들어가면 치우기가 더 어렵습니다.

저는 핵심 데이터셋에 서로 다른 코딩 로직을 쓰는 다섯 개 사업부의 항목이 섞여 있다는 것을 아무도 잡아내지 못해 Go-Live가 실패하는 것을 본 적이 있습니다. 기술적인 마이그레이션은 맞았습니다. 데이터를 쓸 수 없었습니다. 리포트가 깨지고, 사용자는 신뢰를 잃었고, 가동 중인 시스템에서의 정리에는 몇 달이 걸렸습니다.

해법: 데이터를 비즈니스가 책임지는 워크스트림으로 만드십시오. 기술 컨설턴트만이 아니라 프로세스 오너를 지정하십시오. 마이그레이션이 시작되기 전에 무엇을 가져오고, 아카이브하고, 새로 만들지 결정하십시오. 로드 순서에 대한 의존성 맵과 로드별 롤백 방안을 갖추고, 전체 모의 로드를 최소 두 번 수행하십시오. 제 글 SAP 데이터 마이그레이션이 실패하는 이유가 더 깊이 다룹니다.

4. 변화 관리를 부수적인 일로 취급한다

흔한 모습은 이렇습니다. 변화 관리는 ‘이미 처리됐다’고 합니다. 슬라이드 몇 장, 데모, Go-Live 전 교육 한 번을 뜻합니다.

사람들은 변화가 싫어서 반발하는 것이 아닙니다. 왜 바뀌는지, 자신에게 어떤 도움이 되는지 아무도 설명해 주지 않을 때 반발합니다. 체크리스트를 통과할 만큼만 시스템을 따르다가, 다시 스프레드시트로 돌아갑니다.

흔한 계기는 일정 압박입니다. 시간을 만회하려고 교육을 압축하고, Go-Live에서 사용자는 감당하지 못하고, 줄여 버린 교육보다 추가 하이퍼케어 비용이 더 듭니다.

해법: 변화 관리에 처음부터 자체 예산, 일정, 시니어 책임자를 부여하십시오. 역할을 일찍 매핑하고, 현장 챔피언을 찾고, 기술 마일스톤과 함께 활용도 KPI를 추적하십시오. 제 변화 관리 계획 가이드가 그 구조를 설명합니다.

5. 벤더 로드맵에 맞춰 계획한다

벤더의 향후 릴리스를 기준으로 연동 전략을 세웠다가, 그 릴리스가 12개월 뒤로 밀리는 것을 본 팀들이 있습니다. 그동안 임시 우회 방법을 만들며 버텼고, 그 우회 방법은 영구적인 것이 되었습니다.

벤더는 폭넓은 고객군을 위해 로드맵을 만듭니다. 귀사의 비즈니스가 그 설계의 중심인 경우는 드뭅니다.

해법: 로드맵은 여러 입력 중 하나로 다루십시오. 현재 정식 출시된 것을 기준으로 설계하고, 새 기능은 계획에 넣기 전에 샌드박스에서 테스트하고, 로드맵의 이점은 예산이 아니라 추가 이득으로 계산하십시오.

6. 레거시 시스템의 폐기 계획이 없다

저는 1년에 두 번 리포트를 뽑아야 하는 사용자 여섯 명을 위해 오래된 시스템을 돌리는 데 매년 여섯 자릿수 금액을 쓰는 회사를 본 적이 있습니다. 아무도 폐기 계획을 세우지 않았습니다.

해법: 첫날부터 프로젝트 헌장에 폐기를 넣고, IT만이 아니라 법무, 컴플라이언스, 데이터 거버넌스도 참여시키십시오. Go-Live 전에 보관 기간과 아카이브 방식을 합의하고, 구 시스템으로 가는 모든 인터페이스를 매핑해 차단하고, 한 팀에 그것을 끄는 임무를 맡기십시오.

7. 연동의 복잡성을 과소평가한다

연동이 실패하면 IT보다 비즈니스가 먼저 알아챕니다. 테스트 시스템이 아니라 운영 환경에서 워크플로가 프로세스 도중에 멈추기 때문입니다.

흔한 패턴은 이렇습니다. IT와 비즈니스가 서로 상대가 연동 요구사항을 정의했다고 가정합니다. 어느 쪽도 하지 않았습니다. 테스트에서 공백이 드러날 때쯤에는 재설계할 시간이 없습니다.

해법: 블루프린트 단계에서 연동 설계를 시작하십시오. 시나리오별로 미들웨어, 매핑, 메시지 물량을 정의하고, 인터페이스별로 실시간인지 배치인지를 비즈니스와 명확히 하십시오. Go-Live 전에 SLA를 가진 인터페이스 책임자를 지정하십시오. 새로운 SAP 프로그램에서 미들웨어는 SAP Integration Suite입니다. SAP PI/PO는 2027년 말에 표준 유지보수가 끝납니다.

8. ERP가 모든 것을 처리할 수 있다고 가정한다

ServiceNow 같은 외부 시스템을 끌어들이고 싶지 않다는 이유로, 팀들이 복잡한 서비스 워크플로(IT 티켓, 자산 요청, 에스컬레이션 라우팅)를 ERP에 억지로 밀어 넣은 프로젝트에서 일한 적이 있습니다. 그 결과는 곳곳의 커스텀 필드, 수작업 우회, 맞지 않는 프로세스에 갇힌 사용자였습니다.

ERP는 구조화되고, 트랜잭션 중심이며, 재무에 뿌리를 둔 프로세스에 강합니다. IT 서비스 요청, 워크플로 오케스트레이션, 지식 관리는 전용 플랫폼이 더 잘합니다.

해법: ERP에서 무엇을 만들지 않을지 의도적으로 정하십시오. 예외 처리에는 SAP BTP의 사이드 바이 사이드 확장을, 트랜잭션 핵심 밖의 오케스트레이션에는 ServiceNow 같은 도구를 쓰십시오. 제 글 SAP와 ServiceNow로 하는 ERP 현대화가 그 구분을 다룹니다.

9. 장기 라이선스 비용을 과소평가한다

상위 등급 라이선스 뒤에 있는 기능 하나가 필요해서 2년차에 라이선스 비용이 두 배가 된 팀을 알고 있습니다. 비즈니스 케이스는 Go-Live 비용만 모델링한 것이었습니다.

ERP 라이선스는 사용자, 모듈, 트랜잭션, API 사용량에 따라 과금되며, 계획했든 아니든 비즈니스가 커지면 비용도 커집니다. SAP에서는 Digital Access 모델 때문에 서드파티 시스템이 만든 문서에 원래 상업 모델에 없던 라이선스 비용이 붙을 수 있습니다. RISE와 SAP GROW에서는 도입이 늘수록 Full User Equivalent(FUE) 수가 증가합니다.

해법: 서명하기 전에 3~5년짜리 라이선스 모델을 만드십시오. 롤을 라이선스 유형에 매핑하고, 현실적인 도입 곡선으로 FUE 증가를 모델링하고, 외부 시스템을 연결하기 전에 간접 접근을 이해하고, Go-Live 후에는 비활성 사용자를 감사하십시오.

10. ERP를 IT 프로젝트로 취급한다

가장 흔하면서 가장 해로운 패턴입니다. 계획이 IT에서 시작되고, IT가 이끌고, IT의 문제를 풉니다.

서류상으로는 모든 마일스톤을 달성하는데도 비즈니스는 왜 아무것도 나아진 느낌이 없느냐고 묻는 팀을 본 적이 있습니다. 대개는 운영, 재무, 영업 리더가 설계에 참여하지 않은 채 ERP를 어제의 프로세스에 맞춰 구축했다는 뜻입니다.

해법: 처음부터 영업, 재무, 운영 리더를 운영위원회에 넣으십시오. 기술 범위만이 아니라 전략적 정합성을 헌장에 명시하십시오. 설계가 시작되기 전에 프로그램의 목표를 이사회 수준의 성과와 대조해 시험하십시오.

운영위원회마다 사용하십시오. 경고 신호가 보이면, 사라질 때까지 지정된 책임자가 이에 대해 보고합니다.

1. 헌장책임과 비용운영이나 재무 리더 없음, 5년 라이선스 모델 없음, 폐기 일정 없음
2. 블루프린트프로세스와 연동 설계오늘의 프로세스를 복사, 인터페이스는 아직 미설계
3. 첫 모의 로드데이터아직 데이터 품질 리포트 없음
4. Go-Live그다음에 일어나는 일이후 12개월 동안 예산이 확보된 거버넌스 없음

실수	조기 경고 신호	책임자
1. Go-Live를 결승선으로 여김	Go-Live 후 12개월에 대한 예산 확보된 거버넌스 계획 없음	스폰서
2. 복사한 레거시 프로세스	설계 워크숍이 ‘지금 우리가 하는 방식’ 화면에서 시작	프로세스 오너
3. 늦은 데이터 작업	첫 모의 로드 전에 데이터 품질 리포트 없음	데이터 마이그레이션 리드
4. 부수 업무가 된 변화 관리	변화 계획이 교육 일정표에 불과	변화 관리 리드
5. 로드맵 의존	설계 결정이 아직 출시되지 않은 기능을 기다림	솔루션 아키텍트
6. 폐기 계획 없음	헌장에 어떤 레거시 시스템의 폐기 일정도 없음	PMO
7. 과소평가된 연동	블루프린트 종료 시점까지 인터페이스 미설계	연동 리드
8. 모든 것을 ERP로	트랜잭션이 아닌 워크플로를 위한 커스텀 오브젝트	엔터프라이즈 아키텍트
9. 라이선스	비즈니스 케이스에 5년 라이선스 모델 없음	CFO
10. IT만의 프로그램	운영위원회에 운영이나 재무 리더 없음	스폰서

배포. 새로운 SAP 프로그램의 기본값은 SAP Cloud ERP Private 위의 RISE with SAP, 또는 중견 기업을 위한 퍼블릭 에디션(SAP Cloud ERP) 위의 SAP GROW입니다. 신규 온프레미스 배포는 드뭅니다. ECC 고객은 2027년 12월 31일에 종료되는 표준 유지보수에 직면해 있으며, 이는 실수 2, 3, 7을 바로잡을 시간을 줄입니다.

클린 코어. SAP는 이제 확장을 네 가지 클린 코어 레벨로 등급화합니다. 레벨 A(릴리스된 API만 사용, BTP에서 사이드 바이 사이드 또는 ABAP Cloud로 시스템 내부)에서 레벨 D(클린하지 않음)까지입니다. 퍼블릭 에디션은 레벨 A만 허용하므로 실수 2의 이면에 있는 논의가 불가피해집니다. 프라이빗 에디션은 여전히 클래식 확장을 허용하므로, 규율은 거버넌스에서 나와야 합니다. 클래식 커스텀 코드가 모든 업그레이드를 프로젝트로 만듭니다. 제 클린 코어 전략 글이 더 깊이 다룹니다.

딜리버리 도구의 AI. Joule은 이제 SAP Cloud ALM과 SAP Activate Roadmap Viewer 안에 들어와 있고, SAP Build Code는 확장 개발에 Joule을 씁니다. 파트너에게 AI 도구가 요율표에 어떻게 반영되는지 물어보십시오. 반영되지 않았다면, 가격이 높거나 절감분이 파트너의 마진으로 가고 있는 것입니다.

라이프사이클 도구. SAP Cloud ALM은 클라우드 프로그램을 위한 라이프사이클 관리 도구입니다. Solution Manager 7.2는 2027년 말에 표준 유지보수가 끝나므로, 둘을 함께 쓰는 환경은 이전 계획이 필요합니다.

열 가지 실수는 달라지지 않았습니다. 잘못했을 때의 비용이 달라졌습니다. RISE 프로그램에서는 클린 코어 결정, 배포 모델, FUE 모델이 모두 프로젝트 착수 첫 몇 주 안에 정해집니다. 그것에 영향을 줄 수 있는 시간은 짧습니다.

ERP 현대화는 왜 Go-Live 이후에 기대에 못 미칩니까?

대부분의 팀은 Go-Live까지만 계획하고 멈춥니다. 개선, 피드백, 프로세스 보정, 백로그를 책임지는 사람이 없습니다. Go-Live와 함께 운영위원회가 해산하는 것이 문제의 가장 확실한 신호입니다. 첫날부터 Go-Live 후 6~12개월의 거버넌스에 예산을 배정하십시오.

레거시 프로세스를 새 ERP로 복사하면 어떤 위험이 있습니까?

새 시스템이 더 높은 비용으로 낡은 비효율을 물려받습니다. 특히 S/4HANA 마이그레이션에서는 ECC 테이블을 기준으로 만든 커스텀 코드와 배치 잡이 작동하지 않는 경우가 많아, 마이그레이션은 기술적으로 깔끔한데 비즈니스 로직은 깨질 수 있습니다.

데이터 품질이 낮으면 ERP 현대화에 어떤 피해가 생깁니까?

중복 공급업체, 일관되지 않은 마스터 데이터, 레거시 코드, 불완전한 레코드는 누군가 먼저 정리하지 않으면 모두 새 시스템으로 넘어갑니다. 리포트가 깨지고, 사용자는 숫자를 신뢰하지 않게 되고, 가동 중인 시스템에서의 정리에는 몇 달이 걸립니다.

ERP 프로젝트에서 변화 관리는 왜 그렇게 자주 과소평가됩니까?

구성과 달리 프로젝트 계획에 눈에 띄지 않기 때문입니다. 경영진은 교육 몇 번이면 충분하다고 가정합니다. 변화 관리는 Go-Live 전에, 일상 업무에서 실제로 무엇이 바뀌는지 사람들을 준비시키는 일입니다. 현재 SAP 소유인 WalkMe 같은 디지털 도입 도구가 앱 내 안내에는 도움이 되지만, 왜 바뀌는지에 대한 설명을 대체하지는 못합니다.

ERP Go-Live 이후에도 레거시 시스템이 몇 년씩 계속 돌아가는 이유는 무엇입니까?

아무도 종료할 계획을 세우지 않았기 때문입니다. 모두가 새 ERP를 가동하는 데 집중하고, 오래된 시스템은 컴플라이언스, 참조, 안심을 이유로 남습니다. 폐기는 첫날부터 범위에 있어야 하며, 법무와 컴플라이언스가 참여해야 합니다.

RISE with SAP와 클린 코어는 이 실수들을 어떻게 바꿉니까?

퍼블릭 에디션에서는 클린 코어 규칙 때문에 깊은 커스터마이징이 불가능하므로, 실수 2 뒤에 있는 프로세스 논의가 불가피해집니다. 프라이빗 에디션에서는 클래식 확장이 여전히 허용되므로 클린 코어는 거버넌스에 달려 있습니다. PI/PO 유지보수가 끝나면서 연동은 SAP Integration Suite로 옮겨 갑니다. 라이선스는 FUE 증가의 문제가 됩니다. 수년짜리 구독 위에 레거시 시스템 병행 운영 비용이 더해지므로 폐기는 더 시급해집니다.