2026년에 코드 에이전트를 Obsidian 볼트에 연결하는 것은 더 이상 생소한 아이디어가 아닙니다. 아마도 현재 존재하는 가장 과소평가된 지식 관리 시스템일 것입니다. 그런데도 이를 시도하는 거의 모든 사람들이 첫 번째 단계에 머물러 있습니다: Claude Code 를 폴더에 연결하고 마크다운을 읽고 쓰게 하는 것입니다. 작동은 합니다. 하지만 이것은 시작에 불과하며, 다음 단계인 MCP 가 왜 중요한지 이해하려면 먼저 현재 우리가 가진 것이 무엇이고 어디에서 한계가 있는지 이해해야 합니다.
MCP 없이도 이미 가능한 것
Claude Code 가 볼트를 직접 가리키면 파일 시스템에 접근할 수 있는 모든 에이전트처럼 작동합니다: 폴더 구조를 읽고, grep 과 glob 을 사용하여 관련 콘텐츠를 찾고, 사용자가 지정한 규칙(YAML 프론트매터, 위키링크, 콘텐츠 유형별 폴더 계층 구조)을 준수하여 마크다운 파일을 작성하거나 편집합니다. 플러그인, 데이터베이스, API 는 필요 없습니다: 그저 일반 텍스트와 판단력을 가지고 읽고 쓸 줄 아는 에이전트만 있으면 됩니다.
시스템이 잘 설계되었을 때의 결과는 보이는 것보다 훨씬 강력합니다. 가상이 아닌 실제 사례를 들어보자면: 제가 면밀히 관찰하고 있는 한 볼트는 정확히 이 방법을 사용하여 78개의 원시 소스(논문, 기사, 문서)에서 180개의 상호 연결된 위키 페이지(이 중 83개는 개념 페이지, 나머지는 도구, 인물, 비교, 소스 요약)로 성장했으며, 모든 상호 참조는 새로운 콘텐츠가 들어올 때마다 에이전트가 직접 업데이트합니다. 누군가가 직접 한 페이지도 작성하지 않고 말이죠.
직접 파일 접근의 한계
하지만 이 모델에는 성능상의 한계뿐만 아니라 구조적인 한계가 있습니다. Claude Code 는 사용자의 볼트가 어떻게 구성되어 있는지 미리 알아야 합니다: 어떤 폴더가 변경 불가능한지, 프론트매터 규칙은 무엇인지, 개념과 도구가 각각 어디에 있는지 등입니다. 실질적으로 모든 새로운 볼트는 시스템 프롬프트에서 처음부터 설명해야 하는 다른 통합 방식입니다.
더 나아가, 에이전트는 볼트에게 "당신은 무엇을 할 수 있나요?"라고 물을 수 없습니다. 이미 존재하는 것을 읽고 일반적인 파일 작업(읽기, 쓰기, 텍스트 검색)을 실행할 수 있을 뿐입니다. 에이전트가 매번 처음부터 그 로직을 재구성하지 않고는 파생된 작업(이 노트의 역링크 그래프 보여줘, 이 Dataview 쿼리 실행해줘, 어떤 페이지가 고아 페이지인지 알려줘)을 노출할 방법이 없으며, 그 과정에서 컨텍스트와 오류 여유분을 낭비하게 됩니다.
MCP 가 해결하는 것, 자세히
MCP(Model Context Protocol)는 Anthropic 이 2024년 11월에 출시한 오픈 표준으로, 정확히 이 문제, 즉 AI 모델과 외부 시스템 간의 통합 문제를 해결하기 위해 만들어졌습니다. MCP 이전에는 N개의 AI 어시스턴트가 M개의 다른 도구나 데이터 소스에 연결해야 한다면 N×M개의 맞춤형 통합이 필요했습니다: 한 애플리케이션이 Notion 을 지원하고자 할 때 처음부터 구축했고, 다른 애플리케이션이 동일한 기능을 원할 때 다시 처음부터 구축했습니다. MCP 는 이 N×M 을 N+M으로 바꿉니다: 범용 클라이언트(애플리케이션당 하나)와 범용 서버(시스템당 하나)를 구축하면, 어떤 클라이언트든 맞춤형 통합 없이 어떤 서버와도 통신할 수 있습니다.
올바른 비유는 USB-C 입니다: 이전에는 모든 주변기기가 고유한 커넥터를 가지고 있었지만, USB-C 가 도입된 후에는 기기가 Mac 에 연결되었는지 PC 에 연결되었는지 신경 쓰지 않고 프로토콜만 따르면 됩니다.
아키텍처는 세 가지 계층으로 구성됩니다. 호스트(Host)는 사용자 대면 애플리케이션(Claude Code, Claude Desktop 또는 맞춤형 에이전트)으로, 요청된 내용을 해석하고 외부 데이터나 도구가 필요한지 결정합니다. 클라이언트(Client)는 호스트 내부에 존재하며 각 서버와 1:1 연결을 관리하고, 추상적인 요청을 구체적인 MCP 메시지로 변환하며 세션 수명 주기를 관리합니다. 서버(Server)는 프로토콜을 실제 시스템, 여기서는 Obsidian 볼트에 연결하여 MCP 요청을 네이티브 작업으로 변환합니다.
두 가지 속성이 이 프로토콜을 단순한 추상화 계층 그 이상으로 만듭니다. 첫 번째는 동적 기능 발견(dynamic capability discovery)입니다: 연결 시 클라이언트는 서버에게 무엇을 할 수 있는지 묻고, 서버는 실시간으로 응답합니다. 서버가 내일 새로운 기능을 추가해도 클라이언트가 이를 사용하기 위해 재프로그래밍될 필요가 없습니다. 두 번째는 지능과 데이터의 분리(decoupling)입니다: Obsidian 용 MCP 서버를 구축하는 사람은 어떤 모델이 이를 사용할지 알 필요가 없고, 에이전트를 구축하는 사람은 모델을 변경할 때마다 통합을 다시 구축할 필요가 없습니다.
MCP 서버는 세 가지 유형의 프리미티브를 노출합니다. 리소스(Resources)는 모델이 읽을 수는 있지만 수정할 수 없는 데이터입니다: 노트의 내용, 검색 결과, 역링크 그래프 등이 있습니다. 도구(Tools)는 모델이 능동적으로 호출할 수 있는 작업입니다: 노트 생성, 태그 업데이트, 구조화된 쿼리 실행 등이 있습니다. 프롬프트(Prompts)는 재사용 가능하고 매개변수화할 수 있는 명령 템플릿입니다. 예를 들어 "이 소스를 요약하고 해당 위키 페이지를 생성해줘"라는 작업을 매번 다시 작성해야 하는 자유 텍스트가 아닌 명명된 작업으로 정의할 수 있습니다.
Obsidian 에 구체적으로 적용하기
Obsidian 을 위해 특별히 구축된 MCP 서버는 이미 오픈 소스 생태계 내에 존재하며, 일반적으로 Obsidian 의 자체 로컬 REST API 플러그인을 기반으로 합니다. 이러한 서버는 에이전트가 정확한 폴더 구조를 미리 알 필요 없이 볼트에 대한 의미론적 검색, 노트 생성 및 편집, 태그 및 메타데이터 관리, 링크 그래프 읽기 등의 작업을 노출합니다.
실제로 변화하는 점은 미묘하지만 중요합니다: MCP 없이 Claude Code 는 사용자가 하나씩 설명한 규칙으로 볼트를 관리합니다. MCP 를 사용하면 볼트는 Claude Code 가 API 나 데이터베이스를 작동하듯이 정확히 작동할 수 있는 도구가 되며, 기능을 미리 암기하는 것이 아니라 연결 시점에 발견합니다. 그리고 이 동일한 연결은 Claude Code 뿐만 아니라 다른 모든 MCP 클라이언트에서도 작동합니다: 동일한 서버가 Obsidian 측에서 코드 한 줄도 건드리지 않고 다른 애플리케이션의 다른 에이전트에 공급될 수 있습니다.
실용적인 프레임워크: 세 가지 성숙도 수준
자신의 설정이 어디에 있는지 파악하기 위해 제가 사용하는 프레임워크는 다음과 같습니다:
레벨 0: 컨텍스트 수동 복사-붙여넣기. 모든 대화가 처음부터 시작되며, 사용자는 노트의 관련 부분을 채팅에 직접 붙여넣습니다. 특정 작업에는 효과적이지만 확장성은 없습니다.
레벨 1: 직접 파일 접근이 가능한 에이전트. 이 글의 78→180 페이지 예시를 포함한 대부분의 Claude Code + Obsidian 설정이 현재 있는 단계입니다. 에이전트는 명령어 파일에 설명된 규칙을 따라 볼트를 직접 읽고 씁니다. 이미 레벨 0보다 훨씬 강력하며, 단일 에이전트가 관리하는 단일 볼트의 경우 오랫동안 충분할 수 있습니다.
레벨 2: MCP 를 통해 연결된 에이전트. 볼트는 동적으로 발견 가능한 기능을 가진 서버로 노출되어, 여러 모델과 애플리케이션에서 재사용할 수 있습니다. 둘 이상의 에이전트, 둘 이상의 볼트, 또는 파일 단위 읽기 및 쓰기를 넘어서는 작업을 노출해야 할 필요가 생기는 즉시 의미를 갖습니다.
AI 관리 볼트의 이점을 누리기 위해 반드시 레벨 2로 바로 뛰어넘을 필요는 없습니다. 레벨 1만으로도 시스템이 전혀 없을 때와 비교하면 실질적인 도약입니다. 하지만 MCP 가 무엇을 해결하는지 이해하는 것은 이것이 어디로 가고 있는지 이해하는 것입니다: "내 AI 가 내 노트를 읽을 수 있다"에서 "내 지식은 모든 AI 가 작동할 수 있는 시스템이다"로 말이죠.
현재 귀하의 설정은 어떤 수준인가요? 댓글로 알려주세요. 충분한 관심이 있다면, 다음 글에서는 Obsidian 을 위한 첫 번째 MCP 서버를 설정하는 방법을 단계별로 안내해 드리겠습니다.
이 글이 도움이 되셨다면, 저를 팔로우해 주세요 @chesny
이 글은 시스템을 읽기만 하는 것이 아니라 작동시키는 에이전트에 대한 시리즈의 첫 번째 글입니다.
