나의 첫 번째 RAG 레이어가 독립형 벡터 데이터베이스가 아닌 Postgres에서 시작하는 이유

사람들이 워크플로우에 "RAG를 추가한다"고 말할 때, 대화는 종종 인프라 선택으로 너무 빠르게 넘어갑니다.

벡터 데이터베이스 (vector database)를 사용해야 할까요?
리랭커 (reranker)가 있어야 할까요?
모든 것을 지식 그래프 (knowledge graph)에 넣어야 할까요?

그것들은 타당한 질문들이지만, 보통 첫 번째 질문은 아닙니다.

첫 번째 질문은 더 좁습니다:

AI의 결정이 내려지기 전에 워크플로우가 검색할 수 있도록 허용된 승인된 지식 (approved knowledge)은 무엇인가?

이것이 바로 운영용 AI 워크플로우를 위한 나의 첫 번째 검색 (retrieval) 레이어가 독립형 벡터 데이터베이스가 아닌 Postgres에서 시작하는 이유입니다.

워크플로우 문제 (The Workflow Problem)

운영 중심의 시스템에서 모델은 일반적으로 가공되지 않은 메모리나 거대한 프롬프트 덤프 (prompt dump)로부터 답변해서는 안 됩니다.

유용한 컨텍스트 (context)는 이미 다른 곳에 존재합니다:

승인된 응답 규칙 (approved response rules);
인수인계 기준 (handoff criteria);
제품 또는 서비스 노트;
소스 또는 캠페인 가이드라인;
이미 인간에 의해 내려진 운영 결정.

어려운 부분은 유창한 텍스트를 생성하는 것이 아닙니다.

어려운 부분은 올바른 승인된 컨텍스트를 검색하고, 어떤 소스가 결정에 영향을 미쳤는지 보여주며, 안전한 소스가 존재하지 않을 때 거부하는 것입니다.

왜 Postgres가 우선인가 (Why Postgres First)

이러한 종류의 워크플로우의 경우, 주변 데이터의 대부분은 이미 관계형 (relational)입니다:

리드 (leads) 또는 대화;
워크플로우 이름;
단계 및 소유자;
인간 검토 결과;
소스 메타데이터 (metadata);
추적 로그 (trace logs);
문서 버전.

따라서 첫 번째 기술적 선택은 "추상적으로 벡터가 어디에 존재하는가?"가 아닙니다.

그것은 다음과 같습니다:

검색을 운영 데이터 모델 (operational data model)에 가깝게 유지할 수 있는 곳은 어디인가?
검색 경로와 최종 결정을 함께 기록할 수 있는 곳은 어디인가?
너무 일찍 두 번째 시스템을 만들지 않고 스키마 (schema)를 진화시킬 수 있는 곳은 어디인가?

Postgres와 pgvector는 이 질문 세트에 대한 좋은 첫 번째 답변입니다.

이를 통해 다음과 같은 것들을 한 곳에 유지할 수 있습니다:

문서 및 청크 (chunks);
허용된 사용 및 승인 요구 사항과 같은 메타데이터;
검색 추적 (retrieval traces);
비용 추정치;
인간 검토 결과

첫 번째 버전이 필요한 것 (What The First Version Needs)

첫 번째 버전은 광범위할 필요가 없습니다.

검사 가능(inspectable)해야 합니다.

제가 설정한 좁은 검색 범위(retrieval scope)는 다음과 같습니다:

승인된 응답 규칙 (approved response rules);
제품/서비스 노트 (product/service notes);
인계 및 에스컬레이션 기준 (handoff and escalation criteria);
캠페인/소스 가이드라인 (campaign/source guidance);
상업용 플레이북 (commercial playbooks).

검색된 각 청크(chunk)는 텍스트 이상의 정보를 담고 있어야 합니다. 다음과 같은 메타데이터 (metadata)도 함께 포함해야 합니다:

소스 이름 (source name);
문서 버전 (document version);
비즈니스 도메인 (business domain);
허용된 용도 (allowed use);
인간의 승인이 필요한지 여부 (whether human approval is required).

이러한 메타데이터는 매우 중요합니다. 왜냐하면 특정 워크플로(workflow)에서 하나의 청크를 내부 추론 지원용으로는 사용할 수 있지만, 고객에게 직접 노출되는 언어로는 사용할 수 없을 수도 있기 때문입니다.

평가 마인드셋 (The Eval Mindset)

저는 실패 기준 (failure criteria)이 마련되기 전까지는 검색 레이어 (retrieval layer)가 실질적으로 완성되었다고 생각하지 않습니다.

따라서 공개 프로토타입에는 다음과 같은 소규모 골든 질문 세트 (golden-question set)를 포함합니다:

예상되는 소스가 상위 결과에 나타나는가?
소스가 없을 때 워크플로가 '답변 없음' 또는 '인계'를 반환하는가?
고객 대상 언어가 허용된 청크에서만 생성되는가?
나중에 어떤 청크가 결정에 영향을 미쳤는지 검토할 수 있는가?

이는 시스템에 임베딩 (embeddings)이 있다고 발표하는 것보다 훨씬 더 중요합니다.

검색 체크 (retrieval checks)가 없다면, RAG 레이어는 정교해 보일지라도 여전히 잘못된 컨텍스트 (context)를 가져올 수 있습니다.

관찰 가능성은 설계의 일부입니다 (Observability Is Part Of The Design)

검색 단계 (retrieval step)와 AI 결정 단계 (AI decision step)는 함께 추적 가능 (traceable)해야 합니다.

저는 동일한 검토 화면에서 다음 항목들을 보고 싶습니다:

검색된 청크 ID (retrieved chunk IDs);
유사도 또는 검색 점수 (similarity or retrieval score);
모델 이름 (model name);
토큰 및 비용 추정치 (token and cost estimates);
최종 결정 (final decision);
인계 사유 (handoff reason);
인간 검토 결과 (human review outcome).

이것이 바로 "시스템이 답변했다"와 "시스템이 방어 가능한 근거를 가지고 답변했다" 사이를 잇는 가교입니다.

인프라를 추가하는 시점

저는 독립형 벡터 데이터베이스 (standalone vector databases)를 반대하는 것이 아닙니다.

시스템에 다음과 같은 요구사항이 생길 경우 나중에 추가할 것입니다:

더 많은 검색 트래픽 (more search traffic);
더 복잡한 필터링 경계 (more complex filtering boundaries);
별도의 배포 요구사항 (separate deployment requirements);
추가적인 구성 요소(moving parts)를 정당화할 수 있는 재현율/지연 시간 (recall/latency) 요구사항.

하지만 그 시점에 도달하기 전까지, 저는 검색 (retrieval), 평가 (evaluation), 그리고 감사 가능성 (auditability)이 가시적으로 드러나는 더 작은 스택을 선호합니다.

실무적인 교훈

수익 창출 또는 운영 (operations) 맥락의 AI 워크플로우를 위해서는, 첫 번째 검색 레이어가 제어 (control), 검토 (review), 그리고 스키마 명확성 (schema clarity)을 최적화해야 합니다.

최대치의 아키텍처적 참신함을 위해서가 아닙니다.

이것이 제가 첫 번째 RAG 레이어를 Postgres에서 시작하는 이유입니다:

운영 데이터 (operational data)에 더 가깝고;
추적 (trace)하기 더 쉬우며;
평가 (evaluate)하기 더 쉽고;
인간 참여 (human-in-the-loop)를 유지하기 더 쉽기 때문입니다.

공개된 케이스 스터디는 여기에 있습니다:

https://github.com/rkrisa/portfolio-ai-ops/tree/main/cases/operational-knowledge-retrieval-layer