RAG를 도입했는데 "어려운 질문엔 엉뚱한 답을 한다"는 말을 들었다면, 다음에 고를 수 있는 길은 두 가지입니다
RAG는 질문이 올 때마다 문서를 한 번 찾아 붙여 주는 방식입니다. 간단하고 저렴해서 기업 AI의 표준 출발점이 됐습니다. 그런데 한 번만 찾고, 조각만 보고, 매번 처음부터 찾는다는 세 가지 벽이 있습니다. 이 벽을 넘는 방법이 두 갈래로 나뉘었습니다. 찾는 방법을 AI가 직접 운전하게 하는 에이전틱 RAG, 그리고 질문이 오기 전에 AI가 미리 정리해 두는 LLM 위키입니다. 하나는 "더 잘 찾기", 다른 하나는 "찾을 필요를 줄이기"입니다.
시험을 앞둔 학생 세 명을 떠올려 보세요. 셋 다 교과서를 들고 시험장에 들어갈 수 있습니다. 차이는 언제, 얼마나 공부하느냐입니다.
문제를 읽고 교과서 색인에서 가장 비슷한 쪽을 펼쳐 답을 씁니다. 빠르지만 첫 쪽이 틀리면 그대로 틀립니다.
문제를 쪼개 여러 쪽을 찾아보고, 답이 부족하면 다른 단어로 다시 찾습니다. 정확하지만 시간이 걸립니다.
수업이 끝날 때마다 노트를 고쳐 둡니다. 시험장에서는 노트를 봅니다. 노트를 잘못 쓰면 틀린 채로 외웁니다.
세 학생 모두 "교과서를 들고 들어간다"는 점은 같습니다. AI가 모델 바깥의 자료를 보고 답한다는 RAG의 기본 생각은 그대로이고, 자료를 다루는 시점과 횟수만 다릅니다.
RAG의 기본 흐름은 단순합니다. 질문을 받으면 문서 더미에서 가장 비슷한 조각 몇 개를 찾고, 그 조각을 질문과 함께 AI에게 넘겨 답을 쓰게 합니다. 사내 규정을 묻는 질문처럼 답이 한 문서 한 곳에 있는 질문에서는 이 방식이 잘 통합니다. 문제는 질문이 조금만 복잡해져도 드러납니다.
검색은 질문 하나에 한 번입니다. 질문의 표현과 문서의 표현이 다르면 엉뚱한 조각을 가져오고, AI는 그 조각으로 그럴듯한 답을 만듭니다.
"휴가비 지원" 을 물었는데 규정집에는 "복리후생 보조금"으로 적혀 있는 경우
가져오는 것은 문서 전체가 아니라 비슷한 문단 몇 개입니다. 여러 문서를 견줘야 답이 나오는 질문에 약합니다.
"지난 3년 동안 A사와의 계약 조건이 어떻게 바뀌었나?" 처럼 계약서 세 건을 비교해야 하는 질문
어제 누군가 같은 질문으로 좋은 답을 얻었어도 그 이해는 어디에도 남지 않습니다. 오늘 또 같은 검색을 처음부터 합니다.
신입 열 명이 같은 온보딩 질문을 하면 같은 검색과 종합이 열 번 반복되는 경우
①과 ②는 찾는 방법이 단순해서 생기는 벽이고, ③은 찾은 결과가 쌓이지 않아서 생기는 벽입니다. 에이전틱 RAG는 주로 앞의 둘을, LLM 위키는 주로 뒤의 하나를 겨냥합니다.
검색을 정해진 한 단계로 두지 않고, AI 에이전트가 "무엇을, 어디서, 몇 번 찾을지"를 판단하며 반복하는 방식입니다.
"에이전틱(agentic)"은 스스로 판단하며 여러 단계를 진행한다는 뜻입니다. 기본 RAG가 "검색 한 번, 답 한 번"으로 끝나는 일직선이라면, 에이전틱 RAG는 답이 충분해질 때까지 도는 고리입니다. 2025년 1월 공개된 서베이 논문 「Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG」(Singh 외)는 이를 RAG 흐름 안에 자율 에이전트를 넣어 검색 전략을 동적으로 바꾸는 방식으로 정리합니다.
계획 · 한 번에 찾을 질문이 아니라고 판단하고 쪼갭니다. "A사 계약서의 위약금 조항", "B사 계약서의 위약금 조항", "우리 회사 표준 조항"의 세 가지를 찾기로 합니다.
검색 · 쪼갠 질문마다 따로 찾습니다. 계약서는 문서 저장소에서, 표준 조항은 법무팀 가이드에서 찾는 식으로 찾을 곳도 고릅니다.
판단 · 찾은 내용을 읽어 보니 B사 계약서는 본문이 아니라 부속 합의서에 위약금이 따로 적혀 있습니다. 근거가 부족하다고 판단합니다.
다시 검색 · "B사 부속 합의서"로 검색어를 바꿔 다시 찾습니다.
답과 근거 · 두 조항을 비교해 답하고, 각 주장 옆에 근거 문서를 붙입니다.
3단계와 4단계가 핵심입니다. 기본 RAG는 1단계 없이 2단계를 한 번 하고 바로 5단계로 갑니다. 그래서 부속 합의서를 놓친 채 "A사가 더 불리합니다"라고 자신 있게 틀릴 수 있습니다.
인사말이나 계산 문제처럼 문서가 필요 없는 질문에는 검색을 건너뜁니다. 필요한 질문만 찾으니 비용과 잡음이 줄어듭니다.
복잡한 질문을 작은 질문 여러 개로 나누고, 결과가 시원찮으면 다른 표현으로 다시 묻습니다. ①번 벽을 넘는 장치입니다.
사내 문서 검색, 웹 검색, 데이터베이스 조회, 계산기 중 질문에 맞는 것을 고릅니다. ②번 벽을 넘을 재료를 모읍니다.
답을 쓰기 전에 "찾은 근거가 정말 이 질문에 답하나"를 확인하고, 부족하면 고리를 한 번 더 돕니다.
이미 써 본 분도 많습니다. 챗GPT·제미나이의 딥 리서치, 클로드의 리서치 기능이 대표적입니다. 질문 하나에 검색·읽기·재검색을 여러 차례 반복해 보고서를 만듭니다. 대상이 인터넷일 뿐 "찾고 판단하고 다시 찾는" 고리는 같습니다.
대가는 시간과 비용입니다. 검색과 판단을 여러 번 하므로 기본 RAG보다 응답이 느리고, AI 호출 횟수만큼 요금이 늘어납니다. 고리가 몇 번 돌지 미리 알 수 없어 비용 예측도 어렵습니다.
그래서 "모든 질문을 에이전틱으로"는 답이 아닙니다. 간단한 질문은 기본 RAG로, 어려운 질문만 에이전트로 보내는 섞어 쓰기가 현실적인 설계입니다.
자료가 들어올 때마다 AI가 읽고 주제별 문서를 쓰고 고쳐서, 서로 연결된 위키를 계속 키워 가는 방식입니다.
이 이름을 널리 알린 것은 오픈AI 공동 창업자이자 전 테슬라 AI 책임자인 안드레이 카파시(2026년 5월 앤스로픽 합류)입니다. 그는 앤스로픽에 합류하기 한 달 전인 2026년 4월 4일, 개인 자격으로 깃허브 지스트에 「LLM Wiki」라는 짧은 문서를 올렸습니다. 완성된 프로그램이 아니라 "AI 에이전트에게 붙여 넣으면 함께 만들어 가는 아이디어 문서"라고 스스로 소개합니다.
카파시가 짚은 문제는 ③번 벽입니다. 그는 일반적인 RAG에 대해 AI가 질문할 때마다 지식을 처음부터 다시 발견한다고 쓰고, 그래서 아무것도 쌓이지 않는다고 지적합니다. 대안은 지식을 한 번 정리해 두고 계속 최신으로 고쳐 가는 것입니다. 그의 표현으로는 위키가 "계속 불어나는 산출물"이 됩니다.
기사, 논문, 회의록, 데이터 파일 같은 원본입니다. AI는 읽기만 하고 절대 고치지 않습니다. 나중에 대조할 기준이 되기 때문입니다.
AI가 쓰고 관리하는 마크다운 문서 묶음입니다. 자료 요약, 인물·회사·개념별 페이지, 비교표가 서로 링크로 이어집니다. 사람은 주로 읽습니다.
위키를 어떻게 꾸릴지 정한 규칙 문서입니다. 폴더 구조, 페이지 양식, 작업 순서를 적어 둡니다. 이 문서가 AI를 그냥 챗봇이 아닌 성실한 위키 관리자로 만듭니다.
스키마는 생소해 보여도 이미 익숙한 물건입니다. 클로드 코드의 CLAUDE.md, 여러 코딩 에이전트가 쓰는 AGENTS.md 같은 지침 파일이 바로 이 자리에 들어간다고 카파시는 예로 듭니다.
수집 · 새 자료를 넣으면 AI가 읽고 요약 페이지를 쓴 뒤, 관련된 인물·개념 페이지와 목차를 함께 고칩니다. 카파시는 자료 하나가 위키 페이지 10~15개를 건드릴 수 있다고 씁니다. 정리가 질문 시점이 아니라 이때 일어납니다.
질의 · 질문을 받으면 AI가 위키에서 관련 페이지를 찾아 근거와 함께 답합니다. 좋은 답이 나오면 그 답을 새 페이지로 위키에 되돌려 저장합니다. 질문할수록 위키가 두꺼워지는 이유입니다.
점검 · 주기적으로 위키 전체를 훑어 서로 모순되는 내용, 새 자료 때문에 낡은 주장, 어디서도 링크되지 않은 고아 페이지, 빠진 개념을 찾아 고칩니다.
여기에 파일 두 개가 길잡이 역할을 합니다. 모든 페이지를 한 줄 요약과 함께 나열한 목차 파일(index.md)은 AI가 질문을 받으면 가장 먼저 읽는 곳이고, 수집·질의·점검을 날짜순으로 적는 작업 기록(log.md)은 위키가 어떻게 자라 왔는지 보여 줍니다. 카파시는 자료 100건, 페이지 수백 개 정도까지는 별도의 벡터 검색 장치 없이 목차만으로도 잘 돌아간다고 봅니다.
컨플루언스나 노션으로 사내 위키를 만들어 본 회사라면 익숙한 장면이 있습니다. 처음 몇 달은 열심히 쓰다가, 문서가 늘수록 고칠 곳도 늘어 결국 아무도 손대지 않는 "문서 무덤"이 됩니다. 카파시도 같은 지점을 짚습니다. 사람이 만든 위키는 관리 비용이 가치보다 빨리 커져서 버려지는데, AI는 페이지 열다섯 개를 한 번에 고치는 일도 지루해하지 않으니 그 비용이 거의 사라진다는 것입니다.
LLM 위키의 약점은 "정리하다 틀리면 틀린 채로 굳는다"는 것입니다. RAG는 매번 원문을 보니 실수가 그 질문 하나로 끝나지만, 위키는 잘못 요약한 내용이 다음 질문의 근거가 됩니다.
그래서 원천 자료를 절대 고치지 않고 남겨 두는 것, 주기적인 점검, 위키 문장에서 원문으로 거슬러 올라갈 수 있는 출처 표시가 선택이 아니라 필수입니다. 위키가 AI 한 번에 읽을 수 있는 분량을 넘어설 만큼 커지면 결국 검색 장치를 다시 붙여야 한다는 점도 기억해 두세요.
| 구분 | 기본 RAG | 에이전틱 RAG | LLM 위키 |
|---|---|---|---|
| 언제 일하나 | 질문할 때 한 번 | 질문할 때 여러 번 | 자료가 들어올 때 미리 |
| 무엇이 쌓이나 | 없음 | 없음 (질문마다 새로) | 정리된 지식이 계속 쌓임 |
| 비용이 드는 시점 | 질문마다 적게 | 질문마다 많이 | 수집할 때 많이, 질문할 때 적게 |
| 강한 질문 | 답이 한 곳에 있는 질문 | 여러 출처를 견주는 어려운 질문 | 같은 주제를 오래 파고드는 질문 |
| 약점 | 첫 검색이 빗나가면 끝 | 느리고 비용 예측이 어려움 | 정리 오류가 굳고, 규모에 한계 |
| 잘 맞는 자료 | 규정·매뉴얼·FAQ | 계약서·보고서가 흩어진 문서 저장소 | 자료 수십~수백 건의 연구·프로젝트 |
둘은 경쟁 관계가 아닙니다. 카파시의 문서도 위키가 커지면 위키 위에 검색 도구를 얹는 방법을 언급합니다. 정리는 위키로, 정리된 위키를 뒤지는 일은 에이전트로 나누면 두 장점을 함께 쓸 수 있습니다.
두 방식을 처음 비교할 때 자주 나오는 질문입니다. 답은 반은 맞고 반은 다르다입니다. RAG에 꼭 필요한 것은 데이터베이스가 아니라 빨리 찾을 수 있는 색인입니다. LLM 위키에도 색인이 있습니다. 그 색인을 AI가 직접 쓴 목차 파일로 대신할 뿐입니다.
RAG 하면 벡터 DB를 세팅한다는 말이 따라붙는 이유는 뜻으로 찾는 검색 때문입니다. 문서를 조각내고 각 조각을 숫자 묶음(임베딩)으로 바꿔 저장해 두면, 표현이 달라도 뜻이 비슷한 조각을 찾을 수 있습니다. 이 숫자 묶음을 빠르게 비교하려고 벡터 DB를 씁니다. 하지만 길은 하나가 아닙니다.
문서가 수천 건 수준이면 파일 하나에 색인을 담아 두고 단어 일치로 찾아도 충분히 빠릅니다. 별도 서버가 필요 없습니다.
사내 매뉴얼 수백 편을 파일 하나로 묶어 검색하는 도우미
이미 쓰고 있는 DB에 벡터 검색 기능을 추가하는 방법입니다. 새 DB를 들이지 않고 뜻 검색을 쓸 수 있습니다.
PostgreSQL에 벡터 검색 확장을 설치하는 경우
보통 문서가 수십만 건을 넘거나 뜻 검색의 품질이 특히 중요할 때 씁니다. 정해진 기준이 아니라 현장에서 흔히 쓰는 경험칙입니다. 세팅과 운영에 가장 손이 많이 갑니다.
여러 부서의 문서 저장소 전체를 한곳에서 검색하는 경우
이 사이트의 AI 멘토도 RAG를 씁니다. 프로 멤버가 질문하면 아티클 본문, 심화 학습, 빅테크 소식, AI 기업·인물 정보까지 사이트 전체에서 관련 대목을 찾아 붙여 답합니다. 그런데 DB도, 임베딩도 쓰지 않습니다. 위 세 갈래 중 첫째, 단어 일치 검색만 쓰는 방식입니다.
"그건 언제야?"처럼 주제가 빠진 꼬리 질문은 혼자서는 찾을 게 없습니다. 그래서 직전 질문을 함께 넣어 검색합니다.
LLM 위키는 마크다운 파일 묶음이라 처음에는 DB가 필요 없습니다. AI가 목차 파일부터 읽고 필요한 페이지를 열기 때문입니다.
카파시는 자료 100건, 페이지 수백 개 정도까지는 목차만으로 잘 돈다고 썼고, 그보다 커지면 제대로 된 검색이 필요하다며 마크다운 전용 검색 도구(qmd)를 권합니다. 목차가 AI가 한 번에 읽을 수 있는 분량을 넘으면 어려워진다는 점은 이 글의 해석입니다. 위키가 커지면 결국 RAG와 같은 문제를 만나는 셈입니다.
| 구분 | 미리 해 둘 일 | 계속 해야 할 일 |
|---|---|---|
| RAG | 문서 조각내기, 색인 만들기 | 문서가 바뀌면 색인 다시 만들기 |
| LLM 위키 | 폴더와 규칙 문서 한 장 | 자료가 들어올 때마다 AI가 페이지를 고쳐 쓰고, 사람이 점검하기 |
RAG는 처음 세팅에 손이 많이 가지만 이후 유지는 기계적입니다. LLM 위키는 시작이 가볍지만, 자료가 들어올 때마다 AI가 글을 쓰는 비용과 그 글을 점검하는 수고가 계속 듭니다. 그래서 개인이나 작은 팀은 위키로 가볍게 시작하고, 문서가 많은 회사는 RAG로 가는 경우가 많습니다.
용어는 앞으로도 바뀝니다. 오래 쓸 수 있는 것은 이름이 아니라 판단 기준입니다. 도입을 검토할 때 아래 세 가지만 물어보세요.
한 곳이면 기본 RAG로 충분합니다. 여러 문서를 비교·종합해야 하면 에이전틱 RAG를 검토할 때입니다.
그렇다면 질문마다 처음부터 찾는 것은 낭비입니다. 한 번 정리해 두는 LLM 위키가 시간이 갈수록 유리해집니다.
계약·법무·재무처럼 틀리면 비싼 영역은 원문 근거를 매번 다시 확인하는 쪽이 안전합니다. 위키를 쓰더라도 위키의 답에서 원문으로 바로 넘어갈 수 있게 만들어야 합니다.
| 상황 | 추천 | 이유 |
|---|---|---|
| 고객센터 FAQ 300건 응대 | 기본 RAG | 답이 한 항목에 있고, 빠르고 저렴해야 합니다 |
| 여러 해의 계약서를 견주는 법무 질의 | 에이전틱 RAG | 여러 문서를 찾아 비교해야 하고, 근거를 매번 원문으로 확인해야 합니다 |
| 6개월짜리 경쟁사 동향 리서치 | LLM 위키 | 자료가 계속 들어오고, 같은 주제를 오래 쌓아 가는 일입니다 |
| 신규 입사자 온보딩 도우미 | LLM 위키 + 기본 RAG | 정리된 안내 위키를 두고, 위키에 없는 세부 규정만 원문에서 찾습니다 |
에이전틱 RAG는 회사 시스템 단위의 이야기지만, LLM 위키는 혼자서도 오늘 시작할 수 있습니다. 파일을 읽고 쓸 수 있는 AI 도구(클로드 코드 같은 코딩 에이전트, 또는 폴더를 연결할 수 있는 AI 앱)와 폴더 하나면 됩니다.
raw, AI가 쓰는 wiki. 원본 폴더는 AI가 고치지 못하게 규칙에 적어 둡니다.회사 문서를 넣을 때는 사내 보안 규정이 허용하는 도구인지 먼저 확인해야 합니다. 개인 학습 자료나 공개 자료로 먼저 익혀 보는 것을 권합니다.
에이전틱 RAG의 대표 설계 패턴 네 가지와 연구 흐름, 바로 쓸 수 있는 LLM 위키 규칙 문서 견본,
두 방식이 실패하는 지점 체크리스트, 업체 제안서에서 "에이전틱 RAG"를 들었을 때 물어야 할 질문을 다룹니다.
주요 출처
Andrej Karpathy, 「LLM Wiki」 GitHub Gist (2026.4.4) · gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
Singh, A. 외, 「Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG」, arXiv:2501.09136 (2025.1 최초 공개, 2026.4 개정)
Lewis, P. 외, 「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」, NeurIPS 2020