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

먼저 Memory Bank가 실제로 무엇인지부터 짚고 넘어가겠습니다. 공식 문서에는 대부분의 사람들이 생각하는 것보다 더 명확하게 설명되어 있습니다.

"Memory Bank는 Cline을 상태가 없는(stateless) 어시스턴트에서 지속적인 개발 파트너로 전환하는 문서화 방법론(methodology)입니다. 구조화된 마크다운 파일을 통해 Cline은 세션 전반에 걸쳐 프로젝트 세부 정보를 '기억'할 수 있습니다."

방법론(methodology)이라는 단어에 주목하세요. 설정 지침에서도 이를 확인할 수 있습니다. 커스텀 지침 블록을 복사하여 ".clinerules/memory-bank.md와 같은 Cline Rules 파일에 추가"하라고 되어 있습니다. 별도의 토글 스위치는 없습니다. 이 기능은 규칙 파일에 상주하는 프롬프트 규칙과, 그 규칙이 에이전트에게 읽으라고 지시하는 문서 폴더의 조합일 뿐입니다. 만약 setting up Cline's Memory Bank를 따라 설정하셨다면, 방금 복사해 붙여넣었던 그 규칙 파일이 바로 잃게 될 부분이며, 폴더 자체가 사라지는 것은 아닙니다.

폴더 자체는 평범합니다.

"Memory Bank 파일은 프로젝트 내의 일반 마크다운 파일로, 사용자와 Cline 모두 액세스할 수 있습니다. 프로젝트의 전체적인 그림을 그릴 수 있도록 계층적으로 구성되어 있습니다."

각각의 역할을 가진 6개의 파일이 있습니다. 기초 문서인 projectbrief.md, 프로젝트의 존재 이유를 담은 productContext.md, 현재의 초점과 최근 변경 사항을 기록하는 activeContext.md, 아키텍처 및 디자인 패턴을 위한 systemPatterns.md, 기술 스택과 제약 조건을 위한 techContext.md, 그리고 진행 상황과 남은 작업을 기록하는 progress.md입니다. 사용자는 특정 문구로 이를 실행합니다. 문서에는 Cline이 뱅크를 읽고 중단된 부분부터 계속하도록 만드는 "follow your custom instructions"와, "전체 문서 검토 및 업데이트"를 트리거하는 "update memory bank"가 나열되어 있습니다.

따라서 마이그레이션은 깔끔하게 두 갈래로 나뉩니다. 문서(documents)는 완벽하게 전송됩니다. 리포지토리 내의 마크다운 파일이므로 그대로 유지됩니다. 하지만 메커니즘(mechanism)은 전혀 전송되지 않으며, 그 이유는 다음과 같습니다.

Zencoder 문서에 따르면 컨텍스트는 메시지당 5가지 소스에서 조립됩니다. 프로젝트의 파일 구조 및 종속성에 대한 작업 공간 분석, 현재 에디터에 열려 있는 파일, 일치하는 스킬(skills), @ 언급으로 첨부한 항목, 그리고 실행 중 에이전트가 자체 도구로 수집한 컨텍스트입니다. 이것이 컨텍스트가 도달하는 전체 경로이며, 이 5가지 중 항상 로드되는 리포지토리 지침 파일은 존재하지 않습니다.

Zencoder가 가진 영구적이고 버전 관리되는 영역은 바로 스킬(skills)입니다.

"스킬은 .agents/skills/에 SKILL.md 파일로 저장되며 리포지토리와 함께 버전 관리됩니다."

Zencoder는 세 가지 위치에서 스킬을 읽습니다. 프로젝트 스킬을 위한 <workspace>/.agents/skills/, 사용자 수준 스킬을 위한 <user-home>/.agents/skills/, 그리고 문서에서 "Claude 호환 스킬"로 분류하는 <workspace>/.claude/skills/입니다. 기존의 .zencoder/skills/ 경로는 "더 이상 권장되지 않지만(deprecated) 여전히 지원됨"으로 설명되어 있습니다.

그리고 이제 마이그레이션 계획을 결정짓는 문장이 나옵니다.

"스킬은 작업 컨텍스트를 기반으로 에이전트에 의해 자동으로 선택됩니다. 수동 스킬 선택은 현재 지원되지 않습니다."

스킬은 에이전트가 해당 스킬의 description(설명)이 현재 작업과 일치한다고 판단할 때 로드됩니다. 문서에서는 설명이 핵심 역할을 한다고 명시하고 있습니다. 즉, "스킬이 수행하는 작업 — 에이전트는 이를 사용하여 로드할 시기를 결정함"이며, 지침은 "명확한 트리거 조건으로 작성하라"는 것입니다.

이 두 가지 사실을 종합해 보세요. Cline의 Memory Bank는 모든 작업이 시작될 때 무조건 실행되는 지침에 의존합니다. 반면 Zencoder의 상응하는 영역은 설명 일치 시에만 실행되며, 이를 강제할 수 있는 수동 오버라이드 방법은 없습니다. memory-bank/ 폴더를 Zencoder 프로젝트에 복사해 넣는 것만으로는 아무도 열어볼 의무가 없는 6개의 파일만 남게 됩니다.

반대의 경우도 확인해 보겠습니다. Zencoder 문서는 스킬, 메시지별 컨텍스트 조립, 다중 리포지토리 검색을 설명합니다. 세션 전반에 걸쳐 사실을 축적하는 대화형 메모리 저장소에 대해서는 설명하지 않습니다. 오히려 자체 가이드에서는 반대로 조언합니다. "길고 여러 주제가 섞인 대화는 오래된 컨텍스트를 축적합니다. 에이전트의 컨텍스트를 깨끗하게 유지하려면 각 고유 작업마다 새 대화를 시작하세요." 이는 좋은 조언이며, 모든 작업이 리포지토리와 에이전트가 로드하기로 선택한 정보만으로 시작됨을 의미합니다.

1단계: 뱅크를 절차와 상시 사실로 분할하기

6개의 파일을 열고 파일 이름이 아닌 형태에 따라 내용을 다시 분류하세요. 대상 플랫폼(Zencoder)에는 단 하나의 컨테이너만 존재하며, 이는 절차 중심의 형태를 띠고 있기 때문입니다.

릴리스 실행 방법, 마이그레이션 추가 방법, 검토 체크리스트 작동 방식 등 순서가 있는 시퀀스처럼 읽히는 모든 것은 스킬 후보입니다. 이는 자연스러운 트리거 조건("데이터베이스 마이그레이션을 추가할 때 이 스킬을 사용하십시오")을 가지므로 설명이 안정적으로 일치할 수 있고 잘 작동할 것입니다.

상시 사실(standing fact)처럼 읽히는 모든 것은 까다로운 부류입니다. 이벤트 버스가 왜 그렇게 구성되었는지 설명하는 systemPatterns.md, 명백해 보이는 라이브러리를 배제하는 제약 조건을 나열한 techContext.md, 제품의 실제 목적을 설명하는 projectbrief.md 등은 거의 모든 작업과 관련이 있고 특정 작업에 국한되지 않기 때문에 트리거 조건이 없습니다. "항상"에 일치하는 설명을 작성하는 것은 이 메커니즘의 목적이 아닙니다.

그리고 둘 다 아닌 activeContext.md와 progress.md가 있습니다. 이들은 상황이 어떻게 진행되고 있는지에 대한 실행 로그입니다. 이 두 파일은 Memory Bank가 단순한 문서가 아니라 메모리처럼 느껴지게 만들었던 이유였지만, 이제는 갈 곳이 전혀 없는 파일들입니다. 이는 Cline forgetting task history와 같은 불만의 원인이 되는 공백이지만, 이제 그 손실은 컨텍스트 창의 문제가 아니라 구조적인 문제입니다.

2단계: 절차 스킬 작성 및 설명 세심하게 작성하기

.agents/skills/ 아래에 절차당 하나의 폴더를 만들고, 각각 name과 description을 포함하는 SKILL.md를 작성합니다. 설명이 활성화 메커니즘의 전부이므로 여기에 공을 들이셔야 합니다. "API helper skill"은 일치하지 않겠지만, "사용자가 API 엔드포인트를 생성하거나 수정하도록 요청할 때 이 스킬을 사용하십시오"는 일치할 것입니다.

알아두면 좋은 두 가지 필드가 있습니다. paths는 스킬의 범위를 특정 파일로 제한하는 glob 패턴을 허용하므로, 설명만 사용하는 것보다 조건부 로드에 더 가까워집니다. 그리고 disable-model-invocation을 true로 설정하면 에이전트가 스킬을 자동 선택하는 것을 중단합니다. 수동 선택이 지원되지 않는다는 점을 고려하면 이는 사실상 해당 스킬을 비활성화하는 것이므로, 신중하게 사용하거나 아예 사용하지 마십시오.

팀에서 Claude 기반 도구도 함께 사용하는 경우, Zencoder가 <workspace>/.claude/skills/도 읽는다는 점에 유의하세요. 두 개의 복사본을 유지하는 대신 하나의 폴더로 두 도구 모두에 서비스를 제공할 수 있습니다.

하지 말아야 할 일은 모호한 설명을 가진 스킬에 상시 사실들을 쑤셔 넣고 잘 되기를 바라는 것입니다. 그렇게 하면 why agent skills aren't memory에서 다루는 실패 사례, 즉 기술적으로는 존재하지만 정작 중요할 때는 절대 로드되지 않는 문서가 되는 결과를 초래하게 됩니다.

분류할 수 없었던 파일들이 가장 가치 있는 것들입니다. 아키텍처 결정 이유, 기각된 대안들, 이상해 보이는 모듈을 설명하는 제약 조건, 프로젝트의 현재 상태 등은 Memory Bank를 유지할 가치가 있게 만들었던 콘텐츠이지만, Zencoder의 활성화 모델은 이에 대한 신뢰할 수 있는 트리거를 제공하지 않습니다.

MemoryLake는 이 레이어를 에디터 외부에 보관하고 MCP 또는 API를 통해 이에 대한 질문에 답변합니다. 에이전트는 설명만 보고 콘텐츠가 관련이 있는지 추측할 필요가 없으며, 질문이 생기면 직접 물어봅니다. 절차 스킬은 Zencoder가 작업 일치에 따라 로드하는 .agents/skills/에 그대로 유지되고, 상시 사실은 에이전트가 이번 차례에 무엇을 로드하기로 결정했는지와 관계없이 항상 답변 가능한 상태로 유지됩니다.

1단계: API 키 생성하기

키를 생성하고 약 30초 만에 첫 번째 요청을 보내보세요. 위의 1단계를 수행하기 전에 이 작업을 먼저 완료하면, 6개의 파일을 분류하면서 각 사실을 저장할 공간을 확보할 수 있습니다.

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

분류할 수 없었던 파일들을 하나씩 처리해 나갑니다. systemPatterns.md의 아키텍처 결정 사항, techContext.md의 제약 조건, projectbrief.md 및 productContext.md에서의 제품 의도, 그리고 activeContext.md 및 progress.md에서의 현재 상태를 정리합니다. 각각을 결정 사항과 그 이유로 작성하세요. 지원 문서도 같은 위치에 저장됩니다. turning project docs into AI memory에서 모든 것을 다시 작성하지 않고 이 작업을 수행하는 방법을 다룹니다.

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

Zencoder, Claude, Codex 및 기타 에이전트에 MCP 또는 API를 통한 액세스 권한을 부여합니다. 모든 새로운 대화(Zencoder가 권장하는 대로 자주 시작하는 대화들)는 프로젝트가 왜 그렇게 구성되었는지에 대해 답변할 수 있는 상태로 시작됩니다.

첫 번째 변화는 새로운 대화를 시작하는 데 더 이상 부담이 없어진다는 점입니다. Zencoder가 작업당 새 대화를 권장하는 이유는 오래된 컨텍스트가 방해가 되기 때문인데, 이 권장 사항은 영구적인 지식이 애초에 대화방에 들어있지 않을 때만 편안하게 받아들여질 수 있습니다.

두 번째는 스킬의 범위가 좁아지면서 더 정교해진다는 점입니다. 상시 사실이 머무를 다른 공간이 생기면, 각 스킬은 하나의 명확한 설명을 가진 하나의 절차가 될 수 있으며, 이는 설명 매칭이 가장 잘 작동하는 조건입니다.

세 번째는 로그 파일의 손실이 더 이상 발생하지 않는다는 점입니다. activeContext.md와 progress.md는 새 도구에서 갈 곳이 없었습니다. 날짜와 함께 결정 사항으로 기록되면, 이 파일들은 새로운 팀원이 대화 기록을 스크롤하는 대신 읽을 수 있는 유용한 자료가 됩니다.

네 번째는 다음 마이그레이션이 이번 마이그레이션보다 훨씬 쉬워진다는 점입니다. 이번 마이그레이션이 까다로웠던 이유는 Cline의 메커니즘은 규칙 파일이었고 Zencoder의 메커니즘은 설명 매칭이었기 때문입니다. 두 도구 모두에 종속되지 않는 독립적인 레이어는 다음 도구가 어떤 메커니즘을 선택하든 상관하지 않습니다. 이는 Cline forgetting project context 및 다른 모든 도구의 유사한 문제들이 동일한 근본적인 해결책을 공유하는 이유와 같습니다.

설명(description)을 핵심 기능으로 취급하세요. 스킬의 설명은 활성화 메커니즘의 전부입니다. 주제를 나타내는 레이블이 아니라 상황을 명시하는 트리거 조건으로 작성하세요.

스킬당 하나의 절차만 할당하세요. 관련 없는 세 가지 절차를 하나로 묶으면 그 중 어느 것과도 깔끔하게 일치하지 않는 설명이 됩니다.

파일 범위 작업에는 paths를 염두에 두세요. Glob 범위 지정은 조건부 로드에 가장 가까운 방법이며 광범위한 설명보다 더 안정적입니다.

disable-model-invocation을 가볍게 설정하지 마세요. 수동 선택이 지원되지 않는 상황에서 자동 선택을 비활성화하면 스킬을 사용할 수 있는 유일한 경로가 차단됩니다.

기존의 레거시 스킬 경로에서 마이그레이션하세요. 문서에서는 .zencoder/skills/를 더 이상 권장하지 않지만 지원되는 경로로 설명하며, 현재 표준에 맞추기 위해 .agents/skills/를 권장합니다.

Claude 도구와 하나의 스킬 폴더를 공유하세요. Zencoder는 .claude/skills/도 읽으므로 두 도구를 모두 사용하는 팀은 중복 폴더를 유지할 필요가 없습니다.

스킬이 항상 켜져 있는 규칙처럼 작동할 것이라 기대하지 마세요. 모든 작업에서 항상 참이어야 하는 내용이 있다면, 작업 매칭 방식의 컨테이너는 적절한 저장소가 아닙니다.

Cline의 Memory Bank는 마크다운 폴더와 에이전트가 이를 읽도록 만드는 규칙 파일의 조합입니다. Zencoder는 .agents/skills/에서 스킬을 버전 관리하고, 설명에 따라 자동으로 선택하며, 현재 수동 선택은 지원하지 않습니다. 또한 문서화된 컨테이너 소스는 상시 지침 파일에서 로드되는 대신 메시지별로 조립됩니다. 따라서 Memory Bank의 문서는 완벽하게 마이그레이션되지만, 이를 읽도록 보장하는 메커니즘은 마이그레이션되지 않습니다.

이동하기 전에 뱅크를 형태별로 분할하세요. 절차는 트리거 조건으로 작성된 설명을 가진 스킬이 되어 잘 작동할 것입니다. 상시 사실과 실행 상태는 매칭되기를 기다리는 대신 질문에 답할 수 있는 저장소가 필요합니다. 이 분할을 한 번만 수행하면, 모든 작업에 대해 새 대화를 시작하라는 Zencoder의 조언은 원래 의도대로 컨텍스트를 깨끗하게 유지하는 방법이 되며, 처음부터 다시 시작하는 고통이 되지 않을 것입니다.