Copilot 코드 리뷰 개선 공부 정리 | 더 좋은 도구가 더 나쁜 결과를 냈을 때

GitHub 블로그에서 Copilot 코드 리뷰 팀이 올린 글을 읽었는데, 제목 자체가 좀 특이했다. 더 좋은 도구로 바꿨는데 오히려 리뷰가 나빠졌다는 이야기였다.

경위를 읽어보면 이렇다. 코드 리뷰 전용으로 만들어둔 도구들을 버리고 grep·glob·view 같은 Unix 스타일 범용 도구로 마이그레이션했다. 여러 팀이 함께 쓰는 공용 툴셋으로 통합하는 방향이었다. 그런데 바꾸고 나서 리뷰 품질이 오히려 떨어졌다는 거다.

1️⃣ 이게 왜 나빠졌냐

글을 읽어보니 에이전트가 “리뷰어”처럼 행동하지 않고 “탐색자”처럼 행동하기 시작한 게 문제였다.

PR diff를 먼저 보는 대신, 저장소 전체를 돌아다니면서 맥락을 끌어모으기 시작했다는 거다. 범용 도구로 교체하면서 에이전트의 행동 공간이 넓어졌고, 그 넓어진 공간만큼 방향이 흐려진 것 같다.

기존 전용 도구는 도구 자체가 “이건 리뷰 작업”이라는 맥락을 암묵적으로 담고 있었다. 범용 도구로 바꾸면서 그 맥락이 사라진 거였다.

해결책은 도구를 되돌리는 게 아니라 프롬프트를 다시 쓰는 거였다. 원문에 나온 지침은 이런 식이었다:

“Start from the diff. Narrow first with grep and glob; read exact evidence with view.”

diff에서 시작해, 필요하면 grep/glob으로 좁히고, 실제 확인이 필요할 때만 view로 읽는다. 에이전트가 리뷰어처럼 움직이는 순서를 직접 지정해준 거다.

2️⃣ 내가 든 생각

처음엔 좋은 도구를 쓰면 자연히 좋은 결과가 나올 거라 막연히 생각하고 있었는데, 이 글 읽으면서 그게 생각보다 단순하지 않다는 걸 느꼈다.

범용 도구는 행동 공간이 넓다. 그 넓음 자체가, 에이전트한테 “이 도구를 어떻게 써야 하는지”를 따로 명시해야 한다는 뜻이기도 한 것 같다. 전용 도구는 도구 자체가 그 지침을 내포하고 있었던 거다.

👉🏻 도구를 바꿨을 때 실패한 게 아니라, 바꾸면서 잃어버린 맥락을 다른 방식으로 보충하지 않은 게 문제였던 셈이다.

💡 여기서 드는 질문: 범용 도구와 전용 도구의 차이는 결국 어디에 있는 걸까? 기능의 차이인가, 도구가 암묵적으로 담고 있는 맥락의 차이인가?

디자이너로서 보면, 컴포넌트 재사용성을 고민할 때랑 비슷한 구조인 것 같기도 했다. 범용화할수록 쓰는 사람이 “어떻게 써야 하는지”를 따로 배워야 하는 상황이 생긴다. 제품에서는 그 간극을 가이드라인이 채우고, AI 에이전트에서는 프롬프트가 채우는 게 아닐까 싶었다.

⭐️ 마지막으로, 학습 노트 관점에서 정리해보니

공부 끝에 남은 건 이 한 줄이다 — 도구의 범용성과 에이전트의 집중력은 서로 다른 문제다.

GitHub 팀이 도구를 되돌리지 않고 프롬프트를 다시 쓴 선택이 가장 인상에 남았다. 도구를 탓하기 전에 그 도구를 어떻게 쓸지를 먼저 정의하는 방식, 공부하면서 기억해두고 싶었던 패턴이었다.

---

참고 원문: Better tools made Copilot code review worse. Here’s how we actually improved it.