실제로 이전되는 것
Trae 측면. Trae는 프로젝트 수준 규칙을 .trae/project_rules.md에, 사용자 수준 규칙을 .trae/user_rules.md에 보관합니다. 또한 프로젝트 내에 .trae/rules/ 디렉토리를 생성하며, 그 아래의 하위 폴더로 규칙 파일을 구성할 수 있습니다. 시스템은 이 디렉토리들을 재귀적으로 읽습니다. 규칙은 채팅에서 #rulename으로 호출되며, 모든 것이 일반 Markdown으로 작성되어 버전 관리 및 팀 간 공유가 가능합니다. MCP 지원과 .rules는 Trae v1.3.0에서 함께 도입되었으므로, 구성해 둔 MCP 서버는 손실되는 것이 아니라 그대로 이어지는 개념입니다.
Cursor 측면. 프로젝트 규칙은 .cursor/rules에 .mdc 파일로 저장되며, 각 파일은 네 가지 활성화 모드(Always Apply, Apply Intelligently, Apply to Specific Files, Apply Manually) 중 하나를 가집니다. 또한 Cursor는 리포지토리 루트에 있는 일반 AGENTS.md 파일도 읽는데, 이는 Codex, Amp, Jules, Factory 등도 읽을 수 있는 개방형 포맷입니다. 커밋되지 않아야 하는 개인 설정은 Cursor 설정의 User Rules에 들어갑니다.
따라서 매핑은 다음과 같이 직접적으로 이루어집니다:
| Trae | Cursor |
|---|---|
.trae/project_rules.md | .cursor/rules/*.mdc 또는 루트 AGENTS.md |
.trae/user_rules.md | Cursor 설정의 User Rules |
.trae/rules/ 하위 폴더 | 관심사별로 분리된 개별 .mdc 파일 |
#rulename 호출 | Apply Manually 모드, 채팅에서 참조됨 |
| MCP 서버 | MCP 서버, Cursor에서 재구성 |
이전되지 않는 것. 고통스러운 순서대로 세 가지 카테고리가 있습니다:
- 세션 기록. Trae 대화는 Trae에 그대로 남습니다. 이를 대신 읽어주는 도구는 없습니다.
- 파일 대신 채팅에 남겨둔 모든 것. 대부분의 사람들은 실제로 기록하는 것보다 세션당 훨씬 더 많은 내용을 설명합니다. 그 설명은 어디에도 저장되지 않았습니다.
- 거부된 접근 방식. 잃어버리기에 가장 뼈아픈 부분입니다. Cursor는 여러분이 이미 시도했다가 되돌린 리팩토링을 기꺼이 제안할 것이고, 여러분은 이미 결론이 난 문제를 다시 결정하느라 오후 시간을 통째로 날리게 될 것입니다.
Trae 커뮤니티가 이에 대처하기 위해 만든 것을 주목할 가치가 있습니다. 세션 연속성을 수동으로 관리해야 했기 때문에, 한 명령어로 컨텍스트를 저장하고 다른 명령어로 복원하는 Trae용 서드파티 워크플로우 연속성 패키지들이 존재합니다. 만약 이러한 도구를 사용해 왔다면, 저장된 파일들이 이번 마이그레이션을 위한 가장 좋은 원천 자료가 될 것입니다.
수동 마이그레이션
1단계: 규칙 이동 및 분할
하나의 긴 project_rules.md를 하나의 긴 .mdc에 그대로 붙여넣지 마세요. Cursor의 활성화 모드는 규칙이 관심사별로 분리되어 있을 때만 유용합니다.
.trae/project_rules.md를 읽고 빌드 및 테스트 명령, 디렉토리 컨벤션, 스타일, 보안 제약 조건, 특정 하위 시스템에 관한 내용 등의 주제로 분할하세요..cursor/rules에 주제별로 하나의.mdc를 생성하고 활성화 모드를 신중하게 설정하세요. 보편적인 제약 조건은 Always Apply로 설정합니다. 특정 하위 시스템에 특화된 규칙은 glob 패턴과 함께 Apply to Specific Files로 설정합니다. 릴리스 체크리스트나 마이그레이션 절차와 같이 가끔 사용하는 플레이북은 Apply Manually로 설정하고, Trae에서#rulename을 사용했던 것처럼 필요할 때 호출하여 사용합니다.- 모든 것을 Always Apply로 설정하지 마세요. 그렇게 하고 싶은 유혹이 생기겠지만 비용이 많이 듭니다. 항상 켜져 있는 모든 규칙은 매 완료(completion)마다 토큰을 소비합니다. 이는 규칙 마이그레이션에서 가장 흔히 발생하는 실수이며, 오류가 아니라 청구서로 그 결과가 나타납니다.
.trae/user_rules.md를 리포지토리에 커밋하는 대신 Cursor의 User Rules로 이동하세요. 개인적인 선호도는 리포지토리에 포함되어서는 안 됩니다.- 여러 에이전트가 프로젝트를 다룰 가능성이 있다면, Cursor를 비롯한 여러 에이전트가 읽을 수 있도록 도구 중립적인 핵심 내용을 루트
AGENTS.md에 배치하는 것을 고려해 보세요. - Cursor에서 MCP 서버를 재구성하고, 사용하기 전에 각 서버가 제대로 응답하는지 확인하세요.
2단계: 규칙이 담지 못했던 지식 재구축
한 시간 정도 시간을 내어 Trae 세션에만 존재했던 지식을 기록해 보세요.
- 결정 사항 및 그 이유. "환불 처리에 순서가 중요하므로 큐 컨슈머는 싱글 스레드로 유지됨"과 같은 단 한 줄의 기록이 향후 1년 동안 잘못된 제안을 방지할 수 있습니다.
- 막다른 길(실패한 시도). 시도했다가 되돌린 접근 방식과 그 이유를 기록하세요. 이것이 무한 루프를 멈추는 열쇠입니다.
- 로컬 트랩(주의해야 할 함정). Windows에서 불안정한 테스트, 절대 수동으로 편집해서는 안 되는 생성된 파일, 시드 데이터 실행 전에 실행되어야 하는 마이그레이션 등입니다.
- 저장된 컨텍스트 파일의 모든 내용. Trae 연속성 워크플로우를 사용했다면 지금 해당 아카이브를 발굴하세요. 그것이 여러분이 가진 세션의 유일한 서면 기록입니다.
이것을 규칙이 아닌 지식으로 작성하세요. 매주 늘어나는 이 지식들은 항상 켜져 있는 .mdc에 속하지 않습니다. 매 완료마다 900줄짜리 서문을 위해 비용을 지불하고 싶어 하는 사람은 아무도 없기 때문입니다.
더 나은 방법: 에디터에 구애받지 않는 단일 메모리 레이어
그렇다면 당연한 질문이 생깁니다. 이 지식들은 어디에 보관해야 할까요?
두 에디터 모두 규칙 파일과 매 세션마다 제공되는 새로운 컨텍스트라는 동일한 두 가지를 제공합니다. 이것이 마이그레이션이 쉬운 이유이자 동시에 손실이 발생하는 이유입니다. 규칙은 제약 조건을 담기에는 적합하지만 축적된 지식을 담기에는 적합하지 않으며, Trae와 Cursor 모두 이를 보관할 제3의 장소를 제공하지 않습니다. 결국 지식은 채팅에 남게 되고, 세션이 끝나면 채팅도 끝납니다.
해결책은 더 긴 규칙 파일을 작성하는 것이 아니라 누락된 레이어를 추가하는 것입니다. MemoryLake는 에디터 외부에 존재하며 MCP 또는 API를 통해 액세스할 수 있는 메모리 레이어입니다. 이를 통해 지식은 특정 에디터에 종속되지 않게 되며, 다음 마이그레이션이 고고학 발굴 작업처럼 변하는 것을 방지할 수 있습니다.
1단계: API 키 생성
키를 생성하고 약 30초 만에 첫 번째 요청을 완료하세요.
2단계: 첫 번째 메모리 업로드
방금 작성한 결정 로그와 사람들이 계속해서 다시 설명해야 하는 자료(아키텍처 노트, API 계약서, 런북, 장애 보고서, 다이어그램 등)를 로드하세요. 문서, 이미지 및 기타 파일이 모두 동일한 위치로 이동합니다.
3단계: AI 및 에이전트 연결
Cursor, Claude, Codex, OpenClaw 및 기타 에이전트에 MCP를 통해 액세스 권한을 부여하세요. .cursor/rules 파일은 다시 짧고 규칙다운 형태로 돌아가며, 매주 늘어나는 지식은 내년에 어떤 에디터를 사용하든 모든 도구가 쿼리할 수 있는 곳에 보관됩니다.
실제 변화하는 점
첫 번째 차이점은 비용이며, 이는 측정 가능합니다. 규칙 파일은 이중 역할을 수행하느라 비대해지고, 항상 켜져 있는 규칙은 매 완료마다 비용이 청구됩니다. 지식을 규칙에서 분리하여 쿼리 가능한 레이어로 이동하면 요청당 지불하는 비용은 줄어들고, 에이전트가 실제로 필요할 때 찾을 수 있는 정보는 늘어납니다.
두 번째는 전환이 일방통행이 되지 않는다는 점입니다. 현재로서는 Cursor가 마음에 들지 않아 되돌아가려면 또 다른 수동 재구축 작업을 거쳐야 하므로, 사람들은 자신에게 맞지 않는 도구를 계속 사용하게 됩니다. 지식이 외부에 있으면 2주 동안 다른 에디터를 평가하는 데 드는 비용은 설정 변경 한 번뿐입니다.
세 번째는 팀의 일관성입니다. 리포지토리의 규칙 파일은 공유되지만, 여러분이 Trae 채팅에 입력한 컨텍스트는 공유되지 않았습니다. 세 명의 개발자가 아키텍처가 왜 이렇게 구성되었는지에 대해 서로 다른 멘탈 모델을 가지고 있다면, 그들의 에이전트는 세 가지 서로 다른 종류의 코드를 생성하게 됩니다. 이는 Cursor가 여러 기기에서 컨텍스트를 잊어버리는 문제와 동일한 실패가 사람들에게 분산되어 나타나는 것과 같습니다.
이동 후 모범 사례
첫째 주에 규칙 모드 감사하기
모든 .mdc 파일을 열고 활성화 모드가 실제로 필요한 빈도와 일치하는지 확인하세요. 보편적인 제약 조건이 아닌데 Always Apply로 설정되어 있는 것은 모두 등급을 낮추어야 합니다. Cursor가 네 가지 모드를 제공하는 데는 이유가 있으며, 이를 제대로 활용하지 못하면 규칙 파일로 인해 조용히 비용이 증가하게 됩니다.
지식 로그는 세 개의 파일이 아닌 한 곳에 보관하기
마이그레이션 후에는 README, 주석, 규칙 파일 등에 메모를 분산시키고 싶은 유혹이 생기립니다. 축적된 지식을 위한 단 하나의 보금자리를 선택하고 모든 것을 그곳으로 모으세요. 파편화된 지식은 기능적으로 지식이 없는 것과 같습니다. 그 누구도 그 지식 전체를 검색할 수 없기 때문입니다.
2주 동안은 Trae 설정을 삭제하지 마세요
실제 디버깅 세션을 포함하여 Cursor에서 일주일 동안 완전히 작업해 볼 때까지 .trae/ 디렉토리와 Trae 설치 상태를 유지하세요. 마이그레이션의 공백은 첫 한 시간 동안에는 절대 나타나지 않으며, 당연히 이전되었을 것이라고 생각했던 무언가가 처음으로 필요할 때 나타납니다. 이러한 주의 사항은 Copilot에서 Cursor로 전환하거나 Cursor 규칙을 Claude Code로 가져가는 것을 포함하여 모든 에디터 이동에 동일하게 적용됩니다.
결론
Trae에서 Cursor로의 전환은 가장 쉬운 에디터 마이그레이션 중 하나입니다. 두 에디터 모두 Markdown으로 지침을 유지하고, 규칙 디렉토리를 읽으며, MCP를 지원합니다. .trae/project_rules.md를 개별 .mdc 파일로 분할하고, 모든 것을 기본값인 Always Apply로 설정하는 대신 활성화 모드를 신중하게 지정하고, 사용자 규칙을 Cursor 설정으로 이동한 후 MCP 서버를 다시 연결하세요.
그런 다음, 절약된 노력을 파일 매핑이 해결해 주지 못하는 부분에 투자하세요. 두 에디터 모두 세션을 통해 배운 내용을 저장하지 않으므로, 결정 사항과 막다른 길(실패한 시도)은 누군가 직접 기록해야 합니다. 그리고 이를 항상 켜져 있는 규칙 파일에 작성하면 매 완료마다 비용을 지불해야 하고 다음 마이그레이션 때 결국 다시 잃어버리게 됩니다. 에디터 외부의 메모리 레이어는 컨텍스트를 매번 재구축하는 것이 아니라 계속 유지할 수 있도록 만들어 줍니다. 이는 궁극적으로 Trae가 세션 간에 컨텍스트를 잊어버리는 문제 및 Cursor가 이전 세션을 잊어버리는 문제의 이면에 있는 것과 동일한 공백입니다.