자동완성과 에이전트는 ‘정도’가 아니라 ‘종류’가 다르다
Cursor를 아직 ‘VS Code에 AI 자동완성이 얹힌 편집기’로 기억한다면, 지금 제품과는 한 세대 차이가 난다. 초기 핵심은 다음 줄을 예측해 주는 탭 완성이었다. 하지만 최근 공개 자료들이 공통으로 가리키는 신호는 ‘에이전트(agent) 사용 비중의 증가’다. 자동완성은 개발자가 타이핑하는 손끝을 거드는 도구이고, 에이전트는 ‘이 기능 만들어줘’라는 지시를 받아 여러 파일을 스스로 열고 읽고 고치고 실행까지 시도하는 대리자다. 둘의 차이는 성능의 정도가 아니라 상호작용의 종류가 바뀐 것이다. 사람이 ‘추천을 받아 채택’하던 관계에서, ‘작업 단위를 통째로 위임하고 결과를 검수’하는 관계로 넘어갔다.
이 구분이 중요한 이유는 실패의 비용이 달라지기 때문이다. 자동완성은 틀려도 한 줄 지우면 그만이지만, 에이전트가 10개 파일을 건드린 뒤 방향이 어긋나면 어디서부터 잘못됐는지 되짚는 비용이 훨씬 크다. 그래서 도입의 첫 질문은 ‘얼마나 똑똑한가’가 아니라 ‘어디까지 위임하고 어디에 사람 검토 게이트를 두는가’다. 최소 세 가지를 확인해야 한다. (1) 에이전트가 터미널 명령을 사람 승인 없이 자동 실행하도록 열어둘지(예: rm이나 배포 스크립트까지 자동승인하면 사고 위험이 급등한다), (2) 모든 변경을 diff로 먼저 보여주고 승인받는지, (3) 체크포인트나 커밋 단위 되돌리기가 촘촘한지다. 흔한 오해는 ‘에이전트를 켜면 알아서 다 해준다’는 것인데, 현장 경험이 쌓인 사용자일수록 작업을 파일 서너 개·기능 하나 단위로 잘게 쪼개고 매 단계 검수를 붙인다. 위임 범위가 넓을수록 똑똑해지는 게 아니라, 검수 가능한 크기로 쪼갤수록 성공률이 오른다.
자체 모델 Composer 2: 편집기 회사가 모델을 직접 만드는 이유
Cursor는 ‘Composer’ 계열 자체 코딩 모델을 내놓고 기술 보고서(Composer 2)까지 공개했다. 그동안 대다수 AI 코딩 도구는 외부 상용 LLM을 API로 빌려 쓰는 구조였는데, 편집기 회사가 코딩 특화 모델을 직접 학습·운영하겠다는 결정에는 세 가지 동기가 겹친다. 첫째는 지연 시간(latency)이다. 에이전트는 한 번의 지시로 모델을 여러 번 왕복 호출한다. 왕복 한 번에 몇 초가 붙으면 열 번이면 체감 대기가 감당 안 되므로, 반복 편집 루프에서는 ‘똑똑함’보다 ‘빠른 응답’이 실사용성을 가른다. 둘째는 비용·마진 통제다. 외부 API 단가에 원가가 묶이면 요금 정책의 손발이 묶인다. 셋째는 코드 편집과 도구 호출(파일 읽기, 명령 실행) 같은 특정 동작에 모델을 좁게 최적화할 수 있다는 점이다.
모델 학습에는 대규모 연산 인프라가 필요하고, Cursor가 SpaceX와 협력해 학습 인프라를 확보한다는 소식은 그 경쟁의 단면을 보여준다. 다만 여기서 기대와 실제를 분리해야 한다. ‘자체 모델 보유’가 곧 ‘모든 범용 모델보다 우수’를 뜻하지는 않는다. 반복적 코드 편집·빠른 수정에서 속도·비용 균형이 좋은 것과, 복잡한 아키텍처 설계나 까다로운 추론 전반에서 최고 성능인 것은 별개 문제다. 실무자가 세울 판단 기준은 단순하다. 내 작업이 ‘패턴 반복형 편집’ 위주면 자체 모델이 유리하고, ‘어려운 설계·디버깅’ 위주면 범용 최상위 모델이 유리할 때가 많다. 그리고 도구 안에서 작업별로 모델을 갈아 끼울 수 있는지를 확인해야 한다. 가장 흔한 함정은 ‘하나의 모델로 전부 해결’하려는 태도다. 기본값은 저비용·고속 모델로 두고, 막히는 순간에만 고성능 모델로 수동 승격하는 이원화가 속도와 비용을 동시에 잡는다.
실제 성과는 ‘멋진 신규 개발’이 아니라 ‘지루한 대규모 반복’에서 나온다
마케팅 문구보다 신뢰할 만한 근거는 대형 조직의 실제 사용 맥락이다. 오스트레일리아의 대형 은행 NAB(National Australia Bank)가 Cursor로 레거시 마이그레이션을 가속했다는 사례가 대표적이다. 여기서 배울 점은 도구의 화려함이 아니라 ‘어디서 값이 나는가’다. AI 코딩은 창의적 신규 기능보다, 패턴은 반복되지만 사람이 하기엔 지치고 실수가 잦은 작업에서 먼저 성과를 낸다. 구식 언어·프레임워크로 짜인 수만~수십만 줄을 최신 스택으로 옮기는 일이 정확히 그렇다. 규칙은 비슷하게 반복되지만 물량이 방대해 사람 손으로는 집중력이 무너진다. 에이전트가 파일 단위 변환 초안을 만들고 사람이 검증하는 분업이 잘 들어맞는 영역이다.
두 번째 축은 코드 리뷰 자동화, 즉 리뷰 봇 ‘Bugbot’의 강화다. PR(변경 요청) 단계에서 사람이 놓치기 쉬운 버그·회귀를 걸러주는 방향은, AI의 역할이 ‘코드를 쓰는 것’에서 ‘코드를 검증하는 것’으로도 넓어지고 있음을 보여준다. 실무 체크포인트는 두 갈래로 정리된다. 마이그레이션이라면 (1) 자동 변환 뒤 테스트 통과율을 지표로 삼아 ‘괜찮아 보인다’는 감이 아니라 숫자로 판단하고, (2) 전체를 한 번에 바꾸지 말고 모듈 단위로 쪼개 롤백 경로를 확보하며, (3) 변환 규칙을 문서로 남겨 사람이 재현·검토할 수 있게 해야 한다. 리뷰 봇이라면 ‘봇이 지적한 것’뿐 아니라 ‘봇이 놓쳐서 사람이 잡은 것’까지 함께 집계해 정확도와 놓침률을 정량화해야 한다. 여기서 가장 위험한 오해는 ‘AI 리뷰가 생겼으니 사람 리뷰를 줄여도 된다’는 판단이다. 현 단계 리뷰 봇은 사람 리뷰의 대체가 아니라, 명백한 실수를 먼저 걸러 사람의 집중력을 아껴 주는 1차 필터로 두는 편이 안전하다. 신뢰가 데이터로 쌓인 뒤에 위임 범위를 조금씩 넓히는 순서가 맞다.
도입 판단은 기능이 아니라 비용·보안·책임에서 갈린다
기능이 좋아 보여도 조직 도입은 별개의 결정이다. 첫째는 비용 구조다. 에이전트는 자동완성과 원가 자체가 다르다. 지시 한 번이 내부적으로 여러 번의 모델 호출과 파일 읽기·재시도를 유발하기 때문에, 요금제가 ‘월 정액 + 사용량 초과 과금’ 형태로 진화하는 배경이 여기에 있다. 그래서 도입 전에는 3~4주 파일럿으로 ‘개발자 1인당 하루 평균 에이전트 호출·토큰 소비’를 실측한 뒤 ‘인원 × 근무일’로 월 비용을 추정하고, 특정 헤비 유저에게 사용량이 몰릴 때를 대비해 상한선과 알림을 걸어야 한다. 앞서 말한 모델 이원화(기본은 저비용 자체 모델, 어려운 작업만 고성능 모델)는 총비용을 크게 흔드는 정책 레버다. 비용이 예산을 넘겼다는 사후 청구서를 받기 전에, 사용량이 곧 비용이라는 사실을 팀에 명시적으로 공유해야 한다.
둘째는 보안과 책임이다. 소스코드는 회사의 핵심 자산이자 잠재적 유출 경로다. 최소한 (1) 코드가 모델 학습에 쓰이지 않도록 하는 프라이버시 모드 제공 여부, (2) 데이터 보관·삭제 정책과 전용·격리 배포 옵션, (3) 금융·의료 같은 규제 산업에서 요구되는 감사 추적을 확인해야 한다. NAB 같은 규제 조직이 도입했다는 사실은 이런 옵션이 존재한다는 방증이지만, 그 조건이 내 조직이 계약할 요금제·플랜에도 동일하게 적용되는지는 별도로 확인해야 한다. 엔터프라이즈 플랜의 보안 조항이 개인·팀 플랜에는 없을 수 있기 때문이다. 마지막은 책임이다. 에이전트가 만든 코드의 버그·라이선스 위반·보안 취약점에 대한 최종 책임은 여전히 사람과 조직에 있다. 6개월~2년 관점에서 현실적인 그림은 ‘AI가 개발자를 대체’가 아니라, 반복 작업은 에이전트가 초안을 만들고 사람은 설계·검증·책임을 맡는 역할 재분배다. 도입의 성패는 결국 도구의 성능 지표가 아니라, 이 분업과 검토 프로세스를 얼마나 촘촘히 설계하느냐에서 갈린다.
자주 묻는 질문
Cursor는 그냥 VS Code에 확장 프로그램 깐 것과 무엇이 다른가요?
Cursor는 VS Code 기반 위에 AI를 편집기 코어 수준으로 통합한 도구입니다. 단순 자동완성을 넘어 여러 파일을 스스로 읽고 수정·실행까지 시도하는 에이전트, 자체 코딩 모델(Composer 계열), PR 단계 리뷰 봇(Bugbot)이 핵심 차이입니다. 확장 몇 개로 흉내 내기 어려운 지점은 개별 기능이 아니라 ‘작업 단위 위임과 검수’에 맞춰 재설계된 워크플로 전체입니다.
자체 모델(Composer)과 외부 대형 모델 중 무엇을 써야 하나요?
작업 성격으로 나누는 것이 실용적입니다. 반복적 코드 편집·빠른 수정처럼 속도와 비용이 중요한 작업은 자체 모델(Composer 계열)이 유리하고, 복잡한 아키텍처 설계나 까다로운 디버깅이 핵심이면 범용 최상위 모델이 유리한 경우가 많습니다. 하나로 통일하기보다, 기본값은 저비용·고속 모델로 두고 막힐 때만 고성능 모델로 수동 승격할 수 있는지 확인하세요.
레거시 코드 마이그레이션에 정말 효과가 있나요?
패턴이 반복되는 대규모 변환 작업에서 특히 값을 내는 것으로 보고됩니다(예: 은행권 레거시 전환 사례). 다만 자동 변환 초안을 사람이 검증하는 분업이 전제입니다. 전체를 한 번에 바꾸지 말고 모듈 단위로 나눠 테스트 통과율을 지표로 삼고, 롤백 경로를 확보한 채 진행하는 것이 안전합니다.
AI 코드 리뷰 봇이 있으면 사람 리뷰를 줄여도 되나요?
현 단계에서는 권장되지 않습니다. Bugbot 같은 리뷰 봇은 명백한 실수를 먼저 걸러 사람의 집중력을 아껴 주는 1차 필터로 두고, 최종 검토는 사람이 유지하는 편이 안전합니다. 봇이 지적한 것과 놓친 것을 함께 집계해 정확도·놓침률을 데이터로 쌓은 뒤 위임 범위를 점진적으로 넓히세요.
기업이 Cursor를 도입할 때 가장 먼저 봐야 할 리스크는 무엇인가요?
비용과 보안입니다. 에이전트는 지시 한 번이 여러 번의 모델 호출을 유발해 사용량 기반 비용이 빠르게 늘 수 있으므로, 3~4주 파일럿으로 1인당 소비를 실측해 예산을 추정하고 상한을 두세요. 보안은 코드가 학습에 쓰이지 않도록 하는 프라이버시 모드, 데이터 보관·격리 배포 정책, 규제 산업의 감사 추적 지원 여부를 계약할 플랜 기준으로 확인해야 합니다.