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

이름 변경과 4줄의 프론트매터만 추가하면 스티어링 파일을 그대로 사용할 수 있습니다. 이것이 마이그레이션의 핵심이며, 매핑 관계도 깔끔합니다:

두 도구 모두 내부적으로 동일한 방식으로 작동합니다. Kiro의 auto 모드는 "설명(description)을 사용하여 스티어링 파일이 관련이 있는 시점을 결정"합니다. Cursor의 동등한 기능은 "규칙의 설명이 Cursor Agent에게 제공되어 적용 여부를 결정"하는 것입니다. Kiro의 manual 파일은 #steering-file-name으로 불러오고, Cursor의 파일은 @ 언급으로 불러옵니다. 각 파일의 이름을 .mdc로 변경하고 일치하는 프론트매터를 추가하면 이전과 동일하게 작동합니다.

기반 파일(foundation files)은 항상 켜져 있는 규칙(always-on rules)으로 변환됩니다. Kiro의 product.md, tech.md, structure.md는 "기본적으로 모든 상호작용에 포함"됩니다. 이 파일들은 alwaysApply: true 규칙이 됩니다. 하지만 변환하기 전에 한 번 읽어보세요. Kiro 자체의 스티어링 가이드라인은 코드베이스가 이미 명시하고 있는 내용을 중복해서 작성하지 말라고 경고하며, Cursor의 규칙 문서도 동일한 조언을 합니다. 대부분 디렉토리 목록으로 채워진 structure.md는 이식하기보다는 정리하는 것이 좋습니다. 그 이유는 Cursor가 프로젝트의 파일 구조를 기억하게 만드는 방법에서 확인할 수 있습니다.

AGENTS.md는 변경 없이 그대로 유지됩니다. 두 도구 모두 이를 지원합니다. Kiro는 워크스페이스 루트, ~/.kiro/steering/, 하위 디렉토리에서 이를 로드하며, "AGENTS.md 파일은 포함 모드를 지원하지 않으며 항상 포함된다"고 명시합니다. Cursor는 "프로젝트 루트 및 하위 디렉토리에서 AGENTS.md를 지원"하며, .mdc 규칙의 일반 마크다운 대안으로 명시적으로 권장합니다. 대부분의 스티어링이 어차피 항상 켜져 있는 방식이었다면, AGENTS.md가 더 마찰이 적은 선택지입니다.

Skills는 디렉토리를 이동하거나 그대로 두면 됩니다. Cursor는 .agents/skills/, .cursor/skills/, ~/.agents/skills/, ~/.cursor/skills/뿐만 아니라 호환성을 위해 .claude/skills/, .codex/skills/, ~/.claude/skills/, ~/.codex/skills/도 읽습니다. 두 도구 모두 동일한 오픈 Agent Skills 표준을 기반으로 하므로 SKILL.md 파일은 그대로 유지됩니다. 한 가지 동작상의 차이점은, /로 호출된 Cursor skill은 "단일 메시지에만 첨부"되며, 전체 세션 동안 유지하려면 Option+Enter를 눌러 Custom Mode로 실행해야 한다는 점입니다.

스펙(specs)은 파일로 남지만 워크플로우는 유지되지 않습니다. Kiro 스펙은 .kiro/specs/<name>/에 requirements.md(또는 bugfix.md), design.md, tasks.md로 저장됩니다. 이 파일들은 리포지토리 내의 마크다운 파일이므로 마이그레이션 후에도 그대로 유지되고 읽을 수 있습니다. 하지만 승인 단계(approval gates)와 실시간 작업 상태가 포함된 '요구사항-설계-작업'으로 이어지는 3단계 워크플로우는 유지되지 않습니다.

Cursor에서 가장 유사한 기능은 Plan Mode이며, 꽤 유용합니다. 이 모드는 "코드를 작성하기 전에 상세한 구현 계획을 생성"하고, "채팅이나 마크다운 파일을 통해 계획을 검토 및 수정"할 수 있으며, 정제된 계획에서 되돌리거나 다시 실행할 수 있습니다. 하지만 결과물이 저장되는 위치에 유의해야 합니다. "계획은 기본적으로 홈 디렉토리에 저장됩니다. 향후 참조, 팀 공유 및 문서화를 위해 워크스페이스로 이동하려면 'Save to workspace'를 클릭하세요." Kiro 스펙은 기본적으로 리포지토리에 저장되었지만, Cursor 계획은 기본적으로 홈 디렉토리에 저장됩니다. 이 기본값의 차이가 팀의 자산이 되느냐 개인의 자산이 되느냐를 가릅니다.

그 외에는 아무것도 이전되지 않으며, 이는 아키텍처적인 이유 때문입니다. Kiro는 3개의 메모리 영역을 유지합니다. 반면 Cursor의 문서 인덱스에는 메모리 관련 페이지가 없습니다.

Kiro Crew의 6개 레이어는 갈 곳이 없습니다. Crew는 preferences.md 및 projects.md(둘 다 30개의 메시지마다 통합기에 의해 전체 교체됨), 단계적 감쇠가 적용되는 history/ 디렉토리, SQLite 시맨틱 저장소, 벡터 검색 기능이 있는 에피소드 저장소, 학습된 교정 사항을 위한 lessons 저장소를 유지합니다. 각 레이어에는 글자 수 제한과 고유한 감쇠 규칙이 있습니다. 예를 들어 history는 14일이 지나면 "하루에 첫 번째 항목 + 개수"로 줄어들고, 181일이 지나면 로드를 중단하며, 365일이 지나면 "디스크에서 삭제"됩니다. Lessons는 최대 50개 항목으로 제한되며 "사용자가 명시한 것이 항상 우선함"으로 표시됩니다. 이는 정교한 메모리 시스템이지만, Cursor에는 이를 수용할 컨테이너가 없습니다.

Kiro Web의 학습된 메모리 역시 이전되지 않습니다. 이는 풀 리퀘스트에 대한 사용자의 피드백("작업을 생성한 사용자인 귀하의 피드백만이 에이전트가 학습하는 내용에 영향을 미칩니다")을 바탕으로 구축되며, 이에 대한 사용자의 제어 권한은 삭제로 제한됩니다.

Crew 스냅샷은 백업용일 뿐, 내보내기 파일이 아닙니다. kirocrew snapshot은 메모리, 워크스페이스, 크론, 설정, skills, 알림을 포함하는 단일 타르볼(tarball)을 생성합니다. 이는 머신 간에 이동할 때 적합한 방법이며, Kiro도 그렇게 문서화하고 있습니다. 하지만 Kiro만 이를 읽을 수 있으므로, 이는 떠나기 전의 안전한 복사본일 뿐 새로 전환할 도구를 위한 가져오기 파일이 아닙니다. 주의해서 다루세요. Kiro는 "스냅샷에는 민감한 데이터(감사 로그 무결성에 사용되는 보안 키)가 포함되어 있습니다"라고 경고합니다.

1단계: 스냅샷을 찍고, 곧 잃게 될 레이어 읽기

다른 작업을 하기 전에 먼저 kirocrew snapshot ~/migrate를 실행하세요. Cursor가 이를 읽을 수 없더라도 복사본은 필요합니다. 게다가 Crew의 내장 일일 작업은 "마지막 7개의 스냅샷만 유지"하므로 어제의 스냅샷이 아직 남아 있을 것이라 가정하지 마세요.

그다음, 복사하기보다는 읽어보세요. ~/.kiro/crew/workspace/memory/preferences.md와 projects.md를 엽니다. 이 두 파일은 "추가 전용이 아니라 30개의 메시지마다 통합기에 의해 전체 교체"되므로, 로그가 아니라 Crew가 파악한 귀하에 대한 현재 스냅샷입니다. 이 파일들에 담긴 내용은 Crew가 지금 중요하다고 판단한 것이므로, 짧지만 매우 유용한 정보가 담겨 있습니다.

그다음 최대 50개로 제한된 lessons(학습된 교정 사항)를 살펴보세요. 이는 귀하가 Crew에게 항상 하라고 지시했거나 그렇게 하도록 교정한 내용들입니다. 리포지토리의 그 어떤 파일도 이를 암시하지 않으므로, Cursor의 그 어떤 기능도 이를 자동으로 재구성해주지 않습니다.

또한 ~/.kiro/steering/에 있는 글로벌 스티어링도 확인하세요. Kiro는 충돌이 발생할 때 글로벌 스티어링보다 워크스페이스 스티어링을 우선시하여 해결합니다. Cursor의 우선순위는 "Team Rules → Project Rules → User Rules" 순이며, "지침이 충돌할 때 이전 소스가 우선 적용"됩니다. 프로젝트 규칙이 여전히 개인 규칙보다 우선하므로 이 동작의 절반은 유지되지만, Cursor의 Team Rules를 사용한다면 이제 두 규칙보다 더 높은 순위의 새로운 레이어가 생기는 셈입니다.

2단계: 스티어링을 .mdc로 변환하고, 일반 텍스트로 남겨둘 것 선택하기

.kiro/steering/에 있는 각 파일의 프론트매터를 읽고 위의 표에서 해당하는 행을 찾아 Cursor에 맞게 작성하세요. fileMatch 파일은 globs 값이 되고, auto 파일은 description을 유지하고 name을 삭제하며, 항상 켜져 있는 파일은 alwaysApply: true가 되고 둘 다 필요하지 않습니다.

기계적으로 처리하기보다 수동으로 변환하는 것이 좋은 두 가지 사항은 다음과 같습니다.

파일 참조가 작동하지 않게 됩니다. Kiro 스티어링은 #[[file:api/openapi.yaml]]을 통해 실제 파일을 임베드할 수 있어, 파일이 변경되어도 스티어링 텍스트가 최신 상태로 유지되었습니다. Cursor 규칙에는 이와 동등한 지시어가 없습니다. 콘텐츠를 인라인으로 직접 작성하고(최신 상태 유지를 포기해야 함) 아니면 텍스트로 경로를 참조하여 에이전트가 직접 읽도록 하세요.

커스텀 에이전트 리소스 목록에 대응하는 기능이 없습니다. Kiro 커스텀 에이전트를 구성한 경우, "스티어링 파일이 자동으로 포함되지 않기" 때문에 종종 {"resources": ["file://.kiro/steering/**/*.md"]}와 같이 명시적으로 목록을 작성해야 했습니다. Cursor는 모드와 관계없이 프론트매터에 따라 규칙을 적용하므로, 이러한 명시적 리소스 목록은 변환할 대상이 없습니다. 특정 에이전트가 의도적으로 스티어링 없이 실행되고 있었는지 확인해 보세요. 그 의도는 이전되지 않기 때문입니다.

대부분의 스티어링이 항상 켜져 있는 일반 텍스트 형태였다면, 해당 파일들에 대해 .mdc를 건너뛰고 내용을 AGENTS.md에 넣는 것을 진심으로 권장합니다. Cursor 문서에서도 "구조화된 규칙의 오버헤드 없이 간단하고 읽기 쉬운 지침이 필요한 프로젝트"에는 이 방식을 권장합니다. .mdc는 globs나 설명이 정말로 필요한 파일에만 사용하세요.

팀을 이전하는 경우 마지막으로 주의할 점은, Kiro의 팀 스티어링은 "MDM 솔루션이나 그룹 정책을 통해" 머신에 파일을 배포하는 방식이었습니다. Cursor의 Team Rules는 Team 및 Enterprise 플랜의 대시보드에서 관리되며, "해당 팀의 모든 리포지토리 및 프로젝트에 적용"되고, 멤버가 끌 수 없도록 "Enforce this rule"로 표시할 수 있습니다. 이는 더 나은 메커니즘이지만 자유 형식의 텍스트입니다. Team Rules는 "Project Rules의 폴더 구조를 사용하지 않으므로" 스티어링 파일 디렉토리를 단일 텍스트로 평탄화(flatten)해야 합니다.

이 마이그레이션의 두 부분이 어떻게 다르게 작동했는지 주목해 보세요. 직접 작성한 모든 것은 이동했습니다. 스티어링은 규칙이 되었고, AGENTS.md는 그대로 유지되었으며, skills는 변경이 필요 없었고, 스펙은 읽기 쉬운 상태로 남았습니다. 반면 도구가 학습한 모든 것은 전혀 이동하지 않았습니다.

이러한 분리는 Kiro나 Cursor만의 문제가 아닙니다. Kiro는 정교한 학습 메모리 시스템을 구축하여 ~/.kiro/ 아래에 보관합니다. Cursor는 의도적으로 다른 선택을 했습니다. 영구적인 컨텍스트는 버전 관리되는 규칙 파일과 skills에 존재하므로 규칙을 검토할 수 있으며 문서에 메모리 페이지가 없습니다. 둘 다 일관성 있는 설계입니다. 하지만 특정 접근 방식을 거부한 이유에 대한 유일한 복사본을 보관하기에 두 곳 모두 좋은 장소는 아닙니다.

그것이 바로 MemoryLake가 제공하는 역할입니다. 도구가 쿼리하는 레이어에 프로젝트의 영구 지식을 보관하므로, 학습된 데이터가 우연히 열어본 에디터의 종속 속성이 되지 않도록 합니다. 설정은 3단계로 진행됩니다.

Step 1: Create an API key

로그인하고 API 키를 생성합니다. 연결하는 도구 전체에서 하나의 자격 증명만 사용하면 됩니다.

Step 2: Upload your first memories

각각 하나의 주장(claim)을 담은 짧은 항목들을 작성합니다. 1단계에서 읽은 내용을 바탕으로 바로 작성해 보세요.

Lessons를 항목당 하나씩 입력합니다. Crew에서 최대 50개로 제한되었던 학습된 교정 사항들입니다. 이는 귀하가 소유한 가장 가치 있고 복구하기 어려운 정보입니다.

preferences.md와 projects.md의 현재 내용. 실시간 스냅샷이므로 내용이 짧습니다. 파일을 그대로 붙여넣기보다는 개별 주장으로 나누어 입력하세요.

이유가 첨부된 결정 사항들. "부하가 걸릴 때 복제본(replica)이 지연되므로 쓰기 작업을 큐에 대기시킵니다." 규칙은 정책을 명시할 뿐이며, 대안이 다시 채택되는 것을 막는 것은 오직 그 '이유'뿐입니다.

이 코드베이스에서 이미 거부된 접근 방식들. 스티어링 파일, 규칙, 커밋 메시지 그 어디에도 나타나지 않는 카테고리입니다.

Step 3: Connect your AI & agents

사용 중인 도구를 연결합니다. MemoryLake는 MCP 및 API를 통해 액세스할 수 있으며, Kiro와 Cursor 모두 MCP 서버를 지원합니다. 따라서 전환 기간 동안 동일한 추론의 복사본을 두 개 유지할 필요 없이 두 도구를 나란히 실행할 수 있으며, 다른 어시스턴트들도 API를 통해 동일한 메모리를 읽을 수 있습니다.

세 가지 명확한 한계가 있습니다. MemoryLake는 Crew 스냅샷을 읽거나, Kiro Web의 학습된 메모리를 가져오거나, .mdc 파일을 작성할 수 없습니다. 이는 Kiro의 포맷이자 Cursor의 스티어링 영역이기 때문입니다. MemoryLake는 귀하 또는 에이전트가 입력한 내용만 보관하므로 2단계는 수동으로 진행해야 합니다. 또한 규칙은 강제된 구성이 아니라 컨텍스트에 가깝습니다. 매번 반드시 준수해야 하는 사항은 메모리 레이어가 아니라 강제 적용(enforcement)이 활성화된 Cursor의 Team Rules에 두어야 합니다.

스티어링 변환이 판단의 영역이 아닌 단순 조회가 됩니다. 4가지 모드, 4가지 규칙 유형, 단 하나의 표로 정리됩니다.

자동으로 무시되는 현상이 사라집니다. .cursor/rules에 있는 일반 .md 파일은 무시됩니다. 이제 배포하기 전에 이를 알 수 있습니다.

스펙은 읽기 쉬운 상태로 유지되며, 워크플로우는 직접 결정합니다. 파일은 보존되지만 승인 단계는 사라집니다.

계획은 의도적으로 저장해야 합니다. Cursor 계획은 기본적으로 홈 디렉토리에 저장되므로, 'Save to workspace'를 클릭해야 팀의 자산이 됩니다.

Skills가 특정 도구에 종속되지 않습니다. 동일한 SKILL.md가 Kiro, Cursor, Claude Code, Codex에서 모두 실행됩니다.

메모리 감쇠가 더 이상 예기치 않은 일이 되지 않습니다. Crew의 history는 14일이 지나면 세부 정보를 누락하고 365일이 지나면 삭제하고 있었습니다. 이는 보존 점수가 매겨진 메모리 트리가 보여준 것에서 다룬 것처럼 그 자체로 이해할 가치가 있는 동작입니다.

시작하기 전에 스냅샷을 찍고, tarball을 공유 드라이브에 두지 마세요. Kiro는 스냅샷에 민감한 키가 포함되어 있다고 경고합니다.

preferences.md, projects.md 및 lessons를 읽어보세요. 전체 교체되는 파일들은 구조상 짧게 작성됩니다. 이를 건너뛸 이유가 없습니다.

.mdc로 이름을 바꾸고 프론트매터를 추가하거나, 내용을 AGENTS.md로 이동하세요. 실제로 로드되는 유일한 두 가지 옵션입니다.

항상 켜져 있는 일반 텍침에는 AGENTS.md를 우선적으로 사용하세요. Cursor가 이를 권장하며, 전환 기간 동안 두 도구 모두에서 작동합니다.

#[[file:…]] 참조는 의도적으로 변환하세요. 인라인화하면 정보가 오래되고, 텍스트 참조를 사용하면 최신 상태를 유지할 수 있습니다.

structure.md를 이식하기보다 정리하세요. 두 도구의 제공업체 모두 코드베이스를 그대로 중복 기술하는 것을 권장하지 않습니다.

Team Rules를 다루기 전에 팀 스티어링을 평탄화하세요. 폴더 구조가 아닌 자유 형식의 텍스트이기 때문입니다.

항상 켜져 있는 규칙에서 추론 과정을 제외하세요. 모든 도구는 전달하는 정보의 양을 제한하며 추론 과정이 가장 먼저 잘려 나갑니다. 이는 코딩 에이전트가 실제로 읽는 것에서 다룬 일반적인 문제입니다.

Kiro에서 Cursor로의 전환은 난이도가 매우 다른 두 가지 마이그레이션으로 나뉩니다. 문서화된 부분은 거의 기계적입니다. 4가지 스티어링 포함 모드가 4가지 Cursor 규칙 유형에 매핑되고, AGENTS.md는 양쪽 모두에서 작동하며, SKILL.md 파일은 변경이 필요 없고, 스펙은 리포지토리에 읽기 쉬운 마크다운으로 유지됩니다. 한 가지 발목을 잡을 수 있는 부분은 파일 확장자입니다. .cursor/rules에 있는 일반 .md 파일은 에러 표시도 없이 완전히 무시됩니다.

학습된 부분은 전혀 마이그레이션되지 않습니다. Kiro Crew는 홈 디렉토리 아래에 각각 고유한 제한 및 감쇠 일정을 가진 6개의 메모리 레이어를 유지하며, Kiro Web에는 PR 피드백을 바탕으로 구축된 별도의 학습 메모리가 있습니다. Cursor의 문서 인덱스에는 메모리 페이지가 없는데, 이는 영구적인 컨텍스트를 버전 관리되는 규칙과 skills에 대신 두도록 설계되었기 때문입니다. kirocrew snapshot은 Kiro만 읽을 수 있는 완전한 백업을 제공합니다.

따라서 스냅샷을 찍고, Crew가 파악한 귀하에 대한 현재 모델이 담긴 세 개의 파일을 읽고, 표를 참고하여 스티어링을 변환하고, 파일별로 .mdc와 AGENTS.md 중 무엇을 사용할지 결정한 다음, lessons와 거부된 접근 방식을 두 에디터 모두 쿼리할 수 있는 곳에 보관하세요. 그렇게 하면 다음 도구 전환은 기억 상실 사건이 아닌 단순한 선호도의 선택이 될 것입니다.