파일시스템·브라우저 자동화 MCP를 안전하게 쓰는 설정: 허용 경로와 격리

파일시스템 MCP와 브라우저 자동화 MCP는 에이전트에게 가장 강력한 손발을 주는 서버다. 그만큼 설정을 잘못하면 홈 디렉터리의 SSH 키를 읽거나, 로그인된 브라우저 세션으로 원치 않는 작업을 하게 만들 수 있다. MCP 보안 모범 사례는 로컬 서버가 클라이언트와 같은 권한으로 실행된다는 점을 경고하고, 최소 권한과 샌드박스 실행을 권한다. 이 글은 공식 Filesystem 서버와 Playwright MCP를 예로 범위를 좁히는 설정을 정리한다. 사내 도구 전반의 보안 점검은 바이브 코딩 사내 도구 보안 글에서 다뤘다.

Filesystem 서버: 허용 디렉터리부터 좁힌다

Filesystem 서버 README에 따르면 접근 가능한 디렉터리는 실행 인자로 지정하거나 MCP Roots로 전달한다. 클라이언트가 Roots를 지원하면 클라이언트가 알려 준 Roots가 서버의 명령줄 허용 디렉터리를 완전히 대체하며, 실행 중에도 변경 알림으로 갱신된다. 허용 디렉터리가 하나도 없으면 서버는 동작하지 않는다.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/projects/docs-site"]
    }
  }
}

홈 디렉터리 전체나 드라이브 루트를 허용하지 않는다. 작업할 프로젝트 폴더 하나만 지정하고, 필요할 때 추가한다. Roots를 쓰는 클라이언트라면 명령줄 인자가 무시될 수 있으므로 클라이언트가 보내는 Roots 범위도 함께 확인한다.

도구별 쓰기 여부를 알고 연결한다

분류	도구	주석
읽기 전용	read_text_file, read_media_file, read_multiple_files, list_directory, directory_tree, search_files, get_file_info, list_allowed_directories	readOnlyHint: true
쓰기(멱등)	create_directory	idempotentHint: true
쓰기(파괴적)	write_file, edit_file, move_file	destructiveHint: true

클라이언트가 도구별 허용 설정을 지원하면 읽기 도구만 자동 승인하고 파괴적 도구는 매번 확인하게 한다. 문서 검색만 필요하다면 쓰기 도구를 아예 비활성화한다.

Docker로 읽기 전용 마운트하기

더 강한 격리가 필요하면 Docker 컨테이너로 실행하고 필요한 폴더만 마운트한다. README 예시처럼 ro 옵션을 주면 컨테이너 안에서 쓰기가 막힌다.

{
  "mcpServers": {
    "filesystem": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "--mount", "type=bind,src=/Users/me/projects/docs-site,dst=/projects/docs-site,ro",
        "mcp/filesystem",
        "/projects"
      ]
    }
  }
}

이렇게 하면 서버 코드에 경로 처리 버그가 있어도 컨테이너 밖 파일에는 접근할 수 없고, 마운트한 폴더도 수정할 수 없다. 명세는 file:// 리소스를 제공하는 서버가 경로를 정제해 디렉터리 이탈 공격을 막아야 한다고 규정하는데, 컨테이너 격리는 그 위에 한 겹을 더하는 셈이다.

Playwright MCP: 격리 프로필과 출처 제한

브라우저 자동화 서버는 로그인 쿠키, 내부망 접근, 파일 다운로드까지 다룰 수 있다. Playwright MCP README의 옵션 중 안전과 관련된 것은 다음과 같다.

옵션	동작	용도
--isolated	브라우저 프로필을 메모리에만 두고 디스크에 저장하지 않음	평소 쓰는 로그인 세션과 분리
--storage-state	격리 컨텍스트에 쿠키·localStorage 초기값을 파일에서 불러옴	테스트 계정 세션만 주입
--allowed-origins / --blocked-origins	브라우저가 요청할 수 있는 출처를 세미콜론 목록으로 허용·차단	사내 테스트 도메인만 허용
--headless	화면 없이 실행	CI·서버 환경
--sandbox	평소 샌드박스되지 않는 프로세스까지 샌드박스 활성화	프로세스 격리 강화
--caps	vision, pdf, devtools 등 추가 기능 활성화	필요한 기능만 켜기

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest",
        "--isolated",
        "--headless",
        "--allowed-origins", "https://staging.example.com;https://auth.example.com"
      ]
    }
  }
}

주의할 점은 README가 이 출처 목록이 보안 경계가 아니며 리다이렉트에는 적용되지 않는다고 밝힌다는 것이다. 또 Playwright MCP 자체가 보안 경계가 아니므로 실제 통제는 클라이언트 권한 설정에 의존하라고 안내한다. 따라서 출처 제한은 실수 방지용으로 쓰고, 민감한 사이트는 아예 접근 가능한 네트워크에서 분리한다. --allow-unrestricted-file-access처럼 작업 공간 밖 파일 접근을 여는 옵션은 꼭 필요할 때만 쓴다.

두 서버에 공통으로 적용할 운영 규칙

1. 평소 쓰는 브라우저 프로필과 홈 디렉터리를 서버에 넘기지 않는다.
2. 테스트 계정과 스테이징 환경만 쓰고 운영 관리자 계정은 쓰지 않는다.
3. 파괴적 도구와 폼 제출, 결제 같은 동작은 클라이언트에서 호출마다 승인한다.
4. 서버는 컨테이너나 별도 사용자 계정으로 실행해 권한을 줄인다.
5. 웹 페이지 내용이 에이전트 지시로 바뀌는 간접 프롬프트 인젝션을 고려해, 브라우저 결과를 근거로 한 쓰기 작업은 사람이 확인한다.

서버별 권한과 승인 흐름을 맞추는 방법은 Claude Code Auto Mode 보안 글에서, 읽기 전용 MCP 연결 예는 VS Code Continue MCP 글에서 다뤘다.