웹 개발자를 위한 RAG 기초(1) - Naive RAG 이론(Rag란? Rag 기초, RAG 예시, RAG 챗봇 설계)

안녕하세요! 갓대희 입니다. :- )

 

평소에는 주로 최대한? 내용은 간략하게 가져가고, 실습 위주의 글을 작성하여 컨셉정도의 내용을 전하려는 글을 썼던 것 같다.

이번에는 혼자하는 프로그램이 아닌 조별 진행 프로그램을 참여 하다보니 눈높이가 맞지 않는 상태에서 계속 대화가 오가다보니

비슷한 내용이 계속 무한루프처럼 오간다는 느낌을 받게 되었다. 

그래서 어쩔수 없이 다같이 눈높이를 맞추기 위해 이론 위주의 글을 정리해보려고 하게 되었다.

 

1) 이 글의 목표 : RAG에 대해서 다루지만, 웹개발자의 눈높이에서 맞춰보자.

2) 현재 프로그램 상황 : AWS에서 지원하는 프로그램, 기간은 5주, AWS의 서비스를 활용 하는게 도리이자 의리. 참여자들의 회사는 4개정도로 보인다.

3) 현재 프로그램에서의 초도 목표 : 패션 회사 기준에서의 RAG를 이용하여 서비스를 구축할 수 있는 기반 데이터를 구축 / 즉 상품 데이터에 대한 벡터 디비화. 

4) 추가 아이디어 : 이미 진행중인 검색 기능의 고도화 (상기 백터 디비를 활용)

 

내가 갖고 있는 자원들을 활용하여 RAG에 대해 모든 구성원들이 처음 RAG를 접한다고 가정하고, 구성원들의 눈높이를 맞추려는 취지로 글을 작성해 보려 한다. 

 

RAG가 뭔데? 🤔

RAG는 LLM(거대 언어 모델)이 방대한 양의 내부 데이터에만 의존하여 부정확하거나, 거짓 정보를 생성하는 '환각(hallucination)' 현상을 완화하기 위해 등장한 기술이다. 

 

모델 자체의 매개변수를 확장하거나 재학습하는 대신,

외부 지식 기반에서 관련 정보를 검색하여 LLM에 추가적인 문맥으로 제공함으로써 LLM의 응답 정확도와 신뢰성을 향상시키는 것을 목표로 한다.

 

RAG( Retrieval-Augmented Generation )

검색(Retrieval) + 증강(Augmented) + 생성(Generation)

= "관련 정보를 찾아서 → 질문과 함께 AI에게 주고 → 더 정확한 답변을 생성하게 하는 방법"

즉, RAG (Retrieval-Augmented Generation)는 LLM이 응답을 생성하기 전에 외부 지식원에서 관련 정보를 검색하여 프롬프트에 주입하고, 이를 바탕으로 답변을 완성하는 기술이다. 사실성, 출처성, 최신도를 높이는 것이 핵심 목적이라고 볼 수 있다.

 

1. 인덱싱

→

2. 검색

→

3. 보강

→

4. 생성

 

예를 들어보자. ChatGPT에게 "네이버 클라우드의 최신 AI 서비스가 뭐야?"라고 물어보면, 훈련 데이터 기준일 이후의 정보는 모른다고 답할 가능성이 높다. 하지만 RAG를 사용하면:

RAG 동작 과정

1. 검색: "네이버 클라우드 AI 서비스"와 관련된 최신 문서들을 벡터 DB에서 찾는다.
2. 증강: 찾은 정보를 사용자 질문과 함께 프롬프트에 포함시킨다.
3. 생성: AI가 최신 정보를 바탕으로 정확한 답변을 생성한다.

 

그리고 실습을 위해 이런 예시도 하나 생각 해보려 한다.

단순히 AI, Gemini에게 "갓대희 블로그에 Rag라는 주제가 있을까? 라는것을 물어보면, 학습한적이 없으니 모른다고 한다.

이럴때 실시간으로 바로 검색해서 알아 보는 방법이 있는데, 만약 내 블로그 을이 1만개라면 실시간으로 검색해서 나오려면 크롤링을 통해 가져오려면 몇분, 몇십분이 걸릴수도 있고, 과도한 요청으로 인해 캡챠에 막힐수도 있다. 

이럴 때 Rag를 사용하면 해결 가능해 진다.

 

왜 RAG가 필요할까?

기존 LLM의 한계점들을 RAG가 어떻게 해결하는지 명확하게 이해하는 게 중요하다.

LLM만 사용할 때의 문제점

• 훈련 데이터 이후의 최신 정보를 모름
• 도메인 특화 정보 부족 (우리 회사 내부 자료, 전문 분야 등)
• 할루시네이션 (없는 정보를 그럴듯하게 지어내기)
• 출처나 근거를 제시하지 못함

RAG로 해결되는 부분

• 실시간으로 최신 정보 활용 가능
• 우리만의 도메인 지식 활용 (내 블로그 글, 회사 문서 등)
• 검색된 문서를 기반으로 답변하므로 환상 현상 대폭 감소
• 어떤 문서에서 정보를 가져왔는지 출처 제공 가능

 

RAG 패러다임 (RAG 의 발전 과정)

이 부분은 내 실습과정에 맞게 조금 단계를 더 세분화 하였으니, 공식 자료가 아닌 내 블로그의 실습 단계에 맞춰 AI와 같이 내용을 좀 가공했다고 봐주시면 더 좋을 것 같다.

 

1단계. Naive RAG (~2021)

문서를 청킹하여 임베딩 벡터로 변환한 후 벡터 데이터베이스에 저장하고, 사용자 쿼리와의 유사도 검색을 통해 관련 문서 조각을 찾아 LLM에 전달하는 가장 기본적인 RAG 형태.
구현이 단순하고 빠르게 프로토타입을 만들 수 있지만, 단일 벡터 검색만 사용하여 검색 정확도에 한계가 있고, 청킹 전략이나 검색 결과 품질 검증이 부족한 특징을 가진다.

2단계. Enhanced RAG (2021~)

검색 성능을 개선하기 위한 다양한 기법들이 도입된 단계.
벡터 검색과 키워드 검색을 결합한 하이브리드 검색을 통해 의미적 유사성과 어휘적 일치를 동시에 고려하고, 검색된 결과를 재순위화하는 리랭킹 기법으로 가장 관련성 높은 문서를 우선 선별한다. 또한 쿼리 확장이나 개선 기법을 통해 사용자 질문의 의도를 더 정확히 파악할 수 있게 되었다.

3단계. Modular RAG (2022~)

RAG 파이프라인의 각 구성 요소를 모듈화하고, 상황에 따라 동적으로 조합할 수 있게 발전한 단계.
복잡한 질문을 여러 하위 질문으로 분해하여 단계별로 처리하거나, 생성된 답변의 품질을 검증하여 필요시 추가 검색이나 수정을 수행하는 등 보다 정교한 제어가 가능해졌다.각 모듈의 독립적 최적화를 통해 전체 시스템의 유연성과 성능이 향상되었다.

4단계. Agentic RAG (2023~)

텍스트 문서를 넘어 구조화된 데이터 소스까지 활용하여 지식의 범위를 확장한 단계.
데이터베이스 쿼리 생성을 통한 정확한 수치 정보 검색, 지식 그래프를 활용한 복잡한 관계 정보 파악, 그리고 여러 도구를 연계하여 사용하는 에이전트 기반 접근법이 특징. 이를 통해 단순한 텍스트 검색을 넘어 다양한 형태의 지식을 종합적으로 활용할 수 있게 되었다.

 

 

이 4단계중, 이번 글은 1단계 : Naive RAG를 목표, 타게팅으로 진행해보면 좋을 것 같다.

 

Naive RAG란?

RAG 시스템을 처음 접하면 가장 기본적인 형태인 'Naive RAG'부터 이해하게 된다.

Naive란 "단순한, 초기 단계의, 기본적인"이라는 뜻으로 "아주 단순하게 구현된 Retrieval-Augmented Generation"이라는 뜻 정도로 이해하면 된다. 

 

즉, 기초단계의 RAG... 어찌보면 RAG의 근본이 되는 개념이니, 이 부분을 내 블로그 챗봇을 만든다는 가정을 통해 실제 예시를 통해 이해해보려 한다. 

 

하기 내용이 가장 기초적인 Naive RAG의 흐름이라고 생각한다. 이 흐름을 토대로 글을 이어 가보자.

Naive RAG : RAG(Retrieval-Augmented Generation)의 가장 기본적인 구현 방식으로, Indexing → Retrieval → Generation의 3단계를 순차적으로 처리하는 직선적 파이프라인이다.

 

Naive RAG 개요
RAG(Retrieval-Augmented Generation)의 가장 기본적인 구현 방식으로,
1단계 : Indexing →
2단계 : Retrieval →
3단계 : Generation의 3단계를 순차적으로 처리하는 직선적 파이프라인이다.

이 3가지 단계를 다음과 같은 가정, 예시로 진행해 보자.

 

ex) 갓대희의 작은 공간 블로그 Rag 구축 해보기

이론만 알아서는 재미없을 것 같다. 실제로 내 블로그의 AI 관련 포스팅들을 활용해서 RAG를 활용하고 이를 통해 챗봇을 만들어보았다. 이 예시를 통해 좀더 설명이 잘되면 좋을텐데................. 헛수고일까 걱정이다.

 

일단, 목표는 "내 블로그 AI 카테고리에 대해 뭐든 물어보세요!"라고 할 수 있는 챗봇이다.

구축할 챗봇의 전체적인 아키텍처 설꼐

1. 데이터 수집: 내 블로그 AI 카테고리 글들을 크롤링
2. 전처리: 텍스트 청킹(작은 단위로 분할)
3. 벡터화: 임베딩 모델로 텍스트를 벡터로 변환
4. 저장: 벡터 데이터베이스에 저장
5. 검색 + 생성: 워크플로우 구축

 

1단계: Indexing (인덱싱) 

RAG의 첫 번째 단계인 인덱싱은 Raw Data를 AI가 이해할 수 있는 형태로 변환하는 과정이다. 이 과정에서 여러 중요한 처리 단계들이 진행된다.

인덱싱 처리 과정

1. 데이터 추출: PDF, HTML, Word 등 다양한 파일 형식을 표준화된 plain text로 변환
2. 텍스트 청킹(Chunking): LLM의 토큰 제한을 고려해 큰 문서를 작고 관리 가능한 단위로 분할
3. 벡터 임베딩: Embedding Model을 통해 텍스트 청크들을 벡터로 표현
4. 벡터 저장: 벡터화된 청크를 Vector DB에 키-값 쌍으로 저장

여기서 벡터와 임베딩이라는 용어가 낯선 분ㄷ르이 많이 계실텐데 자세히 다루기엔 무거워 지는 주제이고, 별도의글에서 자세히 다루고 지금은 간단히 큰 맥락에서의 내용만 정리해보는것으로 대체하는것이 좋을 것 같다. 

 

임베딩(Embedding) : 컴퓨터가 텍스트의 의미를 숫자로 이해할 수 있게 변환하는 과정이다. "강아지"라는 단어를 [0.2, 0.8, 0.1, ...] 같은 숫자 배열로 바꿔주는 것이라고 볼 수 있다.

 

벡터(Vector) : 임베딩을 통해 만들어진 숫자 배열을 벡터라고 부른다. 의미가 비슷한 단어들은 비슷한 숫자 패턴을 가지게 된다.

"강아지"와 "개"는 비슷한 벡터를, "강아지"와 "자동차"는 다른 벡터를 갖게 되죠.

 

왜 필요한가? : 컴퓨터는 "강아지"와 "개"가 비슷한 의미라는 걸 모른다. 하지만 벡터로 변환하면 두 단어의 숫자 패턴이 비슷해져서 컴퓨터가 "아, 이 둘은 관련있구나!"라고 이해할 수 있게 된다고 이해하고 넘어가자. 

Vector DB의 역할

구축된 Vector DB는 이후 Retrieval 단계에서 효율적이고 확장 가능한 검색 기능을 제공하는 핵심 저장소 역할을 한다. 의미 기반 유사도 검색을 통해 관련 정보를 빠르게 찾아낼 수 있게 해준다.

 

ex) 1. 데이터 추출 

 - 나는 상기 예시에서 HTML을 plain text로 변환 하는 과정을 해야 할 것 이다. 다음과 같은 workflow로 작업을 해보려고 한다.

 

step1 : 먼저 AI카테고리글 리스트를 추출

 

step2 : 크롤링을 통해 html을 가져오고

 

step3 : 이중 불필요한 html태그는 제외, 실제 본문의 글들만 가져 오려고 한다.

 

ex) 2. 텍스트 청킹(Chunking)

 - NaiveRag수준으로 진행하기 위해 단순히 글자수(사실은 토큰이지만 완전 초심자의 눈높이로 일단 글자수로 표현)로 잘라보는게 낫겠다는 생각이다.

(청킹 전략을 잘세우면 퀄리티가 올라가지만, 일부러 이 단계에서는 시행착오를 발생시키기 위해 고급 청킹 기술은 다 빼자.)

 - 한줄로 이어져있던 본문이 다음과 같은식으로 여러줄/N개의 Rows로 나누어 진다고 보면 될 것 같다.

1
2

 

ex) 3. 벡터화 : 임베딩 모델로 텍스트를 벡터로 변환

 - 어떤 AI를 사용하고, 어떤 벡터 DB를 사용하고는 당장은 내가 임의로 진행 하였다. 

 - 이후 이 여러가지 벡터 디비, 임베딩 모델의 trade off에 따라 결정할 수 있는 데이터는 별도로 포스팅 하도록 할 예정이다. (이후 링크 연결)

 - 지금은 다음 환경으로 작업을 진행 하였다.

벡터 데이터 베이스 : PostgreSQL의 확장 기능인 pgvector
임베딩 모델 : OpenAI의 text-embedding-3-small 모델

 

 - Input 예시

 

 - Output 예시

 

 ex) 4. 벡터 저장 : 저장 결과 예시

 

2단계: Retrieval (검색)

사용자 쿼리가 들어오면 외부 지식 소스인 Vector DB로부터 관련 문맥을 검색하는 단계이다.

이 과정은 의미 기반 검색의 핵심이라고 할 수 있다.

검색 처리 흐름

1. 쿼리 벡터화: 사용자 쿼리를 인코딩 모델을 통해 처리하여 의미적 임베딩 생성
2. 유사도 검색: 벡터화된 쿼리로 Vector DB에서 유사성 기반 상위 k개 검색 수행
3. 관련 데이터 추출: 가장 유사한 의미를 가진 데이터 청크들을 검색 결과로 반환

💡 의미 기반 검색의 장점
기존의 키워드 기반 검색과 달리, 의미적으로 관련된 내용을 찾을 수 있다. 예를 들어 "머신러닝"이라고 검색해도 "기계학습"이나 "AI 모델"과 관련된 내용을 찾아낼 수 있다.

 

ex) 1. 쿼리 벡터화

 - 내 블로그에 "MCP"에 대한 글이 어떤것들이 있는지 궁금하다. 

 - GPT처럼 채팅 모델을 통해 "MCP"라는 것을 물어보자. 

 

 - 이 단어를 컴퓨터가 이해할 수 없으니 Embedding을 시키도록 하자. (질문을 임베딩할때에도 동일한 OpenAI의 text-embedding-3-small 모델을 사용할 것 이다.)

 - mcp르 벡터화 시킨 데이터의 일부이다.

 

ex) 2. 유사도 검색 + 3.관련 데이터 추출

 - 벡터화한 쿼리를 던져 N개의 데이터를 가져 오게 된다.

 

3단계: Generation (답변 생성)

마지막 단계에서는 사용자의 원래 쿼리와 검색된 추가 정보를 결합하여 LLM이 최종 답변을 생성한다.

⚡ 답변 생성 과정

1. 프롬프트 구성: 사용자 쿼리 + 검색된 컨텍스트 정보를 하나의 프롬프트로 결합
2. LLM 처리: 구성된 프롬프트를 LLM에 입력하여 처리
3. 답변 생성: 외부 지식을 바탕으로 한 정확하고 관련성 높은 답변 출력

ex) 이때 사용함 시스템 프롬프트는 참고

 

 ex) 최종 답변 생성 예시

 

이 흐름을 전체적으로 요약하면 다음과 같은 워크 플로우이다.

 - Naive RAG의 관점에서의 Flow

 

 - 챗봇 관점에서의 Flow

 

최종 결과물 : 이를 front개발 처리하여 챗봇으로 활용 

ex) 나의 경우 우측 하단에 챗봇, 위젯에 연동 하였다. > 클릭 후 MCP 라고 질의

 

ex) 응답 예시 : 간단한 설명과 함께, 해당 글의 링크를 안내 하도록 하였다.

 

 ****** 최대한 내 블로그를 활용해서 이해에 도움이 되도록 예시를 만들어 보았는데, 보완이 필요한 부분들은 댓글 남겨주시면 보완할 수 있도록 해보겠습니다.! 얼마든지 ㅠ 보완해야하는점들 알려주십셔!! ******

 

 - 이로써 Naive RAG에 대해서 이해하는 내용은 작성 완료 하였고, 왜 2단계, 3단계등 가계되는 한계점들에 대해서 까지만 작성 해두고 마무리 하려고 한다. 

 

Naive RAG의 주요 문제점들

단순해 보이는 Naive RAG 방식이지만, 실제 운영 환경에서는 여러 한계점들이 드러난다. 각 단계별로 어떤 문제들이 발생하는지 살펴보자.

1. Indexing 단계의 문제점

정보 추출의 불안정성
PDF와 같은 비정형 파일 내 이미지와 표에 있는 유용한 정보를 효과적으로 처리하지 못한다. 시각적 정보나 구조화된 데이터가 손실되어 정보의 완성도가 떨어진다.

One-Size-Fits-All 청킹 방법
청킹 과정에서 파일 유형의 특성을 고려하지 않고 동일한 방식을 적용하는 것이 대부분이다. 이로 인해 각 청크에 일관성이 부족하고 불필요한 정보가 포함되며, 원본 텍스트의 문단 구분과 중요한 세부 사항을 놓치게 된다.

비최적화 인덱싱 구조
인덱싱 구조가 최적화되지 않아 비효율적인 검색 기능을 초래한다. 이는 검색 속도를 현저하게 느리게 만들고 검색 결과의 정확성을 떨어뜨린다.

임베딩 모델의 의미 표현 능력 한계
임베딩 모델이 텍스트의 의미를 제대로 파악하지 못해 검색된 정보의 관련성이 낮아진다. 이는 중요한 정보를 놓칠 수 있는 결과를 가져온다.

2. Retrieval 단계의 문제점

 제한된 검색 알고리즘
키워드, 의미, 벡터 검색을 결합하지 않는 등 다양한 검색 알고리즘의 통합이 제한적이다. 이는 검색 결과의 다양성과 정확성을 저하시킨다.

쿼리 및 임베딩 모델의 한계
쿼리 처리가 부족하거나 임베딩 모델의 의미 표현 성능이 낮아서 유용한 정보를 제대로 검색하지 못한다.

답변 정보 중복
여러 검색된 컨텍스트가 유사한 정보를 포함하여 생성된 답변에 반복적인 내용이 포함되는 문제가 발생한다.

3. Generation 단계의 문제점

잘못된 응답 생성
LLM이 관련 없거나 편향된 응답을 생성할 가능성이 높다. 입력된 컨텍스트를 제대로 활용하지 못하고 부적절한 답변을 만들어낼 수 있다.

잘못된 정보 제공
유용한 정보를 제공하지 않고 검색된 내용을 단순히 반복하는 결과를 초래할 수 있으며, 일관성 없는 답변을 생성하는 경우가 발생한다.

 

문제점 요약 및 개선 방향 

Naive RAG의 각 단계별 문제점들을 정리해보면, 단순한 선형 처리 방식의 한계가 드러난다. 이러한 문제들을 해결하기 위해서는 보다 정교한 접근법이 필요하다.

단계	주요 문제점	재선 방향
Indexing	정보 손실, 단순 청킹, 비효율적 구조	스마트 청킹, 멀티모달 처리
Retrieval	제한된 알고리즘, 중복 정보	하이브리드 검색, 리랭킹
Generation	부정확한 답변, 일관성 부족	프롬프트 최적화, 답변 검증

✅ Advanced RAG로의 발전
이러한 문제점들을 해결하기 위해 Advanced RAG 기법들이 개발되었다. 각 단계별로 더욱 정교한 처리 방법과 최적화 기법들을 도입하여 전반적인 성능을 대폭 개선할 수 있다.