Twio가 프로덕션 RAG를 위해 pgvector 대신 Vertex AI Search를 선택한 이유

Twio에서 처음 RAG를 구축했을 때, pgvector는 명백한 선택지였습니다. 우리의 비즈니스 데이터는 이미 PostgreSQL에 있었고, 동일한 데이터베이스에 임베딩 (embeddings)을 넣는 것이 작동하는 제품을 만드는 가장 빠른 경로였습니다.

첫 번째 버전에서는 그것이 맞았습니다. 하지만 규모가 커지면서 문제는 "벡터를 어떻게 저장할 것인가?"가 아니라 "프로덕션 환경에서 수천 개의 브로커 문서, 이메일, 첨부 파일을 어떻게 신뢰할 수 있게 이해할 것인가?"로 변했습니다. 그 점이 답을 바꾸었습니다. 오늘날, Vertex AI Search는 우리의 주요 검색 (retrieval) 레이어입니다.

RAG는 Twio의 검색 기능이 아니라 메모리 레이어입니다

Twio는 대출 브로커를 위한 AI SaaS입니다. 단일 고객 사례는 파편화된 정보의 덩어리입니다:

이메일 스레드 (email threads)
급여 명세서, 은행 거래 내역서, 신분증
대출 양식, 대출 기관 요구 사항
수기 메모, 후속 이메일, 누락 서류 요청

AI는 다음과 같은 질문에 답해야 합니다:

이 고객이 이미 보낸 문서는 무엇인가?
어떤 이메일에서 누락된 요구 사항을 언급했는가?
이 은행 거래 내역서가 소득 증빙을 뒷받침하는가?
이 차입자와 관련된 모든 문서를 요약하라.

검색 (retrieval)이 약하면 답변도 약해집니다. 인덱싱 (indexing)이 뒤처지면 컨텍스트 (context)가 누락됩니다. 파싱 (parsing)이 잘못되면 모델은 잘못된 증거를 보게 됩니다. RAG는 부수적인 기능이 아닙니다. 제품의 메모리 레이어 (memory layer)입니다.

왜 pgvector가 올바른 첫 번째 선택이었나

Twio는 멀티 테넌트 (multi-tenant) SaaS이므로, 검색은 단순히 "유사한 콘텐츠"를 반환해서는 안 됩니다. 올바른 사용자, 고객, 애플리케이션 또는 파일로 범위가 지정된 유사한 콘텐츠를 반환해야 합니다. pgvector는 이를 매우 쉽게 만들어 주었습니다. 임베딩 (embeddings)이 비즈니스 레코드 옆에 위치하여 깔끔하게 조인 (join)되고 일반 SQL로 필터링할 수 있었기 때문입니다.

초기 성과는 확실했습니다:

새로운 인프라가 필요 없음
낮은 비용, 쉬운 로컬 개발
디버깅을 위한 SQL 검사 가능
직관적인 메타데이터 필터링
빠른 출시

이를 통해 우리는 첫 번째 버전을 빠르게 구축하고 실제 사용 사례로부터 배울 수 있었습니다. 이는 사람들이 생각하는 것보다 훨씬 더 중요합니다.

pgvector의 효용이 떨어진 지점

pgvector가 실패한 것은 아닙니다. 그것은 설계된 목적 그대로 역할을 수행했습니다. 문제는 벡터 저장소(vector storage)는 RAG 파이프라인의 단 한 조각일 뿐이며, pgvector는 그 외의 모든 조각을 우리에게 남겨두었다는 점입니다.

첨부 파일 다운로드
PDF에서 텍스트 추출, 스캔본에 대한 OCR 실행
문서 청킹 (chunking), 임베딩 (embeddings) 생성
메타데이터 설계, 검색 쿼리 (retrieval queries) 구축
인덱스 (indexes) 튜닝, 랭킹 (ranking) 개선
Postgres 부하 모니터링, 검색 품질 디버깅

깔끔한 PDF는 쉽습니다. 하지만 스캔된 은행 명세서는 쉽지 않습니다. 이메일 본문은 쉽습니다. 하지만 5개의 첨부 파일, 대출 기관 양식, 표, 그리고 불완전한 OCR이 포함된 이메일은 쉽지 않습니다. 데모 데이터셋은 쉽습니다. 하지만 수년간의 과거 이메일이 쌓인 실제 브로커의 작업 공간은 쉽지 않습니다.

pgvector를 사용할 때, 해당 파이프라인의 모든 약점은 우리가 해결해야 할 몫이었습니다. 검색 품질이 떨어지면, 의심 목록은 OCR부터 청킹, 임베딩, 벡터 거리 (vector distance), SQL 필터링, 랭킹, 그리고 DB 성능에 이르기까지 모든 범위를 아울렀습니다. 확장 프로그램(extension) 자체는 단순합니다. 하지만 그 주변을 둘러싼 프로덕션 RAG 시스템은 단순하지 않습니다.

비용은 클라우드 청구서에서 엔지니어링 시간으로 옮겨갔으며, 엔지니어링 시간은 우리의 제약된 자원이었습니다.

Twio의 관점에서 본 pgvector vs Vertex AI Search

시나리오	pgvector	Vertex AI Search
깔끔한 텍스트 PDF	추출, 청킹, 임베딩, 저장, 검색을 우리가 직접 관리	Vertex가 인덱싱 및 검색 워크플로의 대부분을 처리
...	...	...
pgvector는 데이터베이스 확장 프로그램으로서 더 저렴했습니다. Vertex는 제품 결정(product decision)으로서 더 저렴합니다. 클라우드 청구서는 하나의 입력 요소일 뿐입니다. 우리의 단계에서는 엔지니어링 시간, 신뢰성, 그리고 반복 속도(iteration speed)가 더 큰 요소입니다.

Vertex가 Twio의 문제 유형에 적합한 이유

Twio의 RAG 문제는 문서 중심적입니다. 우리는 짧은 스니펫(snippets)을 검색하는 것이 아니라, 지저분한 브로커 PDF, 스캔본, 양식, 표, 그리고 전달된 첨부 파일들을 다루고 있습니다. Vertex는 네 가지 구체적인 방식으로 도움을 줍니다:

관리해야 할 인프라가 적습니다. 인덱싱 (Indexing) 및 검색 (Retrieval)이 관리형 레이어 (Managed layer)에서 처리되므로, 저희가 해당 영역을 직접 구축할 필요가 없습니다.
유지 관리해야 할 문서 처리 로직이 적습니다. 지저분한 브로커 파일들에 대한 OCR 및 파싱 (Parsing)은 파이프라인의 건강함을 유지하기 가장 어려운 부분 중 하나입니다. Vertex는 이 중 상당 부분을 해결해 줍니다.
Postgres는 본연의 강점에 집중할 수 있습니다. 동일한 리소스를 두고 OLTP 작업과 경쟁하는 대신, 비즈니스 데이터, 트랜잭션 (Transactions), 워크플로우 상태 (Workflow state) 등에 집중할 수 있습니다.
문서 양이 증가함에 따라 더 자연스럽게 확장됩니다.

Vertex가 무료는 아니지만, 대안 역시 무료는 아닙니다. OCR, 인덱싱 (Indexing), 랭킹 (Ranking), 모니터링 (Monitoring), 튜닝 (Tuning)을 직접 구축하는 데에는 엔지니어의 주 단위 시간이라는 비용이 발생합니다.

pgvector가 여전히 잘 수행하는 것들

pgvector는 다음과 같은 상황에서 여전히 강력한 선택지입니다:

데이터 양이 적당할 때
이미 Postgres를 사용 중이며 데이터와 가까운 곳에서 검색을 수행하고 싶을 때
문서가 이미 깨끗한 텍스트 형태일 때
엄격한 SQL 필터링과 완전한 제어가 필요할 때
빠르고 저렴한 첫 번째 버전을 원할 때

저희에게 pgvector는 올바른 첫 번째 구현이었으며, 이를 통해 제품에 실제로 필요한 검색 기능이 무엇인지 배울 수 있었습니다. 내부용 또는 폴백 (Fallback) 유스케이스를 위해 스택에 계속 남아 있을 수도 있습니다.

시사점 (Takeaway)

Twio의 RAG 진화 과정에서 얻은 교훈은 간단합니다:

가장 빠르게 배울 수 있게 도와주는 도구로 시작하세요. 그리고 가장 잘 운영할 수 있게 도와주는 도구로 이동하세요.

pgvector는 저희가 작동하는 RAG 시스템을 빠르게 구축할 수 있게 해주었습니다. 제품이 성숙해짐에 따라 실제 과제는 문서 처리, 인덱싱 품질, 그리고 운영 신뢰성으로 옮겨갔으며, 그 시점에서 Vertex AI Search가 더 적합한 선택이 되었습니다. 서비스로서의 비용은 더 높지만, 시스템 유지 관리 측면에서의 비용은 더 낮습니다. Twio 단계의 SaaS에게는 이것이 중요한 트레이드오프 (Trade-off)입니다.