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

memory-bank/ 디렉토리는 그대로 전송됩니다. projectbrief.md, productContext.md, activeContext.md, systemPatterns.md, techContext.md, progress.md는 저장소에 있는 평범한 Markdown 파일입니다. 이 파일들 중 Cline에 종속된 것은 없습니다. Cline의 문서에서는 이를 "사용자와 Cline 모두가 액세스할 수 있는 프로젝트 내의 일반 markdown 파일"로 설명합니다. 이 파일들은 원래 위치에 그대로 두시면 됩니다.

AGENTS.md 파일이 있다면 이 또한 전송됩니다. Cline은 AGENTS.md 및 ~/.agents/AGENTS.md를 "도구 간 호환성을 위한 표준 형식"으로 읽습니다. Kilo Code는 프로젝트 루트에서 AGENTS.md를 읽고, 없을 경우 AGENT.md를 참조하며, 문서에서는 "파일명은 소문자가 아닌 대문자(AGENTS.md)여야 합니다"라고 경고합니다. 이미 이 파일을 가지고 계셨다면, 신경 쓸 필요 없이 그대로 사용하시면 됩니다.

.clinerules/ 디렉토리는 감지되는 소스로 전송되지 않습니다. Kilo Code가 문서화한 지침 소스는 프로젝트 루트의 AGENTS.md 및 AGENT.md, 프로젝트 및 글로벌 kilo.jsonc 내의 instructions 키, .kilo/rules/ 파일, 그리고 하위 호환성을 위한 .kilocode/rules/ 디렉토리 및 레거시 .kilocoderules 파일입니다. CLI는 "다른 도구와의 호환성을 위해 .claude/ 및 .agents/ 디렉토리도 지원"하지만, .clinerules/는 이 목록에 없습니다.

이 부분이 가장 까다로운 지점입니다. Cline의 설정을 따랐다면 Memory Bank 지침이 .clinerules/memory-bank.md에 위치하기 때문입니다. 이 문제를 해결하지 않고 Kilo Code로 이동하면, memory-bank/ 파일들이 저장소에 온전히 최신 상태로 존재하더라도 아무도 이를 읽지 않게 됩니다. Cline의 자체 지침 텍스트는 이 패턴에서 이것이 왜 치명적인지 명확히 설명합니다: "나는 모든 작업의 시작 시점에 반드시 모든 memory bank 파일을 읽어야 합니다 — 이는 선택 사항이 아닙니다." 지침을 제거하면 이 파일들은 아무도 열어보지 않는 문서로 전락합니다.

조건부 규칙은 전송되지 않습니다. Cline은 YAML 프론트 매터의 paths 배열을 통한 스코핑을 지원하며, 이를 실제 작업 컨텍스트와 비교하여 평가합니다: "현재 작업(열려 있는 파일, 표시된 탭, 언급된 경로, 편집된 파일)에서 컨텍스트를 수집하고, 각 규칙의 조건을 평가하여 일치하는 규칙을 활성화합니다." Kilo Code의 instructions 키는 파일 경로와 glob 패턴을 허용하지만, 이 glob들은 언제 로드할지가 아니라 어떤 파일을 로드할지를 선택합니다. Kilo Code가 문서화한 유일한 조건부 동작은 성격이 다릅니다. 디렉토리별 AGENTS.md 파일은 "에이전트가 해당 디렉토리의 파일을 읽을 때 동적으로 로드되며, 세션 시작 시 미리 로드되지 않습니다." 그리고 그 내용은 "대화에 <system-reminder> 태그로 주입"됩니다. 이는 유용하지만 glob 기반이 아닌 디렉토리 기반이므로, 전체 트리에서 **/*.test.ts로 범위를 지정한 규칙에 상응하는 직접적인 기능은 없습니다.

규칙 결합 방식이 다르게 작동합니다. Cline은 ".clinerules/ 내부의 모든 .md 및 .txt 파일을 처리하여 통합된 규칙 세트로 결합"하며, 선택적인 순서 지정 규칙으로 숫자 접두사를 사용하고, "작업 공간 규칙이 전역 규칙과 충돌할 때 우선순위를 갖습니다." 반면 Kilo Code는 명시적인 우선순위 목록을 제공합니다. 설정의 에이전트별 프롬프트가 가장 높고, 그 다음이 kilo.jsonc의 프로젝트 instructions 키, 그 다음이 프로젝트 루트의 AGENTS.md, 마지막이 전역 instructions 키이며, Skills는 필요에 따라 로드됩니다. 루트 AGENTS.md가 프로젝트 instructions 키보다 아래에 위치한다는 점에 유의하세요.

두 도구 모두 동일한 한계를 가지고 있습니다. 프로젝트와 구성원 전체에 걸쳐 팀이 학습한 내용을 누적하는 저장소에 대해서는 어느 도구도 문서화하고 있지 않습니다. Cline의 해법은 사용자가 직접 유지 관리하는 문서화 방법론이며, Kilo Code의 해법은 사용자가 유지 관리하는 AGENTS.md와 규칙 파일입니다. Memory Bank가 존재하는 이유는 바로 이러한 공백이 실재하기 때문입니다. 이는 도구가 잘 구성되어 있어도 assistants feel forgetful하게 느껴지는 이유이기도 합니다. 콘텐츠가 어디에 위치해야 할지 결정할 때 이 점을 기억할 가치가 있습니다.

1단계: 콘텐츠가 아닌 지침을 다시 연결하기

Kilo Code에서 Memory Bank 패턴을 실행하도록 만드는 두 가지 깔끔한 방법이 있으며, 이 둘은 동일하지 않습니다.

가장 간단한 옵션은 프로젝트의 kilo.jsonc에 있는 instructions 키를 사용하는 것입니다. 이미 가지고 있는 규칙 파일(동일한 .clinerules/memory-bank.md 또는 Cline 이름이 포함된 디렉토리를 유지하고 싶지 않다면 .kilo/rules/memory-bank.md로 복사하여 이동한 파일)을 가리키도록 설정하세요. Kilo Code의 문서에 따르면 instructions는 명시적 경로와 glob을 모두 허용하므로, 단일 항목으로 전체 규칙 폴더를 커버할 수 있습니다. 이는 우선순위 2단계에 위치하여 루트 AGENTS.md보다 위에 있으므로, 다른 어떤 것보다 먼저 실행되어야 하는 지침에 적합한 위치입니다.

또 다른 옵션은 지침 텍스트를 AGENTS.md에 직접 넣는 것입니다. 이는 Kilo Code의 지원 중단 안내가 가리키는 방향이며, 실제로 작동합니다. 하지만 이 경우 지침이 다음 단계에서 설명할 Kilo Code의 파일 보호 기능의 적용을 받게 되며, AGENTS.md 내의 다른 내용들과 공간을 두고 경쟁하게 됩니다.

어떤 방법을 선택하든 명령 어휘를 조정해야 합니다. Cline의 Memory Bank 지침은 "follow your custom instructions", "initialize memory bank", "update memory bank"라는 세 가지 문구를 중심으로 작성되었습니다. 첫 번째 문구는 Cline의 개념에 의존하는 부분입니다. 이를 "모든 작업을 시작하기 전에 memory-bank/에 있는 모든 파일을 읽으십시오"와 같은 직접적인 명령문으로 재작성하세요. 나머지 두 개는 에이전트에 대한 일반적인 영어 지침이므로 그대로 유지됩니다.

그런 다음 새 작업을 시작하고 에이전트가 어떤 지침을 로드했는지 물어보아 검증하세요. memory-bank/ 파일 목록이 나타나야 합니다. Cline은 여기서 "Conditional rules applied" 알림이라는 시각적 신호를 주었지만, 디렉토리별 파일에 대한 Kilo Code의 상응하는 신호는 <system-reminder> 주입이므로, 짐작하기보다는 직접 물어보는 것이 좋습니다.

2단계: memory-bank 콘텐츠를 AGENTS.md에 밀어 넣지 마세요

Kilo Code의 지원 중단 안내는 자체 memory bank에 대해 다음과 같은 2단계 마이그레이션을 제시합니다: ".kilo/rules/memory-bank/(또는 레거시 .kilocode/rules/memory-bank/)의 콘텐츠를 검토"하고 "해당 콘텐츠를 프로젝트의 AGENTS.md 파일로 이동(또는 Kilo Code에 대신 해달라고 요청)하십시오." 이 조언은 설명하는 대상에 대해서는 정확합니다. Kilo Code의 자체 memory bank는 규칙 디렉토리 내에 있었으므로, 이를 AGENTS.md로 통합하는 것이 단순화하는 길이기 때문입니다.

하지만 이를 Cline의 Memory Bank에 적용하면 작동 방식 자체가 망가집니다. Kilo Code의 자체 설명에 따르면 그 이유는 다음과 같습니다: "AGENTS.md와 AGENT.md는 모두 Kilo Code에서 쓰기 방지된 파일입니다." 즉, "AI 에이전트는 명시적인 사용자 승인 없이 이 파일들을 수정할 수 없으며", "이 파일들에 대한 변경 사항을 확인하라는 메시지가 표시됩니다."

Memory Bank는 정적인 문서가 아닙니다. activeContext.md는 Cline 문서에서 "가장 자주 업데이트되는" 파일로 설명하며 "매 세션 후에" 업데이트할 것을 권장하는 파일이고, progress.md는 마일스톤을 추적합니다. 전체 패턴은 여러분이 "update memory bank"라고 말할 때 에이전트가 해당 파일에 쓸 수 있는지 여부에 달려 있습니다. 이 파일들을 AGENTS.md에 병합하면 이러한 모든 쓰기 작업이 승인 프롬프트로 바뀌게 됩니다. 이는 프로젝트의 설정 파일에 대한 프롬프트를 무지성으로 클릭하도록 길들이거나, 업데이트 실행 자체를 중단하게 만들 것입니다.

따라서 분리 상태를 유지하세요. 지침은 지침 소스로 들어가고, 콘텐츠는 특별한 보호 조치가 없는 일반 프로젝트 파일인 memory-bank/*.md에 유지되어야 합니다. 이러한 분리는 Kilo Code와 무관하게 더 나은 관리 방식이기도 합니다. 에이전트가 지속적으로 다시 쓰는 파일을 프로젝트의 가이드라인을 정의하는 파일과 분리해 주기 때문입니다. 표준적인 AGENTS.md도 함께 사용하고 싶다면, migrating CLAUDE.md to AGENTS.md에서 해당 파일의 형태를 다루고 있으니 참고하세요.

예상되지만 걱정할 필요는 없는 한 가지가 더 있습니다. Kilo Code는 "[Memory Bank: Active] 및 [Memory Bank: Missing]과 같은 레거시 Memory Bank 상태 표시기가 여전히 나타날 수 있지만, 모든 클라이언트나 모드에서 보장되지는 않습니다"라고 명시하고 있습니다. 패턴이 활성화되어 있는지 확인하기 위해 배지를 확인해 오셨다면, 이제 멈추고 대신 에이전트에게 무엇을 로드했는지 물어보세요.

Memory Bank의 통찰은 옳습니다. 에이전트에게는 지속적인 기록이 필요하며, Markdown 폴더는 완전히 합리적인 첫 번째 구현 방식입니다. 하지만 그 한계 또한 구조적이며, 여러분도 이미 알고 계실 것입니다.

이는 저장소별로 존재하므로 여러 서비스에 걸친 지식은 복제되거나 유실되어야 합니다. 또한 활성화 지침이 도구에 종속적이기 때문에 실제로는 도구별로 작동하며, 이것이 바로 이 마이그레이션 단계가 필요한 이유입니다. 검색(retrieval) 기능이 없어 관련성 여부와 관계없이 모든 작업에서 6개 파일을 모두 읽습니다. 그리고 "update memory bank"를 실행하는 것을 기억하는 사람에게만 종속되므로, 팀 내에서 쉽게 낡은 정보가 되고 사람이 떠날 때 컨텍스트도 함께 사라지게 됩니다. 이 문제는 keeping AI context when someone leaves에서 다룬 바 있습니다.

MemoryLake는 이러한 네 가지 한계를 제거한 동일한 개념입니다. 저장소나 에디터 외부의 단일 저장소로, MCP나 API를 통해 읽을 수 있고, 전체를 읽는 대신 검색이 가능하며, 팀 전체에서 공유됩니다. 여러분의 memory-bank/ 파일들은 이를 위한 좋은 시작점이 될 것입니다.

1단계: API 키 생성하기

키를 생성하고 약 30초 만에 첫 번째 요청을 보낼 수 있습니다. 하나의 키로 Kilo Code, 팀원들이 여전히 사용 중인 Cline, 그리고 다음에 등장할 어떤 도구에서든 작동합니다.

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

이미 가지고 있는 문서, 이미지, 파일을 끌어다 놓으세요. README의 내용을 단순히 반복하기보다 실제 결정 사항들을 담고 있는 systemPatterns.md, techContext.md, progress.md부터 시작하는 것이 좋습니다.

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

Claude, Codex, OpenClaw 및 기타 에이전트에게 MCP 또는 API를 통해 액세스 권한을 부여하세요. Kilo Code에서는 이를 통해 "매 작업마다 6개 파일을 모두 읽는 것"이 현재 작업에 중요한 두 가지 사실만 검색하는 방식으로 바뀝니다.

의무적인 전체 읽기 과정이 사라집니다. Cline의 지침 텍스트가 매 작업 시작 시 모든 memory bank 파일을 읽도록 고집하는 이유는 검색 레이어가 없기 때문입니다. 관련 파일이 포함되도록 보장하는 유일한 방법이기 때문입니다. 검색 기능이 도입되면 에이전트가 re-read the codebase every session할 필요가 없어지는 것과 마찬가지로, 이 요구 사항도 더 이상 필요하지 않게 됩니다.

activeContext.md가 동기화에서 벗어나는 현상이 멈춥니다. Cline이 가장 자주 변경된다고 표시한 파일은 가장 쉽게 낡은 정보가 될 가능성이 높습니다. 이미 정신적으로 종료한 세션의 끝에 수동으로 업데이트해야 하기 때문입니다. 수정을 가할 때 바로 캡처하는 것이 나중에 세션을 재구성하는 것보다 훨씬 작은 작업입니다.

도구를 이동해도 지식에 영향을 주지 않습니다. 이번 마이그레이션이 번거로운 이유는 활성화 지침이 도구 맞춤형이기 때문입니다. 콘텐츠가 외부에 존재하면 도구를 변경할 때 새로 읽어올 대상을 감사하는 대신, 단 하나의 새로운 지침만 작성하면 됩니다.

그리고 6개 파일 구조는 필수적인 버팀목이 아닌 선택 사항이 됩니다. 이는 폴더 전체를 읽어야 했던 환경에서는 합리적인 스키마였습니다. 검색 기능이 존재하면 이 구조를 유지할 수도 있고, 핵심 사실들만 남겨둘 수도 있습니다.

신뢰하기 전에 감지 여부를 확인하세요. .clinerules/는 Kilo Code의 문서화된 목록에 없습니다. 작업을 시작하고 무엇이 로드되었는지 물어보세요.

쓰기 작업이 빈번한 파일은 AGENTS.md에 넣지 마세요. 이 파일은 의도적으로 쓰기 방지되어 있어 가이드라인을 설정하는 데는 좋지만, 실행 로그를 기록하는 데는 적합하지 않습니다.

범위 지정을 위해 디렉토리 배치를 활용하세요. Kilo Code의 디렉토리별 AGENTS.md 파일은 에이전트가 해당 디렉토리의 파일을 읽을 때 지연 로드(lazy load)됩니다. 이는 Cline의 조건부 규칙과 가장 유사한 기능이며, glob이 아닌 디렉토리 단위로 작동합니다.

우선순위를 염두에 두세요. kilo.jsonc 내의 프로젝트 instructions가 루트 AGENTS.md보다 우선합니다. 두 소스가 충돌한다면 대개 이 때문입니다.

재로드를 예상하세요. Kilo Code는 "AGENTS.md에 대한 변경 사항은 새 작업에서 적용됩니다(재로드가 필요할 수 있음)"라고 명시하고 있습니다. 작업 중간에 편집한 규칙을 디버깅하려고 하지 마세요.

상태 배지에 의존하지 마세요. 레거시 Memory Bank 표시기는 명시적으로 "모든 클라이언트나 모드에서 보장되지 않습니다."

이번 마이그레이션은 겉보기에 적대적으로 보일 수 있습니다. memory bank를 지원 중단한 도구로 Memory Bank를 이동하는 것이니까요. 하지만 그렇지 않습니다. Kilo Code는 기능 래퍼를 중단한 것이며, Cline의 자체 문서에서도 이 방법론은 "문서를 읽을 수 있는 모든 AI에서 작동한다"고 말합니다. 파일들은 아무 문제 없습니다.

두 가지 사항에 주의해야 합니다. Kilo Code의 문서화된 지침 소스에는 .clinerules/가 포함되어 있지 않으므로, 패턴을 실행하는 규칙을 다시 연결해야 합니다. 루트 AGENTS.md보다 우선순위가 높은 kilo.jsonc 내의 instructions 키를 통하는 것이 가장 이상적입니다. 또한 memory bank 콘텐츠를 AGENTS.md로 이동하라는 Kilo Code의 지원 중단 권장 사항은 Cline 버전에 적용해서는 안 됩니다. AGENTS.md는 쓰기 방지되어 있고 에이전트는 이 파일들에 지속적으로 써야 하기 때문입니다. 지침은 안으로, 콘텐츠는 밖에 두세요.

이 두 가지만 올바르게 처리하면 잃을 것이 없습니다. 그렇다면 더 흥미로운 질문은 매 작업마다 저장소별 폴더 전체를 읽는 방식이 여전히 팀의 지식을 담기에 가장 좋은 방법인가 하는 점입니다. 아니면 오늘 아침에 어떤 에디터를 열었는지와 무관하게 검색 가능하고, 공유되며, 독립적인 곳에 보관하는 것이 더 나을까요?