Claude Code에 GitHub MCP 서버 붙여서 PR 확인 왕복 줄이기

PR을 올리고 나면 리뷰 코멘트가 달렸는지, CI가 통과했는지 확인하려고 브라우저 탭을 계속 열어봤습니다. 터미널에서 코드를 고치다가 브라우저로 넘어가 코멘트를 찾고, 다시 터미널로 돌아와 반영하는 왕복이 매번 반복됐습니다. Claude Code에 GitHub MCP 서버를 연결해서 이 왕복을 줄인 과정을 정리합니다.

어떤 작업이었나

여러 파일에 걸쳐 함수 시그니처를 바꾸는 PR을 올린 상황이었습니다. 푸시하고 몇 분 뒤 CI에서 테스트 하나가 실패했고, 리뷰어는 별도로 코멘트 두 개를 남겼습니다. 평소라면 GitHub Actions 탭을 열어 실패 로그를 찾고, PR 페이지로 돌아가 코멘트를 하나씩 읽고, 다시 로컬로 돌아와 수정하는 순서로 처리했을 텐데, 이 확인 작업 자체를 Claude Code 세션 안에서 끝내보기로 했습니다.

MCP 서버를 어떻게 연결했나

프로젝트 루트에 .mcp.json을 만들고 GitHub MCP 서버를 등록했습니다.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

토큰을 파일에 직접 적지 않고 ${GITHUB_TOKEN} 형태로 환경변수를 참조하게 했습니다. .mcp.json은 저장소에 커밋해서 협업자와 설정을 공유할 수 있는데, 토큰 값 자체가 파일에 들어가면 그대로 커밋될 위험이 있어서 참조만 남기는 편이 안전합니다. 발급한 토큰도 해당 저장소 하나만 접근하도록 스코프를 좁혔습니다.

세션을 새로 시작한 뒤 /mcp로 연결 상태를 확인했습니다. 처음에는 서버가 목록에 떴지만 도구 호출 시 401 에러가 났는데, 토큰에 repo 권한이 빠져 있던 게 원인이었습니다. 토큰을 다시 발급하고 나서야 정상적으로 붙었습니다.

이후로는 이렇게 요청했습니다.

방금 올린 PR에 CI 실패했는지, 리뷰 코멘트 달렸는지 확인해서 정리해줘

Claude Code가 PR 정보를 조회하고, 체크 목록에서 실패한 항목을 찾아 실패 로그를 가져왔습니다. 로그에는 다음과 같은 내용이 있었습니다.

FAILED: ItemRepositoryTest.updateItem_변경된_필드만_반영된다
expected: Item(id=3, title="수정됨", done=false)
actual:   Item(id=3, title="수정됨", done=true)

시그니처를 바꾸면서 updateItem 호출부 중 하나가 예전 파라미터 순서를 그대로 쓰고 있어서 done 값이 의도치 않게 덮어써지고 있었습니다. 로그만 봐서는 어느 호출부가 문제인지 바로 안 보였는데, Claude Code가 로그의 스택 트레이스와 코드를 같이 대조해서 문제가 된 호출부 줄까지 짚어줬습니다. 리뷰 코멘트 두 개도 함께 정리해서 보여줬는데, 하나는 이 실패와 같은 원인을 지적한 것이었고 다른 하나는 네이밍 제안이었습니다.

수정은 평소처럼 로컬에서 Edit으로 진행하고, 커밋과 푸시도 일반 git 명령으로 했습니다. MCP 서버는 GitHub 쪽 상태를 읽어오는 데만 썼고, 쓰기 작업은 기존 워크플로우를 그대로 유지했습니다.

결과와 얻은 팁

MCP 서버를 붙였다고 모든 읽기/쓰기를 AI에게 맡길 필요는 없습니다. 상태 확인처럼 반복적으로 왕복이 생기는 부분만 맡기고, 실제 코드 수정과 푸시는 기존 방식대로 두니 통제감을 잃지 않으면서도 왕복 횟수가 줄었습니다.
연결 직후 도구가 목록에 보인다고 바로 동작을 보장하지 않았습니다. 실제 호출을 한 번 해봐야 토큰 권한 문제 같은 게 드러났습니다.
토큰은 저장소 하나로 스코프를 좁히고, .mcp.json에는 값 대신 환경변수 참조만 남기는 편이 안전합니다. 프로젝트 스코프 설정 파일은 커밋되어 공유되는 걸 전제로 다뤄야 합니다.
CI 로그를 그대로 읽어오는 것과, 그 로그를 코드와 대조해서 원인 줄까지 짚어주는 것은 다른 단계입니다. 로그만 붙여넣고 "이거 왜 실패했는지 봐줘"라고 물었을 때보다, 관련 코드까지 같이 열어보게 하니 원인을 더 빨리 찾았습니다.