Cursor Plan Mode를 먼저 쓰는 이유와 Shift+Tab으로 시작하는 작업 순서 | DAKER 커뮤니티

에이전트에게 기능 추가를 맡기면 곧바로 파일이 바뀌기 시작합니다. 진행 표시가 빠르게 올라가면 금방 끝난 듯 보이지만, 막상 실행해 보면 권한 오류가 나거나 원하지 않은 경로에 페이지가 생기고, 이미 있는 코드를 다시 설명하느라 같은 대화를 반복하게 되기도 합니다.

Cursor 공식 영상 Cursor Agent: 10 Pro Tips!는 이 순서를 바꾸라고 말합니다. Agent 입력에서 Shift+Tab으로 Plan Mode를 켠 뒤, 코드베이스를 먼저 읽게 하고 확인 질문을 받은 다음, Markdown 계획과 할 일 목록을 만든 뒤에야 Build로 구현을 시작하는 방식입니다. 특히 해커톤이나 대회처럼 저장소가 빠르게 바뀌고 제출 기한이 가까운 상황이라면, 이 한 단계가 되돌리기 비용을 크게 줄여 줍니다.

왜 Plan Mode가 먼저인가

영상의 첫 번째 팁은 Plan Mode입니다. 발표자는 개인 사이트에 Spotify 상위 아티스트 페이지를 추가하는 예시를 보여 줍니다. 홈에는 이미 최근에 들은 곡이 붙어 있고, Spotify 연동 코드도 있는 상태였습니다. 이때 Plan Mode를 켜면 에이전트는 바로 코드를 쓰지 않고 기존 구현을 먼저 읽습니다. 그리고 경로 이름, 상위 몇 명을 보여 줄지, 기간 버킷을 어떻게 나눌지, 어떤 방식으로 표시할지 같은 선택지를 질문합니다.

답을 받은 뒤에는 새 Markdown 계획 파일을 만들고, 어떤 컴포넌트와 파일을 건드릴지 적은 뒤 할 일 목록까지 정리합니다. 발표자는 이 계획에서 음악 취향 소개 문단은 필요 없다고 판단해 해당 부분을 지운 뒤 저장하고 Build를 눌렀습니다.

Plan Mode의 핵심은 오류를 없애는 것이 아니라, 어디에 무엇을 넣을지와 어떤 파일을 만질지를 먼저 합의하는 데 있습니다.

Build 이후에도 한 번은 실패했습니다. 페이지를 열자 권한 오류가 났고, Spotify 토큰에 추가 권한이 필요했습니다. 발표자는 오류 문구를 그대로 에이전트에 붙여 다시 처리했고, 그다음에야 상위 아티스트 목록이 보였습니다. 여기서 중요한 점은 계획이 모든 문제를 미리 막아 준다는 뜻이 아니라, 오류를 고칠 때도 범위를 벗어난 재작성을 줄일 수 있다는 점입니다.

제출 기한이 가까운 저장소일수록 바로 코딩을 맡기기보다 계획 한 장을 먼저 받는 편이 안전합니다.

Plan Mode 다음에 함께 쓰기 좋은 기능들

컨텍스트 메뉴와 브랜치 리뷰

두 번째 팁은 컨텍스트 메뉴입니다. 채팅에 @를 입력하면 파일, 폴더, 공개 문서, 과거 채팅, 린터 오류, Git 관련 항목이 나옵니다. 그중 @Branch는 현재 브랜치의 변경 사항을 리뷰하라고 맡길 때 유용합니다. 영상에서는 top-artist 브랜치를 만든 뒤, AI가 만든 코드를 다시 AI에게 검토시키는 장면이 나옵니다. 캐시 시간 불일치 같은 작은 이슈를 짚어 주는 식입니다.

이 흐름은 만들었으니 끝이 아니라, 브랜치 단위로 한 번 더 본다는 습관에 가깝습니다.

커스텀 명령으로 반복 작업 줄이기

세 번째 팁은 커스텀 명령입니다. 프로젝트의 .cursor/commands/ 아래에 Markdown 파일을 두면, 에이전트 패널에서 /로 그 명령을 실행할 수 있습니다. 영상에서는 PR용 명령 예시가 나옵니다. 제목을 자세히 쓰고, GitHub CLI를 사용하며, 커밋이 없으면 먼저 커밋하라는 문장을 넣어 두었고, 실행 후 실제로 PR 링크가 생성됐습니다.

대회 팀에서 반복하는 제출 전 체크, 로그 요약, PR 본문 템플릿 같은 작업도 같은 방식으로 정리해 두면 설명을 매번 다시 하지 않아도 됩니다.

이미지와 채팅 복제

네 번째 팁은 이미지 활용입니다. 발표자는 상위 아티스트 목록을 Spotify Wrapped처럼 보이게 하려고 참고 이미지를 붙여 넣었습니다. 에이전트는 이미지 스타일을 읽고 데이터 fetch, 컴포넌트, 원격 이미지 설정을 함께 수정했습니다. UI 레퍼런스가 있을 때는 긴 설명보다 이미지 한 장이 범위 합의에 더 빠를 수 있습니다.

다섯 번째는 채팅 복제입니다. Duplicate chat을 쓰면 지금까지의 맥락을 유지한 채 다른 시도를 분기할 수 있습니다. 다만 발표자는 가능하면 컨텍스트를 작게 유지하라고도 말합니다. 복제와 새 시작 중 무엇이 나은지는 작업 크기에 따라 정하면 됩니다.

품질을 지키는 운영 습관

여섯 번째와 일곱 번째 팁은 보이는 숫자를 관리하는 일입니다. 컨텍스트 창 사용량 게이지를 보면, 영상에서는 Claude Sonnet 4.5 기준 약 200k 창에서 12% 정도를 사용한 상태가 표시됩니다. 대화가 길어지면 /summarize로 압축할 수 있지만, 언제 압축할지는 의도적으로 정하는 편이 좋습니다.

Settings에서 usage summary를 Always로 두면 한도 사용률과 리셋 시각이 항상 보입니다. 비용과 한도를 의식해야 하는 팀이라면, 이 표시만으로도 지금 채팅을 더 이어 갈지 새로 열지를 판단하기 쉬워집니다.

여덟 번째는 단축키입니다. 에이전트 창을 열고 모델을 바꾸는 동작을 손에 익히면 Plan Mode 전환과 새 채팅 생성도 자연스럽게 습관이 됩니다. 아홉 번째는 새 대화를 자주 여는 것입니다. 초보자가 자주 하는 실수는 한 채팅에 기능 A, B, C를 계속 쌓는 일입니다. 컨텍스트가 커질수록 모델이 앞선 지시를 놓치고, 엉뚱한 파일을 건드릴 위험도 커집니다.

기능 단위로 새 채팅을 열면 Plan Mode의 질문도 그 기능에만 맞춰집니다.

열 번째는 체크포인트입니다. 대화 중간 상태로 되돌려 최근 변경을 버릴 수 있습니다. 다만 발표자는 이것과 Git을 함께 쓰라고 강조합니다. 체크포인트는 실험용 되돌리기이고, 브랜치와 커밋은 팀과 공유하는 기록입니다.

보너스로는 작업 완료 사운드와 시스템 알림, 코드베이스 Mermaid 다이어그램 생성, Agent layout 베타가 짧게 소개됩니다. 하지만 이 영상의 핵심 행동은 첫 번째 팁에 있습니다. Plan Mode로 범위를 합의한 뒤 Build하고, 다음 기능은 새 채팅에서 다시 시작하는 흐름입니다.

대회·해커톤 저장소에 옮겨 쓰는 방법

DAKER·DACON 대회 코드는 제출 스크립트, 전처리, 모델, 결과 폴더가 한 저장소에 섞여 있는 경우가 많습니다. 이런 구조에서 에이전트에게 점수만 올려 달라고 하면, 학습 코드와 제출 포맷을 한꺼번에 건드리다가 재현이 깨지기 쉽습니다.

이럴 때는 Plan Mode에 넣는 문장을 짧게 유지하는 것이 좋습니다. 예를 들어 제출 폴더의 CSV 컬럼 순서를 대회 안내와 같게 맞추고, 검증용 스크립트 하나만 추가합니다. 학습 하이퍼파라미터는 바꾸지 않습니다처럼 오늘 끝낼 범위와 건드리지 않을 범위를 함께 적으면 계획도 그 경계를 따라갑니다.

계획이 나오면 먼저 파일 경로만 확인하면 됩니다. 발표자가 인트로 문단을 지운 것처럼, 대회 맥락에 필요 없는 새 대시보드 전체 재작성 같은 항목이 있으면 계획에서 덜어내는 편이 좋습니다. Build 후에는 로컬에서 한 번 실행해 보고, 오류 전문을 그대로 붙여 다시 고치면 됩니다. 권한이 필요한 API나 데이터 파일이라면 영상처럼 토큰이나 경로 문제를 별도 턴으로 처리하는 편이 안전합니다.

점수 실험은 다음 채팅으로 넘기는 편이 낫습니다. 한 채팅에 포맷 수정과 모델 튜닝을 같이 넣으면 컨텍스트가 섞이기 쉽기 때문입니다.

팀으로 작업할 때는 커스텀 명령이 특히 유용합니다. .cursor/commands/submit-check.md에 필수 컬럼 목록, 파일명 규칙, git status에 학습 가중치가 섞이지 않았는지 같은 항목을 적어 두면, 사람마다 다른 체크리스트를 말로 반복하지 않아도 됩니다. PR 명령처럼 GitHub CLI를 쓰라는 문장을 넣어 두면 리뷰어가 보는 제목과 본문 형식도 맞추기 쉽습니다. 여기에 @Branch로 브랜치 리뷰를 한 번 더 돌린 뒤 사람이 diff를 확인하는 순서를 팀 규칙으로 두면 운영이 한결 단단해집니다.

오늘 바로 적용할 수 있는 작업 순서

실제로는 복잡하게 시작할 필요가 없습니다. Cursor에서 Agent 입력을 연 뒤 Shift+Tab으로 Plan Mode를 켜고, 오늘 넣을 기능 하나만 적으면 됩니다. 예를 들어 제출 로그 표, 결과 카드 한 장, 평가 스크립트 연결, README의 실행 명령 정리처럼 범위가 분명한 작업이 적당합니다.

질문이 나오면 경로, 개수, 기간, 표시 범위 정도만 짧게 답하고, 계획이 만들어지면 파일 목록과 할 일 위주로 읽으면 됩니다. 필요 없는 문단이나 과한 범위는 계획에서 지운 뒤 Build를 누르면 됩니다. 오류가 나면 추측을 길게 설명하기보다 터미널이나 브라우저에 보이는 메시지를 그대로 붙여 다시 고치는 편이 낫습니다.

계획 파일은 합의 기록이기 때문에, 경로와 할 일을 잠깐 확인하는 것만으로도 큰 되돌리기를 줄일 수 있습니다.

다음 기능으로 넘어가기 전에는 새 채팅을 열고, 큰 변경이라면 Git 브랜치를 먼저 만드는 편이 좋습니다. 결과가 어색하면 체크포인트로 되돌린 뒤 계획을 다시 받으면 됩니다.

오늘 하지 않는 편이 좋은 것들

한 채팅에서 기능 세 개를 연달아 부탁하는 방식은 피하는 편이 좋습니다. 영상에서도 반복해서 나오는 경고입니다. 컨텍스트가 커지면 앞선 지시가 흐려지고, 이미 끝낸 파일을 다시 고치거나 다른 기능의 이름을 가져오는 일이 생기기 쉽습니다. 일단 되게만 하자는 마음으로 UI, 로깅, 문서까지 한 대화에 몰아넣는 습관도 같은 문제로 이어집니다.

Plan Mode를 켜 놓고도 계획을 읽지 않은 채 Build만 누르는 것도 아쉬운 사용법입니다. 계획 파일은 단순한 중간 산출물이 아니라 합의 기록입니다. 경로와 할 일만 짧게 확인해도 나중에 한참 되돌리는 일을 줄일 수 있습니다.

체크포인트만 믿고 Git을 쓰지 않는 것도 위험합니다. 체크포인트는 그 대화 안에서의 실험용 되돌리기이고, 팀원이나 다른 기기에서는 보이지 않을 수 있습니다. 큰 UI 변경이나 데이터 스키마 변경 전에는 브랜치를 만들고, 동작이 확인된 뒤에만 합치는 편이 안전합니다. 사용량 게이지를 끄고 쓰면 한도 직전에야 문제를 알아차릴 수 있으니, Settings에서 usage summary를 Always로 두는 방법도 함께 기억해 둘 만합니다.

정리

Cursor 공식 영상이 소개한 열 가지 팁의 공통점은 에이전트를 더 많이 돌리는 데 있지 않습니다. 에이전트가 보는 범위와 기록을 사람이 먼저 고르는 데 있습니다. Plan Mode로 오늘 범위를 합의하고, @와 커스텀 명령으로 반복 작업을 줄이고, 새 채팅과 체크포인트, Git으로 실패 비용을 낮추는 흐름입니다.

결국 가장 먼저 바꿔 볼 만한 습관은 단순합니다. 바로 코딩을 맡기기보다 계획 한 장 → Build → 새 채팅 순서로 가는 것입니다.

참고 자료

Cursor Agent: 10 Pro Tips! — 채널: Cursor
전체 URL: https://www.youtube.com/watch?v=WVeYLlKOWc0

여러분은 Cursor에서 바로 Build로 들어가는 편인지, 아니면 Plan Mode로 먼저 범위를 정하는 편인지 궁금합니다.