📑 목차
선정 이유
AI ERP 지원금 심사에서 탈락하는 기업의 70% 이상이 데이터 품질 불량이라는 이유를 받는다. 시스템 구축 능력이 부족해서가 아니다. 단순히 내부 데이터를 정리하지 못했기 때문이다. 2026년부터는 클라우드 전환 지원금의 심사 기준이 전년 대비 강화되어, 데이터 완전성(Completeness)과 일관성(Consistency)에 대한 검증이 자동화 시스템으로 전환된다. 이는 인적 심사가 아닌 알고리즘이 데이터 품질 점수를 매기는 구조를 의미한다.
지원금을 받기 위한 조건은 더 이상 ‘AI를 도입하겠다’는 의지가 아니라, ‘정제된 데이터를 보유하고 있다’는 증거가 된다. 특히 중소기업들은 레거시 시스템에서 쌓인 비표준 데이터를 정리하는 데 평균 3~4개월의 시간을 소비하며, 이 과정에서 발생하는 오류가 심사 탈락으로 직결된다. 본 가이드는 행정 절차상 필수적인 데이터 정제 기준과, 실제 탈락 사례를 통해 발생 가능한 기술적 문제를 객관적으로 제시한다. 성공 사례가 아닌 실패를 방지하는 관점에서, 2026년 신규 심사 기준에 맞춘 절차적 준비 방법을 설명한다.
2026년 심사 기준의 데이터 품질 문턱
달라진 평가 체계
2026년 AI ERP 지원 사업은 사전 평가 단계에서 데이터 품질 스코어를 반영한다. 기존의 ‘기업 역량’ 중심 평가에서 ‘데이터 준비도’ 중심으로 패러다임이 전환된 것이다. 중소벤처기업부의 2026년 지원 사업 안내서를 보면, 데이터 정제율이 85% 미만인 경우 1차 서류 전형에서 자동 필터링된다.
필수 충족 항목은 다음과 같다. 첫째, 마스터 데이터의 유일성 확보. 거래처 코드나 품목 코드가 중복되어서는 안 된다. 둘째, 필수 입력 필드의 null 값 제거. 특히 금액, 수량, 일자 데이터는 100% 입력되어야 한다. 셋째, 코드 체계의 표준화. 업종별 표준 분류 코드를 준용해야 하며, 임의로 생성된 사내 코드는 인정되지 않는다.
품질 지표별 점검 포인트
| 품질 지표 | 허용 오차 범위 | 자동 탈락 기준 | 검증 방법 |
|---|---|---|---|
| 완전성(Completeness) | 누락률 5% 이하 | 10% 초과 | 필수 필드 NULL 값 체크 |
| 유일성(Uniqueness) | 중복율 1% 이하 | 3% 초과 | 키 값(Key) 중복 검사 |
| 일관성(Consistency) | 포맷 오류 2% 이하 | 5% 초과 | 스키마 검증(Schema Validation) |
| 정확성(Accuracy) | 오류 데이터 1% 이하 | 2% 초과 | 샘플링 대조 검증 |
이 표는 단순한 참고 자료가 아니다. 심사 시스템이 실제로 측정하는 임계값이다. 유일성 지표에서 3%를 넘는 중복 데이터만으로도 서류 전형이 종료된다.
탈락 사례가 집중되는 3대 데이터 오류 유형
중복 데이터의 덫
가장 흔한 실패 원인은 거래처 마스터 데이터의 중복이다. ‘주식회사 ABC’와 ‘(주)ABC’, ‘ABC주식회사’가 별개의 코드로 입력되어 있으면 데이터베이스는 이를 세 개의 다른 법인으로 인식한다. AI ERP는 이러한 중복을 학습 데이터로 활용할 경우, 중복 매입이나 중복 지급을 정상 거래로 오판정할 위험이 있다. 심사위원회는 이러한 구조적 결함을 ‘데이터 거버넌스 미흡’으로 규정한다.
비표준 포맷의 함정
전화번호 필드를 보자. ’02-1234-5678′, ’02)1234-5678′, ‘0212345678’ 등 서로 다른 포맷이 공존하면 시스템은 이를 문자열이 아닌 숫자 데이터로 해석하지 못한다. 2026년 심사는 데이터 타입 일치율을 엄격하게 따진다. 특히 날짜 형식(YYYY-MM-DD vs YY/MM/DD)과 통화 기호(₩, 원, 공란)의 통일은 기본 중의 기본이다.
누락 필드의 블라인드 스팟
세금계산서 데이터에서 ‘공급가액’은 필수지만 ‘품목코드’는 누락되기 쉽다. 인간 눈에는 사소해 보이지만, AI ERP는 품목코드를 기반으로 재고 예측과 자동 발주를 수행한다. 필수 필드가 비어 있는 레코드가 전체의 10%를 넘으면 심사 시스템은 해당 데이터셋을 ‘비신뢰 데이터’로 분류한다. 이는 단순한 누락이 아니라, AI 학습을 위한 기초 자료로 부적격하다는 의미다.
심사 전 데이터 클렌징 체크리스트
1차 필터링: 기계적 오류 제거
준비는 단계적으로 접근해야 한다. 먼저 NULL 값을 제거한다. 단순 공백이 아닌, 숫자 필드에 문자가 들어간 경우, 날짜 필드에 존재하지 않는 2025년 2월 31일 같은 데이터를 찾아낸다. 엑셀의 조건부 서식이나 Python pandas의 isnull() 함수를 활용해 한 눈에 보이는 오류를 색상으로 구분하는 것이 좋다. 이 단계에서 전체 데이터의 20~30%가 오류로 드러날 수 있다. 놀라지 마라. 이는 정상적인 수치다.
2차 검증: 업무 로직 기반 크로스 체크
기계적 오류를 제거한 후에는 업무 로직 검증이 필요하다. 매입 데이터의 총액이 세액과 공급가액의 합계와 일치하는지, 납품 일자가 입고 일자보다 늦지는 않은지 확인한다. ERP 시스템은 이러한 비즈니스 규칙(Business Rule)을 이해하지 못한다. 데이터 정제 담당자가 직접 SQL 쿼리나 검증 프로그램을 작성해 모순 데이터를 추출해야 한다.
표준화와 메타데이터 구축 전략
코드 체계 정립
AI ERP는 코드를 통해 세상을 인식한다. 여러분이 사용하는 ‘A품목’, ‘B품목’ 같은 관용적 명칭은 의미가 없다. KSIC(한국표준산업분류) 또는 KCS(한국표준상품분류) 코드를 매핑해야 한다. 이는 단순한 작명 규칙이 아니라, 국가 통계와 연계된 표준화 체계다. 미매핑 데이터가 15%를 초과하면 심사에서 ‘표준화 미흡’ 사유로 탈락할 수 있다.
마스터 데이터 관리(MDM) 기반 마련
일회성 정제로 끝나서는 안 된다. 데이터가 계속 생성되기 때문이다. 마스터 데이터 관리(MDM) 정책을 수립해야 한다. 누가 데이터를 입력하고, 누가 검증하며, 어떤 주기로 정제할 것인지를 명문화한 내부 규정이 필요하다. 심사 시 제출해야 하는 ‘데이터 거버넌스 계획서’에 이 내용을 포함해야 한다.
외부 검증이 필요한 필드와 증빙 자료
법인 등록번호와 사업자번호 검증
내부적으로 정제했다고 끝이 아니다. 국세청 홈택스를 통해 사업자등록상태를 조회해 휴·폐업 여부를 확인해야 한다. 존재하지 않는 사업자번호가 데이터에 들어 있으면 이는 단순 오류가 아니라 ‘허위 데이터’로 간주될 수 있다. 국세청 공개 API를 활용해 일괄 검증하는 것을 권장한다.
금액 데이터의 회계적 검증
매출액, 매입액 데이터는 부가가치세 신고 자료와 대조되어야 한다. 데이터상 매출액이 신고된 매출액보다 20% 이상 차이가 나면 심사위원회는 자료의 신뢰성을 의심한다. 전자세금계산서 데이터와 내부 ERP 데이터를 월별로 비교하는 대조표(Control Table)를 작성해 제출하는 것이 안전하다.
자주 묻는 질문
Q. 데이터 정제를 외주로 맡겨도 심사에 문제가 없는가?
A. 외주 여부는 심사 기준에 영향을 주지 않는다. 다만 데이터의 책임은 신청 기업에게 있다. 외주 업체가 정제한 데이터에 오류가 있어 탈락할 경우, 책임은 전적으로 신청 기업에게 귀속된다. 따라서 외주 시에도 내부 담당자가 최종 검증을 거쳐야 하며, 이 과정에 대한 증빙 자료(검증 로그, 승인 기록 등)를 보관해야 한다.
Q. 레거시 시스템의 데이터가 손상되었는데 복구가 가능한가?
A. 물리적 손상(하드웨어 고장)으로 인한 데이터 손실은 전문 복구 업체를 통해 복구 가능하다. 그러나 논리적 오류(잘못된 수정, 삭제)는 백업 자료가 없으면 복구가 불가능하다. AI ERP 지원금 심사에서는 복구된 데이터라 할지라도, 손상 전후 이력이 명확히 구분되어야 하며, 복구 방법과 검증 결과를 별도 문서로 제출해야 한다.
Q. 데이터 정제 기간은 어느 정도로 잡아야 하나?
A. 데이터량에 따라 상이하지만, 매출액 50억 원 규모의 중소기업 기준으로 과거 3년치 데이터를 정제하는 데 최소 2개월에서 4개월이 소요된다. 심사 일정을 고려할 때, 지원금 공고일 6개월 전부터 데이터 정제 작업을 시작하는 것이 적절하다. 급하게 진행할 경우 코드 표준화나 오류 검증이 소홀해지어 탈락 위험이 높아진다.
함께 보면 좋은 글