AI가 ABAP 개발 초안을 만들고 문법 체크까지, 통제된 방식으로

1. 조회와 실행을 넘어, 이제는 생성

앞선 글에서 기존 ABAP 자산을 AI 도구로 재사용하는 법을 다뤘습니다. 파라미터를 읽어 실행하는 것까지가 거기서의 범위였습니다.

그런데 현업의 요구는 조회와 실행에서 멈추지 않습니다.

“신규 관리 리포트 초안을 만들어줘. 필요한 DDIC 구조와 메시지 클래스도 생성하고 문법 체크까지 해줘.”

이건 개발입니다. 그리고 여기서 대부분의 SAP 운영 조직이 긴장합니다. “AI가 SAP 안에 프로그램을 막 만든다고?“라는 우려가 먼저 나오기 때문입니다. 이러한 우려는 당연합니다. 그래서 이 글의 절반은 “무엇을 만들 수 있는가”이고, 나머지 절반은 “어떻게 통제하는가”입니다. 통제 없는 생성 기능은 솔루션이 아니라 사고의 원인입니다.

2. AI가 생성할 수 있는 ABAP 자산

핵심은 새로운 마법이 아니라, SAP가 이미 제공하는 표준 생성 API를 도구로 감싸는 것입니다. SAP GUI에서 개발자가 트랜잭션으로 하던 생성 작업에는 대부분 대응하는 표준 함수가 있습니다.

• Program / Include - 소스를 기록하고 생성
• DDIC 도메인, 데이터 엘리먼트 - 표준 딕셔너리 API로 정의하고 활성화
• DDIC 테이블, 구조 - 필드 정의로 테이블이나 구조를 생성
• 메시지 클래스 - 메시지 헤더와 개별 메시지를 등록
• Function Module, 글로벌 Class - 시그니처와 소스로 생성

여기에 더해 문법 체크가 있습니다. 생성했거나 수정한 소스를 SAP의 구문 검사에 걸어 오류의 라인과 메시지를 돌려받습니다. 이 검사는 시스템을 바꾸지 않습니다. 순수하게 “이 소스가 문법적으로 유효한가”만 확인합니다.

{
  "hasErrors": true,
  "results": [
    { "line": 42, "severity": "E", "text": "필드 GV_AMOUNT 이(가) 선언되지 않았습니다." }
  ]
}

3. Engineering Loop: 생성에서 검증까지

이 기능들을 하나로 엮으면 반복적인 개발 흐름이 만들어집니다.

1. 생성 - 요구사항에서 리포트나 DDIC, 메시지 클래스 초안을 생성
2. 문법 체크 - 생성한 소스를 구문 검사에 걸어 오류를 확인
3. 수정 반복 - 오류가 있으면 고쳐서 다시 검사
4. Diff 검토 - 사람이 변경 내용을 확인
5. Transport 연계 - 승인 후 표준 Transport로 이관

여기서 중요한 것은 1에서 3까지가 자동으로 순환할 수 있다는 점입니다. AI가 초안을 만들고, 문법 오류를 스스로 확인해 고치는 루프가 돕니다. 하지만 4와 5, 즉 사람의 검토와 운영 이관은 자동화 대상이 아닙니다. 이 경계가 통제의 핵심입니다.

4. 이건 “GUI 자동화”가 아니다

여기서 표현을 분명히 할 필요가 있습니다. 이 방식은 SAP GUI 화면을 대신 클릭해주는 자동화가 아닙니다. 화면을 흉내 내는 것이 아니라, SAP가 공식적으로 제공하는 생성 API를 MCP 도구로 재구성하는 것입니다.

이 차이는 실무에서 큽니다. GUI 자동화는 화면이 바뀌면 깨지고, 무엇이 실행됐는지 추적하기 어렵습니다. 반면 표준 API 기반 방식은 SAP가 보장하는 경로로 동작하고, 어떤 오브젝트를 어떤 파라미터로 생성했는지가 명확히 남습니다. “SAP GUI를 AI에게 열어주는 것”과 “SAP의 개발 기능을 정책 기반 도구로 바꾸는 것”은 전혀 다른 이야기입니다.

5. 통제가 먼저다

생성 기능이 안전하려면 몇 가지 원칙이 반드시 전제되어야 합니다. 실제 구현에서 이 원칙들은 선택이 아니라 코드에 박힌 제약입니다.

커스텀 오브젝트만 생성합니다. 생성 요청은 이름이 Z나 Y로 시작하는 커스텀 오브젝트만 허용합니다. 표준 SAP 오브젝트는 생성하거나 덮어쓸 수 없습니다. 요청이 이 규칙을 어기면 어떤 생성 경로로도 넘어가기 전에 거부됩니다.

개발계에서만 생성합니다. 생성과 변경성 작업은 개발 시스템에 한정됩니다. 운영계는 원칙적으로 읽기와 허용된 실행 중심이고, 직접 생성이나 변경은 막습니다.

운영 반영은 기존 절차를 따릅니다. 생성한 오브젝트를 운영에 올리는 것은 AI의 몫이 아닙니다. 로컬 임시 패키지가 아니라면 표준 Transport 체계로 연계되고, 그 뒤의 코드 리뷰, 품질 검사(ATC), 승인은 기존 프로세스를 그대로 거칩니다.

모든 작업이 기록됩니다. 누가 어떤 오브젝트를 어떤 소스로 생성하고 검사했는지가 로그로 남습니다.

정리하면, 올바른 표현은 이렇습니다. “AI가 SAP에 프로그램을 만든다”가 아니라, “허용된 사용자가 개발계에서 커스텀 오브젝트 초안을 생성하고, 운영 반영은 승인과 품질 검사를 거친다”입니다.

6. 대체가 아니라 선처리

이 자동화의 목적은 ABAP 개발자를 대체하는 것이 아닙니다. 신규 리포트, 단순 조회 프로그램, 메시지 클래스, DDIC 구조 같은 반복적이고 정형화된 작업을 AI가 초안까지 만들어 두면, 개발자는 설계와 품질 판단이라는 더 가치 있는 일에 집중할 수 있습니다.

장애 대응에서도 마찬가지입니다. 관련 DDIC와 프로그램, Function을 찾아보고, 테스트 값으로 실행하고, 로그를 확인하던 여러 단계를 AI가 한 흐름으로 정리하면, 1차 원인 분석 시간이 줄어듭니다.

마무리

AI에게 SAP 개발을 맡기는 일의 핵심은 “얼마나 많이 만들 수 있는가”가 아니라 “어디까지 통제되는가”입니다. 커스텀 오브젝트만, 개발계에서, 문법 체크를 거쳐 초안을 만들고, 운영 반영은 사람의 승인과 품질 검사에 맡기는 것. 이 경계가 분명할 때 개발 자동화는 리스크가 아니라 생산성이 됩니다.

LITEWAY의 IntelliGateway는 이 통제된 Engineering Loop를 SAP 표준 기술 위에서 제공합니다. S/4HANA에서는 표준 API를 기반으로 하고, ECC에서는 LITEWAY의 IntelliGateway를 통해 S/4HANA와 동일한 경험을 제공합니다.강력한 기능과 분명한 통제를 함께 두는 접근이 Intellidesk가 지향하는 방향입니다.