오늘 끝나면

SAP 연동

  • SAP 연동의 핵심 문제를 한 문장으로 설명한다
  • 오른쪽 실습에서 SAP이 어떻게 움직이는지 관찰한다
  • 다음 강의와 이어지는 한계를 말할 수 있다

실습 미션

ERP 데이터를 LLM에 — Azure Gateway 이 문장이 실제로 무슨 뜻인지 실습에서 한 번 손으로 확인한다.

성공 조건

  • 실습의 기본값을 먼저 관찰
  • 입력값이나 모드를 한 번 이상 바꿔 결과 비교
  • 왜 결과가 바뀌었는지 한 문장으로 설명

Enterprise LLM · 09

SAP
연동

사내 데이터의 진짜 본진은 ERP — 대개 SAP임.
재고·매출·발주가 거기 들어 있음. LLM이 이걸 자연어로 답하게 하는 게 목표임.
단, DB를 직접 열어주는 게 아니라 게이트웨이를 한 겹 끼워 권한·감사를 지키며 노출함.

P.01Enterprise LLM · 09

사내 데이터의 본진은 ERP

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

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

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

흩어진 사내 지식 vs SAP 안의 운영 데이터
답이 어디 있나 — 문서 vs ERP
글로 된 것
정책 · 매뉴얼문서 (RAG로 검색)
사내 위키 · PDF문서 (RAG로 검색)
행·열로 된 것 — SAP 안
MM자재·재고강남창고 A제품 120개
SD영업·매출B고객사 3월 4,200만
FI회계미수금 · 마진

재고·매출 질문의 답은 문서가 아니라 여기 있음

P.02Enterprise LLM · 09

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

그럼 LLM에 SAP DB 접속 정보를 그냥 쥐여주면 되나? 절대 안 됨.

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

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

LLM이 DB를 직접 여는 건 위험 · 한 겹을 끼움
직결(위험) vs 게이트웨이 경유(안전)
✕ LLM이 DB 직결
LLMSAP DB

권한 무시 · 아무 테이블 · 잘못된 쿼리로 운영 DB 부하

✓ 게이트웨이 경유
LLM게이트
웨이
SAP
정해진 API 호출만 노출
BAPI_MATERIAL_STOCK 같은 함수만
통로 밖은 LLM이 손 못 댐
P.03Enterprise LLM · 09

게이트웨이가 하는 일 — 권한·감사

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

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

마스킹은 봐도 되는 데이터라도 민감한 칸(고객명·마진·주민번호)을 가림.
감사는 누가·언제·뭘 봤는지 로그에 남김. 막힌 시도까지 기록됨.

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

인증 → 권한 → 마스킹 → 감사 네 관문
게이트웨이 = 검문소 · 호출 하나가 네 관문
1인증누구냐SSO 토큰으로 본인 확정
2권한봐도 되나SAP 역할·스코프 그대로 이어받음
3마스킹민감칸 가렸나고객명·마진·주민번호 가림
4감사기록했나누가·언제·뭘 — 막힌 시도까지

LLM 끼워도 기존 권한은 그대로 강제됨

P.04Enterprise LLM · 09

직접 흘려보기

오른쪽에서 직접 흘려 보셈.
질의자 역할과 자연어 질문을 고르면 게이트웨이 네 관문을 통과하는 모습이 보임.

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

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

역할·질문을 정하면 게이트웨이가 거른다
SAP 연동 흐름 · 게이트웨이가 거른다
질의자 역할
자연어 질의
질의 → LLM → 게이트웨이 → SAP
사용자영업 · 자연어
LLM질의를 호출로 번역
API 게이트웨이
AUTH인증 — 누구냐토큰 확인 · 영업로 로그인됨
SCOPE권한 — 이 데이터 봐도 되나inventory.read 보유 · 통과
MASK마스킹 — 민감정보 가림민감정보 없음
AUDIT감사 — 누가 뭘 봤나 기록영업 → BAPI_MATERIAL_STOCK 기록됨
SAP ERPBAPI_MATERIAL_STOCK 호출
LLM이 받는 결과
데이터 반환

영업 권한으로 MM 재고관리에 닿음. 게이트웨이가 BAPI_MATERIAL_STOCK만 호출하고 그 내역을 감사로그에 남김.

P.05Enterprise LLM · 09

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

그럼 어디부터 여나? 정답은 읽기 전용 조회부터임.

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

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

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

Q. SAP 연동에서 게이트웨이의 역할은? (DB 비번 전달 · 권한·감사 거쳐 안전하게 노출 · 모델 학습 · 문서 검색)정답은 권한·감사를 거쳐 안전하게 데이터 노출임.
게이트웨이는 LLM이 SAP DB를 직접 열지 못하게 사이를 막고, 정해진 API 호출만 통과시킴.
그 통과 과정에서 인증·권한 확인 → 민감정보 마스킹 → 감사로그 기록을 강제함. 기존 SAP 권한이 LLM을 통해도 새지 않게 지키는 게 핵심임.
DB 비번을 LLM에 넘기는 건 정확히 게이트웨이를 두는 이유의 반대임.
조회는 빨리 · 변경은 사람 확인을 끼워
조회부터 · 변경은 사람 확인을 끼워
읽기 조회1차
위험 낮음
재고·매출 자연어 질의
사람 확인 불필요
쓰기 변경나중
위험 높음
발주·재고 수정
사람 승인 단계 필수
잘못돼도 안 다치는 것부터 연다

3줄 요약

  1. 1ERP 데이터를 LLM에 — Azure Gateway
  2. 2SAP 연동은 도입 방식 → RAG·연동 → SAP → 보안·거버넌스 → 운영 흐름 안의 한 칸이다.
  3. 3개념을 외우는 것보다 입력을 바꾸면 무엇이 달라지는지 보는 것이 우선이다.

완료 전 점검

복습 카드

SAP

ERP 데이터를 LLM에 — Azure Gateway

RAG

사내 문서를 검색해 답을 보강하는 방식

임베딩

의미를 숫자 벡터로 바꾼 표현