도입

Cursor를 팀 프로젝트에서 쓰다 보면 “AI에게 어떤 규칙을 항상 지키게 할지”, “테스트 파일에서만 적용할 규칙을 어떻게 나눌지”가 금방 복잡해집니다. `awesome-cursorrules`는 기존 단일 `.cursorrules` 방식에서 최신 `.cursor/rules/*.mdc` 기반 Cursor Rules 구조로 옮겨 가는 예시를 모아 둔 저장소입니다.

특히 테스트 자동화 프레임워크나 프론트엔드 프로젝트에서 Cursor 규칙을 어떻게 쪼개고 정리할지 참고하기 좋습니다.

왜 좋은가 / 왜 유명한가

- 기존 `.cursorrules` 한 파일에 모든 지시사항을 넣던 방식의 한계를 보여주고, 최신 Cursor Rules 구조로 바꾸는 방향을 예시 중심으로 설명합니다.

- MDC 형식, rule type, 중첩 규칙 구조처럼 최신 Cursor Rules에서 쓰는 개념을 실제 폴더 구조로 확인할 수 있습니다.

- Cypress, Selenium Python, Appium, k6, Playwright, RestAssured, Vitest 등 테스트 자동화 관련 규칙 예시가 포함되어 있어 실무 적용 사례를 보기 좋습니다.

- 단순한 규칙 문장 모음이 아니라, `rules`, `frameworks`, `example-structures`, `legacy-migration`처럼 용도별로 나누어 참고할 수 있게 구성되어 있습니다.

- Cursor의 레거시 `.cursorrules`에서 최신 `.cursor/rules` 방식으로 전환할 때 자주 참고되는 저장소로 알려져 있습니다.

무엇을 할 수 있나 / 무엇이 들어있나

원문 README 기준으로 저장소는 크게 네 영역으로 구성되어 있습니다.

awesome-cursorrules/
├── 📚 rules/                       # Legacy .cursorrules files (migration source)
│   ├── appium-mobile-test-automation-framework/
│   ├── cypress-javascript-test-automation-framework/
│   ├── k6-performance-test-framework/
│   ├── playwright-javascript-test-automation-framework/
│   ├── restassured-java-framework/
│   ├── selenium-net-test-automation-framework/
│   ├── selenium-python-test-automation-framework/
│   └── vitest-javascript-unit-test-framework/
├── 🏗️ frameworks/                  # Framework .cursor/rules examples (with nested rules)
│   ├── cypress/                    # .cursor/rules/{core,patterns}/*.mdc
│   └── selenium-python/            # .cursor/rules/patterns/*.mdc
├── 🎯 example-structures/          # Flat, focused .mdc structure examples
│   ├── cypress/                    # testing-fundamentals, api-testing
│   ├── next-js/                    # app-router-patterns
│   ├── react-typescript/           # component-development
│   └── selenium-python/            # architecture, page-objects, test-patterns
└── 📖 legacy-migration/            # Before/after migration guides

핵심은 “Cursor에게 줄 규칙을 한 파일에 몰아넣지 않고, 목적별로 나누는 방식”입니다.

기존 방식은 다음처럼 프로젝트 루트에 `.cursorrules` 하나를 두는 구조입니다.

# Old way - Everything in one file
project/
├── .cursorrules    # 200+ lines of mixed rules
├── src/
└── tests/

README에서는 이 방식의 문제로 유지보수 어려움, 파일 유형별 맥락 부족, 모든 규칙이 항상 활성화되는 점, 협업과 공유의 어려움, 템플릿·예시 통합의 한계를 들고 있습니다.

최신 방식은 다음처럼 `.cursor/rules/` 아래에 규칙을 나누어 두는 구조입니다.

# New way - Organized, contextual, powerful
project/
├── .cursor/rules/
│   ├── core-standards.mdc         # Always applied
│   ├── testing-patterns.mdc       # Auto-attached to test files
│   ├── framework-specific.mdc     # Context-aware activation
│   ├── advanced-optimizations.mdc # Agent-requested when relevant
│   └── templates/
│       ├── component-template.tsx
│       ├── test-template.spec.js
│       └── api-endpoint.js
├── src/
└── tests/

이 구조를 쓰면 README 기준으로 다음 장점이 있습니다.

- 상황에 맞는 규칙 활성화

- 정리되고 유지보수하기 쉬운 구조

- 템플릿 통합과 파일 참조

- 팀 협업과 버전 관리에 친화적인 구성

- 큰 프로젝트에서도 확장 가능한 구조

또한 최신 Cursor Rules에서는 다음과 같은 rule type을 다룹니다.

- Always Rules: 핵심 표준처럼 항상 적용되는 규칙

- Auto Rules: 특정 파일이나 상황에 자동으로 붙는 규칙

- Manual Rules: 필요할 때 직접 호출하는 규칙

- Agent Rules: 에이전트가 관련 상황에서 요청해 쓰는 규칙

설치와 사용법

원문 README에 별도의 설치 명령이나 패키지 매니저 명령은 제시되어 있지 않습니다. 따라서 `npm install`, `pip install`, 특정 CLI 명령처럼 문서에 없는 설치 명령은 사용하지 않는 것이 맞습니다.

사용 흐름은 저장소의 예시 구조를 보고, 본인 프로젝트의 `.cursor/rules/` 아래에 필요한 `.mdc` 규칙 구조를 맞추는 방식입니다. README에서 제시한 최신 Cursor Rules 구조는 아래와 같습니다.

project/
├── .cursor/rules/
│   ├── core-standards.mdc
│   ├── testing-patterns.mdc
│   ├── framework-specific.mdc
│   ├── advanced-optimizations.mdc
│   └── templates/
│       ├── component-template.tsx
│       ├── test-template.spec.js
│       └── api-endpoint.js
├── src/
└── tests/

처음 적용할 때는 너무 많은 규칙을 한 번에 옮기기보다, 아래 순서로 시작하는 편이 안전합니다.

1. 본인 프로젝트와 가까운 예시 폴더를 고릅니다.

예를 들어 Cypress 프로젝트라면 `frameworks/cypress` 또는 `example-structures/cypress`를 먼저 봅니다.

2. 기존에 `.cursorrules` 하나로 관리하던 내용이 있다면, 성격별로 나눕니다.

예시는 다음과 같은 방향입니다.

.cursor/rules/
├── core-standards.mdc
├── testing-patterns.mdc
└── framework-specific.mdc

3. 공통 규칙은 `core-standards.mdc`처럼 항상 적용될 파일로 분리합니다.

4. 테스트 코드에만 필요한 지침은 `testing-patterns.mdc`처럼 별도 파일로 분리합니다.

5. Cypress, Selenium Python, Next.js, React TypeScript처럼 프레임워크에 따라 달라지는 내용은 `framework-specific.mdc` 또는 저장소의 해당 예시 구조를 참고해 별도 규칙으로 둡니다.

예를 들어 테스트 자동화 팀이라면 다음처럼 활용할 수 있습니다.

project/
├── .cursor/rules/
│   ├── core-standards.mdc
│   ├── testing-patterns.mdc
│   └── framework-specific.mdc
├── src/
└── tests/

이때 `core-standards.mdc`에는 팀 전체 코딩 기준을, `testing-patterns.mdc`에는 테스트 작성 원칙을, `framework-specific.mdc`에는 Cypress나 Selenium Python처럼 도구별 패턴을 분리해 넣는 식으로 운영합니다.

레거시 `.cursorrules`를 쓰고 있다면 기존 구조는 아래와 같은 형태일 가능성이 큽니다.

project/
├── .cursorrules
├── src/
└── tests/

이 경우 모든 규칙을 한 파일에 계속 추가하기보다, 저장소의 `legacy-migration` 영역과 `frameworks`, `example-structures` 예시를 보면서 `.cursor/rules/` 구조로 나누어 이전하는 방향을 잡으면 됩니다.

주의할 점

- 이 저장소는 “설치해서 자동 적용되는 패키지”라기보다 Cursor Rules 구성을 참고하는 예시 모음에 가깝습니다. 문서에 별도 설치 명령이 없으므로, 프로젝트에 맞게 규칙 파일 구조를 직접 반영해야 합니다.

- 예시 규칙을 그대로 복사하기 전에 팀의 기술 스택, 테스트 전략, 코드 스타일과 맞는지 확인해야 합니다. 모든 규칙을 무조건 적용하면 오히려 Cursor의 응답이 프로젝트와 어긋날 수 있습니다.

- 레거시 `.cursorrules`와 최신 `.cursor/rules/*.mdc` 구조를 섞어 쓰는 경우 규칙 관리가 다시 복잡해질 수 있습니다. 전환 시에는 공통 규칙, 테스트 규칙, 프레임워크 규칙처럼 역할을 나누어 정리하는 것이 좋습니다.

출처와 다운로드

공식 저장소는 아래에서 확인할 수 있습니다.

https://github.com/tugkanboz/awesome-cursorrules

하단 첨부파일로도 받을 수 있습니다.