Copilot 코드 리뷰 개요 코멘트가 9월 18일 바뀌었습니다.

풀 리퀘스트 맨 위에 붙는 개요 코멘트 한 덩어리에 이번 리뷰의 판단과 발견 목록이 모이고, 발견 항목은 Open, Resolved since last review, Previously missed 세 묶음으로 갈립니다. 항목마다 심각도와 인라인 코멘트로 가는 링크가 함께 붙어서, 목록에서 코드 위치로 바로 넘어가는 형태가 됐어요. 같은 날 자동 resolve 에 사유 표기가 생겼고, 제안을 묶어서 커밋할 때 커밋 제목이 자동으로 채워지는 기능도 함께 정식 출시됐습니다.

커밋을 더 밀고 리뷰를 다시 요청해도 앞선 리뷰의 진행 상황이 개요에 그대로 남습니다.

아래 내용은 2026년 9월 21일 기준이고, 화면 문구와 설정 경로는 GitHub 공식 체인지로그와 문서에 적힌 값입니다. 콘솔 UI 는 자주 바뀌니 경로가 어긋나면 문서 쪽을 기준으로 잡으시면 됩니다.

Copilot 코드 리뷰 개요 코멘트에서 바뀐 것

Copilot code review: An improved review experience 공지는 2026년 9월 18일에 올라왔고, 세 가지가 한꺼번에 정식 출시(GA)됐다고 적혀 있습니다. 개편된 개요 코멘트, 더 똑똑해진 자동 resolve, 배치 제안 수락 시 커밋 메시지 생성입니다.

「Copilot code review: An improved review experience (GitHub Changelog)」 문서 화면

출처: 「Copilot code review: An improved review experience (GitHub Changelog)」, github.blog. 2026-09-21 캡처.

개편된 개요 코멘트에 담기는 것은 세 가지예요. 이번 풀 리퀘스트에 대한 Copilot 의 현재 평가, 이번 리뷰에 쓰인 review effort level, 그리고 리뷰에서 나온 발견 목록입니다.

여기서 말하는 평가는 승인 판정(approval assessment)을 뜻합니다. About GitHub Copilot code review 문서는 모든 리뷰의 개요 코멘트에 이 판정이 들어가되, 기본값에서는 그 판정이 머지 요구 조건을 채우지 않는다고 적어 뒀습니다. 승인이 실제 머지 게이트를 통과하게 하려면 레포·조직·엔터프라이즈 설정에서 승인 기능을 따로 켜야 하고, 켠 뒤 새 커밋이 올라오면 승인은 자동으로 해제됩니다. 이 승인 기능은 아직 공개 미리보기 단계라고 문서가 못 박아 두었습니다.

레포 쪽에서 만지는 칸 이름은 Configuring code review by GitHub Copilot 문서에 나옵니다. Settings → Copilot → Code review 화면의 “Auto-approval” 아래에 Allow Copilot to approve pull requests 와 Allow Copilot approvals to count toward merge requirements 두 개가 따로 놓여 있어요. 승인을 남기게 하는 것과 그 승인이 머지 요건을 채우게 하는 것이 각각 다른 스위치라는 뜻입니다.

「About GitHub Copilot code review (GitHub Docs)」 문서 화면

출처: 「About GitHub Copilot code review (GitHub Docs)」, docs.github.com. 2026-09-21 캡처.

기존에 있던 풀 리퀘스트 요약과 파일별 요약은 없어지지 않고 그대로 남습니다.

Open·Resolved since last review·Previously missed 는 어떻게 나뉘나요?

세 묶음의 기준은 “언제 생긴 문제인가”와 “지금 고쳐졌나” 두 축입니다.

Open 은 아직 손대지 않은 항목이 들어가는 자리입니다. 이 중에서 새로 올린 커밋 때문에 생긴 항목에는 new 라벨이 따로 붙어서, 원래 있던 지적과 방금 만든 지적이 눈으로 구분됩니다.

Resolved since last review 는 앞선 리뷰에서 나왔던 지적이 이제는 고쳐졌다고 Copilot 이 확인한 항목입니다. 체인지로그는 이 자동 판단의 근거를 리뷰와 리뷰 사이에 그 지적이 처리됐는지 여부로 적어 두었어요.

Previously missed 가 셋 중에 가장 낯선 묶음이에요. 새 커밋이 만들어 낸 문제가 아니라, 이미 올라와 있던 변경분에서 뒤늦게 찾아낸 항목이 여기로 들어갑니다. 이 묶음의 지적은 풀 리퀘스트의 다른 어디에도 코멘트로 달리지 않기 때문에, 개요 코멘트 안에 그 내용이 통째로 들어갑니다. 링크를 따라갈 인라인 코멘트가 아예 없는 항목인 셈이죠.

각 항목에는 심각도가 함께 표기됩니다. Using GitHub Copilot code review 문서를 보면 Copilot 은 코멘트마다 High, Medium, Low 중 하나를 붙여 어느 것이 급한지 가늠하게 하고, GitHub.com 에서 리뷰를 요청했을 때 결과가 나오기까지는 보통 30초가 채 걸리지 않는다고 적혀 있습니다.

「Using GitHub Copilot code review (GitHub Docs)」 문서 화면

출처: 「Using GitHub Copilot code review (GitHub Docs)」, docs.github.com. 2026-09-21 캡처.

항목 제목도 이번에 새로 생겼습니다. 리뷰 코멘트 하나하나에 무엇을 찾았는지 요약한 한 줄 제목이 붙고, 그 제목이 개요 코멘트의 목록에 그대로 쓰입니다. 코멘트를 하나씩 펼쳐 보지 않고도 어느 것부터 볼지 고르라는 설계예요.

Previously missed 라는 칸이 존재한다는 사실 자체는 곱씹어 볼 만합니다. 같은 변경분을 두 번 읽었을 때 두 번째에 새로 나오는 지적이 있다는 뜻이니까요. 같은 취지의 경고는 GitHub 도 문서에 써 두었는데, 방금 인용한 Using GitHub Copilot code review 가 아니라 About GitHub Copilot code review 쪽의 「Validating Copilot code reviews」 절입니다. 풀 리퀘스트 안의 문제를 Copilot 이 전부 짚어 낸다는 보장이 없고 틀릴 때도 있으니, 받은 피드백은 늘 꼼꼼히 따져 보고 사람 리뷰를 덧붙이라는 내용이에요. 개요 코멘트가 깔끔해진 것과 리뷰가 빠짐없어진 것은 다른 이야기입니다.

자동 resolve 의 Won’t Fix·Incorrect 판정 기준

Copilot 이 자기가 단 코멘트를 스스로 닫는 기능은 전부터 있었고, 이번에 두 군데가 손질됐습니다.

첫째, Copilot 코드 리뷰 코멘트에 “이건 열어 두자”는 취지의 답글이 달리면 그 답글을 존중해 스레드를 닫지 않습니다. 둘째, 이후 커밋을 근거로 Won't Fix 또는 Incorrect 라는 해결 사유를 붙여서 닫습니다. 고쳐서 닫힌 것인지, 안 고치기로 한 것인지, 애초에 지적이 틀렸던 것인지가 스레드에 남는 구조입니다.

여기서 공식 문서 두 곳의 서술이 서로 다른 방향을 가리킵니다. 체인지로그는 답글이 달리면 그것을 존중한다고 적었지만, Using GitHub Copilot code review 문서의 리뷰 코멘트 설명에는 사람이 Copilot 코멘트에 다는 답글이 다른 사람에게만 보이고 Copilot 에게는 보이지 않으며 Copilot 이 답하지도 않는다고 적혀 있습니다. 답글로 스레드를 열어 둘 의도라면 문서 쪽 서술도 같이 염두에 두시는 편이 안전합니다.

닫아 둔 지적이 다시 올라올 여지도 문서에 명시돼 있어요. 재리뷰 때 Copilot 이 같은 코멘트를 반복할 수 있고, 그것이 Resolve conversation 버튼으로 닫았거나 👎 를 눌러 둔 코멘트여도 마찬가지라고 적혀 있습니다.

리뷰를 두 번 돌리는 팀이라면 이 문장이 이번 개편의 체감을 좌우합니다.

Add suggestion to batch 와 커밋 메시지 자동 생성

세 번째 변경은 제안을 묶어서 커밋할 때 붙습니다. 수락 가능한 제안을 완전한 배치로 커밋하면 Copilot 이 선택된 변경 내용을 보고 커밋 제목을 만들고, 설명은 선택 항목으로 함께 만들어 줍니다. 배치에 Copilot 이 낸 것이 아닌 코멘트가 섞여 들어가도 커밋 메시지는 똑같이 만들어집니다.

클릭 경로는 Incorporating feedback in your pull request 문서에 그대로 나와 있습니다. 제안 하나만 단독 커밋으로 넣을 때는 Commit suggestion, 여러 개를 모을 때는 각 제안에서 Add suggestion to batch 를 누른 뒤 마지막에 Commit suggestions 를 누르면 됩니다. 커밋 메시지 칸을 채우고 Commit changes 를 누르면 커밋 하나가 만들어집니다.

제안 하나를 넣든 배치를 넣든 커밋은 풀 리퀘스트의 compare 브랜치에 한 개로 들어갑니다. 저작 표기도 정해져 있어서, 제안을 낸 사람은 co-author 로, 적용한 사람은 committer 이자 co-author 로 커밋에 남습니다.

제안을 직접 커밋하지 않고 넘기는 경로도 따로 있습니다. 리뷰 코멘트에서 Fix with Copilot 을 누르면 초안 코멘트가 만들어지고, 거기에 지시를 적은 다음 같은 풀 리퀘스트에 커밋으로 넣을지 브랜치에 새 풀 리퀘스트를 만들지 고르는 방식입니다. 이 경로는 Copilot cloud agent 를 함께 켜야 하고, 문서에 공개 미리보기로 표기돼 있습니다.

Review new pushes 설정 경로와 재검토 요청 방법

개요 코멘트가 리뷰 회차를 누적해 보여 주려면 리뷰가 두 번 이상 돌아야 하는데, 기본값은 그렇지 않습니다.

기본 상태에서 Copilot 리뷰는 사람 리뷰어와 똑같이 손으로 요청합니다. 풀 리퀘스트 오른쪽 사이드바의 Reviewers 에서 Copilot 옆의 Request 를 누르는 경로입니다. 푸시마다 리뷰하도록 따로 설정해 두지 않았다면 풀 리퀘스트당 리뷰는 한 번뿐이라, 재검토는 Reviewers 메뉴의 Copilot 이름 옆 버튼을 다시 눌러 손으로 요청해야 합니다.

자동 리뷰는 룰셋으로 켭니다. Configuring code review by GitHub Copilot 문서의 레포 설정 경로는 Settings → 왼쪽 사이드바 Code and automation → Rulesets → New ruleset → New branch ruleset 순서입니다. 이름을 적고 Enforcement Status 를 Active 로 둔 다음, Target branches 에서 대상을 고르고 Branch rules 에서 Automatically request Copilot code review 를 선택하면 됩니다.

같은 화면에 붙어 있는 선택지 두 개가 실제 운영을 가릅니다. Review new pushes 를 켜면 풀 리퀘스트에 커밋이 올라올 때마다 다시 리뷰하고, 켜지 않으면 풀 리퀘스트당 한 번만 리뷰합니다. Review draft pull requests 를 켜면 드래프트 상태에서도 리뷰가 돌아서 사람 리뷰어를 부르기 전에 지적을 받아 볼 여지가 생깁니다.

켜지 않았을 때의 기본 트리거는 두 가지뿐입니다. 풀 리퀘스트를 Open 상태로 만들 때, 그리고 드래프트를 Open 으로 처음 바꿀 때입니다.

자기 풀 리퀘스트에만 적용하는 경로는 따로 있어요. 오른쪽 위 프로필 사진 → Copilot settings 로 들어가 Automatic Copilot code review 를 Enabled 로 바꾸는 방식이고, Copilot Pro·Pro+·Max 플랜에서만 쓸 수 있습니다. 조직 단위로 걸 때는 조직 Settings → Repository → Rulesets 에서 같은 룰셋을 만들고 대상 레포를 패턴으로 지정합니다.

REST API 로 copilot-pull-request-reviewer[bot] 을 리뷰어로 요청하는 방법도 문서에 적혀 있습니다.

Lite 와 Balanced, AI 크레딧 차이는 얼마인가요?

개요 코멘트에 이번 회차의 effort level 이 표기되기 시작했으니, 그 값이 무엇을 뜻하는지도 같이 봐야 합니다.

Lite 는 기본값이고 버그·보안 취약점·스타일 불일치처럼 눈에 띄는 문제를 빠르게 짚는 쪽입니다. Balanced 는 더 높은 추론 모델로 보내서 복잡한 로직, 보안에 민감한 코드, 서비스 여러 곳에 걸친 변경을 길게 분석합니다. 문서는 Balanced 가 Lite 보다 AI 크레딧을 더 쓰고 GitHub Actions 분도 조금 더 쓸 수 있다는 단서를 여기에 붙여 두었어요.

금액 차이가 작지 않습니다. About GitHub Copilot code review 문서의 추정치로 리뷰 한 건은 Lite 에서 0.05달러에서 1달러어치, Balanced 에서 0.25달러에서 5달러어치 AI 크레딧을 씁니다. 풀 리퀘스트가 크거나 레포 커스텀 인스트럭션이 길면 소비가 늘고, 이 추정치에 GitHub Actions 분은 포함돼 있지 않습니다. 모델이 달라지면 범위 자체도 바뀔 수 있다는 말까지 함께 붙어 있습니다.

한 등급 안에서도 위아래 끝값이 크게 벌어져 있어서 예산을 미리 잡기가 까다롭습니다. Balanced 기본값 + 자동 리뷰 + Review new pushes 조합은 켜기 전에 한 번 계산해 보시는 편이 낫습니다.

기본 effort level 은 레포 Settings → Code, planning, and automation → Copilot → Code review 로 들어가 Review effort level 에서 고릅니다. 조직 owner 가 정하는 기본값은 자동 코드 리뷰에 적용되는 값이고, 특정 레포에 한해 레포 관리자가 그것을 덮어쓸 수 있습니다. 손으로 요청할 때는 풀 리퀘스트의 Reviewers 영역에서 그때그때 고르는 것도 됩니다.

크레딧이 누구 앞으로 달리는지도 정해져 있습니다. 새 풀 리퀘스트마다 Copilot 리뷰를 자동으로 부르도록 맞춰 둔 레포라면 소비가 풀 리퀘스트 작성자에게 붙고, 다른 사람이 손으로 요청한 리뷰라면 요청한 그 사람에게 붙습니다. Copilot cloud agent 가 만든 풀 리퀘스트는 변경에 얽힌 사람 co-author 에게 먼저 달리고, 청구가 안 되면 조직으로 넘어갑니다. 그 밖의 봇이 만들었거나 봇이 리뷰를 요청한 경우는 조직에 바로 청구됩니다.

리뷰 대상에서 빠지는 파일도 알아 두면 좋습니다. 의존성 관리 파일(package.json·Gemfile.lock 같은 것), 로그 파일, SVG 파일은 풀 리퀘스트에 들어 있어도 리뷰하지 않습니다. 락파일 diff 를 봐 주길 기대하면 어긋납니다.

에이전틱 기능은 GitHub Actions 러너 위에서 돕니다. 조직이 GitHub 호스티드 러너를 꺼 두었으면 에이전틱 기능이 빠진 채 축소된 리뷰로 떨어지는데, 그런 조직은 셀프 호스티드 러너를 쓰면 된다고 문서가 안내합니다. 기본은 표준 호스티드 러너이고, 더 큰 호스티드 러너로 올리면 분당 단가가 높게 청구된다는 점도 적혀 있어요.

GitLab Duo 코드 리뷰와 다른 점

같은 문제를 GitLab 은 다른 방향으로 풀었습니다. GitLab Duo in merge requests 문서를 보면 머지 리퀘스트에서 @GitLabDuo 를 멘션해 리뷰를 부르고, 리뷰를 시작한 사람이 GitLab Duo Enterprise 시트를 가졌는지에 따라 두 기능 중 하나가 자동으로 실행됩니다. 그룹에서 Owner 역할을 가진 사람이 모든 사용자에게 어느 쪽을 돌릴지 지정하는 길도 열려 있어요.

둘의 성격이 꽤 다릅니다. Code Review Flow 는 에이전틱 방식으로 레포 구조와 파일 사이 의존 관계까지 보며 add-on 없이 GitLab Credits 를 쓰고, GitLab Duo Code Review 는 머지 리퀘스트와 그 안의 diff 에 집중하는 단일 패스 방식으로 GitLab Duo Enterprise add-on 이 필요합니다. 어느 쪽이 돌았는지는 활동 피드에 리뷰 세션이 생겼는지로 갈라 보면 됩니다.

resolve 를 다루는 방향은 정반대예요. GitHub 은 Copilot 이 자기 지적을 스스로 닫고 사유를 붙이는 쪽이고, GitLab 은 사람이 아직 닫히지 않은 스레드에서 Resolve thread 옆 More resolve options 를 펼쳐 Resolve with GitLab Duo 를 고르는 쪽입니다. 그러면 Duo 가 그 리뷰 코멘트와 주변 코드를 읽고 소스 브랜치에 수정을 커밋·푸시한 다음, 무엇을 바꿨는지 요약한 답글을 달면서 스레드를 닫습니다. 이 기능은 GitLab 19.2 에서 베타로 들어왔고 19.3 에서 정식 기능이 됐습니다.

붙는 조건은 오히려 GitHub 쪽보다 많습니다. Tier 는 Premium·Ultimate 이고, 프로젝트에서 Developer·Maintainer·Owner 중 하나의 역할, GitLab Duo Agent Platform 의 전제조건, 최상위 그룹에서 켜 둔 Allow foundational flows 와 Developer, 서비스 계정 푸시를 허용하도록 맞춘 푸시 룰, 그리고 직접 붙인 러너나 프로젝트에 켜 둔 GitLab 호스티드 러너가 모두 필요합니다. 한 번 눌러 보고 되는지 확인하는 종류의 기능이 아닙니다.

커밋 메시지 생성이 붙는 자리도 다릅니다. GitLab 쪽은 머지 위젯에서 Edit commit message 를 체크하고 Generate commit message 를 누른 뒤, 나온 문구를 읽어 보고 Insert 로 커밋에 넣는 흐름입니다. 이번 GitHub 변경은 머지 커밋이 아니라 리뷰 제안을 배치로 커밋할 때의 커밋 제목이라 자리가 다르죠.

닫는 주체가 사람이냐 봇이냐가 두 제품의 갈림길입니다. 리뷰 기록을 감사 자료로 쓰는 팀이라면 GitHub 쪽 자동 resolve 는 사유 표기가 생긴 지금도 한 번 더 들여다볼 대목이에요. 스레드를 닫은 주체와 근거가 모두 봇 판단이라서 그렇습니다.

머지 판단을 개요 코멘트 하나로 끝낼 생각이라면 Previously missed 묶음부터 열어 보시는 편이 낫습니다. 첫 회차가 놓쳤던 자리가 거기 모입니다.

참고 자료