기업용 AI의 도입 시점과 ERP 교체 일정은 대개 같은 속도로 움직이지 않는다. 기존 시스템을 유지하는 기간에도 어떤 준비가 유효한지에 따라 이후 선택지가 달라진다.
클린 코어라는 입장권
SAP는 표준화된 클라우드 코어를 전제로 AI 전략을 세운다. 하지만 실제로는 SAP ECC(SAP의 온프레미스 전사자원관리 시스템)와 구형 Business Suite를 쓰는 기업이 아직 54% 에 이른다. SAP가 그리는 출발점과 고객의 현재 환경 사이에는 그만큼 간격이 있다.
그 현실에서 기업도 AI보다 통합과 분석에 먼저 투자한다. SAP는 온프레미스 ECC 고객에게 Joule을 열면서도 유지보수 지출의 50%를 클라우드로 돌리는 조건 을 붙였다. 클린 코어(SAP 표준 코어를 직접 고치지 않고 확장 로직을 API로 분리하는 원칙)는 기술 원칙이자 SAP 클라우드로 가는 입장권이다.
하지만 클린 코어가 곧 클라우드 이전을 뜻할까. 핵심은 코어를 직접 고치지 않고 업무 로직을 API와 외부 서비스로 빼내는 것이며, ECC에서도 할 수 있는 일이다. 이렇게 옮긴 로직은 당장 AI에 쓰고, 나중에 S/4HANA로 전환할 때 다시 활용한다.
쓰지 않는 코드가 AI를 흐린다
평균적인 ECC 시스템에는 커스텀 오브젝트 약 2만2천 개와 코드 270만 줄 이 있다. 이 가운데 40~60%는 쓰이지 않는 것으로 추정된다. 무엇이 실제로 작동하고 어디에 연결됐는지 모른 채 이관하면 불필요한 분석과 테스트까지 함께 늘어난다.
여기에 더해 표준 오브젝트를 고치거나 표준 테이블에 직접 쓰면 문서와 실제 동작이 어긋난다. 같은 필드가 부서마다 다른 뜻으로 쓰이기도 한다. 사람은 관행으로 그 뜻을 짐작할 수 있다. 모델은 어떤가.
정의되지 않은 맥락은 모델에 전달되지 않는다.
필드 정의와 데이터 흐름이 불분명하면 모델 성능과 무관하게 답의 정확도가 떨어진다.
S/4HANA로 옮긴다고 이 문제가 저절로 풀리지는 않는다. SAP가 Reltio를 인수해 SAP와 비SAP 데이터 통합, 정제에 나선 이유 도 여기에 있다. 이관 전에 마스터 데이터와 커스텀 코드의 실제 사용 범위부터 확인해야 한다.
코어 밖에서도 AI는 일한다
ECC에서는 입력 처리와 판단 보조부터 시작하면 된다. 문서와 계산서에서 항목을 뽑아 정형 데이터로 만드는 일은 코어 버전의 영향을 적게 받는다. 결과를 사람이 확인한 뒤 기존 업무에 넘기면 코어 수정도 줄일 수 있다.
분석도 코어 밖에서 할 수 있다. SAP Business Data Cloud Connect와 Databricks의 제로카피 연동 을 이용하면 데이터를 거듭 복제하지 않고 외부에서 분석할 수 있다. ECC는 거래를 기록하고 외부 플랫폼은 분석과 AI를 맡는다.
반면 쓰기 작업에는 승인 절차가 필요하다. AI가 분개나 조정안을 만들더라도 최종 확정은 사람이 맡고, 검토, 승인 과정과 판단 근거를 기록해야 한다. 회계 자동화도 내부통제 대상 이기 때문이다. 제품 버전이 차이를 만들까. 결과를 되돌릴 수 있는지, 사람이 개입할 수 있는지가 실제 차이를 만든다.
전환보다 먼저 기술 부채를 갚아라
2027년 ECC 메인스트림 유지보수 종료가 모든 기업의 이관 마감일일까. ECC 투자 기업의 49%는 추가 비용을 내며 2030년까지 전환할 계획이다. 2027년은 이관 시한이라기보다 유지 비용이 달라지는 기준일에 가깝다.
서두른다고 성공하는 것도 아니어서, S/4HANA 전환 프로그램 약 60%가 예산, 일정, 품질 목표 중 하나 이상을 놓쳤고, 프로세스 분석 부족과 수십 년 쌓인 커스터마이징, 조직 저항이 비용을 키웠다.
바로 그 지점에서 AI 도입과 S/4HANA 전환은 같은 준비를 요구한다. 쓰지 않는 코드를 걷어내고 마스터 데이터를 정리하고 업무 로직을 API 뒤로 옮기면, AI의 입력 품질이 좋아지고 이관할 코드와 테스트도 줄어든다. 데이터와 통합 계층, AI 서비스, 업무 화면을 코어 밖에 두면 전환 뒤에도 연결부만 바꿔 계속 쓸 수 있다.
S/4HANA 전환을 기다려야 AI를 시작할 수 있는 건 아니다. 지금 데이터와 로직을 코어 밖에서 쓸 수 있게 만들면 된다. 이 자산은 당장의 AI 성과를 만들고, 나중의 전환 비용과 위험도 낮춘다.
전환 전과 후에 같은 자산을 쓸 수 있다면 시스템 선택도 한 시점의 제품 기능에 덜 묶인다. 기술 부채를 줄이는 작업의 가치는 다음 시스템이 정해지기 전부터 이미 확인된다.