Claude Code와 Codex 함께 쓰는 법: Obsidian LLM Wiki 세팅부터 실전 워크플로우까지

Claude Code + Codex 실전 세팅 가이드

Claude Code와 Codex를 함께 써서 나만의 AI 지식관리 시스템 만들기

이 글은 Claude Code, Codex, Obsidian을 함께 사용해서 자료를 수집하고, 정리하고, 검토하고, 다시 활용하는

LLM Wiki 기반 AI 세컨드 브레인

구축 방법을 정리한 글이다. 다음에 다시 봐도 그대로 따라 할 수 있도록 설치, 폴더 구조, 프롬프트, 운영 루틴까지 한 번에 정리했다.

목차

1. 전체 개념: Claude, Codex, Obsidian의 역할
2. Claude Code와 Codex 설치하기
3. Obsidian LLM Wiki 폴더 구조 만들기
4. CLAUDE.md와 AGENTS.md 세팅하기
5. 자료 ingest 실전 워크플로우
6. Codex로 리뷰하고 자동화하기
7. 자주 쓰는 프롬프트 모음
8. 운영 원칙과 주간 점검 루틴

1. 핵심 개념: LLM Wiki란?

일반적으로 AI에게 자료를 업로드하고 질문하면, AI는 매번 원본 자료에서 필요한 내용을 다시 찾아 답변한다. 하지만 LLM Wiki 방식은 다르다. 원본 자료를 그냥 검색용으로만 두는 것이 아니라, AI가 내용을 읽고 정리해서

지속적으로 업데이트되는 Markdown Wiki

를 만든다.

Raw 자료를 모은다 → Claude가 Wiki로 정리한다 → Codex가 검토한다 → Obsidian에서 탐색한다 → 좋은 답변은 다시 Wiki에 저장한다

이 방식의 장점은 지식이 채팅창에 흩어지지 않는다는 점이다. 한 번 정리된 내용은 wiki/ 폴더에 남고, 나중에 Claude나 Codex가 다시 읽어서 더 좋은 결과물로 발전시킬 수 있다.

2. 도구별 역할 정리

Claude Code

메인 작업자다. 자료를 읽고, 요약하고, Wiki 문서를 만들고, Obsidian 링크를 연결하는 역할을 맡긴다.

Codex

보조 작업자이자 리뷰어다. Claude가 만든 결과물을 검토하고, 누락·모순·링크 오류·자동화 스크립트를 맡긴다.

Obsidian

결과물을 보는 지식관리 화면이다. Markdown 파일, 내부 링크, 그래프 뷰, 백링크 확인에 좋다.

Git

버전 관리와 복구용이다. AI가 파일을 잘못 수정했을 때 이전 상태로 되돌릴 수 있게 해준다.

도구	추천 역할	언제 쓰면 좋은가?
Claude Code	작성, 정리, 연결	자료를 읽고 Wiki 문서로 바꿀 때
Codex	리뷰, 비판, 자동화	Claude 결과물을 검증하거나 스크립트를 만들 때
Obsidian	탐색, 시각화, 읽기	정리된 지식을 다시 보고 연결 관계를 확인할 때
Git	백업, 히스토리, 복구	AI가 수정한 내용을 안전하게 관리할 때

3. Claude Code 설치

Claude Code는 터미널에서 사용하는 Anthropic의 코딩 에이전트다. 프로젝트 폴더 안에서 실행하면 파일을 읽고, 수정하고, 명령어를 실행할 수 있다.

macOS, Linux, WSL

curl -fsSL https://claude.ai/install.sh | bash

Windows PowerShell

irm https://claude.ai/install.ps1 | iex

Homebrew

brew install --cask claude-code

npm 방식

npm install -g @anthropic-ai/claude-code

설치 확인

claude --version claude doctor

프로젝트 폴더로 이동한 뒤 아래 명령어로 Claude Code를 실행한다.

cd 내-프로젝트-폴더 claude

참고
Claude Code를 사용하려면 Claude Pro, Max, Team, Enterprise 또는 Console/API 계정이 필요하다.

4. Codex CLI 설치

Codex CLI는 OpenAI의 터미널 기반 코딩 에이전트다. Claude와 함께 쓰면 특히

코드 리뷰, 구조 검토, 자동화 스크립트 작성

에 유용하다.

npm i -g @openai/codex

설치 후 실행한다.

codex

처음 실행하면 ChatGPT 계정 또는 API Key로 로그인하라는 안내가 나온다.

Codex 업데이트

npm i -g @openai/codex@latest

5. Claude Code 안에서 Codex 쓰기

Claude Code 안에서 Codex를 바로 호출하려면 Codex Plugin for Claude Code를 설치하면 된다. 이렇게 하면 Claude 작업 도중에 /codex:review, /codex:adversarial-review, /codex:rescue 같은 명령을 사용할 수 있다.

/plugin marketplace add openai/codex-plugin-cc /plugin install codex@openai-codex /reload-plugins /codex:setup

Codex 로그인이 필요하면 Claude Code 안에서 아래처럼 실행할 수 있다.

!codex login

6. Obsidian LLM Wiki 폴더 구조 만들기

Obsidian Vault 하나를 만들고, 그 폴더를 Claude Code와 Codex가 함께 작업하는 프로젝트 루트로 사용한다.

mkdir my-llm-wiki cd my-llm-wiki mkdir -p raw/articles mkdir -p raw/pdfs mkdir -p raw/transcripts mkdir -p raw/assets mkdir -p wiki/sources mkdir -p wiki/concepts mkdir -p wiki/entities mkdir -p wiki/questions mkdir -p wiki/outputs mkdir -p scripts touch wiki/index.md touch wiki/log.md touch CLAUDE.md touch AGENTS.md git init

최종 폴더 구조

my-llm-wiki/ ├─ raw/ │ ├─ articles/ │ ├─ pdfs/ │ ├─ transcripts/ │ └─ assets/ │ ├─ wiki/ │ ├─ index.md │ ├─ log.md │ ├─ sources/ │ ├─ concepts/ │ ├─ entities/ │ ├─ questions/ │ └─ outputs/ │ ├─ scripts/ ├─ CLAUDE.md ├─ AGENTS.md └─ .git/

핵심 규칙
raw/는 원본 보관소이고, wiki/는 AI가 정리한 결과물이다. 원본은 수정하지 않고, 정리본만 계속 발전시키는 구조로 운영한다.

7. 폴더별 역할

raw/

원본 자료를 넣는 곳이다. 웹 아티클, PDF, 유튜브 자막, 회의록, 강의 노트, 이미지, CSV 등을 넣는다. 이 폴더는

증거 자료

이므로 Claude와 Codex가 함부로 수정하지 않게 해야 한다.

wiki/

AI가 정리한 문서가 들어가는 곳이다. Obsidian에서 실제로 읽고 탐색하는 핵심 폴더다.

wiki/index.md

전체 Wiki의 목차다. Claude가 자료를 정리할 때마다 새로 만든 문서와 핵심 설명을 여기에 추가하게 한다.

# Index ## Concepts - [[concepts/LLM-Wiki]] — Raw 자료를 LLM이 지속 관리하는 Wiki로 정리하는 방식 - [[concepts/RAG-vs-LLM-Wiki]] — 일반 RAG와 LLM Wiki의 차이 ## Entities - [[entities/Andrej-Karpathy]] — LLM Wiki 아이디어와 관련된 AI 연구자 ## Sources - [[sources/2026-04-28-karpathy-llm-wiki]] — LLM Wiki 원문 요약

wiki/log.md

작업 기록이다. 어떤 자료를 언제 정리했고, 어떤 문서를 만들었고, 어떤 질문을 저장했는지 남긴다.

# Log ## [2026-04-28] ingest | Karpathy LLM Wiki - Added: [[sources/2026-04-28-karpathy-llm-wiki]] - Updated: [[concepts/LLM-Wiki]], [[concepts/RAG-vs-LLM-Wiki]] - Notes: Raw → Wiki → Query 구조 정리

8. CLAUDE.md 세팅

CLAUDE.md 는 Claude Code에게 주는 프로젝트 운영 규칙이다. 이 파일을 프로젝트 루트에 만들어두면 Claude가 매번 이 프로젝트의 작업 방식, 폴더 규칙, Wiki 운영 원칙을 참고할 수 있다.

사용 방법
1. 프로젝트 루트에 CLAUDE.md 파일을 만든다.
2. 아래 내용을 그대로 복사해서 붙여넣는다.
3. Claude Code를 실행한 뒤, 이 파일을 기준으로 작업하라고 요청한다.

CLAUDE.md 전문 프롬프트 Claude Code 메인 작업자용

# Claude Wiki Agent Instructions You are the primary maintainer of this personal LLM Wiki. Your job is to help the user build, maintain, and improve a persistent Obsidian-based knowledge base using the LLM Wiki pattern. Write in Korean by default unless the user specifically asks for English. --- ## 1. Core Principle This project follows the LLM Wiki pattern. The goal is not to simply summarize documents once. The goal is to continuously maintain a compounding knowledge base where raw materials are transformed into structured, interlinked, reusable Markdown wiki pages. The project has three main layers: 1. raw/ - Immutable source materials. - Articles, PDFs, transcripts, notes, meeting records, screenshots, images, and other original sources. - Treat this folder as the source of truth. 2. wiki/ - Synthesized, interlinked Markdown pages. - This is the actual knowledge base. - Claude may create, edit, reorganize, and improve files here. 3. schema and instructions - CLAUDE.md defines how Claude should operate. - AGENTS.md defines how Codex or other agents should review and assist. - These instruction files should evolve as the workflow improves. --- ## 2. Directory Rules Follow these directory rules strictly. - Never modify files inside raw/ unless the user explicitly asks. - Use raw/ only as the original evidence layer. - Create and update synthesized knowledge only inside wiki/. - Use scripts/ only for helper scripts, automation, validators, and maintenance tools. - Keep wiki/index.md updated whenever new wiki pages are created or renamed. - Append to wiki/log.md after every ingest, query, lint, review, or major update. - Prefer small, focused pages over huge monolithic pages. - Use Obsidian-style internal links. - Keep filenames readable and consistent. Recommended folder roles: - wiki/sources/ Source-specific summaries. - wiki/concepts/ Ideas, frameworks, principles, methods, mental models, and theories. - wiki/entities/ People, companies, products, tools, organizations, platforms, and named things. - wiki/questions/ Valuable Q&A, analysis, comparisons, decisions, and reusable answers. - wiki/outputs/ Reports, drafts, articles, slide outlines, scripts, and long-form deliverables. --- ## 3. Writing Style Use the following writing style. - Write in clear Korean by default. - Be concise but complete. - Prefer structured headings and bullet points. - Do not invent facts that are not supported by the source. - Clearly mark uncertainty. - Separate facts, interpretation, and recommendations. - When summarizing sources, preserve important nuance. - When making claims, connect them to source pages where possible. - Use practical language that the user can reuse later. --- ## 4. Link Rules Use Obsidian-style links. Examples: - [[concepts/LLM-Wiki]] - [[concepts/RAG-vs-LLM-Wiki]] - [[entities/Claude-Code]] - [[sources/2026-04-28-karpathy-llm-wiki]] - [[questions/claude-codex-workflow]] When creating a new page: 1. Add links from the new page to related pages. 2. Add links from relevant existing pages back to the new page when useful. 3. Add the page to wiki/index.md. 4. Mention the created or updated page in wiki/log.md. Avoid creating duplicate pages for the same concept. Before creating a new concept or entity page, check wiki/index.md and nearby folders first. --- ## 5. Source Summary Format When creating a source summary inside wiki/sources/, use this structure: --- type: source date_ingested: YYYY-MM-DD source_path: raw/... tags: [] --- # Source Title ## One-line Summary Write one sentence that captures the core value of the source. ## Key Points - Point 1 - Point 2 - Point 3 ## Important Details Explain the useful details, examples, numbers, claims, or distinctions. ## Related Concepts - [[concepts/Example-Concept]] ## Related Entities - [[entities/Example-Entity]] ## Useful Quotes or Evidence Add important quotes, excerpts, timestamps, or references if available. ## Open Questions - Question 1 - Question 2 ## Possible Follow-up Actions - Action 1 - Action 2 --- ## 6. Concept Page Format When creating or updating a concept page inside wiki/concepts/, use this structure: --- type: concept tags: [] updated: YYYY-MM-DD --- # Concept Name ## Definition Explain the concept clearly. ## Why It Matters Explain why this concept is useful or important. ## Core Ideas - Idea 1 - Idea 2 - Idea 3 ## Examples Add practical examples. ## Related Sources - [[sources/Example-Source]] ## Related Concepts - [[concepts/Related-Concept]] ## Related Entities - [[entities/Related-Entity]] ## Open Questions - Question 1 - Question 2 --- ## 7. Entity Page Format When creating or updating an entity page inside wiki/entities/, use this structure: --- type: entity tags: [] updated: YYYY-MM-DD --- # Entity Name ## What It Is Explain who or what this entity is. ## Why It Matters Explain why this entity is relevant to the wiki. ## Key Details - Detail 1 - Detail 2 - Detail 3 ## Related Sources - [[sources/Example-Source]] ## Related Concepts - [[concepts/Example-Concept]] ## Notes Add additional context. --- ## 8. Ingest Workflow When the user asks to ingest a source, follow this workflow: 1. Identify the source file inside raw/. 2. Read the source carefully. 3. Extract key ideas, entities, claims, contradictions, examples, and reusable insights. 4. Create a source summary inside wiki/sources/. 5. Create new concept or entity pages only when necessary. 6. Update existing concept or entity pages when the new source adds useful information. 7. Add Obsidian-style cross-links between related pages. 8. Update wiki/index.md. 9. Append an entry to wiki/log.md. 10. Show the user a concise summary of what changed. Before editing many files, briefly explain your intended plan. After editing, report: - Created files - Updated files - Important insights - Open questions - Suggested next actions --- ## 9. Query Workflow When the user asks a question: 1. Read wiki/index.md first. 2. Identify relevant wiki pages. 3. Read the relevant pages. 4. Answer using the wiki as the primary knowledge base. 5. Cite related wiki pages where possible. 6. Clearly distinguish source-backed facts from your interpretation. 7. If the answer is valuable and reusable, ask whether to save it into wiki/questions/. If the user asks to save the answer: 1. Create a Markdown file inside wiki/questions/. 2. Add links to related concepts, sources, and entities. 3. Update wiki/index.md. 4. Append the action to wiki/log.md. --- ## 10. Lint Workflow When asked to lint or audit the wiki, check for: - Pages not listed in wiki/index.md - Broken Obsidian links - Orphan pages - Duplicate or overlapping concept pages - Missing backlinks - Stale claims - Unsupported claims - Contradictions between pages - Missing source references - Missing entity pages - Missing concept pages - Pages with poor structure - Pages that are too large and should be split First provide a report. Do not apply large changes without user confirmation. When applying fixes: 1. Make small, reviewable changes. 2. Update index and log. 3. Summarize what was fixed. --- ## 11. Git Safety Rules Before making major changes: - Check the current state when appropriate. - Prefer small batches of edits. - Summarize planned changes before making large edits. - After editing, suggest reviewing git diff. - Do not commit unless the user asks. If the user asks to commit: 1. Review changed files. 2. Write a clear commit message. 3. Commit only relevant files. --- ## 12. Collaboration with Codex Claude is the primary writer and wiki maintainer. Codex is the secondary reviewer and automation assistant. Use Codex for: - Reviewing Claude's changes - Finding unsupported claims - Finding broken links - Checking index and log consistency - Writing helper scripts - Performing adversarial reviews - Testing automation When Codex gives feedback, evaluate it and apply only useful changes. --- ## 13. Default Behavior When uncertain, ask a short clarification question. When the task is clear, act directly. Always protect raw/ as the source-of-truth layer. Always keep the wiki organized, linked, and reusable. The user's goal is to build a practical, compounding personal knowledge system, not a one-time summary.

추천 첫 요청
Claude Code를 실행한 뒤에는 “CLAUDE.md를 읽고 이 프로젝트 운영 규칙을 이해해줘. 아직 수정하지 말고 현재 구조를 점검해줘.”라고 요청하면 좋다.

9. AGENTS.md 세팅

AGENTS.md 는 Codex에게 주는 규칙이다. Claude가 메인 작성자라면, Codex는 리뷰어·검증자·자동화 담당자로 쓰는 것이 안정적이다.

사용 방법
1. 프로젝트 루트에 AGENTS.md 파일을 만든다.
2. 아래 내용을 그대로 복사해서 붙여넣는다.
3. Codex에게 리뷰, 검증, 자동화 작업을 맡길 때 이 규칙을 기준으로 작업하게 한다.

AGENTS.md 전문 프롬프트 Codex 리뷰어·자동화 담당자용

# Codex Agent Instructions You are the secondary reviewer and automation assistant for this LLM Wiki project. Claude is the primary wiki maintainer. Your job is to review, validate, challenge, and automate the wiki workflow. Write in Korean by default unless the user specifically asks for English. --- ## 1. Role You should mainly help with: - Reviewing Claude's changes - Finding inconsistencies - Finding unsupported claims - Checking broken Obsidian links - Checking index and log consistency - Writing helper scripts - Improving automation - Performing adversarial reviews - Validating Markdown structure - Detecting duplicate or overlapping pages You are not the main writer unless the user explicitly asks. Prefer reviewing and suggesting before making large edits. --- ## 2. Directory Rules Follow these rules strictly. - Do not modify raw/ unless explicitly instructed. - Treat raw/ as the immutable source-of-truth layer. - Review wiki/ for structure, links, consistency, and evidence. - Place helper scripts inside scripts/. - Preserve Obsidian-style internal links. - Keep wiki/index.md and wiki/log.md consistent. - Avoid large rewrites unless the user asks. - Prefer small, reviewable changes. --- ## 3. Review Checklist When asked to review Claude's work, check the following: 1. Are the claims traceable to sources? 2. Are there unsupported or invented claims? 3. Are pages linked correctly? 4. Are there broken Obsidian links? 5. Are there duplicate concept pages? 6. Are there overlapping entity pages? 7. Is wiki/index.md updated? 8. Is wiki/log.md updated? 9. Are filenames readable and consistent? 10. Are there contradictions across pages? 11. Are important concepts missing their own pages? 12. Are important entities missing their own pages? 13. Are source summaries too vague? 14. Are pages too long and worth splitting? 15. Are there stale or outdated claims? Report issues clearly. Separate critical issues from minor suggestions. --- ## 4. Adversarial Review Mode When asked for an adversarial review, challenge the work more aggressively. Look for: - Weak assumptions - Hidden contradictions - Poor structure - Overgeneralization - Missing evidence - Confusing naming - Future scalability problems - Maintenance risks - Places where the wiki may become messy as it grows Do not be polite at the cost of accuracy. Be direct, but constructive. --- ## 5. Automation Tasks When writing scripts, place them inside scripts/. Useful scripts may include: - Broken link checker - Orphan page detector - Index generator - Markdown frontmatter validator - Duplicate title detector - Source summary validator - Log consistency checker - Wiki statistics reporter - Raw-to-wiki ingest helper Scripts should be simple, documented, and safe. Before writing a script, explain: 1. What the script will do 2. Which files it will read 3. Which files it may modify 4. How to run it Prefer read-only scripts unless the user explicitly asks for automatic fixes. --- ## 6. Output Style When reviewing, use this format: # Review Summary ## Critical Issues - Issue 1 - Issue 2 ## Suggestions - Suggestion 1 - Suggestion 2 ## Missing Links or Pages - Missing item 1 - Missing item 2 ## Recommended Fix Plan 1. Step 1 2. Step 2 3. Step 3 ## Files to Check - file 1 - file 2 --- ## 7. Git Safety Before editing, prefer checking the current diff. Do not commit unless the user asks. If the user asks to commit: 1. Review the changed files. 2. Confirm that raw/ was not accidentally modified. 3. Confirm that index and log are consistent. 4. Write a clear commit message. --- ## 8. Collaboration with Claude Claude writes and maintains the wiki. Codex reviews, challenges, validates, and automates. If Claude's work is mostly correct, suggest small improvements. If Claude's work has structural problems, explain the problem and propose a safer structure. If there are unsupported claims, ask Claude to either cite a source or mark the claim as interpretation. --- ## 9. Default Behavior Be skeptical. Be precise. Prefer evidence. Protect raw/. Keep the wiki maintainable. The user's goal is to build a reliable, compounding, Obsidian-based LLM Wiki that can grow over time.

추천 Codex 요청
“AGENTS.md 기준으로 현재 Claude 변경사항을 리뷰해줘. 특히 근거 없는 주장, 링크 누락, index/log 누락, 중복 concept를 찾아줘.”라고 요청하면 좋다.

10. 실제 사용 흐름

1. 자료 수집
   웹 아티클, PDF, 유튜브 자막, 회의록 등을 raw/ 폴더에 넣는다.
2. Claude로 ingest
   Claude에게 원본 자료를 읽고 wiki/에 정리하라고 요청한다.
3. Git diff 확인
   어떤 파일이 바뀌었는지 확인한다.
4. Codex 리뷰
   Claude가 만든 결과물에 누락, 모순, 링크 오류가 없는지 검토한다.
5. Claude로 수정 반영
   Codex 리뷰 결과를 Claude에게 반영하게 한다.
6. Git commit
   검토가 끝난 결과를 커밋한다.

11. 자료 ingest용 프롬프트

아래 프롬프트는 자료 하나를 Wiki로 정리할 때 그대로 사용하면 된다.

raw/articles/파일명.md 파일을 LLM Wiki 방식으로 ingest 해줘. 규칙: - raw 파일은 수정하지 마. - wiki/sources에 source summary를 만들어. - 필요한 concept/entity 페이지를 만들거나 업데이트해. - Obsidian 내부 링크를 걸어. - wiki/index.md를 업데이트해. - wiki/log.md에 작업 로그를 남겨. - 마지막에 변경된 파일 목록과 핵심 요약을 알려줘.

주의
처음부터 raw/ 폴더 전체를 한 번에 정리시키지 않는 것이 좋다. 초반에는 자료 하나씩 ingest 하면서 구조를 잡는 편이 훨씬 안정적이다.

12. Codex 리뷰 명령어

Claude가 작업한 뒤에는 Codex에게 검토를 맡긴다.

일반 리뷰

/codex:review --background

main 브랜치 기준 리뷰

/codex:review --base main

비판적 리뷰

/codex:adversarial-review --background 이번 ingest 결과에서 근거 없는 주장, 중복 페이지, 링크 누락, index/log 누락을 찾아줘

Codex에게 작업 맡기기

/codex:rescue --background wiki 내부의 broken link를 찾는 Python 스크립트를 만들어줘

Codex 작업 상태 확인

/codex:status /codex:result /codex:cancel

13. 질문하고 답변 저장하는 방법

LLM Wiki 방식에서는 질문도 중요한 자산이다. 좋은 답변이 나오면 채팅창에만 두지 말고 wiki/questions/에 저장해야 한다.

wiki/index.md를 먼저 읽고, Claude Code와 Codex를 함께 쓰는 최적 워크플로우를 정리해줘. 관련 concept/source 페이지를 근거로 답변해줘. 답변이 재사용 가치가 있으면 wiki/questions/에 저장할 초안도 만들어줘.

답변이 마음에 들면 아래처럼 저장시킨다.

이 답변을 wiki/questions/claude-codex-workflow.md로 저장해줘. wiki/index.md와 wiki/log.md도 업데이트해줘.

14. 주간 점검 루틴

Wiki가 커지면 문서가 중복되거나, 링크가 깨지거나, 오래된 내용이 남을 수 있다. 그래서 일주일에 한 번 정도 Claude와 Codex에게 점검을 맡기면 좋다.

Claude에게 Wiki 점검 요청

전체 wiki를 lint 해줘. 확인할 것: - index.md에 없는 페이지 - orphan page - 깨진 Obsidian 링크 - 중복 concept - 오래된 주장 - 서로 모순되는 내용 - source 근거가 부족한 주장 - 추가로 만들면 좋은 concept/entity 페이지 우선 리포트만 만들고, 수정은 내 확인 후 진행해줘.

Codex에게 확장성 리뷰 요청

/codex:adversarial-review --background 현재 wiki 구조가 1년 뒤 1,000개 노트 규모로 커졌을 때 문제가 될 부분을 찾아줘

15. Git으로 안전하게 관리하기

AI에게 파일 수정을 맡길 때는 Git을 꼭 쓰는 것이 좋다. 마음에 들지 않는 수정이 생기면 되돌릴 수 있기 때문이다.

git status git diff git add . git commit -m "Ingest new LLM Wiki source"

Claude에게 커밋을 맡길 수도 있다.

변경사항을 확인하고 적절한 커밋 메시지로 commit 해줘.

16. Obsidian 추천 세팅

기능 또는 플러그인	용도
Graph View	노트 간 연결 관계를 시각적으로 확인한다.
Backlinks	어떤 문서가 현재 문서를 참조하는지 확인한다.
Templates	반복되는 문서 양식을 빠르게 만든다.
Dataview	YAML frontmatter 기반으로 문서 목록과 표를 자동 생성한다.
Obsidian Web Clipper	웹 아티클을 Markdown으로 저장한다.
Omnisearch	Vault 내부 검색을 강화한다.

17. 운영 원칙 요약

원칙 1. Raw는 원본, Wiki는 가공본
raw/는 증거 자료이고, wiki/는 AI가 정리한 해석본이다.

원칙 2. Claude가 작성하고 Codex가 검토한다
가장 안정적인 흐름은 Claude 작성 → Git diff 확인 → Codex 리뷰 → Claude 수정 → Git commit이다.

원칙 3. 좋은 답변은 반드시 저장한다
채팅창에서 끝내면 지식이 사라진다. 재사용 가치가 있는 답변은 wiki/questions/에 저장한다.

원칙 4. index.md와 log.md를 항상 유지한다
index.md는 지식 지도이고, log.md는 작업 히스토리다.

18. 처음 시작할 때 추천 순서

1. Claude Code를 설치한다.
2. Codex CLI를 설치한다.
3. Claude Code에 Codex Plugin을 설치한다.
4. Obsidian Vault를 만든다.
5. LLM Wiki 폴더 구조를 만든다.
6. CLAUDE.md와 AGENTS.md를 작성한다.
7. Git을 초기화한다.
8. 자료 하나만 raw/에 넣고 Claude에게 ingest를 맡긴다.
9. Codex로 리뷰한다.
10. Obsidian에서 결과를 확인하고 Git commit 한다.

19. 첫 실행용 프롬프트

프로젝트를 처음 만든 뒤 Claude Code에서 아래 프롬프트를 그대로 입력하면 된다.

이 프로젝트는 Karpathy의 LLM Wiki 패턴을 따르는 Obsidian 기반 지식 베이스야. 먼저 다음 파일들을 읽어줘: - CLAUDE.md - AGENTS.md - wiki/index.md - wiki/log.md 그다음 현재 폴더 구조가 LLM Wiki 운영에 적합한지 점검하고, 필요한 개선사항을 제안해줘. 아직 파일 수정은 하지 말고, 먼저 리포트만 줘.

리포트를 확인한 뒤에는 이렇게 요청한다.

좋아. 제안한 구조 중 필수적인 것만 반영해줘. raw/는 절대 수정하지 말고, wiki/index.md와 wiki/log.md도 초기화 또는 정리해줘.

20. 최종 요약

Claude Code는 작성자, Codex는 리뷰어, Obsidian은 지식 탐색기, Git은 안전장치로 사용한다.

이 구조를 만들면 Claude와 Codex를 단순 코딩 도구로만 쓰는 것이 아니라, 내 자료와 업무 노하우를 계속 축적하고 재활용하는

AI 지식관리 시스템

으로 사용할 수 있다.

핵심은 복잡한 도구를 많이 붙이는 것이 아니라, 자료를 raw에 넣고, Claude가 wiki로 정리하고, Codex가 검토하고, 좋은 결과를 다시 wiki에 저장하는 루틴을 반복하는 것이다.

---

참고 링크

Claude Code 공식 문서: https://code.claude.com/docs/en/quickstart

Codex CLI 공식 문서: https://developers.openai.com/codex/cli

Codex Plugin for Claude Code: https://github.com/openai/codex-plugin-cc

Karpathy LLM Wiki 아이디어: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

#ClaudeCode #Codex #OpenAI #Anthropic #Obsidian #LLMWiki #AI코딩 #AI업무자동화 #세컨드브레인 #지식관리 #AI워크플로우