클로드 코드 vs 커서 비교 사용기

작성: 2025.09.15

수정: 2025.09.15

읽는시간: 00 분

Data/LLM

반응형

Intro

Claude CodeCursor는 현재 개발자들 사이에서 가장 뜨거운 관심을 받는 AI 코딩 에이전트다.

아쉽게도 아무리 찾아봐도 이 둘의 상세한 사용기를 다룬 글이 별로 없었다. X(트위터)에서 Claude 구독을 시작하며 Cursor를 해지했다는 개발자들의 후기가 종종 올라오긴 했지만, 구체적인 이유는 잘 설명되지 않았다. 그래서 직접 둘 다 써보고 비교 글을 작성해보기로 했다.

보통은 Cursor에서 Claude Code로 갈아타는 케이스가 많을 텐데, 나는 반대로 Claude Code에서 Cursor로 넘어간 케이스다.

Claude Code를 만족하며 썼지만, $20짜리 Pro 플랜은 업무용으로 쓰기엔 리밋에 너무 자주 걸렸다. MAX 플랜은 금액이 부담스러운 상황에서, 마침 Cursor CLI가 출시되기도 해서 한 번 써보기로 했다. 회사에서 지원해주는 Cursor Team Plan($40)에 참여한 것도 그 계기였다.

Cursor CLI

Cursor 사용을 시작할 때만 해도 Cursor CLI만 사용할 예정이었지만 CLI는 후술할 여러가지 이유로 거의 사용하지 못했다.

Team Plan에서는 월 총 500회 사용량 제한이 있다. 그런데 버그인지 Cursor CLI를 쓰면 토큰 수에 비해 사용량이 터무니없이 빠르게 소모됐다.

13

맨 위의 1, 1, 1, 1, 1 , 2를 제외한 모든 소수점 있는 요청들이 Cursor CLI로 보낸 요청이다.

683.7K 토큰짜리 요청이 무려 19.9 request 를 사용했다. 위의 커서 IDE 에서 보낸 요청을 보면 1M 짜리도 1회만 차감할 뿐인데 말이다.

컨텍스트가 조금만 늘어나면 맛이 가고 응답이 안 나온다. 사용량 조회를 해보면 말도 안 되는 MAX 딱지가 붙어 저 상태로 고정돼 있다.

분명한 버그라 Cursor 팀에 문의도 남겼는데, "미안하다"고 $10 크레딧을 넣어준 후로 일주일 넘도록 아무런 소식이 없다.

2

비용은 차치하더라도, Claude Code와의 비교를 위해 그리고 개인적으로 터미널 환경을 선호해서 끝까지 CLI를 고집하고 싶었지만, 문제가 너무 많았다.

토큰 수가 조금만 많아지면 응답이 안 오는 일이 비일비재하고, 차라리 응답이 안 오면 다행이지 혼자 주저리주저리 하며 토큰만 한참 동안 소모하다가 아무런 액션이 없을 때가 많다. 나름 Claude Code와 비슷한 기능을 구현하려고 UI/UX는 흡사하게 해놓은 것 같은데, 핵심 기능이 엉망이다.

한동안 Beta 딱지를 떼기는 힘들 것 같다. Cursor CLI는 지금 기준으로는 도저히 써먹을 만한 게 아니라는 결론을 내렸다.

이제부터는 Cursor CLI가 아닌 IDE 기반의 Cursor 에디터와 Claude Code가 비교 대상이다.

비교기

커밋

커밋 작업은 프로젝트의 전체적인 맥락과 코드 흐름, 작업 내용을 어느 정도 이해하고 있는지 알아보기 좋은 지표라고 생각한다.

Claude Code 의 커밋

"커밋해줘"라고 한마디만 하면 정말 알아서 다 해준다. 최근 커밋들을 조회해서 커밋 메시지 컨벤션을 확인하고, 최종 커밋으로부터의 변경사항들을 체크한 뒤 적절한 커밋 메시지를 작성한다. 커밋 컨벤션을 지키면서 최대한 자세히 쓰고, 마지막에는 본인이 같이 코드에 참여했다고 Co-Authored-By에 자기 이름까지 껴넣는다.

더 놀라운 건, 디버깅 중에 실수로 남겨둔 System.err.println() 같은 커밋에 포함할 의도가 없는 코드가 있으면 따로 말하지 않아도 알아서 스테이지에 넣지 않고 커밋해준다는 점이다. 사소한 수정 하나하나도 허투루 하지 않고 확인하며 커밋한다는 증거다. 커밋에서의 이런 디테일은 항상 인상 깊다.

Cursor의 커밋

Cursor에서도 커밋을 시켜봤는데, 컨벤션이고 뭐고 무시하고 자기 멋대로 한다. 당연히 "최근 깃 히스토리 보고 컨벤션 확인해 비슷하게 메시지 입력하고, 구현한 걸 어떻게 표현할지 설명해"라고 구체적으로 지시하면 따르긴 한다. 그런데 그렇게 말 안 해주면 절대 안 한다. Claude Code에서는 "커밋해줘" 한마디로 다 알아서 했던 것들인데 말이다.

더 충격적인 건 그 후에 발생했다. 커밋 후 대화를 유지한 상태에서 다른 작업을 추가로 시키니 코드를 열심히 변경하더니, 자기 멋대로 커밋까지 해버렸다. 수정 내용에 대한 검토나 테스트는 신경 쓰지 않는다.

그래서 이걸 니 맘대로 커밋하냐고 뭐라 한마디 했더니 다짜고짜 미안하다며 git reset을 해버린다. --soft--mixed면 말도 안한다. --hard 붙여서 그냥 다 날려버렸다. 좀 뭐라 그랬다고 삐졌나? 이때 진짜 얘는 뭐하자는건가 싶었다.

코드 되돌리기

마지막 프롬프트로부터의 코드 변경사항이 마음에 들지 않았을 때, 마지막 커밋 이후에 작업한 내용이 남아있는 상태에서 코드를 되돌리자고 할 때의 차이도 컸다.

Claude Code에서는 마지막 프롬프트에서 추가한 작업들만 되돌렸지만, Cursor에서는 어쩌라고 하며 git restore를 수행해버린다. 작업 내용 날려먹고선 뻔뻔하게 "깔끔해졌어요"라고 뿌듯해하는 건 덤이다.

Claude-4-Sonnet-Thinking

Cursor에서의 claude-4-sonnet 모델은 Claude Code에서의 Sonnet4와 비교했을때 같은 모델이 맞나 싶을 정도로 체급 자체가 부족한 느낌이었는다. 그러나 구세주가 나타났으니 Thinking 모델로 바꾸니 "나 적어도 모델은 같은건 맞아요"라는걸 이해하고 받아들일 수 있을 정도는 됐다. 아마 Claude Code 에서는 Cursor에서 말하는 Thinking 모델이 기본 모델인 듯 하다.

다행히도 근본적으로 해결되지 못하는 문제들은 차치하더라도 Thinking 모델을 붙여놓고 쓰면 그래도 Claude Code 쓰던 경험의 80% 이상은 커버가 되었다. 쓸만 하는 이야기다.

다만 여전히 토큰 사이즈와 무관하게 월 요청 횟수 제한 기반으로 과금되는 시스템이라, 어떻게든 응답을 한 번에 뱉으려는 경향이 있다. 잔걸음으로 코딩하기는 힘들고 아깝다. Cursor에서는 한 번에 최대한 충분한 컨텍스트를 밀어넣고 작업이 잘 되기를 바라는 '기도 메타'가 주류인 이유다.

AI와의 협업에서 짧은 호흡으로 목표를 Align하며 차근차근 쌓아가고, 잦은 커밋으로 안정적으로 진행하는 내 스타일로는 사용량이 x2인 Thinking 모델을 쓰면 일주일 만에 리퀘스트를 다 소모한다.

다중 모델 지원

Cursor는 여러 벤더의 다양한 모델을 지원하는 구조라, 사용자 수요에 맞춰 모델을 선택할 수 있다는 점이 얼핏 장점처럼 보인다.

하지만 iOS와 안드로이드에 비유하면 이해하기 쉽다. iOS는 애플의 한정된 기기에서만 작동하기에 메모리, 배터리, 성능 최적화에서 큰 이점을 가진다. 관리 포인트가 늘어나는 건 피곤한 일이다.

Sonnet, GPT-5 등 여러 모델을 번갈아가며 사용해봤지만 결국 Sonnet Thinking만 고정하고 사용하게 되었다.

Cursor를 쓰면서도 결국 대부분의 사용자는 한가지 주력 모델만 사용하게 되기 때문에 여러 모델 중 선택할 수 있다는게 굳이 장점이 될 수 있을지 모르겠다. 한곳에 의지하다가는 사업이 불확실성에 대응하기 힘들어 여러 모델을 사용할 수 있게 했을텐데 고객의 편의보다는 어쩔 수 없는 생존 전략일 것이다.

Claude Code 강점

Claude Code에서는 컨텍스트 확대가 필요하면 알아서 코드베이스를 찾아 시간을 추가로 할애한다. 될 때까지 말이다. 사용자가 토큰을 많이 쓰는 데 개의치 않으므로, 수익 모델상 토큰을 아껴야 하는 Cursor는 꿈도 못 꿀 일이다. 신규나 작은 프로젝트에서는 차이가 적지만, 코드베이스가 큰 레거시 프로젝트에서는 체감이 크다.

서버에 배포할 때도 Claude Code 하나만 딸랑 설치해두고 채팅 몇 번 하면 필요한 세팅 아주 쉽게 싹다 할 수 있다. 에러가 발생해도 스스로 알아서 대응해주기 때문에 에러메시지 읽고 대응하고, 모르는건 LLM에 물어보고 하라는대로 다시 복사해서 실행하고 하는 등의 번거로운 작업이 아주 간소화 된다. 터미널을 종료해도 나중에 /resume으로 이어갈 수 있다는 것도 큰 장점이다.

psql 같은 걸로 스스로 테이블도 뭐있는지 확인하고 쿼리도 직접 날려보면서 확인한다. Solr 같은 검색엔진도 주소만 알려주면 curl로 스스로 쿼리 날려보며 작업한다. 이런 주도적인 모습이 굉장히 인상깊다. docker 컨테이너들도 알아서 오케스트레이션 한다.

비슷한 걸 Cursor에 시키니 할 수는 있지만, 왠만하면 안 하려 한다. 터미널 명령어로 간단히 확인할 걸 굳이 Python 코드로 작성하는 경향이 있다.

Claude는 필요할 때 스스로 서브 에이전트를 생성해 병렬 작업하는 점도 놀랐다.

무엇보다 IDE를 안 가린다는 게 큰 장점이자 단점이다. macOS나 Linux 사용자에게는 최고지만, Windows 유저들은 터미널 환경이 불편할 수 있다.

결론

cursor를 쓰며 달라진 점들

  • AI와 싸우는 일이 늘었다: Claude Code에서는 알아서 하던 것들을 Cursor에게 구구절절 일일이 설명해야 한다.
  • 타이핑이 늘었다: 위의 이유로 컨텍스트를 주구절절 설명하느라 타이핑 양이 늘었다.
  • Rule 설정의 필요성: Cursor에서 rule을 추가해야 잘 쓸 수 있다는 게 이해가 가지만, Claude Code 사용자 입장에서는 코드에 녹아든 내용들을 다시 설명해야 한다는 게 어렵다.
  • Claude 사용할 때는 IntelliJ IDEA만 썼는데, Cursor 때문에 두 IDE에 큰 프로젝트를 동시에 띄우니 리소스 사용이 장난 아니다. 컴퓨터가 버거워하는 게 느껴진다.

새롭게 깨달은 사실들

  • 5 hours window limit의 관대함: Claude Code $20 요금제의 5시간 제한이 사실 엄청 후한 거였다는걸 깨달았다. context만 한번씩 clear 혹은 compact 해주면 그래도 나름 꽤 쓴다. 요금제를 따지고 보면 가성비면에서 사실 MAX 플랜이랑 비교해도 Claude 압승이다. Cursor에서 Opus 모델을 계속 쓴다면 사용요금이 과연 $100~$200 에서 끝날 수 있을까?
  • Auto Accept: Claude Code에서는 auto accept를 쓰면 땡이라서, Cursor 사용자들의 눈으로 보고 판단해야 해서 에디터가 필요하다는 주장을 납득할 수 없었지만 이제는 이해할 수 있게 됐다. Cursor의 결과물은 auto accept 했다가는 다시 고치는데 시간이 더 걸릴 것이다.

그 외 차이

집에서는 Mac, 회사에서는 Ubuntu OS를 사용하니 터미널 환경이 훨씬 편하고 기능이 강력하다. Windows 를 썼다면 Cursor를 썼을지도 모르겠다.

그리고 애초에 Cursor와 Claude Code 는 1:1로 비교할 만한 비교군이 아니라고 생각한다. 프레임워크와 라이브러리의 차이, 즉 Inversion Of Control을 생각해보면 된다. Cursor를 썼을 때는 Cursor의 도움을 받아 내가 주도적으로 코딩을 했다면 Claude Code는 Claude가 스스로 알아서 하고 난 그걸 매니징할 뿐이다. 전체적인 주도권을 쥐고 코딩하고 싶다면 Cursor가 더 손에 맞을 것이다.

솔직히 말해 작성하는 코드 퀄리티 자체는 크게 차이가 없었다. 하지만 전체적인 맥락을 이해하고 작성된 코드인지 아닌지에 따라 그 방향이나 소모되는 시간의 차이가 크게 달라진다. 아무리 좋은 코드도 적절한 때와 장소가 아니라면 추가로 청소해야 할 대상일 뿐이다.

최종 결론

한동안 사용해보니 내겐 알잘딱깔센 Claude Code가 더 잘 맞았다.

사실 여러 차이들이 존재하지만, 각자의 환경과 필요에 따라 더 적합한 도구가 다를 수 있다. Cursor도 분명히 장점이 있고, 특히 에디터와 긴밀하게 통합된 환경을 선호하는 사람들에게는 좋은 선택이 될 수 있다.

터미널 환경에 익숙하고 Claude Code를 먼저 써본 입장에서는 AI가 더 주도적으로 알아서 센스있고 섬세하게 작업을 해줘서 훨씬 편리했다는게 솔직한 소감일 뿐이다.

너무 Claude Code 편만 들어서 쓴 것 같지만, Cursor도 잘 쓰고 있다. 오늘 소감일 뿐, 한두 달 후엔 어떻게 될지 모른다.

그래도 자체 모델을 보유한 Anthropic 앞에서 Cursor가 살아남기 힘들 거라는 게 내 의견이다. 급하게 낸 엉망인 Cursor CLI의 완성도가 그들의 위기감을 보여준다. 끝

참고할만한 다른 사용자의 후기들

반응형