에이전트 스킬과 커서 규칙 비교

규칙을 넣었는데도 어떤 작업에서는 적용되고 어떤 작업에서는 무시되어 파일을 두 곳에 복사하고 있습니까?

가장 빠른 해법은 지속적으로 지켜야 하는 코드 규범은 커서 규칙에 두고, 특정 작업에서만 실행할 절차와 자료는 에이전트 스킬에 두는 것입니다. 두 도구를 함께 쓴다면 같은 문장을 반복 저장하지 말고, 규칙은 장기 제약으로, 스킬은 조건부 작업 흐름으로 분리해야 합니다.

이 글은 커서 규칙을 에이전트 스킬로 옮기려는 개발자, 커서와 클로드 코드를 함께 쓰는 팀, 프로젝트 지침과 자동화 권한을 관리하는 플랫폼 엔지니어를 대상으로 합니다.

마지막 업데이트: 2026년 8월 12일. 경로와 로딩 방식은 커서 공식 규칙 문서, 클로드 코드 공식 스킬 문서, 에이전트 스킬 공개 규격을 기준으로 확인했습니다.

먼저 비교 기준을 고정해야 합니다

에이전트 스킬과 커서 규칙을 단순히 “둘 다 마크다운 파일”이라고 보면 선택이 틀어집니다. 실제 차이는 파일 확장자가 아니라 다음 다섯 가지 지표에서 생깁니다.

커서의 프로젝트 규칙은 .cursor/rules에 저장하고 버전 관리할 수 있습니다. 규칙 유형은 항상 포함, 경로 기반 자동 연결, 에이전트 요청, 수동 적용으로 나뉩니다. 중첩된 규칙 디렉터리는 해당 경로의 파일을 다룰 때 자동으로 연결됩니다. (커서 공식 규칙 문서)

에이전트 스킬은 폴더 안에 SKILL.md를 두는 구조입니다. 공개 규격에는 이름과 설명이 필수이며, 선택적으로 스크립트, 참고 문서, 서식 파일과 자산을 함께 넣을 수 있습니다. 설명 정보는 시작 시 확인되고, 본문은 작업이 활성화된 뒤 읽히는 단계적 공개 방식입니다. (에이전트 스킬 공개 규격)

첫 번째 단계: 로딩 시점을 기준으로 나눕니다

지속적으로 적용해야 하는 내용은 규칙으로 관리하는 편이 안정적입니다. 예를 들어 다음 항목은 거의 모든 코드 생성과 수정에 영향을 줍니다.

• 오류 처리와 로그 기록 방식
• 계층 간 호출 금지 조건
• 시험 파일의 위치와 실행 명령
• 승인 없이 변경하면 안 되는 디렉터리
• 프로젝트에서 사용하는 언어와 형식 규칙

반대로 다음 항목은 에이전트 스킬에 넣는 편이 적합합니다.

• 변경 사항을 분석하고 검토 보고서를 작성하는 절차
• 배포 전 시험, 정적 분석, 문서 갱신을 순서대로 실행하는 작업
• 특정 서식이나 참고 문서를 읽고 결과물을 만드는 과정
• 반복적으로 실행할 수 있는 검사 스크립트가 포함된 업무

에이전트 스킬은 처음부터 이름과 설명만 노출한 뒤, 조건이 맞으면 본문을 읽고, 필요할 때 스크립트와 참고 자료를 불러오는 구조를 전제로 합니다. 공개 구현 안내는 이 과정을 세 단계로 설명하며, 카탈로그 정보는 스킬마다 약 50~100토큰, 본문은 5,000토큰 이하를 권장합니다. (스킬 지원 구현 안내)

이 차이는 문맥 비용과 행동 안정성에 직접 영향을 줍니다. 모든 작업에 긴 배포 절차를 규칙으로 주입하면 응답마다 불필요한 지침이 따라붙습니다. 반대로 핵심 아키텍처 제약을 스킬로만 두면 에이전트가 해당 스킬을 활성화하지 않은 순간 규범을 놓칠 수 있습니다.

두 번째 단계: 내용의 크기보다 책임을 나눕니다

커서 규칙도 파일 참조를 통해 템플릿이나 추가 내용을 연결할 수 있습니다. 하지만 규칙의 중심은 모델이 항상 참고할 프로젝트 문맥과 행동 지침입니다. 규칙 하나에 모든 배포 명령, 시험 절차, 예외 사례를 넣으면 적용 범위가 넓어지고 수정 영향도 함께 커집니다.

에이전트 스킬은 절차를 묶는 구조를 전제로 합니다. 공개 규격은 SKILL.md 아래에 scripts, references, assets 같은 선택 디렉터리를 둘 수 있다고 설명합니다. 본문에 모든 자료를 복사하는 대신 필요한 참고 파일을 분리할 수 있다는 점이 핵심입니다. 스킬 설명 필드는 최대 1,024자이며, 이름은 64자 이내의 소문자와 숫자, 하이픈으로 구성해야 합니다. (에이전트 스킬 공개 규격)

따라서 “규칙에 넣을까, 스킬에 넣을까”를 파일 형식으로 판단하지 말고 실패 비용으로 판단해야 합니다.

• 빠지면 모든 코드가 잘못되는 지침이면 규칙입니다.
• 빠져도 다른 작업에는 영향이 없고 특정 업무만 실패한다면 스킬입니다.
• 실행 명령, 서식, 참고 문서가 함께 움직이면 스킬입니다.
• 경로별 예외가 많고 파일을 열 때마다 달라진다면 커서의 경로 규칙을 먼저 검토합니다.

세 번째 단계: 프로젝트 경로와 팀 공유 방식을 확인합니다

커서는 프로젝트 전체 규칙을 .cursor/rules에 두고, 하위 디렉터리에도 별도 규칙 디렉터리를 둘 수 있습니다. 사용자 규칙은 개인 환경에 전역 적용되므로 팀 저장소에 넣을 프로젝트 지침과 분리해야 합니다. 이전 방식인 .cursorrules는 계속 지원되지만 공식 문서는 프로젝트 규칙 형식으로 옮길 것을 안내합니다. (커서 공식 규칙 문서)

클로드 코드의 프로젝트 스킬은 시작 위치와 상위 경로의 .claude/skills를 탐색하고, 작업 대상의 하위 디렉터리에서도 스킬을 찾을 수 있습니다. 개인 스킬은 ~/.claude/skills에 둘 수 있습니다. 이 경로는 커서의 .cursor/rules와 이름도 우선순위도 같지 않으므로, 두 도구의 파일을 같은 위치에 복사하는 방식은 피해야 합니다.

공식 문서에 없는 우선순위를 임의로 만들면 안 됩니다. 특히 여러 스킬의 이름 충돌, 같은 경로의 규칙 충돌, 클라이언트별 확장 필드 처리는 구현마다 다를 수 있으므로 최소 예제 저장소에서 직접 확인해야 합니다.

네 번째 단계: 호환성을 “무손실 이전”으로 약속하지 않습니다

에이전트 스킬 표준은 name, description 같은 공개 필드와 폴더 구조를 정의합니다. 그러나 allowed-tools처럼 구현에 따라 지원이 달라질 수 있는 항목도 있습니다. 공개 규격 자체도 해당 필드의 지원 범위가 에이전트마다 다를 수 있다고 명시합니다. (에이전트 스킬 공개 규격)

커서 규칙은 자체적인 형식과 적용 유형을 사용합니다. 따라서 커서 규칙의 본문을 SKILL.md로 옮긴다고 해서 자동 연결, 수동 호출, 경로 범위, 참조 파일 동작이 그대로 보장되지는 않습니다. 반대로 스킬 폴더를 커서 규칙으로 복사하면 스크립트 실행과 단계적 로딩을 잃을 수 있습니다.

이전할 때는 다음 순서가 안전합니다.

1. 원본 규칙에서 장기 제약과 작업 절차를 분리합니다.
2. 장기 제약만 커서 규칙으로 남깁니다.
3. 절차, 명령, 참고 자료를 스킬 폴더로 구성합니다.
4. 클라이언트 전용 필드를 별도 문서로 표시합니다.
5. 두 도구에서 같은 입력으로 결과를 비교합니다.
6. 실행 권한이 필요한 명령은 승인 절차를 추가합니다.
7. 이전 뒤에는 원본과 복사본의 책임 범위를 다시 검토합니다.

다섯 번째 단계: 충돌과 권한을 검사합니다

규칙과 스킬을 함께 사용할 때 가장 흔한 문제는 같은 내용을 서로 다른 표현으로 반복하는 것입니다. 예를 들어 규칙에는 “시험을 먼저 실행한다”고 쓰고, 스킬에는 “변경 후 바로 배포한다”고 쓰면 모델이 어느 지침을 우선해야 하는지 불명확해집니다.

또 다른 문제는 스킬이 단순 문서가 아니라 실행 파일을 포함할 수 있다는 점입니다. 공개 규격은 스크립트와 참고 자료를 스킬 폴더에 둘 수 있다고 설명하므로, 외부에서 받은 스킬은 코드 검토와 실행 권한 검사를 거쳐야 합니다. (스크립트 사용 안내)

주의: 스킬 설명은 자동 활성화 조건에 영향을 줍니다. 설명을 지나치게 넓게 쓰면 관련 없는 작업에서도 스킬이 켜지고, 너무 좁게 쓰면 필요한 작업에서 활성화되지 않습니다.

다음 점검표를 저장소 병합 요청에 포함하면 관리 책임이 분명해집니다.

• [ ] 규칙에는 장기적으로 변하지 않는 제약만 남겼습니다.
• [ ] 스킬에는 실행 순서와 완료 조건을 적었습니다.
• [ ] 같은 정책 문장을 두 파일에 복사하지 않았습니다.
• [ ] 스킬에 포함된 명령과 스크립트를 사람이 검토했습니다.
• [ ] 외부 자료와 서식 파일의 출처를 기록했습니다.
• [ ] 자동 활성화 조건을 대표 작업과 비대표 작업으로 나누어 시험했습니다.
• [ ] 규칙과 스킬을 동시에 적용했을 때 충돌 결과를 기록했습니다.
• [ ] 책임자와 다음 검토 날짜를 저장소 문서에 남겼습니다.
• [ ] 도구 업데이트 뒤 경로와 적용 범위를 다시 확인했습니다.

선택 결과를 빠르게 결정하는 기준

다음과 같이 고르면 대부분의 혼합 팀에서 초기 구조를 안정적으로 만들 수 있습니다.

기본 조합은 간단합니다. 커서 규칙에는 “무엇을 반드시 지켜야 하는가”를 쓰고, 에이전트 스킬에는 “특정 요청이 들어왔을 때 어떤 순서로 수행할 것인가”를 씁니다. 이렇게 나누면 한쪽의 정책을 수정할 때 다른 쪽까지 다시 고치는 비용이 줄어듭니다.

혼합 개발 환경을 실제로 검증하는 방법

혼합 팀이라면 새 규칙을 바로 전체 저장소에 배포하지 말고 최소 예제 저장소에서 검증해야 합니다.

1. 작은 프로젝트를 만들고 대표 코드 파일과 시험 파일을 넣습니다.
2. 커서의 전역 규칙, 프로젝트 규칙, 중첩 규칙을 각각 하나씩 추가합니다.
3. 클로드 코드용 프로젝트 스킬에 SKILL.md와 간단한 검사 스크립트를 넣습니다.
4. 같은 요청을 규칙만, 스킬만, 두 가지 동시 적용 상태에서 실행합니다.
5. 적용된 지침, 수정된 파일, 실행된 명령, 실패 이유를 로그로 남깁니다.
6. 경로를 프로젝트 하위 디렉터리로 바꾸어 중첩 적용 결과를 확인합니다.
7. 도구 버전을 바꾼 뒤 같은 시험을 반복하고 변경 사항을 기록합니다.

이 과정에서 “작동했다”만 기록하면 부족합니다. 어떤 파일이 언제 읽혔는지, 스킬이 자동으로 켜졌는지, 규칙이 중복 적용되었는지, 명령 실행 전에 승인을 요구했는지를 함께 남겨야 재현 가능한 팀 표준이 됩니다.

현재 로컬 개발 환경에서 이 검증을 반복하기 어렵다면 ZavCloud 도움말 센터에서 원격 개발 환경과 운영 절차를 먼저 확인하는 것도 방법입니다. 여러 도구의 설정을 분리한 뒤 같은 저장소를 검증하려면 맥 미니 렌탈 환경처럼 독립된 테스트 공간을 사용하는 편이 편리합니다.

결국 로컬 노트북 하나에 커서, 클로드 코드, 여러 버전의 런타임을 모두 얹어 운영하면 환경별 권한 차이, 도구 업데이트에 따른 동작 변화, 팀원마다 다른 경로 설정이 반복됩니다. 특히 규칙과 스킬의 충돌을 재현하려면 깨끗한 실행 환경과 고정된 프로젝트 상태가 필요합니다. 장기간 같은 무거운 작업을 고정해서 돌리거나 물리 장비와 직접 연결해야 한다면 직접 장비를 운영하는 편이 맞지만, 여러 AI 코딩 도구를 시험하거나 단기간에 원격 개발 환경을 분리해야 한다면 ZavCloud의 맥 환경을 빌려 검증하는 쪽이 설정을 되돌리고 팀별 구성을 비교하기 쉽습니다.