30초 결론: 작업 환경과 권한 설정을 비교하세요#
Cursor는 에디터와 CLI에서 코드를 다루고, Claude Code는 터미널과 IDE 등에서 작업을 위임할 수 있습니다. 작업 환경과 권한 설정을 기준으로 비교해 보세요. 에디터에서 diff를 살펴보는 흐름을 원한다면 Cursor가, 터미널에서 작업을 맡기고 결과를 검토하는 흐름을 원한다면 Claude Code가 선택지가 됩니다.
작업 환경과 도구 설명은 Cursor Agent, Cursor CLI, Claude Code 개요를 참고했습니다 (2026-11-01 확인).
한국어 개발자라면 한 가지 더 물어봐야 합니다. 한국어로 지시하고 한글 파일명과 한글 주석이 섞인 저장소에서 한국어로 결과를 확인하는 일이 자연스러운가? 이 질문에 대한 답은 도구마다 다릅니다. 아래에서는 인터페이스와 권한, 한국어 작업 흐름, 가격을 같은 기준으로 비교합니다.
한눈에 보기#
| 항목 | Cursor | Claude Code |
|---|---|---|
| 기본 인터페이스 | 에디터와 CLI | 터미널(CLI) 중심, IDE·데스크톱도 제공 |
| 작업 방식 | Agent가 파일 검색·수정과 명령 실행 | 에이전트가 파일을 읽고, 고치고, 실행 |
| 모델 선택 | 플랜별 선택 가능 모델이 다름 | Anthropic Claude 모델 |
| 컨텍스트 | 열린 파일, 인덱싱된 프로젝트, @-멘션 등 | 관련 파일과 도구 실행 결과 등 |
| 권한 | 작업 종류와 설정에 따라 다름 | 승인 모드와 권한 규칙에 따라 다름 |
| 한국어 | 실제 환경에서 입력·출력 확인 권장 | 실제 환경에서 입력·출력 확인 권장 |
| 가격(미국 공식 페이지 세전, 2026-11-01 확인) | Free · Plus $8 · Premium $30 · Super $100 · Ultra $200 | Pro $20(연간 결제 시 월 $17) · Max $100 · Ultra $200 |
| 살펴볼 작업 방식 | 에디터에서 편집·리뷰, CLI 자동화 | 터미널에서 작업 위임·리뷰, CI 자동화 |
- 작업 환경: Cursor는 에디터와 CLI를, Claude Code는 터미널과 IDE 등에서 작업하는 방식을 제공합니다. 사용할 환경을 기준으로 고르세요. (Cursor Agent, Claude Code 개요)
- 승인과 자동화: Cursor와 Claude Code 모두 권한 설정을 확인해야 합니다. CI를 고려한다면 Cursor CLI의 비대화형 모드와 Claude Code의 인증 방식을 비교하세요. (Cursor 보안, Cursor CLI, Claude Code 권한, 인증)
- 모델과 비용: Cursor는 플랜에 따라 모델 선택과 추가 과금이 다르고, Claude Code는 구독 외에도 Console이나 클라우드 제공업체를 통해 사용할 수 있습니다. (Cursor 요금제, Claude Code 인증)
표의 가격은 미국 공식 페이지에 표시된 세전 미국 달러 월 요금입니다. 2026-11-01 확인한 Cursor 요금제와 Claude 요금제를 기준으로 했습니다. 한국에서는 부가가치세가 포함되어 표시될 수 있으므로 지역별 결제 화면의 최종 금액을 확인하세요. 신규 Premium 이상에서 타사 모델을 사용량에 따라 별도 과금합니다.
2026-11-01 확인 기준 Cursor 요금표는 신규 Plus에 Grok 모델만 사용 가능하다고 설명하지만, 모델 요금 문서는 Grok 외에 Composer 2.5도 명시합니다. 실제 이용 범위는 현재 계정과 결제 화면, 모델 선택기에서 확인하세요.
Cursor가 강한 경우#
에디터 안에서 바로 고치고 싶을 때 Cursor가 편합니다. Tab 자동완성, 인라인 diff, Agent 모드가 한 화면에 있으므로 파일을 열어 놓고 하나씩 승인하며 작업할 수 있습니다. VS Code의 확장과 키바인딩도 그대로 가져옵니다.
변경을 눈으로 확인하고 승인하고 싶을 때 Cursor의 diff UI가 좋습니다. 큰 변경을 한 번에 수락하기보다, 어디가 바뀌는지 보고 고르는 작업에 강합니다.
모델을 선택해 쓰고 싶을 때 Cursor의 선택지는 플랜에 따라 다릅니다. 신규 Plus의 모델 범위는 위의 출처 차이를 참고하세요. Premium 이상에서는 타사 모델을 별도 과금으로 사용할 수 있습니다. Cursor 요금제를 확인하세요.
Claude Code가 강한 경우#
저장소의 관련 파일을 찾아 작업을 이어가고 싶을 때 Claude Code에 파일 검색과 수정, 명령 실행을 요청할 수 있습니다.
큰 리팩토링과 긴 작업을 맡기고 싶을 때 Claude Code는 터미널에서 여러 파일을 오가며 작업할 수 있습니다. 변경 범위와 테스트 결과는 직접 확인해야 합니다.
터미널과 CI에서 일하고 싶을 때 Claude Code는 CLI 중심이라 SSH, 서버, CI 컨테이너에서도 작업할 수 있습니다. claude 실행 후 /init으로 CLAUDE.md를 만들어 프로젝트 규칙을 고정할 수 있습니다.
같은 리팩토링 과제: 에디터에서 고치기 vs 터미널에서 승인하기#
UserProfile을 UserAccount로 바꾸는 8개 파일 리팩토링을 가정해 봅시다.
Cursor에서는 관련 파일을 찾고 diff를 검토하는 흐름을 사용할 수 있습니다. Agent도 명령을 실행할 수 있으며, 권한은 작업 종류와 설정에 따라 달라집니다. Agent 도구와 보안 설정을 확인하세요.
Claude Code에도 파일 수정과 테스트 실행을 요청할 수 있습니다. 권한 모드에 따라 중간에 승인이 필요할 수 있으며 결과는 직접 검토해야 합니다.
두 도구 모두 작업 환경과 승인 설정을 바꿀 수 있습니다. 이 예시는 가상의 작업이며 속도나 승인 횟수를 측정한 비교는 아닙니다.
가격: 구독료와 사용량을 같은 표에 놓기#
| 플랜(미국 공식 페이지 세전) | Cursor | Claude Code |
|---|---|---|
| 무료 | $0, 제한된 사용 | Claude 무료 구독에 미포함 |
| 개인 입문 | Plus $8 | Pro $20(연간 $17) |
| 개인 상위 | Premium $30 · Super $100 · Ultra $200 | Max $100 · Ultra $200 |
| 팀 | $30/사용자/월부터 | Team·Enterprise 요금제 별도 확인 |
| 추가 비용 | 플랜과 모델에 따라 추가 사용량 또는 타사 모델 별도 과금 | 구독 한도·추가 사용량 또는 API 사용량에 따라 다름 |
두 도구 모두 정가보다 실제 사용량에 따른 비용이 중요합니다. Claude Code는 개인 구독 외에도 Console 및 클라우드 제공업체 인증을 지원합니다. 인증 방식에 따른 과금을 함께 확인하세요.
Cursor 가격 페이지의 추가 비용 구조는 플랜이 어떤 모델을 포함하고 어떤 모델을 사용량으로 과금하는지부터 규정하며, 2026-11-01 확인 기준 신규 Plus는 Grok 모델에 한정된다고 한 안내와 모델 요금 문서의 Composer 2.5 언급은 같은 공식 자료 안에서도 읽을 곳이 다릅니다. Claude Code의 비용 구조는 그와 다른 축으로 나뉘며, Pro와 Max, Ultra 구독은 Claude 모델의 개인 사용을 담고 Console과 클라우드 제공업체 경로는 그 구독과 다른 계정의 API 사용량이 별도 계약으로 청구되는 채널입니다. Cursor에서는 총비용의 움직임이 어떤 모델을 선택했는가와 플랜의 모델 포함·과금 규칙에 연결되고, Claude Code에서는 구독 로그인과 Console·클라우드 제공업체 접속 중 어떤 경로로 작업했는지가 청구처를 결정합니다. 그래서 가격 비교 기록에는 선택한 모델, 발생된 추가 사용 항목과 로그인 경로를 같은 줄에 남겨 두어야 하며, 월 단가만 모은 총액은 다음 비교에서 같은 모델과 경로 선택이 전제되어야 같은 구조를 유지합니다. 이 구분을 남기면 다음 갱신 결정에서 어느 구조의 지출이 늘었는지 분리해 읽을 수 있습니다.
커서 vs 클로드 코드 디시: 공개 후기 읽기#
‘커서 vs 클로드 코드 디시’로 실제 사용 경험을 찾는다면 작성일과 작업 맥락부터 확인하세요. 아래는 2026-11-02에 원문을 읽은 공개 게시물 두 건의 제한적인 예시입니다. 표본을 정해 수집한 설문이 아니며 커뮤니티 전체를 설명할 대표성은 없습니다.
| 공개 글·작성일 | 글쓴이가 적은 경험 | 이 글에서 확인할 수 없는 것 |
|---|---|---|
| 특이점이 온다: 슬슬 커서 구독 해지할까 고민되네, 2026-02-03, ‘ㅇㅇ’ | 자동완성에 만족했지만 이후 CLI에 작업을 맡기고 출력 코드를 확인하는 흐름으로 바뀌어 Cursor 유지 필요성을 고민한다고 서술 | 같은 과제의 모델·설정, diff·테스트와 현재 이용 조건 |
| 클로드 갤러리: 클로드 코드 한달차 후기, 2025-09-15, ‘탁갤러’ | CLI 방식에는 만족하면서도 작은 작업의 대기와 반복 요청을 불편하게 느껴 “이런 경우 커서랑 병행해서 사용하면 괜찮을듯”이라고 서술 | 작성자가 보고한 결과의 독립 재현, 이후 버전에서의 지연·오류, 다른 사용자에게도 같은지 여부 |
첫 글은 작업 방식이 바뀌면 구독의 가치도 달라질 수 있다는 개인 경험이고, 둘째 글은 CLI 만족과 편집기 병행을 함께 언급한 개인 경험입니다. 이 두 글로 어느 도구가 보편적으로 더 낫다고 결론 내릴 수 없습니다. 당시 요금제·모델명과 오류를 현재 조건으로 옮겨 적지도 않았습니다. 현재 가격과 기능은 위 공식 출처에서, 자신의 과제 결과는 같은 저장소와 테스트로 따로 확인하세요. 글쓴이의 실명이나 직업, 실제 실행 결과를 이 페이지가 인증한 것은 아닙니다.
한국어 워크플로에서의 차이#
한국어 개발자에게는 세 가지가 실제로 중요합니다.
- IME와 한글 입력. 한글 조합과 커서 동작은 에디터, 터미널, OS와 IME 설정에 따라 직접 확인해 보는 것이 좋습니다.
- 한글 파일명과 경로. 한글 파일명, 한글 경로, NFD/NFC 파일명이 섞인 저장소에서 검색과 편집이 잘 되는지 확인해야 합니다. 두 도구의 검색 결과와 터미널 출력에서 한글 파일명이 바르게 보이는지는 직접 시험하세요.
- 한국어 출력과 리뷰. 코드 수정 설명, 오류 메시지, 리뷰 코멘트가 한국어로 자연스럽게 나오는지가 중요합니다. 두 도구 모두 한국어 입력은 되지만, 출력은 설정과 모델에 따라 달라집니다. 한국어로 끝까지 일하는 흐름이 필요하다면, 그 부분을 직접 테스트해 보는 것이 좋습니다.
HWPX 보고서나 엑셀 자동화 같은 한국어 문서 작업이 많다면, 단순한 코드 편집보다 문서 형식과 한국어 문맥을 이해하는 능력이 더 중요해집니다. 그런 작업에서는 터미널 에이전트가 스크립트를 만들고 실행하는 방식이 더 자연스럽습니다.
Tab 제안과 작업 위임을 따로 평가하는 법#
자동완성은 지금 쓰는 코드의 다음 부분을 제안하는 일이고, 작업 위임은 요구사항을 읽고 여러 행동을 묶어서 수행하는 일입니다. 두 기능을 한 번의 만족도 질문으로 평가하면 어느 부분이 도움이 됐는지 알기 어렵습니다. Cursor에서 Tab을 자주 쓰던 사람이 Claude Code로 긴 수정을 맡기기 시작해도 자동완성의 필요가 사라졌다고 볼 수는 없습니다. 반대로 터미널 에이전트를 쓴다는 이유로 모든 작은 수정까지 대화로 요청할 필요도 없습니다. 자신이 직접 쓰는 구간과 맡기는 구간을 나눠야 구독의 가치를 비교할 수 있습니다.
가령 함수 인자의 이름을 바꾸는 동안 바로 다음 줄의 호출을 손으로 고친다면 제안을 읽고 채택하는 흐름이 평가 대상입니다. 여러 패키지의 공개 타입을 바꾸고 테스트를 맞추도록 맡긴다면 파일 탐색, 계획, 수정, 명령 실행과 결과 보고가 대상입니다. 같은 리팩토링 안에서도 두 구간은 섞입니다. 직접 고친 줄을 에이전트가 생성한 줄로 집계하거나, 에이전트가 찾아낸 영향 범위를 Tab의 성능으로 설명하면 비교가 흐려집니다. 기록에는 사용한 기능과 사람이 개입한 내용을 따로 남기세요.
Cursor를 선택할 이유는 파일을 보며 판단하는 시간이 자신의 일에서 큰 비중을 차지할 때 더 구체적입니다. 화면에서 변경을 읽고 바로 주변 코드를 열어 보는 습관이 있다면 그 흐름을 유지할 가치가 있습니다. Claude Code를 선택할 이유는 터미널에서 조사와 실행을 묶어 맡기려 할 때 구체화됩니다. 어느 쪽이든 결과를 검토할 사람이 필요합니다. 이 페이지에는 두 흐름의 소요 시간을 측정한 자료가 없으므로 편집기 사용 시간이 길다는 사실만으로 속도 우위를 계산하지 않습니다.
승인 횟수보다 승인 범위를 먼저 읽기#
2026-11-03 추가로 읽은 Cursor 실행 모드는 로컬 에이전트의 Auto-review, Allowlist와 Run Everything을 구분합니다. Auto-review의 분류기는 실수할 수 있으며 보안 경계가 아니라고 문서가 명시합니다. Claude Code 권한도 권한 모드와 도구별 규칙을 나눕니다. 따라서 승인 창이 적었다는 관찰은 그 자체로 안전하거나 생산적이었다는 증거가 아닙니다. 이미 넓은 권한을 허용한 환경에서는 같은 작업이 덜 멈출 수 있습니다.
승인을 셀 때는 창의 수와 허용한 행동의 수를 구분하세요. 한 번의 선택이 해당 명령만 허용하는지, 반복되는 명령 계열이나 세션 동안의 파일 수정을 허용하는지에 따라 의미가 달라집니다. 실행 전에 허용 범위를 적지 않았다면 사후에 프롬프트 수만 비교하지 않는 편이 낫습니다. 문서상의 기본값과 자신의 저장소에서 적용되는 최종 설정도 다를 수 있습니다. 팀 정책, 개인 설정과 프로젝트 설정을 함께 확인한 뒤 기록에 실제 적용 범위를 붙이세요.
권한은 행동을 실행할 수 있는지 결정하고, 샌드박스는 실행 중 접근할 수 있는 자원을 제한합니다. 둘을 같은 기능으로 보지 마세요. 문서에 샌드박스가 있다고 해서 모든 MCP 도구나 모든 네트워크 요청이 같은 경계 안에서 처리되는 것도 아닙니다. Claude Code v2.1.278의 설정 예제 안내는 sandbox 속성이 Bash 도구에 적용되며 다른 도구와 훅에는 적용되지 않는다고 설명합니다. 같은 README는 예제가 지원되지 않거나 부정확할 수 있다고 경고하므로, 실제 정책 시험 없이 이 설명을 전체 도구의 차단 보증으로 확대하면 안 됩니다.
| 비교할 승인 사건 | 기록에 남길 범위 | 성급한 해석을 피하는 질문 |
|---|---|---|
| 파일 수정 승인 | 허용한 경로와 유효 기간 | 한 파일만 허용했는가, 세션의 수정 전체인가? |
| 테스트 명령 승인 | 명령, 작업 디렉터리와 실행 권한 | 테스트가 외부 서비스나 설치 훅을 부르는가? |
| 샌드박스 밖 재시도 | 최초 제한, 재시도 사유와 확장 범위 | 단순 실패를 이유로 필요 이상의 접근을 허용했는가? |
| MCP 호출 승인 | 서버, 도구, 읽기·쓰기와 대상 | 로컬 diff에 나타나지 않는 외부 변경이 있는가? |
| 반복 허용 선택 | 저장된 규칙과 이후 적용 범위 | 이번 과제를 넘어서 권한이 남는가? |
표는 승인 기록을 설계하기 위한 기준입니다. 실제 프롬프트의 수나 차단 성공을 채워 넣은 결과표가 아닙니다. 시험할 때는 자신에게 승인 권한이 있는 합성 저장소를 쓰고, 위험한 명령을 실제로 실행해 보려 하지 말고 허용돼야 할 작업과 거부돼야 할 작업의 경계를 먼저 합의하세요. 삭제, 배포, 외부 전송은 리팩토링에 필요한 권한으로 묶지 않습니다. 경계를 바꾸었다면 이전 조건에서 얻은 결과와 새로운 조건의 결과를 나눠 보관하세요.
이름 변경 과제를 실제로 비교할 때의 수용 기준#
두 도구에는 같은 기준 커밋에서 분리한 작업 공간을 주는 방식이 적절합니다. 다른 사람이 이미 수정한 파일을 덮어쓰지 않도록 미커밋 변경을 먼저 분류하고, 비교에 포함할 파일을 확정하세요. 한쪽에만 이전 대화의 설계 설명을 주거나 다른 쪽에는 테스트 위치를 알려 주지 않는다면 입력 조건이 달라집니다. 공통 요청서에는 예상 동작과 변경 금지 영역을 담고, 도구별 규칙 파일의 차이는 별도로 적습니다. 동일한 모델을 쓸 수 없는 경우에는 그 차이를 감추지 마세요.
첫 검토에서는 변경이 요구한 이름과 연결되는지 봅니다. 파일이 많거나 diff가 크다는 사실만으로 나쁜 결과는 아닙니다. 공개 타입의 사용처가 넓다면 필요한 변경도 커질 수 있습니다. 반대로 diff가 작아도 오래된 호출부가 남았다면 과제는 끝나지 않았습니다. 변경 파일마다 이름 변경, 필요한 테스트 수정, 관련 없는 정리 중 어느 범주인지 표시하면 검토가 수월합니다. 관련 없는 포맷 변경은 기능 실패와 구분해 리뷰 부담으로 남기고, 삭제된 테스트는 단순한 줄 수 감소로 칭찬하지 않습니다.
검증 명령도 미리 정하세요. 기존 실패가 있다면 시작 상태에서 관찰한 실패를 남겨 새 실패와 구분합니다. 도구가 실행했다고 말한 명령과 실제 출력이 있는 명령도 구분해야 합니다. 결과 보고에 성공이라고 적혀 있어도 출력이나 종료 상태가 없으면 검증 완료로 집계하지 마세요. 한쪽만 검증 환경을 준비할 수 없었다면 실패를 숨기지 말고 환경 준비 문제로 기록합니다.
사람이 고친 뒤에는 최초 결과와 최종 결과를 나눕니다. 에이전트가 놓친 호출부를 사람이 고쳐 통과했다면 최종 저장소는 정상일 수 있지만 최초 생성 결과의 누락은 남습니다. 다시 요청해 고쳤다면 추가 요청과 사용량, 승인 사건도 비교에 포함합니다. 이 구분이 있어야 처음부터 잘한 도구와 여러 차례 개입으로 고친 도구를 같은 성공 칸에 넣는 일을 피합니다. 다만 한 과제에서의 차이는 그 과제에 한정되며 모든 저장소의 성능 순위로 확장하지 않습니다.
병행 사용에서 충돌을 줄이는 인계 방식#
Cursor와 Claude Code를 함께 쓸 때는 같은 파일을 동시에 고치지 않는 운영 규칙이 먼저입니다. 에디터에서 보던 내용이 터미널 작업으로 바뀌었는데 오래된 버퍼를 저장하면 최신 변경을 덮어쓸 수 있습니다. 이 위험은 특정 제품의 결함을 주장하는 것이 아니라 공유 파일을 다루는 작업 방식의 문제입니다. 한쪽이 수정 중일 때 다른 쪽은 읽기와 검토로 역할을 나누고, 담당을 바꾸기 전에 실제 디스크의 diff를 다시 확인하세요. 저장소 전체를 다시 시작하는 대신 변경 경계를 명확히 잡는 편이 낫습니다.
인계 메모에는 완료한 변경, 미해결 질문, 실행한 검증과 실행하지 않은 검증을 담습니다. 이전 대화 전문을 붙여 넣는 것보다 현재 파일과 수용 기준을 연결하는 짧은 기록이 실용적입니다. 특히 실패한 테스트의 원인 가설은 관찰과 분리하세요. 오류가 났다는 사실과 어떤 코드 때문에 났다는 추정은 다릅니다. 두 번째 도구가 가설을 확정 사실로 받아 수정하지 않도록 오류 출력의 관련 부분과 재현 조건을 남깁니다. 비밀값과 고객 자료는 인계문에서 제외합니다.
비용 역시 병행 여부에 맞춰 봐야 합니다. 이미 내는 구독료를 신규 도입 비용으로 다시 더할지, 다음 갱신 때 줄일 수 있는 지출인지 구분하세요. 두 구독을 잠시 유지하며 비교하는 기간의 지출과 장기 운영비는 다른 숫자입니다. 대기 시간을 줄이려고 별도 API 키를 연결했다면 어느 계정의 요청인지 적어야 합니다. 이 페이지의 표시 가격을 합산해 개인의 월 총액이라고 부를 수는 없습니다. 현재 계약, 포함 사용량과 실제 추가 청구가 있어야 총액을 계산할 수 있습니다.
한국어 요청의 정확도를 검토하는 질문#
한국어 평가에는 자연스러운 말투와 정확한 요구 이행을 따로 넣으세요. 설명이 매끄러워도 바꾸지 말라고 한 공개 이름을 바꾸었다면 실패입니다. 한글 파일을 열었다고 해서 인코딩과 경로 처리가 모두 검증된 것도 아닙니다. 원래 파일명과 수정 후 파일명을 확인하고, 검색 대상과 실제 변경 경로가 일치하는지 보세요. 조합 중 입력, 줄바꿈, 복사한 오류 메시지는 사용하는 터미널과 에디터에서 시험할 항목입니다. 여기서는 그러한 환경별 시험을 수행하지 않았습니다.
리뷰 설명은 변경한 이유와 검증한 범위를 읽을 수 있어야 합니다. 모든 코드를 길게 풀어 쓴 답변보다 위험한 계약 변경과 남은 실패를 정확히 짚은 답변이 더 유용할 수 있습니다. 설명 길이를 품질 점수로 사용하지 말고, 관련 없는 변경을 알아차렸는지와 불확실한 내용을 표시했는지 보세요. 한국어 문장이 친절하다는 이유로 과도한 권한 요청을 승인하지도 않습니다. 자신의 과제에서 필요한 검토 기준을 정한 뒤 두 도구에 동일하게 적용하면 다음 선택에 쓸 근거가 남습니다.
여덟 파일 이름 변경의 구체적인 승인 지도#
앞의 리팩토링을 다음처럼 좁혀 보겠습니다. 아래 파일과 결정은 설명을 위해 만든 예시이며 실행 결과가 아닙니다. 타입과 내부 모듈의 이름은 UserAccount로 바꾸되 외부 JSON의 user_profile, 저장 컬럼과 과거 변경 기록은 유지하는 작업입니다. 동일한 철자가 발견돼도 역할이 다르면 처리도 달라집니다. 따라서 전역 문자열 치환보다 심볼 사용처와 데이터 경계를 분리하는 요청이 맞습니다. 이 차이를 요청에 넣으면 도구가 확인해야 할 질문도 구체화됩니다.
| 예시 파일 | 맡길 변경 | 유지할 계약 | 리뷰에서 내릴 결정 |
|---|---|---|---|
domain/UserProfile.ts | 타입을 UserAccount로 변경 | 필드 의미와 선택 여부 | 이름만 바뀌었는가 |
domain/index.ts | 재수출 이름 갱신 | 다른 공개 타입의 내보내기 | 관련 없는 export가 사라지지 않았는가 |
service/loadUser.ts | 새 타입 가져오기 | 데이터 조회와 오류 처리 | 이름 변경이 동작 변경으로 번지지 않았는가 |
ui/ProfileCard.tsx | 타입 참조 변경 | 사용자에게 보이는 프로필 문구 | 코드 명칭과 화면 명칭을 혼동하지 않았는가 |
api/profileMapper.ts | 내부 타입 연결 | 외부 키 user_profile | 직렬화 경계를 유지했는가 |
tests/loadUser.test.ts | 타입·fixture 참조 갱신 | 실패 동작을 확인하는 단언 | 검증을 약하게 만들지 않았는가 |
tests/profileMapper.test.ts | 새 타입으로 입력 구성 | 기존 응답 필드 확인 | 외부 키 유지가 명시돼 있는가 |
docs/domain.md | 현재 타입 설명 갱신 | 과거 변경 이력의 인용 | 현재 설명과 역사 기록을 구분했는가 |
Cursor에서 첫 파일의 이름과 가져오기를 직접 검토하며 고치려는 개발자는 인라인 변경을 읽는 단위를 작게 잡을 수 있습니다. ProfileCard의 화면 문구를 읽다가 프로필이라는 한국어 이름을 유지하기로 결정했다면 그 결정을 즉시 작업 요청에 반영하면 됩니다. 같은 단어를 모두 바꾸라는 요청보다 도메인 타입만 바꾸라는 요청이 원하는 범위를 더 잘 전달합니다.
Claude Code에 묶어 맡기는 쪽은 표의 경계를 처음 요청에 포함하는 것이 편합니다. 터미널에서 에이전트가 찾은 사용처와 수행할 명령을 읽을 수 있도록 변경 이유를 파일별로 설명하게 합니다. profileMapper에서 외부 필드까지 바꾸려 한다면 코드 작성의 세부 선택이 아니라 범위 변경이므로 멈춰 확인할 지점입니다. 이때 Cursor를 열어 그 매핑만 직접 읽고, 나머지 수정을 Claude Code에 맡기는 병행도 가능합니다. 도구를 나누는 기준은 파일 수보다 결정이 필요한 경계입니다.
이 과제의 검증은 내부 타입의 연결과 외부 응답의 유지라는 서로 다른 질문을 갖습니다. 타입 검사는 새 이름의 참조 누락을 찾는 데 쓰고, 매핑 테스트는 기존 JSON 키가 유지되는지 읽습니다. 문서 검토에서는 현재 설명만 바꾸고 역사 인용은 남겼는지 봅니다. 모든 파일에서 기존 문자열이 사라져야 한다는 종료 조건을 쓰면 외부 키와 이력까지 잘못 바꿀 수 있습니다. 반대로 타입 검사만 통과하면 끝이라는 조건은 외부 응답의 호환성을 충분히 설명하지 못합니다.
같은 명령도 승인 모드에 따라 멈추는 곳이 다릅니다#
Cursor Run Modes의 로컬 Auto-review는 allowlist, 가능한 셸 샌드박스 실행, 분류기 검토의 경로를 설명합니다. 샌드박스 제한 때문에 실패한 명령을 밖에서 다시 실행하려 할 때도 검토가 개입할 수 있습니다. 위 예시에서 로컬 테스트가 추가 파일 쓰기를 요구한다면 먼저 테스트가 어디에 무엇을 만드는지 읽을 이유가 생깁니다. 파일 수정 diff를 수락하는 판단과 테스트 명령에 더 넓은 접근을 주는 판단은 분리됩니다.
Claude Code 권한 문서는 Manual 모드의 파일 수정 승인과 명령의 반복 허용을 다르게 설명합니다. 파일 수정 승인은 세션 종료까지이고, 저장되는 명령 승인은 저장소와 명령의 범위에 연결됩니다. 이름 변경을 위한 이번 수정 승인을 다음 프로젝트의 명령 허용과 같은 것으로 세면 안 되는 이유입니다. 기존에 저장된 허용 규칙이 많은 환경과 처음 쓰는 환경은 승인 창의 수가 달라질 수 있습니다. 횟수를 비교할 때 규칙의 유효 범위도 함께 봐야 합니다.
Claude의 deny, ask, allow 평가 순서에서는 넓은 deny를 좁은 allow로 상쇄할 수 없습니다. 예를 들어 배포 관련 명령을 금지한 팀에서 리팩토링 테스트를 허용하려는 경우, 금지된 동작을 포함한 복합 명령을 쓰지 않는 별도의 검증 경로가 필요합니다. 이것은 더 많은 승인을 받아 해결할 문제와 다릅니다. 반면 파일 수정만 자동 승인하는 모드가 있다고 해서 셸과 외부 도구까지 같은 승인 없이 실행되는 것은 아닙니다. 선택한 모드와 도구별 규칙을 함께 읽어야 실제 중단 이유를 설명할 수 있습니다.
또 하나의 차이는 샌드박스의 적용 대상입니다. Cursor 문서도 로컬 셸 실행과 MCP·Fetch 검토, 클라우드 에이전트의 실행을 나눕니다. 이 이름 변경에 외부 이슈 수정까지 넣으면 코드 diff와 다른 권한 경계가 추가됩니다. 단순한 리팩토링 시험이라면 외부 작업을 제외하는 편이 승인 사건을 해석하기 쉽고, 업무상 꼭 필요하다면 별도 사건으로 기록하는 것이 맞습니다.
편집과 위임 사이에서 남길 한 번의 인계#
이 예시에서 적절한 인계 메모는 구체적입니다. “도메인 타입과 내부 참조 변경을 맡겼고 외부 user_profile은 유지한다. 매핑 파일에서 외부 키 변경 여부를 검토한 뒤, 타입 검사와 기존 매핑 테스트를 실행한다. 문서의 역사 인용은 고치지 않는다.” 여기에는 가상의 성공 출력이나 완료 시간을 넣지 않습니다. 실제 작업에서는 이 메모에 현재 diff와 실행한 검증만 연결하면 됩니다. 편집자가 화면 문구를 직접 고쳤다면 그 변경은 이름 변경과 구분해 인계할 수 있습니다.
이런 분업에서는 Cursor를 항상 실행 담당, Claude Code를 항상 조사 담당으로 고정할 필요가 없습니다. 화면과 코드를 오가며 경계를 결정할 사람은 에디터를 쓰고, 정해진 범위를 여러 파일에 적용하는 일은 터미널에 위임할 수 있습니다. 요청의 범위가 다시 바뀌면 그 결정부터 공유하면 됩니다. 두 도구를 구독할 가치는 이 분업을 얼마나 자주 쓰는지에 달려 있으며, 앞의 여덟 파일 승인 지도는 실제 비용이나 속도의 승자를 계산한 자료가 아닙니다.
그래서 Mirr Code는?#
Mirr Code는 이 비교에서 Cursor와 Claude Code의 중간이 아닙니다. 한국어로 끝까지 일하는 터미널 코딩 에이전트입니다. 한국어 UI, 초성 검색과 한국어 리뷰를 제공합니다. HWPX 파일을 읽거나 수정·변환하는 작업의 지원 범위는 연결된 도구에 따라 다릅니다. 한국어로 작업하기에서 자세히 확인하세요.
요금과 사용 조건은 요금제 페이지와 결제 화면에서 확인하세요. 한국어로 지시하고, 한글 파일명과 한국어 리뷰로 결과를 확인하고 싶다면 Mirr Code가 맞습니다. 최신 영어 벤치마크나 방대한 생태계가 필요하다면 Cursor나 Claude Code가 더 나을 수 있습니다.
수정·보완 기록#
공식 문서의 작업 환경·권한·가격과 가상의 리팩토링 예시를 구분했습니다. 신규 Plus의 상충하는 모델 안내, 세전 가격과 지역별 결제 예외를 유지했으며, 동일 과제 diff·성공/실패 테스트·승인 횟수는 아직 확보하지 못했습니다.
자주 묻는 질문#
Cursor와 Claude Code 중 어떤 것이 더 좋은가요?#
작업 방식에 따라 다릅니다. Cursor는 에디터와 CLI를, Claude Code는 터미널과 IDE 확장 등을 제공합니다. 두 도구 모두 권한 설정과 작업 환경을 확인한 뒤 결과를 검토하는 것이 좋습니다.
둘 중 어떤 것이 더 싼가요?#
2026-11-01 미국 공식 페이지의 세전 가격 기준 Cursor Plus는 월 $8, Claude Pro는 월 $20입니다. Claude Max는 월 $100, Ultra는 월 $200입니다. 지역별 세금과 결제 가격, 포함 모델과 사용량에 따라 총비용은 달라집니다.
무료로 시작할 수 있나요?#
Cursor에는 사용량이 제한된 무료 플랜이 있습니다. Claude 무료 구독에는 Claude Code가 포함되지 않으며, 유료 구독 외에도 Console이나 클라우드 제공업체를 통한 사용이 가능합니다.
한국어로도 잘 되나요?#
둘 다 한국어 입력은 됩니다. 다만 화면 문구, 문서, 오류 메시지, 리뷰 코멘트까지 한국어로 자연스럽게 이어지는지는 도구와 설정에 따라 다릅니다. 한글 파일명과 한글 주석이 섞인 저장소에서 직접 확인해 보는 것이 좋습니다.
둘을 함께 써도 되나요?#
네. 같은 저장소에서 Cursor로 편집하고 Claude Code로 작업을 위임할 수 있습니다. 변경 사항이 겹치지 않도록 diff와 커밋을 확인하세요.
CI에서 쓰기에는 어느 쪽이 나은가요?#
둘 다 CLI를 통해 CI에서 사용할 수 있습니다. Cursor CLI의 비대화형 모드는 쓰기 권한이 있으므로 실행 환경과 권한을 확인하세요. 인증과 사용량 조건도 따로 살펴봐야 합니다.
참고: Cursor CLI 비대화형 모드와 Claude Code 인증 (2026-11-01 확인).
대규모 저장소에서는 어느 쪽이 나은가요?#
두 도구 모두 관련 파일을 찾고 여러 파일을 수정할 수 있습니다. 저장소 규모와 작업에 따라 결과가 달라지므로 실제 과제로 검색 범위, 변경 사항, 테스트 결과를 비교해 보세요.
Mirr Code는 어디에 해당하나요?#
Mirr Code는 터미널에서 한국어로 작업을 이어가는 데 집중한 코딩 에이전트입니다. 한국어 UI, 초성 검색과 한국어 리뷰를 제공합니다. HWPX 파일을 읽거나 수정·변환하는 작업의 지원 범위는 연결된 도구에 따라 다릅니다. 요금과 사용 조건은 /kr/pricing과 결제 화면에서 확인하세요.