RAG, 들어는 봤는데… 내 서비스엔 어떻게 쓰지?

개요

RAG(Retrieval-Augmented Generation, 검색 증강 생성)은 LLM이 학습하지 못한 정보를 외부에서 검색하여 활용할 수 있게 하는 기술입니다. 이 글에서는 RAG이 왜 필요한지부터, 교육 운영 시스템에 실제로 적용하며 겪은 시행착오(MCP 활용 → RAG 서버 직접 구현)와 그 과정에서 정리한 6단계 구현 가이드(필요성 평가 → 요구사항 분석 → 프레임워크 결정 → 색인 → 생성 → 평가)를 다룹니다.

RAG을 처음 접하는 분이라면 개념부터 구현까지의 전체 흐름을, 이미 익숙한 분이라면 각 단계별 핵심 질문과 유의사항을 참고하실 수 있습니다.

이 글은 2025년 10월 WOOWACON 2025에서 "RAG, 들어는 봤는데… 내 서비스엔 어떻게 쓰지?"라는 주제로 진행한 발표를 기반으로, 블로그에 맞게 재구성하고 보충 설명을 추가한 글입니다.

본문에 앞서, RAG의 발음 이야기를 잠깐 하겠습니다. WOOWACON 2025 발표 당시 "랙 발표한다"고 했더니 컴퓨터 랙(Lag) 걸린 걸로 발표까지 하냐는 반응이 돌아왔는데요. 사실 RAG과 Lag은 영어 발음이 각각 /ræɡ/, /læɡ/로, 한글로 옮기면 둘 다 ‘래그’가 맞습니다. 다만 Lag은 ‘렉’, ‘랙’ 등으로 이미 널리 쓰이고 있어 혼동이 생기곤 합니다. 이 글에서 RAG을 읽으실 때는 ‘랙’으로 읽어주시면 됩니다.

왜 RAG이 필요한가?

RAG에 대해 이야기하기 전에, LLM을 사용하면서 한 번쯤 겪어봤을 불편함부터 짚어보겠습니다.

LLM에게 질문을 던지면 어떤 때는 정확한 답변이 돌아오지만, 어떤 때는 "응답이 불가합니다"라거나 사실이 아닌 내용을 그럴듯하게 답변하는 환각(Hallucination) 현상이 발생합니다.

이런 일이 발생하는 이유는 간단합니다. LLM은 인터넷에 공개된 데이터뿐만 아니라, 해당 LLM 제공업체만이 가진 독점적/고유한 데이터, 즉 학습 데이터로만 학습했기 때문입니다. 학습 데이터에 없는 정보는 알 수 없는 것이죠.

LLM의 한계를 넘는 방법

예를 들어 "이번 주 미팅 일정은?"이라고 질문한다고 해보죠. LLM의 학습 데이터에는 우리의 미팅 일정이 없으니 정상적인 응답을 받을 수 없습니다.

하지만 캘린더 파일을 질문과 함께 전달하면 이야기가 달라집니다. LLM이 캘린더 파일의 내용을 이해하고, 질문과 관련된 정확한 답변을 생성할 수 있게 됩니다. 즉, 질문과 관련된 컨텍스트(Context)를 함께 전달하면 LLM은 훨씬 정확하게 답변할 수 있습니다.

컨텍스트를 매번 보내야 한다면?

그런데 만약 아래와 같은 질문들을 자주 해야 한다면 어떨까요?

• "이번 주 미팅 일정은?"
• "기획서 내용을 요약해줘."
• "이 데이터가 존재하는지 확인해줘."

각각의 요청마다 관련 컨텍스트를 항상 함께 보내줘야 합니다. 이를 ‘쿼리-컨텍스트 결합도가 증가했다’라고 표현할 수 있는데, 이는 쿼리를 준비할 때마다 적절한 컨텍스트도 함께 준비해야 한다는 부담을 의미합니다.

더 큰 문제는, "이번 주 미팅 일정은?"이라고 물었는데 엉뚱한 파일 시스템 정보를 컨텍스트로 보내버리면 LLM이 질문과 컨텍스트를 제대로 이해하지 못해 잘못된 응답을 생성한다는 점입니다.

RAG이란 무엇인가?

바로 이 문제들을 해결하는 것이 RAG입니다.

RAG은 사용자가 "이번 주 미팅 일정은?"이라고 쿼리를 보내면, 저장소에서 관련 컨텍스트를 자동으로 검색합니다. 이 컨텍스트를 사용자 쿼리와 함께 LLM에 전달하여 정확한 응답을 생성합니다.

RAG의 정의: LLM이 새로운 정보를 검색하고 통합할 수 있도록 하는 기술

• 새로운 정보 검색의 이유: 학습 데이터에 없는 최신 정보나 전문 지식이 필요하기 때문
• 통합이 필요한 이유: 질문에 맞는 컨텍스트를 자동으로 찾아서 LLM에게 전달하기 위해

쉽게 얘기하면, RAG은 범용 LLM을 나만의 전문 LLM으로 만드는 기술입니다.

RAG의 3가지 파이프라인

RAG은 크게 세 가지 파이프라인으로 구성됩니다.

앞서 본 캘린더 예시에서, 캘린더 파일을 불러오고 저장하는 것이 색인, 질문에 맞는 일정을 찾아 답변을 생성하는 것이 생성, 생성된 답변이 실제 일정과 정확히 일치하는지 검증하는 것이 평가에 해당합니다.

지금은 RAG의 전체 흐름만 이해하시면 됩니다. 각 파이프라인(색인, 생성, 평가)의 설명은 아래 개발 단계에서 단계별로 상세히 다룰 예정입니다.

RAG 이전에는 LLM이 학습된 정보만 알고 있어 최신 정보나 특정 도메인 지식에 대한 질문에 답변할 수 없었습니다.
RAG 이후에는 외부 데이터베이스에서 관련 정보를 검색해 활용하므로, 학습되지 않은 정보도 정확하게 답변할 수 있게 되었습니다.

교육 운영 RAG 구현 사례

교육 운영 환경에서 분산된 데이터를 하나의 자연어 검색 시스템으로 통합하기 위해, RAG을 어떻게 설계하고 적용했는지를 소개합니다. MCP를 활용한 초기 시도부터 RAG 서버를 직접 구축하기까지의 과정을 다룹니다.

문제 상황

테크교육개발팀에서는 교육 과정을 운영하기 위해 여러 시스템에 데이터를 분산 관리하고 있었습니다.

• 데이터베이스: 교육생 정보, 교육 자료
• Google 드라이브: 부가 교육 자료
• Google 캘린더: 교육 일정

문제는 교육 정보를 파악하기 위해 여러 시스템을 매번 개별적으로 확인해야 했다는 점입니다. 예를 들어 "이번 주 수요일 교육 자료가 어디 있지?"를 찾으려면 데이터베이스, Google 드라이브, Google 캘린더를 모두 뒤져야 했고, 각 정보 간의 연관성도 사용자가 직접 파악해야 했습니다.

그래서 ‘교육 운영 정보를 자연어로 검색할 수 있는 시스템을 구축하자’는 목표를 세웠습니다.

1차 시도: MCP 활용

첫 번째로 MCP(Model Context Protocol)를 시도했습니다. MCP는 LLM이 외부 데이터 소스에 접근할 수 있도록 표준화된 프로토콜로, LLM에 요청하면 프로토콜을 통해 외부 데이터를 자동으로 가져옵니다.

하지만 환경 제약과 LLM 자체의 한계 양쪽에서 문제가 발생했습니다.

• 모든 사용자가 MCP를 지원하는 LLM을 사용해야 함
• MCP 서버가 로컬에서 실행되어 격리된 환경(VPC 내 DB 등)에 접근 불가
• MCP와 LLM의 연동이 불안정하여, 때로는 되고 때로는 안 되는 현상 발생
• LLM이 데이터를 찾지 못하면 계속 검색하여 Context window 초과 문제 발생

2차 시도: MCP 직접 구현

두 번째로는 MCP 서버를 직접 구현하여 도커 레지스트리에 등록하고, 데이터를 가져올 때 청킹(Chunking)으로 페이지 단위로 잘라서 가져오게 했습니다.

하지만 근본적인 문제는 해결되지 않았습니다. 여전히 MCP 지원 LLM이 필요했고, 사용자 로컬에서 실행되는 구조적 한계로 격리 환경 접근이 불가능했습니다. Context window 문제도 여전했고, 페이징으로 여러 데이터를 조회하다 보니 지연(Lag) 문제까지 추가로 발생했습니다.

3차 시도: RAG 서버 구현

이러한 불편함을 해소하기 위해 최종적으로 RAG 서버를 직접 구현했습니다. 사용자는 브라우저에서 질문만 남기면 정보를 받을 수 있게 되었습니다.

핵심 설계 포인트는 다음과 같습니다.

• 데이터베이스와 동일한 VPC 환경에 구축하여 격리된 리소스에 접근 가능
• 앞서 소개한 색인, 생성, 평가 파이프라인으로 구현
• 사내 구성원 전용으로, VPN 내에서만 접근 가능한 웹 UI 제공

기존에는 사용자가 직접 각각의 데이터 소스를 방문해야 했지만, RAG 구축 이후 브라우저에서 자연어 검색만 하면 데이터 소스에서 자동으로 정보를 찾아 반환하게 되었습니다.

여러 시도를 거치면서 얻은 교훈은 하나였습니다. 처음부터 완벽한 시스템을 만들려 하기보다, 빠르게 전체 프로세스를 검증하고 점진적으로 개선하는 것이 훨씬 효과적이라는 것이었죠. ‘완벽함보다 빠른 검증’이라는 원칙을 바탕으로 RAG을 구축하며 정리한 6단계를 공유합니다.

개발 단계별 구현 가이드

RAG을 구축하기 위한 단계는 크게 여섯 가지입니다.

1. 사용 사례 식별 및 RAG 필요성 평가
2. 요구사항 수집 및 분석
3. RAG 프레임워크 결정
4. 색인 파이프라인 구현
5. 생성 파이프라인 구현
6. 평가 파이프라인 구현

각 단계별로 던져야 할 핵심 질문과 유의사항을 중심으로 살펴보겠습니다.

1단계. 사용 사례 식별 및 RAG 필요성 평가

RAG을 만들고 싶은 들뜬 마음을 잠깐 내려놓고, 먼저 ‘우리 서비스에 RAG이 정말 필요할까?’를 판단합니다.

아래 네 가지 질문이 그 판단 기준이 됩니다.

유의사항: RAG을 검토하기에 앞서, 단순히 프롬프트 엔지니어링으로 해결 가능한지, 혹은 LLM에 컨텍스트를 직접 전달하는 것만으로 충분한지를 먼저 확인해야 합니다. 쿼리-컨텍스트 결합도가 감당하기 어려울 정도로 높아지는 시점에 RAG 도입을 결정해도 늦지 않습니다.

일반적으로 RAG이 필요한 경우

• 정보가 실시간으로 업데이트되는 경우
• 도메인에 특화된 내부 지식이 필요한 경우

RAG이 불필요한 경우

• 간단한 텍스트 처리
• 정적이고 변하지 않는 데이터
• 일반적인 대화

RAG이 필요하다고 판단됐다면, 다음 단계로 넘어갈 준비가 된 것입니다.

2단계. 요구사항 수집 및 분석

‘무엇을 만들 것인가’보다 ‘사용자의 불편함을 어떻게 해결할 것인가’를 구체화하는 단계입니다.

비즈니스 목표부터 비기능 요구사항까지, 네 가지 관점에서 수집합니다.

유의사항: 기능 나열에 그치지 말고, 사용자의 불편함과 해결하고자 하는 문제에 집중해야 합니다. 그리고 ‘5분에서 30초’, ‘90% 쿼리 3초 이내’처럼 구체적인 수치로 목표를 표현해야 프로젝트 완료 시점을 판단할 수 있습니다.

3단계. RAG 프레임워크 결정

RAG 구현에 어떤 프레임워크를 사용할지 결정하는 단계입니다. 크게 Spring AI와 LangChain을 비교할 수 있으며, 어떤 것이 적합한지는 팀과 개인의 기술 스택에 따라 달라집니다.

유의사항: 프레임워크의 기술적 장점보다 팀이 익숙한 환경이 생산성에 더 큰 영향을 미칩니다. 혼자 개발하더라도 피드백이나 코드 리뷰를 받으려면 팀 전체가 이해할 수 있는 기술을 선택하는 것이 좋습니다. 모든 항목에서 완벽한 선택지는 없으므로, 우리 상황에서 중요한 것의 우선순위를 설정해야 합니다.

4단계. 색인 파이프라인 구현

앞서 RAG의 세 가지 파이프라인 중 첫 번째로 소개한 색인 파이프라인입니다.
문서를 검색 가능한 형태로 준비하고 저장하는 과정으로, 로딩, 청킹, 임베딩, 저장(저장소)의 네 가지 핵심 요소로 구성됩니다.

위 그림에서 Source는 로딩 전 원본 데이터 소스를, Knowledge Base는 저장소를 의미합니다. 즉, 데이터 소스(Source)가 로딩 → 청킹 → 임베딩을 거쳐 저장소(Knowledge Base)에 색인되는 흐름입니다.

4-1. 로딩(Loading): 데이터 소스 연결과 수집

로딩은 어떤 데이터를 가져올지, 어떤 형태로 수집할지를 결정하는 요소입니다.
앞서 본 캘린더 예시에서 캘린더 파일을 불러왔던 바로 그 과정입니다. 단순히 데이터를 읽어오는 것을 넘어, DB·드라이브·캘린더처럼 형식이 제각각인 데이터 소스들을 일관된 형태로 수집하는 것이 핵심입니다. 색인 파이프라인의 시작점인 만큼, 이 단계에서 놓친 데이터는 이후 어떤 과정을 거쳐도 검색할 수 없습니다.

유의사항

• 텍스트 데이터부터 먼저 시작하세요. 이미지, 음성, 동영상이 추가되면 이후 모든 과정이 변경되어야 합니다.
• API의 호출 제한(Rate Limit)을 항상 확인하세요. 호출 제한으로 인한 실패가 생각보다 자주 발생합니다. 가져올 데이터의 양을 미리 설정하는 것도 좋습니다.

4-2. 청킹(Chunking): 검색 가능한 단위로 분할

청킹은 로딩 단계에서 불러온 데이터를 검색 가능한 단위로 분할하는 요소입니다.
캘린더 API의 반환값을 그대로 쓰는 것이 아니라, 의미 있는 조각으로 잘라내는 과정입니다. 청크의 크기와 분할 방식은 이후 임베딩과 검색 품질에 직접적인 영향을 미치기 때문에, RAG 전체 성능에서 가장 많은 튜닝이 필요한 단계이기도 합니다.

고정 크기 청킹(Fixed-size Chunking): 미리 결정된 크기로 데이터를 자르는 방식
부모-자식 구조(Parent-Child Structure): 부모 청크가 전반적인 요약을, 자식 청크가 세부 사항을 포함하도록 구성하는 방식.

유의사항

• 청크 크기 최적화가 핵심입니다. 너무 작으면 맥락 파악이 어렵고, 너무 크면 Context window를 금방 소비하거나 성능이나 속도가 저하됩니다.
• 데이터 분할 시 의미 손실이 쉽게 발생하므로, 이를 어떻게 보완할지 고려해야 합니다.
• 메타데이터는 필수입니다. 때로는 상세한 내용보다 ‘어떤 데이터인지’, ‘어디서 나왔는지’가 검색에 더 중요할 수 있습니다.

4-3. 임베딩(Embedding): 숫자 벡터로 변환

임베딩은 청킹된 데이터를 N차원 벡터, 즉 숫자로 변환하는 요소입니다. 컴퓨터가 텍스트의 의미를 수치적으로 이해할 수 있도록 만드는 과정이라고 볼 수 있습니다.

캘린더 예시에서 "10월 29일 수요일 오후 3시 주간보고 미팅"은 [-0.0412, 0.1523, -0.0891, ...]처럼 숫자 배열로 변환됩니다. 이 변환 덕분에 사용자의 질문과 수치적으로 얼마나 가까운지를 계산할 수 있게 되고, 이것이 의미 기반 검색의 토대가 됩니다.

멀티모달(Multimodal): 텍스트, 이미지, 오디오 등 여러 형식을 함께 처리하는 것
파운데이션 모델(Foundation Model): 대규모 데이터로 사전 학습된 범용 모델. 어디에서든 평균 이상의 성능을 내는 기본 모델

유의사항

• 임베딩 모델은 파운데이션 모델로 먼저 검증해야 합니다. 로딩이나 청킹이 제대로 작동하는지 검증되지 않은 상태에서 파인튜닝 모델을 쓰면 배보다 배꼽이 커질 수 있습니다.
• 차원 수는 높을수록 정확도가 높아지지만, 비용도 함께 증가합니다.
• 도메인 특성에 따라 파인튜닝 필요성을 나중에 검토할 수 있습니다.

4-4. 저장소(Storage): 벡터 데이터 저장과 검색

저장소는 임베딩 단계에서 변환된 벡터 데이터를 보관하고, 사용자 질문이 들어왔을 때 가장 유사한 데이터를 빠르게 찾아주는 요소입니다.

캘린더 예시에서 숫자로 변환된 일정 정보들이 실제로 저장되는 곳이자, "이번 주 미팅 일정은?"이라는 질문이 들어왔을 때 관련성 높은 일정을 꺼내오는 역할을 합니다. 단순한 저장소가 아니라, 벡터 유사도 기반 검색을 수행할 수 있어야 한다는 점에서 일반 데이터베이스와는 다릅니다.

교육 운영 RAG에서는 사내에서 이미 운영 중이던 Redis 인프라를 활용할 수 있어, 별도의 벡터 전용 데이터베이스를 도입하지 않고 Redis Vector Store를 선택했습니다. Redis는 인메모리 아키텍처 기반으로 디스크 I/O 없이 벡터 검색을 수행하기 때문에, pgvector 같은 디스크 기반 저장소보다 검색 지연이 낮다는 점도 선택에 영향을 주었습니다. 또한 교육 데이터는 업데이트 시 기존 데이터를 삭제한 뒤 새로 적재하는 방식을 채택했는데, 인메모리 특성 덕분에 이 과정이 빠르게 이루어집니다.

유의사항

• 관리형(Managed) vs 자체 호스팅(Self-hosted) 결정이 필요합니다. 확장성과 비용을 고려할 때, 도커 등으로 먼저 테스트하는 것을 추천합니다.
• 데이터 삭제 기준 설정이 필수입니다. 삭제 기준이 없으면 오래된 데이터까지 모두 검색 대상이 되어 성능이 떨어집니다. 교육 운영 RAG에서는 업데이트 시 기존 데이터를 전체 삭제 후 재적재하는 방식으로 항상 최신 상태를 유지합니다.

5단계. 생성 파이프라인 구현

RAG의 세 가지 파이프라인 중 두 번째로 소개한 생성 파이프라인입니다.
질문에 맞는 정보를 검색하고 답변을 생성하는 과정으로, 검색 → 증강 → 생성의 세 단계로 구성됩니다.

5-1. 검색(Retrieval): 관련성 높은 청크 추출

검색은 색인 파이프라인에서 저장된 벡터 데이터를 바탕으로, 사용자 질문과 가장 의미적으로 유사한 청크를 찾아오는 요소입니다.
캘린더 예시에서 "이번 주 미팅 일정은?"이라는 질문이 들어오면, 질문 역시 벡터로 변환한 뒤 저장소에서 가장 가까운 일정 데이터를 골라오는 바로 그 과정입니다. 키워드를 단순히 매칭하는 것이 아니라 의미적 유사도를 기준으로 검색한다는 점에서 일반 키워드 검색과 다릅니다.

문맥적 임베딩(Contextual Embedding): 단어의 주변 문맥을 반영하여 벡터로 변환하는 방식. 예를 들어 ‘애플’이 IT 관련 문서에 등장하면 과일이 아닌 회사 Apple의 의미로 임베딩되어, 관련 문서를 더 정확하게 검색
사용자 질문 최적화(Query Optimization): 사용자의 원문을 그대로 쓰지 않고, LLM에게 핵심 정보만 남기도록 요청하여 검색 쿼리를 정제하는 것

검색 전략에는 여러 대안이 있습니다. 일반 벡터 임베딩은 문맥 없이 단어의 평균적 의미만으로 검색하고, 키워드 기반 검색(BM25 등)은 정확한 단어 매칭에 강하며, 하이브리드 검색은 벡터와 키워드를 결합합니다. 교육 운영 RAG에서 문맥적 임베딩을 선택한 이유는, 교육 데이터 특성상 같은 단어라도 맥락에 따라 의미가 달라지는 경우가 많았기 때문입니다. 일반 벡터 임베딩으로는 이런 구분이 어려웠고, 문맥적 임베딩 적용 후 관련성 높은 청크가 검색되는 비율이 개선되었습니다.

유의사항

• 메타데이터 필터링으로 검색 효율성을 향상시키세요. 데이터의 ‘제목’ 등을 필드로 저장해두면 검색이 훨씬 쉬워집니다.
• 검색할 청크의 개수를 제한해야 합니다. 100~200개씩 가져오면 LLM Context window 초과 문제가 발생합니다.
• 유사도 기준 설정에 주의하세요. 너무 낮으면 관련 없는 결과가 포함되고, 너무 높으면 검색 결과가 나오지 않습니다.
• 검색된 데이터의 정밀도는 평가 단계에서 반드시 검토해야 합니다.

5-2. 증강(Augmentation): 프롬프트 구성

증강(Augmentation)이란 기존의 것을 보완하거나 확장하여 기능을 강화한다는 뜻입니다. RAG에서는 LLM의 입력에 외부 지식을 추가하여 응답의 정확성을 높이는 과정을 의미합니다.

증강은 검색 단계에서 찾아온 청크를 사용자 질문과 결합하여, LLM이 올바른 답변을 생성할 수 있도록 프롬프트를 구성하는 요소입니다.
캘린더 예시에서 검색된 일정 데이터를 그대로 LLM에게 전달하는 것이 아니라, "너는 교육 운영 데이터를 검색해주는 서비스야"처럼 역할을 정의하고, 검색된 컨텍스트와 사용자 질문을 일정한 형식으로 엮어 전달하는 과정입니다. 단순히 데이터를 붙여넣는 것이 아니라, LLM이 정확하게 답변할 수 있도록 틀을 만들어주는 것이 핵심입니다.

유의사항

• 처음에는 검색된 청크의 원본을 유지하면서 검증하세요. 청크를 수정하려다 예상치 못한 결과가 나올 수 있습니다.
• 명확한 프롬프트 지시로 환각을 방지해야 합니다. "검색된 내용에서만 답변해", "추론 과정과 답변 형식을 꼭 지켜줘"처럼 강력하게 요구하는 것이 효과적입니다.
• 프롬프트 간결화도 중요합니다. 프롬프트 자체도 Context window에 포함되기 때문입니다.

5-3. 생성(Generation): 최종 답변 생성

생성은 증강 단계에서 구성된 프롬프트를 LLM에게 전달하여, 사용자에게 돌려줄 최종 답변을 만들어내는 요소입니다.
캘린더 예시에서 검색된 일정 데이터를 단순히 나열하는 것이 아니라, "이번 주 미팅은 수요일 오후 3시, 금요일 오전 10시 2건입니다."처럼 사용자의 질문에 맞는 자연스러운 문장으로 종합해 돌려주는 바로 그 과정입니다. RAG 파이프라인의 마지막 단계인 만큼, 앞선 색인과 검색·증강의 품질이 이 최종 답변의 품질을 결정합니다.

유의사항

• 파운데이션 모델로 먼저 검증하세요. 색인, 검색, 증강이 제대로 작동하는지 확인이 우선입니다.
• 모델 크기를 상황에 맞게 선택하세요. 작은 작업에 큰 모델을 쓰면 속도와 비용 문제가, 큰 데이터에 작은 모델을 쓰면 답변 불가 상황이 발생합니다.
• 성능과 속도 사이의 트레이드오프를 고려해야 합니다.

6단계. 평가 파이프라인 구현

RAG의 세 가지 파이프라인 중 마지막으로 소개한 평가 파이프라인입니다.
색인과 생성 파이프라인을 구축했다고 해서 RAG이 완성된 것은 아닙니다. 얼마나 잘 동작하는지를 측정하고 개선하는 것이 평가 파이프라인의 역할이며, 컨텍스트 관련성, 답변 충실성, 답변 관련성의 세 가지 핵심 지표를 기준으로 시스템을 평가합니다.

6-1. 컨텍스트 관련성(Contextual Relevance)

Context 관련성은 검색 직후, 저장소에서 가져온 청크들이 사용자 쿼리와 얼마나 관련 있는지를 측정하는 지표입니다. 검색이 아무리 빠르게 동작해도 가져온 컨텍스트가 질문과 관계없다면 이후 생성 단계에서 올바른 답변을 만들어낼 수 없습니다.
이 지표가 낮다면 검색 전략이나 임베딩 방식을 재검토해야 한다는 신호입니다.

예시 – 쿼리: "이번 주 미팅 일정이 언제야?"

검색된 컨텍스트를 문장 단위로 나누고, LLM이 각 문장이 질문에 답하는 데 실제로 필요한지를 판단합니다. ‘필요한 문장 수/전체 문장 수’가 점수가 되므로, 관련 없는 문장이 많이 포함될수록 점수가 낮아집니다.

6-2. 답변 충실성(Answer Faithfulness)

답변 충실성은 생성 직후, LLM이 생성한 답변이 검색된 컨텍스트에만 근거하는지, 즉 환각(Hallucination)이 발생하지 않았는지를 측정하는 지표입니다.
컨텍스트에 없는 정보를 그럴듯하게 덧붙이는 것이 LLM의 특성인 만큼, 이 지표는 RAG 시스템의 신뢰성을 판단하는 핵심 기준이 됩니다.
이 지표가 낮다면 증강 단계의 프롬프트 설계를 재검토해야 한다는 신호입니다. 검색된 내용에서만 답변하도록 LLM에게 더 명확하게 지시해야 합니다.

예시 – 컨텍스트: "주간보고 미팅이 10월 29일 수요일 오후 3시에 있다"

생성된 답변을 개별 주장(claim)들로 분해한 뒤, LLM이 각 주장이 컨텍스트에 의해 뒷받침되는지를 하나씩 확인합니다. ‘뒷받침되는 주장 수/전체 주장 수’가 점수가 되므로, 컨텍스트에 없는 내용이 많을수록 점수가 낮아집니다.

6-3. 답변 관련성(Answer Relevance)

답변 관련성은 생성 직후, 생성된 최종 답변이 사용자의 원래 질문에 얼마나 직접적으로 응답하는지를 측정하는 지표입니다.
Context 관련성이 ‘검색이 올바른 정보를 가져왔는가’를 측정한다면, 답변 관련성은 ‘그 정보로 실제로 질문에 답했는가’를 측정합니다. 쿼리를 올바르게 이해했는지, 응답이 질문에 적절한지, 응답이 충분히 완전한지를 핵심 기준으로 삼습니다. 한 가지 중요한 점은, 이 지표는 사실적 정확성이 아닌 관련성만을 측정한다는 것입니다. 즉, 사실과 다른 내용이 포함되더라도 질문에 직접 답하고 있다면 관련성 점수는 높을 수 있으므로, 답변 충실성과 함께 보완적으로 해석해야 합니다.
이 지표가 낮다면 검색 단계의 컨텍스트 품질이나 증강 단계의 프롬프트 구성 방식을 재검토해야 한다는 신호입니다.

예시 – 쿼리: "이번 주 미팅 일정이 언제야?"

이 지표는 역방향 질문 생성 방식으로 측정합니다. 생성된 답변을 LLM에게 주고 "이 답변은 어떤 질문에 대한 답인가?"를 역으로 N개의 질문을 생성하게 한 뒤, 생성된 질문들과 원래 질문 사이의 코사인 유사도 평균을 점수로 삼습니다. 답변이 질문에 잘 맞는 답변이라면 역으로 유추한 질문도 원래 질문과 비슷해야 한다는 원리입니다.

6-4. 평가 단계의 유의사항

• 처음에는 인간 평가로 시작하세요. 그라운드 트루스(Ground Truth) 데이터셋, 즉 ‘이런 질문에는 이런 답변이 정답’이라는 기준 데이터를 미리 구축하는 것은 비용이 크므로, 먼저 소수의 쿼리로 직접 품질을 확인한 뒤 자동화 평가를 도입하는 순서가 현실적입니다.
• 평가 지표 간의 우선순위를 정해야 합니다. 세 지표를 모두 완벽하게 달성하기는 어려우므로, 서비스 특성에 따라 기준을 설정하세요. 신뢰도가 중요한 서비스라면 답변 충실성을, 사용성이 중요하다면 답변 관련성을 우선시하는 식입니다.
• 파이프라인 변경 시 재평가가 필수입니다. 모델 업데이트나 청킹 단위 변경만으로도 세 지표 모두 결과가 완전히 달라질 수 있습니다.
• 평가용 LLM과 운영용 LLM을 분리하는 것을 고려하세요. 세 지표 모두 LLM이 판단에 관여하는 만큼, 평가용으로는 비용이 낮은 가벼운 모델을 따로 사용하는 것이 효율적입니다.

정리

교육 운영 RAG을 구축하며 정리한 6단계를 다시 한번 살펴보면 다음과 같습니다.

1. 사용 사례 식별 및 RAG 필요성 평가 – RAG이 정말 필요한지 판단
2. 요구사항 수집 및 분석 – 사용자 니즈와 정량적 목표 설정
3. RAG 프레임워크 결정 – 팀 환경에 맞는 기술 스택 선택
4. 색인 파이프라인 구현 – 로딩 → 청킹 → 임베딩 → 저장
5. 생성 파이프라인 구현 – 검색 → 증강 → 생성
6. 평가 파이프라인 구현 – Context 관련성, 답변 충실성, 답변 관련성 측정

6단계를 모두 살펴보니, 글 초반에 등장했던 아래 그림이 이제는 조금 다르게 보이지 않나요?

처음부터 모든 단계를 완벽하게 구현하려 할 필요는 없습니다. 색인이나 생성이 다소 미흡하더라도 일단 전체 파이프라인을 한 바퀴 돌려본 뒤, 평가 지표를 보며 약한 부분을 하나씩 개선해가는 것이 훨씬 효과적입니다. ‘완벽함보다 빠른 검증’, 이 원칙이 RAG 구축의 핵심입니다.

RAG을 처음 접하는 분들께는 RAG이 무엇인지, 그리고 어떻게 시작할 수 있는지를 이해하는 시간이, 이미 익숙한 분들께는 지식을 점검하고 복습하는 시간이 되었길 바랍니다.