diff --git a/journey/ideas/260316_모든db를_postgresql로_통일하는_아이디어.md b/journey/ideas/260316_모든db를_postgresql로_통일하는_아이디어.md
index 1fd0cf3..4f1189a 100644
--- a/journey/ideas/260316_모든db를_postgresql로_통일하는_아이디어.md
+++ b/journey/ideas/260316_모든db를_postgresql로_통일하는_아이디어.md
@@ -33,21 +33,20 @@ tags: [infra, database, postgres, ideas, consolidation]
 ### 기대상태
 
 - 가능한 많은 데이터를 PostgreSQL 하나로 모은다.
-- 벡터는 `pgvector` 계열로, 텍스트 검색은 PostgreSQL FTS로, 캐시성 데이터는 PostgreSQL 내부 구조로 먼저 수용 가능한지 본다.
-- 전용 DB는 `구조적으로 대체 불가능한 요구`가 있는 경우에만 남긴다.
+- 벡터는 `pgvector`, 그래프성 질의는 PostgreSQL 관계/재귀 모델, 텍스트 검색은 PostgreSQL FTS와 `pg_trgm`으로 통일한다.
+- 현재 남아 있는 전용 DB는 단계적으로 제거 대상에 둔다.
 - 운영 SSOT, 백업, 접근통제, 모니터링, 장애 복구 기준을 PostgreSQL 중심으로 단순화한다.
 
 ## 아이디어
 
-- 기본 전략을 `polyglot by default`가 아니라 `PostgreSQL first`로 바꾼다.
-- 새 기능을 열 때 먼저 묻는 질문을 아래처럼 바꾼다.
-- `이 요구를 PostgreSQL로 먼저 수용할 수 있는가`
-- `정말 전용 DB가 없으면 안 되는 구조적 이유가 있는가`
-- `전용 DB를 유지할 경우 운영 복잡도 증가를 어떤 가치로 상쇄하는가`
+- 기본 전략을 `polyglot by default`가 아니라 `PostgreSQL only until proven otherwise`로 바꾼다.
+- 새 기능을 열 때 기본 저장소는 PostgreSQL로 고정한다.
+- 벡터는 `pgvector`, 검색은 `FTS + pg_trgm`, 그래프성 탐색은 관계 모델과 `WITH RECURSIVE`를 기본 해법으로 사용한다.
+- 기존 ChromaDB, Neo4j, 검색 전용 계층도 후속 단계에서 PostgreSQL로 흡수하는 방향을 기본값으로 둔다.
 
 핵심 한 줄은 아래와 같다.
 
-- `전용 DB를 기본값으로 두지 말고, PostgreSQL에서 막히는 요구가 확인될 때만 별도 저장소를 남긴다.`
+- `지금 단계에서는 전용 DB를 줄이고, non-RDB 기능까지 PostgreSQL로 흡수하는 것을 기본 방향으로 삼는다.`
 
 ## 기대 효과
 
@@ -59,8 +58,8 @@ tags: [infra, database, postgres, ideas, consolidation]
 ## 검증이 필요한 이유
 
 - 캐시, 벡터, 텍스트, 그래프는 단순 저장이 아니라 `질의 패턴`이 다르다.
-- 특히 그래프 순회와 대규모 분산 벡터 검색은 PostgreSQL 통합 전략의 약한 지점일 수 있다.
-- 따라서 이 아이디어는 `좋아 보이는 단순화`만으로 채택하면 안 되고, 대표 워크로드 기준으로 병목과 손실을 먼저 확인해야 한다.
+- 특히 그래프 순회와 대규모 분산 벡터 검색은 PostgreSQL 쪽에서 쿼리 설계와 인덱스 설계가 더 중요해진다.
+- 따라서 이 아이디어는 `전용 DB 유지 여부`를 따지는 단계가 아니라, `PostgreSQL로 옮겼을 때 어떤 쿼리·인덱스·테이블 설계가 필요한가`를 검증하는 단계로 봐야 한다.
 
 ## 이 문서에서 빼야 하는 내용
 
@@ -70,8 +69,8 @@ tags: [infra, database, postgres, ideas, consolidation]
 
 ## 현재 판단
 
-- 이 아이디어는 충분히 검토할 가치가 있다.
-- 다만 `모든 DB를 바로 없앤다`가 아니라 `PostgreSQL 중심 단일화가 기본값이 되는가`를 묻는 방향이 더 안전하다.
-- 현재 시점에서 가장 현실적인 해석은 아래 문장이다.
+- 이 아이디어는 검토 대상이 아니라 현재 방향으로 고정할 수 있다.
+- 현 단계 목표는 `전용 DB와 non-RDB 저장소를 유지할 이유를 찾는 것`이 아니라 `PostgreSQL 통일 경로를 설계하는 것`이다.
+- 현재 시점의 해석은 아래 문장으로 고정한다.
 
-`인프라 기본 전략을 전용 DB 우선이 아니라 PostgreSQL 우선으로 바꾸고, 전용 DB는 구조적으로 필요한 경우에만 남기는 방향을 검토할 가치가 있다.`
+`인프라의 벡터, 그래프, 검색 계층은 지금부터 PostgreSQL로 통일하는 방향으로 정리하고, 전용 DB는 현 단계에서 제거 대상으로 본다.`
diff --git a/journey/research/260316_postgres_통합_vs_전용db_구조성능_리서치.md b/journey/research/260316_postgres_통합_vs_전용db_구조성능_리서치.md
index fdb46bf..293dc1e 100644
--- a/journey/research/260316_postgres_통합_vs_전용db_구조성능_리서치.md
+++ b/journey/research/260316_postgres_통합_vs_전용db_구조성능_리서치.md
@@ -17,9 +17,9 @@ tags: [infra, database, postgres, redis, pgvector, elasticsearch, neo4j, researc
 
 ## 목적
 
-- `PostgreSQL 하나로 Redis/Vector DB/Elasticsearch/Neo4j 역할까지 통합할 수 있는가`를 인프라 관점에서 다시 정리합니다.
-- `전용 DB 대비 Postgres가 몇 % 느리다` 같은 숫자 요약이 SSOT로 쓸 만한지 검증합니다.
-- 앞으로 `모든 DB를 PostgreSQL로 통일`하는 아이디어를 열 때 무엇이 사실이고 무엇이 해석인지 분리합니다.
+- 벡터, 그래프, 검색 같은 non-RDB 기능을 지금 단계에서 PostgreSQL로 통일하는 판단 근거를 인프라 관점에서 다시 정리합니다.
+- `전용 DB 대비 Postgres가 몇 % 느리다` 같은 숫자 요약이 통일 결정을 막을 정도의 SSOT인지 검증합니다.
+- 앞으로 `전용 DB를 걷어내고 PostgreSQL 하나로 정리한다`는 방향에서 무엇이 사실이고 무엇이 과장인지 분리합니다.
 
 ## Facts
 
@@ -93,21 +93,20 @@ tags: [infra, database, postgres, redis, pgvector, elasticsearch, neo4j, researc
 - 하지만 검색이 서비스의 주기능이 되고, 오타 허용·검색 랭킹 튜닝·대규모 색인 재구성·검색 클러스터 운영이 중요해지면 Elasticsearch가 더 자연스럽다.
 - 즉 `Postgres는 검색이 약하다`보다 `검색 전용 운영면은 Elasticsearch가 더 직접적이다`가 더 정확하다.
 
-### 5. 그래프는 PostgreSQL 통합 전략의 가장 약한 고리다
+### 5. 그래프는 가장 까다로운 영역이지만, 현 단계에서 전용 DB 유지 근거로 바로 이어지지는 않는다
 
 - PostgreSQL의 recursive CTE로 그래프성 질의를 구현할 수는 있다.
 - 그러나 복잡한 관계 탐색을 핵심 기능으로 삼는 순간, Neo4j의 index-free adjacency와 graph-native traversal 모델이 구조적으로 유리하다.
-- 따라서 `모든 DB를 PostgreSQL로 통일` 아이디어에서 가장 늦게 결정해야 할 영역은 그래프다.
+- 다만 지금 목적이 `극한 그래프 성능 최적화`가 아니라 `저장소 단일화와 운영 단순화`라면, 이 구조적 약점만으로 Neo4j를 즉시 유지해야 한다고 결론내릴 필요는 없다.
 
-### 6. 이번 주제의 안전한 결론은 `숫자 SSOT`가 아니라 `전환 기준 SSOT`를 만드는 것이다
+### 6. 이번 주제의 안전한 결론은 `전용 DB 유지 기준`이 아니라 `PostgreSQL 통일 전제`를 분명히 하는 것이다
 
 - `Redis 대비 10~50%`, `Neo4j 대비 10~50%` 같은 퍼센트는 문서 첫 줄 결론으로는 위험하다.
 - 사용자가 본 Gemini 요약은 `방향성` 수준에서는 꽤 그럴듯하지만, `2025~2026년 최신 검증치`처럼 받아들이기에는 출처 사슬이 충분히 드러나지 않는다.
-- 더 안전한 SSOT는 아래 질문들이다.
-- `TTL이 핵심 기능인가`
-- `분산 벡터 shard/replica가 지금 필요한가`
-- `오타 허용/검색 전용 랭킹 운영이 핵심인가`
-- `다단 관계 순회가 핵심 제품 기능인가`
+- 지금 더 중요한 질문은 아래와 같다.
+- `현재 운영 규모에서 PostgreSQL로 벡터/검색/그래프 요구를 먼저 수용할 수 있는가`
+- `저장소 단일화로 줄어드는 운영 복잡도가 현재 성능 손실보다 더 큰가`
+- `당장 전용 DB를 남겨야 할 만큼 이미 확인된 병목이 있는가`
 
 ## Unresolved
 
@@ -117,7 +116,7 @@ tags: [infra, database, postgres, redis, pgvector, elasticsearch, neo4j, researc
 
 ## 한 줄 결론
 
-- `PostgreSQL로 대부분을 통합`하는 방향은 충분히 현실적이지만, `전용 DB보다 몇 % 느리다` 같은 숫자를 SSOT로 고정하기보다 `어떤 기능 요구가 나오면 전용 DB를 유지/재도입할지`를 기준으로 삼는 편이 안전하다.
+- 현재 단계에서는 벡터, 그래프, 검색 같은 non-RDB 기능도 PostgreSQL로 통일하는 쪽이 더 합리적이며, Gemini식 퍼센트 비교는 이 결정을 뒤집을 정도의 SSOT 근거로 보기 어렵다.
 
 ## 근거 링크