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

규칙 콘텐츠는 깔끔하게 이전됩니다. Amazon Q의 프로젝트 규칙은 프런트매터(frontmatter)가 없는 일반 Markdown입니다. 문서에 따르면 규칙 파일은 "반드시 Markdown 파일이어야 한다"고 명시되어 있으며 본문은 일반 텍스트로 되어 있습니다. Amp의 AGENTS.md 역시 일반 Markdown입니다. .amazonq/rules/*.md 본문들을 리포지토리 루트의 AGENTS.md로 병합하면 콘텐츠가 그대로 유지됩니다.

디렉토리 배치가 이전되지만, 기본 범위가 더 넓어집니다. Amp의 포함 규칙은 두 번 읽어볼 가치가 있습니다:

"현재 작업 디렉토리(또는 에디터 워크스페이스 루트) 및 상위 디렉토리($HOME까지)의 AGENTS.md 파일은 항상 포함됩니다."

"하위 트리 AGENTS.md 파일은 에이전트가 하위 트리의 파일을 읽을 때 포함됩니다."

하위 트리 규칙은 여러분이 원하는 방식일 것입니다. 영역당 하나의 지침 파일을 두고, 에이전트가 해당 영역을 터치할 때 로드하는 방식입니다. 확인해야 할 부분은 상위 디렉토리 규칙입니다. 리포지토리들을 공유 상위 디렉토리 아래에 두고 홈 디렉토리로 가는 경로 상에 AGENTS.md가 존재한다면, 모든 리포지토리에서 해당 파일이 로드됩니다. Amazon Q의 문서화된 규칙 위치는 {{project-root}}/.amazonq/rules이며, 상위 디렉토리로 거슬러 올라가는 동작은 설명되어 있지 않으므로, 이는 새로 도입되는 동작 범위입니다.

파일 이름 폴백(fallback)이 유리하게 작용합니다. Amp 문서에 따르면 "디렉토리에 AGENTS.md가 존재하지 않지만, AGENT.md('S'가 없는 형태) 또는 CLAUDE.md라는 이름의 파일이 존재하면 해당 파일이 포함됩니다." 따라서 다른 도구에서 이미 사용 중인 CLAUDE.md가 있는 리포지토리는 디렉토리별로 감지됩니다. 우선순위는 AGENTS.md가 먼저이고 나머지 두 개가 폴백이라는 점에 유의하세요. 이는 일부 에이전트가 배포하는 순서와 반대입니다.

세션별 규칙 선택 기능은 대체할 곳이 없습니다. 이것이 가장 큰 변화입니다. Amazon Q에서의 습관은 Rules 버튼을 열고 당장 수행할 작업에 맞는 하위 집합을 선택하는 것이었습니다. Amp에는 항상 켜져 있는 레이어 하나와 조건부 메커니즘 하나가 있으며, 조건부 메커니즘은 다르게 작동합니다. AGENTS.md에서 파일을 @로 언급(mention)하고, 언급된 파일에 globs 프런트매터 필드를 포함할 수 있습니다. Amp 문서에 따르면 "globs가 있는 언급된 파일은 Amp가 해당 glob 중 하나라도 일치하는 파일을 읽은 경우에만 포함"되며, "globs가 지정되지 않은 경우 @ 언급 시 항상 포함"됩니다.

이는 AGENTS.md에서의 언급과 언급된 파일 내의 glob이라는 두 단계의 간접 지정 방식이며, 시작하기 전에 사용자가 선택한 것이 아니라 에이전트가 어떤 파일을 읽느냐에 따라 트리거됩니다. 이 메커니즘에 대해서는 Amp의 지침을 적용 대상 파일로 제한하기에서 자세히 다루었습니다. 여기서 짚고 넘어갈 점은 명확합니다. Amazon Q의 체크박스는 이 작업에 대한 선언이었습니다. 반면 Amp의 glob은 이 경로에 대한 선언입니다. 이 둘은 상호 대체가 불가능하므로, 작업별로 선택하던 규칙은 파일 경로에 대한 규칙으로 다시 표현하거나 항상 켜두는 방식으로 수용해야 합니다.

Your memory bank transfers as static files. Amazon Q는 .amazonq/rules 아래의 memory-bank 하위 폴더에 product.md, structure.md, tech.md, guidelines.md라는 4개의 파일로 구성된 메모리 뱅크를 생성할 수 있습니다. 문서에서는 이 메커니즘을 명확하게 설명합니다. 이 기능은 "프로젝트의 핵심 파일을 분석하여 요약 파일을 생성함으로써, 질문을 할 때마다 전체 프로젝트를 분석하지 않고도 Amazon Q가 코드베이스를 이해할 수 있도록 돕습니다." 이를 업데이트하려면 Regenerate Memory Bank를 선택해야 합니다.

Amp의 문서화된 지침 인터페이스는 AGENTS.md 파일, 스킬(skills), 플러그인(plugins)이며, 이 중 어떤 페이지에서도 생성 또는 재생성 단계를 설명하지 않습니다. 따라서 이 네 개의 파일은 직접 관리해야 하는 일반 Markdown 파일이 되며, 그중 세 개는 코드가 이미 나타내고 있는 내용을 설명할 뿐입니다. 이 차이는 매우 중요하기 때문에 반대 방향의 가이드인 Cursor에서 Amazon Q Developer로 마이그레이션하기를 작성하기도 했습니다. 요약하자면, 도구가 리포지토리에서 재생성할 수 있는 모든 것은 이미 리포지토리에 존재하던 것입니다. 파서가 생성해낼 수 없는 결정 사항들이 포함될 수 있는 것은 네 번째 파일인 guidelines.md이며, 이것이 바로 직접 수동으로 이전해야 할 파일입니다.

압축(Compaction) 동작이 다르며, 두 버전 모두 영구적이지 않습니다. Amazon Q는 컨텍스트 창의 상세 대화 기록을 대체하는 요약 기능인 /compact를 지원하며, 기억해 둘 만한 두 구절을 덧붙입니다: "전체 대화 기록은 현재 세션이 끝날 때까지 채팅 인터페이스에 계속 표시됩니다", "IDE를 재시작하면 상세 채팅 기록이 초기화됩니다." Amp의 문서는 압축 명령 대신 스레드(threads)를 설명합니다. 어느 쪽이든, 대화창은 다음 주에 필요한 내용을 남겨둘 만한 장소가 아닙니다.

이전할 세션 메모리 저장소가 없습니다. Amazon Q의 메모리 뱅크는 생성된 리포지토리 요약본의 집합일 뿐, 사용자에 대해 학습한 기록이 아닙니다. Amp의 문서 인덱스에서는 AGENTS.md, 스킬, 플러그인을 커스터마이징 인터페이스로 설명할 뿐, 세션별 메모리 저장소에 대해서는 설명하지 않습니다. 따라서 양쪽 모두 저장소 간 마이그레이션이 필요 없으며, 이는 작업이 줄어든 것처럼 보이지만 실제로는 신중하지 않으면 마이그레이션 과정에서 지식이 유실되는 원인이 됩니다.

1단계: 규칙이 작업에 관한 것인지 경로에 관한 것인지 분류하기

Amazon Q에서 Rules 버튼을 열고, 각 규칙 파일에 대해 실제로 어떤 세션에서 체크하는지 기록해 두세요. 마이그레이션하는 대상은 파일 자체가 아니라 바로 이 목록입니다.

모든 세션에서 체크하는 규칙은 루트 AGENTS.md로 바로 이동합니다. 사내 컨벤션, 빌드 명령, 리뷰 체크리스트 같은 쉬운 규칙들이 여기에 해당합니다.

특정 영역에서 작업할 때 체크하는 규칙은 하위 트리 AGENTS.md 파일이 됩니다. 프론트엔드 규칙은 프론트엔드 디렉토리에 넣으세요. Amp는 "에이전트가 하위 트리의 파일을 읽을 때" 이를 로드하므로, 제공되는 기능 중 기존의 체크박스 동작과 가장 유사합니다.

파일 유형별로 체크하는 규칙은 globs가 포함된 @ 언급 파일이 됩니다. AGENTS.md에 언급 라인을 추가한 다음, 언급된 파일에 globs 목록을 제공하세요. 여기서 주의해야 할 두 가지 세부 사항이 있습니다. Amp 문서에 따르면 "glob은 ../ 또는 ./로 시작하지 않는 한 암묵적으로 앞에 **/가 붙으며, 이 경우 언급된 파일에 대한 상대 경로를 참조합니다." 즉, 그냥 *.ts라고 쓰면 파일 옆뿐만 아니라 모든 곳에서 일치하게 됩니다. 또한 "오탐을 방지하기 위해 코드 블록 내의 @ 언급은 무시"되므로, 코드 예시 안에 포함된 언급은 아무런 동작도 하지 않습니다.

작업별로 체크하는 규칙("이번 작업에는 엄격한 리뷰 체크리스트 적용")은 깔끔하게 배치할 곳이 없습니다. 각 규칙을 항상 켜둘지 아니면 삭제할지 결정하고, 삭제한 규칙을 기록해 두세요. 이 카테고리는 규칙 파일이 여전히 존재하지만 실제로는 전혀 적용되지 않기 때문에, 마이그레이션 시 조용히 기능이 유실되는 구간입니다.

그 다음 검증합니다. Amp는 이를 확인할 수 있는 방법을 제공합니다: "Amp가 사용 중인 에이전트 파일을 보려면 커맨드 팔레트에서 agents-md list를 선택하십시오." 리포지토리 루트가 아닌 실제 작업 디렉토리에서 이를 실행하고, 예상한 목록과 일치하는지 확인하세요. 특히 자신도 모르게 존재하던 상위 디렉토리 파일이 있는지 확인해야 합니다.

2단계: 메모리 뱅크 및 홈 디렉토리 범위 처리하기

두 가지 정리 작업이 필요하며, 둘 다 3달 뒤에 하는 것보다 지금 하는 것이 훨씬 쉽습니다.

첫째, 메모리 뱅크입니다. 생성된 4개의 파일을 모두 읽고, 파서가 리포지토리에서 생성해낼 수 없었을 문장들을 모두 표시하세요. product.md, structure.md, tech.md에서는 거의 없을 것입니다. 이 파일들은 코드의 요약본이며 코드는 여전히 존재하기 때문입니다. 반면 guidelines.md에서는 꽤 많을 수 있습니다. Amazon Q는 프로젝트 규칙으로 생성을 제어할 수 있게 해주며, 팀들은 종종 이를 통해 단순한 설명이 아닌 표준 지침을 주입하기 때문입니다. 파서가 생성할 수 없는 문장들을 AGENTS.md로 이동하고 나머지는 삭제하세요. 재생성된 리포지토리 설명 파일 3개를 항상 켜져 있는 컨텍스트 레이어에 들고 다니는 것은 매 요청마다 토큰 비용을 낭비할 뿐만 아니라, 에이전트가 이미 읽을 수 있는 내용 외에 새로운 정보를 주지 못합니다.

둘째, 작업 디렉토리부터 $HOME까지의 경로를 훑으며 그 사이에 있는 모든 AGENTS.md, AGENT.md, CLAUDE.md를 나열해 보세요. Amp의 상위 디렉토리 포함 규칙은 끝까지 올라가며, 두 개의 $HOME/.config 위치인 $HOME/.config/amp/AGENTS.md 및 $HOME/.config/AGENTS.md는 "존재하는 경우 항상 포함"됩니다. 플랫폼에 따라 /etc/ampcode/AGENTS.md, /Library/Application Support/ampcode/AGENTS.md 또는 %ProgramData%\ampcode\AGENTS.md에 있는 시스템 전반의 파일도 마찬가지입니다.

조직에서 이러한 시스템 파일 중 하나를 배포한 경우, 실제 적용되는 지침 세트는 리포지토리 크기보다 커지며 리포지토리 내부에는 이를 기록하는 내용이 전혀 없습니다. 원인을 찾을 수 없는 동작을 디버깅하기 전에 무엇이 존재하는지 먼저 파악해 두세요. 이러한 작업의 일반적인 형태는 AI가 실제로 기억하는 내용 감사하기에서 다루고 있습니다.

작업별로 선택했던 규칙들은 이번 마이그레이션에서 가져갈 수 없는 규칙들이며, 동시에 가장 가치 있는 규칙들입니다. 모든 파일에 적용하는 규칙은 대개 컨벤션입니다. 반면 이번 변경 사항에 적용하는 규칙은 대개 판단이며, 판단에는 이유가 있습니다.

MemoryLake는 결정 사항, 적용 대상, 제외 대상 및 그 이유를 보관합니다. 경로 범위나 세션 범위에 종속되지 않으므로, 오직 특정 컨텍스트에서만 의미가 있었던 규칙도 그 컨텍스트를 유지합니다. 여기서 시작하세요.

1단계: API 키 생성

리포지토리를 위한 워크스페이스를 생성하고 API 키를 생성합니다. 이 레이어가 두 도구의 구성 디렉토리에 종속되지 않도록 범위를 리포지토리 수준으로 유지하세요.

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

1단계에서 배치하지 못했던 작업 수준의 규칙, 즉 선택적으로 체크하던 규칙부터 시작하세요. 각 규칙에 대해 적용 대상과 존재 이유를 기록합니다. 그런 다음 파서 테스트에서 살아남은 guidelines.md 내용과 이번 마이그레이션 중에 내린 결정 사항(어떤 규칙이 항상 켜짐으로 설정되었는지, 어떤 규칙이 glob이 되었는지, 어떤 규칙을 삭제했는지)을 추가합니다.

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

Amp를 연결하고, 두 도구를 모두 사용하는 동안에는 Amazon Q도 연결된 상태로 유지하세요. 두 도구 모두 동일한 결정 세트를 읽으므로, 아직 glob으로 다시 표현하지 못한 규칙이라도 그 근거를 여전히 활용할 수 있습니다.

선택적 규칙들을 더 이상 잃어버리지 않게 됩니다. 상황에 따라 체크하던 규칙들은 항상 켜져 있는 모델로 이동할 때 가장 먼저 유실되는 대상입니다. 적용이 중단되어도 에러가 발생하지 않고, 단지 아무도 읽지 않는 파일이 될 뿐이기 때문입니다.

항상 켜져 있는 레이어를 작게 유지할 수 있습니다. 재생성된 리포지토리 설명 파일 3개를 포함하여 모든 것을 병합하는 대신, 파서가 생성할 수 없는 문장들만 가져가고 나머지는 남겨둘 수 있습니다.

디버깅의 출발점이 생깁니다. Amp가 리포지토리만으로는 설명되지 않는 방식으로 동작할 때, 경로 상의 상위 디렉토리 및 시스템 파일 목록을 문서로 가지고 있으며, agents-md list를 통해 이를 확인할 수 있습니다.

그리고 재설명하는 일이 줄어듭니다. 유실된 규칙으로 인해 발생하는 반복적인 비용은 사용자가 프롬프트에서 이를 다시 설명해야 하는 것이며, 이는 AI에게 컨텍스트를 반복해서 설명하지 않는 방법에서 설명한 패턴입니다. 항상 켜져 있거나 glob으로 트리거되는 규칙은 다시 설명할 필요가 없습니다. 반면 조용히 적용이 중단된 규칙은 평생 다시 설명해야 합니다.

첫 주에는 세 개의 서로 다른 디렉토리에서 agents-md list를 실행해 보세요. 결과는 작업 디렉토리에 따라 달라지며, 이것이 바로 하위 트리 메커니즘의 핵심입니다.

경계가 디렉토리인 경우 glob보다 하위 트리 파일을 선호하세요. 움직이는 부분이 적고, 골치 아픈 암묵적 **/ 접두사도 없으며, 해당 코드를 편집하는 사람이 쉽게 찾을 수 있는 위치에 파일이 놓이게 됩니다.

glob 범위의 파일에는 각각 하나의 역할만 부여하세요. Amp는 어떤 glob이라도 일치할 때 언급된 파일을 포함하므로, 서로 무관한 4개의 패턴을 다루는 파일은 필요 이상으로 4배나 자주 로드됩니다.

개인적인 선호 사항은 공유 경로에 두지 마세요. $HOME/.config/amp/AGENTS.md는 여는 모든 프로젝트에 항상 포함됩니다. 이 위치는 기기 전용 명령어를 두기에 적합한 곳이며, 동료들이 동의하지 않은 의견을 두기에는 부적절한 곳입니다. Amp 자체 표에서도 이 위치를 "개인적인 선호 사항, 기기 전용 명령어, 리포지토리에 커밋하기 전에 로컬에서 테스트 중인 가이드"용으로 명시하고 있습니다.

대규모 하위 프로젝트는 의도적으로 분할하세요. Amp는 "최상위 AGENTS.md를 일반적인 내용으로 유지"하고 "각 하위 프로젝트의 하위 트리에 더 구체적인 AGENTS.md 파일을 생성"할 것을 권장합니다. 이는 기존에 Rules 버튼이 해주던 역할을 가장 적은 비용으로 흉내 낼 수 있는 방법이기도 합니다.

나중에 다시 다른 도구로 이동하게 되더라도, 여기서 구축한 인벤토리 덕분에 비용을 크게 줄일 수 있습니다. 이 인벤토리는 Amp에서 Codex로 마이그레이션하기를 고고학적 발굴 작업이 아닌 단순한 파일 작업으로 만들어 주며, Claude Code에서 Amp로 마이그레이션하기의 기반이 되기도 합니다.

Amazon Q는 체크박스를 제공하며 사용자에게 직접 큐레이션할 것을 요구합니다. 반면 Amp는 작업 디렉토리부터 $HOME까지 도달하는 포함 규칙을 제공하며 해당 경로에 무엇을 남겨둘지 주의할 것을 요구합니다. 둘 다 타당한 설계입니다. 어느 한쪽이 다른 쪽의 상위 호환인 것은 아닙니다.

성공적인 마이그레이션은 파일이 이동하기 전, 정답이 아직 머릿속에 있을 때 어떤 규칙을 왜 선택하고 있었는지 기록하는 것부터 시작됩니다. 실패하는 마이그레이션은 단순히 파일 4개를 복사하고 체크박스를 삭제한 뒤, 6주일이 지나서야 결제 모듈에 대한 규칙이 전환 이후 한 번도 적용되지 않았음을 깨닫는 것입니다.