RAG 요소: 청킹, 검색 방법, Vector DB

• 1. 청킹 (Chunking)
  • 1.1 Chunking 개요
  • 1.2 Chunking 전략 및 방법론
  • 1.3 엔터프라이즈 RAG를 위한 트레이드오프 및 파라미터 튜닝
  • 1.4 고급 청킹 아키텍처 패러다임
• 2. 검색 방법 (Retrieval Methods)
  • 2.1 기반 검색 알고리즘 (Core Retrieval Paradigms)
  • 2.2 고도화된 컨텍스트 검색 기술
  • 2.3 사후 처리 아키텍처: 리랭킹 (Reranking)
  • 2.4 검색 방법론 선택을 위한 아키텍트 가이드라인
• 3. 벡터 데이터베이스 (Vector DB)
  • 3.1 벡터 데이터베이스의 개요
  • 3.2 RAG에서의 역할
  • 3.3 시장의 주요 벡터 데이터베이스 분류

• RAG 시스템의 성능을 좌우하는 3대 핵심 요소: 청킹(Chunking), 검색(Retrieval), 그리고 벡터 DB(Vector Database)

1. 청킹 (Chunking)

1.1 Chunking 개요

• Chunking이란?
  • 방대한 양의 단일 문서(PDF, 웹페이지, 매뉴얼 등)를
  • 임베딩 모델 및 LLM이 처리하기에 적합한 의미 있고 관리 가능한 작은 텍스트 조각(Chunk) 단위로 분할하는 데이터 전처리 과정
  • 메모리 효율성을 높이고 병렬 처리를 가능하게 하기 위한 기본 기법
• 왜 Chunking이 필수적인가?
  • Context Window의 물리적 한계:
    • LLM과 임베딩 모델은 한 번에 처리할 수 있는 최대 토큰 수(입력 제한)가 정해져 있음
  • 의미론적 검색(Semantic Search)의 정확도:
    • 너무 큰 문서(예: 100페이지짜리 책)를 통째로 임베딩하면
    • 문서 전체의 평균적인 의미만 벡터에 남게 되어,
    • 특정 페이지에 있는 구체적인 정보를 찾는 유사도 검색이 실패할 수 있음
  • 신호 대 잡음비(SNR) 최적화:
    • LLM에게 정답과 무관한 수십 페이지의 노이즈 데이터를 함께 전달하는 것보다,
    • 정답이 포함된 정밀한 청크 2~3개만 주입하는 것이 답변 품질 향상과 토큰 비용 절감에 직결됨

1.2 Chunking 전략 및 방법론

• 텍스트를 분할하는 아키텍처 알고리즘은 단순 크기 기준부터 의미론적 분석까지 단계적으로 발전하고 있음

• 고정 크기 청킹 (Fixed-size Chunking)
  • 메커니즘:
    • 가장 원시적인 방식
    • 단어나 글자 수(Character/Token)를 기준으로 무조건 일정한 크기(Chunk Size)로 자르는 방식
  • Overlap(중첩):
    • 문맥 단절을 방지하기 위해 앞 청크의 끝부분 일부를 다음 청크의 시작 부분과 겹치게 설정(Chunk Overlap)
  • 장단점:
    • 계산이 매우 빠르고 구현이 단순함
    • 문장의 중간이나 단어의 허리가 잘려 의미가 훼손될 수 있음
• 재귀적 문자 청킹 (Recursive Character Chunking)
  • 메커니즘:
    • LangChain의 RecursiveCharacterTextSplitter가 채택한 글로벌 표준 방식
    • 분할 구분자 기호 리스트(["\n\n", "\n", " ", ""])를 우선순위대로 가지고 있다가,
      🡲 텍스트가 지정된 Chunk Size보다 커지면
      🡲 문단 🡲 문장 🡲 단어 순으로 재귀적으로 쪼개어 내려감
  • 장단점:
    • 가능한 한 문단이나 문장의 경계를 유지하려고 노력하기 때문에,
    • 형태소나 문맥이 파괴되는 것을 막으면서도 목표치 크기를 안정적으로 맞출 수 있음
• 구조적/문서 기반 청킹 (Document-Specific Chunking)
  • 메커니즘:
    • Markdown, HTML, JSON, Python Code 등 문서 고유의 마크업 구조를 인지하여 자르는 방식
      • 예: #, ## 같은 마크다운 헤더 구조 기준 분할
  • 장단점:
    • 문서의 계층 구조(Hierarchy)가 완벽하게 보존됨
      • 예: 소스코드를 함수나 클래스 단위로 쪼갤 때 뛰어난 효율성을 제공
• 의미론적 청킹 (Semantic Chunking)
  • 메커니즘:
    • 최근 각광받는 고도화된 기법
    • 문장 단위로 모두 쪼갠 뒤 각 문장을 임베딩 벡터로 변환
      🡲 앞 문장과 뒷 문장의 벡터 유사도(Distance)를 실시간으로 계산
      🡲 의미적 유사성이 급격히 떨어지는 지점(Threshold)을 찾아 그곳을 청크의 경계선으로 동적 결정
  • 장단점:
    • 텍스트의 실제 ‘주제’가 바뀌는 지점을 정확히 포착하므로 검색 정확도가 극대화됨
    • 청킹 단계 자체에서 임베딩 모델을 무수히 호출하므로 전처리 비용과 시간이 많이 소모됨

1.3 엔터프라이즈 RAG를 위한 트레이드오프 및 파라미터 튜닝

• 청크 사이즈를 결정할 때는 비즈니스 도메인 데이터의 특성을 반드시 반영해야 함

청크 사이즈 (Chunk Size)	장점	단점 / 한계	적합한 유즈케이스
작은 사이즈 (예: 128~256 토큰)	- 수치, 단어, 명확한 사실 검색의 정확도 상승 - LLM 비용 최소화	문맥(Context) 범위가 좁아 전체적인 배경 맥락 추론 요약이 불가능	규정집 조항 검색, 품번/부품 매뉴얼 매칭
큰 사이즈 (예: 512~1024 토큰)	- 풍부한 주변 맥락 확보 가능 - 대화의 거시적 흐름 이해 용이	- 검색 결과에 불필요한 노이즈 혼입 가능성 증가 - LLM 입력 토큰 증가로 지연 시간 증가	논문 분석, 소송 판례 요약, 기술 백서 분석

1.4 고급 청킹 아키텍처 패러다임

• 단순 분할을 넘어, 최근 상용 시스템에서는 RAG 검색 효율을 극대화하기 위해 다음과 같은 이원화 아키텍처를 적용함

• Parent-Child Document (부모-자식 청킹 기법):
  • 메커니즘:
    • 검색용 데이터와 LLM 전달용 데이터를 분리
    • 데이터를 아주 작게 쪼갠 ‘자식 청크(Child)’를 만들고 이들을 벡터 DB에 저장하여 고속 정밀 검색을 수행
    • 유사도 검색으로 자식 청크가 채택되면, 실제 LLM에게는 그 자식 청크를 포함하고 있는 더 큰 ‘부모 청크(Parent)’ 혹은 문서 원본을 찾아서 전달
  • 효과:
    • 검색 정확도(정밀 매칭)와 LLM의 맥락 파악(풍부한 인텍스트) 두 마리 토끼를 모두 잡을 수 있음
• Metadata Enhancement (메타데이터 인젝션):
  • 청크를 자를 때 원문 텍스트만 남겨두면 문맥이 훼손될 수 있음
  • 각 청크의 상단이나 메타데이터 필드에 {"문서 제목": "...", "카테고리": "...", "생성 날짜": "..."}와 같은 컨텍스트를 강제로 주입하여 임베딩함으로써 벡터 공간 상에서 연관 청크들이 뭉치도록 유도

• Chunking은 RAG 시스템의 “첫 단추”이자 “데이터 거름망”
  • 문서의 도메인 특성(정형 구조 유무, 단선형 문장 위주인지 등)에 맞추어 Fixed/Recursive 단계에서 시작해,
  • 고도화 단계에서는 Semantic Chunking이나 Parent-Child 아키텍처로 진화시키는 것이 올바른 이정표
    
    
• 일반적인 한국어 비즈니스 문서 RAG 시스템 구축 시,
  • RecursiveCharacterTextSplitter를 기준으로 Chunk Size: 500 ~ 800 글자, Overlap: 50 ~ 100 글자 수준을 베이스라인(시작점)으로 잡고 실험하며 튜닝하는 것이 엔지니어링

2. 검색 방법 (Retrieval Methods)

• 검색(Retrieval) 방법론
  • RAG(검색 증강 생성) 시스템의 성능을 결정하는 가장 핵심적인 요소
  • 생성(Generation) 단계의 LLM이 아무리 똑똑하더라도, 검색 단계에서 잘못되거나 노이즈가 섞인 데이터를 가져오면 환각현상을 피할 수 없음
  • • RAG의 검색은 단순히 단어가 포함되었는지를 보는 것이 아니라, ‘질문의 의도’와 ‘문서의 내용’이 얼마나 가까운지를 계산함

2.1 기반 검색 알고리즘 (Core Retrieval Paradigms)

• 어휘 검색 (Sparse / Keyword Retrieval)
  • 개념:
    • 사용자가 입력한 단어와 문서 내 단어가 정확히 일치하는지 확인하는 전통적인 텍스트 매칭 방식
  • 대표 알고리즘:
    • TF-IDF(Term Frequency-Inverse Document Frequency)
      • 단어가 문서 내에 출현하는 빈도(TF)와 전체 문서군에서 해당 단어가 얼마나 희귀한지(IDF)를 곱하여 단어의 가중치를 산출하는 고전적 통계 알고리즘
      • 구현이 단순하고 직관적
      • 문서의 길이가 길어질수록 특정 단어가 반복되어 점수가 왜곡되는 ‘문서 길이 편향’을 제어하지 못함
    • BM25(Best Matching 25)
      • TF-IDF의 한계를 수학적으로 보정하여 발전시킨 알고리즘
      • 문서의 전체 평균 길이와 단어 빈도의 과도한 가중치 상승을 억제(Saturation)하여 점수를 매기는 기법
      • 현대 키워드 검색 엔진(Elasticsearch 등)의 표준 스택으로 사용됨
      • 고유명사나 특정 전문 용어를 초고속으로 정밀 검색하는 경우에 우수함
      • 토씨 하나 틀리지 않는 표면적 일치성에만 의존해 문맥(Context)을 읽지 못함
  • 특징:
    • 특정 품번, 고유 명사, 법률 조항 번호, 날짜 등 정확한 키워드 매칭이 필요할 때 압도적인 성능을 발휘함
  • 한계:
    • 동의어나 문맥을 이해하지 못함
      • 예: ‘오류’를 검색하면 ‘버그’나 ‘결함’이라는 단어가 포함된 문서는 찾아내지 못함
• 의미론적 검색 (Dense / Semantic Retrieval)
  • 개념:
    • 텍스트를 고차원 밀집 벡터(Dense Vector)로 변환(Embedding)한 뒤, 두 벡터 사이의 공간적 거리나 각도를 이용한 고유한 의미적 유사도를 계산하여 검색하는 방식
  • 대표 알고리즘:
    • Vector Similarity Search
      • 의미론적 검색(Dense Retrieval)의 핵심 엔진
      • 코사인 유사도(Cosine Similarity): 벡터 간의 방향성(각도)을 측정
      • L2 유클리드 거리(Euclidean Distance, L2 Distance): 절대적인 거리를 측정
      • HNSW(Hierarchical Navigable Small World): 대규모 데이터에서 검색 속도를 극대화
      • 등..
  • 특징:
    • 키워드가 일치하지 않아도 문맥과 의도가 유사한 문서를 찾아낼 수 있음
      • 예: ‘노트북 전원이 안 켜져’ 🡲 ‘배터리 방전 시 대처법’ 매칭 가능
    • “배가 고프다”와 “식사하고 싶다”처럼 단어는 다르지만 의미가 같은 데이터를 찾아낼 수 있음
  • 한계:
    • 학습 데이터에 없던 사내 전문 용어나 코드 번호처럼 정밀한 키워드 매칭에는 오히려 취약함
• 하이브리드 검색 (Hybrid Retrieval)
  • 개념:
    • 어휘 검색(BM25)과 의미론적 검색(Vector)의 장점을 결합한 현대 RAG의 표준(Baseline) 방식
  • 결합 알고리즘:
    • RRF (Reciprocal Rank Fusion)
      • 각각의 검색 엔진이 도출한 결과의 ‘순위(Rank)’를 기반으로 점수를 재계산하여 병합하는 알고리즘
      • 점수 스케일이 다른 두 엔진의 결과를 가장 안정적으로 통합함
  • 특징:
    • 키워드의 정밀함과 문맥의 유연함을 동시에 만족
    • 엔터프라이즈 환경에서 필수적으로 채택됨
• Top-k Retrieval (상위 결과 필터링 제어 기술)
  • 개념:
    • 다양한 검색 엔진(Sparse, Dense 등)을 통해 1차로 스코어링된 무수히 많은 검색 결과 중에서,
    • 유사도 점수가 가장 높은 최상위 k개(Top-k)의 핵심 청크만을 정량적으로 선별하여 LLM에게 최종 전달하는 동적 필터링 제어 기술
  • 대표 알고리즘:
    • k-Nearest Neighbors (k-NN) / Approximate Nearest Neighbors (ANN):
      • 고차원 벡터 공간에서 쿼리와 가장 가까운 k개의 이웃 벡터를 고속으로 추출하는 알고리즘
      • Hierarchical Navigable Small World (HNSW), Inverted File Index (IVF) 등 벡터 DB의 코어 스택
    • RRF (Reciprocal Rank Fusion):
      • 하이브리드 검색 시 여러 엔진의 순위를 조합하여 최종 Top-k 순위를 정렬·도출하는 상호 호환형 순위 병합 알고리즘
  • 특징:
    • 정보 밀도(Information Density) 극대화:
      • 무분별한 노이즈 문서 유입을 사전에 차단하고 정답 확률이 높은 고밀도 콘텍스트만 LLM 프롬프트에 주입
    • 비용 및 자원 효율성:
      • LLM의 입력 토큰 소모량을 예측 가능한 범위로 제한하여 API 호출 비용을 통제
      • 전체 인프라의 추론 지연 시간(Latency)을 최소화
  • 한계:
    • k값 결정의 트레이드오프:
      • k값이 너무 작으면 정답을 유추할 수 있는 결정적인 배경 맥락(Context)이 누락될 수 있음
      • k값이 너무 크면 불필요한 노이즈가 혼입되어 LLM이 헷갈리거나(Lost in the Middle 현상) 토큰 비용이 폭증
    • 고정형 임계치의 맹점:
      • 검색된 청크들의 점수가 전반적으로 모두 낮거나(질문과 무관한 쓰레기 데이터만 가득한 경우) 반대로 상위 10개가 모두 우수한 점수일 때,
      • 무조건 기계적으로 딱 k개만 자르기 때문에 동적인 상황 대응력이 떨어짐
        • 이를 보완하기 위해 최근에는 유사도 점수가 특정 기준을 넘는 청크만 동적으로 가져오는 임계치 방식(Similarity Threshold)을 혼합하여 보완

2.2 고도화된 컨텍스트 검색 기술

• 단순히 질문과 유사한 청크를 바로 뽑아오는 방식의 한계를 극복하기 위해,

• 프롬프트 주입 전단계에서 데이터를 가공하는 전략들

• 부모-자식 검색 (Parent-Child / Sub-Vector Retriever)
  • 개념:
    • 검색용 데이터와 LLM 학습용 데이터를 분리하는 아키텍처
  • 작동:
    • 문서를 작게 쪼갠 ‘자식 청크(Child)’를 임베딩하여 벡터 DB에 저장하고 고속으로 정밀 검색을 수행
    • 유사도 검색으로 자식 청크가 매칭되면, 실제 LLM에게는 그 자식 청크를 포함하는 거대한 ‘부모 문서(Parent)’의 콘텍스트를 찾아서 전달
  • 장점:
    • 파편화된 정보 조각이 아닌 풍부한 전후 맥락을 LLM에게 줄 수 있음
• 문장 윈도우 검색 (Sentence Window Retrieval)
  • 개념:
    • 단일 문장 단위로 아주 작게 쪼개어 임베딩한 뒤 검색 수행
  • 작동:
    • 특정 문장이 검색되면, 해당 문장만 LLM에 주는 것이 아니라
    • 설정된 윈도우 크기(예: 앞 3문장, 뒤 3문장)만큼의 주변 텍스트를 메모리 상에서 동적으로 확장하여 프롬프트에 주입
  • 장점:
    • 벡터 검색의 정밀도를 극대화하면서도 문맥 단절을 방지
• 멀티 쿼리 및 쿼리 변형 (Multi-Query / Query Rewriting)
  • 개념:
    • 사용자의 모호한 질문을 AI가 내부적으로 다양한 각도의 질문으로 다각화하여 검색하는 방식
  • 작동:
    • 사용자가 질문을 던지면 LLM이 유사한 의미의 다른 질문 3~4개를 추가 생성
    • 이 여러 개의 질문으로 각각 벡터 검색을 수행한 뒤 모든 결과를 취합
  • 장점:
    • 유저의 질문 능력이 부족하더라도 다각도로 그물망을 쳐서 정답 리트리벌 확률을 높임

2.3 사후 처리 아키텍처: 리랭킹 (Reranking)

• 검색 엔진이 1차로 찾아온 수십 개의 문서 중에서, LLM에게 전달할 진짜 알짜배기 문서 Top-N개를 고르고 정렬하는 단계

• 현대 고성능 RAG 아키텍처에서 가장 가성비가 좋은 필수 구간

• 역할:
  • 1차 벡터 검색 엔진(Bi-Encoder 방식)은 속도는 빠르지만 두 문장 간의 세밀한 상관관계를 비교하지 못함
  • 이를 보완하기 위해 1차로 걸러진 문서(예: 상위 25개)를 대상으로 고성능 문장 교차 인코더(Cross-Encoder / Reranker 모델)를 가동하여 질문과의 절대적 유사도 점수를 다시 매김
• 대표 모델:
  • Cohere Rerank, BGE-Reranker, 랭체인의 ContextualCompressionRetriever
• 이점:
  • LLM은 컨텍스트의 앞부분과 뒷부분은 잘 인지하지만 중간에 박힌 정보는 놓치는 경향(Lost in the Middle 현상)이 있음
  • Reranker는 가장 정답에 가까운 고밀도 청크를 프롬프트 최상단에 배치하여 이 문제를 해결함

2.4 검색 방법론 선택을 위한 아키텍트 가이드라인

• RAG 구축 대상 도메인의 데이터 성격에 따라 검색 엔진의 메인 아키텍처를 다르게 커스텀해야 함

데이터 도메인 특징	추천 검색 조합	아키텍처 핵심 포인트
정형 매뉴얼, 사규집, 품번 데이터	BM25 + Reranker	의미론적 유사도보다 글자 하나, 조항 단어 하나가 정확히 매칭되는 것이 최우선이므로 키워드 기반 소스에 무게를 둠
고객 인터뷰, 상담 로그, 비정형 Wiki	Hybrid (BM25 + Vector) + Reranker	질문의 표현 방식이 매우 다양하므로 Dense Vector를 통한 의미 검색이 주축이 되어야 하며, Reranker로 최종 필터링
방대한 보고서, 논문, 판례 분석	Parent-Child + Hybrid + Reranker	문서의 거시적 맥락과 미시적 사실 정보가 섞여 있으므로 부모-자식 아키텍처를 도입해 컨텍스트 윈도우 노이즈를 제어

• 현대 프로덕션 레벨의 RAG 검색 아키텍처는 단일 검색을 지양함
  • 1단계: 하이브리드 검색(어휘+의미)을 통해 후보군을 넓게 수집(Recall 극대화)
  • 2단계: 리랭킹(Reranking)을 통해 가장 정답 확률이 높은 청크만 압축·정렬(Precision 극대화)
• 위와 같은 2-Stage 파이프라인 구조를 취하는 것이 성능 최적화의 글로벌 표준

3. 벡터 데이터베이스 (Vector DB)

3.1 벡터 데이터베이스의 개요

• 정의 및 개념
  • 텍스트, 이미지, 오디오 등의 비정형 데이터를 임베딩 모델을 통해
  • 고차원 수치 배열인 밀집 벡터(Dense Vector)로 변환한 뒤,
  • 이를 효율적으로 저장, 인덱싱, 고속 유사도 검색을 수행할 수 있도록 설계된 특화 데이터베이스 시스템
• RAG에서 왜 필수적인가?
  • 기존의 관계형 데이터베이스(RDBMS)
    • 글자나 숫자의 완전 일치(Exact Match)를 기준으로 데이터를 찾음
  • RAG 시스템
    • 사용자의 질문과 “의미적으로 가장 유사한 문맥(Context)”을 찾아내야 하므로,
    • 고차원 공간 상에서 좌표 간의 거리를 계산하는 벡터 데이터베이스가 인프라의 핵심이 됨

3.2 RAG에서의 역할

• 단발성(Stateless)으로 동작하는 LLM에게 외부 지식을 실시간으로 공급하기 위한 ‘엔터프라이즈급 외부 장기 기억 저장소(Long-term Memory)’ 역할

• 핵심 기능 및 메커니즘 고도화
  • 밀집 벡터(Dense Vector) 인덱싱 및 저장:
    • 텍스트 청크를 임베딩 모델을 통해 고차원 수치 배열로 변환한 결과물(Embedding)을 대규모(수만 개~수억 개)로 적재하고 관리하는 고성능 저장소
  • 고속 근사 최근접 이웃 검색 (ANN - Approximate Nearest Neighbors):
    • 수천만 개의 벡터 사이에서 모든 거리를 전수조사(KNN)하면 연산 속도가 기하급수적으로 느려짐
    • 이를 해결하기 위해 HNSW(Hierarchical Navigable Small World)나 IVF(Inverted File Index) 같은 특화 인덱싱 알고리즘을 사용
    • 거대한 데이터셋 안에서도 밀리초(ms) 단위의 초고속 유사도 검색을 보장
  • 메타데이터 필터링 (Metadata Filtering - 하이브리드 서치 인프라):
    • 벡터 데이터(수치 좌표)뿐만 아니라 생성 날짜, 문서 카테고리, 작성자 권한 등 일반 텍스트 데이터(Metadata)를 한 노드에 병렬 저장
    • 사전/사후 필터링(Pre/Post-Filtering) 기술을 통해 특정 조건을 강제한 상태로 벡터 검색을 수행 🡲 검색 신뢰성을 극대화
      • 예: ‘2025년 이후 발행된 보안 등급 2급 이상의 문서 내에서만 검색
• 대표적 솔루션 및 최신 인프라 트렌드
  • 전용 벡터 데이터베이스 (Vector-Native DB):
    • Milvus, Qdrant, Pinecone, Chroma, FAISS 등
    • 대규모 고동시성(High Concurrency) 환경 및 실시간 벡터 인덱싱 성능이 극대화되어 있음
    • 대형 AI 에이전트 인프라의 주축으로 활용
  • 통합형 멀티모델 데이터베이스 (Database Extensions - 현재 주류 패러다임):
    • pgvector (PostgreSQL), Elasticsearch, MongoDB, Redis 등
    • 최근 엔터프라이즈 환경에서는
      • 새로운 DB를 추가 도입하는 비용(Data Silo 및 동기화 파이프라인 관리 오버헤드)을 줄이기 위해,
      • 기존 사내 레거시 데이터베이스 내에 벡터 인덱싱 기능을 통합하는 방식을 선호함
      • 특히 PostgreSQL의 pgvector 인프라는 완벽한 ACID 트랜잭션과 벡터 연산을 동시에 지원하여 표준 스택으로 자리 잡고 있음

3.3 시장의 주요 벡터 데이터베이스 분류

분류	대표 제품군	특징 및 아키텍트 관점의 장단점
전용 벡터 DB (Vector-Native)	Chroma, FAISS, Pinecone, Milvus, Qdrant	- 장점: 벡터 검색만을 위해 설계되어 초기 셋업이 극도로 단순하며 HNSW 등 대규모 벡터 연산 성능이 뛰어남 - 단점: 기존 사내 시스템(RDBMS)과 데이터 동기화 파이프라인을 별도로 구축해야 하는 오버헤드가 있음
확장형 데이터베이스 (Extension)	pgvector (PostgreSQL), Elasticsearch, MongoDB	- 장점: 검증된 DB 안에서 일반 데이터(텍스트, 메타데이터)와 벡터 데이터를 SQL쿼리 하나로 하이브리드 조회 가능 - 단점: 대규모 고동시성(High Concurrency) 벡터전용 검색환경에서는 네이티브 DB에 비해 자원소모제어가 까다로움

• 벡터 DB는 RAG 파이프라인에서 비정형 데이터의 “의미론적 좌표계이자 고속 검색 엔진”
• 초기 PoC(개념 검증) 단계나 로컬 AI 환경에서는 Chroma나 FAISS로 가볍게 시작하고,
• 상용 프로덕션 환경으로 확장 시에는 기존 인프라가 PostgreSQL 중심이라면 pgvector를,
• 대규모 독립 관리가 필요하다면 Milvus나 Qdrant 같은 Native 스택을 검토하는 것이 올바른 아키텍처 가이드라인