직접 작성한 Amazon Q 규칙을 생성된 Memory Bank로부터 격리하는 방법 (2026년 가이드)

Amazon Q의 프로젝트 규칙(rules)은 프로젝트의 .amazonq/rules 폴더에 있는 Markdown 파일입니다. 공식 문서는 그 목적을 명확히 밝히고 있습니다. 규칙은 "팀 전체의 코딩 표준 및 모범 사례를 설명"하며, 이를 프로젝트에 저장하면 "개발자의 경험 수준에 관계없이 일관성을 보장"할 수 있습니다.

Memory Bank는 이와는 다른 목적을 가진 별개의 기능입니다. Amazon Q는 주요 파일을 분석하여 "질문할 때마다 전체 프로젝트를 분석할 필요 없이" 코드베이스를 이해할 수 있도록 "프로젝트 구조, 기술 스택 및 제품 정보에 대한 빠른 인덱스를 제공하는 Memory Bank 파일을 자동으로 생성할 수 있습니다."

이 두 기능은 저장 위치를 공유합니다. 생성 시 "Amazon Q는 .amazonq/rules 아래에 memory-bank 하위 폴더를 생성"하고 4개의 파일을 저장합니다. 프로젝트 개요 및 기능을 위한 product.md, 아키텍처 및 폴더 구조를 위한 structure.md, 기술 스택 및 의존성을 위한 tech.md, 그리고 개발 표준 및 패턴을 위한 guidelines.md입니다.

마지막 파일명이 흥미로운 부분입니다. guidelines.md는 "프로젝트의 개발 표준 및 패턴"을 설명하는 생성된 콘텐츠로, 이는 여러분이 직접 작성한 규칙이 하던 역할과 정확히 일치합니다. 이제 두 가지 모두 동일한 트리 구조에 존재하며, 둘 다 "Amazon Q와 대화할 때 자동으로 컨텍스트로 사용"됩니다.

이것은 결함이 아닙니다. 직접 작성한 콘텐츠와 자동으로 파생된 콘텐츠가 하나의 네임스페이스를 공유하도록 설계된 결과이며, 이 설계의 대가는 가장 중요한 순간에 작성 주체가 모호해진다는 점입니다. 이는 어떤 diff 도구도 보여주지 못하는 상충되는 지시어 레이어 문제와 동일한 범주의 문제이지만, 여기서는 레이어 중 하나가 스스로를 직접 작성했다는 점이 다릅니다.

Memory Bank가 규칙을 대체한다고 가정하기. 그렇지 않습니다. 둘 다 컨텍스트로 사용됩니다. Memory Bank를 생성하면 파일이 추가될 뿐, 직접 작성한 파일이 사라지지는 않습니다.

Regenerate가 생성된 파일만 건드린다고 가정하기. 이는 맹신하기보다 직접 테스트해 볼 가치가 있는 가정입니다. 문서화된 작업은 Regenerate Memory Bank이며, 실제로 재생성되는 것은 Memory Bank 파일들입니다. 가정에 의존하기보다 검증해야 하는 이유는, 그 경계가 여러분도 직접 파일을 작성하는 폴더 내부의 하위 폴더이며, 여러분의 파일을 여러분의 것으로 표시해 주는 유일한 단서가 바로 저장 위치뿐이기 때문입니다.

이름이 어울린다는 이유로 guidelines.md에 팀 표준 작성하기. 이름은 어울릴지 몰라도 이 파일은 자동 생성되는 파일입니다. 여기에 작성된 모든 내용은 재생성 과정에서 덮어써질 위험이 있습니다.

안전을 위해 Memory Bank 기능 끄기. 이는 정리 정돈 문제 때문에 실제 유용한 이점을 포기하는 것입니다. 인덱스가 존재하는 이유는 Amazon Q가 모든 질문마다 전체 프로젝트를 다시 읽지 않도록 하기 위함이며, 이는 충분히 가치 있는 기능입니다.

패널에서 파일을 비활성화하고 해결되었다고 생각하기. Rules 패널은 사용 가능한 규칙을 나열하며, 클릭하여 현재 채팅 세션에 대해 활성화/비활성화할 수 있습니다. 체크 표시가 있는 파일은 "활성화되어 대화에 적용"되고, 체크 표시가 없는 파일은 "현재 세션에서 비활성화"됩니다. 이는 세션별 스위치일 뿐 파일 정리 방식이 아니며, 폴더 내부의 실제 파일 상태를 변경하지 않습니다.

패널이 누가 무엇을 작성했는지 보여줄 것이라 믿기. 패널은 이름과 체크 표시만 보여줍니다. 생성된 파일은 memory-bank 하위 폴더 아래에 위치하므로 경로가 유일한 신호이며, 그 외의 신호는 없습니다.

이 메커니즘이 제공하는 유일한 경계는 memory-bank 하위 폴더뿐입니다. 그 외의 모든 것은 여러분이 직접 부여해야 하는 규칙(컨벤션)이며, 컨벤션은 누군가 검증할 때만 유지됩니다.

1단계: 파일명만으로 작성 주체를 알 수 있도록 직접 작성한 규칙 파일의 이름을 변경하기

.amazonq/rules 폴더를 살펴보고 팀이 작성한 파일의 이름을 변경하여 작성 주체를 명확히 하세요. 접두사(prefix)를 사용하면 좋습니다. 예: team-api-conventions.md, team-testing-policy.md, team-security-baseline.md. 구체적인 컨벤션의 형태보다는, 예외 없이 적용할 수 있는 한 단어 길이의 접두사라는 점이 중요합니다.

이는 단순히 꾸미기 위한 것이 아닙니다. 동일한 트리 구조에 4개의 생성된 파일이 나타났을 때, 폴더가 처음 구성될 때 참여하지 않았던 사람도 파일 목록만 보고 "이것이 우리가 작성한 파일인가?"라는 질문에 답할 수 있어야 합니다. 접두사는 이 질문에 답을 주지만, 단순히 신중하게 지은 파일명은 답을 주지 못합니다. 생성된 파일명 역시 신중하게 지어지기 때문입니다.

이 작업을 수행하는 동안, 생성된 파일에 들어가야 할 내용을 직접 작성한 파일에서 분리하세요. 여러분의 규칙 중 폴더 구조를 설명하는 내용이 있다면 그것은 structure.md가 담당해야 할 역할입니다. 이를 중복해서 작성하면 결국 두 번 유지보수해야 하고 나중에는 서로 내용이 어긋나게 됩니다.

2단계: 생성기가 생성하는 내용을 제어하는 규칙 하나 작성하기

이 부분은 대부분의 팀이 놓치는 부분이며, 공식 문서에도 나와 있습니다. 여러분은 "사용자 지정 프로젝트 규칙을 생성하여 Memory Bank 파일이 생성되는 방식을 맞춤 설정"할 수 있습니다. 제공된 예시는 생성된 파일의 언어와 형식을 지정하는 규칙입니다.

즉, 생성기는 제어 가능하며, 그 제어 장치는 다른 모든 파일과 동일한 폴더에 위치합니다. 접두사를 붙여 team-memory-bank-policy.md라는 파일을 하나 작성하고, 생성된 파일에 포함되어야 할 내용과 포함되지 말아야 할 내용을 명시하세요. 다음 두 가지 지침이 가장 중요합니다. 생성된 파일은 규범적(prescriptive)이기보다는 서술적(descriptive)이어야 하며, 이미 접두사가 붙은 파일에 존재하는 팀 표준을 중복해서 서술하지 않아야 한다는 점입니다.

이 두 번째 지침이 바로 울타리(fence) 역할을 합니다. 파일 시스템 수준에서 무언가를 강제로 막지는 못하지만, 특정 유형의 콘텐츠는 이미 다른 곳에서 관리되고 있음을 생성기에 알려줍니다. 이 설계에서 이를 표현할 수 있는 유일한 방법입니다.

3단계: 커밋, 재생성, 그리고 diff 확인하기

먼저 이름이 변경된 파일들과 정책 규칙을 커밋하여 깨끗한 기준선(baseline)을 만드세요. 그런 다음 Rules 버튼에서 Regenerate Memory Bank를 실행하고, 변경 사항을 수락하기 전에 결과 diff를 확인하세요.

세 가지를 확인해야 합니다. 접두사가 붙은 파일들이 수정되지 않았는지, 4개의 Memory Bank 파일이 memory-bank 하위 폴더 내부에서만 변경되었는지, 그리고 guidelines.md가 정책 규칙에서 건드리지 말라고 지시한 표준들을 다시 생성해내지 않았는지 확인합니다.

비교할 커밋을 두고 이 작업을 의도적으로 한 번 수행해 보면, 가정이 아닌 관찰을 통해 경계를 확실히 알게 됩니다. 대규모 리팩터링 후에는 이 작업을 다시 수행하세요. 리팩터링 직후가 생성기에 가장 많은 새로운 자료가 제공되고, 내용을 중복해서 서술할 가능성이 가장 높은 시기이기 때문입니다.

기준선 커밋을 쉽게 찾을 수 있도록 유지하세요. 생성된 파일은 언제든 다시 생성될 수 있도록 설계되었으므로, 재생성으로 인해 무엇이 변경되었는지 확인할 수 있어야 안전하게 사용할 수 있습니다.

1단계에서 접두사를 붙인 파일들은 이 프로세스에서 영구적으로 보존되어야 하는 절반에 해당합니다. 즉, 어떤 생성기도 만들지 않았고 어떤 재생성으로도 변경되어서는 안 되는, 팀원들의 언어로 합의된 내용들입니다. MemoryLake는 이 소중한 자산을 특정 도구의 폴더 위치에만 종속되지 않도록 안전하게 보관할 수 있는 공간입니다.

여러분은 자신만의 언어로 직접 항목을 작성합니다. .amazonq/rules, Amazon Q의 Memory Bank 또는 다른 벤더의 저장소에서 데이터를 읽거나 쓰거나 삭제하지 않습니다.

1단계: API 키 생성하기

로그인 후 대시보드에서 키를 생성합니다. 이 키를 사용하면 어떤 에디터나 저장소에 있든 상관없이 에이전트가 여러분이 작성한 항목을 읽을 수 있습니다.

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

접두사가 붙은 파일의 합의 사항을 항목당 하나의 결정 사항으로 추가하고, 그 이유를 함께 첨부하세요. 이유는 규칙이 개정되더라도 살아남는 부분입니다. 다음 사람에게 이 규칙이 여전히 유효한지 알려주는 근거가 되기 때문입니다.

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

에이전트가 워크스페이스를 바라보도록 설정하세요. 이제 팀의 합의된 결정 사항들을 .amazonq 폴더가 전혀 없는 도구에서도 사용할 수 있게 되며, 이를 통해 단순한 Amazon Q 설정이 아닌 진정한 팀의 합의 사항으로 기능하게 됩니다.

첫 번째 변화는 파일 목록만으로 작성 주체에 대한 의문이 해결된다는 점입니다. 접두사를 사용하기 전에는 "이것을 우리가 작성했는가"를 알기 위해 폴더의 이력을 알아야 했습니다. 접두사를 적용한 후에는 목록 자체가 답이 되며, 새로 합류한 팀원도 첫눈에 바로 파악할 수 있습니다.

두 번째 변화는 생성기가 예상치 못한 결과를 내놓는 존재가 아니라, 여러분이 직접 구성하고 제어하는 도구가 된다는 점입니다. 정책 규칙은 작은 파일이지만 매우 큰 효과를 발휘합니다. 생성된 파일의 용도를 지정하는 공식적인 방법이기 때문입니다. 이 규칙이 존재하면 Memory Bank가 기존 표준을 중복해서 서술하는 현상이 사라집니다.

세 번째 변화는 재생성이 일상적인 작업이 된다는 점입니다. 대부분의 팀은 무엇을 건드릴지 확신할 수 없기 때문에 Regenerate를 기피합니다. 기준선 커밋과 접두사 컨벤션이 있다면 diff를 통해 몇 초 만에 이를 확인할 수 있으며, 리팩터링 후 새로 고쳐진 Memory Bank는 한 번 생성된 후 방치되어 낡아버린 것보다 훨씬 더 큰 가치를 지닙니다.

또한 세션별 토글의 용도도 명확해집니다. 규칙을 비활성화하는 것은 이번 대화에 대한 결정일 뿐 프로젝트 전체에 대한 결정이 아니며, 세션이 끝나면 유지되지 않습니다. 패널이 프로젝트 정책을 대변할 것이라 기대하는 팀은 결국 단 한 번의 채팅 동안만 유지되는 정책을 갖게 됩니다. 이는 명확히 구분해야 할 차이점이며, 실제로 어떤 가이드라인이 적용 중인지 아는 것이 가이드라인을 작성하는 것과는 별개의 작업인 이유이기도 합니다.

다른 도구에서 memory-bank 패턴을 사용해 보셨다면, 파일 정리 문제는 동일하게 발생합니다. Cline은 자체 디렉토리에 뱅크를 유지하므로, 그곳에 뱅크를 설정하는 것은 폴더의 소유권보다는 주로 각 파일에 무엇이 들어가는지에 관한 문제가 되며, 단일 뱅크의 규모가 커졌을 때 사람들이 비교하는 대안들 역시 정확히 이 지점에서 차이를 보입니다.

하나의 접두사를 사용하고 절대 예외를 두지 마세요. 이 컨벤션의 가치는 접두사가 없는 파일은 확실히 여러분의 것이 아니라는 정의에서 나옵니다. 단 하나의 예외만으로도 이 속성은 깨집니다.

정책 규칙은 짧게 유지하고, 내용이 아닌 형식에 집중하세요. 생성된 파일에 어떤 종류의 내용이 들어가야 하는지만 명시해야 합니다. 정책 규칙에 표준 자체를 담기 시작하면, 여러분의 표준이 생성기의 입력값으로 들어가 버리게 됩니다.

항상 특정 커밋을 기준으로 재생성하세요. diff는 여러분이 얻을 수 있는 유일한 관찰 도구입니다. 기준선 커밋이 없다면 이를 확인할 수 없습니다.

생성된 파일은 서술하게 하고, 여러분의 파일은 규정하게 하세요. 생성된 파일이 "API 레이어는 src/api에 위치한다"고 서술하는 것은 유용하며 새로 고치기도 쉽습니다. 반면 생성된 파일이 "모든 엔드포인트는 입력을 검증해야 한다"고 규정하는 것은 아무도 합의하지 않은 문구의 표준이 되어버립니다.

직접 작성하는 모든 규칙에 이유를 함께 적으세요. 이유가 없는 규칙은 나중에 평가할 수 없으므로, 영원히 맹목적으로 따르거나 답답함에 삭제되고 맙니다. 무시되는 규칙들이 대개 아무도 정당화하지 못하는 규칙들인 이유와 같습니다.

이 폴더가 다른 환경으로도 이동한다는 점을 기억하세요. 동일한 .amazonq/rules 폴더는 GitLab 또는 GitHub의 Amazon Q에서 사용되는 프로젝트 규칙의 공식 저장 위치이기도 하며, 여기서 규칙은 "자동으로" 프로젝트의 컨텍스트가 됩니다. 여러분이 커밋한 내용이 그곳에서 그대로 실행됩니다.

누군가 퇴사할 때 폴더를 검토하세요. 직접 작성한 규칙은 한 개인의 판단 결과물입니다. 그 사람이 떠나면 규칙의 소유자를 새로 지정하거나 삭제해야 합니다. 이는 도구가 기억하는 내용을 감사(audit)하는 작업을 통해 고고학적 유물이 되기 전에 미리 파악해야 하는 부분입니다.

Amazon Q의 Memory Bank는 다소 어색한 위치에 저장되는 유용한 기능입니다. 팀의 합의 사항이 담긴 폴더에 4개의 파일을 생성하며, 그중 하나는 여러분의 합의 사항이 하던 역할과 동일한 이름으로 명명됩니다. 그리고 두 가지를 모두 관리하는 패널은 이들을 동일하게 취급합니다.

해결책은 이 기능을 피하는 것이 아닙니다. 파일명에서 작성 주체를 명확히 구분하고, 공식적인 방법을 통해 생성기에 파일의 용도를 알려주며, 커밋을 기준으로 한 번 재생성하여 가정이 아닌 관찰을 통해 경계를 파악하는 것입니다.

그런 다음 합의 사항 자체는 특정 도구의 설정 폴더보다 더 넓은 공간에 보관하세요. 규칙은 특정 에디터에서 결정을 강제하는 수단일 뿐입니다. 진짜 보존할 가치가 있는 것은 그 결정 자체이며, 이는 폴더보다 더 오래 살아남습니다. 도구를 전환하는 팀들이 규칙을 옮기는 것은 쉽지만, 그 이면의 논리를 전달하는 것이 진짜 어려운 작업임을 깨닫는 이유가 바로 여기에 있습니다.