AI 시대 데이터 사이언티스트 필수 기술, RAG란?

사내 챗봇을 만들어달라는 요청, 내부 문서를 자연어로 검색하고 싶다는 요구. 요즘 데이터 조직이 받는 프로젝트 리스트를 훑다 보면 결국 한 가지 기술 이름으로 수렴합니다. 바로 RAG입니다. 그런데 정작 'RAG란 무엇인가요, 왜 파인튜닝이 아니라 RAG인가요'라는 질문에 30초 안에 명쾌하게 답할 수 있는 사람은 생각보다 많지 않죠.

이 글에서는 RAG 뜻과 정의, 작동 원리, 그리고 데이터 사이언티스트에게 왜 필수 스킬이 되었는지를 풀어봅니다. 사전적 정의에 머무르지 않고, 실제 도입 사례와 채용 시장의 변화까지 같이 짚어봅니다.

1. RAG란 무엇인가, RAG 뜻부터 정리

RAG 뜻과 한 줄 정의

RAG는 Retrieval-Augmented Generation의 약어입니다. 우리말로는 '검색 증강 생성'으로 옮깁니다. IBM은 RAG를 대규모 언어 모델의 출력을 최적화하는 프로세스로, 응답 생성 전에 훈련 데이터 외부의 권위 있는 지식 베이스를 참조하도록 하는 방식이라고 정의합니다.

조금 더 풀어봅시다. LLM은 방대한 데이터로 학습되지만, 학습 시점 이후의 정보나 회사 내부 문서처럼 훈련에 포함되지 않은 지식은 알지 못합니다. RAG는 답변을 생성하기 전에 관련 문서를 먼저 '검색(Retrieval)'해서, 그 내용을 프롬프트에 붙여 모델의 답변 생성을 '증강(Augmented)'하는 구조입니다. 비유하자면, 시험장에 들어가기 전에 오픈북으로 참고 자료를 뒤져보고 답안을 쓰는 방식이죠. 모델은 학습하지 않은 최신 정보나 도메인 지식에 근거해 답을 만들어냅니다.

왜 지금 RAG가 부상했나

ChatGPT 이후 기업들은 LLM을 실무에 붙이려고 시도했지만, 곧 벽에 부딪혔습니다. 사실과 다른 답을 자신 있게 내놓는 환각 문제, 학습 시점 이후 정보를 모르는 최신성 한계, 회사 내부 문서를 반영할 방법이 없다는 도메인 지식 부재. 이 세 가지가 실무 도입의 가장 큰 걸림돌이었습니다.

학계에서도 이러한 한계를 극복하려는 후속 연구가 활발합니다. 2025년 arXiv에 공개된 Finetune-RAG 연구는 자체 구축한 학습 데이터셋으로 오픈소스 모델을 파인튜닝했을 때 기존 방식 대비 사실 정확도를 유의미하게 개선했다고 보고했습니다. 개별 연구이지만, RAG가 검색 전략과 프롬프트 설계, 재순위 모델까지 조합해 성능을 계속 끌어올리는 활발한 연구 대상이라는 신호입니다.

RAG는 이 문제들을 모델 재훈련 없이 해결하는 실용적 해법으로 떠올랐습니다. MarketsandMarkets에 따르면 글로벌 RAG 시장은 2025년 19.4억 달러에서 2030년 98.6억 달러로 성장할 전망이며, 연평균 성장률은 38.4%입니다. Next Move Strategy Consulting의 다른 조사에서는 2026년 33.3억 달러에서 2035년 815.1억 달러까지 확장될 것으로 예측했습니다. 조사기관마다 수치는 다르지만, 공통적으로 연평균 30% 후반대의 고성장이라는 그림은 일치합니다.

2. RAG 파이프라인, 어떻게 작동하는가

RAG의 3가지 구성 요소

RAG 시스템은 크게 세 부분으로 이뤄집니다. 지식 베이스(knowledge base), 검색기(retriever), 생성기(generator)입니다. 지식 베이스는 참고할 문서들의 저장소이고, 검색기는 질문과 관련된 문서를 찾아오는 역할, 생성기는 검색된 문서를 근거로 최종 답변을 만드는 LLM입니다. 도서관에 비유하면 서가(지식 베이스), 사서(검색기), 답변을 정리해 말해주는 상담원(생성기)이 한 팀으로 움직이는 셈이죠.

4단계 파이프라인

실제 RAG 파이프라인은 4단계로 정리할 수 있습니다.

1단계, 문서 준비와 청킹(chunking, 잘라내기). 참고할 원본 문서를 수집하고, 검색에 적합한 크기로 잘라냅니다. 문서를 통째로 넣으면 검색 정확도가 떨어지고 토큰 비용도 커지기 때문에, 보통 수백에서 수천 토큰 단위로 나눕니다. 두꺼운 백과사전을 통째로 던져주는 대신, 색인 카드처럼 잘게 쪼개 서가에 꽂아두는 작업이라고 생각하면 이해가 쉽습니다. 청킹 전략은 RAG 품질에 상당한 영향을 미치는 부분입니다.

2단계, 벡터 인덱싱. 잘라낸 문서 조각을 임베딩 모델로 벡터로 변환한 뒤, 벡터 데이터베이스에 저장합니다. 관리형 서비스로는 Pinecone, 오픈소스로는 Weaviate와 Milvus, 기존 RDBMS 확장으로는 pgvector가 대표적입니다. 이 과정을 통해 '의미적으로 비슷한 문서'를 빠르게 찾을 수 있는 기반이 마련됩니다.

3단계, 검색. 사용자 질문이 들어오면 같은 임베딩 모델로 벡터화한 뒤, 벡터 DB에서 유사도가 높은 문서 조각을 상위 몇 개 뽑아냅니다. 벡터 검색만으로는 회사명, 제품명 같은 고유명사 매칭이 약해질 수 있어서, 키워드 검색을 함께 돌리는 하이브리드 검색이 표준으로 자리 잡았습니다. 검색된 문서를 다시 정교하게 순위 매기는 재순위(rerank) 단계도 마찬가지입니다. 처음 뽑힌 상위 문서 중 진짜로 답변 근거가 될 것을 다시 골라내는 과정이라, 답변 품질을 눈에 띄게 끌어올립니다.

4단계, 프롬프트 증강과 생성. 검색된 문서를 프롬프트에 함께 넣어 LLM에 전달하면, 모델은 그 문서를 근거로 답을 생성합니다. 이때 모델은 근거로 삼은 문서를 인용할 수 있습니다. NVIDIA 블로그의 표현에 의하면, RAG는 모델에 참고 문헌의 각주처럼 인용할 수 있는 출처를 제공하므로 사용자가 주장을 검증할 수 있고, 이는 신뢰를 구축합니다.

파인튜닝과의 차이

RAG를 이야기할 때 자주 나오는 비교 대상이 파인튜닝입니다. 파인튜닝은 모델의 가중치를 재학습시켜 특정 지식이나 스타일을 모델 자체에 주입하는 방식입니다. 두 접근은 목적과 구조가 다릅니다.

두 기법은 서로 배타적이지 않고, 실무에서는 함께 쓰이는 경우가 많습니다. 다만 대부분의 사내 지식 검색, 고객 지원 챗봇 시나리오에서는 RAG가 먼저 검토됩니다. RAG 원 논문 저자들이 RAG를 '거의 모든 LLM이 실질적으로 모든 외부 리소스에 연결할 수 있는 범용 파인튜닝 레시피'라고 표현한 것도 이런 범용성 때문입니다.

3. RAG는 실제로 어떤 문제를 푸는가

주요 활용 분야와 구체 사례

RAG가 가장 활발히 쓰이는 영역은 고객 지원 챗봇, 내부 지식 검색, 회사 문서에서 직접 답변하는 증강 검색 경험입니다. 공통점이 있습니다. 모두 '조직 고유의 문서'가 답변의 근거가 되어야 한다는 점입니다.

국내에서도 도입 사례가 늘고 있습니다. 우아한형제들 기술블로그는 사내 데이터를 기반으로 구성원의 질문에 답하는 사내 챗봇 '물어보새'의 개발 과정을 공개한 바 있습니다. 사내에 흩어져 있던 위키 문서와 노션 페이지를 자연어로 질문해 답을 받을 수 있도록 설계한 사례로, 신입 구성원의 온보딩 질문이나 반복적인 사내 규정 문의를 자동으로 처리하는 데 활용됐습니다. 규모와 산업을 가리지 않고 '사내 지식을 자연어로 다루는 시스템'을 만들려는 시도가 표준화되고 있다는 신호입니다.

MarketsandMarkets의 조사에 따르면 BFSI(금융, 보험)와 헬스케어 부문이 RAG 도입을 주도하고 있습니다. 이 두 산업은 AI 환각을 제거하고, 비정형 데이터를 활용하며, 컴플라이언스 감사를 자동화해야 한다는 공통 과제를 안고 있습니다. 규제가 강한 산업일수록 '근거를 인용할 수 있는' RAG의 특성이 결정적으로 작용합니다.

RAG가 만능은 아니다

다만 RAG가 만능은 아닙니다. 검색된 문서가 잘못됐거나 관련성이 낮으면, LLM은 오히려 잘못된 근거를 확신 있게 인용하며 환각을 강화할 수 있습니다. 사서가 엉뚱한 책을 뽑아주면, 아무리 성실한 상담원이라도 잘못된 답변을 자신 있게 말하게 되는 셈이죠. 청킹이 어색하게 잘리거나 임베딩 모델이 도메인을 이해하지 못하면 검색 상위에 엉뚱한 문서가 올라오고, 그 결과 답변 품질이 파인튜닝만도 못해지는 경우도 흔합니다. 그래서 '검색 품질을 어떻게 평가하고 개선할 것인가'가 RAG 프로젝트의 실질적 승부처가 됩니다.

클라우드 하이퍼스케일러들도 RAG를 엔터프라이즈 AI 제품의 기본 구성 요소로 편입시켰습니다. Research and Markets에 따르면 Microsoft의 Azure OpenAI Service, AWS의 Bedrock 등 주요 클라우드가 RAG를 내장하고 있고, Anthropic, Cohere 같은 모델 기업들도 RAG 기반 솔루션과 파트너십에 대규모로 투자하고 있습니다. 개별 조직이 직접 구축해야 했던 RAG가 이제는 클라우드가 제공하는 표준 서비스로 정착하고 있다는 뜻입니다.

4. 데이터 사이언티스트에게 RAG가 필수가 된 이유

채용 시장에서 요구가 달라지고 있다

데이터 사이언티스트 채용 공고를 들여다보면 최근 눈에 띄는 변화가 있습니다. 예전에는 통계와 머신러닝 위주였던 요구사항에, 이제는 'LLM 활용 경험', 'RAG 파이프라인 구축 경험'이 우대 또는 필수 항목으로 등장하고 있습니다. 특히 신입부터 5년차 사이 성장 구간에서 실무 프로젝트 밀도가 중요한 시점에, LLM과 RAG 스킬은 추가 프리미엄이 붙는 요소로 자리 잡았습니다.

이 변화의 배경에는 두 가지 흐름이 있습니다. 첫째, 데이터 사이언티스트의 역할이 '분석 리포트 작성'에서 '데이터로 작동하는 제품 만들기'로 확장되고 있다는 점. 둘째, 비정형 데이터(문서, 로그, 대화)를 다루는 요구가 정형 데이터 분석만큼이나 중요해지고 있다는 점입니다. RAG는 이 두 흐름의 교차점에 위치합니다.

데이터 사이언티스트가 RAG에서 맡는 역할

RAG 시스템을 구축할 때 데이터 사이언티스트가 담당하는 영역은 생각보다 넓습니다.

데이터 파이프라인 설계. 사내 문서를 수집하고 정제하는 단계입니다. 어떤 문서를 지식 베이스에 넣을지, 어떻게 청킹할지, 메타데이터를 어떻게 구조화할지 결정하는 것은 결국 데이터 파이프라인 문제입니다. 검색기의 성능은 이 단계에서 절반 이상 결정됩니다.

검색 품질 평가. RAG의 성능은 검색기의 정확도에 크게 좌우됩니다. 이때 쓰이는 지표들은 이름만 봐서는 낯설지만, 뜻은 단순합니다. Recall@k는 정답 문서가 상위 k개 안에 들어왔는지 보는 '건짐률' 점수이고, MRR(Mean Reciprocal Rank)은 정답을 얼마나 앞순위에 올려놨는지 재는 '순위 감각' 점수, nDCG(normalized Discounted Cumulative Gain)는 순위별 가중치를 반영해 랭킹 전체의 품질을 매기는 '종합 채점' 점수입니다. 이런 지표를 설계하고, 실제 사용자 질의 로그를 분석해 개선 방향을 잡는 것은 데이터 분석 역량 그 자체입니다.

임베딩과 벡터 DB 튜닝. 어떤 임베딩 모델을 쓸지, 벡터 차원을 얼마로 할지, 하이브리드 검색 비율을 어떻게 조정할지 실험하고 A/B 테스트하는 것은 통계적 실험 설계와 맞닿아 있습니다.

LLM 응답 평가. 생성된 답변의 사실성, 관련성, 인용 정확도를 평가하는 프레임을 만드는 것도 데이터 사이언티스트의 몫입니다. LangSmith, RAGAS 같은 평가 도구를 활용하거나, 자체 평가 셋을 구축하는 프로젝트가 많아졌습니다.

5. RAG를 다루는 데이터 사이언티스트에게 필요한 역량

채용 시장에서 RAG 관련 스킬을 요구할 때, 실제로 어떤 역량 조합을 보는 것일까요? 정리하면 다음과 같습니다.

(1) 데이터 처리와 파이프라인 역량

Python, SQL, 그리고 문서와 로그 같은 비정형 데이터를 다룰 수 있는 전처리 감각이 기본입니다. RAG의 성능은 결국 인덱싱 전에 어떤 데이터를 어떻게 준비했느냐에 달려 있습니다.

(2) 임베딩과 벡터 DB 이해

Sentence-BERT 계열, OpenAI Embeddings 등 임베딩 모델의 특성을 이해하고, Pinecone, Weaviate, pgvector 중 상황에 맞는 도구를 고를 수 있는 판단력이 필요합니다.

(3) LLM 프레임워크 활용

LangChain, LlamaIndex 같은 오케스트레이션 프레임워크로 검색과 프롬프트, 답변 파이프라인을 조립할 수 있는 실무 능력입니다.

(4) 평가와 모니터링 역량

생성된 답변의 품질을 정량 지표로 관리하고, 프로덕션에서 발생하는 실패 사례를 로그로 추적하는 MLOps 감각. 이 부분이 초급자와 실무 경력자를 가르는 결정적 차이가 되고 있습니다.

(5) 도메인 이해력

RAG의 지식 베이스는 결국 특정 도메인의 문서입니다. 금융이든 헬스케어든 커머스든, 그 도메인의 문서 구조와 용어를 이해하는 사람이 훨씬 좋은 검색기를 설계합니다.

이 다섯 가지 역량은 어느 하나만으로 완성되지 않습니다. 데이터 처리, 모델링, 시스템 설계, 도메인 감각을 한 사람 안에서 연결해야 실제로 작동하는 RAG 시스템이 만들어집니다.

RAG의 개념과 파이프라인을 이해했다면, 다음 질문은 '어떻게 이 역량을 실제 프로젝트로 쌓을 것인가'입니다. 벡터 DB 튜토리얼을 몇 번 따라 해보는 것과, 회사에서 요구하는 수준의 RAG 시스템을 설계하고 평가까지 붙여보는 것 사이에는 꽤 큰 벽이 있습니다. 준비를 미루는 흔한 이유도 결국 이 벽입니다. 이론과 실전 포트폴리오를 어디서 어떻게 이어야 할지 모르는 상태에서 시간과 비용까지 걸리기 때문입니다.

한국형 AI 전문가 양성 과정 KANT의 AI 데이터 사이언스 트랙은 이 간극을 커리큘럼으로 좁혀 놓은 과정입니다. Python과 SQL 기초부터 시작해 ML, 딥러닝을 거쳐 Computer Vision, RAG, AI Agent, MLOps까지 이어지는 4단계 구성으로 진행되고, 마지막 3개월은 실제 기업의 문제를 다루는 미니 인턴십 프로젝트로 채워집니다. 전체 6개월의 교육 뒤 3개월의 기업 연계 프로젝트가 붙는 구조라, 이론과 포트폴리오 사이의 벽을 실습 밀도로 넘어서게 설계돼 있습니다. 국비지원으로 진행되므로 비용 부담도 크게 줄어듭니다.

출처

• IBM, What is RAG (Retrieval-Augmented Generation)?

• NVIDIA Blog, What Is Retrieval-Augmented Generation, aka RAG? (2023)

• Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, arXiv (2020)

• MarketsandMarkets, Retrieval Augmented Generation (RAG) Market (2025)

• Next Move Strategy Consulting, Retrieval-Augmented Generation Market (2026)

• Research and Markets, Retrieval-Augmented Generation Market Report (2026)

• Finetune-RAG, arXiv 2505.10792 (2025)

• 우아한형제들 기술블로그, 사내 챗봇 '물어보새' 개발기