자동완성은 이제 기본값이다: Cursor가 방향을 튼 이유
Cursor(커서) 최근 업데이트를 한자리에 모아 보면 개별 기능 발표가 아니라 한 방향의 신호로 읽힙니다. 플러그인 마켓플레이스, CLI 에이전트, 클라우드 핸드오프, 비동기 서브에이전트, 자체 모델(Composer) 개선이 짧은 간격에 겹쳐 나온다는 점입니다. 공통점은 ‘문장을 더 잘 이어 쓰는’ 것과 무관하다는 데 있습니다. 전부 AI가 접근할 도구, 실행 위치, 권한 경계를 관리하는 기능입니다. 제품의 무게중심이 ‘편집기’에서 ‘에이전트를 굴리는 작업대’로 옮겨간 것입니다.
이 전환에는 시장 논리가 깔려 있습니다. 코드 자동완성은 몇 년 전만 해도 차별화 포인트였지만 지금은 여러 제품이 비슷한 수준으로 제공하는 공통 기능이 됐습니다. 경쟁축이 ‘얼마나 잘 짜주나’에서 ‘조직의 실제 워크플로에 얼마나 깊이 박히나’로 넘어간 것이죠. 외부 도구를 MCP(Model Context Protocol)로 연결하고 이를 팀이 공유하는 마켓플레이스를 두는 구조는, 개인 도구가 아니라 팀 표준 자리를 노린다는 뜻입니다. 여기서 가장 흔한 오해를 먼저 깨야 합니다. ‘AI가 알아서 다 해준다’가 아닙니다. AI가 손댈 수 있는 도구·데이터·권한의 경계를 사람이 먼저 설계해 둬야 성능도 나오고 사고도 막힙니다. 경계 설계 없이 붙인 자동화는 빠른 게 아니라 통제 불능에 가깝습니다.
플러그인과 팀 마켓플레이스: 확장성이자 곧 공격 표면
공개된 소재를 종합하면 Cursor는 MCP 기반 앱을 붙이는 플러그인 구조와, 이를 팀이 공유하는 마켓플레이스를 함께 내놨고 한 차례 업데이트에서만 30개가 넘는 신규 플러그인이 추가됐다고 전해집니다. 숫자보다 성격이 중요합니다. 플러그인은 이슈 트래커, 사내 문서, 데이터베이스, 배포 파이프라인 같은 시스템을 에이전트의 ‘손’에 쥐여 주는 통로이고, 마켓플레이스는 그 통로를 개인 설정이 아니라 조직 자산으로 굳힙니다. 편의는 여기서 오지만 위험도 정확히 같은 지점에서 옵니다.
켜기 전에 정해야 할 것은 세 가지입니다. 첫째, 플러그인별 권한 등급을 읽기 전용 / 쓰기 / 삭제·배포 세 단계로 나눠 태깅하세요. 읽기 전용 이슈 조회와 프로덕션 배포 실행은 사고 시 파급이 전혀 다릅니다. 둘째, 마켓플레이스 승인 주체를 한 명이라도 지정하세요. ‘누구나 팀 표준으로 올릴 수 있음’ 상태를 방치하면 검증 안 된 도구가 팀 전체 컨텍스트에 노출됩니다. 셋째, 개수 상한을 미리 정하세요. 플러그인이 30개, 50개로 늘면 버전 호환성과 보안 패치를 누군가는 관리해야 하고, 방치된 연결은 그대로 방치된 취약점이 됩니다. 흔한 함정은 ‘설치가 쉬우니 일단 다 깔자’입니다. 플러그인 하나 = AI가 접근하는 공격 표면 하나라는 등식을 기억하고, 90일 이상 쓰지 않은 연결은 정기적으로 지우는 원칙을 두는 편이 낫습니다.
CLI·클라우드 핸드오프·비동기 서브에이전트: ‘어디서 도느냐’가 바뀐다
두 번째 축은 실행 위치입니다. Cursor는 에디터 UI 밖에서 도는 CLI 에이전트 모드, 로컬에서 시작한 작업을 클라우드로 넘기는 클라우드 핸드오프(Cloud Handoff), 여러 작업을 병렬로 돌리는 비동기 서브에이전트(Async Subagents)를 함께 제시했습니다. 묶으면 이렇습니다. 화면 앞에 붙어 대기하던 조수가, 터미널·CI·클라우드를 오가며 백그라운드로 도는 실행 주체로 바뀌고 있다는 것. 대규모 리팩터링, 테스트 보강, 전체 코드베이스 검색처럼 오래 걸리는 작업을 위임하고 개발자는 다른 일을 이어가는 그림이 목표입니다.
여기서 과장과 실제를 반드시 갈라야 합니다. ‘병렬로 많이 시키면 빨라진다’는 처리량 이야기지 ‘결과가 옳다’는 보장이 아닙니다. 실무에서 실제로 터지는 사고는 두 종류입니다. 하나는 병렬로 돌린 에이전트 여럿이 같은 파일을 동시에 건드려 머지 충돌을 내는 경우, 다른 하나는 사람이 안 본 변경이 조용히 병합돼 나중에 디버깅 비용으로 되돌아오는 경우입니다. 그래서 켜기 전 체크포인트는 명확합니다. (1) 클라우드 핸드오프 시 소스·시크릿이 어디까지 전송·보관되고 학습에 쓰이는지, (2) 자동 생성된 변경에 사람 리뷰(PR 승인) 단계를 강제할 수 있는지, (3) 실패한 백그라운드 작업이 알림 없이 묻히지 않게 로그와 상태가 남는지. 이 셋 중 하나라도 ‘아니오’면 병렬 범위를 넓히기 전에 그 구멍부터 막아야 합니다.
샌드박스 접근 제어와 Composer: 통제와 측정이 진짜 기능이다
자동화가 늘수록 통제가 부가기능이 아니라 핵심 기능이 됩니다. Cursor가 샌드박스 접근 제어(Sandbox Access Controls)를 따로 강조한 것은, 에이전트가 실행할 명령·건드릴 파일·나갈 네트워크의 경계를 관리자가 정하는 장치가 이제 선택이 아니라 전제라는 뜻입니다. 자동으로 도는 에이전트가 임의 셸 명령과 외부 네트워크에 무제한 접근한다면 편의는 그 순간 보안 사고 대기 상태가 됩니다. 반대로 경계를 지나치게 좁히면 기능 자체가 무력화되죠. 그래서 정답은 ‘전부 허용’도 ‘전부 차단’도 아니라, 기본 차단(default-deny) 위에서 필요한 명령·경로·엔드포인트만 화이트리스트로 여는 정책 설계입니다. 이 정책의 정교함이 도입 성패를 가릅니다.
모델 쪽에서는 실시간 강화학습(RL)으로 자체 코딩 모델 Composer(컴포저)를 다듬는다는 대목이 눈에 띕니다. 초보자가 오해하기 쉬운 지점이 여기 있습니다. ‘RL을 쓰면 무조건 똑똑해진다’는 기대인데, RL은 실사용·피드백 신호를 학습에 반영해 특정 작업의 성공률을 끌어올리는 방식이지 만능 성능 스위치가 아닙니다. 벤더 벤치마크 향상이 곧 내 프로젝트의 성과라는 보장도 없습니다. 판단 기준은 홍보 문구가 아니라 내 언어·프레임워크에서의 재현 가능한 수치여야 합니다. 구체적으로는 도입 전 대표 작업 5~10개(버그 수정, 함수 추가, 리팩터링 등)를 고정해 두고 ① 한 번에 통과한 비율, ② 수정에 든 시간, ③ 사람이 손댄 라인 수를 기존 방식과 비교하는 1~2주 파일럿을 권합니다. 그리고 비용·보안·품질·유지보수 네 축마다 상한선을 정해 그 안에서만 자동화 범위를 넓히는 접근이, 단기 유행이 아니라 6개월~2년 관점에서 조직에 남는 방식입니다.
자주 묻는 질문
Cursor 플러그인과 마켓플레이스는 무료인가요?
요금은 시점과 요금제(개인·팀·엔터프라이즈)에 따라 달라지므로 공식 가격 페이지에서 최신 조건을 직접 확인해야 합니다. 이 글이 다룬 소재는 기능 발표 내용이라 구체적 가격을 명시하지 않습니다. 결제 전에는 최소한 좌석당 과금인지 사용량 과금인지, 클라우드 핸드오프 같은 서버 실행 기능에 별도 비용이 붙는지 두 가지를 확인하세요.
비동기 서브에이전트를 쓰면 개발이 그만큼 빨라지나요?
대기 시간은 줄 수 있지만 결과 품질이 자동으로 보장되지는 않습니다. 실제로는 여러 에이전트가 같은 파일을 동시에 수정해 머지 충돌이 나거나, 사람이 안 본 변경이 병합돼 디버깅 비용이 되레 늘어나는 사고가 잦습니다. PR 승인 같은 사람 리뷰 단계와 변경 로그를 먼저 강제한 뒤 병렬 범위를 넓히는 순서가 안전합니다.
클라우드 핸드오프를 쓰면 회사 소스코드가 외부로 나가나요?
로컬 작업을 클라우드로 넘긴다는 개념상 코드와 컨텍스트 일부가 전송될 수 있습니다. 따라서 전송·보관 범위, 보존 기간, 학습 사용 여부를 계약과 설정에서 확인해야 합니다. 시크릿이나 규제 데이터가 든 저장소라면 샌드박스 접근 제어로 나갈 수 있는 경로를 먼저 좁히고 소규모 파일럿부터 시작하세요.
Cursor의 Composer 모델은 다른 상용 모델과 무엇이 다른가요?
Composer는 Cursor가 코딩 작업에 맞춰 개선하는 자체 모델이고, 실사용 피드백을 반영하는 실시간 RL 방식이 언급됩니다. 다만 특정 벤치마크 향상이 내 프로젝트 성과를 뜻하지는 않습니다. 대표 작업 5~10개를 고정해 한 번에 통과한 비율과 수정 소요 시간을 다른 모델과 나란히 측정해 보는 것이 홍보 문구보다 정확한 비교입니다.
플러그인을 많이 설치하면 보안 위험이 커지나요?
네. 플러그인 하나는 AI가 접근하는 외부 도구·데이터 통로이자 공격 표면 하나입니다. 특히 쓰기·삭제·배포 권한을 가진 플러그인은 사고 시 파급이 큽니다. 권한을 읽기전용/쓰기/삭제·배포로 등급화하고, 팀 마켓플레이스 승인 주체를 지정하며, 오래 쓰지 않은 연결은 주기적으로 삭제하는 최소권한 원칙이 필요합니다.