AI 도입 전에 ERP 데이터, 무엇부터 점검해야 할까?

AI 에이전트 도입을 검토하는 분들이 자주 묻습니다. "우리 ERP 데이터, 이대로 AI에 연결해도 괜찮을까요? 무엇부터 점검해야 하나요?" 오류가 나는 데이터는 오히려 다루기 쉽습니다. 어려운 것은 오류 없이 조용히 틀리는 데이터입니다. 질의는 정상 종료되고 숫자도 그럴듯하게 나오는데, 실제로는 일부 행이 빠졌거나 부호가 뒤집혀 있는 경우입니다. 이 글은 저희가 테스트 환경의 손익(CO-PA) 데이터에 정합성 규칙 10가지를 직접 만들어 돌려 보며 확인한 내용을 정리합니다. 테스트 데이터의 수치는 실제 기업 환경을 대표하지 않으므로, 데이터 상태를 나타내는 수치는 싣지 않고 실제로 나타난 패턴과 점검 방법만 정리합니다.

왜 "AI 전에" 점검해야 하나

연재 1회에서 AI를 위한 데이터 플랫폼의 세 번째 층을 관계 층이라고 불렀습니다. 마스터와 거래가 서로 제대로 이어져 있는지가 이 층의 핵심입니다. 사람이 보는 보고서는 담당자가 "이 숫자 이상한데?"라고 멈출 수 있지만, AI 에이전트는 멈추지 않습니다. 연결이 끊긴 데이터 위에서도 자신 있게 답합니다.

지식그래프 글에서 이런 현상을 조용한 누락이라고 불렀습니다. 정합성 진단은 이 조용한 누락을 AI 연결 전에 숫자로 드러내는 작업입니다. 저희가 직접 겪은 예를 하나 들면, 제품 마스터와 손익 데이터를 일반적인 내부 조인으로 붙였더니 제품 코드가 비어 있는 행이 결과에서 통째로 사라졌습니다. 적지 않은 행이 빠졌는데도 오류 메시지는 한 줄도 없었습니다.

정합성 진단 10가지 규칙

저희가 만든 규칙은 네 묶음, 열 가지입니다. 이름은 일반화했지만 모두 실제로 돌려 보고 다듬은 것입니다.

규칙마다 "0이 정상인가"를 미리 정해 둔 것이 중요합니다. ①·③·⑦·⑨는 한 건이라도 나오면 결함이고, ②·④는 줄여 가야 할 지표이며, ⑥·⑩은 판단 재료로 쓰는 참고 규칙입니다.

실제로 돌려 보니 ① 건수로는 멀쩡한데 금액은 뒤집힌다

가장 눈에 띈 것은 ② 차원 미배부였습니다. 축마다 비어 있는 행을 세어 보면 어느 축이 가장 심각한지 순위가 나옵니다. 그런데 금액으로 다시 재면 순위가 바뀔 수 있습니다.

비어 있는 행이 적은 축이라도, 그 행들에 큰 이익이나 손실이 몰려 있으면 "그 축 기준 손익"은 회사 전체 손익과 방향이나 크기가 크게 달라집니다. 저희 환경에서도 건수로는 가장 멀쩡해 보이던 축이 금액으로는 가장 크게 왜곡돼 있었습니다. 이 때문에 저희는 모든 규칙이 건수와 금액을 함께 반환하도록 결과 형식을 고정했습니다. 건수만 보면 놓치는 결함이 금액에서 드러나고, 그 반대도 있습니다.

실제로 돌려 보니 ② 초록불인데 근거가 비어 있었다

⑨ 삭제표시·전기차단 계정 전기는 첫 측정에서 0건이 나왔습니다. "통제가 잘 지켜지고 있다"고 보고할 뻔했습니다. 그런데 ⑥ 마스터 속성 공백을 돌려 보니, 계정 마스터의 삭제표시 플래그가 전 행 공백이었습니다. 0건은 통제가 지켜졌다는 뜻이 아니라, 판정할 재료가 없었다는 뜻이었습니다.

여기서 설계 원칙 하나를 얻었습니다. 규칙은 0을 보고하기 전에 입력이 존재하는지부터 확인해야 한다. 이후로 "0건" 결과에는 판정에 쓴 플래그의 채움률을 함께 적습니다.

비슷한 함정이 미배부 판정에도 있었습니다. 비어 있는 값을 NULL로 찾았더니 0건, 공백 문자열로 찾아도 0건이었는데, 실제로는 원천 뷰가 이미 "미배부"라는 문자열로 바꿔 둔 상태였습니다. 결측은 NULL, 공백, 대체 문자열의 세 가지 모습으로 나타납니다. 판정식을 만들기 전에 원천이 결측을 어떻게 표현하는지부터 확인해야 합니다.

실제로 돌려 보니 ③ 규칙도 오탐을 낸다

⑧ 무의미 명칭은 "이름 자리에 코드가 그대로 들어 있는" 경우를 잡는 규칙입니다. 이름이 아예 없으면 ④가 잡지만, 코드가 이름 자리에 들어가 있으면 어떤 규칙도 잡지 못하기 때문에 따로 만들었습니다.

첫 실행 결과의 절반 이상이 오탐이었습니다. 코드 자체가 한글로 되어 있는 자재는 이름이 코드와 같아도 읽는 데 문제가 없습니다. 실물 목록을 눈으로 확인한 뒤에야 알았고, 한글 코드를 제외하도록 규칙을 좁혔습니다. 남은 진짜 결함은 모두 데모·테스트용 마스터였습니다.

⑥ 마스터 속성 공백은 반대 방향의 문제를 보여 줬습니다. 마스터 테이블 일곱 개의 전 컬럼을 훑자 발견이 수백 건 나왔는데, 대부분은 이 회사가 쓰지 않는 표준 컬럼(합작투자, 주소, 업종 확장 필드 등)이었습니다. 업무적으로 의미 있는 발견은 세 건뿐이었습니다. 그래서 등급을 "참고"로 내리고, 출력은 실제로 분석에 쓰려던 컬럼 위주로 바꿨습니다. 전수 탐지는 만들기 쉽고 읽기 어렵습니다. 규칙은 범위를 좁혀야 쓸모가 있습니다.

실제로 돌려 보니 ④ 시연 데이터가 테스트 마스터 위에 있었다

⑩ 테스트·더미 마스터 실거래 규칙은 코드와 이름에서 TEST, DEMO, DUMMY, 테스트, 더미 같은 패턴을 찾는 휴리스틱입니다. 원가센터처럼 코드는 평범하고 이름만 "더미"인 경우가 있어 코드와 이름을 함께 봅니다.

결과는 두 가지로 놀라웠습니다. 첫째, 테스트 마스터 참조 대부분이 더미 원가센터 한 곳에 몰려 있었습니다. 지난 회차에서 원가센터 축을 열었을 때 원가차이 대부분이 더미 원가센터에 쌓여 있던 것과 같은 실체입니다. 둘째, 저희가 다단계 관계 추적을 시연할 때 쓰던 자재가 바로 테스트용 자재 마스터였습니다. 시연 서사 자체가 테스트 데이터 위에 서 있었던 셈입니다. 규칙이 만든 사람의 맹점까지 잡아낸 사례입니다.

규칙은 코드가 아니라 데이터로 관리한다

규칙 10가지를 만드는 것보다 더 중요했던 것은 규칙을 늘려도 도구를 고치지 않는 구조였습니다.

• 규칙 레지스트리 — 규칙 ID, 등급, 엔진, 정상값, 집계 방식, 기준선을 데이터로 선언합니다. 규칙 추가나 등급 변경은 레지스트리 재적재로 끝납니다.

• 질의 본문 — 집계형 규칙은 SQL로, 구조형 규칙(참조·연결·명칭)은 그래프 질의로 씁니다. 지식그래프 글의 "금액은 SQL로, 관계는 그래프로" 원칙 그대로입니다.

• 실행기 — 레지스트리를 읽어 엔진별로 질의를 보내고, 결과를 같은 형식(규칙·범위·발견 키·건수·전체 건수·영향 금액·전체 금액)으로 모읍니다.

실제로 규칙을 7종에서 8종으로 늘릴 때 실행기 코드는 한 줄도 고치지 않았고, 이후 10종까지도 대부분 레지스트리와 질의 추가만으로 끝났습니다. 집계 방식도 레지스트리에 적어 둡니다. 처음에는 여러 축으로 잰 같은 모집단을 그냥 더해 비율이 100%를 넘는 일이 있었는데, "분할 합산"과 "축별 최악값" 두 방식을 구분해 표시한 뒤로 사라졌습니다.

이 구조는 고객 환경으로 옮길 때 힘을 발휘합니다. 마스터와 거래 범위를 몇 배로 늘려도 연결 규칙은 수정 없이 새 범위를 자동으로 검사했습니다. 테스트 테넌트에서 마스터 미등록 참조는 처음 여러 건 발견됐다가, 원인을 고친 뒤 0으로 내려가는 것까지 같은 규칙으로 증명했습니다.

도구는 어디까지 해 주나 (2026년 11월 기준)

SAP도 데이터 품질 기능을 꾸준히 제공하고 있습니다.

• SAP Master Data Governance(MDG)의 데이터 품질 관리는 마스터 데이터 품질 규칙을 정의·평가하고, 기존 데이터에서 규칙 후보를 머신러닝으로 찾아 주는 룰 마이닝을 제공합니다(제품, 비즈니스 파트너 등).

• SAP Datasphere의 데이터 검증은 뷰의 모델링 메타데이터를 기준으로 키 중복·키 NULL, 계층의 다중 부모·순환 같은 사전 정의 규칙을 뷰 단위로 실행합니다.

• 협력사 생태계에서도 SAP HANA·Datasphere·BDC에 대한 데이터 품질·관찰성 솔루션이 나와 있습니다.

이런 도구는 마스터 하나, 뷰 하나 안의 품질을 보는 데 강합니다. 이 글의 규칙은 초점이 조금 다릅니다. 거래와 마스터 사이의 연결, 손익 금액에 미치는 영향, 재무제표 구조와의 대조처럼 여러 객체에 걸친 정합성을 AI가 답하기 전에 확인하는 것입니다. 두 접근은 대체재가 아니라 함께 쓰는 관계입니다.

AI 연결 전 체크리스트

• 거래가 가리키는 마스터 코드가 모두 마스터에 있는가 (0건이어야 정상)

• 분석 축별 미배부 비중을 건수와 금액 둘 다로 재었는가

• 원천이 결측을 어떻게 표현하는지(NULL·공백·대체 문자열) 확인했는가

• "0건" 결과마다 판정에 쓴 플래그의 채움률을 함께 보는가

• 계정이 재무제표 계층의 정상 노드로 올라가는가

• 이름 자리에 코드가 들어간 마스터, 테스트·더미 마스터에 쌓인 금액은 얼마인가

• 규칙의 결과 자체(오탐·잡음)를 사람이 한 번 검토했는가

• 규칙과 기준선이 문서가 아니라 데이터로 관리되어, 재실행하면 같은 결과가 나오는가

정합성 진단은 한 번 하고 끝나는 검사가 아니라 기준선을 정해 두고 다시 돌리는 건강검진입니다. 다음 단계는 이 실행기를 AI 에이전트가 직접 부를 수 있는 도구로 만드는 것입니다. Joule Agent와 MCP 글에서 다룬 MCP 서버에 "답하기 전에 정합성부터 확인하는" 도구를 두는 방식입니다.

다음 회차에서는 같은 관계 층에서 한 걸음 더 나가, 공급사 하나가 멈추면 어떤 수주까지 영향을 받는지를 지식그래프로 추적하는 방법을 다룹니다.

AI 도입 전 데이터 점검, ASPN과 함께 하세요

ASPN은 SAP ERP 구축·운영 경험을 바탕으로 ERP 데이터를 분석과 AI에 쓸 수 있는 상태로 만드는 일을 다루고 있습니다. 이 글의 규칙도 저희가 테스트 환경에서 직접 만들고 기준선을 확정하며 확인한 것입니다.

• 제공 중 — S/4HANA 관리회계·수익성 분석(CO-PA) 구축과 운영, Datasphere 기반 데이터 모델링과 분석 환경 구축

• 실증 경험·검토 단계 — 지식그래프 기반 정합성 진단 규칙 세트, AI 에이전트가 호출하는 정합성 점검 도구

AI 연결을 앞두고 "우리 데이터는 괜찮을까"가 걱정된다면, 현재 ERP 데이터의 연결과 채움 상태를 기준으로 어디부터 손봐야 하는지 함께 점검해 드립니다.

참고

• SAP Learning, Introducing Rule Mining (SAP Master Data Governance on SAP S/4HANA)

• SAP Learning, Explaining Master Data Quality: Process and Rules

• SAP Community, SAP Datasphere Data Validations

• SAP Community, Master Data Quality Management with SAP Master Data Governance on SAP S/4HANA

• Collibra, Data Quality & Observability with Pushdown for SAP HANA, HANA Cloud and Datasphere

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