GitHub Copilot 코드 리뷰, 리뷰어를 대체하진 못해도 초벌 필터로는 꽤 괜찮다

사람 리뷰어를 없애는 도구라기보다, 첫 번째 망처럼 쓰는 게 맞다

AI 코드 리뷰가 뜨면 늘 같은 기대와 실망이 같이 온다. “이제 리뷰어 없어도 되나?” 싶다가도, 막상 받아보면 너무 뻔한 코멘트만 달거나 중요한 맥락은 놓치기 쉽다. 그런데 GitHub Copilot 코드 리뷰 문서를 자세히 보면, 애초에 포지션이 그 정도는 아니다. 승인도 아니고 변경 요청도 아닌 comment 리뷰로 남고, 필수 승인 수를 대체하지도 않는다. 이 점이 오히려 마음에 들었다.

즉, 이건 사람 리뷰어를 지우는 제품이 아니라 초벌 필터에 더 가깝다. 사소한 실수, 위험한 패턴, 애매한 예외 처리, 이런 걸 PR 초반에 빨리 걸러주는 용도로 보면 기대치가 맞는다. 내가 보기엔 이 기대치 조절이 핵심이다. 사람 대신 최종 판단을 맡기면 실망하고, 리뷰 전에 한 번 더 거르는 자동화로 보면 꽤 쓸 만하다.

좋았던 부분은 속도보다 범위였다

GitHub 문서에 따르면 보통 30초 안쪽으로 리뷰가 붙고, 제안 변경도 바로 적용 가능한 경우가 있다. 이건 분명 편하다. 그런데 실제로 더 중요한 건 어디를 리뷰하고, 어디를 안 보는지다. 의존성 관리 파일이나 로그, SVG 같은 일부 파일은 제외된다. 이런 정보가 문서에 명시돼 있어서 기대를 조절하기 좋다.

또 하나 흥미로운 건 agentic 기능이다. 전체 프로젝트 문맥을 더 수집하고, 특정 코멘트를 구현 제안으로 이어가게 하는 흐름이 보인다. 여기서 가능성이 생긴다. 단순히 “문제가 있다”고 말하는 걸 넘어서, 수정 PR로 이어지면 팀 리듬이 바뀔 수 있다. 다만 이 지점은 아직 과신하면 안 된다. 복잡한 도메인 규칙까지 AI가 다 읽는 건 아니니까.

실무에서 잘 쓰려면 PR을 더 잘 쪼개야 한다

써보면 금방 느끼는 게 있다. 큰 PR에서는 AI 리뷰도 금방 흐릿해진다. 변경 범위가 넓고 맥락이 엉키면, 의미 있는 피드백보다 애매한 코멘트 비율이 늘어난다. 반대로 PR을 작게 쪼개고 제목, 설명, 의도, 체크포인트를 정리해두면 AI가 달아주는 코멘트 품질도 조금은 나아진다. 결국 도구가 좋아져도 리뷰 가능한 PR을 만드는 습관이 먼저다.

그리고 인간 리뷰어와의 역할 분담도 중요하다. 보안, 제품 의도, 비즈니스 규칙, 팀 컨벤션의 예외 같은 건 여전히 사람이 보는 게 낫다. Copilot 리뷰는 그 전에 놓치기 쉬운 부분을 빨리 잡아주는 쪽이 맞다.

지금 시점의 적정 기대치

솔직히 말하면, 이걸로 리뷰 문화가 완전히 바뀌었다고 말하긴 이르다. 문서에도 Copilot 리뷰는 merge를 막지 않는다고 적혀 있고, 피드백에 답글을 달아도 Copilot이 다시 대화형으로 반응하는 구조는 제한적이다. 그러니까 아직은 리뷰어라기보다 보조 레이어다.

그래도 초벌 필터로 놓고 보면 꽤 괜찮다. 특히 바쁜 팀에서 기본적인 품질 체크를 PR마다 한 번 더 돌릴 수 있다는 건 생각보다 든든하다. 사람을 빼는 도구가 아니라, 사람이 더 중요한 문제를 보게 만드는 도구. 지금은 그 정도 정의가 가장 정확해 보인다.

---

📎 참고 자료

• About GitHub Copilot code review
• Using GitHub Copilot code review