이 글은 [조쉬의 뉴스레터]의 인터뷰 편집본입니다.

프로덕트와 창업가, 비즈니스 이야기를 구독해보세요. 구독 시 100개의 1인 창업 케이스 스터디를 받아보실 수 있습니다.

[구독하러 가기]

커맨드스페이스 구요한 인터뷰 — 기록의 규칙에서 AI에게 맡길 일의 기준까지

혼자 메모하려고 만든 설명서가 강의 자료를 거쳐, AI가 읽는 업무 지침이 됐습니다. 커맨드스페이스를 운영하는 구요한님의 이야기예요.

구요한님은 인터뷰에서 옵시디언에 1만 개가 넘는 노트를 쌓아 왔다고 설명했습니다. 하지만 이번 대화에서 눈여겨볼 부분은 기록의 양보다 그 기록을 다시 쓰는 방식이에요. 기록의 위치부터 AI에게 맡길 범위까지 자신의 기준으로 정해 두었습니다.

나를 위해 정리한 지식이 AI의 업무 지침이 되려면, 그 지식을 다루는 나의 규칙도 함께 남아 있어야 합니다. 아래는 빌더 조쉬 채널의 구요한 인터뷰를 주제별로 압축·재구성한 문답입니다. 답변의 1인칭은 구요한님이며, 읽기 쉽게 다듬은 내용은 축어록과 다릅니다.

['빌더 조쉬' 유튜브 구독하러가기]

가르치기 위해 쌓기 시작한 기록

Q. 여러 일을 하시는데, 지식관리는 어떻게 시작하게 되셨나요?

지금 주로 하는 일은 AI와 지식관리에 관한 강의와 컨설팅입니다. 대학에서 AI를 가르치고 있고, 재즈 보컬리스트로도 활동하고 있어요.

어릴 때부터 남에게 무언가 알려주는 걸 좋아했어요. 그런데 알려주려면 저도 알아야 하잖아요. 매년 새롭게 배운 내용을 다른 사람에게 전달하려고 하다 보니, 어떻게 정리해야 더 잘 이야기할 수 있을지를 계속 고민하게 됐습니다.

강의할 때 자주 하는 말이 두 가지 있어요. 질문은 언제나 환영한다는 말과, 모르는 질문에는 2주 뒤에 뵙겠다는 말입니다. 지금은 몰라도 그 사람에게 설명하고 인사이트를 드릴 수 있을 만큼 공부해서 오겠다는 마음이에요. 질문을 받는 일이 저에게는 공부를 시작하는 계기이기도 합니다.

옵시디언을 처음 만난 건 2022년 5월이었는데요. 여러 지식관리 도구를 비교하다가 이 도구를 알게 됐고, 처음 만난 날에 2주 뒤 강의를 잡았어요. 직접 배우고 다른 사람에게 알려주는 과정을 함께 만들었던 거죠.

Q. 여러 도구 가운데 옵시디언을 선택한 이유가 있었나요?

가장 큰 이유는 마크다운(Markdown)이었어요. 텍스트에 간단한 기호로 제목이나 목록을 표시하는 형식인데, 일반 텍스트처럼 여러 편집기에서 열어볼 수 있습니다. 제가 파일로 가지고 있을 수 있다는 점이 좋았어요.

옵시디언의 볼트는 노트들을 담아 두는 폴더라고 생각하시면 됩니다. 저는 데이터가 제 로컬 컴퓨터에 남는다는 점을 중요하게 봤습니다. 내 자료를 제가 가지고 있다는 게 선택의 이유였어요.

처음부터 AI가 붙을 거라고 예상하고 고른 건 아니었습니다. 그런데 이후 Claude Code(파일을 읽고 수정하는 AI 코딩 도구)가 나오면서, 그동안 볼트에 쌓아 둔 파일들을 AI와 함께 활용할 수 있게 된 거죠. 돌아보니 오랫동안 제 기억처럼 쓰던 기록들이, AI가 참고할 수 있는 자료이기도 했던 겁니다.

옵시디언에 설계 문서를 정리해 AI의 참조 자료로 활용한 실사용 기사. 이미지 출처: 디지털투데이, 2026.04.14. 원출처

필요한 기능을 더해 쓰는 플러그인 생태계도 매력적이었어요. 다른 사람이 만든 기능을 써볼 수도 있고, 제가 필요한 기능을 만들어 볼 수도 있으니까요.

나를 위한 설명서가 AI의 지침이 됐습니다

Q. 기록을 AI와 유용하게 쓰려면 무엇부터 정해야 하나요?

저는 무엇에 쓰이는지 설명하기 전에, 자신의 지식관리 체계를 자신이 이해하고 있는지를 먼저 말씀드리고 싶어요. 제가 처음에 많은 시간을 들여 설계한 것도 그 부분이거든요. 어떤 자료가 어디에 있고, 어떤 방식으로 기록할지를 제가 알아야 했습니다.

그때 만든 문서가 큰 목차 역할을 하는 헤드쿼터(Head Quarter)와 기록 규칙을 담은 가이드(Guide)예요. 헤드쿼터에는 제가 연구하는 것, 하는 일, 배우고 싶은 것들의 구조를 잡아 두었어요.

다만 목차 하나만이 유일한 통로는 아니에요. 조쉬님을 떠올린다고 해볼게요. 쓰레드 계정이 먼저 생각날 수도 있고, 유튜브 채널이 생각날 수도 있고, 함께 만났던 자리가 떠오를 수도 있잖아요.

노트도 마찬가지입니다. 날짜로 찾을 수도 있고, 주제로 찾을 수도 있고, 같은 태그를 가진 자료를 따라갈 수도 있어요. 지식 하나로 들어오는 길을 여러 개 열어 두는 것이 중요하다고 생각했습니다. 목차는 그중 큰 길 하나인 거예요.

옵시디언에서는 노트와 연결 그래프를 함께 살펴볼 수 있다. 이미지 출처: Obsidian 공식 제품 화면. 원출처

Q. 그 목차와 가이드는 어떻게 AI가 읽는 설명서가 되었나요?

가이드에는 메타데이터를 어떻게 쓸지 정리해 두었습니다. 메타데이터는 노트 본문을 설명하는 정보예요. 어떤 종류의 노트인지, 날짜나 평점은 어떤 형식으로 쓸지 같은 것들이죠. 연구 자료인지, 프로젝트인지, 강의인지, 일기인지 구별하는 방법도 정했습니다.

같은 항목을 그때그때 다르게 적으면 나중에 쓰기 어려우니까, 각각의 예시도 함께 남겼어요. 폴더 구조와 이름에 붙이는 표현도 정리했고요. 처음부터 거창한 AI 운영 문서를 만든 게 아니라, 제가 일관성 있게 노트를 쓰기 위한 설명서를 만들었던 겁니다.

처음에는 저를 위한 설명서였고, 이후에는 사람들에게 강의하기 위한 설명서가 됐습니다. 지금은 AI가 참고하는 설명서가 됐어요. AI도 제가 정해 놓은 분류와 규칙을 참조할 수 있는 거죠.

지금은 AI 도구를 위한 지침 파일들과 사람이 읽는 가이드를 함께 정리해 두고 있습니다. 제 개인 데이터 자체를 공개한 것은 아니지만, 이런 설계 원리와 시스템 파일은 공개해 두었어요. 본인의 상황에 맞게 바꿔 쓰실 수 있습니다.

상태·평가·연결 필드의 이름과 형식을 정해 둔 CMDS Guide의 일부. 이미지 출처: 빌더 조쉬 YouTube, 09:15 화면 일부 확대. 원출처

기록은 실제 업무로 돌아갈 수 있어야 합니다

Q. 쌓아 둔 노트가 강의나 컨설팅 같은 실제 업무에는 어떻게 쓰이나요?

제 데이터는 옵시디언을 경유한다고 말씀드릴 수 있을 것 같아요. 그렇다고 최종 결과물을 전부 옵시디언 안에 넣는다는 뜻은 아닙니다. 발표 자료는 PPT로 만들기도 하고, 전달할 문서는 PDF로 내보내기도 해요.

대신 기획 문서와 작업을 총괄하는 문서는 볼트에 남깁니다. 프로젝트를 시작하면 무엇을 하려고 하는지, 어떤 단계로 진행하는지 정리해요. 개발 파일이나 강의 자산이 다른 폴더에 있더라도 기획 문서에서 그 위치를 가리키게 해두는 겁니다.

예를 들어 컨설팅 프로젝트의 노트를 열었을 때, 그 일에 필요한 개발 폴더와 강의 자료 폴더로 갈 수 있도록 연결해 두는 거예요. 계약서나 보고서가 들어갈 실제 프로젝트 폴더도 구분해 두고요.

이렇게 하면 옵시디언에는 일을 이해하고 운영하는 데 필요한 마크다운 문서가 남고, 그 자료를 기반으로 만든 결과는 적절한 곳에 놓을 수 있어요. 제게는 일종의 운영을 돕는 공간인 셈입니다.

Q. 이번 인터뷰를 준비할 때도 그 방식을 쓰셨나요?

네. 질문지를 받고 제 볼트에 이 인터뷰 프로젝트를 만들었어요. 받은 원본은 그대로 보관하고, 조쉬님의 채널도 조사했습니다. 어떤 이야기를 나누게 될지 저도 공부해야 하니까요.

질문지에는 저에 관한 수치도 들어 있었는데, 틀렸을 수 있으니 이상하면 알려 달라고 하셨잖아요. 그래서 질문지 내용을 제 자료와 하나씩 대조했어요. 달라진 부분을 바로잡은 정정본을 만들고, 거기에 답변 초안까지 써 두었습니다.

그 과정이 모두 기록으로 남으니, 조쉬님에 대해 정리한 내용과 제 이야기도 함께 연결됐어요. 하나의 작업에서 생긴 자료들이 다음 작업을 위한 맥락으로 남는 것이 이런 방식의 장점이라고 생각합니다.

최근에는 어떤 AI 모델이 문서를 만들었는지도 적어 놓고 있어요. 제가 다시 읽어보고 마음에 드는 부분과 그렇지 않은 부분을 피드백해야 하잖아요. 그러려면 누가 만든 결과인지 알아야 한다고 봤습니다.

인터뷰 질문지를 볼트 자료와 대조한 ‘02. 질문지 검토본’. 설명란에 대조 결과(확인 14건, 옛 수치 7건 등)가, 속성에 작성 모델과 관련 문서가 남아 있다. 이미지 출처: 빌더 조쉬 YouTube, 27:10 화면 일부. 원출처

내가 쓴 지식과 AI가 정리한 지식은 구분합니다

Q. 메인 볼트와 LLM 위키를 따로 두신 이유는 뭔가요?

저자가 다르다고 생각했기 때문이에요. 메인 볼트는 제가 운영하고 AI가 돕는 공간입니다. 제가 지시하고 승인하는 것이 중심이고, 제 이야기를 담습니다. 제가 충분히 알고 설명할 수 있는 내용들을 모아 둔 곳이라고 생각해요.

반면 LLM 위키(대규모 언어 모델이 자료를 정리하는 위키)는 AI가 자료를 읽고 정리하는 역할을 더 많이 맡는 공간이에요. 제가 관심을 가지고 선택한 자료들이지만, 그 자료를 정리하고 연결하는 일은 AI가 좀 더 주도합니다. 저는 그 과정을 관리하고 감독하는 입장이고요.

LLM으로 연구 주제별 개인 지식베이스를 만드는 방식을 소개한 안드레이 카파시의 게시물. CMDS LLM Wiki는 카파시가 제안한 LLM Wiki 패턴을 직접 구현했다고 소개한다. 이미지 출처: Andrej Karpathy X, 2026.04.03. 원출처

제가 요즘 관심을 가지고 공부하는 주제가 있다고 해볼게요. 아직은 제 말로 명확하게 설명할 수 없지만, 그렇다고 저와 아무 관계도 없는 지식은 아니잖아요. 그런 내용을 위키에 담고 제 속도에 맞춰 하나씩 살펴봅니다.

저는 메인 볼트를 중심이 되는 모선처럼 생각하고, 위키나 함께 쓰는 다른 볼트들을 그 주변의 위성처럼 생각했어요. 제 지식을 중심에 두되 새로운 것을 배우고 확장할 수 있도록 주변 공간을 만드는 겁니다.

Q. 자료를 검색하는 것과 위키로 ‘컴파일한다’는 것은 어떤 차이가 있나요?

여기서 컴파일한다는 것은 원자료를 다시 읽고, 활용하기 좋은 지식 형태로 정리한다는 의미로 보시면 됩니다. 어떤 글에 A, B, C라는 개념이 들어 있다고 해볼게요. 그 글을 한 덩어리로만 보관하는 게 아니라, 각각의 개념을 위키 카드로 정리하는 겁니다.

새 자료를 위키에 반영하는 Ingest, 질문에서 나온 좋은 답을 다시 위키 페이지로 남기는 Query를 설명한 카파시의 LLM Wiki 문서. 이미지 출처: Andrej Karpathy GitHub Gist, 2026.04.04, 본문 폭을 좁혀 발췌. 원출처

다른 글을 읽었는데 거기에도 A가 등장한다면, 앞서 정리한 A와 연결할 수 있겠죠. 새로 알게 된 내용을 반영하고, 관련 자료가 무엇인지 함께 남겨 둘 수 있어요.

그다음에 A를 활용해서 무엇을 할 수 있을지 질문했다고 해보죠. 그때 나온 답변도 유용하면 저장해 두는 거예요. 다음번에는 지난 질문과 결과를 바탕으로 다시 이야기할 수 있죠. 자료를 읽은 결과와 질문한 결과가 다시 쌓이는 구조를 원했던 겁니다.

물론 검색으로 관련 자료를 찾아 답하는 RAG도 여전히 좋은 방법이라고 생각해요. 큰 규모의 지식이나 출처가 명확해야 하는 일에 유용하죠. 제가 위키에 기대하는 가치는 검색을 없애는 것보다, 자료를 연결하고 활용하며 만든 결과를 다음 작업에 남기는 데 있습니다.

Q. 자료가 많아지면 AI도 무엇을 읽어야 할지 헤매지 않을까요?

그래서 메타데이터가 중요하다고 생각해요. 문서 본문을 다 읽기 전에도 어떤 내용을 담고 있는지 알 수 있는 정보를 앞에 놓는 거죠. 빙산의 일각처럼 작은 부분이지만, 그 정보를 보면 아래에 어떤 내용이 있을지 짐작할 수 있게 만드는 겁니다.

이름·설명 같은 메타데이터는 항상 먼저 읽고, 본문과 첨부 파일은 필요할 때 불러오는 Anthropic Agent Skills의 단계별 구조. 이미지 출처: Anthropic Engineering, 2025.10.16. 원출처

문서의 종류와 설명, 날짜, 태그, 관련 주제 등을 정리해 둡니다. 이런 정보들이 어떤 문서를 읽을지, 어디로 가면 필요한 내용을 찾을 수 있을지 안내하는 역할을 해요.

저는 관련 작업을 했던 AI 대화의 세션 링크도 남겨 둡니다. 이번 인터뷰 답변 초안을 만든 문서에서 그 링크를 누르면, 준비하면서 사용했던 대화로 다시 돌아갈 수 있게 한 거예요.

메타데이터를 읽고 필요한 문서를 고른 뒤 본문을 확인하는 흐름. 이미지 출처: 빌더 조쉬 YouTube, 22:40. 원출처

기록과 분류의 부담을 줄이는 방법

Q. 처음 시작하는 사람은 분류 체계를 어떻게 잡으면 좋을까요?

처음부터 제 구조 전체를 그대로 따라야 하는 건 아니에요. 저는 원래 이런 일을 좋아해서 오랜 시간 고민하며 설계했습니다. 그 정도까지 하고 싶지 않은 분이라면, 단순한 메모장처럼 쓰면서 내 데이터가 남게 하는 것만으로도 가치가 있다고 생각해요.

제게도 분류가 많아져서 기억하기 어려운 시기가 있었습니다. 처음에는 엄밀하게 설계해서 잘 썼는데, 새로운 일을 하면서 확장하다 보니 저도 문서를 열어 보고 확인해야 하더라고요.

지금은 에이전트가 분류를 돕습니다. 연구 결과에 어떤 주제인지 붙이고, 관련된 과거 연구나 제가 썼던 글도 연결해 주는 식이에요. 제가 미리 만들어 둔 체계가 있으니 AI가 그 안에서 자료의 위치를 잡을 수 있게 된 거죠.

처음에는 내가 어떤 일을 하는지, 어떤 주제를 다루는지 정도를 구분해 보시면 좋겠습니다. 연구인지, 프로젝트인지, 강의인지가 하나의 기준이고요. 데이터 분석, 컨설팅, 자녀 교육처럼 다루는 주제가 또 다른 기준이에요. 공개한 제 설계도 하나의 예시로 두고, 본인의 말과 일에 맞게 변형해 쓰시면 좋겠어요.

일의 종류와 다루는 주제를 구분해 기록을 분류한다. 이미지 출처: 원인터뷰를 바탕으로 편집부 재구성. 원출처

Q. 여러 일을 하면서 기록할 시간은 어떻게 확보하시나요?

제게 들어오는 자료 중 많은 부분은 녹음한 내용을 글로 옮긴 전사본입니다. Plaud Note를 1년 조금 넘게 썼는데, 인터뷰할 때 기준으로 노트가 1,400개를 넘었어요. 사람들과 어떤 이야기를 나눴는지 기록하고, 필요한 대화와 사람을 연결해서 활용하고 있습니다.

구요한님의 Plaud 웹 화면. 전체 파일 1,448개와 지식관리 관련 녹음 기록이 보인다. 이미지 출처: 빌더 조쉬 YouTube, 31:20 화면 일부. 원출처

그런데 기본 앱에서 폴더로 분류하는 것만으로는 아쉬운 부분이 있었어요. 이 기록을 제가 활용했는지, 어떤 태그를 달아야 하는지 같은 정보가 더 필요했거든요. 그래서 그 부분을 다룰 수 있는 도구를 직접 만들었습니다.

Swift로 만든 도구에서 기록을 가져와 보여주고, 제가 분류하는 데 필요한 메타데이터와 태그는 로컬 데이터베이스에 따로 둡니다. 원래 기록의 세션 ID와 연결해 두는 방식이에요. 기록을 어떻게 다루고 있는지도 관리하고 싶었던 겁니다.

내용을 엄밀하게 확인해야 할 때는 다른 도구로 한 번 더 전사하기도 해요. 제가 필요한 방식으로 전사하고, 분류에 필요한 정보까지 연결해서 활용하는 거죠.

녹음기·앱·클라우드가 이어지는 Plaud Note의 사용 경험을 다룬 리뷰. 이미지 출처: IT조선, 2025.08.05. 원출처

맡기되, 읽고 판단할 수 있도록

Q. AI가 내 규칙을 따르게 하려면 무엇을 알려줘야 하나요?

AI가 어떤 문서를 먼저 읽었으면 하는지 우선순위를 정해 두었어요. 도구별 지침이 있고, 그 아래에는 제 지식 체계를 운영하는 데 필요한 맥락과 규칙이 있습니다. 어떤 설명이 먼저 필요한지 제 의도를 담아 둔 겁니다.

예를 들어 옵시디언에서 노트를 연결하는 표기와 AI 도구에서 파일을 불러오는 표기가 다를 수 있어요. 본문과 메타데이터에서 들여쓰기를 어떻게 해야 하는지도 다르고요. 이런 세부 사항이 어긋나면 문서를 읽거나 편집할 때 문제가 생길 수 있어서, 헷갈릴 부분을 규칙으로 남겼습니다.

실제 작업에서 문제가 생기면 그 경험을 다시 반영해요. 어떤 것은 지침 문서에 넣고, 어떤 것은 별도의 규칙이나 스킬로 만듭니다. 오류를 한 번 고치고 끝내기보다, 다음 작업에서도 참고할 설명으로 남기는 것이죠.

다만 기본 문서를 계속 길게만 만들려고 하지는 않아요. 핵심 설명은 줄이고, 필요한 상세 문서를 참조하도록 연결해 두는 방향으로 다듬고 있습니다. 어디에 가면 무슨 규칙을 읽을 수 있는지 알게 하는 거예요.

CMDS의 공개 CLAUDE.md는 공통 규칙을 별도 파일로 나누고 핵심 지침에서 참조한다. 이미지 출처: CMDS System Files. 원출처

Q. 아홉 명의 ‘요한’이라는 에이전트는 지금 어떻게 일하고 있나요?

먼저 말씀드리면, 모든 것이 완벽하게 동작하는 상태는 아닙니다. 역할과 페르소나는 설계해 두었지만, 어떤 도구에서 어떻게 운영할지는 하나씩 시험하고 있어요. 제가 하는 일들을 돕는 역할과 그 역할을 부를 이름이 필요했어요.

지금은 주로 감사나 리뷰 작업을 하게 하고, 제게 의견을 주는 형태로 많이 쓰고 있습니다. 제가 지켜보지 않는 동안 자기들끼리 모든 일을 하게 만드는 것이 주된 목적은 아니었어요. 제가 직접 운영하면서 일을 넓혀 가는 것을 좋아하기 때문에, 그 일을 도와주는 존재를 원했습니다.

역할을 나눈 이유도 제가 질문할 곳을 정하기 위해서예요. 교육과 관련된 일은 어디에 물어보면 되는지, 글을 쓰는 일은 어느 역할에 물으면 되는지 알게 하는 거죠. 그 역할이 담당하는 자료의 범위도 알 수 있고요.

어떤 일을 할 때 누구에게 어떤 자료를 보게 할 것인가를 정해 두고, 실제로 리뷰를 받는 중이에요.

지식관리·글쓰기·교육 등 역할마다 이름을 붙인 ‘9요한 Constellation’ 화면. 이미지 출처: 빌더 조쉬 YouTube, 24:40 화면 일부. 원출처

Q. 모든 지식을 파악하고 있어야 한다면 너무 부담스럽지 않을까요?

모든 내용을 다 알고 있어야 한다는 뜻은 아니에요. 대신 어디로 가면 무엇을 알 수 있는지는 알고 싶었습니다. 조쉬님의 지식을 제가 전부 아는 것은 아니잖아요. 그래도 이 번호로 연락하면 조쉬님께 물어볼 수 있다는 것은 알 수 있죠.

강의할 때 이런 질문을 자주 드려요. 제 어머니가 김치찌개를 맛있게 끓여 주시는데, 그 레시피가 제 볼트에 저장되어 있을까요? 저장되어 있지 않습니다. 궁금하면 어머니께 전화를 해요. 고기를 먼저 넣는지, 김치를 먼저 넣는지 그때 여쭤보면 되거든요.

제가 가진 모든 지식을 저장소 안으로 옮겨야 한다고 생각하지는 않아요. 필요한 것을 어디서 얻을 수 있는지에 대한 힌트가 있으면 됩니다. 에이전트도 마찬가지예요. 어떤 역할을 불러오면 어느 영역을 함께 살펴볼 수 있는지 알도록 경로를 남기는 겁니다.

이런 이유로 AI가 만든 문서를 되도록 많이 읽으려고 해요. 읽기 쉬운 형태로 만들게 하고, 제 취향에 맞지 않는 부분이나 잘못된 부분을 이야기할 수 있으려고 합니다. 그 결과에 제 의견을 줄 수 있으려고 하는 거예요.

사람에게 AI의 출력을 멈추거나 결정을 무효화할 권한을 거의 주지 않은 채 지켜보는 역할만 맡기는 ‘휴먼 인 더 루프’의 한계를 짚은 기사. 이미지 출처: CIO Korea, 2026.09.08. 원출처

Q. 앞으로 AI에게 더 많은 일을 위임하게 되더라도 그 원칙은 같을까요?

저는 제가 알고, 검토하고, 의견을 줄 수 있는 일을 위임해야 한다고 생각합니다. 결과가 괜찮은지 판단하고, 무엇을 바꾸면 좋을지 말할 수 있어야 일을 제대로 맡길 수 있다고 보는 거죠.

지금 제게는 반복되는 일을 자동화하는 것만큼, 직접 새로운 일을 해보는 과정이 중요해요. 새로운 것을 배우고, 필요한 앱을 만들고, 전에 하지 않았던 시도를 해보는 데서 즐거움을 느낍니다. 앞으로 할 수 있는 일을 넓혀 보는 데 시간을 쓰고 싶어요.

물론 앞으로 운영하는 조직의 규모가 커지거나 상황이 달라지면 자동화할 일도 더 많아지겠죠. 자동화를 하지 않겠다는 뜻은 아닙니다. 지금 하고 싶은 일과 즐거움을 기준으로 역할을 정하고 있는 거예요.

AI는 앞으로 더 똑똑해질 겁니다. 그럴수록 제게는 내 이야기와 생각은 어디에 남아 있는가가 중요해요. AI를 제 취향과 목적에 맞게 활용하려고 계속 제 글과 생각을 남기는 중입니다.

완벽한 자동화보다, 즐겁게 기록할 주제 하나

Q. 자신의 지식관리 시스템이 잘 돌아가는지는 어떻게 점검하시나요?

제가 가고 싶은 방향을 살펴보기 위해 AKM Index라는 평가 기준을 만들었어요. AI 에이전트와 함께 지식을 관리할 때 무엇이 갖춰져 있는지 보는 도구입니다. 다섯 영역에서 기록과 운영 상태를 살펴보도록 했습니다.

AKM Index v1.2 공식 문서에 공개된 다섯 평가 영역과 가중치. 이미지 출처: CMDSPACE GitHub. 원출처

이를테면 그때그때 손으로 처리하고 있는지, 방법이 문서로 남아 있는지, 시스템에서 실행되는지, 결과를 보고 개선하는 과정이 있는지를 구분합니다. 파일과 설정, 기록을 보면서 보완할 곳을 찾으려는 거예요.

제가 처음 평가했을 때는 약 70점이 나왔어요. 필요한 부분을 하나씩 개선하고 있습니다. 모든 것을 다 자동화해야 한다고 생각해서 만든 것은 아니에요. 앞으로 갈 수 있는 방향을 그려 보고 싶었습니다.

평가를 실행할 때 로컬에 있는 기록을 살펴보고 결과를 남기는 방식이에요. 공개한 기준을 보면서 자신의 시스템을 한번 점검해 보셔도 좋겠습니다.

AKM Index는 구요한님의 자체 지식관리 평가 기준이다. 파일·설정·로그를 근거로 자신의 운영 방식을 점검한다. 공개 기준 보기

Q. 지식관리를 이제 시작하려는 분께 한 가지만 권한다면요?

무엇을 기록하고 정리할 때 마음이 설레는지 생각해 보셨으면 좋겠습니다. 기록을 좋아하는 사람도 있고 그렇지 않은 사람도 있지만, 누구에게나 관심을 가지고 좋아하는 것은 있잖아요. 꼭 직장이나 커리어와 직접 연결되어 있을 필요는 없습니다.

예를 들어 위스키를 좋아한다면 위스키에 관한 것만 정리해 봐도 돼요. 좋아하는 것을 정리하다 보면 그 내용으로 다른 활동을 하게 될 수도 있겠죠. 신나는 주제부터 시작하는 겁니다.

나의 마음을 뛰게 하는 일을 정리해 보는 것에서 시작하시면 좋겠습니다. 꼭 커리어와 연결하지 않아도, 좋아하는 일을 담는 것부터 시작해 보세요.

HOW I AI PODCAST 전체 인터뷰 보기

소중한 노력이 들어간 글을 널리 알려주세요.

이 기사가 좋으셨다면, 보상을 해주세요.

가장 좋은 보상은 ‘조쉬의 뉴스레터 구독’입니다. :)

구독을 하시면 100개의 1인 창업가 데이터베이스를 발송해드립니다.

[구독하러 가기]