기업용 AI 에이전트가 업무를 정확히 처리하려면 모델 밖의 조건이 먼저 갖춰져야 한다. 오래된 ERP의 복잡성은 유지보수 비용에 그치지 않고 에이전트가 업무를 해석하고 실행하는 범위까지 제한한다.
에이전트가 읽는 사전
SAP의 Joule 에이전트는 고객사 테이블의 업무 의미를 스스로 알아내지 못한다. 판단의 바탕은 SAP 표준 객체와 관계를 정리한 지식그래프다. 여기에는 약 45만2,000개 ABAP 테이블, 8만 개 CDS 뷰, 730만 개 필드 가 연결돼 있다. 에이전트는 지식그래프로 EKKO(SAP 구매전표 헤더 표준 테이블)와 구매 오더의 관계는 알지만, 고객사가 만든 Z테이블까지 이해하지는 못한다.
그래서 커스터마이징은 이제 업그레이드 비용만의 문제가 아니다. 필드의 의미와 관계가 정의돼 있지 않으면, 에이전트가 그 필드를 추론에서 참조할 수 있을까. SAP CTO 필리프 헤르치히도 기업 AI를 늦추는 것은 모델보다 에이전트가 쓸 수 없는 데이터라고 지적했다.
실제로 표준 프로세스를 지킨 시스템은 에이전트를 쉽게 활성화할 수 있지만 깊게 수정된 시스템은 별도 개발이 필요하다. SAP가 Sapphire 2026에서 50개가 넘는 Joule 어시스턴트와 200여 개의 전문 에이전트를 발표했어도 에이전트 파일럿의 88%는 운영 단계에 이르지 못했다. 결국 ERP가 업무 구조를 기계가 읽을 수 있게 설명하지 못하면 에이전트의 판단을 평가하고 감사할 근거가 사라지고 신뢰도 쌓이지 않는다.
부채가 겹치는 자리
커스텀 코드와 부실한 마스터 데이터가 섞이면 에이전트는 잘못된 판단을 그대로 결과에 반영한다. 같은 공급사가 두 개의 벤더 번호로 등록돼 있으면 에이전트는 서로 다른 회사로 본다. 위험을 낮게 평가하거나 엉뚱한 조치를 내놔도 모델은 주어진 데이터대로 작동했을 뿐이다.
같은 맥락에서 만료된 계약이나 비활성 고객을 제외하는 기준도 시스템에 기록돼 있어야 한다. 연체 원인도 지급 지연, 가격 오류, 분쟁, 입고 누락 등으로 나눠 기록한다. 그렇지 않으면 입고 기록이 빠진 거래에 지급 독촉을 보내는 일이 생기지 않겠는가.
통합에서도 테이블을 직접 연결하면 업데이트로 스키마가 바뀔 때 잘못된 값을 보낸다. 반면 ABAP Cloud(SAP가 승인한 API만 쓰도록 강제하는 개발 방식)는 릴리스되지 않은 객체의 호출을 컴파일 단계에서 막는다. 계약된 API는 오류를 실행 전에 차단하는 장치다. 조사에서도 S/4HANA 가동 기업은 59%로 늘었지만 커스터마이징은 44%가 꼽은 마이그레이션 장벽이었고 자동화 도입률은 57%에 그쳤다.
나중에 정리할 코드는 없다
“가동한 뒤 커스텀 코드를 정리하겠다”는 계획은 대개 실현되지 않는다. 안정화를 마치면 기존 커스텀 위에 새 업무와 통합이 쌓인다. 의존성이 늘어나는데, 손댈 여지는 어디에 남겠는가. ECC 시절 미룬 정리가 지금 S/4HANA 전환 비용을 키운다.
하지만 커스텀 코드의 미사용 비율은 40~70%로 추정된다. 개발 전에 Z오브젝트의 호출 기록을 확인하고 표준 기능으로 대체된 코드를 빼면 전환 범위가 줄어든다. Kimberly-Clark는 580만 줄의 ABAP을 수 시간 안에 분석하고 30만5,000건이 넘는 문제를 6주 동안 처리해 예정보다 한 달 먼저 가동했다.
클린 코어는 한 번의 전환이 아니라 지속해서 관리할 기준이다.
| 등급 | 상태 |
|---|---|
| A등급 | 표준 코어와 ABAP Cloud, BTP 확장만 사용 |
| D등급 | 직접 수정과 미관리 코드로 업그레이드가 막힌 상태 |
표준에 가까울수록 업데이트와 내장 AI를 빨리 적용한다. 예외 개발이 쌓이면 코어의 복잡도도 함께 올라간다.
Joule보다 골든 레코드가 먼저다
S/4HANA로 옮긴다고 훼손된 업무 의미까지 복원될까. 중복 벤더와 낡은 코스트센터 체계를 그대로 이전하면 잘못된 권고도 반복된다. 골든 레코드(여러 시스템에 흩어진 동일 대상 정보를 하나로 합친 대표 기록) 통합과 데이터 의미 보강은 Joule 배포보다 앞선 순서다.
그와 함께 코어에는 표준 기능과 릴리스된 API만 두고 확장은 ABAP Cloud나 BTP로 분리하는 구조를 지킨다. 통합은 OData나 이벤트 같은 계약된 인터페이스로 처리하며 직접 DB 접근은 없앤다. 마스터 데이터 정제는 마이그레이션과 함께 이뤄진다. 업무 오너는 각 Z오브젝트를 검토해 폐기, 이관, 재작성, 존치 여부를 정한다.
실행 권한 역시 함께 설계 대상이다. 접근 범위와 승인 한도, 예외 처리, 실행 기록을 정책으로 관리하고 여러 회사의 에이전트를 쓴다면 감사 범위와 책임 주체도 정해야 한다.
우선 출발점은 다섯 가지 지표면 충분하다.
- 분기 업데이트 검증 기간
- 커스텀 오브젝트 수와 미호출 비율
- 마스터 데이터 중복률
- 계약된 API를 거치지 않는 통합 건수
- 에이전트 제안을 사람이 번복한 비율이다.
번복률이 높다면 점검 순서는 모델이 아니라 데이터와 프로세스 정의다. 2030년에도 ECC에 남을 고객이 1만3,000곳에 이를 수 있다는 전망 에는 유지보수 비용은 드러나지만 그동안 놓칠 자동화의 가치는 보이지 않는다.
그 공백 위에서 자동화가 확대될수록 사람이 과거에 허용했던 예외와 임시방편도 시스템이 그대로 판단 기준으로 적용한다. 같은 시스템을 오래 운영해도 그 안에 남은 예외를 어떻게 다뤘는지에 따라 AI가 맡을 수 있는 업무는 달라진다.