우리는 모든 techsy.io 블로그 포스트를 Cursor + Claude Code로 배포하고 있으며, Cursor를 더 효율적으로 사용하기 위한 플레이북이 2026년에 실제로 바뀌었습니다. 인터넷에서 찾을 수 있는 대부분의 팁 목록은 Composer 2.0이 나오기 전, Plan Mode가 나오기 전, Skills가 나오기 전에 작성되었습니다. 여기 있는 12가지는 올해 우리의 배포 속도를 실제로 향상시킨 것들입니다 — 이론이 아닌 실제 클라이언트 빌드에서 추출했습니다.
핵심 요점
- 2026년 Cursor의 가장 큰 승리는 프롬프트 팁이 아닙니다 — Agent를 실행하기 전에 Plan Mode(Shift+Tab)를 마스터하는 것입니다.
- 질문에는 Ask를, 수술적 편집에는 Cmd+K를, 다중 파일 작업에는 Agent를, 한 파일보다 큰 작업에는 Plan Mode를 사용하세요.
- Rules는 Agent에게 당신이 누구인지를 알려주고, Skills는 특정 작업을 어떻게 하는지를 알려주며, MCP는 실제 시스템을 호출할 수 있는 도구를 제공합니다.
- Cursor를 Claude Code와 함께 사용하세요: 한쪽에서는 계획을, 다른 쪽에서는 병렬 agents를 실행 — 2026년 가장 활용되지 않는 워크플로입니다.
실제로 어떤 Cursor 모드를 사용해야 할까요?
Cursor는 다양한 문제를 해결하는 5가지 작업 모드를 가지고 있습니다. 코드베이스에 대한 질문에는 Ask를, 수술적 인라인 변경에는 Cmd+K(Edit)를, 다중 파일 작업에는 Agent를, 전략이 필요한 모든 것에는 Plan Mode(Shift+Tab)를, Agent 실행이 잘못되었을 때는 Debug Mode를 사용하세요. 잘못 선택하면 할당량을 낭비하거나 형편없는 결과를 배포하게 됩니다.
시작하는 모드가 그 이후의 모든 것을 결정합니다. Edit만 필요한 상황에서 Agent를 사용하면 수정 비용으로 3개의 파일을 원치 않게 건드리게 됩니다. 다중 파일 기능에서 Plan Mode를 건너뛰면 Agent가 즉석에서 반 정도의 데이터 모델을 만드는 것을 보게 됩니다. 공식 Cursor 문서는 각 모드의 표면을 다루고 있지만 진정한 기술은 빠르게 선택하는 것입니다.
1. 한 파일보다 큰 작업에는 Plan Mode를 사용하세요 (Shift+Tab)
Plan Mode는 먼저 리포지토리를 조사하고, 마크다운 형식으로 계획을 작성한 후, 코드를 수정하기 전에 승인을 기다립니다. Composer 내에서 Shift+Tab을 누르면 켜집니다. 이 기능은 Composer 2.0과 함께 배포되었으며, 다중 파일 작업의 수학을 바꿉니다 — 이미 잘못된 것을 작성한 Agent와 더 이상 싸우지 않습니다.
워크플로우는 간단합니다: 작업을 설명하고, Plan Mode가 리포지토리를 읽고 계획을 작성하도록 한 후, 계획을 제자리에서 편집한 다음 승인합니다. Agent는 추측하는 대신 계획에 따라 실행합니다. 다시 실행할 가치가 있는 계획을 저장하세요:
실제 클라이언트 작업에 대한 우리의 테스트에서, 다중 파일 작업에 Plan Mode를 사용하도록 전환하면 평균 작업 길이가 대략 절반으로 단축되었습니다. Lee Robinson의 Cursor 블로그의 Agent 모범 사례 포스트는 계획 루프에 대해 더 깊이 있게 설명합니다. 짧은 버전: 5줄로 스케치할 수 없는 기능에 Agent를 절대로 풀어주지 마세요.
2. Git에 체크인할 수 있는 .cursorrules 파일을 작성하세요
Rules는 Cursor의 가장 높은 레버리지 일회성 설정입니다. 리포지토리와 함께 제공되는 지속적인 컨텍스트이므로 모든 팀원(그리고 모든 Agent 실행)이 동일한 기준선에서 시작합니다. 새로운 형식은 .cursor/rules/*.md에 있습니다. 레거시 단일 파일 .cursorrules는 여전히 작동하지만 디렉토리 형식이 조직화에서 이깁니다.
포함할 내용: 스택, 네이밍 컨벤션, 표준화한 라이브러리, "이렇게 하지 마세요" 목록입니다. 포함하지 않을 내용: 린터가 적용할 수 있는 스타일 규칙입니다. 간격과 따옴표를 ESLint와 Prettier로 밀어넣으세요 — Rules는 도구가 잡을 수 없는 것들이어야 합니다.
우리는 모든 리포지토리에 .cursor/rules/ 폴더를 유지합니다. 문법과 패턴 라이브러리에 대해서는, .cursor/rules 문법과 패턴에 대한 우리의 깊이 있는 다이브가 전체 표면을 다룹니다. Cursor 공식 문서가 형식 변경에 대한 신뢰할 수 있는 소스입니다.
3. 컨텍스트를 붙여넣기 중단하세요 — @file, @folder, @docs, @past chats를 사용하세요
@-컨텍스트 시스템은 모든 방향에서 복사-붙여넣기를 이깁니다: 중복을 제거하고, 파일 변경에 따라 최신 상태를 유지하며, Agent가 독립적으로 다시 가져올 수 있습니다. 코드를 채팅에 붙여넣기는 2024년 방식입니다. 2026년에는 가리키면 Agent가 읽습니다. 4가지 원시 요소가 거의 모든 상황을 커버합니다.
- @file — 특정 파일을 고정하세요: @file lib/auth.ts
- @folder — Agent에게 전체 서브트리를 제공하세요: @folder app/api/billing
- @docs — 인덱싱된 외부 문서를 당겨오세요(Supabase, Stripe, 당신의 것): @docs Supabase
- @past chats — 현재 대화를 부풀리지 않고 이전 대화의 컨텍스트를 복원하세요
- @branch(파워 유저) — 검토나 마이그레이션 작업을 위해 다른 브랜치에 대한 diff 컨텍스트
정신적 전환: @-컨텍스트를 Agent의 작업 메모리로 생각하세요. 당신은 코드에 대해 "말하는" 것이 아닙니다 — 보기 위한 도구를 건네고 있습니다. 우리는 전체 컨텍스트 엔지니어링 플레이북에서 더 넓은 패턴을 다룹니다.
4. 새로운 대화를 언제 시작해야 할까요?
Agent의 답이 약간 이상하게 느껴지는 순간 새로운 대화를 시작하세요. 긴 대화는 부패합니다 — 컨텍스트가 가득 차고, 모델이 이전 파일과 현재 파일을 헷갈리기 시작하며, 품질이 조용히 떨어집니다. "컨텍스트 윈도우 가득 참" 경고는 훨씬 너무 늦습니다. 경고가 아닌 마찰을 신뢰하세요.
채팅을 날리기 전에 재사용 가능한 것들을 .cursor/plans/에 저장하면 흔적을 잃지 않습니다. 우리는 이것들을 git stash처럼 취급합니다: 상태, 다음 단계, Agent가 생각하던 파일 경로를 적어둡니다. 새로운 대화, 파일 경로를 붙여넣으세요, 계속 진행합니다. 2분짜리 작성이 혼란스러운 스레드를 구하려는 40분보다 낫습니다.
5. 수술적 변경에는 Cmd+K(Edit)를 사용하고, Agent는 사용하지 마세요
한 문장으로 설명할 수 있는 변경에는 Cmd+K를 사용하세요. 인라인 Edit은 이름 바꾸기, 단일 함수 리팩토링, "위 패턴과 일치하도록 만들어" 트윅에서 Agent보다 빠릅니다 — 사이드 패널을 열지 않고, 다단계 계획을 생성하지 않으며, 강조 표시하지 않은 파일을 건드리지 않습니다. 더 낮은 위험, 더 낮은 지연, 더 적은 정리.
우리에게 잘 작동한 경험 규칙: 변경이 한 함수를 건드리고 입력하기 전에 이름을 지을 수 있다면, Cmd+K입니다. 얼마나 많은 파일을 수정해야 할지 확실하지 않으면, Plan Mode로 Composer를 열어야 합니다. 어느 쪽 그룹에든 잘못된 도구가 가장 느린 경로입니다.
6. 워크트리를 사용하여 병렬로 Agent를 실행하세요
병렬 Agent는 각각 자체 git 워크트리를 제공하여 동일한 리포지토리에서 여러 Cursor 세션을 실행할 수 있게 합니다 — 별도의 분기를 가리키는 별도의 작업 디렉토리입니다. 3개의 독립적인 작업(리팩토링 + 테스트 생성 + 문서 업데이트)이 있을 때, 이것은 실제 시간을 절약합니다. 작업이 독립적이지 않으면, 머지 고통을 만듭니다.
우리가 다국어 포스트 번역을 배포할 때, 병렬 Agent는 실행당 약 40분을 절약합니다. 트릭은 진정한 독립성입니다 — 파일 범위를 겹치게 하고 충돌을 해결하는 데 절약한 시간을 소비할 것입니다. 클라우드 Agent(Cursor의 Pro 계층 백그라운드 Agent)는 동일한 방식으로 작동하며, 단지 원격일 뿐입니다. 더 넓은 보기를 위해, Cursor의 클라우드 Agent는 우리의 비교에서 Devin과 Codex 같은 대안과 비교됩니다.
7. 실제로 사용하는 통합을 위해 MCP 서버를 추가하세요
MCP(Model Context Protocol) 서버는 Agent에게 호출할 수 있는 실제 도구를 제공합니다 — 데이터베이스, GitHub, Linear, Figma. MCP 없이 Agent는 시스템에 대해 말합니다. MCP를 사용하면 직접 쿼리합니다. 대부분의 팀에 가장 높은 레버리지인 4가지는 GitHub, Postgres(또는 Supabase), Linear, Figma입니다.
구성은 ~/.cursor/mcp.json(전역) 또는 .cursor/mcp.json(리포지토리별)에 있습니다. 최소한의 설정:
이번 주에 실제로 사용할 서버만 추가하세요 — 모든 서버가 Agent의 도구 예산을 소비합니다. modelcontextprotocol.io의 공식 MCP 사양이 프로토콜 자체의 신뢰할 수 있는 소스이며, 모든 Agent 호스트를 위한 전체 MCP 설정 가이드가 Cursor, Claude Code 및 나머지 부분 전체에 걸쳐 작동하는 패턴을 설명합니다.
8. Rules vs Skills vs MCP — 올바른 도구를 선택하세요
이 3가지는 한눈에 비슷해 보이지만 다릅니다. Rules는 지속적인 컨텍스트(당신이 누구인가, 스택이 무엇인가)입니다. Skills는 특정 작업을 위한 재사용 가능한 방법 가이드입니다(이 코드베이스에서 Stripe 웹훅을 추가하는 방법). MCP는 Agent에게 외부 시스템을 호출할 수 있는 도구를 제공합니다. 섞어서 쓰면 Rules를 과다하게 채우거나 Skills를 활용하지 않게 됩니다.
...