ERP 데이터에 지식그래프를 얹으면 무엇이 달라지나

왜 지식그래프인가

SAP는 BDC와 함께 HANA Cloud의 지식그래프 엔진(Knowledge Graph Engine)을 AI 에이전트의 기반 요소로 내세우고 있습니다. RDF 트리플로 데이터를 저장하고 SPARQL로 질의하는 방식이며, HANA Cloud 안에서 관계형·벡터 엔진과 함께 동작합니다.

그런데 ERP 데이터는 이미 관계형 테이블에 잘 정리되어 있습니다. 굳이 그래프로 옮겨야 할 이유가 무엇일까요?

저희가 찾은 답은 "여러 단계를 건너는 질문" 입니다.

"이 공급업체에서 문제가 생기면, 어떤 구성품을 거쳐 어떤 완제품과 어떤 수주까지 영향을 받는가?"

이 질문은 공급업체 → 구성품 → BOM → 완제품 → 수주로 4~5단계를 건넙니다. SQL로도 풀 수 있지만 조인이 질문마다 달라지고, AI 에이전트가 매번 올바른 조인 경로를 만들어 내기를 기대하기 어렵습니다. 그래프에서는 관계 자체가 데이터이므로 "따라가라"는 질의 하나로 끝납니다.

ASPN BAC 사업부는 S/4HANA 테스트 테넌트의 수익성 분석(CO-PA) 데이터를 BDC 데이터 프로덕트로 추출하고, 이를 HANA Cloud 지식그래프로 구축해 AI 에이전트에 연결하는 작업을 진행했습니다. 아래는 그 과정에서 정리한 원칙들입니다.

원칙 1. 금액은 그래프에 묻지 않는다

처음에는 모든 것을 그래프로 옮기려 했습니다. 손익 전표 한 줄 한 줄을 노드로 만들고, 제품·고객·조직과 연결했습니다. 질의는 잘 돌아갔습니다. 문제는 답이 틀렸는데 틀린 줄 모른다는 것이었습니다.

손익 전표 중에는 제품이나 사업부가 비어 있는(미배부) 줄이 적지 않습니다. 관계형 집계에서는 이런 줄이 "미배부" 한 줄로 나타나지만, 그래프에서는 연결할 대상이 없으니 관계 자체가 만들어지지 않습니다. 그 결과 "제품별 마진 합계"를 물으면 미배부분이 소리 없이 빠진 부분합이 나오고, 사용자는 그것을 전체로 받아들입니다.

저희는 이것을 "조용한 누락" 이라고 부릅니다. 테스트 테넌트에서 사업부 축은 미배부 건수가 전체의 4분의 1 정도였지만, 금액으로는 배부분만 보면 실제 합계의 4배가 넘는 손실로 보였습니다. 미배부 금액이 반대 부호였기 때문입니다. 건수로는 멀쩡해 보이는데 부호와 규모가 뒤집히는 형태라 눈으로 잡기 어렵습니다.

그래서 역할을 나눴습니다.

그리고 이 경계를 문서가 아니라 도구로 강제했습니다. AI 에이전트용 그래프 조회 도구는 금액 속성을 질의하려 하면 거부하고, 대신 집계 도구를 쓰라고 안내합니다. "그래프에서 금액을 묻지 말라"는 지침은 AI가 무시할 수 있지만, 경로가 없으면 무시할 수 없습니다.

원칙 2. 지식그래프의 가장 큰 쓸모는 "정합성 점검"이다

예상하지 못한 수확은 데이터 품질 진단이었습니다. 그래프를 만들려면 모든 참조가 실제 마스터에 연결되어야 하는데, 그 과정에서 관계형 리포트로는 보이지 않던 문제가 드러났습니다.

저희가 규칙으로 정리한 점검 항목 중 일부입니다.

• 마스터 미등록 참조 — 전표가 가리키는 손익센터·계정이 마스터에 없음

• 차원 미배부 왜곡 — 미배부 건수는 적은데 금액 영향이 큰 축

• 무의미한 명칭 — 마스터 명칭 자리에 코드가 그대로 들어가 있음

• 테스트·더미 마스터의 실거래 — "Dummy" 원가센터에 원가차이 대부분이 전기되어 있음

• 재무제표 구조(FSV) 대조 — 손익 분류가 재무제표 계정 구조와 어긋나는 계정

특히 마지막 두 가지는 경영 리포트의 신뢰도에 직결됩니다. 원가센터별 원가 분석 화면이 아무리 잘 만들어져 있어도, 원가의 90%가 더미 원가센터에 쌓여 있다면 그 화면은 의미가 없습니다.

이 규칙들은 코드에 하드코딩하지 않고 그래프 안에 규칙 자체를 데이터로 저장했습니다. "이 규칙은 0건이 정상", "이 규칙은 금액을 합산하지 말고 축별로 따로 본다" 같은 판정 기준까지 그래프에 적어 두면, 규칙을 추가할 때 점검 도구를 고칠 필요가 없습니다.

원칙 3. 규칙이 "0건"이라고 말할 때 의심하라

삭제 표시나 전기 차단이 걸린 계정에 전표가 있는지 점검하는 규칙을 돌렸더니 0건이 나왔습니다. 통제가 잘 지켜지고 있다는 뜻으로 읽기 쉽습니다.

그런데 별도의 "마스터 속성 공백" 규칙을 돌려 보니, 해당 테넌트의 계정 마스터에서 삭제 표시 필드 자체가 전부 비어 있었습니다. 0건은 "위반이 없다"가 아니라 "판단할 근거가 없다"였던 것입니다.

여기서 얻은 원칙은 단순합니다. 규칙은 결과를 보고하기 전에 입력이 존재하는지부터 확인해야 한다. 점검 결과 보고서에는 "0건"과 함께 그 판단에 쓴 필드의 채움률을 반드시 같이 적습니다.

원칙 4. 운영 관점의 함정

HANA Cloud 지식그래프를 실제로 운영하며 겪은 기술적 교훈도 하나 공유합니다.

그래프 스키마(온톨로지)를 고칠 때마다 그래프를 지우고 다시 적재하는 방식을 반복했더니, 어느 시점에 적재가 메모리 한도로 실패했습니다. 확인해 보니 그래프를 삭제해도 트리플 저장소가 쓰던 메모리가 즉시 반환되지 않았고, 인스턴스 재시작 후에야 회수되었습니다.

이후로는 스키마 변경 시 이전 버전과 새 버전의 차이만 반영하는 방식으로 바꿨습니다. 수십만 건을 다시 넣는 대신 바뀐 몇 건만 지우고 넣으면 되고, 실제 데이터(인스턴스)는 건드리지 않습니다. 개발 단계에서 "지우고 다시 넣기"를 습관적으로 반복하고 있다면 메모리 모니터링을 함께 거는 것을 권합니다.

정리

지식그래프는 AI 에이전트를 "더 똑똑하게" 만드는 도구이기 이전에, 회사 데이터가 실제로 어떻게 연결되어 있고 어디가 끊겨 있는지 보여 주는 지도입니다. AI 도입을 검토하고 있다면, 그 지도부터 그려 보는 것이 순서라고 생각합니다.

참고

• SAP Learning, Multi Model – SAP HANA Cloud Knowledge Graph Engine

• BARC, SAP data and analytics 2026: From roadmap to reality

글쓴이 Data&AI — ASPN BAC사업부에서 SAP BDC·Datasphere, 지식그래프, Joule·MCP 기반 AI Agent 구축을 다룹니다. 직접 구성하고 검증하며 얻은 실무 경험을 정리해 공유합니다.