옵시디언 국내 최고 권위자가 녹음 1,400개와 노트 1만 개를 AI로 굴리는 방법 (커맨드스페이스 구요한님)

한 줄 요약

옵시디언 전도사로 활동하는 커맨드스페이스 구요한님이 녹음 1,400개와 노트 1만 개를 AI가 읽을 수 있는 지식 체계로 어떻게 설계했는지 보여 줘요. 목차·메타데이터·번호 체계를 사람이 먼저 잡아 두니 에이전트가 그 위에서 분류와 연결을 대신 맡게 됐다는 이야기입니다.

전체 내용 정리

옵시디언을 만난 지 2주 만에 강의를 잡아 버렸어요

조쉬가 이번에 초대한 손님은 커맨드스페이스를 운영하는 구요한님이에요. 스스로를 옵시디언 전도사라고 소개하는데요. 박사 전공은 교육공학, 석사는 물리였다고 해요. 이공계와 인문사회를 오가며 지식을 관리하고 논문을 쓰다 보니 그걸 도와줄 도구를 계속 찾게 됐다고 합니다.

지금 메인 비즈니스는 AI와 지식 관리 강의·컨설팅이에요. 대학에서 겸임교수로 AI를 가르치고 국가과학기술인력개발원에도 교수로 소속돼 있습니다. 여기에 재즈 보컬리스트로 무대에도 서죠. 조쉬가 회사 대표에 교수에 재즈 뮤지션까지 해낸다며 감탄할 만큼 페르소나가 많아요.

강의할 때 늘 하는 말이 두 가지 있다고 해요. 하나는 "질문은 언제나 환영이야", 다른 하나는 "2주 뒤에 뵙겠습니다"예요. 모르는 걸 누가 물어보면 2주 동안 공부해서 인사이트를 줄 수 있는 사람이 되어 오겠다는 마음가짐이거든요.

옵시디언도 그렇게 시작했어요. 2022년 5월에 노션을 비롯한 여러 도구를 비교하다가 처음 써 봤는데 너무 신기한 경험이었다고 해요. 그래서 처음 만난 날로부터 2주 뒤에 온라인 세미나를 잡아 버렸습니다.

옵시디언을 고른 가장 큰 이유는 마크다운이었어요. txt 파일이 어느 컴퓨터에서나 열리듯 마크다운도 운영체제와 상관없이 어떤 뷰어로든 열리는 범용 데이터라는 점이 마음에 들었다고 해요. 데이터가 내 로컬에 남는다는 점도 컸어요. "내 데이터를 내가 가지고 있는 것도 되게 중요하겠다"는 생각이었죠. 옵시디언이 오픈소스는 아니지만 서드파티 플러그인 생태계가 활발해서 나도 시간을 써서 개발해 보면 재밌겠다는 마음도 들었다고 합니다.

그런데 이 선택이 나중에 생각보다 크게 맞아떨어졌어요. 클로드 코드(Claude Code, 터미널에서 돌아가는 AI 에이전트)가 나오면서 마크다운이 곧 에이전트가 다루는 재료가 됐거든요. 돌아보니 볼트(vault, 옵시디언의 노트 저장소)에 쌓인 만 몇천 개의 파일을 그대로 자기 메모리로 쓰고 있었다는 걸 깨달았다고 해요.

설계 문서 두 장이 1만 개 노트의 뼈대가 됐어요

구요한님은 어떻게 쓰느냐보다 내 지식 관리 시스템의 체계를 내가 이해하고 있느냐가 먼저라고 강조해요. 그래서 처음에 설계에 시간을 많이 들였고 문서 두 개를 만들었어요. 첫 번째는 헤드쿼터라는 이름의 목차 체계예요. 연구자답게 1장, 2장처럼 지식 영역을 나누고 각 영역에서 무엇을 맡고 무엇을 배워서 만들고 싶은지 적어 뒀죠.

조쉬가 이게 지식으로 들어가는 통로냐고 묻자 구요한님은 유일한 통로는 아니라고 답해요. 누군가를 떠올릴 때도 스레드 계정이 생각날 수 있고 함께 밥 먹은 자리나 그날 날짜가 생각날 수도 있잖아요. 지식에 다다르는 길을 여러 갈래로 열어 두는 게 중요하고 옵시디언의 가장 큰 장점이 그 루트를 내가 설계할 수 있다는 것이라고 봅니다.

이걸 설명하려고 아날로그 수첩 비유를 들어요. 수첩 36페이지에 메모했다면 연결될 수 있는 건 앞뒤인 35, 37페이지뿐이죠. 디지털에서는 옆에 붙어 있지 않아도 같은 종류라고 선언하거나 같은 폴더에 넣거나 같은 태그를 달면 연결이 됩니다.

그래서 두 번째 문서에는 메타데이터 규칙을 정리했어요. 반드시 들어가야 할 메타데이터, ISO 형식으로 정한 날짜 필드, 평점처럼 숫자나 텍스트가 들어가는 필드까지 예시를 미리 써 뒀다고 해요. 나중에 일관성 있게 노트를 쓰려고요. 노트가 연구용인지 프로젝트용인지 강의용인지 일기인지도 태그로 구분하고 폴더 구조와 접두어·접미어 규칙도 차츰 늘려 왔습니다.

번호 체계도 눈여겨볼 만해요. 도서관에서 쓰는 십진분류법(DDC, Dewey Decimal Classification)을 빌려 와서 앞자리 하나와 뒷자리 두 개로 번호를 매겨요. 600번대라면 601부터 699까지 들어가는 식이죠. 그래서 아무것도 기억나지 않아도 901을 치면 케플러, 곧 볼트 전체를 관장하는 1번 페르소나가 떠오르게 돼요. 숫자와 지식을 짝지어 두는 것만으로 길이 하나 더 생기는 셈이에요.

물론 순탄하기만 했던 건 아니에요. 체계를 넓히려고 새 항목을 계속 만들다 보니 본인도 다 기억하지 못할 만큼 많아진 암흑기가 한 번 있었다고 해요. 지금은 분류를 에이전트가 맡아요. 조쉬 인터뷰 질문지 검토본에도 에이전트가 알아서 701 유튜브 번호를 달아 버렸거든요.

이 두 문서는 처음엔 자기를 위한 가이드였다가 강의용 설명서가 됐고 지금은 AI를 위한 설명서가 됐어요. CLAUDE.md, AGENTS.md 같은 AI용 시스템 파일과 사람용 문서 두 개를 모두 공개해 뒀고 설계 원리도 함께 정리해 뒀다고 해요. 이렇게까지 정리할 필요가 있느냐는 질문에는 정리해 두면 그 지식 토대 위에서 마음껏 놀 수 있다는 게 가장 큰 가치라고 답합니다.

처음 시작하는 사람에게는 어떻게 권할까요? AI가 없던 시절에는 내가 인지할 수 있는 최소한의 요소만 쓰라고 했는데 지금은 다르다고 해요. 공개된 시스템 볼트를 가져가서 경로로 참조시키고 내 버전으로 만들어 달라고 하면 된다는 거예요. 직접 잡는다면 연구·프로젝트·강의처럼 내가 하는 일의 종류(클래스)와 데이터 분석·컨설팅·자녀 교육 같은 주제(토픽) 정도만 나눠서 시작하길 권해요. 단순한 메모장 수준이라도 내 데이터가 남는 것만으로 옵시디언의 가치는 충분하다고 덧붙입니다.

메인 볼트와 LLM 위키 볼트는 저자가 달라요

구요한님의 모든 데이터는 옵시디언을 거쳐 가요. 그렇다고 최종 산출물까지 옵시디언에 두지는 않아요. PPT나 PDF로 나갈 건 그 형식으로 만들고 마크다운 기획 문서와 전체를 오케스트레이션하는 문서만 볼트에 남겨요.

기획 문서에는 바깥 폴더를 가리키는 연결이 걸려 있어요. 폴더 연결 도구로 옵시디언과 상관없는 개발 폴더, 강의 자산 폴더를 이어 두고 개발 프로젝트는 저 폴더에서 보라고, 계약서나 성과 보고서는 실제 프로젝트 폴더에 넣으라고 가리켜 두는 식이죠. 옵시디언에서 마크다운을 관리하고 그걸 기반으로 한 결과물은 밖으로 내보내는 구조라 운영 비서 같은 느낌도 있다고 해요.

사례로 이번 인터뷰 준비 과정을 보여 줘요. 조쉬가 보낸 질문지 원본이 프로젝트에 그대로 들어가 있고 조쉬 채널 조사, 질문지 검토, 오류 정정, 응답 초안까지 이어져 있어요. 조쉬가 수치가 틀렸을 수 있으니 이상하면 말해 달라고 했던 걸 감안해 검토도 했다고 하죠. 이 문서들은 가장 빨리 열리게 하려고 직접 만든 마크다운 뷰어 앱으로 보여 줍니다.

최근엔 어떤 모델이 이 문서를 만들었는지도 적고 있어요. 나중에 다시 읽고 마음에 든 점과 안 든 점을 모델에게 피드백하려면 누가 했는지 알아야 한다는 이유예요. 이 메인 볼트는 구요한님이 승인하고 지시하는 볼트예요. 반대로 LLM 위키 볼트는 AI가 더 주도적으로 움직이고 구요한님은 관리·감독을 맡아요.

둘을 나눈 이유가 재밌어요. 구요한님은 "저자가 다르다고 생각을 했어요"라고 말해요. 메인 볼트의 저자는 구요한 본인이고 LLM 위키의 저자는 LLM이라는 거죠. 메인 볼트에는 눈 감고도 이야기할 수 있는 내용이 담기고 위키 볼트에는 아직 명확히 설명하지는 못해도 관심을 두고 공부 중인 지식이 쌓여요. 메인 볼트를 모선(마더십)으로 두고 위키 볼트, 팀원과 함께 쓰는 볼트, 수강생과 함께하는 볼트가 위성처럼 둘러싼 구조라고 설명합니다.

조쉬는 이렇게 로컬에 쌓인 파일을 불러오는 방식이 RAG(검색 증강 생성)와 어떻게 다른지, 왜 컴파일하는 위키라고 부르는지 물어요. 구요한님은 RAG가 여전히 탁월한 방법이라고 인정해요. 다만 벡터 DB나 그래프 DB를 만들어 올리는 데 시간이 들고 내용이 바뀔 때마다 다시 넣고 갱신해야 하죠. 규모가 크고 출처가 분명해야 하는 지식이나 고객 응대 매뉴얼처럼 정해진 루틴을 따르는 일에는 RAG가 훨씬 낫다고 봐요.

반면 업데이트가 잦고 그걸로 뭔가를 설계해야 하는 지식은 한 번 물어본 게 다음 질문에 반영되지 않는 한계가 있다고 해요. 그래서 원한 건 지식이 복리처럼 쌓이는 구조였어요. 컨텍스트 윈도우가 100만 수준까지 커지면서 예전엔 안 되던 게 가능해졌고요. 구요한님은 컴파일을 내용을 보기 쉽게 다시 정리해 넣는 전처리 작업으로 생각하면 된다고 설명해요.

작동 방식은 이래요. 어떤 아티클에 A, B, C 개념이 있으면 아티클을 통째로 보관하는 대신 개념마다 위키 카드를 만들어요. 다른 아티클에서 D와 A가 나오면 앞의 A와 연결하고 린트(lint, 정합성 점검)를 돌리죠. 나중에 A로 뭘 할지 질문하면 그 답도 위키에 쌓여서 지난주에 물어본 것에 더해 답해 주는 식으로 이어집니다.

이걸 가능하게 한 기술로 클로드 코드에 스킬이 나올 때 함께 소개된 프로그레시브 디스클로저(progressive disclosure, 필요한 정보만 단계적으로 펼쳐 보이는 방식)를 꼽아요. 본문 위의 메타데이터 영역은 빙산의 일각이지만 그것만 읽어도 전체를 파악하게 해 주니 어떤 문서를 읽을지 라우팅하기 좋다는 거예요. 카파시의 X 게시물만 보고 위키를 만들어 달라고 한 사람들의 위키는 메타데이터가 약하다고 짚어요. 구요한님 위키에는 타입, 디스크립션, 날짜, 태그, 주제는 물론 세션 링크까지 들어 있어서 누르면 그 문서를 만든 작업 세션이 바로 열립니다.

데이터 자체는 비공개지만 설계 스키마는 공개해 뒀어요. LLM 위키 설계 파일은 1.1.0이 최신 버전이고 받아서 온보딩하자고 하면 당신은 누구인지, 왜 지식을 관리하려는지 묻는 온보딩 스킬까지 들어 있어요. 추가 결제 없이 그냥 받으면 된다고 합니다.

녹음 1,400개는 이렇게 노트가 돼요

멀티 페르소나를 어떻게 다 기록하느냐는 질문에 구요한님은 가장 많은 입력이 녹음 전사본이라고 답해요. 녹음 기기 플라우드 노트를 1년 넘게 써서 노트가 1,400개를 넘었다고 하죠. 이걸로 중요한 분들이나 고객과 어떤 이야기를 나눴는지 매핑해 DB처럼 쓰고 있어요.

그런데 기본 앱은 폴더 정도만 분류해 줘서 아쉬웠다고 해요. 그래서 스위프트(Swift)로 직접 앱을 만들었어요. 내가 이 녹음을 활용했는지 아닌지 같은 태그값을 붙이고 상세 분류를 한 뒤 옵시디언과도 연결했죠. 메타데이터와 태그에 분류 척도를 넣기 위한 로컬 DB를 따로 만들어 세션 ID값만 매칭해 뒀다고 합니다.

전사는 위스퍼(Whisper) 모델로 하는데 엄밀해야 할 땐 다른 서비스로 한 번 더 중복 전사해요. 이 도구는 구요한님 교육 과정 수강생에게는 공개하고 있고 따로 열어 볼 생각도 있다고 했어요. 조쉬는 매일 녹음하는 사람들이 이 그림을 보면 자동으로 옵시디언에 뿌려 주고 전사까지 다시 해 주는 걸 왜 생각 못 했을까 할 거라고 반응합니다.

리서치도 비슷하게 돌아가요. ChatGPT, 제미나이, 그록, 클로드 등 여섯 개 정도의 도구로 조사를 함께 돌리고 결과가 나오면 에이전트가 리서치 항목과 주제, 세션 링크를 달아 줘요. 여기서 그치지 않고 예전에 써 둔 글까지 연결해 줍니다. "기억을 믿지 마라 시스템을 믿어라"라는 에세이를 쓰지 않았냐며 이어 주는 식이에요. 이렇게 라우팅 발판을 깔아 두니 에이전트가 이건 902, 이건 630과 관련된다고 잘 지정한다고 해요.

내가 아는 것만 위임할 수 있다고 봐요

볼트 운영 설계의 중심은 CLAUDE.md예요. 시스템 파일마다 읽는 우선순위를 정해 뒀는데 1순위가 CLAUDE.md, 그다음이 AGENTS.md예요. 자기 데이터를 가져간 사람 중엔 코덱스(Codex)만 쓰는 사람도 있고 본인도 토큰 문제나 코덱스가 더 잘하는 일 때문에 코덱스를 쓰기도 해서 나눠 뒀다고 해요. 에이전트에서 흔히 쓰는 멘션이 옵시디언에서는 노트 연결이라는 규칙도 따로 적어 뒀고요.

운영하면서 겪은 트러블슈팅 이력도 쌓아 뒀어요. 본문 들여쓰기는 탭인데 위쪽 YAML 메타데이터 필드는 스페이스 두 칸이라는 차이, 태그 필드에서 숫자 앞에 #이 붙으면 옵시디언이 태그로 렌더링하지 못한다는 점 같은 것들이죠. 그래서 이 시스템 파일을 가져가면 옵시디언 편집 오류는 대부분 잡혀 있을 거라고 해요. CLAUDE.md는 원래 길었는데 가볍게 하는 게 좋다는 의견을 받아들여 줄이고 참고할 문서로 라우팅만 해 뒀습니다.

조쉬는 요즘 하네스(harness, 에이전트를 둘러싼 규칙·도구 구성)를 예전처럼 빡빡하게 잡을 필요가 없다는 이야기가 나온다며 의견을 물어요. 구요한님 구조는 무거운 하네스 대신 가벼운 연결들이 촘촘하게 엮인 형태예요. 그 배경으로 에이전트가 만든 문서를 되도록 많이 읽으려 한다는 점을 들어요. 직접 읽어야 취향에 안 맞거나 잘못된 부분을 말해 줄 수 있으니 읽기 쉬운 문서를 만들게 하고 그게 하네스를 가볍게 짜는 취지가 됐다는 거죠.

에이전트 팀의 이름은 아홉 요한이에요. 전 세계의 유명한 요한 50명 정도를 검토해 아홉 명을 골랐고 케플러, 괴테, 듀이, 바흐 같은 이름이 붙어 있어요. 교육은 여기, 글쓰기는 여기처럼 역할별로 나눠 두고 어떤 건 클로드 코드로 직접 관리하고 어떤 건 다른 에이전트 환경에서 돌리며 테스트하는 중이에요. 페르소나 설계는 끝났지만 모든 게 완벽히 동작하는 단계는 아니라고 솔직하게 말해요.

지금은 에이전트 대부분이 감사(audit) 작업을 맡아 데일리 로그를 남기고 구요한님에게 의견을 주는 역할을 해요. 노트북을 손에서 거의 놓지 않을 만큼 직접 운영하는 걸 좋아해서라고 합니다. 그렇게 설계한 목적은 경로 라우팅이에요. 구요한님은 강의에서 어머니의 김치찌개 레시피가 자기 볼트에 들어 있을지 자주 묻는다고 해요.

답은 들어 있지 않다는 거예요. 궁금하면 어머니께 전화하면 되니까요. 모든 지식을 내 바운더리 안에 담으려 하기보다 어디로 가면 무엇을 알 수 있는지 힌트를 담는 게 중요하다고 봐요. 아홉 요한도 걔를 불러서 물어보면 그 담당 폴더의 커버리지를 보고 파악할 수 있겠구나 하는 라우팅을 위해 만든 거고요.

조쉬는 앞으로 개인이 대기업 회장처럼 움직이며 에이전트에게 위임하게 되지 않겠냐고 물어요. 구요한님의 답은 분명합니다.

"저는 내가 아는 것만 위임할 수 있다고 판단을 합니다."

대기업 CEO가 퀄리티 있게 일하려면 내가 감사하고 의견을 줄 수 있는 일을 위임해야 한다는 거죠. 자동화를 보는 눈도 조금 달라요. 자동화가 벌여 놓은 일을 수렴하는 작업이라면 구요한님은 지금 새로운 일을 발산적으로 시도해 보는 데 시간을 더 쓴다고 해요. 커맨드스페이스 규모를 일부러 키우지 않는 이유도 여기에 있어요.

본인 일을 슈퍼휴먼 비즈니스라고 부르는 것도 같은 맥락이에요. AI를 명령하지 않아도 알아서 도는 존재로 만들기보다 사람을 강화해 주는 인터페이스로 본다고 해요. 클로드 코드 세션만 100개 정도 열려 있고 10시간을 줘도 다 못 보여 줄 만큼 직접 만든 앱이 많은데 이걸 다 해 볼 수 있었던 건 옵시디언이라는 지식 베이스 덕분이라고 말합니다.

내 시스템은 몇 점일까요, AKM 인덱스로 재 볼 수 있어요

조쉬가 루프 엔지니어링(loop engineering, 에이전트 작업이 반복되며 개선되는 구조 설계)에 대한 생각을 묻자 구요한님은 직접 만든 진단 도구를 꺼내요. AKM(Agentic Knowledge Management) 인덱스예요. 프롬프트, 컨텍스트, 하네스, 루프 등 다섯 영역을 점검하는데 컨텍스트에 가중치를 더 줬어요. 엔터프라이즈 AX 컨설팅을 하면서 어디까지 체크해야 하는지 정리한 결과라고 합니다.

채점은 항목마다 0점에서 4점이에요. 없으면 0점, 그때그때 손으로 하면 1점, 문서화돼 있으면 2점, 시스템에서 돌아가면 3점, 자가 개선 루프까지 있으면 4점이죠. 문서가 다 돼 있어야 2점이니 50점 받기도 굉장히 어렵다고 해요.

점수마다 어떤 상태여야 하는지 행동 기준을 명확히 적은 루브릭도 붙였어요. 그냥 알아서 잘 정리해 달라고 하면 0점, 스킬과 커맨드가 있고 프론트매터가 돌아가면 3점, 린터 작업까지 있으면 4점 하는 식이에요. 모두가 다 자동화할 필요는 없지만 어느 방향으로 가면 되는지는 그려 두고 싶었다고 해요. 구요한님 본인도 처음엔 70점 정도였습니다.

이 진단은 클로드 스킬로 올려 둬서 각자 컴퓨터에서 로컬로 한 번 스캔하고 끝나요. 결과는 아티팩트 성적표로 뜨고 원할 때만 제출하게 돼 있어요. 제출한 사람이 50명 정도인데 그중 서울대 교수 한 분은 80점대에서 시작해 개선을 거듭해 100점을 받았다고 해요. 같은 측정 프롬프트가 30일 동안 운영됐는지 묻는 문항도 있어서 시간이 지나야 채워지는 점수도 있거든요.

74점에서 시작해 점수를 끌어올린 분도 있고요. 83점짜리 성적표 예시에선 항목별 코멘터리, 많이 쓰는 도구, 어느 규모로 얼마나 자동화했는지까지 나와요. 조쉬는 시청자들에게 꼭 한번 해 보라고 권합니다.

마지막으로 지식 관리를 시작하려는 사람에게 한마디를 부탁하자 구요한님은 기록하고 정리할 때 설레는 것부터 고르라고 해요. 위스키를 좋아하면 위스키만 정리해도 된다는 거죠. 좋아하는 걸 담다 보면 인스타그램을 할 수도 있고 유튜브가 대박 날 수도 있으니까요. 그래서 "나의 마음을 뛰게 하는 일들을 정리해 보는 일들로 시작해 보시면 좋지 않을까 싶습니다"라고 정리합니다.

AI는 점점 똑똑해지겠지만 내 이야기와 생각이 어디 있는지가 가장 중요하다는 말도 남겨요. 내 이야기가 있어야 그 AI를 내 취향과 목적에 맞게 부릴 수 있다는 거예요. 그래서 지금도 열심히 글을 쓰고 자기 이야기를 담고 있다고 합니다.

핵심 인사이트

• 설계가 먼저 있어야 AI가 분류를 맡을 수 있어요: 에이전트가 701, 902 같은 번호를 정확히 달 수 있는 건 목차·메타데이터·번호 체계를 구요한님이 먼저 엄밀하게 잡아 뒀기 때문이에요. 체계가 커지며 겪은 암흑기를 에이전트가 풀어 준 셈이라 노트가 많은 사람일수록 설계 문서의 가치가 커집니다.
• 볼트를 저자 기준으로 나누면 신뢰도가 섞이지 않아요: 내가 승인한 지식(메인 볼트)과 LLM이 운영하는 지식(위키 볼트)을 분리하고 문서마다 만든 모델까지 적어 두면 나중에 무엇을 믿고 무엇을 고칠지 판단하기 쉬워져요.
• 위임의 범위는 내가 아는 범위까지예요: 구요한님은 감사하고 의견을 줄 수 있는 일만 맡기고 에이전트가 만든 문서를 직접 읽어요. 그래서 하네스를 가볍게 유지할 수 있다는 점이 요즘 무거운 하네스 논쟁에 대한 하나의 답이 됩니다.

오늘 당장 해볼 것

1. 구요한님이 공개한 시스템 파일과 LLM 위키 설계 파일(1.1.0)을 영상 설명란 링크에서 받아 온보딩 스킬을 돌려 보세요. 당신은 누구인지, 왜 지식을 관리하려는지 답하다 보면 내 볼트의 첫 목차가 저절로 잡혀요.
2. 옵시디언 인덱스 노트 하나를 만들어 클래스(예: 고객 업무·콘텐츠·학습) 세 가지와 토픽 몇 개만 나눠 보세요. 노트 프론트매터에 타입, 디스크립션, 날짜, 태그와 함께 만든 AI 모델명까지 적어 두면 나중에 에이전트가 라우팅할 기준이 생깁니다.
3. AKM 인덱스 스킬로 지금 내 작업 환경을 한 번 진단해 보세요. 결과에서 1점(그때그때 손으로 함)인 항목 하나를 골라 문서로 정리해 2점으로 올리는 것부터 시작하면 부담이 적어요.