지난 글에서는 RAG가 어떤 순서로 동작하는지 살펴봤습니다. 문서를 잘게 나누고, 임베딩하고, Vector Store에 저장한 뒤, 사용자의 질문과 가까운 문서 조각을 찾아 LLM에게 전달하는 흐름이었습니다.
이번 글에서는 그중에서도 검색에 집중해 보겠습니다. RAG에서 검색은 단순히 “문서를 찾아오는 기능”이 아닙니다. 어떤 문서를 찾아오느냐에 따라 LLM의 답변 품질이 거의 결정됩니다.
이번 글의 핵심 질문
RAG에서 Azure AI Search는 왜 필요하고, Keyword Search, Semantic Ranker, Vector Search, Hybrid Search는 각각 어떤 역할을 할까요?
1. Azure AI Search란?
Azure AI Search는 Microsoft Azure에서 제공하는 검색 서비스입니다.
이름만 보면 “검색창 만드는 서비스인가?” 싶을 수 있지만, RAG 관점에서는 훨씬 중요한 역할을 합니다.
Azure OpenAI로 RAG를 구성할 때, Azure AI Search는 문서를 저장하고, 인덱싱하고, 사용자의 질문과 관련 있는 문서를 찾아주는 검색 엔진 역할을 합니다.
쉽게 말하면 LLM이 답변을 하기 전에 참고할 자료를 찾아주는 AI용 도서관 검색 시스템이라고 볼 수 있습니다.
| 기능 | 역할 | RAG에서의 의미 |
|---|---|---|
| Search Index | 검색 가능한 형태로 문서 저장 | 문서 조각, 벡터, 메타데이터를 관리 |
| Keyword Search | 단어 일치 기반 검색 | 정확한 용어가 포함된 문서를 찾음 |
| Vector Search | 의미가 가까운 문서 검색 | 표현이 달라도 의미가 비슷하면 검색 가능 |
| Semantic Ranker | 검색 결과를 의미 기준으로 재정렬 | 더 답변에 가까운 문서를 위로 올림 |
| Hybrid Search | 키워드 검색과 벡터 검색 결합 | 실무 RAG에서 검색 정확도를 높이는 핵심 방식 |
2. RAG에서 검색 엔진이 하는 일
RAG에서 LLM은 최종 답변을 생성합니다. 하지만 답변의 근거가 되는 문서를 찾는 일은 검색 엔진이 담당합니다.
예를 들어 사내 규정 챗봇에 사용자가 이렇게 물었다고 해보겠습니다.
질문:
"보안 문서를 다루는 팀도 재택근무를 신청할 수 있나요?"이때 검색 엔진은 “재택근무”, “보안 문서”, “신청 가능 여부”, “제외 대상”과 관련된 문서 조각을 찾아야 합니다. 만약 엉뚱하게 “휴가 신청 규정”을 찾아오면, LLM은 아무리 좋은 모델이어도 정확한 답을 만들기 어렵습니다.
RAG에서 검색 엔진의 역할은 LLM에게 좋은 재료를 골라주는 것입니다. 좋은 재료가 들어가야 좋은 답변이 나옵니다.
Retrieval과 Relevance
Azure AI Search의 검색 과정을 이해할 때는 크게 두 단어를 기억하면 좋습니다.
- Retrieval: 후보 문서를 찾아오는 단계
- Relevance: 찾아온 문서 중 무엇이 더 관련 있는지 순위를 매기는 단계
즉, 먼저 넓게 후보를 가져오고, 그다음 질문에 더 잘 맞는 문서를 위로 올립니다. 검색 품질을 높이려면 이 두 단계가 모두 중요합니다.
3. Keyword Search와 BM25
Keyword Search는 말 그대로 키워드 중심 검색입니다.
사용자의 질문에 들어 있는 단어와 문서 안의 단어가 얼마나 잘 일치하는지를 기준으로 문서를 찾습니다.
예를 들어 사용자가 “재택근무 신청 조건”이라고 검색하면, 문서 안에 “재택근무”, “신청”, “조건” 같은 단어가 들어 있는 문서를 우선적으로 찾습니다.
BM25란?
BM25는 Keyword Search에서 자주 사용되는 전통적인 랭킹 방식입니다.
쉽게 말해 검색어가 문서에 얼마나 의미 있게 등장하는지를 점수화하는 방법입니다.
여기서 중요한 포인트는 단순히 단어가 많이 나오면 무조건 좋은 문서로 보는 것이 아니라는 점입니다.
너무 흔한 단어는 낮게 보고, 검색어와 관련성이 높은 단어가 적절히 등장하는 문서를 더 높게 평가합니다.
| BM25가 보는 요소 | 직관적 의미 |
|---|---|
| 검색어 빈도 | 검색어가 문서에 어느 정도 등장하는가? |
| 문서 길이 | 너무 긴 문서라서 단어가 많이 나온 것은 아닌가? |
| 단어 희소성 | 흔한 단어인가, 중요한 단어인가? |
예를 들어 “재택근무”라는 단어는 사내 규정 문서에서 중요한 키워드일 수 있습니다. 반면 “신청”, “가능”, “기준” 같은 단어는 여러 문서에 많이 나올 수 있습니다. BM25는 이런 차이를 고려해서 점수를 계산합니다.
Keyword Search는 정확한 용어가 중요한 검색에 강합니다. 제품명, 문서번호, 조항명, 법률명처럼 특정 단어를 반드시 찾아야 할 때 유용합니다.
4. Semantic Ranker
Semantic Ranker는 검색 결과를 의미 기준으로 다시 정렬하는 기능입니다.
여기서 Semantic은 “의미”라는 뜻입니다.
Keyword Search는 단어 일치에 강하지만, 단어가 같다고 해서 항상 사용자의 질문에 가장 잘 맞는 문서는 아닙니다.
이때 Semantic Ranker가 한 번 더 문맥을 보고 “이 질문에 더 직접적으로 답하는 문서가 무엇인지” 판단합니다.
사용자 질문:
"보안 문서를 다루는 팀도 재택근무를 신청할 수 있나요?"
1차 검색 결과:
- 재택근무 신청 절차
- 보안 문서 관리 기준
- 재택근무 제외 대상
- 휴가 신청 방법
Semantic Ranker 적용 후:
1. 재택근무 제외 대상
2. 보안 문서 관리 기준
3. 재택근무 신청 절차
4. 휴가 신청 방법위 예시에서 “재택근무 신청 절차”는 키워드는 잘 맞지만, 질문의 핵심인 “보안 문서를 다루는 팀도 가능한가?”에 직접 답하는 문서는 아닐 수 있습니다. Semantic Ranker는 이런 검색 결과의 순서를 더 답변 중심으로 조정하는 역할을 합니다.
5. Vector Search
Vector Search는 텍스트를 숫자 벡터로 바꾼 뒤, 질문 벡터와 가까운 문서 벡터를 찾는 검색 방식입니다.
Keyword Search가 단어가 같은지를 본다면, Vector Search는 표현이 달라도 의미가 비슷한지를 봅니다.
사용자 질문:
"집에서 일하는 거 일주일에 몇 번 가능해요?"
문서 표현:
"재택근무는 주 2회까지 신청할 수 있습니다."이 경우 “집에서 일하는 거”와 “재택근무”는 단어는 다르지만 의미는 비슷합니다.
Keyword Search만 사용하면 놓칠 수 있지만,
Vector Search는 두 문장의 의미가 가깝다는 것을 활용해 관련 문서를 찾을 수 있습니다.
Vector Search는 사용자가 문서에 있는 표현을 정확히 몰라도 검색할 수 있게 해줍니다. 그래서 자연어 질문이 많은 RAG 챗봇에서 매우 중요합니다.
Vector Search의 기본 흐름
1. 문서 조각을 임베딩해서 벡터로 저장한다.
2. 사용자 질문도 임베딩해서 벡터로 만든다.
3. 질문 벡터와 가까운 문서 벡터를 찾는다.
4. 가까운 문서 조각을 LLM에게 근거로 전달한다.Semantic Ranker와 Vector Search는 뭐가 다를까?
둘 다 의미를 다룬다는 점에서 헷갈릴 수 있습니다. 하지만 역할이 다릅니다.
구분Semantic RankerVector Search
| 구분 | Semantic Ranker | Vecotr Search |
| 역할 | 검색된 결과를 다시 정렬 | 처음부터 의미가 가까운 문서를 검색 |
| 작동 위치 | 검색 이후 Relevance 단계 | 문서 Retrieval 단계 |
| 비유 | 후보 문서 순서를 다시 매기는 심사위원 | 의미가 비슷한 문서를 찾아오는 탐색기 |
6. Cosine Similarity와 Euclidean Distance
Vector Search에서는 질문 벡터와 문서 벡터가 얼마나 가까운지 계산해야 합니다.
이때 자주 등장하는 방식이 Cosine Similarity와 Euclidean Distance입니다.
Cosine Similarity
Cosine Similarity는 두 벡터가 가리키는 방향이 얼마나 비슷한지를 봅니다.
값은 보통 -1에서 1 사이로 해석하며, 1에 가까울수록 방향이 비슷합니다.
문장의 의미를 비교할 때는 벡터의 크기보다 방향이 더 중요할 때가 많습니다. 그래서 텍스트 임베딩 검색에서는 Cosine Similarity가 자주 사용됩니다.
Euclidean Distance
Euclidean Distance는 두 벡터 사이의 실제 거리를 계산합니다. 거리가 작을수록 두 벡터가 가깝다고 봅니다.
| 구분 | Cosine Similarity | Euclidean Distance |
|---|---|---|
| 기준 | 방향의 유사성 | 공간상의 거리 |
| 값 해석 | 1에 가까울수록 유사 | 0에 가까울수록 유사 |
| 직관 | 같은 방향을 바라보는가? | 물리적으로 얼마나 가까운가? |
| 텍스트 검색 | 자주 사용됨 | 상황에 따라 사용됨 |
7. Hybrid Search
Hybrid Search는 Keyword Search와 Vector Search를 함께 사용하는 방식입니다.
실무 RAG에서는 Hybrid Search가 매우 중요합니다.
왜냐하면 키워드 검색과 벡터 검색은 각각 잘하는 일이 다르기 때문입니다.
- Keyword Search는 정확한 단어, 코드, 문서명, 제품명 검색에 강합니다.
- Vector Search는 표현이 달라도 의미가 비슷한 문서를 찾는 데 강합니다.
- Semantic Ranker는 검색된 결과 중 더 답변에 가까운 문서를 위로 올리는 데 유용합니다.
실무에서는 사용자가 항상 문서에 있는 정확한 표현으로 질문하지 않습니다. 하지만 동시에 제품명, 정책명, 법률명처럼 정확한 키워드도 놓치면 안 됩니다. 그래서 두 방식을 결합하는 Hybrid Search가 유용합니다.
Hybrid Search 예시
사용자 질문:
"개인정보 다루는 팀은 집에서 일할 수 있어요?"
Keyword Search:
"개인정보", "팀", "재택근무" 같은 단어가 포함된 문서 검색
Vector Search:
"집에서 일할 수 있어요"와 의미가 가까운 "재택근무 신청 가능 여부" 문서 검색
Semantic Ranker:
검색 결과 중 질문에 직접 답하는 문서를 위로 재정렬Hybrid Search는 “정확한 단어를 찾는 능력”과 “의미를 이해하는 능력”을 함께 쓰는 방식입니다. RAG 검색 품질을 높이고 싶다면 가장 먼저 고려할 만한 전략입니다.
8. Filters와 Facets
Filters와 Facets는 검색 결과를 더 잘 다듬기 위한 기능입니다.
둘 다 검색 결과를 좁히는 데 쓰이지만, 역할이 조금 다릅니다.
Filter
Filter는 조건에 맞는 문서만 검색하도록 제한하는 기능입니다.
예를 들어 “2026년 문서만”, “인사 규정만”, “보안 등급이 공개인 문서만”처럼 검색 범위를 줄일 수 있습니다.
Filter 예시
문서 유형 = "인사 규정"
개정일 >= "2026-01-01"
공개 범위 = "사내 전체"Facet
Facet은 검색 결과를 특정 기준으로 분류해서 보여주는 기능입니다.
쇼핑몰 검색에서 “브랜드별”, “가격대별”, “카테고리별”로 결과를 나눠 보여주는 것을 떠올리면 쉽습니다.
RAG에서는 Facet이 사용자 UI에서 유용할 수 있습니다. 예를 들어 검색 결과를 “인사 규정”, “보안 정책”, “복지 제도”로 나눠 보여줄 수 있습니다.
| 구분 | Filter | Facet |
|---|---|---|
| 역할 | 조건에 맞는 결과만 남김 | 결과를 기준별로 분류해 보여줌 |
| 비유 | 검색 범위를 좁히는 체 | 결과를 정리하는 카테고리 |
| 예시 | 2026년 문서만 검색 | 문서 유형별 결과 수 표시 |
9. Search Index 설계
Search Index는 검색을 위해 문서를 저장하는 구조입니다. RAG에서 인덱스를 어떻게 설계하느냐에 따라 검색 품질, 비용, 속도, 출처 표시 방식이 달라집니다.
Search Index에는 보통 문서 조각의 원문, 임베딩 벡터, 문서명, 페이지, 작성일, 문서 유형 같은 정보가 함께 들어갑니다.
| 필드 | 역할 | 활용 예시 |
|---|---|---|
| id | 문서 조각 고유 식별자 | chunk_001 |
| content | 검색 및 답변에 사용할 원문 | 재택근무 제한 기준 문단 |
| contentVector | Vector Search용 임베딩 벡터 | [0.12, -0.03, 0.44, ...] |
| documentTitle | 출처 표시 | 2026 재택근무 운영지침 |
| category | 필터와 패싯에 사용 | 인사 규정, 보안 정책 |
| updatedAt | 최신성 판단 | 2026-03-01 |
인덱스 설계를 대충 하면 나중에 출처 표시, 필터링, 최신 문서 우선 검색, 권한 관리가 어려워질 수 있습니다. RAG에서는 문서 내용뿐 아니라 메타데이터 설계도 중요합니다.
10. 검색 방식 비교표
이제 Keyword Search, Semantic Ranker, Vector Search, Hybrid Search를 한 번에 비교해 보겠습니다.
| 검색 방식 | 기준 | 장점 | 주의점 | 적합한 상황 |
|---|---|---|---|---|
| Keyword Search | 단어 일치 | 정확한 용어 검색에 강함 | 표현이 다르면 놓칠 수 있음 | 제품명, 코드, 문서번호, 조항명 |
| BM25 | 키워드 기반 랭킹 | 전통적이고 안정적인 검색 점수 제공 | 문장 의미까지 깊게 이해하지는 못함 | 일반 텍스트 검색 |
| Semantic Ranker | 문맥과 의미 기반 재정렬 | 답변에 가까운 문서를 위로 올림 | 보통 후보 검색 이후에 사용 | 검색 결과 품질 개선 |
| Vector Search | 임베딩 벡터 유사도 | 표현이 달라도 의미가 비슷하면 검색 가능 | 정확한 키워드 검색에는 약할 수 있음 | 자연어 질문, 의미 기반 검색 |
| Hybrid Search | 키워드 + 벡터 + 의미 랭킹 | 정확성과 의미 검색을 함께 활용 | 설계와 튜닝이 복잡할 수 있음 | 실무 RAG 검색 |
11. 검색 품질 평가 지표
검색 방식을 선택했다면, 이제 “정말 잘 찾고 있는지” 평가해야 합니다. RAG에서는 답변만 보는 것이 아니라, 검색 결과가 적절했는지도 따로 봐야 합니다.
| 지표 | 의미 | 쉽게 말하면 |
|---|---|---|
| Precision | 검색된 결과 중 관련 있는 문서의 비율 | 가져온 것들이 얼마나 정확한가? |
| Recall | 관련 문서 중 실제로 검색된 비율 | 놓친 중요한 문서는 없는가? |
| MRR | 정답 문서가 얼마나 앞에 나오는지 평가 | 좋은 문서가 첫 번째 근처에 있는가? |
| nDCG | 검색 결과의 순서와 관련도를 함께 평가 | 좋은 문서들이 좋은 순서로 배치됐는가? |
예를 들어 고객센터 RAG라면 “정답 문서가 Top-3 안에 들어오는가?”를 많이 볼 수 있습니다. 검색 결과 상위 몇 개만 LLM에게 전달하기 때문에, 좋은 문서가 뒤쪽에 있으면 실제 답변에는 활용되지 못할 수 있습니다.
12. 비용과 성능 고려
검색 품질을 높이고 싶다고 해서 무조건 많은 기능을 켜고, 많은 문서를 가져오면 좋은 것은 아닙니다. 검색 품질, 응답 속도, 비용 사이에는 항상 균형이 필요합니다.
- 검색 결과를 너무 많이 가져오면 LLM 입력 토큰이 늘어납니다.
- Semantic Ranker나 Reranking 단계를 추가하면 품질은 좋아질 수 있지만 지연 시간이 늘 수 있습니다.
- 벡터 필드가 많고 문서 수가 많으면 인덱스 저장 비용과 검색 비용을 고려해야 합니다.
- 필터를 잘 설계하면 불필요한 검색 범위를 줄여 성능을 개선할 수 있습니다.
실무 RAG에서는 “가장 똑똑한 검색”보다 “충분히 정확하면서 빠르고 비용이 감당 가능한 검색”이 더 중요할 때가 많습니다.
13. 전체 흐름 한 번에 정리
마지막으로 Azure AI Search와 검색 방식의 관계를 한 번에 정리해 보겠습니다.
- Azure AI Search는 Azure OpenAI 기반 RAG에서 문서를 찾는 검색 엔진 역할을 한다.
- RAG 검색은 후보 문서를 찾는 Retrieval과 관련도 순위를 매기는 Relevance 단계로 볼 수 있다.
- Keyword Search는 단어 일치 기반 검색이며, 정확한 용어 검색에 강하다.
- BM25는 키워드 검색 결과의 관련도를 계산하는 전통적인 랭킹 방식이다.
- Semantic Ranker는 검색 결과를 의미와 문맥 기준으로 다시 정렬한다.
- Vector Search는 텍스트를 벡터로 바꿔 의미가 가까운 문서를 찾는다.
- Cosine Similarity는 벡터 방향의 유사도를 보고, Euclidean Distance는 벡터 간 거리를 본다.
- Hybrid Search는 키워드 검색과 벡터 검색을 함께 사용해 검색 품질을 높인다.
- Filters는 조건에 맞는 결과만 남기고, Facets는 결과를 기준별로 분류해 보여준다.
- Search Index 설계는 검색 품질, 출처 표시, 필터링, 비용에 직접적인 영향을 준다.
정리
RAG에서 LLM은 답변을 생성하지만, 좋은 답변의 시작은 검색입니다. 질문과 관련 없는 문서가 들어가면 LLM은 정확한 답변을 만들기 어렵습니다. 반대로 좋은 문서 조각이 들어가면 작은 모델을 사용하더라도 꽤 신뢰할 수 있는 답변을 만들 수 있습니다.
Azure AI Search는 RAG에서 이 검색 품질을 관리하는 핵심 도구입니다. Keyword Search, BM25, Semantic Ranker, Vector Search, Hybrid Search, Filters, Facets를 조합해 사용자의 질문에 가장 적절한 근거 문서를 찾아낼 수 있습니다.
좋은 RAG는 좋은 검색에서 시작됩니다.
LLM을 잘 고르는 것만큼이나, 어떤 검색 방식으로 어떤 문서를 가져올지 설계하는 것이 중요합니다.
다음 글에서는 Azure OpenAI로 RAG를 실제로 구현하는 흐름을 정리하겠습니다. Blob Storage에 문서를 올리고, Azure AI Search Index를 만들고, Playground와 SDK에서 RAG를 연결하는 과정을 실습 중심으로 살펴보겠습니다.
