MCP의 목적은 여러 모델이 같은 Vault를 이용하게 하는 것이다
주장
DanzzaN이 계획하는 원격 MCP의 목적은 모바일과 PC의 여러 모델이 같은 canonical Markdown Vault를 필요한 만큼 읽고, 명시적으로 요청된 반영 작업을 수행하게 해 세션 사이의 수동 전달 비용을 줄이는 것이다. 특정 모델의 스킬 묶음을 영구 보존하거나 모든 대화를 자동 기억하는 서버를 만드는 것이 목적은 아니다.
대화를 옮기는 부담과 지식 상태의 연속성
현재는 모바일 ChatGPT·Claude 대화를 공유하거나 복사해 Codex에 전달한 뒤 Vault 승격을 요청해야 한다. 대화를 옮기는 데 드는 수고는 어떤 지식을 남길지 판단하는 일과 별도로 발생한다. 공용 인터페이스가 있으면 현재 대화를 가진 모델이 기존 Vault를 직접 대조해 승격하고, 다른 모델은 이미 반영된 Markdown 상태를 읽을 수 있다. 각 서비스의 대화 기록을 넘겨받는 대신, 여러 모델이 같은 지식 상태에서 이어 가게 하려는 구상이다.
모델의 해석과 MCP의 동작
현재 대화 + 현재 모델 + 필요한 최소 지침
↓ 요청
MCP의 인증·탐색·링크·쓰기 인터페이스
↓
canonical Markdown Vault- MCP는 요청받은 읽기·검색·링크 조회·쓰기 동작과 권한·경로·저장 일관성 같은 기술 제약을 담당한다.
- LLM은 현재 대화와 관련 기록을 해석해 읽을 노트와 도구를 선택한다. 제목 목록을 먼저 보고 필요한 노트를 읽는 탐색이 가능해야 한다.
- 지침이나 Skill은 꼭 필요한 실행 보완만 제공하며, 공통 Skill이 필수 중간 계층이라는 전제를 두지 않는다.
- 기본 이용 방식은 최소 진입 지침으로 Vault를 발견한 뒤 필요한 지식·절차·기록 계약을 Markdown에서 직접 읽는 것이다. 스킬의 이름·설명에 의존하던 발견은 문서 목록·검색·Map·링크로 대체하고, 스킬 고유 호출·실행 기능의 필요는 따로 판단한다.
- 사용자는 canonical knowledge 변경을 시작하는 경계를 통제한다.
- Obsidian은 같은 맥락을 사람이 검사하는 보조 도구다. 원격 정본과의 상시 동기화는 이 목적의 필수 조건이 아니다.
보장 경계
- 이 노트는 MCP의 도입 목적과 설계 방향을 기록하며 서버가 이미 구축됐다는 뜻이 아니다.
- GitHub 정본 전환, 클라이언트별 검증과 운영 상태는 원격 Vault 전환 실행계획에서 별도로 확인한다.
- 각 서비스의 모바일 MCP 지원, 인증 방식, AWS 구성과 지연시간은 공식 원천 및 실제 측정으로 별도 검증해야 한다.
- 원격 인터페이스가 생겨도 자동 지식화하지 않는 원칙은 유지한다.
근거
- MCP와 Epistemic Twin 운영 구상 - ChatGPT 공유 대화에서 DanzzaN은 여러 모델·기기가 같은 스킬과 Markdown 맥락을 공유하는 것이 목적이라고 밝혔다.
- 같은 대화에서 모바일 대화를 Codex에 수동 전달하는 현재 병목과 24시간 MCP를 두려는 이유를 설명했다.
- 원격 Vault 정본과 쓰기 운영 결정 - Codex 대화 > Vault 직접 읽기로 스킬 역할 대체에서 수시 Vault 조회를 스킬의 문서 역할을 대체하는 기본 경로로 채택했다.
- 원격 Vault 정본과 쓰기 운영 결정 - Codex 대화에서 여러 AI가 같은 맥락을 보는 목적을 다시 확인하고, Obsidian의 보조 역할과 스킬 최소화를 명확히 했다.