저는 2025년 초부터 2026년 2월까지 Cursor를 주요 AI 코딩 도구로 사용했습니다. 제가 이곳에 기록해 온 '3개 디렉토리 사이트 실험'을 시작한 3월에, 저는 메인 드라이버를 Claude Code로 전환했습니다. 이 전환은 충동적인 것이 아니었습니다. 확정하기 전에 약 2주 동안 동일한 작업에 두 도구를 모두 사용해 보았습니다. 제가 걸고 있는 구체적인 베팅 내용과, 제가 진심으로 설득력 있다고 느끼는 반대 논거, 그리고 제가 이 결정을 뒤집을 세 가지 조건은 다음과 같습니다.

명확하게 밝히는 베팅 내용

이 프로젝트를 시작한 지 9개월이 되는 2026년 12월까지, Claude Code는 컨텍스트 재설정(context-restart) 오버헤드와 인라인 탭 완성(inline tab completion) 기능이 없는 데서 오는 오버헤드를 제외하고도, Cursor보다 이 실험에서 저의 전체 실제 소요 시간(wall-clock time)을 더 많이 절약해 줄 것입니다. 측정 방식은 비공식적이지만 조건은 모호하지 않습니다. 만약 제가 Cursor가 사이드바 채팅 기록(sidebar chat history)에 유지했을 컨텍스트를 재설정하는 데 매주 20분 이상을 소비한다면, 제 판단은 틀린 것입니다.

제가 Claude Code가 모든 개발 워크플로우(developer workflows)에서 더 낫다고 주장하는 것은 아닙니다. 저의 베팅은 이 프로젝트가 요구하는 특정 작업 분포에 특화되어 있습니다: 동시에 5개 이상의 파일에 영향을 미치는 다중 파일 리팩터링(multi-file refactors), 터미널 출력이 주요 신호인 GitHub Actions 디버깅, 호출 시점에 AI의 도움이 필요한 자동화된 파이프라인 스크립트, 그리고 스테이징된 git diff를 입력값으로 사용하는 콘텐츠 생성 실행(content-generation runs) 등이 그것입니다.

저를 Claude Code로 이끈 요인

즉각적인 촉매제는 GitHub Actions CI 설정이었습니다. 3개 사이트 아키텍처는 매일 밤 실행되는 ETL, 매일 진행되는 기사 생성 작업, Bluesky 큐 리필, 그리고 여러 번의 배포 후 점검(post-deploy checks)을 각각 별도의 워크플로(workflow)로 실행합니다. Cursor의 채팅 모드에서 이러한 워크플로를 디버깅하는 것은 매우 어색합니다. Cursor는 YAML 파일을 정확하게 인식하지만, 정확히 어떤 단계에서 실패했는지, 그리고 실패한 bash 명령어가 무엇을 생성했는지를 보여주는 런타임 로그(runtime logs)는 보지 못합니다. 저는 GitHub Actions 인터페이스에서 에러 출력을 수동으로 복사하여 Cursor의 채팅창에 붙여넣어야 했고, 이는 작업 흐름(flow)을 끊어놓았습니다.

Claude Code는 터미널 내에서 git 출력, pnpm install 에러, node 스크립트 스택 트레이스(stack traces)와 함께 자리 잡고 있습니다. 컨텍스트(context)를 전환할 필요 없이 실패한 실행 로그를 세션에 직접 붙여넣을 수 있습니다. 실패 관찰, AI 호출, 제안된 수정 사항 검토, 명령 실행으로 이어지는 이 터미널 네이티브 루프(terminal-native loop)에서 저는 처음으로 의미 있는 생산성 격차를 느꼈습니다.

두 번째 요인은 다중 파일 일관성(multi-file coherence)입니다. 공유 Claude Haiku 클라이언트는 세 개의 별도 앱에 걸쳐 있는 다섯 개의 서로 다른 ETL 스크립트에 의해 임포트(import)됩니다. 이를 리팩터링(refactoring)하는 것, 즉 재시도 매개변수(retry parameter)를 추가하거나 캐싱 동작(caching behavior)을 변경하는 것은 다섯 개의 호출 지점(call sites)을 동시에 수정해야 함을 의미합니다. Claude Code는 다섯 개의 파일을 모두 컨텍스트에 열어두고, 사용 패턴을 기반으로 어떤 호출 지점을 업데이트해야 하고 어떤 곳은 그렇지 않은지 추론하며, 일관된 다중 파일 디프(multi-file diff) 설명을 생성할 수 있습니다. Cursor의 "여러 파일에 적용(apply to multiple files)" 흐름은 한 번에 하나의 디프만 보여주며 각 단계마다 수동 승인을 거쳐야 합니다. 이러한 특정 작업, 즉 저장소 간 매개변수 변경(cross-repo parameter change)의 경우, 저는 Claude Code의 방식이 더 빠르다는 것을 알게 되었습니다.

세 번째는 콘텐츠 생성 파이프라인(article-generation pipeline) 그 자체입니다. 콘텐츠 품질 게이트(content quality gate)는 생성된 모든 파일에 대해 감사 스크립트(audit script)를 실행합니다. 제가 실행하는 루틴은 스테이징된 git 출력값을 리뷰어에게 전달하고, 선택적으로 커밋(commit) 전에 기사를 패치(patch)합니다. 생성, 스테이지(stage), 리뷰, 수정, 재스테이지, 커밋으로 이어지는 이 전체 루프는 터미널에서 실행됩니다. Claude Code는 bash 명령어를 실행하고, 변경 사항을 검사하며, 클립보드 전달(clipboard handoffs) 없이 반복 작업을 수행할 수 있습니다. Cursor에서는 감사 출력(audit output)을 확인하거나 pnpm 스크립트를 실행해야 할 때마다 이 흐름이 끊기곤 했습니다.

내가 포기하는 것들

Cursor의 인라인 편집(inline edit) 모드는 미세한 변경(micro-changes)을 수행할 때 진정으로 더 뛰어납니다. CMD+K를 누르면 커서 위치에 플로팅 편집 바가 열리고, 한 문장 정도의 설명을 입력하면 2초 이내에 인라인 차이(inline diff)를 보여주며 이를 수락하거나 거절할 수 있습니다. Claude Code에는 이에 상응하는 기능이 없습니다. 변수 이름을 바꾸거나 조건문을 뒤집고 싶을 때, 저는 터미널에서 위치를 설명하고, 도구가 그곳으로 이동할 때까지 기다린 다음, 변경 사항을 승인해야 합니다. 객관적으로 더 느립니다.

탭 완성(Tab completion) 또한 그리운 기능 중 하나입니다. Cursor의 완성 기능은 익숙한 코드베이스에서 사용자가 다음에 입력할 내용을 놀라울 정도로 정확하게 예측합니다. 제가 끊임없이 반복 작업하는 TypeScript ETL 스크립트에서, Cursor는 이미 제가 await db.execute({sql:를 작성할 것이라는 점을 알고 객체 형태(object shape)를 포함한 패턴을 완성해 줍니다. Claude Code에는 탭 완성 모드가 없으며, 오직 대화형(interactive-only)으로만 작동합니다.

세 번째 격차는 세션 연속성(session continuity)입니다. Cursor의 사이드바 채팅은 세션 전반에 걸쳐 히스토리를 유지합니다. Cursor 대화 내용을 위로 스크롤하여 2주 전에 설계 결정(design decision)을 설명했던 논의 내용을 확인할 수 있습니다. 반면 Claude Code는 호출할 때마다 새로 시작합니다. 만약 4일 전에 작업했던 내용을 디버깅하고 있다면, 저는 이미 추론 과정이 담겨 있는 대화 스레드가 아니라 git 로그와 파일 읽기를 통해 컨텍스트(context)를 다시 구축해야 합니다.

내가 진지하게 받아들이는 반론

내 선택에 대한 가장 강력한 반론은 다음과 같습니다. Claude Code의 터미널 네이티브 (terminal-native) 강점은 곧 그 한계이기도 합니다. Claude Code가 Cursor를 압도하는 작업들 — 다중 파일 리팩토링 (multi-file refactors), CI 디버깅 (CI debugging), 파이프라인 자동화 (pipeline automation) — 은 실제 개발 세션에서 입력되는 전체 글자 수 중 소수에 불과합니다. 라인 단위 편집 (line-level edits), 변수 이름 변경 (variable renames), 독스트링 (docstring) 업데이트, 빠른 함수 호출 (quick function calls) 등이 대다수를 차지합니다. Cursor는 이러한 작업들을 더 빠르게 처리합니다.

만약 올바른 사고 모델이 "개발 시간의 80%는 작은 편집이고, 20%는 대규모 작업이다"라면, 80%의 작업에서 속도 손실을 감수하면서 Claude Code로 나머지 20%를 최적화하는 것은 결국 손해입니다. Cursor는 80%를 잘 처리하고 20%를 적절히 처리함으로써, Claude Code가 대규모 작업의 작업당 속도에서 승리하더라도 전체 실제 소요 시간 (wall-clock time) 측면에서는 승리할 수 있습니다.

이를 깔끔하게 반박할 수 있는 추적 데이터는 저에게 없습니다. 제 직관으로는, 특히 이 프로젝트가 일반적인 단일 앱 제품 빌드보다 20% 영역 — 파이프라인 전반의 변경, 새로운 ETL 통합, CI 실패 디버깅 — 에 더 치우쳐져 있습니다. AI 디렉토리 베팅 글도 동일하게 정직한 구조를 가지고 있습니다. 저는 깔끔한 측정치가 아니라 구조적 추론에 기반하여 주장을 하고 있는 것입니다.

이를 해결할 방법은 무엇일까요: 4주 동안 작업 유형별로 개발 시간을 추적하여 두 카테고리를 비교하는 것입니다. 이는 제가 아직 실행하지 않은 단순한 측정 방법입니다. 만약 작은 편집이 제 Claude Code 세션의 3분의 2 이상을 차지한다면, 반론이 승리하는 것입니다.

비용 구조

두 도구의 월간 비용은 결정적인 요인이 될 만큼 차이가 나지 않지만, 사용 방식에 대한 제 생각에 있어 비용 구조는 중요합니다.

Cursor Pro는 월 $20의 고정 비용으로, 무제한 코드 완성 (completions)과 "프리미엄" 모델 사용에 대한 월간 제한을 제공합니다. 이 글을 쓰는 시점을 기준으로 프리미엄 모델은 Claude Sonnet과 GPT-4o이며, 제한에 도달하면 자동으로 더 작은 모델로 전환됩니다. 비용은 예측 가능하지만, 작업당 소비량은 불투명합니다.

Claude Code는 Anthropic API 키를 통해 직접 비용이 청구됩니다. 저의 사용 패턴 — 이 정도 규모의 프로젝트에서 하루에 대략 3~5회의 복잡한 세션을 진행하는 경우 — 월간 API 비용은 세션의 복잡도에 따라 15달러에서 30달러 사이입니다. 이러한 변동성은 제가 전체 코드베이스 읽기 (full-codebase reads)를 요청하는 빈도와 타겟 편집 (targeted edits)을 요청하는 빈도의 차이에서 발생합니다. Cursor Pro보다 일관되게 저렴하지도 않으며, 일관되게 더 비싸지도 않습니다.

의미 있는 차이점은 가시성 (visibility)입니다. Claude Code를 사용하면 각 세션이 정확히 무엇을 소비했는지 확인할 수 있습니다. 반면 Cursor Pro를 사용할 때는 "12개 파일에 적용" 작업이 프리미엄 크레딧 1개를 사용했는지 아니면 10개를 사용했는지 알 수 없습니다. 인프라 비용의 모든 달러를 추적하고 있는 프로젝트의 경우, 작업당 가시성은 사용 패턴에 대한 저의 사고방식을 변화시킵니다.

실제 워크플로우를 분할하는 방법

저는 여러 파일에 걸친 문제 정의로 시작하는 모든 작업에 Claude Code를 사용합니다: "ETL이 중복 항목을 작성하고 있습니다 — upsert 로직이 어디에 있는지 찾아서 왜 동일한 ID에 대해 두 번 실행되는지 파악하세요." 이러한 종류의 문제에 대해서는 터미널 액세스 (terminal access), 파일 읽기, bash 실행이 하나의 컨텍스트 내에서 이루어지는 것이 미세 편집 (micro-edit)의 트레이드오프를 감수할 만큼 가치가 있습니다.

정말로 작은 편집 — Tailwind 클래스 조정, 컴포넌트의 오타 수정 등 — 의 경우에는 VSCode에서 파일을 직접 열어 수동으로 편집합니다. AI를 관여시키지 않습니다. 명확하고 정확한 해결책이 있는 작업의 경우, 이 방식이 두 도구 중 어느 것을 사용하는 것보다 빠릅니다.

결과적으로 제가 한 일은 편집 과정을 분할한 것입니다: 아키텍처 작업에는 Claude Code를, 정밀한 수정 (surgical fixes)에는 직접 편집을, 사소한 변경에는 AI를 사용하지 않는 방식입니다. Cursor는 이 세 가지 카테고리를 모두 다루려고 시도했습니다. 그 결과, 도구가 "대규모 자율 작업 (large autonomous operation)"과 "두 번의 키 입력으로 끝나는 인라인 수정 (two-keystroke inline fix)"을 동시에 최적화할 수 없었기 때문에 양쪽 끝에서 마찰이 발생했습니다.

정적 사이트 렌더링 선택 또한 유사한 논리를 따랐습니다. 즉, 가장 범용적인 도구를 선택하는 대신 특정 제약 조건 세트에 맞는 하나의 접근 방식을 선택하는 것입니다. 저는 개발 도구에도 동일한 사고방식을 적용하고 있습니다.

내 마음을 돌릴 수 있는 것들

세 가지 신호가 있다면 저는 다시 Cursor로 돌아갈 것입니다.

문맥 손실 (Context loss)이 임계치를 넘어 가중될 때. 만약 제가 이미 알고 있어야 할 아키텍처 결정 사항들을 새로운 Claude Code 세션에 매주 20분 이상 다시 설명하고 있다는 것을 깨닫게 된다면, 그 연속성의 공백은 더 이상 수용 가능한 트레이드오프 (tradeoff)가 아니게 됩니다. 이 임계치는 매달 평가할 수 있을 만큼 구체적입니다.

Cursor가 터미널 네이티브 에이전트 모드 (terminal-native agentic mode)를 출시할 때. Cursor는 에이전트 기능 (agentic capabilities)을 적극적으로 개발하고 있습니다. 만약 그들이 Cursor가 터미널 명령을 실행하고, 출력을 관찰하며, IDE에 집중할 필요 없이 반복 작업을 수행하는 모드 — 본질적으로 Claude Code의 bash 도구가 하는 일 — 를 출시한다면, 제가 설명한 워크플로우의 격차는 거의 제로에 가깝게 좁혀질 것입니다. 그 시점에 저는 다시 직접적인 비교를 수행할 것입니다.

작업 배분이 UI 반복 작업 쪽으로 이동할 때. 이 프로젝트는 현재 ETL 파이프라인, CI 워크플로우, 교차 게시 자동화, 쌍별 비교 페이지 생성 (pairwise compare page generation)과 같이 인프라 비중이 높습니다. 만약 프로젝트가 디렉토리 페이지의 레이아웃 실험이나 컴포넌트 A/B 테스트와 같이 주로 프론트엔드 반복 작업 위주로 성숙해진다면, Cursor가 가진 소규모 수정 / 탭 완성 (tab-completion)의 이점이 파이프라인 운영의 이점보다 커질 것입니다. 이 베팅은 부분적으로 프로젝트가 앞으로 무엇을 계속 필요로 할 것인가에 대한 주장입니다.

2026년 12월의 체크포인트

AI 디렉토리 베팅에는 2026년 10월이라는 공식적인 마감 기한이 있습니다. 이 툴링(tooling)에 대한 베팅은 좀 더 유연합니다. 데이터가 보여주는 결과에 따라 2026년 12월까지 상황을 점검할 것입니다. 저는 다음 사항들을 보고할 것입니다: 컨텍스트 손실 (context-loss)의 고통스러운 지점에 얼마나 자주 부딪히는지, 작업 분포가 여전히 인프라 중심적으로 유지되는지, 그리고 두 도구 중 어느 하나라도 제공 기능을 실질적으로 변경했는지 여부입니다. 만약 그때까지 제가 다시 Cursor로 돌아갔다면, 구체적인 이유와 함께 그렇게 말할 것입니다.

제가 하지 않을 한 가지는 모호한 신호를 낙관적으로 합리화하는 것입니다. Bluesky 자동화 품질에 대해 제가 했던 것과 동일한 약속 — 즉, 자기 검토가 아닌 체계적인 게이트 (systematic gates) — 이 여기에도 적용됩니다. 측정 결과가 제가 틀렸다고 말한다면, 저는 제가 틀렸다고 말할 것입니다.

FAQ

Claude Code와 Cursor를 동시에 사용할 수 있나요?

네, 그리고 저는 가끔 그렇게 합니다. Claude Code 세션은 터미널 창에서 실행되며, Cursor는 그 옆에서 IDE로 실행됩니다. 주요 마찰 지점은 다음과 같습니다: 만약 두 도구가 동시에 Claude Sonnet을 사용한다면, 동일한 API 속도 제한 (rate limits)을 두고 경쟁하게 됩니다. 실제로는 이 프로젝트의 작업량 규모에서 충돌이 발생하지 않았지만, 더 긴 에이전트 기반 세션 (agentic sessions)에서는 주의 깊게 살펴봐야 할 부분입니다.

Claude Code는 Cursor가 지원되는 모든 곳에서 사용할 수 있나요?

아니요. Cursor는 Mac, Windows, Linux에서 사용할 수 있는 완전한 IDE 대체제입니다. Claude Code는 터미널이 필요한 CLI (Command Line Interface)입니다. 2026년 중반 기준으로 Windows용 네이티브 GUI 경험을 제공하지는 않지만, WSL2를 통해서는 작동합니다. WSL 없이 주로 Windows를 사용하는 개발자들에게는 이것이 실질적인 차단 요소가 될 수 있습니다.

GitHub Copilot은 어떤가요 — 둘 중 하나가 이를 대체하나요?

Cursor는 자체 모델 백엔드를 사용하여 Copilot 스타일의 탭 완성 (tab completion) 기능을 포함하고 있습니다. Cursor Pro를 사용 중이라면 별도의 Copilot 구독이 필요하지 않습니다. Claude Code는 탭 완성을 제공하지 않습니다. 만약 인라인 완성 (inline completions)이 귀하의 주요 AI 코딩 용도라면, Claude Code는 Copilot의 대체제가 아닙니다. 그것은 Copilot이 되려고 시도하지 않는 다른 종류의 도구입니다.

이러한 툴링 선택이 파이프라인 자동화에 어떤 영향을 미치나요?