문서를 연결하면 바로 체감된다
MCP를 처음 써 볼 때 가장 효과가 빠른 분야는 문서다. 이유는 단순하다. 많은 업무가 이미 문서 안에 있기 때문이다. 회의록, 기획안, 고객 응대 정책, 개발 런북, 리서치 메모, 프로젝트 README가 흩어져 있을 뿐이다.
AI에게 "이 문서를 읽고 요약해 줘"라고 파일을 하나씩 올리는 방식도 쓸 수 있다. 하지만 매번 파일을 찾아 첨부해야 하고, 여러 문서를 비교하려면 사용자가 자료를 계속 골라 줘야 한다. MCP로 파일 시스템이나 지식베이스를 연결하면 흐름이 달라진다. AI가 허용된 범위 안에서 폴더를 탐색하고, 관련 문서를 찾고, 읽고, 요약하고, 초안을 만들 수 있다.
여기서 핵심은 "모든 문서를 AI에게 열어 주자"가 아니다. 정반대다. AI가 읽어도 되는 문서와 절대 읽으면 안 되는 문서를 먼저 나누고, 필요한 폴더만 연결하는 것이 출발점이다.
AI 생성 이미지
로컬 파일을 연결하는 기본 구조
파일 시스템 MCP 서버는 로컬 컴퓨터의 특정 폴더를 AI 앱에 연결한다. 서버는 보통 파일 읽기, 여러 파일 읽기, 디렉터리 목록 보기, 파일 검색, 파일 정보 확인 같은 읽기 기능을 제공한다. 구현에 따라 파일 생성, 파일 수정, 이동처럼 실제 파일 상태를 바꾸는 기능도 함께 제공할 수 있다.1
가장 먼저 만들 폴더 구조는 다음처럼 단순한 편이 좋다.
MCP-Workspace/
readable/
meetings/
research/
project-docs/
runbooks/
writable/
drafts/
checklists/
private-do-not-connect/
contracts/
personal/readable: AI가 읽고 참고할 수 있는 문서writable: AI가 초안, 요약, 체크리스트를 만들어도 되는 작업 폴더private-do-not-connect: 연결하지 않을 민감 문서
중요한 점은 민감 문서를 "프롬프트로 읽지 말라고 지시"하는 것이 아니라, 처음부터 MCP 서버의 허용 경로 밖에 두는 것이다. 모델은 지시를 오해할 수 있지만, 서버가 접근할 수 없는 경로는 읽을 수 없다.
Claude Desktop이나 Cursor 같은 Host의 설정은 대체로 다음과 같은 형태다. 실제 설정 파일 위치는 환경 구성에서 다룬 Host별 경로를 따르면 된다.
{
"mcpServers": {
"local-docs": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/you/MCP-Workspace/readable",
"/Users/you/MCP-Workspace/writable"
]
}
}
}이 설정은 두 폴더만 파일 시스템 서버에 넘긴다. AI가 바탕화면 전체, 홈 디렉터리 전체, 다운로드 폴더 전체를 볼 수 있게 하지 않는다. 처음에는 범위를 좁게 잡아야 한다. 필요하면 나중에 폴더를 추가한다.
연결 뒤에는 바로 실무 질문을 하기 전에 확인 질문부터 던진다.
현재 접근 가능한 디렉터리 목록을 알려줘.
각 디렉터리에서 상위 2단계까지만 구조를 보여줘.파일 시스템 서버에는 허용된 디렉터리 목록을 확인하는 기능이 제공될 수 있다.1 이 확인 과정은 사소해 보이지만 중요하다. AI가 어떤 문서 영역을 보고 있는지 사용자가 먼저 알아야 한다.
읽기 전용과 쓰기 권한을 분리한다
문서 연결에서 가장 흔한 실수는 읽기와 쓰기를 한 서버에 섞어 놓고 아무 작업이나 시키는 것이다. "회의록을 요약해 줘"라고 했는데 원본 파일을 수정하거나, "초안을 만들어 줘"라고 했는데 기존 문서를 덮어쓰면 곤란하다.
운영 원칙은 간단하다.
원본 문서 폴더는 읽기 중심으로 둔다.
AI가 생성한 결과물은 별도 작업 폴더에 쓰게 한다.
원본 수정은 사용자가 명시적으로 승인할 때만 허용한다.
설정만으로 모든 서버가 폴더별 읽기 전용을 완벽히 지원한다고 가정하면 안 된다. 파일 시스템 MCP 서버가 허용 경로를 제한하더라도, 그 경로 안에서 어떤 쓰기 도구가 노출되는지는 서버 구현과 실행 환경에 따라 다르다. 따라서 안전하게 운영하려면 OS 권한, 별도 복사본, 컨테이너의 읽기 전용 마운트 같은 외부 장치까지 함께 쓰는 편이 좋다.
실무에서는 다음처럼 나눈다.
원본 자료: /Users/you/MCP-Workspace/readable
AI 작업물: /Users/you/MCP-Workspace/writable프롬프트도 명확히 한다.
readable 폴더의 원본 파일은 수정하지 마.
writable/drafts 폴더에 새 Markdown 파일로 요약본을 만들어.
파일명은 2026-07-회의록-요약.md 형식으로 해.가능하다면 원본 폴더는 운영체제 권한으로 쓰기를 막는다. 더 엄격한 환경에서는 Docker 같은 컨테이너로 원본 폴더를 읽기 전용으로 마운트하고, 결과물 폴더만 쓰기 가능하게 둔다. 핵심은 "AI에게 조심하라고 말하기"보다 "실수해도 원본을 못 바꾸게 만들기"다.
바로 써먹는 문서 워크플로
파일과 문서 MCP 연결의 목적은 검색창을 하나 더 만드는 것이 아니다. 반복 업무를 줄이는 것이다. 다음 네 가지부터 시작하면 효과를 빨리 느낄 수 있다.
1. 회의록 요약
회의록 폴더를 연결한 뒤 이렇게 요청한다.
meetings 폴더에서 이번 주 회의록을 찾아줘.
각 회의의 결정 사항, 담당자, 마감일을 표로 정리해 줘.
불확실한 항목은 "확인 필요"로 표시해.좋은 출력은 단순 요약이 아니라 후속 행동을 만든다. "누가 무엇을 언제까지 해야 하는가"가 나오면 업무 관리 도구에 옮기기 쉽다.
2. 리서치 자료 비교
research 폴더의 MCP 관련 리서치 메모를 읽고,
공통으로 반복되는 주장 5개와 서로 충돌하는 주장 3개를 구분해 줘.
각 항목마다 근거가 된 파일명을 붙여 줘.비교 작업에서는 출처 파일명이 중요하다. AI가 그럴듯한 결론만 말하면 검증하기 어렵다. 항상 "어떤 파일을 근거로 했는지"를 함께 요구한다.
3. 초안 작성
project-docs 폴더의 제품 설명 문서를 참고해서
신규 고객용 온보딩 이메일 초안을 작성해 줘.
원본 문서는 수정하지 말고 writable/drafts에 Markdown 파일로 저장해.이때 AI는 기존 문서를 문체와 사실의 기준으로 삼는다. 사람은 빈 화면에서 시작하지 않아도 된다. 단, 고객에게 발송되는 문장은 반드시 사람이 마지막 검토를 해야 한다.
4. 체크리스트 생성
runbooks 폴더의 배포 관련 문서를 읽고
배포 전 점검 체크리스트를 만들어 줘.
각 항목은 "확인 방법"과 "실패 시 조치"를 포함해.체크리스트는 문서 활용의 좋은 결과물이다. 긴 문서를 실행 가능한 절차로 바꿔 주기 때문이다. 개발팀이라면 배포, 장애 대응, 코드 리뷰에 바로 적용할 수 있다. 운영팀이라면 계약 검토, 콘텐츠 발행, 고객 응대 품질 점검에 쓸 수 있다.
Notion, Google Drive, Obsidian, 사내 위키는 구조가 다르다
모든 문서 도구를 같은 방식으로 보면 안 된다. MCP 입장에서는 "문서 저장소"처럼 보이지만, 실제 연결 구조와 권한 모델이 다르다.
로컬 파일과 Obsidian은 가장 단순하다. Obsidian Vault는 대개 로컬 Markdown 폴더다. 파일 시스템 MCP 서버로 Vault의 일부 폴더만 연결하면 된다. 장점은 빠르고 투명하다는 점이다. 어떤 파일을 읽는지 경로로 확인할 수 있다. 단점은 동기화 상태와 로컬 파일 권한을 사용자가 직접 관리해야 한다는 점이다.
Notion은 워크스페이스와 페이지 권한이 중심이다. Notion의 원격 MCP는 AI 도구가 Notion이 호스팅하는 MCP 서버에 연결하고, OAuth로 사용자의 워크스페이스 접근을 승인하는 구조다.2 Notion 공식 로컬 MCP 서버를 쓰는 방식도 있으며, 이 경우 내부 통합 토큰을 설정하고 접근시킬 페이지나 데이터베이스를 연결한다.3 다만 Notion은 현재 원격 MCP를 우선 지원하는 흐름이므로, 새로 시작한다면 먼저 원격 MCP를 검토하고 로컬 서버는 필요한 경우에만 선택하는 편이 좋다. Notion은 페이지 작성과 데이터베이스 작업이 강력하지만, MCP 도구가 사용자의 Notion 권한 안에서 읽기와 쓰기를 수행할 수 있으므로 처음부터 전사 공간 전체를 연결하지 않는 편이 안전하다.
Google Drive는 파일 저장소이면서 Docs, Sheets, Slides 같은 편집 도구의 입구다. Google의 Drive MCP 서버 설정은 Google Cloud 프로젝트, Drive API와 Drive MCP API 활성화, OAuth 동의 화면, OAuth 클라이언트 구성이 필요하다. 권한 범위에는 읽기 전용에 가까운 스코프와 파일 생성·수정에 가까운 스코프가 구분된다.4 팀 문서에 붙일 때는 개인 계정보다 테스트 계정이나 제한된 워크스페이스부터 시작하는 것이 좋다.
사내 위키는 가장 조심해야 한다. Confluence, Wiki.js, GitBook, 자체 포털처럼 형태가 다양하고, 사내 인증과 권한 체계가 얽혀 있다. 이 경우 MCP 서버는 보통 위키 API를 감싸는 형태가 된다. 연결 전에 세 가지를 확인해야 한다.
사용자별 권한이 MCP 호출에도 그대로 적용되는가
검색 결과에 비공개 문서 제목이나 일부 내용이 섞이지 않는가
AI가 작성하거나 수정한 변경 이력이 남는가
사내 위키 연결은 편리하지만, 한 번 잘못 열면 조직 전체 지식이 예상보다 넓게 노출될 수 있다.
폴더와 워크스페이스를 나누는 습관
MCP 문서 활용의 성패는 프롬프트 실력보다 정리 습관에 달려 있다. 좋은 운영 방식은 다음과 같다.
첫째, AI 공개 가능 영역을 따로 만든다. 예를 들어 AI-Readable, AI-Drafts, AI-Archive 같은 폴더를 둔다. 여기에 들어간 문서는 AI가 읽을 수 있다는 뜻으로 팀원 모두가 이해해야 한다.
둘째, 민감 문서는 섞지 않는다. 계약서, 인사 평가, 급여, 고객 개인정보, 보안 사고 보고서, 미공개 재무 자료는 기본적으로 연결하지 않는다. 꼭 필요하다면 별도 승인 절차와 마스킹을 거친 복사본을 만든다.
셋째, 초안과 원본을 분리한다. AI가 만든 결과물은 항상 초안 폴더에 둔다. 원본 반영은 사람이 diff를 보고 결정한다. 개발자는 Git을 쓰면 좋고, 파워유저는 파일명에 날짜와 상태를 붙이는 것만으로도 충분하다.
2026-07-19_onboarding-email_draft.md
2026-07-19_release-checklist_review-needed.md
2026-07-19_meeting-summary_final.md넷째, 정기적으로 연결 범위를 점검한다. 프로젝트가 끝났는데도 폴더가 계속 연결되어 있거나, 임시로 넣은 민감 파일이 남아 있을 수 있다. 한 달에 한 번은 "현재 MCP가 접근 가능한 폴더와 워크스페이스"를 확인한다.
좋은 질문은 범위와 결과물을 함께 정한다
문서 MCP를 잘 쓰는 사람은 "요약해 줘"라고만 하지 않는다. 범위, 기준, 출력 형식을 함께 준다.
나쁜 예는 이렇다.
우리 문서 정리해 줘.좋은 예는 이렇다.
project-docs 폴더에서 온보딩 관련 문서만 찾아줘.
신규 입사자가 첫 3일 동안 해야 할 일을 시간순 체크리스트로 정리해.
근거가 된 파일명을 각 항목 끝에 표시해.
결과는 writable/checklists/onboarding-3days.md 파일로 저장해.
원본 파일은 수정하지 마.이 프롬프트에는 네 가지가 들어 있다. 어디를 볼지, 무엇을 만들지, 어떻게 검증할지, 어디에 저장할지다. 이 정도만 습관이 되어도 MCP는 단순 챗봇이 아니라 개인 문서 비서에 가까워진다.
마무리: 작게 열고, 자주 확인한다
파일, 문서, 지식베이스 연결은 MCP의 가장 현실적인 출발점이다. 새 시스템을 만들지 않아도 된다. 이미 있는 폴더와 문서를 안전하게 연결하면 된다.
다만 편리함은 접근 권한과 함께 온다. 처음부터 전체 드라이브, 전체 워크스페이스, 전체 위키를 연결하지 말자. 작은 폴더 하나, 읽기 중심 문서 몇 개, 초안 저장용 폴더 하나로 시작한다. 그리고 AI에게 묻는다. "지금 어디까지 접근할 수 있어?"
그 질문에 사용자가 명확히 답할 수 있다면, MCP 문서 활용은 안전한 방향으로 가고 있는 것이다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.