Cursor Agent Rules 가이드: 프롬프트 드리프트 없는 저장소 컨텍스트

InYourLeague 리서치 · 2026-08-20

Answer in brief

저장소 규칙, 안전한 편집, 범위가 지정된 컨텍스트, 반복 가능한 다중 파일 작업을 위한 Cursor Agent Rules 작성법입니다. 이 페이지는 cursor의 현재 모델·기능 기준, 실제 작업 절차, 실패 조건, 검증 방법을 함께 정리합니다.

Key facts at a glance

Verification checklist

• 공식 모델 카탈로그에서 모델명과 모델 ID를 다시 확인합니다.
• 입력·권한·출력 형식을 테스트 고정값으로 검증합니다.
• 모델 변경 시 날짜, 출처 URL, 회귀 테스트 결과를 기록합니다.
• 실패 응답과 불확실한 답변을 성공 결과로 취급하지 않습니다.

FAQ

cursor는 어떤 작업에 적합한가요?

Cursor Agent Rules 가이드: 프롬프트 드리프트 없는 저장소 컨텍스트는 cursor의 핵심 작업 흐름과 검증 기준을 설명합니다. cursor 사용자는 작업 목적과 현재 모델·기능 상태를 공식 출처에서 확인해야 합니다.

cursor의 현재 모델 또는 버전은 무엇인가요?

이 페이지가 확인한 대표 기준은 Grok 4.5입니다. 모델 ID와 제공 상태는 공식 문서의 최신 목록을 기준으로 다시 확인해야 하며, 지역·요금제·API 표면에 따라 달라질 수 있습니다.

cursor 사용 전에 어떤 설정을 확인해야 하나요?

cursor 계정, 권한, 입력 데이터, 모델 선택, 실패 시 재시도 정책을 먼저 확인해야 합니다. 민감한 키와 사용자 데이터는 작업 로그와 분리해야 합니다.

cursor 결과의 정확성은 어떻게 검증하나요?

cursor 출력은 원문 요구사항, 공식 문서, 테스트 결과와 대조해야 합니다. 인용·모델명·버전·날짜가 포함되면 해당 값의 출처 URL을 함께 확인해야 합니다.

cursor에서 자주 발생하는 실패는 무엇인가요?

cursor의 대표 실패는 오래된 모델명, 범위가 넓은 프롬프트, 누락된 권한, 검증 없는 자동 실행입니다. 입력 범위를 줄이고 명시적인 성공 조건과 중단 조건을 설정하세요.

Sources and freshness

• Official source
• Last verified: 2026-08-22

Cursor Agent Rules를 저장소 계약으로 쓰기

Rules는 저장소의 두 번째 핸드북이 아니라 작은 context contract여야 한다. 규칙이 적용되면 내용이 Agent context에 들어가므로 Always Apply 문장 하나하나가 현재 작업의 세부 정보와 공간을 경쟁한다. Agent가 반복해서 내려야 하는 결정만 남기고, 나머지는 canonical file과 command를 가리킨다. Cursor 공식 문서는 버전 관리하는 project rule을 .cursor/rules 아래 .mdc로 두도록 설명한다. 그 디렉터리의 일반 .md 파일은 rules system에서 무시된다. 더 단순한 Markdown 대안은 AGENTS.md이며, nested 파일로 디렉터리별 지침을 좁힐 수 있다. Cursor Rules 문서

작은 rules system setup

1. 저장소를 먼저 읽기. root README, contribution notes, build 또는 package file, formatter와 linter config, 대표 implementation 하나를 확인한다. 실제 test와 build command를 기록한다.
2. 지침마다 홈 하나를 정하기. 공통 저장소 동작은 .cursor/rules/*.mdc 또는 root AGENTS.md에 둔다. subtree 경계가 분명하면 nested AGENTS.md를 사용한다. 개인적인 응답 선호는 User Rules에 둔다.
3. 첫 rule은 하나의 목적만 갖게 한다. Cursor Rules UI 또는 /create-rule로 만들고, 생성된 file을 직접 확인한다. 이름을 구체적으로 짓고 stop condition을 적는다. rule 변경도 review할 수 있도록 commit한다.
4. 기술 이름보다 decision으로 나눈다. API boundary validation, migration, UI convention은 각각 별도 rule로 두어야 scope와 문제 원인을 추적하기 쉽다. “complete engineering standards” 같은 거대한 rule 하나로 합치지 않는다.

범위와 precedence

가장 좁게 적용되는 방식을 고른다.

• Always Apply: alwaysApply: true는 “generated output은 절대 수정하지 않는다”처럼 저장소 전체의 invariant에만 사용한다.
• Auto-attached: src/**/*.tsx나 db/migrations/**/*.sql처럼 path rule에는 globs를 사용한다.
• Agent Requested: path가 아니라 작업 종류에 따라 필요한 rule이면 globs 없이 강한 description을 작성한다.
• Manual: 자동 selector를 비워 두고 위험하거나 드문 절차를 @rule-name으로 직접 적용한다.

Cursor 문서는 충돌하는 경우 적용 가능한 Team → Project → User 순서를 설명한다. nested AGENTS.md 지침은 child directory로 갈수록 더 구체적으로 적용된다. Precedence가 모순을 대신 해결해 줄 것이라고 기대하지 않는다. 저장소 invariant는 project rule, local convention은 해당 code 가까이, 개인 선호는 User Rules에 둔다. Team Rule이 있다면 project의 예외와 근거를 문서에 명시한다.

짧고 검증 가능한 rule 쓰기

좋은 rule은 다섯 가지를 말한다. 언제 적용되는지, Agent가 어떤 decision을 내려야 하는지, 어떤 file을 만져도 되는지, 무엇을 바꾸면 안 되는지, 결과를 어떻게 verify하는지다. 붙여 넣은 style guide 대신 imperative bullet과 src/example.ts 같은 canonical reference를 사용한다. 실무 목표는 대략 10–40줄의 focused file이다. Cursor도 큰 rule을 나누고 500줄 아래로 유지하라고 안내하지만, 그 수치는 목표가 아니라 ceiling으로 취급한다. linter, test, CI, code review로 강제할 수 있는 내용은 prompt layer에만 맡기지 않는다.

드리프트를 막는 workflow

먼저 깨끗한 baseline을 만든다.

git status --short
git diff --name-only
git diff --check
npm run lint
npm test

실제 저장소 command로 바꿔 사용한다. 첫 Agent message에는 goal, allowed files, out-of-scope files, validation, stop condition을 명시한다. 수정 전에 짧은 plan과 repository inspection을 요청한다. 관련 context만 붙이고 한 번에 하나의 logical change를 요청한다. 요구가 바뀌면 낡은 대화에 corrective prompt를 계속 쌓지 말고 새 task로 분리하거나 scope를 다시 쓴다.

수정 뒤에는 diff를 먼저 확인한다. changed path, generated file, lockfile, formatting churn, renamed API, unrelated refactor가 있는지 본다. 그 다음 가장 좁은 relevant test, linter, type checker 또는 build를 실행한다. 일반 command가 통과했다고 변경된 동작까지 검증된 것은 아니다.

실패 원인과 verification

• Rule이 전혀 적용되지 않는다: project rule의 .mdc extension, metadata, 맞는 globs, 유용한 description을 확인한다. Customize의 Rules에서 상태를 보고 @rule-name으로 수동 진단한다.
• Rule이 모든 곳에서 적용된다: alwaysApply 또는 src/** 같은 broad glob이 너무 넓다. path를 줄이거나 선택 지침을 Agent Requested 또는 Manual로 옮긴다.
• Agent가 저장소 전체를 수정한다: prompt와 rule에 file boundary가 없다. allowlist를 적고 “do not reformat or upgrade dependencies”를 명시한 뒤 git diff --name-only로 확인한다.
• Rule과 code가 충돌한다: canonical source를 하나 정하고 중복 문장을 삭제한다. divergence를 드러내는 check를 추가한다.
• Prompt guidance를 security control로 믿는다: secret, permission, release gate는 prompt layer 밖의 repository와 CI control로 관리한다.

실무 checklist

• Always-on 문장이 정말 저장소 전체 invariant인가?
• 모든 rule에 하나의 목적과 분명한 scope가 있는가?
• allowed file과 validation command가 명시되어 있는가?
• 최종 diff가 요청한 boundary 안에 머물렀는가?
• 마지막 수정 후 relevant check가 통과했는가?

최신 근거 보충

아래 모델·기능 기록은 연결된 공식 출처에서 다시 확인한 값입니다. 제공 범위가 바뀌면 이 표와 검증 날짜를 함께 갱신하세요.

출처

• Official source
• Official source
• 마지막 검증: 2026-08-22