1장. LLM위키가 필요한 이유 원문 기반 정리

원문과 확인 범위

• 장 원문: 1장. LLM위키가 필요한 이유
• 원천 도서: LLM위키 완벽 가이드
• 하위 원문: 1.1 LLM을 써도 지식이 남지 않는 이유, 1.2 LLM위키는 무엇인가, 1.3 이 책에서 만들 결과물

확인일은 2026-06-06 KST이며, 장 랜딩과 하위 원문 1.1, 1.2, 1.3의 마지막 편집일시는 2026년 5월 16일 1:06 오후로 기록되어 있다. 장 랜딩 페이지는 세 하위 절 목록 중심의 짧은 입구이므로, 장 수준의 실질 내용은 1.1의 문제 진단, 1.2의 개념 정의, 1.3의 결과물 미리보기를 함께 읽어야 완성된다.

핵심 요지

1장의 결론은 “LLM위키를 만들자”가 아니라 “작고 반복되는 업무 지식 하나를 골라 원천, 정리본, 산출물, 규칙으로 남길 준비가 되었는지 확인하자”이다.

원문 구조

세 절은 순서가 중요하다. 1.1이 없으면 도구부터 고르게 되고, 1.2가 없으면 LLM위키를 특정 앱이나 프롬프트 모음으로 오해하며, 1.3이 없으면 결과물이 무엇인지 모른 채 큰 지식베이스를 상상하게 된다.

세부 내용 정리

1. 반복 설명은 프롬프트 문제가 아니라 지식 후보 신호다

회의록 정리, 고객 문의 분류, 보고서 초안 같은 업무 요청에는 항상 배경 기준이 따라온다. 실행 항목 표기 방식, 결정 사항과 논의 중 항목의 분리, 민감 정보 제외, 공유 대상에 맞는 문체, 다음 회의 질문 같은 기준은 매번 새로 만들 정보가 아니다. 같은 업무를 반복한다면 이 기준은 다음에도 재사용할 업무 지식이다.

• 같은 설명을 두 번 이상 했다.
• 답변 품질이 배경 설명의 양에 크게 달라진다.
• 팀, 고객, 제품, 보안, 문체와 관련된 합의 기준이 들어간다.
• 출처나 확인일이 중요하다.
• 다음 달이나 다음 회의에서도 같은 방식으로 쓸 가능성이 있다.

반대로 단순 말투 반복이나 일회성 아이디어 요청은 LLM위키보다 프롬프트 템플릿이나 개인 메모로 충분할 수 있다. 1장은 모든 LLM 대화를 위키로 만들라고 하지 않는다.

2. 대화 기록은 원천 후보이지 완성 지식이 아니다

이 변환을 거치면 “지난 대화 어디 있지?”가 “이 기준 문서를 참고해 처리하자”로 바뀐다. 1장의 문제 진단은 바로 이 전환을 목표로 한다.

3. LLM위키는 제품명이 아니라 반복 지식 작업의 운영 패턴이다

• raw/: 회의록, 업무 메모, 웹 문서, 코드 리뷰 기록처럼 나중에 다시 확인할 원천 자료다.
• wiki/: 원천을 읽고 개념, 결정, 절차, 질문으로 재구성한 활용 문서다.
• rules 또는 schema: AGENTS.md, CLAUDE.md, 정리 기준처럼 LLM이 원천과 정리본을 섞지 않도록 하는 작업 기준이다.
• 질문과 산출물: 위키를 기준으로 질문하고 보고서와 실행 계획을 만들며, 가치 있는 결과는 다시 위키에 반영한다.

이 정의 때문에 LLM위키는 RAG와도 다르다. RAG는 질문 시점에 관련 자료를 검색해 답변을 보강하는 방식에 가깝고, LLM위키는 미리 정리된 지식 구조를 계속 갱신하는 운영 방식이다.

4. 컴파일은 요약이 아니라 재사용 가능한 지식으로 재구성하는 일이다

5. 첫 결과물은 작고 물리적인 구조여야 한다

1.3은 LLM위키를 추상 개념으로 끝내지 않고 작은 폴더 구조로 보여 준다. 예제 주제는 work-automation이고, 최소 구성은 원천 자료를 둘 raw/, 정리 문서를 둘 wiki/, 보고서와 실행 계획을 둘 output/, 아직 정리하지 않은 메모를 둘 inbox/, 전체 입구인 index.md, 처리 이력인 log.md, 작업 규칙인 AGENTS.md 또는 CLAUDE.md다.

중요한 것은 폴더 이름 자체가 아니라 책임 분리다. 원천 자료가 보고서로 바로 바뀌면 근거를 추적하기 어렵다. 중간에 위키 문서가 있어야 질문의 맥락이 안정되고, 산출물의 근거도 다시 확인할 수 있다.

6. 1장의 산출물은 첫 후보와 첫 질문이다

• 반복해서 다시 설명한 업무 맥락 후보 목록
• 대화 기록과 업무 지식을 구분한 판단 메모
• 첫 LLM위키 후보 1개와 제외한 후보의 이유
• LLM위키를 특정 제품이 아니라 패턴으로 이해한 정의 메모
• 최소 구조 초안: raw/, wiki/, output/, inbox/, index.md, log.md, rules 파일
• 2장에서 구조화할 핵심 질문 1개

실무 적용 절차

1. 최근 1주일 동안 LLM에게 다시 설명한 업무 3개를 적는다.
2. 각 업무에서 반복된 맥락을 출력 형식, 판단 기준, 금지 사항, 문체, 참고 자료, 결정 이력으로 나눈다.
3. 단순 말투 반복인지, 출처와 확인일이 필요한 업무 기준인지 판정한다.
4. 대화 기록을 그대로 보존할지, 업무 지식 문서로 재구성할지 결정한다.
5. 후보별로 다음에도 필요한가, 팀이나 고객 합의 기준이 있는가, 다음 산출물에 바로 쓰이는가를 점검한다.
6. 세 가지 이상 해당하는 후보만 첫 LLM위키 후보로 남긴다.
7. 첫 후보는 회의록 실행 항목 정리, 월간 보고서 작성 규칙, 고객 문의 분류 기준처럼 작게 잡는다.
8. 후보 업무의 원천 자료가 회의록, 기존 보고서, 정책 문서, 고객 문의 샘플, 대화 기록 중 어디에 있는지 적는다.
9. 원천 자료가 거의 없으면 위키 후보가 아니라 확인 필요 또는 자료 수집 후보로 둔다.
10. 민감 정보가 포함되면 외부 LLM 호출, 플러그인 권한, 저장 위치, 익명화 기준을 먼저 확인한다.
11. 후보 업무를 LLM위키 패턴으로 한 문장 정의한다.
12. 최소 결과물 구조를 적고 raw/, wiki/, output/에 들어갈 내용을 구분한다.
13. 첫 질문에는 사용할 자료 범위, 업무 목적, 출력 형식, 확인 필요 표시를 포함한다.
14. 2장으로 넘어가기 전에 원천, 위키, 산출물, 작업 규칙의 차이를 말로 설명할 수 있는지 확인한다.

예시와 체크리스트

첫 LLM위키 후보 판정표

대화 기록을 업무 지식으로 바꾸는 최소 점검

• 대화에서 최종 채택한 기준과 중간에 버린 기준을 구분했다.
• 확인된 사실, 결정한 기준, 예외 규칙, 금지 사항, 확인 필요를 별도 항목으로 나눴다.
• 확인일과 상태를 남겼다.
• 원천 대화나 회의록으로 돌아갈 링크 또는 경로를 남겼다.
• 다음 질문에 바로 재사용할 한 문장 기준을 만들었다.
• 민감 정보가 포함된 원문은 그대로 외부 도구에 넣지 않도록 표시했다.

1장 산출물 템플릿

작게 시작하는 예시

검증 질문

• LLM위키가 필요한 이유를 도구 기능이 아니라 반복 업무 맥락의 손실로 설명할 수 있는가?
• 최근 업무에서 매번 다시 설명한 기준, 출력 형식, 금지 사항, 참고 자료를 적었는가?
• 대화 기록과 업무 지식을 구분했는가?
• 대화 기록을 원천 후보로 둘 때 확인된 내용, 결정, 남은 의문, 출처를 따로 정리했는가?
• 첫 후보가 너무 크지 않은가?
• 후보 업무에 실제 원천 자료가 있는가?
• 출처나 확인일이 중요하지 않은 단순 말투 반복을 위키 후보로 과하게 승격하지 않았는가?
• LLM위키를 특정 제품명이나 플러그인 이름으로 단정하지 않았는가?
• 컴파일을 단순 요약이 아니라 출처, 구조, 연결, 확인 필요, 갱신 기준을 남기는 작업으로 이해했는가?
• 최소 구조에서 raw/, wiki/, output/, inbox/, index.md, log.md, rules 파일의 책임을 구분할 수 있는가?
• 민감 정보, 계약 정보, 비공개 코드, 고객 원문을 첫 실습에 그대로 넣지 않도록 보안 기준을 세웠는가?
• 2장으로 넘어가기 전에 구조화할 첫 업무 질문 1개가 남았는가?

관련 문서 연결

• 통합 루트: 책 전체를 raw -> wiki -> output -> review 흐름으로 통합한 안내 문서다.
• 1.1 LLM을 써도 지식이 남지 않는 이유: 반복 업무 맥락, 대화 기록과 업무 지식의 차이, 첫 후보 판정을 다룬다.
• 1.2 LLM위키는 무엇인가: LLM위키를 제품이 아니라 원천 자료, 위키, 작업 규칙, 질문과 갱신을 잇는 패턴으로 정의한다.
• 1.3 이 책에서 만들 결과물: 작은 업무 주제 위키와 최소 폴더, 장별 산출물 흐름을 보여 준다.
• 2장. LLM위키의 기본 구조: 1장에서 고른 후보를 raw/, wiki/, rules, index.md, log.md, output/ 구조로 나눈다.
• 3장. 내게 맞는 LLM위키 방식 고르기: 1장에서 정의한 패턴을 어떤 도구와 방식으로 시작할지 고른다.
• 4장. 첫 번째 주제 위키 만들기: 1장에서 고른 첫 후보를 실제 업무 주제 위키로 초기화한다.
• 8장. 오래 믿고 쓰는 LLM위키 운영법: 1장에서 강조한 출처, 확인일, 확인 필요를 장기 감사 루틴으로 되돌려 점검한다.

누락 또는 주의사항

• 장 랜딩 원문은 세 하위 절 목록 중심의 짧은 페이지다. 이 문서는 장 랜딩만이 아니라 1.1-1.3 세부 원문을 함께 반영해 장 수준으로 재구성했다.
• 원문에 포함된 Andrej Karpathy의 LLM Wiki 아이디어, nvk/llm-wiki, WiCER, Codex AGENTS.md, Claude Code CLAUDE.md 관련 설명은 원문 확인일 기준의 배경 자료다. 실제 도구 도입 전에는 현재 공식 문서, 릴리스, 조직 보안 정책을 다시 확인해야 한다.
• LLM위키는 모든 대화를 저장하는 장치가 아니다. 반복성이 낮거나 출처가 중요하지 않은 요청은 프롬프트 템플릿, 개인 메모, 일회성 대화로 충분할 수 있다.
• 원천 자료가 거의 없거나 검토자가 없으면 LLM이 그럴듯한 추정으로 빈칸을 채울 위험이 있다. 이런 경우 첫 위키 후보가 아니라 자료 수집 또는 확인 필요로 남긴다.
• 개인정보, 계약 정보, 비공개 코드, 고객 원문은 첫 실습에 그대로 넣지 않는 편이 안전하다. 로컬 저장 여부와 별개로 URL 수집, 웹 검색, LLM 호출은 도구와 조직 정책을 따른다.
• 1장의 파일 구조 예시는 학습용 공통 구조다. 실제 저장 위치와 규칙 파일명은 사용하는 도구의 문서와 실행 환경에 맞게 조정해야 한다.
• 이 문서는 원문을 장문 복제하지 않고, 공개 원문에서 확인한 구조와 실습 의도를 실무 절차, 판단 기준, 체크리스트, 감사 질문으로 재구성했다.