LLM 위키는 자료 보관함이 아니라, 나중의 나를 가르치는 작업대다

 

 

 

 

AI 도구를 쓰다 보면 좋은 답을 많이 받는다. 그런데 며칠 지나면 어디서 무슨 얘기를 했는지 흐려진다. 링크는 채팅방 어딘가에 있고, 사업 아이디어는 메모장에 있고, 실험 결과는 사진첩이나 머릿속에 남는다. 다시 쓰려고 하면 매번 처음부터 설명해야 한다.

 

LLM 위키는 이 문제를 해결하는 방식이다. 핵심은 단순하다. 자료를 그냥 쌓아두는 것이 아니라, LLM이 읽고 정리해서 계속 업데이트되는 마크다운 위키로 바꾸는 것이다. 그래서 다음 질문을 할 때 원문을 다시 뒤지는 대신, 이미 정리된 페이지와 연결된 기록을 바탕으로 더 빠르게 판단한다.

 

이 글은 LLM 위키를 처음 쓰는 사람에게 설명하듯 정리한 안내서다. 특히 제품 실험, 블로그 주제 관리, 촬영 현장 노하우, 지원사업 준비처럼 시간이 지나며 지식이 쌓이는 일을 하는 사람에게 맞춰 썼다.

1. 일반 메모와 LLM 위키는 무엇이 다른가

 

일반 메모는 대개 저장으로 끝난다. 오늘 떠오른 문구를 적고, 공고 링크를 저장하고, 실험 결과를 숫자로 남긴다. 문제는 나중에 그 메모들을 다시 연결하는 비용이 크다는 점이다. “이 공고가 어느 아이디어랑 맞았지?”, “그때 QR 문구 중 어떤 게 반응이 있었지?”, “촬영 현장에서 반복된 불편이 뭐였지?” 같은 질문을 하면 사람이 다시 읽고 묶어야 한다.

 

LLM 위키는 저장 다음에 한 단계를 더 둔다. 원본 자료는 그대로 보관하되, 그 자료에서 의미 있는 개체, 개념, 비교, 질문 답변을 별도 페이지로 만든다. 예를 들어 복권집 앞에서 QR 피켓을 테스트했다면 단순히 “QR 3명 스캔”이라고만 남기지 않는다. 항아리 앱 오프라인 실험 페이지에 붙이고, 피켓 문구 비교 페이지와 연결하고, 다음 테스트에서 바꿀 점까지 기록한다.

 

즉 LLM 위키의 목적은 “기억”보다 “재사용”에 가깝다. 저장한 자료가 나중에 홍보물, 제품 기능, 사업계획서, 체크리스트, 블로그 글로 다시 나와야 한다.

 

2. 구조는 세 층이면 충분하다

 

LLM 위키는 복잡한 데이터베이스가 아니어도 된다. 폴더와 마크다운 파일만 있어도 충분하다. 추천 구조는 세 층이다.

 

첫째, raw 폴더다. 여기는 원본 자료를 넣는 곳이다. 기사, 공고문, PDF, 실험 메모, 촬영 노트, 스크린샷 설명 같은 것들이 들어간다. 원본은 되도록 고치지 않는다. 나중에 해석이 틀렸을 때 돌아갈 기준점이 필요하기 때문이다.

 

둘째, wiki 페이지다. 여기에는 LLM이 정리한 개체와 개념이 들어간다. 제품명, 기관명, 장소, 반복되는 문제, 실험 패턴, 비교표 같은 것들이다. 원본이 재료라면 이 페이지들은 요리된 결과물이다.

 

셋째, schema다. schema는 위키 운영 규칙이다. 어떤 태그를 쓸지, 어떤 기준으로 새 페이지를 만들지, 실험 결과를 어떻게 기록할지, 사실과 추정을 어떻게 구분할지 정한다. 이 규칙이 있어야 LLM이 매번 다른 방식으로 정리하지 않는다.

 

예를 들면 이런 식이다.

 

```text

wiki/

├── raw/

│ ├── grants/

│ ├── experiments/

│ ├── product/

│ └── field-notes/

├── entities/

├── concepts/

├── comparisons/

├── queries/

├── index.md

├── log.md

└── SCHEMA.md

```

 

처음부터 완벽하게 나눌 필요는 없다. 중요한 것은 원본, 정리 페이지, 운영 규칙을 분리하는 것이다.

 

3. 저장할 때는 “나중에 어떤 질문으로 꺼낼지”를 같이 생각한다

 

좋은 위키 기록은 미래의 질문을 예상한다. 그냥 “오늘 실험함”이라고 쓰면 나중에 쓸 수 있는 정보가 적다. 반대로 장소, 문구, 노출, 반응, 문제, 다음 테스트를 같이 쓰면 한 달 뒤에도 자료로 살아남는다.

 

예를 들어 항아리 앱 오프라인 실험이라면 이렇게 남긴다.

 

```text

장소: 복권집 앞

시간: 토요일 오후 2시부터 3시

홍보물: “복권 샀어요? 땄다 치고 담아두세요” 피켓

노출 추정: 80명

QR 스캔: 7명

첫 기록 완료: 2명

관찰: 사람들이 문구는 읽었지만 QR은 멀리서 잘 안 보였다

문제: 설명이 길면 지나간다

다음 테스트: QR을 더 키우고 문구를 두 줄로 줄인다

```

 

이렇게 남기면 나중에 질문이 가능해진다.

 

• 어떤 문구가 제일 반응이 있었나?
• QR 크기와 위치 문제는 반복됐나?
• Toss 제출용 고객검증 문장으로 바꾸면 어떻게 되나?
• 다음 피켓은 무엇을 줄이고 무엇을 키워야 하나?

 

기록의 품질은 나중 질문의 품질을 결정한다.

 

4. index.md와 log.md는 작지만 중요하다

 

위키가 커지면 파일이 많아진다. 이때 index.md와 log.md가 길잡이가 된다.

 

index.md는 목차다. 어떤 페이지가 있는지 한 줄 설명과 함께 모아둔다. LLM이 질문에 답할 때 먼저 index를 읽으면 관련 페이지를 빨리 찾을 수 있다. 사람도 Obsidian이나 VS Code에서 index를 보면 현재 지식 지도를 파악하기 쉽다.

 

log.md는 시간순 기록이다. 언제 어떤 자료를 넣었고, 어떤 페이지를 수정했고, 어떤 질문 답변을 보관했는지 남긴다. 이 로그가 있으면 “최근에 무슨 작업을 했지?”를 바로 확인할 수 있다. 특히 여러 프로젝트를 동시에 할 때 유용하다.

 

쉽게 말해 index는 지도이고, log는 일지다. 둘 중 하나만 있어도 부족하다. 지도는 현재 구조를 보여주고, 일지는 변화 과정을 보여준다.

 

5. 질문 답변도 가치가 있으면 다시 저장한다

 

LLM 위키의 좋은 점은 질문도 자료가 된다는 것이다. 예를 들어 “항아리 복권집 피켓 문구를 세 가지로 비교해줘”라고 물어서 좋은 비교표가 나왔다면, 그 답변은 채팅에만 두기 아깝다. comparisons 폴더에 저장해두면 다음 홍보물 제작 때 바로 꺼내 쓸 수 있다.

 

저장할 가치가 있는 질문은 보통 이런 형태다.

 

• 여러 후보를 비교한 답변
• 사업계획서에 재사용할 수 있는 문제정의
• 실험 결과를 종합한 분석
• 체크리스트나 운영 루틴
• 제품 기능 우선순위
• 나중에 반복해서 참고할 설명글

 

반대로 단순한 일회성 질문은 굳이 저장하지 않아도 된다. 위키는 모든 대화를 박제하는 곳이 아니다. 다시 볼 가치가 있는 판단과 정리를 모으는 곳이다.

 

6. 실제 활용 예시: 제품 실험

 

제품을 만들 때 가장 빨리 사라지는 것은 작은 관찰이다. 사용자가 어디서 멈췄는지, 어떤 문구에 웃었는지, 어떤 버튼을 못 찾았는지 같은 것들이다. 이런 관찰은 숫자보다 작아 보이지만 다음 개선의 실마리가 된다.

 

LLM 위키에 제품 실험을 쌓으면 다음과 같은 흐름이 가능하다.

 

1. 오늘 실험 결과를 raw에 저장한다.

2. 관련 실험 페이지에 관찰을 추가한다.

3. 카피 비교 페이지나 UX 문제 페이지에 연결한다.

4. 다음 테스트 가설을 적는다.

5. 나중에 누적 실험을 보고 홍보물이나 제품 화면을 개선한다.

 

예를 들어 “QR을 봤지만 찍지 않았다”는 관찰이 세 번 반복되면, 그것은 단순 우연이 아니라 실험 패턴이다. 위키는 이런 반복을 발견하게 해준다.

 

7. 실제 활용 예시: 사업계획서와 지원사업

 

지원사업을 준비할 때도 위키가 유용하다. 공고문, 제출서류, 자격요건, 예산 항목, 이전에 쓴 문구가 계속 흩어진다. 한 번 정리해두면 다음 공고를 볼 때 훨씬 빠르다.

 

예를 들어 FlowStore 같은 공간/동선/소상공인 운영 개선 아이디어가 있다면, 위키에는 이런 페이지가 쌓일 수 있다.

 

• 소상공인 피로 저감 문제정의
• 식당 동선 개선 사례
• 공간 사진 리포트 MVP
• 지원사업별 적합도 비교
• 예산 항목에서 안전한 표현
• 이미 작성한 회사 소개 문구

 

이렇게 쌓아두면 새 공고가 나왔을 때 “이 공고가 FlowStore에 맞는지 비교해줘”라고 물을 수 있다. 매번 처음부터 사업을 설명하지 않아도 된다.

 

8. 실제 활용 예시: 촬영 현장 노하우

 

촬영 일은 현장에서 배운 것이 많다. 장비 세팅, 동선 파악, 인터뷰 위치, 조명 문제, 편집 납품 루틴은 경험이 쌓일수록 좋아진다. 그런데 바쁜 일정이 반복되면 그 경험이 기록되지 않고 사라진다.

 

위키에 촬영 노하우를 저장하면 두 가지로 재활용된다.

 

첫째, 실제 체크리스트가 된다. 행사 촬영 전날 준비물, A7S III 세팅, 인터뷰 오디오 확인, 납품 전 점검 같은 형태로 꺼낼 수 있다.

 

둘째, 제품 기획 자료가 된다. PrePro Studio 같은 도구를 만든다면, “왜 이 기능이 필요한지”를 현장 사례로 설명할 수 있다. 단순히 기능을 상상하는 것이 아니라 실제 놓칠 뻔한 장면, 반복되는 준비 문제, 마무리 납품의 귀찮음을 근거로 삼는 것이다.

 

9. 처음 시작할 때의 최소 루틴

 

처음부터 완벽한 운영을 목표로 하면 오래 못 간다. 최소 루틴은 세 문장으로 충분하다.

 

첫째, 저장할 때 이렇게 말한다.

 

```text

이거 위키에 저장해.

```

 

둘째, 분야를 붙인다.

 

```text

항아리 실험으로 저장해.

PrePro 현장 노트로 저장해.

지원사업 근거로 저장해.

촬영 노하우로 저장해.

```

 

셋째, 꺼낼 때는 이렇게 묻는다.

 

```text

위키 기준으로 다시 정리해줘.

저장된 것 중 쓸만한 것만 뽑아줘.

이걸 블로그 글/사업계획서/홍보물로 바꿔줘.

```

 

이 정도만 반복해도 위키는 쌓인다. 처음에는 빈 폴더처럼 보이지만, 몇 주 지나면 꽤 강한 개인 데이터베이스가 된다.

 

10. LLM 위키를 잘 쓰기 위한 원칙

 

첫 번째 원칙은 원본과 해석을 섞지 않는 것이다. 원본 자료는 raw에 두고, 해석은 별도 페이지에 쓴다. 그래야 나중에 틀린 해석을 고칠 수 있다.

 

두 번째 원칙은 사실과 추정을 구분하는 것이다. “QR 스캔 7명”은 사실이고, “문구가 귀여워서 찍은 것 같다”는 추정이다. 둘을 섞으면 나중에 잘못된 판단이 쌓인다.

 

세 번째 원칙은 너무 많은 페이지를 만들지 않는 것이다. 지나가는 언급까지 전부 페이지로 만들면 위키가 금방 지저분해진다. 반복되거나 중심이 되는 개념만 페이지로 만든다.

 

네 번째 원칙은 질문 결과도 저장하는 것이다. 좋은 비교, 좋은 설명, 좋은 체크리스트는 채팅에 흘려보내지 말고 queries나 comparisons에 넣는다.

 

다섯 번째 원칙은 가끔 점검하는 것이다. 깨진 링크, 중복 페이지, 오래된 정보, 근거 없는 확정 표현을 정리해야 위키가 오래 간다.

 

11. 결론: 위키는 기억이 아니라 반복 학습 장치다

 

LLM 위키의 장점은 단순히 자료를 많이 보관하는 데 있지 않다. 중요한 것은 반복 학습이다. 오늘의 실험이 내일의 홍보물에 반영되고, 촬영 현장 노트가 제품 기능으로 바뀌고, 지원사업 공고가 다음 사업계획서 문장으로 재사용된다.

 

그래서 LLM 위키는 “나중에 찾기 위한 폴더”보다 “나중의 나를 가르치는 작업대”에 가깝다. 내가 어떤 판단을 했고, 어떤 실험을 했고, 무엇이 반복됐는지를 남겨두면 다음 결정이 빨라진다.

 

처음에는 거창하게 시작할 필요 없다. 링크 하나, 현장 메모 하나, 실험 숫자 하나부터 넣으면 된다. 중요한 것은 저장한 뒤 정리하고, 정리한 뒤 다시 꺼내 쓰는 루프다. 그 루프가 생기면 위키는 단순한 메모장이 아니라 제품과 사업을 밀어주는 지식 자산이 된다.

 

바로 써먹는 명령 예시

 

```text

이 링크 위키에 저장해.

```

 

```text

오늘 실험 결과를 항아리 오프라인 실험 로그로 남겨.

```

 

```text

이 촬영 메모를 PrePro 기능 근거로 정리해.

```

 

```text

저장된 지원사업 공고 중 FlowStore에 맞는 것만 비교해.

```

 

```text

위키 기준으로 이번 주 항아리 홍보물 다시 만들어줘.

```

 

이 다섯 문장만 익혀도 시작할 수 있다. 저장하고, 연결하고, 다시 꺼내 쓰면 된다.

 

참고한 원문: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f