어떤 Cursor Rules를 Skills로 전환하고 어떤 것을 그대로 남겨둘지 분류하는 방법 (2026년 가이드)

겉보기에는 두 메커니즘이 겹쳐 보입니다. 둘 다 에이전트가 설명을 바탕으로 선택할 수 있기 때문입니다.

Rules 측면에서 Cursor는 네 가지 적용 모드를 문서화하고 있습니다. Always Apply("모든 채팅 세션에 적용"), Apply Intelligently("설명을 바탕으로 에이전트가 관련이 있다고 판단할 때"), Apply to Specific Files("파일이 지정된 패턴과 일치할 때"), 그리고 Apply Manually("채팅에서 @로 언급될 때")입니다. 근본적인 작동 방식은 훨씬 더 간단하게 설명되어 있습니다. "alwaysApply가 true이면 규칙이 모든 채팅 세션에 적용됩니다. 그렇지 않으면 규칙의 설명(description)이 Cursor Agent에게 제공되어 적용 여부를 결정하게 합니다."

Skills 측면에서도 선택 방식은 거의 동일하게 들립니다. "Cursor가 시작되면 스킬 디렉토리에서 스킬을 자동으로 감지하여 에이전트가 사용할 수 있도록 합니다. 에이전트에게 사용 가능한 스킬이 제시되며, 에이전트는 컨텍스트를 기반으로 언제 스킬이 관련이 있는지 결정합니다." 이를 구동하는 프론트매터 필드도 똑같이 설명되어 있습니다. description은 "에이전트가 관련성을 판단하는 데 사용됩니다."

따라서 둘 다 설명을 통해 선택될 수 있고, 둘 다 파일 범위(file-scoped)로 지정될 수 있습니다. Skills는 paths 필드를 사용하는데, "설정되면 에이전트가 일치하는 파일로 작업할 때만 스킬이 노출됩니다." 이는 Rules의 globs와 동일한 개념입니다. Skills는 또한 자동으로 실행되지 않도록 고정할 수도 있습니다. disable-model-invocation이 "true이면 스킬은 /skill-name을 통해 명시적으로 호출될 때만 포함됩니다. 에이전트는 컨텍스트를 기반으로 이를 자동으로 적용하지 않습니다."

이 둘이 진정으로 다른 점은 각자가 담을 수 있는 내용과 그것이 읽히는 시점입니다.

Rule은 프롬프트에 들어가는 텍스트입니다. Rules가 존재하는 이유에 대한 Cursor의 설명은 근본적인 문제를 짚어주고 있어 인용할 가치가 있습니다. "대형 언어 모델은 완료(completion) 간에 메모리를 유지하지 않습니다. Rules는 프롬프트 수준에서 지속적이고 재사용 가능한 컨텍스트를 제공합니다."

Skill은 패키지입니다. "Skill은 에이전트에게 도메인별 작업을 수행하는 방법을 가르치는 이식 가능하고 버전 관리되는 패키지입니다. Skills에는 에이전트가 도구를 사용하여 실행할 수 있는 스크립트, 템플릿 및 참조 자료가 포함될 수 있습니다." 그리고 이는 Cursor에만 국한되지 않습니다. "Skills는 Agent Skills 표준을 지원하는 모든 에이전트에서 작동합니다."

이 마지막 문장이 결정을 바꾸는 부분입니다. 이 두 형식 중 하나는 여러분과 함께 다른 도구로 이동할 수 있지만, 다른 하나는 Cursor 전용 구조입니다. 이식성은 팀이 에이전트 간에 이동할 때마다 동일한 질문이 계속 제기되는 이유이기도 합니다. 예를 들어 migrating Cursor rules into Codex의 사례가 그렇습니다.

모든 것에 변환기 실행하기. 명령어가 존재하기 때문에 Cursor가 이미 여러분을 위해 결정을 내린 것처럼 보일 수 있습니다. 하지만 이 명령어는 대상이 되는 동적 규칙과 슬래시 명령어만 변환합니다. '대상'이라는 단어는 중요한 의미를 담고 있으며, 항상 적용되는 컨벤션은 패키징을 기다리는 다단계 절차가 아닙니다.

이미 잘 작동하므로 모든 것을 Rules로 유지하기. 일리 있는 선택이지만, 문서에서 언급하는 비용이 발생합니다. Rules는 시작할 때 모델 컨텍스트에 들어갑니다. Cursor 자체의 모범 사례에서도 비대해지는 것을 경고합니다. "규칙을 500행 미만으로 유지하세요", "큰 규칙은 조합 가능한 여러 규칙으로 분할하세요", "내용을 복사하는 대신 파일을 참조하세요. 이렇게 하면 규칙을 짧게 유지하고 코드가 변경됨에 따라 규칙이 오래되는 것을 방지할 수 있습니다."

rules 디렉토리에 일반 Markdown 파일 넣기. 이는 가장 명확하게 문서화된 실수이며, Cursor는 이제 이를 분명히 밝히고 있습니다. "프로젝트 규칙은 반드시 .mdc 확장자를 사용해야 합니다. .cursor/rules에 있는 일반 .md 파일은 description, globs, alwaysApply를 지정하는 프론트매터가 없기 때문에 규칙 시스템에서 무시됩니다." 문서에서는 대안도 제시합니다. "일반 markdown을 선호한다면 대신 AGENTS.md를 사용하세요." 이 파일로 통합할지 여부는 별개의 결정이며, 저희는 moving a CLAUDE.md into AGENTS.md에서 이를 자세히 다루었습니다.

홈 디렉토리의 skills가 작업 공간을 따라 이동할 것이라 가정하기. 대부분 그렇지 않으며, Cursor는 그 경계를 다음과 같이 명시합니다. "Cursor는 ~/.agents/skills/ 또는 동기화되지 않은 로컬 스킬을 Cloud Agents, Agents Window 원격 SSH 세션 또는 자체 호스팅 워커로 복사하지 않습니다." 문서에서는 이러한 경우 중 하나에 대한 해결책을 제시합니다. "자체 호스팅 워커에서는 레포지토리의 프로젝트 스킬을 사용하거나 워커 이미지에 스킬을 빌드해 넣으세요."

에이전트가 실수를 할 때마다 더 많은 규칙 작성하기. Cursor의 가이드는 의도적으로 신중할 것을 권장합니다. "단순하게 시작하세요. 에이전트가 동일한 실수를 반복하는 것을 발견했을 때만 규칙을 추가하세요." 피해야 할 사항 목록도 매우 구체적입니다. "스타일 가이드 전체 복사하기: 대신 린터를 사용하세요", "가능한 모든 명령어 문서화하기", "거의 적용되지 않는 예외 상황에 대한 지침 추가하기", "이미 코드베이스에 있는 내용 중복 작성하기". 규칙이 쌓이면 when Cursor forgets your project rules에서 설명한 것과 같은 이탈 현상이 발생하기 쉽습니다.

Skills를 에이전트의 메모리로 취급하기. Skills는 패키지화된 절차이지, 팀이 결정한 사항의 기록이 아닙니다. 이 차이는 생각보다 중요하며, 저희는 why agent skills aren't memory에서 이를 설명했습니다.

한 가지 질문만 던져보면 거의 모든 경우를 결정할 수 있습니다. '이것은 항상 참(always true)인가, 아니면 수행해야 하는 작업(something you do)인가?'

1단계: 각 항목을 항상 참, 파일 범위, 또는 절차형으로 분류하기

항상 참(Always true)인 항목은 alwaysApply가 켜진 Rule에 속합니다. 저작권 헤더, 변경 사항을 제안하기 전에 소스 파일을 읽으라는 지침, 절대 수정해서는 안 되는 디렉토리 등 Cursor 자체의 항상 적용 예시가 바로 이러한 목록입니다. 이들은 토큰 비용이 적게 들고 누락되었을 때의 대가가 크므로, 에이전트가 관련성 여부를 판단하게 해서는 안 됩니다.

파일 범위(File-scoped)인 항목은 어느 쪽이든 가능하며, 실제 결정 기준은 이식성입니다. globs가 있는 Rule과 paths가 있는 Skill은 동일한 역할을 수행합니다. 해당 컨벤션이 다른 에이전트에서도 중요할 가능성이 높다면, 이동이 가능한 Skill 형식을 선택하는 것이 좋습니다.

절차형(Procedural)인 항목은 Skill에 속하며, 여기서 변환기가 제 역할을 톡톡히 해냅니다. 단계가 있거나, 채워야 할 템플릿이 있거나, 실행할 스크립트가 있거나, 참조 자료가 첨부된 모든 것은 Skill 형식을 위해 만들어진 것입니다. Skill은 "에이전트가 도구를 사용하여 실행할 수 있는 스크립트, 템플릿 및 참조 자료"를 전달하고 필요할 때만 로드할 수 있습니다. 이를 Rule에 억지로 밀어 넣으면 오늘의 작업에 해당 절차가 포함되어 있든 없든 전체 절차가 프롬프트에 상주하게 됩니다.

Cursor 자체의 레포 범위 지정 방식은 의도에 대한 유용한 힌트를 줍니다. "중첩된 프로젝트 디렉토리의 Skills는 해당 디렉토리 내부의 파일로 범위가 자동으로 지정됩니다." 따라서 적용 대상 패키지 옆에 배치된 Skill은 별도의 설정 없이도 범위가 지정됩니다. 이는 scoping instructions to files에서 살펴본 파일 국소성(file-locality) 원칙과 동일합니다.

2단계: 각 항목을 누가 선택할지 결정하고, 이에 맞게 필드 설정하기

각 항목에 대해 항상 로드할지, 에이전트가 선택하게 할지, 파일과 일치시킬지, 아니면 수동으로 호출할지 결정하세요. 그런 다음 일치하는 필드를 설정하십시오. 양쪽의 기본값이 다르기 때문입니다.

Rule의 경우, 항상 적용하려면 alwaysApply: true, 에이전트가 선택하게 하려면 description, 파일과 일치시키려면 globs를 설정하고, 수동으로 하려면 아무것도 설정하지 않습니다. Cursor는 설명과 globs가 없는 규칙은 "채팅에서 규칙을 @로 언급할 때만 포함됩니다"라고 명시하고 있습니다.

Skill은 기본적으로 에이전트가 선택합니다. Cursor가 사용 가능한 스킬을 제시하면 에이전트가 설명을 보고 관련성을 판단하기 때문입니다. 수동 전용으로 만들려면 disable-model-invocation을 설정하세요. 파일 범위로 지정하려면 paths를 설정하세요. 그리고 호출 동작에 유의하세요. 슬래시로 호출된 스킬은 "메시지 하나에만 첨부"되므로, 세션 전체에서 활성화하려는 스킬은 단일 턴에 사용하려는 스킬과 설정이 달라야 합니다.

준수해야 할 명명 규칙 한 가지: 스킬의 name은 반드시 "소문자, 숫자, 하이픈만 사용"해야 하며 "부모 폴더 이름과 일치해야 합니다."

3단계: 두 형식 모두에 속하지 않는 곳에 각 컨벤션이 존재하는 이유 기록하기

Rules와 Skills는 모두 지침을 담고 있습니다. 두 형식 모두 지침 뒤에 숨겨진 논거를 담기에는 적절하지 않으며, Cursor 자체의 권장 사항도 이러한 파일 내부의 콘텐츠를 외부로 빼낼 것을 권장합니다. 내용을 복사하는 대신 파일을 참조하고, 표준 예시를 가리키고, 규칙을 짧게 유지하라는 것입니다.

여기에 공백이 생깁니다. "컬럼 타입을 인플레이스(in-place)로 절대 변경하지 말 것"은 규칙입니다. 하지만 왜 그렇게 해야 하는지(어떤 마이그레이션이 몇 월에 문제를 일으켰고, 그 이후 팀이 무엇에 합의했는지)는 다음 분기에 누군가가 그 규칙을 삭제하는 것을 막아주는 핵심 정보입니다. 두 형식을 모두 넘어서 오래 보존될 수 있는 곳에 이를 기록해 두세요.

Rules와 Skills는 에이전트가 어떻게 행동해야 하는지에 대한 답을 줍니다. 하지만 팀이 결정한 사항과 그 이유는 담기에 적절하지 않음에도, 사람들은 계속해서 이를 그 안에 저장하려고 합니다. MemoryLake는 이러한 결정을 의도적으로 기록하는 저장소로, 특정 에디터의 설정과 분리되어 있으며 연결하는 모든 어시스턴트에서 읽을 수 있습니다. 여러분은 자신의 언어로 직접 항목을 작성합니다. Cursor 시스템이나 다른 벤더의 저장소에서 데이터를 읽거나 쓰거나 삭제하지 않으므로, 여러분의 Rules, Skills 및 레포지토리는 완전히 자체 제어 하에 유지됩니다.

1단계: API 키 생성하기

대시보드에서 키를 생성합니다. 이 키를 통해 Cursor, 터미널 에이전트, 채팅 어시스턴트가 각각 추론의 복사본을 따로 보관하지 않고도 동일한 사실 정보에 접근할 수 있게 됩니다.

2단계: 첫 번째 memory 업로드하기

규칙 뒤에 숨겨진 결정사항부터 시작해 보세요. 어떤 접근 방식이 어떤 근거로 배제되었는지, 특정 컨벤션이 방지하려는 장애 사건은 무엇인지, 특정 서비스를 건드리기 전에 누구에게 물어봐야 하는지 등입니다. 규칙 파일은 지침을 전달할 뿐, 그 이유는 거의 담지 못합니다.

3단계: AI 및 에이전트 연결하기

도구가 설정 파일에서 추론하는 대신 세션 시작 시 이러한 사실 정보를 로드할 수 있도록 레이어를 가리키게 하세요. 그런 다음 실제로 검증할 수 있는 테스트를 실행해 보세요. 다른 어시스턴트에게 이전 결정 중 하나를 다시 물어보는 것입니다. 답변을 얻을 수 있다면, 여러분의 논거는 더 이상 특정 에디터의 파일 형식에 종속되지 않게 된 것입니다.

첫 번째 변화는 변환기를 안전하게 사용할 수 있게 된다는 점입니다. 무엇을 입력해야 할지 알기 때문입니다. 단계, 스크립트 또는 템플릿이 포함된 절차는 변환하고, 항상 적용되는 컨벤션은 그대로 둡니다.

두 번째는 프롬프트 크기가 작아진다는 점입니다. alwaysApply가 켜진 모든 항목은 매 세션마다 읽히지만, Skills로 이동된 절차는 필요할 때만 로드됩니다. 이것이 실제 기계적인 이점이며, 올바른 항목을 이동했을 때만 이 효과를 누릴 수 있습니다.

세 번째는 .mdc 요구 사항 때문에 더 이상 아까운 시간을 낭비하지 않게 된다는 점입니다. rules 디렉토리의 일반 .md 파일은 규칙 시스템에서 무시되며, Cursor는 이제 해결책과 동일한 문단에서 이를 명시하고 있습니다.

네 번째는 원격 및 클라우드 실행 시 예상치 못한 상황이 발생하지 않는다는 점입니다. 동기화되지 않은 로컬 스킬과 ~/.agents/skills/는 Cloud Agents, 원격 SSH 세션 또는 자체 호스팅 워커에 도달하지 않으므로, 클라우드 실행이 의존하는 모든 것은 레포지토리에 속해야 합니다.

다섯 번째는 이식성이 나중에 발견하는 사실이 아니라 여러분이 선택한 결과가 된다는 점입니다. Skills는 표준을 지원하는 모든 에이전트에서 작동하는 것으로 설명되어 있지만, Rules는 Cursor 전용 구조입니다. 여러분의 컨텍스트가 어떤 형식으로 되어 있는지 아는 것은 마이그레이션과 재작성의 차이를 만듭니다. 이는 다른 벤더가 반대편 관점에서 문서화한 문제이기도 합니다. 예를 들어 which Copilot instructions file gets read의 사례가 그렇습니다.

항상 적용되는 목록은 짧고 절대적인 내용으로 유지하세요. 매 세션마다 읽히기 때문에 모든 줄이 실제 작업과 토큰 경쟁을 벌이게 됩니다.

모든 description에 '무엇'뿐만 아니라 '언제'를 명시하세요. 양쪽 모두에서 description은 에이전트가 관련성을 판단하는 기준이 됩니다.

클라우드 실행에 필요한 skills는 레포지토리에 넣으세요. 프로젝트 수준의 스킬 디렉토리는 이동하지만, 동기화되지 않은 로컬 스킬은 로컬 컴퓨터에만 머무는 것으로 문서화되어 있습니다.

절차당 하나의 스킬을 자체 폴더에 구성하세요. 스킬의 정체성은 SKILL.md가 포함된 폴더에서 오며, 그 위의 카테고리 폴더는 정리용일 뿐입니다.

가능하면 glob 목록 대신 중첩 구조를 사용하세요. 패키지 디렉토리 내부의 스킬은 해당 디렉토리로 범위가 자동으로 지정됩니다.

확장자 규칙을 준수하세요. 프로젝트 규칙에는 .mdc를 사용하고, 일반 Markdown은 대신 AGENTS.md에 작성하세요.

논거는 다른 곳에 보관하세요. 자체 역사까지 담고 있는 규칙 파일은 짧게 유지될 수 없으며, 짧게 유지하는 것이 규칙을 제대로 작동하게 만드는 비결입니다.

Cursor는 두 메커니즘을 모두 명확하게 문서화하고 있지만, 단지 같은 페이지에 두지 않았을 뿐입니다. Rules는 모델 컨텍스트의 시작 부분에 포함되는 프롬프트 수준의 컨텍스트로, 네 가지 적용 모드가 있으며 프로젝트 규칙은 반드시 .mdc 확장자를 사용해야 한다는 엄격한 요구 사항이 있습니다. Skills는 스크립트, 템플릿 및 참조 자료를 포함할 수 있고 필요할 때 리소스를 로드하며 Agent Skills 표준을 지원하는 모든 에이전트에서 작동하는 이식 가능하고 버전 관리되는 패키지입니다.

분류 문제는 기능 비교가 시사하는 것보다 훨씬 간단합니다. 항상 참인 컨벤션은 관련성 판단을 거치지 않아야 하므로 항상 적용되는 규칙(always-apply rules)으로 남겨둡니다. 단계와 첨부 파일이 있는 절차는 온디맨드 로딩을 위해 설계된 형식이므로 Skills로 변환합니다. 파일 범위의 지침은 어느 쪽이든 될 수 있으며, 이식성이 합리적인 결정 기준이 됩니다.

메모지에 적어둘 만한 두 가지 경계선이 있습니다. .cursor/rules에 있는 일반 .md 파일은 규칙 시스템에서 무시된다는 점과, 동기화되지 않은 로컬 스킬은 Cloud Agents, 원격 SSH 세션 또는 자체 호스팅 워커에 도달하지 않는다는 점입니다.

그 다음, 두 형식 모두 지원하지 않는 한 단계를 실행해 보세요. 규칙 파일이나 스킬 패키지가 아닌 다른 곳에 각 컨벤션이 존재하는 이유를 기록하여, 다음에 규칙을 읽는 사람도 그 규칙이 왜 존재하는지 이유를 찾을 수 있도록 하십시오.