GitHub Copilot cloud agent에 Model Context Protocol(MCP)을 연결하면 에이전트가 저장소 밖의 도구와 데이터를 사용할 수 있습니다. 이 기능은 강력합니다. 동시에 위험합니다. 에이전트가 더 많은 맥락을 읽을수록 더 나은 작업을 할 수 있지만, 잘못된 도구 권한을 주면 원하지 않는 작업까지 자동으로 실행할 수 있습니다.
GitHub 문서에 따르면 MCP는 애플리케이션이 대형 언어 모델(LLM)에 컨텍스트를 공유하는 표준 방식입니다. Copilot cloud agent는 MCP 서버가 제공하는 도구를 사용할 수 있으며, 기본적으로 GitHub MCP 서버와 Playwright MCP 서버가 구성됩니다. 단, 현재 Copilot cloud agent는 MCP 서버의 tools만 지원하고 resources나 prompts는 지원하지 않습니다. 또한 OAuth 인증·인가를 사용하는 원격 MCP 서버는 현재 지원하지 않는다고 문서에 명시되어 있습니다.
이 글은 “MCP 서버를 어떻게 많이 붙일까”가 아니라 “실무 저장소에서 어떤 기준으로 붙일까”에 초점을 둡니다. 개발팀에는 기능보다 권한 설계가 먼저입니다.
GitHub 문서에서 놓치면 안 되는 문장이 있습니다. 저장소에 MCP 서버를 구성하면 Copilot cloud agent는 해당 도구를 작업 중 자율적으로 사용할 수 있으며, 사용 전 별도 승인을 요청하지 않습니다. 이 말은 편리하다는 뜻이면서 동시에 위험하다는 뜻입니다.
예를 들어 Playwright MCP 서버는 웹 페이지를 읽고, 상호작용하고, 스크린샷을 찍는 기능을 제공합니다. 기본 설정에서는 Copilot 자체 환경의 localhost 또는 127.0.0.1에 호스팅된 웹 리소스만 접근할 수 있도록 제한됩니다. 이 제한은 안전장치입니다. 하지만 별도 MCP 서버를 추가하면서 접근 범위를 넓히면 에이전트의 행동 반경도 같이 넓어집니다.
GitHub MCP 서버도 마찬가지입니다. 기본적으로 현재 저장소에 대한 읽기 전용 권한을 가진 특수 범위 토큰을 사용한다고 문서에 설명되어 있습니다. 그러나 다른 토큰으로 커스터마이징하면 더 넓은 권한을 줄 수 있습니다. 이때부터 MCP 설정은 단순 개발 편의가 아니라 보안 설정이 됩니다.
많은 팀이 MCP를 도입할 때 서버 단위로 생각합니다. “Notion MCP를 붙일까”, “Jira MCP를 붙일까”, “브라우저 MCP를 붙일까”처럼 결정합니다. 하지만 실무 기준은 서버가 아니라 도구입니다.
GitHub도 베스트 프랙티스에서 MCP 서버에 포함된 도구를 검토하고, 필요한 도구만 tools 필드에 지정하라고 안내합니다. 이유는 명확합니다. 하나의 MCP 서버 안에도 읽기, 쓰기, 삭제, 실행 계열 도구가 섞여 있을 수 있습니다. 에이전트에게 필요한 것은 대부분 읽기와 검색입니다. 쓰기 도구는 별도 검토가 필요합니다.
저장소별 MCP 설정을 만들 때는 다음처럼 분류하는 방식이 좋습니다.
이 분류는 보수적으로 시작해야 합니다. 에이전트 자동화의 권한은 한 번 넓히면 줄이기 어렵습니다. 처음에는 읽기 중심으로 시작하고, 반복적으로 필요한 쓰기만 개별 승인 흐름에 넣는 편이 안전합니다.
Copilot cloud agent의 MCP 서버는 저장소 관리자가 저장소 단위로 구성할 수 있습니다. JSON 형식 설정에 MCP 서버 상세 정보를 넣고, 해당 저장소에서 에이전트가 사용할 수 있게 만듭니다. 커스텀 에이전트에도 MCP 서버를 구성할 수 있으며, 커스텀 에이전트 설정은 기본 서버 이후, 저장소 레벨 설정 이전 순서로 처리된다고 문서에 설명되어 있습니다.
실무에서는 다음 순서를 권장합니다.
중요한 점은 MCP 설정을 “한 번 붙이고 끝”으로 보지 않는 것입니다. 에이전트가 실패한 이유가 도구 부족인지, 프롬프트 부족인지, 권한 과다인지 분리해서 봐야 합니다.
좋은 MCP 사용 사례는 입력과 출력이 명확합니다. 예를 들어 프론트엔드 수정 작업에서 Playwright MCP를 사용해 로컬 미리보기 페이지를 열고, 스크린샷을 찍고, 접근성 상태를 확인하는 것은 합리적입니다. 에이전트가 실제 화면을 확인할 수 있으므로 “코드는 맞지만 UI가 깨지는” 문제를 줄일 수 있습니다.
문서 검색 MCP도 좋은 사례입니다. 에이전트가 사내 API 규칙, 디자인 시스템 사용법, 릴리즈 정책을 읽을 수 있으면 반복 질문이 줄어듭니다. 단, 문서 검색은 민감도별로 범위를 나눠야 합니다. 공개 개발 문서와 고객 계약 문서를 같은 검색 도구에 넣으면 안 됩니다.
나쁜 사용 사례는 에이전트에게 외부 시스템 쓰기 권한을 넓게 주는 것입니다. 예를 들어 티켓 상태 변경, 운영 알림 발송, 배포 버튼 실행, 고객 데이터 추출을 한 MCP 서버에 묶어 자동 호출 가능하게 만드는 것은 위험합니다. 이런 작업은 자동화가 가능하더라도 사람 승인이나 별도 워크플로우가 필요합니다.
MCP를 붙였다고 생산성이 자동으로 오르지는 않습니다. 오히려 도구가 많아지면 에이전트가 불필요한 호출을 반복하고, 작업 시간이 길어지고, 산출물 품질이 흔들릴 수 있습니다. GitHub 문서도 서드파티 MCP 서버 사용이 에이전트 성능과 출력 품질에 영향을 줄 수 있다고 경고합니다.
측정 기준은 단순해야 합니다.
이 기준을 만족하지 못하면 MCP 서버를 더 붙이는 것이 아니라 줄여야 합니다. 좋은 에이전트 운영은 많은 도구가 아니라 필요한 도구의 최소 조합에서 시작합니다.
Copilot cloud agent에 MCP를 붙이기 전 다음 항목을 확인하세요.
MCP의 가치는 에이전트에게 더 많은 맥락을 주는 데 있습니다. 하지만 맥락과 권한은 다릅니다. 다음 MCP 서버를 붙이기 전에 물어봐야 할 질문은 이것입니다. 이 도구가 없으면 에이전트가 일을 못 하는가, 아니면 단지 있어 보이는가?
출처: GitHub Docs, “Model Context Protocol (MCP) and GitHub Copilot cloud agent”.
