컨텍스트 손실 없이 Windsurf에서 Cursor로 마이그레이션하는 방법 (2026)

에디터 수준의 설정은 자동으로 이동합니다. 둘 다 VS Code 포크이므로 확장 프로그램, 테마, 키 바인딩, 설정 등은 최소한의 노력으로 가져올 수 있습니다. 이 부분 덕분에 마이그레이션이 쉬워 보이지만, 실제로는 그렇지 않은 부분을 가리게 됩니다.

규칙은 텍스트로만 전송되며, 동작 방식은 전송되지 않습니다. 커뮤니티 문서에 따르면 Windsurf는 프로젝트 루트의 기존 .windsurfrules 파일과 .windsurf/rules/ 아래의 새로운 스코프 지정 Markdown 파일이라는 두 가지 규칙 시스템을 병행하여 사용하며, 총 글자 수 제한은 약 12,000자 내외로 알려져 있습니다. 반면 Cursor의 모델은 근본적으로 다릅니다. 프로젝트 규칙은 버전 관리 하에 .cursor/rules에 .mdc 파일로 저장되며, 세 가지 frontmatter 필드(alwaysApply, description, globs)가 각 규칙이 컨텍스트에 들어가는 시점을 결정합니다.

따라서 복사하면 내용은 유지되지만 활성화 방식은 유지되지 않으므로, 복사된 규칙 세트가 작동하는 것처럼 보이다가 실제로는 아무런 영향을 미치지 않게 되는 것입니다.

Cascade 기억(memories)은 전혀 전송되지 않습니다. 이 기억들은 자동으로 생성되어 생성된 로컬 기기에 저장되며, 팀원들과 공유되지 않고 내보내기 경로도 없습니다. 마이그레이션 관점에서 이것이 의미하는 바는 다음과 같습니다. 이 기억들은 실제로 유용한 작업을 수행하고 있었고, 마이그레이션에서 유일하게 기한이 정해진 부분이며, 이를 추출하는 유일한 방법은 이전 어시스턴트가 아직 실행 중일 때 무엇을 알고 있는지 물어보는 것뿐입니다.

기록해 두지 않은 것은 무엇이든 전송되지 않습니다. 특정 디렉터리가 금지된 이유, 배포 순서, 클라이언트의 제약 조건 등은 규칙 파일에도 없었고 Cascade의 기억에도 읽을 수 있는 형태로 존재하지 않았기 때문에, 오직 여러분의 머릿속이나 이를 기억하는 팀원의 머릿속에만 존재합니다.

마이그레이션 후 Cursor가 제공하는 것은 이전보다 더 구조화된 시스템입니다. 공식 문서에 따르면 네 가지 규칙 유형이 있습니다. .cursor/rules에 있는 프로젝트 규칙(버전 관리됨, 리포지토리 스코프), 전체 Cursor 환경에 적용되는 사용자 규칙, Team 및 Enterprise 플랜의 대시보드에서 관리되는 팀 규칙, 그리고 .cursor/rules 대신 사용할 수 있는 일반 Markdown 대안인 AGENTS.md입니다. Cursor는 그 메커니즘을 명확히 밝히고 있습니다. "대규모 언어 모델은 완료(completion) 간에 기억을 유지하지 않습니다. 규칙은 프롬프트 수준에서 지속적이고 재사용 가능한 컨텍스트를 제공합니다." 규칙은 모델의 컨텍스트 앞에 추가됩니다. 규칙은 기억(memory)이 아니며, Cursor 역시 그렇게 주장하지 않습니다.

1단계: 삭제하기 전에 Cascade 심문하기

무엇보다 이 작업을 먼저 수행해야 하며, 이전 에디터가 아직 열릴 때 진행해야 합니다. Cascade를 열고 이 프로젝트에 대해 학습한 내용(컨벤션, 주의 사항, 결정 사항, 작업 방식에 대해 기억하는 모든 것)을 평이한 언어로 물어보세요. 다양한 방식으로 반복해서 질문하고, 답변을 임시 파일에 붙여넣으세요. 그런 다음 이 코드베이스에서 하지 말아야 할 일이 무엇인지 물어보세요. 그러면 긍정적인 질문을 했을 때와는 다른 기억들이 드러날 것입니다.

이 시간은 마이그레이션 과정에서 되돌릴 수 없는 유일한 순간입니다. 규칙 파일은 디스크에 저장되어 있으므로 다음 주에도 그대로 남아있을 것입니다. 하지만 Cascade의 기억은 내보낼 수 없는 로컬 기기 생성 상태이므로, 에디터가 사라지면 함께 사라집니다.

이전 프로젝트에 머무는 동안 파일 목록도 정리해 두세요:

• 프로젝트 루트에 여전히 존재하는 경우 .windsurfrules
• .windsurf/rules/ 아래의 모든 파일
• 구성한 워크플로우 및 도구 정의
• 변환하기보다는 새로 추가해야 할 MCP 서버 구성

그런 다음 규칙을 출처에 따라 세 가지로 분류하세요. 리포지토리에서 파생된 것(README에도 적혀 있는 내용 - 삭제), 직접 작성했고 여전히 유효한 것(이것이 마이그레이션 대상), 직접 작성했으나 더 이상 유효하지 않은 것(어느 쪽인지 기억할 때 의도적으로 지금 삭제). 마이그레이션은 모든 규칙을 새로운 시각으로 읽어볼 수 있는 유일한 기회입니다. 이 기회를 활용하세요.

2단계: 각 규칙을 적절한 활성화 모드로 재정의하기

이제 규칙을 하나씩 변환하면서 의도에 맞는 유형을 선택하세요. Cursor의 네 가지 모드는 각각 다른 비용과 매핑됩니다:

• Always Apply (alwaysApply: true) — 모든 채팅 세션에 포함되며, globs와 description은 무시됩니다. 답변을 틀리게 만들 수 있는 소수의 규칙(예: 저작권 헤더, "dist/에 생성된 파일은 절대 수정하지 말 것", 엄격한 아키텍처 제약 조건 등)에만 이 모드를 적용하세요.
• Apply to Specific Files (globs: 설정, alwaysApply: false) — 일치하는 파일이 컨텍스트에 있을 때 자동으로 첨부됩니다. 대부분의 Windsurf 스코프 규칙이 여기에 해당합니다. globs: src/components/**/*.tsx는 막연한 기대 대신 패턴으로 "프론트엔드 규칙"을 명확히 표현합니다.
• Apply Intelligently (description: 설정, globs 없음) — 에이전트가 설명을 읽고 관련이 있다고 판단할 때 규칙을 가져옵니다. 경로에 매핑되지 않는 도메인 규칙에 유용하며, 작성한 설명의 품질에 따라 성능이 좌우됩니다.
• Apply Manually (description 없음, globs 없음) — @my-rule과 같이 직접 @-멘션할 때만 포함됩니다. 매번 완료 시마다 필요하지 않고 필요할 때만 불러오고 싶은 긴 체크리스트에 적합합니다.

이 작업을 수행할 때 피해야 할 세 가지 기술적 함정은 다음과 같습니다:

확장자가 중요합니다. 프로젝트 규칙은 반드시 .mdc를 사용해야 합니다. Cursor 공식 문서에 따르면, .cursor/rules에 있는 일반 .md 파일은 frontmatter 필드가 없기 때문에 규칙 시스템에서 무시됩니다. 일반 Markdown을 선호하는 경우, 문서화된 경로는 규칙 폴더의 .md 파일이 아니라 AGENTS.md입니다.

모든 항목을 Always Apply로 설정하지 마세요. 이는 마이그레이션을 빠르게 "작동"시키는 방법이지만, 동시에 규칙을 무용지물로 만드는 가장 확실한 방법이기도 합니다. 모든 완료 작업에 모든 규칙이 포함되면 중요한 규칙의 집중도가 흐려지며, Cursor의 가이드라인은 규칙을 500행 미만으로 유지하는 것입니다. 이전 Windsurf 설정에서 글자 수 제한 때문에 고민했다면, 그 제한은 선택을 강제함으로써 오히려 도움을 준 것입니다. 여기서는 그러한 제한이 강제되지 않습니다.

공유 표준은 팀원들이 접근할 수 있는 곳에 두세요. 프로젝트 규칙은 버전 관리되므로, 이를 커밋하면 팀원들이 여러분의 작업 내용을 이어받을 수 있습니다. Team 및 Enterprise 플랜의 경우, 대시보드의 팀 규칙이 그 상위 레이어입니다. 개인적인 습관은 리포지토리가 아닌 사용자 규칙에 저장하세요.

마지막으로, 1단계에서 수집한 Cascade 지식을 의도에 맞게 배치하세요. 대부분은 규칙 형태가 아니라 컨텍스트, 이력, 추론 과정입니다. 일부는 규칙이 될 수 있지만, 나머지는 리포지토리 문서나 어시스턴트가 읽을 수 있는 저장소에 보관해야 하며, 이에 대해서는 다음 섹션에서 다룹니다.

방금 수행한 작업을 돌아보세요. 특정 벤더의 규칙 형식을 다른 벤더의 규칙 형식으로 변환했고, 다른 방법이 없었기 때문에 채팅 창에서 기억 세트를 수동으로 복사했습니다. 내년에 Cursor의 소유주가 바뀌거나 서비스가 변경된다면(이 글을 읽고 있는 이유도 이전 에디터에 같은 일이 일어났기 때문일 것입니다), 이 작업을 다시 반복해야 할 것입니다.

지속 가능한 구분 방식은 다음과 같습니다. 규칙은 코딩 에디터가 바로 참조해야 하므로 리포지토리에 유지합니다. 규칙 뒤에 숨겨진 지식은 두 에디터 모두 소유하지 않는 제3의 장소에 보관하는 것입니다.

MemoryLake는 이를 위한 메모리 레이어입니다. 규칙의 기반이 되는 결정 사항, 장애 보고서, 원본 문서 등을 하나의 저장소에 보관하며, Claude 및 Codex와 같은 MCP 지원 도구에서 직접 읽을 수 있고, API를 통해 ChatGPT에서도 읽을 수 있습니다. .mdc 파일은 '무엇을 해야 하는지'를 알려주고, 저장소는 '왜 해야 하는지'를 설명하며 에디터의 변경과 무관하게 유지됩니다.

1단계: API 키 생성하기

키를 생성하고 약 30초 만에 첫 번째 요청을 보낼 수 있습니다. 이 키를 채팅 창에 붙여넣지 말고 환경 변수나 보안 비밀 관리자(secret manager)에 보관하세요.

2단계: 첫 번째 기억 업로드하기

방금 변환한 규칙의 배경이 되는 문서, 이미지, 파일을 업로드하세요. 특정 모듈을 금지하게 만든 장애 보고서, 아키텍처 결정 사항 및 날짜, 클라이언트 요구 사항, API 계약서, 그리고 수집한 Cascade 지식 등이 포함됩니다. 깔끔하게 정리된 요약본보다는 원본 소스를 업로드하세요. 요약본은 결국 1단계에서 재구성하려고 애썼던 바로 그 내용이기 때문입니다.

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

Claude, Codex, OpenClaw 및 기타 AI 에이전트에게 MCP 또는 API를 통해 메모리 접근 권한을 부여하세요. MCP 지원 도구는 자체 규칙 파일과 함께 동일한 저장소를 직접 읽습니다. ChatGPT의 경우, API를 통해 필요한 정보를 검색하여 프롬프트나 모델을 호출하는 워크플로우에 주입할 수 있습니다.

첫 번째 차이점은 Always Apply 규칙 세트를 작게 유지할 수 있다는 것입니다. 모든 것을 로드해야 한다는 압박은 정보를 둘 다른 곳이 없기 때문에 발생합니다. 세부 정보를 검색할 수 있게 되면, 항상 로드되는 규칙은 실제로 답변을 변화시키는 서너 개의 제약 조건으로 압축됩니다.

두 번째는 규칙과 함께 그 이유가 함께 전달된다는 점입니다. "generated/ 폴더의 파일을 수정하지 마세요"라는 규칙은 새로운 엔지니어나 새로운 에이전트가 올 때마다 의문을 제기받습니다. 하지만 티켓과 장애 이력이 첨부된 동일한 규칙은 의문이 제기되지 않으며, 이것이 단순한 관례와 유지되는 아키텍처 결정의 차이입니다.

세 번째는 정보 수집이 일회성 비용으로 끝난다는 점입니다. Cascade를 위해 이 작업을 수행했지만, Cursor를 위해서는 반복하지 않을 것입니다. 지식이 Cursor에 갇히지 않기 때문입니다. 이는 또한 지식이 여러분의 노트북에만 머무는 대신 팀원이 물어볼 때도 즉시 제공될 수 있음을 의미하며, 이는 기기 간에 공유되지 않는 규칙의 한계를 극복해 줍니다.

또한 이는 Cursor가 기본적으로 제공하는 기능과 유기적으로 결합됩니다. 규칙은 문서에 명시된 대로 프롬프트 수준에서 계속 제 역할을 수행합니다. 저장소는 규칙이 원래 담기 힘든 영역인 역사, 근거, 그리고 원본 문서 자체를 보관합니다.

앱 내부에 존재하는 것은 내보낼 수 없다고 가정하세요

규칙 파일은 여러분의 소유입니다. 하지만 어떤 도구에서든 생성된 기억(memories)은 일반적으로 그렇지 않습니다. 삭제하기 전에 어시스턴트에게 알고 있는 내용을 물어보고 답변을 복사해 두세요. UI에만 존재하는 모든 것은 사라지기 쉬운 것으로 취급해야 합니다.

텍스트뿐만 아니라 스코프도 변환하세요

이번 마이그레이션에서 가장 가치 있는 작업은 "이것은 프론트엔드 규칙입니다"를 globs: src/components/**/*.tsx로 바꾸는 것입니다. 경로 스코프가 지정된 규칙은 관련이 있을 때만 로드되고 그렇지 않을 때는 컨텍스트에서 제외되므로, 모델이 한정어를 알아차리기를 바라는 규칙보다 비용이 적게 들고 훨씬 정확합니다.

규칙을 커밋하고, 표준에는 팀 레이어를 사용하세요

버전 관리 하에 있는 규칙은 검토와 상속이 가능하지만, 개인 설정에 있는 규칙은 그렇지 않습니다. Team 또는 Enterprise 플랜을 사용하는 경우, 조직 전체의 표준을 팀 규칙에 두어 각 개발자의 로컬 설정에 의존하지 않도록 하세요.

마이그레이션 중에 삭제하세요

이전 규칙 중 오래된 것을 그대로 가져가면, 에이전트는 그것이 오래되었다는 사실을 모른 채 묵묵히 따를 것입니다. 여전히 필요한 규칙을 삭제했을 때의 비용은 다시 작성하는 데 걸리는 1분뿐입니다. 하지만 잘못된 규칙을 유지했을 때의 비용은 일주일 동안 혼란스러운 diff를 겪는 것입니다.

규칙을 강제 수단으로 취급하지 마세요

Cursor는 규칙이 프롬프트 수준에서 컨텍스트를 제공할 뿐이라고 명확히 밝히고 있습니다. 이는 영향력을 미칠 뿐 보장하는 것은 아닙니다. 포맷팅, main 브랜치로의 직접 푸시 금지, 생성된 파일 수정 금지 등 항상 준수되어야 하는 사항은 포맷터, 훅(hook), 또는 CI에 속해야 합니다. 규칙은 설명할 뿐이며, 강제는 도구가 수행합니다.

Windsurf에서 Cursor로의 전환은 단순한 파일 복사처럼 보이지만 그렇지 않습니다. 두 에디터 모두 VS Code 포크이므로 에디터 레이어는 자동으로 이동하지만, 중요한 부분인 각 규칙의 적용 시점은 Cursor의 방식에 맞게 재구축해야 합니다. 즉, frontmatter를 통해 Always Apply, 파일 패턴, 에이전트 선택, 또는 수동을 선택하는 .mdc 파일로 만들어야 합니다. 일반 .md 파일을 .cursor/rules에 복사하면 오류 메시지도 없이 완전히 무시됩니다.

따라서 올바른 순서로 두 가지 작업을 수행하세요. 삭제하기 전에 Cascade를 심문하세요. 자동으로 생성된 로컬 기억은 내보낼 수 없으며 두 번 다시 기회가 없기 때문입니다. 그런 다음 각 규칙을 적절한 활성화 모드로 재정의하고, 오래된 것은 삭제하고, 팀에 필요한 것은 커밋하며, 규칙 뒤에 숨겨진 추론 과정을 에디터 외부의 저장소에 보관하세요. 다음에 IDE를 변경할 때, 이 저장소 덕분에 일주일이 걸릴 작업이 반나절 만에 끝날 것입니다.