diff --git a/journey/plans/260320_다형식문서_RAG_3차_OCR_관계확장_동기화_계획.md b/journey/plans/260320_다형식문서_RAG_3차_OCR_관계확장_동기화_계획.md
index 465df37..bb62cd6 100644
--- a/journey/plans/260320_다형식문서_RAG_3차_OCR_관계확장_동기화_계획.md
+++ b/journey/plans/260320_다형식문서_RAG_3차_OCR_관계확장_동기화_계획.md
@@ -8,7 +8,7 @@
 ## 참조 문서
 
 - [OCR 선별 적용 정책 리서치](../research/rag/260320_OCR_선별적용_정책_리서치.md)
-- [PostgreSQL 그래프확장 설계 리서치](../research/rag/260320_PostgreSQL_그래프확장_설계_리서치.md)
+- [PostgreSQL 그래프확장 설계 리서치](../research/rag/260320_PostgreSQL_그래프확장_설계_리서치.md) — **Apache AGE 도입으로 방향 변경**
 
 ## 범위
 
diff --git a/journey/plans/260320_로빙_다형식문서_RAG_적용1_계획.md b/journey/plans/260320_로빙_다형식문서_RAG_적용1_계획.md
index 228fcaf..2ed2888 100644
--- a/journey/plans/260320_로빙_다형식문서_RAG_적용1_계획.md
+++ b/journey/plans/260320_로빙_다형식문서_RAG_적용1_계획.md
@@ -11,6 +11,7 @@
 - [다형식문서 RAG 1차 MD·메타 정규화 계획](./260320_다형식문서_RAG_1차_MD_메타_정규화_계획.md)
 - [다형식문서 RAG 2차 PGVector·JSONB 적재 계획](./260320_다형식문서_RAG_2차_PGVector_JSONB_적재_계획.md)
 - [다형식문서 RAG 3차 OCR·관계확장·동기화 계획](./260320_다형식문서_RAG_3차_OCR_관계확장_동기화_계획.md)
+- [PostgreSQL 그래프확장 설계 리서치 (Apache AGE)](../research/rag/260320_PostgreSQL_그래프확장_설계_리서치.md)
 
 ## 현재 상태 (260320 확인)
 
diff --git a/journey/research/rag/260320_PostgreSQL_그래프확장_설계_리서치.md b/journey/research/rag/260320_PostgreSQL_그래프확장_설계_리서치.md
index 58a246d..7288fe0 100644
--- a/journey/research/rag/260320_PostgreSQL_그래프확장_설계_리서치.md
+++ b/journey/research/rag/260320_PostgreSQL_그래프확장_설계_리서치.md
@@ -6,18 +6,29 @@ tags: [research, rag, robeing, postgres, graph, relations]
 
 ## 상태
 
-- proposed
+- **updated** (260320: 재귀 CTE → Apache AGE로 방향 변경)
 
-**작성일**: 2026-03-20  
-**목적**: 별도 그래프 DB 없이 PostgreSQL 안에서 문서 연결성과 탐색성을 얼마나 가져갈 수 있는지 정리한다.
+**작성일**: 2026-03-20
+**목적**: PostgreSQL 안에서 문서 연결성과 탐색성을 확보하는 방법을 정리한다.
 
 ---
 
 ## 1. 결론
 
-- 지금 단계에서 별도 그래프 DB를 바로 도입할 필요는 없다.
-- PostgreSQL만으로도 문서 간 연결, 태그 기반 연결, 재귀 탐색은 상당 부분 구현 가능하다.
-- 로빙의 현재 목표는 "그래프 DB 도입" 자체가 아니라 "근거 문서 연결성을 높이는 것"이므로, 우선 Postgres 확장으로 충분하다.
+- ~~재귀 CTE로 충분~~ → **Apache AGE(PostgreSQL 그래프 확장)를 도입한다.**
+- AGE는 PostgreSQL 위에서 Cypher 쿼리를 지원하여, 복잡한 문서 관계 탐색을 직관적으로 처리한다.
+- 기존 PGVector + JSONB와 같은 DB 커넥션 안에서 벡터 검색 → 그래프 탐색 하이브리드 쿼리가 가능하다.
+
+### 1.1 왜 Apache AGE인가
+
+- **Cypher 지원**: `MATCH (d:Doc)-[:RELATED]->(r:Doc)` 식의 직관적 관계 탐색. 재귀 CTE 대비 쿼리 복잡도 대폭 감소.
+- **PGVector 동거**: 벡터 검색으로 후보군 → AGE로 맥락 확장이 하나의 DB에서 끝남.
+- **운영 단순화**: 별도 그래프 DB(Neo4j 등) 없이 PostgreSQL 하나로 통합.
+
+### 1.2 설치 주의사항
+
+- PostgreSQL 버전과 맞춰 컴파일 필요 — Docker 기반 설치 권장.
+- 에이전트가 Cypher를 구사하려면 프롬프트 DB에 Few-shot 예제 필요.
 
 ## 2. 연결 원천
 
@@ -106,23 +117,39 @@ group by id, title
 order by min_depth, id;
 ```
 
-## 7. 왜 이 정도면 충분한가
+## 7. AGE 그래프 스키마 (예정)
 
-- 로빙이 필요로 하는 것은 수십억 노드 그래프 분석이 아니다.
-- 질문에 대한 근거 문서 묶음, 연관 문서 체인, 같은 프로젝트 맥락 정도면 충분하다.
-- 이 범위는 PostgreSQL과 재귀 쿼리로 관리 가능하다.
+### 노드
+- `Document`: 문서 (title, source_path, file_type, tags)
+- `Folder`: 폴더/프로젝트 단위
+- `Tag`: 태그/키워드
+- `User`: 작성자/소유자
 
-## 8. 그래프 DB를 나중에 도입해야 하는 조건
+### 엣지
+- `RELATED`: 명시적 연결 (front matter related)
+- `IN_FOLDER`: 문서 → 폴더
+- `TAGGED`: 문서 → 태그
+- `AUTHORED`: 작성자 → 문서
+- `SEMANTIC_NEIGHBOR`: 벡터 유사도 기반 보조 연결
 
-- 관계 유형이 너무 많아지고 실시간 그래프 탐색이 핵심이 될 때
-- 연결 시각화가 제품의 핵심 화면이 될 때
-- 추천, 경로 분석, 중심성 분석이 주 서비스가 될 때
+### Cypher 쿼리 예시
 
-## 9. 현재 추천
+```cypher
+-- 특정 문서의 2단계 관련 문서 탐색
+MATCH (d:Document {title: '사업계획서'})-[:RELATED*1..2]-(r:Document)
+RETURN r.title, r.source_path
 
-- 지금은 PostgreSQL 안에서 `document_files`, `document_relations`, PGVector를 함께 운영한다.
-- relation 생성 규칙을 먼저 고정하고, retrieval 품질 향상 여부를 검증한다.
-- 그래프 DB는 필요가 입증될 때 별도로 도입한다.
+-- 같은 폴더 + 같은 태그 문서
+MATCH (d:Document)-[:IN_FOLDER]->(f:Folder)<-[:IN_FOLDER]-(r:Document)
+WHERE d.title = '감사계약서'
+RETURN r.title
+```
+
+## 8. 현재 추천
+
+- 51123 서버 PostgreSQL에 Apache AGE Docker 기반 설치.
+- `document_relations` 테이블 대신 AGE 그래프로 관계 관리.
+- PGVector(의미검색) + AGE(관계탐색)를 하나의 DB에서 하이브리드 운용.
 
 ## 10. 관련 문서