RAG(검색증강생성)이 뭐길래 다들 이야기할까 - 개념부터 실전 고려사항까지

ChatGPT나 클로드 같은 LLM을 써보면 신기하다가도 꼭 한 번은 걸리는 지점이 있습니다. "이거 최신 소식 아는 거 맞아?"라고 물으면 애매하게 답하거나, 회사 내부 문서나 개인 자료에 대해서는 아예 모른다고 답하는 경우입니다. 이 문제를 푸는 방법으로 요즘 가장 많이 언급되는 기술이 RAG(Retrieval-Augmented Generation, 검색증강생성)입니다. 오늘은 이게 정확히 뭘 하는 기술이고, 왜 이렇게까지 널리 쓰이게 됐는지 정리해보겠습니다.

LLM은 왜 "모른다"고 답할까

LLM은 학습 시점까지 모아둔 방대한 텍스트로 훈련된 모델입니다. 즉 모델 자체에는 "그 이후에 생긴 정보"가 원천적으로 없습니다. 회사 내부 위키, 개인 메모, 어제 올라온 뉴스처럼 학습 데이터에 없던 내용을 물으면 두 가지 중 하나가 벌어집니다. 모른다고 솔직히 답하거나, 그럴듯하게 지어내는 할루시네이션(hallucination)입니다. 후자가 훨씬 골치 아픈 문제인데, 답변이 자신감 있게 나오다 보니 사실 확인 없이는 틀렸다는 걸 알아채기 어렵기 때문입니다.

이 문제를 모델을 다시 학습시켜서(파인튜닝) 풀 수도 있지만, 문서가 하루에도 몇 번씩 바뀌는 상황이라면 매번 재학습하는 건 현실적이지 않습니다. 여기서 나온 대안이 RAG입니다.

RAG란 무엇인가

RAG의 아이디어는 단순합니다. 모델의 지식을 늘리는 대신, 답변에 필요한 자료를 질문할 때마다 옆에서 찾아서 건네준다는 접근입니다. 시험에 비유하면, 모든 걸 외워서 치르는 대신 필요한 자료를 참고서에서 찾아 펼쳐놓고 푸는 오픈북 시험에 가깝습니다. 모델은 원래 알던 지식에 더해, 그 순간 검색해온 최신·전용 자료까지 같이 보고 답을 만들어냅니다.

실제로는 이렇게 동작한다

내부적으로는 크게 세 단계로 나뉩니다.

1. 문서를 쪼개서 벡터로 바꿔둔다(임베딩). 사내 문서나 자료를 문단 단위로 잘게 나누고, 각 조각을 임베딩 모델에 통과시켜 의미를 숫자 벡터로 표현합니다. 이 벡터들을 벡터 데이터베이스에 미리 저장해둡니다.

2. 질문이 오면 의미가 비슷한 조각을 찾는다. 사용자 질문도 같은 방식으로 벡터로 바꾼 뒤, 저장해둔 벡터들과 비교해서 의미상 가장 가까운 문서 조각 몇 개를 찾아옵니다. 단어가 똑같지 않아도 "의미"가 비슷하면 찾아낸다는 게 핵심입니다.

3. 찾아온 내용을 프롬프트에 얹어서 답을 만든다. 검색된 문서 조각들을 LLM에게 "이 자료를 참고해서 답해줘"라는 형태로 함께 넘겨주면, 모델이 그 내용을 근거로 답변을 생성합니다. 답변 끝에 출처 문서를 같이 표시하는 경우가 많은 것도 이 구조 덕분입니다.

벡터 데이터베이스, 뭘 쓰나

이 구조에서 자료를 저장하고 빠르게 찾아주는 역할을 벡터 데이터베이스가 맡습니다. 자주 언급되는 선택지를 정리하면 이렇습니다.

1. pgvector — 이미 쓰고 있는 PostgreSQL에 확장 형태로 붙이는 방식입니다. 벡터 검색만을 위해 별도 시스템을 새로 두지 않아도 되니, 저처럼 이미 Postgres를 운영 중인 환경에서는 진입장벽이 가장 낮습니다.

2. Milvus, Weaviate, Pinecone — 벡터 검색을 전문으로 하는 시스템들입니다. 데이터 규모가 커지고 검색 속도·정확도가 중요해질수록 이런 전용 솔루션으로 넘어가는 경우가 많습니다. Pinecone은 직접 운영할 필요가 없는 매니지드 서비스입니다.

3. Chroma — 로컬에서 가볍게 띄워볼 수 있어서, 개인 프로젝트나 프로토타입 단계에서 RAG를 처음 시험해볼 때 많이 선택됩니다.

RAG와 파인튜닝, 뭐가 다른가

둘 다 "모델이 모르는 걸 알게 하는" 목적처럼 보이지만 접근이 반대에 가깝습니다.

1. ❌ 파인튜닝은 모델 자체를 다시 학습시켜 지식을 모델 내부에 새겨 넣습니다. 문서가 자주 바뀌면 그때마다 재학습이 필요하고, 비용과 시간이 듭니다.

2. ⭕ RAG는 모델은 그대로 두고, 참고 자료만 검색해서 매번 새로 넣어줍니다. 문서를 업데이트하면 벡터 데이터베이스만 갱신하면 되니 반영이 훨씬 빠릅니다.

그래서 "정보가 자주 바뀌는 경우"에는 RAG가, "말투나 형식처럼 자주 안 바뀌는 스타일을 학습시키고 싶은 경우"에는 파인튜닝이 더 맞는 선택으로 여겨집니다. 실무에서는 둘을 같이 쓰는 경우도 많습니다.

실전에서 자주 걸리는 문제들

개념은 단순한데, 막상 구축해보면 품질이 생각만큼 안 나오는 경우가 흔합니다. 자주 언급되는 걸림돌은 이렇습니다.

1. 청킹(chunking) 전략. 문서를 너무 잘게 자르면 문맥이 끊겨서 엉뚱한 조각이 검색되고, 너무 크게 자르면 불필요한 내용까지 딸려와 답변이 흐려집니다. 문서 종류에 맞는 적절한 크기를 찾는 게 생각보다 손이 많이 가는 작업입니다.

2. 임베딩 모델 선택. 한국어 문서가 많다면 한국어 성능이 검증된 임베딩 모델을 쓰는 게 중요합니다. 영어 위주로 학습된 모델을 그대로 쓰면 검색 정확도가 눈에 띄게 떨어지는 경우가 있습니다.

3. 검색 결과 재순위화(rerank). 벡터 검색만으로는 "의미는 비슷한데 실제로는 관련 없는" 조각이 섞여 들어오기 쉽습니다. 검색된 후보를 한 번 더 정교하게 재정렬하는 리랭커를 앞단에 두면 답변 품질이 눈에 띄게 좋아집니다.

그래서 어디에 쓰이나

가장 흔한 활용처는 사내 위키나 매뉴얼을 학습 없이 질의응답 챗봇으로 만드는 경우입니다. 고객 상담 이력을 검색해 상담원에게 관련 사례를 띄워주는 용도, 방대한 코드베이스에서 관련 파일을 찾아 코딩 어시스턴트에게 컨텍스트로 넘겨주는 용도로도 널리 쓰입니다. 공통점은 전부 "모델을 새로 학습시키기엔 자료가 계속 바뀌는" 상황이라는 점입니다.

한계도 분명히 있다

RAG가 할루시네이션을 완전히 없애주는 건 아닙니다. 애초에 관련 문서를 잘못 찾아오면 모델은 틀린 자료를 근거로 그럴듯한 오답을 만듭니다. 그리고 검색·재순위화·생성까지 여러 단계를 거치다 보니, 단순히 모델에 바로 물어보는 것보다 응답 속도도 느려집니다. "검색해서 넣어주면 무조건 정확해진다"가 아니라, 검색 품질 자체를 계속 다듬어야 하는 별도의 작업이 따라온다는 걸 감안하고 접근하는 게 좋습니다.

마무리

정리하면 RAG는 모델을 다시 학습시키는 대신, 답변에 필요한 최신·전용 자료를 그때그때 검색해서 곁들여주는 방식입니다. 회사 문서든 개인 자료든 "모델이 원래 모르던 것"을 다루게 해주는 가장 현실적인 방법이라, LLM을 실무에 붙이는 프로젝트에서는 거의 기본 옵션처럼 등장하고 있습니다. 저도 도구 하나를 새로 붙일 때마다 "이건 RAG로 풀 문제인가, 그냥 프롬프트로 될 문제인가"부터 구분해보는 습관이 생겼는데, 이 글이 그 판단에 조금이나마 도움이 되면 좋겠습니다.

여기 적힌 내용은 2026년 9월 기준으로 정리한 내용이라, 시간이 지나면 세부적인 부분(도구, 서비스명 등)은 계속 바뀔 수 있다는 점 참고해주세요.