만약 같은 저장소에서 Cursor와 Claude Code를 모두 사용한다면, 두 도구 모두 영속적인 지침(persistent instructions)을 위한 rules/ 디렉터리를 지원한다는 것을 아마 알아차렸을 것입니다. 당연한 해결책은 이들을 하나의 디렉터리로 만들고 심볼릭 링크를 걸게 하는 것이지만, 그렇게 하지 마세요. 두 형식은 호환되는 것처럼 보이기에 충분히 겹치면서도, 조용히 실패하기에는 충분히 다릅니다. 본 게시물에서는 정확한 비호환성을 살펴보고, 단일 진실 공급원(single source of truth)으로부터 두 형식을 동기화하는 작은 코드 생성기를 소개합니다.

두 가지 규칙 시스템

두 도구 모두 프로젝트 디렉터리에 YAML 프론트매터가 있는 마크다운 파일을 넣을 수 있게 합니다. 지침은 항상 적용되거나 파일 글로브(file globs)에 한정하여 적용됩니다.

Cursor — .cursor/rules/*.mdc:

---
description: "TS/JS 변경 후 ESLint 실행"
globs: extensions/app/**/*.{ts,tsx,js}
...

Cursor는 규칙의 _유형(type)_을 세 가지 필드의 조합으로부터 파생합니다:

alwaysApply	description	globs	유형
true	—	—	항상 적용 (Always)
...
Claude Code — .claude/rules/*.md:

---
description: Run ESLint after changing TS/JS
paths:
...

Claude Code의 모델은 더 간단합니다. paths: 목록이 있는 규칙은 Claude가 일치하는 파일을 읽을 때만 로드되고, paths:가 없는 규칙은 모든 세션에서 무조건 로드됩니다 (.claude/CLAUDE.md와 동일한 우선순위).

• Cursor: 쉼표로 구분된 문자열 형태의 globs:와 alwaysApply:를 사용합니다.
• Claude Code: paths:를 YAML 리스트 형태로 사용하며, alwaysApply 옵션이 없습니다.

만약 Claude Code가 Cursor 형식의 파일을 가리키고 있고 해당 파일에 paths: 키가 없다면, 모든 규칙을 항상 활성화된 것으로 간주합니다. 따라서 신중하게 범위를 지정한 API 규칙도 매 세션마다 로드됩니다. 이 실패는 파일이 실제로 읽히기 때문에 눈에 띄지 않습니다. 단지 잘못된 스키마로 해석되고 있을 뿐입니다.

이것이 전체 실험을 하게 만든 함정입니다. 저는 .cursor/rules -> ../.claude/rules와 같이 연결하고, 파일을 Claude Code 형식으로

– 수동으로 작성한 YAML 파서도 괜찮습니다. 왜냐하면 구조가 고정되어 있기 때문입니다. 이러한 프런트매터(frontmatter) 블록은 매우 작고 사용자가 제어할 수 있습니다. 각 파일마다 두 개의 키만 있는 다섯 개의 파일을 위해 YAML 의존성을 가져오지는 마십시오. 하지만 파서가 어떤 것을 지원하는지 (스칼라 description, 리스트 paths) 그리고 그 이상은 아니라는 점에 대해서는 정직하게 유지해야 합니다.
– alwaysApply: false와 globs가 없는 것은 Claude Code에서 동등한 것이 없습니다. Cursor의