Claude Code 및 기타 AI 도구 전반에서 Obsidian을 활용하는 방법

몇 달 전 AI 코딩 에이전트의 환각 (hallucinations)을 줄이기 위해 노력하던 중, 저는 컨텍스트 관리 (context management)를 개선해야 한다는 점을 점점 더 깨닫게 되었습니다. 단일 세션 내에서뿐만 아니라, 모든 세션에 걸쳐서 말이죠. 한 도구에서 배운 내용이 다른 도구에서도 유용할 수 있었음에도 불구하고, 제 기억력과 복사-붙여넣기 외에는 그 지식을 전달할 메커니즘이 없었습니다.

결국 저는 Obsidian을 AI 코딩 도구 전반에 걸친 장기 기억의 중앙 허브로 사용하는 것에 도달했습니다. 이 글은 제가 사용하던 도구들의 사용성 문제를 설명하여, 제가 이를 어떻게 생각하는지, 그리고 소프트웨어 개발 생명 주기 (software development lifecycle)를 둘러싼 비기술적 문제들을 어떻게 생각하는지 이해할 수 있도록 돕고자 합니다.

지난 몇 달 동안 이에 대해 폭넓은 논의가 있었습니다. 어떤 이들은 이를 "메모리 아키텍처 (memory architecture)"라고 부릅니다. Andrej Karpathy는 그가 LLM 지식 베이스 (LLM Knowledge Bases)를 만들기 위해 Obsidian을 어떻게 사용하는지 설명했습니다.

바이브 코딩 (vibe coding)에 더 깊이 빠져들면서, 저는 코딩, 도구 조사, 그리고 일반적인 계획 수립을 병행해 왔습니다. 저의 일부 AI 대화들은 믿을 수 없을 정도로 유용했으며, 저는 그러한 통찰력을 실제로 다시 사용할 수 있는 어딘가에 보관하고 싶었습니다. 저는 이것이 AI 세계에서 Gene Kim과 Steve Yegge가 최적화를 제안한 "수동적인 프롬프트 던지기 (manual slinging of prompts)"라는 것을 깨달았습니다. 다만 저는 단순히 프롬프트만 던지는 것이 아니라, 컨텍스트 (context)를 던지고 있었습니다.

저는 엔지니어링, 연구, 비즈니스 계획, 글쓰기, 일상생활 등 매우 다양한 목적을 위해 여러 인터페이스 (CLI, 웹, 모바일, 데스크톱)에 걸쳐 다양한 AI 도구를 사용합니다. 작업에 가장 적합한 도구를 사용하는 것은 중요합니다. 하지만 이 도구들은 서로 소통하지 않습니다. 저는 지식을 축적하고 있었지만, 이를 재사용할 가벼운 방법이 없었습니다.

사이드바: 이 글에서 컨텍스트 관리 (context management)를 언급할 때, 저는 "개인적인 노트 테이킹 (personal note-taking)"과 "엔지니어링 문서화 (engineering documentation)"를 위한 관행도 함께 고려하고 있습니다. 각각의 기능은 다르지만, 많은 부분이 겹칩니다. 환각 (hallucinations) 줄이기에 대해 위에 링크한 글에서 컨텍스트 엔지니어링 (context engineering)에 대해 더 자세히 배울 수 있습니다.

AI의 출력을 다음 채팅 세션의 입력으로 넣고 싶었습니다

솔직하게 말해서: 저는 AI와의 대화에서 핵심적인 발견 사항을 추출하고, 긴 채팅을 깔끔한 요약본으로 내보내며, 도구 전반에 걸쳐 산출물 (artifacts)을 풍부하게 만들고 변환하며, 이 모든 것을 나중에 쉽게 참조할 수 있게 만들고 싶었습니다.

때로는 도구들이 컨텍스트를 공유하기를 원합니다. 반대로, 도구들이 무언가를 무작위로 삭제하지 않도록 격리되기를 원할 때도 있습니다. 또한, 저의 코딩 에이전트 (coding agent)가 일상생활의 노트와 엔지니어링 노트를 섞어서 관련 없는 컨텍스트가 코드 리뷰 (code review)에 스며드는 것도 원치 않습니다. 하지만 저는 이들이 언제 상호작용할지를 제가 제어할 수 있는 메커니즘이 필요합니다.

그리고 이 메커니즘이 무엇이든 간에 가벼웠으면(lightweight) 좋겠습니다. 브라우저로 드래그 앤 드롭할 수 있고, 모바일에서 편집하기 쉬우며, 터미널 (terminal)에서 프로그래밍 방식으로 처리할 수 있어야 합니다.

AI 도구 간에 컨텍스트를 공유할 때 발생하는 사용성 문제

AI 코딩 도구들은 이미 코드에 대해서는 이 문제를 해결했습니다. Cursor와 Claude Code는 파일을 읽고 씁니다. 만약 제가 기억하고 싶은 것이 코드라면, 준비는 끝난 셈입니다. 하지만 제가 AI 세션에서 배우는 많은 것들은 코드가 아닙니다. 그것은 새로운 툴링 (tooling)에 대한 조사나 기능 아이디어, 아키텍처 (architecture)에 대한 결정, 기억하고 싶은 패턴, 그리고 제가 원하는 구조화 방식에 대한 선호도 등입니다. 이 중 그 어떤 것도 코드베이스 (codebase)에 속해서는 안 됩니다.

Google Gemini의 Drive로의 Deep Research 내보내기. 이것은 정말 멋집니다. Deep Research (심층 조사) 세션을 실행하면 Google Drive에 문서 형태로 저장됩니다. 하지만 저는 특정 AI의 생태계에 종속되지 않는 무언가가 필요했습니다. Drive로 내보내더라도, 내용을 복사하여 형식을 다시 맞추고 다른 곳에 붙여넣지 않고서는 Claude Code나 Cursor에 쉽게 입력할 수 없습니다. 이러한 추가 단계는 사용성을 저해합니다.

채팅 검색 및 기록의 문제점. 모든 AI 도구에는 채팅 기록 (chat history)이 있습니다. 하지만 그 어떤 도구도 3주 후에 무언가를 쉽게 찾을 수 있게 만들어주지 않습니다. 검색이 도움이 되긴 하지만, 큐레이션 (curation) 문제를 해결해주지는 못합니다. 저는 200개의 대화를 검색하고 싶지 않습니다. 보관할 가치가 있는 6가지 항목을 원합니다.

"그냥 모든 것에 Claude Code나 Cursor를 사용하세요." 영업이나 마케팅 같은 비기술적인 업무에도 AI 코딩 도구를 사용하는 사람들이 있습니다. 따라서 범용 AI 목적으로 Vibe Coding (바이브 코딩) 도구를 사용하는 것이 기술적으로는 가능합니다. 하지만 어떤 작업들은 시각적 미리보기 (visual preview), 드래그 앤 드롭 (drag-and-drop), 또는 볼일을 보는 동안 사용할 수 있는 모바일 화면을 필요로 합니다. 모든 것이 터미널 (terminal) 작업인 것은 아닙니다.

Notion 및 JIRA를 위한 MCP 서버. 이것은 실제로 강력합니다. 저는 업무 환경에서 팀 지식 베이스 (knowledge base)에 대한 읽기/쓰기 작업을 위해 MCP를 사용해 본 적이 있습니다. 구조화된 데이터가 있는 공유 시스템의 경우 매우 훌륭합니다. 하지만 빠른 개인 메모의 경우, 상호작용 지연 시간 (latency)이 정말 무겁게 느껴집니다. 터미널 출력값을 반복적으로 내보내기 위해 API 왕복 (round-trip)을 기다리고 싶지는 않습니다. 빠르게 움직이며 여러 문서를 넘나들며 반복 작업할 때는 이 차이가 크게 누적됩니다.

왜 하필 Obsidian인가: 전통적인 파일 방식은 가볍습니다

어느 시점에 저는 제가 이 과정을 너무 복잡하게 만들고 있다는 사실을 깨달았습니다. 파일 시스템(filesystem)에 있는 파일들은 AI 코딩 도구들이 읽기에 쉽고, 공유하기 편리하며, 드래그 앤 드롭(drag-and-drop) 방식과도 호환됩니다. 새로운 플러그인을 기다리거나 직접 만들 필요가 없었습니다.

한 친구가 수년 동안 저에게 Obsidian을 사용해 보라고 권유했던 것이 기억났습니다. 저는 그동안 그것을 그저 "또 하나의 노트 필기 앱"이라며 무시해 왔습니다. 하지만 그것이 실제로 무엇인지(동기화 기능이 있는 로컬 우선 (local-first) 마크다운 (markdown) 에디터)를 확인했을 때, 그것이 바로 제가 찾던 마지막 조각이라는 것을 깨달았습니다.

로컬 파일은 보편적인 호환성을 의미합니다. 제가 사용하는 모든 AI 도구는 마크다운 (markdown) 파일을 읽을 수 있습니다. 파일을 채팅 인터페이스로 드래그하거나, CLI 도구가 특정 디렉토리를 가리키게 하거나, 에디터에서 복사하여 붙여넣을 수 있습니다. 내보내기 단계도, API도, 변환도 필요 없습니다. 파일 그 자체가 인터페이스입니다.

기기 간 동기화. Obsidian은 제 노트북과 휴대폰 사이에서 마크다운 (markdown) 파일을 동기화합니다. 모바일에서 노트를 검토하고, 길을 걷는 동안 무언가를 적어두면, 책상에 앉았을 때 그 내용이 그대로 있습니다. 이는 제가 예상했던 것보다 더 중요합니다. 왜냐하면 저는 컴퓨터 앞이 아닌 곳에서도 생각을 많이 하는 편인데, 다른 모든 작업에 사용하는 것과 동일한 시스템에서 그 생각을 포착할 수 있게 되면서 Evernote를 제 노트 필기 도구로 대체할 수 있었기 때문입니다. (네, 저는 2025년에도 여전히 Evernote를 사용하고 있었습니다!)

기본적으로는 격리되어 있고, 선택적으로 공유합니다. 저는 AI에게 제 Google Drive 전체에 대한 읽기/쓰기 권한을 주는 것이 불편했습니다. 파일 시스템 기반의 접근 방식은 특정 폴더만 화이트리스트 (allowlist)에 추가할 수 있게 해줍니다. Claude Desktop과 Claude Code 모두 이를 지원합니다. 제가 경계를 제어합니다. 제가 의도적으로 특정 폴더를 공유하지 않는 한, 저의 개인적인 노트는 개인적인 상태로 유지됩니다.

Markdown은 AI 도구들의 공용어 (lingua franca)입니다. AI 코딩 어시스턴트(AI coding assistants)는 이미 마크다운 (Markdown) 방식으로 사고합니다. 계획, 문서, 요약, 규칙 파일(rules files) — 이 모든 것이 마크다운입니다. 저의 노트는 출력물과 동일한 형식을 갖추고 있습니다. 별도의 번역 계층이 필요 없습니다. 제가 AI 세션에 노트를 입력할 때, AI는 특별한 파싱 (parse) 과정을 거칠 필요가 없습니다. 반대로 AI가 보관할 가치가 있는 결과물을 생성하면, 그것은 이미 제가 직접 저장할 수 있는 형식으로 되어 있습니다.

제 메모리 관리 워크플로의 다양한 측면들

코드 및 git 히스토리와 병행하는 장기 메모리 저장소로서의 역할. 제가 배우는 것들 중에는 코드베이스 (codebase)나 커밋 메시지 (commit message)에 포함되지 않는 것들이 있습니다. 오픈 소스 소프트웨어 및 벤더(vendors)에 대한 조사, 시도해보고 싶은 새로운 AI 기술에 관한 흥미로운 기사 등이 그러합니다. ChatGPT나 Gemini의 웹 인터페이스에서 무언가를 작업한 후에는, 핵심 부분을 추출하여 나중에 Claude Code, Cursor, 또는 Codex가 찾아볼 수 있는 곳에 저장합니다.

유익한 대화 내용 내보내기. AI 채팅은 새로운 접근 방식, 잘 구조화된 분석, 의사결정 프레임워크(decision framework)와 같이 보관할 가치가 있는 내용을 정기적으로 제시합니다. 이런 일이 발생하면, 저는 종종 핵심 부분을 마크다운 노트로 가져오고 싶어 합니다. 이것은 채팅 히스토리 검색으로는 해결할 수 없는 큐레이션 (curation) 단계이며, 특히 데이터를 다른 소스와 혼합하거나 조합하고 싶을 때 더욱 그렇습니다 (아래의 "입출력 허브" 섹션 참조).

재사용 가능한 프롬프트 (Reusable prompts). 어떤 프롬프트들은 머릿속에만 담아두기에는 너무 미묘하고, 스크립트 (script)로 만들기에는 문맥 의존적 (context-dependent)입니다. 이러한 프롬프트들은 필요할 때 바로 꺼내 쓸 수 있는 마크다운 파일 형태로 존재합니다. 저는 코드 리뷰용, 연구 종합용, 특정 스타일의 글쓰기용 프롬프트를 가지고 있습니다. 이것들은 모든 상황에 적용되는 범용적인 것이 아니라, 시간이 흐르며 다듬어진 저의 워크플로에 최적화된 프롬프트들입니다.

입출력 허브 (input/output hub)로서의 역할. 저는 노트를 작성하고, 이를 AI 도구에 입력하며, 도구가 이를 풍성하게 만들거나 변환하면, 그 결과물을 다시 새로운 버전으로 저장합니다. 보관함 (vault)은 시간이 흐르며 축적되는 작업 기억 (working memory)이 됩니다. 저의 블로그 작성 워크플로도 거의 전적으로 이런 방식으로 진행됩니다. 개요가 초안이 되고, 초안은 검토 및 반복 과정을 거치며, 전체 이력이 보관함에 남습니다. 저는 AI 채팅 내보내기 (exports), 리서치 통화 노트, 스크린샷, 그리고 입력값으로 사용하고 싶은 리서치 PDF 등을 혼합하여 사용하고자 합니다.

선순환: 일부 비중을 다시 로컬 파일 시스템으로 이동하기

모든 것에 클라우드 웹 앱을 사용해 온 15년 이상의 세월 끝에, 저는 노트 작성을 위해 다시 로컬 파일 시스템 (local filesystem)의 파일들로 돌아왔습니다. 제가 현대적인 코딩 환경에 대해 글을 쓰면서, 특히 많은 비기술적 (non-technical) 업무에 대해 이야기하고 있음에도 왜 이 워크플로에 대해 쓰고 싶었을까요? 전형적인 소프트웨어 엔지니어의 주간 업무에는 많은 비기술적 업무가 포함되어 있으며, 엔지니어링을 둘러싼 업무를 자동화하는 것은 AI 중심의 작업 속도를 늦추는 병목 현상 (bottlenecks)을 방지하는 데 도움이 될 것입니다.

저는 여전히 이 사용법을 발전시켜 나가는 중입니다. 만약 여러분이 여러 AI 도구를 병행하며 사용하고 있고, 좋은 작업물들을 채팅 기록의 무덤 (chat history graveyards) 속에서 잃어버리고 있다고 느낀다면, 여러분은 이를 어떻게 처리하고 계신지 궁금합니다. AI 대화에서 좋은 내용들을 보존하기 위한 여러분만의 시스템은 무엇인가요? 알려주세요. LinkedIn으로 DM을 보내주시기 바랍니다.

원문은 ashu.co에 처음 게시되었습니다.