전사 검색 벡터는 전용 벡터 DB 없이 pgvector에 둔다

• 상태: 채택됨
• 작성일: 2026-07-23
• 관련 문서: ADR-0020, APP-78, APP-102

맥락

전사 검색을 붙이려면 벡터를 어디에 둘지 정해야 한다. 전용 벡터 DB는 운영해야 할 컴포넌트를 하나 더 만든다. GraphRAG는 거기에 추출 파이프라인까지 달고 온다. 노트 수백 개 규모에서는 그 값이 안 보였다.

결정

• 기존 heymoa_ai Postgres에 pgvector 확장을 켜고 거기에 둔다.
• 확장 설치는 테이블과 달리 DB 클러스터 단위 상태라 첫 마이그레이션(0001)에 미리 열어 둔다.
• 임베딩 차원은 설정으로 빼지 않는다. 마이그레이션과 같이 박는다. 빼는 순간 두 곳이 갈라진다.
• 되돌리는 신호를 함께 정한다: 노트가 수백 개를 넘어 note_id IN (…) 필터가 느려질 때. 그때는 CreateAnalysisRequest에 workspaceId를 더해 컬럼으로 건다. 되돌리더라도 CREATE EXTENSION vector는 되돌리지 않는다.

대안

대안 1 — 전용 벡터 DB(pinecone·qdrant 등). 규모가 커져도 검색 성능이 따로 논다. 기각한 이유: 운영할 것이 하나 더 생긴다. 노트 수백 개 규모로는 그만큼을 치를 이유가 없다.

대안 2 — neo4j 기반 GraphRAG. 관계 질문까지 답할 수 있다. 기각한 이유: 비용 구조가 다르다. 운영 컴포넌트에 더해 추출 파이프라인까지 딸려 온다.

대안 3 — 임베딩 차원을 환경 설정으로 빼기. 모델 교체가 배포 없이 된다. 기각한 이유: 바꾸면 마이그레이션도 같이 바뀌어 두 곳이 갈라진다.

결과

• 새로 운영할 컴포넌트는 없다. 벡터와 서비스 데이터가 같은 트랜잭션 경계 안에 있다.
• 벡터 검색이 서비스 DB와 같은 인스턴스를 나눠 쓴다. 규모가 커지면 성능이 먼저 무너진다.
• 임베딩 차원이 설정이 아니라 마이그레이션에 박혀 있다. 모델을 바꾸려면 마이그레이션도 함께 바꿔야 한다.
• 관계 질문("이 결정은 왜 바뀌었나")은 벡터 유사도가 답하는 모양이 아니다. 그 한계가 ADR-0020의 출발점이 됐다.