Windsurf 및 Devin 규칙 폴더를 병합하여 올바른 규칙이 적용되도록 하는 방법 (2026년 가이드)

공식 문서에 명시된 우선순위는 한 번 찾아보면 명확합니다. Devin Desktop의 규칙 검색(rules discovery) 섹션에 다음과 같이 직접적으로 명시되어 있습니다:

"Devin Desktop은 유연한 구성을 제공하기 위해 여러 위치에서 규칙을 자동으로 검색합니다. .devin/ 디렉토리가 선호되는 위치이며 우선순위를 가집니다. .windsurf/는 하위 호환성을 위한 폴백(fallback)으로 유지됩니다."

이 한 문장으로 핵심 질문은 해결됩니다. 문제는 그 주변의 모든 것입니다.

검색은 단 하나의 폴더에서 멈추지 않습니다. 현재 작업 공간 및 하위 디렉토리 내의 "모든 .devin/rules(및 레거시 .windsurf/rules) 디렉토리"를 포함하며, git 리포지토리의 경우 "상위 디렉토리에서 규칙을 찾기 위해 git 루트 디렉토리까지 검색"하기도 합니다. 여러 폴더가 동시에 열려 있는 경우, "규칙은 중복 제거되어 가장 짧은 상대 경로로 표시"됩니다.

대부분의 팀이 완전히 잊고 있는 작업 공간 범위의 세 번째 파일이 있습니다:

"작업 공간 루트에 있는 레거시 단일 파일 .windsurfrules도 여전히 읽힙니다."

작업 공간 위에는 자체 규칙을 가진 전역 파일이 있습니다: ~/.codeium/windsurf/memories/global_rules.md. 이 파일은 "모든 작업 공간에 적용되는 단일 파일. 항상 켜짐(Always on). 6,000자로 제한"으로 설명되어 있습니다. 작업 공간 규칙 파일은 각각 12,000자라는 자체 제한이 있습니다.

그리고 전혀 별개의 시스템이 아닌 AGENTS.md가 있습니다. 관련 문서에서 이 관계를 명확히 설명합니다:

"AGENTS.md 파일(또는 agents.md)을 생성하면, Devin Desktop은 이를 자동으로 검색하여 .devin/rules/(및 레거시 .windsurf/rules/)를 구동하는 동일한 규칙 엔진에 입력합니다. 다만 활성화 모드는 프론트매터(frontmatter) 대신 파일의 위치에서 유추됩니다."

루트 레벨은 항상 켜짐(always-on)을 의미합니다. 하위 디렉토리는 "자동 생성된 패턴 <directory>/**를 가진 glob 규칙"을 의미합니다.

그리고 기업의 경우, IT 부서에서 배포하고 사용자는 읽기 전용인 시스템 레이어가 있으며, 여기에도 동일한 신구 쌍이 존재합니다. macOS의 경우 /Library/Application Support/Devin/rules/(레거시 폴백으로 Windsurf 사용), Linux의 경우 /etc/devin/rules/(폴백으로 /etc/windsurf/rules/ 사용), 그리고 Windows에도 이에 상응하는 쌍이 있습니다. 시스템 규칙은 "사용자 정의 규칙을 재정의하지 않고 Cascade에 추가적인 컨텍스트를 제공하기 위해 작업 공간 및 전역 규칙과 병합"됩니다.

영역의 수를 세어보십시오: .devin/rules, .windsurf/rules, .windsurfrules, 다수의 AGENTS.md 파일, global_rules.md, 그리고 두 개의 시스템 디렉토리입니다. 이 모든 것이 활성화되어 있습니다. 이 중 두 쌍은 단지 이름 변경이 발생했고 기존 기능이 깨지지 않도록 하기 위해서만 존재합니다.

규칙의 불일치(drift)를 쉽게 만드는 세부 사항이 하나 더 있습니다. 새로운 규칙은 여러분이 예상하는 위치에 저장되지 않습니다:

"새 규칙을 생성하면 git 루트가 아니라 현재 작업 공간의 .devin/rules 디렉토리에 저장됩니다."

따라서 모노레포(monorepo)에서 특정 패키지 내부에 있을 때 생성된 규칙은 최상위가 아니라 해당 패키지 내부에 저장됩니다.

레거시 폴더를 즉시 삭제하기. 유혹적이지만 대개 시기상조입니다. 이전 폴더는 여전히 읽히므로, 이전 클라이언트를 사용 중이거나 아직 pull을 받지 않은 팀원이 이에 의존하고 있을 수 있습니다. 콘텐츠가 새 위치에 제대로 반영되었는지 확인한 후에 삭제해야 하며, 그 전에는 안 됩니다.

가장 최신 파일이 우선한다고 가정하기. 그렇지 않습니다. 우선순위는 수정 시간이 아니라 위치에 따라 결정됩니다. 오늘 아침 .windsurf/rules에 작성한 규칙은 .devin/rules에 있는 오래된 규칙에 밀려 적용되지 않습니다.

폴더 문제를 피하기 위해 모든 것을 global_rules.md에 넣기. 이는 하나의 문제를 더 나쁜 문제와 바꾸는 격입니다. 전역 파일은 항상 켜져 있고, 모든 작업 공간에 적용되며, 6,000자로 제한됩니다. 프로젝트별 컨벤션을 담기에는 부적절한 컨테이너이며, 가장 먼저 용량 제한에 부딪힐 것입니다.

AGENTS.md는 이 논쟁에서 예외라고 가정하기. 그렇지 않습니다. 이 파일 역시 동일한 규칙 엔진을 거치며, 루트 레벨에 있는 파일은 항상 켜져 있습니다. 따라서 선언된 방식이 아니라 위치한 곳에서 활성화 여부가 유추되므로, 항상 켜져 있는 규칙 파일과 동일한 컨텍스트 예산(context budget)을 두고 경쟁하게 됩니다.

자동 생성된 메모리를 영구적인 레이어로 취급하기. 관련 문서는 이에 대해 이례적으로 직접적으로 설명하고 있으며, 벤더가 자체 기능의 용도를 직접 밝히고 있으므로 인용할 가치가 있습니다:

"Cascade가 안정적으로 재사용하기를 원하는 지식은 자동 생성된 메모리(Memories)에 의존하기보다 규칙(Rule)으로 작성하거나 리포지토리의 AGENTS.md에 추가하십시오. 규칙은 버전 관리 및 팀 공유가 가능하며, 활성화에 대한 명시적인 제어권을 제공합니다."

자동 생성된 메모리는 로컬 전용이기도 합니다. 이들은 ~/.codeium/windsurf/memories/ 아래에 저장되며, "한 작업 공간에서 생성된 메모리는 다른 작업 공간에서 사용할 수 없으며 리포지토리에 커밋되지 않습니다." 세션 간에 컨텍스트를 잃어버리는 증상 때문에 이 글을 읽게 되었다면, why Cascade loses context에서 해당 내용을 직접 다루고 있습니다.

세 단계로 진행됩니다. 순서대로 수행하십시오. 인벤토리 작성이 두 번째 단계를 안전하게 만드는 열쇠입니다.

1단계: 이동하기 전에 모든 영역 인벤토리화하기

7개 영역을 모두 살펴보고 각 영역에 무엇이 있는지 기록하십시오. 구체적으로: 작업 공간 및 git 루트까지의 상위 디렉토리에 있는 모든 .devin/rules 디렉토리, 동일한 위치의 모든 .windsurf/rules 디렉토리, 작업 공간 루트에 존재하는 경우 .windsurfrules 파일, 모든 레벨의 모든 AGENTS.md 또는 agents.md, global_rules.md, 그리고 조직에서 배포한 경우 현재 및 레거시 시스템 디렉토리입니다.

각 규칙에 대해 기록해야 할 두 가지는 활성화 모드와 다른 곳에 동일한 규칙이 이미 존재하는지 여부입니다. 활성화 모드가 중요한 이유는 프론트매터의 trigger 필드를 통해 선언되며, 네 가지 값의 비용이 매우 다르기 때문입니다. 문서는 이 트레이드오프를 명확히 설명합니다: always_on은 모든 메시지의 시스템 프롬프트에 전체 규칙을 넣습니다. model_decision은 프롬프트에 description만 넣고 Cascade가 해당 설명이 관련이 있다고 판단할 때 전체 파일을 읽습니다. glob은 Cascade가 패턴과 일치하는 파일을 읽거나 편집할 때 규칙을 적용합니다. manual은 사용자가 @rule-name을 입력할 때까지 프롬프트에서 완전히 제외합니다.

인벤토리를 작성하는 동안 두 가지 예외 사항에 유의하십시오: "전역 규칙 파일(global_rules.md) 및 루트 레벨 AGENTS.md 파일은 프론트매터를 사용하지 않으며 항상 켜져 있습니다." 이 두 가지는 범위를 제한할 수 없습니다. 그 안에 있는 내용은 모든 메시지에 포함됩니다.

2단계: 각 규칙을 .devin/rules로 이동하고 중복을 수동으로 해결하기

각 레거시 규칙을 실제로 속해야 하는 레벨의 .devin/rules 디렉토리로 복사하십시오. 대부분의 컨벤션의 경우 이는 규칙을 생성할 때 머물렀던 패키지가 아니라 git 루트입니다.

두 폴더에서 동일한 규칙을 발견하면 하나를 선택하기 전에 두 버전을 모두 읽어보십시오. 이 단계에서 불일치가 눈에 띄게 드러나며, 완전히 똑같은 중복이 아닌 경우가 많습니다. 레거시 버전에 새 버전에서 누락된 세부 정보가 있거나, 새 버전에 레거시 버전에는 반영되지 않은 수정 사항이 있을 수 있습니다. 신중하게 병합한 다음 레거시 복사본을 삭제하십시오.

.windsurfrules는 자체적인 결정이 필요합니다. 프론트매터가 없는 단일 파일이므로 그 안의 모든 것이 구분되지 않은 하나의 블록으로 작동합니다. 이동할 때 선언된 트리거가 있는 개별 규칙 파일로 분할하십시오. 이것이 바로 최신 형식이 제공하는 핵심 이점입니다.

AGENTS.md 파일의 경우, 각각이 정말로 항상 켜져 있어야 하는 내용인지 결정하십시오. 루트 레벨 AGENTS.md는 범위를 제한할 수 없으므로, 트리의 일부에만 적용되는 내용은 하위 디렉토리 AGENTS.md(해당 디렉토리에 대한 자동 glob 적용)로 만들거나 명시적인 glob 트리거가 있는 규칙 파일로 변환해야 합니다.

⚠️ 이 파일들을 다루는 동안 도구 간 호환성에 대한 경고가 하나 있습니다. Devin Desktop은 이름에 대해 관대합니다. "대소문자 구분 없음: AGENTS.md와 agents.md 모두 인식됨." 하지만 다른 도구들은 그렇지 않습니다. Kilo Code의 문서에는 "파일명은 소문자(agents.md)가 아닌 대문자(AGENTS.md)여야 합니다"라고 명확히 명시되어 있습니다. 리포지토리를 다른 에이전트를 사용하는 사람들과 공유하는 경우 대문자를 사용하십시오. 여기서는 비용이 들지 않지만, 다른 곳에서 파일이 읽히느냐 아니면 소리 없이 무시되느냐의 차이를 만듭니다. 이러한 종류의 불일치는 벤더 간에 규칙을 이동할 때도 나타납니다. moving Cursor rules into Windsurf에서 프론트매터 측면을 다룹니다.

3단계: 활성화 모드를 가질 수 있는 모든 것에 대해 활성화 모드 선언하기

통합이 완료되면 .devin/rules를 살펴보며 모든 파일의 trigger가 기본값이 아닌 의도적인 선택인지 확인하십시오.

가장 확실한 테스트는 규칙당 하나의 질문을 던지는 것입니다. '이 규칙이 모든 메시지의 프롬프트에 포함되어야 하는가?' 대부분의 규칙은 그렇지 않습니다. 테스트 파일에 대한 컨벤션은 glob 규칙입니다. 릴리스 런북은 manual입니다. 데이터 모델에 대한 긴 설명은 model_decision으로 설정하여 설명만 항상 존재하고 본문은 필요할 때 읽히도록 합니다.

이 단계는 7개의 중복된 영역이 조용히 소비하고 있던 컨텍스트 예산을 되찾아오는 단계이며, 중복이 제거된 후에만 가능합니다. 동일한 규칙이 세 번 존재하는 상황에서는 활성화 비용을 합리적으로 판단할 수 없습니다.

통합은 폴더 문제를 해결해 줍니다. 하지만 중복을 신속하게 해결할 수 없었던 근본적인 원인, 즉 동일한 규칙이 서로 다른 두 가지 문구로 두 곳에 존재할 때 어떤 버전이 최신 버전인지 또는 그 사이에 무엇이 변경되었는지 기록되지 않았던 문제는 해결해 주지 못합니다.

MemoryLake는 해당 기록을 규칙 레이어 외부에서 완전히 관리하며, MCP 또는 API를 통해 요청하는 에이전트에 제공합니다. .devin/rules 파일은 원래 위치에 그대로 유지되며 문서에 설명된 대로 정확히 계속 작동합니다. MemoryLake는 규칙 엔진이 저장하도록 설계되지 않은 부분, 즉 각 규칙의 용도, 대체된 내용, 변경 시점 등을 보관합니다.

1단계: API 키 생성하기

키를 생성하고 약 30초 만에 첫 번째 요청을 완료하십시오. 통합의 2단계를 진행하기 전에 이 작업을 수행하여 중복을 해결하는 과정에서 내린 결정들을 기록해 두십시오.

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

각 중복 쌍을 병합할 때 유지한 내용, 버린 내용 및 그 이유를 기록하십시오. 특정 장애나 사건에서 비롯된 규칙들을 추가하십시오. 이러한 규칙들은 아무도 그 이유를 기억하지 못해 감히 문구를 변경하지 못하는 규칙들입니다. 문서 및 기타 파일도 동일한 위치에 저장됩니다.

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

Claude, Codex, OpenClaw 및 Devin Desktop 세션에 MCP 또는 API를 통해 액세스 권한을 부여하십시오. 연결이 완료되면 규칙의 배경 논리를 필요할 때 가져올 수 있으므로, 규칙 파일 자체를 always_on 트리거를 정당화할 수 있을 만큼 짧게 유지할 수 있습니다.

가장 즉각적인 변화는 "실제로 어떤 규칙이 적용 중인가"에 대한 답을 한 곳에서 얻을 수 있게 된다는 점입니다. 하나의 폴더, 규칙당 하나의 파일, 그리고 각각 선언된 활성화 모드를 갖게 됩니다.

두 번째 변화는 컨텍스트 예산입니다. 언제나 켜져 있는 파일의 수를 알 수 없는 7개의 중복된 영역은 작업의 극히 일부에만 적용되는 지침에 너무 많은 프롬프트를 낭비하게 만듭니다. 중복을 제거하고 트리거를 선언하는 것만이 이를 줄일 수 있는 유일한 방법이며, 이는 대개 사람들이 예상하는 것보다 더 많은 공간을 확보해 줍니다.

세 번째 변화는 다음 이름 변경 작업이 지루하고 단순해진다는 점입니다. 이러한 일은 앞으로도 일어날 것입니다. 벤더가 합병되고, 제품 이름이 바뀌고, 경로가 이동하며, 벤더가 취할 수 있는 책임감 있는 조치는 기존 경로를 계속 읽는 것입니다. 규칙이 통합되어 있고 그 배경 논리가 폴더 외부에 존재한다면, 다음 경로 변경은 또 다른 고고학 프로젝트가 아니라 단순한 복사 작업이 될 것입니다.

공식 문서에서 선호하는 위치이자 우선순위를 가지는 .devin/rules로 통합하십시오. 우선순위 순서와 싸우지 말고, 우선권을 가진 쪽으로 이동하십시오.

프로젝트 전반에 적용되는 규칙은 git 루트에 두십시오. 새 규칙은 "반드시 git 루트가 아닌" 현재 작업 공간 디렉토리에 저장되므로, 모노레포에서 컨벤션이 하나의 패키지 내부에 묻히게 되는 원인이 됩니다.

.windsurfrules를 통째로 이식하기보다 분할하십시오. 구분되지 않은 단일 파일은 활성화 모드를 표현할 수 없으며, 활성화 모드는 최신 형식이 제공하는 가장 큰 이점입니다.

대문자 AGENTS.md를 사용하십시오. Devin Desktop은 대소문자를 모두 허용하지만, 공유 리포지토리의 다른 에이전트들은 대문자를 요구할 수 있습니다.

global_rules.md는 진정으로 개인적이고 프로젝트 전반에 걸친 선호 사항만을 위해 유지하십시오. 항상 켜져 있고, 모든 곳에 적용되며, 6,000자로 제한됩니다.

콘텐츠가 이동되었는지 확인한 후에만 레거시 복사본을 삭제하십시오. 이전 경로도 여전히 읽히므로, 불완전한 통합은 아예 통합하지 않은 것보다 나쁜 결과를 초래할 수 있습니다.

자동 생성된 메모리를 팀의 기록으로 사용하지 마십시오. 문서는 영구적이고 공유 가능한 지식을 위해 규칙이나 AGENTS.md를 권장하며, 자동 생성된 메모리는 작업 공간 로컬 전용이고 커밋되지 않는다고 명시하고 있습니다. 규칙 파일이 아닌 에이전트가 쿼리하는 저장소에 속해야 하는 내용에 대해서는 memory tools for Windsurf users에서 옵션들을 다룹니다.

Devin Desktop은 7개의 규칙 영역을 읽으며, 그중 두 쌍은 단지 이름 변경이 발생하고 하위 호환성이 유지되었기 때문에 존재합니다. .devin/이 .windsurf/보다 우선하고, 둘 다 읽히며, 그 위에 .windsurfrules도 여전히 읽힙니다. 그리고 AGENTS.md 파일은 위치에서 유추된 활성화 상태로 동일한 엔진에 입력됩니다.

이 중 어느 것도 고장 난 것은 아닙니다. 하지만 특히 새 규칙이 현재 머무르고 있는 작업 공간 디렉토리에 저장되기 때문에, 이 모든 것은 불일치(drift)가 발생하기 쉬운 상태입니다.

7개 영역을 모두 인벤토리화하고, 적절한 레벨의 .devin/rules로 통합하고, 레거시 단일 파일을 분할하고, 활성화 모드를 가질 수 있는 모든 것에 대해 활성화 모드를 선언하고, 각 규칙의 배경 논리를 규칙 엔진이 소유하지 않는 곳에 보관하십시오. 그러면 "어느 것이 우선하는가"에 대한 답은 간단해집니다. 오직 하나뿐입니다.