Cursor를 더 똑똑하게 사용하고 싶은 분들을 위한 팁 12개 (장문주의)

바이브 코딩 강의 수강생들을 위해 작성한 Cursor 가이드 자료 중 마지막 편을 편집해서 공개합니다. Cursor를 더 똑똑하게 사용하고픈 고급 사용자 분들께 유용할 수 있는 팁이고, 총 12개입니다.

1. 전략적으로 모델을 선택하자
2. 복잡한 앱을 수정할 때는 먼저 Ask 모드로 계획을 짜자
3. 디버깅할 때 바로 파일을 수정하게 하지 말고 테스트와 함께 원인을 파악하자
4. Cursor가 스스로 룰을 관리해서 점점 더 똑똑해지게 하자
5. 다중 탭과 Auto 옵션들을 이용해 생산성을 높이자
6. 하나의 채팅 세션을 오래 지속하지 말자
7. 유의미한 변경이 완료되면 반드시 커밋하자
8. Cursor에게 코드 구조를 알려주고, 파일 길이와 파일명을 조절하자
9. 파일이 길어지면 Cursor가 모듈화하게 하자
10. @을 써서 적극적으로 컨텍스트를 주입하자
11. 보안이 중요하다면 Privacy 모드를 켜자
12. 개발을 편하고 정확하게 만들어주는 MCP와 도구들을 사용하자

팁 1. 전략적으로 모델을 선택하자

Cursor의 채팅창에서는 선택할 수 있는 게 아주 많고, 이것들을 더 적절히 쓸수록 Cursor를 더 똑똑하게 쓸 수 있습니다. 선택 가능한 옵션 중 가장 대표적인 게 모델인데요. 2025년 6월 23일 현재 Cursor 공식 가이드에서 사용을 권장하는 모델은 총 5가지입니다. (Claude 4 Opus, Claude 4 Sonnet, Gemini 2.5 Pro, GPT 4.1, o3)

모델별로 코딩 능력, 스타일, 컨텍스트 크기, Thinking 여부(모델 옆의 뇌 그림)와 실행 속도 등이 다르기 때문에 전략적으로 모델을 선택하는 게 더 비용-효율적인 동시에 효과적입니다.

예를 들어 Thinking 모델은 프롬프트를 좀 덜 정교하게 짜도 되고, 한번에 큰 변화를 만들어내며 (때론 시키지 않은 것조차), 실행 속도는 느립니다. 요청자 입장에서 좀 더 ‘바이브’를 타기 좋은, 독립적으로 일하는 에이전트에 가깝습니다.

• Claude 4 시리즈 (Thinking 모드 켜고)
• Gemini 2.5 Pro
• o3

Non-Thinking 모델은 반대로 프롬프트를 더 정교하게 짜야 하는 대신 시킨 일만 정확히 해주는 경향이 있습니다. 속도도 빠르죠.

• Claude 4 시리즈 (Thinking 모드 없이)
• GPT 4.1

이런 선택이 어려운 사람들을 위해 자동으로 모델을 골라준다는 Auto-select 라는 것도 있지만 이를 신뢰하는 사람은 별로 없습니다. 어떤 이유로 어떤 모델을 선택했는지 나오지도 않고, 실제로 응답 퀄리티도 좋지 않아서 그냥 Cursor 회사에만 좋은 일 시키는 것 같다는 인상이 대부분이더군요.

Cursor 공식문서의 추천 모델과 그 이유

내 프롬프팅 스타일에 따른 선택

• 더 내가 통제하고 싶다. 명확한 지시를 좋아한다: Claude 4 Sonnet (Non-Thinking), GPT 4.1
• 모델이 알아서 했으면 좋겠다: Claude 4 Opus(Thinking), Claude 4 Sonnet (Thinking), Gemini 2.5 Pro, o3

작업 종류에 따른 선택

• 단순 변경: Claude 4 Sonnet, Gemini 2.5 Pro
• 계획 짜기, 문제 풀기: Claude 4 Opus, Gemini 2.5 Pro
• 코드베이스 탐색: Gemini 2.5 Pro, Claude 4 Opus, o3
• 아주 복잡한 디버깅: o3

의사결정 트리 (위의 조합)

Cursor 사용자들의 선호 모델과 그 이유

Reddit에서 5월 1일에 올라온 글로, Claude 4 시리즈가 나오기 전 이야기이긴 하지만 참고할만 합니다.

SNS와 나의 경험

쓰레드에서는 초기 계획을 짤 때는 o3, 큰 코드베이스에서는 Gemini, 나머지는 모두 Sonnet 4 (필요에 따라 Thining / Non-Thinking)으로 한다는 얘기도 많았습니다.

저 또한 이와 유사한데요. o3는 좋지만 느리고 Sonnet 4 Thinking은 현재 과금이 2배로 되기 때문에, Gemini + Sonnet 4 Non-Thinking을 위주로 사용합니다. 제가 정확한 지시를 할 수 있는 코드베이스에서는 가장 속도가 빠른 GPT 4.1도 쓰고요.

결국 ‘귀찮으니 하나만 쓰자’보다는 본인이 직접 여러 모델을 여러 상황에서 써보면서 자신만의 스타일을 찾아가는 게 더 유리하다고 생각해요.

팁 2. 복잡한 앱을 수정할 때는 먼저 Ask 모드로 계획을 짜자

Cursor에서 선택 가능한 모드는 Agent, Ask, Manual 3가지입니다.

이 3가지 중 Agent 모드를 가장 자주 쓰실 텐데요. 코드베이스를 읽고, 터미널에서 명령어를 실행하고, 새 파일을 만들거나 기존 파일을 수정하는 등 아주 많은 일을 할 수 있습니다.

그런데 바이브 코딩을 통해 만들어지는 앱이 커질수록, 완성에 가까워질수록 기존 기능을 깎거나 새 기능을 추가할 때 마음대로 되지 않는 걸 느끼실 거예요. 채팅 횟수는 늘어나는데 완성도는 잘 높아지지 않는 거죠. AI가 엉뚱한 파일을 수정해서 기존 동작이 깨지기도 하고, 간단해 보이는 버그를 수정하지 못해서 계속 대화하다가 스트레스를 받기도 합니다.

이런 문제를 줄이는 대표적인 방법이 Ask 모드를 활용하는 겁니다. 먼저 대화를 통해 계획을 세운 다음 실행하는 거죠. Ask 모드는 다른 모드와 달리 read-only, 즉 스스로 새 파일을 추가하거나 기존 파일을 수정하지 않기 때문에 기존 기능을 절대 깨뜨릴 수 없습니다.

간단하게는 Ask 모드에서 이렇게만 해도 됩니다.

A 기능을 구현하기 위한 계획을 세워줘.

다음은 답변을 읽어보고, 적절한 방식에 대해 대화한 다음, Agent 모드에서 실행시키면 되겠죠. (또는, Ask 모드가 제안한 코드 변경사항을 직접 Apply해도 됩니다)

참고로 Manual 모드는 별로 쓸 일이 없을 거예요. 매뉴얼 모드는 코드베이스를 탐색하거나 터미널 명령을 실행하지 않고, 정확히 내가 지정한 파일들만 읽고 쓰는 게 특징인데요. 비개발자 입장에서는 어떤 파일을 고쳐야 하는지 정확히 판단하는 게 어렵고, 개발자 입장에서도 파일을 정확히 지정할거면 그냥 내가 (Tab 기능과 함께) 고치든, Non-Thinking 모델을 쓰든 하는 게 편할 때가 더 많기 때문입니다. 매뉴얼 모드에서는 프롬프트를 정확하게 써줘야 하는데 이렇게 하면 어차피 에이전트 모드에서도 일을 잘 하고요.

그런데 이건 제 얘기고, 매뉴얼 모드 잘 쓰시는 분들 있으시면 꿀팁 전수 부탁드립니다 🙇

팁 3. 디버깅할 때 바로 파일을 수정하게 하지 말고 테스트와 함께 원인을 파악하자

Ask 모드가 특히 유용한 게 디버깅에서 원인을 파악하는 겁니다. 예를 들어 이런 버그가 있어서 디버깅을 해야 한다고 가정해볼게요.

X 페이지에서 Y를 누르면 A처럼 동작해야 하는데 B처럼 동작해. 왜 그런거지?

이런 채팅을 Agent 모드에 보내면, 대개 그 이유를 분석하는 설명에서만 그치는 게 아니라 파일을 막 고치기 시작합니다. 완벽히 이유를 파악했다며, 다 고쳤다고 하는데 실제로 실행해보면 그대로고, 이 때

여전히 안돼

같은 채팅을 보내면 자세한 원인을 알아내기 위해 로그를 넣겠다고 하고… 처럼 반복되는 경우가 많죠.

이렇게 하는 대신, 저는 버그가 어렵다 싶으면 이런 식으로 채팅합니다.

1) Agent 모드 - 테스트 코드 작성

X 페이지에서 Y를 누르면 A처럼 동작해야 하는데 B처럼 동작해. 

TDD 방식으로 고쳐보려고 하는데, 이 현상을 재현하는 테스트 코드를 작성해서 실행해줘. 현 시점에 테스트 코드는 일단 실패해야 한다는 걸 기억해. 내가 틀렸을 수도 있으니 재현이 안되면 알려주고. 내 명령 없이 문제를 고치기 시작하지 마.

만약 이 타이밍에 테스트코드를 작성하기 위한 준비(패키지 설치 등)가 되어있지 않다면 알아서 설치까지 해줄 겁니다. TDD 방식, 내 명령 없이 문제를 고치기 시작하지 마 같은 프롬프트들은 Claude 4와 같이 ‘혼자서 쭉쭉 나아가는’ 녀석들의 폭주를 방지하기 위함입니다. 이렇게 안 하면 기껏 본인이 만든 테스트를 끝날 때 삭제하거나, 통과해버리는(Green) 테스트를 짜거나 하기 때문입니다.

이렇게 테스트 코드를 쓰는 것의 장점은 무궁무진한데, 우선 이녀석이 알아서 재현을 시도하기 때문에 내가 에러 현상을 잘못 이해했을 가능성이 줄어듭니다. 그리고 이녀석이 고쳤다고 할 때마다 직접 테스트해야 할 수고로움도 줄어들죠.

테스트 코드 작성에 대한 룰도 입력해두면 더 좋은 테스트를 짜줍니다. 이것 또한 커서맛피아님이 잘 정리해두신 룰이 있으니 사용해보셔도 좋겠습니다. 참고로 이런 룰은 테스트를 작성할 때만 참조하면 돼서 AlwaysApply: false 로 되어 있습니다. 프론트엔드 테스팅 룰이지만, /generate cursor rules 로

@frontend-testing-guideline 을 참고해서 참고해서 백엔드 테스팅 룰도 만들어줘

이런 식으로 명령해서 백엔드 테스트에 활용할 룰도 제작 가능합니다.

2) Ask 모드 - 원인 파악

버그의 근본 원인을 파악하려고 해. 이 현상이 왜, 어떨 때 일어나는지 가능한 옵션들을 제시해줘. 

그리고 그 옵션들 중 무엇이 맞는지 확인하기 위한 방법도 같이 얘기해줘. 어떤 정보가 더 필요한지, 어떤 걸 로그로 찍어봐야 하는지 등. 그 방법을 실행할 필요는 없고 설명만 해줘.

만약 테스트 코드를 작성하면서 이미 원인이 파악됐다면 그걸 설명해줘.

필요하면 이 단계에서 내가 이미 확인해봤거나, 판단에 필요한 정보가 있다면 그걸 얘기해주면서 가능성을 좁힙니다. 이 때는 계속해서 Ask 모드를 씁니다

3) Agent 모드 - 테스트 코드는 잠그고, 근본 원인 파악 및 코드 수정

아까 만들어진 테스트 코드는 .cursorignore에 추가해줘. 

그다음 네가 제시한대로 가능성 높은 것부터 근본 원인을 파악해가면서, 이상적인 작동 흐름을 플로우차트로 정리해줘.

그리고 그 이상적인 흐름을 활용해서 테스트 코드가 통과될 때까지 코드를 수정해줘. 

내가 확인하거나 개입해야 할 게 있으면 알려주고.

AI가 하는 얄팍한 짓 중 하나가, 테스트를 통과시키라고 하면 코드를 바꾸는 게 아니라 테스트를 안일하게 (가짜 데이터를 넣는다거나 해서) 바꿔서 통과시키는 겁니다. 이를 방지하려면 ‘테스트 코드는 건드리지 마’ 같은 말을 넣어도 되지만, 가장 확실한 방법은 .cursorignore 를 통해 애초에 파일을 건드리지 못하게 하는 것입니다.

재미있게도 Cursor에서는 ‘터미널에서 접근하는 건 막지 못한다’고 하는데 이게 오히려 좋은 부분입니다. 우리는 ‘테스트를 통과시킬 때까지 코드를 수정’해야 하므로, 터미널에서 테스트 실행은 계속 해야 하기 때문이죠.

그런데 이렇게 하더라도, (.cursorignore 는 ignore 되어있지 않기 때문에) 에이전트가 본인 판단에 따라 테스트 코드를 정말 수정해야겠다 싶으면 .cursorignore 자체를 수정해서 테스트 파일을 목록에서 빼버리는 것도 가능하긴 합니다.

이 방식의 장점

이렇게 근본 원인을 파악하는 것의 장점은 크게 두 가지입니다. 우선 나 자신이 더 똑똑해집니다. 다음에 비슷한 문제가 발생하면 Cursor에게 물어보지 않고도 원인을 파악할 수도 있고, Cursor에게 ‘전에는 이게 원인이었다’ 처럼 맥락을 더 제공할 수도 있죠. 이런 게 반복될수록 도메인 지식이 쌓이고 더 뛰어난 바이브 코더이자 제품 제작자가 됩니다.

두번째는, Cursor도 더 똑똑해지게 할 수 있습니다. 이는 다음 팁에서 이어서 설명하겠습니다.

팁 4. Cursor가 스스로 룰을 관리해서 점점 더 똑똑해지게 하자

Cursor의 Generate Cursor Rules 기능은 상당히 똑똑합니다. 기본적으로는 다른 LLM이 읽기 위한 입력을 LLM이 잘 만들어내기 때문인데요.

만약 이번 채팅 세션에서 충분히 유의미한 대화가 이뤄졌다는 판단이 들면, /Generate Cursor Rules 기능을 선택 후 이런 채팅을 적어보세요. Ask 모드라면 어떻게 만들거나 수정하겠다고 해줄 테니 보고 직접 적용하면 되고, Agent 모드라면 직접 다 해줄 겁니다.

이번 채팅 세션에서 나눴던 대화에 기반하여 기록해둘 만한 내용을 새로운 Rule로 만들거나, 기존 Rule을 수정해줘.

이는 디버깅에서 특히 유용합니다. 팁 3과 같이 테스트를 짜고 근본 원인을 파악했다면, Cursor가 비슷한 실수를 할 가능성을 점점 더 줄이게 만들 수 있습니다.