공공기관 AI-레디 데이터 해설: LLM을 붙이기 전에 표준·메타데이터·품질 치료 루프부터 고정해야 하는 이유

발행일: 2026-05-19 | 카테고리: 개발정보

1) 한 줄 문제 정의

핵심 한 줄: 공공기관의 AI 도입 병목은 모델 성능보다 기관마다 다른 데이터 구조를 AI가 믿고 쓸 수 있는 상태로 만드는 일입니다.

AI타임스는 2026년 5월 19일, 우리데이터가 공공데이터를 AI가 즉시 활용할 수 있는 상태로 정제하는 우리데이터클리닉 V1.0을 출시했다고 보도했습니다. 기사에서 중요한 대목은 솔루션 홍보가 아니라, 공공기관 데이터가 기업 데이터와 다르게 다뤄져야 한다는 문제 제기입니다. 기업은 내부 표준 하나로 밀어붙일 수 있지만, 공공 데이터는 여러 기관, 법정 표준, 국민 서비스, 개방 API, 평가 지표가 동시에 얽힙니다.

이 글은 공공기관, 지자체, 공공 SI, 데이터 품질 담당자, AI 서비스 개발자가 AI-레디 데이터를 실제 작업 단위로 쪼개는 방법을 설명합니다. 범위는 데이터베이스·메타데이터·코드 체계·품질 진단·개선 루프입니다. 반대로 특정 솔루션 구매 판단이나 벤더 기능 비교표만 제공하는 글은 아닙니다.

2) 먼저 결론

핵심 한 줄: 공공기관은 챗봇을 먼저 붙이기보다 데이터 품질 치료 루프를 먼저 만들어야 합니다.

• 지금 바로 필요한 조직: 여러 부서·산하기관 DB를 연결해 검색, 민원 자동화, 정책 분석, RAG를 만들려는 기관
• 아직 과한 조직: 단일 엑셀 파일 몇 개를 내부 분석에만 쓰는 작은 팀
• 제 판단: AI-레디 데이터는 “데이터를 깨끗하게 정리하자”가 아니라 AI가 잘못된 연결을 만들지 못하게 표준, 의미, 출처, 품질 점수를 같이 고정하는 운영 체계입니다.

그래서 첫 단계는 LLM 교체가 아닙니다. 먼저 물리 DB에서 실제 컬럼, 코드, 관계, 누락, 중복, 최신성을 역추적하고, 사람이 검토해야 할 항목과 자동 치료 가능한 항목을 분리해야 합니다. AI타임스 기사에 따르면 우리데이터클리닉은 개선 대상 데이터 중 50~80%는 완전 자동 치료가 가능하다고 설명했습니다. 이 수치를 그대로 일반화하면 안 되지만, 실무적으로는 자동 치료 가능한 결함과 정책 판단이 필요한 결함을 분리하는 것이 핵심입니다.

3) 핵심 구조 분해

핵심 한 줄: AI-레디 데이터는 데이터 정제 도구 하나가 아니라 표준, 메타데이터, 품질 규칙, 개선 이력이 연결된 구조입니다.

3-1. 물리 DB 역추적 계층

역공학은 이미 만들어진 물리 DB에서 테이블, 컬럼, 관계, 코드 체계, 제약 조건을 거꾸로 읽어 설계 산출물을 복원하는 방식입니다. 공공기관처럼 오래된 시스템과 여러 DBMS가 섞인 곳에서는 문서가 최신 상태가 아닐 가능성이 높습니다. 그래서 설계 문서부터 믿기보다 실제 DB에서 출발해야 합니다.

3-2. 표준·코드 체계 계층

공공데이터는 기관 내부에서만 맞으면 끝나지 않습니다. 같은 의미의 항목이 기관마다 다른 이름, 다른 코드, 다른 날짜 형식으로 존재하면 AI는 그 차이를 의미 차이로 오해할 수 있습니다. 예를 들어 주소, 소재지, 사업장위치가 같은 개념인지 다른 개념인지 메타데이터로 설명돼야 합니다.

3-3. 품질 진단·치료 계층

IBM은 데이터 품질 차원으로 정확성, 완전성, 유효성, 일관성, 유일성, 적시성, 목적 적합성을 설명합니다. 공공기관의 AI-레디 작업도 이 기준을 그대로 실무 언어로 번역해야 합니다. 누락값은 완전성 문제이고, 법정 코드와 맞지 않는 값은 유효성 문제이며, 같은 기관명이 여러 방식으로 쓰이면 일관성 문제입니다.

3-4. 평가·증빙 계층

공공기관은 품질 개선을 했다는 말만으로 부족합니다. 공공데이터포털의 품질관리 매뉴얼도 계획, 구축, 운영, 활용 단계의 품질관리 활동과 진단·개선 절차를 강조합니다. AI 도입에서도 어떤 규칙으로 진단했고, 무엇을 자동 수정했고, 무엇을 사람이 승인했는지가 증빙으로 남아야 합니다.

4) 설계 의도 해설

핵심 한 줄: 공공 데이터 품질 관리는 데이터 정리 작업이 아니라 기관 간 신뢰 계약을 만드는 작업입니다.

기업 데이터는 보통 하나의 사업 목표를 향해 움직입니다. CRM, ERP, 주문 DB처럼 소유자와 KPI가 비교적 분명합니다. 반면 공공 데이터는 개방, 행정 처리, 통계, 민원, 정책 결정, AI 학습이 동시에 목적이 됩니다. 목적이 여러 개이면 “쓸 만한 데이터”의 기준도 흔들립니다.

그래서 공공기관에서는 사후 진단만으로 부족합니다. AI가 연결해서 쓸 수 있으려면 신규 DB 구축 단계부터 표준명, 코드, 메타데이터, 품질 규칙을 같이 설계해야 합니다. 이미 운영 중인 DB는 역추적으로 현재 상태를 먼저 파악하고, 자동 치료 가능한 오류와 제도·업무 판단이 필요한 오류를 분리해야 합니다.

제 해석은 이렇습니다. AI-레디 데이터의 진짜 경쟁 상대는 더 좋은 챗봇이 아니라 엑셀 수작업, 부서별 임시 코드, 문서와 DB가 따로 노는 운영 습관입니다. 이 습관을 고치지 않으면 RAG를 붙여도 답변은 그럴듯하지만 근거는 약해집니다.

5) 근거 및 비교

핵심 한 줄: 공공기관은 “정제했는가”보다 AI가 재사용할 수 있는 품질 계약을 만들었는가로 비교해야 합니다.

AI타임스 기사에는 공공기관 700여 곳의 데이터가 연관돼 있고, 우리데이터클리닉이 오라클, 티베로, Microsoft SQL Server, MariaDB, DB2, HanaDB 등 13종 DBMS를 지원하며, 16종 필수 산출물 자동 생성 기능을 제공한다는 설명이 나옵니다. 이 숫자들이 말하는 핵심은 기능 많음이 아니라 공공 데이터 품질 문제가 단일 DB 문제가 아니라 이기종 환경과 행정 증빙 문제라는 점입니다.

GOV.UK의 Government Data Quality Framework도 정부 데이터 품질 작업은 선제적이고, 증거 기반이며, 목적에 맞게 타깃팅돼야 한다고 설명합니다. 즉 공공 데이터 품질은 “한 번 청소”가 아니라 지속 운영입니다.

6) 실제 동작 흐름 / 단계별 실행 방법

핵심 한 줄: AI-레디 데이터 프로젝트는 모델 PoC가 아니라 데이터 자산 진단표에서 시작해야 합니다.

1. 대상 업무를 1개로 좁히십시오.
   예: 민원 FAQ RAG, 복지 사업 중복 검토, 시설물 점검 이력 검색처럼 AI가 답해야 할 질문을 먼저 정합니다.
2. 연결되는 DB와 파일을 목록화하십시오.
   DBMS, 테이블 수, 소유 부서, 최신 갱신일, 외부 공개 여부, 개인정보 포함 여부를 적습니다.
3. 물리 DB에서 메타데이터를 역추출하십시오.
   컬럼명, 데이터 타입, PK/FK 후보, 코드값, null 비율, 중복률, 날짜 범위를 추출합니다.
4. 품질 규칙을 7개 차원으로 나누십시오.
   완전성, 유일성, 유효성, 적시성, 정확성, 일관성, 목적 적합성 기준으로 규칙을 만듭니다.
5. 자동 치료와 승인 치료를 분리하십시오.
   공백 제거, 날짜 형식 통일, 명백한 코드 매핑은 자동화할 수 있습니다. 하지만 법정 코드 변경, 기관명 병합, 개인정보 비식별 기준은 담당자 승인으로 남겨야 합니다.
6. AI 투입 전 테스트셋을 만드십시오.
   대표 질문 30개, 정답 근거 행 또는 문서, 허용 가능한 답변 범위를 정합니다.
7. 운영 지표를 고정하십시오.
   예: null 비율 5% 미만, 미매핑 코드 1% 미만, 최신성 SLA 24시간, 출처 없는 AI 답변 0건.

# 예시: AI-레디 데이터 진단 규칙 초안
checks:
  completeness:
    주민등록주소: null_rate < 0.01
  validity:
    법정동코드: match_reference_table == true
  consistency:
    기관명: canonical_name_mapping_required == true
  timeliness:
    시설점검일: max_age_days <= 30
  ai_grounding:
    rag_answer: source_row_or_document_required == true

7) 실수/함정(Pitfalls)

핵심 한 줄: AI-레디 데이터 프로젝트는 “데이터 청소”로 시작하면 대부분 다시 엉킵니다.

• 실수 1: LLM이 알아서 컬럼 의미를 추론할 것이라고 믿는 것
  예방: 컬럼 설명, 코드표, 업무 정의를 메타데이터로 붙이십시오.
  복구: AI 답변 오류 사례를 모아 어떤 컬럼 의미가 빠졌는지 역으로 보강하십시오.
• 실수 2: 자동 수정률만 KPI로 삼는 것
  예방: 자동 치료율과 함께 승인 대기 건수, 재발률, 출처 연결률을 같이 보십시오.
  복구: 자동 수정된 항목의 샘플을 감사하고, 정책 판단이 필요한 항목은 룰에서 제외하십시오.
• 실수 3: 기관별 예외를 표준화 실패로만 보는 것
  예방: 법·업무상 필요한 예외와 단순 관성 예외를 분리하십시오.
  복구: 예외 사유, 담당자, 만료일을 둬서 영구 예외가 되지 않게 하십시오.
• 실수 4: 품질 점검 결과를 AI 평가와 분리하는 것
  예방: RAG 답변 평가에 데이터 품질 점수를 함께 기록하십시오.
  복구: 오답을 모델 탓으로 돌리기 전에 근거 데이터의 최신성, 코드 매핑, 중복 여부를 먼저 확인하십시오.

8) 강점과 한계

핵심 한 줄: AI-레디 데이터 루프는 공공 AI의 신뢰도를 올리지만, 모든 품질 문제를 자동으로 해결하지는 않습니다.

강점

• LLM 도입 전에 데이터 오류를 구조적으로 줄일 수 있습니다.
• 기관 간 데이터 연계에서 같은 의미의 항목을 더 안정적으로 맞출 수 있습니다.
• 품질 진단, 개선, 산출물, AI 답변 근거를 하나의 감사 흐름으로 묶을 수 있습니다.

한계

• 업무 정의가 불분명하면 도구가 컬럼 의미를 완전히 해결할 수 없습니다.
• 오래된 시스템은 DB 제약 조건이 약하거나 문서와 실제 구조가 다를 수 있습니다.
• 개인정보, 보안 등급, 공개 범위는 자동 치료가 아니라 정책 결정이 필요합니다.

반례: 단일 부서가 내부 통계용으로 쓰는 작은 데이터셋이라면 거대한 AI-레디 프로젝트보다 간단한 데이터 프로파일링과 수작업 검수가 더 경제적입니다. 하지만 기관 간 연계나 시민 대상 AI 서비스라면 품질 루프 없이 바로 LLM을 붙이는 것은 위험합니다.

9) 더 깊게 공부할 포인트

핵심 한 줄: 다음 학습은 모델 프롬프트보다 데이터 품질 차원과 공공 메타데이터 표준에서 시작해야 합니다.

• 공공데이터 품질관리 매뉴얼의 계획·구축·운영·활용 단계
• 정확성, 완전성, 유효성, 일관성, 유일성, 적시성, 목적 적합성의 차이
• DB 역공학으로 ERD, 코드표, 컬럼 사전을 복원하는 방법
• RAG 평가에서 답변 정확도와 근거 데이터 품질을 함께 보는 방법
• 개인정보 비식별, 공개 등급, 데이터 최신성 SLA를 AI 서비스 요구사항으로 쓰는 방법

10) 실행 체크리스트 + 작성자 관점

핵심 한 줄: 공공 AI 프로젝트의 첫 산출물은 챗봇 화면이 아니라 데이터 품질 계약서여야 합니다.

• AI가 답해야 할 업무 질문 30개와 정답 근거를 정했는가?
• 대상 DB·파일·API의 소유 부서, 갱신 주기, 공개 등급을 기록했는가?
• 컬럼 사전, 코드표, 표준명, 예외 사유가 최신 상태인가?
• 품질 규칙을 완전성·유일성·유효성·적시성·정확성·일관성·목적 적합성으로 나눴는가?
• 자동 치료 가능한 오류와 담당자 승인이 필요한 오류를 분리했는가?
• AI 답변마다 출처 행, 문서, 갱신일을 남기는가?
• 품질 점수 하락 시 AI 서비스 배포를 멈추는 게이트가 있는가?

Definition of Done: 한 업무 영역의 대표 질문, 데이터 자산 목록, 품질 규칙, 자동·승인 치료 기준, AI 답변 근거 추적이 문서와 대시보드로 연결되면 AI-레디 데이터의 1차 운영 기준이 잡힌 것입니다.

제 추천: 공공기관은 AI 서비스를 보여주기 전에 데이터 품질 루프를 먼저 공개 가능한 수준으로 만들어야 합니다. “우리 데이터가 AI에 들어갔다”가 아니라 “AI가 답변할 때 어떤 데이터 품질 기준을 통과했는지 설명할 수 있다”가 신뢰의 기준입니다. 반대로 데이터 범위가 작고 내부 실험이라면 처음부터 대규모 솔루션을 들이기보다 프로파일링, 코드표 정리, RAG 테스트셋부터 시작하는 편이 낫습니다.

참고자료

• AI타임스, “공공기관 AI-레디 데이터, 기업과 다르게 접근해야”…’우리데이터클리닉’ 공식 출시 (2026-05-19)
• 공공데이터포털, 공공데이터 품질관리 매뉴얼 ver 2.1 (수정 등록 2025-02-27)
• GOV.UK, The Government Data Quality Framework (Published 2020-12-03)
• IBM Think, Data Quality - dimensions and governance context (확인일: 2026-05-19)