도구가 더 좋아지면 에이전트의 결과도 자연스럽게 좋아질 것처럼 보입니다. 하지만 GitHub가 Copilot 코드 리뷰의 탐색 도구를 교체하면서 확인한 결과는 달랐습니다. 관리하기 쉽고 여러 Copilot 제품이 공유할 수 있는 도구로 바꿨는데, 초기 벤치마크에서는 리뷰 비용이 늘고 유용한 문제를 찾아내는 성과는 오히려 떨어졌습니다.
핵심 원인은 새 도구의 성능이 아니라 도구를 사용하는 방식과 지시문이었습니다. 일반적인 코딩 에이전트는 저장소의 넓은 영역을 탐색하고 구조를 이해해야 할 때가 많지만, 풀 리퀘스트 리뷰는 출발점과 목적이 다릅니다. 리뷰어는 변경된 diff에서 시작해 문제가 의심되는 지점을 정하고, 그 의심을 확인하거나 기각하는 데 필요한 최소한의 주변 코드만 읽어야 합니다.
무엇이 바뀌었나
기존 Copilot 코드 리뷰에는 전용 코드 탐색 도구가 있었습니다. 디렉터리를 나열하고, 파일이나 디렉터리 안에서 코드를 검색하고, 필요한 코드 범위를 읽는 방식입니다. 이 도구들은 단순한 명령 래퍼가 아니었습니다. 검색 결과나 요청한 코드와 함께 주변 문맥을 추가로 제공해, 적은 수의 도구 호출로도 모델이 충분한 정보를 받을 수 있도록 설계돼 있었습니다.
GitHub는 이 전용 도구를 Copilot CLI에서 사용하는 Unix 스타일의 공유 도구로 옮기는 실험을 진행했습니다. 목적은 중복 구현을 줄이고, 코드 탐색 기능을 한곳에서 개선하며, 그 개선을 여러 Copilot 제품에 적용하기 쉽게 만드는 것이었습니다.
| 기존 코드 리뷰 도구 | 공유 도구 | 역할 |
|---|---|---|
| list_dir | glob | 열어볼 파일과 디렉터리 후보를 찾습니다. |
| search_file, search_dir | grep | 문자열, 심볼, 호출 지점 등 일치하는 코드를 검색합니다. |
| read_code | view | 경로나 범위를 확인한 뒤 필요한 파일 내용을 읽습니다. |
기능만 놓고 보면 자연스러운 교체였습니다. 그러나 실제 에이전트 동작은 도구 이름이나 검색 성능만으로 결정되지 않습니다. 도구 설명과 사용 지침이 어떤 탐색 순서를 유도하는지, 결과로 받은 코드가 이후 문맥에 얼마나 오래 남는지까지 함께 봐야 합니다.
더 나은 도구가 처음에는 왜 더 나쁜 결과를 냈나
오프라인 벤치마크에서 공유 도구를 사용한 리뷰 에이전트는 풀 리퀘스트를 검토하기보다 저장소 전체를 이해하려는 것처럼 행동했습니다. 넓은 범위를 검색하고, 가능성이 있어 보이는 경로를 추측하고, 큰 코드 범위를 읽은 뒤, 새로 발견한 단서를 따라 다시 검색하는 순환이 나타났습니다.
“이 저장소를 이해하라”는 작업이라면 이런 탐색이 필요할 수 있습니다. 코드를 직접 수정하는 에이전트 역시 변경이 다른 영역을 깨뜨리지 않는지 확인하기 위해 넓은 구조를 살펴볼 이유가 있습니다. 반면 코드 리뷰의 질문은 더 좁습니다. 변경된 함수가 어디에서 호출되는지, 새 설정 키가 다른 곳에서도 사용되는지, 같은 패턴을 다루는 테스트나 헬퍼가 있는지처럼 diff에서 파생된 구체적인 의문에 답하면 됩니다.
에이전트에게 도구 출력은 잠깐 보고 버리는 화면이 아닙니다. 읽어온 파일과 검색 결과는 작업 문맥의 일부가 되어 이후 추론에도 영향을 줍니다. 관련 없는 코드가 많이 들어오면 토큰 사용량이 증가할 뿐 아니라, 정작 변경 사항과 직접 연결되는 증거에 집중하기 어려워질 수 있습니다. 따라서 코드 리뷰에서는 “얼마나 많이 읽었는가”보다 리뷰 판단에 필요한 증거를 얼마나 좁고 정확하게 확보했는가가 중요합니다.
GitHub가 실제로 개선한 지점
GitHub는 공유 도구를 다시 전용 도구로 되돌리는 대신, 리뷰 작업에 맞게 지시문을 고쳤습니다. 에이전트가 일반 코딩 도우미처럼 저장소를 넓게 탐색하지 않고, 풀 리퀘스트 diff를 기준으로 질문을 만들고 그 질문에 필요한 최소 범위의 증거를 찾도록 작업 흐름을 재구성한 것입니다.
그 결과 초기 회귀는 개선으로 바뀌었습니다. GitHub가 공개한 벤치마크 결과에 따르면 리뷰 품질을 같은 수준으로 유지하면서 평균 리뷰 비용을 약 20% 낮췄습니다. 여기서 중요한 교훈은 특정 명령이 다른 명령보다 항상 우수하다는 것이 아닙니다. 같은 도구라도 작업의 목표에 맞는 탐색 규칙이 없으면 더 많은 호출과 문맥을 만들 수 있고, 적절한 지침을 결합하면 비용과 품질을 함께 관리할 수 있다는 점입니다.
개발자가 확인해야 할 의미
Copilot 코드 리뷰를 사용하는 개인 개발자나 팀은 이번 사례를 단순한 내부 도구 교체 소식으로 볼 필요가 없습니다. 에이전트 기반 개발 도구를 평가할 때 최종 답변만 비교하면 중요한 차이를 놓칠 수 있다는 실무 사례이기 때문입니다. 같은 리뷰 코멘트가 나오더라도 불필요한 파일을 얼마나 읽었는지, 검색이 diff에서 멀어졌는지, 실패한 경로를 반복했는지에 따라 운영 비용과 응답 시간은 달라질 수 있습니다.
- 개인 프로젝트: 코멘트 수보다 실제 결함을 지적한 비율과 불필요한 수정 제안의 수를 함께 봐야 합니다.
- 학생: 리뷰 결과를 정답으로 받아들이기보다 지적한 코드와 근거가 직접 연결되는지 확인해야 합니다.
- 연구자: 최종 점수뿐 아니라 도구 호출 수, 검색 범위, 읽어온 문맥 크기, 오류와 재시도 경로를 평가 항목에 포함하는 것이 좋습니다.
- 개발팀: 에이전트가 저장소 전체를 탐색할 권한이 필요한지, 변경 파일과 관련 경로만으로 범위를 제한할 수 있는지 검토해야 합니다.
- 에이전트 개발자: 범용 도구 설명을 그대로 재사용하지 말고 리뷰, 수정, 조사, 테스트 등 작업별 탐색 전략을 분리해야 합니다.
도입 여부보다 먼저 볼 평가 기준
| 항목 | 확인할 질문 | 판단 기준 |
|---|---|---|
| 리뷰 품질 | 실제 문제를 찾았는가, 근거가 변경 코드와 연결되는가? | 코멘트 개수보다 재현 가능한 지적과 유용한 수정 제안의 비율을 봅니다. |
| 탐색 범위 | diff에서 시작했는가, 저장소 전체로 불필요하게 확장됐는가? | 각 도구 호출이 명확한 리뷰 질문에 답하는지 확인합니다. |
| 문맥 비용 | 판단에 필요하지 않은 파일과 코드 범위를 많이 읽었는가? | 같은 품질이라면 더 작은 문맥과 적은 호출로 끝나는 흐름이 유리합니다. |
| 권한 | 비공개 코드와 관련 저장소를 어디까지 읽을 수 있는가? | 업무 코드에는 최소 권한을 적용하고 접근 기록과 관리 범위를 확인합니다. |
| 적용 범위 | 사용 중인 계정, 조직, 저장소와 리뷰 방식에서 지원되는가? | 발표 내용이 자신의 계정과 환경에 실제로 적용되는지 공식 문서에서 확인합니다. |
| 비용 | 기능 이용 조건과 사용량 제한은 무엇인가? | 이 글에 구체적인 가격 조건은 제시되지 않았으므로 최신 플랜 안내를 별도로 확인합니다. |
| 대안 | 기존 정적 분석, 테스트, 사람이 하는 리뷰로도 같은 문제를 찾을 수 있는가? | 기존 검사를 대체하기보다 빈틈을 보완하고 반복 시간을 줄일 때 도입 가치가 큽니다. |
작은 풀 리퀘스트로 검증하는 방법
전체 저장소에 바로 적용하기보다 이미 결론을 알고 있는 작은 풀 리퀘스트로 비교하는 편이 안전합니다. 정상적인 변경, 의도적으로 문제가 포함된 변경, 테스트만 수정한 변경처럼 성격이 다른 사례를 준비하면 에이전트가 어떤 상황에서 넓게 탐색하는지 확인하기 쉽습니다.
- 사람이 이미 검토한 풀 리퀘스트를 몇 개 선택하고 실제로 중요했던 문제를 기준 답안으로 정합니다.
- 에이전트가 찾은 문제 중 재현 가능한 항목과 잘못된 경고를 구분합니다.
- 가능하다면 검색한 경로, 읽은 파일, 도구 호출 수와 오류 발생 여부를 기록합니다.
- 리뷰 코멘트가 diff의 어느 변경에서 출발했고 어떤 주변 증거로 이어졌는지 확인합니다.
- 같은 사례를 반복 실행해 결과가 지나치게 달라지지 않는지 살펴봅니다.
- 기존 리뷰 방식과 비교해 사람이 확인하는 시간, 수정 횟수, 놓친 결함이 실제로 줄었는지 판단합니다.
로그나 추적 정보를 제공하지 않는 제품이라면 최종 코멘트의 근거라도 확인해야 합니다. 파일 경로와 코드 위치가 구체적인지, 지적한 동작을 테스트로 재현할 수 있는지, 관련 없는 영역을 근거로 결론을 확대하지 않았는지가 실용적인 대체 기준입니다.
에이전트를 직접 만드는 경우의 적용 기준
grep, glob, view 같은 범용 도구를 연결하는 것만으로 리뷰 에이전트가 완성되지는 않습니다. 시스템 지침에는 탐색의 출발점, 범위를 넓힐 조건, 중단 조건을 명확하게 넣어야 합니다. 예를 들어 diff에서 의심되는 동작을 먼저 식별하고, 호출 지점이나 설정 사용처를 찾을 때만 검색하며, 결론을 낼 증거가 확보되면 추가 탐색을 멈추는 식입니다.
또한 도구별 출력 크기를 제한하고 필요한 코드 범위를 좁혀 읽도록 설계할 필요가 있습니다. 검색 결과가 많을 때 모든 파일을 여는 대신 변경 코드와 직접 연결되는 후보부터 확인해야 합니다. 경로 추측이 반복되거나 검색 결과가 리뷰 질문과 연결되지 않으면 탐색을 중단하거나 질문을 다시 구성하는 규칙도 도움이 됩니다.
평가 역시 정답률 하나로 끝내기 어렵습니다. 유용한 문제를 찾은 비율, 잘못된 지적, 평균 비용, 도구 호출 수, 읽은 코드의 양을 함께 측정해야 합니다. 이번 사례처럼 최종 품질이 비슷해도 탐색 과정이 달라지면 운영 효율에는 상당한 차이가 생길 수 있습니다.
적용 전 체크포인트
- 현재 사용하는 계정과 저장소에서 기능을 이용할 수 있는지 공식 안내를 확인합니다.
- 비공개 저장소, 조직 코드, 연구 자료를 다룬다면 접근 권한과 데이터 처리 조건을 먼저 검토합니다.
- 현재 가격, 플랜별 제한, 사용량 산정 방식은 이 사례에 구체적으로 제시되지 않았으므로 별도 확인이 필요합니다.
- 정적 분석, 테스트, 보안 스캔과 역할이 겹치는지 확인하고 동일한 경고가 중복되지 않도록 구성합니다.
- 에이전트 리뷰를 병합 승인 조건으로 사용할지, 사람이 참고하는 보조 신호로 사용할지 팀 규칙을 정합니다.
- 문제가 생겼을 때 자동 리뷰를 끄고 기존 절차로 돌아갈 수 있는지 확인합니다.
자주 묻는 질문
Copilot 코드 리뷰가 저장소를 전혀 넓게 탐색하지 않는다는 뜻인가?
그런 의미는 아닙니다. 변경의 영향을 확인하려면 호출 지점, 관련 설정, 테스트처럼 diff 밖의 코드를 볼 수 있습니다. 중요한 차이는 저장소를 먼저 넓게 훑는 것이 아니라, diff에서 나온 구체적인 질문을 해결하기 위해 필요한 범위만 확장하는 데 있습니다.
평균 비용이 약 20% 줄었다면 모든 리뷰에서도 같은 절감이 발생하나?
공개된 수치는 GitHub가 설명한 벤치마크의 평균 결과입니다. 저장소 크기, 변경 유형, 언어와 리뷰 난이도에 따라 개별 결과는 달라질 수 있습니다. 자신의 환경에서는 동일한 유형의 풀 리퀘스트를 기준으로 비용과 품질을 함께 비교해야 합니다.
공유 도구로 바꾸는 것이 항상 좋은 선택인가?
공유 도구는 중복 구현을 줄이고 여러 제품에 개선을 확산하기 좋지만, 작업별 지침과 평가가 뒤따라야 합니다. 기존 전용 도구가 제공하던 주변 문맥이나 기본 동작이 사라질 수 있으므로 단순한 이름 대응만으로 교체해서는 결과를 예측하기 어렵습니다.
이 소식만 보고 바로 도입해도 되나?
작은 검증부터 진행하는 편이 좋습니다. 기능의 현재 제공 범위, 플랜 조건, 권한과 데이터 처리 정책은 공식 문서에서 확인하고, 실제 풀 리퀘스트에서는 지적의 정확성과 근거, 잘못된 경고, 사람이 절약한 시간을 함께 측정해야 합니다.
출처와 검증
이 글의 도구 교체 과정, 초기 벤치마크 회귀, 탐색 방식의 차이와 평균 리뷰 비용 개선 수치는 GitHub Blog의 설명을 기준으로 정리했습니다. 가격, 계정별 제공 범위, 데이터 처리 조건처럼 변경될 수 있는 사항은 적용 시점의 공식 문서를 추가로 확인해야 합니다.
GitHub Blog의 이번 발표는 Better tools made Copilot code review worse. Here’s how we actually improved it.: 개발자가 확인할 점와 관련해 개발 도구 관점에서 실제 적용 범위와 운영 조건을 확인해야 하는 변화입니다. 기능명보다 계정 유형, 관리자 설정, 비용과 권한 조건, 기존 대안과 비교했을 때 반복 작업을 얼마나 줄이는지가 판단 기준입니다.