---
tags: [research, rag, robeing, ingestion, normalization, multimodal]
---

# 다형식 문서 RAG 자동수집·정규화 전략 리서치

## 상태

- proposed

**작성일**: 2026-03-20  
**목적**: 로빙이 여러 형식의 파일을 읽고, 검색 가능하고, 자동으로 갱신되는 지식 자산으로 만드는 전체 방향을 정리한다.

---

## 1. 문제 정의

- 로빙이 다뤄야 하는 원본은 PDF, HWP, DOCX, XLSX, PPTX, JPG, PNG, MP4처럼 형식이 매우 다양하다.
- 파일 수가 수만 건 규모로 커지면 단순 텍스트 추출만으로는 관리가 무너진다.
- 파일이 계속 생성·수정·삭제되므로 일회성 적재가 아니라 지속 동기화 구조가 필요하다.
- 최종 목표는 단순 검색기가 아니라, 로빙이 근거를 찾아 읽고 답변하고, 점점 더 똑똑해지는 구조다.

## 2. 이번 리서치의 결론

- **원본 보존, 중간표현 정규화, 저장계층 분리**가 핵심이다.
- 원본 파일은 그대로 두고, 로빙이 읽는 표준 중간표현을 별도로 생성해야 한다.
- 중간표현은 Markdown을 기본으로 하고, 메타데이터는 front matter와 PostgreSQL JSONB 양쪽에 반영 가능하게 설계한다.
- 검색은 `키워드 검색 + 벡터 검색 + 연결 탐색`을 함께 가져가야 한다.
- OCR과 LLM은 전체 전수 적용이 아니라 메타 기반 선별 적용이 맞다.

## 3. 목표 아키텍처

| 계층 | 역할 | 권장 형태 |
|------|------|-----------|
| 원본 계층 | 실제 파일 보존 | NAS/파일시스템 원본 |
| 중간표현 계층 | 로빙이 읽는 표준 문서 | Markdown 1:1 파생본 |
| 메타 계층 | 검색/운영/동기화 상태 | front matter + JSONB |
| 검색 계층 | 키워드/의미/연결 검색 | PostgreSQL + PGVector |
| 확장 계층 | 그래프형 연결 탐색 | related/tags 기반 Postgres 그래프 |

## 4. 내가 추천하는 설계 원칙

### 4.1 Markdown을 중간표현으로 둔다

- 이유 1: 사람도 읽을 수 있고, LLM도 읽기 쉽다.
- 이유 2: 파일 하나에 대한 요약, OCR 추가 결과, 후속 분석을 누적하기 쉽다.
- 이유 3: 나중에 임베딩을 다시 만들더라도 원본 재파싱 없이 중간표현만 다시 읽으면 된다.

### 4.2 원본과 파생본은 1:1 대응으로 관리한다

- `원본 파일 1개 -> MD 파일 1개`가 기본이다.
- 파일 수가 많을수록 폴더 구조 유지가 중요하다.
- 이 방식은 삭제, 재생성, 부분 재처리, 감사 추적에 모두 유리하다.

### 4.3 PostgreSQL을 중심 허브로 둔다

- 이미 PGVector를 쓰고 있으면 별도 벡터 DB를 늘리는 것보다 운영 복잡도를 줄이는 편이 낫다.
- 메타데이터, 문서 상태, 임베딩, 문서 간 관계를 한 DB에서 관리할 수 있다.
- Chroma/FAISS는 빠른 실험에는 유리하지만, 로빙의 장기 운영 SSOT로는 PostgreSQL 쪽이 더 일관적이다.

## 5. 처리 흐름 제안

1. 원본 스캔
2. 파일 타입 식별
3. 기본 메타 추출
4. Markdown 파생본 생성
5. 선별 OCR 또는 후처리 판단
6. 문단/청크 단위 분리
7. 임베딩 생성
8. PostgreSQL 적재
9. 생성·수정·삭제 동기화 반영

## 6. 자동화 관점의 핵심 포인트

- 새 파일 생성 시: 같은 상대 경로에 MD 생성
- 파일 수정 시: MD와 임베딩 재생성 필요 여부 판정
- 파일 삭제 시: MD와 DB 레코드를 hard delete하지 말고 `deleted` 상태 우선 기록
- OCR 미적용 파일은 `ocr_pending` 같은 상태로 남겨 후속 배치 대상화

## 7. 왜 이 구조가 로빙을 더 똑똑하게 만드는가

- 로빙은 원본 형식에 직접 종속되지 않고, 표준화된 중간표현을 읽게 된다.
- front matter와 JSONB 메타를 통해 "표가 많은 문서", "이미지가 많은 PDF", "최근 수정된 계약서" 같은 질의를 더 잘 처리할 수 있다.
- PGVector는 의미 검색을 맡고, 메타 조건은 SQL이 맡고, related/tags는 연결 탐색을 맡는다.
- 결과적으로 "단순 벡터 검색"보다 훨씬 정교한 근거 회수와 응답 합성이 가능해진다.

## 8. 이번 단계에서 보류해야 할 것

- 모든 파일에 전수 OCR
- 모든 파일에 전수 LLM 요약
- 별도 그래프 DB를 즉시 도입하는 것
- 원본 형식별 완벽 보존을 목표로 지나치게 복잡한 파서 체인을 먼저 만드는 것

## 9. 추천 실행 순서

1. Markdown 중간표현 규칙 고정
2. front matter 메타 스키마 고정
3. PostgreSQL 기본 테이블과 JSONB 구조 고정
4. OCR 선별 정책 고정
5. 100~500개 파일로 샘플 검증
6. 이후 배치 자동화와 증분 동기화로 확대

## 10. 관련 문서

- [Markdown 중간표현 SSOT 설계 리서치](./260320_MD_중간표현_SSOT_설계_리서치.md)
- [Front Matter 메타데이터 설계 리서치](./260320_FrontMatter_메타데이터_설계_리서치.md)
- [OCR 선별 적용 정책 리서치](./260320_OCR_선별적용_정책_리서치.md)
- [PGVector·JSONB RAG 스키마 설계 리서치](./260320_PGVector_JSONB_RAG_스키마_설계_리서치.md)
- [PostgreSQL 그래프 확장 설계 리서치](./260320_PostgreSQL_그래프확장_설계_리서치.md)
