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

각 도구의 공식 문서 내용부터 시작해 보겠습니다. 격차는 대부분의 사람들이 예상하는 곳에 있지 않기 때문입니다.

Cursor의 규칙 문서는 규칙의 목적과 존재 이유를 명확히 설명합니다:

"대규모 언어 모델은 완료(completion) 간에 메모리를 유지하지 않습니다. 규칙은 프롬프트 수준에서 지속적이고 재사용 가능한 컨텍스트를 제공합니다."

규칙은 컨텍스트로 주입됩니다: "적용될 때, 규칙 내용은 모델 컨텍스트의 시작 부분에 포함됩니다." 각 프로젝트 규칙은 프론트매터(frontmatter)가 포함된 .mdc 파일이며, 프론트매터 필드는 네 가지 적용 유형 중 하나를 결정합니다. 즉, Always Apply, Apply Intelligently ("설명을 기반으로 Agent가 관련이 있다고 판단할 때"), glob 패턴을 통한 Apply to Specific Files, 그리고 @ 언급을 통한 Apply Manually입니다. Cursor는 또한 우선순위 체인을 명시하고 있습니다: "규칙은 Team Rules → Project Rules → User Rules 순서로 적용됩니다. 적용 가능한 모든 규칙이 병합되며, 가이드라인이 충돌할 때는 이전 소스가 우선합니다."

Amazon Q Developer의 프로젝트 규칙은 폴더 내에 존재하며 일반 Markdown 파일입니다:

"프로젝트 규칙은 프로젝트의 {{project-root}}/.amazonq/rules 폴더에 있는 Markdown 파일에 정의됩니다."

그리고 이 규칙들은 선언된 조건 없이 적용됩니다:

"프로젝트 규칙을 생성하면, 개발자가 프로젝트 내에서 Amazon Q와 채팅할 때마다 Amazon Q가 이를 컨텍스트로 자동 사용하며, 답변을 생성할 때 규칙을 준수하도록 합니다."

제어 영역은 채팅 패널의 Rules 버튼으로, 규칙 목록을 보여주고 현재 세션에 대해 각 규칙을 토글할 수 있게 해줍니다: "체크 표시가 있는 규칙이 활성화되어 대화에 적용됩니다." 동일한 .amazonq/rules 폴더가 GitLab 및 GitHub의 Amazon Q Developer용으로도 문서화되어 있으므로, 이 레이어는 IDE 전용이 아닙니다.

따라서 전송은 다음과 같이 이루어집니다. 규칙 내용(content)은 깔끔하게 전송됩니다. 양쪽 모두 Markdown 파일의 텍스트이기 때문입니다. 하지만 규칙 조건성(conditionality)은 전송되지 않습니다. Cursor의 네 가지 적용 유형은 문서화된 하나의 동작과 세션별 체크박스로 축소됩니다. Amazon Q의 프로젝트 규칙 문서에는 glob 매칭, 설명 기반 검색, 또는 수동 @ 호출을 위한 프론트매터 필드에 대한 설명이 전혀 없습니다.

전송되지 않는 두 번째 사항이 있으며, 이는 계획을 세울 때 고려해야 할 가치가 있습니다. Amazon Q는 자체적으로 생성된 컨텍스트 레이어를 가지고 있으며, 이는 마이그레이션하려는 동일한 폴더 내에 저장됩니다.

두 단계로 진행됩니다. 첫 번째는 기계적인 작업이고, 두 번째는 사람들이 흔히 건너뛰는 단계입니다.

1단계: 프론트매터 제거 및 본문에 조건 통합하기

Cursor는 파일 확장자에 대해 엄격합니다: "각 규칙은 원하는 이름으로 지정할 수 있는 .mdc 파일입니다. 프로젝트 규칙은 반드시 .mdc 확장자를 사용해야 합니다. .cursor/rules에 있는 일반 .md 파일은 description, globs, alwaysApply를 지정하는 프론트매터가 없기 때문에 규칙 시스템에서 무시됩니다."

Amazon Q는 반대 방향으로 똑같이 명확합니다. 규칙 파일은 .amazonq/rules 내의 "Markdown 파일이어야 하며", 문서는 프론트매터가 없는 일반 텍스트를 보여줍니다.

리터럴 값의 함정이 바로 여기에 있습니다. .cursor/rules/api.mdc를 변경 없이 .amazonq/rules/api.md로 복사하면, description, globs, alwaysApply라는 세 줄의 YAML을 해당 필드를 사용할 기능이 없는 파일로 가져가게 됩니다. Amazon Q는 에러를 발생시키지 않습니다. 프론트매터를 규칙 텍스트의 일부로 처리할 뿐이며, 해당 필드가 표현하던 조건성은 단순히 존재하지 않게 됩니다.

따라서 규칙별로 다음과 같이 수행하세요:

Always Apply였던 규칙의 경우, 프론트매터를 삭제하고 넘어가면 됩니다. 이는 깔끔하게 이식됩니다. Cursor에서도 무조건적이었고 Amazon Q에서도 무조건적입니다.

Apply to Specific Files였던 규칙의 경우, 프론트매터를 삭제하고 규칙 자체의 첫 번째 문장에 범위를 작성하세요. glob이 **/*.test.ts였던 규칙은 테스트 파일을 대상으로 명시하는 문장으로 시작하는 규칙이 됩니다. 기계가 강제하던 조건을 서술형 조건으로 변환하는 것이며, 정밀도 면에서 하향 조정된다는 점을 솔직히 인정해야 합니다. 이제 모델은 매칭된 경로가 아니라 작성된 문구를 보고 관련성을 결정합니다.

Apply Intelligently였던 규칙의 경우, description 필드가 검색 신호였습니다. 이를 시작 문장에 통합하세요. 이제 메타데이터가 아닌 일반 텍스트로서 역할을 해야 하기 때문입니다.

Apply Manually였던 규칙의 경우, 실제로 항상 켜두고 싶은지 결정하세요. 이 중 일부는 기본적으로 실행되어서는 안 되기 때문에 존재합니다. 이러한 규칙들은 .amazonq/rules에서 완전히 제외하고 의도적으로 호출할 수 있는 다른 곳에 보관하는 것이 좋습니다.

Cursor의 자체 작성 권장 사항은 마이그레이션 후에도 유효하므로 계속 따르는 것이 좋습니다. 규칙을 500줄 미만으로 유지하고, "콘텐츠를 복사하는 대신 파일을 참조하세요. 이렇게 하면 규칙을 짧게 유지하고 코드가 변경됨에 따라 규칙이 오래된 상태가 되는 것을 방지할 수 있습니다."

이전에 규칙 변환을 해본 적이 있다면 이 형태가 익숙할 것입니다. moving Cursor rules to a Codex AGENTS.md도 다른 대상 형식에서 동일한 프론트매터 문제를 다룹니다.

2단계: 직접 작성한 규칙을 재생성 경로에서 제외하기

Amazon Q는 프로젝트에 대한 memory bank를 생성할 수 있으며, 이 부분에서 마이그레이션이 까다로워집니다:

"Amazon Q는 프로젝트의 구조, 기술 스택 및 제품 정보에 대한 빠른 인덱스를 제공하는 memory bank 파일을 자동으로 생성할 수 있습니다. 이 기능은 프로젝트의 주요 파일을 분석하여 요약 파일을 생성하므로, 질문할 때마다 전체 프로젝트를 분석하지 않고도 Amazon Q가 코드베이스를 이해하는 데 도움이 됩니다."

네 개의 파일(product.md, structure.md, tech.md, guidelines.md)이 생성되며, 이 파일들은 .amazonq/rules 하위의 memory-bank 서브폴더에 작성됩니다. 이는 방금 Cursor 규칙을 마이그레이션한 것과 동일한 폴더 트리입니다.

업데이트 경로는 편집이 아니라 재빌드입니다:

"프로젝트가 변경되면 Amazon Q가 새로운 memory bank 파일을 생성하여 컨텍스트를 업데이트하도록 할 수 있습니다. 그렇게 하려면 Rules 버튼을 선택한 다음 Regenerate Memory Bank를 선택하세요."

두 가지 결과가 따릅니다. 첫째, 팀원이 memory-bank/ 내부에 직접 작성한 모든 내용은 다음 재생성 시 덮어씌워질 위험이 있습니다. 둘째, 더 중요한 점은 이 네 개의 파일이 코드를 분석하여 생성되기 때문에 코드에 이미 있는 내용만 포함할 수 있다는 것입니다. "다른 HTTP 클라이언트를 사용하지 마라"는 규칙을 유지한 이유는 코드에 없습니다. 다른 클라이언트가 존재하지 않기 때문입니다. 재생성은 그러한 문장을 만들어낼 수 없으며, 앞으로도 결코 만들지 못할 것입니다.

이는 이 분야의 다른 잘 알려진 memory bank와 대조해 볼 가치가 있습니다. Cline's Memory Bank는 작업이 진행됨에 따라 에이전트가 읽고 업데이트하도록 지시받은 파일 세트이므로, 그 내용은 에이전트가 프로젝트 상태에 대해 기록한 모든 것입니다. Amazon Q의 memory bank는 이름은 같지만 출처는 정반대입니다. 리포지토리에서 생성됩니다. 어느 쪽이 더 낫다고 할 수 없으며, 서로 다른 질문에 대한 답입니다. 하나가 다른 하나처럼 작동할 것이라고 가정하는 것은 팀이 콘텐츠를 잃어버리는 원인이 됩니다.

따라서 두 레이어를 물리적으로 분리해 두세요. 마이그레이션된 규칙은 개별 파일로 .amazonq/rules/에 직접 저장합니다. memory-bank 서브폴더는 자동으로 생성되도록 두고 파생된 출력물로 취급하세요. 생성되는 내용을 조정하고 싶다면, Amazon Q는 지원되는 방법을 문서화하고 있습니다. 즉, 원하는 형식을 설명하는 규칙을 .amazonq/rules에 작성하는 것입니다. 이는 생성된 레이어가 직접 작성한 레이어에 의해 제어되고 그 반대는 아니라는 훌륭한 특성을 가집니다.

위의 모든 작업은 번역 작업이며, 다음에 도구를 바꿀 때 또다시 반복하게 될 것입니다. 계속해서 비용을 발생시키는 부분은 파일 형식이 아닙니다. 각 규칙 뒤에 숨겨진 의사결정 배경(reasoning)이 도구 전용 파일 내부를 제외하고는 그 어디에도 저장되지 않았다는 점입니다.

MemoryLake는 두 제품 외부에서 이러한 의사결정 배경을 보관할 수 있는 공간을 제공하며, MCP 또는 API를 통해 요청하는 모든 에이전트에게 이를 제공합니다. Cursor는 규칙을 유지하고 Amazon Q는 memory bank를 있는 그대로 유지합니다. 이 솔루션은 그 옆에 나란히 위치하여 두 도구 모두 저장하도록 설계되지 않은 레이어, 즉 여러분이 결정한 사항, 거부한 사항, 그리고 그 이유를 보관합니다.

1단계: API 키 생성

키를 생성하고 약 30초 만에 첫 번째 요청을 완료하세요. 규칙 파일을 다시 작성하기 전에 이 작업을 수행하여, 진행하면서 의사결정 배경을 저장할 곳을 마련해 두세요.

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

위의 1단계에서 각 .mdc 파일을 작업하면서 규칙이 왜 존재하는지 다시 구성하게 될 것입니다. 작업하면서 컨벤션, 거부한 대안, 그리고 그 뒤에 숨겨진 사건이나 제약 조건 등을 캡처하세요. 지원 문서, 다이어그램, 파일도 함께 추가하세요.

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

Claude, Codex, OpenClaw, Amazon Q에 MCP 또는 API를 통해 액세스 권한을 부여하세요. 의사결정 레이어를 쿼리할 수 있는 에이전트는 규칙을 단순히 다시 설명하는 대신, 이유를 첨부하여 "왜 이것이 여기서 컨벤션인가요?"에 답변합니다.

즉각적인 변화는 1단계에서 잃어버린 조건성이 그리 중요하지 않게 된다는 점입니다. glob 범위 규칙이 존재했던 이유 중 하나는 관련 없는 가이드라인이 컨텍스트 창에 들어가지 않도록 하기 위함이었습니다. 의사결정 배경이 에이전트가 필요할 때 쿼리하는 저장소에 존재하면, .amazonq/rules는 상시 명령만 포함하여 정말 짧게 유지될 수 있으며, 롱테일 정보는 혹시 필요할지 몰라 미리 로드되는 대신 실제로 관련이 있을 때 검색됩니다.

두 번째 변화는 첫 번째 Regenerate Memory Bank를 실행할 때 나타납니다. 보관할 가치가 있는 것들은 생성된 파일에 전혀 들어있지 않았기 때문에 아무것도 잃지 않을 것입니다.

셋째, 부분적인 마이그레이션이 더 이상 문제가 되지 않습니다. 많은 팀이 서로 다른 리포지토리나 팀의 절반씩 나누어 수개월 동안 Cursor와 Amazon Q를 병행하여 사용합니다. 두 가지 형식의 두 규칙 폴더는 서로 달라지게(drift) 됩니다. 하지만 두 에이전트가 모두 읽는 하나의 의사결정 레이어는 달라지지 않습니다.

네 번째 변화는 다음 마이그레이션 때 찾아옵니다. 규칙 파일은 다시 변환되겠지만, 의사결정 배경은 규칙 파일에 있었던 적이 없으므로 변환할 필요가 없습니다.

한 번에 하나의 규칙만 마이그레이션하고, 각 규칙을 꼼꼼히 읽으세요. 일괄 복사는 이 마이그레이션에서 실패하는 지름길입니다. 대상 도구에서 아무 의미도 없는 프론트매터를 보존하고, 가장 중요한 조건들을 소리 없이 폐기하기 때문입니다.

절대로 memory-bank/ 내부에 직접 작성하지 마세요. 이는 생성된 출력물입니다. 파일은 .amazonq/rules/에 직접 넣으세요.

이전에 glob이 있던 규칙에서는 범위를 명확히 명시하세요. 규칙이 적용되는 파일이나 디렉토리를 언급하며 규칙을 시작하세요. 강제된 조건을 서술형 조건으로 변환했으므로, 해당 서술을 놓칠 수 없게 만드세요.

규칙을 사용하여 생성을 조정하세요. Amazon Q는 프로젝트 규칙을 통해 memory bank 출력을 맞춤 설정하는 것을 지원합니다. 이것이 직접 작성한 레이어와 생성된 레이어 간의 문서화된 연결점입니다. 생성된 파일을 편집하는 대신 이 방법을 사용하세요.

핀 고정(pinning)이 모든 것을 해결해 준다고 가정하지 마세요. 컨텍스트 핀 고정은 VS Code IDE에서만 사용 가능한 것으로 문서화되어 있으며, 고정된 항목은 현재 채팅 탭에만 적용됩니다. 새 탭은 새로 시작됩니다. 이는 대화별 편의 기능일 뿐, 지속적인 프로젝트 레이어가 아닙니다.

두 도구 모두 소유하지 않은 어딘가에 '이유'를 단 한 번만 기록해 두세요. 이것이 반복되지 않는 유일한 작업입니다.

Cursor에서 Amazon Q Developer로의 마이그레이션은 양쪽 모두 프로젝트 폴더에서 Markdown을 사용하기 때문에 과소평가하기 쉽습니다. 콘텐츠는 이식되지만, 조건성은 이식되지 않습니다. Cursor의 문서화된 네 가지 적용 유형은 Amazon Q의 프로젝트 규칙에 문서화된 대응 항목이 없으며, .mdc 프론트매터의 네 가지 필드는 그대로 복사할 경우 아무 기능도 하지 않는 텍스트가 됩니다.

두 번째로 바로잡아야 할 것은 폴더 관리 규칙입니다. Amazon Q의 memory bank는 동일한 .amazonq/rules 트리의 서브폴더에 생성되며, 편집되는 것이 아니라 재빌드됩니다. 이는 코드베이스에 포함된 내용에 대한 정말 유용한 인덱스이지만, 바로 그 이유 때문에 코드베이스에 포함되지 않은 결정 사항은 담을 수 없습니다.

변환을 신중하게 진행하고, 직접 작성한 콘텐츠와 생성된 콘텐츠를 별도의 장소에 보관하며, 다음 도구 변경 시에도 유지될 수 있는 곳에 의사결정 배경을 저장하세요. 그러면 이번이 처음부터 이 특정 변환 작업을 수행하는 마지막 기회가 될 것입니다.