||
안녕하세요. 크리에이트립(Creatrip)의 강병준입니다.
저는 사내에서 FE 업무뿐만 아니라, AI를 활용한 개발 생산성 향상과 코드 품질 개선에도 깊이 관여하고 있는데요, 오늘은 그 중 하나인 AI 코드 리뷰의 품질을 개선해온 과정을 공유해보려고 합니다.
배경
GitHub Octoverse 2025에 따르면 한 해 동안 머지된 PR은 전년 대비 23% 증가했고, 커밋은 10억 건을 넘었습니다. 이런 급격한 성장을 보면 AI를 통한 코드 작성이 어느새 우리 삶의 일부가 된 것이 실감이 납니다.
하지만 생산성이 올라간 만큼, 그 이면의 비용도 함께 커지고 있습니다. CodeRabbit 리포트에 따르면 AI가 생성한 코드는 인간 코드 대비 PR당 이슈가 1.7배 많고, 로직 에러는 75%가 더 높습니다.
소프트웨어 개발 업계도 이 문제에 대해 명확히 인식하고 있는 것으로 보입니다. Amazon은 AI 작성 코드로 인한 연쇄 장애 이후 시니어 엔지니어의 PR 승인을 의무화 하였고, Shopify는 AI가 작성한 코드의 PR에 대해 자동 머지를 허용하지 않기로 결정하였습니다. 또 Stripe의 자율 에이전트는 주당 1,300개의 PR을 만들지만, 전부 사람이 리뷰합니다.
여전히 AI가 작성한 코드에 대한 신뢰성 부재라는 문제가 존재하며, 코드를 검증하는 중요성은 더욱 커지고 있습니다.
Agent SDK로 만드는 자율적 AI Assistant
이전 글에서 우리는 이러한 검증의 한 가지 수단으로서 Claude Agent SDK를 활용한 AI 코드 리뷰 시스템을 만든 과정을 공유했었습니다. 팀원 모두가 대체적으로 만족하고 있었지만 어디까지나 정성적 평가와 느낌에 기반할 뿐, 명확한 수치나 평가 기준이 없어 “정말 리뷰를 잘 하고 있는걸까?”라는 질문에 명쾌한 답을 할 수는 없었습니다.
이 글은 위 질문에서 출발하여 AI 코드 리뷰의 품질을 수치화하고 품질을 높이기 위해 지금까지 시도하고, 실패하고, 개선한 기록을 공유합니다.
1. 측정할 수 없으면 개선할 수 없다
LLM이 발전하면서 자연스럽게 AI 리뷰의 품질도 높아졌고, AI 리뷰가 코드 상에서 발생할 수 있는 문제를 잘 검증해주고 있다는 느낌은 있었습니다. 그러나 동일한 환경에서도 항상 다른 결과를 뱉는 AI에게 프롬프트의 수정은 무의미한 반복이었고, 확률에 기대며 AI가 문제를 잘 지적해주기를 바라는 것에 불과했습니다.
그래서 확률이 아닌 데이터에 기반할 수 있는 우리만의 벤치마크를 만들기 시작했습니다.
무엇을 테스트할 것인가
가상의 버그가 포함된 PR을 합성 데이터 형식으로 만들 수도 있었지만, 실제로 프로덕션에서 발생한 버그만큼 확실한 기준은 없었습니다. 그래서 Hotfix PR에서 원본 PR을 역추적하여, 원본 PR 시점에 AI 리뷰를 돌렸다면 이 버그를 잡을 수 있었는가를 기준으로 테스트 케이스를 구성하였습니다.
“이 Hotfix는 Original PR에서 AI 리뷰로 잡을 수 있었던 버그인가?”
Origin PR (버그가 생겨난 PR)
↑
|
git commit
↑
| 커밋 히스토리 역추적 (git blame)
|
Hotfix PR (버그 수정) ← 여기서 출발
테스트 케이스는 PR diff만으로 검출 가능한 버그만 포함하고, PR에 명시되지 않은 외부 맥락이 필요한 경우는 배제하였습니다.
어떻게 채점할 것인가
테스트 케이스에 대한 AI 리뷰의 결과가 나왔을 때 버그를 잘 잡는지를 판정하는 것도 문제였습니다. 사람이 일일이 평가하는 방식은 리소스가 너무 많이 들어, 장기적으로 지속할 수 있는 방법이 아니었고 키워드 매칭 방식은 한계가 분명했습니다.
그래서 GPT 4o mini 모델을 활용하여 AI 리뷰 결과를 채점하는 LLM-as-a-Judge 방식을 적용하였습니다. 오차 범위는 존재하지만, 모든 테스트에 동일한 Judge를 적용하기 때문에 상대 비교에는 문제가 없었습니다. 프롬프트나 서브에이전트에 대해 A와 B 중 어느 쪽이 더 잘 잡는지를 비교하는 것이 초기 목적이었으니까요.
자체 구축한 벤치마