VS Code를 쓰다가 Cursor로 넘어온 사람이라면 처음 며칠은 “이게 다야?”라는 의문이 든다. Tab 자동완성이 뜨는 건 Copilot과 비슷해 보이고, 채팅창도 익숙하다. 그런데 Composer로 다섯 개 파일을 한 번에 고치고 나면 생각이 바뀐다. Cursor의 차이는 기능 하나가 아니라 세 레이어가 같은 컨텍스트를 공유한다는 구조에 있다.
Cursor가 기존 에디터와 다른 이유
Cursor는 VS Code 포크다. 그래서 기존에 쓰던 확장·단축키·설정·테마를 그대로 가져올 수 있다. 이전 비용이 거의 없다는 뜻이다. 첫 실행 때 “VS Code 설정 가져오기” 버튼 하나면 끝난다.
진짜 차이는 AI 설계에 있다. Tab·Chat·Composer가 모두 같은 코드베이스 인덱스를 공유한다. Copilot은 현재 열린 파일과 몇 개의 관련 파일을 컨텍스트로 넣어 제안하지만, Cursor는 에디터가 프로젝트 전체를 직접 인덱싱하고 관리한다. Chat에서 @코드베이스를 붙이면 수천 개 파일이 있는 레포에서도 관련 코드를 찾아 답변에 반영한다. Copilot과의 실무 차이가 궁금하다면 AI 코딩 도구 비교 글을 참고하면 된다.
세 레이어의 역할을 먼저 구분해두면 이후 워크플로가 훨씬 선명해진다. Tab은 현재 편집 중인 코드의 다음 줄을 예측한다. Chat은 코드에 대한 질문과 지시를 주고받는다. Composer는 여러 파일을 동시에 생성·수정하는 에이전트 역할을 한다.
설치·초기 설정: 5분 안에 시작하기
cursor.com에서 OS별 설치 파일을 받는다. macOS는 .dmg, Windows는 .exe, Linux는 .AppImage나 .deb를 쓴다. 설치 후 처음 실행하면 VS Code 설정·확장을 한 번에 가져올지 묻는데, 기존 VS Code 사용자라면 무조건 “예스”다.
요금제는 2025년 6월부터 API 비용 연동 크레딧 기반 과금으로 전환됐다. 공식 요금제 페이지를 보면 Hobby(무료)·Pro($20/월)·Pro+($60/월)·Ultra($200/월)·Teams($40/user/월) 등 6개 티어가 있다. 처음 시작한다면 Hobby로 한 달 써보고, 크레딧 소진이 잦아지면 Pro로 올리는 게 현실적이다. Pro+와 Ultra는 무거운 모델을 집중적으로 쓰는 팀 단위 사용자에게 맞다.
초기 설정에서 꼭 챙겨야 할 세 가지:
- 기본 모델 선택:
Cursor Settings → Models에서 기본 모델을 지정한다. 크레딧 소모가 크게 달라지므로 처음엔 가벼운 모델로 시작해 필요할 때 올리는 방식이 낫다. - @코드베이스 인덱싱 활성화:
Cursor Settings → Features → Codebase Indexing을 켜면 전체 프로젝트를 인덱싱한다. 대형 레포는 첫 인덱싱에 수 분이 걸린다. - Privacy Mode 결정:
Cursor Settings → General → Privacy Mode를 켜면 코드가 AI 학습에 사용되지 않는다. 사내 코드나 민감한 프로젝트라면 반드시 켜두어야 한다.
Tab 자동완성: 한 줄 너머를 예측하는 방식
Cursor Tab은 단순히 현재 줄 다음 코드를 제안하는 게 아니다. 방금 편집한 맥락을 보고 다음 편집이 필요한 위치까지 예측해 커서를 이동시켜준다. 반복 리팩터링이나 테스트 스텁 작성에서 이게 극적으로 느껴진다.
단축키 흐름은 간단하다:
Tab— 제안 전체 수락Ctrl+→(macOS:Cmd+→) — 단어 단위 부분 수락Esc— 거절, 계속 직접 입력
반복 패턴 코드 작성 시나리오가 Tab이 가장 빛나는 상황이다. 예컨대 React 컴포넌트의 prop 타입을 하나 추가하면 Cursor가 defaultProps·테스트 픽스처·Storybook 스토리의 같은 부분을 수정해야 한다고 예측하고 Tab을 누를 때마다 다음 수정 위치로 이동한다.
반대로 Tab이 방해가 되는 상황도 있다. 주석을 직접 정교하게 쓰거나, SQL 쿼리를 조심스럽게 입력할 때 자동완성이 튀어나오면 집중이 깨진다. 파일별로 끄고 싶다면 에디터 우측 하단의 Cursor 아이콘을 클릭해 현재 파일 혹은 언어 단위로 비활성화할 수 있다. 언어 전체를 끄려면 Cursor Settings → Features → Tab Autocomplete → Disabled Languages에 추가한다.
Chat과 @-mention: 코드베이스를 맥락으로 넣는 법
Ctrl+L (macOS: Cmd+L)로 Chat 패널을 연다. 여기서 강력해지는 건 @로 컨텍스트를 직접 지정할 수 있기 때문이다.
| @-mention | 적합한 상황 |
|---|---|
@파일명 | 특정 파일 하나를 집중 논의할 때 |
@폴더명 | 모듈 단위로 구조를 물어볼 때 |
@코드베이스 | 프로젝트 전체에서 패턴·의존성을 찾을 때 |
@문서 | 외부 URL이나 로컬 마크다운을 컨텍스트로 넣을 때 |
실전에서 가장 효과적인 프롬프트 구조는 “버그 설명 + @관련파일 + 수정 지시”다. 예: @src/auth/jwt.ts 이 파일에서 토큰 만료 에러가 발생한다. 예외 처리가 빠진 부분을 찾고 수정해줘. 파일을 통째로 열어놓은 채 설명만 늘어놓는 것보다 훨씬 답이 정확해진다.
Chat 결과를 적용할 때는 두 가지 선택지가 있다. Apply 버튼을 누르면 변경사항이 에디터에 바로 반영된다. 조심스럽다면 Diff 뷰로 변경 전후를 비교한 뒤 수락·거절을 파일별로 결정하는 게 낫다.
대화가 10턴을 넘어가면 컨텍스트 품질이 떨어지기 시작한다. 이때는 새 채팅을 시작하고 @파일로 필요한 컨텍스트만 다시 지정하는 게 더 좋은 결과를 낸다. 긴 대화를 이어가는 것보다 짧고 명확한 대화를 여러 번 여는 게 Cursor Chat의 현실적인 사용법이다.
Composer로 다중 파일 동시 편집하기
Ctrl+I (macOS: Cmd+I)로 Composer를 연다. Chat이 “대화”라면 Composer는 “실행”에 가깝다. 지시를 내리면 새 파일을 만들고, 여러 파일을 동시에 수정하고, 터미널 명령을 실행하는 에이전트로 동작한다.
Composer에는 두 가지 모드가 있다:
- Normal 모드: 지시한 파일 범위 안에서 편집. 예상치 못한 파일을 건드리지 않아 안전하다.
- Agent 모드: 자율적으로 파일을 탐색·생성·수정하고 터미널 명령도 실행한다. 강력하지만 그만큼 검토가 필요하다.
Cursor 2.0(2025년 10월 출시)부터는 자체 개발 AI 코딩 모델이 Composer에 탑재됐다. 공식 발표에 따르면 동급 성능 모델 대비 4배 빠르고, 대부분의 턴을 30초 이내에 완료한다. 실제로 중간 규모 리팩터링에서 응답 대기 시간이 눈에 띄게 줄었다.
다중 파일 리팩터링 예시: 컴포넌트 Button.tsx를 새 디자인 시스템에 맞게 리팩터링하고, Button.test.tsx와 Button.stories.tsx도 함께 업데이트해줘. 이 지시 하나로 Composer가 세 파일을 열어 동시에 수정한다.
변경 결과는 Accept All로 일괄 수락하거나, 파일별 Diff 뷰에서 하나씩 검토할 수 있다. Agent 모드로 큰 작업을 맡겼다면 반드시 파일별 리뷰를 권장한다. 예상 밖의 파일이 수정됐을 때 일괄 수락은 되돌리기 어렵다.
실전 워크플로: Tab·Chat·Composer를 연결해 쓰기
세 기능을 따로 쓰는 것보다 연결해 쓸 때 체감 생산성 차이가 크다.
새 기능 개발 흐름은 이렇다. 먼저 Chat에서 @코드베이스로 기존 패턴을 물어보며 설계를 논의한다. 방향이 잡히면 Composer에게 파일 생성과 기본 구조 작성을 맡긴다. 그 다음 에디터로 돌아와 Tab으로 세부 구현을 채워나간다. Chat으로 논의하고 Composer로 뼈대를 세우고 Tab으로 마무리하는 구조다.
Cursor 3.3(2026년 5월 7일 출시)에서 추가된 PR Review 기능은 에디터 안에서 풀 리퀘스트 코드 리뷰를 자동으로 받을 수 있다. 커밋하기 전에 변경사항을 Composer에게 리뷰 요청하는 흐름으로 쓰면 CI를 돌리기 전에 명백한 문제를 잡아낼 수 있다.
같은 버전에서 추가된 /multitask 명령어는 Composer 내에서 여러 작업을 병렬로 진행할 때 쓴다. 예컨대 API 엔드포인트 작성과 테스트 작성을 동시에 요청하면 두 작업을 순차가 아닌 병렬로 처리한다. Build in Parallel 기능과 함께 쓰면 빌드 대기 없이 다른 파일 작업을 이어갈 수 있다.
규모별 조합 추천: 단독 스크립트나 소형 프로젝트는 Chat + Tab 조합으로 충분하다. 멀티 패키지 모노레포나 기능 단위 리팩터링은 Composer Agent 모드가 압도적으로 유리하다. Composer가 파일 경계를 넘나들 수 있어야 진짜 힘이 나온다.
주의사항과 알려진 한계
MCP 서버 보안: 2025년 8월 Cursor의 MCP 서버 연동에서 임의 코드 실행 취약점(CVE-2025-54135, CVE-2025-54136)이 공개됐다. 이후 패치에서 MCP 설정 파일을 변경할 때마다 사용자 승인을 요구하도록 수정됐다. 외부에서 받은 .cursor/mcp.json 파일을 검토 없이 적용하는 습관은 위험하다. 신뢰할 수 없는 소스의 MCP 설정은 내용을 직접 확인하고 승인해야 한다.
크레딧 과금 함정: 크레딧 기반 과금으로 전환된 이후, 무거운 모델을 자주 쓰면 예상보다 빠르게 크레딧이 소진된다. Cursor Settings → Usage에서 잔여 크레딧과 소모 패턴을 주기적으로 확인하고, Composer Agent 작업처럼 큰 작업은 시작 전에 모델 선택을 의식하는 습관이 필요하다.
Privacy Mode와 인덱싱: 코드베이스 인덱싱을 켜기 전에 Privacy Mode 여부를 결정해야 한다. 모드를 바꾼 뒤에는 인덱스가 재구축되므로 순서가 중요하다. .cursorignore 파일을 프로젝트 루트에 만들면 .gitignore 문법으로 인덱싱에서 제외할 경로를 지정할 수 있다. 환경변수 파일(.env)이나 대용량 바이너리는 여기에 넣어두는 게 맞다.
Composer Agent 사용 전 git commit: Agent 모드는 파일을 자율적으로 수정한다. 되돌리기 어려운 상황을 막으려면 Composer에게 큰 작업을 맡기기 전에 반드시 git commit으로 현재 상태를 저장해두어야 한다. “Accept All을 눌렀는데 예상과 달랐다”는 상황은 생각보다 자주 온다.
자주 묻는 질문
Q. Cursor와 VS Code + Copilot 조합 중 어느 것이 더 나은가?
단순 자동완성만 쓴다면 체감 차이가 크지 않다. Cursor가 앞서는 건 Chat의 @코드베이스와 Composer의 다중 파일 편집이다. 이 두 기능을 활용하는 워크플로에 익숙해지면 Copilot + VS Code 조합으로 돌아가기 어렵다. 반대로 현재 Copilot 자동완성에 만족하고 있고 멀티 파일 작업이 드물다면 굳이 전환할 이유는 없다.
Q. Hobby 플랜에서 실제 작업이 가능한가?
가능하다. 단, 크레딧 한도 안에서 무거운 모델을 쓰면 며칠 안에 소진되는 경우가 있다. Hobby 구간에서는 가벼운 모델을 기본으로 두고 복잡한 Composer 작업에만 강한 모델을 선택하는 방식으로 크레딧을 아끼는 게 현실적이다.
Q. .cursorignore와 .gitignore는 별도로 관리해야 하는가?
별도다. .gitignore가 있어도 Cursor 인덱싱은 별도 파일을 본다. .cursorignore를 만들지 않으면 .gitignore에서 제외된 파일도 인덱싱될 수 있다. 프로젝트 루트에 .cursorignore를 따로 만들고 민감 파일 경로를 명시하는 게 안전하다.
Q. Composer가 여러 파일을 수정했을 때 되돌리는 방법은?
Cursor Composer의 변경사항을 Accept하기 전 단계에서는 “Reject All”로 전체 취소가 된다. 이미 Accept했다면 git으로 되돌려야 한다. 이 때문에 큰 Composer 작업 전에 git stash 혹은 git commit을 해두는 게 필수다. Cursor 자체 Undo(Cmd+Z)는 단일 파일 내 변경에는 동작하지만 다중 파일 Composer 작업을 한 번에 되돌리지는 못한다.
단계별 실행 가이드
1단계. Cursor 설치 및 VS Code 설정 이전
cursor.com에서 OS에 맞는 설치 파일을 내려받아 실행한다. 첫 실행 시 나타나는 설정 이전 다이얼로그에서 “VS Code에서 가져오기”를 선택하면 확장·키바인딩·테마가 자동 복사된다. 이전 없이 시작해도 나중에 Cursor Settings → General → Import from VS Code로 언제든 가져올 수 있다.
2단계. Privacy Mode 결정 후 코드베이스 인덱싱 활성화
Cmd+Shift+J(Windows: Ctrl+Shift+J)로 Cursor Settings를 열고, General에서 Privacy Mode 여부를 먼저 결정한다. 민감한 코드라면 켜둔다. 그 다음 Features → Codebase Indexing을 활성화한다. 첫 인덱싱은 프로젝트 크기에 따라 수 분이 걸린다.
3단계. Tab 자동완성으로 현재 파일 편집 연습
평소처럼 코드를 작성하면서 Tab 제안이 뜰 때 수락·거절 패턴을 익힌다. 반복적인 코드(배열 초기화, 테스트 케이스, 타입 정의)를 작성할 때 Tab이 얼마나 문맥을 따라오는지 확인한다. Ctrl+→로 단어 단위 부분 수락하는 것도 함께 익혀두면 제안이 절반만 맞을 때 유용하다.
4단계. Chat에서 @-mention으로 코드 질문하기
Cmd+L로 Chat을 열고, @파일명이나 @코드베이스를 붙여 구체적인 질문을 던진다. 처음에는 현재 작업 중인 파일 하나를 @로 지정하고 “이 함수에서 성능 문제가 있을 만한 부분은?” 같은 질문으로 시작한다. Apply와 Diff 뷰 버튼의 동작을 직접 확인해본다.
5단계. Composer로 다중 파일 작업 시도
Cmd+I로 Composer를 열고 Normal 모드에서 간단한 작업을 먼저 맡긴다. 예: utils/format.ts 파일에 날짜 포맷 함수를 추가하고, 해당 함수에 대한 테스트를 utils/format.test.ts에 작성해줘. 변경 결과를 Diff 뷰에서 파일별로 검토하고 수락하는 흐름을 익힌다.
6단계. 실전 워크플로 통합
새 기능 작업 시 Chat으로 방향 논의 → Composer로 파일 구조 생성 → Tab으로 세부 완성 순서를 의식적으로 따라간다. 몇 번 반복하면 어느 레이어를 언제 쓰는지 감이 잡힌다. Cursor 3.3의 PR Review 기능도 커밋 전 루틴으로 추가해두면 코드 품질 확인이 에디터 안에서 끝난다.