에이전트는 똑똑하지만, 내 회사·내 분야의 사정은 모른다. 흩어진 자료를 잘 쪼개 쌓고, 질문이 오면 그중 맞는 조각을 찾아 근거로 답하게 만드는 법. 모델의 기억이 아니라 내 지식으로 답하게 하는 다섯 걸음이다.
Lesson 55
LLM 위키란
에이전트에게 “우리 회사 환불 규정대로 답해줘”라고 하면, 모델은 일반적인 환불 상식을 그럴듯하게 지어낸다. 우리 규정은 그 두뇌 어디에도 없기 때문이다.
모델의 두뇌는 학습이 끝난 시점에 멈춰 있다. 우리 팀의 결정도, 어제 받은 메일도, 내 분야의 세부 규칙도 그 안엔 없다.
그래서 필요한 게 에이전트가 답하기 전에 들여다보는 ‘외부 노트’다. 모델 바깥에 내 지식을 글로 쌓아두고, 질문이 오면 거기서 찾아 읽고 답하게 한다. 이렇게 모델 밖 지식을 검색해 답에 끌어다 쓰는 방식을 RAG(검색 증강 생성)라고 부른다.
이름은 거창하지만 원리는 단순하다. 시험장에 다 외워 들어가는 대신, 잘 정리한 오픈북을 옆에 두고 필요할 때 펼쳐 보는 것과 같다.
그림 1. RAG의 흐름. 질문이 오면 위키에서 관련 노트를 검색해 근거로 모델에 넘기고, 모델은 그 근거로 출처가 달린 답을 낸다.
위키를 직접 두는 게 왜 나은가
“그냥 매번 자료를 통째로 붙여넣으면 되지 않나” 싶을 수 있다. 자료가 한두 장일 때는 맞는 말이다.
하지만 자료가 수백 장으로 불어나면 통째로 붙여넣는 건 불가능해진다. 한 번에 넣을 수 있는 양에 한계가 있고, 관련 없는 내용까지 잔뜩 끼면 답이 오히려 흐려진다.
위키를 따로 두면 질문에 맞는 조각만 골라 넘길 수 있다. 자료가 늘어도 답의 품질은 흔들리지 않고, 무엇을 근거로 답했는지 출처까지 짚을 수 있다. 이 ‘내 지식 저장소’를 이 교재에서는 LLM 위키라 부른다.
RAG
검색 증강 생성. 모델이 답하기 전에 외부 지식을 검색해 근거로 끌어다 쓰는 방식.
LLM 위키
에이전트가 답할 때 참고하는 내 지식 저장소. 모델 밖에 글로 쌓아둔 노트 묶음.
근거(출처)
답이 어느 노트에서 나왔는지 가리키는 표시. 환각을 줄이는 가장 싼 안전장치.
한 문장 요약
모델의 기억으로 답하게 하지 말고, 내 노트에서 찾아 답하게 한다.
에이전트는 똑똑하지만 내 사정은 모른다. 그 빈칸을 채우는 게 위키이고, 위키를 검색해 답하는 방식이 RAG다. 다음 레슨부터는 이 위키를 실제로 어떻게 쌓는지 다룬다.
Lesson 56
지식베이스 구축 — 아토믹 노트와 MOC
위키의 품질은 글을 얼마나 많이 쌓았느냐가 아니라, 얼마나 잘게 쪼갰느냐에서 갈린다.
긴 문서 한 덩어리는 검색에 약하다. 너무 많은 이야기가 한 파일에 엉켜 있어서, 막상 필요한 한 줄을 골라내기 어렵다.
그래서 노트를 ‘더 쪼갤 수 없는 작은 단위’로 만든다. 한 노트엔 한 가지 개념, 한 가지 주장만 담는다. 이렇게 만든 작은 노트를 아토믹 노트라 부른다. 작을수록 검색에 정확히 걸리고, 여러 답에 재사용하기도 좋다.
비유하자면 레고 블록이다. 큰 완성품 하나는 다른 데 못 쓰지만, 작은 블록은 이리저리 다시 조립된다. 노트도 잘게 나눠둘수록 새 질문에 맞춰 다시 끼워 맞추기 쉬워진다.
노트가 쌓이면 길을 잃는다 — MOC
잘게 쪼개면 노트 수가 빠르게 는다. 수백 개가 평평하게 흩어지면, 이번엔 내가 무엇을 가졌는지조차 헷갈린다.
그래서 노트를 묶는 ‘지도 노트’를 하나 둔다. 한 주제에 관련된 노트들의 링크를 모아둔 안내판인데, 이걸 MOC(Map of Content, 콘텐츠 지도)라 부른다. 책의 목차와 같은 역할이다.
노트끼리도 서로 링크로 잇는다. 그러면 평평한 파일 더미가 아니라, 서로 연결된 지식 그래프가 된다. 한 노트에서 옆 노트로, 다시 그 옆으로 — 생각이 이어지는 길이 생긴다.
그림 2. 위키 지식그래프. 작은 노트들이 링크로 이어지고, 가운데 허브(MOC)가 한 주제의 노트를 묶어 길을 안내한다.
한 노트 한 개념. 더 쪼갤 수 없을 만큼 작게. 제목만 봐도 무슨 내용인지 알게 짓는다.
frontmatter로 손잡이를 단다. 노트 맨 위에 제목·태그·출처를 적어두면, 나중에 검색과 필터의 손잡이가 된다.
링크와 MOC로 묶는다. 관련 노트를 서로 잇고, 주제별 지도 노트로 입구를 만든다.
자주 하는 실수
“일단 다 넣고 나중에 정리하자”는 위키를 가장 빨리 망친다. 정리 안 된 긴 글이 쌓이면 검색이 부정확해지고, 결국 아무도 안 쓰는 폴더가 된다. 들어올 때 쪼개는 것이 핵심이다 — 그 방법은 레슨 58에서 자동화한다.
한 문장 요약
잘게 쪼개 쌓고(아토믹 노트), 지도로 묶는다(MOC).
작은 노트는 검색에 정확히 걸리고 재사용이 쉽다. MOC와 링크는 흩어진 노트를 길이 난 지식 그래프로 바꾼다. 이렇게 쌓아둔 위키를 다음 레슨에서 ‘제대로 검색’한다.
Lesson 57
하이브리드 검색
위키를 잘 쌓아도, 찾지 못하면 없는 것과 같다. 검색이 빗나가면 에이전트는 근거를 못 찾아 다시 지어내기 시작한다.
검색에는 성격이 다른 두 방식이 있다. 둘은 각자 약점이 있어서, 하나만 쓰면 자주 헛다리를 짚는다.
두 가지 검색, 서로의 빈틈
하나는 키워드 검색이다. 노트 안에 그 단어가 글자 그대로 들어 있는지 찾는다. ‘환불’을 찾으면 ‘환불’이 적힌 노트가 정확히 걸린다. 대신 ‘반품’이라고 적은 노트는 놓친다 — 글자가 다르기 때문이다.
다른 하나는 의미 검색이다. 글자가 아니라 뜻이 가까운 노트를 찾는다. ‘환불’로 물어도 ‘반품·교환·돈을 돌려준다’ 같은 노트를 함께 끌어온다. 대신 정확한 제품 코드나 고유명사처럼 ‘딱 그 글자’를 찾을 땐 오히려 흐릿하게 빗나간다.
그래서 둘을 함께 쓴다. 키워드로 정확히 걸리는 것과 의미로 가깝게 걸리는 것을 모두 모은 뒤 합치는 방식을 하이브리드 검색이라 부른다. 한쪽이 놓친 걸 다른 쪽이 줍는다.
키워드로 한 번질문 속 핵심 단어가 글자 그대로 들어간 노트를 찾는다. 고유명사·코드·정확한 용어에 강하다.
의미로 한 번질문과 뜻이 가까운 노트를 따로 찾는다. 다른 말로 적힌 같은 내용을 줍는다.
합치고 추린다두 결과를 모아 중복을 빼고, 가장 관련 높은 몇 개만 근거로 남긴다.
근거로 넘긴다추려낸 노트만 모델에 넘겨 답하게 한다. 관련 없는 노트는 일부러 뺀다.
왜 ‘몇 개만’ 넘기나
찾은 노트를 전부 넘기면 관련 없는 내용이 섞여 답이 흐려진다(맥락 오염). 가장 관련 높은 서너 개로 추려 넘기는 편이, 많이 넘기는 것보다 거의 항상 정확하다. 적게, 정확하게가 원칙이다.
한 문장 요약
키워드로 정확히, 의미로 폭넓게 — 둘을 합쳐 빈틈을 메운다.
키워드 검색은 글자에 강하고 의미 검색은 뜻에 강하다. 하이브리드는 둘의 약점을 서로 덮는다. 잘 찾아 추려낸 근거가 좋은 답의 절반이다.
Lesson 58
수집 → 위키화
위키의 진짜 적은 게으름이 아니라 손이 많이 가는 정리 작업이다. 좋은 자료를 봐도, 쪼개서 태그 달고 링크까지 거는 일이 귀찮아 결국 안 쌓인다.
그래서 이 정리 작업을 에이전트에게 맡긴다. 긴 자료를 던지면 아토믹 노트로 쪼개고, frontmatter를 채우고, 링크 후보까지 달아 위키에 넣게 하는 것 — 이게 ‘수집에서 위키화까지’의 자동화다.
흐름은 단순하다. 자료를 가져오고(수집) → 작은 노트로 쪼개고(쪼개기) → 태그·출처를 채우고(정리) → 위키에 저장한다(쌓기). 사람은 결과 목록만 한 번 확인한다.
자료를 연다기사·회의록·논문 요약 등 위키에 넣을 원본과 위키 폴더를 함께 작업 대상으로 연다.
쪼개기를 시킨다“한 노트 한 개념으로 쪼개고 frontmatter를 채워라.” 아래 프롬프트 카드를 그대로 붙여넣는다.
목록부터 받는다곧바로 저장하지 말고, 어떤 노트를 만들지 제목 목록부터 받아 확인한다. 1모듈에서 익힌 ‘계획 먼저’ 그대로다.
진행 · 확인목록이 맘에 들면 저장시키고, 위키 폴더를 열어 노트가 잘 쪼개졌는지 눈으로 확인한다.
붙여넣기 프롬프트 · 자료를 아토믹 노트로 위키화
첨부한 자료를 "아토믹 노트"로 쪼개서 위키 폴더(/wiki)에 저장해줘.
- 한 노트에는 한 가지 개념·주장만 담는다 (작게 쪼갤수록 좋다)
- 파일명은 "주제-핵심키워드.md"로, 한글로 알아보기 쉽게
- 각 노트 맨 위에 frontmatter(title·tags 2~4개·source)를 넣어줘
- 본문 끝에 "관련: [[다른노트제목]]"으로 이어질 링크 후보를 적어줘
- 저장 전에 만들 노트 제목 목록부터 보여주고,
내가 "진행"이라고 하면 그때 저장해
“진행”. 위키 폴더를 열어 노트 다섯 장 안팎이 frontmatter와 함께 쌓였는지 확인한다.
목표: 긴 자료 하나가 손 안 대고 작은 노트 여러 장으로 쪼개져 쌓이는 흐름을 한 번 끝까지 돌려보는 것. 다음 레슨에서 이 위키에 직접 질문해본다.
한 번에 다 넣지 말 것
자료 수십 편을 한꺼번에 던지면 노트가 뒤섞이고 중복이 생긴다. 한 번에 한 편씩 넣고 목록을 확인하는 편이, 결국 더 빠르고 위키도 깨끗하다.
Lesson 59
오토리서치
여기까지 오면 마지막 한 걸음이 자연스럽게 보인다. 자료를 가져오고, 쪼개 쌓고, 검색해 답하는 일을 사람이 매번 손으로 잇는 대신 — 에이전트가 스스로 돌게 만드는 것이다.
이걸 오토리서치라 부른다. 주제 하나를 던지면 에이전트가 알아서 자료를 찾고, 위키로 정리하고, 부족한 곳을 다시 찾아 채우는 자율적인 조사 루프다.
1모듈에서 봤던 ‘관찰 → 판단 → 행동’ 루프가 지식관리에 그대로 적용된 모습이라고 보면 된다. 무엇을 알고 무엇을 모르는지 살피고(관찰), 다음에 뭘 찾을지 정하고(판단), 찾아 위키에 넣는다(행동). 이 한 바퀴를 충분해질 때까지 반복한다.
한 바퀴가 도는 모습
예를 들어 “경쟁사 다섯 곳의 환불 정책을 정리해줘”라고 시킨다고 하자. 에이전트는 한 곳씩 자료를 찾아 아토믹 노트로 쌓고, 다섯 곳이 다 모였는지 점검하고, 빠진 곳을 다시 찾는다. 다 차면 위키를 근거로 비교표를 만들어 답한다.
오토리서치 — 경쟁사 환불 정책
❯ 경쟁사 5곳의 환불 정책을 조사해서 위키로 정리하고 비교표를 만들어줘
# 에이전트가 스스로 돌린 루프✓ 1바퀴 — A사·B사 자료 수집, 아토믹 노트 6장 저장
✓ 점검 — 아직 C·D·E사 노트 없음 → 더 찾기로 판단
✓ 2바퀴 — C·D·E사 수집, 노트 9장 추가 (출처 frontmatter 기록)
✓ 점검 — 5곳 모두 확보 → 조사 종료
✓환불정책-비교표.md 작성 (각 행에 근거 노트 링크 표시)
붙여넣기 프롬프트 · 위키를 근거로 답하기 (RAG)
앞으로 내 질문에 답할 때는 /wiki 안의 내 노트에서 먼저 찾아 답해줘.
- 관련 노트를 검색해 골라 읽고, 그 내용을 근거로 답한다
- 답 끝에 "근거: [노트제목]"으로 어떤 노트를 봤는지 꼭 표시해줘
- 위키에 근거가 없으면 지어내지 말고 "관련 노트 없음"이라고 말해줘
- 위키와 일반 지식이 충돌하면 위키를 우선하되 그 사실을 알려줘
질문: (여기에 질문)
오토리서치는 강력하지만, 멈출 줄 모르면 끝없이 자료만 긁어모은다. “언제 충분한가”를 미리 정해줘야 한다 — 예: “출처 5개를 모으면 종료”, “세 바퀴까지만”. 자율성과 멈춤 조건은 한 쌍이다(9모듈 권한·5모듈 검증의 연장선).
모듈 13 마무리
지식관리의 끝은, 조사하는 일까지 에이전트가 스스로 돌게 하는 것이다.
위키가 무엇인지(L55), 어떻게 쌓는지(L56), 제대로 찾는 법(L57), 자료를 위키로 바꾸는 자동화(L58)를 거쳐, 마지막엔 그 전부를 스스로 도는 오토리서치(L59)에 닿았다. 모델의 기억 대신 내가 쌓은 지식으로 답하는 에이전트 — 이게 이 모듈이 남기는 결과물이다. 다음 모듈에서는 이 능력을 이미지·콘텐츠 대량생성으로 확장한다.
출처 · 더 읽을거리
이 모듈의 근거 문서
논문Lewis et al. — Retrieval-Augmented Generation (2020)
