MCP 보안 설정 가이드 2026 — GitHub·파일 권한 어디까지 열까

MCP 보안 설정 가이드 2026 — GitHub·파일 권한 어디까지 열까

AI 리뷰 & 가이드 2026. 07. 07. 약 13분 읽기

MCP 서버를 쓸 때 가장 위험한 Filesystem, GitHub, Playwright 권한을 어디까지 열어야 하는지 실무 기준으로 정리했습니다.

MCP는 편합니다. 그런데 편한 만큼 위험합니다.

AI 코딩 도구에 Filesystem, GitHub, Playwright 같은 MCP 서버를 붙이면 모델이 파일을 읽고, 이슈를 확인하고, 브라우저까지 조작할 수 있습니다. 이게 잘 쓰면 생산성이고, 대충 열면 사고 후보입니다.

이 글은 MCP 서버 추천 목록이 아닙니다. 예전에 MCP 도구 모음 글을 이미 발행했기 때문에, 이번에는 각 도구를 어디까지 열어야 안전한지만 따로 정리합니다. 특히 개인 프로젝트에서 Claude Code, Cursor, ChatGPT 계열 도구에 MCP를 붙이려는 분들이 보면 좋습니다.

MCP는 많이 붙이는 것보다 작게 여는 게 먼저입니다. 처음부터 모든 폴더와 모든 토큰을 넘기면 편한 게 아니라 불안한 자동화가 됩니다.

MCP에서 진짜 위험한 지점

Model Context Protocol 공식 문서는 MCP를 AI 앱이 외부 시스템과 연결되는 표준 방식으로 설명합니다. 여기서 중요한 단어는 "연결"입니다. AI가 답변만 하는 게 아니라, 실제 도구를 부를 수 있게 됩니다.

개발자가 자주 붙이는 MCP 서버는 대략 아래처럼 나뉩니다.

서버 유형	하는 일	사고가 나는 지점
Filesystem	로컬 파일 읽기·수정	홈 폴더 전체를 열어 시크릿까지 노출
GitHub	이슈, PR, Actions, 저장소 접근	토큰 권한을 과하게 부여
Playwright	브라우저 조작과 화면 확인	로그인된 관리자 페이지를 클릭
Fetch/Browser	웹 문서 읽기	신뢰 낮은 페이지 내용을 그대로 반영
Memory	프로젝트 규칙 저장	임시 정보와 민감 정보가 장기 기억처럼 남음

MCP를 쓴다는 건 AI에게 "손"을 달아주는 일에 가깝습니다. 그래서 모델 성능보다 권한 설계가 먼저입니다. 모델이 똑똑해도, 잘못 열린 도구는 잘못 누를 수 있습니다.

용어 풀이

Filesystem은 프로젝트 폴더 하나만

가장 먼저 조심할 건 Filesystem입니다. 이름은 단순하지만 실제 위험은 제일 큽니다. 파일을 읽고 쓸 수 있다는 건 .env, SSH 키, 다운로드 폴더, 개인 문서까지 잘못 노출될 수 있다는 뜻입니다.

저의 기준은 간단합니다.

Filesystem MCP는 프로젝트 폴더 하나만 엽니다. 예를 들어 블로그 자동화 프로젝트를 작업한다면 그 프로젝트 루트만 허용합니다. C:\Users\사용자명 전체, Downloads 전체, 바탕화면 전체는 열지 않습니다.

특히 아래 파일은 AI가 읽지 못하게 분리하는 게 좋습니다.

• .env
• API 키가 들어간 JSON 파일
• SSH 개인키
• 결제·광고 계정 관련 파일
• 고객 정보가 들어간 CSV
• 브라우저 프로필 폴더

그리고 쓰기 권한이 꼭 필요한지도 따져봐야 합니다. 단순 분석이면 읽기만으로 충분합니다. 코드를 고쳐야 할 때만 쓰기 권한을 켜도 늦지 않습니다.

GitHub 토큰은 작게 시작하세요

GitHub MCP Server는 개발자에게 체감이 큽니다. 공식 저장소 기준으로 이슈, PR, Actions, 저장소, 코드 보안 관련 도구를 다룰 수 있습니다.

문제는 토큰입니다. GitHub 토큰은 한 번 크게 열어두면 AI가 생각보다 많은 맥락을 볼 수 있습니다. 개인 공개 저장소 정도면 부담이 작지만, 회사 저장소나 비공개 저장소는 얘기가 달라집니다.

 

제가 권하는 순서는 이렇습니다.

단계	GitHub 권한	사용 목적
1	공개 저장소 읽기	문서, 이슈, 코드 구조 확인
2	특정 개인 저장소 읽기	내 프로젝트 이슈·PR 요약
3	특정 저장소 쓰기	이슈 작성, PR 코멘트 초안
4	Actions 확인	실패한 CI 로그 분석
5	보안 관련 권한	필요할 때만 별도 검토

처음부터 조직 전체 권한을 주는 건 피하는 게 좋습니다. "내가 자주 쓰는 저장소 하나"에서 시작하고, 실제로 필요한 작업이 보일 때 권한을 늘리는 쪽이 안전합니다.

그리고 토큰은 이름을 분리해두면 관리가 쉽습니다. 예를 들어 mcp-personal-readonly, mcp-blog-repo-write처럼 용도를 이름에 넣어두면 나중에 끊기도 편합니다.

Playwright는 테스트 프로필로만

Microsoft Playwright MCP는 웹앱을 만드는 사람에게 꽤 좋습니다. 브라우저를 열고, 버튼을 누르고, 화면 구조를 읽어 테스트 흐름을 도와줄 수 있습니다.

하지만 Playwright는 "실제 클릭"이 가능한 도구입니다. 그래서 로그인된 브라우저를 그대로 넘기면 위험합니다. 쇼핑몰 관리자, 광고 계정, 클라우드 콘솔, 결제 페이지처럼 클릭 하나가 실제 변경으로 이어지는 화면에서는 특히 조심해야 합니다.

 

 

제 기준으로는 이렇게 씁니다.

• 개인 브라우저 프로필과 테스트 프로필을 분리합니다.
• 결제·삭제·발행 버튼이 있는 페이지는 자동 조작 대상에서 뺍니다.
• 관리자 페이지는 읽기 확인까지만 맡깁니다.
• 실제 배포/발행/삭제는 사람이 마지막에 누릅니다.
• 가능하면 로컬 개발 서버나 스테이징에서 먼저 돌립니다.

Playwright MCP는 "화면을 확인하는 눈"으로 쓰면 좋습니다. "내 계정으로 마음껏 클릭하는 손"으로 쓰면 불안합니다.

Memory에는 규칙만 넣으세요

Memory MCP도 조심해야 합니다. 프로젝트 규칙을 기억하게 만들면 편하지만, 아무거나 넣으면 나중에 지우기 귀찮은 먼지가 됩니다.

넣어도 되는 건 이런 것들입니다.

• 이 프로젝트는 article_qa PASS 후 HTML을 생성합니다.
• 커밋은 scripts/save.py로 처리합니다.
• 본문 H1은 금지하고 YAML title만 씁니다.
• 이미지 생성은 금지하고 공식 이미지만 씁니다.

넣으면 안 되는 건 훨씬 명확합니다.

• API 키
• 비밀번호
• 광고 계정 정보
• 고객 정보
• 비공개 URL
• 임시로 정한 작업 지시

Memory는 "비밀 보관함"이 아닙니다. 반복되는 작업 규칙을 넣는 곳이라고 보는 게 맞습니다.

용어 풀이

처음 세팅할 때 체크할 것

MCP를 처음 붙일 때는 아래 순서로 보면 됩니다. 복잡하게 생각할 필요 없습니다. 하나씩 좁게 열면 됩니다.

체크 항목	권장 기준
폴더 범위	프로젝트 루트 하나
GitHub 토큰	특정 저장소 읽기부터
브라우저	테스트 프로필 사용
메모리	반복 규칙만 저장
회사 계정	개인 실험 후 별도 검토
삭제·결제·발행 작업	사람 확인 후 실행

특히 회사 업무에 붙일 때는 더 느리게 가야 합니다. 개인 프로젝트에서 편했다고 해서 회사 저장소, 사내 DB, Slack, 이메일을 한꺼번에 붙이면 안 됩니다. 자동화는 편하지만, 권한 사고는 수습이 피곤합니다.

내 생각

개인적으로 MCP는 AI 코딩 도구의 체감 성능을 크게 올려주는 기술이라고 봅니다. 모델이 답만 하는 게 아니라, 실제 프로젝트 파일과 이슈와 화면을 같이 볼 수 있으니까요.

다만 처음부터 욕심내면 좋지 않습니다. 저는 MCP를 "많이 붙이면 좋은 플러그인 묶음"으로 보기보다, 권한을 빌려주는 계약처럼 보는 게 맞다고 생각합니다. 계약서를 대충 쓰면 나중에 피곤하듯이, MCP도 처음 권한을 대충 열면 나중에 찜찜합니다.

저의 경우라면 Filesystem은 프로젝트 폴더 하나만, GitHub는 개인 저장소 읽기부터, Playwright는 테스트 프로필에서만 시작하겠습니다. 이 정도만 지켜도 MCP는 꽤 안전하게 쓸 수 있습니다.

그리고 제일 중요한 건 마지막 버튼입니다. 삭제, 결제, 발행, 배포는 AI가 준비할 수는 있어도 사람이 눌러야 마음이 편합니다. 이 선만 지켜도 MCP는 훨씬 실용적인 도구가 됩니다.

그럼 이만~

참고 자료

• Model Context Protocol 공식 문서
• Model Context Protocol reference servers
• GitHub MCP Server 공식 저장소
• Microsoft Playwright MCP 공식 저장소