RAG의 진화, 더 똑똑한 AI를 만드는 여정

요즘 ChatGPT를 비롯한 거대 언어 모델(LLM)들이 놀라운 능력을 보여주고 있지만, 여전히 해결해야 할 숙제가 있습니다. 바로 ‘최신 정보’와 ‘정확한 사실’에 대한 문제죠. 예를 들어, GPT에게 “어제 발표된 삼성전자 실적은?”이라고 물으면 당황스러운 답변을 받게 됩니다. 학습 데이터가 특정 시점에서 멈춰있기 때문이에요. 또한 때로는 그럴듯하지만 완전히 틀린 정보를 자신있게 말하는 ‘환각(Hallucination)’ 현상도 보입니다.

이런 한계를 극복하기 위해 등장한 것이 바로 **RAG(Retrieval-Augmented Generation)**입니다. 쉽게 말해, AI가 대답하기 전에 먼저 관련 자료를 찾아보고 답하는 방식이죠. 마치 우리가 모르는 걸 물어봤을 때 “잠깐, 검색해볼게”라고 하는 것과 비슷합니다.

가장 단순한 시작: Naive RAG#

RAG의 가장 기본적인 형태인 Naive RAG부터 살펴볼까요? 이름에서 알 수 있듯이 ‘순진한’ 접근 방식입니다.

동작 원리는 정말 간단합니다. 먼저 모든 문서를 일정한 크기로 잘라서(이를 ‘청킹’이라고 합니다) 각각을 숫자 벡터로 변환해 저장해둡니다. 마치 도서관에서 책을 분류 번호로 정리하는 것처럼요. 사용자가 질문하면, 그 질문도 같은 방식으로 벡터로 바꾸고, 가장 비슷한 문서 조각들을 찾아옵니다. 그리고 이 조각들을 LLM에게 “이 자료를 참고해서 답변해줘”라고 함께 전달하는 거죠.

이 방식의 매력은 구현이 정말 쉽다는 점입니다. 파이썬으로 수십 줄이면 기본적인 RAG 시스템을 만들 수 있어요. 그래서 많은 기업들이 처음 AI 챗봇을 만들 때 이 방식으로 시작합니다. “우리 회사 휴가 정책 알려줘” 같은 단순한 FAQ 챗봇에는 충분히 효과적이거든요.

하지만 한계도 명확합니다. 문서를 기계적으로 자르다 보니 중요한 문맥이 끊기는 경우가 많아요. 예를 들어 “이에 따라 정부는…”으로 시작하는 문장이 있다면, ‘이’가 무엇을 가리키는지 알 수 없게 되죠. 또한 단순히 의미적으로 비슷한 것만 찾다 보니, 실제로는 관련 없는 내용을 가져오는 경우도 있습니다. “사과”를 검색했는데 과일 사과와 사죄의 사과가 섞여서 나오는 식이죠.

한 단계 진화: Advanced RAG#

Naive RAG의 이런 문제점들을 개선하기 위해 Advanced RAG가 등장했습니다. 핵심은 ‘검색의 정확도를 높이자’는 것이에요.

가장 눈에 띄는 개선점은 하이브리드 검색입니다. 기존에는 의미적 유사성만 봤다면, 이제는 키워드 매칭도 함께 고려합니다. 마치 네이버나 구글이 검색할 때 여러 알고리즘을 조합하는 것처럼요. BM25 같은 전통적인 키워드 검색과 벡터 검색을 함께 사용해서, “2024년 반도체 시장 전망”처럼 특정 연도나 고유명사가 중요한 검색에서 훨씬 정확한 결과를 얻을 수 있게 되었습니다.

또 하나의 혁신은 쿼리 변환 기법입니다. 특히 재미있는 건 HyDE(Hypothetical Document Embeddings)라는 방식인데요. 사용자가 “파이썬으로 파일 읽는 방법”을 물으면, 먼저 AI가 “파이썬에서 파일을 읽으려면 open() 함수를 사용합니다…”라는 가상의 답변을 만들어냅니다. 그리고 이 가상 답변과 비슷한 실제 문서를 찾는 거죠. 질문보다는 답변 형태의 문서가 데이터베이스에 더 많기 때문에 이 방법이 의외로 효과적입니다.

**리랭킹(Reranking)**도 중요한 개선점입니다. 처음 검색으로 관련 있을 법한 문서 100개를 대충 가져온 다음, 더 정교한 모델로 다시 한 번 평가해서 진짜 관련 있는 10개만 추려내는 방식이죠. 마치 채용 과정에서 서류 전형 후 면접을 보는 것과 비슷합니다.

문서를 자르는 방식도 똑똑해졌습니다. 기계적으로 500자씩 자르는 대신, 문장의 의미를 파악해서 자연스러운 단위로 나눕니다. 또한 작은 조각으로 검색하되, 실제 답변할 때는 그 조각이 포함된 더 큰 문서를 통째로 제공하는 ‘Parent Document Retriever’ 같은 기법도 사용합니다.

이런 개선들 덕분에 Advanced RAG는 훨씬 정확한 답변을 제공할 수 있게 되었습니다. 다만 대가도 있죠. 처리 시간이 길어지고 비용도 증가합니다. 하지만 “최근 반도체 시장 동향에 대해 A 보고서와 B 뉴스를 종합해서 알려줘”처럼 여러 소스를 참고해야 하는 복잡한 질문에는 이 정도 투자가 충분히 가치 있습니다.

궁극의 유연성: Modular RAG#

그런데 말이죠, 모든 질문이 똑같은 처리 과정을 거쳐야 할까요? “오늘 날씨 어때?”와 “테슬라를 창업한 사람의 출신 국가의 GDP는?”이 같은 방식으로 처리되는 건 비효율적이잖아요. 이런 문제의식에서 출발한 것이 Modular RAG입니다.

Modular RAG의 핵심은 동적 실행입니다. AI가 먼저 질문을 분석해서 “이건 단순 검색이면 되겠네” 또는 “이건 여러 단계의 추론이 필요하겠는데?”라고 판단합니다. 그리고 필요한 모듈들을 레고 블록 조립하듯 연결해서 최적의 처리 경로를 만들어냅니다.

예를 들어 “테슬라를 창업한 사람의 국적은?”이라는 질문을 받으면, AI는 이게 다단계 추론이 필요하다고 판단합니다. 먼저 “테슬라 창업자”를 검색해서 “일론 머스크”라는 정보를 얻고, 다시 “일론 머스크 국적”을 검색해서 최종 답을 찾아내죠. 이런 과정이 자동으로 이루어집니다.

더 놀라운 건 자기 수정(Self-Correction) 기능입니다. 답변을 생성한 후 스스로 “이 답변이 충분한가? 근거가 확실한가?”를 평가합니다. 만약 부족하다고 판단하면 다른 키워드로 다시 검색하거나, 다른 데이터베이스를 뒤지기도 합니다. 마치 신중한 연구원이 논문을 쓰면서 계속 자료를 찾고 검증하는 것처럼요.

Modular RAG는 벡터 검색뿐만 아니라 SQL 데이터베이스, 지식 그래프, API 호출 등 다양한 도구를 필요에 따라 활용할 수 있습니다. 예를 들어 “우리 회사 올해 매출 중 해외 비중은?”이라는 질문에는 SQL 쿼리를, “아인슈타인과 보어의 관계는?”이라는 질문에는 지식 그래프를 사용하는 식이죠.

이런 유연성은 특히 복잡한 대화형 AI나 리서치 어시스턴트를 만들 때 빛을 발합니다. 사용자와의 대화 맥락을 기억하고, 이전 질문과 연결해서 생각하며, 필요하면 여러 출처를 종합해서 심도 있는 분석을 제공할 수 있거든요.

실무에서 마주치는 선택의 순간#

자, 이제 여러분이 실제로 RAG 시스템을 구축한다고 해봅시다. 성능이 기대에 못 미칠 때, LLM 자체를 파인튜닝해야 할까요, 아니면 검색 시스템을 개선해야 할까요?

대부분의 경우, 검색 시스템 개선이 먼저입니다. 이유는 간단해요. 첫째, 비용 대비 효과가 훨씬 좋습니다. LLM 파인튜닝은 많은 데이터와 컴퓨팅 자원이 필요하지만, 검색 시스템 개선은 상대적으로 적은 비용으로 큰 효과를 볼 수 있어요. 둘째, 유연성이 높습니다. 새로운 문서가 추가되면 바로 검색 대상에 포함시킬 수 있지만, 파인튜닝된 모델은 재학습이 필요하죠.

특히 최신 정보가 중요하거나, 답변의 근거를 명확히 제시해야 하거나, 여러 도메인을 다루는 경우라면 검색 시스템 개선이 정답입니다. 회사 내부 문서 검색 챗봇, 뉴스 기반 QA 시스템, 법률 자문 AI 등이 좋은 예시죠.

반대로 LLM 파인튜닝이 필요한 경우도 있습니다. 특정 분야의 전문 용어를 정확히 이해하고 사용해야 하거나, 독특한 문체나 형식을 따라야 할 때입니다. 의료 차트 작성 AI, 특정 브랜드의 톤앤매너를 지켜야 하는 마케팅 카피 생성기 등이 이에 해당합니다.

마치며#

RAG의 진화 과정을 보면, 결국 ‘더 똑똑하게 정보를 찾고 활용하는 방법’을 고민하는 여정임을 알 수 있습니다. Naive RAG의 단순함에서 시작해, Advanced RAG의 정교함을 거쳐, Modular RAG의 유연함에 이르기까지, 각 단계마다 실제 문제를 해결하기 위한 혁신이 있었죠.

앞으로 RAG는 어떻게 진화할까요? 아마도 더욱 지능적인 에이전트 형태로 발전하면서, 단순히 정보를 찾는 것을 넘어 능동적으로 지식을 구성하고 추론하는 방향으로 나아갈 것 같습니다. 또한 멀티모달 RAG, 실시간 스트리밍 RAG 등 새로운 형태도 등장하겠죠.

중요한 건, 여러분의 문제에 맞는 적절한 수준의 RAG를 선택하는 것입니다. 모든 문제에 Modular RAG가 필요한 건 아니니까요. 때로는 심플한 Naive RAG로도 충분할 수 있습니다. 기술의 화려함보다는 실제 사용자의 니즈를 충족시키는 것이 더 중요하다는 점, 잊지 마세요.