더 나은 Bugbot 만들기(Cursor)
TMT코딩 에이전트의 역량이 향상되면서, 우리는 리뷰에 더 많은 시간을 들이게 되었습니다. 이를 해결하기 위해, 프로덕션에 도달하기 전에 풀 리퀘스트를 분석하여 로직 버그, 성능 문제, 보안 취약점을 찾아내는 코드 리뷰 에이전트인 Bugbot을 만들었습니다. 지난여름, Bugbot이 매우 잘 작동하게 되자 사용자들에게 공개하기로 결정했습니다.
Bugbot을 만드는 과정은 정성적 평가로 시작해 점차 체계적인 접근으로 발전했으며, 품질을 향상시키기 위해 맞춤형 AI 기반 지표를 사용한 힐 클라이밍을 적용했습니다.
출시 이후, 우리는 40개의 대규모 실험을 진행하여 Bugbot의 해결률(resolution rate)을 52%에서 70% 이상으로 끌어올리는 동시에, 실행당 평균 버그 표시 수를 0.4에서 0.7로 증가시켰습니다. 이는 PR당 해결된 버그 수가 대략 0.2에서 약 0.5로 두 배 이상 증가했음을 의미합니다.
11개 버전에서의 개선을 보여주는 차트로, 해결률과 실행당 평균 버그 수를 함께 표시하며 성능이 우상향하는 흐름을 보입니다. 우리는 2025년 7월에 버전 1을 출시했고, 2026년 1월에 버전 11을 출시했습니다. 최신 버전은 거짓 양성(false positives)의 유의미한 증가 없이 더 많은 버그를 포착했습니다.
소박한 시작
처음 코드 리뷰 에이전트를 만들려 했을 때는 모델의 역량이 충분하지 않아 리뷰가 유용하지 않았습니다. 그러나 기본 모델들이 개선되면서, 우리는 버그 보고의 품질을 높일 수 있는 다양한 방법이 있음을 깨달았습니다.
우리는 모델, 파이프라인, 필터, 영리한 컨텍스트 관리 전략의 다양한 구성들을 실험했으며, 그 과정에서 엔지니어들을 내부 설문으로 지속적으로 폴링했습니다. 특정 구성에서 거짓 양성이 줄어든 것처럼 보이면, 그 구성을 채택했습니다.
초기에 발견한 가장 효과적인 품질 개선 중 하나는 여러 개의 버그 탐지 패스를 병렬로 실행한 뒤, 다수결 투표로 그 결과를 결합하는 방식이었습니다. 각 패스는 diff의 순서를 다르게 받아 모델이 서로 다른 추론 경로를 따르도록 유도했습니다. 여러 패스에서 독립적으로 동일한 이슈를 표시할 경우, 우리는 그것을 실제 버그임을 시사하는 더 강한 신호로 간주했습니다.
수주에 걸친 내부 정성적 반복 작업 끝에, 우리는 시장의 다른 코드 리뷰 도구들을 능가하면서도 출시할 자신감을 주는 버전의 Bugbot에 도달했습니다. 이 버전은 다음과 같은 흐름을 사용했습니다:
- 무작위화된 diff 순서로 8개의 병렬 패스 실행
- 유사한 버그를 하나의 버킷으로 결합
- 단 한 패스에서만 발견된 버그를 필터링하기 위한 다수결 투표
- 각 버킷을 하나의 명확한 설명으로 병합
- 컴파일러 경고나 문서 오류와 같은 원치 않는 카테고리 필터링
- 거짓 양성을 잡기 위한 검증 모델을 통해 결과 처리
- 이전 실행에서 게시된 버그와의 중복 제거
프로토타입에서 프로덕션으로
Bugbot을 실전에서 사용 가능하게 만들기 위해, 우리는 핵심 리뷰 로직과 함께 일련의 기초 시스템에 투자해야 했습니다. 여기에는 Git 통합을 Rust로 재구현하여 저장소 접근을 빠르고 안정적으로 만들고, 가져오는 데이터 양을 최소화하며, 레이트 리밋 모니터링, 요청 배치, GitHub의 제약 내에서 작동하기 위한 프록시 기반 인프라 추가가 포함되었습니다.
도입이 증가하자, 팀들은 안전하지 않은 마이그레이션이나 내부 API의 잘못된 사용 같은 코드베이스 특유의 불변 조건을 인코딩할 방법이 필요했습니다. 이에 대응하여, 우리는 그러한 검사들을 시스템에 하드코딩하지 않고도 지원할 수 있도록 Bugbot rules를 추가했습니다.
이 구성 요소들은 함께 Bugbot을 실제 코드베이스에서 실행 가능하고 적응력 있게 만들었습니다. 그러나 이것만으로는 품질이 실제로 개선되고 있는지를 알려주지 못했습니다. 진행 상황을 측정할 지표가 없다면, 우리는 실제 환경에서 Bugbot의 성능을 정량적으로 평가할 수 없었고, 이는 우리가 밀어붙일 수 있는 한계선을 그었습니다.
중요한 것을 측정하기
이 문제를 해결하기 위해, 우리는 해결률(resolution rate)이라 불리는 지표를 고안했습니다. 이는 PR 머지 시점에, 최종 코드에서 작성자가 실제로 해결한 버그가 무엇인지 AI를 사용해 판단합니다. 이 지표를 개발할 때, 우리는 내부적으로 모든 사례를 PR 작성자와 함께 표본 점검했으며, LLM이 거의 모든 항목에 대해 해결됨/미해결을 정확히 분류한다는 것을 확인했습니다.
팀들은 Bugbot이 자신들에게 어떤 영향을 주는지 평가하는 방법을 자주 묻기에, 우리는 이 지표를 대시보드에 두드러지게 노출합니다. 효과를 평가하는 팀들에게, 이는 댓글 반응이나 경험담보다 훨씬 더 명확한 신호입니다. 해결률은 Bugbot이 엔지니어들이 실제로 수정하는 진짜 이슈를 찾아내고 있는지를 직접적으로 답합니다.
Bugbot 대시보드는 시간이 지남에 따라 검토된 PR, 해결된 이슈, 사용자 수, 절약된 시간 등의 지표를 보여줍니다. Bugbot 대시보드는 팀의 해결률 추세와 기타 핵심 지표도 보여줍니다.
Hill-climbing
해결률을 정의하면서 Bugbot을 만드는 방식이 바뀌었습니다. 처음으로, 우리는 감(감각)에 의존하지 않고 실제 신호를 바탕으로 힐 클라이밍을 할 수 있게 되었습니다. 우리는 온라인에서는 실제 해결률을 사용해 변경 사항을 평가하고, 오프라인에서는 사람이 주석을 단 실제 코드 diff로 구성된 큐레이션된 벤치마크인 BugBench를 사용해 평가했습니다.
우리는 모델, 프롬프트, 반복 횟수, 검증기, 컨텍스트 관리, 카테고리 필터링, 에이전틱 디자인에 걸쳐 수십 개의 실험을 진행했습니다. 놀랍게도 많은 변경 사항이 우리의 지표를 후퇴시켰습니다. 초기의 정성적 분석에서 내린 많은 판단이 옳았다는 사실이 드러났습니다.
에이전틱 아키텍처
우리는 올가을 Bugbot을 완전한 에이전틱(agentic) 설계로 전환했을 때 가장 큰 성능 향상을 보았습니다. 에이전트는 diff를 추론하고, 도구를 호출하고, 고정된 일련의 패스를 따르지 않고 어디를 더 깊게 파고들지 결정할 수 있었습니다.
에이전틱 루프는 프롬프트팅에 대한 재고를 강제했습니다. 이전 버전의 Bugbot에서는 거짓 양성을 최소화하기 위해 모델을 억제할 필요가 있었습니다. 하지만 에이전틱 접근에서는 반대 문제가 나타났습니다. 너무 신중했던 것입니다. 우리는 에이전트가 의심스러운 패턴을 모두 조사하고 잠재적 이슈를 표시하는 쪽으로 기울이도록 독려하는 공격적인 프롬프트로 전환했습니다.
추가로, 에이전틱 아키텍처는 더 풍부한 실험 표면을 열어 주었습니다. 우리는 dynamic context로 더 많은 정보를 정적 컨텍스트에서 끌어내어, 모델이 사전에 받는 컨텍스트의 양을 조절하고 그에 따라 어떻게 적응하는지 관찰할 수 있었습니다. 모델은 런타임에 필요한 추가 컨텍스트를 일관되게 끌어오며, 사전에 모든 것을 제공할 필요가 없었습니다.
같은 설정은 우리로 하여금 도구 집합 자체를 직접 반복(iterate)하게 해줍니다. 모델의 행동은 호출 가능한 도구에 의해 형성되므로, 도구 설계나 가용성의 작은 변화도 결과에 과도한 영향을 미쳤습니다. 여러 차례의 반복을 통해, 우리는 그 인터페이스를 조정하고 정제하여 모델의 행동이 기대와 일관되게 맞춰지도록 했습니다.
What’s next
오늘날 Bugbot은 Rippling, Discord, Samsara, Airtable, Sierra AI 같은 고객들을 위해 한 달에 2백만 개 이상의 PR을 리뷰합니다. 우리는 Cursor의 모든 내부 코드에도 Bugbot을 운영하고 있습니다.
앞으로, 우리는 다른 제공자와 우리의 자체 학습 노력 모두로부터, 각기 다른 강점과 약점을 가진 새로운 모델들이 정기적으로 도착할 것으로 예상합니다. 지속적인 진전은 올바른 모델 조합, 하니스(harness) 설계, 리뷰 구조를 찾는 데 달려 있습니다. 오늘의 Bugbot은 출시 당시의 Bugbot보다 몇배의 개선을 이루었습니다. 몇 달 후에는 다시 상당히 더 나아질 것으로 기대합니다.
우리는 이미 그 미래를 향해 나아가고 있습니다. 우리는 방금 베타로 Bugbot Autofix를 출시했으며, 이는 PR 리뷰 중 발견된 버그를 자동으로 수정하기 위해 Cloud Agent를 스폰합니다. 다음 주요 기능은 Bugbot이 자체 버그 리포트를 검증하기 위해 코드를 실행할 수 있도록 하고, 복잡한 문제에 직면했을 때 심층 연구를 가능하게 하는 것입니다. 또한, 풀 리퀘스트를 기다리지 않고 코드베이스를 지속적으로 스캔하는 항상-온 버전도 실험하고 있습니다.