Cline의 Memory Bank 설정 및 최신 상태 유지 방법 (단계별 가이드, 2026)

이것은 문서이며, 문서는 노후화됩니다

Memory Bank를 구동하는 맞춤형 지침(custom instruction) 블록은 1인칭으로 작성되어 있으며, 문자 그대로 읽어볼 가치가 있습니다. "나는 Cline이며, 독특한 특징을 가진 전문 소프트웨어 엔지니어입니다. 내 기억은 세션 사이에 완전히 초기화됩니다. 이것은 한계가 아니라 내가 완벽한 문서를 유지하도록 이끄는 원동력입니다. 매번 초기화된 후, 나는 프로젝트를 이해하고 작업을 효과적으로 계속하기 위해 전적으로(ENTIRELY) 나의 Memory Bank에 의존합니다."

모든 것은 이 문장에서 비롯됩니다. Cline은 기억하는 것이 아니라 읽는 것입니다. 파일에 프로젝트가 REST를 사용한다고 적혀 있는데 3주 전에 GraphQL로 전환했다면, Cline이 혼란스러워하는 것이 아닙니다. 잘못 작성된 파일의 내용을 정확하게 따르고 있을 뿐입니다.

6개의 파일 중 하나가 다른 파일들보다 훨씬 빠르게 변경됩니다

핵심 구조는 의도적인 계층 구조를 가진 6개의 파일입니다. 모든 다른 파일의 형태를 결정하는 기초 문서인 projectbrief.md를 시작으로, 이를 기반으로 구축되는 productContext.md, systemPatterns.md, techContext.md가 있으며, 이들은 다시 activeContext.md와 progress.md로 이어집니다.

이 6개의 파일이 노후화되는 속도는 제각각입니다. projectbrief.md는 1년 동안 유효할 수 있습니다. 반면 activeContext.md는 "현재 집중하고 있는 작업, 최근 변경 사항, 다음 단계"를 다루며, 문서에 따르면 "가장 자주 업데이트"됩니다.

이러한 불균형이 유지 관리의 핵심 문제입니다. 가장 낡기 쉬운 파일이 동시에 Cline이 작업을 시작할 때 가장 크게 의존하는 파일이기도 합니다. 어제 무엇을 하고 있었는지 설명하는 파일이기 때문입니다.

업데이트는 누군가 기억해서 실행해야 하는 명령어입니다

Cline은 세 가지 명령어를 제공합니다. 구조를 생성하는 "initialize memory bank", "전체 문서 검토 및 업데이트"를 트리거하는 "update memory bank", 그리고 Cline이 뱅크를 읽고 중단된 부분부터 계속하도록 하는 "follow your custom instructions"입니다.

문서에서는 업데이트를 트리거해야 하는 네 가지 조건으로 "새로운 프로젝트 패턴 발견 시", "중요한 변경 사항을 구현한 후", "사용자가 update memory bank로 요청할 때 (반드시 모든 파일을 검토해야 함)", "컨텍스트 명확화가 필요할 때"를 나열합니다.

이 네 가지 중 세 가지는 사람이 직접 인지해야 합니다. 이는 설계에 대한 비판이 아니라 문서화 방법론의 본질입니다. 하지만 이를 통해 우리가 어디에 노력을 기울여야 하는지 알 수 있습니다.

한 번 초기화하고 다시는 손대지 않기. 가장 흔한 패턴이며, 대략 2주 동안은 잘 작동합니다. 그러다 뱅크가 더 이상 존재하지 않는 버전의 프로젝트를 설명하게 되고, Cline은 이를 확신을 가지고 읽기 때문에 잘못된 컨텍스트는 컨텍스트가 없는 것보다 더 나쁜 결과를 초래합니다.

무언가 고장 났을 때만 "update memory bank" 실행하기. 그때가 되면 업데이트는 점진적인 수정이 아니라 전체 재작성이 되며, 전체 재작성은 계속 미뤄지게 됩니다.

모든 것을 activeContext.md에 집어넣기. 사람들이 가장 자주 열어보는 파일이다 보니, 아키텍처 노트, 기술 스택 결정 사항, 미해결 질문 등이 쌓여 결국 현재 집중하고 있는 작업의 요약본 역할을 잃게 됩니다. 계층 구조는 바로 이러한 현상을 방지하기 위해 존재합니다.

Memory Bank를 자동 압축(auto-compaction)의 대체재로 취급하기. 이 둘은 서로 다른 도구입니다. 문서에서도 다음과 같이 명확히 구분하고 있습니다. "일상적인 컨텍스트 관리는 Auto Compact가 처리하도록 두고, 수동 'update memory bank'는 중요한 체크포인트를 위해 아껴둘 수 있습니다."

올바른 폴더에 .md 파일이 있는 것만으로 충분하다고 가정하기. Memory Bank가 작동하려면 지침 블록이 활성화되어 있어야 합니다. .clinerules/memory-bank.md와 같은 Cline Rules 파일에 복사하거나 글로벌 맞춤형 지침에 넣어야 합니다. 그렇지 않으면 이 파일들은 그냥 일반 파일일 뿐이며, 이는 에이전트가 지침 파일을 무시하는 이유에서 설명하는 에이전트가 지침 파일을 무시하는 한 가지 원인이 됩니다.

한 대의 컴퓨터에만 설정해 두고 팀 전체가 가지고 있다고 가정하기. 지침 블록이 리포지토리가 아닌 개인의 글로벌 맞춤형 지침에만 있다면, 동료들은 Memory Bank를 전혀 사용하지 못하고 있는 것입니다. 그들에게는 그저 아무 에이전트도 읽지 않는 마크다운 파일 폴더일 뿐입니다. 이 경우 증상이 혼란스러운데, 내가 관리하기 때문에 뱅크는 잘 유지되는 것처럼 보이지만 다른 사람들에게는 아무런 효과가 없는 것처럼 보입니다.

다음 사람 대신 모델만을 위해 뱅크 작성하기. 이 파일들은 리포지토리에 있는 일반 마크다운 파일이므로, 코드 리뷰나 온보딩 중에 사람이 읽게 됩니다. 간결한 키워드 목록으로만 작성된 항목은 작성하기는 쉽지만, 한 달 후에 두 대상 모두가 검증하기는 훨씬 더 어렵습니다.

설정은 3단계로 진행되며, 세 번째 단계는 대부분의 가이드에서 생략하는 부분입니다.

1단계: 지침 설치 후 초기화

Cline 문서에서 Memory Bank 맞춤형 지침 블록을 복사하여 Cline Rules 파일(문서에서 예시로 든 .clinerules/memory-bank.md)에 붙여넣은 다음, Cline에게 "initialize memory bank"를 요청합니다.

위치는 신중하게 선택해야 합니다. Cline FAQ에서는 이를 트레이드오프 관계로 설명합니다. "맞춤형 지침은 모든 프로젝트에 전역적으로 적용됩니다. 반면 Cline Rules 파일은 프로젝트 전용이며 리포지토리에 저장되므로 협업자와 쉽게 공유할 수 있습니다." 두 명 이상이 참여하는 프로젝트라면 리포지토리 버전이 무조건 유리합니다. 나만 가지고 있는 전역 지침은 나만 관리하는 Memory Bank를 만들기 때문입니다.

알아두면 좋은 세 번째 옵션도 있습니다. 조건부 규칙을 사용하여 "memory-bank/ 파일로 작업할 때만 Memory Bank 지침을 활성화"하는 것입니다. 항상 켜져 있는 버전이 컨텍스트를 너무 많이 차지할 때 유용합니다.

6개의 파일을 직접 작성하기보다는 Cline이 초기 구조를 생성하도록 하세요. 문서에서는 기본 프로젝트 브리프(project brief)로 시작하여 구조를 점진적으로 발전시킬 것을 권장하며, Cline은 사람이 템플릿을 채우는 것보다 더 일관되게 계층 구조를 구성합니다.

2단계: 변경 속도에 따라 6개의 파일을 분류하고, 그 주기에 맞춰 업데이트하기

누가, 무엇을, 언제 업데이트할지 한 번 정리해 두세요. 효과적인 예시는 다음과 같습니다.

• projectbrief.md 및 productContext.md — 세션 단위가 아닌 마일스톤 단위로 검토합니다.
• systemPatterns.md 및 techContext.md — 아키텍처나 종속성 결정이 실제로 변경될 때, 해당 변경 사항과 동일한 커밋에서 업데이트합니다.
• activeContext.md — 각 작업 세션이 끝날 때 업데이트합니다. 문서에서도 명시하고 있듯이 "가장 자주 변경되므로 각 세션 후에 업데이트"해야 합니다.
• progress.md — "마일스톤을 추적"하므로 작업을 재개할 때 검토합니다.

그런 다음 문서에 설명된 컨텍스트 창(context-window) 워크플로우를 사용하세요. 이는 유지 관리 의식의 역할도 겸합니다. 컨텍스트 창이 가득 차면, Cline에게 "update memory bank"를 요청하여 현재 상태를 기록하고, 새 대화를 시작한 다음, Cline에게 "follow your custom instructions"를 요청합니다. 이 세 가지 동작만으로 새로운 컨텍스트 창과 최신 상태의 뱅크를 동시에 얻을 수 있으며, 이는 달력 알림보다 훨씬 더 확실합니다.

전체 업데이트 시 한 가지 주의할 점이 있습니다. "update memory bank"는 Cline이 "반드시 모든 파일을 검토해야 함"을 의미합니다. 이는 철저하지만 비용이 듭니다. 대규모 뱅크의 경우 상당한 리소스가 소모됩니다. 따라서 이는 체크포인트용으로 아껴두고, 일상적인 정리는 FAQ의 제안대로 Auto Compact를 통해 처리하도록 하세요.

3단계: 리포지토리보다 오래 지속되는 사실들은 다른 곳에 보관하기

여기에 이 설계의 한계가 있습니다. Memory Bank는 프로젝트 디렉토리로 범위가 제한되고 코드베이스를 중심으로 형성됩니다. 이는 systemPatterns.md에는 적합하지만, 에이전트가 필요로 하는 다른 많은 정보에는 적합하지 않습니다.

고객 및 도메인 관련 세부 정보, 다루는 모든 리포지토리에 공통으로 적용되는 작업 방식에 대한 선호도, 결과보다 그 과정의 논리가 더 중요한 결정 사항들, 그리고 다른 도구를 사용하는 팀원과 공유해야 하는 모든 것들이 이에 해당합니다.

이러한 정보는 단일 리포지토리의 6개 마크다운 파일에 속하지 않으며, 억지로 밀어 넣으면 Memory Bank가 비대해지는 동시에 낡아버리게 됩니다. 리포지토리 외부의 메모리 레이어가 프로젝트 간 공유되는 절반을 담당하고, Memory Bank는 본연의 역할에 집중하도록 해야 합니다. MemoryLake는 3단계로 설정할 수 있습니다.

1단계: API 키 생성

로그인 후 대시보드에서 API 키를 생성합니다. 이 키는 리포지토리가 아닌 사용자 개인에게 귀속되므로, 새로운 Memory Bank를 만들 때마다 매번 다시 설정할 필요 없이 동일한 지식이 프로젝트 간에 유지됩니다.

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

현재 집중하고 있는 작업과는 무관하지만 activeContext.md에 붙여넣고 싶었던 내용들부터 시작해 보세요. 고정된 선호도, 도메인 용어집, 고객 세부 정보, 결정 사항 및 그 배경 이유 등이 이에 해당합니다. 그런 다음 다른 리포지토리에서 이미 반복해서 설명했던 내용들을 추가합니다.

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

Cline이 해당 저장소를 가리키도록 설정합니다. 리포지토리 전용 정보는 팀원들이 풀 리퀘스트(PR)에서 검토할 수 있도록 Memory Bank에 유지되고, 영구적인 정보는 새 프로젝트를 시작할 때마다 매번 다시 입력할 필요가 없어집니다.

첫 번째 변화는 activeContext.md 파일이 가벼워져서 정확하게 유지된다는 점입니다. 현재 집중하고 있는 작업만 담고 있는 파일은 세션이 끝날 때 30초 만에 솔직하게 업데이트할 수 있습니다. 반면 일반적인 지식 저장소가 되어버린 파일은 업데이트를 건너뛰게 됩니다.

두 번째는 새로운 리포지토리를 시작할 때 아무것도 없는 백지 상태에서 시작하지 않아도 된다는 점입니다. 현재는 새 프로젝트를 시작하면 아무것도 없는 새 Memory Bank가 생성되므로, Cline이 이미 두 번이나 학습한 선호도를 다시 설정하는 데 첫 주를 허비하게 됩니다. 영구적인 정보가 외부에 저장되어 있으면 프로젝트 전용 파일만 새로 작성하면 됩니다.

세 번째는 다른 도구를 사용하는 팀원도 소외되지 않는다는 점입니다. Memory Bank는 Cline의 관례입니다. 다른 에이전트를 사용하는 동료는 이를 메모리가 아닌 단순 문서로만 읽을 수 있습니다. 팀의 절반이 전환한 경우(예: Cursor에서 Cline으로의 전환 이후), 공유 레이어를 통해 양쪽 모두가 동일한 사실을 바탕으로 작업할 수 있습니다.

• 두 명 이상이 참여하는 프로젝트의 경우, 지침 블록을 전역 설정이 아닌 리포지토리에 두세요.
• 매 세션이 끝날 때마다 activeContext.md를 업데이트하세요. 이는 세션 단위로 업데이트해야 하는 유일한 파일이며, Cline이 가장 집중적으로 읽는 파일입니다.
• 아키텍처 업데이트는 아키텍처를 변경하는 커밋과 연동하세요. systemPatterns.md를 별도의 귀찮은 작업으로 따로 업데이트해서는 안 됩니다.
• 컨텍스트 창이 가득 차는 시점을 업데이트 트리거로 활용하세요. 업데이트 후 새 대화를 시작하고 "follow your custom instructions"를 실행합니다. 이미 하고 있는 작업에 자연스럽게 유지 관리를 녹여낼 수 있습니다.
• 전체 "update memory bank" 실행은 체크포인트용으로 아껴두세요. 모든 파일을 검토하므로, 일상적인 컨텍스트 관리는 Auto Compact에 맡기세요.
• 특정 주제에 깊이가 필요할 때는 memory-bank/ 아래에 새 파일을 추가하세요. 문서에서도 복잡한 기능, 통합 사양 또는 테스트 전략을 위해 새 파일을 추가하는 것을 허용합니다. 한 파일을 무한정 키우지 마세요.
• 프로젝트 간 공유되는 지식은 제외하세요. 다음 리포지토리에서도 동일하게 적용되는 사실이라면, Memory Bank는 적절한 보관 장소가 아닙니다.
• 한 달에 한 번은 직접 뱅크를 읽어보세요. 리포지토리에 있는 일반 마크다운 파일이라는 점이 가장 큰 장점이며, 이는 사람이 직접 확인하면 노후화된 부분을 쉽게 발견할 수 있음을 의미합니다. AI가 기억하는 내용 감사하기는 숨겨진 저장소뿐만 아니라 여기에도 동일하게 적용됩니다.

Memory Bank는 이 분야에서 가장 정직한 설계 중 하나입니다. 모델이 무언가를 기억한다고 주장하지 않고, 기억은 초기화되며 문서만이 살아남는다고 말합니다. 그 정직함이 바로 이것이 작동하는 이유이자 동시에 노후화되는 이유입니다. 문서화에 기반한 시스템은 문서화의 실패 모드를 그대로 물려받기 때문입니다.

리포지토리에 이를 설정하고, 변경 속도에 따라 6개의 파일을 분류하고, 이미 하고 있는 작업에 업데이트를 연동하고, 이 리포지토리보다 오래 지속되는 지식은 리포지토리 외부의 더 오래 지속되는 곳에 보관하세요.