흩어진 회사 지식을 위키로 컴파일하고, Claude·ChatGPT에 붙여 "우리 회사를 아는 AI"로 일하기 — 클릭과 복붙으로
왜 똑똑한 AI도 우리 회사 일은 못 도와줄까요? 그 답이 '위키'에 있습니다.
ChatGPT는 세상 모든 걸 알지만, 정작 우리 팀 반품 규정은 모릅니다. 여러분도 매번 자료를 다시 붙여 넣어 설명해본 적 있으시죠? 이걸 한 방에 해결하는 방법을 2026년 4월, AI 석학 안드레 카파시(Andrej Karpathy)가 제안했습니다. 바로 LLM Wiki입니다.
위키는 한 번 정리한 지식이 그대로 남아 복리로 쌓입니다. 게다가 AI는 권태도 없고 잊지도 않아서, 15개 문서를 동시에 정리해도 지치지 않습니다 — 유지비가 0에 가깝죠. 그래서 위키가 살아남습니다. 놀랍게도 벡터DB도, 임베딩도 필요 없습니다. 마크다운 파일과 목차 하나면 문서 100개까지 충분합니다.
카파시가 4월에 올린 짧은 글은 두 달 만에 구글 클라우드의 정식 업계 표준(OKF, Open Knowledge Format)이 됐습니다. 특정 회사 제품에 갇히지 않고, 모델이 바뀌어도 살아남는 — 검증된 방식입니다.
LLM Wiki는 문서 수백 개 규모에 최적입니다. 수만 개 문서를 다루는 대기업 전사 검색이라면 벡터DB·임베딩을 곁들여야 합니다. 또 위키는 사람이 한 번씩 검토해야 정확합니다 — AI에게 다 맡기고 방치하면 틀린 내용도 쌓입니다. 이 책은 "한 팀이 매주 굴리는 위키"에 딱 맞는 방법을 다룹니다.
방법은 단순합니다. 원본을 모으고(Raw), AI가 위키로 컴파일하고(Compile), 그게 위키가 되고(Wiki), 자연어로 물어봅니다(Q&A). 이 책 전체가 이 흐름을 따라갑니다. 그리고 폴더는 딱 3칸으로 나눕니다.
그리고 위키를 굴리는 동작도 3가지뿐입니다. 이 책은 이 셋을 모두 실습합니다.
| 동작 | 하는 일 | 이 책 |
|---|---|---|
| Ingest (넣기) | 원본 1개를 넣으면 → AI가 위키 페이지 10~15장을 갱신. 한 번에 하나씩. | 4장 |
| Query (묻기) | 위키로 자연어 질문에 답. 좋은 답은 다시 위키로 저장 — 탐색 자체가 자산. | 6·7장 |
| Lint (점검) | 모순·고아 문서·깨진 링크·오래된 주장을 AI가 건강검진. | 9장 |
5명짜리 마케팅팀 '한빛'을 예로, 여러분도 똑같이 따라 만들어 봅시다. 먼저 '원본 서랍'부터.
🎯 이 장이 끝나면: raw · wiki · schema 3칸으로 나뉜 금고가 생긴다.
브라우저에서 obsidian.md → Download → 내 OS용 파일 실행. 무료입니다.
첫 화면 → Create new vault → 이름 회사위키 → 위치는 '문서' 폴더 → Create.
왼쪽 빈 곳 우클릭 → New folder → raw. 같은 방법으로 wiki, schema도. 이 셋이 카파시 위키의 전부입니다.
🎯 이 장이 끝나면: 회사 자료 원본 몇 개가 raw에 들어간다.
raw는 원본을 그대로 던져두는 서랍입니다. 정리하지 않습니다. 여러분이 가진 회의록, 메일, 매뉴얼, 카톡 캡처 글… 있는 그대로 텍스트로 넣어두세요. 정리는 4장에서 AI가 합니다.
raw의 원본은 고치지 않습니다. AI도 여기는 '읽기만' 합니다. 원본을 지키고, 가공본은 wiki에 따로 쌓는 것 — 이게 카파시 위키가 안 무너지는 비결입니다.
무엇부터 넣을까요? 기준은 하나, "또 물어보는 것"입니다. 한빛팀이라면:
raw 폴더 우클릭 → New note → 이름은 날짜+제목 → 원본 텍스트를 그대로 붙여넣기. 다듬지 마세요.
제일 자주 묻는 주제 3~5개 분량이면 충분합니다. 위키는 한 번에 짓는 게 아니라 매주 쌓는 겁니다.
raw에 들어간 원본이 부실하면 위키도 부실해집니다. 완벽할 필요는 없지만, 핵심 사실(숫자·날짜·이름)은 정확한 원본을 넣으세요.
이제 AI에게 raw를 '컴파일'시켜 진짜 위키를 만들 차례입니다. 카파시 방법의 심장이니, 함께 가보시죠.
🎯 이 장이 끝나면: AI가 위키를 어떻게 쓸지 규칙(CLAUDE.md)이 생긴다.
AI에게 무작정 "정리해줘" 하면 제멋대로 씁니다. 그래서 먼저 규칙서를 줍니다. schema 폴더에 CLAUDE.md 라는 노트를 만들고 아래를 복붙하세요. (회사 사정에 맞게 폴더·항목만 바꾸면 됩니다.)
이 규칙 한 장이 위키 전체의 일관성을 잡습니다. AI는 매번 이 파일을 읽고 같은 방식으로 정리하니까요.
🎯 이 장이 끝나면: raw 원본 1개가 깔끔한 위키 페이지로 바뀐다.
드디어 핵심입니다. Ingest(넣기)는 원본 하나를 AI에게 주고 위키 페이지로 컴파일시키는 동작이에요. 여기서 카파시의 철칙 하나만 기억하세요 — "한 번에 하나씩, 사람이 검토"입니다.
Claude Desktop(또는 Claude Code)에 회사위키 폴더를 열어두고, 이렇게 시킵니다.
raw 파일 하나만 시킵니다. 여러 개를 한꺼번에 던지면 AI가 뭉뚱그려요.
AI가 만든 wiki 페이지를 열어 숫자·날짜·이름이 원본과 맞는지 확인. 틀리면 "이건 7일이야"처럼 고쳐주면 다시 씁니다.
하나가 깔끔해지면 다음 raw로. 같은 요청을 2~3번 반복하면 AI가 패턴을 익혀 점점 좋아집니다.
지저분한 원본(raw)이 → 규칙(schema)에 맞춰 → 깔끔한 위키(wiki)로 컴파일됐습니다. 사람이 한 게 아니라 AI가요.
AI 컴파일은 빠르지만 완벽하진 않습니다. 날짜를 옮겨 적거나, 없는 내용을 그럴싸하게 채우기도 합니다(환각). 그래서 카파시도 "한 번에 하나, 사람이 검토"를 못박았습니다. 자동화에 다 맡기지 말고, 처음 몇 번은 결과를 꼭 눈으로 확인하세요.
🎯 이 장이 끝나면: 위키 페이지가 어떻게 생겼고, 어떻게 '지도'가 되는지 안다.
AI가 만든 위키 페이지는 이렇게 생겼습니다. 위(노란 칸)는 AI가 읽는 꼬리표, 아래는 사람이 읽는 본문이에요.
페이지마다 [[링크]]로 서로 연결돼 있으면, 옵시디언 왼쪽의 그래프 뷰가 이걸 '지식 지도'로 그려줍니다.
위키가 생겼으니, 이제 AI가 직접 읽고 답하게 연결해 봅시다.
🎯 이 장이 끝나면: Claude가 회사위키를 직접 읽고 답한다.
위키를 AI에 상시 연결하는 표준 통로가 MCP입니다. 이름은 어렵지만 하는 일은 "AI야, 이 폴더를 읽어도 돼" 허락해주는 것뿐. 설정 파일에 몇 줄 복붙하면 됩니다.
nodejs.org → LTS 다운로드 → 설치(다음·다음).
Claude Desktop → 설정 → Developer → Edit Config.
맥: ~/Library/Application Support/Claude/claude_desktop_config.json
윈도우: %APPDATA%\Claude\claude_desktop_config.json
설정은 켤 때 한 번만 읽습니다 (맥은 ⌘Q).
입력창의 🔌 아이콘에 회사위키 가 보이면 성공.
팀 전체가 같은 위키를 쓰려면 회사가 서버에 올려 '커넥터 주소'로 나눠줘야 합니다 — 관리자 몫(다음 권 '공개화'). 직원은 그 주소만 등록하면 끝.
🎯 이 장이 끝나면: 회사 일을 AI에게 물어 처리한다.
이제 여러분은 그냥 물어보면 됩니다. AI가 위키를 읽고 출처까지 대며 답해줄 거예요.
좋은 답이 나왔다면, AI에게 "방금 답을 wiki/ 에 정리해서 저장해줘" 라고 하세요. 한 번 한 고민이 위키에 남아, 다음엔 바로 꺼내집니다. 이게 지식이 복리로 쌓이는 순간입니다.
🎯 이 장이 끝나면: 위키가 'AI용 정문'뿐 아니라 '사람용 정문'도 된다는 걸 안다.
같은 위키 하나에서 문이 두 개 납니다. AI가 들어오는 문(MCP, 6장)과, 사람이 들어오는 문(대시보드)입니다. 대부분의 직원은 코드가 아니라 대시보드를 봅니다 — 검색하고, 클릭하고, 관계를 눈으로 따라가죠.
아래는 실제로 운영 중인 지식그래프 대시보드입니다. 점 하나가 개념, 선이 관계예요. 검색하거나 점을 클릭하면 이웃 개념이 펼쳐집니다.
직원 대부분은 설정 파일을 만지지 않습니다. 회사가 깔아준 대시보드 주소에 들어가 검색만 하면, 흩어진 회사 지식이 한 장의 지도로 보입니다. 이게 위키를 '나만의 금고'에서 '회사의 자산'으로 바꾸는 지점입니다.
위 대시보드처럼 지식그래프를 뽑아 서버에 올리고 권한을 나누는 건, 1~7장의 "내 PC 옵시디언"보다 한 단계 위의 작업입니다. 일반 직원은 회사가 준 주소를 보기만 하면 됩니다. 깔아 제공하는 쪽(관리자·대표)의 구축 방법은 다음 권에서 다룹니다 — 이 장은 "이런 정문이 있다"까지입니다.
여러분이 만든 위키가 썩지 않도록 관리하는 마지막 동작, Lint입니다.
🎯 이 장이 끝나면: 위키의 모순·고아·깨진 링크를 AI가 잡아준다.
위키가 커지면 서로 안 맞는 내용, 아무도 안 링크한 외톨이 페이지, 깨진 링크가 생깁니다. Lint(점검)는 이걸 AI에게 건강검진시키는 동작이에요.
일주일에 한 번 Ingest(새 자료 추가), 한 달에 한 번 Lint(건강검진). 이 리듬만 지키면 위키는 계속 살아서 복리로 자랍니다.
AI가 "이게 모순 같다"고 알려주지만, 최종 판단은 사람이 합니다. 7일이 맞는지 14일이 맞는지는 회사가 압니다. Lint는 의심 후보를 모아주는 건강검진이지, 알아서 고치는 자동 수술이 아닙니다.