데이터 플랫폼과 AI — AI 에이전트가 일하려면 무엇이 먼저 있어야 하나
AI는 회사 데이터 앞에서 왜 자주 멈추나
생성형 AI를 사내 데이터에 연결해 보면 비슷한 장면을 자주 만납니다. 질문은 잘 알아듣는데 답이 틀리거나, 그럴듯한 숫자를 내놓았는데 근거를 따라가 보면 실제 데이터에 없는 값입니다. 처음에는 모델 탓을 하게 되지만, 들여다보면 원인은 대개 데이터 쪽에 있습니다.
의미를 모른다. "매출총이익"에 원가차이가 포함되는지, 어느 계정이 매출차감인지 같은 회사 고유의 정의가 데이터에 붙어 있지 않습니다.
연결을 모른다. 공급사와 자재, 자재와 완제품, 완제품과 수주가 어떻게 이어지는지 테이블 이름만 봐서는 알 수 없습니다.
누가 묻는지 모른다. 같은 질문이라도 사람마다 볼 수 있는 범위가 다른데, AI가 그 경계를 지키지 못하면 연결 자체를 허용할 수 없습니다.
SAP도 같은 이야기를 합니다. 2026년 Business AI 전략을 설명하며, AI의 미래는 모델이 아니라 업무 맥락을 제공할 수 있는 데이터 기반에서 시작한다고 정리했습니다. 저희가 지난 몇 달간 직접 구축하고 검증하며 내린 결론도 다르지 않습니다.
AI를 위한 데이터 플랫폼의 다섯 개 층
AI 에이전트가 회사 데이터로 일하려면, 아래 다섯 개 층이 아래에서 위로 차례대로 갖춰져야 합니다.
1. 데이터 통합 — 필요한 데이터가 한곳에서 보이는가
ERP, 외부 시스템, 분석 플랫폼에 흩어진 데이터를 복제하지 않고 함께 볼 수 있어야 합니다. 데이터 프로덕트와 Zero-Copy 공유가 이 층의 핵심입니다.
→ BW에서 BDC로 — 무엇을 버리고 무엇을 가져가나 · SAP 데이터를 Snowflake와 연결하는 방법들
2. 의미(시맨틱) — 숫자가 무엇을 뜻하는지 정의되어 있는가
지표의 정의, 계정의 분류, 코드의 명칭이 데이터와 함께 다녀야 합니다. 이 층이 비어 있으면 AI는 이름만 보고 추측합니다. 실제로 거래유형 코드의 텍스트를 넘겨주지 않았더니 모델이 영문 이니셜로 의미를 짐작해 틀리게 설명한 경험이 있습니다.
3. 관계 — 데이터가 어떻게 이어지는지 알고 있는가
여러 단계를 건너는 질문("이 공급사가 멈추면 어떤 수주까지 영향을 받나")은 관계가 데이터로 표현되어 있어야 답할 수 있습니다. 지식그래프가 이 층을 담당하고, 그 구축 과정 자체가 데이터 품질 진단이 되기도 합니다.
→ ERP 데이터에 지식그래프를 얹으면 무엇이 달라지나
4. 권한·통제 — 누가 무엇을 볼 수 있는지 지켜지는가
AI가 사용자 대신 데이터를 조회할 때도 원래의 권한 체계가 그대로 적용되어야 하고, 무엇을 조회했는지 기록이 남아야 합니다. 이 층이 없으면 기술적으로 연결할 수 있어도 운영에 올릴 수 없습니다.
5. 에이전트 접점 — AI가 데이터에 닿는 표준 통로가 있는가
MCP(Model Context Protocol)처럼 AI가 도구를 발견하고 호출하는 표준 통로입니다. 중요한 것은 통로 자체보다 그 통로 뒤에서 서버가 무엇을 책임지느냐입니다. 집계·권한 확인·근거 반환을 서버가 맡아야 에이전트의 답이 안정됩니다.
→ Joule Agent와 MCP로 S/4HANA에 자연어로 질문하기
플랫폼별로 다섯 개 층을 어떻게 채우나
주요 데이터 플랫폼은 이 다섯 개 층을 각자의 방식으로 채우고 있습니다. 아래는 2026년 10월 기준 대표 구성요소를 정리한 것입니다. 기능과 출시 상태는 빠르게 바뀌므로, 도입 시점에 각 사 문서로 다시 확인하는 것을 권합니다.
층 | SAP Business Data Cloud | Snowflake | Databricks |
|---|---|---|---|
데이터 통합 | SAP 관리형 데이터 프로덕트, Datasphere, Snowflake·Databricks 등과 Zero-Copy 공유 | BDC Connect for Snowflake(Zero-Copy), 외부 데이터 수집 | SAP Databricks(BDC 내 통합), Delta Sharing |
의미 | 데이터 프로덕트에 실린 SAP 업무 의미 정보, Datasphere 분석 모델 | Semantic View | Unity Catalog 메트릭 뷰 |
관계 | SAP Knowledge Graph, HANA Cloud 지식그래프 엔진 | 별도 구성 | 별도 구성 |
권한·통제 | S/4HANA 권한 체계(CDS 접근 제어), BDC 거버넌스 | 역할 기반 접근 제어(RBAC), 도구 단위 권한 | Unity Catalog 거버넌스 |
에이전트 접점 | Joule Agents, Joule Studio(MCP 서버를 도구로 연결) | Cortex Agents, Snowflake 관리형 MCP 서버 | Genie 등 에이전트 기능, 메트릭 뷰 연계 |
표를 읽는 관점은 하나입니다. SAP 데이터의 가장 큰 자산은 업무 의미가 처음부터 붙어 있다는 점입니다. 계정 체계, 조직 구조, 프로세스 흐름이 데이터 모델 안에 이미 들어 있습니다. 다른 플랫폼으로 데이터를 가져갈 때 숫자만 옮기고 이 의미를 두고 오면, 2번 층을 처음부터 다시 만들어야 합니다. 그래서 어느 플랫폼을 쓰든 "의미를 함께 옮기는 방식"이 선택 기준이 되어야 합니다.
도입 순서 — "AI부터"가 아니라 "아래층부터"
AI 과제를 시작할 때 흔히 에이전트 화면부터 만듭니다. 시연은 빨리 되지만, 운영으로 넘어가는 순간 아래층의 빈자리가 한꺼번에 드러납니다. 저희가 권하는 순서는 반대입니다.
데이터 정리 — 쓰지 않는 데이터를 걷어내고, 필요한 데이터를 데이터 프로덕트 단위로 정리합니다.
의미 정의 — 핵심 지표 10~20개의 정의를 현업과 합의해 데이터에 붙입니다.
관계·품질 점검 — 마스터 간 연결을 확인하고, 미배부·더미 마스터 같은 품질 문제를 먼저 드러냅니다.
권한 설계 — AI 채널에서도 원래 권한이 지켜지는 구조를 확정합니다.
에이전트 연결 — 마지막에 에이전트를 붙이고, 답이 원천과 일치하는지 대조하며 범위를 넓힙니다.
이 순서로 가면 에이전트를 붙이는 마지막 단계가 오히려 가장 짧습니다.
앞으로의 연재
이 글을 지도로 삼아, 매주 한 편씩 각 층을 더 깊이 다룰 예정입니다.
층 | 다룰 주제 |
|---|---|
데이터 통합 | BDC 데이터 프로덕트 실전 — 관리형과 커스텀, 무엇을 언제 쓰나 |
의미 | 원가차이를 자재 단위로 쪼개기 — 마진 드라이버 트리 설계 |
관계 | AI 도입 전 ERP 데이터 건강검진 — 정합성 진단 규칙 / 공급망 영향 분석을 지식그래프로 |
권한·통제 | AI에게 권한을 어떻게 물려주나 — Principal Propagation과 CDS 접근 제어 / MCP 서버 운영의 숨은 일 |
에이전트 접점 | SAC Planning에 Joule이 들어오면 / SAP 데이터 위의 Snowflake Cortex |
참고
SAP News, SAP Business AI Platform and Business Data Cloud 발표
Snowflake Documentation, Snowflake-managed MCP server
Databricks Documentation, Unity Catalog metric views
The Paypers, Databricks launches SAP Databricks in partnership with SAP
글쓴이 Data&AI — ASPN BAC사업부에서 SAP BDC·Datasphere, 지식그래프, Joule·MCP 기반 AI Agent 구축을 다룹니다. 직접 구성하고 검증하며 얻은 실무 경험을 정리해 공유합니다.