RAG(검색 증강 생성)란 무엇이고, 언제 필요한가
RAG 는 문서를 모델 가중치에 굽는 대신 질문 시점에 건네준다. 파이프라인이 어떻게 도는지, 왜 RAG 실패의 대부분이 «검색» 실패인지, 그리고 언제 더 단순한 방법이 이기는지.
한 줄 답
검색 증강 생성(RAG)이란 무엇인가?
검색 증강 생성은 질문과 관련된 대목을 우리 문서에서 찾아 모델의 프롬프트에 넣고, 그것을 근거로 답하게 하는 방식이다. 모델의 가중치는 그대로다. 지식은 요청 시점에 «컨텍스트»로 도착한다.
핵심 요약
- RAG 는 검색 + 프롬프팅이다. 검색이 엉뚱한 대목을 가져오면 어떤 모델도 답을 구해내지 못한다.
- 벡터 유사도만으로는 이름·코드·정확한 문구에 약하다 — 키워드와 벡터를 섞는 하이브리드가 실무 기본값이다.
- 즉시 반영된다. 문서를 고치면 다음 답이 바뀐다. 파인튜닝은 그렇게 못 한다.
- 인용이 핵심이다. 근거 대목으로 링크되는 답변은 감사(監査)가 가능하다.
언어모델은 학습 데이터에 있던 것만 안다. 우리 계약 조항도, 지난 분기 숫자도, 어제 올라온 장애 보고서도 모른다. 검색 증강 생성은 아무것도 재학습하지 않고 그 간극을 메우는 표준 방법이다.
파이프라인 전체
RAG 는 두 국면으로 나뉜다. 첫 번째는 미리 해둔다.
색인 (오프라인)
- 문서를 모은다.
- 몇 백~몇 천 토큰 단위의 대목으로 청킹한다.
- 각 청크의 임베딩을 계산한다 — 의미가 비슷한 텍스트가 가까이 놓이는 공간 속의 좌표 벡터다.
- 벡터·원문·메타데이터(출처, 절, 날짜, 권한)를 색인에 저장한다.
응답 (요청마다)
- 사용자 질문을 같은 방식으로 임베딩한다.
- 가장 가까운 청크들을 검색한다 — 키워드 검색과 함께 쓰는 경우가 많다.
- 필요하면 작은 모델로 재순위(rerank) 를 매긴다. 벡터 거리보다 관련성을 정확히 점수화한다.
- 프롬프트를 조립한다: 지시 + 검색된 대목 + 질문.
- 각 주장이 어느 대목에서 나왔는지 인용하도록 지시하고 답을 생성한다.
이게 전부다. 영리함은 «생성»이 아니라 «검색»에 들어간다.
RAG 실패의 대부분은 검색 실패다
RAG 가 틀린 답을 내면 본능적으로 모델을 탓하게 된다. 거의 언제나 검색이 문제다.
다른 걸 손대기 전에 이것부터 확인하라. 실패한 질문을 놓고, 실제로 검색된 대목을 꺼내 보고, 꼼꼼한 사람이라면 그 대목만으로 정답을 낼 수 있었을까를 물어본다. 아니라면 모델에게는 애초에 기회가 없었다.
흔한 원인을 빈도순으로 대략 적으면,
- 어휘 불일치. 사용자는 "해지"라고 묻는데 계약서에는 "해제"라고 적혀 있다. 벡터 검색이 그럭저럭 다루고, 순수 키워드 검색은 못 다룬다.
- 정확한 식별자. 사용자가
INV-2024-8871을 묻는다. 벡터 검색이 약한 지점이다 — 식별자의 임베딩에는 의미가 거의 없다. 키워드 검색은 즉시 찾는다. 하이브리드 검색(둘 다 돌려 순위를 합치기)이 필요한 가장 강한 근거다. - 잘못된 청크 경계. 정의는 한 청크에, 예외는 다음 청크에 있고 하나만 검색됐다.
- 메타데이터 필터 누락. 사용자가 볼 권한이 없는 문서나 폐기된 버전에서 답이 나왔다. 권한과 유효기간 필터는 유사도 «이후»가 아니라 «이전»에 걸어야 한다.
- 결과가 너무 적다. 세 청크만 가져오는 건 효율적이면서 부서지기 쉽다. 스무 개를 가져와 재순위하고 다섯 개를 남긴다.
RAG 가 틀린 도구인 경우
RAG 는 공짜가 아니다. 관리해야 할 색인, 감시해야 할 검색 품질, 모든 요청에 얹히는 지연이 따라온다. 다음 경우엔 건너뛰어라.
- 코퍼스가 작다. 지식베이스 전체가 20쪽이면 시스템 프롬프트에 넣고 캐싱하라.
- 문서에 관한 질문이 아니다. "지난달 지연 배송 건수는?" 같은 집계는 SQL 의 일이다. 벡터 색인 대신 쿼리 도구를 줘라.
- 사실이 아니라 문체의 문제다. 사내 톤으로 쓰게 하는 건 프롬프팅이나 파인튜닝의 영역이다.
알아둘 만한 중간 길도 있다. 에이전틱 검색 — 모델에게 검색 도구를 주고 스스로 질의를 만들고 결과를 보며 다듬게 하는 방식이다. 요청 수가 늘지만, 한 번의 검색으로는 놓치는 다중 홉 질문("2024년과 2025년 정책을 비교해줘")을 처리한다.
답을 믿을 수 있게 만들기
세 가지 실천이 대부분의 일을 한다.
인용을 요구하라. 각 주장에 출처 식별자를 붙이게 하고 링크로 렌더링하라. 사용자는 확인할 수 있고, 우리는 «인용된 대목이 정말 그 문장을 뒷받침하는가»를 측정할 수 있다.
«모른다»를 허용하라. 명시적으로 지시한다 — 가져온 대목에 답이 없으면 모른다고 말하라. 이 문장이 없으면 친절한 모델이 일반 지식으로 빈칸을 메운다. 맞을 수도, 틀릴 수도, 아예 다른 회사 이야기일 수도 있다.
검색을 따로 평가하라. 질문–정답대목 쌍을 만들어 recall@k 를 추적한다. 이 숫자는 답변이 «읽히는 느낌»과 무관하게 검색이 나아지는지 알려준다. 최종 답만 눈으로 보는 팀은 눈을 감고 튜닝하는 것이다.
잘 된 상태는 이렇다
성숙한 RAG 시스템은 특정한 방식으로 «지루하다». 우리 문서에서 답하고, 그 문서로 링크하고, 못 찾으면 못 찾았다고 하고, 오늘과 내일이 같다. 거기에 이르는 길은 대부분 검색 엔지니어링 — 청킹, 하이브리드, 재순위, 필터 — 이고, 언어모델은 마지막 가장 작은 단계를 맡는다.
일주일을 어디에 쓸지 고른다면, 검색에 써라.
자주 묻는 질문
- RAG 가 파인튜닝보다 나은가?
- 푸는 문제가 다르다. RAG 는 모델이 «모르는 사실»을 공급하고, 파인튜닝은 형식·말투·좁은 기술을 가르친다. «우리 데이터를 모른다»면 RAG 다. «우리가 원하는 방식으로 답하지 않는다»면 파인튜닝을 검토한다.
- 컨텍스트 윈도우가 아주 크면 RAG 가 필요 없어지나?
- 압박은 줄지만 필요가 사라지진 않는다. 매 요청마다 전체 코퍼스를 보내는 건 비싸고 느리며, 아주 긴 입력에서는 정확도도 떨어진다.
- RAG 를 붙였는데도 왜 환각이 나는가?
- 보통 검색이 쓸 만한 걸 못 가져왔는데 모델이 그냥 답해버렸기 때문이다. 해법은 명시적 지시와 점검이다 — 가져온 대목에 답이 없으면 «모른다»고 말하게 한다.
- 청킹이 왜 중요한가?
- 청킹은 색인 전에 문서를 나누는 방식이다. 너무 작으면 주변 맥락을 잃고, 너무 크면 일치도가 희석된다. 글자 수로 자르기보다 문서 구조(절·소제목)로 나누는 편이 대개 낫다.