풀 리퀘스트는 죽었다 2026 - 리뷰어 코멘트를 AI가 직접 받는 MCP 코드리뷰 워크플로 체크리스트

2026년 3월 5일 GitHub는 Copilot code review가 agentic tool-calling architecture로 전환됐다고 밝혔다. GitHub 공식 문서 기준으로 Copilot code review에 달린 인간 답글은 Copilot에게 보이지 않지만, Copilot coding agent는 이슈나 코멘트에서 작업을 받고 PR 위에서 리뷰 피드백에 맞춰 반복 수정할 수 있다. GitHub 공식 MCP Server와 GitHub Actions 이벤트는 pull request review comment, review thread, check run을 읽고 쓰는 흐름을 이미 열어 두고 있다.

2026년 이전의 PR은 거의 항상 사람이 사람에게 넘기는 마지막 문서에 가까웠습니다. 사람이 열고, 사람이 리뷰하고, 사람이 답글 달고, 사람이 다시 고쳤죠.

지금은 얘기가 달라졌습니다.

PR은 여전히 필요합니다.

하지만 PR이 컨텍스트의 종착지는 아닙니다.

이제는 리뷰 코멘트가 붙는 순간 AI가 그 코멘트를 읽고, 관련 파일을 더 가져오고, 체크런까지 보고, 다시 수정 제안을 밀어 넣는 흐름이 현실적인 운영 패턴이 됐습니다.

그래서 이 글에서 말하는 “풀 리퀘스트는 죽었다”는 표현은 기능이 사라졌다는 뜻이 아닙니다.

내 해석을 먼저 밝히면, PR은 죽은 게 아니라 “사람만 대화하는 마지막 방”이라는 역할이 죽어가고 있다는 뜻에 가깝습니다.

한 줄 요약: 2026년의 PR은 승인 문서라기보다 라우터에 가깝습니다. 리뷰어 코멘트가 달리면, 사람만 읽는 게 아니라 에이전트도 읽고 움직일 수 있게 됐습니다. 다만 이 흐름이 진짜 잘 굴러가려면 PR 안의 diff만 보는 게 아니라, PR 이전 의사결정 로그까지 같이 물려야 합니다.

지금 제일 중요한 사실 5개

GitHub는 2026년 3월 5일 Copilot code review가 에이전트형 툴 호출 구조로 바뀌었다고 공식 발표했습니다. 이 말은 리뷰 모델이 단순 diff 요약기에서 더 넓은 저장소 문맥을 가져오는 방향으로 진화했다는 뜻입니다.
GitHub 문서상 Copilot code review 댓글에 사람이 답글을 달아도, 그 답글은 Copilot code review에게 보이지 않습니다. 즉 “리뷰 봇”과 “리뷰에 반응해 수정하는 에이전트”는 아직 같은 존재가 아닙니다.
반대로 Copilot coding agent는 이슈나 코멘트에서 일을 받고, PR 위에서 리뷰 피드백에 맞춰 다시 움직일 수 있다고 GitHub 문서가 명시합니다. 이게 진짜 포인트입니다.
GitHub 공식 MCP Server는 pull_request_read, pull_request_review_write, add_reply_to_review_comment, add_comment_to_pending_review 같은 도구를 제공합니다. 즉 GitHub 밖의 에이전트도 PR 리뷰 흐름에 들어올 수 있습니다.
GitHub Actions는 pull_request_review_comment, pull_request_review, pull_request_review_thread, issue_comment 이벤트를 따로 제공합니다. 코멘트 종류에 따라 트리거를 세밀하게 쪼갤 수 있다는 뜻입니다.

여기서 벌써 느낌이 오죠.

이제 중요한 건 “PR을 쓸까 말까?”가 아닙니다.

어떤 이벤트를 누가 받고, 어떤 문맥을 붙여서, 어떤 권한으로 응답하게 할까가 핵심입니다.

왜 갑자기 “PR은 죽었다” 같은 말이 나오는가

옛날 PR의 본질은 이거였습니다.

코드 변경 묶음
사람 리뷰 요청
승인 또는 변경 요청
작성자가 수동 수정
다시 승인

그런데 2026년 구조는 이렇게 바뀝니다.

에이전트가 브랜치에서 초안 PR 생성
리뷰 에이전트 또는 사람 리뷰어가 코멘트 추가
코멘트 이벤트를 다른 에이전트가 읽음
에이전트가 필요한 추가 문맥을 MCP 도구로 수집
체크런과 실패 로그까지 확인
수정 커밋 또는 수정 PR 생성
사람은 “변경 자체”보다 “의사결정과 책임”을 검증

즉 PR이 끝점이 아니라 비동기 작업 큐의 인터페이스가 됩니다.

이 변화가 체감되는 순간은 보통 이럴 때입니다.

리뷰어가 “여기 race condition 날 수 있음”이라고 남긴다.
예전에는 작성자가 그 말 읽고 직접 파일 다시 열고 테스트 돌리고 커밋했다.
지금은 에이전트가 그 코멘트를 읽고 관련 락 처리 코드, 테스트 파일, 최근 실패 체크런까지 같이 보고 바로 수정 초안을 올릴 수 있다.

솔직히 말하면, 여기서부터는 “코드 리뷰”라는 말보다 리뷰 이벤트 기반 수정 루프라는 표현이 더 정확합니다.

PR은 사라지지 않았습니다.

하지만 사람의 수동 반응을 기다리는 병목이라는 역할은 약해지고 있습니다.

네이티브 GitHub만으로도 이미 반쯤은 와 있다

이 지점이 은근히 많이 헷갈립니다.

GitHub 안에서도 역할이 두 개로 갈려 있습니다.

1. Copilot code review

이쪽은 리뷰어에 가깝습니다.

공식 문서 기준으로:

PR에 리뷰 댓글을 남길 수 있음
제안 변경을 붙여줄 수 있음
댓글은 사람 리뷰 댓글처럼 보임
하지만 사람이 그 댓글에 답글 달아도 Copilot code review는 그 답글을 읽지 못함
자동 재리뷰도 기본은 아님

즉 이쪽은 “리뷰하는 눈”이지, “코멘트 대화에 계속 붙어 있는 작업자”는 아닙니다.

2. Copilot coding agent

이쪽은 실행자에 가깝습니다.

GitHub 문서 기준으로:

이슈나 Copilot Chat에서 작업을 받을 수 있음
자기 개발 환경에서 테스트와 린트를 돌릴 수 있음
PR을 만들 수 있음
그리고 리뷰 코멘트에 반응해서 PR을 계속 반복 수정할 수 있음

이걸 운영 언어로 번역하면 이렇습니다.

GitHub 자체가 이미 “리뷰어 AI”와 “수정하는 AI”를 분리해서 생각하고 있다는 뜻입니다.

그래서 많은 팀이 “PR이 죽었다”는 자극적인 표현을 쓰는 겁니다.

사실 죽은 건 PR이 아니라, PR 댓글이 인간 전용 채널이라는 가정입니다.

그런데 왜 MCP가 또 필요한가

좋은 질문입니다.

“GitHub 안에서도 되는데 굳이 MCP까지 붙여야 하나?” 싶죠.

여기서 MCP가 필요한 이유는 GitHub 바깥의 문맥과 다른 에이전트 런타임을 같이 묶기 위해서입니다.

예를 들어 이런 상황이 있습니다.

리뷰 댓글 자체는 GitHub에 있음
그런데 설계 근거는 docs/decisions/ 안에 있음
관련 장애 이력은 Sentry에 있음
최근 체크 실패 원인은 GitHub Actions에 있음
구현 가이드는 사내 위키나 Obsidian에 있음
실제 수정은 Claude Code, Codex, Cursor 같은 별도 호스트에서 돌리고 싶음

이때 GitHub 웹 UI 하나만으로는 문맥이 끊깁니다.

반면 MCP는 호스트가 여러 서버를 붙여서 필요한 문맥만 가져오고, 보안 경계를 관리하는 구조를 전제로 합니다.

MCP 공식 아키텍처 문서가 강조하는 포인트도 여기와 맞닿아 있습니다.

호스트가 보안 정책과 승인 요구를 관리함
각 서버 연결은 서로 격리됨
서버는 전체 대화를 통째로 읽지 못함
필요한 문맥만 전달됨

이 구조가 중요한 이유는 단순합니다.

코드리뷰 자동화에서 제일 무서운 건 “문맥은 부족한데 권한은 큰 에이전트”거든요.

MCP는 적어도 구조상 이 위험을 줄이기 좋은 출발점입니다.

GitHub 공식 MCP Server가 실제로 열어주는 것

GitHub 공식 MCP Server README를 보면, 이건 그냥 “이슈 읽기 도구” 수준이 아닙니다.

PR 리뷰 루프에 바로 연결되는 도구들이 있습니다.

읽기 쪽

pull_request_read
pull_request_read:get_review_comments
pull_request_read:get_comments
pull_request_read:get_check_runs

즉 에이전트는 이런 질문을 바로 할 수 있습니다.

이 PR diff에 달린 리뷰 코멘트가 뭐지?
일반 코멘트는 뭐지?
지금 CI에서 어디가 터졌지?
이 코멘트가 달린 파일 주변 맥락은 뭐지?

쓰기 쪽

pull_request_review_write
add_comment_to_pending_review
add_reply_to_review_comment
resolve_thread / unresolve_thread 계열 작업

즉 에이전트가 할 수 있는 행동은 이렇게 넓어집니다.

리뷰 스레드에 답글 달기
수정 이유 설명 남기기
pending review에 코멘트 누적하기
조건 만족 시 스레드 해결 처리하기

한마디로 정리하면,

읽고 끝나는 자동화가 아니라, 읽고-판단하고-응답하는 자동화가 가능합니다.

바로 여기서 PR은 “문서”보다 “작업 인터페이스”에 가까워집니다.

진짜 차이는 PR 이후가 아니라 PR 이전 로그를 같이 먹이는 데 있다

이 글감 메모에 있던 포인트가 이거였습니다.

PR 이후가 아니라 PR 이전 의사결정 로그를 AI 리뷰 응답과 묶어라.

나는 이 포인트가 진짜 핵심이라고 봅니다.

왜냐면 리뷰 코멘트만 따로 읽는 AI는 생각보다 쉽게 멍청해지거든요.

예를 들어 리뷰어가 이렇게 남겼다고 칩시다.

“왜 여기 sync로 막았죠?”
“이거 그냥 eager load 하면 되는 거 아닌가요?”
“retry 넣으면 깔끔할 듯요”

겉으로 보면 타당해 보입니다.

그런데 PR 이전 로그에 이런 내용이 있었을 수 있습니다.

이 경로는 외부 결제 시스템 중복 호출을 막기 위해 의도적으로 sync 처리했다.
eager load는 메모리 폭증 때문에 지난 릴리스에서 이미 롤백했다.
retry는 데이터 중복 삽입 리스크 때문에 금지했다.

이걸 AI가 모르면 어떤 일이 생길까요?

리뷰 코멘트에 “예쁘게” 답하면서, 팀이 이미 버린 선택지를 다시 살려냅니다.

이거 진짜 자주 일어납니다.

그래서 리뷰 코멘트를 AI가 읽게 만들 때는, 최소한 아래 중 하나는 같이 붙여야 합니다.

PR description에 의사결정 로그 요약
linked issue에 acceptance criteria
docs/decisions/*.md 같은 ADR 문서
설계 초안 또는 SDD 링크
“왜 이 구현을 택했는가”를 적은 체크리스트

내가 추천하는 최소 규칙은 이겁니다.

PR 이전 로그 최소 세트

문제 정의 1문장
이번 변경에서 절대 깨지면 안 되는 제약 3개
버린 대안 1~2개와 이유
테스트 기준
리뷰어가 집중해서 봐야 할 위험 포인트

이 다섯 줄만 있어도 AI의 응답 품질이 확 달라집니다.

리뷰 코멘트를 받은 뒤에 에이전트가 해야 하는 첫 질문은 “어떻게 고칠까?”가 아닙니다.

“이 코멘트가 원래 결정과 충돌하는가?”가 먼저입니다.

이걸 안 하면 자동화가 아니라 자동 역주행입니다.

이벤트 설계부터 틀리면 코멘트를 못 줍는다

GitHub는 코멘트 종류를 꽤 세밀하게 나눕니다.

여기서 많이 헷갈리는 네 가지를 구분해야 합니다.

상황	이벤트	언제 쓰나
PR 일반 댓글	`issue_comment`	diff 특정 줄이 아닌 일반 대화
diff 줄 코멘트	`pull_request_review_comment`	코드 줄 단위 리뷰 코멘트
리뷰 상태	`pull_request_review`	approve / comment / request changes 같은 공식 리뷰 상태
리뷰 스레드 상태	`pull_request_review_thread`	스레드 resolve / unresolve 추적

이벤트를 잘못 물리면 이런 참사가 납니다.

리뷰어가 코드 줄에 코멘트 달았는데 에이전트가 못 봄
일반 댓글만 읽고 실제 변경 요청은 놓침
resolve 상태를 못 읽어서 이미 끝난 스레드를 또 건드림
formal review state를 모르고 “승인됨” 이후에도 이상하게 수정함

최소 권장 조합

pull_request_review_comment.created
pull_request_review.edited 또는 submitted
pull_request_review_thread.resolved / unresolved
필요하면 issue_comment.created

이 정도는 잡아야 “리뷰 이벤트 기반 루프”라는 말이 성립합니다.

머릿속 그림은 이렇다

flowchart LR
  A[리뷰어] --> B[PR diff 코멘트 작성]
  B --> C[GitHub webhook / Actions]
  C --> D[MCP 호스트]
  D --> E[GitHub MCP Server]
  E --> F[리뷰 코멘트, 일반 코멘트, 체크런 읽기]
  D --> G[에이전트 런타임]
  G --> H[PR 이전 의사결정 로그 읽기]
  H --> I[수정안 생성 또는 답글 작성]
  I --> J[새 커밋 / 새 PR / 리뷰 답글]
  J --> K[체크런 재확인]
  K --> L[사람 승인]

여기서 제일 중요한 박스는 GitHub도, 에이전트도 아닙니다.

PR 이전 의사결정 로그입니다.

이게 없으면 AI는 diff와 댓글만 보고 반응합니다.

그리고 diff와 댓글만 보고 움직이는 AI는 생각보다 자주, 아주 자신감 있게 틀립니다.

실전 체크리스트: 이 정도면 굴러간다

아래는 내가 실제 팀에 붙인다면 제일 먼저 체크할 순서입니다.

1. 코멘트 종류를 먼저 나눠라

일반 댓글은 issue_comment
코드 줄 코멘트는 pull_request_review_comment
승인/변경요청은 pull_request_review
스레드 해결 여부는 pull_request_review_thread

이걸 한 바구니로 보면 시작부터 문맥이 섞입니다.

2. PR description을 그냥 소개글로 쓰지 마라

PR description은 마케팅 문구가 아니라 에이전트 컨텍스트입니다.

최소한 아래를 넣으세요.

왜 이 변경이 필요한지
절대 깨지면 안 되는 것
이번 PR에서 일부러 안 한 것
리뷰어가 봐야 할 위험 포인트

3. MCP 도구 allow-list를 좁혀라

GitHub Copilot coding agent용 MCP 설정 문서도 읽기 전용 도구 allow-list를 강하게 권합니다.

이건 괜히 쓰는 문장이 아닙니다.

처음부터 모든 도구를 열면, 편하긴 한데 사고도 같이 커집니다.

초기 세트는 이 정도면 충분합니다.

PR 읽기
리뷰 코멘트 읽기
체크런 읽기
제한된 답글 쓰기

처음부터 merge, branch update, broad write 권한을 다 주는 건 좀 무섭습니다.

아니, 꽤 무섭습니다.

4. “자동 수정”과 “자동 답글”을 분리하라

모든 리뷰 코멘트에 대해 에이전트가 바로 코드를 바꾸게 하지 마세요.

먼저는 이 두 단계로 나누는 편이 낫습니다.

1단계: 코멘트 요약 + 관련 파일 + 의사결정 로그 비교 + 제안 답글 생성
2단계: 사람이 승인한 경우에만 실제 수정 브랜치 생성

이렇게 가면 AI가 실수해도 피해가 작습니다.

5. 체크런을 코멘트보다 뒤가 아니라 같이 보게 하라

리뷰어가 “여기 테스트 추가해 주세요”라고 남겼는데, 이미 관련 테스트가 다른 체크런에서 깨지고 있었다면?

그 코멘트만 보면 반쪽짜리 대응이 됩니다.

그래서 PR 리뷰 루프에서는 댓글과 체크런을 묶어서 읽게 해야 합니다.

6. resolve 조건을 문장으로 박아라

테스트 통과
reviewer concern addressed 요약 남김
관련 스크린샷 또는 로그 첨부
위험한 변경이면 사람 재승인 필요

이런 조건이 없으면 스레드를 너무 빨리 닫거나, 반대로 영원히 못 닫습니다.

7. “누가 최종 책임자인가”를 절대 흐리지 마라

AI가 코멘트 읽고 고쳐도, 책임은 여전히 사람 팀에 있습니다.

이건 GitHub 문서도 반복해서 말하는 부분입니다.

에이전트는 도구이지 대체물이 아닙니다.

듣기엔 뻔하지만, 운영에서는 이 뻔한 문장을 제일 자주 까먹습니다.

네이티브 GitHub 흐름과 MCP 확장 흐름은 어떻게 다른가

A. GitHub 안에서 끝내는 흐름

이 흐름은 Copilot 중심입니다.

Copilot code review가 코멘트 생성
사람이 확인
필요하면 Copilot coding agent로 구현 제안 실행
PR 반복 수정

장점은 단순합니다.

설정이 덜 복잡함
GitHub 안에서 흔적이 비교적 깔끔함
팀이 이미 Copilot을 쓰면 진입 장벽이 낮음

단점도 뚜렷합니다.

댓글 수준 맥락이 GitHub 외부 자료와 자연스럽게 이어지지 않음
PR 이전 의사결정 로그를 잘 안 챙기면 금방 diff 중심 사고로 흐름
사내 도구, 위키, 관측 시스템과 연결할 때 한계가 있음

B. MCP 확장 흐름

이 흐름은 GitHub을 한 서버로 보고, 다른 문맥 서버를 같이 붙이는 쪽입니다.

GitHub MCP Server로 PR/리뷰/체크런 문맥 수집
필요한 경우 사내 문서 서버, 관측 서버, 스펙 서버 추가
Claude Code, Codex, Cursor, 자체 에이전트 호스트에서 조합
제한된 쓰기 권한으로 답글 또는 수정안 생성

장점은 큽니다.

문맥 확장이 쉬움
도구 역할 분리가 좋음
PR 이전 로그와 PR 이후 코멘트를 같은 루프에 넣기 쉬움

단점도 분명합니다.

권한 설계가 어려움
이벤트 설계를 잘못하면 오히려 복잡도 폭증
호스트가 멍청하면 여러 서버를 붙여도 멍청함

도구가 많아진다고 자동으로 똑똑해지지 않습니다.

그냥 더 시끄러운 멍청이가 될 수도 있습니다.

이거 은근 중요한 기술 사실입니다.

가장 현실적인 시작점: “자동 코드 수정” 말고 “자동 리뷰 응답 초안”부터

많은 팀이 처음부터 이렇게 꿈꿉니다.

리뷰 코멘트 달리면 AI가 바로 고친다
테스트 돌린다
커밋한다
스레드 닫는다
나이스

네, 이상은 아름답죠.

근데 현실은 권한과 문맥 때문에 한 번씩 삐끗합니다.

그래서 내가 추천하는 1단계는 이겁니다.

1단계 워크플로

리뷰 코멘트 생성 이벤트 수신
GitHub MCP Server로 관련 리뷰 코멘트/체크런/파일 맥락 읽기
PR description 또는 decision log도 읽기
에이전트가 아래 형식으로 초안 생성

- 리뷰어 코멘트 요약
- 현재 구현 의도와 충돌 여부
- 수정 필요 여부: yes / no / partial
- 수정 시 영향 파일
- 테스트 영향
- 추천 답글 초안

이 정도만 자동화해도 사람 리뷰 속도가 꽤 빨라집니다.

왜냐면 사람은 이제 “뭘 해야 하지?”가 아니라 “이 초안이 맞나?”만 판단하면 되거든요.

이 다음 단계에서:

안전한 범위만 자동 수정
고위험 변경은 draft patch만 생성
사람 승인 후만 push

이렇게 올라가면 됩니다.

처음부터 풀오토로 가다가 리뷰 문화가 깨지는 팀, 꽤 많이 봅니다.

AI가 실수해서가 아니라, 팀이 통제 레버를 안 만들고 달려서요.

실패하는 패턴 6가지

1. 댓글만 읽고 스레드는 안 읽는 경우

스레드 초반 코멘트만 보고 수정하면, 이미 아래에서 결론 난 대화를 다시 뒤집을 수 있습니다.

2. diff만 읽고 결정 로그를 안 읽는 경우

겉보기에 깔끔한 리팩터링을 하다가, 팀이 일부러 남겨 둔 예외 처리를 지워버립니다.

3. review bot과 coding agent를 같은 존재로 착각하는 경우

GitHub 네이티브 흐름에서도 둘은 완전히 같지 않습니다.

리뷰를 잘하는 모델과, 수정 루프를 잘 도는 모델은 운영 방식이 다릅니다.

4. resolve를 너무 쉽게 자동화하는 경우

“수정 커밋 푸시됐으니 resolve”는 위험합니다.

리뷰어가 원한 게 단순 코드 수정이 아니라 설명일 수도 있거든요.

5. MCP 도구를 너무 넓게 여는 경우

처음부터 모든 write 권한을 주면, 나중에 누가 무슨 이유로 뭘 바꿨는지 추적이 어려워집니다.

6. 사람이 안 읽고 머지하는 경우

이건 말 그대로 사고 예약입니다.

GitHub 문서가 계속 “도구로 써라, 대체물로 보지 마라”라고 반복하는 데는 이유가 있습니다.

그럼 PR은 앞으로 뭐가 되나

내 해석은 이렇습니다.

PR은 앞으로 세 가지 역할만 더 선명해질 겁니다.

1. 승인 인터페이스

사람 책임이 남는 자리입니다.

2. 이벤트 허브

코멘트, 리뷰 상태, 스레드 상태, 체크런, 새 커밋이 여기서 만납니다.

3. 감사 로그

누가 어떤 맥락에서 어떤 수정 제안을 했는지 나중에 다시 볼 수 있는 자리입니다.

반대로 약해지는 역할도 있습니다.

약해지는 역할: 사람이 직접 모든 코멘트를 소화하는 유일한 작업창

이제는 아닙니다.

코멘트는 사람도 읽고, 에이전트도 읽습니다.

에이전트는 체크런도 보고, 관련 파일도 더 보고, 의사결정 로그도 읽을 수 있습니다.

그래서 PR은 “사람이 일하는 곳”이라기보다 사람과 에이전트가 각자 읽고 반응하는 공용 이벤트 표면으로 바뀝니다.

이게 내가 말하는 “PR은 죽었다”의 진짜 뜻입니다.

조금 더 정확히 말하면,

PR의 사회적 역할이 죽고, 프로토콜 역할이 강해진다는 쪽입니다.

지금 바로 붙여볼 최소 운영안

작게 시작하고 싶다면 아래 순서가 제일 덜 아픕니다.

PR template에 의사결정 로그 5줄 추가
pull_request_review_comment.created 이벤트부터 수신
GitHub MCP Server에서 pull_request_read와 체크런 읽기만 먼저 허용
에이전트는 답글 초안만 생성
사람 승인 후에만 실제 답글 게시
한두 주 운영 후, 안전한 범위의 자동 수정만 일부 허용
resolve/unresolve 자동화는 맨 마지막에 붙이기

이렇게 가면 과한 자신감으로 큰 사고 낼 확률이 줄어듭니다.

처음부터 끝까지 자동화하는 건 멋있어 보입니다.

근데 운영은 멋보다 회수 가능성이 더 중요합니다.

망했을 때 빨리 되돌릴 수 있느냐.

그게 진짜 실력입니다.

FAQ

Q1. PR이 진짜 없어지나요?

아닙니다.

2026년 3월 22일 기준으로 GitHub의 PR, 리뷰, 체크런, 승인 흐름은 여전히 핵심입니다.

다만 PR이 인간 전용 최종 대화방이라는 가정은 빠르게 약해지고 있습니다.

Q2. Copilot code review 댓글에 내가 답글 달면 Copilot이 읽나요?

GitHub 공식 문서 기준으로, 아닙니다.

그 답글은 인간에게는 보이지만 Copilot code review에는 보이지 않고, Copilot이 그 답글에 직접 응답하지도 않습니다.

Q3. 그런데 Copilot coding agent는 리뷰 코멘트에 반응하나요?

GitHub 공식 문서 기준으로, 그렇습니다.

Copilot coding agent는 이슈나 코멘트에서 작업을 받고, PR 위에서 피드백에 맞춰 반복 수정할 수 있다고 설명됩니다.

Q4. 그러면 MCP는 꼭 필요한가요?

GitHub 안에서만 끝낼 거면 꼭은 아닙니다.

하지만 사내 문서, 장애 이력, 별도 에이전트 런타임, PR 이전 의사결정 로그까지 같이 붙이려면 MCP가 훨씬 자연스럽습니다.

Q5. 제일 먼저 자동화할 건 뭔가요?

자동 수정이 아니라 자동 리뷰 응답 초안부터요.

이게 리스크 대비 효율이 제일 좋습니다.

Q6. 제일 위험한 건 뭔가요?

문맥은 빈약한데 권한은 큰 에이전트입니다.

특히 diff만 보고 write 권한을 가진 자동 수정 루프는, 보기엔 똑똑한데 이상하게 팀 결정을 자꾸 되돌리는 방향으로 사고를 냅니다.

같이 보면 흐름이 이어지는 글

출처

GitHub Changelog, 2026-03-05, “Copilot code review now runs on an agentic architecture”
GitHub Docs, “Using GitHub Copilot code review”
GitHub Docs, “Responsible use of Copilot coding agent”
GitHub Docs, “Extending GitHub Copilot coding agent with the Model Context Protocol (MCP)”
GitHub 공식 저장소, github/github-mcp-server README
GitHub Docs, “Webhook events and payloads”
Model Context Protocol 공식 스펙, “Architecture”

마무리

2026년의 코드리뷰에서 중요한 질문은 “AI가 리뷰를 해주나?”가 아닙니다.

그건 이미 어느 정도 됩니다.

진짜 질문은 이겁니다.

리뷰 코멘트가 생겼을 때, 어떤 AI가 어떤 문맥을 읽고 어떤 권한으로 어디까지 반응하게 만들 것인가?

이걸 설계하지 않으면 PR 자동화는 그냥 화려한 알림 시스템이 됩니다.

반대로 이걸 잘 설계하면, PR은 병목이 아니라 아주 괜찮은 이벤트 허브가 됩니다.

그러니까 PR이 죽은 게 아니라,

PR을 바라보는 우리의 옛 습관이 죽어가고 있는 것에 더 가깝습니다.