RAG의 시대에서 Wiki의 시대로

RAG는 무엇을 잘하는가

RAG는 Retrieval-Augmented Generation의 줄임말이다. 한국어로 풀면 "검색으로 보강한 생성" 정도로 이해하면 된다. LLM이 답변하기 전에 외부 문서에서 관련 내용을 먼저 찾고, 그 자료를 근거로 답변하게 만드는 방식이다.

이 방식은 AI 활용의 큰 전환점이었다. LLM은 학습 시점 이후의 정보를 모를 수 있고, 회사 내부 문서나 개인 자료도 기본적으로 알지 못한다. 그런데 RAG를 쓰면 모델을 새로 학습시키지 않아도 문서 묶음을 검색해 답변에 반영할 수 있다.

예를 들어 이런 질문에는 RAG가 강하다.

• "우리 회사 환불 정책에서 예외 조항은 무엇인가?"

• "이 논문 저장소에서 LoRA를 다룬 문서를 찾아 요약해줘."

• "지난 분기 고객 인터뷰 중 가격 불만과 관련된 내용을 찾아줘."

• "최근 업로드한 보고서들에서 일본 시장 관련 수치를 정리해줘."

문서가 많고, 사용자가 어떤 자료를 필요로 할지 미리 알기 어렵고, 최신 자료가 계속 추가되는 환경에서는 RAG가 유용하다. 사람이 모든 문서를 읽고 정리해두지 않아도, 질문이 들어온 순간 관련 문서를 찾아 답변을 만들 수 있기 때문이다.

RAG의 장점은 분명하다. 첫째, 대량 문서를 다룰 수 있다. 둘째, 최신 자료를 연결하기 쉽다. 셋째, 사용자가 직접 파일을 뒤지지 않아도 된다. 넷째, 특정 문서에 근거한 답변을 만들 수 있다.

그래서 RAG는 사내 문서 검색, 고객지원 챗봇, 법률·의료·기술 문서 조회, 연구 자료 검색 같은 영역에서 강력하다. 문제는 RAG가 "지식을 운영한다"기보다 "자료를 찾아 답한다"는 데 있다.

검색 기반 답변의 한계

RAG는 질문을 받으면 관련 문서를 찾는다. 이때 대부분의 시스템은 긴 문서를 작은 조각으로 나눈다. 이 작은 조각을 보통 청크라고 부른다. 긴 PDF, 회의록, 웹 문서, 책 내용을 일정한 길이로 잘라두고, 질문과 비슷한 청크를 찾아 LLM에게 넘기는 방식이다.

이 구조는 빠르고 실용적이다. 하지만 중요한 문제가 있다. 지식은 문장 몇 개의 조각으로만 존재하지 않는다. 어떤 주장은 앞뒤 맥락 속에서 의미가 정해진다. 어떤 결정은 당시 상황, 반대 의견, 제약 조건을 함께 봐야 이해된다. 어떤 개념은 다른 개념과의 관계 속에서 선명해진다.

청크 검색은 이 관계를 자주 놓친다.

예를 들어 한 회의록에 이런 흐름이 있다고 하자.

1. 처음에는 무료 플랜을 유지하자는 의견이 나왔다.

2. 고객 전환율 데이터를 검토했다.

3. 무료 플랜이 오히려 유료 전환을 막는다는 해석이 제기되었다.

4. 반론도 있었다.

5. 최종적으로 3개월 뒤 무료 플랜 축소를 실험하기로 결정했다.

RAG가 이 회의록 일부만 검색하면 "무료 플랜을 유지하자는 의견이 있었다"는 문장만 가져올 수 있다. 또는 "무료 플랜 축소를 실험하기로 했다"는 결론만 가져올 수도 있다. 둘 다 틀린 말은 아니지만, 전체 판단의 흐름을 보여주지는 못한다.

지식 업무에서 중요한 것은 단순한 문장 검색이 아니다. 왜 그런 결론에 도달했는지, 어떤 반론이 있었는지, 시간이 지나며 생각이 어떻게 바뀌었는지, 지금도 유효한 판단인지 알아야 한다.

RAG는 이 부분에서 약해진다.

청크는 문서를 자르고, 위키는 의미를 잇는다

청크 검색의 핵심 단위는 "비슷한 텍스트 조각"이다. 반면 위키의 핵심 단위는 "의미 있는 지식 페이지"다.

이 차이는 작아 보이지만 결과는 크게 다르다.

RAG에서 "고객 이탈 원인"을 물으면 시스템은 고객 이탈과 관련 있어 보이는 문서 조각을 찾아준다. 어떤 조각은 고객 인터뷰에서 오고, 어떤 조각은 회의록에서 오고, 어떤 조각은 제품 분석 보고서에서 올 수 있다. LLM은 그것을 모아 답한다.

LLM Wiki에서는 접근이 다르다. 자료를 넣는 시점에 AI가 다음과 같은 페이지를 미리 만들거나 업데이트한다.

• 고객 이탈 원인.md

• 가격 불만.md

• 온보딩 실패.md

• 경쟁사 전환 사례.md

• 2026-04 무료 플랜 축소 결정.md

• 고객 인터뷰/김OO.md

이 페이지들은 단순 요약이 아니다. 개념, 인물, 주장, 근거, 반론, 결정, 시간 흐름을 나누어 저장한다. 같은 자료 하나가 여러 페이지를 동시에 업데이트할 수도 있다.

예를 들어 고객 인터뷰 하나를 넣었을 때, LLM Wiki는 그 인터뷰를 단순히 raw/interviews/2026-04-12.md에 저장하는 데서 끝나지 않는다. 원문은 그대로 보존하되, 위키층에는 다음과 같은 변화가 생긴다.

• 가격 불만.md에 새 사례 추가

• 온보딩 실패.md에 관련 발언 추가

• 고객 세그먼트/초기 스타트업.md에 패턴 추가

• 경쟁사 A.md에 전환 이유 추가

• 고객 피드백 로그.md에 날짜별 항목 추가

이렇게 하면 나중에 질문할 때 매번 원문 더미에서 답을 새로 조립하지 않아도 된다. 이미 정리된 지식의 지도 위에서 질문을 시작할 수 있다.

RAG가 "찾아서 답하는 방식"이라면, LLM Wiki는 "쌓아둔 지식 위에서 답하는 방식"이다.

RAG가 놓치기 쉬운 세 가지

RAG가 나쁘다는 뜻은 아니다. RAG는 매우 유용하다. 다만 RAG만으로 지식 시스템을 만들면 반복해서 부딪히는 문제가 있다.

첫째, 원문 맥락이 잘린다.

청크는 검색을 위해 문서를 자른 단위다. 그러나 사람의 판단은 문단, 장, 회의 전체, 프로젝트 전체의 흐름에 의존한다. 한 문장만 보면 긍정처럼 보이지만 전체 맥락에서는 반론일 수 있다. 한 수치만 보면 성과처럼 보이지만 전월 대비로는 악화일 수 있다.

둘째, 주장 간 관계가 약하다.

문서 안에는 사실, 주장, 추정, 의견, 결정이 섞여 있다. RAG는 관련 조각을 찾을 수 있지만, "이 주장은 어떤 근거 위에 있는가", "이 주장과 충돌하는 다른 문서는 무엇인가", "이 결정은 어느 문제를 해결하기 위한 것이었나"를 안정적으로 관리하기 어렵다.

셋째, 시간에 따른 변화가 흐려진다.

지식은 고정되어 있지 않다. 특히 제품, 시장, 연구, 조직 운영에서는 시간이 중요하다. 3개월 전에는 맞았던 판단이 지금은 틀릴 수 있다. 작년의 경쟁사 분석은 현재 상황과 다를 수 있다. RAG는 최신 문서를 검색할 수는 있지만, 어떤 지식이 언제 생겼고, 언제 수정되었고, 왜 바뀌었는지 관리하는 데는 별도의 구조가 필요하다.

LLM Wiki는 이 지점을 보완한다. 자료를 넣을 때부터 날짜, 출처, 관련 페이지, 변경 이력, 결정 이유를 남긴다. 그래서 지식이 단순히 쌓이는 것이 아니라 관리된다.

LLM Wiki는 수집 시점에 구조화한다

RAG는 질문 시점에 검색한다. LLM Wiki는 수집 시점에 정리한다.

이것이 가장 큰 차이다.

웹 문서, 논문, 책, 회의록, 고객 인터뷰, 강의 transcript를 위키에 넣는다고 해보자. RAG 방식에서는 원문을 저장하고 검색 인덱스를 만든다. 나중에 질문이 들어오면 관련 조각을 찾는다.

LLM Wiki 방식에서는 원문 저장에 더해 위키 페이지를 업데이트한다. AI에게 이런 일을 맡긴다.

• 새로 등장한 개념을 찾고 개념 페이지를 만든다.

• 기존 개념 페이지에 새로운 근거를 추가한다.

• 인물, 조직, 제품, 논문, 책을 별도 페이지로 연결한다.

• 서로 충돌하는 주장을 표시한다.

• 비교 페이지를 갱신한다.

• 중요한 결정은 의사결정 기록으로 남긴다.

• index와 log를 업데이트해 전체 흐름을 추적한다.

여기서 중요한 점은 "요약"이 목적이 아니라는 것이다. 많은 사람이 AI에게 자료를 주고 "요약해줘"라고 말한다. 요약은 유용하지만, 요약 파일이 많아진다고 지식 시스템이 되지는 않는다.

LLM Wiki의 목적은 자료를 재사용 가능한 지식 단위로 바꾸는 것이다. 한 번 정리한 개념은 다음 자료가 들어올 때 다시 업데이트된다. 한 번 만든 비교 페이지는 새 경쟁사가 등장하면 확장된다. 한 번 남긴 결정 기록은 나중에 결과를 평가할 때 기준점이 된다.

즉, LLM Wiki는 답변 생성 도구가 아니라 지식 축적 장치다.

언제 RAG가 더 적합한가

그렇다면 모든 것을 위키로 만들어야 할까? 그렇지 않다.

다음과 같은 상황에서는 RAG가 더 적합하다.

• 문서 양이 너무 많아 사람이 구조를 미리 설계하기 어렵다.

• 사용자의 질문 범위가 매우 넓고 예측하기 어렵다.

• 원문 검색 자체가 핵심 기능이다.

• 최신 문서를 빠르게 반영하는 것이 중요하다.

• 콜센터, 사내 검색, 법규 조회처럼 "근거 문서 찾기"가 우선이다.

예를 들어 수만 건의 고객지원 문서를 대상으로 상담원이 빠르게 답을 찾아야 한다면 RAG가 적합하다. 모든 문서를 사람이 읽을 수는 없고, 모든 이슈를 위키 페이지로 정리하기도 어렵다. 이때는 검색 인프라가 필요하다.

또한 법률, 정책, 기술 문서처럼 원문 표현이 중요한 영역에서는 원문을 정확히 찾는 능력이 중요하다. 위키 요약만 보고 판단하면 위험할 수 있다. 이런 경우 RAG는 원문 접근 통로로 강력하다.

언제 LLM Wiki가 더 적합한가

반대로 다음과 같은 상황에서는 LLM Wiki가 더 적합하다.

• 같은 주제를 계속 공부하거나 연구한다.

• 자료가 시간이 지나며 누적된다.

• 단순 검색보다 관점, 구조, 판단이 중요하다.

• 개인이나 팀의 의사결정 이력을 남겨야 한다.

• 책, 보고서, 제품 기획, 전략 문서처럼 결과물을 만들어야 한다.

• AI와 반복적으로 협업하며 맥락을 이어가고 싶다.

예를 들어 창업자가 고객 인터뷰를 계속 모은다고 하자. 매번 "최근 인터뷰 요약해줘"라고 묻는 것은 검색 기반 활용에 가깝다. 반면 인터뷰가 들어올 때마다 고객 세그먼트, 문제 유형, 가격 반응, 경쟁사 언급, 기능 요청, 결정 기록을 업데이트한다면 지식이 쌓인다.

작가나 연구자도 마찬가지다. 논문과 기사, 책을 계속 읽는 사람에게 필요한 것은 단순 요약 폴더가 아니다. 개념 간 연결, 논쟁의 흐름, 반복되는 주장, 아직 비어 있는 질문이다. LLM Wiki는 이 구조를 만들기에 적합하다.

개인 지식관리에서도 위키 방식이 강하다. 일기, 회고, 목표, 건강 기록, 반복되는 고민을 단순히 저장하면 나중에 다시 읽기 어렵다. 하지만 "수면 패턴", "불안이 커지는 상황", "집중이 잘되는 조건", "올해의 목표 변화" 같은 페이지로 축적하면 자기 이해의 자료가 된다.

작은 규모에서는 Markdown 위키가 강하다

개인이나 작은 팀이라면 처음부터 복잡한 검색 시스템을 만들 필요가 없다. 오히려 Markdown 파일 기반 위키가 더 빠르고 투명하다.

Markdown은 평범한 텍스트 파일이다. 특정 서비스에 갇히지 않는다. Git으로 버전 관리할 수 있고, Obsidian 같은 도구로 쉽게 읽고 연결할 수 있다. AI 에이전트도 파일을 열고 수정하고 링크를 만들기 쉽다.

작은 규모에서 중요한 것은 거대한 인프라가 아니다. 다음 세 가지다.

• 원문은 안전하게 보존한다.

• 위키 페이지는 사람이 읽기 쉽게 유지한다.

• AI가 어떤 규칙으로 업데이트할지 명확히 정한다.

문서가 수백 개, 위키 페이지가 수십 개 수준이라면 Markdown 위키만으로도 충분히 강력하다. 검색도 파일명, 링크, 태그, 기본 텍스트 검색으로 해결되는 경우가 많다. 무엇보다 모든 내용이 눈에 보인다. AI가 잘못 정리했는지도 사람이 확인할 수 있다.

투명성은 생각보다 중요하다. 복잡한 RAG 시스템에서는 답변이 왜 그렇게 나왔는지 추적하기 어려울 때가 있다. 반면 Markdown 위키에서는 어떤 페이지가 수정되었는지, 어떤 출처에서 왔는지, 어떤 문장이 추가되었는지 확인하기 쉽다.

처음 LLM Wiki를 만들 때는 단순해야 한다. raw/에 원문을 넣고, wiki/에 정리된 지식 페이지를 둔다. index.md로 전체 지도를 만들고, log.md로 변경 흐름을 남긴다. 이것만으로도 많은 사람에게 충분한 출발점이 된다.

큰 규모에서는 검색 인프라와 결합해야 한다

규모가 커지면 이야기가 달라진다.

문서가 수만 개로 늘어나고, 팀원이 많아지고, 권한 관리가 필요해지고, 실시간 검색이 중요해지면 Markdown 위키만으로는 부족할 수 있다. 이때는 검색 인프라가 필요하다.

하지만 이 말은 LLM Wiki가 사라진다는 뜻이 아니다. 오히려 더 중요해진다. 큰 규모에서는 원문 검색과 위키 지식층을 함께 써야 한다.

구조는 이렇게 생각할 수 있다.

• 원문 저장소: PDF, 웹 문서, 회의록, 계약서, 로그 등

• 검색 인프라: 키워드 검색, 벡터 검색, 하이브리드 검색

• 위키 지식층: 핵심 개념, 결정, 비교, 주장, 타임라인

• AI 에이전트: 검색하고, 요약하고, 위키를 업데이트하고, 모순을 찾는 역할

• 사람의 검수: 중요한 판단, 민감한 정보, 외부 공개 문서 확인

큰 조직에서 모든 자료를 위키 페이지로 정리할 수는 없다. 그러나 중요한 지식은 위키층으로 올려야 한다. 검색 결과는 원문을 찾게 해주고, 위키는 조직이 무엇을 알고 있는지 보여준다.

이 둘은 경쟁 관계가 아니다. 역할이 다르다.

RAG는 넓게 찾는다. LLM Wiki는 깊게 쌓는다. RAG는 질문에 반응한다. LLM Wiki는 지식의 형태를 미리 만든다. RAG는 자료 접근성을 높인다. LLM Wiki는 판단의 연속성을 만든다.

판단 기준: 찾을 것인가, 쌓을 것인가

어떤 방식을 선택해야 할지 헷갈릴 때는 질문을 바꾸면 된다.

"나는 지금 자료를 찾고 싶은가, 지식을 쌓고 싶은가?"

자료를 찾는 것이 목적이라면 RAG가 맞다. 방대한 문서에서 관련 근거를 빠르게 꺼내야 한다면 검색 기반 접근이 필요하다.

지식을 쌓는 것이 목적이라면 LLM Wiki가 맞다. 같은 주제를 계속 다루고, 판단이 누적되고, 나중에 다시 활용할 결과물을 만들고 싶다면 위키 기반 접근이 필요하다.

실제로는 둘을 함께 쓰는 경우가 많다. 처음에는 Markdown 위키로 시작한다. 원문과 위키를 분리한다. 자료를 넣을 때마다 AI가 개념, 주장, 인물, 결정 기록을 업데이트하게 한다. 규모가 커지면 검색 인프라를 붙인다. 원문은 RAG로 찾고, 핵심 지식은 위키로 운영한다.

이 순서가 중요하다. 많은 사람이 처음부터 거대한 검색 시스템을 만들려고 한다. 하지만 검색할 문서가 있어도, 그 문서들이 어떤 지식 구조를 이루는지 모르면 답변 품질은 쉽게 흔들린다.

먼저 작은 위키를 만들어야 한다. 내가 반복해서 묻는 질문, 자주 참고하는 자료, 계속 수정되는 판단을 페이지로 남겨야 한다. 그다음 검색을 붙여도 늦지 않다.

AI 시대의 지식 관리는 단순히 "더 잘 검색하는 법"에서 끝나지 않는다. 중요한 것은 검색된 답변을 다시 지식으로 남기는 일이다. 질문하고, 답을 얻고, 그 답에서 새 페이지를 만들고, 다음 질문은 그 위에서 시작한다.

이때부터 AI는 일회성 답변기가 아니라 지식관리자가 된다. 그리고 우리의 노트는 저장소가 아니라, 시간이 지날수록 더 똑똑해지는 두 번째 뇌가 된다.