SAP, AI 에이전트를 활용해 커스텀 코드를 수정하는 방안을 공개하다

SAP TechEd Berlin은 10월 27일에 시작하며 에이전트 주도 커스텀 코드 마이그레이션 세션을 선보입니다. SAP가 발표한 클린 코어 레벨과 현장에서 질문해야 할 내용들을 알아봅니다.

모든 ECC 마이그레이션에는 공통적인 '악당'이 있습니다. 예산도 아니고, 데이터베이스도 아닙니다. 바로 커스텀 코드입니다.

수천 개의 Z 프로그램, 사용자 엑시트(user exits), 양식 및 리포트들. 20년 이상에 걸쳐 작성되었고, 그중 두 명은 퇴사하여 세 명만이 이해하고 있습니다.

SAP는 이제 AI 에이전트가 이 문제를 해결할 수 있다고 말합니다. 증거는 SAP TechEd Berlin, 10월 27일부터 29일까지에서 공개됩니다. 가상 버전은 무료입니다.

이는 미리 보기 자료입니다. 저는 세션들을 직접 보지 못했습니다. 제가 할 수 있는 것은 SAP가 어떤 아젠다를 준비했는지 보여주고, 그 배경이 되는 프레임워크를 설명하며, 좋은 데모와 좋은 결과를 가르는 질문들을 제공하는 것입니다.

요약하자면: SAP는 에이전트 주도 툴체인(toolchain)을 통해 커스텀 코드를 계획 단계부터 '대규모 수정(mass remediation)'까지 처리할 수 있다고 말합니다. 이것이 실제로 작동하는지는 하나의 숫자에 달려 있습니다: 에이전트가 수정한 내용 중 검토와 테스트를 거쳐 건드리지 않고 살아남는 비율입니다.

SAP 아젠다에 포함된 내용

TM105, 에이전트 주도 커스텀 코드 마이그레이션: 계획부터 대규모 적응까지. SAP의 설명에 따르면, 커스텀 코드 마이그레이션은 종종 SAP ERP Central Component에서 SAP Cloud ERP Private로 전환하는 과정의 병목 현상을 일으킵니다. 이 툴체인은 SAP Cloud ALM에서의 계획 수립부터 SAP Joule for Developers의 Custom Code Migration Agent를 사용한 'AI 기반 대규모 수정(remediation)'까지 이어집니다. 10월 27일과 29일에 세션이 예정되어 있습니다.
TM260, 실습 워크숍: MCP 도구를 사용하여 ECC에서 RISE로 커스텀 코드를 마이그레이션하고 현대화하는 방법을 다룹니다.
TM103, 에이전트 주도 AI 어시스턴트로 재구상된 마이그레이션 및 현대화. SAP의 설명: 비용을 절감하고, 시간 일정을 단축하며, 전체 마이그레이션 수명 주기(lifecycle)를 아우르는 어시스턴트입니다.
**TM108, SAP Cloud ERP Private를 위한 클린 코어 여정(clean core journey)**에 대해 다루며, AI가 커스텀 코드를 어떻게 클린 코어 준수(compliant)하게 만드는지, 그리고 SAP의 API 정책과 연관된 새로운 가이드를 포함합니다.
AD100 및 AD819, 에이전트 주도 ABAP 개발. 이는 ABAP Language Server와 ABAP MCP Server를 기반으로 구축되었습니다. 이 트랙 전체에 대한 SAP의 헤드라인은 개발이 'AI 지원(AI-assisted)'에서 '에이전트 주도(agent-led)'로 이동한다는 것입니다.

Diagram of the custom code pipeline: plan, classify, remediate with an agent, then review and test, with the steps SAP names and the steps you own

에이전트가 들어갈 곳과 여전히 사람이 서명해야 하는 곳을 보여주는 다이어그램입니다. ayraix.com 제작.

첫째, 프레임워크: 클린 코어 레벨(clean core levels)

어떤 에이전트를 평가하려면 '고정되었다'는 것이 무엇을 의미하는지 알아야 합니다. SAP은 이전의 3단계 모델을 대체하기 위해 2025년 8월에 도입된 클린 코어 레벨로 이를 정의합니다.

Level A: 공개적으로 출시된 안정적인 인터페이스만을 사용하며, 공식적인 안정성 계약(formal stability contracts)의 지원을 받습니다. BTP 또는 ABAP Cloud와 온스택(on-stack)으로 나란히 구축됩니다.
Level B: SAP의 클래식 API 및 기술도 사용합니다. 이들은 문서화되어 있으며 일반적으로 업그레이드 안정성을 가집니다.
Level C: SAP 내부 객체에 접근합니다. 레거시 시나리오에는 유연하지만, 업그레이드 위험이 따릅니다. SAP는 변경 사항을 조기에 파악할 수 있도록 SAP 객체에 대한 변경 로그(changelog)를 계획하고 있습니다.
Level D: 권장하지 않습니다. 수정, SAP 테이블에 쓰기 접근, 암묵적 향상(implicit enhancements) 등이 포함됩니다. SAP는 이를 가장 높은 위험 요소이자 상당한 기술 부채(technical debt)의 원인이라고 지칭합니다.

흥미로운 점은 다음과 같습니다. SAP 자체 커뮤니티 가이드라인에 따르면, 과거의 이진 뷰(binary view), 즉 '클린 코어(clean core)' 대 '비-클린(not clean)' 방식은 많은 클래식 커스텀 코드를 가진 시스템에는 '너무 제한적'이었다고 합니다. 다시 말해, SAP는 실제 환경이 기존 모델을 충족할 수 없었기 때문에 모델을 변경한 것입니다.

거버넌스 측면에서 SAP는 ABAP Test Cockpit을 권장하며, 프라이빗 클라우드 및 온프레미스(on-premises) 환경의 클린 코어 개발 거버넌스를 위해 중앙 ATC(ABAP Test Cockpit)를 SAP BTP에서 사용하는 것이 권장 접근 방식이라고 말합니다.

Diagram of SAP clean core levels A to D with a short description of each

Z 코드가 위치하는 곳. SAP의 네 가지 레벨. ayraix.com 제작 다이어그램.

컨퍼런스를 넘어 이 부분이 중요한 이유

커스텀 코드는 고객들이 마이그레이션 지연을 언급하는 주요 원인 중 하나입니다. 한 파트너 CEO는 CIO.com에 많은 고객들이 'Z 코드와 산업별 커스터마이징 때문에 ECC에 갇혀 있다'고 말했습니다. DSAG 회장 역시 복잡한 환경과 인력 부족 문제를 지적합니다.

그리고 일정을 기억해야 합니다. SAP는 ECC의 메인스트림 유지보수(mainstream maintenance)가 2027년에 종료되고 확장 유지보수(extended maintenance)가 2030년에 종료된다고 말했습니다. 만약 에이전트들이 커스텀 코드 수정 작업을 안전하게 처리할 수 있다면, 마이그레이션 계산 자체가 바뀝니다. 바로 그 '만약'이 전체 이야기입니다.

에이전트가 잘 할 수 있는 것과 위험해지는 지점

(SAP의 의견이 아닌) 제가 보기엔: 일부 커스텀 코드는 기계가 처리하기에 적합합니다.

적합한 경우: 반복적이고 규칙 기반의 변경 사항들. 구식이 된 구문이나 호출을 대체하거나, 알려진 단순화된 데이터 모델에 맞추거나, 수백 개의 오브젝트 전반에 걸쳐 동일 패턴으로 대량 수정하는 경우.
위험한 경우: 의도가 누군가의 머릿속에 존재하는 코드. 비즈니스 규칙을 조용히 수정하는 사용자 종료(User exit). 부작용이 있는 리포트. "컴파일되고 ATC를 통과한다"는 것이 "여전히 비즈니스가 필요로 하는 기능을 수행한다"와 같지 않은 모든 경우.

기술 검사를 통과시키는 에이전트라 할지라도 여전히 비즈니스 결과에 문제를 일으킬 수 있습니다. 이것이 바로 검토 및 테스트 단계가 복구(remediation) 단계만큼 중요하다는 이유입니다.

회의에서 질문할 내용

어떤 비율의 수정 사항이 인간의 편집이 필요하지 않습니까? 숫자를 요청하고, 그 뒤에 있는 샘플의 규모와 종류를 물어보세요. 깔끔한 코드(tidy code)에 대한 데모는 거의 증명하지 못합니다.
변경 사항은 어떻게 검토되고 테스트되며 전송됩니까? 에이전트가 제안합니까, 아니면 개발 시스템에 바로 작성합니까?
레벨 A 또는 B에 도달할 수 없는 코드는 어떻게 처리됩니까? 재작성(Rewrite)합니까, 폐기(retire)합니까, 아니면 핵심 영역 외부에 보관합니까?
제 릴리스와 애드온에서는 어떻게 작동합니까? 세션 자료는 Cloud ERP Private를 목표로 언급합니다. 온프레미스 S/4HANA에 대해서도 물어보세요.
대량 복구(mass remediation) 실행 비용은 얼마입니까? 소비 요금(consumption charges)이 있는지, 그리고 실패한 시도에 대한 비용 부담 주체가 누구인지 물어보세요.
에이전트가 만든 변경 사항으로 인해 사고가 발생했을 때 누가 책임집니까? 이 답변은 서면으로 받아야 합니다.

역할 기반 주간 계획

아래 모든 시간은 SAP에서 명시한 CET(중앙유럽 표준시)입니다. 여러 세션이 겹치며, 일부는 가상 리플레이나 두 번째 시간이 있으므로 이동하기 전에 일정을 확인하세요.

모두: 키노트 '빌드하는 사람들을 위해 만들어지다 (Built for the ones who build)' (KEY100), 10월 27일 화요일, 9:00부터 10:30까지, SAP 최고 AI 책임자 및 CTO가 진행합니다.
마이그레이션 리드: 에이전트 기반 커스텀 코드 마이그레이션(TM105) (14:00부터 14:45까지, 목요일에도 반복), 이후 TM260 워크숍, 그리고 Cloud ERP Private을 위한 클린 코어에 대한 TM108(수요일 12:30부터 13:15까지, 목요일에는 가상으로 12:00).
ABAP 리드: ABAP 도구를 활용한 에이전틱 개발(AD100) (화요일 12:00부터 12:45까지, 수요일 14:30에 반복), 그리고 ABAP 전략 세션 ST124(화요일 14:00부터 14:25까지). 참고로 ST124와 TM105는 화요일 오후에 중복되며, AD100은 다른 정오 세션과 충돌합니다. 다시 보기(replays)를 사용하세요.

청취하며 채워 넣을 점수표 (A scorecard to fill in while you listen)

인간의 수정 없이 수용된 수정 건수: ￰% (샘플 객체 ￰개 기준).
커버된 코드 종류와 커버되지 않은 코드 종류: ￰￰￰￰.
자동으로 실행되는 테스트 및 방법: ￰￰￰￰.
지원하는 대상(Cloud ERP Private, S/4HANA 온프레미스, 기타): ￰￰￰￰.
실패한 시도 포함 비용 모델: ￰￰￰￰.
누가 검토하며 인간의 승인(human sign-off)이 어디에 위치하는지: ￰￰￰￰.
전송 후 문제가 발생했을 때 롤백(Rollback): ￰￰￰￰.

베를린 이후 자체 파일럿을 실행하는 방법 (How to run your own pilot after Berlin)

커스텀 객체 클러스터 세 개 선택: 간단한 것 하나, 일반적인 것 하나, 지저분한 것(ugly) 하나.
수동 노력 추정하기. 에이전트가 어떤 작업을 하기 전에 먼저 해야 합니다.
에이전트를 실행하고 측정하기: 필요한 수정 건수, 통과된 테스트, QA에서 발견된 결함, 소요 시간.
시작하기 전에 기준 정하기. 예를 들어: 수정 없이 수용되는 대부분의 수정 건수 ￰ 그리고 심각한 회귀(regressions)가 없는 것. 결과에 따라 기준을 설정하면 스스로를 속이게 될 것입니다.
통과된 부분만 확장하기. 지저분한 클러스터를 정직한 테스트로 유지하세요.

요점 (The take)

데모로 이 기술을 판단하지 마세요. 데모는 깔끔한 코드를 사용합니다.

엉망인 시스템에서 숫자로 평가하라: 수정 없이 승인된 수정 사항, 통과한 테스트, 절약된 시간, 발생한 사고. 만약 SAP가 이러한 수치를 보여준다면, 이는 전 세계 모든 ECC 사용자에게 진정으로 큰 뉴스일 것입니다.

저희는 계속 주시할 것입니다. Berlin 이후에 돌아와서, 약속했던 것이 아니라 실제로 보여준 것을 보고드리겠습니다.

출처 (Sources)

원래 발행처: ayraix.com, 엔터프라이즈 빌더를 위한 실용적인 AI.