Azure OpenAI 기반 사내 문서 검색 시스템 구성 방식: AI Search, Private Endpoint, 보안까지

"사내 문서를 검색하려면 키워드를 정확히 알아야 합니다." 이 말에 공감한다면, 자연어로 질문하면 관련 문서를 찾아 답변을 생성해주는 시스템이 필요한 상황입니다. Azure OpenAI와 AI Search를 결합하면 이 구조를 Azure 환경 안에서 완결적으로 구성할 수 있습니다.

핵심 요약

Azure AI Search는 키워드 검색, 벡터 검색, Semantic Ranker를 결합한 Hybrid Search를 제공하여, 단일 벡터 검색보다 높은 검색 정확도를 구현할 수 있습니다.
Azure OpenAI Service는 Azure 테넌트 내에서 모델을 호출하므로, 사내 데이터가 외부로 전송되지 않습니다.
Integrated Vectorization 기능으로 문서 업로드 → Chunking → Embedding → 인덱싱까지 파이프라인을 자동화할 수 있습니다.
Private Endpoint로 모든 서비스를 VNet 내부에서만 접근 가능하게 구성하여 네트워크 수준의 보안을 확보합니다.
비용은 AI Search 인스턴스 티어, OpenAI 토큰 사용량, Storage 세 가지에서 발생하며, 티어 선택이 월 비용의 대부분을 결정합니다.

1. 설계 배경과 요구사항

사내 기술 문서, 운영 매뉴얼, 정책 문서가 SharePoint와 Azure Blob Storage에 산재해 있는 중견 기업 시나리오를 가정합니다.

1.1 비즈니스 요구사항

직원 1,000명이 사용하는 사내 문서 검색 시스템
문서 규모: PDF, Word, PowerPoint, Markdown 약 10,000건
응답 시간: 3~5초 이내
보안: 사내 문서가 Azure 테넌트 외부로 유출되면 안 됨
기존 환경: Microsoft 365 + Azure AD(Entra ID) 기반 인증 체계

1.2 기술 제약 조건

Azure 환경에서 운영 중이므로 Azure 서비스 우선 검토
VNet 내부에서만 접근 가능해야 함 (공용 인터넷 노출 금지)
Entra ID 기반 사용자 인증과 문서 접근 제어가 필요
문서 업데이트 시 인덱스가 자동으로 갱신되어야 함
답변에 출처 문서와 해당 페이지를 반드시 포함해야 함

1.3 왜 Azure OpenAI + AI Search 조합을 선택했는가

사내 문서 검색 시스템을 구축하는 방법은 여러 가지가 있습니다.

선택지	장점	단점
LangChain + Pinecone + OpenAI API	유연한 커스터마이징	데이터가 외부로 전송됨, 인프라 직접 관리
AWS Bedrock Knowledge Bases	관리형, S3 통합	Azure 환경과 별도 관리, Entra ID 연동 불가
Azure OpenAI + AI Search	Entra ID 통합, VNet 격리, Hybrid Search	Azure 종속, AI Search 티어별 비용 차이 큼
자체 구축 (pgvector + 오픈소스 LLM)	완전한 통제, 비용 최적화 가능	운영 복잡도 높음, 검색 품질 직접 튜닝 필요

이 시나리오에서 Azure 조합을 선택하는 이유:

데이터 주권: Azure OpenAI는 고객 데이터를 모델 학습에 사용하지 않으며, 테넌트 내에서 처리됩니다.
인증 통합: Entra ID 기반 SSO로 별도 인증 체계 없이 사용자 식별과 권한 제어가 가능합니다.
Hybrid Search: 키워드 + 벡터 + Semantic Ranker 조합은 단일 벡터 검색 대비 검색 정확도가 높습니다.
Integrated Vectorization: 별도 Embedding 파이프라인 없이 AI Search가 문서 인덱싱 시 자동으로 벡터를 생성합니다.

다만 AI Search의 Semantic Ranker는 Standard 티어 이상에서만 사용 가능하므로, 비용과 검색 품질 사이의 trade-off를 초기에 결정해야 합니다.

2. 전체 아키텍처 구조

이 아키텍처는 크게 네 영역으로 나뉩니다.

영역	역할	주요 서비스
데이터 수집/인덱싱	문서를 청크로 분할하고 벡터 인덱스 생성	Blob Storage, AI Search (Indexer + Skillset)
검색/생성	사용자 질문에 대해 검색 + 응답 생성	AI Search (Hybrid Search), Azure OpenAI (GPT-4.1)
보안/네트워크	접근 제어와 네트워크 격리	Private Endpoint, Entra ID, Managed Identity
운영/모니터링	비용 추적, 품질 모니터링, 로그 수집	Azure Monitor, Application Insights, Log Analytics

2.1 데이터 흐름 요약

운영팀이 Blob Storage에 문서를 업로드하거나, SharePoint에서 동기화됩니다.
AI Search Indexer가 문서를 감지하고 Skillset을 통해 텍스트 추출 → Chunking → Embedding을 수행합니다.
생성된 벡터와 텍스트가 AI Search 인덱스에 저장됩니다.
사용자가 웹 앱에서 자연어 질문을 입력합니다.
애플리케이션이 AI Search에 Hybrid Query를 실행하여 관련 문서 청크를 검색합니다.
검색된 청크를 컨텍스트로 Azure OpenAI(GPT-4.1)에 전달하여 응답을 생성합니다.
출처 정보와 함께 사용자에게 응답을 반환합니다.

3. 핵심 구성 요소 상세

3.1 Azure AI Search

AI Search는 이 아키텍처에서 검색 엔진 역할을 담당합니다. 단순한 벡터 저장소가 아니라, 키워드 검색과 벡터 검색을 결합하고 Semantic Ranker로 재정렬하는 복합 검색 엔진입니다.

Hybrid Search가 중요한 이유:

Microsoft의 벤치마크에 따르면, Hybrid Search + Semantic Ranker 조합은 단일 벡터 검색 대비 검색 정확도가 높습니다. 이는 키워드 검색이 정확한 용어 매칭에 강하고, 벡터 검색이 의미적 유사성에 강하기 때문입니다.

검색 방식	강점	약점
키워드 검색 (BM25)	정확한 용어, 코드명, 고유명사 매칭	동의어, 문맥 이해 부족
벡터 검색	의미적 유사성, 다국어 지원	정확한 키워드 매칭에 약함
Hybrid (키워드 + 벡터)	양쪽 강점 결합	단독 사용 대비 지연 시간 증가
Hybrid + Semantic Ranker	최고 정확도, 문맥 기반 재정렬	Standard 티어 이상 필요, 추가 비용

Reciprocal Rank Fusion (RRF):

Hybrid Search에서 키워드 결과와 벡터 결과를 병합할 때, RRF 알고리즘을 사용합니다. 각 검색 방식의 순위를 기반으로 점수를 계산하여 통합 순위를 생성합니다. 별도 가중치 튜닝 없이도 안정적인 결과를 제공하는 것이 장점입니다.

Semantic Ranker:

Hybrid Search 결과에 대해 Microsoft의 언어 이해 모델이 추가 재정렬(L2 ranking)을 수행합니다. 검색 결과 중 질문과 가장 관련 있는 문서를 상위로 올려주며, Semantic Captions(하이라이트된 요약)과 Semantic Answers(질문에 대한 직접 답변 추출)도 제공합니다.

3.2 Azure OpenAI Service

Azure OpenAI는 OpenAI 모델을 Azure 인프라에서 호스팅하는 서비스입니다. API는 동일하지만, 데이터 처리가 Azure 테넌트 내에서 이루어지는 것이 핵심 차이입니다.

모델 선택:

용도	모델	이유
응답 생성	GPT-4.1	코드/기술 문서 이해력, 긴 컨텍스트 지원, instruction following 성능
Embedding	text-embedding-3-large	3,072차원, 다국어 검색 성능 우수, 차원 축소 가능
간단한 질문 라우팅	GPT-4.1 mini	비용 절감, 빠른 응답

text-embedding-3-large 선택 이유:

3,072차원 벡터를 생성하지만, dimensions 파라미터로 256~3,072 사이에서 조절 가능합니다 (Matryoshka Representation Learning).
이 시나리오에서는 1,536차원으로 설정하여 저장 비용과 검색 성능의 균형을 맞춥니다.
한국어 문서가 포함된 환경에서 ada-002 대비 다국어 검색 성능이 향상되었습니다.

3.3 Integrated Vectorization

AI Search의 Integrated Vectorization은 별도 Embedding 파이프라인을 구축하지 않아도 되는 기능입니다.

동작 방식:

AI Search Indexer가 Blob Storage에서 문서를 가져옵니다.
Skillset에 포함된 Text Split Skill이 문서를 청크로 분할합니다.
Azure OpenAI Embedding Skill이 각 청크를 벡터로 변환합니다.
벡터와 텍스트가 함께 인덱스에 저장됩니다.
쿼리 시에도 동일한 Embedding 모델로 질문을 벡터화합니다.

Skillset 구성 예시:

{
  "skills": [
    {
      "@odata.type": "#Microsoft.Skills.Text.SplitSkill",
      "textSplitMode": "pages",
      "maximumPageLength": 2000,
      "pageOverlapLength": 500,
      "unit": "characters"
    },
    {
      "@odata.type": "#Microsoft.Skills.Text.AzureOpenAIEmbeddingSkill",
      "modelName": "text-embedding-3-large",
      "dimensions": 1536,
      "resourceUri": "https://<your-openai>.openai.azure.com",
      "deploymentId": "text-embedding-3-large",
      "apiKey": null
    }
  ]
}

Managed Identity를 사용하면 apiKey 없이 AI Search가 Azure OpenAI에 인증할 수 있습니다. 키 기반 인증보다 보안적으로 더 적합합니다.

3.4 Azure Document Intelligence (선택)

PDF에 표, 이미지, 복잡한 레이아웃이 많은 경우, Document Intelligence의 Layout 모델을 Skillset에 추가하면 구조를 유지한 채 텍스트를 추출할 수 있습니다.

시나리오	권장 방식
텍스트 중심 문서 (Markdown, Word)	AI Search 기본 파서로 충분
표/양식이 많은 PDF	Document Intelligence Layout 모델 추가
스캔된 이미지 PDF	Document Intelligence OCR + Layout 조합

Document Intelligence를 추가하면 인덱싱 비용이 증가하므로, 모든 문서에 적용하기보다는 복잡한 PDF에만 선별적으로 사용하는 것이 합리적입니다.

4. 데이터 파이프라인 설계

4.1 문서 수집 흐름

소스	수집 방법	Blob Storage 경로
SharePoint Online	Azure Logic App / Graph API 연동	`documents/sharepoint/`
직접 업로드 (PDF, Word)	관리자 포털 또는 AzCopy	`documents/upload/`
Confluence	Custom Connector (Azure Functions)	`documents/confluence/`
내부 Wiki	Git Sync 또는 주기적 Pull	`documents/wiki/`

4.2 인덱싱 파이프라인 구성

AI Search의 Indexer → Skillset → Index 구조로 자동화합니다.

Indexer 설정:

{
  "name": "doc-indexer",
  "dataSourceName": "blob-datasource",
  "targetIndexName": "documents-index",
  "skillsetName": "doc-skillset",
  "schedule": {
    "interval": "PT1H"
  },
  "parameters": {
    "configuration": {
      "dataToExtract": "contentAndMetadata",
      "parsingMode": "default"
    }
  },
  "fieldMappings": [],
  "outputFieldMappings": [
    {
      "sourceFieldName": "/document/pages/*",
      "targetFieldName": "chunk_content"
    },
    {
      "sourceFieldName": "/document/pages/*/vector",
      "targetFieldName": "content_vector"
    }
  ]
}

인덱싱 주기 설계:

방식	설정	적합한 경우
스케줄 기반	`interval: PT1H` (1시간)	문서 변경이 적은 환경
이벤트 기반	Blob 변경 감지 → Indexer 실행	실시간성이 중요한 환경
수동 트리거	REST API로 Indexer 실행	대량 업로드 후 일괄 처리

설계 관점에서 스케줄 기반(1시간)을 기본으로 하되, 긴급 문서 업데이트가 필요한 경우 수동 트리거를 병행합니다. AI Search Indexer는 변경 감지(Change Detection)를 지원하므로, 매 실행마다 변경된 문서만 재인덱싱합니다.

4.3 Blob Storage 구조 설계

storage-account/
├── documents/                  # 원본 문서 컨테이너
│   ├── sharepoint/
│   │   ├── hr-policy/
│   │   └── engineering/
│   ├── upload/
│   └── wiki/
├── processed/                  # 전처리 필요 시 사용
└── metadata/                   # 접근 권한 매핑 정보
    └── acl-mapping.json

메타데이터 활용:

Blob에 메타데이터 태그를 추가하면, AI Search 인덱스에서 필터링에 활용할 수 있습니다.

x-ms-meta-department: engineering
x-ms-meta-confidentiality: internal
x-ms-meta-document-type: runbook

이 메타데이터는 인덱스 필드로 매핑되어, 검색 시 $filter=department eq 'engineering' 형태로 접근 제어에 활용됩니다.

5. 검색과 응답 생성 설계

5.1 쿼리 처리 흐름

사용자가 자연어 질문을 입력합니다.
애플리케이션 레이어에서 Entra ID 토큰을 확인하고 사용자 부서/권한을 추출합니다.
AI Search에 Hybrid Query를 실행합니다 (키워드 + 벡터 + Semantic Ranker + 필터).
상위 5~10개 청크를 검색 결과로 받습니다.
검색 결과를 시스템 프롬프트의 컨텍스트로 구성합니다.
Azure OpenAI(GPT-4.1)에 Completion 요청을 보냅니다.
생성된 응답과 출처 정보를 사용자에게 반환합니다.

5.2 Hybrid Query 구성 예시

from azure.search.documents import SearchClient
from azure.search.documents.models import VectorizedQuery

# 질문을 벡터로 변환
question_vector = openai_client.embeddings.create(
    model="text-embedding-3-large",
    input=user_question,
    dimensions=1536
).data[0].embedding

# Hybrid Search 실행
results = search_client.search(
    search_text=user_question,              # 키워드 검색
    vector_queries=[
        VectorizedQuery(
            vector=question_vector,          # 벡터 검색
            k_nearest_neighbors=10,
            fields="content_vector"
        )
    ],
    query_type="semantic",                   # Semantic Ranker 적용
    semantic_configuration_name="default",
    filter=f"department eq '{user_department}'",  # 접근 제어
    top=5
)

5.3 프롬프트 설계

시스템 프롬프트:
당신은 사내 문서를 기반으로 질문에 답변하는 어시스턴트입니다.
규칙:
1. 아래 제공된 문서 내용만을 기반으로 답변하세요.
2. 문서에서 답을 찾을 수 없으면 "해당 정보를 찾을 수 없습니다"라고 답하세요.
3. 답변 끝에 참조한 문서 이름과 페이지를 명시하세요.
4. 추측하거나 문서에 없는 정보를 생성하지 마세요.

---
[검색된 문서]
문서 1: {title} (페이지 {page})
{chunk_content}

문서 2: {title} (페이지 {page})
{chunk_content}
---

사용자 질문: {user_question}

이 프롬프트 구조에서 핵심은 "문서에 없는 정보를 생성하지 마세요"입니다. RAG에서 Hallucination을 줄이는 가장 기본적인 방법이지만, 모델이 이 지시를 반드시 따른다는 보장은 없으므로 추가 검증 레이어가 필요합니다.

5.4 응답 품질 향상 전략

전략	설명	적용 시점
Query Rewriting	사용자 질문을 검색에 적합한 형태로 변환	질문이 모호한 경우
Top-K 조정	검색 결과 수를 5~10개로 조절	컨텍스트 길이 vs 정확도 균형
Chunk Overlap 조정	인접 청크 간 겹침을 500자로 설정	문맥 단절 방지
Re-ranking	Semantic Ranker로 최종 순위 재조정	검색 결과 상위 50개에 적용

6. 보안 아키텍처

6.1 네트워크 격리

계층	설정	목적
AI Search Private Endpoint	VNet 내 전용 IP 할당	공용 네트워크 접근 차단
Azure OpenAI Private Endpoint	VNet 내 전용 IP 할당	모델 호출을 VNet 내부로 제한
Blob Storage Private Endpoint	VNet 내 전용 IP 할당	문서 저장소 네트워크 격리
Public Network Access: Disabled	모든 서비스에서 공용 접근 비활성화	인터넷 경유 접근 원천 차단

Private DNS Zone 구성:

Private Endpoint를 사용하면 서비스의 FQDN이 VNet 내부 IP로 해석되어야 합니다. 이를 위해 Private DNS Zone을 연결합니다.

서비스	Private DNS Zone
AI Search	`privatelink.search.windows.net`
Azure OpenAI	`privatelink.openai.azure.com`
Blob Storage	`privatelink.blob.core.windows.net`

6.2 인증과 권한 관리

Managed Identity 기반 서비스 간 인증:

서비스 간 통신에 API Key 대신 Managed Identity를 사용합니다.

호출 경로	인증 방식	RBAC 역할
App Service → AI Search	System-assigned Managed Identity	Search Index Data Reader
App Service → Azure OpenAI	System-assigned Managed Identity	Cognitive Services OpenAI User
AI Search Indexer → Blob Storage	System-assigned Managed Identity	Storage Blob Data Reader
AI Search Skillset → Azure OpenAI	System-assigned Managed Identity	Cognitive Services OpenAI User

이 구성의 장점: - API Key 누출 위험이 없습니다. - Key Rotation 관리가 필요 없습니다. - Entra ID의 조건부 액세스 정책을 적용할 수 있습니다.

사용자 인증 흐름:

[사용자] → [Entra ID 로그인] → [App Service (MSAL)] → [토큰 검증]
                                                            │
                                                            ▼
                                    [사용자 부서/그룹 클레임 추출]
                                                            │
                                                            ▼
                                    [AI Search 필터에 부서 조건 추가]

6.3 문서 접근 제어 (ACL)

사용자별로 볼 수 있는 문서가 다른 경우, Security Trimming을 적용합니다.

방법 1: 메타데이터 기반 필터링 (권장)

문서 업로드 시 department, access_level 메타데이터를 태깅합니다.
검색 시 $filter 파라미터로 사용자 권한에 맞는 문서만 반환합니다.
구현이 단순하고 성능에 미치는 영향이 적습니다.

방법 2: Azure AI Search Security Trimming

각 문서에 allowed_groups 필드를 추가합니다.
사용자의 Entra ID 그룹 멤버십과 비교하여 필터링합니다.
세밀한 접근 제어가 가능하지만, 인덱스 크기가 증가합니다.

이 시나리오에서는 방법 1로 시작하여, 세밀한 제어가 필요해지면 방법 2로 전환합니다. 대부분의 사내 문서 시스템에서는 부서 단위 접근 제어로 충분합니다.

6.4 데이터 보호

보호 대상	적용 방법
저장 중 암호화	Azure Storage Service Encryption (기본 활성화)
전송 중 암호화	TLS 1.2 이상 강제
AI Search 인덱스 암호화	Customer Managed Key (CMK) 적용 가능
응답 내 민감 정보	Azure Content Safety로 PII 필터링

7. 비용 설계

7.1 비용 구조 분석

구성 요소	과금 기준	월 예상 비용 (1,000명, 일 100건 질문 기준)
AI Search (Standard S1)	인스턴스 시간	~$245/월 (1 SU)
Semantic Ranker	1,000 쿼리당 $1 (첫 1,000건 무료)	~$2/월 (3,000건/월)
Azure OpenAI - GPT-4.1 (응답 생성)	토큰 사용량	~$30~60/월
Azure OpenAI - Embedding	토큰 사용량	~$3~5/월
Blob Storage	GB/월 + 트랜잭션	~$5~10/월
App Service (B2)	인스턴스	~$55/월
Private Endpoint (4개)	시간 + 데이터 처리	~$30~40/월
합계		~$370~417/월

7.2 티어별 비용 비교

AI Search 티어 선택이 전체 비용의 핵심을 결정합니다.

티어	월 비용 (SU당)	벡터 검색	Semantic Ranker	인덱스 용량	적합한 경우
Free	$0	✗	✗	50MB	PoC/테스트
Basic	~$74	✓	✗	15GB (최대 45GB)	소규모, Semantic Ranker 불필요
Standard S1	~$245	✓	✓	160GB (최대 1.9TB)	대부분의 프로덕션 환경
Standard S2	~$981	✓	✓	512GB (최대 6TB)	대규모 문서, 높은 QPS

가격은 리전에 따라 다를 수 있으며, 위 가격은 공식 가격 페이지 기준입니다.

7.3 비용 최적화 전략

1. 모델 라우팅으로 LLM 비용 절감

간단한 FAQ 질문 → GPT-4.1 mini (비용 약 1/10)
복잡한 분석/요약 질문 → GPT-4.1
질문 복잡도를 판단하는 분류기를 앞단에 배치합니다.

2. 응답 캐싱

Azure Cache for Redis에 질문 해시 → 응답을 캐싱합니다.
동일 질문의 반복이 많은 사내 환경에서 30~50% 캐시 히트율이 기대됩니다.
캐시 TTL은 문서 갱신 주기와 맞춰 설정합니다 (예: 1시간).

3. Embedding 차원 축소

text-embedding-3-large의 기본 3,072차원을 1,536차원으로 줄이면 저장 용량과 검색 비용이 약 50% 절감됩니다.
검색 품질 저하가 허용 범위인지 PoC에서 먼저 검증합니다.

4. Provisioned Throughput Units (PTU)

일일 호출량이 예측 가능하고 안정적이면, PTU로 전환하여 토큰 비용을 절감할 수 있습니다.
다만 사용량이 불규칙한 초기에는 Pay-as-you-go가 더 적합합니다.

8. 운영 설계

8.1 모니터링 지표

지표	수집 방법	알림 기준
응답 지연 시간 (P95)	Application Insights	> 5초
AI Search 쿼리 지연	AI Search Metrics	> 500ms
OpenAI 호출 실패율	Application Insights	> 2%
검색 결과 0건 비율	애플리케이션 로그	> 15%
토큰 사용량 (일별)	Azure OpenAI Metrics	일일 예산 80% 도달 시
Indexer 실행 실패	AI Search Indexer Status	실패 발생 시 즉시

8.2 검색 품질 평가

초기 평가 (출시 전):

50~100개의 질문-정답 쌍을 준비합니다.
각 질문에 대해 검색 결과의 관련성을 평가합니다 (Precision@5, Recall).
Top-K, Chunk 크기, Overlap을 조정하며 최적값을 찾습니다.

운영 중 평가:

사용자 피드백(👍/👎)을 수집하여 주간 단위로 품질 추이를 모니터링합니다.
검색 결과 0건 질문을 분석하여 인덱싱 누락 문서를 파악합니다.
응답에 대한 Groundedness 점수를 계산합니다 (응답이 검색 결과에 근거하는 비율).

8.3 인덱스 유지보수

작업	주기	방법
증분 인덱싱	매시간	Indexer 스케줄
전체 재인덱싱	스키마 변경 시	수동 트리거
삭제된 문서 처리	매일	Soft-delete 정책
인덱스 통계 확인	매주	Azure Portal / REST API

Soft-delete 처리:

문서가 삭제되었을 때 인덱스에서도 제거하려면, Blob Storage의 Soft-delete metadata를 활용합니다. Blob에 IsDeleted=true 태그를 추가하면, Indexer가 다음 실행 시 해당 문서를 인덱스에서 제거합니다.

9. AWS Bedrock 방식과의 비교

이전 글에서 다룬 AWS Bedrock Knowledge Bases와 이 Azure 구성을 비교합니다.

기준	Azure OpenAI + AI Search	AWS Bedrock Knowledge Bases
검색 엔진	AI Search (Hybrid + Semantic Ranker)	OpenSearch Serverless (벡터 검색 중심)
검색 방식	키워드 + 벡터 + Semantic Ranker	벡터 유사도 중심
인덱싱 자동화	Integrated Vectorization (Indexer + Skillset)	Knowledge Bases Sync
최소 비용	~$250/월 (Standard S1)	~$200~691/월 (OpenSearch OCU)
인증 통합	Entra ID 네이티브	IAM + Cognito 조합
문서 소스	Blob, SharePoint, SQL 등 다양한 Indexer 지원	S3 중심
Chunking 제어	Skillset에서 자유롭게 구성	4가지 프리셋 옵션
Guardrails	Azure Content Safety	Bedrock Guardrails
네트워크 격리	Private Endpoint + NSG	VPC Endpoint

선택 기준:

Microsoft 365 + Azure 환경 → Azure OpenAI + AI Search
AWS 환경 + S3 기반 문서 → Bedrock Knowledge Bases
검색 정확도 최우선 → Azure AI Search (Hybrid + Semantic Ranker)
운영 단순성 최우선 → Bedrock Knowledge Bases (전체 파이프라인 관리형)
Chunking 커스터마이징 필요 → Azure AI Search (Skillset 자유도 높음)

10. 구현 시 자주 하는 실수

Private Endpoint 설정 후 DNS 해석 문제: Private Endpoint만 만들고 Private DNS Zone을 VNet에 연결하지 않으면, 서비스 FQDN이 여전히 공용 IP로 해석됩니다. AI Search, OpenAI, Storage 각각에 대해 Private DNS Zone을 생성하고 VNet에 링크해야 합니다.
AI Search Indexer와 Private Endpoint 충돌: AI Search Indexer가 Blob Storage에 접근할 때, 양쪽 모두 Private Endpoint로 설정하면 Shared Private Link를 구성해야 합니다. 이 설정을 누락하면 Indexer가 데이터 소스에 접근하지 못합니다.
Embedding 모델 불일치: 인덱싱 시 사용한 Embedding 모델과 쿼리 시 사용하는 모델이 다르면 벡터 검색 결과가 의미 없어집니다. 반드시 동일한 모델과 동일한 차원을 사용해야 합니다.
Semantic Ranker 없이 Hybrid Search만 사용하는 것: Hybrid Search는 키워드와 벡터 결과를 RRF로 병합하지만, Semantic Ranker를 추가하면 의미 기반 재정렬이 적용되어 정확도가 더 높아집니다. Standard 티어를 사용한다면 Semantic Ranker를 활성화하는 것이 합리적입니다.
Chunk 크기를 기본값으로 두는 것: 기본 Chunk 크기(1,024 토큰)가 모든 문서에 적합하지는 않습니다. 기술 문서와 정책 문서는 문서 구조가 다르므로, 문서 유형별로 Chunk 크기를 조정하는 것이 검색 품질에 영향을 줍니다.
토큰 한도를 설정하지 않는 것: Azure OpenAI에는 분당 토큰 한도(TPM)가 있습니다. 동시 사용자가 몰리면 429 에러가 발생할 수 있으므로, Retry 로직과 큐잉을 구현해야 합니다.

11. 정리

Azure OpenAI + AI Search 조합은 Azure 환경에서 사내 문서 검색 시스템을 구축할 때 데이터 주권, 인증 통합, 검색 품질 측면에서 적합한 선택지입니다.
Hybrid Search(키워드 + 벡터) + Semantic Ranker 조합은 단일 벡터 검색보다 높은 정확도를 제공하며, 특히 기술 용어와 고유명사가 많은 사내 문서에서 효과적입니다.
Integrated Vectorization으로 별도 Embedding 파이프라인 없이 인덱싱을 자동화할 수 있으며, Managed Identity로 서비스 간 인증을 키 없이 처리합니다.
Private Endpoint로 모든 서비스를 VNet 내부에서만 접근 가능하게 설정하되, Private DNS Zone 연결과 Shared Private Link 구성을 누락하지 않도록 주의합니다.
비용의 대부분은 AI Search 티어에서 결정되므로, 문서 규모와 검색 품질 요구사항에 맞는 티어를 선택하는 것이 중요합니다.

참고 문서

'AI' 카테고리의 다른 글

Vector DB 비교: Pinecone, Weaviate, pgvector, OpenSearch 선택 기준 (0)	2026.06.06
RAG Chunking 전략: 문서를 나누는 기준과 성능 영향 (0)	2026.06.06
RAG와 Fine-tuning 차이: LLM 커스터마이징 전략 선택 기준 (0)	2026.05.31
AWS Bedrock 기반 RAG 챗봇 아키텍처 설계: Knowledge Bases, Agent, 보안까지 (0)	2026.05.31
AI 애플리케이션 보안 리스크: Prompt Injection과 데이터 유출 (0)	2026.05.31