Agent-Led Transformation: AI 어시스턴트 일곱 개로 S/4HANA 전환 공수를 줄이는 방식
SAP가 2026년에 내놓은 Agent-Led Transformation과 일곱 개 Migration and Modernization Assistant가 ECC→S/4HANA 전환의 어느 단계를 맡는지, 그리고 35% 공수 절감 목표를 우리 프로젝트에서 어떻게 검증할지 정리했습니다. 커스텀 코드 파일럿 설계와 에이전트 권한표를 붙였습니다.
SAP는 S/4HANA 전환의 분석·데이터·코드·설정·테스트·롤아웃·일정 관리를 일곱 개 AI 어시스턴트로 묶고, 이들이 같은 시스템 지식을 함께 쓰게 하려 합니다. 효과를 보려면 먼저 커스텀 코드·데이터·인터페이스·프로세스 목록을 최신으로 만들고, 한 ABAP 패키지로 기존 방식과 AI 방식을 비교하는 파일럿부터 돌려야 합니다.
요약
터키 이스탄불의 SAP Basis 서비스 기업 Basisci는 2026년 10월 글에서 SAP가 같은 해 발표한 Agent-Led Transformation(에이전트가 이끄는 전환 방식)을 설명합니다. SAP는 Sapphire 2026에서 System Analysis, Data Management, Custom Code, Configuration, Test Management, Rollout, Project Management의 일곱 가지 Migration and Modernization Assistant(전환 단계별 AI 어시스턴트)를 내놓았습니다. 이 어시스턴트들은 SAP Cloud ALM(SAP의 프로젝트·운영 관리 도구) 위에서 돌아가고, 사용자는 Joule(SAP의 대화형 AI)로 이들을 부릅니다. 저자는 어시스턴트마다 하는 일을 정리한 뒤, 터키의 한 제조사가 ECC에서 SAP Cloud ERP Private로 옮기는 대표 시나리오에 대입합니다.
저자가 보는 AI의 가치는 개별 작업의 속도보다 연결에 있습니다. 분석·코드·데이터·설정·테스트는 보통 서로 다른 팀이 따로 다루는데, 어시스턴트가 이를 한 시스템 맥락 안에서 잇는다는 것입니다. 다만 저자는 세 가지를 분명히 합니다. 일곱 개 가운데 2026년 9월 기준으로 정식 출시(GA)가 확인된 것은 커스텀 코드 쪽뿐이고, SAP가 밝힌 약 35%의 공수 절감은 목표치일 뿐 보장이 아니며, 운영 반영 전에는 사람이 승인해야 합니다. 아래에서는 어시스턴트의 작동 방식, 저자가 통념과 다르게 보는 점, 터키 제조사 시나리오를 정리하고, 실제로 파일럿을 돌릴 때 필요한 기술·현업 디테일을 덧붙였습니다.
핵심 메커니즘
Agent와 Assistant: 일을 하는 단위와 묶는 단위
저자는 두 말을 구분합니다. AI Agent는 정해진 권한 안에서 정보를 모으고 분석하고 행동하는 소프트웨어입니다. AI Assistant는 한 업무 영역에서 여러 에이전트와 AI 기능을 묶은 것입니다. 이를테면 Custom Code Assistant 안에는 코드 점검 결과를 해석하는 에이전트와 일부를 고치는 에이전트가 함께 들어갈 수 있습니다. SAP FAQ에 따르면 어시스턴트들은 하나의 플랫폼처럼 움직이지만 각자 범위가 정해져 있어 따로도 쓸 수 있습니다. 필요한 기반은 Cloud ALM, Joule for Consultants, Joule for Developers이고, SAP Solution Manager에서는 쓸 수 없습니다. 첫 적용 범위는 ECC에서 RISE with SAP 방법론으로 SAP Cloud ERP Private로 가는 경로입니다.
언제 의미가 있나: 이미 Cloud ALM을 쓰거나 도입할 수 있고, 전환 대상이 ECC→Private Cloud인 경우입니다. Solution Manager 중심으로 운영하면서 기반을 바꿀 생각이 없다면 당장 쓸 수 있는 범위가 좁습니다.
System Analysis Assistant: 다른 어시스턴트가 함께 쓰는 시스템 지식
이 어시스턴트는 데이터, 커스터마이징, 커스텀 코드를 분석해 회사별 시스템 지식을 만듭니다. 예를 들어 어떤 ABAP 프로그램이 어떤 업무 프로세스를 받치는지를 기록합니다. 다른 어시스턴트는 이 지식을 받아 설정·데이터 정제·테스트 생성을 같은 기준으로 맞춥니다. SAP FAQ도 이를 나머지 어시스턴트의 기반이라고 설명합니다.
저자가 덧붙이는 조건이 있습니다. 기술적 의존 관계를 그려도, 그 프로그램이 업무에 얼마나 중요한지는 현업이 판단해야 합니다. 시스템 정보가 빠지거나 틀리면 AI도 그만큼 틀립니다. 그래서 저자는 AI-ready(AI를 쓸 준비가 된) 전환의 출발점을 가시성, 곧 커스텀 코드·데이터·인터페이스·프로세스의 최신 목록으로 둡니다.
Custom Code Migration Agent: 점검 결과를 해석하고 일부를 고치는 에이전트
일곱 가운데 가장 먼저 나온 기능입니다. 저자에 따르면 S/4HANA Custom Code Migration Agent는 2026년 2분기에 정식 출시됐습니다. 에이전트는 ATC(ABAP Test Cockpit, SAP의 코드 점검 도구)를 돌리고, 나온 지적을 해석하고, 일부는 직접 고칩니다. 확신도가 낮은 제안은 개발자에게 넘기고, 모든 변경은 transport request(SAP의 변경 이관 단위)로 추적합니다.
저자는 고치기 전에 물어야 할 질문을 먼저 둡니다. 이 코드를 정말 옮겨야 하는가. SAP 표준 기능, Clean Core(표준을 건드리지 않고 확장은 밖에 두는 원칙), 확장 옵션으로 대신할 수 있다면 옮기지 않는 편이 낫습니다. 즉 이 에이전트는 ‘고칠 코드’를 빨리 고쳐 주지만, ‘버릴 코드’를 가려내는 일은 사람이 함께 해야 합니다.
Test Management Assistant: 결과까지 확인하는 테스트 범위 만들기
이 어시스턴트는 SAP Signavio의 프로세스 모델과 요구사항에서 테스트 범위와 시나리오를 뽑고, Tricentis와 연결해 자동 실행합니다. 저자가 드는 예는 order-to-cash(주문에서 수금까지)입니다. 송장이 만들어졌는지만 보면 부족하고, 재고가 줄었는지, 회계 전표가 맞게 생겼는지, 외부 인터페이스로 넘어갔는지까지 확인해야 합니다. 무엇이 성공인지는 프로세스 오너가 정합니다. AI는 범위를 넓게 잡아 주고, 합격 기준은 사람이 정하는 구조입니다.
Rollout과 Project Management Assistant: 현지 차이와 지연의 파급
Rollout Assistant는 본사의 중앙 SAP 템플릿과 각 나라·법인의 프로세스를 비교해, 무엇을 현지에 맞춰야 하는지 찾습니다. 저자는 터키의 e-Invoice(전자 송장)와 e-Ledger(전자 장부) 요건을 예로 듭니다. Project Management Assistant는 진척을 추적하고 작업을 배정하며 위험을 일찍 알립니다. 예를 들어 데이터 정제가 늦어지면 통합 테스트가 밀린다는 사실을 미리 보여 줍니다. 다만 이 분석은 프로젝트 계획이 정확하고 최신일 때만 맞습니다.
Configuration Assistant(고객 요구사항과 SAP 표준 관행을 묶어 목표 시스템 설정을 제안)와 Data Management Assistant(데이터 불일치를 찾아 원인을 조사하고 수정안을 제시)도 같은 원칙을 따릅니다. 중복 거래처를 합치는 일처럼 영업·회계 판단이 필요한 마스터 데이터는 최종 결정을 현업이 내립니다.
통념과 다른 주장
흔히 이렇게 봅니다AI가 코드 분석을 몇 배 빠르게 하면 전환 기간과 비용도 그만큼 줄어든다.
저자는 이렇게 봅니다한 활동이 빨라져도 전체 일정이 그만큼 줄지는 않습니다. 데이터 정제, 테스트 인력, 인터페이스 재개발이 절감분을 상쇄할 수 있습니다.
근거SAP는 2026년 8월 이 방식의 목표를 전체 공수 약 35% 절감이라고 밝혔지만, 저자는 이를 모든 프로젝트의 보장된 절감으로 보지 않습니다. 대신 같은 ABAP 패키지로 기존 방식과 AI 방식을 비교하는 파일럿을 권합니다. 같은 달 SAP News 기사에서는 한 컨설팅사 CEO가 잠재 비용 절감을 약 60%로 내다봤는데, 이 역시 측정치가 아니라 추정입니다.
흔히 이렇게 봅니다AI가 전환을 맡으면 Basis 같은 기술 전문가의 역할이 줄어든다.
저자는 이렇게 봅니다일하는 방식이 바뀔 뿐 일은 남습니다. 반복 분석 시간이 줄고, 아키텍처·위험·검증·의사결정에 쓰는 시간이 늘어납니다.
근거AI가 의존 관계를 짚어 줘도 자원 규모, 인터페이스 구조, 허용 가능한 다운타임은 실제 운영 조건을 아는 사람이 판단해야 합니다. 자동 수정이 기술적으로 성공해도 운영 안정성까지 보장하지는 않습니다.
흔히 이렇게 봅니다글로벌 표준 템플릿이 기술적으로 돌아가면 현지 요건도 대부분 해결된다.
저자는 이렇게 봅니다터키의 e-Invoice, e-Ledger, GİB(터키 국세청) 요건은 따로 평가해야 하고, 민간 연계 사업자(private integrator)와의 연결은 처음부터 끝까지 시험해야 합니다.
근거문서 생성, 전송, 상태 회신, 회계 전기까지 이어지는 흐름 가운데 하나만 어긋나도 법정 요건을 지키지 못합니다.
저자가 든 사례
터키 제조사의 ECC → SAP Cloud ERP Private 전환 (대표 시나리오)
저자는 이를 실제 고객 사례가 아니라 대표 시나리오로 제시하며, 일곱 어시스턴트가 지금 모두 함께 돌아간다는 뜻은 아니라고 밝힙니다.
| 단계 | 상황 | 한 일 | 사람이 맡는 부분 |
|---|---|---|---|
| ① 현행 이해 | 숨은 커스터마이징과 의존 관계가 늦게 드러남 | System Analysis로 커스텀 코드·의존 관계·구조 파악 | 현업이 아직 쓰는 프로그램 확인 |
| ② 데이터·코드 준비 | 데이터 오류와 코드 호환성 문제 | AI로 데이터 문제와 코드 문제 탐지 | ABAP 팀이 남길 것과 버릴 것을 가름 |
| ③ 목표 시스템·현지 요건 | 표준 템플릿은 돌아가도 터키 요건은 별개 | e-Invoice·e-Ledger·GİB 요건 별도 평가 | 민간 연계 사업자 연결을 끝까지 시험 |
| ④ 테스트·go-live | 핵심 프로세스의 끝단 결과 확인 필요 | AI로 테스트 범위 정의 | 애플리케이션·Basis·프로세스 오너가 함께 검증 |
결과 수치는 원문에서 밝히지 않았습니다. 이 시나리오는 System Analysis(①), Custom Code·Data(②), Rollout(③), Test Management(④)를 순서대로 보여 줍니다.
order-to-cash 테스트
상황은 송장만 만들어지면 테스트를 통과시키는 관행입니다. 저자는 재고, 회계, 인터페이스 결과까지 확인하는 시나리오로 바꾸라고 하고, 성공 기준은 프로세스 오너가 정하게 합니다. 결과 수치는 원문에서 밝히지 않았습니다. Test Management Assistant의 사례입니다.
기술 디테일: 파일럿을 실제로 돌리려면
아래는 원문의 원칙을 실제 프로젝트에서 돌릴 때 필요한 설정과 형식으로, AX Review가 새로 작성했습니다.
시스템 지식(System Analysis)을 믿을 수 있게 하려면 객체마다 “누가 쓰는가”를 함께 기록합니다. 어시스턴트 출력과 별개로, 코드 사용 로그(SCMON·SUSG 같은 사용 이력 도구)에서 최근 12~13개월 실행 여부를 붙여 두면 현업 확인 질문이 짧아집니다. 아래 형식으로 엑셀이나 DB에 쌓습니다.
{
"object": "ZSD_INVOICE_PRINT",
"type": "PROG",
"package": "ZSD",
"process": "order-to-cash / 송장 출력",
"executions_13m": 48210,
"atc_findings": 7,
"ai_recommendation": "remediate",
"ai_confidence": 0.86,
"standard_alternative": "출력 관리(BRF+) 표준 양식",
"business_owner": "영업관리팀",
"decision": "pending",
"checked_at": "2026-10-25"
}Custom Code Migration Agent의 확신도 경계는 처음부터 정하지 말고 파일럿에서 잽니다. 같은 패키지에서 확신도 구간(0.9 이상, 0.8~0.9, 0.8 미만)별로 AI 수정안을 개발자가 그대로 받아들인 비율을 셉니다. 채택률이 90%를 넘는 구간까지만 ‘리뷰 1명’으로 두고, 그 아래는 개발자가 직접 고치게 합니다. 모든 수정은 transport request 단위로 묶고, transport 번호를 위 표의 decision 옆에 기록해 되돌릴 수 있게 합니다.
파일럿의 비교 지표는 다섯 개로 고정합니다. 저자가 제안한 대로 하나의 ABAP 패키지(예: 객체 150~300개)를 반으로 나눠 기존 방식과 AI 방식으로 처리하고 아래를 기록합니다. 분석 시간만 재면 절감이 크게 보이므로, 재작업과 전문가 총 공수를 반드시 함께 봅니다.
| 지표 | 정의 | 기록 단위 |
|---|---|---|
| 분석 시간 | ATC 결과 해석과 분류까지 걸린 시간 | 객체당 분 |
| 수정 품질 | 단위 테스트를 한 번에 통과한 수정 비율 | % |
| 재작업 | 리뷰나 테스트에서 되돌린 수정 수 | 건 |
| 전문가 총 공수 | 개발자·리뷰어·Basis가 쓴 시간 합계 | 인시 |
| 하류 영향 | 통합 테스트에서 이 패키지 때문에 난 결함 | 건 |
테스트(Test Management)는 기대 결과를 데이터로 적습니다. order-to-cash 시나리오 하나에 아래처럼 확인 항목을 묶으면, AI가 만든 시나리오와 프로세스 오너가 정한 합격 기준을 기계적으로 대조할 수 있습니다.
{
"scenario": "O2C-STD-01",
"steps": ["판매오더", "출하", "송장"],
"expect": {
"stock_change": {"material": "FG-1001", "qty": -10},
"fi_postings": [{"account": "매출", "side": "credit"}, {"account": "매출채권", "side": "debit"}],
"interface": {"target": "e-Invoice 연계 사업자", "status": "accepted"}
},
"acceptance_owner": "영업관리팀장"
}에이전트 권한은 환경별로 나눕니다. 저자가 요구하는 접근 통제, 사람 승인, 감사 로그, 롤백을 표 한 장으로 정리하면 보안팀 검토가 빨라집니다. 아울러 AI가 어떤 데이터에 접근하고 그 데이터가 어디서 처리되는지(BTP 리전)를 계약 전에 확인합니다.
시작할 때 가용성을 표로 확인합니다. 어시스턴트마다 GA 여부, 지원 릴리스, 라이선스 조건을 SAP 공식 문서로 확인하고 확인 날짜를 남깁니다. 2026년 9월 기준 원문이 GA로 밝힌 것은 커스텀 코드 쪽뿐이므로, 나머지는 계획 단계에서 ‘없을 수도 있는 도구’로 두고 일정을 짭니다.
현업 실행 디테일: 누가, 언제, 무엇을
| 역할 | 담당 | 파일럿에서 하는 일 |
|---|---|---|
| 스폰서 | CIO 또는 ERP 전환 PMO 리더 | 파일럿 범위·판정 기준 승인 |
| AX 리드 | 전환 PMO의 AI 담당 1명 | 지표 기록, 주간 보고 |
| ABAP 리드 | 개발 리드 1명 + 개발자 2~3명 | 패키지 절반을 기존 방식, 절반을 AI 방식으로 처리 |
| Basis 리드 | Basis 담당 1명 | Cloud ALM 연결, 권한·transport·롤백 설계 |
| 프로세스 오너 | 영업관리·회계 각 1명 | 코드 사용 여부 확인, 테스트 합격 기준 정의 |
| 보안·법무 | 보안 담당 1명 | 데이터 처리 위치와 에이전트 권한 검토 |
시작 전 준비물: Cloud ALM 테넌트와 Joule for Developers 사용 권한, 대상 ABAP 패키지 목록(객체 150~300개), 최근 13개월 코드 사용 이력, 기존 방식의 과거 처리 시간 기록(있으면), 어시스턴트별 가용성·라이선스 확인표.
| 주차 | 할 일 | 산출물 |
|---|---|---|
| 1주 | 패키지 선정, 사용 이력 수집, 권한표 확정 | 객체 목록, 권한표 |
| 2주 | 현업 확인으로 폐기 후보 확정, 패키지를 둘로 나눔 | 유지/폐기 목록 |
| 3~4주 | 기존 방식과 AI 방식 병행 처리, 매일 지표 기록 | 지표 시트 |
| 5주 | 수정분 통합 테스트(O2C 시나리오 포함) | 결함 목록 |
| 6주 | 결과 비교, 확신도 경계 조정, 확대 여부 판정 | 판정 보고서 |
현업 확인 질문(프로세스 오너용): 이 프로그램은 지난 1년 동안 누가 썼습니까? 없어지면 어떤 업무가 멈춥니까? 표준 기능으로 바꿀 때 잃는 것은 무엇입니까? order-to-cash에서 ‘성공’을 확인하는 숫자 세 가지는 무엇입니까?
진행 판정 기준(예시): 전문가 총 공수가 기존 방식보다 20% 이상 줄고, 수정 품질이 기존 방식과 같거나 높고, 통합 테스트의 하류 결함이 늘지 않으면 다음 패키지로 넓힙니다. 공수 절감이 10% 미만이거나 재작업이 늘면, 확신도 경계를 올리거나 범위를 분석 단계로 좁혀 다시 잽니다.
AX 적용 제언. 국내 기업 가운데 상당수는 ECC 표준 유지보수 종료(2027년 말)를 앞두고 전환 견적을 받는 중입니다. 이 글의 쓸모는 견적서에 적힌 ‘AI로 공수 절감’이라는 문구를 검증 가능한 질문으로 바꾸는 데 있습니다. 어느 어시스턴트가 GA인지, 절감은 어느 활동에서 나오는지, 파일럿 지표는 무엇인지를 제안 요청서(RFP)에 넣으십시오. 순서는 가시성(코드·데이터·인터페이스 목록) → 커스텀 코드 파일럿 → 테스트 자동화 → 현지 법정 요건(국내라면 전자세금계산서 연계) 끝단 시험이 무난합니다. 현업 스폰서는 정보시스템 부서보다 영업관리·회계 쪽에서 세워야 테스트 합격 기준과 마스터 데이터 결정이 막히지 않습니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 발표처 | Basisci 블로그(2026.10.02), SAP Basis 서비스 기업 |
| 다룬 방식 | SAP Agent-Led Transformation(2026), Sapphire 2026에서 일곱 Migration and Modernization Assistant 발표 |
| 일곱 어시스턴트 | System Analysis, Data Management, Custom Code, Configuration, Test Management, Rollout, Project Management |
| 기반 | SAP Cloud ALM, Joule, SAP Signavio·LeanIX(프로세스·아키텍처 맥락), Tricentis(테스트 실행) |
| 성숙도 | 2026년 9월 기준 커스텀 코드 쪽만 GA. S/4HANA Custom Code Migration Agent는 2026년 2분기 GA |
| 절감 목표 | SAP 2026년 8월 발표: 전체 전환 공수 약 35% 절감 목표(보장 아님) |
| 대표 시나리오 | 터키 제조사 ECC → SAP Cloud ERP Private, 4단계 |
| 권고 | 같은 ABAP 패키지로 기존 방식과 AI 방식 비교 파일럿, 운영 변경에는 사람 승인·감사 로그·롤백 |
핵심 개념
- SAP Cloud ALM
- SAP 프로젝트의 구축과 운영을 관리하는 클라우드 도구. 어시스턴트 대부분이 이 위에서 돌아갑니다.
- Joule
- SAP의 대화형 AI 비서. 컨설턴트용·개발자용 버전이 어시스턴트를 불러냅니다.
- ATC (ABAP Test Cockpit)
- ABAP 코드가 S/4HANA와 맞는지 점검하는 SAP 도구.
- transport request
- SAP에서 개발→품질→운영으로 변경을 옮기는 묶음 단위. 추적과 되돌리기의 기준이 됩니다.
- Clean Core
- ERP 표준은 수정하지 않고, 필요한 확장은 표준 밖(BTP 등)에 두는 원칙.
- RISE with SAP
- SAP 클라우드 ERP로 옮기는 구독형 전환 프로그램과 방법론.
- GİB
- 터키 국세청. e-Invoice·e-Ledger 같은 전자 세무 요건을 관리합니다.
- private integrator
- 기업과 세무 당국 사이에서 전자 문서를 주고받아 주는 민간 연계 사업자.
내 메모
TODO: 내 생각 추가
원문: Basisci, “AI in SAP S/4HANA Transformation: Emerging Approaches and Practical Use Cases”(2026.10.02). 요약·메커니즘·통념과 다른 주장·사례는 원문 내용을 AX Review가 다시 정리했고, 어시스턴트 구성과 35% 목표는 SAP의 「FAQ SAP Migration and Modernization Assistants」(2026.06)와 SAP News Center 기사(2026.08.21)로 함께 확인했습니다. 기술·현업 디테일, JSON 예시, 지표·일정·판정 기준, 인포그래픽, 표는 새로 작성한 것이며 확신도 경계·판정 수치는 가상 예시입니다. 원문 전체는 Basisci 블로그에서 볼 수 있습니다.