리서치와 글쓰기에 활용하기

빈 문서에서 시작하지 않는다

많은 사람이 글쓰기를 빈 문서에서 시작한다. 제목을 쓰고, 목차를 짜고, 첫 문장을 고민한다. 하지만 리서치 기반 글쓰기에서는 이 방식이 자주 막힌다. 아직 충분히 읽지 않았고, 관점이 정리되지 않았고, 근거와 반례가 분리되지 않았기 때문이다.

LLM Wiki를 쓰면 순서가 바뀐다. 먼저 글을 쓰는 것이 아니라, 먼저 위키를 키운다. 논문, 기사, 보고서, 인터뷰, 책, 강의 노트를 raw/에 모은다. AI에게 그것을 읽히고 wiki/ 안의 개념, 주장, 근거, 반례, 인물, 기관, 사례 페이지로 나누게 한다. 시간이 지나면 위키 안에 특정 주제에 대한 작은 지식 지도가 생긴다.

그다음 글을 쓴다. 이때 글쓰기는 무에서 유를 만드는 일이 아니다. 이미 축적된 페이지에서 구조를 뽑고, 주장을 고르고, 근거를 배치하고, 독자에게 맞는 순서로 재조립하는 일에 가까워진다.

핵심은 단순하다.

목차를 먼저 만들지 말고, 위키가 목차를 낳게 하라.

리서치 자료는 네 종류의 페이지로 분해한다

리서치 자료를 넣을 때 가장 흔한 실수는 요약 페이지 하나만 만드는 것이다. 예를 들어 보고서 하나를 읽고 2026 AI 업무 자동화 보고서 요약.md 같은 파일만 만들면, 나중에 그 내용은 다시 찾기 어렵다. 요약은 자료 단위로 묶여 있기 때문이다.

LLM Wiki에서는 자료를 주제 단위로 다시 분해해야 한다. 특히 글쓰기와 책 기획을 목표로 한다면 다음 네 종류의 페이지가 중요하다.

첫째, 관점 페이지다. 관점 페이지는 어떤 주제를 바라보는 렌즈를 정리한다. 예를 들어 AI는 일자리를 대체하는가.md, 개인 지식관리는 생산성 도구인가 학습 시스템인가.md, 스타트업에서 문서화는 속도를 늦추는가.md 같은 페이지다. 관점 페이지에는 한 가지 결론만 적지 않는다. 서로 다른 해석을 함께 모은다.

둘째, 주장 페이지다. 주장 페이지는 글의 뼈대가 된다. 예를 들어 AI 대화 기록은 지식 자산이 되기 어렵다.md라는 페이지를 만들 수 있다. 이 페이지에는 주장의 핵심 문장, 이 주장을 뒷받침하는 근거, 적용되는 조건, 반박 가능성을 적는다.

셋째, 근거 페이지다. 근거 페이지는 숫자, 사례, 인용 가능한 사실, 조사 결과, 실험 결과를 모은다. 글을 쓸 때 설득력은 대부분 여기서 나온다. 단, 근거는 원문과 연결되어 있어야 한다. 출처 없는 근거는 나중에 불안한 문장이 된다.

넷째, 반례 페이지다. 좋은 글은 자기 주장만 밀어붙이지 않는다. 예외와 반론을 다룰 때 더 강해진다. 예를 들어 RAG는 항상 부족한가.md라는 반례 페이지를 만들면, 위키는 균형을 갖게 된다. LLM Wiki가 단순한 아이디어 창고가 아니라 사고의 검증 장치가 되는 순간이다.

하나의 자료는 여러 페이지를 업데이트할 수 있다. 논문 하나가 개념 페이지를 만들고, 주장 페이지를 보강하고, 반례 페이지를 새로 만들고, 타임라인 페이지에 사건을 추가할 수 있다. 이 분해 과정이 리서치 위키의 핵심이다.

자료의 신뢰도와 날짜를 함께 관리한다

리서치와 글쓰기에서 오래된 정보는 조용히 위험해진다. 당시에는 맞았지만 지금은 틀린 주장도 있고, 특정 산업에서는 1년 전 자료도 오래된 자료가 될 수 있다. 특히 AI, 소프트웨어, 정책, 시장 데이터처럼 변화가 빠른 분야에서는 날짜 관리가 중요하다.

각 위키 페이지에는 최소한 다음 정보를 남기는 것이 좋다.

• source_type: 논문, 기사, 보고서, 인터뷰, 책, 강의, 내부 문서

• published_at: 원문 발행일

• ingested_at: 위키에 넣은 날짜

• last_checked: 마지막으로 검토한 날짜

• confidence: 높음, 중간, 낮음

• status: 유효, 확인 필요, 오래됨, 반박됨

이 정보는 단순한 관리용 메타데이터가 아니다. AI에게 판단 기준을 주는 장치다. 나중에 "이 주제에 대해 최신 근거 중심으로 글의 개요를 만들어줘"라고 요청했을 때, AI는 발행일과 상태를 참고할 수 있다. "오래된 주장과 여전히 유효한 주장을 나눠줘"라고 요청할 수도 있다.

신뢰도도 함께 관리해야 한다. 모든 자료는 같은 무게를 갖지 않는다. 동료 검토를 거친 논문, 공식 통계, 기업의 자체 홍보자료, 개인 블로그, 인터뷰 발언은 신뢰의 성격이 다르다. 개인 블로그가 항상 낮은 가치라는 뜻은 아니다. 새로운 현장 감각은 블로그나 인터뷰에서 먼저 나올 수 있다. 다만 그것을 사실처럼 쓸지, 사례처럼 쓸지, 의견처럼 쓸지는 구분해야 한다.

간단한 규칙은 이렇다.

• 숫자는 원문 출처를 반드시 남긴다.

• 예측은 예측이라고 표시한다.

• 개인 의견은 사실처럼 쓰지 않는다.

• 오래된 자료는 삭제하지 말고 오래됨으로 표시한다.

• 서로 충돌하는 자료는 하나를 지우지 말고 함께 연결한다.

리서치 위키에서 중요한 것은 완벽한 정리가 아니다. 나중에 믿고 다시 사용할 수 있는 상태를 만드는 것이다.

목차는 위키가 충분히 자란 뒤에 뽑는다

책이나 긴 글을 기획할 때 우리는 흔히 목차부터 만든다. 하지만 너무 이른 목차는 생각을 가둔다. 아직 자료가 부족한데 구조를 먼저 정하면, 이후 리서치는 그 구조를 채우는 작업으로 좁아진다. 반대로 위키를 먼저 만들면 예상하지 못한 연결이 보인다.

예를 들어 "AI 시대의 지식관리"라는 책을 쓰고 싶다고 하자. 처음부터 10장짜리 목차를 만들 수도 있다. 하지만 LLM Wiki 방식에서는 먼저 자료를 넣는다.

• AI 업무 자동화 관련 기사

• 개인 지식관리 도구 사례

• RAG와 에이전트 메모리 관련 자료

• 연구자의 노트 작성법

• 팀 문서화 실패 사례

• 스타트업 온보딩 문서 사례

• 독자 인터뷰 또는 고객 인터뷰

이 자료들이 위키에 들어가면 여러 페이지가 생긴다. 반복 질문의 비용, 대화 기록의 한계, 원문과 해석의 분리, 팀 위키의 검수 구조, AI가 문서를 업데이트할 때의 위험, 지식 축적의 복리 효과 같은 페이지다.

이제 AI에게 이렇게 요청할 수 있다.

현재 wiki/의 페이지를 바탕으로 "AI 시대의 지식관리"라는 책의 목차 후보를 3가지로 제안해줘.
1안은 입문자용, 2안은 실무자용, 3안은 팀 운영자용으로 구성해줘.
각 장마다 참고해야 할 기존 위키 페이지를 함께 표시해줘.

이 방식의 장점은 목차가 자료와 연결된다는 점이다. 그냥 그럴듯한 목차가 아니라, 실제로 쓸 수 있는 목차가 나온다. 각 장 아래에 이미 연결된 근거와 사례가 있기 때문이다.

블로그 글도 마찬가지다. "LLM Wiki가 RAG와 다른 점"이라는 글을 쓰고 싶다면, AI에게 곧바로 초안을 쓰게 하지 말고 먼저 관련 페이지를 찾게 한다.

• RAG의 장점

• 청크 검색의 한계

• 축적 기반 지식관리

• 원문 저장소와 위키 지식층

• 작은 팀에서 Markdown이 강한 이유

그다음 글의 독자를 정한다. 개발자에게 설명할 것인지, 기획자에게 설명할 것인지, 대표에게 설명할 것인지에 따라 구조가 달라진다. 위키는 재료를 제공하고, 사람은 방향을 정한다.

질문은 버리지 말고 페이지로 남긴다

리서치는 질문으로 움직인다. 좋은 질문 하나가 여러 자료를 부르고, 여러 자료가 다시 새로운 질문을 만든다. LLM Wiki의 강점은 이 흐름을 저장할 수 있다는 데 있다.

기본 루프는 다음과 같다.

1. 질문한다.

2. AI가 위키와 raw 자료를 바탕으로 답한다.

3. 답변에서 새로운 주장, 개념, 반례를 뽑는다.

4. 새 위키 페이지를 만들거나 기존 페이지를 업데이트한다.

5. 업데이트된 위키를 바탕으로 다시 질문한다.

예를 들어 처음 질문은 이렇게 시작할 수 있다.

개인 지식관리에서 AI가 실제로 도움이 되는 지점은 어디인가?

AI는 기존 위키를 바탕으로 "검색", "요약", "분류", "연결", "회고", "글쓰기 변환" 같은 답을 줄 수 있다. 여기서 끝내면 일반적인 대화다. 하지만 LLM Wiki에서는 답변을 다시 지식으로 바꾼다.

• AI 기반 개인 지식관리의 사용 사례.md 생성

• 검색과 축적의 차이.md 업데이트

• 반복되는 고민을 위키화하기.md에 연결

• AI가 개인 기록을 다룰 때의 위험.md 반례 페이지 생성

그다음 다시 묻는다.

위 페이지들을 바탕으로, 초보자가 가장 먼저 체감할 수 있는 사용 사례 5가지를 골라줘. 단, 과장된 자동화는 제외해줘.

이렇게 하면 질문이 사라지지 않는다. 질문은 위키를 성장시키는 입력이 된다. 답변은 일회용 문장이 아니라 다음 질문을 위한 발판이 된다.

글쓰기 산출물별로 추출 방식이 다르다

위키에서 글을 뽑아낼 때는 산출물의 형태를 먼저 정해야 한다. 같은 자료도 블로그, 뉴스레터, 책, 보고서에서 다른 구조로 쓰인다.

블로그 글은 하나의 명확한 문제를 다루는 데 좋다. 위키에서 주장 페이지 하나를 고르고, 근거 2~3개와 반례 1개를 붙이면 된다. 글의 구조는 단순할수록 좋다. "문제 → 흔한 오해 → 핵심 주장 → 근거 → 실천 방법" 정도면 충분하다.

뉴스레터는 관점이 중요하다. 독자는 모든 정보를 원하지 않는다. "이번 주에 무엇을 다르게 봐야 하는가"를 원한다. 따라서 위키의 최신 자료, 날짜가 중요한 변화, 서로 충돌하는 해석을 모아야 한다. 뉴스레터용 프롬프트는 이렇게 쓸 수 있다.

지난 30일 동안 추가된 AI 지식관리 관련 페이지를 검토해줘.
독자가 알아야 할 변화 3가지, 아직 불확실한 쟁점 2가지, 다음 주에 추적할 질문 3가지를 제안해줘.

책 원고는 더 긴 호흡이 필요하다. 책은 자료의 나열이 아니라 관점의 이동이다. 독자가 처음에는 무엇을 모르고, 중간에는 무엇을 이해하고, 마지막에는 무엇을 할 수 있게 될지를 설계해야 한다. 이때 위키는 장별 재료 창고가 된다. 각 장마다 연결된 개념, 사례, 주장, 반례, 실습 페이지를 붙이고, 부족한 부분은 research/questions.md에 남긴다.

보고서는 신뢰도와 출처가 중요하다. 위키에서 confidence: 높음인 근거를 우선 가져오고, 확인 필요 상태의 주장은 본문이 아니라 부록이나 리스크 항목으로 보낸다. 보고서에서 AI의 역할은 문장을 그럴듯하게 만드는 것이 아니라, 근거의 위치를 잃지 않게 하는 것이다.

리서치 위키 운영 프롬프트

리서치와 글쓰기에 LLM Wiki를 쓰려면 프롬프트도 작업 단위로 나누는 것이 좋다. 한 번에 "자료를 정리하고 글도 써줘"라고 하면 결과가 흐려진다. 대신 다음 순서로 요청한다.

1. 자료 분해 요청

raw/research/에 있는 새 자료를 읽고, 기존 wiki/와 연결해줘.
새로 만들 페이지와 업데이트할 페이지를 구분해줘.
관점, 주장, 근거, 반례 페이지를 우선 생성해줘.
원문 출처, 발행일, 신뢰도, 확인 필요 여부를 각 페이지에 남겨줘.

2. 연구 질문 생성 요청

현재 위키를 기준으로 아직 답하지 못한 질문 10개를 만들어줘.
질문을 중요도순으로 정렬하고, 각 질문에 필요한 추가 자료 유형을 제안해줘.

3. 목차 추출 요청

wiki/의 관련 페이지를 바탕으로 글 또는 책의 목차 후보를 제안해줘.
각 목차 항목 아래에 사용할 수 있는 위키 페이지와 부족한 근거를 표시해줘.

4. 초안 작성 요청

아래 목차에 따라 초안을 작성해줘.
이미 위키에 있는 주장과 근거만 사용해줘.
근거가 부족한 부분은 단정하지 말고 [추가 리서치 필요]로 표시해줘.

이 순서를 지키면 AI는 글쓰기 도구이기 전에 리서치 관리자처럼 일한다. 자료를 흡수하고, 구조를 만들고, 빈틈을 드러내고, 그다음 글을 쓴다.

작가는 사라지지 않는다

LLM Wiki를 쓰면 글쓰기의 많은 과정이 빨라진다. 하지만 작가의 역할이 사라지는 것은 아니다. 오히려 더 선명해진다.

AI는 자료를 빠르게 읽고 연결할 수 있다. 그러나 어떤 질문이 중요한지, 어떤 독자를 위해 쓸지, 어떤 주장을 끝까지 밀고 갈지, 어떤 표현을 버릴지는 사람이 정해야 한다. 위키가 아무리 커져도 방향이 없으면 글은 흩어진다.

리서치 위키의 목적은 AI가 대신 생각하게 만드는 것이 아니다. 사람이 더 좋은 판단을 할 수 있도록 기억과 근거를 정리하는 것이다. 빈 문서 앞에서 막히는 시간을 줄이고, 생각할 가치가 있는 문제에 더 오래 머물게 하는 것이다.

좋은 글은 갑자기 나오지 않는다. 좋은 질문, 좋은 자료, 좋은 분해, 좋은 연결이 쌓인 뒤에 나온다. LLM Wiki는 그 축적 과정을 보이게 만든다. 오늘 읽은 논문 하나, 저장한 기사 하나, 정리한 인터뷰 하나가 언젠가 한 문단이 되고, 한 장이 되고, 한 권의 책이 된다.