AI를 ERP에 붙이는 건 커넥터 문제가 아니다

기업의 AI 활용이 확산되면 현업은 단순 질의를 넘어 데이터 조회, 리포트 실행, 장애 분석, 개발 요청까지 AI에게 맡기게 됩니다. 이때 필요한 것은 커넥터 하나가 아니라, 인증과 정책과 감사를 갖춘 ERP Agentic Control Plane입니다. 그 구조를 정리합니다.

1. 곧 현업은 ERP에 이런 것들을 요구한다

기업에서 생성형 AI 활용이 자리를 잡으면, 요구는 빠르게 진화합니다. 처음에는 문서 요약과 질의응답으로 시작하지만, 곧 현업은 AI에게 이런 것들을 맡기고 싶어 합니다.

“이번 달 사업부별 손익을 전월과 비교해줘” (데이터 분석)
“판매오더 12345의 납품과 청구 상태를 확인해줘” (업무 조회)
“이 여신 조회에 쓰이는 기존 Function을 찾아 실행해줘” (레거시 실행)
“장애가 난 이 프로그램의 관련 테이블과 로그를 정리해줘” (운영 분석)
“신규 관리 리포트 초안을 만들고 문법 체크까지 해줘” (개발 요청)

질의응답에서 데이터로, 데이터에서 실행으로, 실행에서 개발로. 이 흐름은 예외 없이 반복됩니다. 그리고 이 요구를 각 팀이, 각 AI 모델별로, 제각각 해결하기 시작하면 문제가 생깁니다.

2. 커넥터가 난립하면 통제가 무너진다

가장 흔한 실패 패턴은 이렇습니다. A팀은 ChatGPT에 맞춰 커넥터를 만들고, B팀은 Claude용으로 다시 만들고, 어떤 팀은 급하니 공용 계정으로 SAP GUI를 자동화합니다. 시스템마다, 모델마다, 팀마다 연결 방식이 늘어납니다.

이렇게 되면 네 가지가 동시에 나빠집니다.

보안 - 연결점이 많아질수록 통제해야 할 표면이 넓어집니다.
권한 - 공용 계정과 과다 권한이 곳곳에 생깁니다.
감사 - 누가 무엇을 했는지 일관되게 추적할 수 없습니다.
유지보수 - 비슷한 커넥터와 커스텀 개발이 중복으로 쌓입니다.

문제의 본질은 커넥터의 품질이 아닙니다. 연결을 통제하는 공통 계층이 없다는 것입니다. 그래서 이건 “더 좋은 커넥터를 만들자”로 풀리지 않습니다. 필요한 것은 통제 계층, 곧 Control Plane입니다.

3. ERP Agentic Control Plane의 구조

해법은 개별 연결을 하나의 통제된 계층으로 표준화하는 것입니다. 전체 구조는 네 개의 층으로 정리됩니다.

AI 에이전트 (ChatGPT / Claude / Gemini / 사내 에이전트)
        │
        ▼
인증 / 정책 / 감사 계층
   - 사용자별 인증 (OAuth / SSO)
   - SAP 권한 연계
   - 도구 허용 목록 (Allowlist)
   - 승인 워크플로우
   - 감사 로그
        │
        ▼
ERP-MCP Gateway
   - 분석 쿼리 도구
   - 업무 API 도구
   - 레거시 자산 실행 도구
   - 개발 자동화 도구
        │
        ▼
SAP S/4HANA / ECC / 각 시스템

여기서 가장 중요한 것은 인증과 정책과 감사 계층이 게이트웨이 앞에 반드시 있다는 점입니다. 게이트웨이의 기능이 강력할수록, 통제 계층 없이는 그 자체가 리스크가 됩니다. 순서가 뒤바뀌면 안 됩니다.

4. 각 층은 이미 이 시리즈에서 다뤘다

이 구조의 각 조각은 앞선 글들에서 하나씩 짚었습니다.

역할	무엇을 하는가	관련 글
업무 API	표준 OData를 AI 액션 도구로	OData를 MCP로
분석	CDS 분석 쿼리를 자연어로	분석 쿼리를 MCP로
레거시 재사용	기존 Report, FM, Class 실행	기존 ABAP 자산 재사용
개발 자동화	ABAP 초안 생성과 문법 체크	통제된 ABAP 개발
인증과 감사	사용자별 접근 통제	공용 계정을 쓰지 마라

각각은 개별 도구가 아니라 하나의 통제 계층 위에서 동작하는 구성 요소입니다. 분석과 업무 API는 표준 인터페이스를 코어 변경 없이 연결하고, 레거시 재사용과 개발 자동화는 표준 API가 없는 영역을 통제된 방식으로 확장합니다. 그리고 그 앞을 인증과 감사가 지킵니다.

5. 강력함과 통제를 함께 두는 법

이 계층이 신뢰를 얻으려면, “무엇까지 허용할지”를 먼저 말할 수 있어야 합니다. 실행 권한을 단계로 나누면 강력함과 통제를 동시에 설명할 수 있습니다.

단계	허용 범위	적용
조회	오브젝트와 메타데이터 조회	전 시스템
읽기 실행	SELECT 조회, 조회성 실행	운영계 제한 허용
통제 실행	지정된 실행성 도구 호출	승인 기반
개발	커스텀 오브젝트 생성, 문법 체크	개발계 한정
운영 반영	Transport, 운영 이관	사람 승인과 품질 검사 필수

이렇게 나누면 “강력한데 위험한 도구”가 아니라 “강력하지만 통제 가능한 플랫폼”이 됩니다. 조직은 낮은 단계부터 열고, 신뢰가 쌓이는 만큼 범위를 넓힐 수 있습니다.

이 관점은 SAP의 클린코어 원칙과도 맞습니다. 표준 API로 가능한 업무는 코어 변경 없이 처리하고, 개발이 필요한 경우에도 개발계에서 생성과 검증, 승인을 거치는 통제된 방식으로 다룹니다. 신규 요건이 들어와도 바로 새 프로그램을 만들지 않고, 먼저 기존 자산을 탐색해 조합하는 순서가 자연스럽게 자리 잡습니다.

마무리

AI를 ERP에 연결하는 일의 핵심은 커넥터의 개수나 품질이 아닙니다. 늘어나는 연결을 하나의 인증과 정책과 감사 아래 세우는 것입니다. 그럴 때 기업은 팀마다 모델마다 커넥터가 난립하는 혼란 대신, 통제된 하나의 계층 위에서 AI 활용을 확장할 수 있습니다.

분석, 업무 API, 레거시 자산, 개발 자동화, 그리고 인증. 이 다섯을 하나의 통제 계층으로 묶는 것이 ERP Agentic Control Plane이고, LITEWAY가 제안하는 AI 시대의 SAP 운영 방식입니다.