---
tags: [research, rag, robeing, postgres, graph, relations]
---

# PostgreSQL 그래프확장 설계 리서치

## 상태

- proposed

**작성일**: 2026-03-20  
**목적**: 별도 그래프 DB 없이 PostgreSQL 안에서 문서 연결성과 탐색성을 얼마나 가져갈 수 있는지 정리한다.

---

## 1. 결론

- 지금 단계에서 별도 그래프 DB를 바로 도입할 필요는 없다.
- PostgreSQL만으로도 문서 간 연결, 태그 기반 연결, 재귀 탐색은 상당 부분 구현 가능하다.
- 로빙의 현재 목표는 "그래프 DB 도입" 자체가 아니라 "근거 문서 연결성을 높이는 것"이므로, 우선 Postgres 확장으로 충분하다.

## 2. 연결 원천

- front matter의 `related`
- 공통 `tags`
- 공통 `keywords`
- 같은 폴더/프로젝트/작성자
- 벡터 유사도 상 가까운 문서

## 3. 권장 테이블

```sql
create table if not exists document_relations (
    id bigserial primary key,
    from_document_id bigint not null references document_files(id) on delete cascade,
    to_document_id bigint not null references document_files(id) on delete cascade,
    relation_type text not null,
    weight numeric(6,3),
    metadata_jsonb jsonb not null default '{}'::jsonb,
    created_at timestamptz not null default now(),
    unique (from_document_id, to_document_id, relation_type)
);

create index if not exists idx_document_relations_from
    on document_relations (from_document_id);

create index if not exists idx_document_relations_to
    on document_relations (to_document_id);

create index if not exists idx_document_relations_metadata
    on document_relations using gin (metadata_jsonb);
```

## 4. relation_type 예시

- `explicit_related`
- `same_folder`
- `same_project`
- `shared_tag`
- `shared_keyword`
- `semantic_neighbor`
- `derived_from`

## 5. 내가 추천하는 연결 생성 방식

### 5.1 명시 연결 우선

- front matter의 `related`는 사람이 검증한 연결이므로 신뢰도가 높다.

### 5.2 규칙 기반 연결 다음

- 같은 폴더, 같은 프로젝트, 같은 태그 등은 자동 생성하기 쉽다.

### 5.3 벡터 기반 연결은 후순위

- 유사도만으로 연결하면 오탐이 많을 수 있다.
- `semantic_neighbor`는 보조 연결로만 두는 것이 맞다.

## 6. 재귀 탐색 예시

```sql
with recursive related_docs as (
    select
        df.id,
        df.title,
        0 as depth
    from document_files df
    where df.id = $1

    union all

    select
        df2.id,
        df2.title,
        rd.depth + 1
    from related_docs rd
    join document_relations dr
      on dr.from_document_id = rd.id
    join document_files df2
      on df2.id = dr.to_document_id
    where rd.depth < 3
)
select distinct id, title, min(depth) as min_depth
from related_docs
group by id, title
order by min_depth, id;
```

## 7. 왜 이 정도면 충분한가

- 로빙이 필요로 하는 것은 수십억 노드 그래프 분석이 아니다.
- 질문에 대한 근거 문서 묶음, 연관 문서 체인, 같은 프로젝트 맥락 정도면 충분하다.
- 이 범위는 PostgreSQL과 재귀 쿼리로 관리 가능하다.

## 8. 그래프 DB를 나중에 도입해야 하는 조건

- 관계 유형이 너무 많아지고 실시간 그래프 탐색이 핵심이 될 때
- 연결 시각화가 제품의 핵심 화면이 될 때
- 추천, 경로 분석, 중심성 분석이 주 서비스가 될 때

## 9. 현재 추천

- 지금은 PostgreSQL 안에서 `document_files`, `document_relations`, PGVector를 함께 운영한다.
- relation 생성 규칙을 먼저 고정하고, retrieval 품질 향상 여부를 검증한다.
- 그래프 DB는 필요가 입증될 때 별도로 도입한다.

## 10. 관련 문서

- [PGVector·JSONB RAG 스키마 설계 리서치](./260320_PGVector_JSONB_RAG_스키마_설계_리서치.md)
- [Front Matter 메타데이터 설계 리서치](./260320_FrontMatter_메타데이터_설계_리서치.md)