[LangChain RAG 구축 시리즈 Ep.05] 🧩 왜 metadata.json을 문서처럼 다뤄야 할까?

이 글에서는 RAG 시스템에 Iceberg의 metadata.json을 입력으로 활용할 때,
왜 이 구조화된 JSON 파일을 자연어 기반 문서처럼 가공해야 하는지, 그리고
어떻게 가공해야 검색 성능이 좋아지는지를 실제 예시와 함께 알아보겠습니다.

---

❓ JSON 그대로 임베딩하면 안 되나요?

많은 분들이 처음엔 이렇게 생각할 수 있습니다:

“metadata.json은 구조가 잘 되어 있는데, 그냥 통째로 벡터화하면 되는 거 아냐?”

하지만 실제로는 그대로 벡터화하면 RAG 성능이 매우 떨어집니다.

---

🧱 구조적 JSON → 의미 중심 텍스트로 바꿔야 하는 이유

문제	설명
⚠️ 벡터가 정보의 핵심을 놓침	“field-id”, “source-id” 같은 키워드가 의미를 흐림
⚠️ LLM이 이해하기 어려움	LLM은 자연어 문맥에 강하고, JSON 구조에는 약함
⚠️ 검색 품질 저하	사용자가 “상품 테이블”이라고 검색해도 "table_name": "products"를 찾지 못함

---

✅ 해결 전략: 의미 중심 텍스트로 전처리

원본 metadata.json 예시

{
  "schema": {
    "fields": [
      { "id": 1, "name": "product_id", "type": "long" },
      { "id": 2, "name": "product_name", "type": "string" }
    ]
  },
  "partition-spec": [
    { "source-id": 2, "name": "product_name", "transform": "identity" }
  ]
}

전처리된 텍스트 예시

📂 테이블: products  
🔢 컬럼:  
- product_id (long)  
- product_name (string)  
🧩 파티션 기준: product_name

➡️ 이런 방식으로 문서화해야 LLM이 “이 테이블은 상품 정보를 담고 있다”고 판단할 수 있습니다.

---

🛠️ 전처리 기본 전략 요약

항목	처리 방식	설명
컬럼 리스트	컬럼명 (타입)으로 나열	구조를 명확히 보여줌
파티션 정보	“Partitioned by: 컬럼명” 문장화	쿼리 필터에 도움
테이블 설명 (Optional)	존재 시 상단에 요약 작성	검색 우선순위 ↑

---

🤖 이렇게 바꿔야 RAG에서 잘 검색됩니다

사용자 질문:

“상품 카테고리별로 나뉜 테이블이 뭐야?”

기존 JSON:

• 검색 실패 (keyword mismatch)

전처리 텍스트:

• "Partitioned by: category" → ✅ 검색 성공

---

📌 실제 적용 방식

RAG 시스템에서는 metadata.json을 로딩한 후 다음과 같이 전처리합니다:

1. Python 코드로 JSON 파싱
2. 테이블명, 컬럼, 파티션 정보를 자연어 문서로 변환
3. 이 텍스트를 LangChain 임베딩에 전달

---

📎 요약 및 핵심 정리

• metadata.json은 그대로 벡터화하면 검색 품질이 낮아집니다.
• 구조적 JSON 데이터를 자연어 중심 문서로 가공해야 LLM이 이해할 수 있습니다.
• 테이블명, 컬럼, 파티션을 텍스트 문서처럼 표현하면 RAG 성능이 극대화됩니다.