MCP의 roots에 폴더를 넣었다고 파일 접근 권한이 생기거나 그 밖의 접근이 자동 차단되지는 않습니다. 파일이 안 읽히면 먼저 서버가 실행되는 위치와 실제 접근 정책을 확인하세요. 반대로 범위 밖 파일이 읽힌다면 roots 목록을 고치는 것만으로 보안 문제가 해결됐다고 볼 수 없습니다.
적용 범위는 기존 roots 구현을 점검하는 개발자와 운영자입니다. MCP 2026-07-28에서 Roots는 deprecated, 즉 신규 도입을 권장하지 않는 기능입니다. 공식 문서는 도구 인자·리소스 URI·서버 설정으로 파일과 디렉터리를 전달하도록 이전을 권고합니다. 이 글의 확인일은 2026년 10월 10일입니다. 현재 Roots 규격
1. 폴더 선택, 경로 전달, 접근 허용을 나누기
문제를 좁힐 때는 세 질문을 따로 적는 편이 좋습니다. 사용자가 어떤 폴더를 골랐는가. 서버는 어떤 위치를 전달받았는가. 그 서버 프로세스는 무엇을 읽을 수 있는가. 아래는 이 구분을 실무에 적용한 진단 틀입니다.
| 확인할 층 | 확인할 내용 |
|---|---|
| 화면의 선택 | 현재 작업 폴더가 맞는지, 이전 프로젝트 이름이 남아 있지 않은지 |
| 전달된 정보 | 클라이언트·서버가 쓰는 규격과 실제 경로 값이 일치하는지 |
| 실행 환경 | 로컬 프로세스인지 원격 서버인지, 파일이 그 환경에 존재하는지 |
| 접근 통제 | 서버의 허용 경로, 운영체제 권한, 격리 환경 정책이 허용하는지 |
현재 규격은 roots를 작업 범위에 대한 안내 정보로 설명하며, 서버를 그 안에 가두는 기능은 아니라고 명시합니다. 접근 통제는 별도로 구현해야 합니다. 로컬 서버의 최소 권한과 격리 실행은 공식 보안 가이드에서도 권고합니다.
2. 예전 로그와 현재 로그를 섞지 않기
2025-11-25 방식의 로그를 최신 규격에 그대로 대입하면 정상적인 동작도 누락처럼 보일 수 있습니다. 아래는 해당 두 규격의 비교이며, 모든 제품이 최신 규격으로 이전했다는 뜻은 아닙니다.
| 항목 | 2025-11-25 | 2026-07-28 |
|---|---|---|
| roots 지원 표시 | 초기화 때 클라이언트 capabilities | 요청별 클라이언트 capabilities 메타데이터 |
| 목록 요청 흐름 | 서버가 roots/list 요청 | InputRequiredResult의 inputRequests에 roots/list |
| 목록 결과 전달 | JSON-RPC 응답의 result | 재요청의 inputResponses |
| 신규 도입 판단 | 당시 규격의 기능 | deprecated: 대체 전달 방식 검토 |
이전 규격에는 listChanged와 notifications/roots/list_changed도 정의돼 있습니다. 현재 규격의 요청 흐름을 점검하면서 이 알림이 없다는 이유만으로 장애를 단정하지 마세요. 먼저 양쪽 구현의 프로토콜 버전을 확인해야 합니다. 2025-11-25 Roots 규격 · 2026-07-28 Roots 규격
3. 파일이 안 읽히는 경우의 진단 순서
먼저 파일 내용 대신 환경 정보를 확인합니다. 비밀 파일을 읽어 접근 여부를 시험하지 말고, 본인이 관리하는 테스트 환경에 둔 무해한 샘플 파일을 사용하세요. 아래 절차는 권장 점검 순서이며 특정 클라이언트에서 재현한 장애 보고가 아닙니다.
① 클라이언트와 서버의 제품명·버전, 사용 중인 MCP 규격을 기록합니다. SDK를 쓰면 그 버전도 따로 적습니다. 제품 버전과 프로토콜 날짜를 같은 값으로 취급하지 않습니다.
② 서버가 실제로 실행되는 환경을 확인합니다. 예를 들어 내 컴퓨터에 있는 폴더 이름을 원격 서버에 전달했다고 그 서버에 파일이 복사되는 것은 아닙니다. 원격 서버의 저장소나 마운트에 대응 파일이 있는지 운영 설정에서 확인합니다.
③ 전달 값을 비교합니다. 화면의 프로젝트 이름만 비교하지 말고, 의도한 경로와 서버가 받아들인 경로가 같은 대상을 가리키는지 확인합니다. 외부 문의에는 실제 사용자명·프로젝트명·전체 경로를 제거하고 필요한 형태만 남깁니다.
④ 서버 설정과 실행 계정의 권한을 읽기로 확인합니다. 접근 거부를 없애려고 전체 홈 디렉터리를 허용하거나 관리자 권한으로 실행하는 방법을 먼저 택하지 않습니다. 필요한 경로 하나에 대한 정책이 맞는지부터 검토합니다.
⑤ 같은 샘플로 다시 확인합니다. 읽기 결과와 대상 파일을 대조하고, 실패하면 오류가 발생한 층을 기록합니다. 연결 표시만 정상이라고 파일 접근까지 정상이라고 결론 내리지 않습니다.
4. 복사해서 쓸 점검 기록
다음은 문서나 이슈에 붙여 쓰는 가상 진단 기록 양식입니다. MCP 요청 본문이나 실행 코드가 아니며, 예시 이름은 실제 서비스와 무관합니다. 공유 전에 민감한 값을 지웠는지도 확인하세요.
클라이언트 제품 / 버전: <기입>
서버 제품 / 버전: <기입>
SDK 버전 또는 미사용: <기입>
MCP 프로토콜 버전: <기입>
서버 실행 위치: 로컬 / 원격 / 격리 환경
전달 방식: 기존 roots / 도구 인자 / 리소스 URI / 서버 설정
샘플 파일 식별명: demo-note.txt
기대 결과: 허용된 샘플 읽기
실제 결과: <성공 또는 오류 종류>
경로 대응 확인: <동일 대상인지>
권한 정책 확인: <허용된 범위인지>
다음 조치: <확인되지 않은 한 항목>가령 화면에는 프로젝트 A가 선택됐는데 원격 서버에는 샘플 파일이 없다면, roots 지원 여부만 조사해서는 해결되지 않습니다. 파일 전달 또는 저장 위치 설계를 확인해야 합니다. 이 사례는 진단 분기를 설명하기 위한 가상 상황입니다.
5. 범위 밖 파일이 읽힌다면
이 경우에는 편의 기능의 문제가 아니라 접근 정책을 점검해야 합니다. 해당 경로가 정말 금지 대상으로 정의돼 있는지, 서버가 그 정책을 적용하는지부터 확인하세요. 정책을 모른 채 다른 폴더를 무작위로 읽는 시험은 하지 않습니다.
허가된 격리 테스트 환경에서는 허용 샘플과 차단 대상으로 지정한 별도 샘플을 준비해 기대 결과를 나눌 수 있습니다. 경로 해석이나 링크 처리까지 포함한 검토가 필요할 수 있으므로 단순 문자열 비교 한 줄을 완전한 보안 대책처럼 쓰지 마세요. 실제 차단은 서버·운영체제·격리 계층에서 보장해야 한다는 설계상의 권고입니다.
6. 새 구현에서는 무엇으로 바꿀까
새 도구를 만든다면 호출마다 필요한 대상이 달라지는지, 고정된 작업 공간만 다루는지부터 결정하세요. 공식 이전 방향을 실무에 적용하면 다음처럼 선택할 수 있습니다. 아래 선택 기준은 설계 제안이며 MCP가 강제하는 제품 구조는 아닙니다.
| 업무 조건 | 검토할 전달 방식 |
|---|---|
| 호출마다 대상이 달라짐 | 도구 인자에 명시적인 대상 식별자를 전달 |
| 서버가 제공하는 문서·데이터를 읽음 | 서버가 정의한 리소스 URI 사용 |
| 서버가 고정 작업 공간만 처리함 | 관리자가 통제하는 서버 설정으로 범위 지정 |
어느 방식을 골라도 대상 지정과 접근 허용은 따로 판단해야 합니다. 경로나 URI를 받았다는 사실만으로 호출자가 그 대상을 읽을 권한을 갖는 것은 아닙니다. 이전할 때는 기존 작업이 계속 되는지와 금지된 작업이 계속 차단되는지를 함께 살펴야 합니다.
함께 읽기와 공식 출처
읽기 전용이라는 표시의 의미가 궁금하다면 도구 annotations의 네 가지 힌트를, 최신 요청 흐름이 낯설다면 initialize 없는 discovery 모델을 함께 읽으세요. 리소스 목록과 실제 읽기의 차이는 resources/list와 URI 템플릿 진단에 정리했습니다.
공식 근거: Roots 2026-07-28, Roots 2025-11-25, SEP-2577, 로컬 MCP 서버 보안 고려사항. 2026년 10월 10일 확인. 특정 SDK의 동작이나 제품별 메뉴 위치를 검증한 글은 아닙니다.