ChatGPT는 이제 수능 문제도 푸는데, 왜 기업의 AI 챗봇은 홈페이지에 있는 답조차 찾지 못할까요?

제품의 환불 규정을 물었는데 엉뚱한 답을 하거나, 홈페이지에 버젓이 있는 정보를 찾지 못하는 경우가 있습니다. 결국 고객은 챗봇 창을 닫고 직접 검색하거나 상담원에게 전화를 겁니다.

AI가 대중화 되면서 기업들도 처음에는 회사의 모든 문서를 AI에 연결하면 회사 업무와 제품을 잘 아는 AI가 될 것으로 기대했습니다. 하지만 실제로는 필요한 문서를 찾지 못하거나 질문과 관계없는 자료를 가져오는 일이 잦았습니다.

고객에게는 그저 “별로 똑똑하지 않은 챗봇”으로 보이지만, 그 뒤에서는 담당자들이 임베딩 모델을 바꾸고 문서를 자르는 방법(Chunking)을 조정하며 검색 성능을 높이느라 머리를 싸매고 있습니다.

이처럼 AI가 답하기 전에 회사 자료를 검색하고, 찾은 내용을 근거로 답하게 만드는 기술을 RAG라고 합니다.

이번에는 고객도 답답하고 담당자도 머리 아팠던 초기 RAG와 이 기술의 발전에 대해 이야기를 해보려고 합니다.

1. RAG라는 개념의 시작

LLM은 학습이 끝나면 가중치가 고정됩니다. 대화하면서 새로운 정보를 읽을 수는 있지만, 그 정보가 자동으로 모델의 가중치에 학습되는 것은 아닙니다.

따라서 이미 학습이 끝난 LLM은 비공개 사내 문서나 학습 이후에 바뀐 정보를 원래 알 수 없습니다. 그렇다고 새로운 문서가 생길 때마다 모델을 다시 학습시키기도 어렵습니다. 비용과 시간이 많이 들고, 무엇보다 기업의 데이터는 계속 바뀝니다.

• 오늘 새 규정이 올라온다.

• 어제 회의록이 추가된다.

• 지난달 제품 매뉴얼이 수정된다.

• 고객 지원 FAQ가 매주 바뀐다.

(파인튜닝처럼 모델의 일부를 추가로 학습시키는 방법도 있지만, 이렇게 자주 바뀌는 정보를 반영하는 용도로는 적합하지 않습니다. 파인튜닝은 다음 장에서 자세히 살펴보겠습니다.)

그래서 모델의 지식을 매번 바꾸는 대신, 질문을 받을 때 필요한 자료를 외부에서 찾아 보여주자는 아이디어가 나왔습니다.

이것이 RAG(Retrieval-Augmented Generation)의 시작입니다.

RAG는 질문이 들어오면 미리 준비된 문서에서 관련 내용을 검색하고, 검색 결과를 LLM에 전달해 그 내용을 근거로 답하게 합니다.

질문 → 관련 문서 검색 → 검색 결과를 LLM에 전달 → 전달된 검색 결과를 근거로 답변 생성

간단히 말하면 이런 요청을 시스템으로 만든 것입니다.

네 기억으로 추측하지 말고, 지금 찾은 회사 자료를 근거로 답해.

2. RAG는 컨텍스트 엔지니어링이다

RAG는 모델을 다시 학습시키는 기술이 아닙니다. 모델이 답변하기 직전에 어떤 정보를 보게 할지 설계하는 기술입니다.

LLM은 사용자의 질문, 지시 사항, 참고 문서처럼 현재 입력된 정보를 바탕으로 답을 만듭니다. 앞에 "4.2 문맥과 기억"에서 이런 입력을 컨텍스트(Context)라고 부른다고 설명 드렸죠?

그리고 모델이 일을 잘하도록 적절한 정보와 도구, 지시 사항을 구성해서 컨텍스트를 잘 만들어주는 작업을 컨텍스트 엔지니어링(Context Engineering)이라고 부릅니다.

RAG는 컨텍스트 엔지니어링 방법 중 하나입니다. 질문과 관련된 외부 자료를 검색하고, 그중 필요한 부분을 골라 모델의 컨텍스트에 넣습니다.

(컨텍스트 엔지니어링에 대해서는 나중에 따로 설명하도록 하겠습니다.)

3. RAG는 어떻게 작동하는가

RAG라는 이름에는 세 가지 과정이 들어 있습니다.

Retrieval    : 질문과 관련된 자료를 찾는다.

Augmentation : 찾은 자료를 질문의 컨텍스트에 추가한다.

Generation   : 질문과 자료를 바탕으로 답을 생성한다.

실제로 RAG를 만들려면 검색이 가능하도록 문서를 준비하는 과정과 질문에 답하는 과정을 구현해야 합니다.

[문서 준비]

사내 문서 수집 → 문서를 작은 단위로 분할 → 임베딩 생성 → 검색 인덱스에 저장

[질문 답변]

사용자 질문 → 관련 문서 검색 → 필요한 문서 조각 선택 → 질문과 문서를 LLM에 전달 → 답변 생성

자 그럼 사용자가 질문을 하면 RAG가 어떻게 답을 찾는지 살펴보도록 하죠. 예를 들어 사용자가 이런 질문을 했다고 가정해봅시다.

신규 입사자도 재택근무를 할 수 있나요?

일반 모델은 학습할 때 얻은 지식으로 답하려 합니다. 반면 RAG 시스템은 모델에 묻기전에 먼저 사내 문서 저장소에서 재택근무 규정을 찾습니다. 예를 들면 아래와 같은 문서를 찾을 수 있겠죠.

** 사내 재택근무 규정

정규직 직원은 부서장 승인 후 주 2회까지 재택근무를 신청할 수 있다.

단, 신규 입사 후 3개월 이내 직원은 예외 승인이 필요하다.

.....

** 근태 관리 가이드

재택근무일에는 오전 10시까지 업무 시작 상태를 등록해야 한다.

그리고 그 결과를 포함해서 아래와 같은 텍스트를 생성한 다음 그대로 LLM에 입력으로 넣습니다.

### 지시 사항

아래 [검색 결과]를 바탕으로 사용자의 질문에 답하세요.

검색 결과에 답이 없다면 "제공된 정보로는 알 수 없습니다"라고 답하세요.

### 검색 결과

[문서 1] 사내 재택근무 규정

정규직 직원은 부서장 승인 후 주 2회까지 재택근무를 신청할 수 있다.

단, 신규 입사 후 3개월 이내 직원은 예외 승인이 필요하다.

[문서 2] 근태 관리 가이드

재택근무일에는 오전 10시까지 업무 시작 상태를 등록해야 한다.

### 사용자 질문

신규 입사자도 재택근무를 할 수 있나요?

이제 모델은 자기에게 학습된 데이터를 기반으로 답하는게 아니고 입력으로 들어온 내용을 정리해서 답변을 하면 됩니다. 그러면 이런식으로 답변을 할 수 있겠죠.

신규 입사 후 3개월 이내에는 예외 승인이 필요합니다. 따라서 재택근무가 금지된 것은 아니지만, 일반 신청 절차만으로는 이용할 수 없습니다.

이 구조에는 기업이 원하는 몇 가지 장점이 있습니다.

• 모델을 다시 학습시키지 않아도 내부 문서를 활용할 수 있다.

• 최신 문서를 반영하면 바뀐 정보로 답할 수 있다.

• 답변에 출처를 붙여 사람이 검증할 수 있다.

• 사용자의 문서 접근 권한을 검색 단계에서 통제할 수 있다.

RAG를 도입하는 또 하나의 이유는 AI의 환각(Hallucination)을 줄이기 위해서입니다. 모델의 기억에만 의존하지 않고 사내 문서를 답변의 근거로 제공하면, 사실과 다른 내용을 만들어낼 가능성이 낮아집니다.

다만 RAG가 환각을 완전히 막아주는 것은 아닙니다. 잘못된 문서를 검색하거나, 문서에 없는 내용을 모델이 추론해서 덧붙이면 여전히 틀린 답이 나올 수 있습니다. 좋은 RAG는 필요한 자료를 잘 찾는 데서 끝나지 않습니다. 근거가 없을 때는 답하지 않고, 어떤 자료를 참고했는지 확인할 수 있도록 설계해야 합니다.

4. RAG에 쓰이는 임베딩과 벡터 검색

사내 문서에서 필요한 내용을 찾는 가장 단순한 방법은 키워드 검색입니다. 하지만 사람은 질문할 때 문서에 적힌 표현을 그대로 사용하지 않습니다.

사용자가 이렇게 물었다고 가정 해보겠습니다.

신규 입사자도 집에서 일할 수 있나요?

규정에는 다음과 같이 적혀 있을 수 있습니다.

입사 후 3개월 이내 직원의 재택근무에는 예외 승인이 필요하다.

질문에는 신규 입사자, 집에서 일하다가 쓰였고 문서에는 입사 후 3개월, 재택근무가 쓰였습니다. 뜻은 통하지만 단어가 다릅니다. 키워드만 비교하면 이 문서를 놓칠 수 있습니다.

앞에서 임베딩공간(Embedding Space)에 대해서 설명한거 기억하시나요? 임베딩 공간은 문장이나 문서의 의미를 숫자 벡터로 바꾼 후 뜻이 비슷한 문장을 가까운 위치에 놓이도록 배치한 공간입니다. 여기에서 벡터 검색(Vector Search)을 하면 질문의 벡터와 가까운 문서 벡터를 찾아냅니다.

RAG를 구현할 때는 그래서 보통 문서들을 임베딩해서 임베딩공간에 배치하고 벡터 검색을 통해서 Retrieval을 하게됩니다. 덕분에 사용자가 문서의 정확한 표현을 몰라도 의미가 비슷한 내용을 찾을 수 있습니다.

5. 기존 RAG의 두 가지 한계

RAG의 답변 품질은 LLM의 능력만으로 결정되지 않습니다. 필요한 문서를 제대로 찾았는지, 그리고 한 번의 검색으로 풀 수 있는 질문인지가 함께 영향을 줍니다.

검색이 틀리면 답도 틀어진다

임베딩 공간에서 벡터 검색은 "의미가 가깝다"이지 언제나 "이 질문에 필요한 자료다"라는 뜻은 아닙니다.

가령 사용자가 "계약 해지 시 위약금 기준"을 물었는데 검색기가 "계약 갱신 절차"를 가져올 수 있습니다. 두 문서 모두 계약을 다루지만 질문에 답할 근거는 전혀 다릅니다.

잘못된 문서가 컨텍스트에 들어가면 모델은 그 자료를 바탕으로 그럴듯한 답을 만들기도 합니다. 결국 RAG의 품질은 임베딩 모델, 검색엔진, 문서를 나누는 방식, 검색 결과를 재정렬하는 방식에 크게 좌우됩니다.

한 번 검색하고 답하는 구조

초기 RAG는 대부분 다음과 같이 움직였습니다.

질문 → 검색 1회 → 답변

규정 한 조항을 찾는 일이라면 이 정도로 충분합니다. 여러 자료를 비교하고 원인까지 분석해야 한다면 이야기가 달라집니다.

작년 고객 불만 중 배송 관련 문제가 늘어난 원인을 제품군별로 비교하고, 올해 운영 정책과 연결해서 개선안을 제안해줘.

이 질문에 답하려면 고객 불만 데이터, 제품군 정보, 배송 정책과 올해 운영 계획을 따로 찾아야 합니다. 배송 지연과 출고 지연처럼 표현이 다른 항목도 연결해야 합니다. 중간 자료가 부족하면 추가 검색도 필요합니다.

그런데 초기 RAG는 질문을 나누거나, 검색 결과가 충분한지 확인하거나, 서로 충돌하는 자료를 다시 점검하지 못했습니다.

앞 장에서 추론 모델과 AI 에이전트를 살펴보며, 복잡한 문제는 한 번에 답을 만드는 것보다 단계를 나누고 결과를 확인하면서 풀 때 더 잘 해결된다고 했습니다. 기존 RAG는 이와 달리 오랫동안 One-shot, 즉 한 번 검색하고 바로 답하는 구조에 머물렀습니다.

그래서 좋은 벡터 검색 시스템을 갖춘 RAG보다, 단순한 키워드 검색 도구를 여러 번 사용할 수 있는 AI 에이전트가 복잡한 조사에서 더 나은 결과를 내는 경우도 생겼습니다. 검색기의 정확도만 높이는 것으로는 해결되지 않는 한계가 있었던 것입니다.

6. RAG는 어떻게 발전하고 있는가

이 한계를 보완하는 방향은 크게 세 가지입니다. 검색 결과를 더 정확하게 고르고, 문서 사이의 관계를 인덱스에 담고, 검색 과정 자체를 여러 단계로 바꾸는 것입니다.

하이브리드 검색과 리랭킹

첫 번째 방향은 검색 품질을 높이는 것입니다.

업무 분야에 맞는 임베딩 모델을 사용하면 사내 용어나 전문적인 표현을 더 잘 구분할 수 있습니다. 사용자의 짧거나 모호한 질문을 검색하기 좋은 문장으로 다시 쓰는 쿼리 재작성(Query Rewriting)도 활용합니다.

벡터 검색만 고집할 필요도 없습니다. 제품명, 법 조항, 오류 코드, API 처럼 정확한 문자열이 중요한 질문은 키워드 검색이 더 잘 찾습니다. 실무에서는 두 검색 방식을 함께 사용하는 경우가 많습니다.

벡터 검색     : 의미가 비슷한 문서를 찾는다.

키워드 검색    : 정확한 단어가 들어간 문서를 찾는다.

하이브리드 검색 : 두 결과를 합쳐 후보를 넓힌다.

리랭킹        : 후보를 다시 평가해 관련성이 높은 순서로 정렬한다.

지식 그래프, 온톨로지와 GraphRAG

벡터 검색은 질문과 가까운 문서 조각을 찾는 데 능하지만, 여러 문서에 흩어진 정보가 서로 어떻게 연결되는지는 알기 어렵습니다.

다음 질문을 생각해봅시다.

지난 3년간의 보고서를 읽고, 우리 회사 신사업 리스크의 큰 흐름과 서로 연결된 원인을 분석해줘.

이 질문에 답하려면 특정 문장 하나를 찾는 것으로는 부족합니다. 여러 문서에 등장하는 조직, 제품, 사건과 리스크를 연결해 전체 구조를 봐야 합니다.

지식 그래프: 실제 관계를 저장한다

지식 그래프(Knowledge Graph)는 문서에 등장하는 사람, 조직, 제품, 사건 같은 대상을 노드(Node)로 만들고, 대상 사이의 실제 관계를 엣지(Edge)로 연결합니다.

고객 A가 제품 B를 구매했다

  : 고객 A → 구매 → 제품 B

제품 B에는 부품 C가 사용된다

  : 제품 B → 사용 → 부품 C

공급사 D가 부품 C를 공급한다

  : 공급사 D → 공급 → 부품 C

공급사 D의 납기 지연이 제품 B에 영향을 준다

  : 공급사 D → 납기 지연 → 제품 B

임베딩 공간과 벡터 검색이 비슷한 문장을 찾는다면, 지식 그래프는 데이터 안에 실제로 존재하는 관계를 저장합니다.

온톨로지: 관계의 템플릿과 규칙을 정의한다

그래프를 만들기 전에 어떤 종류의 노드와 엣지를 사용할지 정할 수 있습니다. 이것이 온톨로지(Ontology)입니다.

[온톨로지]

공급사 → 공급한다 → 부품

[실제 그래프 데이터]

MCY전기 → 공급한다 → 3상모터

온톨로지는 고객, 계약, 제품, 장애, 보상 같은 개념이 무엇인지, 그리고 서로 어떤 관계를 맺을 수 있는지 정의합니다. 관계의 방향이나 의미도 정할 수 있습니다.

예를 들어 해지라는 표현이 통신 계약 해지인지, 구독 해지인지, 고용 계약 종료인지 구분하도록 만들 수 있습니다. 이렇게 하면 문서마다 다른 표현을 사용하더라도 일관된 기준으로 관계를 정리할 수 있습니다.

GraphRAG: 지식 그래프를 검색에 활용한다

GraphRAG는 문서에서 지식 그래프를 만들고, 그 그래프를 RAG의 검색과 답변에 활용합니다. GraphRAG의 특징은 밀접하게 연결된 노드를 커뮤니티로 묶고 요약한다는 점입니다.

1. 문서에서 엔티티와 관계를 추출한다.

2. 추출한 관계를 지식 그래프로 만든다.

3. 밀접하게 연결된 노드를 커뮤니티로 묶는다.

4. 각 커뮤니티의 내용을 요약한다.

5. 질문에 맞는 그래프와 요약을 검색한다.

GraphRAG가 반드시 온톨로지를 필요로 하는 것은 아닙니다. LLM이 문서를 읽고 노드와 엣지를 직접 추출할 수도 있습니다. 다만 온톨로지를 함께 사용하면 관계의 이름과 의미를 일관되게 만들고, 잘못된 연결을 줄이는 데 도움이 됩니다.

GraphRAG에서는 전체 자료의 주요 주제나 반복되는 위험을 묻는 질문에는 여러 커뮤니티 요약을 종합하는 Global Search를 사용합니다. 특정 고객과 제품의 관계처럼 범위가 좁은 질문에는 해당 노드 주변을 따라가는 Local Search를 사용합니다.

GraphRAG는 대규모 보고서 분석, 리스크 분석, 시장 조사처럼 전체 흐름과 숨은 연결이 중요한 작업에 잘 맞습니다. 반면 지식 그래프와 커뮤니티 요약을 만드는 데 많은 LLM 호출이 필요합니다. 짧은 문서나 단순 FAQ를 위해 사용하기에는 비용이 클 수 있습니다.

Agentic RAG

지금까지 살펴본 개선 방법은 주로 더 좋은 자료를 찾는 것에 집중했습니다. 임베딩과 하이브리드 검색은 검색 정확도를 높이고, GraphRAG는 정보 사이의 관계까지 검색할 수 있게 만듭니다. 하지만 검색 정확도를 아무리 높여도, 한 번 검색하고 바로 답한다는 초기 RAG의 한계는 남습니다.

그래서 엔지니어들은 이것을 극복하기 위해 앞에서 얘기한것처럼 AI에이전트의 장점을 RAG에 도입하기 시작했습니다. 에이전트의 절차적 실행과 반복 구조를 RAG에 적용해서 성능을 극대화 시킨것이 Agentic RAG입니다.

질문 분석

  ↓

검색 계획 수립

  ↓

검색 실행

  ↓

결과 평가

  ├─ 자료가 충분함 → 답변 생성

  └─ 자료가 부족함 → 질문을 나누거나 검색어를 바꿔 재검색

예를 들어 "올해 매출 하락 원인을 제품군별로 분석해줘"라는 질문을 받으면, Agentic RAG는 먼저 제품군 목록을 찾습니다. 그다음 각 제품군의 매출 자료를 조회하고, 원인 후보를 확인하기 위해 영업 보고서와 고객 피드백을 추가로 검색합니다. 자료끼리 충돌하면 다른 출처를 찾아 다시 확인할 수도 있습니다.

제가 RAG글을 AI에이전트 다음에 쓴 이유도 여기에 있습니다. RAG가 에이전트보다 먼저 시작되었지만 기존 RAG의 One-shot 구조가 에이전트의 반복 구조를 만나 어떻게 달라졌는지 연결해서 보기 위해서입니다.

Agentic RAG는 특히 복잡한 조사가 필요한 질문에서 RAG의 성능을 극적으로 끌어 올렸습니다. 다만 Agentic RAG는 검색과 판단을 반복하므로 시간과 비용이 늘어납니다. 그래서 실무에서는 질문의 난이도에 따라 Agentic RAG와 고정형 RAG 두 방식을 나눠 쓰는 편이 현실적입니다.

7. RAG의 현재와 미래

제가 직접 사용해 본 여러 기업용 AI 챗봇은 답변 품질만 놓고 보면, 아직도 단순한 벡터 검색 중심의 초기 RAG나 하이브리드 검색과 리랭킹을 적용하는 단계에 머문 시스템이 적지 않아 보입니다. (물론 외부에서 챗봇의 내부 구조를 정확히 알 수는 없으므로 이는 답변 품질을 바탕으로 한 추정입니다.)

앞으로 더 나은 임베딩과 검색 방식, GraphRAG나 온톨로지, Agentic RAG등을 적용해서 고객이 다시 검색하거나 상담원에게 전화하지 않아도 되는 성능좋은 챗봇이 만들어지면 좋겠습니다.

또한 AI챗봇 뿐만 아니라 AX(AI Transformation)을 원하는 기업들은 높은 성능의 RAG환경을 구축하는 것이 필수적입니다.

작년까지 AX를 실행한 기업들이 RAG에 상당히 많은 투자를 한것으로 알고 있는데 안타깝게도 너무 일찍 투자한 기업들은 기존 RAG 기술만 써서 성능 한계를 겪고 있을 가능성이 높습니다.

RAG성능 향상 방법은 여러가지 말씀 드렸지만 온톨로지 방법론이나 GraphRAG에 비해 Agentic RAG로 전환하는 것이 도입 비용이 저렴하고 기술적으로도 쉬워서 저는 그쪽을 추천하는 편입니다.

그리고 요즘 Agentic AI 환경을 구축할 때는 RAG시스템이 검색을 하도록 하는 대신 검색기능을 MCP로 열어주고 모델이 직접 검색하도록 하는 경우도 많습니다. 이 경우 더 많은 토큰 비용이 발생하지만 기존 Agentic AI환경 구축에 묶어서 같이 할 수 있으므로 이렇게도 많이 합니다.

한 줄 정리

RAG는 AI가 회사 내부 데이터를 검색하고, 그 자료를 컨텍스트에 넣어 답하게 만드는 기술입니다.

초기에는 임베딩과 벡터 검색의 성능을 높이는 데 집중했습니다. 지금은 하이브리드 검색과 리랭킹으로 검색 결과를 다듬고, GraphRAG와 온톨로지로 정보의 관계를 담으며, Agentic RAG로 여러 번 검색하고 판단하는 방향까지 발전하고 있습니다.