벡터 데이터베이스와 임베딩이란?

임베딩은 의미를 담은 숫자 벡터이며, 벡터 데이터베이스는 이 벡터를 저장하고 정확한 일치가 아닌 유사도로 검색하는 시스템입니다. 두 개념은 하나의 능력을 이룹니다. 모델은 텍스트(또는 이미지, 오디오)를 의미가 비슷하면 가까이 놓이도록 배치된 숫자 목록으로 바꾸고, 벡터 데이터베이스는 가장 가까운 점을 빠르게 찾습니다. 시맨틱 검색, 추천, RAG의 비결은 이것이 전부입니다. 앱 개발자에게 실용적인 핵심은, 임베딩은 자신이 설명하는 데이터 옆에 저장하는 필드 하나일 뿐이라는 점입니다.

핵심 요약

임베딩, 구체적으로

잠시 1,536차원은 잊고 3차원을 떠올려 보겠습니다. 각 단어에 동물인 정도, 탈것인 정도, 작은 정도를 점수로 매기는 장난감 모델입니다.

                동물     탈것    작음
새끼 고양이     0.95     0.02    0.90
고양이          0.93     0.01    0.60
트럭            0.03     0.96    0.05
오토바이        0.04     0.94    0.55

"새끼 고양이"는 "고양이" 가까이에 있고(둘 다 동물 점수가 높음) "트럭"과는 멀리 떨어져 있습니다.
distance(새끼 고양이, 고양이) → 작음    → 유사함
distance(새끼 고양이, 트럭)   → 큼      → 무관함

실제 모델은 3개가 아니라 수백, 수천 개의 차원을 쓰며,
차원은 사람이 직접 붙인 라벨이 아니라 데이터에서 학습됩니다. 하지만 직관은 정확히 다음과 같습니다:
의미는 기하 구조가 되고, "유사함"은 "가까움"이 됩니다.

이 방식이 실제 구조를 담아낸다는 유명한 증거는 벡터 산술입니다. 학습된 단어 임베딩에서 king − man + woman(왕 − 남자 + 여자)은 queen(여왕) 근처에 놓입니다. 의미가 좌표로 바뀌면 대수 연산도 할 수 있게 됩니다.

유사도 검색의 작동 방식

세 가지 거리 척도가 주로 쓰입니다. 코사인은 벡터 사이의 각도를 측정하고(길이는 무시), 내적은 크기까지 반영하며, 유클리드는 직선 거리입니다. 혼란을 덜어 주는 핵심은 이것입니다. 정규화된 벡터에서는 세 척도의 순위 결과가 같고, 텍스트 임베딩 모델은 보통 코사인에 맞춘 정규화된 벡터를 출력하므로, “어떤 척도를 쓸까”라는 질문의 답은 대개 이미 정해져 있습니다.

정확한 검색 vs. 근사 검색: ANN 트레이드오프

정확한 검색은 쿼리를 저장된 모든 벡터와 비교합니다. 완벽하며, 약 100만 개 벡터까지는 전혀 문제가 없습니다. 그 이상에서는 가장 널리 쓰이는 근사 인덱스인 HNSW가 여러 층으로 된 근접 그래프(먼 거리를 건너뛰는 성긴 상위 층, 모든 것을 담는 촘촘한 최하위 층)를 만들고, 거친 층에서 세밀한 층으로 탐욕적으로 내려가며 대부분의 비교를 건너뜁니다. HNSW는 B-트리의 시맨틱 사촌입니다. B-트리가 “같음”과 “작음”을 인덱싱한다면, ANN 인덱스는 “비슷함”을 인덱싱합니다. 경쟁 페이지들이 흐리게 넘기는 솔직한 단서도 있습니다. ANN은 진짜 최근접 이웃을 놓칠 수 있고, 조정 매개변수는 재현율과 속도, 메모리를 맞바꾸며, 그래프는 RAM에 상주합니다. 벡터 데이터베이스의 규모 산정이 사실상 메모리에 관한 논의인 이유입니다.

벡터 인덱스 vs. 벡터 데이터베이스

용어가 뒤섞이면서 흐려지는 구분입니다. 인메모리 인덱스 라이브러리(FAISS 등)는 최근접 이웃을 계산하지만 영속화, 업데이트, 필터링은 하지 않습니다. 재시작하면 다시 인덱싱해야 하고, WHERE 절도 없습니다. 벡터 데이터베이스는 인덱스에 내구성, 증분 업데이트, 메타데이터 필터링을 더한 것입니다. 바로 이 차이 때문에 “그냥 라이브러리를 쓰면 된다”는 방식은 프로덕션에서 실패하고, 벡터 인덱스를 갖춘 기존 데이터베이스가 정답인 경우가 많습니다. 기존 데이터베이스에는 라이브러리에 없는 내구성, 트랜잭션, 권한이 이미 있기 때문입니다.

전용 벡터 데이터베이스가 정말 필요할까?

벤더 페이지는 줄 수 없는 중립적인 답입니다. 벡터를 지원하는 범용 데이터베이스, 즉 pgvector를 쓰는 Postgres나 배열 필드 위에 MongoDB의 HNSW 벡터 인덱스를 쓰는 구성은 노드당 약 100만 개 벡터까지 무리 없이 처리하며, 애플리케이션 데이터와 그 권한 바로 옆에 자리합니다. 전용 엔진이 운영 비용과 이중 시스템 동기화 비용(벡터 저장소를 기준 데이터베이스와 일관되게 유지하는 부담)을 감수할 가치가 생기는 것은 진정으로 큰 규모에서입니다. 수천만 개의 벡터, 매우 높은 쿼리 처리량, 또는 강한 필터링 아래에서도 높은 재현율이 요구되는 경우입니다. 벡터가 약 100만 개 미만이라면 특화 저장소는 성능으로 돌려주는 것보다 연결 코드에 드는 비용이 대개 더 큽니다. “벡터 데이터베이스가 필요하다”고 말하는 페이지 대부분이 구조적으로 할 수 없는 계산입니다. 그 페이지들이 바로 벡터 데이터베이스 벤더이기 때문입니다.

메타데이터 필터링이 곧 보안 경계

벡터 유사도는 의미로 순위를 매길 뿐 누가 무엇을 읽을 수 있는지는 전혀 모릅니다. 따라서 프로덕션 쿼리는 결코 “가장 가까운 이웃 10개”가 아니라 “가장 가까운 이웃 10개 중 이 사용자가 볼 수 있는 것”입니다. 순서를 잘못 잡으면 관련성 버그가 아니라 데이터 유출이 됩니다. 사전 필터링은 ANN 검색 전에 후보를 허용된 집합으로 좁힙니다(올바른 방법). 사후 필터링은 검색 후에 결과를 잘라 내므로, 금지된 항목의 존재를 노출하는 동시에 k개보다 적은 결과를 조용히 반환합니다. 필터가 ACL이라면, 사전 필터링은 시맨틱 검색과 보안 침해를 가르는 차이입니다. RAG가 뼈아프게 배우는 바로 그 교훈입니다. 이미 권한을 강제하는 데이터베이스에 임베딩을 저장하면 필터는 저절로 따라옵니다.

실제 코드로 보는 임베딩

// JavaScript — Cloud Code (cloud/main.js)
// Embeddings live as a field next to the data they describe
Parse.Cloud.beforeSave('Doc', async (req) => {
  if (req.object.dirty('text')) {
    // generate server-side; embedding API key stays on the server
    req.object.set('embedding', await embed(req.object.get('text')));
    req.object.set('embedModel', 'text-embed-v3'); // version it — models differ
  }
});

// Similarity search, ACL-filtered: "nearest neighbors this user MAY see"
Parse.Cloud.define('semanticSearch', async (req) => {
  const qVec = await embed(req.params.q);
  return vectorSearch('Doc', qVec, { limit: 10, aclUser: req.user });
  // The pre-filter is the security boundary, not a relevance tweak.
});

// Flutter / Dart — Back4app Flutter SDK
// The client searches by meaning — the vector math is server-side
final results = await ParseCloudFunction('semanticSearch')
    .execute(parameters: {'q': 'how do refunds work?'});
for (final doc in results.result) print(doc['title']);
// "refund policy" matches "money back" though they share no keywords —
// because their embeddings are near each other. Filtered to your ACL.

// iOS / Swift — Back4app Swift SDK
// The client searches by meaning — the vector math is server-side
let results: [[String: Any]] = try await Cloud.run(
    name: "semanticSearch",
    parameters: ["q": "how do refunds work?"])
for doc in results { print(doc["title"] ?? "") }
// "refund policy" matches "money back" though they share no keywords —
// because their embeddings are near each other. Filtered to your ACL.

// Android / Kotlin — Back4app Android SDK
// The client searches by meaning — the vector math is server-side
val params = mapOf("q" to "how do refunds work?")
val results = ParseCloud.callFunction<List<Map<String, Any>>>(
    "semanticSearch", params)
results.forEach { println(it["title"]) }
// "refund policy" matches "money back" though they share no keywords —
// because their embeddings are near each other. Filtered to your ACL.

embedModel 필드에 주목해야 합니다. 서로 다른 모델, 또는 같은 모델의 다른 버전에서 나온 벡터는 서로 비교할 수 없으므로, 임베딩 모델을 바꾸면 전체 코퍼스를 다시 임베딩해야 합니다. 모델 이름을 벡터와 함께 저장하지 않으면, 조용한 업그레이드 한 번에 인덱스가 노이즈로 변합니다.

일반적인 사용 사례

• 시맨틱 검색: 공통 키워드가 하나도 없어도 “돈 돌려받기”로 “환불 정책”을 찾습니다.
• RAG 검색: LLM의 답변을 그라운딩하는 청크를 가져옵니다.
• 추천: 임베딩 공간에서 사용자의 이력 근처에 있는 항목을 찾습니다.
• 중복 제거와 클러스터링: 거의 같은 콘텐츠는 거의 같은 벡터가 됩니다.
• 이상 탐지와 사기 탐지: 이상치는 모든 정상 사례에서 멀리 떨어진 벡터입니다.

벡터는 어디에 두어야 할까? 결정 매트릭스

한계와 트레이드오프

• 임베딩은 모델의 세계관을 담습니다. 편향, 사각지대, 학습 데이터 기준일이 함께 따라옵니다. 기하 구조는 그것을 그린 모델만큼만 좋습니다.
• ANN은 의도적으로 근사합니다. 재현율은 걸려 있는 위험의 크기에 맞춰 조정해야 합니다. “대개 가장 잘 맞는 결과를 찾는다”는 것이 속도를 얻는 대가로 받아들인 조건입니다.
• 모델 버전은 스키마의 일부입니다. 모델을 바꿀 때 대규모 코퍼스를 다시 임베딩하는 일은 설정 하나 바꾸는 일이 아니라 본격적인 마이그레이션입니다.
• 메모리가 상한선입니다. HNSW 그래프는 RAM에 상주합니다. 노드당 벡터 한도는 이름표만 다른 메모리 한도입니다.
• 유사도는 관련성이 아닙니다. 벡터 공간에서 가깝다는 것은 강력한 신호이지 보장이 아닙니다. 순수 벡터 검색은 정확한 용어를 놓치기 때문에 하이브리드 검색과 리랭킹이 존재합니다.

Back4app에서의 벡터

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. Back4app은 MongoDB 위에서 동작하므로, 저장 방식은 이 글이 권장하는 바로 그 방식입니다. 임베딩은 자신이 설명하는 객체의 배열 필드이며, 문서와 그 벡터가 같은 레코드에 있고, 그 밑에서 실제로 작동하는 메커니즘은 HNSW 벡터 인덱싱입니다. 결과는 자연스럽게 이어집니다. 이미 모든 쿼리를 통제하는 ACL이 추가 비용 없이 유사도 검색의 사전 필터가 되므로 검색이 권한 경계를 넘을 수 없습니다. 임베딩은 키를 서버 측에 둔 채 임베딩 모델을 호출하는 Cloud Code beforeSave 트리거에서 생성됩니다. 그리고 동기화하고, 보안을 챙기고, 비용을 치러야 할 별도의 벡터 서비스가 없습니다. 대부분의 제품이 실제로 다루는 앱 규모의 코퍼스라면, “벡터 데이터베이스”는 도입해야 할 시스템이 아니라 추가하는 필드 하나입니다.