저는 Cursor를 사용하던 상위 0.01% 사용자였는데, 그 후 Claude Code 2.0으로 갈아탔습니다

글의 배경과 저자 관점

저자는 2021년부터 AI 코딩 도구를 적극적으로 써온 사용자로, AutoGPT 개발에 참여했고 Cursor에서도 상위 0.01% 사용량을 기록한 헤비유저다.¹

처음 Claude Code를 썼을 때는 Cursor 대비 UX와 성능이 아쉬워 금방 떠났지만, Claude Code 2.0과 Opus 4.5 조합을 기준으로 다시 써 본 뒤 완전히 주력 도구를 Claude Code 중심으로 바꾸게 되었다는 경험을 공유한다.

글 전체는 "왜 Cursor에서 Claude Code로 넘어갔는가?", "어떻게 세팅하고 써야 성능이 극대화되는가?", "에이전틱(Agentic) 코딩의 원칙은 무엇인가?"를 정리한 실무용 가이드다.

Cursor → Claude Code 전환 이유

저자는 여전히 Cursor를 높게 평가하지만, "코드를 직접 만지는 개발자 중심 IDE"에서 "행동·결과 중심 에이전트"로 사고 수준이 한 단계 추상화되는 시점에선 Claude Code가 더 맞는다고 본다.

전환의 핵심 이유는 네 가지다.

첫째, 터미널 네이티브 UX를 통한 "비동기 우선" 사고다. IDE에 있으면 눈앞 코드 한 줄 한 줄을 고치며 완벽을 추구하게 되지만, 터미널 속 Claude Code는 "행동과 결과(behavior)" 단위로 생각하게 강제한다.

둘째, Claude 모델이 Claude Code 환경에 맞게 RLHF·툴 튜닝이 되어 있다는 점이다. 같은 Opus 4.5라도 Claude Code 안에서 파일 검색, 도구 사용, 맥락 유지가 더 자연스럽고 일관되게 동작한다고 느낀다.

셋째, 비용 효율성이다. 토큰당 "일 잘하는 정도"를 기준으로 보면 Cursor 유료 플랜 대비 Claude Code가 더 많은 작업량을 뽑아준다는 인상을 받는다.

넷째, 커스터마이즈와 조합성이다. 명령(커맨드), 스킬, MCP, 서브 에이전트 등을 직접 엮어 "내 워크플로우용 시스템"을 만드는 데 Claude Code가 더 열려 있다.

Cursor와 Claude Code의 역할 분담

저자는 둘 중 하나를 버리기보다, 성격을 분리해 쓰라고 제안한다.

Cursor는 픽셀 완벽 UI, 학습용 짧은 피드백 루프, 작은 독립 변경 작업에 더 어울린다. 코드 이해를 직접 하면서 "손으로 배우고 싶은 사람"이나 "기본적인 코딩 감각을 키우려는 사람"에겐 Cursor를 기본값으로 추천한다.

Claude Code는 "결과만 원하고, 내부 구현은 최대한 추상화하고 싶은 사람"이나, 추상화 극대화를 지향하며 시스템 수준에서 설계·자동화를 하고 싶은 사람에게 적합하다. 코드 전체를 직접 알지 않아도 되는 방향으로 최대한 추상화하려는 태도와 잘 맞는다.

저자의 실제 세팅은 Claude Code(Opus 4.5)를 계획·코드 생성·복잡한 리팩터링·아키텍처 결정에 쓰고, Cursor(GPT 5.2 / Sonnet 4.5 계열)를 UI 정교화·학습·작은 수정을 위한 보조 도구로 쓰며, ChatGPT는 프로젝트 맥락이 필요 없는 질문, 계획 세컨드 오피니언, Claude 출력 설명용으로 쓴다.

에이전틱 코딩을 지탱하는 다섯 가지 축

저자는 "에이전트 기반 코딩"을 다섯 가지 기둥으로 정리한다.

첫째, 알파 캡처(Setup 자동화)다. 이 글의 핵심 노하우를 /setup-claude-code와 /setup-repo 두 커맨드에 모두 녹여 두었다고 강조한다. 한 번은 머신 단위로, 한 번은 프로젝트 단위로 실행해두면 필수 커맨드와 구조가 자동 세팅되고, 이후부터는 사용자의 아이디어만 있으면 거의 모든 코딩 루프를 Claude가 대신 수행할 수 있게 된다.

둘째, 컨텍스트 관리다. 하나의 채팅에 너무 많은 잡다한 작업을 섞지 말고, "한 채팅 ≒ 한 작업" 원칙을 지키라고 권한다. 서브 에이전트를 써서 별도 연구를 하거나, /compact로 대화를 압축해 유지하거나, /transfer-context로 중요한 맥락만 새 채팅으로 가져가는 식으로 관리한다. Claude Code는 200k 컨텍스트 제한이 있어, 어디까지 하나의 채팅으로 끌고 갈지, 언제 새 채팅으로 나눌지 판단하는 게 품질에 직접 영향을 준다.

셋째, 계획(Planning)이다. "1분을 계획에 쓰면, 이후 디버깅·추가 프롬프트에서 3분을 번다"는 경험칙을 제시한다. Plan mode(Shift+Tab 두 번)를 활용해 대화형으로 요구사항을 정리하고, 최종적으로는 repo 내 plan.md 등에 계획을 쓰게 한 뒤 구현을 시작시키는 패턴을 추천한다. 특히 /interview-me-planmd 같은 커맨드로 Claude가 사용자를 거듭 인터뷰하게 하면서, 숨겨진 요구사항·트레이드오프를 미리 표면화시키는 것이 매우 효과적이라고 강조한다.

넷째, 루프 닫기(Closing the loop)다. 예전엔 "5분짜리 일을 일주일 걸려 자동화하는 우스갯소리"가 있었지만, 에이전트 코딩에서는 이 경제성이 뒤집혔다고 말한다. 반복되는 작업, 자주 쓰는 프롬프트, 자주 수정하는 설정 등은 과감히 커맨드·에이전트·문서로 추상화하면서, "같은 생각을 두 번 이상 하지 않도록" 루프를 닫아야 한다고 주장한다.

다섯째, 검증 가능성(Verifiability)이다. 이제는 사람이 코드 한 줄 한 줄을 다 이해해야만 검증할 수 있는 시대가 아니며, 인터페이스 단에서 "행동이 맞는지"를 확인하는 것이 핵심이 됐다고 본다. UI는 눈으로, UX는 클릭과 흐름으로, API는 요청과 응답으로 검증한다. 대규모 리팩터링 전에는 인터페이스 테스트를 먼저 쓰게 해서, 리팩터링 전후 일관성을 보장하는 안전망으로 삼으라고 권한다.

Debugging과 멀티모델 활용

AI가 쓴 코드를 디버깅하는 일은 "직접 쓴 코드를 디버깅하는 것"과 다르다. 개발자가 코드의 전체 정신모델을 갖고 있지 않기 때문이다. 저자는 /debug 커맨드로 에이전트에게 진지한 조사 루프를 돌리게 한다.

에러가 발생했을 때는 가설을 세우고, 관련 코드를 충분히 읽고, 가설을 검증하는 로깅을 추가하고, 필요하면 새 채팅에서 다른 접근을 시도하고, 모델을 바꾸고, 안 되면 되돌린 뒤 다시 시도하는 식으로 단계적 접근을 취하는 것이 좋다고 조언한다.

또한 "같은 설명을 세 번 했는데도 Claude가 못 알아먹으면, 설명을 더 하는 것이 아니라 무언가 구조를 바꿔야 한다"는 'Rule of Three'를 제시한다. 최소 예시를 보여주거나, 새 채팅으로 맥락을 리셋하거나, 프롬프트 자체를 재설계해야 한다.

모델 편향을 줄이기 위해 "모델 위원회(Council of models)" 전략도 소개한다. /ensemble-opinion 커맨드로 Claude, Gemini, Codex 등의 의견을 병렬로 받아 비교하거나, PR 리뷰에는 코드를 작성한 모델과 다른 모델(OpenAI Codex 등)을 쓰는 식으로 상호 보완을 권한다. 같은 편향을 가진 모델이 자기 코드를 스스로 리뷰하면, 같은 실수를 그대로 지나칠 위험이 크기 때문이다.

리팩터링, 정리, 그리고 CLAUDE.md

리팩터링은 "기분이 나빠졌을 때" 혹은 "큰 기능을 추가한 뒤 한 번에" 하는 것을 추천한다. 세션 중간 중간 계속 청소하려 들면 흐름이 깨지고, 전체 생산성이 떨어진다는 경험에 기반한 조언이다. dead code 탐지(knip), 중복 코드 탐지(jscpd), code-simplifier 플러그인 등을 묶은 /refactor 세션으로 별도 단계로 처리하는 패턴을 사용한다.

깔끔함의 기준은 사람마다 달라서, Claude가 처음엔 사용자의 취향을 이해하지 못한다. 그래서 프로젝트마다 CLAUDE.md에 요약, 디렉터리 구조, 주요 의존성·패턴, 비표준 조직 방식, 도구·스크립트 정보, 코드 스타일 및 청소 선호 등을 점점 쌓아가는 것을 강하게 추천한다. 새 패턴을 도입하거나, Claude가 반복해서 헷갈리는 부분을 발견할 때마다 /update-claudemd로 이 파일을 갱신하면서, 에이전트를 점진적으로 "팀의 암묵지에 맞춰가는 동료"로 만들어야 한다는 관점이다.

특히 모노레포에서는 패키지 경로, 스크립트, 작업 중인 패키지 범위 등을 명시적으로 적어두지 않으면 Claude가 헤매기 쉽다고 강조한다.

도메인별 전략: 프론트엔드, 백엔드, AI 연구, 학습

프론트엔드는 설명이 난해하고 검증이 눈으로 하는 영역이라, 프롬프트와 규칙 설계가 품질에 매우 큰 영향을 준다. UI를 완벽하게 맞추는 마지막 단계는 여전히 IDE에서 사람 손으로 만져야 하는 경우가 많고, 반응형 대응도 모델이 잘 잊어버리므로 처음부터 명시적으로 요구하라고 적는다. leaf 컴포넌트는 프레젠테이셔널하게 유지하고, 비즈니스 로직은 상위에서 관리해 패턴을 명확히 보여주는 전략을 추천한다. 스크린샷을 Claude에 드래그해 UI를 설명하는 것은 강력하지만 반복 작업에는 느릴 수 있어, 필요한 순간에만 쓰는 것이 좋다고 말한다.

백엔드는 검증이 더 직관적이다. ORM(예: Prisma)을 사용하면 DB 스키마를 하나의 파일로 모델에게 제공할 수 있어 컨텍스트가 깔끔해지고, 현실적인 시드 데이터를 잘 유지하면 에이전트가 자체적으로 API를 호출해 결과를 검증하기 좋다. API 작업을 할 때는 Claude에게 API 문서와 Postman 컬렉션을 자동 생성하게 해서, 사람이 직접 엔드포인트를 찍어보며 UX를 확인하라고 권한다.

AI 연구나 실험 영역에서는 Karpathy의 예시를 인용하며, Claude가 VM에 접속해 코드 작성, 테스트, 학습 실행, wandb 로그 모니터링, 결과 요약 등을 계속 돌리는 "실험 오케스트레이터"가 될 수 있음을 보여준다. 다만 "엄청난 주장을 하는 결과"에 대해서는 여전히 인간의 엄격한 검증이 필요하다고 상기시키며, 결과를 곧이곧대로 믿고 과대망상에 빠지지 말라고 말한다.

학습 관점에서는 Claude Code가 큰 맥락의 노트북(IPYNB)을 생성해주는 데 유용하지만, 실제 개념을 몸으로 이해하려면 Cursor와 ChatGPT가 제공하는 짧은 피드백 루프, Cmd+K 기반 실험이 더 좋다고 평가한다. 또, 코드를 전부 대신 생성하게 하기보다, 틀과 빈칸을 만들게 한 뒤 직접 채우는 방식이 학습 효과에 도움이 된다고 제안한다.

고급 활용: 여러 터미널, Ralph, Subagent, Skills, MCP, Headless

저자는 실제로 IDE 없이 10개가 넘는 Claude Code 터미널을 펼쳐두고, 프로젝트당 두 개(컨텍스트 관리용, 작업용)를 쓰는 식으로 병렬 작업을 한다. 브랜치를 여러 개 만드는 대신 하나의 브랜치에 "변경 폭(Blast radius)"을 항상 의식하며 작업하고, Claude 인스턴스마다 /commit-smart로 자신이 만진 파일만 커밋하는 패턴으로 롤백 가능성을 유지한다. 가끔 잘못 겹치더라도, 되돌리는 비용이 병렬성에서 얻는 이득보다 작다는 판단이다.

Ralph는 prd.json과 progress.txt를 기반으로 여러 Claude 인스턴스를 루프에 올려 대형 프로젝트를 스프린트 식으로 돌리는 메타 에이전트 시스템이다. 저자 평가는 "셋업 대비 이득이 크지 않아서 대부분 상황에서는 과하다"이지만, 새 프로젝트 시작처럼 큰 덩어리를 쪼개서 처리할 때는 쓸 만하다고 한다. Ralph를 돌릴 때는 별도의 채팅으로 모니터링을 하며, 키워드 때문에 조기 종료되지 않도록 진행 상태 표현도 신경 써야 한다고 알려준다.

Subagent는 메인 컨텍스트를 오염시키지 않는 별도 Claude 인스턴스로, 대규모 리팩터링이나 심층 리서치, 코드 리뷰 파이프라인 등에 유용하다. 예를 들어 스타일 체크, 보안 스캔, 테스트 커버리지 검사를 각각 서브 에이전트로 병렬 실행할 수 있다.

Skills는 명령보다 한 단계 확장된 개념으로, 여러 스크립트·프롬프트를 담은 폴더를 의미한다. LLM이 필요할 때 적절한 파일을 골라 쓰는 구조이며, 코드 리뷰 기준, 커밋 메시지 포맷, DB 쿼리 패턴, API 문서 양식 등 반복 가능한 패턴을 캡슐화하는 데 활용할 수 있다.

MCP(Model Context Protocol)는 Claude가 GitHub, Slack, DB, 이슈 트래커 등 외부 서비스와 직접 상호작용하도록 연결해준다. 예를 들어 JIRA 이슈를 읽고 기능을 구현하거나, PostgreSQL을 직접 질의해 데이터를 점검하거나, Figma 디자인을 참조하거나, 이메일·슬랙 스레드를 요약하는 등 "툴 사용형 에이전트" 시나리오를 열어준다.

Headless 모드는 -p 플래그로 터미널에서 비대화형 실행을 하는 방식이다. 한 번의 프롬프트를 실행해 결과만 출력하게 할 수 있어, 자동 PR 리뷰, 자동 문서 업데이트, 자동 서포트 답변 생성 같은 파이프라인에 Claude Code를 끼워 넣는 데 유용하다. 모든 동작이 로그와 함께 남기 때문에 감사 가능성도 유지된다.

결론: 변하는 것은 도구, 남는 것은 원칙

저자는 글 마지막에서 "도구와 버전은 빠르게 바뀌지만, 남는 것은 몇 가지 원칙"이라고 정리한다.

좋은 계획의 레버리지는 계속 커진다. 모델이 강해질수록, 잘 정리된 프롬프트·계획·레포 구조가 성과에 미치는 영향은 더 커진다.

검증 가능성은 계속 중요하다. 에이전트가 일을 많이 할수록, 행동을 간단히 검증할 수 있는 인터페이스를 설계하는 능력이 핵심이 된다.

사고를 게을리하지 말아야 한다. 코드를 직접 치지 않아도, 무엇을 해야 하는지 논리적으로 분해하고 난이도를 재평가하는 일은 여전히 사람의 역할이다.

정답은 하나가 아니다. "최적의 워크플로우"는 사람마다 다르며, 각자의 취향과 경험에 따라 달라진다. 결국에는 직접 실험하고, 시행착오를 겪고, 자신에게 맞는 시스템을 만들어야 한다는 메시지로 글을 마무리한다.

참고

¹I was a top 0.01% Cursor user. Here's why I switched to Claude Code 2.0.