코드 리뷰는 흔히 느리고 편차가 큽니다. diff는 대기열에서 기다리고, 피드백은 누가 온라인인지에 따라 달라집니다.

AI 코드 리뷰는 리뷰어에게 실제 코드베이스 컨텍스트가 있을 때만 효과적입니다.

AI 코드 리뷰는 리뷰어가 이미 전체 repo, 최근 변경 사항, 테스트, 명확한 규칙 세트를 파악하고 있을 때 가장 효과적입니다. 이러한 컨텍스트를 갖춘 AI 코드 리뷰는 단일 diff만 들여다보는 독립형 봇이라면 절대 발견하지 못할 문제를 잡아냅니다. 리뷰는 변경 사항을 만든 동일한 시스템의 일부일 때 가장 유용합니다.

#코드 리뷰에서 달라진 점

코딩 에이전트가 긴 풀 리퀘스트를 만들어낸 것은 아니지만, 기존의 리뷰 방식은 그 영향으로 더 빨리 한계에 부딪히게 되었습니다.

코딩 에이전트를 사용하는 개발자들은 더 큰 변경을 배포하고 있습니다. 수백만 건의 Cursor 세션 데이터에 따르면, PR당 추가된 줄 수(p75)는 전년 대비 약 2.5배 증가했습니다. 변경 줄 수가 1,000줄이 넘는 메가 PR이 머지에서 차지하는 비중도 커지고 있으며, 에이전트와 모델이 개선되면서 2026년 1월에는 뚜렷한 증가세가 나타났습니다. Agent 세션도 더 깊어졌습니다. 최근 두 달 동안 세션당 평균 tool call 수는 약 30% 증가했습니다. AI가 작성한 코드가 유지되는 비율도 높아졌습니다. 수락된 AI 코드 줄 가운데 60분 후에도 그대로 남아 있는 비율은 2026년 초 이후 대략 76%에서 81%로 상승했습니다. 별도의 수동 diff 수락 단계 없이 commit까지 이어진 Agent 생성 변경은 같은 기간 동안 5배 넘게 증가했습니다.

사람의 리뷰 역량은 이런 변화에 맞춰 확장되지 않았습니다. 전통적인 동료 리뷰 지침에서는 오래전부터 몇백 줄 정도를 주의 깊게 읽는 수준까지를 품질이 유지되는 범위로 보아 왔습니다.

AI 코드 리뷰는 변경량이 모든 diff를 읽을 수 있는 시니어 엔지니어의 수를 앞지를 때도 품질 게이트를 유지하는 방법입니다.

리뷰 대상 코드 중 AI 지원을 받아 작성된 코드의 비중이 더 커졌습니다. 사람은 "이건 우리가 여기서 만드는 방식과 맞지 않는다"는 점을 잘 잡아냅니다. 하지만 크고 그럴듯하며 대체로 맞는 에이전트 패치에서 미묘한 한 가지 문제를 찾아내는 데는 더 약하며, 바로 그런 지점에서 실제 repo 맥락을 이해하는 리뷰어가 도움이 됩니다. 큰 변경을 작성하는 것과 그것을 점검하는 것은 서로 다른 스킬이며, 리뷰는 그 점검입니다.

#AI 코드 리뷰를 시작하기 전 확인할 질문

AI 코드 리뷰 도구를 평가하고 있다면, 먼저 다음 개념을 살펴보세요.

#AI 코드 리뷰란 무엇인가요?

AI 코드 리뷰는 변경 사항(보통은 pull request, 때로는 로컬 diff)을 읽고, 병합 전에 버그, 회귀, 위험 요소를 짚어 주는 소프트웨어입니다. 유용한 버전은 눈앞의 변경된 줄만 보는 데 그치지 않고 그 이상의 맥락까지 추론합니다. 관련 file, test, 구성, 팀 규칙까지 끌어와 함께 살펴봅니다. 반면 성능이 떨어지는 버전은 diff를 문장으로 풀어 쓰거나 comments와 naming만 두고 잔소리하는 수준에 머뭅니다.

#린팅이나 CI와는 어떻게 다른가요?

린터와 타입 체커는 이미 알고 있는 규칙을 코드로 옮긴 것입니다. CI는 자동화해 둔 검사를 실행합니다. AI review는 그 밖의 영역을 다룹니다. 예를 들어 논리 오류, race conditions, 인증 관련 실수, 몇 개 폴더 떨어진 곳에서 발생하는 문제, 그리고 docs와 behavior가 맞지 않는 경우입니다. CI와 겹치는 부분도 있습니다. 하지만 CI를 대체하는 것은 아닙니다.

#AI 코드 리뷰가 사람의 리뷰를 대체하나요?

아니요. 사람이 어디에 시간을 쓰는지를 바꿉니다. 사람이 남긴 리뷰 코멘트의 절반 정도만 결국 같은 PR에서 실제 변경으로 이어집니다. 건강한 리뷰 문화에는 나중에 수정해도 되는 메모와 참고용 맥락도 포함됩니다. 사람들이 아직 모델이 알지 못하는 아키텍처, 제품 리스크, 팀의 암묵지에 집중할 수 있도록 신뢰도 높게 판별할 수 있고 기계가 처리할 수 있는 버그를 먼저 걸러내는 것이 좋습니다.

#AI review에 왜 노이즈가 많을까요?

노이즈는 사람들이 봇에게서 원하지 않는 코멘트에서 나옵니다. 스타일에 대한 잔소리, 실패하는 테스트도 없이 모호하게 "테스트를 추가하세요"라고 적는 메모, 버그를 잡아내지 못하는 재작성 제안은 모두 사람들이 리뷰를 무시하게 만듭니다. 모델이 잡아낼 수 있는 것과 사람들이 실제로 지적해 주길 바라는 것을 구분하세요. AI 코드 리뷰는 실제 버그, 실수로 포함된 커밋, 성능 및 보안 문제, 그리고 문서와 코드가 서로 어긋나는 부분을 플래그해야 합니다. Graphite가 AI reviews의 범위를 그 겹치는 지점으로 좁혔을 때, 코멘트의 약 52%가 코드 변경으로 이어졌고(대략 인간 리뷰어와 같은 비율), 비추천 비율은 4% 미만이었습니다.

#무엇을 측정해야 할까요?

해결률: 병합 시점에 플래그된 이슈가 실제로 최종 코드에서 수정되었는가? 해결률이 코멘트 수보다 중요합니다.

이것은 Cursor가 Bugbot을 개선하는 데 사용한 지표이기도 합니다. 해결률은 52%에서 70% 이상으로 올라갔고, 40번의 실험에 걸쳐 실행당 플래그된 버그 수는 0.4에서 0.7로, PR당 해결된 버그 수는 대략 0.2에서 약 0.5로 증가했으며, 매월 200만 건이 넘는 PR을 검토한 결과입니다. 2026년 5월 기준으로 기본 추론 수준에서 병합 시점까지 해결된 버그 비율은 약 80%에 도달했습니다. 해결률은 떨어지는데 코멘트 수만 늘어난다면, 그 봇은 잡음만 만들어내고 있는 것입니다.

Bugbot 대시보드는 각 리포지토리의 시간에 따른 해결률과 찾아내고 수정한 이슈 수를 차트로 보여줍니다. 이를 통해 봇의 코멘트 범위를 넓히기 전에 리뷰가 실제 문제를 잡아내고 해당 문제가 해결되는지 확인할 수 있습니다.

#리뷰는 언제 실행해야 할까요? 로컬에서, PR에서, 아니면 둘 다에서?

둘 다 필요하지만, 역할은 서로 다릅니다. 로컬 리뷰는 (에이전트 작업 후, 푸시하기 이전) 아직 컨텍스트가 생생하고 스레드도 아직 없을 때 문제를 잡아냅니다. PR 리뷰는 팀의 공통 기준입니다. 즉, 공유된 규칙, 공유된 히스토리, 공유된 merge gate 역할을 합니다. 보안 중심 점검은 배포 방식에 따라 어느 쪽에 두어도 됩니다.

#리뷰 도구가 에이전트와 같은 제품에 있어야 할까요?

독립형 리뷰어를 구매할 수 있습니다. 실제로 많은 팀이 그렇게 합니다. 그 대가는 컨텍스트 전환이 늘어나고 코드가 어떻게 만들어졌는지에 대한 시야가 더 좁아진다는 점입니다. 리뷰가 변경 사항을 만든 동일한 시스템에서 실행되면, 이미 열려 있는 파일, repo 맵, 그리고 코드와 함께 관리하는 규칙을 알고 있습니다. 수정 사항에서 곧바로 편집기로 딥링크할 수도 있고, 발견 내용을 불러온 상태로 에이전트를 실행할 수도 있습니다. 이런 루프는 덧붙인 도구로는 흉내 내기 어렵습니다.

#Cursor에서 AI 코드 리뷰를 실행하는 방법

Cursor의 워크플로는 에디터에서 로컬 리뷰를 수행하고, pull request에서 Bugbot 검토를 거친 뒤, 동일한 도구 체인에서 수정하는 루프로 이어집니다.

로컬. Agent 작업 후 Agent Review를 실행하세요. Agent 입력란에 /agent-review를 입력하거나, Source Control 탭에서 실행해 로컬 변경 사항을 main 브랜치와 비교하거나, 모든 커밋 후 자동 검토를 켤 수 있습니다. 푸시하기 전에는 /review-bugbot 및 /review-security 스킬을 사용해 Bugbot 또는 Security Agent를 로컬에서 실행할 수도 있습니다. 세션에 컨텍스트가 남아 있을 때 명백한 문제를 해결하는 단계입니다.

PR에서. Bugbot은 GitHub, GitLab, Bitbucket의 풀 리퀘스트를 검토합니다. 팀의 불변 조건은 팀 규칙 및 repo 규칙과 함께 .cursor/BUGBOT.md에 정의하세요. 학습된 규칙(@cursor remember)은 피드백을 이후 실행에 반영합니다. 댓글 범주를 확대하기 전에 Bugbot 자동화에서 해결률을 확인하세요.

수정 루프. 발견 사항은 Cursor로 돌아갈 수 있는 경로(Fix in Cursor 및 Fix in Web)와 함께 PR에 표시됩니다. Bugbot Autofix는 수정을 제안할 Cloud Agent를 생성할 수 있습니다. 보안 측면에서 Cursor의 Security Agents는 두 가지 역할을 수행합니다. Security Reviewer는 병합 전에 PR을 검토하고, Vulnerability Scanner는 유휴 상태의 코드베이스를 검사합니다.

시작하기. 문서에서 repo 연결, 검토를 트리거할 repo와 사용자 선택, 추론 수준, .cursor/BUGBOT.md를 비롯한 전체 설정 과정을 다룹니다. cursor.com/docs/bugbot에서 시작해 보세요.

#라우팅 및 승인 자동화

버그를 찾아내는 것만이 검토 업무의 전부는 아닙니다. 두 가지 Cursor 자동화가 반복적인 작업을 처리합니다.

위험도가 낮은 변경 사항 자동 승인. Approval Agents는 각 pull request의 위험도를 평가하고, 설정한 기준을 충족하는 요청을 승인합니다. 문구 수정이나 구성 버전 업데이트는 사람의 검토를 기다리지 않고 병합할 수 있습니다. 위험 임계값을 초과하는 변경 사항은 보류됩니다. Bugbot 및 Security Agent의 발견 사항도 이 결정에 반영되므로, 위험한 변경 사항이 그대로 승인되는 일은 없습니다.

적절한 리뷰어에게 라우팅. PR에 사람의 검토가 필요할 때 Approval Agents는 정의한 영역별 라우팅 정책을 사용해 변경 사항이 영향을 미치는 코드베이스 부분에 따라 리뷰어를 할당합니다. 변경 사항은 공용 대기열이 아닌 해당 코드를 담당하는 팀으로 전달됩니다.

#리뷰를 코드 가까이에서 유지하세요

AI 코드 리뷰는 에이전트가 변경의 규모와 속도를 키우는 상황에서도 팀이 품질 게이트를 유지할 수 있게 해줍니다. 잘 작동하는 방식은 repo 컨텍스트, 엄격한 코멘트 정책, 그리고 발견 사항이 실제로 수정되는지 추적하는 지표를 갖추고 있습니다.

리뷰는 코드가 작성된 곳 가까이에서 같은 규칙과 같은 수정 경로를 따라 이뤄져야 합니다. 활발한 repo 하나에 Bugbot을 켜고, Bugbot 자동화에서 일주일 동안 해결 추이를 지켜본 뒤 어떤 범주에 더 많은 볼륨이 필요한지 결정하세요.