RAG란? — AI에게 모르는 걸 알려주는 가장 현실적인 방법

• RAG는 질문이 들어오면 관련 문서를 먼저 찾아 질문에 붙여 보내는 구조입니다
• 모델이 배운 적 없는 최신 자료나 사내 문서를 학습 없이 답에 쓰게 만드는 방법입니다
• 찾기에 실패하면 답도 실패하기 때문에 검색 품질이 사실상 전부입니다

AI 이야기를 조금만 들여다보면 RAG라는 말이 계속 나옵니다. 우리말로는 검색 증강 생성이라고 옮기는데, 풀어 쓴 이름이 오히려 더 어렵게 들립니다. 영어로는 Retrieval-Augmented Generation, 말 그대로 찾아서(Retrieval) 보태고(Augmented) 만든다(Generation)는 뜻입니다.

결론부터 말하면 RAG는 모델을 똑똑하게 만드는 기술이 아니라, 모델에게 답할 근거를 먼저 쥐여주는 장치입니다. 질문이 들어오면 곧바로 모델에게 넘기지 않고, 관련 있어 보이는 문서를 먼저 찾아 질문 뒤에 붙여서 보냅니다. 모델은 그 붙어 온 내용을 읽고 답합니다.

이 한 문장만 잡고 있으면 뒤에 나오는 이야기가 거의 정리됩니다. 이 글에서는 RAG가 왜 필요한지, 어떤 순서로 도는지, 자주 듣는 임베딩과 벡터 검색이 무엇인지, 그리고 어디서 잘 망가지는지까지 순서대로 정리하겠습니다.

RAG가 정확히 무엇인가요?

언어 모델은 배포되는 순간의 상태로 멈춰 있습니다. 학습을 끝낸 시점까지의 글만 읽었기 때문에 그 이후에 생긴 일은 알지 못합니다. 우리 회사 위키나 계약서처럼 애초에 공개된 적 없는 문서는 더 말할 것도 없습니다.

그렇다고 모델을 다시 학습시키는 건 현실적이지 않습니다. RAG는 그 대신 질문이 들어온 바로 그 순간에 필요한 자료를 찾아다 붙이는 방식을 택합니다. 모델의 머릿속을 바꾸는 대신, 모델이 읽을 종이를 책상 위에 올려 두는 셈입니다.

비유하자면 오픈북 시험에 가깝습니다. 외운 것만으로 답하게 하는 대신, 관련된 페이지를 펼쳐 놓고 그걸 보면서 답하게 하는 것입니다. 시험지에 이 자료 안에서만 답하라는 조건이 붙는다는 점도 비슷합니다.

그래서 RAG를 쓴 시스템의 실제 요청은 우리가 입력한 질문 한 줄보다 훨씬 깁니다. 뒤에 찾아온 문서 조각 몇 개가 조용히 따라붙어 있습니다. 사용자에게는 보이지 않지만, 모델이 실제로 읽는 것은 그 뭉치 전체입니다.

이름에 들어 있는 두 동작만 기억하면 됩니다. 앞쪽 검색은 무엇을 근거로 삼을지 고르는 일이고, 뒤쪽 생성은 그 근거로 문장을 만드는 일입니다. 많은 사람이 뒤쪽만 AI라고 생각하지만, 품질을 가르는 것은 대부분 앞쪽입니다.

왜 문서를 통째로 넣지 않고 굳이 찾아서 붙이나요?

가장 먼저 떠오르는 방법은 가진 문서를 전부 같이 보내는 것입니다. 실제로 문서가 몇 장뿐이라면 그렇게 해도 됩니다. 문제는 분량이 조금만 늘어도 이 방법이 곧바로 막힌다는 점입니다.

첫 번째 벽은 한 번에 실을 수 있는 분량의 한도입니다. 모델마다 한 요청에 넣을 수 있는 글의 양이 정해져 있어서, 사내 문서 수천 장을 통째로 밀어 넣는 일은 애초에 불가능합니다. 한도를 넘기면 잘려 나가거나 아예 거절당합니다.

두 번째 벽은 비용입니다. 요금은 보낸 글의 양에 비례해서 매겨지기 때문에, 질문 한 줄을 물어보려고 매번 문서 전체를 실어 보내면 값이 감당이 안 됩니다. 게다가 그중 실제로 쓰이는 부분은 보통 한두 문단뿐입니다.

세 번째 벽은 조금 덜 알려져 있는데, 길수록 답이 나아지지도 않는다는 점입니다. 관련 없는 내용이 잔뜩 섞여 들어가면 모델이 무엇에 집중해야 할지 헷갈려 하고, 가운데 묻힌 중요한 문장을 놓치기도 합니다. 많이 준다고 잘 답하는 구조가 아닙니다.

RAG는 이 세 가지를 한 번에 피해 갑니다. 매번 전부 보내는 대신, 이번 질문에 필요한 조각만 골라 보내는 것입니다. 보내는 양이 줄어드니 한도에 걸리지 않고, 비용도 내려가고, 모델이 볼 내용도 깔끔해집니다.

지식을 심는 게 아니라 근거를 붙이는 구조입니다.모델을 다시 가르치는 대신, 답하기 직전에 필요한 자료를 손에 쥐여주는 방식입니다.

임베딩과 벡터 검색은 무슨 말인가요?

여기서 한 가지 문제가 남습니다. 어떻게 관련 있는 조각을 찾아내느냐입니다. 단어가 똑같이 들어간 문서를 찾는 방식은 한계가 뚜렷합니다. 연차 쓰는 법이라고 물었는데 문서에는 휴가 신청 절차라고 적혀 있으면 글자로는 하나도 겹치지 않습니다.

그래서 쓰는 것이 임베딩입니다. 문장의 의미를 숫자 목록, 즉 좌표로 바꿔 두는 작업이라고 보면 됩니다. 비슷한 뜻을 가진 문장은 서로 가까운 좌표에 놓이도록 변환되기 때문에, 글자가 달라도 의미가 가까우면 가까운 자리에 모입니다.

그다음이 벡터 검색입니다. 질문도 같은 방식으로 좌표 하나로 바꾼 뒤, 미리 저장해 둔 문서 조각들의 좌표 중에서 가장 가까운 것 몇 개를 집어 오는 일입니다. 지도 위에서 내 위치와 가장 가까운 가게를 찾는 것과 구조가 같습니다.

이 좌표들을 쌓아 두고 빠르게 뒤져 주는 저장소를 벡터 데이터베이스라고 부릅니다. 조각이 수십만 개가 되어도 순식간에 이웃을 찾아내야 하니, 이 부분은 전용 도구를 쓰는 경우가 많습니다.

정리하면 RAG의 준비 단계는 문서를 조각내고, 각 조각을 좌표로 바꿔 저장해 두는 것까지입니다. 실제 질문이 들어오기 전에 미리 해 두는 작업이라, 사용자는 기다릴 필요가 없습니다.

요즘은 의미로 찾는 방식과 단어로 찾는 방식을 같이 쓰는 구성이 흔합니다. 제품명이나 사번처럼 정확히 일치해야 하는 말은 글자 검색이 더 잘 잡고, 돌려 말한 질문은 의미 검색이 더 잘 잡기 때문입니다.

파인튜닝하고는 무엇이 다른가요?

둘을 두고 무엇을 고를지 묻는 경우가 많은데, 사실 겨루는 사이가 아닙니다. 파인튜닝은 모델이 답하는 방식을 바꾸는 작업이고, RAG는 모델이 무엇을 근거로 답할지를 바꾸는 작업입니다.

그래서 판단 기준은 의외로 간단합니다. 바꾸고 싶은 게 답의 모양인지, 답의 내용인지만 보면 됩니다. 말투와 형식이 마음에 안 들면 파인튜닝 쪽이고, 내용이 옛날 것이거나 우리 자료를 모르면 RAG 쪽입니다.

최신 정보를 넣겠다고 파인튜닝을 하는 것이 흔한 헛수고입니다. 학습은 그렇게 말하는 버릇을 들이는 일에 가까워서, 사실을 정확히 기억하게 만드는 데는 잘 듣지 않습니다. 게다가 자료가 바뀔 때마다 다시 학습시킬 수도 없습니다.

RAG의 가장 큰 장점이 바로 여기서 나옵니다. 자료가 바뀌면 문서만 갈아 끼우면 끝입니다. 가격표가 수정되면 그 문서를 새로 넣기만 하면 되고, 모델은 손댈 필요가 없습니다.

또 하나는 출처를 같이 보여줄 수 있다는 점입니다. 어떤 조각을 근거로 썼는지 알고 있으니, 답 아래에 문서 이름과 위치를 붙여 줄 수 있습니다. 사람이 직접 확인할 수 있다는 것만으로 업무에 쓸 수 있느냐 없느냐가 갈립니다.

실무에서는 둘을 같이 쓰는 조합이 가장 흔합니다. 근거는 RAG가 가져오고, 그 근거를 어떤 형식과 말투로 정리해 보여줄지는 파인튜닝이 맡는 식입니다. 역할이 갈려 있어서 서로 방해하지 않습니다.

RAG는 어디서 잘 실패하나요?

가장 많이 걸리는 곳은 검색 단계입니다. 애초에 관련 조각을 못 찾아오면, 뒤에 붙은 모델이 아무리 좋아도 답할 재료가 없습니다. RAG가 잘 안 된다는 말은 열에 아홉 찾기가 잘 안 된다는 뜻입니다.

두 번째는 조각을 어떻게 자르느냐입니다. 너무 잘게 자르면 앞뒤 맥락이 끊겨서, 찾아온 문장만으로는 무슨 말인지 알 수 없게 됩니다. 반대로 너무 크게 자르면 관련 없는 내용이 같이 딸려 와 답이 흐려집니다.

정답이 정해져 있지는 않아서, 보통은 문서 성격에 맞춰 실험으로 정합니다. 항목별로 끊기는 매뉴얼과 줄글로 이어지는 보고서는 적당한 크기가 다릅니다. 조각끼리 조금씩 겹치게 잘라 맥락이 끊기는 것을 줄이는 방법도 자주 씁니다.

세 번째는 근거를 무시하는 경우입니다. 자료를 제대로 붙여 줬는데도 모델이 원래 알던 내용으로 답해 버리거나, 자료에 없는 말을 슬쩍 지어내기도 합니다. 주어진 자료에 없으면 모른다고 답하라는 지시를 명시해 두는 이유가 여기 있습니다.

네 번째는 자주 놓치는 지점인데, 문서 자체가 틀려 있는 경우입니다. 옛날 규정이 담긴 파일이 섞여 있으면 시스템은 그걸 아주 성실하게 찾아다 근거로 씁니다. 넣는 자료를 정리하는 일이 사실상 품질 관리의 절반입니다.

그래서 RAG를 도입할 때 시간을 써야 하는 곳은 모델 고르기가 아닙니다. 어떤 문서를 넣을지 고르고, 어떻게 자를지 정하고, 제대로 찾아오는지 확인하는 쪽입니다. 이 셋이 자리를 잡으면 나머지는 대체로 따라옵니다.

같이 보면 좋은 글

• 파인튜닝이란? — 답하는 방식을 바꾸는 쪽
• 컨텍스트 윈도우란? — 근거를 붙일 자리가 한정된 이유
• 토큰이란? — 붙인 만큼 비용이 되는 단위
• AI·테크 용어사전 전체 목록

다음 용어는 임베딩을 따로 떼어 정리하겠습니다. 이 글에서 의미를 좌표로 바꾼다고만 하고 넘어간 부분인데, 검색이 왜 잘되고 왜 안 되는지는 결국 이 단계에서 갈리기 때문에 한 편을 들여 볼 값이 있습니다.