oracle-ai-ready-data Skill 제1회에서는 샘플 HR 스키마를 대상으로 oracle-ai-ready-data Skill을 통해 AI Ready 평가를 수행했습니다. HR 스키마는 테이블 이름이나 컬럼 이름, 기본 키(Primary Key, PK)·외래 키(Foreign Key, FK) 등이 비교적 알기 쉽게 정비되어 있었기 때문에, 코멘트 필수 게이트(Mandatory comment gate)를 통과하였으며, AI가 이용하기 쉬운 상태에 가깝다는 것을 확인할 수 있었습니다.

반면, 실제 시스템에서는 데이터 자체에는 문제가 없더라도 테이블이나 컬럼의 설명, 기본 키·외래 키, 업데이트 일시, 데이터의 출처, 통계 정보 등이 충분히 정비되어 있지 않은 경우가 있습니다. 이러한 상태에서는 인간은 경험을 통해 의미를 추측할 수 있어도, AI는 업무상의 의미나 테이블 간의 관계를 올바르게 판단하기 어려워집니다.

이번에는 행 데이터의 유일성과 참조 무결성은 미리 충족시키면서, AI 이용에 필요한 메타데이터만을 의도적으로 결락시킨 BAD_AI_READY 스키마를 작성합니다. 그 후, Skill이 생성한 개선 후보를 이번 데이터 모델에 맞춰 리뷰하고, 개선 SQL을 실행하여 평가 결과가 어떻게 변하는지 확인합니다. 마지막으로, 정비한 코멘트와 PK/FK를 Select AI가 자연어로부터의 SQL 생성에 이용할 수 있는지도 확인해 보겠습니다.

oracle-ai-ready-data Skill은 Oracle Database의 코멘트, 제약 조건(Constraints), 통계, 신선도, 출처, 권한 등의 메타데이터를 확인하여 AI가 이용하기 쉬운 상태인지를 0.00~1.00으로 평가합니다.

따라서, 미준비(unready) 상태에서 AI Ready 후보로 개선하는 일련의 흐름을 실제로 진행해 보겠습니다.

이번 확인 포인트는 다음과 같습니다.

본 기사의 AI Ready는 데이터 사전(Data Dictionary)에서 확인할 수 있는 메타데이터상의 준비 상태를 가리킵니다. 실제 데이터의 업무적 정확성, 개인정보 이용 가능 여부, 법령 준수, 생성된 SQL의 완전성을 보장하는 것은 아닙니다.

1. BAD_AI_READY 스키마 작성

2. 개선 전의 oracle-ai-ready-data 평가

3. 개선 전 리포트 결과

4. 개선 SQL을 리뷰하고 실행

5. Mermaid ER 다이어그램으로 개선 후의 테이블 관계 확인

6. 개선 후 Skill 재실행

7. 개선 후의 Oracle Database AI Ready 평가

8. Select AI로 AI Ready Data 기능 확인

9. 요약

덤

참고 정보

이번에 사용할 검증 스키마는 GitHub Release에서 공개하고 있는 재현 패키지를 사용합니다. DDL, CSV 데이터, 개선 SQL, 검증 SQL, Select AI용 프롬프트를 모아두었기 때문에 동일한 구성을 반복해서 생성할 수 있습니다.

BAD_AI_READY Part 2 다운로드: bad_ai_ready_part2-v1.0.0.zip

00_admin_create_schema.sql은 기존의 BAD_AI_READY 사용자를 삭제하고 재생성합니다. 반드시 검증용 데이터베이스 또는 폐기 가능한 스키마에서 실행해 주세요.

생성되는 것은 다음 8개의 테이블입니다. 중복 키, NULL 키, 고아 레코드(Orphan record)는 포함하지 않으며, 개선 SQL을 통해 PK/FK를 그대로 ENABLE VALIDATE로 추가할 수 있는 테스트 데이터로 구성되어 있습니다.

CSV는 총 448행입니다. 개선 전에는 8개 테이블, 52개 열이었으나, 개선 SQL을 통해 각 테이블에 UPDATED_AT과 SOURCE_SYSTEM을 추가하므로 개선 후에는 68개 열이 됩니다.

행 데이터는 다음 조건을 충족합니다.

• PK(기본 키) 후보는 NULL 없음·중복 없음
• FK(외래 키) 후보는 모두 참조 대상이 있음
• 날짜, 금액, 수량, 상태 코드는 통일된 문자열 형식
• 이메일 주소, 전화번호, 식별 번호, URI는 모두 합성값(Composite value)

반면, 메타데이터는 의도적으로 다음과 같은 상태로 설정했습니다.

테이블 코멘트: 0건
컬럼 코멘트: 0건
PK, FK, UNIQUE, CHECK: 0건
...

즉, 이번에는 "망가진 데이터를 수리하는" 것이 아니라, 올바르게 연결될 수 있는 데이터에 대해 AI가 의미를 이해할 수 있도록 메타데이터를 추가하는 것에 초점을 맞춥니다.

1) ZIP 압축 해제 및 패키지로 이동

SQLcl의 LOAD 명령은 data/*.csv를 상대 경로로 참조하므로, 압축을 해제한 패키지의 루트에서 작업합니다.

unzip bad_ai_ready_part2-v1.0.0.zip
cd bad_ai_ready_part2

2) ADMIN 계정으로 BAD_AI_READY 스키마 생성

Autonomous AI Database에 ADMIN으로 접속하여 검증용 BAD_AI_READY 사용자를 생성합니다. 비밀번호는 SQLcl에서 대화형으로 입력하므로 SQL 파일에는 저장되지 않습니다.

00_admin_create_schema.sql

-- Run as ADMIN, SYS, or a user that can CREATE USER.
-- Usage in SQLcl:
-- @00_admin_create_schema.sql
...

sql admin/<ADMIN_PASSWORD>@adb_high @00_admin_create_schema.sql

실행 후에는 BAD_AI_READY로 다시 접속합니다.

3) BAD_AI_READY 계정으로 테이블 DDL 실행

01_create_bad_tables.sql에서는 코멘트, 기본 키(PK), 외래 키(FK), 최신성 열, 출처 열이 없는 8개 테이블을 생성합니다. 여기서 의도적으로 부족한 부분을 만듦으로써, 이후 Skill 평가와 개선 SQL의 효과를 비교하기 쉽게 합니다.

sql bad_ai_ready/<BAD_AI_READY_PASSWORD>@adb_high @01_create_bad_tables.sql

4) CSV 임포트

CSV 로드에는 SQLcl의 LOAD 명령을 사용합니다. 헤더가 포함된 UTF-8 CSV를 기존 테이블에 로드하여, 8개 테이블 총 448행을 등록합니다.

@02_load_csv.sql

5) 선택 사항: PUBLIC 권한 추가

Compliant 평가에서 넓은 데이터 액세스 권한이 탐지되는 것을 확인하기 위해, 다음 3개 테이블에 의도적으로 PUBLIC SELECT를 부여할 수 있습니다.

RAW_CUSTOMERS
RAW_ORDERS
SUPPORT_TICKETS

@03_optional_public_grants.sql

이 단계는 선택 사항이지만, 실행하면 개선 SQL의 REVOKE

까지 포함한 Before/After를 확인할 수 있습니다.

6) 평가 직전에 통계 정보 삭제

Autonomous AI Database에서는 통계 정보가 자동으로 수집되는 경우가 있습니다. 첫 번째 평가에서 통계 정보가 정비되지 않은 상태를 재현하기 쉽게 하기 위해, Skill 실행 직전에 삭제합니다.

@04_delete_stats_before_scan.sql

통계 정보는 자동 수집 타이밍에 따라 일부가 재생성될 수 있습니다. 따라서 종합 점수의 절대값뿐만 아니라, Mandatory gate나 각 coverage의 변화를 중심으로 확인합니다.

BAD_AI_READY의 준비가 완료되었으므로, 우선 개선 전 상태를 scan Profile로 평가합니다. oracle_ai_ready_collect.sql로 데이터 딕셔너리 (Data Dictionary)의 메타데이터를 수집하고, Python 스크립트로 리포트와 개선 SQL 후보를 생성합니다.

Skill은 실제 데이터의 모든 행을 읽어서 판정하는 것이 아니라, 주로 코멘트(Comment), 제약 조건(Constraint), 통계(Statistics), 열 타입(Column Type), 신선도·출처 후보, 권한 등을 평가합니다. 따라서 이번 사례처럼 행 데이터가 정합하더라도 메타데이터가 부족하면 낮은 평가를 받게 됩니다.

GitHub에서 리포지토리 (Repository)를 다운로드하여 Oracle SQLcl을 실행할 클라이언트에 배치합니다.

디렉터리 구조는 다음과 같습니다.

oracle-ai-ready-data/
├── README.md
├── SKILL.md
...

oracle-ai-ready-data에서는 SQLcl로 수집한 .out 파일을 입력으로 하여, 동일한 메타데이터로부터 평가 리포트와 개선 SQL을 생성합니다. 수집과 채점을 분리해 두었기 때문에, 수집 결과를 저장해 두고 다른 Profile로 재평가할 수도 있습니다.

1) 디렉터리 이동

cd oracle-ai-ready-data-main

2) 개선 전 메타데이터 수집

메타데이터 .out 파일이 출력됩니다.

이번 환경을 위해 인자(Argument)는 다음과 같이 사용합니다.

schema: admin
schema_owner: BAD_AI_READY

sql -s <schema>/<ADMIN_PASSWORD>@adb_high \ 
@scripts/oracle_ai_ready_collect.sql <schema_owner> % scan

3) 메타데이터 .out 파일 확인

이 파일을 사용하여 리포트를 정렬할 수 있습니다.

리포트 파일명은 oracle-ai-ready-data를 실행할 때 사용한 인자를 이용하여 생성됩니다.

ls -ltr
・・・
-rw-r--r-- 1 shirok staff 11988 Jul 21 13:05 oracle_ai_ready_scan_BAD_AI_READY_scan.out

4) 개선 전 리포트와 개선 SQL 후보 생성

python3 scripts/score_oracle_ai_ready_scan.py \ 
oracle_ai_ready_scan_BAD_AI_READY_scan.out \ 
--profile scan \ 
...

5) 생성 파일 확인

다음 3개의 파일이 생성되었는지 확인합니다. .out은 수집된 메타데이터, .md는 평가 결과, .sql은 부족한 항목에 대한 개선 후보입니다.

.md 마크다운 (Markdown) 파일: AI Ready 평가 리포트
.html HTML 파일: 사람이 확인하기 쉬운 AI Ready 평가 리포트
.sql 파일: AI Ready 개선 SQL 후보

$ ls -ltr
・・・
-rw-r--r-- 1 shirok staff 11988 Jul 21 13:05 oracle_ai_ready_scan_BAD_AI_READY_scan.out
...

--html-output을 지정하면, Markdown과 동일한 평가 내용을 카드, 상태 배지(Status Badge), 프로그레스 바(Progress Bar)로 확인할 수 있는 자기 완결형 HTML 리포트도 생성됩니다. CSS는 HTML 내에 포함되어 있으므로, 외부 CDN이나 JavaScript를 사용하지 않고 로컬 브라우저에서 바로 열 수 있습니다.

open bad_ai_ready_scan_before_report.html

Markdown은 GitHub나 Qiita에서의 공유, HTML은 리뷰 회나 브라우저에서의 확인용으로 구분하여 사용할 수 있습니다.

이번 실행에서는 종합 점수가 0.22였으며, Mandatory comment gate와 Comment quality review가 모두 fail로 나타났습니다. 또한, 숫자나 날짜로 취급될 가능성이 있는 문자열 타입(String type) 컬럼이 11건 검출되었습니다. 통계 정보는 Autonomous AI Database의 자동 수집 타이밍에 따라 일부 남아 있을 수 있으나, 코멘트, PK/FK, 신선도(Freshness), 출처(Provenance) 등 이번에 의도적으로 누락시킨 항목들은 예상대로 검출되었습니다.

리포트 전문은 길기 때문에 아래 접기(folding) 안에 게시합니다.

bad_ai_ready_scan_before_report.md 내용 (확인하려면 여기를 클릭하세요)

• 종합 점수:
  0.22 / 1.00 - Profile:
  scan - Mandatory comment gate:
  fail - Comment quality review:
  fail - Semantic type warnings:
  11건 - 결론:
  필수 코멘트 게이트 미달로 인해, 요구 정책상 미준비(Not Ready) 상태 - 코멘트 유무 체크는 필수 조건입니다. 코멘트 품질과 Semantic type mismatch는 초기 구현 단계에서는 경고(Warning)이며, 기존 점수에는 영향을 미치지 않습니다.

• Mandatory comment gate가 fail입니다. table comment 누락 8건, column comment 누락 52건이 있습니다.

• 기본 키(Primary Key)가 검출되지 않은 테이블이 8건 있습니다. RAG/Agent 응답의 근거 행을 안정적으로 참조하기 어려워집니다.

• PUBLIC 등 광범위한 데이터 액세스 권한 후보가 3건 있습니다. AI 이용 전에 공개 범위를 확인하십시오.

• 통계 정보가 미취득되었거나 오래된 테이블이 1건 있습니다. Clean/Current score의 주요 감점 요인입니다.

• 신선도(Freshness)를 나타내는 일시(Datetime) 컬럼이 검출되지 않은 테이블이 8건 있습니다. 데이터의 최신성을 설명하기 어려워집니다.

• 민감 정보(Sensitive information) 후보 컬럼이 10건 있습니다. 컬럼명 기반의 추정이므로 업무 담당자에 의한 분류가 필요합니다.

• VECTOR 타입 컬럼은 검출되지 않았습니다. 임베딩(Embedding)을 별도 스키마나 외부 서비스에서 관리하는 경우 설계서에 명시해 주십시오.

문자열(String) 타입이지만, 열 이름 또는 코멘트를 통해 숫자나 날짜로 취급될 가능성이 있는 열입니다. 추정 결과이므로 자동적인 타입 변경은 수행하지 않습니다.

-- Remediation: missing table comments
-- Reason: 테이블 코멘트가 없기 때문에, Contextual score와 mandatory comment gate가 저하됩니다.
-- Purpose: 테이블의 업무 목적, 입도, 업데이트 빈도, AI 이용 시 주의사항을 명문화합니다.
...

• 민감 정보 후보 열: 10건. 업무 소유자에 의한 분류가 필요합니다.

• 넓은 데이터 권한 후보: 3건. DBA 확인이 필요합니다.

• Semantic type mismatch 후보: 11건. 추정 결과이므로 업무 및 애플리케이션 사양과 대조하십시오.

• 기본 키(PK), 외래 키(FK), 업데이트 일시, 데이터 입도, 보존 기간은 애플리케이션 사양과 대조하십시오.

• 누락된 테이블 코멘트 8건, 컬럼 코멘트 52건을 보완하여 Mandatory comment gate를 pass 상태로 만듭니다.

• 구조 및 운영 메타데이터를 개선합니다: 기본 키 미정의 8개 테이블, 미취득 또는 오래된 통계 1개 테이블, 최신성(Freshness) 열 미정의 8개 테이블, 출처(Lineage) 열 미정의 8개 테이블.

• 문자열 타입으로 저장된 숫자·날짜 후보 11개 열을 확인하고, 타입이 지정된 열, 가상 열, 또는 AI용 View를 검토합니다.

• DBA 및 업무 소유자가 보안과 프라이버시를 확인합니다: 넓은 데이터 권한 3건, 민감 정보 후보 10개 열.

개선 전의 주요 지표를 추출하면 다음과 같습니다.

특히 중요한 것은 Mandatory comment gate입니다. 종합 점수가 일정 수준 이상이더라도, 테이블 또는 컬럼 코멘트가 단 하나라도 누락되면 본 정책에서는 未Ready (Ready 아님)로 처리됩니다.

열 이름만으로는 AMOUNT_TXT가 어떤 통화의 무엇을 나타내는지, CHURN_SCORE_TXT가 높을수록 좋은 것인지 나쁜 것인지, ORPHAN_REGIONS가 어떤 마스터 데이터인지 AI에게 충분히 전달할 수 없기 때문입니다.

또한, Skill이 생성한 SQL에는 코멘트의 TODO, 기본 키 후보, 최신성 열 후보, 통계 수집, PUBLIC 권한 리뷰 후보가 포함되어 있습니다. 이는 그대로 무조건 실행하는 완성된 SQL이 아니라, 데이터 모델과 업무 규칙을 확인하기 위한 출발점으로 활용합니다.

Skill이 생성한 개선 SQL에는 업무 소유자의 리뷰를 전제로 한 TODO 코멘트와 기본 키·최신성 열 후보가 출력되었습니다. Skill이 데이터 사전(Data Dictionary)만으로 업무상의 정확한 설명이나 키를 단정 짓는 것은 위험하기 때문에, 후보로서 출력되도록 설계되었습니다.

따라서 Skill이 생성한 bad_ai_ready_scan_before_improvement.sql은 원래의 후보로서 남겨두고, Remediation, Reason, Purpose, Review 구성을 유지한 검토 완료된 SQL을 bad_ai_ready_scan_before_improvement_reviewed.sql로 별도 파일로 생성했습니다. 이번 BAD_AI_READY 스키마에 맞춰 다음 내용을 구체화했습니다.

테스트 데이터는 유일성(Uniqueness)과 참조 무결성(Referential Integrity)을 충족하므로, 행 데이터(Row data)의 복구 과정을 거치지 않고 PK/FK를 추가할 수 있습니다. 다음 SQL은 개선 전 스키마에 대해 한 번만 실행한다는 전제하에 작성되었습니다.

검토 완료된 개선 SQL 내용은 여기를 클릭하세요

-- BAD_AI_READY Part 2: reviewed AI Ready remediation SQL.
--
-- oracle-ai-ready-data Skill 이 생성하는 개선 SQL 형식에 맞춰,
...

1) 디렉토리 이동 및 파일 확인

cd oracle-ai-ready-data-main
ls -1 bad_ai_ready_scan_before_improvement*.sql

bad_ai_ready_scan_before_improvement.sql
bad_ai_ready_scan_before_improvement_reviewed.sql

2) 개선 SQL 실행

검토가 완료된 bad_ai_ready_scan_before_improvement_reviewed.sql을 BAD_AI_READY에서 실행합니다. 만약 03_optional_public_grants.sql을 실행하지 않았다면, 3건의 REVOKE를 주석 처리하거나 권한 상황을 확인한 후 실행하십시오.

sql bad_ai_ready/<BAD_AI_READY_PASSWORD>@adb_high @bad_ai_ready_scan_before_improvement_reviewed.sql

3) 개선 후 메타데이터 검증

개선 SQL 실행 후에는 Skill을 재실행하기 전에 패키지 검증 SQL로 반영 상황을 확인합니다.

@08_verify_after_improvement.sql

주요 기대값은 다음과 같습니다.

이러한 사전 확인 과정을 거침으로써, 재평가 시 점수가 상승한 이유를 실제로 반영된 DDL과 매칭하여 설명할 수 있습니다.

개선 전의 BAD_AI_READY 스키마에는 기본키(Primary Key)와 외래키(Foreign Key)가 설정되어 있지 않았기 때문에, 각 테이블은 데이터베이스 메타데이터상에서 독립된 상태였습니다. 테이블 이름이나 컬럼 이름을 통해 사람이 관계를 추측할 수는 있어도, 데이터베이스 측에는 고객과 주문, 주문과 주문 상세와 같은 참조 관계가 정의되어 있지 않았습니다.

개선 SQL에서는 전체 8개 테이블에 기본키를 추가함과 동시에 고객, 주문, 주문 상세, 고객 특징량, 문의, 국가 코드 마스터 간의 관계를 5개의 외래키로 정의했습니다. 이를 통해 Relationship coverage와 Constraint coverage가 개선되어, Select AI에 테이블 간의 관계를 메타데이터로서 전달할 수 있게 됩니다.

그럼, 개선된 BAD_AI_READY 스키마를 Mermaid ER 다이어그램으로 확인해 보겠습니다.

모든 컬럼을 표시하면 도표가 복잡해지므로, 여기서는 기본키, 외래키, 그리고 후반부의 Select AI 검증에서 JOIN에 사용될 주요 컬럼만 표시합니다.

Mermaid ER 다이어그램을 확인하면, RAW_CUSTOMERS를 중심으로 다음과 같은 참조 관계가 정의되어 있음을 알 수 있습니다.

Mermaid ER 다이어그램을 확인하면, RAW_CUSTOMERS를 중심으로 다음과 같은 참조 관계가 정의되어 있음을 알 수 있습니다.

특히, 주문 데이터의 중심이 되는 3개 테이블은 다음과 같이 연결되어 있습니다.

RAW_CUSTOMERS
|
|
CUSTOMER_ID
...

이 관계를 외부 키(FK)로 정의함으로써, 고객에서 주문으로, 주문에서 주문 명세로 이어지는 JOIN 조건이 명확해졌습니다. 후반부 Select AI 검증에서는 AI Profile에서 constraints=true을 활성화하고, 이 PK/FK 정보를 SQL 생성용 컨텍스트에 포함합니다.

개선 전후를 ER 다이어그램 관점에서 정리하면 다음과 같습니다.

AI_DOCUMENTS와 EMPTY_EXPORT는 이번 데이터 모델에서 다른 테이블을 참조하지 않는 독립적인 용도의 테이블입니다. ER 다이어그램 상에 외부 키 선이 없다는 것 자체는 문제가 아니며, 각각에 기본 키(PK)가 설정되어 행을 고유하게 식별할 수 있는 상태임을 확인합니다.

참고로, Mermaid ER 다이어그램으로 시각화되는 것은 주로 PK/FK와 같은 구조적인 개선입니다. 이번 AI Ready 개선에는 테이블/컬럼 주석, 통계 정보, UPDATED_AT, SOURCE_SYSTEM 등의 포함, 민감 정보 후보 설명, PUBLIC 권한 삭제도 포함됩니다. 이들을 모두 포함한 최종적인 개선 결과는 이어서 oracle-ai-ready-data Skill을 재실행하여 확인합니다.

개선 전과 동일한 scan Profile로 메타데이터를 재수집합니다. Profile이나 대상 테이블을 변경하지 않고 재평가함으로써, 개선 SQL에 의한 변화를 비교할 수 있습니다. Before/After 파일을 덮어쓰지 않도록, 개선 후 출력명에는 after를 붙입니다.

**1) 디렉토리 이동