Cursor Plan Mode로 바로 코드를 쓰지 않습니다 — 오늘 Shift+Tab으로 계획부터 받고 Build하십시오 | DAKER 커뮤니티

에이전트에게 “이 기능 추가해 주십시오”라고 보내는 순간부터 파일이 바뀌기 시작합니다. 화면에는 진행 표시가 빠르게 올라가고, 잠깐은 일이 끝난 것처럼 보입니다. 그런데 새로고침을 하면 권한 오류가 뜨거나, 원하지 않은 경로에 페이지가 생기거나, 이미 있는 코드를 다시 설명하느라 같은 질문을 반복하게 됩니다. 공식 Cursor 채널의 Cursor Agent: 10 Pro Tips!(약 12분 32초)는 그 앞에서 순서를 바꾸라고 말합니다. Agent 입력에서 Shift+Tab으로 Plan Mode를 켠 뒤, 코드베이스를 읽고 확인 질문을 받고 Markdown 계획과 할 일 목록을 만든 다음에야 Build로 구현을 시작합니다.

Cursor Plan Mode 훅 이미지
설명용 생성 이미지입니다.

왜 Plan Mode가 먼저인가

영상 첫 팁이 Plan Mode입니다. 발표자는 개인 사이트에 Spotify 상위 아티스트 페이지를 추가하는 작업을 예로 듭니다. 홈에는 이미 “최근에 들은 곡”이 붙어 있고, Spotify 연동 코드가 있습니다. Plan Mode에 들어가면 에이전트는 그 구현을 먼저 읽고, 경로 이름·상위 몇 명·기간 버킷·표시 방식 같은 선택을 묻습니다. 답을 받은 뒤에는 새 Markdown 계획 파일을 만들고, 건드릴 컴포넌트와 파일 이름을 직접 적으며 할 일 목록까지 붙입니다. 발표자는 “음악 취향 소개 문단은 필요 없다”고 계획을 고친 뒤 저장하고 Build를 눌렀습니다.

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 베타(왼쪽 에이전트 목록·가운데 대화·오른쪽 diff, 브라우저·터미널 연동)가 짧게 소개됩니다. 오늘 글의 핵심 행동은 보너스가 아니라 첫 팁입니다. Plan Mode로 범위를 합의한 뒤 Build하고, 다음 기능은 새 채팅에서 다시 시작하는 것입니다.

오늘 바로 할 일

  1. Cursor에서 Agent 입력을 연 뒤 Shift+Tab으로 Plan Mode를 켭니다.
  2. 오늘 넣을 기능 하나만 적습니다. 예: 제출 로그 표, 결과 카드 한 장, 평가 스크립트 연결, README의 실행 명령 정리.
  3. 질문이 나오면 경로·개수·기간·표시 범위만 짧게 답하고, 계획이 만들어지면 파일 목록과 할 일만 읽습니다.
  4. 필요 없는 문단·과한 범위는 계획에서 지운 뒤 Build를 누릅니다.
  5. 오류가 나면 추측 설명을 길게 쓰지 말고, 터미널·브라우저에 보이는 메시지를 그대로 붙여 한 번 더 고칩니다.
  6. 다음 기능으로 넘어가기 전에 새 채팅을 열고, 큰 변경은 Git 브랜치를 먼저 만듭니다. 결과가 어색하면 체크포인트로 되돌린 뒤 계획을 다시 받습니다.

Plan Mode는 더 화려한 한 방이 아닙니다. 에이전트가 만질 파일과 오늘 끝낼 범위를 먼저 합의하는 절차입니다. 해커톤·대회 저장소처럼 사람이 여러 명이고 제출 시간이 정해진 곳일수록, “바로 코딩”보다 “계획 한 장 → Build → 새 채팅” 순서가 안전합니다. 오늘은 Shift+Tab 한 번으로 그 순서를 시작하십시오.

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

DAKER·DACON 대회 코드는 보통 제출 스크립트, 전처리, 모델, 결과 폴더가 한 저장소에 섞여 있습니다. 이런 구조에서 에이전트에게 “점수 올려 주십시오”라고만 하면, 학습 코드와 제출 포맷을 한꺼번에 건드리다가 재현이 깨지기 쉽습니다. Plan Mode에 넣을 문장은 짧게 유지하십시오. 예: “제출 폴더의 CSV 컬럼 순서를 대회 안내와 같게 맞추고, 검증용 스크립트 하나만 추가합니다. 학습 하이퍼파라미터는 바꾸지 않습니다.”처럼 오늘 끝낼 범위와 건드리지 않을 범위를 같이 적으면, 계획이 그 경계를 따라갑니다.

계획이 나온 뒤에는 파일 경로만 먼저 확인합니다. 발표자가 인트로 문단을 지운 것처럼, 대회 맥락에 필요 없는 “새 대시보드 전체 재작성” 같은 항목이 있으면 계획에서 삭제합니다. Build 후에는 로컬에서 한 번 실행해 보고, 오류 전문을 그대로 붙여 고칩니다. 권한이 필요한 API·데이터 파일이면, 영상처럼 토큰·경로 문제를 별도 턴으로 처리하는 편이 안전합니다. 점수 실험은 다음 채팅으로 넘기십시오. 한 채팅에 포맷 수정과 모델 튜닝을 같이 넣으면 컨텍스트가 섞입니다.

팀으로 작업할 때는 커스텀 명령이 특히 도움이 됩니다. .cursor/commands/submit-check.md에 “필수 컬럼 목록, 파일명 규칙, git status에 학습 가중치가 섞이지 않았는지”를 적어 두면, 사람마다 다른 체크리스트를 말로 반복하지 않아도 됩니다. PR 명령처럼 GitHub CLI를 쓰라는 문장을 넣으면, 리뷰어가 보는 제목·본문 형식도 맞춰집니다. @Branch로 브랜치 리뷰를 한 번 돌린 뒤, 사람이 diff를 확인하는 순서를 팀 규칙으로 고정해 두십시오.

오늘 하지 말아야 할 것

한 채팅에서 기능 세 개를 연달아 부탁하지 마십시오. 영상에서 반복해서 나오는 경고입니다. 컨텍스트가 커지면 앞 지시가 희미해지고, 이미 끝낸 파일을 다시 고치거나 다른 기능의 이름을 가져오기 쉽습니다. “일단 되게만” 하고 UI·로깅·문서까지 한 대화에 몰아넣는 습관도 같은 문제에 닿습니다. Plan Mode를 켜 놓고도 계획을 읽지 않은 채 Build만 누르는 것도 피하십시오. 계획 파일은 합의 기록입니다. 경로와 할 일만 30초 읽어 보는 것이, 나중에 한 시간 되돌리는 것보다 낫습니다.

체크포인트만 믿고 Git을 안 쓰는 것도 위험합니다. 체크포인트는 그 대화 안의 실험용 되돌리기이고, 팀원이나 다른 기기에서는 보이지 않을 수 있습니다. 큰 UI 변경·데이터 스키마 변경 전에는 브랜치를 만들고, 동작이 확인된 뒤에만 합치십시오. 사용량 게이지를 끄고 쓰면 한도 직전에야 문제를 알게 됩니다. Settings에서 usage summary를 Always로 두면, 지금 이 채팅을 더 끌지 새로 열지를 숫자로 판단할 수 있습니다.

정리

Cursor 공식 영상이 나열한 열 가지 팁의 공통점은 “에이전트를 더 많이 돌린다”가 아니라 “에이전트가 보는 범위와 기록을 사람이 고른다”입니다. Plan Mode로 오늘 범위를 합의하고, @와 커스텀 명령으로 반복 작업을 고정하고, 새 채팅·체크포인트·Git으로 실패를 싸게 만듭니다. 오늘은 Shift+Tab 한 번, 기능 하나, Build 한 번이면 충분합니다. 그다음 기능은 새 대화에서 다시 시작하십시오.

출처