지식을 컨텍스트로
채우는 첫 90분.

마크다운 — AI 시대의 통신 규격

세션 매핑: Session 1 1부 (1)(2) — 마크다운 핵심 메시지 + 5분 라이브 데모 · 코호트의 한 단어: 강의가 끝나도 딱 하나 가져가야 한다면 → 마크다운

1. 왜 지금 마크다운인가

(a) 마크업 랭귀지의 계보

• HTML (Hypertext Markup Language) — 웹 표준
• XML (Extended Markup Language) — DOCX·HWPX·PPTX의 내부 구조
• 마크다운(.md) — 마크업 랭귀지 톤다운 버전. 사람도 읽고 AI도 처리

(b) 비교표

→ 마크다운의 유일한 강점: human-friendly + machine-readable + AI-friendly + metadata-capable + format-portable.

(c) AI들이 모두 마크다운으로 출력하는 이유

• ChatGPT / Claude / Gemini / Grok 등 모든 LLM이 공통 출력 포맷으로 마크다운 채택
• 우연이 아니라 사람과 AI가 동시에 보기 편한 유일한 합의점이기 때문

(d) 정부·산업 채택

• 2026년 3월 초, 국가 AI 전략위원회가 공식 보고 포맷의 표준으로 마크다운 채택
• 마이크로소프트·한컴 등 모든 문서 제조사가 자사 포맷 → 마크다운 변환 툴 출시 중

(e) PPT/HWP의 운명

• PPT/HWP/PDF는 퍼블리케이션 포맷 — 사람이 보기 위해 한 번 출력한 형식
• 한 번 출력되면 AI 워크플로에 재투입하기 어려움 → AX(AI 전환)의 결정적 병목
• "조직의 모든 보고가 PPT면 AX는 못 한다" — 사용자 LG 임원 교육 발언

2. 핵심 문법 — 5분 라이브 데모

(a) Heading (#)

# 제목             → Heading 1 (문서 최상위)
## 챕터            → Heading 2
### 섹션           → Heading 3 ... 6레벨까지

AI는 이 위계로 문서 구조를 파악.

(b) 강조

(c) 리스트 + 들여쓰기

- 장 볼 것들
  - 우유
  - 식빵
- 좋아하는 음식
  - 치킨
  - 피자

→ AI 편집기에서 Tab 키 안 먹음 → 스페이스바 2~4칸으로 들여쓰기.

(d) Backtick (`) — Esc 키 아래, Tab 키 위

→ 삼중 백틱 활용 예시: 회의록 + 작년 인사말 + 전임 원장 인사말 3개를 AI에게 줄 때, 각각을 코드 블록으로 감싸면 AI가 어디서부터 어디까지가 무슨 자료인지 명확히 인식.

(e) 위키링크 ([[]]) — 옵시디언 확장

• 표준 마크다운은 아니지만 옵시디언·Bear·Logseq 등이 채택
• 같은 볼트 내 다른 노트로 즉시 링크

3. 메타데이터(Frontmatter) — 본문 위 YAML

---
type: note
aliases: [별칭]
description: "1–2문장 영어 LLM 힌트"
author:
  - "[[구요한]]"
date created: 2026-05-02
date modified: 2026-05-02
tags: [pkm, markdown]
---

본문 시작…

4. 자주 묻는 질문

Q. 마크다운 직접 쓰기 어렵다면? → 차선책: Google Docs. 입력 후 마크다운 다운로드 가능. 핵심 아젠다만 마크다운으로 보존하면 됨.

Q. PDF는? → 읽기는 Claude Code가 OCR로 다 해냄. 단, 옵시디언 볼트에 직접 넣지는 말 것 — 검색·메타 처리가 어려워짐. 메타 정보만 옵시디언에, 본문은 외부 도구(Bookends/Zotero)에.

Q. HWP 중심 기관에서 어떻게 시작?

• 단계 1: 모든 HWP → HWPX(XML 기반)로 전면 교체
• 단계 2: 헤딩 스타일을 명시적으로 적용 (글자 크기 조절 X)
• 단계 3: 마크다운 변환 툴 활용 (한컴이 출시 중)

메타데이터 설계 원리

세션 매핑: Session 1 1부 (3) — 메타데이터 = 빙산의 일각 · 한 문장: 본문보다 메타데이터가 AI에게 더 중요하다.

1. Progressive Disclosure (점진적 공개)

(a) 컨텍스트 윈도우의 한계

• 모든 LLM은 기억할 수 있는 토큰 수가 제한 (모델별 상이)
• 옵시디언 볼트에 1만 개 노트가 있어도 모두 다 읽을 수는 없음
• 따라서 효율적 읽기가 필수

(b) AI는 메타데이터부터 읽는다

• 노트의 frontmatter(YAML 영역)는 빙산의 일각 — 본문 진입 전 먼저 스캔
• 메타로 어떤 종류의 노트인지·언제 쓴 건지·누가 작성했는지·어떤 주제인지 파악
• "이 노트는 깊게 볼만한가?" 를 메타로 1차 판단 → 필요한 노트만 본문 진입

(c) 비유

• 조직에서 누구한테 무슨 일을 시킬지 머릿속에 있는 그 정보 = 각 사람의 메타데이터
• 카탈로그/제품 설명서만 보고 사야 할 제품을 결정하는 것과 같음
• 도서관에서 카드 카탈로그로 책을 찾는 것과 같음

→ "AI가 별거 없다 = 내가 쓴 말 별거 없다" — 메타데이터를 안 쓰면 AI는 맥락 없는 텍스트 더미를 받는 것

2. CMDS 7 필수 프로퍼티

---
type:           # note / meeting / terminology / curriculum 등
aliases: []     # 별칭 (배열)
description: "" # ⭐ 영어 1–2문장, LLM 관련성 힌트
author:
  - "[[구요한]]"
date created:   # YYYY-MM-DD (ISO 8601)
date modified:  # YYYY-MM-DD
tags: []        # 주제 태그
---

(a) type — 노트의 종류

• 노트가 어떤 클래스인지 명시. AI가 처리 패턴을 다르게 적용
• 흔한 값: note / meeting / terminology / people / curriculum / channel / manuscript / moc / CMDS

(b) description — 영어 1–2문장 LLM 힌트 ⭐ 가장 중요

원칙:

• 영어 (한국어 X)
• 1–2문장
• "스킬 설명" 스타일: 무엇 + 언제 참조해야 하는지
• 반드시 큰따옴표 "..." 로 감쌀 것 (안에 :  나  # 들어가면 YAML 파서 깨짐)

좋은 예시:

description: "Meeting minutes from 2026-04-07 LG AX camp retrospective. Contains CEO feedback summary and next-action items."

나쁜 예시:

description: "회의록입니다"        # 한국어 + 비기능
description: This is a note        # 큰따옴표 누락 → YAML 파서 위험

(c) date created / date modified

• ISO 8601 (YYYY-MM-DD)
• AI가 최신성으로 검색·소팅 가능 → "최신 글 10개만 학습해" 같은 명령 가능

(d) author — 배열 + 큰따옴표 wikilink

author:
  - "[[구요한]]"
  - "[[김진영]]"

3. CMDS 선택 프로퍼티

⚠️ CMDS: vs index: 방향 규칙 (자주 헷갈림)

4. 카멜케이스 규칙

• 복합어 필드는 카멜케이스: myRate, totalPage, startReadDate
• ⚠️ rating 사용 금지 → 반드시 myRate

5. 메타데이터가 결정적인 이유 — 사용자 사례 3가지

(a) "심평원이랑 1분기 했던 연구 다 가져와봐"

• 모든 연구 노트에 coworker, period, topic 메타가 있어야 가능
• 메타 없으면 본문 검색만 → 1만 노트면 사실상 불가

(b) writer 스킬 (publish=true 필터)

• 사용자가 발행한 글만 학습시키는 스킬
• frontmatter에 published: true 가 있어야 작동
• 새 글 추가될 때마다 자동으로 최신 학습 풀에 반영

(c) Claude Code "LG 관련 문서 정리해줘" → 1–2분 만에 연표

• 모든 미팅 노트의 attendees, date, organization 메타로 시기별 정렬
• 메타 없으면 Regex 검색 + 수동 분류로 1시간+ 소요

옵시디언의 장점 — 왜 3세대인가

세션 매핑: Session 1 2부 도입 — 옵시디언 vs 노션 vs 에버노트 · 한 문장: 노션의 AI 협력 가능성이 1이라면, 옵시디언은 100이다.

1. 노트 도구의 세대 구분

2. 옵시디언의 5대 장점

(1) 마크다운 + 로컬 파일 = 데이터 주권

• 모든 노트가 .md 파일로 내 컴퓨터에 저장
• 옵시디언이 사라져도 마크다운 에디터만 있으면 모든 데이터 그대로 사용 가능
• Vendor lock-in 없음. 미래 호환성 보장

(2) 위키링크 = 노트 간 연결을 1급 시민으로

• [[노트명]] 한 번이면 양방향 링크 자동 생성
• 한 노트를 수정하면 해당 노트를 참조하는 모든 노트가 자동 인지
• 결과: 뇌의 뉴럴 네트워크처럼 노트 그래프 형성

[[구광모]] 검색 → 미팅 노트 + 교육 이력 + 관련 인물 + 프로젝트 한 번에 surface

(3) 메타데이터 친화 = AI 활용의 결정적 차이

• frontmatter(YAML) 표준 지원
• 데이터뷰(Dataview) 플러그인으로 노트를 DB로 사용 가능
• AI에게 메타로 필터링 가능 ("publish=true인 글만 읽어")

(4) 플러그인 생태계 = 2,700+개 + 자체 제작 가능

• Import 플러그인: Notion / Evernote / Apple Note / Google Keep / OneNote / CSV → 마크다운 변환
• Dataview: 노트 쿼리 (DB 기능)
• Templater: 동적 템플릿 + 변수 자동 입력
• Excalidraw / Excalibrain: 시각적 사고
• Smart Connections: AI 기반 노트 연결
• Calendar / Chronology: 날짜 기반 탐색
• 본인 플러그인 직접 개발 가능 (사용자도 5개 직접 제작)

(5) 엔터프라이즈 무료 + 사내망 SYNC 가능

• 기존 유료 엔터프라이즈 요금제가 무료로 풀림
• 오픈소스는 아님. 단, 모든 데이터 로컬 → 보안은 사내 인프라가 결정
• 사내 클라우드 서버 + 자체 플러그인으로 사내망 전용 SYNC 구성 가능
• 단, 앱(.app)이 있어야 함. 웹 미지원

3. 노션과의 직접 비교 (AI 협업 관점)

4. 다른 도구와의 관계 — 안 버려도 됨

옵시디언이 모든 것을 대체해야 하는 게 아님. 역할 분리가 핵심:

• 노션 → 팀 매뉴얼·프로세스 공유는 노션 유지 OK
• PDF·논문 → Bookends(Mac) 또는 Zotero(Win)에 원문 보존, 옵시디언엔 메타+노트만
• 이미지 자산 → Eagle 등 자산 관리 툴
• 회의록 음성 → Plaud / Otter / Whisper로 전사 후 옵시디언으로 import
• 할 일 / 캘린더 → 별도 도구 + Obsidian Tasks 플러그인 연동

→ "옵시디언이 안 좋은 게 아니라, 모든 걸 한 도구로 하려는 게 안 좋은 것"

5. 코호트 1주차 학생용 진입 권장 순서

1. 클론: cmds-vault 클론 (Mac/Win, 한글 폴더명 회피) → G1 클론 가이드
2. 첫 노트: 00. Inbox/에 일자 노트 1개 작성 (마크다운 + frontmatter 7필드)
3. 위키링크: 다른 노트 1개에 [[]]로 연결
4. 그래프뷰: 그래프 한 번 보기 — 노드 2개 + 엣지 1개의 작은 시작
5. Daily Note: Calendar 플러그인 활성화 후 매일 일자 노트 1개 작성

→ "그래프뷰가 풍성해지는 데 평균 3개월". 첫 1–2주는 그냥 작성에만 집중.

다차원 분류 (Multi-dimension Classification)

세션 매핑: Session 1 1부 (4) — 폴더 vs 태그 vs 링크 vs 메타 · 한 문장: 하나의 파일은 하나의 폴더에만 살 수 없다.

1. 시작 비유: 원숭이·바나나·팬더

세 가지 사물을 두 그룹으로 분류하시오. 학생들에게 답을 시켜보면 보통 4–5가지 답이 나옴:

→ 모두 정답. 단지 어느 차원으로 자르느냐의 차이. 마찬가지로 하나의 노트가 하나의 폴더에만 살 수 없다.

2. 폴더의 한계 — 왜 폴더 한 개로는 부족한가

예시: 리더십 논문 1편

• 주제 분류: 리더십? 그런데 조직 문화도 다룸
• 방법론: 서베이 사용? 그런데 머신러닝 분석도 함
• 산출물: 저널 논문? 그런데 강의 자료로도 재활용

→ 어느 폴더에 넣어도 다른 분류에서 보면 잘못된 곳

폴더의 정당한 사용처

폴더는 서로 겹치지 않는(mutually exclusive) 분류에만:

• 00. Inbox/ (미정리) vs 30. Permanent Notes/ (정리 완료) — 시간/상태 기준
• 60. Collections/61. People/ vs 60. Collections/63. Meetings/ — 엔티티 종류 기준
• 40. Docs/41. Official Docs/ vs 40. Docs/46. My Docs/ — 출처 기준

3. 4가지 분류 도구 — 언제 무엇을 쓸 것인가

4. "정리되어 있지 않다 ≠ 정리 안 됨"

학생이 흔히 갖는 오해: 모든 노트가 깔끔한 폴더에 들어가 있어야 정리된 상태.

사실은:

• 스택 형태도 정리: "이번 분기 읽을 논문 30편" 스택 = 정리된 상태
• 인덱스 노트(MOC)도 정리: 큐레이션 노트 1개로 분산된 노트 모음
• 태그 클러스터도 정리: #book2026으로 묶인 모든 노트
• 그래프 군집도 정리: 위키링크로 자연스럽게 형성된 클러스터

→ 폴더에만 의존하면 분류 불안에 시달림. 다차원적으로 보면 어디든 정리된 상태.

5. CMDS의 다차원 매핑 — 실제 사례

한 노트 (예: 2026-04-15 LG 회장단 코칭 회의)는 다음 차원에 동시에 등장:

type: meeting                            # → 클래스
CMDS: "[[📚 909 Consulting & Advisory]]" # → 카테고리
index: "[[🏷 Meeting Notes]]"             # → 인덱스
attendees:
  - "[[구광모]]"
  - "[[권봉석]]"                         # → 인물 그래프
project: "[[LG-AX-임원교육-프로젝트]]"   # → 프로젝트
date: 2026-04-15                         # → 시간축
tags: [coaching, executive, lg, ax]      # → 횡단 주제

→ 폴더는 60. Collections/63. Meetings/2026-04-15-LG-회장단-코칭.md 단 한 곳. 하지만 6개 차원에서 동시 surface.

6. 강의 진행 큐 (5–7분 핸드아웃)

CMDS 시스템 구조 — 9 카테고리 + 8 시스템 파일

세션 매핑: Session 1 2부 (1)(2) — CMDS 9 카테고리 + 8 시스템 파일 라이브 투어

0. 강조: 학생은 CMDS를 그대로 따라할 필요 없음

• 9 카테고리는 구요한의 체계. 도서관 Decimal System을 모방
• 본 코호트는 체계 만드는 방법을 보여주는 게 목적, 이 체계를 강제하는 게 목적이 아님
• 학생 권장 경로: ① cmds-vault 그대로 시작 → ② 3–6개월 사용하며 자기 도메인 적응 → ③ 자기 버전 100–900 만들기

1. 9 카테고리 (100–900) 빠른 투어

2. CMDS Process — Connect → Merge → Develop → Share

CMDS는 분류 체계인 동시에 지식 흐름의 4단계 파이프라인:

🔗 Connect          🔀 Merge              🛠 Develop                📤 Share
(아이디어 발견)   →  (지식 통합)        →  (방법론·도구 적용)     →  (출판·교육·공유)
[100 Themes]        [200 Literature]      [300–600]                 [700 Creatives /
                                                                     800 Outputs]

단계별 질문:

• Connect: 무엇이 궁금한가? 어떤 용어를 알아야 하는가?
• Merge: 학자들은 뭐라 하나? 내 해석은?
• Develop: 어떤 데이터·방법·도구로 발전시킬까?
• Share: 누구에게 어떤 형식으로 공유할까?

→ CMDS Process는 마더십에서 8개 슬래시 커맨드로 자동화 (/connect, /merge, /develop, /share + /inbox, /lint, /query, /status)

3. 8 시스템 파일 — Audience 별 그룹

그룹 A: 🤖 LLM 코딩 에이전트 (always-loaded)

그룹 B: 🧪 Vendor-specific

그룹 C: 📚 Context & Standards (모든 agent가 참조)

그룹 D: 🧠 Gobi 페르소나 시스템 (Gobi 앱 전용)

4. 공개 vs 비공개 — system.cmdspace.work

8개 중 공개 가능한 5개 (그룹 A·C) 가 system.cmdspace.work에 배포:

• CLAUDE.md / AGENTS.md / CMDS.md / 🏛 CMDS Guide / 🏛 CMDS Head Quarter
• + .claude/rules/ 7개 공유 규칙
• + CMDS-System-Files.zip 번들

비공개 3개:

• ANTIGRAVITY.md (Gemini 전용 — vendor-specific)
• BRAIN.md / BRAIN_PROMPT.md (Gobi 페르소나 — product 전용)

→ 학생이 자기 버전을 만들 때는 CLAUDE.md / AGENTS.md / CMDS.md / Guide / HQ 5개로 시작 권장.

5. 학생 적응 가이드 — 자기 시스템 파일 만들기

1. 그대로 시작: cmds-vault 클론 → CLAUDE/AGENTS/CMDS/Guide/HQ 그대로. 처음엔 변경 X. 1–2주 사용하며 어디가 본인과 안 맞는지 관찰
2. CMDS.md 부분 수정: 100–900 카테고리 중 본인 도메인에 없는 것 제거, 없는 것 추가
3. BRAIN.md 작성 (Session 1 4부 실습으로 이어짐): Claude Code 온보딩 인터뷰로 본인 페르소나 캡처
4. 자기 버전 8 시스템 파일 정착: 6개월 사용 후, 안정된 본인 시스템으로 정립

AI 협업 환경 — Chat UI · API · CLI

세션 매핑: Session 1 3부 도입 — 왜 Claude Code를 쓰는가 · 한 문장: AI 사용 환경은 3 단계, 그중 PKM·볼트 작업의 정점은 CLI다.

1. 3 단계 비교

2. 1단계 — Chat UI (모두가 시작한 곳)

• 가장 사용성 높음. 90%의 사람이 여기서 시작
• 한국에서 ChatGPT가 압도적, Gemini·Claude·Grok 추격
• 이미지 첨부, 파일 1–2개 첨부 가능
• 한계: 볼트 1만 노트를 한 번에 컨텍스트로 줄 수 없음

3. 2단계 — API

• 서비스 ↔ AI 간 프로그램적 통신
• 처방전처럼 표준화된 요청·응답
• 일관된 결과, 자동화 가능
• 코딩 필요 (Python·JavaScript 등)

4. 3단계 — CLI ⭐ Claude Code

• 까만 화면에 흰 글씨 (MS-DOS 같은 터미널)
• 진입 곡선: 처음 무섭지만 3시간이면 적응
• 체급이 다름:
  • 내 컴퓨터의 모든 파일에 접근 가능
  • 볼트 전체를 컨텍스트로
  • 멀티스텝 추론 + 자기 계획 수립
  • 미리 만든 스킬 (서브 에이전트) 자동 호출
  • 여러 에이전트 병렬 실행

사용자 발언 인용

"CLI를 안 쓰는 AI 전문가는 가짜다."
"전 세계 AI를 극단적으로 쓰시는 분들은 다 이걸 쓰고 있다."

CLI에서만 가능한 작업

• "내 만 개 노트 다 읽고서, LG 관련 미팅을 시기별 연표로 정리해" — 1–2분
• "내 발행 글 publish=true 만 학습한 다음, 더베러 스타일로 글 한 편 써" — writer 스킬 자동 호출
• "이 PPT 읽고서 옵시디언 마크다운으로 변환해서 적절한 폴더에 저장해" — 파일 시스템 직접 조작
• "이 데이터 분석하고, 통계 돌리고, 결과 페이지 만들어" — Python·R 직접 실행

5. CLI 거부감 해소 — 비개발자를 위한 경로

옵션 A: Claudian 옵시디언 플러그인

• 옵시디언 UI 내에서 Claude Code 작동
• 윈도우 스위칭·터미널 진입 없이 사용
• 추천 대상: CLI 처음 진입, 옵시디언이 익숙해진 학생

옵션 B: Gobi Desktop

• GUI 기반 AI 비서
• 옵시디언 볼트 자동 인식
• 추천 대상: CLI 자체가 부담스러운 학생, 3주차 이후 본격 사용

옵션 C: Claude Code 직접

• 정통 경로. 익숙해지면 가장 강력
• macOS·WSL2 윈도우에서 가장 잘 작동

6. 5 모델 비교 — 어디에 무엇을 쓸 것인가

→ 사용자 구독 = 월 200만원 = 1인 인건비. 단, 100명 역할.

→ 학생 권장: 본 코호트 시작 시 Claude Code + ChatGPT 또는 Gemini 무료/저가 1개로 시작. 익숙해지면 전문성 영역에 맞춰 확장.

멀티볼트 컨셉 — mothership + satellite

세션 매핑: Session 1 5부 — 2주차 LLM Wiki 위성 볼트 추가 예정 사전 안내 · 한 문장: 한 볼트로 모든 걸 담을 수 없다.

1. 왜 한 볼트로 안 되는가

사용자(구요한)의 7-볼트 생태계 (2026-04 기준)

분리의 5가지 힘 (5 Forces)

새 볼트를 언제 만들어야 하는가의 결정 기준:

1. 주저자 분리 — 사람 vs LLM, 개인 vs 협업 (Contamination Mitigation)
2. 합의 모델 분리 — Solo / Pair / Team / Public 의 git·sync 충돌 방식이 다름
3. 수명 분리 — Permanent vs Project-bound vs Time-boxed
4. 도구 분리 — vault 별 plugin / hook / .claude/ 다를 수 있음
5. 검색 인덱스 분리 — qmd collection 단위로 분리 가능

2. Karpathy LLM Wiki 패턴

컨셉

• Andrej Karpathy의 LLM Wiki 아이디어: AI가 외부 자료를 ingest 하고 지속 가능한 위키를 컴파일
• 마더십과 분리하여 LLM 주저자의 위키만 담는 위성

3-Layer 구조

[Raw Sources]   →   [Wiki]          →   [Queries]
(immutable)         (LLM-maintained)    (synthesized)
원본 자료           정제된 wiki 페이지   대화/질의 결과

• Raw Sources: 외부 아티클·논문·전사본 (수정 불가)
• Wiki: LLM이 수집된 자료에서 합성한 재사용 가능한 위키 페이지
• Queries: 사용자가 LLM과 대화한 답변 — 위키 가치 있으면 wiki로 file back

3. 코호트 1기 권장 구조 — 단계적 도입

1주차 (5/2)

• 메인 볼트만: cmds-vault 클론 → 자기 컨텍스트로 채우기
• 멀티볼트 컨셉만 노출 (이 자산이 그 노출)

2주차 (5/9) ⭐ 위성 볼트 추가

• CMDS_LLM_Wiki 위성 볼트 추가 생성
• 메인은 PKM 작업본, 위성은 학습·연구 컴파일
• 분리 이유: AI가 만든 노트와 본인이 만든 노트를 섞지 않기 위해

3주차+ (선택)

• 팀 협업 볼트 (Pair / Team) — 본인 도메인이 협업 중심이면
• Personal Product 볼트 — Gobi Desktop 등 본격 사용 시

4. Anti-pattern — 새 볼트 만들지 말 것

다음은 새 볼트 만들지 말고 마더십 처리:

→ "새 볼트는 governance가 다를 때만. 단순 분류는 폴더·메타로." — 사용자

5. 학생용 멘탈 모델 — 단순화

학생이 처음 멀티볼트를 들으면 부담스러울 수 있음. 최소 모델:

[메인 볼트]                    [LLM Wiki 위성]
                               (2주차에 추가)
- 일상 PKM                  vs - 학습·연구·정리
- 회의·미팅·일기              - AI가 컴파일한 개념 위키
- 개인 산출물                  - Raw 자료 + Wiki 페이지
- 자기 손으로 작성             - LLM이 주저자

→ 헷갈리면? 일단 메인에 다 쌓고, 시간 지나서
   *LLM이 정리할 만한 것* 만 위성으로.