SAP
연동

사내 데이터의 본진은 ERP

앞선 강에서 RAG로 끌어온 건 주로 문서다. 정책, 매뉴얼, 위키 같은 글이다.

그런데 “강남 창고 재고 얼마 남았나”, “B고객사 지난달 매출은” 같은 질문의 답은 문서가 아니라 ERP 안에 행과 열로 들어 있다. 한국 대기업이면 대개 SAP를 쓴다.

SAP는 모듈로 쪼개져 있다.
재고와 자재는 MM, 영업과 매출은 SD, 회계는 FI가 맡는다.
LLM이 사내 질문에 제대로 답하려면 이 살아 있는 운영 데이터에 닿아야 한다.

DB 직결 금지, 사이에 게이트웨이

LLM에 SAP DB 접속 정보를 그냥 쥐여주면 안 된다.

LLM은 시키면 뭐든 만들어 본다. 권한 없는 테이블도 긁으려 하고, 잘못된 쿼리로 운영 DB에 부하를 줄 수 있다.
그래서 LLM과 SAP 사이에 API 게이트웨이를 한 겹 끼운다. Azure API Management, AWS API Gateway, SAP 자체 OData나 BAPI처럼 정해진 통로만 노출한다.

LLM은 DB가 아니라 게이트웨이가 허용한 호출만 부른다.
“재고 조회”는 BAPI_MATERIAL_STOCK 같은 미리 정의된 함수로만 닿는다.
이 통로 밖은 LLM이 손도 못 댄다. 노출 범위를 우리가 못 박는 것이다.

게이트웨이가 하는 일, 권한과 감사

게이트웨이는 단순 통로가 아니라 검문소다. 호출 하나가 네 관문을 지난다.

인증은 누구의 질문인지 확인한다. SSO 토큰으로 본인을 못 박는다.
권한은 그 사람이 이 데이터를 봐도 되는지 본다. SAP 원래 권한인 역할과 스코프를 그대로 이어받는다.

마스킹은 봐도 되는 데이터라도 민감한 칸인 고객명, 마진, 주민번호를 가린다.
감사는 누가 언제 뭘 봤는지 로그에 남긴다. 막힌 시도까지 기록한다.

핵심은 LLM을 끼웠다고 권한 체계가 느슨해지면 안 된다는 것이다.
영업이 직접 SAP에서 못 보던 회계 데이터를 LLM 통한다고 볼 수 있으면 안 된다.
게이트웨이가 기존 권한을 그대로 강제해서 그 구멍을 막는다.

직접 흘려보기

질의자 역할과 자연어 질문을 고르면 게이트웨이 네 관문을 통과하는 모습이 보인다.

영업으로 매출을 물으면 권한이 맞아 SAP까지 닿고 결과가 온다.
외부 협력사로 같은 매출을 물으면 SCOPE 관문에서 막힌다. LLM이 아니라 게이트웨이가 막고, SAP 호출은 아예 가지도 않는다.

구매가 매출을 물어도 권한이 없어 막힌다.
권한이 있어도 민감 칸은 MASK에서 가려진 채 LLM에 전달된다.
통과든 차단이든 마지막 AUDIT에 기록이 남는 게 핵심이다.

실무는 읽기부터, 쓰기는 나중

어디부터 여는가. 읽기 전용 조회부터다.

재고와 매출 조회는 잘못돼도 운영에 상처가 안 남는다. 그래서 1차로 읽기 API만 게이트웨이에 노출한다.
여기서 자연어 질의가 정확한 숫자 답변으로 안정되게 도는지부터 검증한다.

발주나 재고 변경 같은 쓰기는 다르다. LLM이 멋대로 발주를 넣으면 진짜 돈이 나간다.
그래서 쓰기는 LLM이 초안만 만들고 사람이 확인하고 승인하는 단계를 반드시 끼운다. 자동 실행은 마지막이다.

정리하면 ERP 데이터를 잇되, 게이트웨이로 통로를 못 박고, 권한과 마스킹과 감사로 안전하게 노출한다.
그래야 “자연어로 재고와 매출 물어보기”가 사고 없이 사내에서 돈다.