지난 기사에서 Google Cloud가 공개한 OKF (Open Knowledge Format)의 사양을 정리했습니다.

OKF는 Markdown + YAML frontmatter로 지식을 구조화하는 포맷이지만, 사양을 읽는 것만으로는 "그래서 무엇이 좋은가?"라는 점이 잘 보이지 않는다고 느꼈습니다.

데이터 기반(Data Platform) 프로젝트에서는 "이 컬럼은 어디서 왔지?", "테이블 간의 관계는?", "이 컬럼을 바꾸면 어디에 영향을 주지?"와 같은 질문이 일상적으로 발생합니다. 이러한 의문에 대해 OKF로 구조화한 정보를 AI에게 읽히면 자동으로 답을 얻을 수 있지 않을까 하는 가설을 검증해 보겠습니다.

본 기사에서는 가상의 EC 사이트를 주제로 OKF 번들(Bundle)을 작성하고, AI에게 데이터 리니지(Data Lineage) 도표와 ER도를 자동 생성하게 합니다.

아래에 특징을 정리합니다.

OKF의 핵심을 3가지 포인트로 되돌아봅니다.

• 1파일 = 1컨셉 (테이블, 대시보드 등)
• frontmatter (YAML)로 type을 선언하고, 독자적인 키를 자유롭게 추가할 수 있음
• cross-link (표준 Markdown 링크)로 Concept 간의 관계를 표현함

위의 메커니즘을 사용하여 AI에게 다음을 자동 생성하게 합니다.

• 데이터 리니지(Data Lineage) 도표 (컬럼 레벨)
• ER도 (테이블 간 관계)
• 영향 분석 (변경 파급처 특정)
• 시험 계획서

가상의 EC 사이트를 주제로 합니다. 구성은 다음과 같습니다.

EC 사이트 (PostgreSQL) Spark ETL S3 (Parquet) Athena → QuickSight
┌──────────────────┐ ┌────────────┐ ┌──────────────────────┐
│ orders │ │ │ │ Bronze（그대로） │
...

먼저, 아래와 같이 steering과 skill을 준비합니다.

ec-knowledge/
├── .kiro/
│ ├── steering/
...

아래와 같은 번들 구성으로 했습니다.

ec-knowledge/
├── index.md
├── tables/
...

이후, 각 레이어의 대표적인 파일을 게재합니다.

---
type: PostgreSQL Table
title: orders
...

---
type: PostgreSQL Table
title: order_items
...

(생략. customers는 customer_id, customer_name, email, prefecture, registered_at. products는 product_id, product_name, category, sub_category, list_price.)

---
type: Bronze Table
title: bronze_orders
...

(bronze/order_items.md, bronze/customers.md, bronze/products.md 도 동일 구조. 생략.)

---
type: Silver Table
title: silver_orders
...

---
type: Silver Table
title: silver_customers
...

---
type: Silver Table
title: silver_products
...

---
type: Gold Table
title: daily_sales
...

---
type: Gold Table
title: customer_purchase_summary
...

---
type: Gold Table
title: category_trends
...

---
type: Gold Table
title: rfm_scores
...

---
type: QuickSight Dashboard
title: 매출 대시보드
...

---
type: QuickSight Dashboard
title: 고객 분석 대시보드
...

---
type: QuickSight Dashboard
title: 상품 분석 대시보드
...

위의 Step 1에서 OKF를 통해 번들을 구축했습니다. 다음은 프롬프트를 실행합니다.

다음과 같은 프롬프트를 실행합니다.

10% λ > 다음의 OKF 번들을 읽고, daily_sales_dm의 컬럼 레벨 데이터 리니지 (Data Lineage)를 Mermaid 플로우차트로 출력해 주세요. Source 열의 링크를 따라가서, 각 컬럼이 어떤 테이블의 어떤 컬럼으로부터 왔는지 보여주세요. @generate-lineage를 사용할 것

실행이 시작됩니다.

> 먼저 daily_sales_dm 파일을 찾아 스키마를 읽습니다. Searching for files: **/*daily_sales* (using tool: glob) ✓ Successfully found 2 files under current directory - Completed in 0.6s > daily_sales_dm이 아니라 daily_sales가 Gold 레이어에 있습니다. 이를 읽습니다. Reading file: /XXXXX/ec-knowledge/tables/gold/daily_sales.md, all lines (using tool: read) ✓ Successfully read 908 bytes from /XXXXX/ec-knowledge/tables/gold/daily_sales.md - Completed in 0.0s ・・・・・・ 보충: - silver_orders.line_amount는 quantity * unit_price의 ETL 산출 컬럼 (Bronze 레이어의 2개 컬럼에서 파생) - total_quantity / total_amount는 SUM 집계임을 에지 레이블 (Edge Label)로 명시 - daily_sales_dm이라는 이름의 테이블은 번들 내에 존재하지 않았으므로, Gold 레이어의 daily_sales를 리니지 대상으로 설정했습니다

출력된 리니지를 확인합니다. 컬럼 레벨의 리니지가 생성되었습니다.

프롬프트를 실행합니다.

@generate-er-diagram을 사용하여 다음 OKF 번들의 Schema 섹션을 읽고, 테이블 간의 관계를 Mermaid ER 다이어그램으로 출력해 주세요. FK의 크로스 링크 (cross-link, Markdown 링크)를 통해 관계를 판정해 주세요.

실행됩니다.

> 먼저 스킬의 정의를 확인합니다. ・・・ - Summary: 6 operations processed, 6 successful, 0 failed - Completed in 0.5s > 모든 테이블의 정보가 준비되었습니다. 레이어별로 ER 다이어그램을 생성하여 파일로 출력합니다.

프롬프트를 실행합니다.

OKF 번들 내에서 orders.customer_id를 삭제했을 때의 영향 범위를 알려주세요. 크로스 링크 (cross-link)를 역추적하여, 영향을 받는 파일과 컬럼을 나열해 주세요. 또한, QuickSight에 미치는 영향도 고려해 주세요.

실행됩니다.

먼저 impact-analysis 스킬을 확인합니다 ・・・ > 스킬의 절차에 따라 source/orders.customer_id로부터 하류 (downstream)를 재귀적으로 추적합니다. 이미 읽어들인 모든 테이블 정보로 역추적할 수 있습니다.

분석 결과를 확인합니다. 그럴듯한 결과가 나왔습니다.

■ 영향 분석: source.orders.customer_id 삭제 ### 직접 영향 | 파일 | 컬럼 | 영향 | |----------|--------|------| | tables/bronze/orders.md | customer_id | 소스 소실 → 취득 불가 | ### 간접 영향 (Level 1: Bronze → Silver) | 파일 | 컬럼 | 영향 | |----------|--------|------| | tables/silver/orders.md | customer_id | 상류 Bronze 소실 → 취득 불가 | ### 간접 영향 (Level 2: Silver → Gold) | 파일 | 컬럼 | 영향 | |----------|--------|------| | tables/gold/customer_purchase_summary.md | customer_id | 집계 키 소실 → 테이블 전체 생성 불가 | | 위와 동일 | customer_name, prefecture, total_orders, total_amount, first_order_date, last_order_date | 고객별 GROUP BY 불가 | | tables/gold/rfm_scores.md | customer_id | 집계 키 소실 → 테이블 전체 생성 불가 | | 위와 동일 | recency_days, frequency, monetary, r_score, f_score, m_score, rfm_segment | 고객별 산출 불가 | ### 간접 영향 (Level 3: Gold → QuickSight) | 대시보드 | 비주얼 | 영향 | |---------------|-----------|------| | 고객 분석 대시보드 | No.1 도도부현별 고객 수 | customer_purchase_summary 소실 → 표시 불가 | | 위와 동일 | No.2 구매 금액 분포 | 위와 동일 | | 위와 동일 | No.3 RFM 세그먼트 구성 | rfm_scores 소실 → 표시 불가 | | 위와 동일 | No.4 우량 고객 리스트 | 위와 동일 | ### 영향을 받지 않는 테이블 - tables/gold/daily_sales.md — customer_id를 사용하지 않음 - tables/gold/category_trends.md — 위와 동일 - 매출 대시보드 / 상품 분석 대시보드 — 위와 동일 ### 요약 | 지표 | 건수 | |------|------| | 영향 파일 수 | 7건 (Bronze 1 + Silver 1 + Gold 2 + Dashboard 1 + ETL 플로우 2) | | 영향 컬럼 수 | 15건 | | QuickSight 영향 비주얼 수 | 4건 (고객 분석 대시보드 전멸) | orders.customer_id를 삭제하면, 고객 축의 분석 기반이 완전히 붕괴됩니다. 매출·카테고리 계열은 무사합니다.`

이번에는 테스트 계획서(Test Plan)를 생성하게 합니다.

프롬프트를 실행합니다.

다음 OKF 번들을 읽고, daily_sales_dm의 테스트 계획서를 작성해 주세요. Schema (타입·NULL 허용 여부), Source 열 (출처), SQL (변환 로직), cross-link (참조 관계) 모두를 근거로 테스트 케이스를 도출해 주세요.

실행이 시작됩니다.

실행이 시작됩니다.

먼저 스킬 정의와 ETL 플로우를 확인합니다. Batch fs_read 작업은 2개의 작업을 사용합니다 (도구: read) ↓ 작업 1: 파일 읽기: /XXXXX/ec-knowledge/.kiro/skills/generate-test-plan.md, 모든 라인 ↓ 작업 2: 파일 읽기: /XXXXX/ec-knowledge/flows/etl_gold_daily_sales.md, 모든 라인 ✔ 성공적으로 1106 바이트를 /XXXXX/ec-knowledge/.kiro/skills/generate-test-plan.md에서 읽음 ✔ 성공적으로 1326 바이트를 /XXXXX/ec-knowledge/flows/etl_gold_daily_sales.md에서 읽음 ⋮ - 요약: 2개의 작업 처리, 2개 성공, 0개 실패 - 0.2초 만에 완료 > 모든 정보가 갖춰졌습니다. 테스트 계획서를 생성합니다.

확인했습니다. 테스트 계획서에는 화이트박스 테스트(White-box test)나 경계값 분석(Boundary value analysis)의 관점이 포함되어 있지 않았기 때문에, 단일 테스트(Unit test)로서는 앞으로 정교화할 수 있을 것 같습니다.

이번에 OKF를 사용해 보니, OKF의 본질은 인간의 문서를 AI의 인터페이스로 만든 것이라는 것을 알았습니다. 앞으로는 '설계서 → 테스트 계획 생성 → 구현 → 검증'의 사이클을 계속 돌리고 싶습니다.

아래는 이번 건에서 느낀 점들입니다.

• Source 열이 없으면 AI가 리니지(Lineage)를 생성할 수 없습니다. '어디에서 왔는지'가 구조화되어 있는 것이 전제 조건입니다.
• cross-link (Markdown 링크)가 없으면 ER 다이어그램의 FK 관계를 판별할 수 없습니다. Description에 단순히 글로 적혀만 있는 것만으로는 정확도가 떨어집니다.
• OKF의 '독자 키 자유 확장' (§4.1 Extensions) 기능이 Source 열 추가를 가능하게 합니다. 사양이 엄격했다면 이 응용은 불가능했을 것입니다.
• 엑셀 설계서로도 같은 정보는 작성할 수 있지만, AI가 직접 읽게 하려면 번거로운 과정이 필요하고 정확도도 떨어집니다. OKF(Markdown)라는 것이 자동 생성의 전제 조건입니다.
• 반대로 말하면, OKF가 아니더라도 'Markdown + Source 열 + 링크'만 있다면 같은 것은 가능합니다. OKF의 가치는 이 구조를 사양으로 표준화했다는 점에 있습니다.