이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
AI 프로젝트에서 Vector DB를 처음으로 적용한 것은 문서 유사도 검색 기능을 만들 때였습니다. 키워드 검색으로는 의미가 비슷하지만 단어가 다른 문서를 찾기 어렵다는 문제를 해결하기 위해, 텍스트를 임베딩으로 변환해 Pinecone에 저장하는 방식을 선택했습니다. 쿼리 텍스트도 같은 임베딩 모델로 변환한 뒤 코사인 유사도로 가장 가까운 벡터를 찾는 구조를 구현했습니다. 처음에는 임베딩 차원이 너무 커서 검색 속도가 느렸는데, HNSW 인덱스를 설정하자 대용량 데이터에서도 응답 시간이 안정됐습니다. 메타데이터 필터를 조합해 특정 카테고리 내에서만 유사도 검색을 하는 기능도 구현했고, 이 방식이 전체 검색보다 정확도가 높았습니다. Vector DB는 임베딩 품질이 검색 정확도를 결정한다는 결을 이 프로젝트에서 얻었습니다.
Vector DB 프로젝트에서 임베딩 모델을 바꿨을 때 검색 정확도가 얼마나 달라지는지를 직접 측정해본 경험이 있습니다. 처음에 사용한 임베딩 모델로 검색하면 의미적으로 관련 없는 문서가 상위에 오는 경우가 있었습니다. 더 강력한 임베딩 모델로 교체하니 동일한 쿼리에서 관련 문서 비율이 눈에 띄게 높아졌습니다. 정성 평가도 했는데, 쿼리 20개에 대해 상위 5개 결과가 실제로 관련 있는지 직접 확인하는 방식으로 정확도를 측정했습니다. 응답 시간도 측정했는데, 인덱스 종류에 따라 검색 속도 차이가 컸습니다. 브루트포스 검색은 데이터가 늘수록 선형으로 느려졌고, HNSW 인덱스는 데이터가 늘어도 응답 시간이 상대적으로 일정하게 유지됐습니다. 메타데이터 필터를 추가하면 검색 범위를 줄여서 속도와 정확도를 동시에 높일 수 있었는데, 카테고리 필터를 조합한 경우 필터 없는 전체 검색보다 정확도가 높았습니다.
Vector DB는 저장 방식보다 임베딩 품질과 인덱스 설계가 성능을 결정한다는 것을 이 경험에서 배웠습니다.
Vector DB를 RAG(검색 기반 생성) 구조에 적용했을 때 청크 분할 방식이 검색 품질에 큰 영향을 준다는 것을 발견했습니다. 처음에는 문서를 고정 크기로 나눴는데, 문단 중간이 잘리면서 문맥이 끊기는 경우가 생겼습니다. 문단 경계나 제목을 기준으로 분할하는 방식으로 바꾸니 청크가 완결된 의미 단위를 유지했고, 검색된 청크가 LLM에게 더 유용한 컨텍스트가 됐습니다. 청크 크기도 실험했는데, 너무 크면 관련 없는 내용이 함께 검색되고 너무 작으면 문맥이 부족해서 LLM 답변 품질이 떨어졌습니다.
중간 크기로 실험하면서 질의응답 품질이 가장 좋은 청크 크기를 찾았습니다. 임베딩 저장 시 원본 문서 ID와 청크 위치를 메타데이터로 같이 저장해두니, 검색 결과에서 원본 문서로 추적하는 것이 가능했습니다. RAG에서 Vector DB 품질은 임베딩 이전의 청크 분할 전략이 절반 이상을 결정한다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 신세계아이앤씨 AI 리서처 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.