Gemini Code Assist 활용기
일을 하다보면 코드리뷰가 필요함에도 불구하고 여러 이유로 코드리뷰를 진행하지 못하는 경우가 있다.
뭐 사실은 귀찮다는게 가장 큰 이유다.
코드를 작성하는 것과 작성된 코드를 이해하는 것은 또 다른 영역이라 남이 작성한 코드를 일일히 보면서 어디가 어떻게 잘못될 것인지 안티패턴이 존재하는지 파악하는 것은 꽤 힘든 일이다.
그래서 이제 코드리뷰도 AI의 도움을 받자는 생각이 들었다.
조금 다른 얘기지만 코드 작성도, 리팩토링도, 리뷰도 이젠 AI의 도움을 받는다니 이제 정말 단순 코더들은 다 죽어나가겠구나 하는 생각이 든다.
다시 돌아와서, 코드리뷰를 위한 AI는 생각보다 꽤 많다.
CodeRabbit, Github Copilot, 기타 등등
몇 가지 비교해보면서 내린 결론은 Gemini Code Assist이다.
가장 큰 이유는 비용 부담 없이 가장 빠르게 실무에 도입할 수 있다는 점이었다.
물론 Gemini 자체에 대한 신뢰도 있었다.
하여튼 그래서 오늘의 글은 Gemini Code Assist를 도입하면서 생긴 크고 작은 변화들에 대한 기록이다.
Gemini Code Assist는 좀 기니까 GCA라고 부르겠다.
GCA는 깃허브 마켓플레이스에서 무료로 설치할 수 있다.
설치 후 적용할 레포지토리를 연결해주면 간단하게 설정이 끝난다.
이제 해당 레포지토리에 PR을 올리면 간략한 코드 변경 요약과 리뷰가 출력된다.
변경 요약은 체감상 거의 즉시 ~ 1분 내로 올라온다.
실제 리뷰는 약 5분 정도 지나야 올라오는 느낌이다.
리뷰에는 Critical, High Priority, Medium Priority, Low Priority로 중요도 레벨이 같이 달린다.
기본적으로 Medium Priority까지만 출력이 되도록 설정이 되어있다.
실무에서도 너무 과한 리뷰를 방지하기 위해 기본 설정을 그대로 가져갔다.
실제로 GCA를 도입하고 나서 느낀 점들을 좀 정리해보면, 생각보다 얻어가는 부분이 꽤 많았다.
첫 번째로, 팀 전체의 스타일가이드를 훨씬 명확하게 정리할 수 있게 됐다.
사람마다 기준이 조금씩 다른 부분을 GCA에 명시적으로 정의해두면, 그게 사실상 팀의 공식 컨벤션처럼 작동한다. 기존에는 구두로만 전달되거나 PR 리뷰 중간에 슬쩍 이야기되는 것들이 많았는데, 이제는 명확한 문서와 자동화된 리뷰가 동시에 역할을 하니까 기준이 흐트러질 일이 거의 없다.
두 번째로, 자잘한 컨벤션 리뷰에 시간을 낭비하지 않아도 된다는 점이 상당히 크다.
띄어쓰기, 변수명 일관성, import 정렬, 스타일 포맷팅 같은 것들은 솔직히 사람이 매번 리뷰할 필요가 없다. ‘이런 것까지 내가 직접 리뷰해야 하나?’ 싶은 것도 많았는데, 이제는 그런 부담을 거의 GCA가 가져간다. 기본적인 스타일 문제는 머신이 걸러주고 리뷰어는 진짜 논의해야 하는 로직, 아키텍처, 설계 쪽에 집중할 수 있다.
세 번째로, 안티패턴을 찾는 데도 확실히 도움이 된다.
특정 프레임워크나 언어에서 흔히 발생하는 비효율적인 패턴, 잘못된 추상화, 리소스 누수 가능성 같은 것들을 꽤 잘 잡아준다. 사람이 놓치기 쉬운 부분을 자동으로 탐지해주니 코드 품질 관리가 한결 수월해진 느낌이다.
그리고 마지막으로, 이건 아직 확신할 정도는 아니지만, 장기적으로 팀 전체의 컨벤션을 강제하고 신규 인력이 합류해도 온보딩이 빨라질 것 같다.
팀마다 고유한 규칙이나 철학이 있는데, 그걸 새 팀원이 학습하는 데 꽤 시간이 걸린다. 그런데 GCA가 그 기준을 계속 자동으로 피드백해주면, 자연스럽게 팀의 코드 스타일을 따라가게 된다. 문서 + 자동화 리뷰 조합이 온보딩 시간을 줄여줄 것 같다는 느낌이 있다.
장점들을 쭉 이야기했는데, 반대로 쓰다 보니 몇 가지 아쉬운 점도 분명 있었다. 이 부분도 같이 적어두는 게 균형이 맞을 것 같아 정리해보면 아래 정도다.
첫째, PR을 닫았다가 다시 열지 않는 이상 자동 리뷰는 최초 한 번만 진행된다.
물론 수동으로 “리뷰 다시 해줘”라고 요청할 수는 있지만, 여전히 흐름이 끊기고 번거롭다. 코드가 계속 업데이트되는 상황에서는 자동으로 다시 리뷰가 붙어주면 좋겠다는 생각이 자꾸 든다.
둘째, 재리뷰를 받을 때는 생성형 AI의 한계가 그대로 드러난다.
어떻게든 뭔가 새로운 피드백을 만들어내려는 특유의 억지 리뷰가 종종 보인다. 이미 해결된 부분인데 다른 말로 또 언급한다든가, 실제로는 별 의미 없는 포인트를 중요해 보이게 말하는 식의 현상이 조금 있다. 이런 부분은 사람이 읽을 때 피곤해진다.
셋째, 기본 설정에서는 과거 리뷰 맥락을 모르고 동작한다.
과거 리뷰나 팀의 누적된 컨벤션을 학습시키는 옵션이 있기는 하지만, 설정도 까다롭고 리뷰 시간이 길어질 가능성이 높다. 여기에 비용 문제까지 고려하면 굳이 그렇게까지 해야 하나 싶은 마음이 든다. 말 그대로 배보다 배꼽이 커질 것 같은 느낌이다.
물론 단점보단 장점이 많고 실제 경험을 따져보면 실무에 들여올만한 가치는 충분이 있다고 본다.
아직은 시범적인 도입단계라 단순 리뷰에만 사용하고 있지만 좀 더 이런식의 코드리뷰 문화가 조직에 정착되면 개인적으로 해보고 싶은 것들이 더 있다.
뭐, 그건 좀 나중의 이야기기 때문에 일단 오늘 기록은 여기까지.
