RAG, 긴 컨텍스트, 파인튜닝, LLM Wiki 비교

네 가지 방법

모델이 내 자료를 바탕으로 답하게 하는 방법은 크게 넷입니다.

방법	한 줄 설명	자료가 들어가는 시점
긴 컨텍스트	문서를 통째로 질문과 함께 넣음	질문할 때마다
RAG	질문과 관련된 조각만 찾아서 넣음	질문할 때마다, 검색을 거쳐
파인튜닝	자료로 모델을 추가 학습시킴	학습할 때 한 번
LLM Wiki	문서를 미리 위키로 정리해 두고, 질문 때 위키를 읽음	정리할 때 한 번, 읽을 때 다시

앞의 둘과 마지막은 모델을 건드리지 않습니다. 답하는 시점에 자료를 입력으로 넣어 주는 방식입니다. 파인튜닝만 모델 자체를 바꿉니다.

비교표

항목	긴 컨텍스트	RAG	파인튜닝	LLM Wiki
준비 작업	없음	추출, 청크, 색인	학습 자료 제작, 학습	추출, 에이전트의 정리 작업
문서가 바뀌면	새 문서를 넣음	바뀐 문서만 다시 색인	다시 학습	해당 페이지를 고쳐 병합
출처 표기	가능	가능(조각 단위)	어려움	가능(페이지와 원문 링크)
맞는 규모	문서 몇 건~수십 건	수백 건 이상	규모와 무관	수백~수천 건
강한 질문	문서 전체를 봐야 하는 질문	특정 조항, 사실 찾기	말투, 형식, 분류 기준	여러 문서를 가로지르는 질문
약한 질문	문서가 많을 때	여러 문서를 종합하는 질문	최신 사실, 근거 제시	정리할 때 빠뜨린 세부 사항
로컬 PC 부담	컨텍스트 길이만큼 메모리	작음	학습에 큰 자원 필요	정리 단계에 좋은 모델 필요

파인튜닝은 다른 문제를 푼다

파인튜닝은 “우리 문서를 알게 하는 방법”으로 자주 오해됩니다. 사실을 기억시키는 용도로는 잘 맞지 않습니다.

• 문서가 바뀔 때마다 다시 학습해야 합니다.
• 답이 어느 문서에서 나왔는지 댈 수 없습니다.
• 학습 자료를 질문과 답의 쌍으로 만드는 일이 따로 듭니다.

파인튜닝이 맞는 경우는 모델의 행동을 바꾸고 싶을 때입니다. 우리 기관의 문서 형식으로 쓰게 하거나, 정해진 기준으로 분류하게 하는 일입니다. 내부 자료로 답하게 하는 목적이라면 먼저 RAG로 풀고, 그래도 말투나 형식이 맞지 않을 때 파인튜닝을 검토합니다.

RAG가 약한 질문

RAG는 “제12조가 뭐라고 하나”처럼 답이 한두 조각에 들어 있는 질문에 강합니다. 다음 질문에는 약합니다.

• “우리가 지난 3년간 교육 과정에서 이 개념을 어떻게 설명해 왔나”
• “이 주제를 다룬 자료가 어디 어디에 흩어져 있나”
• “비슷한 프로젝트에서 어떤 기술을 썼었나”

이런 질문은 조각 다섯 개로 답할 수 없습니다. 여러 문서를 읽고 종합해야 합니다. RAG는 질문이 들어올 때마다 조각을 새로 모으기만 하고, 한 번 종합한 결과를 쌓아 두지 않습니다.

LLM Wiki 방식

LLM Wiki는 안드레이 카파시가 제안한 방식입니다. 신성진 강사가 자신의 강의 자료와 프로젝트를 정리하는 데 쓰고 있습니다.

비유는 이렇습니다. 내 PDF와 문서는 소스 코드이고, 정리된 위키는 컴파일된 결과물입니다. RAG는 질문 때마다 원문에서 검색합니다. LLM Wiki는 문서를 한 번 위키로 정리해 두고, 질문 때는 위키를 먼저 읽습니다. 새 문서를 넣으면 기존 위키에 병합되어 지식이 쌓입니다.

출발점이 된 생각은 유지보수입니다. 사람이 만든 위키는 검색이 안 돼서 죽는 것이 아니라 유지보수가 지겨워서 죽습니다. 링크 하나 고치기가 귀찮아 방치되고, 방치된 위키는 믿을 수 없게 됩니다. 언어 모델은 지겨워하지 않고, 한 번에 여러 파일을 고칠 수 있습니다. 그 유지보수를 에이전트에게 맡기자는 것입니다.

폴더 구조

purpose.md, schema.md   위키의 목적과 규칙 (먼저 씀)
raw/sources/            원본 문서 (고치지 않고 보관)
raw/extracted/          문서에서 뽑은 텍스트
wiki/                   정리된 위키 (개념, 대상, 출처 페이지)
tools/                  추출과 색인용 스크립트

별도의 앱을 설치하지 않습니다. 폴더가 곧 작업 공간이고, 위키는 평범한 마크다운 파일입니다. 어떤 편집기로도 열 수 있습니다.

작업 순서

1. 문서를 넣습니다. 스크립트가 원본을 보관하고 텍스트를 추출합니다.
2. 코딩 에이전트에게 “새로 추출한 문서를 위키로 정리해 줘”라고 요청합니다.
3. 에이전트가 문서에서 개념과 대상을 뽑아 페이지를 만들거나, 이미 있는 페이지에 병합합니다. 페이지끼리는 링크로 잇습니다.
4. 색인 페이지를 갱신합니다.
5. 질문할 때 에이전트는 색인 페이지를 먼저 읽고, 관련 페이지와 링크된 페이지를 읽은 뒤 답합니다. 더 자세한 내용이 필요하면 페이지에 적힌 원문으로 갑니다.

벡터 임베딩을 쓰지 않습니다. 에이전트가 파일을 직접 읽고 판단합니다.

운영 규칙

강사가 운영하면서 정리한 규칙입니다.

위키는 저장소가 아니라 검색 계약이다. “무엇을 찾을 것인가”를 먼저 정하지 않으면 요약만 쌓인 무덤이 됩니다. 목적 파일에 이 위키가 반드시 답해야 하는 질문을 적어 둡니다. 강사의 위키는 세 개를 적어 두었습니다. 어떤 프로젝트에 어떤 기술을 썼는가, 이 주제의 강의 자료가 어디에 모여 있는가, 이 개념을 어떻게 설명했었는가입니다.

원문으로 돌아가는 길이 없으면 위키가 아니다. 요약만 있고 원문 위치가 없으면 그냥 노트입니다. 모든 페이지에 원본 파일의 위치를 남깁니다.

덮어쓰지 않고 병합한다. 새 문서가 들어오면 기존 페이지를 지우고 다시 쓰지 않습니다. 기존 내용에 더하고, 변경 이력을 기록합니다.

완전 자동화하지 않는다. 새 문서가 생길 때마다 사람 확인 없이 자동으로 요약해 넣는 것도 기술적으로는 가능합니다. 하지만 정리에는 “이 내용은 어느 분류에 넣을까”, “어느 페이지와 연결할까” 같은 판단이 들어갑니다. 판단 없이 자동으로 쌓으면 분류가 다시 어지러워집니다. 그래서 새 문서가 생겼다는 알림은 자동으로 받고, 정리는 사람이 요청할 때 합니다.

한계

강사가 스스로 점검하며 적어 둔 한계입니다.

• 목적 파일을 예시 문구 그대로 두고 몇 달을 운영했습니다. 규칙을 알아도 실천은 따로입니다.
• “어떻게 설명했는가”를 담는 폴더가 다른 폴더보다 훨씬 얇았습니다. 정리할 때 의식하지 않은 내용은 위키에 남지 않습니다.
• 페이지 수가 주는 착시가 있습니다. 수백 개 페이지가 있어도 깊이 정리된 것은 일부이고, 나머지는 제목과 도입부만 담은 목록에 가깝습니다.
• 그래프 화면을 보기 좋게 만드는 일에 시간을 쓰기 쉽습니다. 그래프는 부산물이고, 목적은 질문에 답이 나오는 것입니다.

정리 단계에서 빠진 세부 사항은 위키에서 찾을 수 없습니다. 그래서 원문과 추출 텍스트를 함께 보관하고, 필요하면 원문으로 내려갑니다.

무엇을 고를까

강사의 정리는 “RAG와 위키 가운데 무엇이 나은가는 가짜 논쟁이고, 질문의 형태가 조합을 정한다”입니다.

질문의 형태	맞는 방법
이 문서 한두 개에서 답을 찾아줘	붙여 넣기, 긴 컨텍스트
수백 건 가운데 해당 조항을 찾아줘	RAG
정확한 문서 번호, 조문 번호로 찾아줘	RAG의 키워드 검색
여러 자료에 흩어진 내용을 종합해줘	LLM Wiki
예전에 이걸 어떻게 했었지	LLM Wiki
우리 형식과 말투로 써줘	지침과 예시, 부족하면 파인튜닝

섞어 쓸 수도 있습니다. 위키 페이지를 RAG의 검색 대상에 넣거나, 위키로 범위를 좁힌 뒤 원문 조각을 검색합니다.

로컬 환경에서 고려할 점이 하나 있습니다. LLM Wiki의 정리 단계는 여러 파일을 읽고 고치는 작업이라 성능 좋은 모델과 에이전트 도구가 필요합니다. 강사는 이 단계에 온라인 코딩 에이전트를 씁니다. 문서를 외부로 보낼 수 없는 환경이라면 정리 단계를 어떤 모델로 할지부터 정해야 합니다. RAG는 작은 임베딩 모델과 로컬 대화 모델만으로 돌릴 수 있어서 이 제약이 덜합니다.

다음에 읽을 글

• 문서를 붙여 넣을까, RAG를 만들까
• RAG가 잘 되도록 사무 문서 준비하기