호스팅형 벡터 DB 사용을 중단한 이유: 프로덕션 환경에서 발생한 문제점

논란의 전환점

지난 분기, 우리는 관리형 클라우드 벡터 DB 구독 서비스를 폐지했습니다. 대신 온프레미스 하이브리드 엔진(로컬 Qdrant + Docker 루프백상의 SQLite FTS5)으로 교체했습니다.

다음은 프로덕션 환경에서 얻은 실제 데이터입니다:

1. 다단계 지연 시간 세금 (The Multi-Hop Latency Tax)

8~10개의 순차적인 도구/메모리 단계를 거치는 자율 에이전트 워크플로우에서는 네트워크 지연 시간이 공격적으로 복합됩니다:

• 클라우드 벡터 SaaS: 0 곱하기 55 ms (TLS + 네트워크 허브) = 550 ms가 순수하게 소켓 대기 시간으로 소비되었습니다.
• 로컬 루프백 메시: 0 곱하기 3.8 ms = 38 ms의 총 시간이었습니다. 이 14배 차이는 반응성이 좋은 에이전트와 타임아웃되는 워커 사이의 경계입니다.

2. 순수 벡터 검색이 파츠 카탈로그에 실패한 이유

의미론적 유사성(Semantic similarity)은 정확한 부품 번호나 오류 코드에는 매우 취약합니다. 임베딩을 사용하여 검색할 경우, 잘못된 직경을 가진 의미론적으로 '유사한' 베어링이 반환되었습니다.
우리는 여전히 BM25/FTS5 키워드 검색 기능을 추가로 구현해야 했습니다. 어차피 어휘적 정밀도가 필요한 상황이라면, 로컬 검색과 함께 전용 클라우드 벡터 SaaS를 운영하는 것은 유지보수 측면에서 분리된 두 개의 시스템(split-brain)을 만듭니다.

3. 트레이드오프 (Trade-Off)

셀프 호스팅이 공짜는 아닙니다. OOM killer가 HNSW 인덱스 빌드 중에 노드를 파괴하지 않도록 엄격한 Linux 메모리 cgroups를 강제해야 합니다.

여러분께 드리는 질문

관리형 벡터 검색은 다음 거대한 엔터프라이즈 과잉 설계 함정이 되고 있습니까?

여러분의 팀은 호스팅된 SaaS(Pinecone, Weaviate Cloud)에 머물렀나요, 아니면 임베디드 엔진(pgvector, 로컬 Qdrant, SQLite)으로 이동했나요?

프로덕션 환경에서의 실제 p95 지연 시간은 얼마입니까?

Bohdan Hordii // 시스템 및 주권 인프라 아키텍트

자세한 내용: bohdanhordii.dev