MCP는 필요 없었다 :: Claude Code + Obsidian 진짜 통합기

문제가 없는 곳에서 문제를 찾고 있었다

"Obsidian CLI가 제공된다고 하는데, Claude Code랑 같이 쓰면 어떻게 될까?"

이 질문 하나가 오늘의 탐구를 시작하게 했다. 솔직히 처음엔 단순한 호기심이었다.

 

Obsidian(마크다운 기반의 개인 지식 관리 앱)과 Claude Code를 같이 쓰면 뭔가 더 강력해지지 않을까, 하는 막연한 기대.

진짜 문제는 "어떻게 연결하냐"가 아니라, "연결이 필요한지 아닌지부터 따져야 한다" 는 것이었다.

---

두 가지 선택지

Claude Code + Obsidian 통합 방법은 크게 두 가지로 나뉜다.

---

방식 A: MCP (Model Context Protocol)

https://github.com/iansinnott/obsidian-claude-code-mcp

GitHub - iansinnott/obsidian-claude-code-mcp: Connect Claude Code and other AI tools to your Obsidian notes using Model Context

 

MCP는 Claude Code가 외부 시스템에 연결할 수 있도록 해주는 프로토콜이다.

쉽게 말하면, Claude Code와 Obsidian 사이에 실시간 통신 채널을 열어주는 파이프다.

Obsidian에 플러그인을 설치하고, Claude Code 설정에 서버 주소를 등록하면 둘이 연결된다.

{
  "mcpServers": {
    "obsidian": {
      "command": "npx",
      "args": ["mcp-remote", "http://localhost:22360/sse"]
    }
  }
}

---

방식 B: Obsidian CLI Skill

https://github.com/pablo-mano/Obsidian-CLI-skill

GitHub - pablo-mano/Obsidian-CLI-skill: Obsidian Skill for Claude Code and other agents

 

Obsidian 1.12 버전부터 공식 CLI(터미널에서 명령어로 앱을 제어하는 기능)가 제공된다.

이 CLI를 Claude Code의 스킬로 등록하면 /obsidian search 키워드 같은 명령어로 vault를 제어할 수 있다.

Obsidian CLI

obsidian search query="wwise fade" format=json
obsidian daily:append content="- [ ] 오늘 할 일"

둘 다 그럴듯해 보였다. 그런데 여기서 첫 번째 함정이 등장한다.

---

"토큰이 더 들지 않나?"

"MCP 기반으로 설정하면 토큰 소모가 많이 들지 않아?"

AI 도구를 많이 써본 사람이라면 토큰에 민감해진다.

토큰이 많이 쓰일수록 비용이 올라가고 응답이 느려진다. 그런데 실제로 비교해보면 결론은 이렇다.

	MCP 방식	CLI Skill 방식
파일을 읽는 주체	Claude가 자동 판단	사용자가 명시적 호출
토큰 소모 결정 요소	읽는 파일의 양	읽는 파일의 양
제어권	낮음	높음

MCP가 토큰을 더 쓰는 게 아니다. 결국 "얼마나 많은 파일을 읽느냐"가 토큰을 결정한다.

MCP는 Claude가 스스로 판단해서 파일을 읽기 때문에 의도치 않게 많이 읽을 수 있다는 차이가 있을 뿐이다.

 

CLI Skill이 더 유리한 이유는 토큰 절약이 아니라 명시적 제어다.

---

그런데, 진짜 함정은 여기 있었다

MCP vs CLI Skill을 비교하느라 정작 핵심을 놓치고 있었다.

D:\Unreal Projects\GAS\
└── Docs\
    ├── Audio_Refactor_Plan.md
    ├── todo.md
    └── ...

프로젝트 문서가 이미 프로젝트 폴더 안에 있다.

 

Claude Code는 Read, Write, Edit, Grep, Glob 같은 내장 도구를 통해 경로만 알면 시스템 어디든 파일에 접근할 수 있다. Obsidian MCP도, CLI Skill도 필요 없다. 그냥 "이 파일 읽어줘"라고 하면 된다.

 

이 사실을 확인하기 위해 시험해봤다.

<!-- todo.md 수정 전 -->
- [ ] `UGS_MapAudioConfig` DataAsset 클래스 추가

<!-- Edit 도구로 한 줄 수정 -->
- [x] `UGS_MapAudioConfig` DataAsset 클래스 추가

실행하니까 됐다. 아무 플러그인도, 아무 MCP 설정도 없이.

도구를 추가하기 전에 먼저 "지금 가진 도구로 이미 되는 게 아닐까?"를 물어봐야 한다.

---

그렇다면 언제 MCP가 필요한가

모든 게 불필요하냐 하면, 그건 아니다. 딱 한 가지 케이스가 있다.

프로젝트 폴더 밖에 있는 vault.

 

내 경우 D:\Obsi에 개인 지식 저장소가 있다.

D:\Obsi\
├── Development\
│   ├── WWise\
│   └── 언리얼 엔진\
├── AI STUDY\
└── 경제(재테크)\

이건 어떤 프로젝트에도 속하지 않는, 순수하게 개인적인 지식 베이스다.

Wwise 학습 노트, 언리얼 엔진 정리, AI 툴 사용기가 쌓여 있다.

 

이 vault의 내용을 코딩 중에 참조하고 싶다면 — 그때 비로소 연결이 의미를 갖는다.

그런데 여기서도 MCP가 최선이냐는 다시 검토할 필요가 있다.

---

MCP 설치를 시도했다가 멈춘 이유

Obsidian 커뮤니티 플러그인에서 claude code mcp를 검색했다.

검색 결과에는 MCP Tools, Tars, Open in Terminal 등 8개 플러그인이 나왔지만, 처음에 안내했던 obsidian-claude-code-mcp는 없었다. (따로 다운받아서 해야 하나본데... 귀찮다)

 

대신 더 간단한 방법이 있었다.

claude mcp add obsidian-vault npx -- @modelcontextprotocol/server-filesystem "D:/Obsi"

Filesystem MCP다.

Obsidian이 실행 중인지와 관계없이 D:/Obsi 폴더에 직접 접근할 수 있게 해주는 방식이다.

Obsidian 전용 플러그인이 전혀 필요 없다.

 

그런데 이것도 사실 과잉이다.

 

Claude Code의 내장 도구는 이미 어느 경로든 접근 가능하다.

D:\Obsi도 예외가 아니다. 내가 직접 경로를 알려주거나,

CLAUDE.md에 vault 위치를 적어두면 Claude가 알아서 참조한다.

 

최종 결론: MCP 설치 없이, 플러그인 없이, vault 경로를 알려주면 충분하다.

---

그래서 만든 것: /vault 커스텀 스킬

복잡한 설정 대신, 하나의 커스텀 스킬을 만들었다.

Claude Code의 스킬(.claude/commands/ 폴더에 마크다운 파일을 넣으면 /명령어로 호출할 수 있는 기능)을 활용했다.

~/.claude/commands/vault.md 파일 하나로 이런 게 가능해진다.

/vault                    → 현재 작업 관련 노트 자동 추천
/vault search wwise fade  → D:\Obsi에서 fade 키워드 검색
/vault ref AudioManager   → 관련 참고 노트 요약 후 프로젝트와 연결점 제시
/vault read WWise/언리얼엔진 연동/GS_AudioManager 설계
/vault note 오늘 구현 내용 기록
/vault sync               → todo.md 현황을 vault에 기록

스킬 파일의 핵심은 단순하다.
두 저장소의 위치와 구조를 명시해두고, 각 명령어가 무엇을 해야 하는지 자연어로 기술하면 된다.
Claude가 나머지를 처리한다.

---

스킬을 테스트하다가 발견한 것

/vault read로 GS_AudioManager 설계.md를 열었을 때 예상치 못한 내용이 나왔다.

// 초기 설계 당시 AudioManager (vault 기록)
UCLASS()
class GAS_API UGS_AudioManager : public UGameInstanceSubsystem
{
    void PlayEvent(UAkAudioEvent* Event, AActor* Context);
    void SetSwitch(FName SwitchGroup, FName SwitchState, AActor* Context);
    void SetRTPC(FName RTPCName, float Value, AActor* Context);
};

예전에는 프로젝트에서 사용하기로 생각한 API가 단 3개였다. PlayEvent, SetSwitch, SetRTPC.

현재 진행 중인 Audio Refactor Phase 1-B는 복잡도가 상당히 올라가 있다.

MapAudioConfig, StartCombatSequence, StartBossSequence... 기능이 추가되면서 자연스럽게 커진 것이지만, 초기 설계의 단순함을 다시 보니 "지금 과도하게 복잡해진 건 아닌가?"라는 질문이 생긴다.

 

vault가 단순한 메모장이 아니라, 과거의 기록이 현재의 자신에게 보내는 코드 리뷰가 된 셈이다.

---

정리: 오늘 배운 것

1. 먼저 기존 도구로 되는지 확인하라. Claude Code는 경로만 알면 어디든 파일에 접근할 수 있다. MCP나 플러그인이 필요한 케이스는 생각보다 적다.
2. 외부 vault + 복잡한 검색이 필요할 때만 MCP를 고려하라. 단순 파일 접근은 Filesystem MCP 한 줄이면 충분하고, 그것조차 내장 도구로 대체 가능하다.
3. 커스텀 스킬은 강력하다. 설정 파일 하나로 Claude의 행동 패턴을 프로젝트에 맞게 특화시킬 수 있다. vault의 구조를 알고 있는 AI 어시스턴트를 갖게 되는 것과 같다.
4. 지식 저장소의 진짜 가치는 나중에 드러난다. 그날그날 기록한 사운드 설계 문서가 6개월 뒤 리팩토링 과정에서 참고 기준이 됐다. 기록은 미래의 자신을 위한 투자다.

---

실제 적용해보려면

Claude Code 커스텀 스킬 만들기:

mkdir -p ~/.claude/commands

~/.claude/commands/vault.md 생성 후:

# Vault Assistant
**Vault 경로**: D:\Obsi (또는 자신의 vault 경로)

$ARGUMENTS에 따라:
- `search <키워드>`: vault 전체 검색
- `read <경로>`: 특정 노트 읽기
- `note <내용>`: 오늘 날짜 작업일지에 추가
- `sync`: 현재 프로젝트 todo 현황을 vault에 기록

---

CLAUDE.md에 vault 위치 명시:

## Personal Knowledge Vault
- 위치: D:\Obsi
- 주요 경로: Development/WWise/, Development/언리얼 엔진/

이걸로 끝이다.

복잡한 설정 없이, Claude Code는 이제 개인 지식 저장소를 알고 있다.