Reconsidered RAG(RRAG)라는 오픈소스 프로젝트가 어떤 질문에서 시작해서, 어떤 답에 도달했는지를 이야기합니다.
요즘 ChatGPT, Claude 같은 AI에게 질문하면 꽤 그럴듯한 답이 돌아옵니다. 하지만 이 AI들이 가진 근본적인 한계가 하나 있습니다. 학습이 끝난 시점 이후의 정보를 모른다는 것입니다. 어제 발표된 회사 내부 보고서, 지난달에 바뀐 사내 규정—이런 것은 아무리 똑똑한 AI라도 알 수 없습니다.
그래서 등장한 개념이 RAG(Retrieval-Augmented Generation), 우리말로 하면 "검색 증강 생성"입니다. AI가 답변을 만들기 전에 관련 문서를 먼저 찾아보게 하는 것입니다. 마치 시험 때 오픈북을 허용하는 것과 비슷합니다. AI의 머리(모델)는 그대로 두되, 참고할 수 있는 자료(검색 결과)를 함께 주는 방식입니다.
대부분의 RAG 시스템은 이런 흐름으로 동작합니다:
- 회사 문서를 잘게 자른다 (청킹)
- 잘린 조각들을 숫자 벡터로 변환한다 (임베딩)
- 사용자가 질문하면, 질문과 가장 비슷한 조각을 찾는다 (검색)
- 찾은 조각을 AI에게 "참고해"라고 함께 넘긴다 (생성)
간단해 보입니다. 실제로 많은 회사가 이 방식으로 사내 AI 시스템을 만들고 있습니다. 그런데 여기에 생각보다 까다로운 문제들이 숨어 있습니다.
Reconsidered RAG, 줄여서 RRAG라는 프로젝트는 거창한 이론에서 시작하지 않았습니다.
시작은 이런 경험이었습니다: RAG 시스템을 만들면서 "이 임베딩 모델 대신 다른 걸 써볼까?" 하고 모델을 바꿨더니, 보유한 문서 전체를 다시 잘게 자르고, 다시 벡터로 변환해야 했습니다. 수 시간이 걸리는 작업이 모델을 바꿀 때마다 처음부터 반복된 것입니다.
이때 든 생각이 있었습니다:
"벡터로 바꾸기 직전의 텍스트만이라도 따로 저장해두면, 자르는 과정은 건너뛰고 임베딩만 다시 하면 되지 않을까?"
아주 실용적인 발상이었습니다. 그리고 이 작은 발상이 예상치 못한 방향으로 계속 확장되었습니다.
텍스트를 따로 보존하고 나니, 그다음 질문이 자연스럽게 떠올랐습니다. "이 텍스트를 만드는 과정 자체도 다르게 할 수 있지 않을까?"
기존에는 임베딩 모델이 문서의 의미 흐름을 분석해서 자동으로 자르는 방식(시맨틱 청킹)이 주류였습니다. GPU가 달린 서버에서 모델을 돌려야 하는, 상당히 무거운 작업입니다.
그런데 생각해보면, 문서를 자르는 방법은 이것만 있는 게 아닙니다. 마크다운 문서의 제목 구조(# 제목, ## 소제목)를 기준으로 잘라도 되고, 데이터베이스 테이블의 행 단위로 잘라도 됩니다. AI를 전혀 쓰지 않는 방법도 충분히 유효합니다.
핵심은 이것이었습니다: 문서를 어떻게 자르는가는 기술적 기본값이 아니라, 운영자가 내리는 설계 결정이다. 각 방법마다 장단점이 다르고, 어떤 방법을 선택했는지에 따라 나중에 AI가 받아보는 자료의 품질이 완전히 달라집니다.
여기서 한 걸음 더 나아가는 깨달음이 있었습니다.
문서를 자르는 것뿐 아니라, 문서의 내용 자체를 AI로 요약하거나 재구성한 뒤 RAG 소스로 쓸 수도 있습니다. 원본 문서 100페이지를 요점 정리한 10페이지로 바꿔서 RAG에 넣을 수 있다는 것입니다.
이것이 가능하다면, RAG 시스템이 실제로 제공하는 것은 원본 문서 자체가 아닙니다. 원본에서 가공된 지식을 제공하는 것입니다.
이 차이는 생각보다 큽니다.
전통적인 검색 엔진에서는 원본 문서가 곧 결과입니다. 구글에서 검색하면 원본 웹페이지로 이동합니다. 하지만 RAG 시스템에서 원본은 지식을 만들기 위한 원재료입니다. 요리에 비유하면, 원본 문서는 식재료이고, RAG가 제공하는 것은 요리된 음식입니다. 식재료가 어디서 왔는지 추적하는 것은 중요하지만, 손님에게 나가는 것은 식재료가 아니라 요리입니다.
그렇다면 질문이 하나 더 생깁니다: 이 "요리"에 누구의 의도가 반영되어야 하는가?
이 질문에 대한 답은 의외의 곳에서 왔습니다.
AI 기반 서비스를 만들면서 "어떻게 하면 의미 있는 콘텐츠를 만들 수 있을까"를 고민하던 중이었습니다. 이른바 "슬롭(slop)"—AI가 자동으로 대량 생성한 것처럼 보이는, 그럴듯하지만 실제로는 아무런 깊이가 없는 콘텐츠—이 아닌, 진짜 가치 있는 자료를 어떻게 확보할 것인가.
관찰 끝에 하나의 패턴이 보였습니다. 가장 밀도 있는 자료는 잘 정리된 보고서나 위키 문서가 아니었습니다. 어떤 주제에 관심을 가진 사람이 AI와 나눈 대화 기록이었습니다.
왜 그럴까요? 사람이 AI와 대화할 때, 단순히 정보를 받아 적는 것이 아니기 때문입니다.
자신이 궁금한 것을 질문합니다. AI의 답변 중 마음에 드는 부분을 더 파고듭니다. 동의하지 않는 부분에는 반론을 제기합니다. 관심 없는 주제는 건너뜁니다. 자기만의 언어로 결론을 정리합니다.
이 과정에서 만들어지는 대화 세션에는 그 사람만의 "의도"라는 지문이 선명하게 찍혀 있습니다. 어떤 질문을 먼저 했는지, 어디를 깊이 파고들었는지, 무엇을 무시했는지—이 모든 것이 그 사람이 무엇을 중요하게 여기는지를 담고 있습니다.
이런 대화 세션은 단순한 채팅 로그가 아닙니다. 사람의 사고 과정이 기록된 고유한 지식 자산입니다. 그리고 이것은 어떤 문서도 대체할 수 없는 종류의 자료입니다.
이 네 단계의 발견—벡터 재계산의 비효율, 청킹의 다양성, 원본의 참조 자료 성격, 대화 세션의 가치—을 관통하는 하나의 결론이 있습니다.
RAG 시스템의 핵심 활동은 검색이 아닙니다. 지식을 만들어내는 것입니다.
검색은 만들어진 지식을 전달하는 수단이고, 임베딩은 그 지식을 정리하는 기법이며, 청킹은 준비 전략일 뿐입니다. 진짜 중요한 것은 RAG 시스템이 제공하는 지식이 어디서 왔는지, 어떻게 만들어졌는지, 그리고 누구의 의도가 반영되어 있는지입니다.
RRAG는 바로 이 "지식 생산 과정"을 눈에 보이게, 검사할 수 있게, 그리고 운영자가 책임질 수 있게 만드는 것을 목표로 합니다.
여기서 한 가지 중요한 질문이 남습니다.
아무리 좋은 지식을 준비해도, AI가 그 범위를 넘어서 답변하면 의미가 없습니다. "사내 인사 규정에 대해서만 답해"라고 해놓았는데 AI가 일반 상식까지 섞어서 답하면, 그 답변의 신뢰성은 사라집니다.
처음에 이 "거절" 문제를 풀기가 어려웠습니다. AI 모델은 이미 완성된 블랙박스입니다. RAG가 있다고 해서 AI 모델 자체를 고칠 수 있는 것이 아닙니다. "범위 밖이면 답하지 마세요"라는 지시를 프롬프트에 넣을 수는 있지만, AI가 이 지시를 100% 따를 거라는 보장은 없습니다.
해답은 구조를 바꾸는 것에 있었습니다.
AI에게 자료를 미리 주입하는 대신, AI가 필요할 때 도구를 호출하게 만드는 것입니다. MCP(Model Context Protocol)나 tool calling이라고 불리는 메커니즘입니다.
이 구조에서는 AI가 "이 주제에 대해 자료를 찾아줘"라고 도구에 요청합니다. 그러면 도구가 먼저 판단합니다: "이 질문은 우리가 허용한 범위 안인가?" 범위 밖이면 도구가 직접 "이 질문에는 답할 수 없습니다"라고 반환합니다. AI는 도구가 돌려준 것만 가지고 답변을 만듭니다.
거절의 책임이 AI라는 블랙박스가 아니라, 운영자가 코드로 통제하는 도구 계층에 있게 되는 것입니다. "답하지 마"라는 희망 사항이 아니라, "답할 수 없다"라는 구조적 제약이 되는 것입니다.
정리하면, Reconsidered RAG가 다루는 문제와 제안은 이렇습니다:
"RAG를 만들 때 무엇을 고민해야 하는가?"
첫째, 지식을 어떻게 준비할 것인가. 문서를 자르는 방법은 하나가 아닙니다. AI를 쓸 수도, 쓰지 않을 수도 있습니다. 중요한 것은 그 선택을 의식적으로 하고, 결과를 눈으로 확인할 수 있어야 한다는 것입니다.
둘째, 어떤 자료를 지식의 소스로 인정할 것인가. 기존 문서만이 아니라, 사람이 AI와 나눈 대화—그 사람의 의도가 구조 속에 담긴 대화—도 강력한 지식 소스가 될 수 있습니다.
셋째, AI가 범위를 넘지 않도록 어떻게 보장할 것인가. "답하지 마"라는 프롬프트 지시가 아니라, 도구 계층에서 구조적으로 경계를 집행해야 합니다.
그리고 이 모든 과정에서 가장 중요한 원칙: 책임은 AI가 아니라 운영자에게 있습니다. 어떤 문서를 넣을지, 어떻게 가공할지, 어디까지 답하게 할지—이 결정들은 모두 사람이 내리는 것이고, RRAG는 그 결정이 눈에 보이고, 검사 가능하고, 추적 가능하도록 만드는 것을 지향합니다.
Reconsidered RAG는 오픈소스 프로젝트로 공개되어 있습니다.
- GitHub: github.com/rkttu/reconsidered_rag
- 라이선스: Apache License 2.0
이 프로젝트는 빠른 배포를 위한 것이 아니라, 배포하기 전에 한 번 더 생각하게 만들기 위한 것입니다. RAG 시스템을 만들고 있거나 만들 계획이 있다면, 한 번 들여다보시길 권합니다.