작업을 시작하기 전 활성화된 Cline 규칙을 매핑하는 방법 (2026년 가이드)

먼저 규칙으로 간주되는 항목이 얼마나 많은지부터 살펴보겠습니다. Cline의 문서는 "다른 도구의 기존 규칙 파일을 사용할 수 있도록" 다음과 같이 인식하는 네 가지 유형을 나열합니다:

.clinerules/, .cline/rules/에 있는 Cline Rules (공식 설명: "지원되는 작업 공간 규칙 디렉터리"); .cursorrules에 있는 Cursor Rules (공식 설명: "자동 감지됨"); .windsurfrules에 있는 Windsurf Rules (공식 설명: "자동 감지됨"); 그리고 AGENTS.md, ~/.agents/AGENTS.md에 있는 AGENTS.md (공식 설명: "도구 간 호환성을 위한 표준 포맷").

이는 대부분의 사람들이 생각하는 것보다 더 넓은 범위이며, 이전 도구에서 남겨진 .cursorrules가 비활성 상태로 방치되지 않는다는 것을 의미합니다. 네 가지 모두 동일한 위치로 모입니다: "감지된 모든 규칙 유형은 Rules 패널에 표시되며, 여기서 개별적으로 토글할 수 있습니다."

첫 번째 게이트가 바로 이 패널입니다. "모든 규칙에는 활성화 또는 비활성화할 수 있는 토글이 있습니다. 이를 통해 규칙 파일을 삭제하지 않고도 현재 작업에 적용할 규칙을 세밀하게 제어할 수 있습니다." 이 기능은 매우 유용합니다. 문서에서는 "프로토타이핑할 때 비활성화하고 싶은 엄격한 테스트 규칙이나, 특정 클라이언트의 기능을 작업할 때만 필요한 클라이언트 전용 규칙"을 예로 들고 있습니다. 하지만 그 대가로 3주 전에 꺼둔 규칙이 디스크 상에서는 현재 활성화된 규칙과 완전히 똑같이 보인다는 문제가 있습니다.

두 번째 게이트는 YAML front matter를 통한 조건부 활성화입니다. "Cline은 요청을 처리할 때 현재 작업(열려 있는 파일, 보이는 탭, 언급된 경로, 편집된 파일)에서 컨텍스트를 수집하고, 각 규칙의 조건을 평가하여 일치하는 규칙을 활성화합니다." 지원되는 조건은 단 하나로 문서화되어 있습니다: "현재 지원되는 조건은 paths입니다." 이는 glob 패턴의 배열을 인자로 받습니다.

이 조건과 관련된 세 가지 동작이 대부분의 실제 사례를 결정하며, 세 가지 모두 문서에 명시되어 있습니다. "frontmatter 없음: frontmatter가 없는 규칙은 항상 활성화됩니다." "빈 paths 배열: paths: []는 규칙이 절대 활성화되지 않음을 의미합니다. 규칙을 일시적으로 비활성화할 때 사용하세요." 그리고 "잘못된 YAML: frontmatter를 파싱할 수 없는 경우, Cline은 예외를 허용하여 열어둡니다(fails open). 디버깅을 돕기 위해 원본 콘텐츠가 보이는 상태로 규칙이 활성화됩니다."

마지막 동작이 중요한 단서입니다. 규칙의 원본 front matter가 Cline의 출력에 나타난다면 로드에 실패한 것이 아닙니다. YAML 파싱에 실패하여 디버깅 형태로 로드된 것입니다.

규칙을 더 강한 어조로 다시 작성하기. 모델에 도달조차 하지 않은 지침을 강조해 보았자 아무것도 바뀌지 않습니다. 오히려 나중에 실제로 규칙이 적용될 때 파일의 가독성만 떨어뜨립니다.

지원되는 두 디렉터리 모두에 규칙 복사하기. 불필요한 작업이며, 문서에서도 다음과 같이 밝히고 있습니다: "두 디렉터리가 모두 존재하면 둘 다 검색하므로 규칙을 두 위치 모두에 복사할 필요가 없습니다." 또한 새 파일이 생성되는 위치도 명시하고 있습니다: "VS Code Rules 패널은 여전히 .clinerules/에 새로운 작업 공간 규칙을 생성합니다."

"항상 적용되도록" front matter 삭제하기. 이 방법은 실제로 작동하며 문서에 명시된 동작이기도 합니다. 하지만 이를 광범위하게 적용하면 조건문이 존재해야 하는 이유인 원래의 문제를 다시 야기하게 됩니다. 문서에서는 그 비용에 대해 직접적으로 경고합니다: "규칙 라이브러리가 커짐에 따라 모든 요청에 대해 모든 규칙을 로드하면 컨텍스트 토큰이 낭비되고 Cline의 집중도가 흐려질 수 있습니다."

파일 이름을 지정하는 대신 줄글로 설명하기. 문서에는 사람들이 실제로 이런 행동을 하는 것을 보고 작성된 듯한 팁이 있습니다: "프롬프트에서 파일 경로를 명확히 지정하세요. 'src/services/user.ts 업데이트해줘'는 경로 기반 규칙을 확실하게 트리거하지만, '유저 서비스 업데이트해줘'는 트리거하지 못할 수 있습니다."

메모리 문제라고 가정하기. 실제로 메모리 문제일 때도 있습니다. 규칙이 올바르게 적용되었음에도 Cline이 프로젝트의 사실 관계를 계속 다시 추론하고 있다면, 이는 다른 종류의 실패이며 how to set up a Cline memory bank의 영역에 가깝습니다. 하지만 규칙이 아예 실행되지 않는다면 이는 활성화 문제이며, 해결책은 패널과 front matter에 있습니다.

다른 에디터와 동일한 오류라고 가정하기. 증상은 비슷할지 몰라도 메커니즘은 다릅니다. 다른 도구가 세션 중간에 프로젝트 규칙을 놓치는 경우, 이는 대개 두 개의 게이트로 이루어진 활성화 모델보다는 스코프와 세션 상태의 문제인 경우가 많습니다. 자세한 내용은 why Cursor forgets project rules를 참고하세요.

1단계: 내가 작성하지 않은 파일을 포함하여 Cline이 규칙으로 간주하는 모든 파일 나열하기

Rules 패널을 열고 설정 화면이 아닌 인벤토리 목록으로 읽어보세요. 감지된 모든 유형이 여기에 표시되므로, 오래된 .cursorrules나 .windsurfrules가 여전히 모델에 제공되고 있는지 이 패널을 통해 확인할 수 있습니다.

그런 다음 디스크 상의 두 작업 공간 위치인 .clinerules/와 .cline/rules/를 모두 확인하세요. "두 레이아웃 모두 VS Code, 데스크톱 및 CLI에서 지원"되기 때문에 동료가 내가 열어보지 않은 디렉터리를 사용했을 수도 있습니다. 글로벌 레이어도 추가하세요. 글로벌 규칙은 시스템의 Cline Rules 디렉터리에 위치하며, 문서에서는 "Cline은 ~/.agents/AGENTS.md에서 도구 간 글로벌 AGENTS 지침도 읽습니다"라고 명시하고 있습니다.

목록의 각 파일에 대해 두 가지를 기록하세요: 토글이 켜져 있는지 여부와 front matter가 있는지 여부입니다. 이 두 가지 정보가 바로 지도 역할을 합니다. 토글이 켜져 있고 front matter가 없는 파일은 항상 활성화됩니다. 토글이 꺼져 있는 파일은 front matter의 내용과 상관없이 비활성 상태입니다. "조건부 규칙을 완전히 비활성화하려면 토글을 끄십시오(경로가 일치하더라도 활성화되지 않음)."

이 작업을 수행하는 동안 구조적 권장 사항도 적용해 보세요. 지도를 유지 관리하기가 훨씬 쉬워집니다: "파일당 하나의 관심사만 다루세요. 규칙을 주제별로 나누십시오: 스타일을 위한 coding.md, 테스트 요구 사항을 위한 testing.md, 구조적 결정을 위한 architecture.md. 이렇게 하면 특정 규칙을 쉽게 켜고 끌 수 있습니다." 하나의 거대한 규칙 파일은 서로 무관한 6가지 관심사에 대해 단 하나의 토글만 제공할 뿐입니다.

2단계: Cline이 실제로 평가하는 컨텍스트와 비교하여 glob 패턴 분석하기

패턴은 문제의 절반에 불과합니다. 나머지 절반은 Cline이 이를 무엇과 비교하는가입니다. 문서화된 컨텍스트에는 다섯 가지 입력이 있습니다: "사용자 메시지: 프롬프트에 언급된 파일 경로", "열려 있는 탭: 현재 에디터에 열려 있는 파일", "보이는 파일: 활성화된 에디터 창에 보이는 파일", "편집된 파일: 작업 중 Cline이 생성, 수정 또는 삭제한 파일", 그리고 "대기 중인 작업: Cline이 편집하려는 파일"입니다.

이로 인해 두 가지 결과가 따릅니다. 첫째, 활성화 타이밍이 고정되어 있지 않습니다: "조건부 규칙은 첫 번째 메시지에서 활성화되거나, 관련 파일이 열려 있을 때, 또는 Cline이 일치하는 파일로 작업을 시작하는 작업 중간에 활성화될 수 있습니다." 시작할 때는 없었던 것처럼 보였던 규칙이 나중에 적용되었을 수 있습니다. 둘째, 다른 창에 관련 없는 파일이 우연히 열려 있어 의도하지 않은 이유로 규칙이 실행될 수 있습니다.

이제 문서화된 구문을 바탕으로 glob 패턴 자체를 읽어보세요. *는 "/를 제외한 모든 문자 일치", **는 "/를 포함한 모든 문자 일치(재귀적)", ?는 "단일 문자 일치", [abc]는 "대괄호 안의 모든 문자 일치", {a,b}는 "두 패턴 중 하나 일치"를 의미합니다. 다음 예시들을 숙지해 두는 것이 좋습니다: src/**/*.ts는 "src/ 하위의 모든 TypeScript 파일", *.md는 "루트 디렉터리의 Markdown 파일만", **/*.test.ts는 "프로젝트 내 모든 위치의 테스트 파일", src/components/*.tsx는 "components 폴더 바로 아래에 있는 TSX 파일(중첩되지 않음)"을 의미합니다.

결합 규칙은 꽤 관대합니다: "컨텍스트의 파일 중 하나라도 패턴과 일치하면 규칙이 활성화됩니다." 이 때문에 좁은 패턴이 누락되는 것보다 너무 넓은 패턴이 잘못 실행되는 경우가 더 자주 발생합니다. 이는 공식 문서의 문제 해결 노트에서도 지적하는 트레이드오프입니다. 문서에서는 "규칙이 예기치 않게 활성화됨"의 원인으로 "**는 재귀적이므로 의도한 것보다 더 많이 일치할 수 있음"과 열려 있는 파일이 패턴과 일치하는 상황을 꼽고 있습니다.

3단계: 일회용 테스트 규칙으로 검증하고 알림 확인하기

이것이 작동할 때 Cline은 하나의 신호를 보냅니다. 이를 알고 있으면 추측을 확실한 검증으로 바꿀 수 있습니다. 조건부 규칙이 활성화되면 문서에 따르면 'Conditional rules applied: workspace:frontend-rules.md'라는 알림이 표시됩니다.

이를 활용하는 문서화된 방법은 일회용 규칙을 만드는 것입니다. .clinerules/에 확실하지 않은 paths 패턴만 front matter로 가지고, 본문은 명확한 한 줄로 구성된 작은 파일을 만듭니다. 문서에서는 "TEST: This rule should activate for your/pattern/here files."와 같은 내용을 제안합니다. 그런 다음 "해당 경로의 파일로 작업을 진행하면서 활성화 알림이 표시되는지 확인"합니다.

알림이 나타나지 않는 경우, 문제 해결 단계는 다음과 같이 짧고 순서가 정해져 있습니다: "컨텍스트의 파일 경로가 glob 패턴과 일치하는지 확인", "Rules 패널에서 규칙이 켜져 있는지 확인", "YAML frontmatter에 올바른 --- 구분 기호가 있는지 확인". 이 순서대로 실행하세요. 첫 번째가 가장 흔한 원인이고, 세 번째는 가장 이상한 증상을 유발하는 원인이기 때문입니다. 파싱할 수 없는 front matter는 원본 콘텐츠가 보이는 상태로 예외적으로 활성화된다는 점을 기억하세요.

문서에서는 패턴을 추측하는 대신 빌드하는 방식으로 "넓게 시작해서 좁혀가기(Start Broad, Then Narrow)"를 제안합니다. 예를 들어 src/**로 시작해서 무엇이 일치하는지 확인한 후 src/features/auth/**로 구체화하는 식입니다. 파일을 직접 작성하고 싶지 않다면, "Cline이 대화식으로 규칙을 생성하도록" 하는 /newrule 슬래시 명령어를 사용할 수도 있습니다.

규칙은 지침입니다. 여기서 코드를 작성하는 방법, 피해야 할 사항, 준수해야 할 규칙 등이 이에 해당합니다. 하지만 규칙은 규칙이 내포하고 있는 또 다른 요소, 즉 그 뒤에 숨겨진 결정과 이유를 담기에는 적합하지 않습니다. 이러한 배경 정보는 모든 작업에 로드되기보다는 규칙이 여전히 유효한지 결정할 때 검색할 수 있어야 합니다. MemoryLake에 의도적으로 항목을 기록해 두는 저장소를 사용하면 이 두 가지를 분리하여 관리할 수 있으므로, glob 패턴을 좁히더라도 규칙 뒤에 숨겨진 추론 과정을 잃어버리지 않습니다. 항목은 본인의 언어로 직접 작성합니다. 규칙 파일이나 Cline의 설정에서 아무것도 읽거나 쓰거나 삭제하지 않습니다.

1단계: API 키 생성하기

로그인한 후 워크스페이스 설정에서 API 키를 생성합니다. 이 키는 에이전트와 연동 기능이 사용하는 인증 정보이므로, 데이터를 이동하기 전에 먼저 생성해 두세요.

2단계: 첫 번째 메모리 업로드하기

규칙 파일에서 누락된 "이유"부터 시작해 보세요: 레거시 디렉터리가 금지된 이유, 어떤 규칙이 언제 어떤 규칙으로 대체되었는지, 제약 조건이 무엇을 보호하고 있는지 등입니다. 각 항목을 독립적인 짧은 노트로 작성하여 개별적으로 검색할 수 있도록 하세요.

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

사용 중인 어시스턴트와 에이전트를 연결하세요. 그러면 특정 에디터가 어떤 규칙 디렉터리를 읽는지와 상관없이, 추론 과정이 도구를 초월하여 함께 이동합니다.

디버깅에 명확한 순서가 생깁니다. 규칙을 다시 작성하는 대신 토글을 확인하고, front matter를 확인하고, 다섯 가지 컨텍스트 입력과 비교하여 glob 패턴을 확인한 다음, 테스트 규칙을 실행하고 알림을 확인합니다. 문서에 답이 나와 있는 네 가지 확인 단계만 거치면 됩니다.

오래된 도구 파일의 처리가 우연이 아닌 명확한 결정으로 바뀝니다. 남겨진 .cursorrules가 감지되어 제안되므로, 이를 의도적으로 규칙 세트에 포함할지 아니면 삭제할지 결정해야 합니다. 이는 how to migrate Cursor rules to Claude Code에서 다루는 것처럼 도구 간에 규칙을 마이그레이션할 때 방향성을 더 명확하게 해줍니다.

프롬프트 표현 방식이 설정의 일부가 됩니다. 메시지에 언급된 경로가 컨텍스트로 간주되므로, 변경하려는 파일 이름을 명시하는 것은 꼼꼼함의 문제가 아니라 문서의 팁에 따른 가장 확실한 트리거 방법입니다.

규칙 라이브러리가 무작정 늘어나는 것을 방지합니다. 어떤 규칙이 항상 켜져 있는지 파악하고 나면, 항상 켜져 있는 규칙 레이어는 물려받은 짐이 아니라 관리해야 할 예산이 됩니다. 이는 how to consolidate Kilo Code rule files에서 논의된 것처럼 사람들이 흩어진 규칙 파일을 통합하려는 이유와 동일한 맥락입니다.

그리고 반복되는 불만 사항을 재진단할 수 있게 됩니다. "또 우리 스타일을 잊어버렸어"라는 문제는 메모리 문제가 아니라 알려진 원인이 있는 활성화 문제일 수 있습니다. 무언가를 변경하기 전에 이 차이를 구별하는 것이 중요하며, 이는 why Cline forgets your coding style에서 해결책을 도출하는 기반이 됩니다.

항상 켜져 있는 파일을 하나 유지하고 그에 걸맞은 이름을 지정하세요. 문서의 예시 레이아웃은 "No frontmatter = always active"라는 주석이 달린 universal.md로 끝납니다. 동작에 따라 이름을 지정한 파일은 다음 사람에게 그것이 무엇인지 명확히 알려줍니다.

의도한 트리거를 규칙 본문에 명시하세요. 상단에 "src/components에 대해 활성화될 것으로 예상됨"이라는 한 줄을 적어두면, 향후 오작동이 발생했을 때 복잡한 조사 대신 2초 만에 비교하여 파악할 수 있습니다.

하나의 넓은 범위의 파일보다 여러 개의 좁은 범위의 파일을 선호하여 토글을 정밀한 도구로 활용하세요. 이것이 바로 "파일당 하나의 관심사" 원칙이 주는 실질적인 이점입니다.

리팩터링 후에는 테스트 규칙을 다시 실행하세요. 디렉터리를 이동하면 glob 패턴이 일치하는 대상이 변경되며, 툴체인의 그 어떤 도구도 패턴 일치가 중단되었음을 알려주지 않습니다.

도구 간 공유 파일은 항상 켜져 있는 것으로 취급하세요. 루트의 AGENTS.md나 ~/.agents/AGENTS.md는 규칙 소스로 감지되며, 공유 파일은 도구별로 게이트가 지정되지 않기 때문에 공유되는 것입니다. 어떤 설정을 선택하든, 규칙에 무엇이 포함되어야 하는지에 대한 더 넓은 질문은 주기적으로 재검토할 가치가 있으며, 이는 the best memory setups for Cline에서 다루는 내용입니다.

Cline 규칙은 토글이 켜져 있고 조건이 일치하는 경우에만 모델에 도달합니다. 두 게이트 모두 닫힐 때 아무런 알림을 주지 않으며, 네 가지 다른 파일 유형이 동일한 패널에 제공되므로 무시되고 있는 규칙이 항상 내가 보고 있던 규칙은 아닐 수 있습니다.

지도를 한 번 만들어 보세요: 상속된 규칙을 포함한 모든 규칙 소스, 각각의 토글 상태, 각각의 front matter, 그리고 문서화된 다섯 가지 컨텍스트 입력과 비교하여 읽은 glob 패턴을 정리하는 것입니다. 그런 다음 일회용 테스트 규칙을 유지하세요. 활성화 알림은 시스템에서 유일하게 확인할 수 있는 긍정적인 신호이기 때문입니다. 다시 실행할 수 있는 확실한 검증 방법이 규칙을 다시 작성하고 잘 작동하기를 바라는 것보다 훨씬 낫습니다.