RAG (검색 증강 생성)

RAG(Retrieval-Augmented Generation, 검색 증강 생성) 는 AI가 답을 만들기 전에 사내 문서나 데이터에서 관련 자료를 먼저 찾아와 그 내용을 근거로 답하게 만드는 방식입니다. 기업이 AI를 사내 지식과 연결하려 할 때 가장 먼저 검토하는 구조이며, 실제로 대기업의 AI 플랫폼 구성을 보면 데이터 레이어·벡터DB·평가 체계와 함께 RAG가 공통 구성요소로 들어가 있습니다.

동작 순서 — 무엇이 추가된 것인가

일반적인 AI 질의응답과 비교하면 중간에 한 단계가 끼어듭니다.

[일반]  질문 ─────────────────────────→ 답변
                                        (모델이 학습한 범위 안에서)

[RAG]   질문 → 관련 문서 검색 → 찾아온 내용을 함께 전달 → 답변
                    ↑                                    (근거를 갖고)
              여기가 추가된 단계

이 한 단계가 만드는 차이는 두 가지입니다. 첫째, 모델이 학습하지 않은 사내 고유 정보 를 다룰 수 있습니다. 둘째, 답변에 어떤 문서를 근거로 삼았는지 를 함께 표시할 수 있어 사람이 검증할 수 있습니다.

재정의 — RAG는 지식 주입 기술이 아니라 문서 상태 진단 도구다

RAG를 도입하려는 조직 대부분은 이렇게 기대합니다. "사내 문서를 다 넣으면 AI가 우리 회사를 아는 상태가 되겠지."

실제로 도입해보면 먼저 드러나는 것은 성능이 아닙니다.

RAG를 붙이면 AI의 답변 품질보다 우리 문서가 서로 모순된다는 사실이 먼저 드러납니다.

같은 주제에 대해 2년 전 기준과 작년 개정본이 함께 검색되고, 팀별로 다르게 쓰던 용어가 한 화면에 나란히 놓입니다. 폐기됐는지 살아 있는지 아무도 모르는 문서가 근거로 인용됩니다. 그동안 이런 불일치는 사람이 암묵적으로 흡수하고 있었습니다. 담당자가 "그건 옛날 기준이고 지금은 이렇게 합니다"라고 말로 메우던 것을, RAG는 메우지 않고 그대로 보여줍니다.

그래서 RAG 프로젝트의 앞부분은 대부분 검색 기술 작업이 아니라 문서 정리 작업 이 됩니다. 이걸 실패라고 볼 필요는 없습니다. 오히려 조직이 그동안 미뤄온 문서 상태를 처음으로 정면에서 확인하는 계기입니다. 선도 기업들이 AI 도입에서 AI-ready 데이터를 전제조건으로 못 박는 이유가 여기에 있습니다.

정리하면 이렇습니다. RAG의 정확도 상한선은 모델이 정하는 게 아니라 문서의 상태가 정합니다. 모델을 바꾸면 표현이 좋아지지만, 틀린 문서를 근거로 삼는 문제는 그대로입니다.

언제 RAG가 필요하고, 언제 필요 없는가

RAG는 무조건 좋은 것이 아니라 특정 조건에서 필요해지는 구조입니다.

마지막 줄이 실무에서 가장 자주 걸리는 지점입니다. "우리 회사 기준으로 검토해줘"가 안 되는 이유가 검색 시스템이 없어서인 경우도 있지만, 그 기준이 애초에 문서로 존재한 적 없는 경우 가 더 많습니다. 이때 필요한 것은 RAG가 아니라 AI 자산화 — 기준을 협의해 문장으로 남기는 작업입니다.

RAG와 MCP는 경쟁 관계가 아니다

둘을 헷갈리는 경우가 많은데 역할이 다릅니다.

• RAG — 자료를 찾아와 근거로 삼는 구조. 방향은 읽기 쪽입니다.
• MCP — AI를 외부 도구·시스템에 표준화된 방식으로 연결 하는 프로토콜. 읽기뿐 아니라 실행까지 포함합니다.

실무 구성에서는 함께 쓰입니다. MCP로 사내 시스템에 연결하고, 그 안에서 문서를 찾아오는 방식이 RAG인 식입니다. "무엇을 근거로 답할 것인가"가 RAG의 질문이라면, "어떻게 연결할 것인가"가 MCP의 질문입니다.

실무 함의 — 많이 찾아올수록 좋은 게 아니다

RAG를 도입한 뒤 답변이 산만해지는 일이 흔합니다. 원인은 대개 검색해온 문서를 너무 많이 넣기 때문입니다.

검색해서 가져온 자료도 결국 AI가 참고하는 정보 범위 안으로 들어갑니다. 그리고 Attention의 성질상 참고 비중의 총합은 정해져 있어서, 관련성이 낮은 문서를 여러 개 넣으면 정말 중요한 근거의 비중이 깎입니다. 문서 10개를 찾아 넣는 것이 3개를 정확히 찾아 넣는 것보다 나쁠 수 있다는 뜻입니다.

그래서 RAG 설계의 실제 작업은 검색을 붙이는 게 아니라 이런 결정들입니다.

• 몇 개를 가져올 것인가
• 관련도가 일정 수준 아래면 아예 버릴 것인가
• 같은 주제에 서로 다른 문서가 걸리면 무엇을 우선할 것인가 (최신본? 공식본?)
• 근거를 못 찾았을 때 추측하지 않고 "확인 필요"로 표시 하게 할 것인가

마지막 항목이 특히 중요합니다. 근거를 못 찾았을 때 그럴듯하게 채워 넣는 것이 RAG에서 가장 위험한 실패 모드입니다. 출처가 붙어 있어 더 믿음직해 보이는데 내용은 근거가 없는 상태가 되기 때문입니다.

RAG 도입 전 점검 체크리스트

• 답해야 할 질문에 대한 근거 문서가 실제로 존재 한다
• 그 문서가 최신 이고, 폐기된 문서와 구분된다
• 같은 주제에 대해 서로 다른 말을 하는 문서 가 없다 (있다면 우선순위가 정해져 있다)
• 문서를 갱신할 담당자 가 정해져 있다
• 어떤 문서를 AI가 볼 수 있는지 권한 범위 가 구분되어 있다
• 답변에 출처가 표시 되고, 사람이 원본으로 되돌아가 확인할 수 있다
• 근거를 못 찾았을 때 추측하지 않는 동작이 정의되어 있다

앞의 네 개는 문서 준비도, 뒤의 세 개는 가드레일과 AI 거버넌스의 영역입니다. 앞쪽이 비어 있으면 RAG는 흩어진 문서를 더 빨리 찾아주는 시스템이 되고, 뒤쪽이 비어 있으면 출처가 붙어 더 믿음직해 보이는 오답을 만들어냅니다.

정리 — 도구를 사기 전에 재료를 확인한다

AI 기회는 멋진 아이디어에서 나오지 않고 업무·데이터·평가·개선 루프가 만나는 지점 에서 나옵니다. RAG는 그중 데이터 쪽 재료가 준비됐을 때 힘을 발휘하는 도구입니다.

그래서 RAG 검토를 시작할 때 가장 유용한 질문은 "어떤 벡터DB를 쓸까"가 아니라 이것입니다. "우리 조직에 검색당할 만한 문서가 있는가, 그리고 그 문서를 누가 최신으로 유지하는가?" 이 질문에 답할 수 있으면 도구 선택은 그다음 문제이고, 답할 수 없으면 도구를 바꿔도 결과는 같습니다.