Cursor Composer 1.5 업데이트 노트를 보다가 멈췄습니다.
Memories? Rules 강화? 사실 저는 이미 비슷한 걸 수동으로 만들어 쓰고 있거든요. .claude/MEMORY라는 폴더에 hot/warm/cold 3단계로 메모리를 관리하고, AI가 매 세션 시작할 때 참조하게 해놓은 시스템입니다. Cursor가 이걸 자동화해주겠다니까 궁금해졌어요. 과연 얼마나 편해지는 건지. 공식 문서를 파봤습니다.
Cursor의 Memories는 AI가 사용자의 코딩 선호를 학습해 다음 세션에 반영하는 기능이고, Rules는 프로젝트·사용자·팀 단위로 AI 행동 규칙을
.cursor/rules디렉토리에 Markdown 파일로 저장하는 기능입니다. (Cursor Rules 공식 문서)
오늘은 이 두 기능을 공식 문서 기준으로 정리하면서, 제가 쓰고 있는 수동 시스템과도 비교해보겠습니다. 같이 설정해봅시다.
Composer 1.5, 그리고 Cursor의 메모리 인프라
Composer 1.5는 Cursor가 새로 내놓은 에이전트 코딩 모델입니다. 기존 모델 대비 20배 많은 강화학습(RL)으로 훈련되었고, 핵심은 두 가지예요.
- Enhanced Reasoning — 작업 난이도에 맞춰 사고 깊이를 조절하는 “thinking tokens” 시스템
- Advanced Self-Summarization — 컨텍스트가 길어져도 스스로 요약하며 해결책을 탐색
이 모델 업데이트와 함께, Cursor IDE 자체에도 “AI가 나를 기억하게 만드는 인프라”가 강화되었습니다.
기존 문제가 뭐였냐면요. 매번 새 채팅을 열 때마다 처음부터 다시 설명해야 했습니다. “이 프로젝트는 Next.js 14고, App Router 쓰고, CSS는 Tailwind이고…” 이걸 하루에 서너 번 반복하면, 그것만으로도 시간이 꽤 깎입니다.
Cursor 공식 Changelog에 따르면, 최근 업데이트에서 추가·강화된 주요 기능은 이렇습니다.
| 기능 | 설명 | 기대 효과 |
|---|---|---|
| Composer 1.5 | 20x RL 강화 에이전트 모델 | 복잡한 멀티스텝 코딩 성능 향상 |
| Memories | AI가 대화 중 사용자 선호를 자동 학습·저장 | 반복 지시 제거 |
| Rules (강화) | Always/Auto/Manual 3종 적용 모드 | 프로젝트별 맞춤 AI |
| Custom Commands | / 슬래시로 재사용 프롬프트 실행 | 워크플로우 자동화 |
| Self-Summarization | 컨텍스트 한계 시 자동 요약·탐색 지속 | 긴 작업도 끊김 없이 |
| MCP Resources | 외부 도구·API 연결 공식 지원 | 확장성 확대 |
이 중에서 일상 코딩에 가장 직접적으로 영향을 주는 건 Memories와 Rules 두 가지입니다. Composer 1.5의 모델 성능 향상은 체감하기 어려울 수 있지만, 이 두 가지는 “설정하면 당장 반복작업이 줄어드는” 기능이거든요.
Memories가 뭔지, 왜 필요한지
AI 코딩 도구의 고질적인 문제가 있습니다. “건망증”이에요.
어제 “세미콜론 빼” 라고 했는데, 오늘 새 채팅 열면 또 세미콜론을 붙여놓습니다. “date-fns 써” 했는데 다음 날 moment.js를 추천합니다. 한 번 말할 때마다 30초라고 치면, 하루에 수십 번 반복하면 수십 분이 쌓입니다.
Memories는 이 문제를 해결하기 위한 기능입니다.
Memories란? Cursor 공식 문서에 따르면, Memories 기능은 AI가 사용자와의 대화에서 코딩 선호, 프로젝트 패턴, 자주 쓰는 라이브러리 등을 자동으로 식별해 저장하는 시스템입니다. 다음 세션에서 이 정보가 자동 반영되어, 매번 같은 지시를 반복할 필요가 없어집니다.
Memories의 핵심 원리
공식 문서 기준으로, Memories는 두 가지 방식으로 작동합니다.
1. 자동 생성 (Generate Memories)
Settings > Rules에서 “Generate Memories” 옵션을 켜면, Cursor가 대화 중에 중요하다고 판단한 정보를 자동으로 메모리에 저장합니다. 예를 들어 여러 번 “함수는 arrow function으로 써줘”라고 말하면, AI가 이 패턴을 기억해서 이후에는 알아서 arrow function을 쓰게 됩니다.
2. 수동 지시
“이거 기억해: 이 프로젝트에서는 styled-components 대신 Tailwind CSS를 쓴다”처럼 직접 말하면, AI가 해당 정보를 Memories에 추가합니다. 중요한 선호는 이렇게 직접 말해주는 게 확실합니다.
Memories가 해결해주는 반복 지시 목록
구체적으로 어떤 반복이 줄어드는지 정리해보면 이렇습니다.
| 반복 지시 유형 | 예시 | Memories 설정 후 |
|---|---|---|
| 코딩 스타일 | “세미콜론 빼, 작은따옴표 써” | 자동 적용 |
| 프레임워크 설명 | “이 프로젝트는 Next.js App Router야” | 자동 인지 |
| 라이브러리 선호 | “date-fns 쓰고, moment.js 쓰지 마” | 자동 적용 |
| 파일 구조 안내 | “컴포넌트는 src/components/에 넣어” | 자동 인지 |
| 응답 언어 | “한국어로 설명해줘” | 자동 적용 |
이 지시들, 하루에 몇 번이나 반복하고 계세요? Memories를 설정하면 이론적으로 전부 자동화됩니다.
잠깐 — 나는 이미 수동으로 이걸 하고 있었다
사실 이 문제를 Cursor보다 먼저 해결하려고 했던 사람들이 있습니다. 저도 그중 하나예요.
AI 코딩 도구의 “건망증” 문제가 너무 답답해서, .claude/MEMORY라는 디렉토리에 직접 메모리 시스템을 만들어 쓰고 있었거든요. 구조는 이렇습니다.
MEMORY/
├── hot/ # 🔴 즉시 참조 (오늘 필요한 것)
│ ├── today.md # 오늘의 상태, 진행 중 작업
│ └── session-log.md # 최근 세션 로그
├── warm/ # 🟡 최근 학습 (1-4주 이내)
│ ├── recent-patterns.md # 블로그 도입부 패턴 추적
│ └── skill-feedback.md # 스킬 실행 결과 피드백
└── cold/ # 🔵 장기 참조 (변하지 않는 것)
├── annual-review.md # 연간 회고
└── system-changelog.md # 시스템 변경 이력
hot은 수명 1~3일짜리 정보, warm은 1~4주, cold는 영구 보존. AI가 세션 시작할 때 hot을 먼저 스캔하고, 관련 작업이면 warm을 참조하는 식입니다.
이걸 Cursor의 Memories와 비교하면 어떨까요?
| 비교 항목 | 수동 시스템 (.claude/MEMORY) | Cursor Memories |
|---|---|---|
| 진입장벽 | 높음 (직접 설계·관리) | 낮음 (토글 하나) |
| 구조화 | 자유로움 (hot/warm/cold 분리) | AI가 알아서 판단 |
| 중요도 분류 | 가능 (tier별 수명 관리) | 불가능 (전부 동일) |
| 정확도 | 높음 (직접 작성) | AI 판단 의존 |
| 유지 비용 | 높음 (주기적 정리 필요) | 낮음 (자동) |
| 팀 공유 | 가능 (Git) | 불가능 |
솔직히 말하면, 수동 시스템이 더 정교합니다. “이 정보는 3일만 유효해”, “이건 한 달짜리야” 같은 판단을 AI가 혼자 하기는 어렵거든요.
그런데. 이걸 직접 만들어서 관리할 사람이 얼마나 될까요?
대부분의 개발자는 Settings에서 토글 하나 켜는 것도 귀찮아합니다. 그래서 Cursor Memories의 가치는 **”아무것도 안 해도 어느 정도는 기억해준다”**는 데 있습니다. 완벽하진 않지만, 안 쓰는 것보다는 확실히 낫죠.
제 결론은 이렇습니다.
- 시간 투자할 의향이 있다면 → 수동 메모리 시스템 + Rules 조합이 최강
- 빠르게 효과를 보고 싶다면 → Cursor Memories ON + Rules 기본 설정
- 회사 코드라 Privacy Mode 켜야 한다면 → Rules만으로 커버
Memories 설정법 — 5분이면 충분합니다
같이 설정해봅시다. 어렵지 않습니다.
STEP 1: Privacy Mode 확인
Memories가 작동하려면 Privacy Mode가 꺼져 있어야 합니다.
Cursor 설정 → General → Privacy Mode → OFF
Privacy Mode가 켜져 있으면 대화 내용이 서버에 저장되지 않기 때문에, AI가 학습할 데이터 자체가 없습니다. 개인 프로젝트에서는 끄는 게 좋고, 회사 코드를 다루는 경우에는 팀/보안 정책을 확인하세요.
STEP 2: Generate Memories 활성화
Cursor 설정 → Rules → Generate Memories → ON
이걸 켜면 AI가 대화 중 “이 사용자는 이런 패턴을 선호하는구나”를 자동으로 캐치해서 저장합니다.
STEP 3: 핵심 선호를 직접 기억시키기
자동 학습을 기다리는 것보다, 처음에 핵심 사항을 직접 말해주는 게 빠릅니다. 채팅에서 이렇게 입력해보세요.
"Remember this: - 이 프로젝트에서는 TypeScript strict mode를 사용합니다 - 컴포넌트는 함수형으로만 작성합니다 - CSS는 Tailwind CSS를 사용합니다 - import 순서: React → 외부 라이브러리 → 내부 모듈 → 스타일"
이렇게 한 번 말해두면, 다음 세션부터 반영됩니다.
STEP 4: 저장된 Memories 확인·관리
Cursor 설정 → Rules → Memories 섹션
여기서 저장된 기억을 확인하고, 잘못된 기억은 삭제할 수 있습니다. AI가 의도와 다르게 학습할 수 있으니 주기적으로 확인하는 게 좋겠습니다. 예를 들어 테스트 코드에서 var를 한 번 썼는데 “이 사용자는 var를 선호한다”고 기억해버릴 수도 있거든요.
주의: Memories가 작동하지 않는 경우
가장 흔한 원인은 Privacy Mode가 켜져 있는 것입니다. 그 외에, 공식 문서에 따르면 너무 짧은 대화에서는 AI가 패턴을 잡기 어려우니, 자동 학습을 원하면 어느 정도 대화량이 필요합니다.
Rules가 뭔지, Memories와 뭐가 다른지
여기서 헷갈리는 분들이 많을 겁니다.
“Memories도 기억하는 건데, Rules도 기억하는 거 아니야?” 맞는 말이지만, 성격이 다릅니다.
| 구분 | Memories | Rules |
|---|---|---|
| 성격 | AI가 스스로 학습한 것 | 개발자가 명시적으로 지시한 것 |
| 저장 방식 | AI 내부 저장소 | .cursor/rules 디렉토리 (Markdown 파일) |
| 범위 | 사용자 전체 | 프로젝트/사용자/팀별 분리 |
| 버전 관리 | 불가능 | Git으로 관리 가능 |
| 팀 공유 | 불가능 | 가능 (Project Rules) |
| 신뢰도 | AI 판단 의존 | 명시적, 100% 적용 |
핵심 차이를 한 줄로 요약하면 이겁니다. Memories는 AI의 추론이고, Rules는 개발자의 명령입니다.
Memories는 “이 사람은 세미콜론을 안 좋아하는 것 같네”라고 AI가 추론한 것. Rules는 “세미콜론 절대 쓰지 마”라고 개발자가 파일로 남긴 것. Rules가 더 강력하고, 충돌 시에도 Rules가 우선합니다.
Rules 설정법 — 프로젝트에 맞는 AI 만들기
Rules는 Cursor에서 가장 강력한 커스터마이징 기능입니다. 공식 문서(Cursor Rules)를 기반으로 설정 방법을 정리했습니다.
Rules의 3가지 적용 모드
| 모드 | 동작 | 사용 예시 |
|---|---|---|
| Always | 모든 요청에 항상 적용 | 코딩 스타일, 언어 설정 |
| Auto | AI가 관련성을 판단해서 적용 | 프레임워크별 패턴 |
| Manual | @rulename으로 명시적 호출 | 특수 워크플로우 |
Rules의 3가지 범위
| 범위 | 위치 | 용도 |
|---|---|---|
| Project Rules | .cursor/rules/ (프로젝트 내) | 프로젝트별 규칙, Git 관리 가능 |
| User Rules | Cursor 설정 > Rules | 개인 전역 규칙, 모든 프로젝트 적용 |
| Team Rules | 팀 대시보드 | 팀 전체 표준, Team/Enterprise 플랜 |
왜 이렇게 나눠놨을까요?
Project Rules는 “이 프로젝트에서만 적용”되는 규칙입니다. Next.js 프로젝트의 Rules와 Python FastAPI 프로젝트의 Rules가 다를 수밖에 없잖아요. .cursor/rules/에 넣어두면 Git으로 팀원과 공유할 수 있다는 게 핵심입니다.
User Rules는 모든 프로젝트에 공통 적용됩니다. “코드 설명은 한국어로 해줘” 같은 건 프로젝트와 무관하니까요.
Team Rules는 팀 단위 강제 규칙입니다. “시크릿 키는 코드에 직접 넣지 마” 같은 보안 규칙을 팀 전체에 적용할 때 씁니다. Team/Enterprise 플랜에서만 가능합니다.
STEP 1: Project Rules 만들기
프로젝트 루트에 .cursor/rules/ 디렉토리를 만들고, .mdc 파일로 규칙을 작성합니다.
mkdir -p .cursor/rules
예시: .cursor/rules/coding-style.mdc
---
description: 프로젝트 코딩 스타일 가이드
globs: "**/*.{ts,tsx}"
alwaysApply: true
---
# 코딩 스타일 규칙
## TypeScript
- strict mode 사용
- 세미콜론 사용하지 않음
- 작은따옴표(') 사용
- 인터페이스 이름은 I 접두사 없이 작성 (예: User, not IUser)
## React 컴포넌트
- 함수형 컴포넌트만 사용 (class 금지)
- Props 타입은 컴포넌트 바로 위에 정의
- useState 대신 useReducer 권장 (복잡한 상태)
- 이벤트 핸들러 네이밍: handle + 동사 (handleClick, handleSubmit)
## 파일 구조
- 컴포넌트: src/components/[ComponentName]/index.tsx
- 훅: src/hooks/use[HookName].ts
- 유틸: src/utils/[utilName].ts
- 타입: src/types/[typeName].ts
## Import 순서
1. React 관련
2. 외부 라이브러리 (next, zustand 등)
3. 내부 컴포넌트
4. 내부 유틸/훅
5. 스타일/타입
이 파일 하나만 있으면, AI가 이 프로젝트의 코딩 스타일을 알아서 따릅니다.
STEP 2: globs로 파일 범위 지정
Rules의 강력한 기능 중 하나가 globs입니다. 특정 파일 패턴에만 규칙을 적용할 수 있어요.
---
description: API 라우트 작성 규칙
globs: "src/app/api/**/*.ts"
alwaysApply: true
---
# API Route 규칙
- 모든 API는 try-catch로 감싸기
- 에러 응답은 NextResponse.json({ error: message }, { status: code }) 형식
- 인증이 필요한 API는 미들웨어 확인 주석 추가
- 요청 body 검증은 zod 사용
이렇게 하면 src/app/api/ 폴더의 TypeScript 파일을 수정할 때만 이 규칙이 적용됩니다. 컴포넌트 코드를 작성할 때는 적용되지 않으니, 컨텍스트 낭비도 없습니다.
STEP 3: User Rules 설정
Cursor 설정 > Rules에서 모든 프로젝트에 적용할 전역 규칙을 설정합니다.
# User Rules ## 언어 - 코드 주석과 설명은 한국어로 작성 - 변수명/함수명은 영어 camelCase ## 응답 스타일 - 코드 변경 시 변경 이유를 한 줄로 설명 - 긴 함수는 작은 함수로 분리 제안 - 에러 가능성이 있는 코드에는 주의사항 코멘트 ## 절대 하지 말 것 - console.log를 프로덕션 코드에 남기지 말 것 - any 타입 사용하지 말 것 - 인라인 스타일 사용하지 말 것
추천 Rules 디렉토리 구조
공식 문서와 커뮤니티 사례를 참고해서, 실전에서 쓸 만한 구조를 정리하면 이렇습니다.
.cursor/
└── rules/
├── coding-style.mdc # 코딩 스타일 (Always)
├── api-routes.mdc # API 라우트 규칙 (globs: api/**)
├── components.mdc # 컴포넌트 패턴 (globs: components/**)
├── database.mdc # DB 쿼리 규칙 (globs: db/**)
├── testing.mdc # 테스트 코드 규칙 (globs: **/*.test.*)
└── git-commit.mdc # 커밋 메시지 규칙 (Manual)
Always 모드는 3~5개 이내로 유지하는 게 좋겠습니다. 전부 Always로 설정하면 모든 요청마다 모든 규칙이 컨텍스트에 들어가서, 토큰 소비가 늘고 응답 속도도 느려질 수 있습니다.
Memories + Rules 조합 전략
두 기능을 같이 쓸 때 역할 분담을 어떻게 하면 좋을까요? 공식 문서의 설계 의도를 생각하면 이렇게 나눌 수 있습니다.
| 역할 | 담당 기능 | 예시 |
|---|---|---|
| 강제 규칙 | Rules (Always) | 코딩 스타일, 금지 패턴 |
| 프로젝트 컨텍스트 | Rules (Auto) | 프레임워크/라이브러리 규칙 |
| 개인 선호 | Memories | “나는 설명을 짧게 받는 걸 좋아해” |
| 특수 작업 | Rules (Manual) | 커밋 메시지 생성, PR 설명 작성 |
원칙은 간단합니다. 확실하게 강제해야 하는 건 Rules, 자연스럽게 학습시킬 건 Memories에 맡기면 됩니다.
새 프로젝트 시작할 때 추천 순서
- 프로젝트 초기화 (npm create, etc.)
.cursor/rules/디렉토리 생성 (mkdir -p .cursor/rules)- 코딩 스타일 Rule 작성 (5분)
- 프레임워크별 Rule 작성 (10분)
- 첫 대화에서 Memories 시드 — “Remember: 이 프로젝트는 …”
- Git commit (
.cursor/rules/포함)
초기 설정에 15~20분 정도 소요됩니다. 이걸 한 번 해두면 이후 매 세션마다 반복 지시를 안 해도 된다는 게 핵심이에요.
Custom Commands — 반복 워크플로우를 슬래시 하나로
Cursor에서 추가된 Custom Commands도 반복작업 줄이기에 유용합니다.
.cursor/commands/ 디렉토리에 Markdown 파일로 만드는 재사용 프롬프트입니다. 채팅에서 /명령어이름으로 실행합니다.
실전 활용 예시 3개
1. /lint-fix — 린터 에러 자동 수정
.cursor/commands/lint-fix.md:
--- description: ESLint 에러를 자동으로 수정합니다 --- 현재 파일의 ESLint 에러를 확인하고 수정해주세요. - `npx eslint --fix` 실행 후 남은 에러가 있으면 수동으로 수정 - 수정 이유를 각 변경 옆에 한 줄 코멘트로 설명 - any 타입으로 우회하지 말 것
2. /pr-desc — PR 설명 자동 생성
.cursor/commands/pr-desc.md:
--- description: Git diff를 기반으로 PR 설명을 생성합니다 --- 현재 Git diff를 분석해서 PR 설명을 작성해주세요. 형식: ## 변경 사항 - (주요 변경 요약) ## 영향 범위 - (영향 받는 파일/기능) ## 테스트 - (테스트 방법)
3. /component — 새 컴포넌트 스캐폴딩
.cursor/commands/component.md:
--- description: 새 React 컴포넌트를 프로젝트 패턴에 맞게 생성합니다 --- 새 컴포넌트를 만들어주세요. 반드시 다음 패턴을 따릅니다: - src/components/[ComponentName]/index.tsx - Props 타입은 export - forwardRef 사용 - displayName 설정 - 기본 스토리북 파일 함께 생성
Custom Commands + Rules를 함께 쓰면, /pr-desc 한 번에 프로젝트 규칙에 맞는 PR 설명이 자동 생성됩니다. 매번 포맷을 설명할 필요가 없어지는 거죠.
주의할 점 — 설정 전에 알아두세요
Memories와 Rules를 쓸 때 공식 문서와 커뮤니티에서 자주 언급되는 주의사항입니다.
1. Privacy Mode와 Memories의 관계
Privacy Mode가 ON이면 Memories는 작동하지 않습니다. 회사 프로젝트에서 Privacy Mode를 켜야 하는 경우, Rules만으로 커버해야 합니다. 이때는 Rules를 더 상세하게 작성해서 Memories 역할까지 대신하면 됩니다.
2. Always Rules는 적게 유지
Always 모드 규칙이 너무 많으면, 모든 요청에 전부 컨텍스트로 들어가기 때문에 토큰 소비가 증가합니다. 공통적으로 필요한 핵심 규칙만 Always로 설정하고, 나머지는 Auto(globs 기반)나 Manual로 분리하는 게 효율적입니다.
3. Memories의 잘못된 학습
AI가 대화 패턴을 잘못 해석할 수 있습니다. 테스트 코드에서 일시적으로 사용한 패턴을 “선호”로 기억할 수 있기 때문에, 주기적으로 Settings > Rules > Memories에서 저장된 내용을 점검하는 게 좋습니다.
4. 기존 .cursorrules 마이그레이션
이전에 .cursorrules 파일을 쓰고 있었다면, .cursor/rules/ 디렉토리 방식으로 전환이 권장됩니다. 기존 파일도 여전히 작동하지만, globs와 Always/Auto/Manual 모드 같은 새 기능을 활용하려면 마이그레이션하는 편이 낫습니다.
내가 느낀 점
수동 메모리 시스템을 직접 만들어 쓰면서 느낀 건, “AI 도구에 메모리가 없다는 게 비정상이었다”입니다.
생각해보면 .eslintrc나 .prettierrc는 이미 프로젝트 설정 파일로 당연하게 쓰고 있잖아요. AI 코딩 도구에도 똑같은 개념이 필요한 건 당연한 건데, 이제서야 .cursor/rules/로 그게 가능해진 겁니다. Git으로 버전 관리까지 된다니까, 팀 프로젝트에서도 AI 행동 규칙을 통일할 수 있어요.
다만 Cursor Memories가 제 수동 시스템을 완전히 대체할 수 있을지는 아직 모르겠습니다. hot/warm/cold처럼 정보의 수명을 관리하는 건 자동 시스템으로는 한계가 있거든요. 그래서 저는 당분간 Memories + 수동 시스템을 병행하면서 어느 쪽이 더 효율적인지 비교해볼 생각입니다.
솔직한 마음
걱정이 두 가지 있습니다.
첫 번째는 사람들이 과연 이걸 쓸까입니다. 솔직히 저처럼 수동으로 메모리 시스템까지 만들어 쓰는 사람은 극소수예요. 대부분은 Rules 파일 하나 만들기도 귀찮아하거든요. Cursor가 Memories를 “토글 하나로” 만든 이유가 이것 때문이겠지만, 그래도 제대로 활용하려면 Rules까지 설정해야 하니까 진입장벽이 여전히 있습니다.
두 번째는 Privacy 문제입니다. Memories가 Privacy Mode OFF에서만 작동한다는 건, 코딩 데이터가 서버에 저장된다는 뜻이에요. 개인 프로젝트는 괜찮지만, 회사 코드에서는 보안 정책과 충돌할 수 있습니다. 그래서 저는 회사 코드에서는 Rules만 쓰고, 개인 프로젝트에서만 Memories를 켜는 식으로 분리할 생각입니다.
결국 Rules를 제대로 쓰는 게 가장 현실적인 시작점이라고 봅니다. Memories는 있으면 좋은 보너스고, Rules가 진짜 근본입니다.
앞으로 할 것들
- 실전 사용 후기 업데이트 — 2~3주 써보고 실제 시간 절약 효과를 측정해서 이 글에 추가할 예정입니다
- 팀 Rules 템플릿 공개 —
.cursor/rules/구조를 GitHub에 올릴 계획입니다 - Memories 정리 루틴 수립 — 주 1회 잘못 학습된 Memories 점검 습관 만들기
- Custom Commands 확장 — 자주 쓰는 워크플로우를 Custom Commands로 만들어보기
특히 1번이 중요합니다. 실제로 써보기 전에 “30분 줄어든다”고 단언할 순 없으니까요. 실사용 데이터가 나오면 업데이트하겠습니다.
❓ 자주 묻는 질문
Q1. Cursor 무료 플랜에서도 Memories와 Rules를 쓸 수 있나요?
Rules는 무료 플랜에서도 Project Rules와 User Rules를 모두 사용 가능합니다. Team Rules만 Team/Enterprise 플랜에서 제공됩니다. Memories도 무료 플랜에서 사용 가능하지만, Privacy Mode 설정에 따라 제한될 수 있습니다.
Q2. Rules 파일 형식이 .md인가요, .mdc인가요?
Cursor는 .mdc (Markdown with Config) 형식을 사용합니다. 일반 .md와 거의 같지만, YAML frontmatter에 globs, alwaysApply, description 같은 Cursor 전용 설정을 포함합니다. .mdc 확장자 사용이 권장됩니다.
Q3. Memories가 잘못 학습한 것을 초기화할 수 있나요?
Settings > Rules > Memories에서 개별 삭제가 가능합니다. 전체 초기화는 Generate Memories를 끄고, 기존 Memories를 모두 삭제한 후, 다시 켜면 됩니다.
Q4. Always와 Auto의 차이가 뭔가요?
Always는 모든 요청에 무조건 적용됩니다. Auto는 AI가 관련성을 판단해서 적용합니다. Auto로 설정하면 불필요한 컨텍스트가 줄어서 토큰을 아낄 수 있습니다. “한국어로 응답” 같은 건 Always, “React 컴포넌트 규칙” 같은 건 Auto가 적절합니다.
Q5. 기존 .cursorrules 파일은 어떻게 되나요?
기존 .cursorrules 파일도 여전히 작동합니다. 하지만 globs, Always/Auto/Manual 모드 등 새 기능을 쓰려면 .cursor/rules/ 디렉토리 방식으로 전환하는 것이 권장됩니다.
Q6. Memories와 Rules가 충돌하면 어떻게 되나요?
Rules가 우선합니다. Rules는 명시적 지시이기 때문에, AI가 학습한 Memories보다 항상 우선 적용됩니다.
Q7. Team Rules는 어떻게 설정하나요?
Team Rules는 Cursor 팀 대시보드(dashboard.cursor.com)에서 관리합니다. 팀 관리자가 규칙을 작성하면, 팀 멤버의 Cursor에 자동 적용됩니다. Team 또는 Enterprise 플랜이 필요합니다.
결론
Cursor의 Memories와 Rules는 “AI 코딩 도구”를 “내 프로젝트를 이해하는 파트너”로 바꿔주는 설정입니다.
설정에 15~20분 투자하면, 이후 매 세션마다 반복 지시를 줄일 수 있습니다. 정리하면 이렇습니다.
- Privacy Mode 확인 + Generate Memories 켜기 (2분)
.cursor/rules/에 코딩 스타일 Rule 작성 (10분)- 프레임워크별 Rule 추가 (5분)
- Custom Commands 2~3개 만들기 (5분)
이게 전부입니다. 실사용 후기는 2~3주 뒤에 이 글에 업데이트하겠습니다.
📚 참고 자료
- Cursor 공식 Changelog — Cursor 업데이트 전체 내용
- Cursor Rules 공식 문서 — Rules 종류별 설정 가이드
- Cursor Forum — 커뮤니티 사용 사례 및 팁
🏷️ 태그: #Cursor #Memories #Rules #AI코딩 #AI코딩자동화 #개발자생산성 #Cursor설정