OData가 없는 기존 ABAP 자산을 AI 도구로 재사용하는 법

1. 표준 API가 없는 업무는 어떻게 하나

앞선 두 글에서 SAP OData를 MCP 도구로 바꾸는 법과 CDS 분석 쿼리를 자연어로 물어보게 만드는 법을 다뤘습니다. 둘 다 표준 메타데이터가 있는 자산이 출발점이었습니다. OData는 $metadata, Analytical Query는 차원과 측정값 정의가 이미 기계가 읽을 수 있는 형태로 존재하니까요.

그런데 실제 기업 SAP에서 업무 가치의 상당 부분은 그 바깥에 있습니다.

• 수십 년간 쌓인 Z 리포트 - 여신 조회, 재고 마감, 정산 명세 같은 커스텀 프로그램
• 핵심 로직이 담긴 Function Module - 가격 계산, 신용 한도 판정, 세금 산출
• 업무 규칙을 감싼 Class Method
• OData로 노출된 적 없는 Z 테이블

이 자산들은 대개 SAP GUI에서만 실행됩니다. OData 서비스가 없으니 앞선 방식으로는 AI에 연결할 수 없습니다. 그렇다고 이걸 다 OData로 새로 감싸는 건 큰 프로젝트입니다. “AI에 붙이려고 인터페이스를 새로 만드는” 순간, 클린코어도 무너지고 중복 개발이 시작됩니다.

핵심 질문은 이겁니다. 기존 ABAP 자산을, 새 인터페이스를 만들지 않고, 그대로 AI 도구로 쓸 수 없을까?

2. 열쇠는 “파라미터를 읽어내는 것”

MCP 도구를 만들려면 도구의 입력 스키마가 필요합니다. 그리고 ABAP 오브젝트는 이미 자신의 시그니처를 시스템 딕셔너리에 갖고 있습니다. 새로 정의할 필요 없이, 읽어내면 됩니다.

• Function Module - 파라미터 정의가 FUPARAREF에 있습니다. 파라미터명, 방향(IMPORTING/EXPORTING/CHANGING/TABLES), 선택 여부, 기본값, 참조 구조까지.
• Class / Interface Method - 메서드 파라미터가 SEOSUBCODF에 있습니다. IMPORTING/EXPORTING/CHANGING/RETURNING 방향과 타입 정보가 담겨 있습니다.
• Report 프로그램 - 선택 화면(SELECT-OPTIONS/PARAMETERS)이 그 자체로 입력 명세입니다.
• DDIC 구조와 테이블 - 필드, 도메인, 데이터 엘리먼트로 타입이 정의돼 있습니다.

즉, SAP GUI에서 개발자가 F1을 눌러 확인하던 “이 오브젝트는 무엇을 입력받는가”가 이미 구조화된 데이터로 존재합니다. 이것을 읽어오는 것이 **introspection(내부 구조 조회)**이고, MCP 도구화의 출발점입니다.

3. 시그니처 → MCP 도구 스키마

Function Module 하나를 예로 들면, 시그니처를 읽어 아래처럼 정리할 수 있습니다.

Function: Z_CREDIT_LIMIT_CHECK
  IMPORTING  IV_CUSTOMER   (KUNNR)      필수
  IMPORTING  IV_COMPANY    (BUKRS)      필수
  EXPORTING  EV_LIMIT      (Amount)
  EXPORTING  EV_AVAILABLE  (Amount)
  TABLES     ET_OPEN_ITEMS (structure)

이 시그니처의 IMPORTING 파라미터가 그대로 MCP 도구의 입력 스키마가 됩니다.

{
  "name": "run_z_credit_limit_check",
  "description": "거래처의 여신 한도와 가용 한도를 조회합니다.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "customer": { "type": "string", "description": "거래처 코드 (KUNNR)" },
      "company":  { "type": "string", "description": "회사 코드 (BUKRS)" }
    },
    "required": ["customer", "company"]
  }
}

Report나 Class Method도 원리는 같습니다. 선택 화면 파라미터, 메서드 IMPORTING 파라미터를 읽어 입력 스키마를 만들고, 실행 결과(EXPORTING/TABLES/스풀)를 도구의 출력으로 돌려줍니다. 기존 오브젝트를 손대지 않고, 그 위에 얇은 실행 계층만 얹는 방식입니다.

결과적으로 “이 거래처의 여신 한도를 확인해줘”라는 질문에, 모델은 기존 Z Function Module을 그대로 호출해 답합니다. 새 OData 서비스를 만들 필요가 없습니다.

4. 강력한 만큼, 실행은 통제되어야 한다

기존 ABAP을 실행할 수 있다는 건 강력합니다. 그리고 강력한 만큼, “무엇이든 실행”이 아니라 “허용된 것만 실행”이어야 합니다. 통제 없이 열면 그건 솔루션이 아니라 리스크입니다. 실제 구현에서 통제는 두 축으로 걸립니다.

첫째, SQL은 읽기 전용입니다. 테이블 조회는 동적 SQL로 처리하되, 쿼리를 토큰 단위로 검사해 첫 토큰이 SELECT가 아니거나 DELETE, INSERT, UPDATE, MODIFY, DROP, CALL 같은 변경이나 실행 토큰이 하나라도 있으면 즉시 거부합니다. 문자열 부분 일치가 아니라 토큰 전체 비교라, UPDATED_ON 같은 컬럼명이 UPDATE로 오인되거나 우회되지 않습니다.

SELECT kunnr, name1 FROM kna1 WHERE land1 = 'KR'   → 허용
UPDATE kna1 SET name1 = ...                         → 거부 (변경성)
SELECT ... ; DROP TABLE ...                          → 거부 (금지 토큰)

둘째, 실행 대상은 allowlist로 제한합니다. 어떤 Report, Function, Class를 실행할 수 있는지는 별도의 허용 목록 테이블로 관리합니다. 오브젝트 타입별로 패턴(예: Z_CREDIT_*)을 등록하고, 활성화된 패턴에 매칭되는 오브젝트만 호출을 허용합니다. 목록에 없으면 실행되지 않습니다.

여기에 실행 계층 앞단의 사용자별 인증과 권한, 그리고 호출 로그가 더해집니다. 누가, 어떤 도구를, 어떤 파라미터로 호출해 무엇을 받았는지가 남습니다. 이 인증과 감사 축은 별도 글에서 자세히 다루겠습니다.

5. 세 방식은 경쟁이 아니라 보완이다

정리하면, SAP 자산을 AI에 연결하는 길은 하나가 아닙니다.

자산	연결 방식	성격
표준 OData 서비스	메타데이터 → MCP	업무 트랜잭션 API
CDS Analytical Query	차원, 측정값 → MCP	집계와 분석
기존 Report, FM, Class	시그니처 → MCP	레거시 자산 재사용

표준 API가 있는 업무는 OData와 CDS로 코어 변경 없이 처리하고, 표준 API가 없는 기존 자산은 introspection으로 재사용합니다. 신규 요건이 들어와도 바로 새 프로그램이나 인터페이스를 만들기 전에, 먼저 기존 Report, FM, Class, DDIC를 탐색해 조합하는 순서가 됩니다. 정말 새로운 데이터 구조나 로직이 필요할 때만 개발로 넘어갑니다.

이 “기존 자산 먼저” 접근이 중요한 이유는 명확합니다. 기업이 수십 년간 축적한 ABAP 자산은 AI 시대에 폐기 대상이 아니라, 재사용 가능한 도구 카탈로그이기 때문입니다.

마무리

OData와 CDS가 “표준 API가 있는 SAP”를 AI에 연결한다면, ABAP introspection은 그 바깥의 레거시 자산을 연결합니다. 원리는 단순합니다 - 오브젝트가 이미 갖고 있는 시그니처를 읽어 도구 스키마로 바꾸고, 실행은 SELECT 전용과 allowlist로 통제하는 것.

LITEWAY의 IntelliGateway는 이 introspection과 통제된 실행을 SAP 표준 기술 위에서 제공합니다. 기존 자산을 버리지 않고, 새 인터페이스를 만들지 않으면서 AI가 활용할 수 있게 하는 것 - 그것이 Intellidesk가 지향하는 방향입니다.