AI 코딩 도구를 ‘코드 자동완성’으로 이해하면 지금 벌어지는 변화를 놓친다. Cursor(커서)의 최근 발표—더 빠른 모델 Composer 1.5, 자동 코드 검토 Bugbot, 런타임 로그를 읽는 Debug Mode, 사람 손을 떠나 백그라운드에서 도는 클라우드 Agent—를 신기능 목록으로 훑으면 남는 게 없다. 이 글은 기능 소개 대신, 이 도구들이 왜 하필 이 방향으로 몰려가는지, 그리고 도입을 저울질하는 개발자·팀이 계약서에 서명하기 전 실제로 확인해야 할 것이 무엇인지를 다룬다. 결론부터 말하면, 자동화가 늘수록 줄어드는 건 타이핑이고 늘어나는 건 검수·비용 관리·책임 판단이다.
‘줄’이 아니라 ‘task’가 작업 단위가 됐다
1세대 AI 코딩의 단위는 커서 위치 기준 다음 몇 줄을 예측하는 자동완성이었다. 하지만 현업에서 ‘한 파일의 다음 줄’로 끝나는 작업은 드물다. 함수 시그니처 하나를 바꾸면 호출부 대여섯 곳, 관련 테스트, 타입 정의가 연쇄로 움직인다. Composer 1.5가 ‘더 똑똑한 자동완성’이 아니라 ‘빠르고 넓게 맥락을 보는 에이전트’로 홍보되는 이유가 여기 있다. 본질은 모델이 몇 점 더 똑똑해졌는지가 아니라, 작업 단위가 ‘줄(line)’에서 ‘작업(task)’으로 한 계단 커졌다는 사실이다.
문제는 단위가 커진 만큼 실패 비용도 커진다는 점이다. 자동완성은 틀리면 한 줄 지우면 끝이지만, 에이전트가 5개 파일을 수정하고 테스트까지 손댔다면 그 diff 전체를 사람이 다시 읽어야 한다. 초보자가 가장 자주 착각하는 지점이 이것이다. 현실은 ‘에이전트가 알아서 해준다’가 아니라 ‘에이전트가 만든 결과를 검수하는 새 업무가 생긴다’에 가깝다. 그래서 매 작업마다 세 가지를 습관으로 확인해야 한다. 첫째, 지시 범위를 ‘한 번에 한 기능’으로 좁혔는가—막연히 ‘리팩터링해줘’라고 던지면 검토 불가능한 크기의 diff가 돌아온다. 둘째, 자동 커밋을 끄고 변경분을 눈으로 훑었는가. 셋째, 테스트가 ‘통과했다는 말’이 아니라 실제 실행 로그로 통과를 확인했는가. 이 세 가지를 건너뛰면 생산성은 착시일 뿐이다.
Composer 1.5·Bugbot: ‘버그 더 잡는다’만 보면 반쪽짜리 판단
Bugbot(버그봇) 개선 발표는 이런 도구들이 어떤 축으로 경쟁하는지 압축해서 보여준다. 강조된 지표는 셋이었다. 검토 속도 약 3배 이상 향상, 비용 약 22% 절감, 발견 버그 약 10% 증가. 눈여겨볼 대목은 ‘더 많은 버그’를 단독으로 내세우지 않고 속도·비용을 나란히 붙였다는 점이다. 코드 리뷰 자동화는 정확도만으로 채택되지 않는다. PR마다 검토가 2분씩 걸리면 개발 흐름이 끊기고, 검토 비용이 팀 예산을 넘으면 아무리 잘 잡아도 못 쓴다. ‘속도 3배’는 벤치마크 자랑이 아니라 ‘리뷰가 개발 리듬을 끊지 않는 선까지 내려왔다’는 실용적 신호로 읽어야 한다.
다만 수치는 반드시 맥락과 함께 해석해야 한다. ‘버그 10% 더 발견’은 이전 버전 대비 상대치이지, ‘전체 버그의 몇 %를 잡는다’는 절대 커버리지가 아니다. 자동 검토는 널 체크 누락, 명백한 논리 오류, 흔한 안티패턴은 잘 걸러내지만, ‘이 상태에서 이 값이 이렇게 흘러가면 안 된다’ 같은 도메인 판단은 여전히 사람 몫이다. 그래서 기대치를 둘로 쪼개 세워야 한다—자동화가 대체하는 건 ‘기계적 1차 스크리닝’이고, 대체하지 못하는 건 ‘설계·도메인 맥락 리뷰’다. 비용 22% 절감도 함정이 있다. 단가가 22% 내려가도 팀이 자동 검토를 더 자주 돌리면 월 총액은 오히려 오른다. 절감률이라는 상대 지표가 아니라 ‘지난달 실제 청구액 대비 이번 달 얼마’라는 절대 금액으로 봐야 예산이 새지 않는다.
Debug Mode: ‘코드를 읽는 AI’에서 ‘실행을 보는 AI’로
Debug Mode(디버그 모드)가 의미 있는 건 화려해서가 아니라, AI가 정적 소스코드가 아니라 실행 중 쌓이는 런타임 로그를 근거로 원인을 좁힌다는 점 때문이다. 기존 AI는 코드를 ‘읽고’ 무엇이 잘못됐을지 추측했다. 그런데 실무 버그의 상당수는 코드만 봐서는 보이지 않는다. 특정 입력값, 특정 호출 순서, 특정 배포 환경에서만 재현되는 문제가 그렇다. 로그를 함께 읽는다는 건 ‘가정’이 아니라 ‘증거’로 원인을 특정한다는 뜻이고, 이는 디버깅에서 가장 시간을 잡아먹는 ‘재현과 원인 특정’ 구간을 정확히 겨냥한다.
하지만 이 기능은 조건부로만 이득을 준다. 확인할 체크포인트는 둘이다. 첫째, 로그에 민감정보가 섞이는가. 사용자 이메일, 인증 토큰, 내부 URL이 그대로 로그에 찍히는 팀이라면, 그 로그를 AI에 넘기는 순간 데이터 유출 경로가 하나 늘어난다. 도입 전에 로그 마스킹·필터링 규칙부터 점검해야 한다. 둘째, 결과가 로그 품질에 좌우된다. 스택 트레이스와 컨텍스트가 부실하면 AI도 추론할 재료가 없다. 흔한 오해는 ‘AI가 알아서 버그를 잡아준다’지만, 실제로는 ‘관측 가능성(observability)이 좋은 코드일수록 AI 디버깅이 잘 먹힌다’는 역설이 작동한다. 즉 이 기능의 효용을 끌어올리는 선행 조건은 AI가 아니라 ‘사람이 로그를 잘 남기는 습관’이다.
클라우드 Agent: 자동화가 늘수록 커지는 통제·비용·책임
마지막 흐름은 에이전트가 로컬 에디터를 벗어나 클라우드 백그라운드에서 도는 방향이다. 노트북을 닫아도 서버에서 작업이 이어지고 여러 작업을 병렬로 굴릴 수 있다는 점은 분명 매력적이다. 그런데 이런 시스템을 만든 팀들이 공통으로 꼽는 교훈은 성능 자랑이 아니라 ‘통제의 어려움’이다. 사람이 실시간으로 지켜보지 않는 상태의 자동 수정은, 방향을 한 번 잘못 잡으면 오류가 조용히 누적된다. 그래서 실전에서는 격리된 실행 환경, 최소 권한 범위, 결과를 사람이 승인하는 게이트가 선택이 아니라 필수가 된다.
비용과 책임도 성격이 달라진다. 로컬 자동완성은 대체로 인당 정액 구독에 가깝지만, 클라우드에서 상시 도는 에이전트는 실행량에 비례하는 변동비가 붙는다. 6개월~2년 관점에서 보면 팀 예산에 ‘개발자 1인당 구독료’와 별개로 ‘에이전트 실행량 기반 변동비’라는 항목이 새로 들어올 가능성이 크다—실행 상한과 알림 없이 두면 청구서가 예고 없이 튀는 구조다. 여기에 책임 문제가 겹친다. 에이전트가 짠 코드가 장애를 냈을 때 책임은 여전히 그 코드를 머지한 사람과 팀에 있다. 자동화가 늘어난다고 검토·테스트·유지보수 부담이 사라지는 게 아니라, ‘무엇을 어디까지 자동에 맡길지 선을 긋는 판단’이 새 핵심 역량으로 올라선다. 도입을 고민한다면 기능 비교표보다, 이 선긋기 기준을 팀 안에서 먼저 합의하는 것이 순서다.
자주 묻는 질문
Cursor의 Composer, Bugbot, Debug Mode는 각각 무슨 역할인가요?
Composer는 여러 파일에 걸친 코드 변경을 한 번에 수행하는 에이전트형 기능이고, Bugbot은 PR 같은 코드 변경을 자동으로 검토해 버그를 찾아줍니다. Debug Mode는 소스코드만 보는 게 아니라 실행 중 발생하는 런타임 로그를 근거로 원인을 추론하는 디버깅 기능입니다. 각각 ‘작성’, ‘검토’, ‘디버깅’ 단계를 자동화한다는 점에서 역할이 갈립니다.
Bugbot이 ‘버그를 10% 더 찾는다’는 게 대부분의 버그를 잡는다는 뜻인가요?
아닙니다. 10%는 이전 버전 대비 상대적 증가치일 뿐, 전체 버그의 특정 비율을 잡는다는 절대 커버리지가 아닙니다. 널 체크 누락이나 흔한 안티패턴은 잘 걸러내지만, 도메인·비즈니스 로직 판단이 필요한 문제는 여전히 사람 리뷰가 필요합니다. 자동 검토를 1차 스크리닝으로 두고 설계·맥락 리뷰는 사람이 맡는 구성이 현실적입니다.
클라우드 Agent를 쓰면 비용이 얼마나 늘 수 있나요?
정확한 금액은 사용량에 따라 다르지만 구조가 로컬과 다릅니다. 로컬 기능은 인당 정액 구독에 가깝지만, 클라우드에서 상시 도는 에이전트는 실행량에 비례하는 변동비가 붙습니다. 절감률 같은 상대 지표보다 ‘지난달 대비 이번 달 실제 청구액’을 기준으로 보고, 실행량 상한과 승인 게이트를 함께 설정해 비용 급증을 막아야 합니다.
Debug Mode가 로그를 읽으면 보안 문제는 없나요?
로그에 이메일·인증 토큰·내부 URL 같은 민감정보가 담겨 있다면, 그 로그를 AI가 읽는 과정 자체가 새 유출 경로가 될 수 있습니다. 도입 전 로그 마스킹·필터링 규칙이 있는지 먼저 점검하세요. 또 로그 품질이 낮으면 AI 추론 근거도 부실해지므로, 관측 가능성을 좋게 유지하는 것이 보안과 효용 양쪽에 이득입니다.
AI 에이전트가 코드를 자동으로 짜주면 리뷰 부담이 줄어드나요?
오히려 검토의 성격이 바뀝니다. 자동완성은 틀려도 한 줄 지우면 되지만, 에이전트는 여러 파일을 한 번에 수정하므로 diff 전체를 사람이 읽어야 합니다. 자동 커밋을 끄고 변경 범위를 ‘한 번에 한 기능’으로 좁게 지시하며, 테스트가 실제 로그로 통과했는지 확인하는 습관이 필요합니다. 자동화가 늘수록 ‘무엇을 자동에 맡기고 무엇을 사람이 검토할지 선을 긋는 판단’이 더 중요해집니다.