CyrilXBT — GPT-6 Astra × Obsidian vault 연결
Obsidian vault에 AI를 붙일 때 막히는 지점은 “노트 AI가 글을 못 써서”가 아니다. 싼 일상 작업과 오래전 디테일을 찾아 오는 깊은 종합을 한 설정으로 같이 못 푸는 것이 진짜 문제다. Astra는 그 레버—effort(추론 깊이를 단계로 조절하는 다이얼)와 검색—를 열어 주지만, 아키텍처 없이 자동으로 해결되지는 않는다.
CyrilXBT(@cyrilXBT)의 X 아티클 How to Connect GPT-6 Astra to Your Obsidian Vault…(2026-09-11)을 운영 설계의 눈으로 다시 정리한 글이다.
초안 작성과 문장 정리에 AI를 사용했다. 해석은 작성자 것이며 원문과 다를 수 있다. 수치와 대비는 원문의 주장이다.
vault 문제가 뭔지 (풀어서)
여기서 말하는 vault 문제는 Obsidian이 고장 났다는 뜻이 아니다. 연구·메모 vault가 수개월, 수년 쌓일 때 AI를 붙일수록 커지는 운영 모순이다.
1. 일이 한 종류가 아니다
같은 vault 안에도 성격이 다른 일이 섞인다.
일상 쪽은 새 자료를 넣고, 태깅하고, 위키 링크와 frontmatter를 맞추고, 한 노트를 보강하는 일이다. 잘 정의되어 있고 반복적이라, 비싸게·깊게 돌릴 이유가 거의 없다.
가끔 쪽은 이번 주 추가분과 몇 달 전 노트를 교차하고, 모순을 드러내고, “진짜 패턴”을 고르는 일이다. 여기에는 더 긴 숙고와, 오래된 구체 문장을 실제로 찾아 오는 힘이 필요하다.
한 모드에만 고정하면—항상 가볍게, 또는 항상 최대로—일상은 과하게 비싸지거나 종합은 얕아진다. 원문이 flat한 단일 effort를 문제로 보는 지점이 바로 여기다.
2. “창이 크다”와 “예전에 적은 한 줄을 찾는다”는 다르다
vault의 진짜 시험은 토큰을 많이 넣을 수 있는가보다, 석 달 전 노트에 있는 특정 claim을 다시 설명받지 않고도 정확히 꺼내는가다. 창만 크고 검색이 흐리면, 종합은 그럴듯해도 출처가 vault에 안 남는 글이 된다.
원문이 Sol 73.8% 대비 Astra 96.3%(512K–1M)를 내세우는 이유가 이것이고, 동시에 약 1/25는 놓친다는 전제라 인용 규율이 붙는다.
3. 도구를 잘못 고르면 문제가 바뀐다
파일로 충분한 일을 UI 클릭, 곧 computer-use(화면을 보고 조작하는 방식)로 하면 느리고 드리프트한다. 반대로 그래프·Canvas처럼 공간이 필요한 일을 파일 API만으로 하면 안 보인다. vault 문제의 일부는 모델이 아니라 연결 아키텍처—Method One과 Method Two— 선택이다.
4. 한 줄로
vault 문제는 이렇게 요약할 수 있다. (A) 싼 루틴과 비싼 종합이 공존하고, (B) 오래 쌓인 디테일 검색이 종합의 재료인데, (C) 연결·인용·티어를 안 짜면 모델만 바꿔도 같은 실패가 반복된다.
Astra가 건드리는 건 주로 (A)와 (B)의 모델 레버다. (C)는 프로토콜·티어·인용·체크포인트—원문이 설치 다음에 길게 쓰는 아키텍처 쪽이다.
다른 모델 대비, Astra가 이기는 축
원문이 끝까지 밀어 주는 대립은 「더 똑똑한 챗봇」이 아니다. vault가 수개월·수년 쌓일 때 생기는 두 문제를 한 모델이 같이 푸느냐다.
첫째, 일상 섭취는 싸게·빠르게 가야 한다. flat max는 비싸다.
둘째, 가끔의 깊은 종합은 오래전 노트의 구체 문장까지 찾아 추론해야 한다. 큰 창만으로는 부족하다.
아래 표는 원문이 내세운 축을 vault에서 무슨 뜻인지와 함께 정리한 것이다.
| 축 | Astra (원문) | 대비로 적힌 것 | vault에서 의미 |
|---|---|---|---|
| 추론 깊이 | low·medium·high·xhigh·max 5단 effort | 「한 모드에 고정」된 일반 패턴 | 섭취는 medium, 종합만 high/xhigh |
| 세션 중 전환 | effort를 대화 중간에 바꿔도 캐시 유지 | 설정 바꿀 때마다 컨텍스트를 다시 태우는 방식 | 같은 세션에서 루틴→심층 전환 |
| 장문맥 검색 정확도 | 512K–1M에서 96.3% | GPT-5.6 Sol 73.8%(동일 테스트) | “창이 크다”≠“석 달 전 한 줄을 찾는다” |
| 창 크기 | 약 1.1M | Claude Fable 5.1 1M 수준 | 방만 비슷하고, 검색 정확도에서 갈림 |
| 캐시 단가 | 읽기 $1/M | Fable 캐시 $0.25/M | Astra는 검색·effort 조합에 돈을 쓰고, Fable은 캐시 재사용에 유리 |
| 잘 맞는 일 | 루틴 섭취 + 가끔 깊은 vault 종합 | Fable: 장기 코딩·연구 지구력(Terminal-Bench 등). Kimi K3: 프론트·시각 — vault 종합엔 비추천 | 작업 성격에 맞게 고른다 |
표의 캐시는 이미 읽은 컨텍스트를 다시 태우지 않고 재사용하는 장치다. effort를 대화 중간에 바꿔도 캐시가 유지된다는 점이, 같은 세션에서 루틴에서 심층으로 넘어갈 때 비용을 아끼는 이유다.
원문의 핵심에 가깝게 쓰면 이렇게다. effort만 있으면 비용 문제는 풀려도 “석 달 전 디테일”을 못 찾고, 검색만 강하면 싼 루틴과 비싼 종합을 같은 깊이로 돌리는 강제 트레이드오프가 남는다. 둘을 같이 쓸 때 tiered vault 프로토콜이 성립한다.
모델 문제인가, 아키텍처 문제인가
앞 절의 강점이 “모델만 바꾸면 끝”인지, “설계가 필요한지”를 가려 보자. 원문을 한 줄로 쪼개면 아래와 같다.
| 질문 | 원문이 가리키는 답 |
|---|---|
| 모델의 문제인가? | 일부다. flat 단일 깊이·약한 장문맥 검색이면, 쌓인 vault의 “석 달 전 한 줄”과 “싼 루틴 vs 비싼 종합”을 같이 못 푼다. Astra가 내세우는 건 여기—5단 effort, 세션 중 전환과 캐시, 512K–1M 검색 96.3%(vs Sol 73.8%). |
| 아키텍처의 문제인가? | 나머지가 여기다. Method One/Two 선택, medium→종합만 상향, 인용 필수, 세션 번 체크포인트, Tier3로 내 vault 검증. 모델이 좋아도 전부 max·인용 생략·UI computer-use 기본이면 강점이 안 산다. |
| 그래도 Astra면 해결되나? | 아니다. 원문도 한계(약 20분 세션, 접근 게이트, 드리프트, 비용, 1/25 미스)와 “한 달 측정”을 같이 적는다. Astra는 풀 수 있는 레버를 준다. 레버를 안 짜면 Sol/Fable을 쓸 때와 같은 실패 모드가 남는다. |
정리하면, 모델이 문을 열고, 아키텍처가 문을 통과하는 동선이다. 문만 바꿔 놓고 동선이 없으면 “해결”이 아니다.
이 글이 다루는 것
클릭 설치를 나열하는 글이 아니다. 위 강점을 실제로 vault에 태우는 운영 설계—연결 패턴, 티어, 인용 규율, 한계—를 다룬다. 그래서 다음 절부터는 effort와 검색을 어떻게 붙일지, 연결은 어떤 두 갈래인지, 세션 전에 무엇을 물을지를 순서대로 적는다.
Effort + 검색을 vault에 태우는 법
effort의 기본은 medium에 planning을 더한 설정이다. 낮은 단계가 실패로 문서화된 뒤에야 xhigh·max로 올린다. 상시 max는 Astra의 비용 이점을 스스로 지운다.
원문이 제시한 티어 샘플은 다음과 같다.
- Tier1 medium — raw 섭취, 새 claim 추출, 기존 노트 확장. 모순은 덮지 않고 플래그한다.
- Tier2 high/xhigh — 주간 종합, 수개월 전 노트와 교차. 캐시를 유지한 채 세션 중 상향한다.
- Tier3 — 벤치가 아니라 내 vault에서 “몇 달 전 그 디테일”을 찾아 인용하게 하는 검색 테스트다.
한 주 샘플을 따라가면 이렇게 돌아간다. 월요일에 medium으로 섭취하고, 수요일에 모순을 플래그하고, 일요일에 상향 종합이 4개월 전 연결을 찾는다. 사람은 판단만 한다. flat 단일 effort였다면 월·수는 과하게 비싸거나, 일요일 교차는 얕아진다.
연결 패턴 두 가지
effort와 검색을 쓸 준비가 됐다면, 다음은 어떻게 연결할지다. 원문은 두 방법을 구분한다. 아래 표를 보기 전에 질문 하나만 기억하면 된다. 파일로 충분한가, 화면이 필요한가?
| Method One (기본) | Method Two | |
|---|---|---|
| 방식 | Local REST API + MCP 파일 연산 | Obsidian UI computer-use |
| 강점 | 구조화·빠름·일상 | 그래프·Canvas·API 없는 플러그인 등 공간·시각 |
| 원문 샘플 | kepano/obsidian-skills, /plugin marketplace add kepano/obsidian-skills |
플러그인 최소, 화면 접근 |
| 권고 | 기본 | 예외만 (느림·실험·드리프트) |
여기서 MCP(Model Context Protocol)는 모델이 파일을 구조화된 도구로 읽고·쓰고·검색하게 하는 연결 방식이다. computer-use는 앞에서 말했듯 화면을 보고 조작하는 방식이라, 느리고 드리프트하기 쉽다. 기본은 Method One이고, Method Two는 시각·공간이 필요할 때만 쓴다.
(살짝) MCP에서 문서 옵션을 건드릴 때
이 글의 본론은 effort·검색·티어다. MCP 클라이언트에서 Obsidian 문서 옵션을 세세히 설정하는 방법은 논외로 두고, 원문이 가리키는 위치만 짚는다.
Method One에서는 보통 (1) Obsidian Local REST API 플러그인으로 vault를 로컬 API로 열고, (2) 그 API 키를 Claude Code·Codex 같은 클라이언트의 MCP 연결 설정에 넣으며, (3) 모델이 “그냥 .md”가 아니라 Obsidian답게 쓰도록 문서 관습을 가르친다. 원문 샘플이 kepano/obsidian-skills와 /plugin marketplace add kepano/obsidian-skills인 이유가 여기다. wikilink, callout, Bases, JSON Canvas처럼 렌더링되는 문서 옵션을 에이전트 쪽에 심는 축약 경로다.
같은 취지로, 원문의 ASTRA VAULT PROTOCOL 스타일 설정 파일에는 “generic markdown이 아니라 Obsidian 관습을 따를 것”, “새 노트 전에 기존 노트를 확장할 것” 같은 문서 동작 옵션이 effort 기본값 옆에 붙는다. 키·경로·플러그인 화면을 클릭으로 나열하진 않는다. 다만 기억할 한 줄은 이것이다. MCP로 파일을 읽히게만 하고 문서 옵션(관습·스킬·프로토콜)을 안 주면, Astra 검색이 좋아도 출력은 vault에 안 맞는 메모가 되기 쉽다.
세션 전 매뉴얼 (Astra 강점 쓰기)
연결까지 정했다면, 마지막은 이번 세션에 Astra 강점을 켤지 판별하는 문이다. 답이 「예/아니요 + 한 줄 이유」로 안 나오면, 모델을 바꿔도 아키텍처는 안 켠 것에 가깝다.
| # | 질문 | 의미 | 기대 답 (원문 기준) |
|---|---|---|---|
| 1 | 오늘이 섭취면 medium, 종합이면 high/xhigh로 올릴 이유가 문서화됐는가? | effort 예산을 어디에 쓸지 | 섭취·태깅 → medium. 주간 교차·모순 정리 → high/xhigh(+이유). 이유 없는 max → 아니요 |
| 2 | Sol 대비 내세운 검색 정확도를 쓰려면, “오래전 구체 문장”을 찾는 과제가 있는가? | 96.3% vs 73.8% 이점을 쓸 과제가 있는지 | 석 달 전 claim·모순 출처 등이 있으면 예. 오늘 새 노트만이면 그 강점은 거의 안 씀 |
| 3 | effort를 올릴 때 같은 세션·캐시 유지로 가는가, 새 세션으로 끊어 버리는가? | mid-conversation 전환+캐시 이점을 깨는지 | 루틴→심층은 같은 세션에서 상향. 심층만 새 창이면 캐시 이점 포기 |
| 4 | 주장마다 vault 출처 노트를 붙일 수 있는가? | 약 1/25 미스·환각 종합 방지 | 경로/노트 인용. 못 붙이면 “완료”로 안 침 |
| 5 | Method Two인가? 정말 시각·공간인가? | UI computer-use는 예외 | 그래프·Canvas·API 없는 UI → Two. 파일 읽고 쓰기 → One(기본) |
한계 (강점과 같이 적기)
강점만 외우면 운영이 깨진다. 아래는 원문이 같은 글에서 한계로 적어 둔 것들이다. “Astra라서 안 된다”가 아니라, 레버를 쓸 때 어디에 브레이크가 걸리는지를 미리 아는 쪽이다.
1. 세션이 생각보다 빨리 닳는다
원문은 Plus Codex 계열에서 세션 한도가 약 20분 안의 평범한 작업으로도 소진될 수 있다고 적는다. 벤치 점수와 체감 길이가 다르다는 뜻이다.
깊은 종합(Tier2)을 “한 세션에 끝낸다”고 가정하면, 중간에 끊겼을 때 처음부터 다시 읽게 된다. 그래서 원문이 강조하는 대응은 체크포인트다. 예산이 닳기 전에, 지금까지 본 것·남은 것을 vault 안 status 노트에 남겨 다음 세션이 이어 받게 한다. 강점인 장문맥을 쓰더라도, 세션 길이 한도는 별개의 제약이다.
2. 접근 경로가 열려 있지 않을 수 있다
원문 기준 Astra는 당시 ChatGPT Plus의 Work·Codex 쪽에 있고, 일반 Chat 화면을 기본으로 두면 안 된다. (일반 Chat 쪽은 Pro 플랜 이야기도 원문에 함께 나온다.)
워크플로를 짜기 전에 “우리 계정·화면에서 실제로 Astra가 보이는가”를 확인하지 않으면, 티어 설계는 종이 위에서만 완성된다. 모델 능력 문제가 아니라 제품 표면·요금제 게이트 문제다.
3. computer-use(Method Two)는 어긋나기 쉽다
화면을 보고 클릭하는 방식은 Obsidian UI 상태가 조금만 바뀌어도(창 포커스, 배율, 모달, 노트 이름 변경) 클릭이 빗나갈 수 있다. 원문은 이를 드리프트로 부른다.
그래서 Method Two는 “더 멋진 기본값”이 아니라 공간·시각 작업용 예외다. 긴 클릭 연쇄를 믿지 말고, 의미 있는 단계마다 화면을 확인해 달라고 요구하는 편이 안전하다. 파일로 되는 일을 Two로 옮기면, 한계가 일상 속도까지 잡아먹는다.
4. 비용은 토큰 수만이 아니다
원문이 적는 형태는 대략 입력 $10 / 출력 $50 per M tokens, 캐시 읽기 $1/M, 입력 272K를 넘으면 요청 단위로 $20/$75 할증이다. Fable 쪽 캐시($0.25/M)와 비교하면, Astra는 같은 문맥을 자주 다시 읽는 짧은 세션보다, effort를 올려 가끔 깊게 가는 패턴에 맞춰야 수지가 맞기 쉽다.
effort를 전부 high로 고정하면 Sol 대비 검색 이점과 상관없이 비용 이점이 먼저 사라진다. 티어를 나누는 이유가 성능만이 아니라 한계(비용) 대응이기도 하다.
5. 96.3%는 평균이지, 매 질문 보증이 아니다
512K–1M 검색 96.3%는 원문이 내세우는 강점이지만, 동시에 대략 25번에 한 번은 놓친다는 말이다. 통제된 벤치지, 내 vault의 노트 밀도·서식과는 다를 수 있다.
그래서 Tier3(내 vault에서 오래된 디테일을 찾아 인용하게 하기)와 출처 없는 종합은 완료로 치지 않기가 한계 대응이다. 숫자를 믿되, 내 창고에서 한 번 더 재는 것이다.
6. 흔한 실수 = 한계를 무시한 운영
원문과 같은 줄에 두면 이렇게 이어진다.
- 모든 일을 high로 고정 → 세션·비용 한계를 스스로 키움, Astra 대비 이점 소멸
- Method Two를 기본값으로 → 드리프트·속도 한계가 일상화
- 인용 생략 → 1/25 미스가 “그럴듯한 오종합”으로 쌓임
- 벤치만 믿고 Tier3 생략 → 내 vault에서는 강점이 검증되지 않음
효과는 원문대로 한 달 단위로 본다. 영리한 한 세션은, 한계를 넘었는지 알기엔 표본이 너무 작다.
출처
- CyrilXBT (@cyrilXBT), How to Connect GPT-6 Astra to Your Obsidian Vault and Get Reasoning Depth No Other Model Gives You (2026-09-11): https://x.com/i/article/2098140027746242570
- 소개 포스트: https://x.com/cyrilXBT/status/2098433272573214816
운영 설계 정리. 벤치·단가는 원문 주장. AI 보조 작성.
댓글