내 프로젝트에 딱 맞는 커서 룰 만들기

2025.05.31·AI, Cursor

서론

본격적으로 커서룰을 적용해야겠다는 생각에 어떻게 적용할지 여러 글을 접해봤습니다. 근데 커서룰의 장점에 대한 설명은 많았지만 직접 컨트롤하는 방법에 대한 글은 접하지 못했습니다.그나마 찾을 수 있던 것은 커서 룰 자동 생성기 였습니다. 하지만 결론적으로는 이것을 나만의 것으로 개선해야하는 과정이 존재해야 했고 그렇게 글을 정리하다보니 블로그까지 올리게 되었습니다.

대부분 공식 홈페이지에 존재하는 내용이긴 하지만 좀 더 쉽게 이미지를 첨부하고 실제 결과물로 내용을 더하였습니다.

커서 룰 자동 생성기

룰 종류

Cursor rules

.cursor/rules 내부에 생성하는 코드베이스 룰.

User rules

나의 커서 환경세팅으로 적용 가능한 글로벌 룰

.cursorrules (Legacy)

레거시

룰의 동작

내가 명령하는 컨텍스트의 시작 부분에 룰이 포함됩니다.

이렇게 하면 코드를 생성하든, 편집 내용을 해석하든, 워크플로우를 지원하든 AI에 일관된 지침을 제공할 수 있습니다.

프로젝트 룰

cursor - 기본 설정 - Cursor Settings

프로젝트 룰은 각각의 규칙이 .cursor/rules 폴더에 파일로 저장되면 버전으로 관리됩니다.

프로젝트 규칙을 사용하여 아래와 같은 룰을 추가할 수 있습니다.

코드베이스에 대한 도메인별 지식 인코딩
프로젝트별 워크플로 또는 템플릿 자동화
스타일 또는 아키텍처 결정 표준화

룰 구조

룰 파일은 MDC(.mdc)확장자를 지원합니다.

룰 파일 규칙

규칙 유형	설명
Always	항상 모델 컨텍스트에 포함됨
Auto Attached	글로브 패턴과 일치하는 파일이 참조될 때 포함됨
Agent Requested	규칙을 AI가 사용할 수 있으며, AI가 포함할지 여부를 직접 결정합니다. description을 제공해야 합니다.
Manual	@ruleName을 사용하여 명시적으로 언급된 경우에만 포함됨

Example

html

---
description: RPC Service boilerplate
globs: 
alwaysApply: false
---

- Use our internal RPC pattern when defining services
- Always use snake_case for service names.

@service-template.ts // 참조 파일

💡Cmd + Shift + P > “New Cursor Rule” 를 통해 빠르게 커서 룰 추가가 가능합니다!

중첩 규칙

html

project/
  .cursor/rules/        # Project-wide rules
  backend/
    server/
      .cursor/rules/    # Backend-specific rules
  frontend/
    .cursor/rules/      # Frontend-specific rules

디렉토리 기반 자동 적용

해당 디렉토리에 있는 파일들이 참조될 때 자동으로 적용됩니다.

context picker, 에이전트에서 접근가능

자동 적용 외에도 수동으로 적용도 가능합니다.

도메인별 규칙을 근처에 정리하기 적합

auth/, payment/, ui/ 등 각 기능 폴더마다 그에 특화된 규칙을 정의 가능
쉽게 말하면 나의 폴더구조에 app/auth/가 존재할때 rules/app/auth/ 가 존재한다면 예외적인 규칙을 적용가능하다는 의미

룰 생성 방법 2가지

규칙 만들기 새 커서 규칙 명령을 사용하거나 커서 설정 > 규칙으로 이동하여 규칙을 만들 수 있습니다. 그러면 .cursor/rules 디렉터리에 새 규칙 파일이 생성됩니다. 설정에서 모든 규칙의 목록과 상태를 볼 수도 있습니다.

cursor > 기본 설정 > Cursor Settings > Rules > add new rules
Generator Rules

Best practices

규칙을 간결하게 만드세요. 500줄 미만이 좋은 목표입니다.
큰 개념은 여러 개의 작성 가능한 규칙으로 나누기
도움이 되는 경우 구체적인 예시나 참조 파일을 제공하기
모호한 지침은 피하세요. 명확한 내부 문서를 작성하는 방식으로 규칙을 작성하세요
채팅에서 프롬프트가 반복되는 경우 규칙 재사용하기

직접 룰을 만들어본다면?

내가 적용하고 싶은 룰.

TDD
테스트를 먼저 작성한 다음 코드를 작성하고, 이를 기반으로 테스트를 실행하고 테스트가 통과될 때까지 코드를 업데이트해줘.
테스트 파일의 경우 현재 작업중이 폴더내부에 존재하는 __tests__ 폴더에 적용해줘
테스트의 경우 Jest를 사용해줘.
- 통합 테스트, E2E테스트는..검토 필요
디자인 시스템 컴포넌트로 mui를 사용하고 있어. 컴포넌트 사용은 우선순위를 지켜서 사용해줘. 1순위 : 도메인 컴포넌트, 2순위 : 공통 UI 컴포넌트(/components), 3순위 : mui 컴포넌트
1. 참고 파일
코드 컨벤션
1. import, type, 컴포넌트 사이에는 하나의 줄바꿈을 처리해줘
2. .eslintrc.js 규칙을 따라줘
3. prettier.config.json 규칙을 따라줘.
에러 핸들링
1. 에러 핸들링의 경우 errorHandler.ts 파일을 사용해줘
mock API
1. form Action이나 list 호출과 같은 API호출이 필요하다고 판단되는 부분은 mock API를 만들어줘. mock은 msw를 사용하고 있고 src/mock 폴더를 참고해서 추가해줘.
2. API 엔드포인트와 스키마는 나에게 요청해줘.

/Generator cursor Rules을 사용하여 무식하게 적용해보기

결과

plain text

  # Development Guidelines

      ## 1. Test-Driven Development (TDD)

      ### Testing Structure
      - All test files should be placed in the `__tests__` directory within the current working folder
      - Use Jest as the testing framework
      - Follow TDD workflow:
        1. Write test first
        2. Write implementation code
        3. Run tests
        4. Refactor until tests pass

      ### Test Types
      - Unit tests: Required for all new features
      - Integration tests: Under review
      - E2E tests: Under review

      ## 2. Component Usage Priority

      When implementing UI components, follow this priority order:

      1. Domain Components (highest priority)
      2. Common UI Components (`/components` directory)
      3. MUI Components (lowest priority)

      ## 3. Code Conventions

      ### Import and Component Structure
      ```typescript
      // imports
      import { useState } from 'react';

      // types
      type Props = {
        // ...
      };

      // component
      const MyComponent = () => {
        // ...
      };
      ```

      ### Code Style
      - Follow rules defined in `.eslintrc.js`
      - Follow formatting rules in `prettier.config.json`
      - Maintain single line breaks between imports, types, and component definitions

      ## 4. Error Handling

      Use the centralized error handling system:
      - All error handling should be implemented using `errorHandler.ts`
      - Reference: @errorHandler.ts

      ## 5. Mock API Implementation

      ### Mock API Guidelines
      - Use MSW (Mock Service Worker) for API mocking
      - Place mock implementations in `src/__mock__` directory
      - Follow existing mock patterns in the mock directory

      ### API Implementation Process
      1. When API calls are needed (e.g., form actions, list fetching):
         - Create mock implementation using MSW
         - Follow existing patterns in `src/__mock__`
      2. For new API endpoints:
         - Request API endpoint and schema details from the team
         - Implement mock after receiving specifications

      ### Mock API Structure
      ```typescript
      // Example mock structure
      import { rest } from 'msw';

      export const handlers = [
        rest.get('/api/endpoint', (req, res, ctx) => {
          return res(
            ctx.status(200),
            ctx.json({
              // mock data
            })
          );
        }),
      ];
      ```

      ## Reference Files
      - ESLint Config: @.eslintrc.js
      - Prettier Config: @prettier.config.json
      - Error Handler: @errorHandler.ts
      - Mock Directory: @src/__mock__

      ```

룰 타입 적용

결론

무식하게 해도 생각보다 룰만들기가 쉬웠습니다. 물론 커서 룰 자동 생성기가 만들어주는 것에 비하면 보잘 것 없긴 합니다. 그러나 제 프로젝트에 제가 원하는 룰을 만들기 위해서는 자동 생성기에 의존하기 보다 직접 구현하고 불편한점을 계속 고쳐나가는 게 더 쉽고 빠른길이라는 생각합니다.

출처

https://docs.cursor.com/context/rules

도움이 되었던 글

https://siosio3103.medium.com/%EB%B2%88%EC%97%AD-cursor-%EC%82%AC%EC%9A%A9-%EB%B0%A9%EB%B2%95-%EC%B5%9C%EA%B3%A0%EC%9D%98-%ED%8C%81-e931ced0429f

커서 룰 자동 생성기

awesome-cursor-rules-mdc

cursor-custom-agents-rules-generator