GitHub MCP가 연결하는 것#
이슈를 읽은 뒤 코드 수정과 PR 검토로 이어갈 수 있도록 작업을 나눕니다. 이 절의 「권장 순서」 흐름은 최소 권한을 고려한 제안이며 Mirr Code에서 실제로 수행하거나 검증하지 않았습니다.
GitHub 공식 문서에서 확인한 범위입니다. 연결에 필요한 도구와 권한은 실제 서버 및 계정 설정에 따라 다릅니다. 출처 확인: 2026-11-01.
| 항목 | 공식 문서의 내용과 확인할 점 |
|---|---|
| 기능 | 공식 서버는 저장소 조회와 이슈·PR 관리 기능을 제공합니다. (GitHub MCP 서버) |
| 원격 주소 | GitHub 공식 원격 서버의 HTTP 주소는 https://api.githubcopilot.com/mcp/입니다. (원격 서버 안내) |
| 인증 | 원격 서버는 클라이언트에 따라 OAuth 또는 개인 액세스 토큰(PAT)을 사용합니다. OAuth 지원은 호스트마다 다릅니다. (공식 서버 안내) |
| 최소 권한 | 가능한 경우 세분화된 PAT에서 필요한 저장소와 권한만 선택합니다. 각 API의 필요 권한은 별도로 확인하세요. (PAT 관리) |
| 읽기와 쓰기 | 서버의 읽기 전용 모드는 쓰기 도구를 제외합니다. 도구 묶음 제한과 계정 권한 제한은 별도로 확인하세요. (서버 설정) |
| 위험 | 이슈·PR 등의 외부 내용을 신뢰할 수 없는 입력으로 취급하고, 비공개 코드와 토큰이 외부로 전달되지 않도록 확인합니다. 쓰기 전에는 대상과 변경 내용을 검토하세요. (서버 설정의 프롬프트 인젝션 설명) |
권장 순서 — 실제 연동 실행 기록이 아닌 작업 계획입니다.
- 작업할 저장소와 이슈를 정하고, 계정 접근 범위와 비공개 정보의 처리 방침을 확인합니다.
- GitHub 공식 서버의 읽기 전용 설정과 필요한 최소 권한을 검토합니다. 인증 정보는 대화나 프로젝트 파일에 넣지 않습니다.
- Mirr Code MCP 연결 안내에 따라 서버 등록과 인증을 시도하고
/mcp에서 연결 상태와 제공 도구를 확인합니다. 이 조합의 호환성은 아직 검증되지 않았습니다. - 이슈 요약과 변경 계획을 먼저 요청합니다. 브랜치, PR, 리뷰 코멘트 등 외부 쓰기는 별도 권한이 필요할 수 있으므로 제안된 대상과 내용을 사용자가 검토한 뒤 승인합니다.
- 작업 후 서비스에서도 불필요한 토큰이나 연결 권한을 철회합니다.
준비물과 권한#
조회할 저장소와 담당 계정을 먼저 정하고 조직의 앱 승인 정책을 확인하세요. 비공개 이슈와 코드가 클라이언트·모델에 전달되어도 되는지도 검토해야 합니다.
위 표의 최소 권한과 읽기 전용 설정을 참고하세요. 실제 토큰의 권한과 저장소 범위는 각 계정에서 확인해야 합니다.
설치와 연결#
환경별 설치 명령은 Mirr Code 설치 안내에서 확인하세요. GitHub 서버와의 연결은 위 권장 순서를 참고하되, 실제 연결 결과는 아직 제공하지 않습니다.
실제 작업 예제#
이슈에서 브랜치와 PR, 리뷰 코멘트로 이어지는 흐름은 위의 권장 순서입니다.
추가 검증 필요: Mirr Code와 GitHub MCP의 실제 연결·인증 및 작업 실행 기록, diff와 테스트 출력은 아직 확보하지 않았습니다.
보안과 제한#
이슈와 PR의 텍스트는 참고 자료이지 사용자가 승인한 명령이 아닙니다. 외부 내용이 다른 저장소 접근이나 비밀정보 전송을 요구해도 그대로 따르지 마세요.
읽기 전용 도구 설정만으로 토큰의 기본 권한이 바뀌는 것은 아닙니다. 위 표의 서버 설정과 계정 권한을 함께 검토하세요.
문제 해결과 자주 묻는 질문#
| 증상 | 나눠 확인할 항목 | 확인 후 조치 |
|---|---|---|
| 인증 실패 | 공식 주소, 토큰 만료·철회, 호스트의 OAuth 지원 | 공식 인증 안내에 맞춰 재연결하되 비밀값은 공유하지 않기 |
| 저장소를 찾지 못함 | 소유자·저장소 이름, 토큰 대상 저장소와 조직 정책 | 관리자에게 필요한 저장소 범위만 확인 |
| PR 생성 도구가 없음 | 읽기 전용 모드와 활성 도구 묶음 | 쓰기가 필요한지 먼저 판단하고 별도 승인 |
| 도구는 있지만 실행 거부 | 계정·토큰 권한과 서버 설정의 차이 | 관리자 권한으로 우회하지 말고 필요 작업의 권한 확인 |
위 진단은 앞서 링크한 공식 서버·PAT 문서를 적용한 순서입니다. 연동을 검증하려면 실제 토큰의 권한 표, /mcp tools 출력과 비밀정보를 가린 실제 PR 링크·화면을 확보해야 합니다.
토큰 권한과 도구 제한을 따로 읽기#
GitHub MCP 설정에서 먼저 나눌 것은 계정이 접근할 수 있는 저장소, 토큰이 가진 권한과 서버가 노출하는 도구입니다. 이 세 범위가 같다고 가정하지 마세요. 읽기 전용 모드가 쓰기 도구를 제외해도 토큰의 기본 권한이 줄어드는 것은 아닙니다. 도구 묶음을 이슈로 한정하는 것과 특정 저장소만 접근하도록 토큰을 만드는 것도 다릅니다. 필요한 작업에서 거꾸로 범위를 정하면 불필요한 권한을 줄일 수 있습니다.
공식 서버 설정 문서는 원격 서버의 X-MCP-Readonly와 X-MCP-Toolsets 헤더를 설명합니다. 이 헤더를 지원하는 호스트에서 어떻게 전달하는지는 해당 클라이언트에서 확인해야 합니다. Mirr가 그 설정을 그대로 받는다고 보장하지 않습니다. 다른 클라이언트용 JSON을 Mirr 설정 파일로 복사하지 마세요. 서버의 기능 설명과 실제 호스트의 전송·인증·헤더 지원을 분리해서 검토하는 것이 필요합니다.
| 작업 목적 | GitHub에서 검토할 최소 범위 | 서버·호스트에서 별도 확인 |
|---|---|---|
| 이슈 내용 읽기 | 대상 저장소와 이슈 읽기에 필요한 권한 | 읽기 도구만 노출되는지 |
| 코드와 변경 조회 | 필요한 저장소의 콘텐츠·PR 읽기 | 반환 데이터의 공개·전송 범위 |
| 브랜치·코드 변경 | 선택한 API의 콘텐츠 쓰기 요구 | 실제 코드 변경과 push 승인 |
| PR 생성 | 선택한 PR API의 쓰기 권한 | base/head·제목·본문의 사람 검토 |
| 리뷰 코멘트 게시 | 사용하는 댓글·리뷰 API의 권한 | 현재 head SHA와 결과의 일치 |
| 연결 종료 | 토큰·앱 승인 철회 위치 | 클라이언트 제거와 서비스 철회의 차이 |
이 표는 특정 토큰을 발급해 검사한 scope 표가 아닙니다. 세분화된 PAT는 저장소 권한 이름과 접근 대상, 만료와 조직 승인을 실제 화면에서 확인해야 합니다. classic PAT의 scope 이름을 다른 토큰의 권한 이름처럼 옮기지 마세요. 각 API가 요구하는 권한도 다를 수 있습니다. 필요한 작업을 하나 고른 뒤 공식 토큰 안내와 API 요구를 대조하고 실제 부여된 권한을 가린 기록으로 남겨야 권한 조건을 채울 수 있습니다. 요청한 범위와 실제 승인 범위를 나란히 보면 불필요한 접근을 찾을 수 있습니다.
도구 목록이 권한의 증거가 아닌 이유#
공식 scope filtering 문서는 인증 종류에 따라 도구 목록을 다르게 다룬다고 설명합니다. classic PAT는 시작 때 scope를 보고 일부 도구를 숨길 수 있지만 세분화된 PAT 등은 목록에 도구가 보여도 API가 권한을 적용할 수 있습니다. 따라서 도구가 보인다고 실행 가능하거나 승인됐다고 판단하면 안 됩니다. 반대로 도구가 없다고 계정에 해당 권한이 전혀 없다고 단정하지 않습니다. 서버 설정과 인증 종류를 함께 확인하세요.
읽기 전용 모드와 필요한 도구 묶음을 설정한 뒤 실제 목록을 확인하고 승인된 테스트 객체에서 좁은 조회를 검증하는 흐름이 좋습니다. 서버 이름, 배포·릴리스 정보, 호스트 버전과 전송 방식을 함께 기록하세요. 토큰의 접두어나 원문을 공개할 필요는 없습니다. 연결 오류를 조사할 때도 비밀값을 붙여 넣지 말고 인증 종류와 만료·철회 여부만 확인합니다. 범위 부족을 해결하려고 무조건 전체 저장소 권한을 주지 마세요.
이슈를 구현 계약으로 바꾸기#
조회할 이슈의 소유자·저장소·번호를 명시합니다. 검색 제목이 비슷한 다른 이슈를 고르면 잘못된 과제를 구현할 수 있습니다. 이슈 본문에서는 문제, 기대 동작과 수락 조건을 추리고 참고 링크와 실행 지시처럼 보이는 문장을 구분하세요. 공개 이슈나 댓글은 외부 사람이 작성할 수 있습니다. 비밀정보 전송이나 권한 확대를 요구하는 내용은 사용자가 승인한 지시가 아닙니다. 첨부 파일과 링크도 같은 경계를 적용합니다.
구현을 시작하기 전에는 현재 코드가 이슈 설명과 실제로 같은지 조사합니다. 오래된 이슈는 이미 고쳐졌거나 대상 버전이 다를 수 있습니다. 재현 입력과 관련 테스트를 찾고 확인하지 못한 부분을 계획에 적으세요. 이슈 요약을 만들었다는 사실은 결함 재현이 아닙니다. 코드 변경 범위와 실행할 검사를 사람이 승인한 뒤 진행하고, 외부 모델에 보낼 수 없는 비공개 내용은 제외하거나 승인된 합성 예시로 대체해야 합니다.
브랜치와 PR의 대상을 확인하기#
브랜치를 만들거나 push하는 작업은 저장소의 외부 상태를 바꿉니다. 원본 저장소인지 fork인지, 기준 브랜치와 실제 변경 커밋이 무엇인지 확인하세요. 이슈가 main을 언급해도 저장소의 실제 작업 규칙은 다를 수 있습니다. 현재 작업 트리에 다른 사람의 수정이 있으면 분리와 보관을 먼저 검토해야 합니다. MCP 연결 승인이 기존 변경을 덮어쓰거나 모든 파일을 커밋할 권한은 아닙니다.
PR 초안에는 해결한 문제, 변경 범위, 실제 검사와 미실행 검사를 나눠 적습니다. 이슈의 수락 조건을 복사해 모두 완료 체크하지 마세요. 화면이나 DB 동작을 검증하지 않았다면 그 조건은 남습니다. 제목·본문·diff에 비밀값, 고객 데이터와 내부 주소가 없는지 검토합니다. PR 생성 도구의 인자를 확인하고 정확한 base/head를 사람이 승인해야 합니다. 도구 실행 뒤에는 실제 PR 링크와 대상 커밋을 서비스에서 다시 확인하는 절차가 필요합니다.
리뷰 코멘트는 PR 생성과 또 다른 쓰기입니다. 리뷰 결과가 가리키는 커밋과 현재 PR head가 다르면 오래된 지적을 최신 결과로 올릴 수 있습니다. 파일 위치, 재현 근거와 중복 여부를 확인하세요. 같은 결과를 여러 번 게시하지 않도록 기존 댓글과 실행 식별자를 검토하는 방식도 필요합니다.
CI와 모델 인증을 섞지 않기#
PR 검사에는 신뢰하지 못하는 코드가 들어올 수 있습니다. fork PR뿐 아니라 같은 저장소의 브랜치도 자동으로 신뢰할 수 있는 것은 아닙니다. 모델 자격 증명이 있는 환경에서 검토되지 않은 PR 코드를 실행하지 않도록 검사와 리뷰, 게시를 분리하세요. pull_request_target으로 바꾸어 비밀값 제한을 우회하는 설계를 피해야 합니다. 권한 있는 후속 작업도 이전 산출물을 실행 코드로 신뢰하면 위험합니다.
PR 제목과 본문, 댓글과 파일 내용은 데이터입니다. 셸 명령 안에 직접 삽입하면 의도하지 않은 실행이 생길 수 있습니다. 신뢰한 게시 코드에서 형식과 길이, 저장소·PR 번호·현재 SHA를 확인하는 흐름을 검토하세요. 결과가 비거나 인증과 테스트가 실패했을 때 리뷰 통과로 처리하지 않습니다. Mirr의 무인 인증, CI 종료 코드와 실제 게시 경로는 별도 제품 검증이며 공식 GitHub MCP 문서가 이를 대신하지 않습니다.
비공개 코드와 모델 제공자의 경계#
GitHub에서 읽을 권한이 있다고 외부 모델에 전달할 권한까지 있는 것은 아닙니다. 조직의 코드 처리 정책과 사용하는 모델 제공자의 보관·학습·삭제 조건을 확인하세요. 조회 결과에는 이슈 본문뿐 아니라 코드, 로그와 첨부된 고객 정보가 섞일 수 있습니다. 필요한 파일과 부분만 읽도록 범위를 제한하는 편이 좋습니다. 민감정보는 요약해도 여전히 민감할 수 있으므로 공개 가능 여부를 따로 판단해야 합니다.
서버의 lockdown 같은 보호 옵션이 있어도 모든 악성 지시가 차단된다고 가정하지 마세요. 외부 자료가 다른 도구의 호출과 데이터 공유를 유도할 수 있습니다. 사용자의 원래 목적과 승인한 저장소 범위를 유지하고 예상하지 못한 외부 쓰기는 중단해 검토합니다. 로그와 스크린샷에도 토큰, 사용자 정보와 비공개 코드가 담길 수 있으므로 실제 증거를 공유하기 전에 직접 가려야 합니다. 자동 마스킹만으로 충분하다고 보장하지 않습니다.
인증·권한·대상 오류를 나눠 조사하기#
인증이 실패하면 공식 서버 주소와 호스트의 지원 전송·인증 종류부터 확인합니다. 인증은 됐는데 저장소가 안 보이면 소유자와 이름, 토큰 대상 저장소와 조직 정책을 봅니다. 도구가 실행됐지만 작업이 거부되면 실제 API 권한과 읽기 전용 설정을 구분하세요. 오류 하나를 해결하려고 인증 종류를 바꾸거나 관리자 토큰을 넣는 것은 먼저 검토할 대응이 아닙니다. 필요한 최소 작업을 기준으로 원인을 좁혀야 합니다.
쓰기 요청이 시간 초과되면 실제로 반영됐는지 먼저 조회합니다. 이미 PR이나 댓글이 만들어졌을 수 있어 재시도가 중복을 만들 수 있습니다. 요청한 대상과 내용, 확인한 현재 상태를 남기고 서비스가 제공하는 중복 방지 계약을 검토하세요. 연결 제거는 생성한 PR과 댓글을 취소하지 않습니다. 잘못 게시했다면 서비스에서 별도 승인으로 수정하고 토큰 철회와 기록 보존을 각각 처리해야 합니다.
실제 검증을 위해 준비할 최소 과제#
다음은 미실행 가상 과제입니다. 승인된 예시 저장소에 이미 변경 브랜치가 있고, 사용자는 이슈를 읽어 PR 초안 문구를 검토하려 합니다. 이 단계에는 이슈·변경 조회만 필요하며 새 브랜치 생성, 코드 쓰기와 PR 게시를 실행하지 않는다고 정합니다. 나중에 PR 게시까지 승인받으면 별도의 작업으로 전환합니다. 어떤 API를 선택하는지에 따라 검토할 대상과 인자가 달라집니다.
| 필요한 결과 | 공식 API에서 구분할 작업 | 검토할 권한·대상 | 가상 과제의 판단 |
|---|---|---|---|
| 이슈의 수락 조건 | 이슈 조회 | 해당 저장소·이슈 접근과 필요한 읽기 권한 | 조회만, 상태·담당자 변경은 제외 |
| 코드의 실제 변경 | 콘텐츠·PR 변경 조회 | 대상 커밋과 읽기 범위 | 제목 요약 대신 변경 내용을 근거로 초안 작성 |
| 이미 존재하는 브랜치로 PR 생성 | POST /repos/{owner}/{repo}/pulls | 선택 토큰의 API 권한, head와 base | 별도 게시 승인 전에는 호출하지 않음 |
| diff의 특정 줄에 지적 남기기 | PR review comment 생성 | 해당 PR의 쓰기 권한과 커밋·파일·줄 | 일반 댓글과 구별해 초안만 검토 |
| 파일 내용 자체 변경 | 콘텐츠 쓰기 | 콘텐츠 수정 권한과 승인한 파일 | PR 생성에 끼워 넣지 않는 별도 변경 |
이 표는 토큰 발급 안내나 실제 허용 결과가 아닙니다. 각 API의 권한표는 인증 종류와 대상 저장소에 맞춰 확인해야 합니다. 특히 PR 생성의 head는 변경이 구현된 브랜치이고 base는 반영할 기존 브랜치입니다. PR 요청에 브랜치 이름을 넣는 것과 그 브랜치의 코드를 만들거나 push하는 일은 분리하세요. 다른 사용자의 저장소에서 온 브랜치라면 공식 문서의 사용자:브랜치 표기와 대상 저장소 관계도 확인합니다.
변경 승인 문구를 실제 인자와 대조하기#
가상 PR에서 “빈 금액을 거부하는 분기를 확인해 주세요”라는 코멘트를 남긴다고 합시다. 문구는 같아도 PR 타임라인의 일반 댓글과 diff의 특정 줄에 붙는 리뷰 댓글은 다른 결과입니다. 공식 리뷰 댓글 API는 commit_id, path와 줄·방향 같은 위치 정보를 다룹니다. 검토한 파일을 다른 커밋에서 읽었거나 삭제된 줄을 새 코드의 방향으로 지정하면 의도한 위치와 맞지 않을 수 있습니다. 생성된 문장뿐 아니라 어떤 종류의 코멘트인지 먼저 정해야 합니다.
공식 문서가 폐기 방향을 알리는 position을 기본값으로 복사하지 말고 현재 도구가 지원하는 인자를 확인하세요.
코멘트를 쓰는 API는 알림을 발생시킬 수 있습니다. 같은 문구를 다른 위치에 반복 게시하는 일을 피하고, 승인·변경 요청이라는 리뷰 상태를 바꾸는 작업까지 포함하는지 구분해야 합니다. 코멘트 초안을 승인했다고 PR 자체를 승인하거나 병합할 권한이 생기지는 않습니다. 승인 뒤 코드가 바뀌어 대상이나 내용의 근거가 달라졌다면 범위를 다시 검토해야 합니다. 실제 게시 전에 현재 PR의 커밋이 검토한 것과 같은지 확인하는 앞 절의 원칙을 이 위치 정보에도 적용하세요.
최소 권한 요청을 관리자에게 전달하는 방법#
공식 MCP 문서는 원격 OAuth의 scope challenge와 PAT의 고정 권한을 구분합니다. OAuth에서는 호출에 필요한 추가 scope를 서버가 요구하고 호스트가 승인 절차를 처리할 수 있습니다. 이 흐름이 Mirr에서 지원되는지는 별도 검증 대상입니다. 반면 PAT는 호출 중 대화의 승인만으로 권한이 늘어나지 않습니다. 필요한 권한을 검토해 토큰 설정을 바꾸는 서비스 측 작업과 그 뒤 서버가 이를 인식하는 과정이 필요합니다. 그 변경도 조직 승인을 받아야 합니다.
예를 들어 이슈 요약 중 파일 쓰기 권한을 추가하라는 요구가 나오면 요청 목적과 맞지 않습니다. 반대로 별도 승인된 코드 수정에서 workflow 파일을 바꾼다면 일반 파일 변경과 요구가 달라질 수 있습니다. 공식 scope 문서는 파일 쓰기 호출이 workflow 파일을 바꿀 때 repo 외에 workflow scope를 요구하는 경우를 설명합니다. 이는 OAuth/classic scope 문맥의 설명이지 세분화된 PAT 권한 이름이나 모든 클라이언트의 동작을 보장하는 표가 아닙니다. 필요한 파일과 권한만 관리자에게 전달하세요.
읽기 전용 공개 저장소 도구가 항상 보이는 예외나 scope 발견 실패 뒤 필터 없이 계속하는 경로도 문서에 있습니다. 따라서 classic PAT라도 목록에 보인다는 관찰 하나로 실행 권한을 확정할 수 없습니다. 발견 실패를 해결하려고 비밀값을 로그에 붙이거나 관리자 토큰으로 바꾸지 마세요. 작업 기간과 종료 조건을 정하고, 사용 뒤 서비스의 토큰·앱 철회와 클라이언트 연결 제거를 따로 확인합니다.
같은 과제로 연결 성공과 작업 성공을 나눠 기록하기#
가상 과제에서 인증은 됐고 이슈 조회도 됐지만 PR 생성 요청이 거부됐다고 합시다. 먼저 “같은 토큰으로 조회가 됐다”와 “PR 생성에 필요한 권한과 인자가 맞다”를 분리합니다. 필요한 도구가 읽기 전용 설정 때문에 빠진 경우와 API가 요청을 받아 거부한 경우는 조사 위치가 다릅니다. 이 가정은 오류 재현 결과가 아니라 실패를 분류하는 연습입니다.
공식 PR API의 422는 검증 실패 외의 제한 사유도 포함할 수 있으므로 상태 코드 하나로 “권한만 부족하다”고 결론 내리지 않습니다. 응답의 공개 가능한 오류와 요청 인자를 함께 조사하세요. 실제 PR이 만들어졌어도 병합·배포는 별도 작업이며, 리뷰 코멘트의 성공도 따로 확인해야 합니다.
추가 근거: 공식 scope filtering, 서버 설정과 읽기 전용 모드. 문서의 조건부 권한 동작을 가상 결정에 적용했습니다.
다음에 연결할 것#
여러 서비스를 연결하더라도 한 서비스의 승인이 다른 서비스의 쓰기 승인까지 포함하지는 않습니다.
이슈 관리 작업을 함께 살펴보려면 Linear MCP 연결과 권한을 참고하세요.
관련#
편집 메모 (2026-11-02): 조회·PR·토큰 철회 FAQ와 오류별 점검표를 보충했습니다.