GitHub MCP Server를 읽기 전용으로 시작하는 법: CI 실패·보안 경고를 주간 점검표로 바꾸기

GitHub MCP를 처음 연결할 때는 PR 수정이나 이슈 생성부터 하기보다, actions와 code_security 조회 결과를 사람이 검토하는 주간 점검표부터 만드는 편이 안전합니다.

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

GitHub 저장소 상태를 AI 에이전트에게 물어보고 싶지만, 처음부터 쓰기 권한까지 주기는 부담스럽습니다. 특히 운영 담당자에게 필요한 것은 코드 변경이 아니라, 아래 질문에 답하는 정기 점검 결과인 경우가 많습니다.

• 이번 주에 실패한 GitHub Actions 실행은 무엇인가?
• Code Scanning 경고 중 확인이 필요한 항목은 무엇인가?
• 담당자가 다음으로 확인해야 할 저장소·워크플로·경고는 어디인가?

이 글의 목표는 분명합니다. GitHub MCP Server를 읽기 전용으로 연결하고, CI 실패와 보안 경고를 한 장의 주간 점검표로 정리하는 것입니다. 에이전트가 이슈를 만들거나 PR을 수정하지 않는 상태에서 시작합니다.

GitHub는 호스팅형 원격 MCP 서버에서 도구군별 연결과 /readonly 경로를 안내합니다. 처음부터 모든 GitHub 기능을 열기보다, 이번 업무에 필요한 actions와 code_security 도구군만 읽기 전용으로 분리하는 편이 낫습니다.

GitHub MCP Server 원격 서버 문서

먼저 정할 것: 에이전트의 결과물이 아니라 점검표의 범위

GitHub MCP를 연결하기 전에 프롬프트보다 먼저 정할 것은 산출물입니다. 이번 범위에서는 “CI 실패·보안 경고 주간 점검표” 하나만 만듭니다.

점검표에는 다음 항목만 넣습니다.

구분	점검 항목	사람이 확인할 내용
GitHub Actions	실패한 실행 또는 워크플로	저장소, 워크플로 이름, 실패 시점, 후속 확인 대상
Code Scanning	열린 보안 경고	저장소, 경고 유형, 우선 확인 필요 여부
후속 조치	사람이 결정할 일	재실행 여부, 담당자 확인, 수정 작업 전환 여부

여기에는 분명한 제한이 있습니다. 에이전트는 “어떤 항목을 확인해야 하는지”를 정리할 수 있지만, 재실행·이슈 생성·PR 생성·코드 수정은 하지 않습니다. 점검표는 운영 관찰 결과이고, 조치는 사람이 승인한 뒤 별도 절차로 넘깁니다.

이 구분은 이전의 “PR 병합 전 보안 수정 제안”과도 다릅니다. 여기서 다루는 대상은 개발자가 아니라 운영 점검 담당자이며, 결과물도 수정 제안이 아닌 읽기 전용 관찰 리포트입니다.

GitHub MCP를 actions·code_security 읽기 전용으로 연결하는 순서

1. 연결할 도구군을 두 개로 제한합니다

GitHub MCP Server는 원격 서버에서 도구군을 나누어 연결할 수 있도록 안내합니다. 이번 목적에는 아래 두 범위만 선택합니다.

• actions: GitHub Actions 실행 상태와 실패 여부를 점검하기 위한 범위
• code_security: Code Scanning 관련 경고를 확인하기 위한 범위

이 단계에서는 저장소 전반의 쓰기 작업이나 협업 작업 도구군을 함께 연결하지 않습니다. 필요한 도구가 늘어날수록 점검표 작성이라는 처음 목적에서 벗어날 가능성도 커집니다.

원격 MCP 서버의 도구군 구성과 읽기 전용 엔드포인트는 GitHub 공식 문서에서 확인할 수 있습니다. MCP 클라이언트에 URL을 등록할 때는 해당 문서의 도구군별 원격 URL과 /readonly 경로를 사용합니다.

GitHub MCP Server: Remote server

2. 인증 방식은 OAuth 또는 PAT 중 조직 정책에 맞춰 고릅니다

GitHub MCP Server 문서는 원격 연결에서 OAuth와 PAT 사용 구성을 안내합니다. 어떤 방식을 쓸지는 편의성보다 조직 정책을 먼저 확인해야 합니다.

• OAuth 연결이 조직의 MCP·OAuth 정책에 허용되는지 확인합니다.
• PAT를 사용한다면 조직의 PAT 정책과 SSO 적용 여부를 확인합니다.
• 연결 대상 저장소가 개인 계정인지, 조직 소유인지 확인합니다.
• 인증 정보는 프롬프트, 점검표, 공유 문서에 포함하지 않습니다.

GitHub는 배포 방식에 따라 인증과 조직 정책이 적용되는 방식을 별도로 설명합니다. 조직에서 허용하는 MCP 도구군, OAuth 앱, PAT 세부 권한은 각 조직의 정책을 확인해야 합니다. 이 부분은 외부 문서만으로 일괄 단정할 수 없습니다.

GitHub MCP Server: Policies and governance

GitHub MCP Server 저장소

3. 샘플 저장소에서 조회 요청 하나로 시작합니다

처음부터 조직 전체를 대상으로 주간 점검을 실행하지 않습니다. 조회가 가능한 샘플 저장소나 승인된 테스트 저장소 한 곳에서 연결을 확인합니다.

에이전트에는 아래처럼 제한된 질문을 요청할 수 있습니다.

이 저장소에서 최근 실패한 GitHub Actions 실행을 정리해 주세요. 실행이나 설정을 변경하지 말고, 워크플로 이름과 확인이 필요한 항목만 표로 작성해 주세요.

그다음 보안 경고 조회를 별도로 요청합니다.

이 저장소의 열린 Code Scanning 경고를 점검표 형식으로 정리해 주세요. 경고를 닫거나 수정하지 말고, 사람이 확인할 항목만 제시해 주세요.

한 번의 요청에 CI 상태와 보안 경고, 수정 방향, 이슈 생성까지 모두 넣으면 조회 범위와 행동 범위가 섞입니다. 처음에는 질문도 두 개로 나누는 편이 결과를 검토하기 쉽습니다.

4. 읽기 전용 연결은 “조회 성공”과 “쓰기 차단”을 함께 확인합니다

읽기 전용 설정은 결과가 보인다고 끝나지 않습니다. 아래 두 종류의 검증이 모두 필요합니다.

첫째, 허용된 조회가 작동하는지 확인합니다.

• Actions 관련 정보를 조회할 수 있는가
• Code Scanning 경고를 조회할 수 있는가
• 결과가 의도한 저장소 범위 안에 머무르는가

둘째, 허용하지 않은 행동이 차단되는지 확인합니다.

• 이슈를 생성해 달라고 요청했을 때 실행되지 않는가
• PR을 수정하거나 생성해 달라고 요청했을 때 실행되지 않는가
• 워크플로 재실행이나 설정 변경 요청이 수행되지 않는가

실패 요청은 실제 운영 저장소가 아니라 테스트 대상에서 수행하는 편이 좋습니다. 목적은 실패를 만드는 것이 아니라, 연결에 쓰기 도구가 섞이지 않았는지 확인하는 것입니다.

주간 점검표를 만드는 프롬프트와 검토 기준

연결이 확인되면 정기 점검은 같은 형식으로 반복합니다. 예시는 아래와 같습니다.

승인된 저장소 범위에서 지난 점검 이후의 GitHub Actions 실패와 열린 Code Scanning 경고를 정리해 주세요.

실행·수정·생성 작업은 하지 마세요.

결과는 구분 / 저장소 / 항목 / 확인이 필요한 이유 / 사람이 다음에 결정할 일 순서의 표로 작성해 주세요.

사실로 확인되지 않은 원인은 추정하지 말고 “확인 필요”로 표시해 주세요.

점검 결과를 받을 때는 다음 기준으로 검토합니다.

확인 기준	통과 조건
범위	승인한 저장소와 도구군의 정보만 포함됩니다.
사실성	실패 원인이나 보안 영향이 조회 결과로 확인되지 않았다면 추정하지 않습니다.
행동 제한	이슈 생성, PR 수정, 워크플로 재실행 등 쓰기 행동이 결과나 실행 내역에 없습니다.
후속 조치	“누가 무엇을 확인할지”는 제시하되, 에이전트가 조치를 실행하지는 않습니다.
보안	토큰, 인증 헤더, 개인 식별 가능 정보가 점검표에 노출되지 않습니다.

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

• [ ] 결과물을 “CI 실패·보안 경고 주간 점검표” 하나로 한정했는가?
• [ ] 원격 MCP 연결에서 actions, code_security만 선택했는가?
• [ ] GitHub 공식 문서의 /readonly 경로를 사용했는가?
• [ ] OAuth 또는 PAT 사용 전 조직의 MCP·OAuth·PAT·SSO 정책을 확인했는가?
• [ ] 테스트 저장소에서 Actions 조회와 Code Scanning 조회가 모두 되는지 확인했는가?
• [ ] 이슈 생성, PR 수정, 워크플로 재실행 요청이 차단되는지 확인했는가?
• [ ] 점검표에 확인되지 않은 원인이나 영향도를 단정하지 않았는가?
• [ ] 점검 결과를 받은 뒤 실제 조치는 사람이 승인하는 흐름으로 분리했는가?

마무리

GitHub MCP의 첫 적용 과제는 “에이전트가 GitHub에서 무엇을 할 수 있는가”보다 “운영 담당자가 매주 무엇을 확인할 수 있는가”에 두는 편이 낫습니다.

actions와 code_security를 읽기 전용으로 분리하면 CI 실패와 보안 경고를 한 화면의 점검표로 모으면서도, 이슈 생성·PR 수정 권한은 열지 않을 수 있습니다. 조회 성공만 확인하지 말고, 쓰기 요청이 실제로 차단되는지도 테스트해야 합니다.

생각해볼 질문: 지금 팀에 필요한 것은 GitHub 작업을 대신 실행하는 에이전트일까요, 아니면 사람이 우선순위를 판단할 수 있도록 실패와 경고를 정리해 주는 관찰 도구일까요?