회사 소개서비스프로젝트아티클

글: Kristijan Sekereš

2027년 12월 31일 SAP ECC 유지보수 종료: 전원이 꺼지는 것이 아니라 가격이 오르는 것

서버실에 파란 패치 케이블이 꽂힌 네트워크 랙

2027년 12월 31일 SAP는 SAP ECC 6.0과 SAP Business Suite 7의 다른 핵심 애플리케이션에 대한 메인스트림 유지보수를 종료합니다. 2028년 1월 1일에 꺼지는 것은 없습니다. 시스템은 계속 돌아가고, 사용자는 계속 인보이스를 전기하며, SAP는 여전히 지원을 판매합니다. 바뀌는 것은 지원에 내는 비용과 그 대가로 받는 내용입니다.

이 차이가 중요한 이유는 돌아다니는 조언 상당수가 2027년을 절벽처럼 다루기 때문입니다. 아직 ECC를 쓰는 대부분의 회사에게 2027년은 절벽이 아니며, 그들도 그것을 압니다. 남아 있는 ECC 사용자 중 가장 큰 집단은 2030년을 기준으로 계획하고 있습니다. 진짜 위험은 다른 데 있습니다. 실제로 날짜를 결정하는 작업(커스텀 ABAP, 인터페이스, 데이터)의 범위가 늦게 잡히고, 그 결과 2030년도 2027년만큼 빠듯해지는 것입니다.

이 글은 아직 ECC를 운영하면서 앞으로 3년을 어떻게 보낼지 결정해야 하는 중견기업의 CIO와 SAP 책임자, 그중에서도 주로 독일어권 시장의 독자를 위한 것입니다.

SAP가 실제로 약속한 것

조건은 SAP의 유지보수 전략 페이지에 있으며 2020년 2월에 처음 발표되었습니다.

  • 2027년 12월 31일까지: SAP ERP 6.0을 포함한 Business Suite 7 핵심 애플리케이션의 최신 인핸스먼트 패키지 세 개에 대한 메인스트림 유지보수. 시스템이 그보다 오래된 인핸스먼트 패키지에 있다면, 2027년 날짜를 전제로 계획을 세우기 전에 그 페이지에 링크된 SAP Note 2881788을 확인하십시오.
  • 2028년 1월 1일부터 2030년 12월 31일까지: 선택형 연장 유지보수이며, "유지보수 기준액에 2%포인트의 추가 요금"이 붙습니다. 쉽게 말해 지금 내는 유지보수 요율이 2%포인트 오릅니다.
  • 연장 유지보수를 선택하지 않으면: 자동으로 고객 특화 유지보수(customer-specific maintenance)로 넘어갑니다. 그 범위는 같은 페이지에 링크된 SAP Note 52505에 설명되어 있습니다. 그것으로 충분하다고 가정하기 전에 읽어 보십시오.
  • S/4HANA의 경우: SAP는 2040년 말까지 유지보수를 약속했습니다.

더 작은 집단을 위한 추가 경로도 있습니다. SAP는 2025년 8월 SAP ERP, private edition, transition option을 발표했습니다. SAP의 프라이빗 클라우드 안에서 ECC를 2031년부터 2033년까지 이어 가는 기간 한정 구독입니다. 조건은 엄격합니다. "시스템은 2030년 12월 31일 전에 SAP HANA 기반의 SAP ERP, private edition으로 마이그레이션되어야 합니다." 지원되는 데이터베이스는 HANA뿐이고, 이 옵션은 2031년부터 2033년까지의 max success plan과 함께만 제공되며, SAP는 이 옵션으로 구독하는 시스템에 최소 2TB를 요구합니다. SAP는 이것이 "가장 크고 복잡한 SAP ERP 고객"을 위한 것이라고 말합니다. SAP가 제시한 "상업적으로 동등한 조건"은 2025년 말까지 private edition을 약정한 고객을 위한 것이었습니다.

어느 수준을 고르든 SAP와 파트너에게 서면으로 물어야 할 질문이 하나 있습니다. 어떤 법적 변경(세금, 급여, 전자 인보이스 형식)이 언제까지 귀사의 ECC 시스템에 반영되느냐는 것입니다. 독일 회사라면 그 답 하나로 현 상태 유지가 가능한지가 결정될 수 있습니다.

시장의 나머지는 무엇을 하고 있나

독일어권 SAP 사용자 그룹 DSAG는 2025년 12월 8일부터 2026년 1월 21일까지 응답자 198명을 대상으로 Investment Report 2026을 진행했습니다. 그중 54%가 여전히 ECC나 그 이전의 Business Suite를 운영하고 있으며, 2024년의 68%에서 줄었습니다.

시점을 보면 응답자의 절반 가까이가 2030년 말까지 S/4HANA로 전환할 계획이며, DSAG는 이것이 연장 유지보수 비용을 낸다는 뜻이라고 지적합니다. 또 37%는 2027년 말까지 전환하려 하고, 2033년과 private edition transition option을 목표로 하는 곳은 4%에 불과합니다.

DSAG 의장 옌스 훙거스하우젠(Jens Hungershausen)은 이유를 솔직하게 밝혔습니다. 인력 부족, 동시에 진행되는 전환 프로젝트, 제한된 예산이 일정을 뒤로 밀고 있다는 것이며, "그 결과 유지보수 비용이 늘더라도" 그렇다는 것입니다.

공공 구매자도 움직이고 있습니다. 저희가 직접 EU 공공 입찰 공고를 집계한 결과, 2025년과 2026년 내내 반기마다 약 200건의 S/4HANA 마이그레이션 절차가 있었고, 2026년에는 10월 초까지 300건이 넘었으며, 대부분 독일에서 나왔습니다. 작업은 실제로 일어나고 있습니다. 다만 2027년이라는 헤드라인이 암시하는 것보다 더 긴 기간에 걸쳐 퍼져 있습니다.

실제 작업이 있는 곳

ECC에서 S/4HANA로의 기술적 전환은 SAP와 파트너들이 도구를 잘 갖춰 두었습니다. 커스터마이징이 적고 표준 인터페이스가 몇 개뿐인 ECC라면 통합 업체가 이미 여러 번 해 본 일이고, 아래 내용 대부분은 귀사의 문제가 아닙니다.

직접 만든 것이 많을수록 그만큼 귀사의 문제가 됩니다.

커스텀 ABAP: 프로젝트가 밀리는 곳

S/4HANA는 새 데이터베이스 위의 ECC가 아닙니다. 데이터 모델의 일부가 바뀌었습니다. 고객과 공급자는 비즈니스 파트너가 됩니다. 재무와 재고 전기는 더 적고 더 넓은 테이블로 통합되었습니다. 일부 트랜잭션과 기능은 제거되거나 대체되었습니다.

테이블을 직접 읽거나, 위치가 바뀐 exit에 의존하거나, 정렬 순서를 은연중에 가정하는(HANA는 쿼리가 요구하지 않으면 정렬 순서를 보장하지 않습니다) 커스텀 코드는 구문 검사를 통과하고도 잘못된 일을 할 수 있습니다. 아픈 것은 바로 이 마지막 유형입니다. 코드 스캔이 아니라 통합 테스트나 운영 개시 후에 드러나기 때문입니다.

효과가 있는 절차는 다음과 같습니다.

  1. 먼저 사용량을 측정합니다. 운영 환경에서 사용 로깅(ABAP 호출 모니터, 트랜잭션 SCMON)을 켜고 연말 결산 한 번을 통째로 지나도록 둡니다. 오래 운영된 시스템에서는 커스텀 객체 가운데 상당 부분이 한 번도 실행되지 않는 경우가 많습니다. 아무도 실행하지 않는 코드는 마이그레이션하지 않고 삭제합니다.
  2. 남은 것에 분석 도구를 돌립니다. SAP의 점검 도구는 문제 후보를 찾아냅니다. 그중 어느 것이 업무에 중요한지는 알려 주지 못합니다.
  3. 모든 객체를 분류합니다. 폐기하거나, 표준 기능으로 대체하거나, 그 자리에서 고치거나, 코어 밖에서 다시 만듭니다. 객체마다 결정 하나, 그리고 이름이 정해진 업무 담당자 한 명입니다.
  4. 객체가 아니라 프로세스 단위로 테스트합니다. 코드를 바꾸는 것은 저렴한 부분입니다. 주문에서 수금까지와 월말 결산이 여전히 같은 숫자를 내는지 증명하는 것이 비싼 부분입니다.

프로젝트가 여기서 밀리는 이유는 지루할 만큼 단순합니다. 아무도 충분히 일찍 세어 보지 않았기 때문입니다. 커스텀 코드의 양은 대략적으로만 알려져 있고, 그것을 쓴 사람들은 떠난 경우가 많으며, 진짜 발견 사항은 날짜가 사내에 이미 발표된 뒤인 두 번째 테스트 주기에 나옵니다.

인터페이스, 그리고 같은 시계를 따르는 PI/PO

ECC가 홀로 서 있는 경우는 드뭅니다. 창고로 가는 IDoc, 생산 현장에서 오는 RFC와 BAPI 호출, 은행과 세무사에게 가는 플랫 파일, 누군가 2011년에 만든 데이터베이스 뷰를 읽는 고객 포털이 있습니다. 하나하나 찾아내고 테스트해야 하며, 일부는 다시 만들어야 합니다.

이 인터페이스들이 SAP Process Integration이나 Process Orchestration을 거친다면 같은 날짜에 두 번째 기한이 있습니다. SAP의 Architecture Center는 PI/PO가 "2027년 표준 유지보수 종료"에 다가가고 있으며, 고객은 2030년까지 유지보수를 연장할 수 있고, 그 뒤에는 SAP 지원이 끝난다고 말합니다. SAP는 PI/PO 고객을 SAP Integration Suite로 안내하며, 여기에는 마이그레이션 평가와 마법사 기반 마이그레이션 도구가 함께 제공됩니다.

도구는 표준 객체에는 도움이 됩니다. 어떤 인터페이스가 아직 무언가에 쓰이는지는 알려 주지 않고, 커스텀 매핑 로직은 여전히 사람이 읽어야 합니다. 현황 목록은 설문이 아니라 미들웨어 설정, 로그, 예약 작업으로 만드십시오. 그다음 ERP 이전과 미들웨어 이전을 함께 계획하십시오. 하나씩 차례로 하면 모든 인터페이스를 두 번 테스트하게 됩니다.

데이터 마이그레이션

시스템 전환(system conversion)에서는 데이터가 시스템과 함께 옮겨지며, 데이터 품질도 함께 옮겨집니다. 비즈니스 파트너 전환이 대개 첫 충돌 지점입니다. 중복 고객, 고객이기도 한 공급자, 자유 텍스트 필드에 든 주소, 엉뚱한 자리에 든 세금 번호가 있습니다. 이 모든 것은 전환 도중이 아니라 전환 전에 정리해야 합니다.

신규 구축(new implementation)에서는 추출, 정제, 변환, 적재를 하며, 어려운 부분은 대사입니다. 재무팀은 적재 작업이 끝났을 때가 아니라 잔액과 미결 항목이 맞을 때 승인합니다. 마이그레이션은 점점 깨끗해지는 데이터를 대상으로 열두 번이라도 돌릴 수 있고, 매번 결과를 자동으로 비교하는 반복 가능한 코드로 만드십시오.

어느 경로든 더 이상 필요 없는 데이터는 먼저 보관 처리하십시오. 데이터가 적을수록 전환 실행 시간과 다운타임이 짧아집니다.

클린 코어 확장

기한에 쫓기는 프로젝트에서는 모든 수정 사항을 그대로 옮기고 나중에 정리하겠다고 약속하고 싶어집니다. 나중은 오지 않습니다.

SAP가 그 대안에 붙인 이름은 클린 코어입니다. 표준 시스템은 수정하지 않고 두고, SAP가 공개하고 안정적으로 유지하는 인터페이스를 대상으로 확장 기능을 S/4HANA 안에서, 또는 그 옆의 SAP Business Technology Platform에서 만드는 것입니다. 첫날부터 모든 것을 깨끗하게 할 수는 없습니다. 실제로 지킬 수 있는 규칙은 더 단순합니다. 새로 만드는 것은 하나도 옛 방식으로 만들지 않는다는 것입니다. 지금 피한 수정 하나하나는 앞으로의 모든 업그레이드 때 다시 테스트하지 않아도 되는 수정입니다.

결정의 틀

현실적인 경로는 세 가지이고, 덜 주목받는 네 번째가 있습니다.

2027년 12월 31일까지 S/4HANA 운영 개시. 이미 시작했고, 시스템이 대체로 표준이며, 파트너를 확보한 회사에 맞습니다. 오늘부터 15개월이고, 연말 결산 한가운데의 전환을 받아들일 재무팀은 거의 없습니다. 커스텀 코드 분석을 아직 하지 않았다면 아마 귀사의 경로가 아닐 것입니다.

연장 유지보수 비용을 내고 2030년까지 운영 개시. 시장의 대부분이 향하는 곳입니다. 비용은 2%포인트의 추가 요금이며, 기간 도중에 운영을 개시하면 어떻게 적용되는지 SAP에 확인하십시오. 위험은 2030년을 2027년처럼 다루는 것입니다. 갑자기 코앞에 닥치기 전까지는 멀게만 느껴진다는 뜻입니다.

private edition transition option으로 2033년까지. RISE with SAP 계약, HANA, 2030년 12월 31일 전에 SAP ERP, private edition으로 옮긴 시스템, max success plan, 최소 2TB를 뜻합니다. 중견기업에게 시간을 사는 가장 저렴한 방법인 경우는 드뭅니다.

SAP를 떠나기. 일부 중견 제조사와 유통사에게는 더 작은 ERP가 실제 선택지입니다. 인터페이스와 데이터 작업은 줄어들지 않습니다. 오히려 프로젝트의 대부분이 됩니다.

어느 경로를 고르든 앞으로 6개월

지금부터 2027년 3월 말까지 다음 일들은 어느 경로에서든 보람이 있습니다.

  1. 출발점을 확인합니다. 인핸스먼트 패키지, 데이터베이스, 유지보수 계약입니다. 귀사에 적용되는 연장 유지보수 조건을 SAP 영업 담당 팀에 서면으로 요청하십시오.
  2. 지금 사용 로깅을 켜서 2026년 연말 결산을 담게 합니다.
  3. 커스텀 코드 분석을 돌려 인상이 아니라 숫자를 얻습니다. 객체가 몇 개인지, 그중 몇 개가 쓰이는지, 몇 개가 데이터 모델의 바뀐 부분에 닿는지입니다.
  4. 인터페이스 현황 목록을 만듭니다. PI/PO를 거치는 모든 것을 포함하고, 인터페이스마다 담당자와 결정을 둡니다.
  5. 마스터 데이터 정제를 시작합니다. 고객과 공급자부터입니다.
  6. 수정 추가를 멈춥니다. 새 개발은 오늘부터 클린 코어를 따릅니다.
  7. 2028년 유지보수 인상분을 2027년 예산에 뜻밖의 비용이 아니라 이미 아는 비용으로 넣습니다.
  8. 역량을 확보합니다. 파트너, 사내 SAP 팀, SAP 주변 시스템을 맡는 개발자입니다. 인력 부족은 DSAG 회원사들이 일정이 밀리는 이유로 꼽는 것 중 하나입니다.

2030년 운영 개시에서 거꾸로 세면, 2030년에는 테스트 주기와 전환 리허설, 2029년에는 구축과 개선, 2028년에는 설계와 데이터 정제, 그리고 지금은 분석입니다. 보기보다 여유가 적습니다.

도움이 필요하시면

저희는 SAP 기능 컨설팅 회사가 아니며 S/4HANA 전환을 직접 수행하지 않습니다. 전환을 맡은 파트너 옆에서 인터페이스 현황 파악과 재구축, 데이터 마이그레이션 코드와 그 대사, 그리고 이전 후에도 살아남아야 하는 ECC 주변 애플리케이션을 맡습니다. 이 작업은 ERP 현대화 페이지에 설명되어 있고, 이전할 때까지 제자리에 남는 시스템은 레거시 시스템 유지보수가 다룹니다. 프로그램 계약에 서명하기 전에 ERP 주변 시스템 현황을 집계해 두고 싶다면 office@c9group.dev로 연락 주십시오.

Back to All Articles