모든 Windsurf 규칙에 맞는 트리거 모드 선택하는 방법 (2026년 가이드)

Windsurf는 그 메커니즘을 한 문장으로 설명합니다. "각 워크스페이스 규칙은 frontmatter의 trigger 필드를 통해 활성화 모드를 선언합니다. 이는 규칙의 콘텐츠가 언제 Cascade에 제공되는지, 그리고 컨텍스트 창을 얼마나 소비하는지 제어합니다."

하나의 필드가 두 가지를 결정합니다. 규칙이 에이전트에 전달되는지 여부와 그에 따른 비용입니다. 문서에 명시된 옵션은 다음과 같습니다.

always_on — "모든 메시지에서 전체 규칙 콘텐츠가 시스템 프롬프트에 포함됩니다." 비용: 모든 메시지.

model_decision — "시스템 프롬프트에는 설명(description)만 표시됩니다. Cascade는 설명이 관련이 있다고 판단할 때 전체 규칙 파일을 읽습니다." 비용: 설명은 항상 포함, 전체 콘텐츠는 필요할 때만 로드.

glob — "Cascade가 globs 패턴과 일치하는 파일을 읽거나 편집할 때 규칙이 적용됩니다." 비용: 일치하는 파일을 다룰 때만 발생.

manual — "규칙이 시스템 프롬프트에 포함되지 않습니다. Cascade 입력창에 @rule-name을 입력하여 활성화합니다." 비용: @언급할 때만 발생.

이 비용들을 단계별 사다리로 이해해 보세요. always_on에서 model_decision으로 전환하면 메시지당 고정 비용이 설명 크기만큼의 비용으로 줄어들고, 본문은 필요할 때만 로드됩니다. glob으로 전환하면 비용은 사용자가 다루는 파일에 따라 조건부로 발생합니다. manual로 전환하면 사용자가 직접 요청할 때만 비용이 발생합니다.

이제 이 모든 과정을 재정의하는 부분이 나옵니다.

"글로벌 규칙 파일(global_rules.md)과 루트 레벨의 AGENTS.md 파일은 frontmatter를 사용하지 않으며, 항상 켜져 있습니다(always on)."

이 두 영역에는 모드가 없습니다. 구조적으로 항상 켜져 있습니다. 따라서 무언가를 최적화하기 전에 이미 예산의 일부가 고정되어 있는 셈이며, 제한 사항을 통해 그 양을 알 수 있습니다. 글로벌 파일은 ~/.codeium/windsurf/memories/global_rules.md에 위치하며 모든 워크스페이스에 적용되고 "6,000자로 제한"됩니다. 워크스페이스 규칙은 .devin/rules/(권장) 또는 .windsurf/rules/(대체)에 파일당 하나씩 위치하며 "파일당 12,000자로 제한"됩니다.

그리고 사람들이 잊고 있는 세 번째 '항상 켜져 있는' 영역이 있습니다. "워크스페이스 루트에 있는 레거시 단일 파일 .windsurfrules도 여전히 읽힙니다." 수년 전에 규칙 디렉토리로 마이그레이션하고 이 파일을 삭제하지 않았다면, 이 파일은 여전히 로드되고 있는 것입니다.

AGENTS.md는 frontmatter가 아닌 위치에 따라 모드가 할당됩니다. "루트 레벨 = always-on, 하위 디렉토리 = 해당 디렉토리에 대한 auto-glob." 이는 정말 우아한 기본 설정이지만, 파일을 한 단계 상위 디렉토리로 이동하는 것만으로도 비용이 조건부에서 영구적으로 조용히 바뀐다는 것을 의미합니다.

규칙이 존재하지만 예상대로 작동하지 않는 이 문제의 일반적인 형태는 에이전트가 지침 파일을 무시하는 이유에서 다루고 있습니다.

모든 것을 always_on으로 설정하기. 가장 안전하게 느껴집니다. 규칙이 확실히 적용되기 때문입니다. 하지만 프론트엔드 작업만 하는 세션 동안 Terraform 컨벤션에 메시지당 예산을 낭비하게 되며, 긴 대화가 이어질수록 비용이 누적됩니다. 이로 인해 발생하는 증상은 Windsurf 에이전트가 컨텍스트를 잃을 때에서 설명한 컨텍스트 이탈 현상입니다.

모드를 바꾸는 대신 규칙을 더 짧게 작성하기. 도움이 될 수는 있지만, 잘못된 변수를 해결하려는 것입니다. 모든 메시지에 로드되는 400자짜리 규칙은 두 번만 로드되는 3,000자짜리 규칙보다 세션 전체에서 더 많은 비용이 듭니다. 간결함과 활성화는 독립적인 레버이며, 두 번째 레버가 훨씬 더 강력합니다. 간결함에만 의존하는 접근 방식의 한계는 짧은 프롬프트만으로는 충분하지 않은 이유에서 다루고 있습니다.

대신 자동 생성된 메모리(memories)에 의존하기. Windsurf 자체 문서에서도 이를 권장하지 않습니다. "Cascade가 안정적으로 재사용하기를 원하는 지식은 자동 생성된 Memories에 의존하기보다 규칙(Rule)으로 작성하거나 리포지토리의 AGENTS.md에 추가하세요. 규칙은 버전 관리가 가능하고 팀과 공유할 수 있으며, 활성화를 명시적으로 제어할 수 있습니다." 비교 표에서도 메모리의 역할을 명확히 규정합니다. "일회성 사실은 Cascade가 기억하도록 두고, 지속적인 지식은 규칙이나 AGENTS.md를 선호하세요." 또한 현재 문서에 명시된 범위 주의 사항도 참고하세요. 메모리는 레거시 Cascade 에이전트에만 적용되는 것으로 문서화되어 있으며, 새 탭의 기본값인 Devin Local 에이전트는 메모리를 유지하지 않습니다.

단순화를 위해 모든 것을 하나의 파일로 통합하기. 이는 관리 가능한 모드 결정 세트를 차별화되지 않은 하나의 always-on 블록과 맞바꾸는 것이며, 파일당 글자 수 제한에 부딪히게 됩니다. 이 결정의 폴더 수준 버전은 Windsurf 및 Devin 규칙 폴더 병합하기에서 다루고 있습니다.

엔터프라이즈 규칙이 이 혼란을 해결해 줄 것이라고 가정하기. 그렇지 않습니다. 문서에 명시되어 있듯이, 시스템 수준 규칙은 "사용자 정의 규칙을 재정의하지 않고 워크스페이스 및 글로벌 규칙과 병합되어 Cascade에 추가적인 컨텍스트를 제공합니다." 관리자 기준 설정은 예산을 대체하는 것이 아니라 오히려 예산을 추가하게 만듭니다.

결정해야 할 것은 "어떤 모드가 가장 좋은가"가 아닙니다. "이 규칙이 실제로 얼마나 자주 관련이 있는가"이며, 모드는 이에 대한 네 가지 솔직한 답변에 매핑됩니다.

1단계: 모드가 없는 영역을 포함하여 모든 영역 인벤토리화하기

무언가를 변경하기 전에 모든 것을 나열해 보세요. 규칙이 올 수 있는 곳은 다섯 가지가 있으며, 그중 단 하나만 trigger 필드를 가지고 있습니다.

~/.codeium/windsurf/memories/global_rules.md에 있는 글로벌 파일 — 항상 켜짐, 6,000자.

루트 레벨 AGENTS.md — 항상 켜짐, frontmatter 없음.

하위 디렉토리 AGENTS.md 파일 — 해당 디렉토리에 대한 auto-glob.

워크스페이스 루트에 있는 레거시 .windsurfrules(존재하는 경우) — 이를 꼭 확인하세요. 자신도 모르게 낭비하고 있는 컨텍스트 예산의 가장 흔한 원인입니다.

.devin/rules/ 또는 .windsurf/rules/에 있는 워크스페이스 규칙 파일 — 규칙당 파일 하나, 각 12,000자 제한, 모드를 선택할 수 있는 유일한 영역.

먼저 always-on의 총합을 더해 보세요. 이 숫자가 기본 바닥(floor)이며, 조건부 규칙이 로드되기 전에 모든 메시지가 지불해야 하는 비용입니다.

2단계: 각 워크스페이스 규칙을 네 가지 솔직한 답변 중 하나로 분류하기

규칙을 하나씩 살펴보며 실제로 얼마나 자주 관련이 있는지 자문해 보세요. 답변은 다음과 같이 직접 매핑됩니다.

모든 메시지와 관련이 있음. "영국식 영어로 응답하기" 또는 "main 브랜치에 절대 커밋하지 않기"와 같은 사항입니다. 이들은 always_on을 부여받습니다. 이러한 규칙은 극소수여야 하며, 이들의 합산 크기가 중요하게 관리해야 할 수치입니다.

가끔, 예측할 수 없게 관련이 있음. 특정 주제가 발생할 때 에이전트가 참조해야 하는 도메인 지식(예: 결제 제약 조건, 규정 준수 규칙)입니다. 이들은 model_decision에 해당하며, 여기서는 설명(description)이 매우 중요한 역할을 합니다. 기본적으로 설명만 로드되기 때문입니다. 설명을 제목이 아니라 "이 규칙을 언제 사용해야 하는지" 설명하는 문장으로 작성하세요.

특정 파일이 관련될 때만 관련이 있음. 테스트 컨벤션, 마이그레이션 안전성, 생성된 코드 등 파일 형태와 관련된 모든 것입니다. 이들은 glob에 해당하며, 대부분의 컨벤션이 파일 형태임에도 사람들이 항상 always-on으로 설정해 두었기 때문에 보통 여기서 가장 큰 최적화 효과를 얻을 수 있습니다.

사용자가 지정할 때만 관련이 있음. 릴리스 체크리스트, 장애 대응 절차 등 의도적으로 호출하는 모든 것입니다. 이들은 manual에 해당하며, @rule-name으로 활성화합니다.

만약 어떤 규칙이 이 네 가지 중 어디에도 맞지 않는다면, 그것은 진단 신호입니다. 보통 하나의 파일에 항상 참인 규칙과 상황에 따른 규칙 두 개가 묶여 있음을 의미하며, 이를 분할하면 각 절반에 맞는 모드를 부여할 수 있습니다.

3단계: 파일을 읽는 대신 모슨을 통해 검증하기

frontmatter를 보는 것만으로는 모드를 확인할 수 없습니다. 핵심은 에이전트가 실제로 그 콘텐츠를 수신했는지 여부이기 때문입니다.

For a glob rule, open a file that should not match and ask for something the rule would change. If the rule's behaviour shows up anyway, your pattern is broader than you think. Then open a file that should match and check the behaviour appears.

glob 규칙의 경우, 일치하지 않아야 하는 파일을 열고 해당 규칙이 변경할 만한 작업을 요청해 보세요. 규칙의 동작이 여전히 나타난다면 패턴이 생각보다 넓게 설정된 것입니다. 그런 다음 일치해야 하는 파일을 열고 동작이 나타나는지 확인하세요.

model_decision 규칙의 경우, 규칙 이름을 언급하지 않고 해당 주제에 대해 질문해 보세요. 에이전트가 규칙을 가져오지 않는다면 본문이 아니라 설명(description)이 문제입니다.

manual 규칙의 경우, @rule-name 호출이 정상적으로 작동하는지 확인하고, 언급하지 않았을 때는 규칙이 적용되지 않는지 확인하세요. 이것이 이 모드의 핵심 목적입니다.

모드를 변경한 후 규칙마다 이 작업을 한 번씩 수행하세요. 이것이 설정된 모드와 실제로 작동하는 모드를 구분할 수 있는 유일한 방법이며, Windsurf가 프로젝트 규칙을 잊어버릴 때의 문제를 잡아내는 것과 동일한 훈련 과정입니다.

이 과정을 거치고 나면 두 가지가 남게 되는데, 그중 하나만 규칙 디렉토리에 적합합니다. 어떻게 행동하고 무엇을 선호해야 하는지에 대한 '지침'은 Windsurf가 지정한 위치에 정확히 들어맞습니다. 하지만 그 뒤에 숨겨진 '이유'는 그렇지 않습니다. "우리는 일 단위 결제를 사용한다"는 규칙이고, "재무 시스템이 부분 일수를 거부하기 때문이다"는 에이전트가 규칙의 적용이 중단되는 시점을 판단할 수 있게 해주는 근거입니다.

MemoryLake는 글자 수 제한과 특정 에디터의 제약을 벗어나 이 두 번째 레이어를 보관합니다. 규칙은 더 짧아지고, always-on 기본 비용은 낮아지며, 사용 중인 모든 도구에서 그 추론 과정을 여전히 활용할 수 있습니다.

1단계: API 키 생성하기

로그인하고 워크스페이스 설정을 연 다음 API 키를 생성합니다. 이 키는 에디터와 에이전트가 동일한 레이어를 읽는 데 사용하는 인증 정보이므로, 한 번 생성하여 각 장치에서 접근할 수 있도록 보관하세요.

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

규칙 본문에서 추론 과정을 분리하세요. 각 컨벤션이 존재하는 이유, 거부한 접근 방식, 당연해 보이는 답을 오답으로 만드는 제약 조건 등이 이에 해당합니다. 규칙 파일은 지침을 유지하고, 레이어는 그 정당성을 보관합니다.

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

Windsurf 및 작업하는 다른 모든 도구를 연결하세요. 동일한 추론 과정이 각 도구에 전달됩니다. 규칙 디렉토리는 다음 도구로 이동하지 않지만, 그 안의 결정 사항들은 이동해야 하므로 이는 매우 중요합니다.

첫 번째 차이점은 단 한 번의 세션 내에서도 측정할 수 있습니다. 파일 형태의 컨벤션을 always_on에서 glob으로 이동하면 모든 메시지에서 제외되므로, 두 시간이 지나도 긴 대화의 성능이 저하되지 않습니다.

두 번째는 model_decision을 유용하게 쓸 수 있게 된다는 점입니다. 이는 가장 흥미로운 모드이면서도 가장 흔하게 낭비되는 모드인데, 설명을 단순한 라벨처럼 작성하면 에이전트가 판단할 근거가 없기 때문입니다. 이를 조건문 형태로 작성하면 필요할 때 작동하는 훌륭한 영역이 됩니다.

세 번째는 always-on 기본 비용이 명확히 인지할 수 있는 숫자가 된다는 점입니다. 6,000자의 글로벌 파일, 루트 AGENTS.md, 그리고 잊고 있던 .windsurfrules 사이에서, 이 기본 비용은 사람들이 관리하고 있다고 생각하는 예산의 대부분을 차지하곤 합니다.

네 번째는 규칙이 더 이상 추론 과정을 담고 있지 않아도 된다는 점입니다. 더 짧아진 파일은 12,000자 제한에 여유롭게 들어맞으며, 정당성은 사람이 읽을 수 있고 다른 도구가 로드할 수 있는 곳에 보관됩니다. 이렇게 하지 않았을 때 발생하는 비용은 Windsurf가 Cascade 컨텍스트를 잊어버릴 때에서 컨텍스트 손실로 나타납니다.

always_on이 아닌 glob을 기본값으로 설정하세요. 대부분의 컨벤션은 파일에 관한 것입니다. 에이전트의 노출 범위를 이에 맞추세요.

model_decision 설명은 조건문으로 작성하세요. "결제 흐름이나 환불 로직을 작업할 때 사용"이 "결제 규칙"보다 훨씬 낫습니다. 기본적으로 설명만 로드되기 때문입니다.

레거시 파일을 확인한 후 삭제하세요. 워크스페이스 루트의 .windsurfrules는 여전히 읽힙니다. 이것이 단일 진실 공급원(source of truth)이 아니라면 존재해서는 안 됩니다.

파일 이동의 영향을 주시하세요. 하위 디렉토리의 AGENTS.md는 해당 디렉토리에 대한 auto-glob이지만, 루트에 있는 동일한 파일은 always-on입니다. 디렉토리 이동은 비용의 변화를 의미합니다.

나머지를 최적화하기 전에 always-on 총합을 먼저 계산하세요. 모든 메시지에 6,000자짜리 글로벌 파일이 로드되는 상황에서 조건부 규칙을 최적화하는 것은 순서가 잘못되었습니다.

자동 생성된 메모리는 일회성 사실로 취급하세요. 이것이 Windsurf 자체의 포지셔닝이며, 지속적인 지식은 대신 규칙이나 AGENTS.md에 작성하는 것을 권장합니다.

모드를 변경한 후에는 항상 다시 검증하세요. frontmatter 수정은 증거가 되지 못합니다. 모순을 통한 검증만이 확실한 증거입니다.

Windsurf는 이미 어려운 부분을 해결했습니다. 각 활성화 모드의 비용과 로드 시점을 공개한 것입니다. 네 가지 모드는 규칙이 얼마나 자주 관련되는지에 대한 네 가지 솔직한 답변에 깔끔하게 매핑되며, 대부분의 규칙 디렉토리가 잘못 구성된 이유는 단지 파일별로 이 질문에 대해 진지하게 고민하고 답하지 않았기 때문입니다.

그러니 이제 답해 보세요. 모드가 없는 영역을 인벤토리화하고, 이들이 차지하는 기본 비용을 합산하고, 나머지를 네 가지 버킷으로 분류한 다음, frontmatter를 읽는 대신 모순을 통해 검증하세요. 그런 다음 규칙 본문에서 추론 과정을 분리하세요. 글자 수 제한이 있는 곳은 컨벤션이 존재하는 이유를 보관하기에 적절한 장소가 아닙니다. 또한 다음에 사용할 도구는 자체적인 제한과 모드를 가질 것이며, 이 디렉토리를 전혀 읽지 못할 것이기 때문입니다.