안녕하세요. 아는 형입니다.
“우리 회사는 ECC 잘 쓰고 있는데, 굳이 지금 전환해야 하나요?” 요즘도 현업들과 업무 미팅 자리에서 이 질문, 꽤 자주 받습니다. 결론부터 말씀드리면 “시간이 없다”가 정답에 가깝습니다. 왜 그런지, 그리고 지금 뭘 준비해야 하는지 정리해봤습니다.
2027년, 정확히 무엇이 끝나는가
일단 날짜부터 명확히 짚고 가겠습니다. 저도 처음엔 헷갈렸던 부분인데, 표로 정리하면 이렇습니다.
| 구분 | 종료 시점 | 비고 |
|---|---|---|
| 표준 유지보수 (Mainstream Maintenance) | 2027년 말 | SAP Business Suite 7 / ECC 6.0 대상 |
| 연장 유지보수 (Extended Maintenance) | 2030년 말 | 기존 유지보수 비용에 2%p 추가 |
| Private Edition 전환 옵션 | 2031~2033년 | RISE with SAP 계약 + HANA DB 전제, 일부 대형 고객 한정 |
여기서 중요한 포인트가 하나 있습니다. SAP는 2033년 옵션을 발표하면서도, 이게 2027/2030 데드라인 자체를 연장하는 건 아니라고 못박았습니다. “시간을 좀 더 벌 수 있는 예외적 경로”이지, 일반적인 대안이 아니라는 뜻입니다.
게다가 2033년 옵션은 조건이 꽤 까다롭습니다.
- RISE with SAP 클라우드 구독 계약 필수
- 2030년 말 이전에 HANA DB로 전환 완료 필요
- Java 등 서드파티 구버전 도구 사용 조정 필요
- ECC 중심 옵션이라 Business Suite 7의 여러 구성요소는 제외 — 레거시 애드온·커스텀 컴포넌트 의존도가 높다면 별도 마이그레이션 이슈 발생 가능
정리하면, “어차피 2033년까지 버틸 수 있으니 괜찮다”는 생각은 대부분의 기업에게 해당되지 않습니다.
지금 전환하지 않으면 실제로 벌어지는 일
① 컨설턴트·구축 인력 품귀 현상
2027년이 다가올수록 동시에 전환하려는 기업이 몰리면서, 경험 있는 S/4HANA 컨설턴트 확보가 점점 어려워지고 있습니다. 업계에서는 이 인력난이 데드라인 이후 컨설팅 단가 급등으로 이어질 수 있다는 우려가 나옵니다. 대형 SI 파트너사들은 이미 향후 몇 년치 프로젝트 팀을 선점하고 있는 상황이라, 늦게 움직일수록 원하는 시점에 원하는 품질의 팀을 구성하기 어려워집니다.
실무적으로 체감하는 부분도 비슷합니다. TR/FI처럼 도메인 지식과 시스템 경험이 동시에 필요한 영역은 특히 인력 풀이 좁아서, 프로젝트 착수 시점의 인력 매칭 자체가 일정 리스크로 작동하는 경우를 자주 봅니다.
② 압축된 일정 = 높은 리스크
대규모 ERP 전환은 원래 수년 단위의 계획과 실행이 필요한 작업입니다. 준비 기간이 부족한 상태에서 데드라인에 쫓겨 시작하면, 시스템 오류나 예기치 못한 다운타임 같은 운영 리스크가 커집니다. “일단 데드라인에 맞추는 것”과 “제대로 전환하는 것”은 전혀 다른 이야기입니다.
③ 서드파티 지원 종료에 따른 보안·컴플라이언스 리스크
연장 유지보수 기간(2030년)이 지나면 구버전 Java 등 서드파티 제품에 대한 벤더 지원도 함께 끊깁니다. 재무, 물류, 인사, SCM 등 핵심 업무를 여전히 ECC로 돌리고 있는 조직이라면, 이 시점부터는 운영·컴플라이언스 리스크를 안고 가는 셈입니다.
④ Compatibility Pack 사용권 만료
의외로 놓치기 쉬운 부분인데요, S/4HANA 전환 초기에 후속 기능이 아직 준비되지 않아 ECC 기능을 임시로 가져와 쓸 수 있게 해준 “S/4HANA Compatibility Pack”의 사용권 상당수가 이미 만료됐습니다. 이미 S/4HANA로 전환은 했지만 특정 ECC 기능에 여전히 의존하고 있던 기업이라면, 별도로 확인이 필요한 부분입니다.
실제로 기업들은 지금 어떻게 움직이고 있나
데드라인 얘기만 들으면 막연한 위기감만 남기 쉬우니, 실제 업계가 어느 방향으로 움직이고 있는지 짚어보겠습니다.
① 아직 절반도 못 넘었다
Gartner 조사에 따르면 ECC 고객 중 S/4HANA 라이선스를 확보한 비율은 아직 30%대에 머물러 있습니다. “다들 아직 안 했으니 우리도 여유 있다”로 읽으면 안 됩니다. 오히려 남은 1~2년 사이에 나머지 기업들이 한꺼번에 몰려서 전환에 나선다는 뜻이고, 이는 앞서 말씀드린 컨설턴트 품귀 현상을 더 심화시키는 요인입니다.
② “전면 재구축”에서 “선별적·최적화 전환”으로
과거에는 Big Bang 방식의 전면 재구축이 기본값이었다면, 최근에는 재무·구매·생산·물류 같은 핵심 프로세스만 선별해 단계적으로 전환하고, Downtime-Optimized Conversion(DoC) 같은 기법으로 시스템 비가동 시간을 최소화하는 방식이 확산되고 있습니다.
국내 사례로는 삼성전기가 이 방식을 도입해 다운타임을 최초 예상 대비 75% 이상 줄인 것이 대표적입니다. 즉 트렌드는 “무조건 빨리”가 아니라 “업무 중단 없이 정교하게”로 옮겨가고 있습니다.
③ 논의의 중심이 “전환”에서 “전환 이후”로 이동
SAP 생태계 전반에서 화두가 바뀌고 있다는 점도 눈여겨볼 부분입니다. 지난 2년간은 마이그레이션 자체가 최대 관심사였다면, 이제는 Go-live 이후 실제로 그 시스템에서 얼마나 가치를 뽑아내느냐(Value Realization)로 논의의 중심이 옮겨가는 분위기입니다.
Fiori 앱을 도입해놓고 직원들이 여전히 구 T-code로 돌아가고 있지는 않은지, 실제 업무 처리 속도가 ECC 대비 개선됐는지 같은 “사용률” 지표가 성공의 기준으로 떠오르고 있습니다. 이는 전환을 “IT 프로젝트”가 아니라 “비즈니스 프로젝트”로 봐야 한다는 신호이기도 합니다.
④ AI가 전환 프로젝트와 맞물리기 시작
SAP는 최근 Joule, Business AI Platform 등 AI 아키텍처를 S/4HANA와 적극적으로 결합하는 방향으로 메시징을 강화하고 있습니다. 아직 모든 기업에 당장 해당되는 이야기는 아니지만, 앞으로의 전환 프로젝트는 단순히 “ECC를 S/4HANA로 옮기는 것”을 넘어 AI 기반 업무 자동화까지 염두에 둔 설계가 요구될 가능성이 높습니다.
정리하면, 지금의 트렌드는 “늦게 시작할수록 경쟁은 치열해지고, 전환의 기준 자체도 계속 높아지고 있다”는 방향으로 움직이고 있습니다.
그래서 지금 무엇을 해야 하는가
- 현재 시스템의 EhP/버전 확인 — 표준 유지보수 종료가 실제로 우리 회사에 적용되는 일정인지부터 확인
- 전환 방식 결정 — Greenfield/Brownfield/Selective, 그리고 회사 규모·복잡도에 따라 Private Edition 전환 옵션 해당 여부 검토
- 인력 계획 조기 수립 — 프로젝트 착수 시점을 인력 시장 상황과 맞춰서 역산
- 전환 이후 목표까지 함께 설계 — 단순 이전이 아니라 Fiori 전환율, 프로세스 처리 속도 등 성공 지표를 미리 정의
마무리
2027년은 아직 1년 넘게 남은 것처럼 보이지만, ERP 전환 프로젝트의 특성상 지금이 사실상 마지막 여유 구간입니다. “버틸 수 있는 옵션이 있다”는 것과 “버티는 게 합리적이다”는 것은 다른 문제입니다. 다음 글에서는 실제 TR/FI 모듈 관점에서 전환 프로젝트 체크리스트를 다뤄보겠습니다.
참고: 본 글의 데드라인 정보는 SAP 공식 발표를 기반으로 작성했으나, 개별 기업의 계약 조건(RISE with SAP 여부, EhP 버전 등)에 따라 적용 일정이 다를 수 있으니 SAP 공식 채널을 통해 재확인하시기 바랍니다.