1536에서 1024로 — 벡터DB 차원을 낮춰 RAG 병목을 뚫은 실전기

도입 장면

저녁 10시 반, 실제로 서비스를 운영하는 한 참가자가 벡터 데이터베이스 병목을 겪은 뒤 차원을 낮췄다는 근황을 던지면서 대화가 시작됐다. RAG(검색 증강 생성) 시스템에서 벡터DB는 질문과 가장 가까운 문서를 찾아주는 핵심 구성요소인데, 이 참가자는 그 검색 속도 자체가 발목을 잡고 있었다고 운을 뗐다.

전개 — 구체적 수치와 반론

"차원을 지난달에 낮췄어요"

곧이어 구체적인 이유를 덧붙였다.

"1536까진 필요없고 병목이 너무 심해서"

일반적으로 임베딩 모델은 문장이나 문서를 1536차원 같은 고차원 벡터로 변환해 저장한다. 차원이 높을수록 의미를 세밀하게 담을 수 있지만, 그만큼 저장 공간과 검색 연산량도 함께 늘어난다. 이 참가자는 그 균형을 낮추는 쪽으로 조정한 셈이다.

이에 다른 참가자가 곧바로 실무적인 반론 겸 보충 설명을 던졌다.

"검색이 느려질거에요 아마.. 벡터 DB를 PG자체가 지원하긴 해도 최적화된건 아니라서"

PG는 오픈소스 관계형 데이터베이스인 PostgreSQL을 가리킨다. 최근 들어 PostgreSQL도 확장 기능을 통해 벡터 검색을 지원하지만, 이 참가자는 그 지원이 전용 벡터DB만큼 최적화된 것은 아니라는 점을 짚었다. 차원을 낮춘다고 병목이 그냥 사라지는 게 아니라, DB 엔진 자체의 한계가 또 다른 변수로 남는다는 지적이었다.

이 대화 끝에 원래 질문을 던졌던 참가자는 자신이 택한 해법을 공유했다.

"그래서 외부에서 임베딩 하는 방식으로"

맥락 해석

세 발화를 이으면 하나의 최적화 여정이 드러난다. 처음에는 임베딩 차원을 1536에서 낮추는 비교적 손쉬운 조정으로 병목을 줄이려 했고, 이 방식 자체는 이미 계산된 벡터에 가중치를 한 번 곱해 차원을 줄이는 수준이라 기술적으로는 간단한 축에 속한다. 그러나 검색 속도가 여전히 느릴 수 있다는 반론과, PostgreSQL의 벡터 지원이 전용 솔루션만큼 최적화되어 있지 않다는 지적이 겹치면서, 결국 임베딩 자체를 서비스 내부가 아닌 외부에서 처리하는 방식으로 구조를 바꾸는 결론에 도달했다. 하나의 손쉬운 트릭만으로 병목이 해결되지 않을 때는, 데이터베이스 선택과 임베딩 처리 위치까지 함께 재검토해야 한다는 점을 보여주는 사례다.

시사점

이 짧은 문답은 RAG 시스템을 실제로 운영하는 이들에게 실전 체크리스트를 남긴다. 차원 축소는 계산 비용이 낮은 개선책이지만 검색 품질과 속도를 동시에 보장하지는 않으며, PostgreSQL처럼 범용 DB에 벡터 기능을 얹어 쓰는 구성은 트래픽이 늘어날수록 한계에 부딪히기 쉽다는 것이다. 결국 이 참가자가 택한 '외부 임베딩'이라는 결론은, 시스템 전체를 하나의 DB 안에 몰아넣기보다 임베딩 생성과 벡터 검색을 역할별로 분리하는 편이 병목 해소에 더 근본적인 해법이 될 수 있음을 시사한다. RAG를 이제 막 도입하려는 이들에게는, 차원 수 하나를 낮추기 전에 어떤 DB로 어디까지 감당할 것인지 미리 가늠해보라는 조언으로 읽힌다.