2026년 6월, 구글이 ‘AI가 읽는 지식’의 공개 표준 Open Knowledge Format(이하 OKF)을 발표했습니다. 새 기술처럼 보이지만, 그 정체를 뜯어보니 제가 PM 코치 10년 동안 굴려온 Obsidian Vault, 그리고 Andrej Karpathy가 제안한 llm-wiki와 정확히 같은 핏줄이었습니다.
결론부터 말씀드리면 — 셋은 경쟁자가 아니라 한 아이디어의 세 가지 구현이고, 일반인이 시작하는 데는 비싼 도구도 코딩도 필요 없습니다. 폴더 하나, 마크다운 파일, 머리말 한 줄이면 됩니다.
Karpathy 사고 체계 시리즈 K-7 · 시작 가이드편 — K-6 30시간 실측 벤치마크의 후속. 이번엔 “무엇을, 어디서, 어떻게 시작할까”에 답합니다.
① 2026년 6월, 구글이 ‘AI가 읽는 지식’의 공개 표준 Open Knowledge Format(OKF)을 v0.1로 내놨는데, 그 정체는 마크다운 + 머리말(frontmatter) + 링크라는 — 제가 10년 굴려온 Obsidian Vault, Karpathy의 llm-wiki와 똑같은 형식이었습니다.
② 셋은 경쟁자가 아니라 한 핏줄의 세 구현입니다 — Vault는 정밀·시각 탐색, llm-wiki는 대량·자동 생성, OKF는 교환·표준에 강합니다. 그리고 머리말의 각 항목(property)이 곧 AI 에이전트가 검색 증강 생성(RAG)으로 붙잡는 손잡이입니다.
③ 시작엔 비싼 도구도 코딩도 필요 없습니다 — 폴더 하나, 한 파일=한 개념, 머리말 type 한 줄, 링크, 그리고 index.md·log.md면 그 순간 OKF 호환입니다. 용도별 선택 가이드와 5단계 시작법을 끝에 붙였습니다.
“지식이 흩어져 있다”는 문제는, 사실 ‘AI가 못 읽는다’는 문제였습니다
“내 머릿속, 내 노트앱, 회사 위키, 공유 드라이브, 시니어의 기억 속에 지식이 다 흩어져 있다. 그런데 AI에게 일을 시키려면, 그 흩어진 지식을 매번 다시 긁어모아 붙여 넣어야 한다.”
— 에이전트에게 일을 맡겨본 사람이라면 누구나 부딪히는 벽
요즘 ‘AI가 똑똑하다’는 말은 절반만 맞습니다. AI는 자기가 받은 맥락(context)만큼만 똑똑합니다. 같은 모델이라도, 우리 회사 용어·과거 결정·표준 산출물을 알려주면 전문가처럼 답하고, 아무것도 안 주면 일반론만 늘어놓습니다.
그래서 작년부터 똑똑한 사람들이 같은 답에 도달했습니다 — “지식을 AI가 읽을 수 있는 형태로 정리해 두자.” 그 형태는 신기하게도 거의 똑같이 생겼습니다. 마크다운(markdown) 파일 + YAML 머리말(frontmatter) + 파일끼리 거는 링크. Obsidian Vault, AGENTS.md, llms.txt가 모두 이 모양이었죠.
구글은 2026년 6월, 이 제각각의 관행에 이름과 규격을 붙였습니다. 그것이 Open Knowledge Format(OKF)입니다. 구글의 표현을 그대로 옮기면 OKF는 “llm-wiki 패턴을 이식 가능하고 상호운용되는 형식으로 공식화한 것”입니다.
- 셋은 무엇이 같고 무엇이 다른가 — OKF · Obsidian Vault · llm-wiki의 목적과 장단점
- 실제로 어떻게 맞물리나 — 제가 PM 컨설팅에 쓰는 ‘Sillok 하네스’ 3층 구조에서 셋이 하는 역할
- 일반인은 어디서 시작하나 — 용도별 선택 가이드 + 오늘 당장 시작하는 5단계
세 가지는 경쟁자가 아니라, 같은 아이디어의 세 얼굴입니다
먼저 셋이 각각 무엇인지부터 정리하겠습니다. 핵심만 보면 놀라울 만큼 닮았습니다.
Obsidian Vault
개인이 손수 가꾸는 마크다운 지식 정원입니다. 한 노트 = 한 아이디어로 쪼개고(Zettelkasten), [[위키링크]]로 엮어 머릿속 지도를 만듭니다. 앱이 그래프·검색·플러그인을 얹어 줍니다.
llm-wiki
AI 연구자 Andrej Karpathy가 제안한 패턴입니다. 흩어진 대량 원본을 AI가 훑어 위키 페이지로 정리하되, 사람이 명시적으로 시킬 때만 갱신하고 모든 변경을 log.md에 남깁니다.
Open Knowledge Format
구글이 2026년 6월 공개한 벤더 중립 공개 표준(v0.1)입니다. 위와 똑같은 모양에 최소한의 약속만 더해, 한 사람이 만든 지식을 다른 사람의 AI가 번역 없이 읽게 합니다.
눈치채셨나요? 저장 형식이 셋 다 똑같습니다 — 마크다운 + YAML 머리말 + 파일 링크. 그래서 구글도 OKF를 “새 발명”이 아니라 “이미 여기저기서 반복 출현하던 패턴(Obsidian Vault, AGENTS.md, llms.txt)의 공식화”라고 설명합니다.
요즘 자주 들리는 비슷한 이름들의 역할을, 구글은 ‘도서관’에 빗대 깔끔하게 정리했습니다.
- llms.txt = 건물 앞 안내판 (여기 무엇이 있는지 알리는 한 장)
- OKF = 그 안의 서가(도서관) 자체 (지식이 실제로 꽂혀 있는 곳)
- Model Context Protocol(MCP) = 요청하면 책을 꺼내다 주는 사서
- AGENTS.md / CLAUDE.md = 에이전트에게 “이 방에선 이렇게 행동하라”고 알려주는 행동 지침 (지식 자체가 아니라 규칙)
→ 즉 OKF는 다른 표준을 대체하지 않고, ‘읽을 지식의 본체’를 담당합니다.
같은 형식, 다른 목적 — 한 표로 보는 셋의 차이
형식은 같아도 “누구를 위해, 무엇을 하려고 만들었나”가 다릅니다. 그 차이가 곧 선택의 기준입니다.
표의 넷째 줄을 다시 보십시오. 저장 형식이 완전히 같습니다. 그래서 한쪽에서 만든 지식을 다른 쪽으로 옮기는 비용이 거의 0에 가깝습니다. 진짜 차이는 딱 두 군데 — 연결 방식(위키링크 vs 표준 마크다운 링크)과 운영 철학(사람이 키우나 / AI가 짓나 / 표준으로 교환하나)입니다.
OKF가 강제하는 건 딱 하나, 모든 파일의 머리말에 type 한 줄입니다. 권장 필드는 title · description · resource · tags · timestamp 다섯 개뿐이고, 압축 규격도·런타임도·전용 SDK도 없습니다. 구글의 말 그대로 “그냥 마크다운, 그냥 파일, 그냥 YAML”입니다. 전체 규격이 한 페이지에 담깁니다. 진입 문턱이 낮다는 것이 이 표준의 가장 큰 무기입니다.
유용성으로 다시 보기 — ‘이 차이가 쓸모가 되는 순간’
앞 표가 ‘무엇이 다른가’였다면, 아래는 ‘그 차이가 언제 쓸모가 되는가’입니다. 한 줄을 가로로 읽으면 셋의 유용성을 한눈에, 맨 오른쪽 용도 칸을 보면 ‘나는 어느 쪽이 필요한가’를 바로 가를 수 있습니다.
📌 핵심: 세 가지는 ‘유용성의 봉우리’가 서로 다릅니다 — Vault는 정밀·시각 탐색, llm-wiki는 대량·자동, OKF는 교환·표준. 그래서 고르는 게 아니라 필요한 봉우리부터 오르고, 형식이 같으니 나중에 이어 붙이는 것이 정답입니다.
이 ‘property’가 곧 AI의 손잡이입니다 — RAG가 잘 잡게 만드는 머리말
여기까지가 큰 그림이라면, 이제 실무의 핵심으로 한 칸 들어가 보겠습니다. 세 체계가 공유하는 YAML 머리말(frontmatter)의 각 항목(property)이 바로, AI 에이전트가 검색 증강 생성(RAG)으로 우리 지식을 끌어올 때 붙잡는 손잡이입니다. 손잡이가 많고 일관될수록, Claude Code·Codex·Antigravity 같은 도구가 더 정확히·더 적은 토큰으로 회수합니다.
제가 실제로 쓰는 Vault 노트 한 장의 머리말을 그대로 펼쳐 보겠습니다 (삼성전자 GlobalPM 강의 세션 색인 노트).
---
title: 20241112-samsung-global-pm
type: external-index # 문서 종류 → 에이전트 라우팅·필터
status: active # 폐기·초안 제외
topic: pm-practice # 분류축(대)
subtopic: session-index # 분류축(소)
tags: [PM] # 패싯 태그
related: # 관계 링크 → 그래프 확장(multi-hop)
- "[[20241007-samsung-global-pm]]"
- "[[samsung-quality-pmc-202201]]"
- "[[AT-2026-samsung-gauss-pmbasedpmbok8core-vo1]]"
# …(외 9건)
source-system: onedrive-lecture # 원본 위치(provenance)
source-path: "[FullyActiveLearning]/20241112 삼성전자 GlobalPM(PMC)"
client: samsung # 도메인 좌표
client_ref: "[[CL-삼성전자]]" # 정본 고객 프로필 역참조
client_slug: samsung
industry: electronics # 산업 스코프
program: global-pm
session-date: "20241112" # 시간축 → 최신성 가중
token_count: 220 # ⑧ 검색 전용 신호 ↓ (랭킹·토큰 예산·티어링)
extraction_method: manual
retrieval_tier: D
quality_score: 1.0
---겉보기엔 그냥 메타데이터 같지만, 한 줄 한 줄이 검색의 ‘필터·정렬·연결·인용’ 레버입니다. 특히 맨 아래 네 줄(token_count·extraction_method·retrieval_tier·quality_score)은 OKF·llm-wiki엔 없는 검색 전용 신호로, RAG 랭킹을 직접 끌어올립니다. 같은 항목을 세 체계가 어떻게 두고, 그게 RAG에서 왜 쓸모인지 묶어 보겠습니다.
OKF는 8개 역할군 중 핵심만(type + 권장 5개) 일부러 표준화했습니다. 누구나 따르기 쉬워 ‘교환·호환’에 강하죠. 반대로 제 Vault는 ④분류축과 ⑧검색 전용 신호까지 빼곡히 채워 ‘검색 정밀도’를 끌어올립니다. 둘은 충돌이 아니라 분업입니다 — 호환은 OKF 최소 세트로, 정밀도는 Vault 확장 필드로. OKF 머리말을 ‘뼈대’로 두고, 내 검색용 필드를 ‘살’로 더하면 둘 다 가집니다.
정리하면, 에이전트가 RAG로 우리 지식을 참고하는 순간 머리말 항목들은 이렇게 일을 합니다 — 필터 술어(③④로 후보 좁히기) → 랭킹 신호(⑦⑧로 순위) → 그래프 간선(⑤로 이웃 근거 확장) → 인용 앵커(⑥으로 원본 되짚기) → 임베딩 보강(②로 벡터 품질). 그래서 ‘property를 잘 적어 두는 일’이 곧 ‘AI가 내 지식을 잘 쓰게 만드는 일’입니다.
📌 핵심: property는 장식이 아니라 AI가 잡을 손잡이입니다. OKF의 진짜 기여는 그 손잡이에 ‘공용 규격’을 붙인 것 — 그래서 내가 만든 손잡이를 남의 에이전트도 똑같이 잡을 수 있게 됐습니다.
제 컨설팅 하네스는, 이미 OKF가 말하는 그 패턴을 굴리고 있었습니다
저는 PM 컨설팅 작업을 ‘Sillok 하네스’라 부르는 개인 운영 체계 위에서 합니다. 그 안에 지식을 보관하는 층이 정확히 세 겹인데, 공교롭게도 OKF가 가리키는 구조와 똑같았습니다.
llm-wiki 폴더를 열어 보니 뿌리에 index.md와 log.md가 이미 놓여 있었습니다. 그런데 이 두 파일이 바로 OKF가 ‘예약 파일’로 지정한 그 두 개였습니다. 표준이 나오기 전에 같은 결론에 도달해 있었던 셈입니다. Karpathy의 패턴을 따랐을 뿐인데, 구글이 같은 패턴을 표준화하니 자연히 호환된 것이죠.
지난 4월, 저는 이 두 시스템을 정면으로 붙여 봤습니다. 10년치 강의·프로젝트 원본 약 2만 9천 파일을 AI로 추출해 llm-wiki를 만들고, 손수 가꿔온 Vault와 6개 실무 질문으로 양방향 채점을 돌렸습니다.
결과는 Vault 72 : llm-wiki 70. 큐레이션한 Vault가 깊이·정밀도에서 앞섰지만 — llm-wiki는 Vault에 아예 없던 개념 2건을 찾아냈습니다. ‘사람이 가꾼 정원’은 정밀하고, ‘AI가 훑은 위키’는 빈틈을 드러냅니다. 둘은 우열이 아니라 상호 보완이었습니다.
— K-6 「30시간 RAG 실측 회고」 중에서
그래서 OKF를 보는 제 입장은 이렇습니다. “새로 갈아엎을 것이 아니라, 이미 가진 것을 더 멀리 보낼 수 있게 되었다.” 제 Vault와 llm-wiki는 이미 90%가 OKF 모양입니다. 남은 차이는 링크 표기([[위키링크]] → [표준 링크](/경로.md)) 정도라서, 그것만 바꾸면 제 지식을 남의 AI도 번역 없이 읽을 수 있게 됩니다. 개인의 지식이 ‘교환 가능한 자산’이 되는 길목이 열린 것입니다.
참고로 구글은 OKF를 그냥 종이 규격으로만 내지 않았습니다. 표준 문서, 데이터베이스를 훑어 OKF 문서를 자동으로 써 주는 ‘생산자’ 에이전트, OKF 묶음을 인터랙티브 그래프로 보여 주는 ‘소비자’ HTML 도구, 그리고 예제 묶음(전자상거래·Stack Overflow·Bitcoin 공개 데이터)까지 함께 공개했습니다. 직접 만져 보며 배울 수 있다는 뜻입니다.
그래서 나는 무엇부터? — 상황별 한 장 선택 가이드
셋을 다 할 필요는 없습니다. 지금 내 상황이 어디에 가까운지로 출발점을 정하면 됩니다.
셋의 저장 형식이 같으므로, Obsidian으로 시작했다가 OKF 규격에 맞추는 일은 거의 비용이 들지 않습니다. 출발점만 고르고, 자라면서 갈아타면 됩니다. 잘못된 선택이라는 게 없는 구조예요.
오늘 당장, 코딩 없이 시작하는 5단계
거창한 준비는 필요 없습니다. 아래 다섯 걸음이면 ‘내 AI 전용 지식 서가’의 디딤돌이 놓입니다.
- 완벽한 분류 체계부터 만들려 하지 마세요. 빈 폴더 구조만 그리다 지칩니다. 개념 하나 쓰고, 링크 하나 거는 게 먼저입니다.
- AI에게 ‘전부 자동으로 정리해’라고 맡기지 마세요. Karpathy 패턴의 핵심 규율은 ‘자동 갱신 금지, 사람이 시킬 때만’입니다. 무차별 자동화는 잡음과 환각을 부릅니다.
- 도구부터 고르느라 시작을 미루지 마세요. 형식이 같으니 도구는 나중에 갈아타도 됩니다. 오늘은 폴더와 파일이면 충분합니다.
지식을 ‘AI가 읽는 형태’로 두는 습관이, 곧 경쟁력입니다
구글이 OKF를 내놓은 진짜 신호는 ‘새 포맷의 등장’이 아닙니다. “흩어진 지식을 AI가 읽을 수 있게 정리하는 일”이 이제 개인과 조직의 기본기가 되었다는 선언입니다. 그리고 그 기본기는 비싼 솔루션이 아니라 — 한 파일 = 한 개념, 머리말 한 줄, 링크 하나라는 작은 습관에서 시작합니다.
저처럼 10년치 자산을 가진 사람이든, 오늘 첫 노트를 쓰는 분이든 출발선은 같습니다. 형식이 같으니까요. 중요한 건 지금 한 줄을 적는 것입니다.
- 오늘: 폴더 하나 + 개념 노트 1개 (머리말
type:한 줄) - 이번 주: 노트 10개 + 서로 링크 걸기 +
index.md목차 - 한 달 뒤: AI에게 폴더째 물려 질문 → 답의 품질 차이를 직접 체감
- 분기 뒤: 링크 표기를 표준 마크다운으로 정리 → ‘OKF 호환’ 서가 완성
📚 더 깊이 보고 싶다면 — 같은 시리즈의 K-6 「30시간 RAG 실측 회고」에서 Vault와 llm-wiki의 6쿼리 벤치마크 전 과정을, K-1 「PM의 온톨로지맵」에서 10년 자산을 ‘AI가 읽는 지식망’으로 바꾼 방법론을 보실 수 있습니다.
- Google Cloud Blog — How the Open Knowledge Format can improve data sharing (2026-06, OKF v0.1 공식 발표)
- OKF 규격 원문 — GoogleCloudPlatform/knowledge-catalog · okf/SPEC.md (필수 필드·예약 파일·적합성 기준)
- Andrej Karpathy — llm-wiki gist (원형 패턴)
- 프로젝트리서치 — K-6 llm-wiki vs obsidian-vault 30시간 실측 벤치마크 (Vault 72 : llm-wiki 70, 자체 실험)
이 글은 PM 코치 10년 동안 1만 5천여 노트 규모의 Obsidian Vault와 llm-wiki를 직접 운영하며 얻은 경험을 바탕으로 작성되었습니다.
관련 글 — Karpathy 사고 체계 시리즈
- 📘 K-1: Agentic 시대, PM의 온톨로지맵 — Obsidian으로 나만의 RAG 만들기 (2026-03-23) — 10년치 PM 자산을 ‘AI가 읽는 지식망’으로 바꾸는 4단계 전환법. 검색 시간 30분→3초(600배)를 정량 제시한 vault 측 출발점.
- 📗 K-2: Karpathy의 LLM과 Obsidian 지식 결합 — Governed Autonomy의 실전 (2026-04-04) — Karpathy 3계층(Raw/Wiki/Schema)을 vault에 적용해 4~9배 자동화·436 atom 자동 추출을 측정한 llm-wiki 측 출발점.
- 📕 K-6: Karpathy의 llm-wiki는 내 10년 obsidian-vault를 이길 수 있었나 — 30시간 RAG 실측 (2026-04-18) — 6쿼리 양방향 벤치마크 Vault 72 : llm-wiki 70. 본 글이 인용한 비교의 데이터 토대.
- 📙 K-7: 본 글 (2026-06-21) — 구글 Open Knowledge Format 등장으로 다시 본 세 체계 비교 + property·RAG 유용성 + 일반인 5단계 시작 가이드.
함께 보면 좋은 글 — 클라우드를 하나로 합쳤더니 일하는 환경이 사라졌습니다 (OneDrive 단일화 × Agentic 환경)
「Karpathy의 LLM과 Obsidian 지식 결합」
「llm-wiki vs 10년 obsidian-vault — 30시간 RAG 실측 회고」
「RAG 지식관리와 PM — PO·PM·PL의 조직 자산화」
「Fable 5 첫 하루 — 모델 × 하네스 × RAG」
「내 노트 4만 개 검색 — 직접 읽기 vs 전용 CLI, 하이브리드 5.5배」
「Obsidian 노트를 앱 없이 검색 — 오픈소스 byeori(벼리)」
- M-1 Agentic PM 시리즈 진입 가이드 — 전체를 한 장으로
- Z-1 실록(Sillok) — 5세기 Audit-Grade 거버넌스를 LLM 운영에 빌려온 한국형 LLMOS 하네스
- Z-2 실록(Sillok) 2026 상반기 결산 — RAG·고객사·지능화 루프·오픈소스
- Z-3 하네스×RAG 기업 컨설팅 — 네 현장·환각 방지·TOP10 자가진단·진화 루프
- Z-4 하네스 엔지니어링 백서 — Weng 하네스론×실록 구조 매핑·자기개선 루프·정직한 결산
- Z-5 에이전트 스킬 수명주기 백서 — Dynamic Agent Skills 8단×실록 매핑(7 온전+1 갭)·분기 12문항 레퍼런스·PO/PM/PL 컨설팅 직역
- K-1 Agentic 시대, PM의 온톨로지맵 — Obsidian을 통해 나만의 RAG를 만드는 법
- K-2 Karpathy의 LLM과 Obsidian 지식 결합
- K-3 Karpathy의 autoresearch: PM에서의 적용 사례
- K-5 Karpathy LLM OS 시각으로 본 AX PM/PL 역량 — Claude Code 소스 교차 분석
- K-6 30시간 RAG 실측 — Karpathy llm-wiki vs obsidian-vault 양강 비교
- K-7 구글 OKF·Obsidian Vault·llm-wiki — 무엇을 어떻게 시작할까
- K-8 Obsidian × LLM 4만 노트 — 개인 RAG 최종 아키텍처 5층
- K-9 PM 온톨로지맵 템플릿 배포판 — 30분에 채우는 5칸
- P-0 7인의 사고 체계 종합 프레임워크
- P-1 Karpathy: 제약 설계 + 닫힌 루프
- P-2 Sutskever: 압축이 곧 지능이다
- P-3 Hassabis: 제1원리 분해
- P-4 LeCun: 세계 모델 + 예측
- P-5 Hinton: 거버넌스 + 자기부정
- P-6 Ng: AI 전환 플레이북
- P-7 Fei-Fei Li: 인간중심 설계
- P-8 Builders 종합: Boris·Cat·Truell·Masad·Murati·Brockman
- P-9 Operators 종합: Altman·Amodei·Nadella·Pichai·Zuckerberg·Suleyman
- P-10 Hardware 양강: Jensen Huang · Lisa Su
- P-11 DeepSeek 량원펑 — 연속 학습의 공백과 하네스
- X-1 AI/AX 2030 전략: McKinsey, BCG, Accenture, Deloitte, Gartner 교차 분석
- X-2 빅테크 리더십 격변과 AX 전략
- X-3 2026년 GitHub에서 주목할 프로젝트와 AI 전환 신호
- X-4 AI 에이전트 2026 상반기 대해부 — 지금 무슨 일이, 리더는 무엇을
- W-1 Agentic 월간 관전포인트 2026-05 — 가우스+빅테크 듀얼 모델 시대
- W-2 Agentic 2026 상반기 총결산 — 다섯 축 6개월
- E-1 AI 네이티브 기업 전환 — CHO·PMO 재정의
- E-2 한국 기업 AX 2030 (Capstone)
- E-3 NH농협은행 SAFe 애자일 3년 — 페이스메이킹의 기록
- E-4 하나은행 × BCG 애자일 전환 — 두 개의 리듬으로
- E-5 네이버랩스 AKI — 하이브리드 애자일 PMO로 7개 제품을 한 박자로
- S-1 Agentic PM의 시대가 열리다 — LG전자 SW PM 워크숍을 마치며
- S-2 삼성전자 PMC: AI와 함께하는 PM 교육 혁신
- S-3 SKT Agent 도출을 위한 AI 퍼실리테이션 기법
- S-4 리스크는 그릇이었다 — LG전자 SW공학연구소 GenAI RISK 워크숍
- S-5 코드 한 줄 없이 손익관리팀이 만든 에이전트 — 신한EZ손해보험
- S-6 “어디까지 입력해도 되나요?” — 삼성 구매 현장의 Agentic 각성
- S-7 지금 Agentic으로 전환해야 하는 이유 — 삼성·LG·KT·Clean&Science 300여 분의 증명
- S-8 ‘바이브 프로젝트 매니징’을 스스로 이름 붙였습니다 — 현대모비스 편
- S-9 “대충 시키면 다 해줄 줄 알았는데” — SK쉴더스 보안 PM들의 이틀
- S-10 휴맥스 전사 ALM 정착 — 표준 4개를 codeBeamer 하나에
- S-11 AI로 신약 프로젝트 관리 — KDRA 바이오 PM 3일 워크숍
- S-12 AI 바이오·제약 회사는 무엇부터 자동화해야 하는가 — 26주 실측
- S-13 에이전트를 어디까지 붙일 것인가 — 되돌릴 수 없는 일 먼저 NEW
- S-14 같은 기준, 다른 답 — 22개 업무 유형의 사람 확정 지점 NEW
- S-15 가장 무거운 일은 전문 업무가 아니었다 — 에이전트 10종 NEW
- G-1 삼성전자 GAUSS PM Agent: 효과적 설계로 주니어 PM 지원하기
- G-2 주니어 PM 위한 AI 하네스 구축 가이드
- G-4 삼성 DX 엔지니어를 위한 Codex 온보딩 — 하네스 & 개인 RAG
- G-5 나의 Agent 비서, 블록 12개로 조립한다 — 재사용 블록과 77%의 법칙
- G-6 내 업무를 맡길 AI 에이전트 — 6블록 설계와 PROFILE BIND
- CC-6 사내 지식을 RAG로 — 망분리·토큰0 6단계
- CC-4 내 노트 4만 개 검색 — LLM 직접 읽기 vs 전용 CLI, 하이브리드 5.5배
- CC-5 Obsidian 노트를 앱 없이 검색 — 오픈소스 byeori(벼리)
- A-5 Fable 5와 보낸 첫 하루 — 모델 × 하네스 × RAG 실측 회고
- A-8 좋은 엔진은 없다, 맞는 엔진이 있다 — Codex/Sol vs Claude/Fable 5대 실전 비교
- CC-3 Opus xhigh 솔로 vs ultracode 멀티에이전트 — 작업유형별 A/B 실측
- A-6 맥은 이미 AI 워크스테이션 — 사진·노트·인박스 0원 정리
- A-7 Mac@Work 2026 — 맥 20년차의 도구 모음과 Agentic 카테고리
- G-3 대기업 직장인을 위한 AI Agent & Skill 추천 가이드 2026
- G-7 녹취 엔진 두 레인 — SpeechAnalyzer와 Alt, 코칭·컨설팅 6장면 판단표