안녕하세요, 비즈니스 혁신 파트너 BSG입니다.
SAP 현장에서 요즘 조용히 오가는 질문이 있습니다.
"AI가 ABAP을 짜준다는데, 그럼 우리 개발자들은요?"
농담처럼 나오지만 웃으며 넘기기엔 변화가 빠릅니다.
오늘은 AI가 ABAP 개발에 실제로 어디까지 들어왔는지, 그리고 개발자의 역할이 어떻게 달라지는지 정리해보겠습니다.
ChatGPT나 GitHub Copilot 같은 도구가 나왔을 때, ABAP 개발자들도 당연히 써봤습니다.
그리고 금방 한계를 만났습니다.
문법은 그럴듯하게 써주는데, SAP를 모른다는 게 문제였습니다.
이미 폐기된 함수 모듈을 추천하거나, 표준 CDS 뷰를 두고 데이터베이스 테이블을 직접 읽는 코드를 만들어내는 식이죠.
문법은 맞지만 SAP 환경에서는 쓸 수 없는 코드입니다.
ABAP은 일반적인 프로그래밍 언어와 다릅니다.
방대한 표준 오브젝트, 릴리스 정책, 업그레이드 호환성 같은 SAP만의 맥락 위에서 돌아가니까요.
이걸 모르면 코드가 아니라 문제를 만들어냅니다.
그래서 SAP가 내놓은 것이 Joule for Developers입니다.
핵심은 SAP가 자체적으로 만든 ABAP 전용 대규모 언어 모델을 쓴다는 점입니다.
엔터프라이즈급 ABAP 코드로 학습해서, 문법이 아니라 SAP의 방식을 이해하도록 만든 것이죠.
그리고 별도 도구가 아니라 개발자가 이미 쓰는 환경 안에 들어와 있습니다.
Eclipse 기반의 ABAP 개발 도구와 SAP Business Application Studio에 직접 내장돼 있어서, 창을 옮겨 다닐 필요가 없습니다.
현재 제공되는 기능은 크게 네 갈래입니다.
코드 생성.
필요한 것을 자연어로 설명하면 데이터 모델과 애플리케이션 로직을 만들어줍니다.
코드 설명.
개발자가 가장 반가워하는 기능일지 모릅니다.
20년 전 누군가 짜놓고 문서 한 장 없이 떠난 그 프로그램, 이제 AI에게 "이게 무슨 일을 하는 코드냐"고 물어볼 수 있습니다.
단위 테스트 생성.
알지만 늘 시간에 밀려 못 하던 그 작업을 AI가 대신 만들어줍니다.
커스텀 코드 마이그레이션 지원.
기존 SAP ERP의 사용자 정의 코드를 S/4HANA로 옮길 때, 분석하고 조정하는 작업을 돕습니다.
네 번째 기능이 왜 중요한지 짚고 싶습니다.
이 블로그에서 여러 번 다뤘듯, 2027년 말 ECC 표준 지원 종료가 다가오고 있습니다.
그리고 S/4HANA 전환 프로젝트에서 기간과 비용을 결정하는 가장 큰 변수가 바로 커스텀 코드입니다.
수십 년간 쌓인 수천, 수만 개의 커스텀 오브젝트.
이걸 하나하나 열어보며 "아직 쓰는지, 표준으로 대체 가능한지, 고쳐야 하는지"를 판단하는 작업이 프로젝트 초반을 통째로 잡아먹습니다.
AI가 이 분석과 설명을 돕는다면, 전환 프로젝트의 가장 무거운 구간이 가벼워집니다.
"AI가 코드를 짜준다"보다 실무적으로 훨씬 큰 의미를 갖는 대목입니다.
여기서 멈추지 않습니다.
SAP가 공개한 방향은 분명합니다.
ABAP 영역의 AI가 개별 기능의 묶음에서 에이전틱 AI로 넘어간다는 것입니다.
무슨 뜻이냐면, 지금은 개발자가 물어보면 답하는 방식이지만 앞으로는 스스로 일을 처리하는 쪽으로 간다는 겁니다.
여러 오브젝트에 걸친 리팩터링 계획을 제안하고 조율하거나, 레거시 코드 분석부터 새 모델 생성까지 마이그레이션 작업을 이어서 수행하거나,
코드 검사와 이송 처리, 문서 생성 같은 여러 단계 작업을 실행하는 식이죠.
VS Code 환경 지원과 외부 AI 도구를 연결하는 표준 인터페이스도 로드맵에 올라 있습니다.
ABAP 개발 환경이 열리고 있다는 신호입니다.
본론입니다. 결론부터 말하면 "사라진다"보다 "역할이 바뀐다"가 정확합니다.
지금까지 ABAP 개발자의 일 중 상당 부분은 '짜는 일'이었습니다.
요구사항을 받아 코드로 옮기는 작업이죠. 이 영역은 AI가 빠르게 가져가고 있습니다.
하지만 AI가 못 하는 일이 남습니다.
무엇을 만들지 정하는 일.
현업이 "이렇게 해달라"고 요청한 것이 정말 필요한 기능인지, 표준으로 해결되는 것을 굳이 개발하려는 건 아닌지 판단하는 일. 이건 업무를 아는 사람만 할 수 있습니다.
AI가 만든 것을 검증하는 일.
AI가 그럴듯한 코드를 내놓아도, 그게 우리 시스템에서 안전한지, 성능 문제는 없는지, 업그레이드에 지장은 없는지 판단할 사람이 필요합니다.
판단하려면 알아야 하고요.
구조를 설계하는 일.
어디까지 표준을 쓰고 어디부터 확장할지, 그 확장을 어디에 둘지. 이런 아키텍처 판단은 여전히 사람의 몫입니다.
정리하면, 코드를 '생산'하는 역할에서 '판단하고 설계하는' 역할로 무게중심이 옮겨가고 있습니다.
낙관만 할 일은 아닙니다.
앞서 HR 글에서 다룬 문제가 여기서도 똑같이 나타납니다.
신입 개발자가 실력을 쌓던 과정이 바로 '단순한 코드부터 짜보는 것'이었는데, 그 구간을 AI가 가져가면 어디서 배울까요.
판단하고 검증하는 역할이 중요하다지만, 그 판단력은 직접 짜보고 틀려보면서 생깁니다.
시니어 개발자는 AI로 생산성이 크게 오르는 반면, 주니어가 성장할 발판은 좁아지는 구조입니다.
그래서 기업 입장에서는 "AI를 도입하면 개발 인력을 줄일 수 있다"가 아니라, "AI 시대에 개발자를 어떻게 키울 것인가"를 함께 고민해야 합니다.
AI가 ABAP을 짜는 시대는 이미 시작됐습니다.
다만 그것이 개발자를 대체하는 방향이 아니라, 개발자가 더 가치 있는 일에 시간을 쓰도록 만드는 방향이라는 점이 중요합니다.
반복적인 코드 작성과 레거시 해독에 쓰던 시간을, 업무를 이해하고 구조를 설계하는 데 쓸 수 있다면 — 그건 개발자에게도, 회사에도 좋은 변화입니다.
BSG는 26년간 수많은 기업의 SAP 시스템을 구축하고 운영해왔습니다.
커스텀 코드 정비나 S/4HANA 전환 준비를 고민 중이시라면, 편하게 이야기 나눠보시죠.
출처 : SAP 공식 제품 정보(Joule for Developers), SAP Community 2026 ABAP AI 로드맵
기획 : 도예원