GitHub MCP Server를 붙이기 전, “무엇을 할 수 있게 할지”부터 정해야 합니다

GitHub MCP Server 연결의 핵심은 설치 명령이 아니라, 에이전트에게 열어줄 GitHub 권한과 도구 범위를 먼저 정하는 것입니다.

들어가며 — 독자가 지금 이 문제를 검색하는 이유

AI 에이전트를 IDE나 업무 도구에 붙이는 일이 점점 쉬워지고 있습니다.

GitHub도 공식 MCP Server를 제공하고, 원격 서버 방식과 로컬 Docker 실행 방식을 모두 문서화하고 있습니다.

그래서 많은 팀이 이렇게 검색합니다.

“GitHub MCP Server는 어떻게 연결하지?”

“VS Code에서 바로 쓸 수 있나?”

“PAT를 발급해야 하나, OAuth로 연결해야 하나?”

“이걸 켜면 에이전트가 우리 저장소에서 어디까지 할 수 있지?”

하지만 실제 도입에서 더 중요한 질문은 연결 방법이 아닙니다.

“AI 에이전트가 GitHub에서 무엇을 할 수 있게 할 것인가?”

GitHub MCP Server는 repo, issue, pull request, actions, security 등 GitHub 업무와 연결될 수 있는 여러 toolset을 제공합니다. 편리하다고 한꺼번에 열어두면, 에이전트가 읽기만 해야 할 상황에서도 변경 작업까지 할 수 있는 구조가 될 수 있습니다.

그래서 GitHub MCP Server를 붙이기 전에는 설치보다 권한 설계가 먼저입니다.

GitHub MCP Server는 무엇을 연결해주는가

GitHub 공식 저장소인 github/github-mcp-server는 GitHub용 MCP Server로 안내되어 있습니다. 리서치 기준 GitHub API에서도 공식 MCP Server로 확인되며, 최근 push 시점은 2026-08-14로 확인되었습니다.

출처: GitHub MCP Server 저장소, GitHub API

이 서버의 목적은 AI 에이전트나 MCP 클라이언트가 GitHub와 상호작용할 수 있도록 도구 인터페이스를 제공하는 것입니다. 예를 들면 다음 업무에 연결될 수 있습니다.

• 저장소 정보 확인
• 이슈 조회
• Pull Request 확인
• GitHub Actions 관련 정보 확인
• 보안 관련 정보 확인

다만 여기서 중요한 점은 “GitHub에 연결된다”는 말이 너무 넓다는 것입니다.

GitHub는 단순한 문서 저장소가 아닙니다.

코드, 이슈, PR, CI/CD, 보안 정보, 조직 정책이 함께 있는 협업 시스템입니다. AI 에이전트에게 GitHub 접근을 허용한다는 것은 단순히 검색 기능을 붙이는 일이 아니라, 팀의 개발 운영 영역 일부를 자동화 도구에 노출하는 일입니다.

그래서 GitHub MCP Server를 사용할 때는 다음 질문부터 정해야 합니다.

• 에이전트가 저장소를 읽기만 하면 되는가?
• 이슈나 PR에 댓글을 달 수 있어야 하는가?
• Actions나 security 관련 도구까지 필요한가?
• 개인 PAT로 연결할 것인가, OAuth 흐름을 사용할 것인가?
• 조직 정책상 MCP 사용이 허용되어 있는가?

GitHub 공식 문서도 서버 설정과 정책·거버넌스 문서를 별도로 제공합니다.

출처: server-configuration.md, policies-and-governance.md

연결 방식보다 먼저 정해야 할 3가지

1. 원격 서버를 쓸지, 로컬 Docker 실행을 쓸지 정한다

리서치에 따르면 GitHub 공식 MCP Server는 원격 서버 방식과 로컬 Docker 실행 방식을 모두 제공합니다.

또한 VS Code 1.101+에서는 원격 MCP와 OAuth 사용이 문서화되어 있습니다.

출처: GitHub MCP Server, VS Code MCP 문서

여기서 팀이 먼저 정해야 할 것은 “어느 방식이 더 멋진가”가 아닙니다.

업무 환경에 따라 다음 기준으로 판단해야 합니다.

• 개인 개발자가 로컬 실험을 하는가?
• 조직 차원에서 여러 사용자가 공통 정책으로 연결해야 하는가?
• 인증 정보를 어디에 둘 것인가?
• 네트워크·보안 정책상 원격 MCP 사용이 허용되는가?
• Docker 실행 환경을 관리할 수 있는가?

확인필요 항목은 팀 보안 정책입니다.

특히 회사 GitHub 조직에서 외부 도구 연결, OAuth 앱 사용, PAT 사용, MCP 클라이언트 사용이 어떤 기준으로 허용되는지는 조직마다 다를 수 있으므로 단정하면 안 됩니다.

2. PAT와 OAuth 중 무엇을 쓸지 정한다

GitHub MCP Server 문서에는 PAT 인증과 OAuth 방식이 함께 언급됩니다.

출처: server-configuration.md

PAT를 사용할 때 핵심은 “토큰을 발급했다”가 아니라 “토큰에 어떤 권한을 줬는가”입니다.

MCP 연결은 에이전트가 GitHub API를 다루는 통로가 됩니다. 따라서 PAT 권한이 넓으면 에이전트가 사용할 수 있는 범위도 넓어질 수 있습니다.

실무에서는 처음부터 넓은 권한을 주기보다 다음 순서가 안전합니다.

1. 읽기 전용으로 가능한지 먼저 확인한다.

2. 필요한 저장소 범위를 최소화한다.

3. 필요한 toolset만 활성화한다.

4. 실제 변경이 필요한 업무는 별도 승인 절차를 둔다.

5. 토큰 보관 위치와 만료·회수 절차를 정한다.

OAuth를 사용할 때도 마찬가지입니다.

OAuth가 더 편리해 보이더라도, 조직 정책과 승인 범위를 확인해야 합니다. VS Code 1.101+에서 원격 MCP/OAuth 사용이 문서화되어 있다는 점은 연결 가능성을 보여주는 것이지, 모든 조직에서 바로 허용된다는 뜻은 아닙니다.

3. toolsets와 개별 tools를 제한한다

GitHub MCP Server는 toolsets와 개별 tools 설정을 문서화하고 있습니다.

출처: server-configuration.md

이 부분이 실무 도입의 핵심입니다.

AI 에이전트에게 GitHub를 붙일 때 흔한 실수는 “일단 전체 기능을 열고 써보자”입니다. 하지만 GitHub 업무에는 단순 조회와 변경 작업이 섞여 있습니다. 저장소 읽기, 이슈 조회, PR 확인은 비교적 위험이 낮은 업무일 수 있지만, 이슈 작성, PR 수정, 워크플로 실행, 보안 관련 작업은 훨씬 조심해야 합니다.

따라서 처음 연결할 때는 다음처럼 좁게 시작하는 편이 좋습니다.

• 1단계: read-only 우선 적용
• 2단계: repo·issue·PR 중 실제 업무에 필요한 toolset만 활성화
• 3단계: 변경 작업이 필요한 tools는 별도 검토 후 허용
• 4단계: 조직 정책과 감사 기준에 맞게 운영
• 5단계: 사용 결과를 검증한 뒤 범위 확대

이 글의 핵심은 여기 있습니다.

GitHub MCP Server는 “AI가 GitHub를 잘 쓰게 하는 도구”이지만, 실무에서는 “AI가 GitHub에서 하지 말아야 할 일을 못 하게 하는 설정”이 먼저입니다.

실제 업무 시나리오: PR 리뷰 보조부터 시작하기

GitHub MCP Server를 처음 붙인다면, 가장 안전한 출발점은 “PR 리뷰 보조”처럼 읽기 중심의 업무입니다.

예를 들어 다음과 같은 업무 산출물을 목표로 잡을 수 있습니다.

• 열린 PR 목록 확인
• 특정 PR의 변경 내용 요약
• 관련 이슈 확인
• 리뷰어가 확인해야 할 위험 지점 정리
• 테스트·CI 상태 확인 가능 여부 점검

이 시나리오의 장점은 에이전트가 처음부터 코드를 수정하거나 워크플로를 실행하지 않아도 된다는 점입니다. 업무 가치는 얻으면서도 변경 권한은 최소화할 수 있습니다.

준비물

• MCP를 지원하는 클라이언트 또는 IDE
• GitHub MCP Server 연결 방식 결정
• 원격 서버
• 로컬 Docker 실행
• 인증 방식 결정
• OAuth
• PAT
• 조직 정책 확인
• 외부 도구 연결 허용 여부
• OAuth 또는 PAT 사용 기준
• 저장소 접근 범위
• 활성화할 toolset 목록
• read-only 적용 여부

최소 적용 단계

1. GitHub MCP Server 공식 문서를 확인한다.

출처: GitHub MCP Server

2. 사용할 MCP 클라이언트가 GitHub MCP Server 연결을 지원하는지 확인한다.

3. 원격 서버 방식 또는 로컬 Docker 실행 방식 중 하나를 선택한다.

4. OAuth 또는 PAT 인증 방식을 선택한다.

5. 처음에는 read-only를 우선 적용한다.

6. repo, issue, PR 등 필요한 toolset만 활성화한다.

7. PR 조회처럼 변경 없는 작업으로 테스트한다.

8. 에이전트가 실제로 어떤 GitHub 정보를 읽는지 확인한다.

9. 변경 작업이 필요한 경우, 개별 tools 단위로 추가 허용 여부를 검토한다.

10. 조직 정책과 거버넌스 문서에 맞게 운영 기준을 남긴다.

출처: policies-and-governance.md

검증 프롬프트 예시

처음부터 “이 PR 수정해줘”라고 요청하지 않는 편이 좋습니다.

대신 다음처럼 읽기 중심의 프롬프트로 검증할 수 있습니다.

• “현재 접근 가능한 저장소 범위를 알려줘.”
• “이 저장소의 열린 PR 목록을 읽고 제목만 요약해줘.”
• “특정 PR의 변경 내용을 읽고, 테스트 확인이 필요한 부분만 정리해줘.”
• “이슈와 연결된 PR이 있는지 확인해줘.”
• “읽기 외의 변경 작업을 시도하지 말고, 가능한 작업과 불가능한 작업을 구분해줘.”

이 검증의 목적은 에이전트의 답변 품질만 보는 것이 아닙니다.

더 중요한 것은 다음을 확인하는 것입니다.

• 의도한 저장소만 접근되는가?
• read-only 설정이 실제로 동작하는가?
• 불필요한 toolset이 열려 있지 않은가?
• 에이전트가 변경 작업을 임의로 시도하지 않는가?
• 조직 정책상 허용된 범위 안에서 동작하는가?

바로 적용하는 체크리스트 또는 비교 기준

GitHub MCP Server 도입 전 체크리스트

• [ ] GitHub MCP Server 공식 저장소와 설정 문서를 확인했다.
• [ ] 원격 서버 방식과 로컬 Docker 실행 방식 중 하나를 선택했다.
• [ ] MCP 클라이언트 또는 IDE의 지원 상태를 확인했다.
• [ ] VS Code 사용 시 1.101+ 원격 MCP/OAuth 관련 전제를 확인했다.
• [ ] OAuth 또는 PAT 중 사용할 인증 방식을 정했다.
• [ ] PAT를 쓴다면 필요한 최소 권한만 부여할 계획을 세웠다.
• [ ] 조직의 GitHub 정책, OAuth 앱 정책, 외부 도구 연결 기준을 확인했다.
• [ ] 처음에는 read-only 우선 적용을 검토했다.
• [ ] repo, issue, PR, actions, security 중 필요한 toolset만 골랐다.
• [ ] 개별 tools 단위로 불필요한 기능을 끌 수 있는지 확인했다.
• [ ] 변경 작업은 별도 승인 또는 검토 절차를 두었다.
• [ ] 첫 테스트는 PR 조회, 이슈 조회 같은 읽기 중심 업무로 진행한다.
• [ ] 에이전트가 접근 가능한 저장소와 불가능한 저장소를 구분해 검증한다.
• [ ] 토큰 회수, 권한 변경, 사용 중지 절차를 정했다.
• [ ] 운영 중 문제가 생겼을 때 누가 MCP 설정을 끄거나 수정할지 정했다.

연결 방식 비교 기준

기준	원격 GitHub MCP Server	로컬 Docker 실행
설치 난이도	MCP 클라이언트와 인증 흐름에 따라 달라짐	Docker 실행 환경 필요
인증	OAuth 또는 문서화된 인증 방식 확인 필요	PAT 등 설정 방식 확인 필요
조직 정책 영향	외부 연결·OAuth 정책 확인 필요	로컬 실행 정책과 토큰 관리 확인 필요
운영 관리	중앙 정책과 클라이언트 설정 확인 필요	로컬 환경별 설정 관리 필요
첫 적용 추천	조직 정책이 정리되어 있고 클라이언트 지원이 명확할 때	개인·팀 단위로 제한된 범위에서 실험할 때

확인필요: 각 방식의 세부 설정값과 지원 범위는 사용하는 MCP 클라이언트, IDE, 조직 정책에 따라 달라질 수 있습니다. 실제 적용 전에는 GitHub 공식 문서와 사용하는 클라이언트 문서를 함께 확인해야 합니다.

실패 시 점검 순서

GitHub MCP Server 연결이 기대대로 동작하지 않는다면, 다음 순서로 확인하는 것이 좋습니다.

1. MCP 클라이언트가 GitHub MCP Server 연결을 지원하는지 확인한다.

2. 원격 서버 또는 로컬 Docker 실행 방식이 문서와 맞는지 확인한다.

3. OAuth 또는 PAT 인증이 정상인지 확인한다.

4. PAT 사용 시 권한 범위가 너무 좁거나 넓지 않은지 확인한다.

5. read-only 설정 때문에 변경 작업이 막힌 것인지 확인한다.

6. 필요한 toolset이 비활성화되어 있지 않은지 확인한다.

7. 조직 정책에서 외부 도구, OAuth 앱, PAT 사용을 제한하고 있지 않은지 확인한다.

8. 에이전트가 접근하려는 저장소가 실제로 인증 계정에 허용되어 있는지 확인한다.

9. 변경 작업을 요청했다면, 해당 개별 tool이 활성화되어 있는지 확인한다.

10. 그래도 해결되지 않으면 공식 저장소의 서버 설정 문서와 정책·거버넌스 문서를 다시 확인한다.

마무리 + 생각해볼 질문 1개

GitHub MCP Server는 AI 에이전트를 개발 워크플로에 연결하는 강력한 통로입니다. 하지만 강력한 통로일수록 “연결”보다 “제한”이 먼저입니다.

처음부터 모든 repo, issue, PR, actions, security 도구를 열 필요는 없습니다.

read-only로 시작하고, 필요한 toolset만 켜고, 실제 업무 시나리오에서 검증한 뒤 범위를 넓히는 편이 안전합니다.

특히 회사나 팀 단위로 도입한다면 GitHub MCP Server 설정은 개인 생산성 도구 설정이라기보다 개발 조직의 권한·거버넌스 설계에 가깝습니다.

생각해볼 질문은 하나입니다.

우리 팀이 GitHub MCP Server를 붙인다면, AI 에이전트에게 가장 먼저 허용할 “읽기 전용 업무”는 무엇인가요?