AI 코드 리뷰, 처음 한 번보다 수정한 뒤 다시 읽게 하는 설정이 중요합니다

핵심 요약 (TL;DR)

AI에게 코드를 고치게 한 뒤 리뷰를 한 번 받았다고 작업이 끝나는 것은 아닙니다. 리뷰에 따라 다시 바꾼 코드가 처음 검토한 코드와 달라지기 때문입니다. GitHub가 9월 23일 일반 제공을 알린 Copilot 코드 리뷰 설정은 이 간격을 다룹니다. 개인 설정에서 자동 리뷰, draft 상태의 풀 리퀘스트, 새 push에 대한 리뷰를 나누고 기본 검토 강도도 정할 수 있게 했습니다.

이번에는 무엇이 달라졌나요?

공식 발표에 따르면 이전 개인 설정은 Pro·Pro+·Max 요금제의 Copilot features 페이지에 있었으며, draft와 새 push를 구분하지 않는 하나의 자동 리뷰 설정을 제공했습니다. 이제 프로필의 Copilot settings 안에 전용 code review 페이지가 생기고 Business와 Enterprise를 포함한 모든 Copilot 요금제로 제공 범위가 넓어졌습니다.

자동 리뷰를 켜면 본인이 만들거나 공동 작성한 풀 리퀘스트, 그리고 draft에서 벗어나는 풀 리퀘스트가 대상이 됩니다. 자신이 만들거나 공동 작성한 draft와 새 push에 대한 자동 리뷰도 별도로 켤 수 있습니다. 기본 리뷰 강도는 현재 Lite와 Balanced로 표시됩니다.

왜 draft와 새 push를 나누어 생각해야 할까요?

풀 리퀘스트는 변경안을 검토하기 위해 올리는 묶음이고, draft는 아직 준비 중이라는 표시입니다. 화면 문구를 자주 바꾸는 초기 작업과, 공개 직전의 로그인 수정은 검토를 받고 싶은 순간이 다릅니다. 모든 중간 변경을 같은 무게로 읽게 하면 중요한 지적이 반복 알림 사이에 묻힐 수도 있습니다.

예를 들어 아직 구성 중인 화면은 사람 검토가 가능한 단계에서 리뷰를 시작하고, 승인 직전의 변경안은 추가 push 후에도 다시 확인하도록 운영할 수 있습니다. 팀에서는 ‘언제 검토를 시작하는가’와 ‘무엇이 바뀌면 다시 검토하는가’를 짧게 합의하는 편이 좋습니다.

검토 강도는 어디까지 기본값일까요?

개인 기본값은 직접 요청하는 리뷰와 자동으로 요청되는 본인의 리뷰에 적용됩니다. 풀 리퀘스트 페이지의 Reviewers에서 수동 요청할 때는 다른 강도를 선택할 수 있습니다. 이번 발표만으로 Lite와 Balanced의 정확도, 속도, 비용 차이를 수치로 비교할 수는 없습니다.

기업 관리자는 조직 소유 저장소에 상속될 기본 리뷰 강도를 정할 수 있고, 조직과 저장소는 별도 설정으로 이를 덮어쓸 수 있습니다. 따라서 조직의 기본값을 들었다고 현재 저장소도 같을 것이라 가정하기보다, 실제 적용 설정을 확인하는 것이 정확합니다.

바이브코더는 리뷰 다음에 무엇을 남겨야 할까요?

AI의 지적을 받으면 고친 파일과 다시 실행한 테스트를 함께 적어 두세요. 로그인이라면 정상 입력만 아니라 잘못된 비밀번호, 권한 없는 접근 같은 실제 흐름을 확인하는 식입니다. 리뷰가 남긴 설명과 앱을 실행해 확인한 결과는 서로 다른 증거입니다.

코드를 생성한 속도보다 중요한 것은 마지막 변경 이후 무엇을 다시 확인했는가입니다. 자동 리뷰의 재시점을 정하는 일은 사람 검토를 없애는 방법이 아니라, 사람이 오래된 결과를 보고 승인하지 않도록 돕는 작은 장치입니다.

FAQ: 자동 리뷰를 켜면 자동으로 병합되나요?

이번 발표는 리뷰 요청과 설정에 관한 내용입니다. 리뷰를 받는 것과 변경을 병합하는 것은 별개이며, 팀의 승인 규칙은 따로 유지해야 합니다.

FAQ: AI가 지적하지 않으면 안전한 코드인가요?

아닙니다. 리뷰는 참고할 검토 결과입니다. 결제·권한·개인정보처럼 실패 비용이 큰 기능은 실제 동작 시험과 사람의 확인을 함께 거치세요.

출처: https://github.blog/changelog/2026-09-23-copilot-code-review-more-ways-to-request-and-configure-reviews
관찰 시점: 2026-09-24 KST