앞선 글에서는 RAG의 개념, 문서 처리 흐름, Azure AI Search의 검색 방식을 살펴봤습니다. 이제는 실제 Azure Portal과 SDK를 사용해 RAG를 구성하는 실습 흐름으로 넘어가겠습니다.
이번 글은 개념 설명보다 실습 순서가 중요합니다. Azure OpenAI 모델을 준비하고, Blob Storage에 문서를 저장하고, Azure AI Search 인덱스를 만들고, Playground와 SDK에서 RAG를 테스트한 뒤, 벡터 검색과 CSV 데이터, 콘텐츠 안전까지 이어지는 흐름을 하나씩 정리하겠습니다.
이번 글의 핵심
이번 실습은 “RAG가 무엇인가?”를 다시 설명하는 글이 아니라, Azure에서 RAG를 실제로 구성할 때 어떤 리소스를 만들고, 어떤 순서로 연결하며, 어디서 자주 막히는지를 정리하는 실습형 글입니다.
목차
1. 개요
이번 실습의 최종 목표는 내가 올린 문서를 기반으로 답변하는 RAG 챗봇을 만드는 것입니다. 사용자가 질문하면 Azure AI Search가 관련 문서를 찾고, Azure OpenAI가 그 문서를 근거로 답변을 생성하는 구조입니다.
예를 들어 여행 가이드 PDF를 업로드했다면, 사용자는 “미국 여행지를 추천해줘”라고 질문할 수 있습니다. 사내 규정 문서를 업로드했다면, “보안 문서를 다루는 팀도 재택근무가 가능한가요?”처럼 내부 문서 기반 질문도 할 수 있습니다.
RAG 실습 전체 흐름
1. Azure OpenAI 모델을 배포한다.
2. Blob Storage를 생성하고 문서를 저장한다.
3. CORS 설정을 확인한다.
4. Azure AI Search 리소스를 만든다.
5. Playground에서 파일을 업로드하고 RAG를 테스트한다.
6. 생성된 Search Index를 확인한다.
7. 기존 인덱스를 다시 연결해 사용한다.
8. SDK에서 Azure AI Search 인덱스를 데이터 원본으로 연결한다.
9. 벡터 검색 방식으로 검색 품질을 높인다.
10. CSV 공공데이터를 RAG에 활용한다.
11. 콘텐츠 안전, 개인정보, 비용을 점검한다.이번 실습은 한 번에 완성되는 구조가 아니라, Playground에서 먼저 테스트하고 → 인덱스를 확인하고 → SDK로 확장하고 → 벡터 검색과 CSV 데이터까지 확장하는 흐름으로 이해하면 됩니다.
2. 실습 준비
실습을 시작하기 전에 Azure에서 사용할 리소스를 준비해야 합니다. 이 단계에서는 Azure OpenAI 모델 배포, 엔드포인트/API 키 확인, Storage Account 생성, CORS 설정, Azure AI Search 리소스 생성을 진행합니다.
2-1. Azure OpenAI 모델 배포
Azure OpenAI에서 GPT 모델을 사용하려면 먼저 모델을 배포해야 합니다. 모델 배포는 “이 이름으로 이 GPT 모델을 호출하겠다”라고 정해두는 과정입니다.
Azure OpenAI 모델 배포 경로
Azure Portal
→ 리소스 그룹
→ Azure OpenAI 리소스 선택
→ Explore Azure AI Foundry portal
→ 모델 카탈로그
→ gpt-4o-mini 등 모델 선택
→ 배포 이름 지정
→ 배포| 확인 항목 | 설명 | 실습 팁 |
|---|---|---|
| 모델 | 답변을 생성할 GPT 모델 | 실습에서는 gpt-4o-mini처럼 비용 부담이 낮은 모델 사용 가능 |
| 배포 이름 | SDK에서 모델을 호출할 때 사용하는 이름 | 나중에 환경 변수에 그대로 넣으므로 기억하기 쉽게 지정 |
| 지역 | 리소스가 배포되는 Azure Region | Storage, AI Search와 같은 지역으로 맞추면 관리가 편함 |
| TPM 제한 | 분당 처리 가능한 토큰 제한 | 실습 규모에 맞게 너무 높게 잡지 않아도 됨 |
2-2. 엔드포인트와 API 키 확인
SDK 실습을 하려면 Azure OpenAI 엔드포인트, API 키, 모델 배포 이름이 필요합니다. 이 값들은 나중에 .env 파일에 넣어 코드에서 불러옵니다.
확인해야 할 값
AZURE_OPENAI_ENDPOINT = Azure OpenAI 엔드포인트
AZURE_OPENAI_KEY = Azure OpenAI API 키
AZURE_OPENAI_DEPLOYMENT = 배포한 모델 이름API 키는 비밀번호처럼 다뤄야 합니다. 블로그 캡처, GitHub 코드, 노션 문서에 실제 키를 그대로 올리면 안 됩니다. 실습 글에서는 반드시 예시값이나 환경 변수 형태로 표현하는 것이 안전합니다.
2-3. Storage Account 생성
Blob Storage는 RAG에 사용할 문서를 저장하는 공간입니다. PDF, TXT, CSV 파일을 올려두면 Azure AI Search가 이 파일을 읽어 인덱스를 만들 수 있습니다.
Storage Account 생성 경로
Azure Portal
→ 리소스 그룹
→ 만들기
→ 스토리지 계정 검색
→ Storage Account 선택
→ 스토리지 계정 이름 입력
→ Azure OpenAI와 동일한 지역 선택
→ 검토 + 만들기
→ 배포 완료 후 리소스로 이동| 설정 항목 | 권장 설정 | 이유 |
|---|---|---|
| 스토리지 계정 이름 | 영어 소문자와 숫자 조합 | Storage Account 이름은 전역적으로 고유해야 함 |
| 지역 | Azure OpenAI와 동일한 지역 | 리소스 관리와 지연 시간 측면에서 유리함 |
| 성능 | 표준 | 일반 실습에는 표준 계층으로 충분함 |
2-4. CORS 설정
CORS는 Cross-Origin Resource Sharing의 약자입니다. 쉽게 말하면, 다른 도메인에서 실행되는 웹 애플리케이션이 Blob Storage에 접근할 수 있도록 허용하는 설정입니다.
Playground나 웹앱에서 Blob Storage의 파일을 읽을 때 CORS 오류가 발생할 수 있습니다. 실습 중 CORS 관련 오류가 보이면 Storage Account의 리소스 공유 설정을 확인하면 됩니다.
CORS 설정 경로
Azure Portal
→ Storage Account
→ 설정
→ 리소스 공유(CORS)
→ Blob service| 항목 | 실습용 값 | 설명 |
|---|---|---|
| 허용된 원본 | * | 실습에서는 모든 출처를 임시 허용 |
| 허용된 메서드 | GET, POST, OPTIONS, PUT | 파일 조회, 업로드, 사전 요청 등에 사용 |
| 허용된 헤더 | * | 요청 헤더를 폭넓게 허용 |
| 노출된 헤더 | * | 브라우저에서 응답 헤더를 읽을 수 있게 허용 |
| 최대 기간 | 0 또는 200 | Preflight 요청 결과를 캐시하는 시간 |
실습에서는 허용된 원본에 *를 사용할 수 있지만, 실제 서비스에서는 권장되지 않습니다. 운영 환경에서는 https://myapp.com처럼 필요한 도메인만 허용해야 합니다.
2-5. Azure AI Search 리소스 생성
Azure AI Search는 RAG에서 문서를 검색하는 핵심 리소스입니다. Blob Storage에 문서를 올려두기만 하면 GPT가 바로 읽는 것이 아니라, Azure AI Search가 문서를 인덱싱해야 검색과 답변에 활용할 수 있습니다.
Azure AI Search 생성 경로
Azure Portal
→ 리소스 그룹
→ 만들기
→ Azure AI Search 검색
→ 서비스 이름 입력
→ Azure OpenAI와 동일한 지역 선택
→ 가격 계층 선택
→ 검토 + 만들기
→ 배포 완료 후 리소스로 이동| 항목 | 설명 | 실습 기준 |
|---|---|---|
| 서비스 이름 | AI Search 리소스 이름 | 식별 가능하도록 지정 |
| 지역 | 리소스가 생성될 위치 | Azure OpenAI, Storage와 동일 지역 권장 |
| 가격 계층 | Search 리소스의 성능과 비용 수준 | 실습 규모에서는 Basic 계층 사용 가능 |
3. 의미 검색 실습 - PG
이제 Playground에서 파일을 업로드하고, 의미 검색 기반 RAG를 테스트합니다. 여기서 PG는 Playground를 의미합니다. 즉, 코드를 작성하지 않고 Azure AI Foundry의 Chat Playground 화면에서 RAG를 구성해 보는 단계입니다.
이 실습의 핵심은 파일 업로드를 통해 Blob Storage와 Azure AI Search를 연결하고, 업로드한 문서가 검색과 답변에 실제로 사용되는지 확인하는 것입니다.
3-1. 데이터 원본 추가
데이터 원본 추가 흐름
Azure AI Foundry
→ Chat Playground
→ 데이터 추가
→ 데이터 원본 추가
→ 파일 업로드 선택
→ Storage Account 선택
→ Azure AI Search 리소스 선택
→ 인덱스 이름 지정
→ 파일 업로드3-2. 데이터 관리 설정
| 설정 항목 | 설명 | 실습 기준 |
|---|---|---|
| 검색 유형 | 문서 검색 방식 선택 | 의미 체계 검색 사용 |
| Chunk Size | 문서를 나누는 크기 | 기본값 1024부터 시작 |
| 인증 유형 | Search 연결 인증 방식 | API 키 사용 가능 |
| 검색된 문서 | 질문당 가져올 Top-N 문서 조각 수 | 처음에는 3~5개 정도로 테스트 |
Chunk Size는 실습에서 특히 중요합니다. 너무 크면 불필요한 내용이 함께 들어가고, 너무 작으면 답변에 필요한 문맥이 잘릴 수 있습니다. 처음에는 기본값으로 시작하고, 답변 품질을 보면서 조정하는 방식이 좋습니다.
3-3. RAG 테스트
파일 업로드와 데이터 연결이 끝났다면 질문을 입력해 답변을 확인합니다. 이때 중요한 것은 답변 내용뿐 아니라, 답변 하단에 표시되는 참조 문서입니다.
테스트 질문 예시
- 이 문서에서 중요한 내용을 요약해줘.
- 미국 여행지를 추천해줘.
- 이 문서 기준으로 가장 추천할 만한 장소는 어디야?
- 문서에서 확인할 수 없는 내용이면 어떻게 답하나요?Playground에서 답변이 이상하다면 GPT 모델보다 먼저 검색 결과와 참조 문서를 확인해야 합니다. RAG 오류의 원인은 검색 결과 부정확, 인덱싱 지연, Chunk Size 문제, CORS 설정 문제에서 시작되는 경우가 많습니다.
4. 인덱스 활용 실습 - PG
의미 검색 실습에서 파일을 업로드하면, Azure AI Search에는 자동으로 인덱스가 생성됩니다. 이번 단계에서는 이미 생성된 인덱스를 다시 활용해 RAG를 구성해 봅니다.
이 단계가 중요한 이유는 실무에서는 매번 문서를 새로 업로드하지 않기 때문입니다. 한 번 잘 만들어둔 Search Index를 여러 앱이나 여러 Playground 설정에서 재사용하는 방식이 더 일반적입니다.
4-1. 생성된 인덱스 확인( 이전 실습을 통해서 생성된 )
인덱스 확인 경로
Azure Portal
→ Azure AI Search 리소스
→ 인덱스
→ 생성된 인덱스 이름 확인Playground에서 업로드한 파일은 Azure AI Search를 통해 인덱싱됩니다. 따라서 AI Search 리소스로 이동하면 생성된 인덱스를 확인할 수 있습니다.
4-2. 기존 인덱스 연결
기존 인덱스 활용 흐름
Azure OpenAI Playground
→ 기존 데이터 원본 제거
→ 데이터 원본 추가
→ Azure AI Search 선택
→ AI Search 서비스 선택
→ 기존 인덱스 선택
→ 인증 유형 API 키 선택
→ 저장 후 닫기
→ RAG 테스트| 방식 | 특징 | 적합한 상황 |
|---|---|---|
| 파일 업로드 방식 | 문서를 새로 업로드하고 인덱스 생성 | 처음 실습할 때 |
| 기존 인덱스 재사용 | 이미 생성된 AI Search 인덱스 연결 | 반복 테스트, SDK 연결, 운영 구성 |
인덱스 활용 실습의 핵심은 “문서를 다시 올리지 않아도 된다”는 점입니다.
한 번 생성된 Search Index는 RAG 시스템의 검색 기반으로 계속 재사용할 수 있습니다.
5. 인덱스 활용 실습 - SDK
Playground는 RAG를 빠르게 테스트하기에 좋지만, 실제 서비스에서는 SDK로 구현해야 합니다. SDK 실습의 목표는 Azure AI Search 인덱스를 데이터 원본으로 연결하고, Azure OpenAI 호출 시 그 인덱스를 함께 사용하는 것입니다.
5-1. SDK 실습 준비
1. 실습용 레포 URL : GitHub - parveenkrraina/mslearn-openai · GitHub
GitHub - parveenkrraina/mslearn-openai
Contribute to parveenkrraina/mslearn-openai development by creating an account on GitHub.
github.com
2. 해당 레포에서 Labfile의 6번째 폴더 들어가기
3. 가져온 다음 터미널에서 가상환경 설정하기
4. python-dotenv 패키지 설치
5. openai 패키지 설치
6. .env 파일 작성
7. 파일 실행
5-2. .env 환경 변수 설정
SDK 코드에서 매번 키와 엔드포인트를 직접 작성하면 보안상 위험합니다. 그래서 보통 .env 파일에 환경 변수를 저장하고, 코드에서는 그 값을 불러와 사용합니다.
환경 변수 예시
AZURE_OPENAI_ENDPOINT=https://your-openai-resource.openai.azure.com/
AZURE_OPENAI_KEY=your-openai-api-key
AZURE_OPENAI_DEPLOYMENT=gpt-4o-mini
AZURE_SEARCH_ENDPOINT=https://your-search-service.search.windows.net
AZURE_SEARCH_KEY=your-search-api-key
AZURE_SEARCH_INDEX=your-index-name.env 파일에는 실제 API 키가 들어갈 수 있습니다. 따라서 GitHub에 올리면 안 되고, 반드시 .gitignore에 포함해야 합니다.
5-3. SDK에서 인덱스를 데이터 원본으로 연결
SDK를 활용한 RAG에서는 Azure AI Search 인덱스 정보를 호출 Body에 포함해야 합니다. 즉, “이 질문에 답할 때 이 Search Index를 참고해라”라고 Azure OpenAI 요청에 함께 전달하는 구조입니다.
위 코드에서 핵심은 extra_body입니다. 이 부분에 Azure AI Search 인덱스 정보를 넣어야 Azure OpenAI가 해당 인덱스를 참고하여 답변할 수 있습니다.
5-4. 출처 표시 확인
RAG 답변에서는 출처 표시가 중요합니다. 사용자는 AI 답변이 어떤 문서를 근거로 만들어졌는지 확인할 수 있어야 합니다.
출처 포함 답변 예시
결론:
미국 여행지로는 뉴욕, 샌프란시스코, 그랜드캐니언을 추천할 수 있습니다.
근거:
업로드된 여행 가이드 문서에서 각 지역의 주요 관광지와 추천 일정이 설명되어 있습니다.
참고 문서:
- usa-travel-guide.pdf
- national-parks-guide.pdf6. 벡터 검색 활용 실습
이번 단계에서는 벡터 검색을 활용합니다. 의미 검색이 검색 결과를 의미적으로 재정렬하는 방식에 가깝다면, 벡터 검색은 문서와 질문을 임베딩 벡터로 바꾼 뒤 의미적으로 가까운 문서 조각을 직접 찾는 방식입니다.
벡터 검색을 사용하면 사용자가 문서에 있는 표현을 정확히 모르더라도 비슷한 의미의 문서를 찾을 수 있습니다. 예를 들어 사용자가 “집에서 일하는 기준”이라고 물어도, 문서의 “재택근무 신청 조건”과 연결될 수 있습니다.
벡터 검색 흐름
1. 문서 조각을 임베딩 모델로 벡터화한다.
2. 사용자의 질문도 임베딩한다.
3. 질문 벡터와 문서 벡터의 유사도를 계산한다.
4. 가장 가까운 문서 조각을 검색한다.
5. 검색된 문서 조각을 GPT 프롬프트에 넣는다.
6. GPT가 근거 기반 답변을 생성한다.| 검색 방식 | 기준 | 적합한 상황 |
|---|---|---|
| Keyword Search | 단어 일치 | 제품명, 문서번호, 코드 검색 |
| Semantic Search | 검색 결과의 의미적 재정렬 | 텍스트 검색 결과 품질 개선 |
| Vector Search | 임베딩 벡터 유사도 | 표현이 달라도 의미가 비슷한 문서 검색 |
벡터 검색 실습의 핵심은 “문장 표현이 달라도 의미가 가까우면 찾을 수 있다”는 점을 확인하는 것입니다. RAG 챗봇에서는 사용자가 문서의 정확한 표현을 모르기 때문에 벡터 검색이 특히 중요합니다.
7. 콘텐츠 안전
RAG는 내부 문서와 외부 데이터를 연결하기 때문에 콘텐츠 안전을 반드시 고려해야 합니다. 특히 기업 문서, 고객 데이터, 공공데이터를 사용할 때는 개인정보나 민감정보가 섞일 수 있습니다.
| 위험 요소 | 설명 | 대응 방법 |
|---|---|---|
| 개인정보 | 이름, 전화번호, 이메일, 주소 등 | 마스킹, 비식별화, 접근 권한 제한 |
| 민감정보 | 건강, 금융, 인사평가, 징계 정보 등 | 권한 기반 필터링과 출력 제한 |
| 유해 콘텐츠 | 폭력, 혐오, 자해, 성적 콘텐츠 등 | Content Safety 필터 적용 |
| 프롬프트 인젝션 | 문서나 사용자 입력이 시스템 지시를 우회하려는 공격 | 시스템 메시지 강화, 문서와 명령 분리 |
| 권한 문제 | 사용자가 보면 안 되는 문서가 검색될 위험 | 사용자별 필터와 문서 등급 관리 |
개인정보 마스킹 예시
원본:
홍길동 / 010-1234-5678 / 서울시 ○○구 ○○로
마스킹 후:
홍○○ / 010-****-5678 / 서울시 ○○구RAG는 내부 문서를 활용할 수 있다는 장점이 있지만, 그만큼 정보 유출 위험도 생깁니다. 문서를 인덱싱하기 전에 개인정보, 민감정보, 접근 권한을 반드시 점검해야 합니다.
8. RAG 평가와 비용 최적화
RAG는 구현했다고 끝나는 것이 아닙니다. 실제 서비스에서는 검색 결과가 맞는지, 답변이 근거와 일치하는지, 비용이 과도하게 발생하지 않는지 계속 평가해야 합니다.
| 평가 항목 | 확인 질문 | 개선 방법 |
|---|---|---|
| 검색 정확도 | 질문과 관련된 문서가 검색되는가? | 검색 방식, Chunk Size, 필터 조정 |
| 근거 적합성 | 검색된 문서가 답변 근거로 충분한가? | Top-N, Reranking, Metadata 개선 |
| 답변 정확성 | 답변이 문서 내용과 일치하는가? | 시스템 메시지와 답변 형식 개선 |
| 출처 표시 | 참고한 문서가 표시되는가? | 파일명, 페이지, URL 필드 관리 |
| 비용 | 검색, 임베딩, 토큰 비용이 과도하지 않은가? | Top-N 조정, Chunk 최적화, 응답 길이 제한 |
RAG 비용 최적화의 핵심은 필요한 문서를 정확히 찾아서, 필요한 만큼만 LLM에게 전달하는 것입니다. 검색 결과를 많이 넣는다고 항상 답변이 좋아지는 것은 아닙니다.
9. 정리
Azure OpenAI로 RAG를 구현한다는 것은 GPT 모델 하나를 사용하는 일이 아닙니다. 문서를 저장하는 Blob Storage, 문서를 검색하는 Azure AI Search, 답변을 생성하는 Azure OpenAI가 서로 연결되어야 합니다.
이번 실습에서 가장 중요한 흐름은 세 가지입니다. 첫째, 실습에 필요한 리소스를 준비합니다. 둘째, Playground에서 파일 업로드와 인덱스 활용을 통해 RAG를 테스트합니다. 셋째, SDK와 벡터 검색, CSV 데이터, 콘텐츠 안전까지 확장해 실제 서비스에 가까운 구조로 발전시킵니다.
10. 전체 흐름 한 번에 정리
- 개요: RAG 실습의 전체 목적과 구조를 이해한다.
- 실습 준비: Azure OpenAI 모델, Storage Account, CORS, Azure AI Search를 준비한다.
- 의미 검색 실습 - PG: Playground에서 파일을 업로드하고 의미 검색 기반 RAG를 테스트한다.
- 인덱스 활용 실습 - PG: 생성된 Azure AI Search 인덱스를 다시 연결해 사용한다.
- 인덱스 활용 실습 - SDK: 코드에서 Azure AI Search 인덱스를 데이터 원본으로 연결한다.
- 벡터 검색 활용 실습: 임베딩과 벡터 유사도 기반으로 관련 문서를 검색한다.
- 공공데이터 CSV 실습: 행과 열 기반 데이터를 검색과 답변에 활용한다.
- 콘텐츠 안전: 개인정보, 민감정보, 유해 콘텐츠, 권한 문제를 점검한다.
- 평가와 비용 최적화: 검색 정확도, 답변 품질, 비용 구조를 개선한다.
11. 핵심 키워드 정리
| 키워드 | 의미 |
|---|---|
| Azure Blob Storage | RAG에 사용할 PDF, TXT, CSV 파일을 저장하는 공간 |
| CORS | 다른 도메인의 웹앱이 Blob Storage에 접근할 수 있도록 허용하는 설정 |
| Azure AI Search | 문서를 인덱싱하고 질문과 관련된 문서를 검색하는 서비스 |
| Search Index | 문서 조각과 메타데이터를 검색 가능한 형태로 저장한 구조 |
| Playground RAG | 코드 없이 Azure OpenAI와 데이터 원본을 연결해 테스트하는 방식 |
| SDK RAG | 애플리케이션 코드에서 Azure AI Search와 Azure OpenAI를 연결하는 구현 방식 |
| Vector Search | 임베딩 벡터의 유사도를 이용해 의미가 가까운 문서를 찾는 검색 방식 |
| CSV RAG | 행과 열로 구성된 CSV 데이터를 검색과 답변에 활용하는 방식 |
| Content Safety | 유해 콘텐츠, 개인정보, 민감정보, 권한 문제를 관리하는 안전 장치 |
| Cost Optimization | 검색, 임베딩, 토큰, 스토리지 비용을 효율적으로 관리하는 작업 |
다음 글 예고
다음 글에서는 RAG에서 한 단계 더 나아가 AI Agent 개념을 살펴보겠습니다. 단순히 문서를 검색해 답변하는 챗봇과, 목표를 달성하기 위해 도구를 사용하고 행동하는 Agent가 무엇이 다른지 정리해 보겠습니다.
