더 나은 Bugbot 만들기
코딩 에이전트가 점점 더 강력해지면서, 우리는 코드 리뷰에 더 많은 시간을 쓰고 있다는 것을 깨달았습니다. 이를 해결하기 위해, 프로덕션에 들어가기 전에 PR에서 로직 버그, 성능 문제, 보안 취약점을 분석하는 코드 리뷰 에이전트 Bugbot을 만들었습니다. 지난여름쯤에는 성능이 충분히 좋아졌다고 판단해, 이를 사용자에게 공개하기로 했습니다.
Bugbot을 만드는 과정은 초기의 정성적 평가에서 시작해, 맞춤형 AI 기반 지표를 활용해 품질을 점진적으로 끌어올리는(hill-climbing) 보다 체계적인 접근 방식으로 발전해 갔습니다.
출시 이후 우리는 40개의 주요 실험을 진행해 Bugbot의 해결 비율을 52%에서 70% 이상으로 끌어올렸고, 실행당 평균 발견 버그 수는 0.4개에서 0.7개로 늘렸습니다. 이는 PR당 해결되는 버그 수가 대략 0.2개에서 약 0.5개로, 두 배 이상 증가했다는 의미입니다.
소박한 시작
처음 코드 리뷰 Agent를 만들려고 했을 때는 모델 성능이 충분하지 않아, 리뷰가 크게 도움이 되지 않았습니다. 하지만 베이스라인 모델이 개선되면서, 버그 리포트의 품질을 높일 수 있는 여러 가지 방법이 있다는 것을 깨달았습니다.
우리는 모델, 파이프라인, 필터, 컨텍스트 관리 전략의 다양한 조합을 실험했고, 그 과정 내내 내부 엔지니어들을 대상으로 계속 의견을 수집했습니다. 어떤 설정이 거짓 양성(false positive)이 더 적어 보이면 그 설정을 채택했습니다.
초기에 찾은 가장 효과적인 품질 향상 방법 중 하나는, 여러 번의 버그 탐지 패스를 병렬로 실행하고 그 결과를 다수결로 결합하는 것이었습니다. 각 패스에는 서로 다른 순서의 diff가 전달되었고, 이는 모델이 서로 다른 추론 경로를 따르도록 유도했습니다. 여러 패스가 독립적으로 같은 이슈를 지적하면, 우리는 그 버그가 실제일 가능성이 더 높다는 강한 신호로 간주했습니다.
수 주에 걸친 내부 정성적 실험과 반복을 거쳐, 우리는 시장의 다른 코드 리뷰 도구들을 능가하면서도 출시할 만하다는 확신을 주는 Bugbot 버전에 도달했습니다. 이 버전은 다음과 같은 플로우를 사용했습니다:
- 무작위화된 diff 순서로 8개의 병렬 패스 실행
- 유사한 버그를 하나의 버킷으로 묶기
- 한 번의 패스에서만 발견된 버그를 걸러내기 위한 다수결 투표
- 각 버킷을 하나의 명확한 설명으로 병합
- 컴파일러 경고나 문서 오류 같은 원치 않는 카테고리 필터링
- 거짓 양성을 잡기 위해 검증용 모델을 통해 결과 재검사
- 이전 실행에서 이미 보고된 버그와의 중복 제거
프로토타입에서 프로덕션까지
Bugbot을 실사용 가능한 수준으로 만들기 위해, 핵심 리뷰 로직과 더불어 여러 기초 시스템에 투자해야 했습니다. 여기에는 Git 통합을 Rust로 다시 구현해 리포지토리 접근을 빠르고 안정적으로 만들고 가져오는 데이터 양을 최소화하는 일, 그리고 GitHub의 제약 안에서 동작할 수 있도록 요청 속도 제한(rate limit) 모니터링, 요청 배치, 프록시 기반 인프라를 추가하는 작업이 포함되었습니다.
도입이 늘어나면서, 팀들은 위험한 마이그레이션이나 내부 API의 잘못된 사용처럼 코드베이스별로 달라지는 불변 조건을 규칙으로 표현해 둘 방법도 필요했습니다. 이에 우리는 그런 검사를 시스템에 하드코딩하지 않고도 지원할 수 있도록 Bugbot rules를 추가했습니다.
이 요소들이 모여 Bugbot을 실제 코드베이스에 적용 가능하고 운영 가능한 도구로 만들어 주었습니다. 하지만 이것만으로는 품질이 실제로 향상되고 있는지 알 수 없었습니다. 진행 상황을 측정할 수 있는 지표가 없으면, 실제 환경에서의 Bugbot 성능을 정량적으로 평가할 수 없고, 이는 우리가 Bugbot을 얼마나 더 발전시킬 수 있는지에 상한을 만들어 버립니다.
중요한 것 측정하기
이 문제를 해결하기 위해 우리는 해결률(resolution rate)이라는 지표를 고안했습니다. 이 지표는 PR이 머지될 때 AI를 사용해 최종 코드에서 실제로 어떤 버그가 작성자에 의해 해결되었는지를 판단합니다. 이 지표를 개발하는 과정에서 우리는 내부적으로 모든 예시를 PR 작성자와 함께 샘플링해 검증했으며, LLM이 거의 모든 사례를 “해결됨/해결되지 않음”으로 정확하게 분류한다는 것을 확인했습니다.
팀들은 종종 Bugbot이 자신들에게 어떤 영향을 주고 있는지 어떻게 평가해야 하는지 묻기 때문에, 우리는 이 지표를 대시보드에 눈에 잘 띄게 노출하고 있습니다. 효과를 평가하는 팀 입장에서는, 이 지표가 댓글에 달린 반응이나 주관적인 피드백보다 훨씬 더 명확한 신호가 됩니다. 해결률은 Bugbot이 엔지니어들이 실제로 고친 실제 이슈를 찾아내고 있는지를 직접적으로 보여줍니다.
힐클라이밍
해결률을 정의한 것은 우리가 Bugbot을 만드는 방식을 근본적으로 바꾸어 놓았습니다. 이제 처음으로, 단순한 감이 아니라 실제 신호를 바탕으로 힐클라이밍을 할 수 있게 되었습니다. 우리는 실제 해결률을 기반으로 온라인에서 변경 사항을 평가하고, 사람이 버그를 주석으로 표시해 둔 실제 코드 diff로 구성된 정제된 벤치마크인 BugBench를 활용해 오프라인 평가를 진행하기 시작했습니다.
우리는 모델, 프롬프트, 반복 횟수, 검증기, 컨텍스트 관리, 카테고리 필터링, 그리고 에이전트 기반 설계 전반에 걸쳐 수십 가지 실험을 수행했습니다. 놀랍게도 많은 변경 사항이 우리의 지표를 되레 악화시켰습니다. 초기 정성 분석에서 내렸던 판단들 상당수가 실제로 옳았다는 사실이 드러났습니다.
에이전트 기반 아키텍처
올가을 Bugbot을 완전히 에이전트 기반 설계로 전환했을 때 가장 큰 성과를 얻었습니다. 에이전트는 diff를 검토해 추론하고, 도구를 호출하며, 고정된 여러 단계의 순서를 따르기보다 어디를 더 깊이 파고들지 스스로 결정할 수 있게 되었습니다.
에이전트 루프를 도입하면서 프롬프트를 완전히 다시 고민해야 했습니다. 초기 버전의 Bugbot에서는 거짓 경보(false positive)를 최소화하기 위해 모델을 최대한 제약해야 했습니다. 하지만 에이전트 기반 접근으로 전환하자 정반대 문제가 나타났습니다. 지나치게 조심스러웠던 것입니다. 우리는 에이전트가 의심스러운 패턴을 모두 조사하고, 잠재적인 문제를 과감하게 표시하도록 유도하는 공격적인 프롬프트로 전환했습니다.
또한 에이전트 아키텍처는 훨씬 더 풍부한 실험 공간을 열어 주었습니다. 정적인 컨텍스트에 두던 정보를 dynamic context로 옮겨, 모델이 처음에 받는 컨텍스트 양을 달리하고 그에 어떻게 적응하는지 관찰할 수 있었습니다. 모델은 실행 시점에 필요한 추가 컨텍스트를 일관되게 스스로 가져왔고, 모든 정보를 미리 제공할 필요가 없었습니다.
같은 설정 덕분에 도구 세트 자체도 직접 반복 개선할 수 있었습니다. 모델의 행동이 호출 가능한 도구들에 의해 좌우되기 때문에, 도구 설계나 제공 여부의 작은 변화만으로도 결과에 큰 영향을 미쳤습니다. 여러 차례의 반복을 거치며 우리는 그 인터페이스를 조정하고 다듬어, 결국 모델의 행동이 우리의 기대와 일관되게 맞춰지도록 만들었습니다.
앞으로의 계획
현재 Bugbot은 Rippling, Discord, Samsara, Airtable, Sierra AI와 같은 고객을 위해 한 달에 200만 개가 넘는 PR을 리뷰하고 있습니다. 또한 Cursor의 모든 내부 코드에도 Bugbot을 적용하고 있습니다.
앞으로는 다양한 강점과 약점을 가진 새로운 모델들이, 다른 제공사로부터도, 그리고 저희가 직접 학습한 모델들로부터도 꾸준히 등장할 것으로 예상하고 있습니다. 지속적인 발전을 위해서는 적절한 모델 조합, 하네스(harness) 설계, 리뷰 구조를 찾아야 합니다. 현재의 Bugbot은 출시 당시의 Bugbot보다 몇 배 더 뛰어나며, 앞으로 몇 달 안에 다시 한 번 크게 향상될 것으로 보고 있습니다.
우리는 이미 그런 미래를 향해 나아가고 있습니다. 최근 PR 리뷰에서 발견된 버그를 자동으로 수정하기 위해 Cloud Agent를 자동으로 실행하는 기능인 Bugbot Autofix를 Beta로 출시했습니다. 다음 주요 기능으로는 Bugbot이 자신의 버그 리포트를 검증하기 위해 직접 코드를 실행할 수 있도록 하는 것과, 복잡한 이슈를 만났을 때 심층적인 조사를 수행할 수 있도록 하는 것이 포함되어 있습니다. 또한, PR을 기다리는 대신 코드베이스를 지속적으로 스캔하는 상시 동작 버전도 실험 중입니다.
지금까지 우리는 Lee Danilek, Vincent Marti, Rohan Varma, Yuri Volkov, Jack Pertschuk, Michiel De Jong, Federico Cassano, Ravi Rahman, Josh Ma 등 핵심 팀원들의 기여가 없었다면 불가능했을 큰 진전을 이뤄 왔습니다. 함께, 저희의 목표는 앞으로도 여러분의 AI 개발 워크플로가 확장되더라도 팀이 코드 품질을 유지할 수 있도록 돕는 것입니다.