벡터DB 실전 구축기 — 로컬 vs 클라우드, 다국어 임베딩의 함정

오후 8시 57분, 에이전트코리아에 실무형 질문 하나가 올라왔다.

"벡터db를 개인 서버에서 돌리시는 분 계시나요?"

질문을 던진 참여자는 여러 나라 언어로 흩어진 자료를 모아둔 상태였다. 그는 곧이어 "모아둔 정보가 엄청나게 많은데 (각국 언어로 돼있음) 벡터db 없으면 도무지 일관성있는 인덱싱이나 검색이 불가능하더라구요"라며, 다국어 자료를 검색 가능한 형태로 묶어낼 방법을 찾고 있다고 설명했다.

로컬 환경에서 벡터DB를 직접 굴려본 경험자가 답을 내놨다. 그는 개인 서버 운영의 현실적인 어려움부터 짚었다. "벡터엔진이 그지같을때는 메모리때문에 머신터지거나 아니면 인덱싱 갈아엎는동안 db가 귀찮아진다거나 서버에서 클라우드SSD에 안하면 다 날라간다거나 그러지만"이라며, 메모리 부족으로 인한 장애와 인덱스 재구축 시 발생하는 병목, 그리고 스토리지를 잘못 잡았을 때의 데이터 유실 위험까지 세 가지 함정을 한 번에 나열했다.

가장 중요한 조언은 다국어 임베딩 모델 선택에 관한 것이었다. 그는 "멀티링구얼이라면 지금은 코히어가 더 좋어요"라며 여러 언어를 동시에 다뤄야 하는 경우 코히어 계열 임베딩을 권했다. 이어 "한국어 특화나 그렇게 하면 검색 완전 망가짐다"라고 덧붙이며, 특정 언어에 맞춰 튜닝된 임베딩 모델을 다국어 자료에 그대로 쓸 경우 검색 품질이 오히려 무너질 수 있다고 경고했다.

로컬 구축이냐 클라우드냐를 두고 흔히 비용과 편의성만 비교하지만, 이날 대화는 그보다 앞서 임베딩 모델 선택이 결과를 가른다는 점을 보여줬다. 메모리와 스토리지 같은 인프라 문제는 돈으로 어느 정도 해결할 수 있지만, 잘못된 임베딩 모델을 고른 채 시작하면 인덱스를 통째로 다시 만들어야 하는 경우도 흔하다. 언어가 섞인 데이터를 다루는 실무자라면, 인프라를 고민하기 전에 임베딩부터 다시 점검할 필요가 있어 보인다.

특히 한국어 특화 임베딩을 다국어 자료에 그대로 적용했다가 검색 품질이 무너진다는 지적은, 성능 벤치마크 상 상위권에 있는 모델이라고 해서 모든 상황에 맞는 것은 아니라는 점을 새삼 확인시켜준다. 벡터DB를 처음 구축하는 이들은 대개 어떤 벡터엔진을 쓸지, 어떤 서버 사양이 필요한지부터 고민하지만, 실제로 부딪히는 벽은 그보다 한 단계 앞선 데이터 전처리와 임베딩 선택 단계에 있는 경우가 많다. 개인 서버로 시작하려던 질문자에게도, 결국 인프라보다 먼저 어떤 언어 조합의 데이터를 다룰 것인지부터 명확히 정의하는 편이 시행착오를 줄이는 길이라는 조언이 이날 대화의 핵심으로 남았다.