자료 넣기: Ingest 워크플로

Ingest는 수집이 아니라 흡수다

LLM Wiki에서 자료를 넣는 일은 단순한 저장이 아니다. 웹 문서를 저장하고, PDF를 모으고, 회의록을 쌓아두는 것만으로는 위키가 똑똑해지지 않는다. 자료는 raw/에 보관될 때 기록이 되고, wiki/에 반영될 때 지식이 된다.

여기서 ingest는 새 자료를 위키에 흡수하는 과정이다. 원문을 읽고, 핵심을 뽑고, 기존 페이지와 연결하고, 필요한 페이지를 새로 만들고, 변경 이력을 남기는 전체 흐름을 뜻한다.

좋은 ingest는 매번 같은 질문에 새로 답하지 않는다. 한 번 들어온 자료가 여러 페이지를 고치고, 기존 지식과 연결되며, 다음 질문의 출발점이 되게 만든다. 그래서 LLM Wiki에서 가장 중요한 운영 루틴은 "자료를 많이 저장하기"가 아니라 "자료를 넣을 때마다 위키 전체를 조금씩 개선하기"다.

기본 절차: raw에 넣고, wiki를 갱신한다

가장 단순한 ingest 흐름은 다섯 단계로 나눌 수 있다.

1. 새 자료를 raw/에 저장한다.

2. LLM에게 원문을 읽게 한다.

3. source-summary 페이지를 만든다.

4. 관련 wiki 페이지를 새로 만들거나 갱신한다.

5. index.md와 log.md를 업데이트한다.

예를 들어 웹 기사 하나를 넣는다면 다음처럼 저장할 수 있다.

raw/articles/2026-05-19-llm-wiki-karpathy.md

PDF 논문이라면 다음과 같이 둘 수 있다.

raw/papers/2026-05-19-paper-title.pdf
raw/papers/2026-05-19-paper-title-notes.md

책 챕터라면 이렇게 저장한다.

raw/books/book-title/chapter-03.md

회의록은 날짜와 프로젝트명을 포함하는 편이 좋다.

raw/meetings/2026-05-19-product-roadmap.md

이름 규칙은 복잡할 필요가 없다. 중요한 것은 나중에 사람이 봐도 언제, 무엇을, 어디에서 가져온 자료인지 알 수 있어야 한다는 점이다. 파일명에 날짜, 자료 유형, 제목을 넣으면 대부분 충분하다.

그리고 한 가지 원칙을 지켜야 한다. raw/의 원문은 수정하지 않는다. 오탈자를 고치고 싶어도 원문은 그대로 둔다. 원문은 증거이고, 위키는 해석이다. LLM이 요약을 잘못했거나 사람이 나중에 다른 해석을 하더라도, 원문이 그대로 남아 있어야 다시 검토할 수 있다.

source-summary는 자료의 입구다

새 자료가 들어오면 곧바로 개념 페이지를 고치기보다 먼저 source-summary를 만드는 것이 좋다. source-summary는 특정 자료 하나에 대한 요약 카드다. 원문 전체를 매번 다시 읽지 않아도, 이 자료가 무엇을 말하는지 빠르게 확인할 수 있게 해준다.

예시는 다음과 같다.

# 2026-05-19 LLM Wiki 관련 기사 요약

- 원문 위치: raw/articles/2026-05-19-llm-wiki-karpathy.md
- 자료 유형: 웹 기사
- 주제: LLM Wiki, 지식 축적, AI 에이전트
- 핵심 주장:
  - LLM은 대화마다 장기 기억을 유지하지 못한다.
  - Markdown 기반 위키를 두면 지식이 누적된다.
  - AI는 단순 답변자가 아니라 위키 관리자로 작동할 수 있다.
- 위키 반영 대상:
  - wiki/concepts/llm-wiki.md
  - wiki/concepts/rag-vs-wiki.md
  - wiki/people/andrej-karpathy.md
- 검토 필요:
  - 실제 발언 원문 확인 필요
  - RAG와의 차이 설명 보강 필요

source-summary는 길 필요가 없다. 핵심은 "이 자료가 왜 들어왔는가"와 "어디에 반영되었는가"를 남기는 것이다. 나중에 어떤 개념 페이지가 특정 주장을 포함하게 되었을 때, 그 주장이 어떤 자료에서 왔는지 추적할 수 있어야 한다.

하나의 자료는 여러 페이지를 바꾼다

초보자가 자주 하는 실수는 자료 하나를 요약 파일 하나로만 남기는 것이다. 물론 요약은 필요하다. 하지만 LLM Wiki의 힘은 요약 파일이 아니라 연결된 페이지에서 나온다.

예를 들어 LLM Wiki에 관한 인터뷰 하나를 넣었다고 하자. 이 자료는 하나의 파일이지만, 위키에서는 여러 방향으로 반영될 수 있다.

• sources/ 또는 raw/ 기반 source-summary 페이지 생성

• wiki/concepts/llm-wiki.md에 개념 설명 추가

• wiki/concepts/rag.md에 RAG의 한계와 비교 내용 추가

• wiki/comparisons/rag-vs-llm-wiki.md에 차이점 추가

• wiki/people/andrej-karpathy.md에 관련 발언 기록 추가

• wiki/index.md에 새 페이지 링크 추가

• logs/ 또는 log.md에 변경 이력 기록

이것이 ingest의 핵심이다. 자료 하나가 위키의 여러 지점을 동시에 갱신한다. 반대로 말하면, 자료를 넣을 때마다 "이 자료는 어떤 기존 페이지를 더 똑똑하게 만들 수 있는가?"라고 물어야 한다.

LLM에게 요청할 때도 단순히 "요약해줘"라고 하면 안 된다. 다음처럼 요청하는 편이 좋다.

다음 raw 자료를 읽고 LLM Wiki에 ingest하라.

작업 순서:
1. source-summary 페이지를 만든다.
2. 기존 wiki 페이지 중 갱신할 페이지를 찾는다.
3. 필요한 경우 새 concept, people, comparison 페이지를 만든다.
4. 모든 주장에는 원문 위치를 연결한다.
5. index.md에 새 페이지와 주요 변경 사항을 반영한다.
6. log.md에 날짜, 자료명, 변경한 페이지, 검토 필요 사항을 기록한다.

주의:
- raw 원문은 수정하지 않는다.
- 확실하지 않은 내용은 추정으로 표시한다.
- 기존 내용과 충돌하면 덮어쓰지 말고 '검토 필요'로 남긴다.

이 프롬프트는 AI에게 단순 요약자가 아니라 위키 관리자로 행동하라고 지시한다.

웹 문서 ingest

웹 문서는 가장 자주 들어오는 자료다. 블로그 글, 뉴스 기사, 공식 문서, 인터뷰, 포럼 글이 여기에 해당한다. 웹 문서의 장점은 빠르고 다양하다는 것이다. 단점은 품질 차이가 크고, 시간이 지나면 링크가 사라지거나 내용이 바뀔 수 있다는 점이다.

웹 문서를 넣을 때는 세 가지를 확인해야 한다.

첫째, URL과 접근 날짜를 남긴다. 둘째, 글쓴이와 발행 주체를 기록한다. 셋째, 사실과 의견을 구분한다.

프롬프트는 다음처럼 쓸 수 있다.

이 웹 문서를 LLM Wiki에 ingest하라.

특히 다음을 구분하라.
- 확인 가능한 사실
- 저자의 해석 또는 의견
- 우리 위키에 반영할 만한 개념
- 기존 페이지와 충돌하는 주장

결과물:
1. source-summary 작성
2. 관련 concept 페이지 업데이트
3. 필요한 comparison 페이지 업데이트
4. index.md와 log.md 갱신

웹 문서는 빠르게 반영하되, 너무 쉽게 믿으면 안 된다. 특히 "업계의 미래", "최고의 방법", "가장 중요한 변화" 같은 표현은 대개 저자의 해석이다. 위키에는 이런 문장을 그대로 넣기보다 "어떤 관점에서는 이렇게 볼 수 있다"는 식으로 낮은 확신도로 정리하는 편이 안전하다.

PDF와 논문 ingest

PDF와 논문은 웹 기사보다 구조가 단단하다. 하지만 길고 어렵다. 이때는 전체 요약보다 연구 질문, 방법, 결과, 한계를 분리하는 것이 중요하다.

논문 ingest 프롬프트는 다음처럼 구성할 수 있다.

이 논문을 LLM Wiki에 ingest하라.

다음 항목을 중심으로 정리하라.
- 연구 질문: 이 논문은 무엇을 해결하려 하는가?
- 배경: 기존 연구의 어떤 한계를 다루는가?
- 방법: 어떤 접근을 사용했는가?
- 결과: 무엇을 확인했는가?
- 한계: 저자가 인정한 한계와 내가 추가로 의심해야 할 점은 무엇인가?
- 관련 개념: 위키의 어떤 concept 페이지와 연결되는가?

작업 후 source-summary, concept 페이지, research 페이지, index.md, log.md를 갱신하라.

논문은 특히 "결과"와 "주장"을 섞지 않는 것이 중요하다. 실험에서 확인된 내용은 결과다. 그 결과를 바탕으로 일반화한 말은 주장이다. LLM은 종종 논문의 결론을 더 크게 부풀려 말한다. 따라서 논문 ingest에서는 "이 논문이 실제로 보여준 것"과 "이 논문이 암시하는 것"을 나눠 적게 해야 한다.

책 챕터 ingest

책은 논문과 다르게 긴 논리 흐름을 가진다. 한 챕터에는 개념, 사례, 주장, 반론, 비유가 섞여 있다. 책을 ingest할 때는 챕터별 요약을 만드는 것에서 끝내지 말고, 책 전체를 관통하는 개념 네트워크를 만들어야 한다.

책 챕터용 프롬프트는 다음과 같다.

이 책 챕터를 LLM Wiki에 ingest하라.

다음 기준으로 정리하라.
1. 이 챕터의 핵심 주장
2. 새로 등장한 개념
3. 이전 챕터와 연결되는 내용
4. 저자가 반복해서 강조하는 관점
5. 반론 또는 비판 가능성
6. 나의 프로젝트나 글쓰기에 재활용할 수 있는 아이디어

작업:
- 책 요약 페이지 업데이트
- 새 concept 페이지 생성 또는 기존 concept 페이지 갱신
- 인물, 사례, 용어가 중요하면 별도 페이지 생성
- index.md와 log.md 갱신

책을 위키로 바꿀 때 가장 좋은 질문은 "이 장을 나중에 어디에 써먹을 수 있는가?"이다. 독후감에 쓸 수도 있고, 강의안에 쓸 수도 있고, 제품 전략이나 개인 회고에 연결할 수도 있다. LLM Wiki는 책을 읽고 잊어버리는 일을 줄여준다. 책의 문장이 아니라 책에서 얻은 생각의 부품을 남기기 때문이다.

회의록 ingest

회의록은 팀 위키에서 가장 가치 있는 자료 중 하나다. 많은 조직에서 중요한 결정은 회의에서 이루어지지만, 시간이 지나면 왜 그런 결정을 했는지 잊힌다. 회의록 ingest의 목적은 대화 전체를 예쁘게 정리하는 것이 아니라 결정, 근거, 할 일을 남기는 것이다.

회의록 프롬프트는 다음처럼 쓴다.

이 회의록을 LLM Wiki에 ingest하라.

다음을 분리해서 정리하라.
- 결정된 사항
- 결정의 근거
- 논의했지만 결정하지 않은 사항
- 담당자와 다음 행동
- 위험 요소
- 나중에 다시 확인해야 할 질문

작업:
- 프로젝트 페이지 업데이트
- 필요한 decision 페이지 생성
- 관련 고객 피드백 또는 기능 기획 페이지 연결
- index.md와 log.md 갱신

회의록에서 가장 중요한 페이지는 의사결정 기록이다. 단순히 "A 기능을 만들기로 했다"가 아니라 "왜 A 기능을 만들기로 했는가"를 남겨야 한다. 나중에 상황이 바뀌었을 때, 결정의 근거를 다시 검토할 수 있기 때문이다.

좋은 decision 페이지는 다음 질문에 답한다.

• 어떤 결정을 했는가?

• 어떤 선택지가 있었는가?

• 왜 이 선택을 했는가?

• 어떤 조건이 바뀌면 결정을 재검토해야 하는가?

• 누가 검토했고 언제 결정했는가?

이 구조가 쌓이면 팀은 같은 논의를 반복하지 않는다.

유튜브와 강의 transcript ingest

영상과 강의는 정보량이 많지만 구조가 느슨하다. 말은 글보다 반복이 많고, 핵심이 뒤늦게 나오는 경우도 많다. 따라서 transcript를 ingest할 때는 단순 요약보다 주제별 재구성이 필요하다.

프롬프트는 다음처럼 쓴다.

이 강의 transcript를 LLM Wiki에 ingest하라.

작업 기준:
- 반복 표현은 제거한다.
- 시간 순서보다 주제별 구조를 우선한다.
- 중요한 개념, 사례, 프레임워크를 추출한다.
- 강연자의 의견과 확인 가능한 사실을 구분한다.
- 인용할 만한 표현은 별도로 표시하되, 위키 본문에는 내 문장으로 재작성한다.

작업 후 source-summary, concept 페이지, people 페이지, index.md, log.md를 갱신하라.

영상 자료에서 특히 조심할 점은 말의 분위기를 사실처럼 기록하지 않는 것이다. 강연자는 강조를 위해 단정적으로 말할 수 있다. 위키에는 그 단정을 그대로 옮기기보다 맥락을 붙여야 한다. 예를 들어 "앞으로 모든 회사가 AI 회사를 해야 한다"라는 말은 사실이 아니라 주장이다. 위키에는 "강연자는 AI 활용 역량이 회사 경쟁력의 핵심이 될 것이라고 주장한다"처럼 정리하는 편이 낫다.

index.md와 log.md는 반드시 갱신한다

ingest가 끝났다면 마지막 작업은 항상 index.md와 log.md 갱신이다. 이 두 파일을 소홀히 하면 위키는 금방 어두운 창고가 된다.

index.md는 탐색을 위한 지도다. 새로 만든 페이지, 중요한 개념, 자주 봐야 할 프로젝트를 연결한다. 모든 파일을 다 넣을 필요는 없지만, 위키의 입구가 될 만한 페이지는 반드시 연결해야 한다.

예시는 다음과 같다.

## 최근 추가된 자료

- [[concepts/llm-wiki]]: LLM이 관리하는 축적형 지식 구조
- [[comparisons/rag-vs-llm-wiki]]: 검색 기반 답변과 축적 기반 위키의 차이
- [[people/andrej-karpathy]]: LLM Wiki 아이디어 관련 인물 메모

log.md는 변경 이력이다. 위키가 언제, 어떤 자료 때문에, 어떻게 바뀌었는지 남긴다.

## 2026-05-19

- ingest: raw/articles/2026-05-19-llm-wiki-karpathy.md
- 생성: wiki/concepts/llm-wiki.md
- 갱신: wiki/comparisons/rag-vs-llm-wiki.md
- 갱신: wiki/people/andrej-karpathy.md
- 검토 필요: 원 발언 출처와 날짜 확인

로그는 자세한 일기가 아니다. 나중에 추적할 수 있을 정도면 충분하다. 어떤 자료가 들어왔고, 어떤 페이지가 바뀌었고, 무엇을 다시 확인해야 하는지만 남기면 된다.

좋은 ingest의 기준

좋은 ingest는 예쁜 요약이 아니다. 위키가 실제로 더 쓸모 있어졌는지가 기준이다.

다음 질문으로 점검해보자.

• 원문이 raw/에 보존되어 있는가?

• source-summary가 만들어졌는가?

• 기존 페이지와 연결되었는가?

• 새로 필요한 개념 페이지가 생겼는가?

• 사실, 추정, 의견이 구분되어 있는가?

• 출처가 없는 단정이 추가되지 않았는가?

• index.md에서 찾을 수 있는가?

• log.md에 변경 이력이 남았는가?

이 질문에 대부분 "예"라고 답할 수 있다면 좋은 ingest다.

LLM Wiki는 한 번에 완성되지 않는다. 자료 하나를 넣고, 관련 페이지를 조금 고치고, 로그를 남기는 작은 작업이 반복되면서 강해진다. 오늘 넣은 웹 기사 하나가 내일의 글감이 되고, 다음 달의 강의안이 되고, 1년 뒤의 책 기획이 될 수 있다.

자료를 쌓아두면 저장소가 된다. 자료를 흡수하면 지식 시스템이 된다. Ingest 워크플로는 그 차이를 만드는 첫 번째 습관이다.