커서 디렉토리와 커서 룰 완벽 정리 | 바이브 코딩 필수 사이트
목록으로최초 발행: 2025년 12월 16일 오후 08:02|최종 수정: 2025년 12월 16일 오후 08:18
커서 디렉토리와 커서 룰 완벽 정리 | 바이브 코딩 필수 사이트
Cursor AI로 코딩을 하다 보면 이런 경험을 하게 됩니다. "TypeScript 써줘"라고 했는데 JavaScript로 코드를 짜고, "Tailwind CSS로 스타일링해"라고 했는데 엉뚱하게 CSS 모듈을 사용합니다. 매번 같은 말을 반복해야 하고, AI가 내 프로젝트 스타일을 전혀 모르는 것처럼 행동합니다.
이 문제의 원인은 간단합니다. AI는 대화가 시작될 때마다 백지 상태로 돌아가기 때문입니다. 어제 열 번을 말했던 규칙도 오늘은 다시 알려줘야 합니다. 프로젝트가 Next.js 14 앱 라우터를 쓴다는 것, 파일명은 케밥 케이스로 짓는다는 것, 코드 설명 없이 코드만 달라는 것을 매번 채팅창에 입력하는 건 시간 낭비입니다.
커서 룰(Cursor Rules)은 이 문제를 해결합니다. 프로젝트 폴더에 규칙 파일을 하나 만들어두면, AI가 대화를 시작할 때마다 이 파일을 자동으로 읽습니다. "이 프로젝트는 이런 규칙을 따라"라고 미리 가르쳐두는 것입니다. 그리고 cursor.directory는 전 세계 개발자들이 만들어둔 검증된 규칙 파일을 모아놓은 곳입니다. 직접 규칙을 작성할 필요 없이, 내 기술 스택에 맞는 규칙을 복사해서 바로 쓸 수 있습니다.
테슬라 AI 디렉터 출신 안드레이 카패시가 말한 바이브 코딩은 개발자가 "느낌(Vibe)"만 전달하면 AI가 알아서 구현하는 방식입니다. 이 방식이 제대로 작동하려면 AI가 프로젝트의 맥락을 완벽히 이해해야 합니다. cursor.directory와 커서 룰은 바로 이 맥락을 AI에게 심어주는 도구입니다.
1. cursor.directory가 정확히 무엇인지 이해하기
1) 프롬프트 규칙 라이브러리의 개념
cursor.directory는 웹사이트 주소 https://cursor.directory 이자, Cursor AI 에디터를 위한 규칙 파일 저장소입니다. 이곳에는 React, Python, Next.js, Flutter, Django, FastAPI 등 수십 가지 기술 스택별로 최적화된 규칙 파일이 올라와 있습니다. 각 규칙 파일은 해당 기술을 잘 아는 개발자들이 작성하고, 커뮤니티에서 검증한 것들입니다.
예를 들어 Next.js 규칙 파일에는 "App Router만 사용할 것", "서버 컴포넌트를 기본으로 할 것", "use client는 꼭 필요할 때만 쓸 것" 같은 모범 사례가 담겨 있습니다. 이 파일을 프로젝트에 넣어두면 AI가 구형 Page Router 대신 최신 App Router를 사용하고, 불필요한 클라이언트 컴포넌트를 남발하지 않습니다.
2) 규칙 파일이 AI 행동을 바꾸는 원리
Cursor AI는 대화를 시작할 때 프로젝트 루트에 있는 .cursorrules 파일을 자동으로 읽습니다. 이 파일의 내용은 AI의 시스템 프롬프트에 추가되어, 모든 응답에 영향을 미칩니다. 마치 새로 입사한 인턴에게 "우리 팀은 이렇게 일해"라는 업무 매뉴얼을 건네주는 것과 같습니다.
규칙 파일이 없으면 AI는 매번 범용적인 방식으로 코드를 작성합니다. 프로젝트의 특성을 모르니 당연한 일입니다. 하지만 규칙 파일이 있으면 AI는 "아, 이 프로젝트는 Tailwind를 쓰는구나", "여기서는 TypeScript 엄격 모드를 따라야 하는구나"라고 인식하고 그에 맞춰 코드를 생성합니다.
3) 사이트의 두 가지 핵심 섹션
cursor.directory는 크게 두 가지 섹션으로 나뉩니다. 첫 번째는 Rules 섹션으로, 기술 스택별 코딩 규칙이 모여 있습니다. Next.js, React, Python, TypeScript, Tailwind CSS 등 인기 있는 기술마다 여러 가지 규칙 파일이 있고, 각각 다운로드 수와 좋아요 수로 인기도를 확인할 수 있습니다.
두 번째는 MCP(Model Context Protocol) 섹션입니다. MCP는 Cursor가 외부 도구와 연동할 수 있게 해주는 표준 프로토콜입니다. 이 섹션에서는 Google Drive, Slack, GitHub, 로컬 파일 시스템 등과 연동할 수 있는 MCP 서버 정보를 제공합니다. 바이브 코딩을 코드 작성에서 전체 워크플로우 자동화까지 확장하려면 이 섹션을 활용해야 합니다.
2. 바이브 코딩이 성공하려면 커서 룰이 필수인 이유
1) 바이브 코딩의 정확한 의미
바이브 코딩은 안드레이 카패시가 2025년에 소개한 개념입니다. 개발자가 세부 구현을 직접 하지 않고, 자연어로 원하는 것을 설명하면 AI가 알아서 코드를 작성하는 방식을 말합니다. "로그인 페이지 만들어줘", "이 버튼 클릭하면 데이터 저장되게 해줘"처럼 느낌(Vibe)만 전달하고, 구체적인 구현은 AI에게 맡기는 것입니다.
이 방식의 장점은 개발 속도가 빨라진다는 것입니다. 문법을 일일이 기억하지 않아도 되고, 보일러플레이트 코드를 직접 작성하지 않아도 됩니다. 하지만 이 방식이 제대로 작동하려면 전제 조건이 있습니다. AI가 프로젝트의 맥락과 스타일을 정확히 알고 있어야 합니다.
2) 규칙 없는 AI의 한계
아무 설정 없는 AI는 범용적인 코드를 생성합니다. Next.js 프로젝트인데 React 클래스 컴포넌트를 쓰거나, Tailwind CSS 프로젝트인데 인라인 스타일을 사용하는 일이 벌어집니다. 개발자는 매번 "그거 말고 이거 써", "그 방식 말고 이 방식으로 해"라고 수정을 요청해야 합니다.
이런 상황은 바이브 코딩의 흐름을 깹니다. 느낌만 전달하고 싶은데, 세부 사항을 계속 지정해야 하니 결국 직접 코딩하는 것과 별반 다르지 않게 됩니다. 커서 룰은 이 문제를 해결합니다. AI가 미리 프로젝트 규칙을 알고 있으니, 개발자는 진짜로 느낌만 전달해도 됩니다.
3) 커서 룰이 만드는 차이
커서 룰을 적용하면 대화 방식이 달라집니다. "로그인 페이지 만들어줘"라고만 해도 AI는 규칙 파일을 참고하여 Next.js 앱 라우터 구조로, TypeScript로, Tailwind CSS로 코드를 작성합니다. "TypeScript로 해", "Tailwind 써"라는 추가 지시가 필요 없습니다.
토큰 비용도 절약됩니다. 매번 같은 지시를 반복하면 그만큼 토큰을 소모합니다. 규칙 파일에 한 번 적어두면 추가 토큰 없이 AI가 규칙을 따릅니다. 특히 긴 프로젝트에서 수십, 수백 번의 대화를 나눌 때 이 차이는 상당합니다.
3. cursor.directory를 방문해야 하는 4가지 구체적 이유
1) 전문가가 만든 검증된 규칙 확보
효과적인 프롬프트를 직접 작성하려면 시행착오가 필요합니다. 어떤 표현이 AI에게 잘 먹히는지, 어떤 순서로 규칙을 나열해야 하는지 경험으로 알아가야 합니다. cursor.directory에는 이미 수많은 개발자가 테스트하고 개선한 규칙들이 올라와 있습니다.
예를 들어 인기 있는 Next.js 규칙 파일에는 "App Router만 사용", "서버 컴포넌트 우선", "next/image 필수 사용", "any 타입 금지" 같은 모범 사례가 촘촘하게 담겨 있습니다. 이런 규칙을 직접 정리하려면 Next.js 공식 문서를 읽고, 베스트 프랙티스를 공부하고, 프롬프트 표현을 다듬는 시간이 필요합니다. cursor.directory를 쓰면 이 시간을 아낄 수 있습니다.
2) 반복적인 지시 제거로 생산성 향상
채팅창에 매번 입력하는 문장들을 생각해보면, 상당 부분이 반복입니다. "코드만 줘, 설명하지 마", "파일명은 케밥 케이스로", "컴포넌트는 화살표 함수로", "console.log 남기지 마" 같은 지시를 프로젝트 내내 반복하게 됩니다.
cursor.directory의 규칙을 적용하면 이런 반복이 사라집니다. 규칙 파일에 한 번 적어두면 AI가 기본값으로 인식합니다. 개발자는 핵심 로직에만 집중하면 됩니다. "사용자 인증 기능 추가해줘"라고만 하면, 규칙에 맞는 스타일로 코드가 나옵니다.
3) MCP를 통한 AI 기능 확장
cursor.directory의 MCP 섹션은 Cursor의 기능을 크게 확장합니다. MCP(Model Context Protocol)는 AI가 외부 도구와 직접 소통할 수 있게 해주는 표준입니다. 이 섹션에서 유용한 MCP 서버를 찾아 연동하면, AI가 단순히 코드를 짜는 것을 넘어 다양한 작업을 수행합니다.
예를 들어 Google Drive MCP를 연동하면 AI가 드라이브 문서를 읽고 내용을 코드에 반영할 수 있습니다. GitHub MCP를 연동하면 이슈를 읽고 관련 코드를 수정할 수 있습니다. 파일 시스템 MCP를 연동하면 프로젝트 폴더를 직접 탐색하고 파일을 생성할 수 있습니다. 바이브 코딩의 범위가 코드 작성에서 전체 개발 워크플로우로 확장됩니다.
4) 팀 단위 협업에서 코드 일관성 유지
혼자 개발할 때는 본인 스타일대로 하면 됩니다. 하지만 팀으로 개발할 때는 코드 스타일 통일이 중요합니다. 같은 프로젝트인데 A 개발자는 화살표 함수를 쓰고 B 개발자는 일반 함수를 쓰면 코드가 일관성 없어 보입니다.
cursor.directory의 규칙 파일을 프로젝트에 넣어두면, 누가 AI를 돌리든 같은 스타일의 코드가 나옵니다. 규칙 파일을 Git에 커밋해두면 팀원 전체가 동일한 규칙을 사용하게 됩니다. 코드 리뷰 시간이 줄고, "이거 왜 이렇게 썼어?"라는 질문이 줄어듭니다.
4. 커서 룰 작성 방법 두 가지 완전 정리
1) 방법 ①: .cursorrules 파일 (가장 쉽고 권장)
가장 간단한 방법은 프로젝트 최상위 폴더(루트)에 .cursorrules라는 이름의 파일을 만드는 것입니다. 파일명 앞에 점(.)이 있어서 숨김 파일로 취급되지만, Cursor 에디터에서는 정상적으로 보입니다.
이 파일에 작성한 규칙은 프로젝트 전체에 전역적으로 적용됩니다. 어떤 파일을 열든, 어떤 폴더에서 작업하든 AI는 이 규칙을 참고합니다. 프로젝트의 핵심 기술 스택, 코딩 스타일, 절대 어겨서는 안 되는 원칙을 정의할 때 사용합니다.
파일 생성 방법은 간단합니다. Cursor 에디터에서 프로젝트 루트를 선택하고, 마우스 오른쪽 클릭 후 New File을 선택합니다. 파일명에 .cursorrules를 입력하면 됩니다. 또는 터미널에서 touch .cursorrules 명령어로 생성할 수도 있습니다.
2) 방법 ②: .cursor/rules/*.mdc 폴더 방식 (고급, 모듈형)
더 세밀한 제어가 필요하면 폴더 방식을 사용합니다. 프로젝트 루트에 .cursor라는 폴더를 만들고, 그 안에 rules라는 하위 폴더를 만듭니다. 이 rules 폴더 안에 .mdc 확장자로 여러 파일을 생성합니다.
이 방식의 장점은 특정 파일이나 폴더에만 규칙을 적용할 수 있다는 것입니다. 예를 들어 backend.mdc 파일을 만들고 파이썬 파일에만 적용되도록 설정할 수 있습니다. frontend.mdc 파일은 TypeScript 파일에만 적용되도록 할 수 있습니다. 풀스택 프로젝트에서 프론트엔드와 백엔드 규칙을 분리하고 싶을 때 유용합니다.
폴더 구조는 다음과 같습니다. 프로젝트 루트 아래에 .cursor 폴더가 있고, 그 안에 rules 폴더가 있으며, rules 폴더 안에 frontend.mdc, backend.mdc, testing.mdc 같은 파일들이 있습니다.
3) 두 방식 중 어떤 것을 선택해야 하는가
소규모 프로젝트나 단일 기술 스택을 사용하는 경우 .cursorrules 파일 하나로 충분합니다. 설정이 단순하고 관리가 쉽습니다. 대부분의 개인 프로젝트나 학습 프로젝트는 이 방식으로 해결됩니다.
반면 풀스택 프로젝트, 모노레포, 여러 언어가 혼합된 프로젝트에서는 .mdc 파일을 여러 개 만들어 관리하는 것이 낫습니다. 프론트엔드 개발할 때는 프론트엔드 규칙만, 백엔드 개발할 때는 백엔드 규칙만 적용되니 더 정확한 코드가 나옵니다.
두 방식을 동시에 사용할 수도 있습니다. .cursorrules에 전역 규칙을 넣고, .mdc 파일에 특정 상황별 규칙을 넣으면 됩니다. 규칙이 충돌하는 경우 더 구체적인 규칙(.mdc)이 우선 적용되는 경향이 있습니다.
5. 커서 룰 작성 문법과 구조 상세 설명
1) 마크다운 기반 기본 구조
규칙 파일은 마크다운(Markdown) 문법을 따릅니다. 제목은 #으로 시작하고, 목록은 -로 시작합니다. AI가 읽기 쉽게 구조화하면 됩니다. 복잡한 문법이 필요 없고, 평소 마크다운 문서 작성하듯 쓰면 됩니다.
일반적인 구조는 역할(Role) 정의, 기술 스택(Tech Stack) 명시, 코딩 스타일 가이드(Coding Style Guide), 행동 규칙(Rules) 순서입니다. 역할 정의에서는 AI에게 "너는 시니어 풀스택 개발자야"처럼 정체성을 부여합니다. 기술 스택에서는 프로젝트에서 사용하는 기술을 나열합니다. 코딩 스타일 가이드에서는 네이밍 컨벤션, 파일 구조 등을 정합니다. 행동 규칙에서는 "코드 설명하지 마", "any 타입 쓰지 마" 같은 구체적인 지시를 넣습니다.
2) 기본 작성 예시
# Role
You are an expert Senior Full-Stack Developer specializing in Next.js 14, Supabase, and Tailwind CSS. # Tech Stack
- Frontend: Next.js 14 (App Router), React, Tailwind CSS
- Backend: Supabase (Auth, DB), Python (Edge Functions)
- State Management: Zustand # Coding Style Guide
- Use functional components with TypeScript interfaces.
- Use const for variable declarations.
- Prefer async/await over promise chains.
- File naming: Use kebab-case for files (e.g., user-profile.tsx). # Rules
- Never explain the code unless asked. Just provide the code.
- Always use strict types. No any.
- If you modify a file, show the full file content only if it's small (<100 lines). Otherwise, show precise diffs.
이 예시에서 AI는 Next.js 14 전문가 역할을 맡고, App Router와 Tailwind CSS를 기본으로 사용합니다. 코드 설명 없이 코드만 제공하고, any 타입은 절대 쓰지 않습니다.
3) .mdc 파일의 Frontmatter 문법
.mdc 파일에서는 상단에 Frontmatter를 추가하여 적용 범위를 지정합니다. Frontmatter는 세 개의 대시(---)로 감싸는 YAML 형식입니다.
---
description: Rule for Python Backend files
globs: **/*.py
alwaysApply: false
---
# Python Coding Standards - Follow PEP 8 style guide.
- Use Type Hints for all function arguments and return values.
- Docstrings should follow Google Style.
description은 이 규칙이 무엇인지 설명합니다. globs는 이 규칙이 적용될 파일 패턴입니다. 위 예시에서 **/*.py는 모든 폴더의 파이썬 파일을 의미합니다. alwaysApply가 true면 파일 패턴과 상관없이 항상 이 규칙을 참고합니다.
4) 효과적인 규칙 작성을 위한 팁
구체적인 부정 명령을 포함하면 AI가 원치 않는 행동을 하지 않습니다. "Tailwind CSS 사용해"보다 "CSS 모듈 쓰지 마, 무조건 Tailwind CSS 써"가 더 효과적입니다. AI는 긍정 명령보다 부정 명령을 더 확실하게 따르는 경향이 있습니다.
한글로 작성해도 AI는 이해합니다. 다만 기술 용어나 프레임워크 이름은 영어로 쓰는 편이 정확도가 높습니다. "넥스트제이에스"보다 "Next.js"로 쓰세요. 설명이나 지시는 한글로, 기술 스택은 영어로 쓰는 혼합 방식도 좋습니다.
규칙이 너무 길면 AI가 일부를 무시할 수 있습니다. 핵심적인 규칙 위주로 간결하게 작성하고, 덜 중요한 규칙은 과감히 생략하세요. 20-30개 규칙이 적당합니다.
6. 실전에서 바로 복사해서 쓰는 템플릿 3가지
1) 웹 개발용 템플릿: Next.js + Tailwind CSS + TypeScript
프론트엔드 웹 개발에서 가장 인기 있는 스택입니다. 이 템플릿을 적용하면 AI가 구형 Page Router 대신 최신 App Router를 사용하고, 서버 컴포넌트를 우선하며, TypeScript 엄격 모드를 따릅니다.
# Role
You are an expert Frontend Developer specializing in Next.js (App Router), TypeScript, and Tailwind CSS. # Tech Stack & Principles
- Framework: Next.js 14+ (App Router only, no Page Router)
- Styling: Tailwind CSS (Use utility classes, avoid arbitrary values like w-[35px])
- Language: TypeScript (Strict mode, no any type)
- Component: React Server Components (RSC) by default. Use 'use client' only when hooks/interactivity are needed. # Coding Guidelines
1. Naming Conventions - Components: PascalCase (e.g., UserProfile.tsx) - Functions/Variables: camelCase - Files/Folders: kebab-case (e.g., user-profile/page.tsx) 2. Code Structure - Export components as named exports. - Use lucide-react for icons. - Implement error handling with error.tsx and not-found.tsx. 3. Performance - Use next/image for all images. - Minimize use of useEffect and useState; prefer Server Actions for data fetching. # Behavior Rules
- Do not provide explanations unless asked ("Don't be chatty").
- Always verify if a library is installed before importing it.
- When suggesting code, provide the full complete code for small files (<50 lines). For large files, use concise diffs.
2) 백엔드 개발용 템플릿: Python + FastAPI
파이썬 백엔드 개발에 최적화된 템플릿입니다. 타입 힌트 필수, 비동기 처리 우선, PEP 8 스타일 가이드 준수 등 깔끔한 백엔드 코드를 위한 규칙이 담겨 있습니다.
# Role
You are a Senior Backend Engineer proficient in Python 3.12+, FastAPI, and SQLAlchemy. # Core Principles
- Clean Code: Follow PEP 8 standards strictly.
- Type Safety: MUST use Type Hints for all function arguments and return values (e.g., def get_user(id: int) -> User:).
- Asynchronous: Prefer async/await for all I/O bound operations (DB, API calls). # Implementation Rules
1. API Design - Follow RESTful API standards. - Use Pydantic models for data validation. - Return clear HTTP status codes (201 for created, 404 for not found). 2. Error Handling - Use try/except blocks for external calls. - Log errors using the standard logging module, not print(). 3. Documentation - Add Docstrings (Google Style) to all public functions and classes. - Keep comments concise and focused on "Why", not "What". # Restrictions
- Do not use global variables.
- Avoid deeply nested loops (max depth: 3).
- Never leave "TODO" comments in the final code output.
3) 범용 한국어 템플릿: 초보자 친화적
영어 프롬프트가 부담스럽거나, 특정 기술 스택에 종속되지 않는 범용 규칙이 필요할 때 사용합니다. 한국어로 답변을 받고, 서론 없이 바로 코드를 제시하도록 설정합니다.
# 역할
당신은 세계 최고의 풀스택 개발자 멘토입니다. 내 코드를 분석하고 최적의 솔루션을 제공하세요. # 기본 원칙
1. 한국어 답변: 모든 설명은 한국어로 해주세요.
2. 코드 우선: 서론(인사말, 잡담)을 생략하고 바로 코드나 해결책부터 제시하세요.
3. 최신 문법: 항상 해당 언어의 최신 안정 버전(Stable) 문법을 사용하세요. # 코드 작성 규칙
- 변수명은 직관적이고 의미 있게 지으세요 (예: a 대신 userCount).
- 코드가 길어질 경우, 핵심 변경 사항 위주로 보여주되 문맥 파악이 가능하도록 주변 코드 1-2줄을 포함하세요.
- 보안에 취약한 코드(예: API 키 하드코딩)는 절대 작성하지 말고 경고해주세요. # 행동 지침
- 내가 짠 코드에서 잠재적 버그가 보이면 수정된 코드를 제안하기 전에 먼저 알려주세요.
- 모르는 라이브러리나 함수가 나오면 환각(Hallucination)을 일으키지 말고 "정보가 부족하다"고 말해주세요.
7. 커서 룰 적용 후 확인하는 방법
1) 파일 생성 단계별 과정
첫 번째 단계는 Cursor 에디터를 열고 프로젝트 폴더를 여는 것입니다. 왼쪽 탐색기(Explorer) 패널에서 프로젝트 루트가 보여야 합니다.
두 번째 단계는 파일을 생성하는 것입니다. 탐색기에서 프로젝트 루트(가장 상위 폴더)를 선택하고 마우스 오른쪽 클릭합니다. New File을 선택하고 파일명에 .cursorrules를 입력합니다. 파일명 맨 앞에 점(.)이 있어야 합니다.
세 번째 단계는 규칙 내용을 채우는 것입니다. cursor.directory에서 내 기술 스택을 검색하고, 마음에 드는 규칙을 복사해서 붙여넣습니다. 또는 위에서 제공한 템플릿을 복사해서 붙여넣어도 됩니다. 필요에 따라 내용을 수정합니다.
2) 규칙이 적용되었는지 확인하는 방법
규칙 파일을 저장한 후 Cursor 채팅창(Ctrl+L 또는 Cmd+L)을 엽니다. 아무 질문이나 던져봅니다. 예를 들어 "버튼 컴포넌트 만들어줘"라고 입력합니다.
AI가 응답하기 전에 잠깐 "Reading .cursorrules..." 같은 문구가 표시될 수 있습니다. 또는 채팅창 하단에 Rules 인디케이터가 활성화되어 있는지 확인합니다. 응답 내용이 규칙에 맞는지도 확인합니다. TypeScript를 쓰라고 했는데 TypeScript로 코드가 나오면 규칙이 적용된 것입니다.
3) 규칙 수정 시 반영 시점
규칙 파일을 수정하고 저장하면 다음 대화부터 새 규칙이 적용됩니다. 이미 진행 중인 대화에서는 새 규칙이 바로 반영되지 않을 수 있습니다. 확실하게 하려면 새 채팅을 시작하는 것이 좋습니다.
프로젝트가 진행되면서 규칙이 바뀌면 수시로 파일을 수정하세요. AI는 항상 최신 저장된 규칙 파일을 참조합니다. 초기에는 규칙이 느슨해도 되지만, 프로젝트가 커지면서 규칙을 세밀하게 다듬어가는 것이 좋습니다.
8. MCP 서버 활용으로 바이브 코딩 확장하기
1) MCP가 무엇인지 이해하기
MCP는 Model Context Protocol의 약자로, AI 모델이 외부 도구와 표준화된 방식으로 소통할 수 있게 해주는 프로토콜입니다. 쉽게 말해 AI에게 "손"을 달아주는 것입니다. 기본 AI는 텍스트만 읽고 쓸 수 있지만, MCP를 통해 파일을 읽고, 웹 검색을 하고, 다른 서비스와 연동할 수 있습니다.
cursor.directory의 MCP 섹션(https://cursor.directory/mcp)에는 다양한 MCP 서버 정보가 모여 있습니다. 각 서버는 특정 기능을 제공합니다. 파일 시스템 접근, GitHub 연동, 데이터베이스 쿼리, 웹 검색 등 다양한 서버가 있습니다.
2) 유용한 MCP 서버 예시
파일 시스템 MCP는 AI가 로컬 파일을 직접 읽고 쓸 수 있게 합니다. "프로젝트의 모든 컴포넌트 파일을 분석해줘"라고 하면 AI가 직접 파일들을 읽어서 분석합니다.
GitHub MCP는 AI가 GitHub 저장소와 연동됩니다. 이슈 목록을 읽거나, 풀 리퀘스트 내용을 확인하거나, 커밋 히스토리를 분석할 수 있습니다. "최근 이슈들을 보고 우선순위를 정리해줘"라고 하면 AI가 실제 이슈를 읽고 정리해줍니다.
데이터베이스 MCP는 AI가 데이터베이스에 직접 쿼리를 날릴 수 있게 합니다. 스키마를 파악하거나 샘플 데이터를 확인할 때 유용합니다.
3) MCP 설정 방법
cursor.directory의 MCP 섹션에서 원하는 서버를 찾습니다. 각 서버 페이지에 설치 방법과 설정 방법이 안내되어 있습니다. 대부분 Cursor 설정 파일에 서버 정보를 추가하는 방식입니다.
MCP 설정은 규칙 파일보다 조금 복잡하지만, 한 번 설정해두면 AI의 능력이 크게 확장됩니다. 바이브 코딩을 코드 작성에서 전체 개발 워크플로우 자동화까지 확장하고 싶다면 MCP를 적극 활용해보세요.
9. FAQ
Q: cursor.directory에서 가져온 규칙을 그대로 써도 되나요?
A: 대부분의 규칙은 바로 사용할 수 있지만, 프로젝트 상황에 맞게 수정하는 것을 권장합니다. 규칙 파일에 명시된 기술 스택 버전이 내 프로젝트와 다를 수 있고, 팀 내 코딩 컨벤션이 따로 있을 수도 있습니다. 규칙 파일은 템플릿으로 활용하고, 필요한 부분만 수정하거나 삭제하세요. 처음에는 그대로 써보고, AI 응답이 마음에 안 드는 부분이 있으면 그때 수정해도 됩니다.
Q: .cursorrules 파일과 .mdc 파일을 동시에 사용할 수 있나요?
A: 동시에 사용할 수 있습니다. .cursorrules는 전역 규칙으로 항상 적용되고, .mdc 파일은 지정한 파일 패턴에만 추가로 적용됩니다. 예를 들어 .cursorrules에 전체 프로젝트 스타일을 넣고, python-backend.mdc에 파이썬 전용 규칙을 넣으면 파이썬 파일 작업 시 두 규칙이 모두 적용됩니다. 두 규칙이 충돌하는 경우 더 구체적인 규칙(.mdc)이 우선하는 경향이 있지만, 가능하면 충돌을 피하도록 규칙을 설계하세요.
Q: 한글로 규칙을 작성해도 AI가 잘 이해하나요?
A: 한글로 작성해도 AI는 충분히 이해합니다. Claude나 GPT 같은 대형 언어 모델은 한국어 처리 능력이 좋습니다. 다만 기술 용어나 프레임워크 이름은 영어로 쓰는 편이 정확도가 높습니다. "넥스트제이에스"보다 "Next.js", "타입스크립트"보다 "TypeScript"로 쓰세요. 설명이나 지시문은 한글로, 기술 스택 이름은 영어로 쓰는 혼합 방식이 가장 효과적입니다.
Q: 규칙 파일을 Git에 커밋해야 하나요?
A: 커밋하는 것을 권장합니다. .cursorrules 파일을 버전 관리에 포함하면 팀원 모두가 동일한 규칙을 사용하게 됩니다. 새로운 팀원이 합류해도 AI가 같은 스타일로 코드를 생성하니 온보딩이 쉬워집니다. 다만 개인적인 취향이 반영된 규칙(예: "이모지 많이 써줘")은 .gitignore에 추가하여 개인 로컬에만 유지할 수도 있습니다. 팀 규칙과 개인 규칙을 분리하려면 .mdc 파일을 활용하세요.
Q: 규칙이 적용되지 않는 것 같을 때 어떻게 해야 하나요?
A: 몇 가지 확인할 점이 있습니다. 첫째, 파일명이 정확히 .cursorrules인지 확인하세요. 앞에 점(.)이 없거나 오타가 있으면 작동하지 않습니다. 둘째, 파일이 프로젝트 루트에 있는지 확인하세요. 하위 폴더에 있으면 인식되지 않습니다. 셋째, Cursor를 재시작해보세요. 간혹 파일 변경이 바로 반영되지 않는 경우가 있습니다. 넷째, 새 채팅을 시작해보세요. 이미 진행 중인 대화에서는 규칙 변경이 바로 반영되지 않을 수 있습니다.
Q: 규칙을 너무 많이 넣으면 문제가 생기나요?
A: 규칙이 너무 많으면 AI가 일부를 무시하거나 충돌하는 규칙 사이에서 혼란을 겪을 수 있습니다. 핵심적인 규칙 20-30개 정도가 적당합니다. 덜 중요한 규칙은 과감히 생략하고, 정말 중요한 규칙 위주로 간결하게 작성하세요. 규칙이 많아지면 우선순위를 명시하는 것도 방법입니다. "위 규칙이 충돌하면 첫 번째 규칙을 우선한다" 같은 문구를 추가할 수 있습니다.
10. 마무리
cursor.directory와 커서 룰은 바이브 코딩의 효율을 근본적으로 높이는 도구입니다. AI에게 프로젝트의 맥락을 미리 알려주면, 매번 같은 지시를 반복하지 않아도 원하는 스타일의 코드를 얻을 수 있습니다. 마치 유능한 인턴에게 업무 매뉴얼을 건네주는 것과 같습니다. 매뉴얼이 잘 정리되어 있으면 인턴이 물어보지 않고도 알아서 일합니다.
핵심 요약:
- cursor.directory는 Cursor AI용 프롬프트 규칙 라이브러리로, 기술 스택별 검증된 규칙을 제공합니다
- 커서 룰을 적용하면 AI가 프로젝트 맥락을 이해하고, 반복적인 지시 없이도 일관된 코드를 생성합니다
- .cursorrules 파일은 프로젝트 전역에 적용되며, .mdc 파일은 특정 파일 패턴에만 적용됩니다
- 규칙 파일은 마크다운 문법으로 작성하며, 역할 정의, 기술 스택, 코딩 스타일, 행동 규칙 순서가 일반적입니다
- MCP 섹션을 활용하면 AI가 외부 도구와 연동되어 바이브 코딩의 범위가 크게 확장됩니다
지금 바로 cursor.directory에 방문하여 사용 중인 기술 스택에 맞는 규칙을 찾아보세요. 프로젝트 루트에 .cursorrules 파일을 만들고 규칙을 붙여넣는 데 5분도 걸리지 않습니다. 그 5분 투자가 앞으로의 모든 AI 대화를 바꿔놓을 것입니다.
