커서를 잘못 사용하고 있습니다.

대부분의 개발자들은 Cursor를 열고 에이전트 모드로 전환한 후, 단락 길이의 기능 요청을 입력하고 Enter를 누릅니다. "인증, 역할 기반 접근, 차트가 있는 AI 기반 대시보드를 만들어줘,"라고 말한 후, 모델이 레포지토리 전반에 걸쳐 파일을 다시 작성하는 동안 편안히 기대합니다. 처음 30초는 마법 같은 느낌이지만, 차이를 읽기 시작하면 그런 기분이 사라집니다.

그 단일 프롬프트 뒤에서 AI는 당신이 남긴 모든 공백을 조용히 채워 넣습니다. 프로젝트의 제약보다는 자신의 경험에 기반하여 폴더 구조, 상태 관리, API 경계, 심지어 UI 패턴을 결정합니다. 기술적으로 컴파일은 되지만 종종 당신의 디자인 시스템을 무시하고, 기존의 추상화를 깨트리거나 이미 다른 파일에 존재하는 로직을 재구현하는 코드를 얻게 됩니다.

이것이 에이전트 모드 트랩의 핵심입니다: 당신은 구현을 위임하고 있다고 생각하지만, 실제로는 아키텍처를 위임하고 있습니다. 커서가 “Stripe 청구 추가”를 보게 되면, 지난 분기에 작성한 결제 유틸리티와 통합하는 대신 새로운 훅, 라우트 및 설정을 만들어낼 수 있습니다. 이러한 것들은 500줄의 차이(diff)를 스크롤하면서 왜 당신의 앱의 절반이 갑자기 이동했는지 궁금해할 때까지는 보이지 않는 가정들입니다.

결과가 당신의 정신 모델에서 벗어나면, “다시 해봐”라는 의식을 시작합니다. “아니, 폴더 구조는 유지해,” “사실, Tailwind를 사용해,” “인증 흐름은 건드리지 마,”라고 말하며 매번 새로운 대규모 수정 작업을 촉발합니다. 모델은 당신의 제약이 머릿속에 있을 뿐, 공유된 계획 안에는 없기 때문에 해석 간에 흔들립니다.

사소한 변경 사항(소품 이름 변경, 작은 버그 수정)을 넘어서는 모든 작업에 대해서는 이 워크플로우가 잘 확장되지 않습니다. 다수 파일로 이루어진 기능, 교차 절단 문제 및 점진적인 리팩토링은 각 구성 요소가 어떻게 맞아야 하는지에 대한 공유된 Mental Model을 요구합니다. 에이전트 모드를 맹목적으로 사용하면 그 단계를 건너뛰고 관련성이 있다고 생각되는 파일을 바로 편집하게 됩니다.

당신은 AI로 생성된 아키텍처 결정에 대한 인간 린터 역할을 하게 됩니다. 더 빠르게 배송하기보다는, 예상치 못한 마이그레이션을 검토하고, 공격적인 수정을 되돌리며, 어색한 추상화를 패치하는 데 시간을 낭비합니다. 커서는 “코드 슬롯 머신”이 되어버립니다: 레버를 당기고, 차이가 의도한 대로 맞기를 바라며, 맞지 않으면 다시 당깁니다.

대부분의 사람들은 Cursor를 코드 자판기처럼 취급합니다: 거대한 프롬프트를 에이전트에 입력하고, 전송 버튼을 눌러 수정 사항이 의미 있게 만들어지길 희망합니다. 커서 계획 모드는 그 작업 흐름에 누락된 단계를 추가하여 AI를 지나치게 열의 있는 인턴에서 체계적인 기술 리드로 변모시켜, 파일 하나도 터치하기 전에 작업을 명확히 정리합니다.

당신의 저장소에 변경 사항을 일괄적으로 적용하는 대신, Plan Mode의 핵심 업무는 간단하고 엄격합니다: “작업을 완료하기 위한 상세한 계획을 수립하는 것”. 커서가 코드베이스를 스캔하고, 명확한 질문을 하며, 코드 생성이 시작되기 전에 아키텍처 결정, 파일 수준 변경 및 구현 단계를 설명하는 Markdown 청사진을 작성합니다.

액세스는 이미 사용하는 에이전트 드롭다운 메뉴에 있습니다. 채팅 입력 옆의 모드 선택기를 클릭하면 다음을 볼 수 있습니다: - 에이전트: 직접 코드 수정 - 플랜 모드: 구조화된 구현 계획 - 디버그: 런타임 문제 추적 및 수정 - 질문하기: 수정 없는 순수 Q&A

플랜 모드로 전환하면 커서의 동작이 전환됩니다. 예를 들어, “OpenAI API를 사용하여 이 Next.js 앱에 AI 기반 색상 팔레트 생성기를 추가하십시오.”라는 프롬프트는 더 이상 즉각적인 파일 쓰기를 트리거하지 않고, 구성 요소, API 통합 지점, UI 상태 및 엣지 케이스를 설명하는 중간 계획 파일인 일반적으로 `.md` 파일을 생성합니다.

그 Markdown 계획은 살아있는 사양 역할을 합니다. 빌드 단계가 실행되기 전에 단계를 편집하고, 위험한 아이디어를 거부하며, 파일 이름을 바꾸거나 범위를 축소할 수 있습니다. 이는 에이전트 모드만으로는 서두를 때 잘 권장되지 않습니다. 5~10개의 파일에 걸쳐 복잡한 기능을 다룰 경우, 이러한 사전 협의는 재작업 및 예기치 않은 차이를 크게 줄여줍니다.

커서(Cursor)는 대화 엔진으로서 플랜 모드(Plan Mode)도 사용합니다. 모델은 디자인 선호도, 성능 제약 또는 라이브러리 선택에 대해 질문한 후, 당신의 답변에 따라 계획을 업데이트합니다. 이는 “AI가 조용히 결정하는 것”에서 공동 저작 의도로 이동하는 것으로, 이곳에서 품질이 뛰어납니다.

이것은 혼잡한 UI의 또 다른 토글이 아닙니다. 계획 모드는 Cursor를 코드 작성기에서 기획 파트너로 재구성하여, `pnpm dev`를 입력하기 전에 디자인 문서를 요구하는 선임 엔지니어와의 협업에 더 가까워집니다. 이를 채택하게 되면, 계획 없이 에이전트를 실행하는 것이 무모하게 느껴지기 시작합니다.

커서 계획 모드는 겉으로 보기에는 간단한 것으로 시작합니다: 구체적인 사양이 아닌 대략적인 아이디어를 입력합니다. 데모를 위해 Astro K Joseph은 빈 Next.js 스타터 위에 "AI 기반 색상 팔레트 생성기 웹사이트"에 대한 모호한 브리프를 넣습니다. 아직 파일 변경은 없습니다; 계획 모드는 수정 대신 분석으로 전환됩니다.

조용히 나아가는 대신, AI는 질문을 던집니다. 커서가 사용자에게 어두운 테마 또는 밝은 테마 중 어떤 것을 원하는지, 사용자가 색상 팔레트를 생성하는 방법(텍스트 프롬프트, 이미지 업로드, 또는 랜덤)과 OpenAI API의 역할에 대해 묻습니다. 또한 레이아웃 세부 사항에 대해서도 질문합니다: 랜딩 페이지 대 다중 페이지 앱, 색상 코드가 표시될 위치, 그리고 사용자가 팔레트를 저장하거나 공유해야 하는지 여부를 탐색합니다.

그 상호작용은 모호한 아이디어를 구체적인 청사진으로 바꿉니다. 당신이 대답할 무렵에는 다음과 같은 결정이 내려져 있습니다:

• 1UX 흐름 (싱글 페이지 vs. 대시보드 스타일)
• 2팔레트 생성 트리거 (버튼, 실시간 미리보기 또는 폼 제출)
• 3OpenAI API의 데이터 형식 및 검증 방법
• 4“세련되고 현대적인” 대 “재미있는”과 같은 시각적 제약

Cursor는 그 답변들을 Markdown 계획으로 정리합니다: 프로젝트 개요, API 사용, UI 구성 요소, 라우트, 구현 단계에 대한 섹션으로 나뉘어 있습니다. 각 단계는 특정 파일과 함수에 참조를 두어 새로운 구성 요소, 훅, 유틸리티 모듈이 정확히 어디에 위치할지를 보여줍니다. 코드를 수정하기 전, 미니 디자인 문서처럼 그 계획을 편집할 수 있습니다.

그것과는 대조적으로 에이전트 모드는 조용하게 모든 호출을 대신 수행할 수 있습니다. 무작위 레이아웃을 선택하거나, 라이트 테마를 하드코딩하거나, OpenAI 응답을 당신의 아키텍처와 충돌하는 방식으로 상태에 연결할 수 있습니다. 이러한 가정은 코드베이스 전반에 걸쳐 변경 사항이 퍼진 후에야 발견됩니다.

인터랙티브 계획은 그 모호함을 없앱니다. 당신과 커서가 API 예산부터 UI 다듬기까지 제약 조건을 공동 소유하므로, 후속 "코드 생성" 단계는 실행처럼 느껴지고, 룰렛 게임처럼 느끼지 않습니다. 더 큰 프로젝트에서 이 계획 레이어가 어떻게 작동하는지에 대한 심층적인 예시는 커서의 커서 플랜 모드 공식 블로그에서 다중 파일, 다단계 워크플로우를 더 자세히 설명하고 있습니다.

커서 플랜 모드는 단순히 생각하지 않습니다; 작성합니다. 요구 사항 협상이 끝난 후, 모든 것을 Markdown 사양서로 구체화합니다—AI가 코드 한 줄이 변경되기 전 정확히 무엇을 할 것인지 명시한 단일 `.md` 파일입니다.

그 Markdown 계획은 일반적으로 아키텍처 개요로 시작됩니다. 여기에는 앱의 핵심 구성 요소, 데이터 흐름 및 경계에 대한 섹션이 포함되어 있습니다: 프론트엔드에서 어떤 것이 존재하는지, API 계층에 어떤 요청이 가는지, 상태가 시스템을 통해 어떻게 이동하는지, OpenAI API와 같은 외부 서비스가 어디에 연결되는지 설명합니다.

다음은 구체적인 기술 스택 분해입니다. Next.js 색상 팔레트 생성기인 Cursor는 “Next.js 앱 라우터, TypeScript, Tailwind CSS, OpenAI API, 변이를 위한 서버 액션”과 같은 결정 사항을 확정할 수 있으며, “데이터베이스 없음, 로컬 상태만 사용” 또는 “localStorage를 통해 팔레트를 지속화”하는 등의 제약도 설정할 수 있습니다.

사양은 그러고 나서 현실의 파일 수준 맵으로 전환됩니다. 일반적으로 다음과 같은 내용이 포함됩니다: - 생성해야 할 파일 (예: `app/page.tsx`, `app/api/palettes/route.ts`) - 수정해야 할 파일 (예: `app/layout.tsx`, `styles/globals.css`) - 현재는 그대로 두어야 할 파일

그 아래에서 계획 모드는 한 단계씩 할 일을 나열합니다. 각 항목은 구체적인 행동을 설명합니다: “프롬프트 양식 구현,” “OpenAI에 API 경로 연결,” “로딩 및 오류 상태 추가,” “재사용 가능한 `PaletteCard` 컴포넌트 생성,” “API 핸들러에 대한 최소한의 테스트 작성.” 커서는 나중에 이 체크리스트를 실행 스크립트로 사용합니다.

계획은 Markdown 형식으로 작성되기 때문에 경량 디자인 문서처럼 작동합니다. 편집기에서 검토하고, 코드 리뷰에 댓글을 추가하거나, 슬랙에 스니펫을 붙여넣어 리팩토링이 진행되기 전에 팀원에게 빠른 피드백을 받을 수 있습니다.

팀은 이러한 `.md` 계획을 레포지토리에 커밋할 수 있습니다. 이는 기능이 존재하는 이유, 수용한 트레이드오프, 구현이 어떻게 발전했는지를 검색 가능한 기록으로 생성합니다. 이는 미스터리 풀 리퀘스트의 차이보다 훨씬 더 투명합니다.

가장 중요한 것은 이 아티팩트가 여러분에게 완전한 가시성을 제공한다는 것입니다. 커서가 조용히 파일을 편집하는 대신, 여러분은 변경 사항의 전체 의도, 범위, 순서를 미리 보고, AI가 한 줄도 작성하기 전에 청사진을 승인합니다.

제품 사양의 초안은 발송하지 않으며, Cursor의 계획 초안도 발송해서는 안 됩니다. Cursor Plan Mode가 그 Markdown 청사진을 뱉어내면, 진정한 작업이 시작됩니다: 건축가로서 행동하는 것입니다, 청중이 아니라.

커서는 AI 기반 색상 팔레트 생성기를 위해 경로, 구성 요소, API 호출, 심지어 파일 이름을 제안합니다. Markdown 사양에 따라 한 줄씩 진행하며 불필요한 부분을 줄이고, 모듈 이름을 변경하며, 계획을 실제 아키텍처, 디자인 시스템 및 비협상 요소와 일치시킵니다.

AI가 잊어버린 “이미지 업로드 및 주요 색상 추출” 기능이 필요하신가요? 계획에 새로운 하위 섹션을 추가하세요: 필요한 UI 변경 사항, `/api/upload` 엔드포인트, 파일 크기 제한, 및 이미지가 로컬 디스크가 아닌 S3로 전송된다는 메모. 이제 Cursor는 스택과 인프라를 추측하는 대신 정확한, 인간 승인 계약을 보유하고 있습니다.

또한 잘못된 가정을 악화되기 전에 수정할 수 있습니다. Cursor가 클라이언트에서 OpenAI API를 직접 사용하도록 제안하면, 해당 단계를 수정하여 모든 요청이 서버 측 Next.js API 핸들러를 통해 라우팅되도록 하고, 속도 제한을 추가하며, 환경 변수 사용을 명시합니다.

이 편집 우선 루프는 나중에 디버깅하는 것보다 훨씬 더 안전합니다. 계획을 수정하는 것은 몇 줄의 마크다운을 변경하는 것으로 끝나지만, 생성된 코드를 수정하는 것은 5~10개의 파일을 뒤지고、副작용을 구분하며, AI가 이상한 추상화를 선택한 이유를 유추하려는 노력이 필요합니다.

당신도 더 빨리 움직입니다. 계획을 업데이트하여 다음을 추가합니다: - 다크 모드 지원 - 키보드 단축키 - 사용자 프로필에 팔레트 저장

텍스트에서 여러 번의 프롬프트–생성–되돌리기 사이클 대신 몇 초 만에 완료됩니다. 그런 다음 Cursor는 그 단일화된 업그레이드 계획을 일관된 방식으로 실행합니다.

당신이 최종 권한을 가지고 있습니다. Cursor가 전략을 초안하지만, 어떤 라이브러리, 패턴 및 제약이 유지될지는 당신이 결정합니다. Plan Mode를 설계 문서를 작성하는 주니어 엔지니어로 취급하세요: 가치 있고, 빠르며, 세부적이지만, 코드 한 줄이 변경되기 전에는 항상 당신의 검토를 받아야 합니다.

승인은 커서가 생각을 멈추고 행동하기 시작하는 지점입니다. 빌드를 클릭하면, 추상적인 Markdown 사양이 즉시 계약으로 구체화됩니다: 해당 문서의 모든 항목, 파일 경로 및 TODO는 이후에 발생할 일에 대한 에이전트의 명확한 기준이 됩니다.

Cursor의 에이전트는 이제 해당 계획을 귀하의 리포를 위한 마이그레이션 스크립트처럼 처리합니다. 체크리스트를 단계별로 확인하며, 구체적인 작업을 수행합니다: 파일 생성 및 이름 변경, 패키지 설치, 임포트 연결, 설정 업데이트 등, 모두 귀하가 이미 승인한 구조에 맞춰 진행됩니다.

왜냐하면 플랜 모드에서 엄격한 논리가 작용하기 때문에 실행이 빠르고 놀라울 정도로 결정적입니다. 모델은 더 이상 아키텍처에 대해 다시 논의하는 데 토큰을 소모하지 않고, 단순히 “3단계: /app/api/palettes/route.ts 구현”을 수정으로 매핑하여 불필요한 리팩토링과 무작위 파일 수정이 줄어듭니다.

커서를 통해 Markdown 사양을 빌드 로그처럼 확인할 수 있습니다. 각 완료된 항목이 파일을 편집할 때 체크되어, 페이지를 구축하거나 훅을 추가하거나 프로바이더를 연결할 때 정확히 언제 이루어지는지 알 수 있습니다. AI가 당신도 모르게 조용히 무엇을 변경하고 있는지 걱정할 필요가 없습니다.

복잡한 작업이 섬세하게 느껴지지 않는 것은 동일한 청사진에 기반하기 때문입니다. Next.js 앱의 경우, Cursor는 한 번의 작업으로 다음을 수행할 수 있습니다: - 올바른 /app/api 하위 트리에 API 라우트 설정 - Tailwind 또는 shadcn/ui와 같은 UI 라이브러리 설치 및 구성 - React 컴포넌트를 레이아웃, 섹션 및 공유 원시 요소로 구조화

그 동작들은 "스마트해 보이지만" 실제로는 순종적입니다. 계획서에 "사용자 정의 색상 팔레트를 사용하여 Tailwind를 활용하라"라고 적혀 있다면, Cursor는 tailwind.config를 추가하고, globals를 업데이트하며, 사양에서 지시하는 정확한 위치에 JSX에 클래스를 주입합니다. 즉, 무작위 디자인 시스템을 즉흥적으로 만들지 않습니다.

의존성 관리도 계획의 통제 아래에 있습니다. 마크다운에서 OpenAI, Zustand 또는 차트 라이브러리를 호출하면 Cursor는 해당 npm 또는 pnpm 설치를 실행하고, tsconfig 또는 env 유형을 업데이트한 후 이들 패키지가 존재한다고 가정하는 코드를 작성합니다.

더 깊은 기술적 행동 및 기타 자동화 실험에 대해 Cursor는 Cursor 기능 페이지에서 이 구축 계획 파이프라인을 문서화하고 있지만, 핵심 변화는 간단합니다: 구축 버튼을 누르면 Cursor는 논의를 멈추고 귀하의 청사진을 줄줄이 실행하기 시작합니다.

대부분의 Cursor 사용자들은 계획 모드를 반짝이는 토글처럼 취급하고 무시합니다. 이는 잘못된 접근입니다. 계획 모드는 실제로 아키텍처를 변화시키는 작업을 위해 존재하며, 단일 파일에 몇 줄의 코드를 추가하기 위해서가 아닙니다.

앱의 형태를 변경할 때 커서 계획 모드를 선택하세요. 여기에는 여러 구성 요소에 영향을 미치는 새로운 기능을 구축하거나, 새로운 API를 도입하거나, 프로젝트 전반에 걸쳐 데이터 흐름을 재구성하는 작업이 포함됩니다. 다이어그램을 그리거나 디자인 문서를 작성해야 한다고 느낄 때마다, 그것은 계획 모드의 영역입니다.

플랜 모드는 여러 파일을 동시에 리팩토링할 때 매우 유용합니다. 예를 들어, REST에서 GraphQL로 이동하거나, 모놀리식 React 컴포넌트를 적절한 기능 모듈로 분할하거나, 자사 개발 인증 레이어를 OAuth로 교체하는 경우를 생각해 볼 수 있습니다. 커서는 영향을 받는 파일을 매핑하고, 단계별 순서를 제안하며, 전체 리팩토링을 일관되게 유지하여 무작위로 편집하는 대신 체계적으로 진행할 수 있도록 돕습니다.

낯선 코드베이스인가요? 플랜 모드로 전환하세요. 50,000줄의 레거시 앱을 상속받으면, Cursor는 복잡함 속을 당신보다 빠르게 파악하고 주요 모듈을 정리한 뒤 새로운 로직이 어디에 있어야 할지를 제안합니다. 당신은 아키텍처를 제어하고, AI는 스캔과 조직의 번거로운 작업을 처리합니다.

복잡한 로직도 계획 모드에 포함됩니다. 결제 흐름, 다단계 온보딩, 백그라운드 작업 오케스트레이션 또는 재시도, 경쟁 조건, 엄격한 성능 제약과 관련된 모든 것은 검토하고 댓글을 달며 저장소에 커밋할 수 있는 마크다운 계획에서 이점이 있습니다.

에이전트 모드는 여전히 중요하지만, 정밀한 수정에 사용됩니다. 변경할 내용과 위치를 이미 알고 있다면 에이전트를 사용하고, 단지 커서가 당신보다 빠르게 입력하길 원합니다. 작업이 하나의 정신적 화면에 편안하게 맞아떨어진다면, 아마도 계획이 필요하지 않을 것입니다.

빠르고 지역적인 수정이 필요할 때는 에이전트 모드를 유지하고 계획 수립에 소요되는 시간을 피하세요: - 하나의 함수에서 버그 수정 - 파일 전반에 걸친 변수 또는 속성 이름 변경 - 콘솔 로그 추가 또는 단일 가드 절차 추가 - 작은 JSX 코드 조각 또는 CSS 규칙 업데이트

플랜 모드를 당신의 건축 공동 비행사로 생각하세요, 철자 검사기처럼 사용하지 마세요. 디자인 결정이 중요할 때 사용하고, 단순히 빠른 도움이 필요할 때는 건너뛰세요.

커서는 이제 “단순한 AI 자동완성”이 아닙니다. 그 모드를 통합된 시스템으로 다룰 때 진정한 잠재력을 발휘합니다. 커서 계획 모드는 청사진을 제공하지만, 첫 번째 빌드 이후 모든 것을 처리하는 두 개의 다른 에이전트와 함께 작동합니다: 디버그 모드와 질의 모드. 이 셋은 함께 건설, 수리, 조사에 있어 밀접한 순환 구조를 형성합니다.

Plan Mode를 건설 팀으로 생각해 보세요. 이는 Markdown 사양을 공동 저작하고, 파일 구조를 결정하며, 변경 사항이 발생하기 전에 아키텍처에 동의하는 데 사용됩니다. Build를 클릭하면 Agent 모드가 그 계획을 실행하여 이미 승인한 방식으로 구성 요소, API 및 UI를 연결합니다.

버그는 앱이 실제 데이터, 실제 사용자, 혹은 잘못 구성된 환경을 만나는 순간 발생합니다. 디버그 모드는 바로 그런 순간을 위해 존재하며, 감각 대신 런타임 추적을 사용합니다. Cursor는 스택 추적, 로그 및 오류 메시지를 수집하여 문제를 일으키는 특정 파일과 함수로 다시 매핑할 수 있습니다.

`console.log` 디버깅으로 허우적대기보다는, 디버그 모드에 실패한 명령어, 테스트 출력 또는 추적을 입력합니다. 이를 통해 다음과 같은 작업을 수행할 수 있습니다: - 관련 파일에서 근본 원인 식별 - 최소한의 범위에서 수정 제안 - 기존 계획을 유지하면서 패치 적용

Ask Mode는 워크플로우의 세 번째 단계인 이해를 다룹니다. Ask Mode는 편집 권한을 부여하지 않고 코드베이스를 검색 가능한 뇌처럼 탐색할 수 있게 해줍니다. “우리는 어디에서 JWT를 검증하나요?”, “테마 상태는 레이아웃에서 컴포넌트로 어떻게 흐르나요?”, 또는 “지난주와 비교해 이 PR에서 뭐가 바뀌었나요?”와 같은 질문을 할 수 있습니다.

Ask Mode는 귀하의 리포지토리, 문서 및 Plan Mode에서 생성된 Markdown 사양을 읽기 때문에 onboard 직원 엔지니어처럼 작동합니다. 파일 경로, 코드 발췌 및 설명을 제공하면서도 귀하는 수정 작업을 완전히 수동으로 제어할 수 있습니다. 예상치 못한 리팩토링, 숨겨진 차이점은 없습니다.

전문 도구 세트로 활용하세요: 건설을 위한 계획 모드, 수리를 위한 디버그 모드, 상담을 위한 질문 모드. 기능을 계획하고, 코드를 배포하며, 충돌을 디버그하고, 아키텍처에 대해 문의하는 모든 작업을 Cursor 안에서 수행하세요. 반쪽짜리 AI 채팅과 여러 도구 사이를 오가는 불편함을 없애줍니다.

AI 코딩은 예전에는 일종의 마술처럼 보였는데, 기능을 설명하고 생성 버튼을 클릭한 후 최선의 결과를 바라기만 하면 됐습니다. 그러나 커서 플랜 모드는 그 패러다임을 조용히 뒤바꾸어 모델을 단순한 자동 완성 도구에서 벗어나 명세 기반의 협업자로 변화시킵니다. 이는 마치 직원 엔지니어처럼 행동하며 코드 천사와는 다릅니다.

이제는 마크다운 디자인 문서를 공동 작성하여 여러분의 저장소에 저장하고, 다른 아티팩트처럼 버전 관리되고 검토될 수 있습니다. 커서가 코드베이스를 탐색하면서 파일 수준의 변경을 제안하고, 한 줄도 건드리기 전에 명확한 질문을 던지는 방식은 진지한 팀들이 RFC 및 기술 사양을 다루는 방식과 유사합니다.

그 구조는 코드가 변화하는 것만큼 개발자의 심리도 변화시킵니다. 구성 요소, API 호출 및 엣지 케이스의 구체적인 체크리스트를 보게 되면, 개념을 재조정하거나 범위를 조정하거나 누락된 제약 사항을 지적할 수 있습니다. 이렇게 하면 diff에 매몰되기 전에 미리 대응할 수 있습니다. 개발자들은 AI가 “결정”한 내용을 역설계하는 데 드는 시간이 줄어들어 구현 방향을 조정하는 데 더 많은 시간을 할애함으로써 더 빠른 반복 작업을 보고합니다.

코드 품질이 향상되는 이유는 모델이 모호한 문장이 아니라 공유된 계획에 대해 최적화하기 때문입니다. "팔레트 생성을 위해 OpenAI API 사용", "테마 토큰 중앙화", "다크 모드 지원"을 명시적으로 나열한 계획은 불필요한 추상화, 유휴 파일, 일회성 해킹을 dramatically 줄여줍니다. 이렇게 하면 특히 다중 파일 Next.js 또는 React 빌드에서 더 적은 약한 패치와 더 일관된 아키텍처를 얻을 수 있습니다.

자신감도 상승합니다. Cursor가 단계별 실행 경로를 보여줄 때, 문제가 발생할 수 있는 지점, 테스트가 도달해야 할 곳, 그리고 풀 리퀘스트에서 검토해야 할 사항을 알 수 있습니다. 이러한 투명성 덕분에 저작권을 포기하지 않으면서 자동화를 신뢰하는 것이 더 쉬워지며, 이는 팀들이 점점 더 플랜 모드를 가벼운 디자인 검토 게이트로 취급하는 이유입니다.

한 발 물러서서 보면, 이것은 더 넓은 에이전트 중심 워크플로우 트렌드의 일환입니다. 다양한 도구들이 단일 입력에서 다단계 에이전트로 이동하고 있으며, 이들은 계획하고 비판한 다음 실행합니다. 이 변화의 심층 분석을 원하신다면, (LSJ) 커서의 새로운 계획 모드 - 평생 세계에서 유사한 패턴을 설명하고 있습니다.

오늘의 커서 계획 모드는 기능 전환처럼 보입니다. 몇 년 후에는 이러한 계획-후 구축 루프가 인간과 기계가 동일한 사양을 가지고 작업하는 소프트웨어 작성의 기본 방법이 될 가능성이 높습니다.

커서는 실제로 계획을 처음부터 끝까지 실행할 때 새로운 패러다임으로 클릭됩니다. 자, 이제 다섯 분 도전이 있습니다: 지금 당장, 내일도 아니고 “시간이 날 때”도 아닌, 커서 계획 모드를 사용하여 마이크로 기능을 배송해 보세요.

작고 집중된 프로젝트를 구축하세요: `제목`과 `내용`이라는 두 개의 필드와 저장된 메모 목록이 있는 Markdown 노트 작성 앱. 인증, 동기화, 태그, 방해 요소는 없습니다. Cursor의 계획을 평가할 수 있을 만큼 작고, 자신의 복잡성 예산은 고려하지 않으려는 것입니다.

먼저 선택한 스택에서 빈 프로젝트를 생성하세요: 최소한의 Next.js 앱, Vite + React 스타터, 또는 단일 파일 Node 스크립트. 리포지토리를 깔끔하게 유지하세요: 불필요한 라이브러리, UI 키트, 데이터베이스 통합은 아직 필요하지 않습니다. 캔버스가 간단할수록 Cursor의 계획이 더 명확하게 읽힐 것입니다.

다음으로, 드롭다운을 사용하여 측면 패널 모드를 에이전트에서 플랜 모드로 전환하십시오. 색상 변경이 확인되었는지 확인하여 자동 편집 모드에 우연히 빠지지 않도록 하십시오. 모델을 선택하고 다른 내용을 입력하지 않으며 "코드"에서 "디자인"으로의 정신적 전환을 명확히 인식하도록 하십시오.

간단한 Markdown 노트 작성 앱을 만드세요. 제목 필드, Markdown을 지원하는 내용 텍스트 영역, 저장된 노트 목록 및 기본 클라이언트 측 저장소를 포함합니다. 깔끔하고 반응형 레이아웃을 사용하세요. 상태 라이브러리나 CSS 프레임워크와 같은 구현 세부사항은 피하세요.

커서는 명확한 질문으로 응답할 것입니다. 그에 대해 직접적으로 답변하세요: - 프레임워크 또는 스택 선호도는 무엇인가요? - LocalStorage와 API 백엔드 중 어떤 것을 원하시나요? - 스타일링 방식: CSS 모듈, Tailwind, 아니면 인라인 스타일 중 어떤 것을 선호하나요? - 파일 구조에 대한 제약이 있나요?

그런 상호작용 후, Cursor는 파일, 구성 요소, 저장소 선택 및 UI 상태를 설명하는 Markdown 사양 시트를 생성합니다. 한 줄씩 읽어보세요: 파일 경로, 구성 요소 이름, 그리고 Markdown 렌더링을 처리하는 계획을 확인하세요. 동료를 위해 작성할 문서와 일치하도록 사양을 실제 문서처럼 편집하세요.

계획이 지루하게 뻔하게 느껴질 때에만 Build를 누르세요. 방금 공동 작성한 체크리스트를 따라 Cursor가 진행하는 모습을 지켜보세요. 그 순간, 당신의 막연한 아이디어가 구조화된 실행 가능한 청사진으로 구체화되는 것을 보는 것은 Cursor 사용 방식을 영구적으로 바꿔 줄 “아하”의 순간입니다.

Cursor의 플랜 모드란 무엇인가요?

플랜 모드는 Cursor IDE의 기능으로, 여러분과 AI가 코드 작성 전에 Markdown 파일에서 자세한 단계별 구현 계획을 협력하여 작성할 수 있게 해줍니다. 이를 통해 접근 방식에 대한 명확성과 일치를 보장합니다.

Plan 모드는 기본 에이전트 모드와 어떻게 다른가요?

에이전트 모드는 프롬프트에 따라 직접 코드를 수정합니다. 플랜 모드는 먼저 청사진을 생성하고, 명확한 질문을 하며, 계획을 검토하고 수정할 수 있도록 한 후, 빌드 프로세스를 실행하여 오류와 재작업을 줄입니다.

Cursor에서 모든 작업에 플랜 모드가 반드시 필요한가요?

아니요, 그렇지 않습니다. 플랜 모드는 중대형 기능, 여러 파일 변경, 또는 익숙하지 않은 코드베이스에서 작업할 때 가장 효과적입니다. 작고 국소적인 수정의 경우, 표준 에이전트 모드가 더 효율적인 경우가 많습니다.

AI가 코딩을 시작하기 전에 계획을 수정할 수 있나요?

네. 플랜 모드의 핵심 이점은 생성된 Markdown 계획을 검토하고, 수정하며, 추가할 수 있다는 것입니다. 여러분은 빌드를 시작하기 전에 최종 설계도에 대한 완전한 통제권을 가지고 있습니다.