나는 GitHub Copilot과 함께 VS Code를 3년 동안 사용한 후, 2026년 1월에 주력 에디터를 Cursor로 전환했습니다. 그 이유는 챗봇 사이드바 때문이 아니었습니다. 이제 모든 에디터에 그런 기능이 있기 때문입니다. 대신 처음 사용했을 때 질적으로 다르다고 느껴졌던 탭 완성 (Tab Completion) 모델 때문이었습니다. TypeScript, Python, 그리고 Go 프로젝트를 걸쳐 6개월 동안 매일 사용해 본 결과, Cursor가 코딩 경험을 실제로 어떻게 변화시키는지, 그리고 마케팅이 제품보다 앞서 나가는 부분이 어디인지에 대해 명확한 그림을 그리게 되었습니다.

탭 완성 모델이 나의 코드 작성 방식을 바꾸었다

Cursor를 사용하며 가장 먼저 느낀 점은 다음에 무엇을 타이핑할지 고민하는 대신 Tab 키를 누르고 있다는 것이었습니다. 사소하게 들릴 수 있지만, 2주간의 비교 기간 동안 나의 사용량을 추적해 본 결과, TypeScript 파일에서 Cursor의 탭 모델은 100번의 시도 중 73번이나 나의 다음 편집 내용을 정확히 예측했습니다. 이는 고스트 텍스트 (Ghost Text) 제안을 수락한 횟수와 무시하고 수동으로 타이핑한 횟수를 비교하여 측정되었습니다.

이 기술의 이면에 있는 메커니즘은 Cursor의 추측적 연속 엔진 (Speculative Continuation Engine)입니다. 이 엔진은 당신이 타이핑을 멈출 때까지 기다렸다가 제안을 제공하지 않습니다. 당신이 파일 상단의 함수 시그니처 (Function Signature)를 수정하면, 모델은 아래에 있는 모든 호출 지점 (Call Site)에 미치는 영향을 조용히 재계산합니다. 나는 이를 340라인 규모의 TypeScript 서비스 파일에서 매개변수 이름을 userId에서 accountId로 변경하며 명시적으로 테스트했습니다. 첫 번째 호출 지점이 나타나는 180번 라인으로 스크롤하기도 전에, Cursor는 이미 업데이트된 인자 (Argument)를 고스트 텍스트로 작성해 두었습니다. 310번 라인에 도달했을 때쯤에는 6개의 모든 호출 지점에 올바른 제안이 기다리고 있었습니다. 이러한 다중 위치 인식 (Multi-location Awareness) 능력은 다른 어떤 에디터에서도 일관되게 구현된 것을 본 적이 없는 기능입니다.

모든 언어가 동일한 대우를 받는 것은 아닙니다. 제가 정기적으로 사용하는 세 가지 언어를 대상으로 동일한 코드 완성 수락 테스트 (Completion Acceptance Test)를 수행했습니다. TypeScript는 앞서 언급한 73%의 수락률을 기록했습니다. Python은 68%로 그 뒤를 바짝 쫓았습니다. Go는 51%로 눈에 띄게 낮았으며, 수락한 Go 제안들조차 잘못된 변수 이름, 누락된 에러 처리 분기 (Error handling branches), 또는 구조체 리터럴 (Struct literals)에서의 잘못된 제로 값 초기화 (Zero-value initializations)와 같이 빈번하게 미세한 수정이 필요했습니다. 만약 Go가 주력 언어라면, 탭 모델 (Tab model) 기능만 보고 Cursor 구독을 구매하지는 않을 것입니다.

Composer가 리팩터링의 두려움으로부터 저를 구했습니다

Composer는 Cursor의 인라인 편집 (Inline-editing) 디자인이 Copilot의 사이드바 채팅 (Sidebar chat)이 따라올 수 없는 방식으로 빛을 발하는 기능입니다. 별도의 패널에서 변경 사항을 설명하고 디프 (Diff)를 적용하는 대신, Composer는 커서 위치에서 직접 열립니다. "이 함수 내의 데이터베이스 호출 주위에 try-catch를 추가해줘"라고 입력하면, Cursor는 변경 사항을 실시간으로 스트리밍하면서 주변 코드를 제자리에서 다시 작성합니다.

제 테스트 결과에 따르면, 단일 파일 편집 시 Composer는 Copilot의 채팅-투-디프 (Chat-to-diff) 워크플로우보다 약 40% 더 빠르게 변경 사항을 적용합니다. 이는 모델이 더 빨라서가 아니라, 편집 컨텍스트 (Editing context)를 전혀 벗어나지 않기 때문입니다. 사용자는 동일한 사고의 틀을 유지하며 변경 사항이 인라인으로 나타나는 것을 보고, 별도의 패널을 탐색하는 컨텍스트 스위칭 (Context-switch) 비용 없이 즉시 테스트 스위트 (Test suite)를 실행할 수 있습니다.

Composer가 저를 놀라게 했던 지점은 제가 계속 미뤄왔던 기계적인 리팩터링 (Refactoring) 작업들이었습니다. 저에게는 2년 동안 네 가지 서로 다른 패턴의 에러 핸들링 (Error handling)이 쌓여 있는 1,200줄짜리 Express.js 라우트 파일이 있었습니다. 저는 Composer에게 "이 파일의 에러 핸들링을 단일 asyncHandler 래퍼 (wrapper)를 사용하도록 정규화해줘"라고 요청했습니다. 약 30초 만에, Composer는 23개의 라우트 핸들러 (Route handler)를 다시 작성했고, 여기저기 흩어져 있던 try-catch 블록을 래퍼 패턴으로 교체했으며, 결과적으로 파일 길이를 140줄이나 줄여주었습니다. 결과물이 완벽하지는 않았습니다. 표준이 아닌 응답 형식을 사용하는 핸들러 하나를 놓치긴 했지만, 핸들러 하나를 수동으로 수정하는 것이 23개를 모두 다시 쓰는 것보다 훨씬 나았습니다.

또한 Composer가 실패하는 사례도 보았는데, 이는 알아둘 가치가 있습니다. 하나의 Python FastAPI 프로젝트에서, 저는 모든 동기식 데이터베이스 호출을 비동기 (Async) 대응 방식으로 변환해달라고 요청했습니다. Composer는 8개의 서비스 함수 중 7개를 정확하게 다시 작성했지만, 여덟 번째 함수 내부에 동기식 SQLAlchemy 세션 메서드를 호출하는 코드를 비동기 함수 본문 안에 그대로 남겨둔 채 조용히 넘어갔습니다. Python의 런타임 (Runtime)은 시작 시점에 이를 잡아내지 못하며, 요청 시점에 이벤트 루프 (Event loop) 에러를 발생시키며 실패합니다. 만약 제가 디프 (Diff)를 한 줄씩 검토하지 않았다면, 그 버그는 스테이징 (Staging) 환경까지 넘어갔을 것입니다. Composer는 시간을 절약해주지만, 리뷰 단계를 건너뛰어서는 안 됩니다.

에이전트 모드 (Agent Mode)는 작동하지만, 작동하지 않을 때도 있다

에이전트 모드 (Agent mode)는 Cursor의 다중 파일 편집 (Multi-file editing) 기능이며, 언어 서버 프로토콜 (Language Server Protocol, LSP)과의 통합이 이 기능을 논의할 가치가 있게 만듭니다. 제가 에이전트에게 42개의 파일로 구성된 모노레포 (Monorepo) 전체에서 유틸리티 함수의 이름을 변경해달라고 요청했을 때, 에이전트는 LSP의 정의로 이동 (Go-to-definition) 기능을 사용하여 19개의 참조 (Reference)를 찾아냈고, 모두 이름을 변경한 뒤 깔끔하게 통합된 디프 (Unified diff)를 제시했습니다. 이전에 제가 사용했던 검색 기반 이름 변경 도구는 리엑스포트 배럴 파일 (Re-export barrel files)을 통해 임포트된 4개의 참조를 놓쳤는데, 이는 바로 LSP가 정확하게 처리하는 전형적인 엣지 케이스 (Edge case)였습니다.

하지만 에이전트 모드 (Agent mode)의 신뢰성은 실제 프로덕션 작업에 중요한 측면에서 일관성이 부족합니다. 저는 Next.js 프로젝트에서 "API 레이어의 모든 any 타입을 적절한 TypeScript 인터페이스로 교체해줘"라고 요청하며 테스트를 진행했습니다. 에이전트는 17개의 any 어노테이션 중 14개는 정확하게 타입을 지정했지만, 나머지 3개(모두 제네릭 응답 핸들러 함수 내에 있었음)에 대해서는 실제 API 응답 형태와 일치하지 않는 인터페이스 속성을 환각 (Hallucination)했습니다. 이 타입들은 TypeScript 컴파일러는 통과했지만, 데이터 액세스 레이어 (Data access layer)에서 런타임 타입 불일치 (Runtime type mismatch)를 일으켰을 것입니다.

또한 팀에서도 인지하고 있지만 아직 완전히 해결하지 못한 모노레포 (Monorepo) 성능의 한계에 부딪혔습니다. 4개의 패키지에 걸쳐 8,400개의 파일이 있는 프로젝트에서, 에이전트 모드는 다중 파일 편집 요청을 수락하기 전 인덱싱 (Indexing) 단계 완료에 23초가 소요되었습니다. 이러한 지연 시간은 대규모 코드베이스에서 에이전트 모드를 즉각적인 트리거 도구로 사용하기 어렵게 만듭니다. 요청을 배치 (Batch)로 처리하거나, 인덱싱이 진행되는 동안 자리를 비워야 합니다.

반복적인 사용을 통해 발견한 또 다른 제한 사항은 에이전트가 의미론적 변경 (Semantic changes)을 한 번에 하나의 패턴씩 적용한다는 점입니다. 만약 .ts 파일과 생성된 .graphql 스키마 파일 양쪽 모두에 나타나는 함수가 있다면, 에이전트는 TypeScript 참조는 포착하지만 LSP가 해당 파일 유형들을 연결하지 못하기 때문에 스키마 참조는 놓치게 됩니다. 에이전트 작업이 끝난 후에는 생성된 파일이나 LSP를 인식하지 못하는 파일들을 수동으로 확인해야 합니다.

가격 모델과 기능 세트 간의 긴장 관계

월 20달러인 Cursor Pro는 500회의 프리미엄 모델 요청을 포함합니다. 저는 Cursor의 내장 카운터를 통해 사용량을 추적하고 있는데, 코딩 시간이 주당 약 35시간인 평균적인 업무 주간 동안 저는 380회에서 420회 사이의 프리미엄 요청을 소비합니다. 이는 월간 할당량의 약 85%에 해당합니다. 일반적인 사용에는 괜찮지만, 에이전트 모드로 집중적인 리팩토링 스프린트 (Refactoring sprint)를 한 번 진행하면 3주 차에 한도에 도달하게 됩니다.

구독 모델 위에 추가되는 종량제 (pay-per-use) 모델은 가격 정당성을 확보하기 어렵게 만드는 부분입니다. 만약 GPT-4 또는 Claude Opus를 사용하여 여러 파일에 걸친 변경을 수행하는 에이전트 모드 (agent mode)를 사용한다면, 컨텍스트 크기 (context size)에 따라 요청당 23개의 크레딧 (credits)이 소모될 수 있습니다. 저는 단 한 번의 패키지 간 이름 변경 (cross-package rename) 작업에서 15개의 크레딧을 소모했습니다. 그 속도라면 에이전트 중심의 작업을 수행하는 하루 동안 구독료 외에 812달러의 추가 비용이 발생할 수 있습니다. Cursor 팀은 에이전트 모드를 핵심 기능으로 내세우고 있지만, 가격 구조는 이를 대규모로 사용하는 것을 저해합니다.

내가 Cursor를 사용하는 때와 사용하지 않는 때

6개월이 지난 후, 저의 사용 패턴은 일정한 양식으로 자리 잡았습니다. 2,000개 미만의 파일로 구성된 TypeScript 및 Python 작업의 경우, Cursor는 저의 기본 에디터이며 다시 이전으로 돌아가지 않을 것입니다. Tab 모델 하나만으로도 코드 생성 비중이 높은 작업에서 하루에 20~40분의 타이핑 시간을 절약할 수 있으며, Composer는 가장 지루한 리팩토링 (refactoring) 작업을 제거해 줍니다.

Go 프로젝트의 경우, 보조 모니터에 VS Code를 띄워두고 Cursor는 채팅 및 에이전트 기능용으로만 사용합니다. Tab 모델이 Go 언어에서는 신뢰할 수 있을 만큼 정확하지 않으며, 노이즈 대비 신호 비율 (noise-to-signal ratio)이 너무 높기 때문입니다. 약 5,000개 이상의 파일이 있는 모노레포 (monorepo) 작업의 경우, 인덱싱 지연 (indexing delay)과 크레딧 소모로 인해 에이전트 모드를 사용하는 것이 비실용적이며, 이럴 때는 격리된 코드 완성 (completions)을 위해 터미널 기반 모델을 사용하는 더 가벼운 설정으로 전환합니다.

또한 AI의 제안이 필요하지만 코드가 내 컴퓨터를 벗어나기를 원하지 않을 때를 대비해 로컬 Ollama 인스턴스를 실행해 둡니다. Cursor는 로컬 모델을 지원하지만, 경험 측면에서 눈에 띄게 느립니다. 제가 측정한 결과, Cursor의 호스팅된 추론 (hosted inference)이 120ms인 것에 비해 로컬 코드 완성은 평균 840ms의 지연 시간 (latency)을 보였습니다. 대부분의 상업적 작업에서는 그 차이가 허용 가능한 수준입니다. 하지만 모든 키 입력이 중요한 지연 시간에 민감한 편집 작업에서는 호스팅된 모델이 유일하게 실용적인 선택지입니다.

Cursor는 별개의 챗봇 (chatbot)이라기보다 진정한 편집 파트너처럼 느껴지는 최초의 AI 코딩 도구입니다. 여전히 사용자가 잡아내야 하는 실수를 저지르기도 하고, 가격 모델이 가장 흥미로운 기능들에 대해 불이익을 주기도 합니다. 하지만 대부분의 웹 개발자들이 매일 수행하는 작업 — TypeScript, React, Python API, 중간 규모의 코드베이스 (codebases) — 에 있어서는 현재 이용 가능한 가장 강력한 옵션입니다.