Claude + Obsidian 실제로 써본 6개월 워크플로 — 잘 되는 것과 안 되는 것 솔직 정리

Posted on by

Claude를

Obsidian에 붙였다고 해서

세컨드 브레인이

자동으로 생기진 않는다.

오히려 반대다.

둘을 대충 붙이면

노트는 많아지고,

요약은 넘치고,

정작 나중에 다시 쓸 수 있는 지식은

별로 안 남는다.

지난 6개월,

대략 2025년 10월부터 2026년 4월 13일까지

이 볼트를 굴리면서

가장 크게 느낀 게 그거였다.

Claude는

정리를 잘해주는 도구가 아니라,

정리된 구조를 빨리 증폭시키는 도구

에 더 가깝다는 것.

구조가 괜찮으면

미친 듯이 편해지고,

구조가 흐리면

미친 듯이 어질러진다.

2026년 4월 13일 기준으로

Anthropic 공식 문서는

Claude Code가

터미널에서 동작하는 agentic coding tool이고,

CLAUDE.md 같은 메모리 파일을

계층적으로 읽는다고 설명한다.

Obsidian 공식 문서는

노트를 로컬 파일시스템 위의

Markdown plain text vault로 저장한다고 설명하고,

CLI와 Headless Sync도

별도 계층으로 안내한다.

이 공식 사실 위에

실제 운영 경험을 얹어보면

잘 되는 패턴과

안 되는 패턴이 꽤 선명하게 갈린다.

이 글은

기능 소개 글이 아니다.

6개월 정도 실제로 굴려보니 무엇은 오래 남고, 무엇은 계속 사고를 냈는가

를 정리한 운영 후기다.

한 줄 답

  • Claude는 노트의 원장이 아니라 노트를 가공하는 작업층으로 둘 때 제일 잘 맞았다.
  • Obsidian은 로컬 Markdown vault를 원장으로 두고, Claude는 인박스 정리·요약·초안·분류·운영 루틴 같은 bounded task에 붙일 때 효율이 컸다.
  • 반대로 볼트 전체를 매번 다 읽게 하기, 앱 포커스를 흔드는 자동화, 한 번 만든 요약을 곧바로 지식이라고 믿기는 계속 문제를 만들었다.
  • 지난 6개월 경험상 가장 오래 버틴 구조는 인박스 -> 위키/프로젝트 승격 -> 발행/운영 -> 메모리 업데이트 루프였다.

먼저 공식 문서가 말하는 바닥

경험담으로만 가면

사람마다 환경이 달라서

너무 흐려진다.

그래서 먼저

공식 문서가 깔아주는 바닥부터 짚자.

Anthropic의 Claude Code overview는

Claude Code를

터미널에서 동작하는 agentic coding tool로 설명한다.

파일 편집,

명령 실행,

외부 도구 연동,

MCP를 통한 외부 데이터 접근 같은 것들이

작업 계층이라는 얘기다.

그리고 memory 문서는

./CLAUDE.md,

~/.claude/CLAUDE.md 같은 메모리 파일이

세션에 자동 로드되고,

프로젝트 메모리와 사용자 메모리가

계층적으로 쌓인다고 설명한다.

즉

Claude 쪽 공식 세계관은

대화창 하나보다

작업 맥락 + 메모리 계층 + 실행 도구

쪽에 가깝다.

Obsidian 공식 문서도

비슷하게 중요한 사실을 하나 깔아준다.

Obsidian은 노트를

로컬 파일시스템의 vault 안에 있는

Markdown plain text 파일로 저장한다.

CLI 문서는

터미널에서 Obsidian을 제어하는 인터페이스라고 설명하고,

Headless 문서는

데스크톱 앱 없이도

명령줄에서 vault sync를 돌릴 수 있다고 안내한다.

이 두 가지를 합치면

결론은 꽤 분명하다.

Claude와 Obsidian의 조합은

AI가 생각하고, 노트앱이 기억한다

가 아니라,

로컬 파일 원장을 두고, AI가 그 위에서 작업한다

로 보는 쪽이 훨씬 덜 꼬인다.

지난 6개월 동안 제일 잘 된 것

잘 된 패턴은

의외로 화려하지 않았다.

오히려

조금 boring한 구조가

제일 오래 버텼다.

1. Obsidian을 원장으로 두고 Claude를 작업층으로 둔 것

이게 제일 컸다.

노트의 진짜 원장은

항상 Obsidian vault였다.

요약본이든,

프로젝트 메모든,

블로그 초안이든

최종 텍스트는

파일로 남아야 했다.

이 구조가 왜 좋았냐면

Claude 세션이 바뀌어도

원장은 안 바뀌기 때문이다.

세션은 휘발된다.

모델은 바뀐다.

도구도 바뀐다.

근데 vault는 남는다.

그래서 실제로 오래 버틴 패턴은

Claude에게 뭔가를 잘 기억시키는 법

보다

나중에 다른 세션이 와도 읽을 수 있게 파일로 남기는 법

이었다.

이 차이를 빨리 이해할수록

워크플로가 안정됐다.

2. 인박스와 위키를 분리한 것

두 번째로 좋았던 건

인박스를 지식 저장소처럼 안 쓴 거다.

실제로는

인박스에 들어오는 노트의 질이 들쭉날쭉하다.

URL 요약도 있고,

깨진 캡처도 있고,

중복도 있고,

나중에 버릴 노트도 있다.

이걸 전부

지식처럼 믿고 쌓으면

볼트가 금방 탁해진다.

그래서

00.Inbox

는 그냥 받은 편지함으로 두고,

쓸모가 검증된 것만

위키나 리소스 쪽으로 올리는 구조가

가장 효율적이었다.

실제 운영도

이 흐름에 맞춰 굴렀다.

/inbox 커맨드는

트리아지 후

AUTO는 @inbox-to-wiki,

애매한 건 queue,

보류는 defer로 흐르게 돼 있다.

핵심은

요약이 들어오는 순간을

지식 완성 시점으로 보지 않는다는 거다.

진짜 지식은

승격된 뒤에 생겼다.

3. no-focus 파일 운영

이건 생각보다 엄청 중요했다.

Obsidian 자동화를 한다고 하면

사람들은 자꾸 앱 UI를 움직이거나,

노트를 열고,

포커스를 바꾸는 쪽으로 생각한다.

근데 오래 써보니

그쪽은 사고가 많았다.

현재 이 워크스페이스도

기본 원칙을

filesystem/no-focus 모드

로 두고 있다.

.claude/scripts/obsidian-helper.sh도

기본 HELPER_MODE를 filesystem으로 두고,

safe-move는

CLI가 안 되면

그냥 파일시스템 기준으로 이동한 뒤

백링크 수동 검토 경고를 띄우는 방식이다.

이게 좋은 이유는 단순하다.

앱을 조작하는 자동화보다

파일을 조작하는 자동화가

재현성이 높고,

포커스를 덜 흔든다.

실제로 오래 버틴 워크플로는

거의 다 이 계열이었다.

직접 쓰기.

frontmatter 업데이트.

안전 이동.

로그 남기기.

다 화려하진 않은데

이상하게 제일 안 죽었다.

4. 메모리 계층을 얇고 명확하게 둔 것

Claude를 오래 쓰면

결국 메모리 관리 문제가 온다.

Anthropic 공식 문서가 말하듯

CLAUDE.md는

세션 바깥의 작업 규칙을 쌓는 계층이다.

실사용에서 도움이 됐던 건

메모리를 무겁게 만드는 게 아니라

계층을 분리한 거였다.

  • 프로젝트 공통 규칙은 AGENTS.md나 CLAUDE.md
  • 반복 워크플로는 skills와 commands
  • 최근 패턴 회피 같은 운영 메모는 recent-patterns.md
  • 아주 일시적인 상태는 로그나 시트

이렇게 역할을 나누니까

세션마다 똑같은 지시를

계속 다시 치지 않아도 됐다.

반대로

모든 걸 한 파일에 몰아넣었을 때는

읽는 사람도 AI도 같이 피곤해졌다.

5. 글쓰기와 지식 정리를 같은 vault에서 돌린 것

이건 장단이 모두 있었지만,

결과적으로는 장점이 더 컸다.

인박스 요약,

위키 정리,

블로그 초안,

대시보드,

패턴 메모가

같은 vault 안에 있으니

루프가 빨랐다.

새로운 요약이 들어오면

인박스에서 정리되고,

쓸만한 건 위키로 올라가고,

그중 일부가 블로그 아이디어나 발행 글로 이어졌다.

즉

Claude와 Obsidian 조합의 강점은

노트를 더 많이 만들게 하는 것

보다

같은 재료가 다른 산출물로 이어지게 만드는 것

에 있었다.

반대로 잘 안 됐던 것

이제 망한 쪽 얘기를 하자.

이게 오히려 더 중요하다.

1. 볼트 전체를 매번 한 번에 먹이려는 시도

이건 정말 자주 망했다.

처음엔

내가 쌓은 노트가 다 자산이니, AI가 다 읽으면 더 똑똑해지겠지

같이 생각하기 쉽다.

실제로는

문맥이 너무 넓어지면

노이즈가 훨씬 빨리 커진다.

중복 설명이 많아지고,

예전 규칙과 새 규칙이 섞이고,

이번 작업에 중요하지 않은 노트가

계속 튀어나온다.

지난 6개월 동안 가장 잘 통했던 건

전체 볼트 이해

가 아니라

이번 작업에 필요한 폴더와 문서만 선택해서 읽히기

였다.

Claude는

광대한 지식창고보다

잘 자른 작업 묶음에서 더 강했다.

2. 요약을 곧바로 지식이라고 믿은 것

이것도 꽤 큰 함정이었다.

Claude가 요약을 잘하니까

요약된 문장을 보면

왠지 이미 정리된 것처럼 느껴진다.

근데 실제로는

요약이 제일 위험할 때가 많다.

원문이 부실할 수도 있고,

캡처가 깨졌을 수도 있고,

맥락이 잘렸을 수도 있다.

그래서 인박스 단계 요약은

지식이 아니라

후보

로 보는 쪽이 맞았다.

실제로 이번에도

빈 캡처 수준인 노트 두 개는

위키에 억지로 넣지 않고

archive로 보냈다.

이런 판단이 없으면

볼트는 빨리 불어나지만

품질은 천천히 무너진다.

3. 앱 포커스를 건드리는 자동화

앞에서도 말했지만

이건 정말 자주 피곤했다.

앱을 열고,

커서를 옮기고,

활성 노트를 바꾸고,

창 포커스를 뺏는 식의 자동화는

데모에선 멋있어도

실사용에선 피로가 크다.

특히 글 쓰거나

다른 IDE랑 같이 돌릴 때는

포커스 뺏김이 바로 짜증으로 이어진다.

그래서 현재 운영도

명시적 opt-in 없이는

obsidian://,

open-note,

앱 포커스를 요구하는 흐름을

기본 차단한다.

이 원칙 하나만 지켜도

툴에 대한 스트레스가 꽤 줄었다.

4. 같은 기기에서 동시 쓰기 경로를 너무 많이 여는 것

Obsidian 공식 문서 기준으로도

CLI와 Headless Sync는

역할이 다르다.

CLI는 제어,

Headless는 sync다.

문제는

이걸 사용자가 욕심내서

같은 볼트에 대한 동시 쓰기 루프로

한꺼번에 섞기 시작할 때 생긴다.

앱도 쓰고,

headless sync도 돌고,

외부 스크립트도 frontmatter를 만지고,

다른 자동화도 파일을 옮기면

어느 순간부터

무슨 변경이 언제 들어갔는지

사람도 헷갈린다.

공식 문서가

이 조합을 모두 금지하는 건 아니지만,

실무적으로는

같은 기기 + 같은 볼트 + 동시 쓰기

를 줄일수록 안정성이 올라갔다.

이건 내가 계속 체감한 부분이다.

5. 모든 노트를 처음부터 구조화하려는 욕심

이것도 AI랑 붙이면 더 심해진다.

모든 노트에

frontmatter를 빡세게 넣고,

태그를 강하게 정하고,

온톨로지처럼 처음부터 정규화하고 싶어진다.

근데 실제로는

초반에 너무 강한 스키마를 넣으면

캡처 속도가 죽고,

나중에 다 뜯어고치게 된다.

지난 6개월 동안 오래 버틴 방식은

사람 인박스는 느슨하게 받고,

자주 쓰는 객체나 운영 문서만

조금 더 엄격하게 다루는 방식이었다.

즉

처음부터 다 구조화

보다

나중에 자주 쓰이는 것만 승격

이 훨씬 현실적이었다.

실제로 오래 버틴 루프

결국 워크플로는

거창한 아키텍처보다

매일 돌 수 있는 루프가 중요했다.

지금 기준으로

제일 오래 버틴 루프는 대략 이렇다.

단계 Obsidian 역할 Claude 역할 실패하기 쉬운 지점
캡처 인박스에 원문/요약 적재 요약, 1차 분류 요약 품질 과신
트리아지 queue, archive, 승격 후보 분리 분류, 중복 감지 애매한 노트 억지 분류
승격 wiki/resources/project 이동 구조화, 링크 정리 모든 노트 승격 시도
생산 블로그/문서/운영 산출물 작성 초안, 비교표, 정리 전체 vault 과투입
회고 패턴 메모, 대시보드, 로그 업데이트 반복 규칙 보강 한 파일에 전부 몰아넣기

이 루프에서

중요한 건

Claude가 모든 단계를 주도하는 게 아니라

각 단계에서 필요한 역할만 맡는다는 점이다.

캡처 단계에서는

추출과 요약.

트리아지에서는

분류와 의사결정 보조.

생산 단계에서는

초안과 재정리.

회고 단계에서는

반복 패턴 갱신.

이렇게 나누면

훨씬 덜 피곤했다.

지금 다시 시작하면 이렇게 깐다

만약 오늘 처음

Claude와 Obsidian 워크플로를 다시 깐다면

나는 훨씬 단순하게 시작할 거다.

1. 인박스 폴더 하나부터 만든다

처음부터 위키와 프로젝트를

복잡하게 설계하지 않는다.

먼저

받는 곳

하나를 만든다.

그리고 여기에 들어온 걸

사람이든 AI든

나중에 다시 triage할 수 있게만 해둔다.

2. 원장은 로컬 파일로 둔다

노트의 최종본이

어딘가 SaaS 화면 안에만 있으면

길게 보면 불안하다.

Obsidian의 장점은

로컬 Markdown 원장이라는 점이다.

이 장점은

생각보다 시간이 지날수록 커진다.

3. 자동화는 UI보다 파일 단에서 붙인다

파일 생성,

frontmatter 수정,

안전 이동,

로그 기록 같은

재현성 높은 것부터 붙인다.

UI 클릭 자동화는

나중으로 미룬다.

4. Claude는 bounded task부터 맡긴다

전체 볼트 해석보다

인박스 정리,

블로그 초안 작성,

비교표 만들기,

리팩터링 메모 정리처럼

작업 범위가 좁은 것부터 맡긴다.

이게 훨씬 낫다.

5. 메모리는 짧고 살아 있게 둔다

프로젝트 규칙,

반복 워크플로,

최근 패턴 정도만

얇게 관리한다.

메모리 파일이 백과사전처럼 커지면

읽는 사람도,

AI도,

결국 둘 다 둔해진다.

어떤 사람에게 이 조합이 잘 맞나

모든 사람에게

Claude + Obsidian 조합이 맞는 건 아니다.

특히 잘 맞는 사람은 이렇다.

  • 파일 기반 원장을 좋아하는 사람
  • 요약보다 재가공과 승격이 더 중요하다고 느끼는 사람
  • 인박스가 많고, 나중에 다시 쓰는 산출물이 필요한 사람
  • 글쓰기, 리서치, 운영 문서를 하나의 흐름으로 엮고 싶은 사람

반대로

바로바로 예쁜 결과물만 원하거나,

노트를 파일처럼 관리하는 감각이 너무 싫거나,

앱 안에서 모든 게 마법처럼 끝나길 바란다면

이 조합은 오히려 피곤할 수 있다.

결국 남는 건 이것이었다

지난 6개월 동안

Claude와 Obsidian을 같이 써보면서

결국 남은 건

아주 단순한 결론이었다.

Obsidian은

생각을 저장하는 곳이라기보다

다시 쓸 수 있는 형태로 남기는 곳

이었고,

Claude는

그 재료를 빠르게 잘라주고,

정리해주고,

초안을 밀어주는

작업 엔진에 가까웠다.

즉

둘을 잘 붙이는 방법은

AI를 노트앱 안에 밀어넣는 게 아니라

로컬 원장을 중심에 두고

AI를 주변 작업층으로 배치하는 거였다.

이 구도가 잡히면

생산성이 오른다.

이 구도가 흐리면

요약만 쌓이고

지식은 잘 안 남는다.

지난 반년 동안

진짜 차이를 만든 건

모델 성능보다

이 구조였다.

FAQ

Claude가 Obsidian 내용을 전부 기억하게 만들 수 있나

실무적으로는

그 생각부터 버리는 편이 좋았다.

전체 볼트를 다 기억시키려 하기보다

이번 작업에 필요한 문맥만

선별해서 읽히는 쪽이 훨씬 안정적이었다.

Obsidian을 AI 노트앱처럼 써도 되나

가능은 하지만

나는 원장 쪽 감각으로 쓰는 편이 더 오래 버텼다.

즉

노트 저장소는 Obsidian,

가공 작업은 Claude로 나누는 편이 덜 꼬였다.

앱 UI 자동화보다 파일 자동화가 나은 이유는 뭐였나

재현성과 포커스 보존 때문이다.

직접 파일을 쓰는 쪽이

앱 상태에 덜 흔들리고

다른 작업을 방해하지 않았다.

요약 노트는 바로 위키로 올려도 되나

내 경험상

그렇게 하면 품질이 금방 흐려졌다.

인박스에서 한 번 걸러지고,

실제로 재사용 가치가 확인된 것만

승격시키는 편이 훨씬 나았다.

Claude + Obsidian 조합에서 제일 중요한 한 가지를 고르면 뭔가

원장을 어디에 둘지다.

원장을 로컬 파일과 명확한 폴더 구조로 잡아두면

Claude는 강해지고,

그게 없으면

아무리 모델이 좋아도 계속 흐트러졌다.

관련 글

참고 자료/공식 출처