바이브코딩으로 혼자 짠 코드의 오류 잡는 Cusor Bugbot

퇴근하고 집에서 혼자 코드를 짜다 보면, 다 만든 걸 서버에 올리는 순간이 제일 불안해요. 개발에서는 이 '올리기'를 푸시(push)라고 불러요. 내 컴퓨터에서 작업한 코드를 다 같이 쓰는 서버로 밀어 올리는 걸 말하죠. 동료 리뷰어 없이 혼자 일하면 "이거 괜찮을까?" 싶어도 물어볼 사람이 없거든요. 게다가 자기가 짠 코드를 자기가 검토하는 건 누구에게나 약한 부분이에요. 의도한 대로 보이지, 실제로 뭘 썼는지는 잘 안 보이니까요.

그런데 2026년 6월, Cursor(커서, AI로 코드를 짜는 개발 도구)가 Bugbot 업데이트를 발표했어요. Bugbot(버그봇)은 커서가 만든 'AI 코드 리뷰어'예요. 단순한 띄어쓰기나 문법 오류가 아니라, 사람이 놓치기 쉬운 치명적인 논리 오류나 보안 구멍을 찾아주죠. 이번 업데이트로 리뷰 시간이 약 5분에서 약 90초로 3배 이상 빨라졌고, 실행당 비용은 약 22% 줄었으며, 버그 탐지는 약 10% 늘었다고 해요(모두 커서 자체 측정 기준). 전체 리뷰의 90%가 3분 안에 끝나고요.

여기서 핵심은 속도가 아니에요. 더 흥미로운 변화는 리뷰를 하는 '시점'이 바뀌었다는 점이에요. 원래 코드 리뷰는 PR 단계에서 했어요. PR(Pull Request)은 내가 고친 코드를 실제 서비스에 합쳐달라고 요청하는 단계인데, 보통 여기서 동료들이 코드를 보고 피드백을 줘요. 그런데 새로 추가된 `/review` 명령은 PR을 열기 전, 내 컴퓨터(로컬)에서 바로 돌릴 수 있어요. 같은 변경분(diff, 고치기 전과 후의 달라진 부분)으로 나중에 PR을 열면 Bugbot이 "이미 봤다"고 인식해서 중복 검토를 건너뛰고 기존 리뷰만 코멘트로 남겨줘요. 덕분에 중복 청구도 막히고, 올리기 전에 한 번 걸러낼 수 있는 흐름이 생긴 거예요.

코드 리뷰 시간 90초로 단축

5분과 90초는 도구를 쓰는 방식 자체를 바꾸거든요. 5분이면 기다리는 동안 딴 일 하다가 까먹고, 결국 코드를 올린 다음 Bugbot 댓글이 달릴 때까지 또 기다리게 되죠. 그런데 리뷰의 90% 이상이 3분 안에 끝나면, 코드를 저장하기 전에 그냥 내 컴퓨터에서 한 번 돌리고 넘어가는 흐름이 가능해져요.

빌더 입장에서는 작업 흐름이 짧아지는 게 핵심이에요. 원래는 "저장(커밋) → 올리기(푸시) → 합치기 요청(PR) → Bugbot 댓글 기다리기 → 수정 → 다시 올리기"라는 긴 루프를 돌았어요. 여기서 커밋은 "여기까지 작업 완료" 하고 내 컴퓨터에 중간 저장을 찍는 단계예요. 이 긴 루프가 이제 "수정하다가 `/review` → 바로 고치기 → 올리기"로 짧아져요. 리뷰어 없이 혼자 일하는 환경이라면 이 차이가 크게 느껴지죠.

이 속도 개선은 커서가 Composer 2.5라는 모델을 학습시키며 얻은 진전과, 하네스(harness, AI 도구가 작업을 처리하는 실행 틀) 개선에서 나왔다고 해요. 커서는 이 모델 학습을 Bugbot을 계속 개선하는 방법의 일부라고 밝혔어요.

`/review` 명령은 어떻게 쓰나요?

`/review`를 실행하면 Bugbot과 Security Review(보안 전용 검토) 중 무엇을 돌릴지 고를 수 있고, `/review-bugbot`이나 `/review-security`로 바로 특정 검토를 지정할 수도 있어요. 코드를 올리기 전에 문제를 잡아 고칠 수 있는 방법이죠.

`/review`는 GitHub·GitLab(코드를 보관하고 협업하는 대표적인 서비스)과도 연동돼요. 내 컴퓨터에서 `/review`로 점검한 변경분을 그대로 PR로 올리면 Bugbot이 "이미 리뷰했음"을 인식하고 중복 분석을 건너뛰어요. 보통은 `/review-bugbot`을 먼저 돌린 다음 같은 변경분으로 PR을 열어, 원격에서의 중복 리뷰를 건너뛰게 쓰는 식이에요.

커서 3.7 이상 버전과 cursor.com/agents에서 쓸 수 있고, 터미널에서 바로 쓰는 CLI 지원은 곧 나온다고 해요. 실제로 써보는 흐름은 이래요.

1. 내 컴퓨터에서 코드 작성 완료

2. 저장(커밋) 전에 `/review-bugbot` 실행

3. 약 90초 대기, Bugbot이 버그·보안 이슈를 보고

4. 지적받은 부분 바로 수정

5. 저장(커밋) → 올리기(푸시) → 합치기 요청(PR)

6. Bugbot이 "이미 리뷰함" 코멘트만 남기고 중복 청구 안 함

이 흐름은 동료 리뷰어가 없는 1인 빌더에게 "올리기 전 마지막 체크리스트" 역할을 해줘요.

10% 늘었다는 버그 탐지 및 해결율

Cursor 6월 릴리스 노트에 따르면 Bugbot은 기본(Default) 실행 기준으로 평균 0.62개의 버그를 찾습니다. 이전 0.56개에서 약 10% 늘어난 수치죠. 커서 발표에 따르면 출시 이후 40회 이상의 주요 실험으로 해결률(resolution rate)을 52%에서 70% 이상으로 끌어올렸어요. 해결률이란 Bugbot이 "여기 문제 있어요" 하고 지적했을 때 개발자가 실제로 코드를 고쳐서 반영한 비율이에요. 이 수치가 높다는 건, AI가 쓸데없는 잔소리를 안 하고 진짜 고쳐야 할 핵심만 잘 짚는다는 뜻이에요.

규모도 작지 않아요. 2026년 초 기준 Bugbot은 월 200만 건 이상의 합치기 요청(PR)을 처리하고, 출시 이후 100만 건 이상을 리뷰했으며, 150만 건의 잠재 이슈를 지적했고 그중 50% 이상이 코드 합쳐지기 전에 해결됐어요.

Bugbot이 찾는 건 단순한 문법 오류가 아니에요. 문법·형식 오류를 자동으로 잡아주는 도구를 린터(linter)라고 하는데, Bugbot은 린터와 달리 '논리 오류'를 봐요. 예를 들면 이런 것들이죠.

• null pointer 오류: 비어 있는(데이터가 없는) 상자를 열어 뭔가 꺼내려다 프로그램이 멈추는, 가장 흔한 버그

• 경쟁 조건(race condition): 여러 작업이 동시에 돌 때 순서가 꼬여 생기는 버그. 예를 들어 마지막 남은 상품 하나를 두 명이 동시에 결제하면 수량이 마이너스로 뚫리는 현상

• 누락된 에러 처리나 보안 구멍

코드를 글자 그대로만 보는 게 아니라 '의미'로 이해하기 때문에 가능한 일이에요. 다만 모든 버그를 잡아주진 않아요. Bugbot은 일부러 띄어쓰기·형식·사소한 문제엔 코멘트를 달지 않아서, 정확성·신뢰성·보안에 영향을 주는 이슈에만 집중시켜요. 그래서 잔소리가 적고 진짜 고쳐야 할 것만 알려준다는 평가를 받죠. 이 수치들은 커서 자체 측정이라 독립 검증은 아니지만, 월 200만 건 이상을 처리하는 도구가 공개한 값이라 실사용 데이터에 기반한 거예요.

비용이 22% 줄었다는데, 그래서 얼마들까?

커서 발표 기준으로 평균적인 Bugbot 실행은 코드 변경의 크기와 복잡도에 따라 실행당 약 $1.00~$1.50예요. 이건 22% 인하가 이미 반영된 현재 비용이에요. 커서는 인원수(좌석)에 따라 돈을 받던 요금제를 없애고, 쓴 만큼 내는 사용량 기반 과금으로 바꿨어요.

혼자 일하는 빌더라면 올리기 전 한 번, PR 한 번 이렇게 두 번 청구되는 걸 걱정할 수 있는데, 앞서 말했듯 같은 변경분이면 Bugbot이 중복 분석을 건너뛰고 기존 리뷰가 있다고 표시해줘요. 중복 청구 걱정은 안 해도 돼요.

사용량 기반으로 바뀌면서 리뷰에 얼마나 공들일지 단계(effort level, 노력 수준)도 고를 수 있게 됐어요. Default(기본)는 속도와 효율에 맞춰져 비용이 적지만 버그를 덜 찾을 수 있고, High(높음)는 더 오래 추론해서 비용·시간이 더 들지만 버그를 더 많이 찾아요. Cursor 5월 요금제 업데이트 발표에 따르면, 리뷰 강도를 High(높음)로 설정할 경우 기본(Default)보다 35% 더 많은 버그를 발견한다고 명시되어 있어요. 일상적인 작업엔 Default, 중요한 배포 전엔 High로 한 번 더 돌리는 식으로 조절하면 돼요.

혼자 작업하는 사람이`/review`를 돌려야 하는 이유

자기 코드를 자기가 리뷰하는 게 어려운 건 실력 문제가 아니라, 누구에게나 있는 인지적 편향 때문이에요. 팀이라면 코드 리뷰가 이걸 메워줘요. 다른 사람이 새로운 눈으로 보고 놓친 버그, 보안 구멍, 엣지 케이스를 잡아내죠. 엣지 케이스(edge case)는 평소엔 멀쩡하다가 아주 특이한 상황에서만 터지는 오류예요. 예를 들어 2월 29일 윤년에만 앱이 꺼지는 것처럼요.

혼자 일하는 빌더에겐 그 '다른 사람'이 없어요. 코드 변경이 크거나 급하면 작지만 중요한 버그를 놓치기 정말 쉬워요. 하나 차이로 어긋나는 실수(오프바이원), 특이 상황 로직, 미묘하게 비어 있는 데이터 처리 같은 것들이죠. 팀이 있으면 누군가 지적해주겠지만, 혼자라면 올리기 → 배포 → 버그 신고 → 긴급 수정이라는 긴 루프를 돌게 돼요.

앞으로 코드의 더 많은 부분을 AI가 쓰게 되면서, 리뷰 단계가 품질을 지키는 핵심 지점이 되고 있어요. 그리고 가장 비용이 싼 지점은 올리기 전이에요. 90초짜리 점검이 몇 달러로 평균 0.62개의 버그를 미리 잡아준다면, 그건 AI가 쓴 코드를 안전하게 내보내는 쪽과 사고가 난 뒤 수습하는 쪽을 가르는 작은 습관이 돼요.

실제로 한 엔지니어는 자신이 여는 모든 PR마다 Bugbot을 자동 리뷰어로 돌린다고 밝혔어요. 핵심은 이거예요. 코드를 쓴 AI가 그 코드를 다시 리뷰하면 같은 실수를 못 잡아요. 사람이든 AI든 자기가 만든 건 같은 착각으로 보거든요. 그래서 다른 AI의 눈으로 한 번 더 보는 게 의미가 있어요. 혼자 일하는 빌더에게 `/review`는 단순한 속도 개선이 아니라, "올리기 전에 다른 눈으로 한 번 더 보는 습관"을 만들어주는 루틴이에요. 동료 리뷰어가 없는 환경에서 이 차이는 곧 배포 안정성의 차이로 이어져요.

이전 Bugbot과 비교

이전 Bugbot은 코드를 올릴 때마다 PR 전체를 다시 리뷰했어요. 그러다 보니 이미 검토하고 승인했던 코드에도 새 지적이 달릴 수 있었죠. 이제는 마지막 리뷰 이후 바뀐 부분만 보도록 설정할 수 있어요. 이걸 Incremental Review(바뀐 부분만 다시 보는 모드)라고 하는데, 대시보드에서 켜면 피드백이 최신 변경에만 집중돼요.

종합하면 세 가지가 좋아졌어요. 속도는 3배 이상 빨라졌고, 비용은 22% 줄었고, 버그 탐지는 10% 늘었어요(모두 커서 자체 측정). 그리고 가장 큰 변화는 `/review`가 생기면서 리뷰 시점이 "합치기 요청을 연 뒤"에서 "올리기 전"으로 당겨진 거예요. 혼자 일하는 빌더라면 Bugbot 댓글을 기다리는 대신, 내 컴퓨터에서 바로 확인하고 고친 뒤 깔끔하게 올릴 수 있게 됐어요. 단순히 빨라진 게 아니라, 일하는 흐름 자체가 바뀐 거죠.

정리하면 이번 업데이트는 1인 빌더에게 "동료 리뷰어가 없어도 올리기 전에 한 번 더 점검할 수 있는 흐름"을 만들어줘요. 90초면 끝나고, 실행당 몇 달러 안 들고, 중복 청구도 막히고, 평균 0.62개의 버그를 미리 잡아내요. 퇴근 후 짧은 시간에 안전하게 마무리하고 싶은 빌더라면 지금 바로 써볼 만한 도구예요.

한 번 더, 빠르게 짚고 갈게요

Q. `/review`를 돌렸는데 아무 문제도 안 나왔으면 정말 안전한 건가요? A. Bugbot은 논리 오류·보안 이슈·엣지 케이스 중심으로 보고, 모든 버그를 잡진 않아요. 해결률이 70% 이상이라지만 나머지는 여전히 사람이 봐야 할 부분이거든요. `/review`는 "첫 번째 안전망"이지 마지막 점검은 아니에요.

Q. `/review-bugbot`과 `/review-security` 중 뭘 써야 하나요? A. 일상 작업엔 `/review-bugbot`으로 논리 버그를 체크하고, 민감한 데이터를 다루는 기능이나 배포 전엔 `/review-security`도 함께 돌리면 좋아요. `/review`만 쓰면 둘 중 뭘 돌릴지 선택 창이 뜨니, 상황에 맞게 고르면 돼요.

Q. 내 컴퓨터에서 `/review` 돌린 다음 PR 올리면 정말 중복 청구가 안 되나요? A. 같은 변경분(diff)으로 PR을 열면 Bugbot이 인식해서 중복 리뷰를 건너뛰고 "이미 리뷰했음" 코멘트만 달아요. 중복 청구는 안 되니 걱정 말고 먼저 돌려보세요.

Q. Default랑 High는 차이가 크나요? A. 커서 발표 기준으로 Default는 리뷰당 평균 0.7개, High는 0.95개의 버그를 찾아요. High가 더 꼼꼼하지만 시간·비용도 더 들어요. 일상엔 Default, 중요한 배포 전엔 High로 한 번 더 보는 식으로 나눠 쓰면 돼요.

Q. 커서를 안 쓰는 사람도 Bugbot만 따로 쓸 수 있나요? A. Bugbot은 GitHub·GitLab의 PR에 자동으로 붙는 리뷰어로 쓸 수 있어요. 다만 `/review` 명령은 커서 3.7 이상이나 cursor.com/agents에서만 되고, 터미널용 CLI는 곧 나온다고 해요. 내 컴퓨터에서 미리 돌리는 기능을 원하면 커서 설치가 필요해요.