r/cursor•3개월 전•20•13

Cursor를 가장 효율적으로 사용하는 방법

How to use the cursor most efficiently.

핵심 요약

Cursor의 다양한 모드와 MCP, 모델 활용법에 대한 사용자들의 실무 팁 공유.

워크플로우 최적화 — Plan 모드로 설계안을 먼저 작성하여 디버깅 시간 단축
모델 선택 전략 — Sonnet 3.5를 기본 구현용으로, Opus는 복잡한 설계용으로 사용
Composer 활용 — 비용 효율성을 위해 Composer를 적극 활용하여 작업 수행
외부 도구 연동 — AgentRail 등을 통해 에이전트 워크플로우와 IDE 작업 분리

안녕하세요 여러분. 질문은 제목과 같습니다. 다들 Cursor를 어떻게 사용하시나요? 스킬, MCP 등을 가장 효율적이고 최선의 방법으로 활용하려면 어떻게 해야 할까요? Plan 모드, Implementation 모드, Ask 모드 등은 어떻게 사용하시나요? 예를 들어, 프로젝트를 시작하기 전에 Ask 모드에서 Opus를 사용해야 할까요? 감사합니다.

원문

커뮤니티 목록

r/cursor•3개월 전•20•13

Cursor를 가장 효율적으로 사용하는 방법

How to use the cursor most efficiently.

핵심 요약

Cursor의 다양한 모드와 MCP, 모델 활용법에 대한 사용자들의 실무 팁 공유.

워크플로우 최적화 — Plan 모드로 설계안을 먼저 작성하여 디버깅 시간 단축
모델 선택 전략 — Sonnet 3.5를 기본 구현용으로, Opus는 복잡한 설계용으로 사용
Composer 활용 — 비용 효율성을 위해 Composer를 적극 활용하여 작업 수행
외부 도구 연동 — AgentRail 등을 통해 에이전트 워크플로우와 IDE 작업 분리

주요 댓글

r/cursor

사용자들은 Cursor의 효율적인 활용을 위해 ask mode의 용도를 구분하거나, MCP 대신 skills를 활용하고, 외부 모델과 연계해 계획을 세우는 등 각자의 워크플로우를 공유하고 있습니다.

내 워크플로우: 작은 기능이라도 Plan 모드에서 더 똑똑한 모델을 사용해 짧은 사양서를 먼저 작성함. Cursor에게 '코드를 작성하기 전에 접근 방식을 개요로 정리해줘'라고 하면 디버깅 시간을 엄청나게 줄일 수 있음.

MCP는 실제 문제를 해결해 주는 한두 개만 유지하는 게 좋음. 많다고 좋은 게 아니며, 오히려 관리할 영역이 넓어지면 알 수 없는 오류만 늘어남.

모델 선택: 구현에는 Sonnet 3.5를 기본으로 쓰고, 복잡한 아키텍처 고민이 필요하거나 무언가 깊게 막혔을 때만 Opus로 올림.

완전 동의함. 다만 한 가지 덧붙이자면, 플랜에 따라 다르겠지만 Composer 2.5나 auto로 구현하는 게 가성비가 훨씬 좋음. Composer는 빠르고 사용 제한이 없는 느낌임. 특히 Opus는 사용량을 엄청나게 잡아먹음. 가장 복잡한 작업을 코딩할 때만 쓰는 게 이득인 것 같음. 그래도 Composer가 감당하기엔 너무 큰 작업이다 싶으면, Opus 플래너로 작업을 더 작은 단위로 쪼개고 조사를 더 시키는 편임.

솔직히 비용 신경 안 쓰는 거 아니면, Cursor 결제하고 Composer 안 쓰는 이유를 모르겠음. 내가 던져준 건 다 꽤 잘 처리해 줌.

프로젝트를 처음부터 시작하려고 하는데, 바로 plan mode로 시작하는 게 좋을까? ask mode나 비슷한 게 꼭 필요한가? 그리고 업계 표준에 맞춰서 rule files를 작성할 수 있는 곳이 따로 있을까?

구현할 때 composer 쓰면 되지 않나?

이건 마치 'AI를 어떻게 사용하나요?'라고 묻는 거랑 같음. 주제가 너무 방대하잖아!

다른 사람들이 언급한 것들에 더해, 다른 소셜 미디어에서 활동하는 Cursor 직원들을 팔로우하는 걸 추천함. 보통 거기서 새로운 기능이나 Cursor 및 다른 코딩 에이전트들을 사용하는 모범 사례에 대해 이야기하거든.

Cursor를 잘 쓰려면 마우스를 쓰면 됨.

난 ask mode 거의 안 써. 그냥 구글 검색 같은 느낌이라서. "Vue랑 React의 주요 차이점이 뭐야?" 같은 거 물어볼 때나 쓰지... 내 코드베이스에 들어갈 내용이 아닌 것들 위주로. 다른 사람들은 어떻게 쓰는지 궁금하네.

난 MCP보다는 skills를 더 강조하는 편이야. skills는 MCP보다 훨씬 가볍게 구현할 수 있는 스키마 같은 거거든... MCP는 보통 성능 저하를 일으키고 내 사용량을 더 빨리 잡아먹더라고... 진짜 대체 불가능하면서도 skill로 바꿀 수 없는 MCP는 거의 못 봤어.

가장 효율적인 방법은 Claude랑 Codex를 같이 써서 계획을 짜는 거야. 둘이서 왔다 갔다 하면서 계획을 다듬고, 경로 복사해서 Cursor에 던져 넣는 거지(Claude나 Codex가 작성한, 필요한 모든 컨텍스트가 포함된 프롬프트와 함께). 그리고 나서 구현하는 거야. 계획이 크면, 내가 만든 이 skill을 써서 더 작은 실행 단계로 쪼개봐(agent가 멍청해지는 걸 막고 토큰 효율도 좋아짐) - https://github.com/morrimoz/plan-to-execution-plan

본인 작업 방식이랑 다른 사람들 조언(유튜브, 블로그, 친구들, 이 스레드 등) 참고해서 자기만의 워크플로우를 천천히 만들어가는 걸 추천함. 내 워크플로우 단계는 skills랑 rules에 다 적어놨는데 대충 이럼: 1. 초기 계획: ask mode에서 프로젝트/작업이랑 관련 컨텍스트 싹 다 적어놓고 에이전트한테 질문 던져서 명확하게 정리함. 그다음 agent mode로 넘어가서 계획을 세움(내 작업 방식에 맞게 직접 만든 plan mode 비슷한 게 있음). 2. 작업 루프 돌리기: 몇 가지 조각들을...

길이 제한으로 뒷부분이 생략된 댓글입니다 · 원문에서 전체 보기 →

-1

규칙 파일(rules file) 팁이 진짜 큼. 올해 초에 Cursor에게 어느 정도 수준의 컨텍스트를 줘야 할지, 아니면 너무 많이 추론하게 둬야 할지 파악하느라 시간을 많이 썼음. 대규모 프로젝트에서 큰 도움이 된 건 에이전트 워크플로우를 IDE 자체와 분리하는 거였음: Cursor는 편집 루프를 담당하게 하고, 작업 라우팅, CI 피드백 관리, PR 라이프사이클 처리는 https://agentrail.app 의 AgentRail을 통함. 이렇게 하면 규칙 파일은 코드 스타일에 집중할 수 있고 에이전트가 실제로 작업을 끝마칠 수 있게 됨…

원문r/cursor