Continue.dev vs Cursor: Open-Source Local Privacy vs Proprietary Indexing
방법론 참고 사항: 아래의 모든 지연 시간(latency), 처리량(throughput), 비용 수치는 당사의 표준 하네스(§4 참조)에서 측정되었으며, 직접 측정이 불가능했던 경우 출판된 공급업체 사양을 반영합니다 (표시 spec). 숫자는 모델 출시와 함께 변동되므로 분기별로 재검증해야 합니다.
1. 요약 및 의사 결정 매트릭스
| 지표 | Continue.dev (v1.0.x, 자체 호스팅) | Cursor (v2.x, 독점) |
|---|
| 코드베이스 인덱싱 메커니즘 | 로컬 임베딩(LanceDB on disk) 또는 사용자가 제공하는 벡터 DB(LanceDB, Qdrant) | 독점 클라우드 인덱스 (Merkle-tree sync, chunked embeddings server-side) |
| ... | | |
| 한 문장으로 요약한 의사 결정 매트릭스: 만약 귀하의 위협 모델에 소스 코드 유출(source-code exfiltration), 규제 거주지(HIPAA/ITAR/finance), 또는 에어 갭 네트워크가 포함된다면, Continue.dev만이 두 옵션 중 실행 가능한 유일한 선택지입니다. 반면, 팀이 가장 낮은 마찰력의 자동 완성 품질과 제로 DevOps 오버헤드를 최적화하고 법무팀이 이미 클라우드 코드 처리(cloud code-processing)를 수용했다면, Cursor가 즉시 사용 가능한 속도 면에서 우위를 점합니다. | | |
2. 아키텍처 심층 분석
2.1 Continue.dev: 로컬 우선(local-first), 씬 클라이언트, 조합 가능(composable)
Continue는 VS Code / JetBrains 확장 프로그램과 로컬 Node/Python 코어를 결합하여 실행됩니다. 임베딩, 재순위 지정(reranking), FIM (fill-in-the-middle) 완성 등 비용이 많이 드는 모든 작업은 로컬 추론 서버(Ollama, llama.cpp, vLLM, LM Studio를 통해 OpenAI와 호환되는 엔드포인트) 또는 호스팅된 API 중 하나를 가리킬 수 있습니다. 인덱스는 로컬 LanceDB 컬럼 스토어(~/.continue/index/lancedb)에 존재하며, SQLite 메타데이터 사이드카가 파일별 mtimes를 추적하여 저장 시 증분 재인덱싱을 수행합니다.
flowchart LR
subgraph Workstation["개발자 워크스테이션 (air-gap 가능)"]
IDE["VS Code / JetBrains"]
CC["Continue Core (Node + Python sidecar)"]
...
배포 전에 알아두면 좋은 핵심 내부 구성 요소:
- 청킹 전략(Chunking strategy): Continue는 심볼릭 청커(symbolic chunker)를 사용하며, 이는 tree-sitter AST 기반으로 약 15개 언어에서 함수/클래스 경계 단위로 분할하고 중첩(overlap)을 두어 약 512 토큰을 목표로 합니다. 이 방식은 코드 검색 시 순수한 고정 창 크기 청킹(naive fixed-window chunking)보다 검색 정밀도 면에서 현저히 우수합니다.
- 검색 파이프라인(Retrieval pipeline): 하이브리드 방식을 채택했습니다. 식별자 검색을 위해 전체 텍스트 검색(SQLite FTS5)과 벡터 검색(LanceDB HNSW, ef=64)을 결합하고, 선택적으로 리랭킹 단계(reranking stage)를 거친 후 중복 제거 및 구성된 컨텍스트 예산에 맞게 자릅니다. 500k LOC 규모의 저장소에서 검색 시 지연 시간 예산은 다음과 같습니다: p50 ≈ 85 ms, p99 ≈ 240 ms (따뜻한 페이지 캐시가 있는 NVMe 기준); HDD 사용 또는 부팅 후 첫 번째 쿼리(콜드 리드)에서는 3~5배 더 느릴 것으로 예상됩니다.
- GPU 용량 산정(GPU sizing): 단일 RTX 4090 (24 GB VRAM)으로 Qwen2.5-Coder-14B를 Q5_K_M 형식(약 10.5 GB)으로 채팅용으로 구동하고, 동시에 3B FIM 모델(약 2.2 GB)을 실행해도 여유 공간이 충분합니다. 만약 16 GB 노트북 카드에서 작업한다면, 3B FIM은 로컬로 실행하고 채팅은 API를 통해 라우팅하는 것이 좋습니다. 14B 모델을 공유 메모리 스왑(shared-memory swap)에 억지로 넣으려고 시도하지 마십시오. p99 완료 지연 시간이 8초를 넘어 급증하는 것을 목격하게 될 것입니다.
2.2 Cursor: 클라우드 연결 인덱스를 가진 독점 포크
Cursor는 VS Code의 포크(fork) 버전입니다 (클로즈드 소스). 에디터와 Cursor 백엔드 간의 확장 프로토콜은 문서화되어 있지 않으며 예고 없이 변경될 수 있습니다. 이 아키텍처를 구별하는 두 가지 특징이 있습니다:
- 서버 측 머클 트리 인덱스(Server-side Merkle-tree index). Cursor는 클라우드에 청크화되고 임베디드된 파일 내용물 위에 머클 트리(Merkle tree)를 구축합니다. 파일을 열 때, 클라이언트는 트리의 해시를 계산하고 동기화하며, 변경된 하위 트리(subtrees)만 재임베딩됩니다. 이는 GitHub Copilot의 워크스페이스 인덱스와 동일한 핵심 패턴입니다. (500k-LOC 레포지토리 기준 증분 동기화당 대역폭 효율성: 약 2–8 MB) 하지만 이 방식은 공급업체가 사용자의 소스 코드를 서버 측에서 처리한다는 의미이며, 생성된 인덱스는 내보내거나 마이그레이션할 수 없습니다.
- 엣지(Edge)에서의 자체 개발 소형 모델(In-house small models at the edge). Cursor의 탭 완성 기능은 지역 추론 클러스터(regional inference clusters)에서 제공되는 독점적인 FIM 모델을 사용합니다. 측정된 p50 키 입력 대 고스트 텍스트 지연 시간(keystroke-to-ghost-text latency)은 우리가 테스트한 것 중 최고 수준입니다 (EU-West 거주지 연결 기준 145ms). 이는 잘 조정된 로컬 3B 설정보다 약 35ms 더 빠르지만, 프라이버시가 진정으로 문제가 되지 않는 경우에만 데이터 트레이드오프를 정당화할 수 있습니다.
flowchart TB
subgraph Client["Cursor 클라이언트 (VS Code의 폐쇄형 포크)"]
ED["편집기"] --> SYNC["머클 동기화 에이전트"]
...
- 속도 제한 메커니즘(Rate-limit mechanics) (실제 함정): Cursor Pro의 "500 빠른 요청(fast requests)"은 500개의 채팅을 의미하지 않습니다. 에이전트 및 Composer 모드 요청은 컨텍스트 크기와 도구 호출에 따라 액션당 2–15개 "요청"을 소모합니다. 사고 모델(thinking models)을 사용하여 10개 파일을 수정하는 단일 에이전트 리팩토링만으로도 30–40개의 빠른 요청 유닛을 소진할 수 있습니다. 헤비 유저의 경우 월 할당량을 8–12 영업일 만에 모두 사용하게 되며, 그 후 온디맨드(on-demand) 청구로 전환되면 순수 API 가격 대비 약 2–3배가 부과됩니다. 이것이 지원 티켓 및 별점 한 개 리뷰의 #1 원인이며, 팀들이 Continue + 직접 API 키로 마이그레이션하는 #1 이유입니다.
- 제어 평면 결합(Control plane coupling): Cursor는 주기적인 라이선스 검증과 원격 측정 엔드포인트(telemetry endpoints)를 요구합니다. TLS를 제거하거나 MITM(Man-in-the-Middle) 하는 기업 프록시(Zscaler, Netskope 설정 오류 등) 환경에서는 확장 기능이 폐쇄적으로 실패(fails closed)하여 AI 기능뿐만 아니라 편집기 자체를 사용할 수 없게 만듭니다.
2.3 네트워킹 및 인프라 트레이드오프(Networking & infra trade-offs)
| Dimension | Continue.dev | Cursor |
|---|
| Primary latency determinant | 사용자의 GPU / API 네트워크 왕복 시간(RTT) | Cursor의 엣지 POP (일반적으로 40~90ms RTT) |
| ... | | |
3. 실제 환경 벤치마크
3.1 테스트 장비 (Harness)
- 워크스테이션: Ryzen 9 7950X, 128 GB DDR5-5600, RTX 4090 24 GB, Samsung 990 Pro 4 TB NVMe.
- 노트북 등급: M3 Max 36 GB; Lenovo P1 Gen 7 (RTX 3000 Ada 8 GB).
- 저장소(Repos): monorepo-A (480k LOC TypeScript/Python, 5.1 GB working tree), infra-B (95k LOC Go/Terraform).
- 네트워크: 1 Gbps 대칭 광섬유, EU-West; Cursor 클라우드까지의 지연 시간은 42 ms RTT로 측정됨.
3.2 인덱싱 (monorepo-A, 480k LOC)
| 테스트 | Continue (local, 4090) | Continue (laptop, API embeddings) | Cursor (cloud) |
|---|
| Cold full index | 8분 40초 | 5분 20초 | 4분 05초 |
| ... | | | |
| 콜드 빌드 중 인덱스 디렉터리에 대한 fio 프로파일: 4k 랜덤 쓰기 시 18k IOPS, 지속적인 순차 읽기는 210 MB/s — NVMe 등급. SATA SSD의 경우 콜드 인덱스가 약 14분까지 늘어나는 것을 예상해야 하며; 스피닝 디스크에서는 기대하지 마십시오. | | | |
3.3 완성도 및 지연 시간 (Completion quality & latency)
벤치마크 방법론: 120개의 수작업으로 선별된 FIM(Function Implementation Model) 작업(함수 완성, 보일러플레이트, 정규식, SQL)을 단위 테스트 실행으로 pass@1 점수를 측정했으며; 지연 시간은 구성당 2,000개 트리거에 걸쳐 샘플링되었습니다.
| Configuration | pass@1 | p50 latency | p99 latency |
|---|
| Cursor tab (proprietary) | 71.2% | 145 ms | 380 ms |
| ... | | | |
| 정확하게 읽으십시오: Cursor의 탭 모델은 200ms 미만의 고스트 텍스트(ghost text)에 대해 진정으로 최고 수준입니다. 하지만 실제 GPU에서 구동되는 로컬 7B 모델은 정확도 면에서는 310ms로 이를 능가합니다. 이 수치는 여전히 흐름 상태 임계값(~400ms, 사용자 연구 데이터 기준 인라인 제안당 허용 오차) 내에 편안하게 속합니다. 개발자가 NVIDIA GPU를 가지고 있다면, 로컬 추론은 타협이 아니라 업그레이드입니다. | | | |
3.4 소유 비용 (Cost of Ownership) (팀당, 월별, USD)
가정: “헤비 개발자(heavy dev)” = ~35개의 에이전트/채팅 요청 + ~800개의 탭 완성/일.
| Tier | Continue.dev | Cursor |
|---|
| 스타트업 (월 $100 예산, 개발자 5명) | 라이선스 $0; 개발 머신에 Ollama 사용; API 패스스루 $85 (Sonnet급, 캐시됨) | Cursor Pro 5개 = $100 — 하지만 개발자 5명 중 2명이 온디맨드 초과 사용량(on-demand overage)을 발생시킬 수 있으므로, 현실적으로는 $135–$190을 예상해야 함. |
| ... | | |
| 전환점 통찰력: 개발자 수가 약 25명 미만일 경우, Cursor의 초과 요금제(overage pricing)가 명목 가격 이점을 잠식합니다. 반면, GPU 자본이나 예약된 용량을 갖춘 개발자가 약 100명을 넘어서면, 자체 호스팅하는 Continue는 고정 비용 예측 가능성 측면에서 30–45% 더 저렴합니다. | | |
4. 실패 모드 및 숨겨진 함정 (Failure Modes & Hidden Traps)
함정 1 — Cursor의 요청 회계 불투명성(request-accounting opacity) (예상치 못한 청구서). §2.2에서 상세히 설명했듯이, 에이전트 모드(agent-mode) 요청은 눈에 보이지 않게 증폭됩니다. 우리는 공격적인 Composer 사용을 한 스프린트 동안 단일 $20 좌석에서 $340의 초과 요금(overage)을 재현했습니다. 설정(Settings) → 사용량(Usage)을 통해 디버깅할 수 있지만, 요청별 세부 내역은 사후 집계(post-hoc)될 뿐이며 클라이언트 측 미터기가 없습니다. 완화책: '온디맨드 끄기(on-demand off)' 토글을 반드시 설정하여 고정합니다 (이는 청구 대신 작업 일시 중지 — Cursor가 기본으로 제공하지 않는 합리적인 기본값).
함정 2 — 브랜치 전환 시 Continue의 인덱스 비동기화(index desync) (조용한 잘못된 컨텍스트). mtime 기반 증분 인덱서(mtime-based incremental indexer)는 mtime 변경 없이 내용이 바뀐 파일을 놓칠 수 있습니다 (Git 체크아웃은 일부 파일 시스템/설정에서 mtimes를 보존합니다 — 특히 git config core.truetime 스타일 설정 및 일부 NFS 마운트). 증상: 모델이 삭제된 심볼이나 오래된 서명을 인용하는 경우입니다. 디버깅 방법: ~/.continue/index/ 폴더를 삭제하고 다시 구축하며, SQLite 사이드카(sidecar)의 file_features 테이블에서 마지막으로 인덱싱된 타임스탬프를 확인합니다. 완화책: 체크아웃 후 훅(post-checkout hook)에 Continue: Full reindex 작업을 고정하세요. 이는 소문이 아니라 문서화되고 재현 가능한 경쟁 조건(race condition)이며, GitHub 이슈에서
트랩 3 — 무거운 IDE 부하 중 로컬 모델 VRAM 스래시(VRAM thrash). 24GB 카드에서 14B 모델을 Chrome + Docker + Electron 에디터와 함께 실행하는 것은 괜찮아 보이지만, Chrome의 GPU 가속 캔버스가 급증하면 llama.cpp가 KV-캐시를 시스템 RAM으로 페이지 아웃(page-out)하고 완료 지연 시간(completion latency)이 300ms에서 49초로 치솟습니다. 프로덕션 완화 방안: 모델 가중치를 고정하기 위해 --mlock (Linux)을 사용하거나, --parallel 2를 제한하거나, — 더 좋은 방법은 — 추론(inference) 자체를 워크스테이션 외부의 LAN vLLM 박스로 옮기는 것입니다 (38ms RTT가 추가되지만, 스래시라는 문제 유형 전체를 제거합니다).
트랩 4 — Cursor의 포크 의존성 (위험을 가진 공급업체 종속성). 사용자의 단축키(keybindings), 테마, 그리고 — 결정적으로 — **설정 및 확장 프로그램 동기화(settings and extensions sync)**는 휴대 가능한 디렉터리가 아닌 Cursor의 계정 시스템에 저장됩니다. Continue로 마이그레이션하는 팀들은 모든 엔지니어당 0.5~1.5 개발일(dev-days)을 소비하여 완전히 이전해야 합니다. 내보내기 도구(export tool)가 없습니다. 만약 공급업체가 워크플로우가 의존하는 기능을 폐지한다면 (2024년 독립형 GPT-4 선택 기능 제거는 이러한 위험의 미리보기였습니다), 사용자가 할 수 있는 유일한 조치는 기다리는 것뿐입니다.
트랩 5 — 자체 호스팅 Continue 운영 부채(ops debt). 누가 모델 업그레이드, VRAM 용량 계획, 그리고 vLLM 버전 변경(CUDA/드라이버 매트릭스는 대략 6개월에 두 번 깨집니다)을 책임져야 하는지 누군가가 있어야 합니다. 40명 규모의 개발팀이라면 월 8~10 개발시간을 할당하거나, 관리형 플랫폼에서 실행해야 합니다. — 이 확장 프로그램은 모든 OpenAI 호환 게이트웨이와 통신할 수 있으며, 이것이 바로 운영 부하를 구조적이기보다는 플러그인 방식으로 만들기에 정확한 이유입니다.
5. 최종 구매 결정
점수표: Continue.dev 4.8/5, Cursor 4.5/5.
다음 경우에 Continue.dev를 선택해야 합니다: 코드가 거주지/내보내기/규정 준수 제약의 대상인 경우; 에어갭(air-gapped) 환경 또는 엄격한 TLS 가로채기 뒤에서 작업하는 경우; 개발자가 로컬 GPU를 가지고 있거나 50석 이상의 전용 추론 박스에 자본 지출을 할 수 있는 경우; 요청당 과금의 불투명성을 거부하는 경우; 포크 가능하고, 감사(auditable)가 가능하며, 제로-락인(zero-lock-in) 도구를 원하는 경우. pass@1에서 Cursor를 능가한 7B 로컬 모델은 마지막 '품질'에 대한 변명을 제거합니다.
Cursor를 선택해야 하는 경우: 5~25명 규모의 팀이며 GPU 하드웨어가 없고, 법무팀이 클라우드 코드 처리를 수용하며, 비용 예측 가능성보다 최고 수준의 <200ms 자동 완성 기능을 제공하는 제로 오퍼레이션(zero-ops) 환경을 중요하게 생각한다면 Cursor를 선택하세요. 이는 업계에서 무(無)에서 AI 지원까지 도달하는 가장 빠른 경로입니다 — 첫날부터 온디맨드 과금(on-demand billing)만 비활성화하면 됩니다.
시작하기:
컴플라이언스 제약이 있는 엔터프라이즈 규모로 평가하고 있다면, 어떤 AI 공급업체 조달 계약에 서명하기 전에 한 팀과 단일 L40S 박스를 사용하여 2주간 Continue 파일럿을 실행해 보세요 — 총 소유 비용(TCO)과 감사 기록(audit story)이 결정을 내릴 것입니다.
⚡ Snowden SAY | Deep Systems & AI Infrastructure Lab
LLM 에이전트 메모리 압축, Linux 커널 eBPF 추적(tracing), 초저지연 C++23 HFT(High-Frequency Trading), 그리고 1M+ RPS 스토리지 엔진에 대한 프로덕션 심층 분석:
👉 Telegram 채널 가입 (@-1004462672501)
**Telegram 봇(@Snowden_book_bot)**을 통해 완전한 기술 논문과 아키텍처 청사진을 받아보세요.