생성형 AI 프로젝트를 점검하다 보면 LLM 호출과 프롬프트 작성까지는 자연스럽게 설명하는데, 벡터 DB가 등장하는 순간 구조가 모호해지는 경우가 있습니다. PDF나 사내 문서를 벡터 DB에 저장했고 사용자가 질문하면 관련 내용을 찾아 답변한다고 설명하지만, 문서 원문이 어떤 과정을 거쳐 벡터가 되었는지, 질문과 문서를 무엇을 기준으로 비교하는지, 비슷한 벡터를 찾은 뒤 그 결과가 어떻게 다시 LLM으로 전달되는지까지 질문하면 각각의 기술이 따로 떨어져 있는 식입니다. 반대로 벡터 DB 사용법은 익숙한데 프로젝트 목적과 검색 품질이 보이지 않는 경우도 있습니다. 컬렉션과 인덱스를 만들고 임베딩 벡터도 저장했지만, 퇴직금이라고 질문했을 때 문서의 퇴직급여 내용을 왜 찾을 수 있는지, 제품 코드처럼 정확한 문자열이 중요한 질문에서는 왜 검색이 흔들리는지, 검색된 상위 문서가 실제 답변 근거로 적절한지는 확인하지 않은 경우입니다. 이 상태에서는 벡터 DB를 사용한 프로젝트는 되지만 생성형 AI가 필요한 지식을 어떻게 찾아 사용하는지 설계한 프로젝트라고 설명하기에는 부족할 수 있습니다. 현재 OpenAI의 임베딩 가이드도 임베딩을 텍스트의 관련성을 수치 벡터로 표현하는 방식으로 설명하고 있으며, 검색에서는 질문과 데이터의 벡터 거리를 이용해 관련 결과를 순위화합니다. 많은 벡터를 빠르게 검색해야 할 경우 벡터 DB를 활용하는 방식도 안내하고 있습니다.
Microsoft Azure AI Search 역시 문서와 질문을 임베딩으로 변환하고 같은 벡터 공간에서 가까운 항목을 찾아 반환하는 구조를 벡터 검색의 기본 흐름으로 설명합니다. 여기에 키워드 검색을 함께 실행하는 하이브리드 검색도 제공하고 있어 실제 RAG에서는 벡터 검색 하나만 보는 것보다 질문 특성에 맞는 검색 전략이 중요합니다. 따라서 벡터 DB를 생성형 AI 프로젝트에 연결한다는 것은 데이터베이스 제품 하나를 추가하는 작업으로 보면 안 됩니다. 문서를 임베딩으로 바꿔 의미를 수치화하고, 질문 벡터와 저장된 벡터의 유사도를 비교하며, 상위 검색 결과를 LLM의 context로 전달해 답변을 생성하는 하나의 retrieval pipeline으로 이해해야 합니다. 벡터 DB 프로젝트의 핵심은 벡터를 저장했다는 사실보다 임베딩 → 유사도 계산 → 검색 → LLM context 전달의 흐름을 설명하고, 실제 질문에서 필요한 근거가 검색되는지 검증할 수 있는가에 있습니다.
이번 글에서는 벡터 DB를 생성형 AI 프로젝트에 연결하는 방법을 임베딩, 유사도, 검색 세 가지 기준으로 나누어 정리하겠습니다.
임베딩은 문서와 질문을 검색 가능한 숫자 표현으로 바꾸는 출발점입니다
- 벡터 DB에 문서를 넣기 전에 어떤 단위를 임베딩할 것인지부터 정해야 합니다
벡터 DB를 처음 사용하면 PDF나 텍스트 파일 전체를 바로 저장한다고 생각하기 쉽습니다. 실제로는 긴 문서를 적절한 단위로 나누고 각 청크를 임베딩 모델에 전달해 벡터를 만든 뒤, 원문과 메타데이터를 함께 저장하는 구조가 일반적입니다.
프로젝트에서는 다음 내용을 연결해서 볼 수 있습니다.
- 원본 문서를 검색 가능한 청크 단위로 나눕니다.
- 각 청크의 텍스트를 임베딩 모델에 전달합니다.
- 반환된 벡터와 원문을 같은 레코드에 연결합니다.
- 문서명과 페이지, 작성일 같은 메타데이터를 함께 저장합니다.
- 어떤 임베딩 모델과 차원을 사용했는지 기록합니다.
- 데이터가 변경되면 어떤 청크를 다시 임베딩할지 기준을 정합니다.
예를 들어 100페이지의 사내 규정을 하나의 벡터로 만들면 휴가 신청 기간과 출장비 기준처럼 서로 다른 내용이 하나의 표현에 섞일 수 있습니다. 반대로 문서를 너무 작은 문장 단위로 나누면 질문에 필요한 조건과 예외가 서로 다른 청크에 분리될 수 있습니다. 따라서 벡터 DB 연결에서 첫 번째 판단은 어느 제품을 사용할지가 아니라 어떤 텍스트 단위를 하나의 의미 벡터로 만들 것인지입니다.
- 원문과 임베딩 벡터는 저장 목적에서 차이가 있습니다
임베딩은 원문을 암호화하거나 압축해 다시 복원하기 위한 값이 아닙니다. 텍스트의 의미적 특성을 숫자 좌표 형태로 표현해 다른 텍스트와 비교하기 위한 데이터에 가깝습니다.
- 원문 텍스트: 검색 결과를 사용자에게 보여주거나 LLM의 context로 전달하기 위해 필요합니다.
- 임베딩 벡터: 질문과 문서가 의미적으로 얼마나 가까운지 계산하기 위해 사용합니다.
- 문서 ID: 검색 결과가 어느 원문과 연결되는지 식별하는 데 사용합니다.
- 메타데이터: 날짜와 카테고리, 문서 유형 등의 조건으로 검색 대상을 좁히는 데 활용할 수 있습니다.
- 벡터 인덱스: 많은 벡터 가운데 가까운 후보를 빠르게 찾을 수 있도록 구성됩니다.
OpenAI의 현재 임베딩 문서에서도 임베딩은 부동소수점 숫자의 벡터이며 두 벡터 사이의 거리가 텍스트 관련성을 나타낸다고 설명합니다. 생성된 임베딩을 벡터 DB에 저장해 검색에 이용할 수도 있습니다. 이 차이를 알고 있으면 문서를 벡터 DB에 넣었다는 표현도 더 구체적으로 바뀝니다. 실제로는 원문과 메타데이터를 보존하면서 의미 비교에 사용할 벡터 표현과 연결한 것이라고 설명하는 편이 정확합니다.
- 임베딩 모델을 바꿀 때는 기존 인덱스와의 일관성도 함께 확인해야 합니다
생성형 AI 프로젝트를 개선하면서 더 새로운 임베딩 모델로 변경하는 경우가 있습니다. 이때 질문만 새 모델로 임베딩하고 기존 문서 벡터를 그대로 두면 서로 다른 기준으로 생성된 벡터를 비교하게 될 수 있습니다.
임베딩 변경에서는 다음 내용을 확인할 수 있습니다.
- 문서와 질문이 같은 임베딩 모델을 사용하는지 확인합니다.
- 벡터 차원이 데이터베이스 인덱스 설정과 일치하는지 살펴봅니다.
- 기존 문서 벡터를 다시 생성해야 하는지 판단합니다.
- 동일 질문으로 변경 전후 검색 순위를 비교합니다.
- 다국어와 전문 용어에서 결과 차이를 확인합니다.
- 재임베딩 비용과 처리시간도 함께 기록합니다.
Azure AI Search의 벡터 인덱스 가이드도 하나의 벡터 필드에 같은 임베딩 모델에서 생성된 벡터를 구성하고, 쿼리 시에도 동일한 임베딩 공간에서 비교하는 구조를 설명합니다. 따라서 포트폴리오에서는 임베딩 모델을 업그레이드했다는 결과보다 모델 변경 후 전체 문서를 다시 벡터화하고 같은 질문 세트로 검색 품질을 재평가했다는 과정이 더 중요합니다.
- 임베딩이 잘 만들어졌다는 사실은 벡터 생성 성공이 아니라 실제 검색 결과로 확인해야 합니다
API가 정상적으로 벡터를 반환하면 임베딩 단계가 끝났다고 생각하기 쉽습니다. 하지만 프로젝트 목적은 숫자 배열을 얻는 것이 아니라 실제 질문에서 관련 문서를 찾는 것입니다.
- 기본 검증: 문서와 질문의 임베딩이 정상적으로 생성되는지 확인합니다.
- 동의어 검증: 표현은 다르지만 의미가 같은 질문에서 관련 문서가 검색되는지 확인합니다.
- 유사 개념 검증: 의미는 비슷하지만 다른 문서를 제대로 구분하는지 살펴봅니다.
- 고유명사 검증: 상품명과 코드처럼 정확한 문자열이 중요한 질문에서 결과를 확인합니다.
- 다국어 검증: 서비스가 여러 언어를 사용한다면 동일 의미 질문의 검색 결과를 비교합니다.
예를 들어 문서에는 연차유급휴가라고 적혀 있는데 사용자가 연차는 며칠 생기나요라고 질문했을 때 관련 규정이 검색된다면 의미 기반 검색의 장점이 드러납니다. 반대로 AB-100과 AB-101 같은 상품 코드는 의미가 매우 비슷해 보일 수 있기 때문에 벡터 검색만으로 정확한 결과를 보장하기 어려울 수 있습니다. 이런 테스트가 포함되어 있어야 임베딩 모델이 현재 프로젝트의 데이터와 질문 유형에 적합한지를 설명할 수 있습니다.
유사도는 질문과 문서 벡터 가운데 어떤 항목을 더 가깝다고 판단할지 정하는 기준입니다
- 벡터 검색에서는 질문과 가까운 문서를 거리나 유사도 점수로 찾습니다
사용자가 질문을 입력하면 해당 질문 역시 문서와 동일한 방식으로 임베딩됩니다. 벡터 DB는 질문 벡터와 저장된 문서 벡터를 비교하고 가까운 결과부터 순위를 만들어 반환합니다.
유사도 검색에서는 다음 내용을 이해할 수 있습니다.
- 사용자 질문을 임베딩 벡터로 변환합니다.
- 저장된 문서 벡터와 질문 벡터를 비교합니다.
- 유사도가 높은 후보를 순서대로 정렬합니다.
- 상위 k개의 결과를 검색 결과로 반환합니다.
- 결과마다 연결된 원문과 메타데이터를 함께 가져옵니다.
- 최종적으로 LLM에 전달할 문서를 선택합니다.
OpenAI는 임베딩 검색에서 cosine similarity를 권장하고 있으며 현재 임베딩은 정규화되어 있어 cosine similarity와 Euclidean distance가 동일한 순위를 만들 수 있다고 설명합니다. Azure 역시 cosine, dot product, Euclidean distance 등 여러 비교 방식을 지원하며 Azure OpenAI 임베딩에는 cosine을 사용하는 구조를 안내합니다. 다만 프로젝트에서 중요한 것은 수학 공식을 길게 설명하는 것이 아닙니다. 어떤 질문에서 어떤 문서가 더 높은 점수를 받았고 그 순위가 실제 의미와 일치하는지를 확인하는 것이 핵심입니다.
- cosine similarity와 거리 값은 숫자의 방향과 해석이 다를 수 있습니다
벡터 DB 제품이나 라이브러리에 따라 결괏값을 similarity 또는 distance로 표현할 수 있습니다. 이 차이를 이해하지 못하면 숫자가 큰 결과가 좋은 것인지 작은 결과가 좋은 것인지 잘못 판단할 수 있습니다.
- Cosine similarity 방식: 일반적으로 두 벡터 방향이 비슷할수록 유사성이 높은 것으로 해석합니다.
- Cosine distance 방식: similarity를 거리 형태로 바꿔 표현할 수 있어 작은 값이 더 가까운 결과가 될 수 있습니다.
- Euclidean distance 방식: 두 벡터 좌표 사이의 직선거리를 계산하기 때문에 작은 값일수록 가까운 결과입니다.
- Dot product 방식: 두 벡터의 방향과 크기에 영향을 받을 수 있으며 정규화된 벡터에서는 cosine과 유사한 순위를 만들 수 있습니다.
- DB별 score 표현: 같은 개념을 사용해도 API가 반환하는 score의 범위와 방향이 다를 수 있으므로 사용하는 시스템의 기준을 확인해야 합니다.
Azure AI Search의 최근 벡터 순위 문서도 cosine과 dot product, Euclidean distance의 차이를 구분하며 가까운 벡터 후보를 순위화하는 과정을 설명합니다. 포트폴리오에서는 유사도 공식 자체보다 현재 DB에서 score 0.8이 어떤 의미인지, 어떤 점수 아래의 결과를 실제 서비스에서 제외할지처럼 검색 결과를 운영 기준으로 연결한 경험이 더 중요합니다.
- 유사도 점수만 믿지 않고 실제 관련성을 직접 확인하는 과정이 필요합니다
벡터 DB가 높은 점수를 반환했다고 해서 항상 사용자의 질문에 필요한 문서라는 의미는 아닙니다. 표현이나 주제가 비슷하지만 실제 질문의 조건과 맞지 않는 문서가 상위에 올라올 수 있기 때문입니다.
유사도 평가에서는 다음 내용을 확인할 수 있습니다.
- 상위 검색 결과가 질문에 직접 답할 근거를 포함하는지 살펴봅니다.
- 의미는 비슷하지만 다른 문서가 높은 점수를 받는 사례를 수집합니다.
- 정답 문서가 몇 번째 순위에 나타나는지 기록합니다.
- 질문 유형별로 score 분포가 다른지 확인합니다.
- 임계값을 적용했을 때 정답 문서까지 제거되지 않는지 살펴봅니다.
- 점수와 사람이 판단한 관련성을 함께 비교합니다.
예를 들어 육아휴직 신청 방법이라는 질문에서 육아 관련 복지 안내 문서가 가장 높은 점수를 받을 수 있습니다. 두 문서는 의미적으로 관련 있지만 실제 신청 절차를 답할 근거는 다른 규정 문서에 있을 수 있습니다. 따라서 유사도 0.85 이상이면 정답처럼 임의의 기준을 먼저 만드는 것보다 실제 테스트 질문과 정답 문서를 이용해 score와 관련성의 관계를 확인한 뒤 기준을 정하는 방식이 더 적절합니다.
- 유사도 검색의 한계를 이해하면 키워드와 메타데이터를 함께 사용할 이유가 보입니다
벡터 검색은 의미가 비슷한 표현을 찾는 데 강점을 갖지만 모든 검색 조건을 의미 유사도로 해결할 필요는 없습니다. 특히 날짜와 상품번호, 문서 버전처럼 정확한 값이 중요한 조건에서는 다른 방식이 더 적합할 수 있습니다.
- 의미 중심 질문: 퇴사할 때 남은 연차는 어떻게 처리되나요처럼 문서 표현과 질문 표현이 다른 경우 벡터 검색이 도움이 될 수 있습니다.
- 정확한 코드 질문: 상품 A-104처럼 정확한 문자열이 핵심이라면 키워드 매칭이 중요할 수 있습니다.
- 기간 조건 질문: 2026년 이후 개정 규정처럼 날짜가 중요하다면 메타데이터 필터를 함께 사용할 수 있습니다.
- 문서 유형 조건: 인사규정과 복지안내처럼 검색 범위를 구분해야 한다면 카테고리 필터를 적용할 수 있습니다.
- 복합 질문: 의미 검색과 정확한 키워드가 모두 중요하다면 하이브리드 검색을 비교할 수 있습니다.
Azure AI Search의 현재 하이브리드 검색은 벡터 검색과 키워드 검색을 하나의 요청에서 병렬로 실행하고 결과를 결합합니다. 정확한 문자열과 의미 유사성을 함께 다뤄야 하는 RAG에서 이런 방식이 유용할 수 있습니다. 이런 차이를 이해하면 벡터 DB를 모든 검색의 대체재가 아니라 의미 검색이 필요한 부분을 담당하는 검색 구성요소로 볼 수 있습니다.
검색은 가까운 벡터를 찾는 것에서 끝나지 않고 LLM에 전달할 근거를 결정하는 단계입니다
- 벡터 DB 검색 결과는 최종 답변이 아니라 LLM이 사용할 후보 근거입니다
벡터 검색 결과를 사용자에게 그대로 보여주는 서비스도 있지만 RAG에서는 검색 결과를 다시 생성 모델에 전달하는 경우가 많습니다. 이때 벡터 DB는 답변을 만드는 시스템이라기보다 관련된 context를 찾아주는 retrieval layer 역할을 합니다.
검색 흐름에서는 다음 내용을 연결해서 볼 수 있습니다.
- 사용자의 질문을 임베딩합니다.
- 벡터 DB에서 가까운 문서를 검색합니다.
- top-k 결과와 메타데이터를 가져옵니다.
- 필요하면 검색 결과를 필터링하거나 재정렬합니다.
- 선택한 원문을 LLM prompt의 context에 포함합니다.
- LLM이 질문과 context를 이용해 최종 답변을 생성합니다.
OpenAI의 현재 Retrieval API 역시 vector store를 데이터 인덱스로 사용해 의미적으로 가까운 결과를 검색하고, 검색 결과를 모델과 결합해 응답을 합성하는 구조를 제공합니다. 따라서 포트폴리오에서 벡터 DB 구축을 별개의 기술 항목으로 보여주기보다 사용자 질문 → 임베딩 → 벡터 검색 → context 구성 → LLM 답변이라는 전체 흐름 안에서 설명하는 것이 좋습니다.
- top-k와 검색 임계값은 많이 가져오는 것과 정확한 근거만 가져오는 것 사이의 균형입니다
벡터 검색에서는 상위 몇 개 문서를 가져올지를 결정할 수 있습니다. 검색 결과를 많이 가져오면 필요한 문서가 포함될 가능성은 높아질 수 있지만 관련성이 낮은 내용까지 LLM context에 섞일 수도 있습니다.
- top-k가 작은 경우: context가 간결하지만 필요한 문서가 순위 밖으로 밀리면 정답 근거를 놓칠 수 있습니다.
- top-k가 큰 경우: 정답 문서 포함 가능성은 높아질 수 있지만 관련 없는 정보와 토큰 사용량도 증가할 수 있습니다.
- 임계값이 높은 경우: 관련성이 강한 결과만 남길 수 있지만 답할 수 있는 질문 범위가 줄어들 수 있습니다.
- 임계값이 낮은 경우: 더 많은 후보를 확보할 수 있지만 불필요한 문서까지 LLM에 전달될 수 있습니다.
- reranking을 사용하는 경우: 처음에는 후보를 넓게 찾고 질문과의 관련성을 다시 평가해 상위 문서를 정리할 수 있습니다.
예를 들어 top-3에서는 필요한 문서가 네 번째에 있어 답변에 실패하지만 top-10에서는 불필요한 문서가 너무 많이 들어올 수 있습니다. 이 상황에서는 단순히 k를 계속 늘리기보다 청킹과 검색 방식, reranking을 함께 검토하는 편이 좋습니다. 이런 비교가 프로젝트에 남으면 top-k=5를 사용했다보다 왜 5개를 선택했고 다른 값에서 어떤 결과 차이가 있었는지를 설명할 수 있습니다.
- 메타데이터와 하이브리드 검색을 추가하면 실제 서비스형 검색 구조에 가까워질 수 있습니다
벡터 DB 프로젝트에서 텍스트와 벡터만 저장하면 기본적인 의미 검색은 구현할 수 있습니다. 하지만 실제 서비스에서는 사용자가 원하는 문서 범위와 최신성, 권한 같은 조건도 함께 고려해야 할 수 있습니다.
검색 프로젝트에서는 다음 내용을 추가할 수 있습니다.
- 문서 작성일과 버전을 메타데이터로 저장합니다.
- 문서 유형과 조직, 카테고리로 검색 범위를 제한합니다.
- 사용자 권한에 따라 검색 가능한 문서를 구분합니다.
- 정확한 키워드가 중요한 질문에서는 keyword search를 함께 사용합니다.
- 벡터와 키워드 결과를 결합한 hybrid search를 비교합니다.
- 최종 검색 결과에 출처 정보를 함께 유지합니다.
Azure AI Search에서는 벡터 필드와 일반 텍스트·숫자 필드를 같은 인덱스에 구성할 수 있고, 메타데이터 필터와 하이브리드 검색을 함께 사용할 수 있습니다. 예를 들어 사내 문서 검색 AI라면 출장 규정이라는 의미 검색만 하는 것보다 2026년, 인사규정, 현재 유효 같은 메타데이터 조건을 함께 적용하면 오래된 문서를 제외하기 쉬워집니다. 이렇게 구성하면 벡터 DB 프로젝트가 단순 의미 검색 데모를 넘어 실제 서비스에서 필요한 검색 조건을 설계한 프로젝트로 발전합니다.
- 검색 결과와 최종 답변을 분리해서 평가해야 벡터 DB의 실제 역할을 설명할 수 있습니다
RAG 프로젝트에서 최종 답변이 틀리면 벡터 DB부터 바꾸거나 LLM 프롬프트부터 수정하는 경우가 있습니다. 하지만 먼저 검색 결과를 직접 확인해야 어느 단계가 문제인지 구분할 수 있습니다.
- 검색 실패 상태: 정답 근거가 벡터 DB 상위 결과에 포함되지 않습니다.
- 검색 순위 문제: 정답 문서는 존재하지만 top-k 밖에 위치합니다.
- context 구성 문제: 관련 문서는 검색됐지만 필요한 부분이 잘리거나 누락됩니다.
- 생성 실패 상태: 충분한 근거가 전달됐지만 LLM이 내용을 잘못 해석합니다.
- 정상 상태: 필요한 근거가 검색되고 생성 결과도 해당 문서에 충실합니다.
이 구조로 평가하면 최종 답변 하나만 보고 RAG 전체를 수정하는 문제를 줄일 수 있습니다. 벡터 DB에서 필요한 문서를 찾지 못했다면 임베딩과 청킹, 검색 조건을 확인하고, 정확한 문서가 전달됐는데도 답변이 틀렸다면 생성 단계의 프롬프트와 모델을 확인하는 방식입니다. 결국 검색 단계에서 중요한 것은 벡터 DB가 정상적으로 응답했는가가 아니라 필요한 근거를 실제로 LLM에 전달했는가입니다.
- conclusion
벡터 DB를 생성형 AI 프로젝트에 연결할 때 가장 피해야 할 방식은 제품 사용법만 익힌 뒤 벡터 DB 기반 RAG 구현이라는 결과로 프로젝트를 끝내는 것입니다. 벡터 DB는 그 자체로 답변을 생성하는 기술이 아닙니다. 문서와 질문을 임베딩으로 변환하고, 벡터 사이의 의미적 가까움을 이용해 필요한 데이터를 찾으며, 검색된 원문을 생성 모델의 context로 전달하는 검색 인프라입니다.
임베딩에서는 무엇을 벡터로 만들 것인지가 중요합니다.
원본 문서를 어느 단위로 나눌지와 어떤 모델을 사용할지, 메타데이터를 어떻게 연결할지에 따라 이후 검색 결과가 달라집니다. 모델을 변경한다면 문서와 질문이 같은 임베딩 공간에서 비교되는지도 확인해야 합니다.
유사도에서는 단순히 높은 score를 정답으로 받아들이지 않는 것이 중요합니다.
cosine similarity와 distance의 표현 차이를 이해하고, 실제 질문에서 높은 점수를 받은 문서가 정말 필요한 근거인지 직접 평가해야 합니다. 의미 기반 검색이 약한 상품 코드와 날짜, 고유명사 같은 질문은 키워드나 메타데이터 필터를 함께 검토할 수 있습니다. 검색에서는 top-k와 필터, 하이브리드 검색과 reranking 등을 이용해 최종적으로 LLM에 어떤 context를 제공할 것인지 결정해야 합니다. 현재 벡터 검색 시스템도 단순 kNN뿐 아니라 키워드와 벡터를 결합하는 하이브리드 검색, 메타데이터 필터 등을 함께 제공하는 방향으로 구성되고 있습니다.
최종적으로 확인할 항목은 다음과 같습니다.
- 원본 문서를 어떤 기준으로 나누고 임베딩했는지 설명할 수 있는지 확인합니다.
- 문서와 질문이 같은 임베딩 모델과 벡터 공간을 사용하는지 살펴봅니다.
- 사용하는 벡터 DB의 유사도 score와 distance 의미를 구분할 수 있는지 확인합니다.
- 실제 정답 문서가 top-k 안에서 어느 순위에 나타나는지 점검합니다.
- 벡터 검색이 약한 질문에서 키워드·필터·하이브리드 검색을 비교했는지 살펴봅니다.
- 검색 실패와 LLM 생성 실패를 분리해 다시 검증했는지 확인합니다.
벡터 DB 생성형 AI 프로젝트 준비 흐름은 다음과 같이 연결할 수 있습니다.
- 원본 데이터 수집 → 문서 구조 확인 → 청킹 → 임베딩 생성 → 원문·메타데이터·벡터 저장 → 벡터 인덱스 생성 → 질문 임베딩 → 유사도 검색 → top-k 결과 확인 → 메타데이터 필터 적용 → 키워드·하이브리드 검색 비교 → context 구성 → LLM 연결 → 검색 결과와 생성 결과 분리 평가 → 실패 원인 분석 → 설정 개선 → 동일 질문 재검증 → 프로젝트 문서화 → 포트폴리오와 면접 연결
결국 벡터 DB를 생성형 AI 프로젝트에 연결하는 핵심은 DB 제품 이름을 많이 아는 것이 아닙니다. 임베딩에서는 문서와 질문을 비교 가능한 벡터로 만들고, 유사도에서는 어떤 데이터가 의미적으로 가까운지 판단하며, 검색에서는 실제 답변에 필요한 근거를 골라 생성 모델에 전달할 수 있어야 합니다. 이 세 과정이 하나의 프로젝트 안에서 연결되고 검색 실패까지 직접 분석한 기록이 남아 있다면, 단순히 벡터 DB를 사용했다는 수준을 넘어 생성형 AI가 외부 지식을 찾아 사용하는 전체 검색 구조를 설계한 경험으로 포트폴리오와 면접에서 설명할 수 있습니다.