## 소개
이번 OT과제에서는 관심 있는 주제의 지식을 AI와 함께 Markdown wiki로 저장해보는 실습을 해봤습니다. 회사 업무에서 AI를 어떻게 활용했는지 흩어지지 않게 기록하고, 나중에는 반복 업무 자동화 아이디어까지 이어질 수 있는 개인 LLM wiki를 만들어보고 싶었습니다.
평소에는 Hermes라는 AI 에이전트에 Codex 5.5 모델을 연결하고, Obsidian을 저장소로 사용하고 있습니다. Telegram과 Discord로 대화하면서 필요한 내용을 쌓아가는 방식이라, 생각을 정리하거나 아이디어를 발전시키는 데 편했습니다.
이번 OT에서는 Claude Code를 처음 제대로 사용해보면서, 같은 “wiki 만들기”라도 접근 방식이 꽤 다르다는 점을 느꼈습니다.
이번 과제는 단순히 문서를 몇 개 만드는 것보다, 대화형 AI와 파일 기반 작업 도구를 함께 써보며 두 방식의 차이를 경험해본 데 의미가 있었습니다.
이번 과제의 중심은 특정 업무 사례 자체가 아니라, 그런 AI 활용 경험을 계속 쌓고 다시 꺼내 쓸 수 있는 wiki 구조를 만드는 것이었습니다.
제가 시도하고자 했던 것은 다음 세 가지였습니다.
1. 로컬 Markdown 기반의 LLM wiki 구조 만들기
2. AI 활용 사례를 파일로 정리하고 다시 꺼내 쓸 수 있게 만들기
3. 비개발자도 Claude Code와 협업할 수 있는 기본 규칙 만들기
---
## 진행 방법
이번 OT에서는 Claude Sonnet 4.6 모델이 연결된 Claude Code를 사용했습니다. 저장 방식은 로컬 Markdown 파일 기반 wiki로 구성했습니다.
평소에는 Codex 5.5 모델을 연결한 Hermes와 대화하면서 아이디어와 방향을 정리하고, 필요한 내용은 Obsidian에 저장해 관리하고 있습니다. 반면 이번에 사용한 Claude Code는 프로젝트 폴더 안의 파일을 직접 만들고 수정하면서 wiki 구조를 정리하는 데 강점이 있다고 느꼈습니다.
진행은 크게 다섯 단계로 했습니다.
1. **wiki 기본 구조 설계**
- `my-vault/llm-wiki/` 폴더를 만들었습니다.
- 노트, 첨부파일, 원본자료를 구분했습니다.
- 파일명은 `{날짜}-{주제}.md` 형식으로 정했습니다.
- `attachments/`에는 참고 파일을, `_raw/`에는 원본 자료를 보관하도록 나눴습니다.
2. **`CLAUDE.md` 작성**
- Claude Code가 매번 같은 기준으로 작업하도록 볼트 루트에 `CLAUDE.md`를 만들었습니다.
- 프론트매터 형식, 파일명 규칙, 변경 이력 작성 방식 등을 정의했습니다.
- 비개발자인 제가 나중에 봐도 이해할 수 있도록, 기술 용어에는 쉬운 설명을 붙이라는 규칙도 넣었습니다.
3. **변경 이력 관리 방식 추가**
- `_changelog.md` 파일을 만들어 wiki에서 어떤 파일이 언제 수정되었는지 기록하도록 했습니다.
- 단순히 문서만 만드는 것이 아니라, wiki 자체를 계속 관리할 수 있는 구조를 만들어보려 했습니다.
4. **첫 노트 작성**
- 기존에 만들었던 업무 보조 도구의 결과물과 개발 과정을 정리했습니다.
- 반복적으로 발생할 수 있는 업무 리스크 사례와 문서 검토 자동화 아이디어도 wiki에 담았습니다.
5. **기존 파일 정리**
- HTML, Markdown, Excel, Word 문서 등 여러 형식의 파일을 wiki 구조 안에 맞춰 분류했습니다.
- 결과물과 원본 자료가 섞이지 않도록 정리하는 데 신경 썼습니다.
아래는 이번 작업에 실제로 사용한 프롬프트입니다. 처음부터 구조를 다 정해놓고 시작한 것은 아니었고, Claude Code에게 LLM wiki를 어떻게 만들고 관리하면 좋을지 물어보면서 방향을 잡았습니다.
```text
프롬프트 1.
너를 이용해 로컬 LLM wiki를 만들어 관리하고 싶어. 모든 정보는 md파일로 정리할거고, 단순 index 뿐 아니라 llm wiki의 히스토리도 별도의 md파일로 관리하고 싶어. 다만 각 md파일마다 프론트매터를 넣을거라 프론트매터를 활용하면 별도의 히스토리 관련 md파일은 넣을 필요가 없으려나?
프롬프트 2.
우선 이 llm wiki 관련 볼트의 사용규칙을 정해야 할 것 같아. 옵시디언을 사용하는 것은 아니지만, 마땅히 떠오르는 명칭이 없으니 우선은 볼트라고 하자. claude.md를 작성하면 될까? 아니면 다른 방법으로 프론트매터 등 사용규칙을 정하는게 좋을까? 글을 적으면서 생각해보니 llm wiki를 작성/정리/관리하기 위한 방법을 네게 물어보는게 가장 빠르겠다. 네 의견은 어때?
```
이후에는 이 대화에서 정리한 내용을 바탕으로, Claude Code가 같은 기준으로 wiki를 작성·정리·관리할 수 있도록 `CLAUDE.md`에 운영 규칙을 남겼습니다.
```markdown
# My Vault 운영 규칙
## 구조
- `/llm-wiki/` — 업무 AI 활용 wiki
## 파일 명명 규칙
- 일반 노트: `{date}-{slug}.md`
- 인덱스 노트: `index-{키워드}.md`
- 메타 파일: `_` prefix 사용
## 프론트매터 표준
---
title:
date:
tags: []
related: []
type:
status:
source:
aliases: []
updated: []
---
## Claude 행동 규칙
1. 새 노트 생성 시 위 프론트매터 템플릿을 반드시 포함
2. 기존 노트 수정 시 `updated` 리스트에 오늘 날짜 추가
3. 노트 생성/수정/삭제 후 `_changelog.md`에 이력 기록
4. 사용자가 비개발자임을 감안해 기술 용어 사용 시 쉬운 설명 병기
```
---
## 결과와 배운 점
이번에 가장 크게 느낀 점은 AI 도구마다 잘하는 역할이 다르다는 것이었습니다.
평소 쓰던 Hermes는 대화하면서 생각을 발전시키고, 제 맥락을 반영해주는 데 강했습니다. 반면 Claude Code는 파일 구조와 규칙을 명확히 정해두면 그 안에서 일관되게 문서를 만들고 수정하는 데 강했습니다.
특히 비개발자 입장에서는 `CLAUDE.md`가 인상적이었습니다. 파일명, 프론트매터, 변경 이력 같은 기본 규칙을 적어두니 다음 세션에서도 같은 기준으로 작업할 수 있어 AI와 협업하는 방식이 훨씬 안정적으로 느껴졌습니다.
이번 과제를 하면서 LLM wiki는 단순한 노트 모음이 아니라, AI와 함께 지식을 계속 축적하고 다시 꺼내 쓰기 위한 작업 환경에 가깝다고 느꼈습니다.
이번 실험을 하면서 제 개인 LLM wiki를 어떻게 운영하면 좋을지도 조금 더 선명해졌습니다. Hermes는 대화 속에서 제 의도와 맥락을 읽고, 그것을 실행 가능한 Markdown 지시서나 wiki 노트로 정리해주는 두뇌에 가깝다고 느꼈습니다. 반면 Claude Code나 Codex는 그 문서와 프로젝트 규칙을 참고해 실제 파일 생성·수정·코드 작업을 수행하는 실행자에 가까웠습니다. 앞으로는 Hermes에서 생각과 방향을 정리하고, Claude Code로 그 내용을 wiki 구조에 맞게 정리·관리하는 방식으로 병행해보려 합니다.
그리고 이번에 새로 느낀 점은, AI로 만든 결과물만 기록할 것이 아니라 AI 도구를 어떻게 쓰고 조합했는지도 wiki에 남길 만한 지식이라는 점이었습니다. 예를 들어 Hermes와 Claude Code의 차이를 대화하면서 정리해보니, 앞으로는 업무 사례뿐 아니라 “어떤 도구를 어떤 상황에서 쓰면 좋은지”, “규칙 파일은 언제 업데이트해야 하는지”, “대화형 AI와 파일 기반 wiki를 어떻게 연결할지” 같은 운영 노트도 함께 쌓아갈 수 있겠다고 느꼈습니다.
## 시행착오
첫 번째는 `CLAUDE.md` 위치 문제였습니다. 처음에는 `llm-wiki` 하위 폴더에 만들었는데, Claude Code가 프로젝트 규칙을 안정적으로 읽게 하려면 실제 작업 루트에 `CLAUDE.md`를 두는 것이 중요하다는 점을 알게 되어 볼트 루트로 옮겼습니다.
두 번째는 프론트매터 작성 방식 오류였습니다. 수정 이력을 `updated#1`, `updated#2`처럼 쓰려고 했는데, Markdown/YAML에서는 `#`이 주석처럼 해석될 수 있다는 점을 알게 됐습니다. 그래서 수정 이력은 YAML 리스트 형태로 바꿨습니다.
세 번째는 히스토리 문서 중복 문제였습니다. 같은 프로젝트의 히스토리 문서가 2개 있었는데 어떤 것이 최종본인지 애매했습니다. Claude와 함께 비교하면서 최종본을 확인하고, 차이가 있는 내용은 별도 노트로 분리했습니다.
## 작동한 방식: 최소 규칙 먼저
이번 실험에서 가장 잘 작동한 방식은 처음부터 완벽한 wiki를 만들려고 하기보다, 먼저 `CLAUDE.md`에 최소 규칙만 적어두고 시작하는 것이었습니다.
제가 느낀 최소 규칙은 아래 네 가지입니다.
1. 파일명 규칙
2. 프론트매터 형식
3. 원본자료와 정리본 분리 방식
4. 변경 이력 기록 방식
이 네 가지만 있어도 Claude Code가 훨씬 일관되게 움직였습니다.
## 앞으로의 활용 계획
앞으로는 Hermes와 Claude Code를 역할별로 나누어 함께 사용해보려고 합니다.
- Hermes는 대화형 탐색, 의도 정리, 실행 가능한 Markdown 지시서 작성에 사용
- Claude Code는 그 지시서와 `CLAUDE.md` 규칙을 바탕으로 Markdown wiki 구조화와 파일 관리를 수행
- 실제 업무에서 나온 AI 활용 사례를 민감정보 없이 일반화해서 계속 wiki에 축적
- 검토가 필요한 자동화 아이디어는 작은 단위의 실험부터 기록
- 업무 지식뿐 아니라, AI 도구 사용 경험 자체도 별도 지식으로 정리
## 도움이 필요한 점
첫 번째는 Hermes처럼 대화하면서 쌓이는 내용과, Claude Code로 구조화한 wiki를 어떻게 자연스럽게 연결할지입니다. 대화형 AI와 파일 기반 wiki를 병행해서 쓰는 좋은 운영 방식이 있다면 배우고 싶습니다.
두 번째는 한 세션이 길어졌을 때 기존 맥락을 새 세션으로 어떻게 넘길지입니다. 대화가 길어지면 맥락 유지가 어려워지거나 토큰을 많이 쓰게 되는데, 핵심 결정사항과 파일 구조, 시행착오, 남은 작업을 어떤 형식으로 요약해두면 다음 세션에서 자연스럽게 이어갈 수 있을지 궁금합니다.
세 번째는 변경 이력 관리의 적정 수준입니다. 이번 과제를 Claude Code, Hermes와 계속 대화하며 Markdown 파일로 다듬다 보니 `_changelog.md`에 변경 이력이 꽤 많이 쌓였습니다. 개발 작업이나 자동화 스크립트 수정에는 changelog가 유용하지만, 단순 글쓰기나 과제 초안 수정에도 같은 수준으로 변경 이력을 남기는 것이 좋은지, 아니면 최종본 중심으로 가볍게 관리하는 것이 나은지 고민이 생겼습니다.
---
## 도움 받은 글
OT 과제 안내를 바탕으로 직접 실험했습니다. 별도로 참고한 외부 글은 없습니다.
