WIKIM 통합데이터플랫폼 — 데이터 수집 방법론

수천 건의 조직 문서를 한 번만 읽고 여러 형태로 재활용하는 수집·정규화 전략
— 연구원 내부 활용과 대외 RAG 서비스를 동시에 지향

Ingest Once, Project Many Canonical Layer Vector + Graph GraphRAG K-FERM Phase 1→2→3

1문제의식

WIKIM 통합데이터플랫폼은 두 방향의 요구를 동시에 만족해야 한다.

연구원 내부용: 문헌·조사자료 검색, 관계 탐색, 표준 연계
대외 서비스용: 질의응답(RAG), 지식 서비스

"일단 온톨로지/지식그래프로만 구축을 끝내면, 나중에 RAG 서비스를 붙일 때 그 수천 개의 문서를 처음부터 다시 읽어야 하는 것 아닌가?"

이 우려는 정당하다. 그리고 이를 방지하는 것이 본 방법론의 목표다. 핵심은 저장 "형식"(그래프냐 벡터냐)을 먼저 정하는 문제가 아니라, 문서를 한 번만 읽어 재활용 가능한 중간 자산으로 남기느냐의 문제다.

2핵심 원칙 — Ingest Once, Project Many

데이터 처리에서 진짜 비용이 드는 단계와 언제든 재실행 가능한 단계를 분리한다. 영속 저장해야 할 진짜 자산은 고정된 청크나 트리플이 아니라, 구조가 보존된 파싱 결과(Canonical Layer)이며, 벡터 스토어와 그래프 DB는 모두 이 계층에서 파생(project)되는 산출물이다.

그림 1. 원본은 한 번만 파싱(비쌈), 벡터·그래프는 Canonical Layer에서 재실행(쌈)

💰 비싼 작업 — 딱 한 번

파싱(Parsing): PDF·HWP·이미지 → 텍스트, OCR, 표·레이아웃 복원. 느리고 포맷 의존적이며, 재실행 시 원본이 필요하다.

♻️ 싼 작업 — 언제든 재실행

청킹 · 임베딩 · 관계추출: 저장된 파싱 결과에서 다시 돌린다. RAG 피드백·스키마 진화에 따라 반복 실행하며, 원본은 다시 읽지 않는다.

3파싱과 청킹을 같은 계층으로 묶지 말 것

RAG 품질은 청킹 전략(청크 크기·경계)에 크게 좌우되며, 최적값은 실제 RAG로 답변을 뽑아봐야 알 수 있고 파일 포맷마다 다르다.

너무 작게 자르면 → 맥락 상실
너무 크게 자르면 → 어떤 질문에도 비슷한 답만 반환

그러므로 청킹을 "한 번 하고 고정"하면 안 된다. 청킹은 버전 관리되는 파생물로 취급하고, 파싱 결과 위에서 몇 번이고 다시 돌릴 수 있어야 한다.

구분	파싱 (Parsing)	청킹 (Chunking)
성격	비싸다 · 느리다	싸다 · 빠르다
안정성	한 번 잘 하면 재활용	RAG 피드백으로 계속 튜닝
포맷 의존	높음 (포맷별 파서)	높음 (전략 실험)
재실행 시	원본 문서 필요 → 피해야 함	저장된 파싱본에서 재실행 → 원본 불필요

4구조 보존 파싱 (Structure-Preserving Parsing)

단순히 "텍스트 한 덩어리"로 저장하면 재청킹이 불가능하다. 재청킹·재추출을 가능하게 하는 구조 정보를 함께 저장해야 한다.

그림 2. 구조 정보만 보존하면 청크 전략을 몇 번이든 재생성 — 원본 재파싱 없음

문서 구조: 제목 / 절 / 문단 / 리스트 / 표 경계 (semantic boundaries)
위치 메타(Provenance): 문서 ID · 페이지 · offset · 좌표
표·그림: 별도 구조로 보존 (텍스트로 뭉개면 RAG·KG 모두 손상)

5진짜 위험은 청킹이 아니라 "파싱 품질" — 파일럿 우선

청킹은 재실행이 싸므로 나중에 튜닝하면 된다. 정작 나중에 원본을 다시 읽게 만드는 원흉은 "파싱 자체가 틀린 경우"다 (표가 깨지고, 단이 뒤섞이고, OCR이 엉망). 이는 포맷마다 다르며, 대량 처리 후 발견하면 수천 문서를 다시 파싱해야 한다.

그림 3. 데이터 수집 순서 — 파일럿이 재작업을 막는 관문

6계층형 아키텍처

원본은 한 번만 읽고, 벡터 스토어와 그래프 DB는 Canonical Layer에서 파생한다. 두 저장소는 chunk_id / 개념 IRI로 상호 참조하여 출처 추적과 GraphRAG 결합을 가능하게 한다.

그림 4. Ingest Once → 벡터·그래프 이중 투영 → GraphRAG 결합

7K-FERM 진화 전략과의 정합

본 방법론은 K-FERM의 3단계 진화 전략(Phase 1→2→3)과 정확히 맞물린다. 완벽한 지식그래프 완성을 기다릴 필요 없이 Phase 1부터 즉시 서비스가 가능하며, Phase 2·3은 원본을 다시 읽지 않고 Canonical Layer 위에서 진화한다.

그림 5. K-FERM Phase 1→2→3 — 동일한 중간 계층 위에서 점진적 진화

8안티패턴 · 요약

피해야 할 안티패턴

트리플만 뽑고 원문 텍스트·청크를 버리는 경우 → RAG하려면 처음부터 재파싱 ❌
그래프 DB를 유일 저장소로 삼고 출처(provenance)를 안 남기는 경우 → 출처 추적·RAG 결합 불가 ❌
청킹을 한 번 고정하고 재실행 불가하게 굳히는 경우 → RAG 튜닝 시 재작업 ❌
파일럿 없이 수천 문서를 대량 파싱하는 경우 → 파싱 결함 발견 시 전량 재처리 ❌

통합데이터플랫폼은 처음부터 완성형 GraphRAG를 무리하게 만들 필요는 없다. 그러나 데이터 수집 계층은 처음부터 벡터·그래프 두 방향을 모두 염두에 두고, "문서를 한 번 읽어 구조 보존 파싱본(Canonical Layer)에 저장하고, 벡터·그래프는 그로부터 파생"하는 구조로 설계해야 한다. 그러면 나중에 RAG 서비스를 붙이거나 온톨로지 스키마가 진화해도 수천 문서를 다시 읽는 일은 없다.