AI 위키 만드는 법——리서치를 반복할수록 판단이 흐려지는 메모장을 ‘AI가 읽는 운영체제’로 바꾼 7단계

AI 위키 만드는 법을 검색하는 사람의 대부분은 같은 벽에 부딪힌다. AI에게 조사를 시킬 때마다 성과가 리셋되고, 이전과 비슷한 검색을 반복하며, 판단 기준이 어디에도 남지 않는다.

요리에 비유하면, 매번 레시피를 검색하지만 지난번 잘됐던 불 조절 메모가 어디에도 없는 상태다. 조미료는 계속 늘어나는데 맛이 안정되지 않는다.

이 글에서는 그 메모장 수준의 AI 위키를 ‘AI가 반복해서 읽는 운영 기반’으로 바꾼 7단계 구조 변화를, 설계 판단의 이유와 함께 기록한다. 기술적 설계 판단도 다루지만, 각 단계의 첫머리에 “무엇이 곤란했고, 무엇을 바꿨는가”를 먼저 설명하므로 엔지니어가 아니어도 흐름을 따라갈 수 있다.

왜 AI 위키 만드는 법을 메모만 쌓아서는 풀 수 없는가

메모 앱에 리서치 결과를 쌓는 사람은 많다. 하지만 메모가 늘어날수록 “어디에 뭘 썼는지” 모르게 되고, 결국 또 검색한다——이런 경험 없는가.

AI 리서치를 시작했을 때의 문제는 3가지였다.

• 조사할수록 헷갈린다 — 정보는 늘지만, 지금 판단에 무엇이 관계되는지 모르겠다
• 매번 처음부터 다시 — 글을 쓸 때마다 비슷한 조사를 반복했다
• AI가 맥락을 잊는다 — 검색은 잘하지만 팀의 기준이나 과거 판단을 오래 유지하지 못한다

메모를 늘려도 이 3가지는 풀리지 않았다. 문제는 정보량이 아니라 판단을 떠받칠 구조가 없다는 것이었다.

1단계: 파일 더미에서 지식 그래프로

곤란했던 것: 메모가 폴더에 100개 있어도, 필요할 때 못 찾는다.
바꾼 것: 메모끼리 “이 얘기와 저 얘기는 관계가 있다”고 선으로 이었다.

첫 구조 변경은 파일을 폴더로 분류하는 걸 멈추고, 정보끼리의 관계를 설계하는 것이었다.

층	역할	예
raw	원문 그대로 보관	논문, 기사, 공식 발표
source	소스별 요약	요점 추출·팩트 정리
concept / entity	반복 등장하는 개념·인물	정의·배경·관련 짓기
synthesis	여러 근거를 묶은 해석	비교 분석·구조화된 견해

핵심은 ‘소스를 쌓는 것’이 아니라 ‘소스 간 관계를 AI가 따라갈 수 있는 형태로 남기는 것’이다. Markdown 위키링크로 개념끼리를 잇고, AI가 관련 정보를 줄줄이 참조할 수 있게 했다.

책장에 책을 늘어놓기만 해서는 사전이 되지 않는 것과 같다. 색인과 상호 참조가 없으면, 파일이 아무리 늘어도 ‘검색되는 메모장’이 되지 않는다.

실제 구조를 보면 이렇다.

최상위가 INPUT(raw) / KNOWLEDGE(sources, concepts, entities, synthesis, cases, insights) / OUTPUT(editorial, published) / OPS(meta, scripts) 4가지 역할로 나뉘어 있다. 폴더 이름이 아니라 역할 기반으로 설계하는 게 핵심이다.

2단계: 다음에 쓸 주제를 ‘감’이 아니라 ‘점수’로 고른다

곤란했던 것: 소재는 50개 있는데 “다음에 뭘 쓸까”로 매번 헤맨다.
바꾼 것: 소재에 점수를 매겨서 헤매는 시간을 0으로 만들었다.

AI 위키가 커지면 다음 병목은 우선순위였다. 어떤 정보를 글로 만들지, 어떤 걸 보류할지를 감으로 정하면 판단이 흔들린다.

그래서 스코어링 모델을 도입했다.

평가축	보는 것
blog fit	블로그 글로서의 적합도
evidence	근거의 두께
trend	검색 수요·시류와의 일치
importance	독자에게의 중요도
maintenance health	정보의 신선도

5축으로 수치화함으로써, “지금 뭘 써야 할까”의 논의가 속인적 판단에서 구조적 판단으로 바뀌었다.

점수가 높다고 자동으로 쓰는 건 아니다. 점수는 대화의 트리거다. “왜 이 주제 점수가 높은가”를 확인하고 나서 착수하는 룰로 만들었다.

3단계: ‘정보를 정리한 글’과 ‘시각을 바꾸는 글’의 설계를 분리한다

곤란했던 것: ‘재미있는 의견’만 있는 글과 ‘단순 정보 정리’만 있는 글로 양극화된다.
바꾼 것: 한 글 안에 ‘사실·징조·의견’ 3개의 박스를 만들고, 어느 하나라도 비면 공개하지 않는 룰로 정했다.

여기가 가장 시간을 들인 구조 변경이었다.

통찰을 강화하면 AI가 ‘그럴듯한 해석’을 양산하는 쪽으로 기운다. 정보성을 강화하면 어디서나 볼 수 있는 정리글로 돌아간다. 이 균형을 감으로 잡으려 하면 글마다 품질이 흔들린다.

그래서 감이 아닌 구조로 제어하기로 했다.

• fact — 검증 가능한 사실
• signal — 경향을 보이는 징조
• thesis — 우리들의 해석·주장

이 3가지를 글 안에서 의식적으로 분리해서 쓰게 했다. 여기에 글 전체의 방향성을 2개의 레인으로 분류했다.

레인	특징	예
속보형	사실의 빠르기가 가치	도구 발표, 공식 업데이트
심층형	해석의 깊이가 가치	설계 사상, 운용 사례, 비교 분석

거기에 글의 출구에도 체크를 넣었다. “통찰은 들어가 있는가, 그런데 정보가 비어 있지는 않은가”를 공개 전에 확인하는 구조다.

가장 아까운 실패 패턴은 “좋은 해석은 있는데, 읽고 나서 가져갈 정보가 없는 글”이었다. 독자가 시간을 들여서 읽었는데 얻은 게 모호한 견해뿐——이걸 구조적으로 막는 게 fact·signal·thesis 분리의 목적이다.

실제로 구조 덕에 막은 실패 패턴 2가지를 든다.

첫째는 ‘미래 예측만으로 끝나는 글’. AI에 최신 동향을 요약시키면 “앞으로는 이 방향으로 갈 것이다”라는 추상적 결론이 나열된다. 독자는 “그래서 지금 숫자는? 근거는?”이 알고 싶은데 그게 안 적혀 있다. fact 칸이 빈 채 thesis만 부풀어오른 상태다. 출구 체크에서 이걸 막는다.

둘째는 ‘사실 나열만 하는 글’. 반대로, 뉴스나 공식 발표를 그대로 늘어놓기만 하고 “그래서 뭐?”의 해석이 없는 글도 있다. 이건 thesis 칸이 빈 상태다. 정보량은 있는데 독자가 글을 닫은 후 “이 글을 읽고 뭐가 바뀌었지”를 떠올리지 못한다. 이것도 출구 체크에서 막는다.

이 둘만 막아도 글의 합격선이 명확해졌다.

4단계: AI가 쓴 ‘그럴듯한 글’에서 빠져나오기

곤란했던 것: 글은 잘 쓰는데 “이 사람이 직접 써본 적 있구나”로 독자에게 안 느껴진다.
바꾼 것: 우리가 시도한 기록(성공도 실패도)을 AI 위키에 쌓는 구조를 만들었다.

통찰형 구조를 넣고 나서, 또 다른 벽이 보였다. AI는 유창하게 쓰지만 “쓴 사람이 시도해봤다”처럼 읽히지는 않는다. 소스 요약과 synthesis만으로는 글이 똑똑해 보여도 독자가 신뢰할 만큼의 무게가 부족했다.

여기서 도입한 게 first-party evidence(직접 증거) 구조다.

• 우리가 시도한 작업 로그
• before / after 기록
• 실패한 선택지와 그 이유
• 대표적인 스크린샷

이 설계에서 가장 어려웠던 건 저장 장소 문제가 아니었다. 어디까지 공개 가능하고, 어디서부터 내부 정보인가를 동시에 설계해야 한다는 점이었다.

작업 로그에는 계정 정보, 내부 KPI, 비공개 도구 설정이 섞인다. 그대로 쌓으면 공개할 수 없고, 다 지우면 증거로서의 가치가 사라진다. 그래서 “그대로 공개” “가공해서 공개” “메타데이터만 남김”의 3단계로 나누어, 증거마다 공개 레벨을 설정하기로 했다.

공개 3단계의 판별은 이런 이미지다.

공개 레벨	예	공개 가능 범위
그대로 공개	공식 도구의 설정 화면, 외부 기사 캡처	전부
가공해서 공개	우리들의 작업 로그, before/after 비교	개인정보·KPI·절대 경로 마스킹
메타데이터만	내부 시제품, 비공개 스폰서 상담	“했다”는 사실과 “배운 점”만

이 룰 덕에 증거를 모을 때마다 “이거 공개 가능한가?”로 헤매는 일이 없어졌다. 처음부터 공개 레벨을 정해서 저장하니까, 나중에 글을 쓸 때 “이 소재 쓸 수 있나?”를 다시 생각할 필요가 없다.

품은 들지만, 이 구조 덕에 글의 인용원이 외부 소스뿐 아니라 우리들의 운용 기록이 됐다. “어떤 AI라도 쓸 수 있는 글”과 “이 사람들이 시도해봤기에 쓸 수 있는 글”의 차이는 여기서 생긴다.

5단계: 도표를 ‘장식’이 아닌 ‘증거’로 다룬다

곤란했던 것: 도표를 잔뜩 붙였는데, 뭘 증명하려는 도표인지가 독자에게 안 전해진다.
바꾼 것: 1개의 도표에 1개의 주장을 묶고, “이 도표가 무엇을 말하는가”를 반드시 명기하는 룰로 정했다.

텍스트만으로는 설명이 부족한 영역이 나왔다. 인프라 비교, 시장 동향, 구조도. 하지만 도표는 금방 낡고, 스크린샷은 맥락 없이 붙이면 오해를 만든다.

그래서 도표 관리 룰을 만들었다.

• 1도표 = 1주장 — 도표가 뭘 증명하는지 명시한다
• 역할 분류 — proof(증거) / context(맥락 설명) / workflow(절차 도시)
• 현재값 차트와 구조도 분리 — 낡는 데이터와 안 낡는 개념도를 구분

“도표를 많이 넣는 것”이 품질이 아니다. 도표가 어떤 주장을 떠받치는지가 명시되어 있는 것이 품질이다.

6단계: 최신 데이터는 ‘저장’이 아니라 ‘재취득 절차’로 관리

곤란했던 것: 지난달 저장한 ‘최신 랭킹’이, 이번 달엔 이미 낡았다.
바꾼 것: 숫자 자체를 저장하는 걸 멈추고, “그 숫자를 어디서 다시 가져올 수 있는지”를 저장하기로 했다.

여기는 예상 이상으로 까다로웠다.

AI 위키의 강점은 지식을 축적할 수 있는 것이지만, 차트나 수치 데이터에 관해서는 그 강점이 그대로 약점이 된다. 지난달 정확했던 랭킹표가 이번 달에는 낡은 정보원으로 변해 있다. AI 위키에 숫자를 장기 저장하면 오히려 잘못된 정보를 스스로 양산하는 구조가 된다.

여기서 철학을 바꿨다. 차트를 저장하는 걸 그만두고, 차트를 재취득하는 절차를 저장하기로 했다.

저장하는 것	저장하지 않는 것
데이터의 취득원(공식 URL 등)	데이터의 값 그 자체
업데이트 빈도 기준	“최신 숫자”
재취득 절차	낡는 랭킹표

거기에 도표를 2종류로 나눴다.

• 현재값 차트(랭킹, 가격, 벤치마크) → 저장 안 하고 재취득
• 구조·메커니즘 도표(아키텍처도, 개념도) → 저장해도 됨(안 낡음)

이 구분이 들어오고 나서, “이 도표 아직 정확한가?”라는 확인이 훨씬 쉬워졌다. 현재값 차트는 재취득 절차를 실행하기만 하면 된다. 구조도는 구조 자체가 안 바뀌는 한 유효하다.

최신성은 축적의 대상이 아니라 검증 절차의 대상이다.

“이 도표는 저장해도 되는가? 재취득해야 하는가?”를 판별하려고, 우리는 이 2가지 질문을 쓴다.

1. 6개월 후에 이 도표를 봐도 아직 정확하다고 말할 수 있는가? — 말할 수 있으면 저장해도 된다. 못 하면 재취득 절차 쪽으로 분류한다.
2. 이 도표는 수치 자체인가, 아니면 구조인가? — 수치면 stale, 구조면 permanent.

단순하지만, 이 2가지 질문만으로 도표 관리 비용이 크게 줄었다. “왠지 낡은 것 같다”는 모호한 감각으로 도표를 갈아붙이는 작업이 없어지고, 재취득해야 할 도표만 정기적으로 업데이트하는 운용으로 바뀌었다.

7단계: 한 카테고리 정비에서 전 AI 위키 운영 기반으로

곤란했던 것: AI 관련은 정비됐는데 디자인이나 콘텐츠 전략은 원래 메모장 그대로.
바꾼 것: 잘 됐던 구조를 다른 주제에도 복제했다.

처음에는 1개 주제(AI 툴링)만 정비되어 있었다. 하지만 운용을 계속하면서 디자인, 콘텐츠 전략, 블로그 운영에도 같은 수준의 구조가 필요해졌다.

도메인별 evidence pack을 만들었다.

• AI 툴링 — 도구 비교·벤치마크·운용 사례
• 디자인/사양 — DESIGN.md·Anti-AI UI·스펙 리뷰
• 콘텐츠 성장 — 독자 분석·글 퍼포먼스·채널 최적화

좋은 AI 위키는 1개 주제만 정비된 곳이 아니라, 판단 패턴이 여러 분야에 복제되는 곳이다.

실제 synthesis 페이지의 일례를 보여준다.

프론트매터(type, confidence, tags, related)로 메타 정보를 가지고, 본문 안의 [[wikilink]]로 다른 페이지에 이어진다. AI 에이전트는 이 구조를 따라가면서 매번 관련 판단 기준을 읽어들인다. 이게 ‘AI가 읽는 운영체제’의 실체다.

이 7단계를 거치고 실제로 무엇이 바뀌었는가

여기까지 구조 얘기를 해왔지만, 운용 결과로도 변화가 있었다.

before(메모장 시대):

• 블로그 글 1편을 위해 매번 처음부터 정보 수집했다
• “다음에 뭘 쓸까”로 매주 헤맸다
• AI에 조사를 시켜도 3일 후에는 맥락을 다 잊었다
• 도표는 붙인 채로 반년 후에 보면 낡아 있었다
• 내부 시행착오는 기억 속에만 있었다

after(운용 기반화 후):

• 1편의 글에 필요한 정보의 70%가 이미 AI 위키 안에 있다
• 다음에 쓸 주제는 점수로 자동 정렬된다
• AI는 매번 위키를 다시 읽어서 과거 판단 기준을 이어받는다
• 도표는 “저장해도 되는 것”과 “재취득해야 하는 것”으로 나뉘어 있다
• 시행착오는 기록되어 다음 판단에 재사용된다

숫자로 말하자면, 글 1편을 쓰는 데 필요했던 조사 시간이 대략 절반 이하로 줄었다. 하지만 진짜 바뀐 건 시간이 아니다. “같은 판단 실수를 반복하지 않게 됐다”는 점이다.

AI 위키가 운영 기반이 된다는 건, 단순히 정보가 정리된다는 게 아니다. 과거의 자기 판단을, 미래의 자기와 AI가 이어받을 수 있는 상태를 만드는 것이다.

다음에 예상하는 병목

그래도 아직 완성된 게 아니다. 지금 보이는 다음 병목은 3가지다.

1. 크로스 도메인 참조 — AI 툴링 위키와 디자인 위키를 횡단하는 글을 쓸 때, 양쪽 맥락을 동시에 유지하기 어렵다
2. 오래된 synthesis의 재평가 — 반년 전에 쓴 해석이 지금도 정확한지, 자동으로 플래그가 서는 구조가 없다
3. 독자 피드백 반영 — 공개 후 반응을 위키에 되돌리는 경로가 아직 가늘다

이게 보이기 시작했으니, 또 다음 구조 변경이 시작된다. AI 위키는 다 만들어지는 것이 아니라, 병목이 보일 때마다 키우는 것이다.

지금 AI 위키가 채택한 7가지 원칙

7단계 구조 진화를 거쳐, 지금의 설계 원칙은 다음과 같다.

1. AI 위키는 메모장이 아니라 AI가 읽는 운영체제다
2. 소스 축적보다 판단 규칙 축적이 더 중요한 장면이 있다
3. 좋은 글은 정보량이 아니라 판단 구조와 해석 프레임에서 차이가 난다
4. 통찰과 팩트는 분리한다
5. 실제 사례와 작업 증거가 없으면 신뢰는 얕다
6. 도표는 장식이 아니라 evidence다
7. 최신성은 저장이 아니라 라이브 검증으로 관리한다

오늘 할 일

AI 위키 만드는 법을 시작하기 위해 할 일은 단 3가지다.

1. 자기 리서치용 메모를 1개 고른다
2. 그 메모가 ‘소스’ ‘개념’ ‘해석’ 중 어느 것에 해당하는지 분류한다
3. 분류했으면 Markdown 파일에 type: 프론트매터를 붙여 저장한다

15분이면 시작할 수 있다. 구조는 나중에 키우면 된다.

관련 기사: 하네스 엔지니어링 완전 가이드 / OpenAI Codex 팀 도입

AI 위키 만드는 법 자주 묻는 질문

Q. Notion이나 Obsidian으로도 같은 AI 위키 구조를 만들 수 있나요?

A. 만들 수 있습니다. 중요한 건 도구가 아니라 정보를 ‘소스 → 개념 → 해석’의 층으로 나눠 잇는 설계 사상입니다. 도구는 취향대로 고르세요.

Q. AI 위키는 몇 페이지부터 효과가 나오나요?

A. 10~15페이지부터 연결 구조의 혜택이 보이기 시작합니다. 50페이지를 넘으면 스코어링이 필요해집니다. 처음부터 다 갖출 필요는 없습니다.

Q. AI 에이전트(Codex, Claude Code 등)와 어떻게 같이 쓰나요?

A. 한쪽이 리서치해서 지식을 늘리고, 다른 쪽이 그걸 참조해서 글이나 분석을 만드는 역할 분담이 효과적입니다. AI 위키가 두 에이전트의 공유 메모리가 됩니다.

Q. 개인용인가요, 팀용인가요?

A. 개인으로 시작해서 구조가 만들어지면 팀으로 전개하는 게 자연스럽습니다. 1인 운용이라도 ‘미래의 자기’와 ‘AI 에이전트’가 독자가 되므로 구조의 가치는 변하지 않습니다.

Q. 최신 정보를 저장하지 않으면 AI 위키는 뭘 위한 건가요?

A. 최신 숫자가 아니라 ‘뭘 어디서 다시 확인할지’를 저장합니다. AI 위키의 가치는 축적량이 아니라 판단과 검증 절차가 남아 있다는 점에 있습니다.

회원 가입(무료)으로 매주 월요일 뉴스레터 받기 →

이 글을 쓴 사람: VibeCoding Tailor(@shuntailor). AI 위키·DESIGN.md·AGENTS.md·검증 루프를 자사 블로그 운영과 프로덕트 개발에 도입해 AI 에이전트 운용의 품질 관리를 일상적으로 실천하고 있다.

소스 리스트:

• LLM Wiki 개발 철학 타임라인(2026-04-10) — 내부 설계 기록
• First-Party Evidence Capture System — 실증 데이터 축적의 설계 사상
• Chart Freshness Governance — 도표 신선도 관리 정책
• Live Chart Retrieval Protocol — 실시간 데이터 재취득 절차
• Wiki Scoring Model — 페이지 평가 스코어링 설계
• Andrej Karpathy — LLM Wiki: 지식 컴파일 패턴

최종 업데이트: 2026년 4월 10일