실제로 이전되는 것
Project 지침은 여유 있게 이전됩니다. Perplexity에서는 Project 내에서 Computer가 작동하는 방식을 지시하는 지침을 "최대 8,000자"까지 추가할 수 있습니다. Zed의 AGENTS.md에는 문서화된 글자 수 제한이 없으므로 이 콘텐츠는 여유롭게 마이그레이션할 수 있습니다. 이 부분이 이번 마이그레이션에서 가장 깔끔하게 처리되는 영역입니다.
파일은 수동으로 이전됩니다. 각 Project에는 개별적으로 또는 폴더로 업로드되거나 연결된 파일 소스에서 가져온 파일들이 있으며, Computer는 "사용자를 대신하여 파일을 생성, 업데이트 및 관리"할 수도 있습니다. 이 파일들을 다운로드하여 리포지토리에 넣으세요. Zed의 에이전트는 파일 시스템을 읽으므로 디스크에 있는 모든 항목에 접근할 수 있습니다.
개인 대 프로젝트 범위 설정에도 상응하는 개념이 있습니다. Perplexity는 프로젝트 지침과 개인 메모리를 분리합니다. Zed는 ~/.config/zed/AGENTS.md(Windows의 경우 %APPDATA%\Zed\AGENTS.md)에 있는 개인 지침과 프로젝트 지침 파일을 분리하며, "충돌 시 프로젝트 지침이 개인 AGENTS.md보다 우선합니다." 메커니즘은 다르지만 동일한 구분 방식입니다.
이전되지 않는 것 — 그리고 이것이 성숙한 Project가 보유한 대부분의 내용입니다:
Brain이 생성한 메모리. 이 부분이 가장 중요하며, 정확히 짚고 넘어갈 필요가 있습니다. Perplexity에는 메모리 기능이 있습니다. Brain은 "프로젝트에서 수행된 모든 작업에 대한 지속적인 메모리를 구축하는 데 도움을 주며", "프로젝트 활동을 기반으로 실시간으로 업데이트되는 지식을 구축하여 Computer에 더 나은 컨텍스트를 제공"하고, 사용자는 "Brain 탭에서 생성된 현재 메모리를 볼 수 있습니다." Brain 실행 비용은 프로젝트 생성자에게 청구되며, Settings 탭에서 자동 또는 수동 실행 여부를 제어할 수 있습니다.
Zed에는 활동으로부터 메모리를 생성하는 기능이 없습니다. 상시 활성화된 지침과 필요할 때 호출하는 Skills만 있을 뿐입니다. 따라서 Brain에 누적된 출력물은 자동으로 이동하지 않지만, Brain 탭에서 볼 수 있으므로 읽고 복사할 수 있으며, 이것이 실제 마이그레이션 단계가 됩니다.
프로젝트 요약. Perplexity의 프로젝트 요약은 "프로젝트에서 수행된 작업의 진행 상태 업데이트를 생성"하며, 컨텍스트를 위해 Brain을 활용할 수 있습니다. Zed에는 이에 상응하는 기능이 없으며, 어차피 진행 상태 업데이트는 상시 활성화된 지침 파일에 넣기에는 적절하지 않은 콘텐츠입니다.
협업 기능 전체. 역할(소유자, 편집 가능, 보기 가능), 액세스 범위(기본적으로 제한됨, 조직 보기 가능, Enterprise의 경우 조직 편집 가능, 또는 링크가 있는 모든 사람), 비 Enterprise Project의 경우 최대 5명, Enterprise 소유 Project의 경우 최대 9,999명의 기여자 제한, 그리고 프로젝트에 연결되어 컨텍스트에 포함되는 Slack 또는 Teams 채널 등이 이에 해당합니다. Zed의 지침 파일은 git에 커밋하여 공유됩니다. 이는 단순한 형식의 변화가 아니라 실제 기능적 패러다임의 변화입니다.
커넥터, 자격 증명 및 연결된 도구. 프로젝트 수준의 커넥터 선택, 커넥터별 지침, 공유 프로젝트 수준 자격 증명은 Perplexity의 인프라 기능입니다.
Search 대화 및 Computer 작업. 세션은 Perplexity에 그대로 남습니다.
수동 마이그레이션
1단계: 지침 추출 및 Brain 탭 확인
두 가지를 내보내야 하는데, 사람들이 주로 두 번째 단계를 건너뜁니다.
프로젝트 지침 복사. Settings 탭의 Context 섹션을 엽니다. 이곳에 "프로젝트에서 실행되는 모든 쿼리에 사용되는 지침"과 우선순위가 지정된 웹 링크 및 도메인, 기본 모드가 있습니다. 지침을 복사해 두세요. 또한 우선순위 도메인도 기록해 두세요. 설정으로 직접 이전되지는 않지만, "X의 소스를 선호함"과 같은 텍스트 형태로 지침에 남겨두는 것은 유용합니다.
Brain 탭을 열고 구축된 내용을 읽어보세요. 이 단계는 마이그레이션을 통해 가치 있는 정보를 보존할 수 있을지를 결정하는 핵심 단계입니다. Brain은 프로젝트 활동을 통해 프로젝트의 작동 모델을 축적해 왔습니다. 이 콘텐츠는 시각적으로 확인할 수 있으며, 몇 달간의 작업 결과물을 내보낼 수 있는 가장 유사한 방법입니다.
통째로 복사하기보다는 비판적으로 읽어보세요. 의사 결정에 영향을 미친 제약 조건, 신뢰할 수 있는 것으로 판명된 소스, 조사 후 폐기된 접근 방식 등 지속적으로 유용한 정보를 찾아야 합니다. 상태 스냅샷에 불과한 내용은 건너뛰세요. 그것은 프로젝트 요약의 역할이었으며 시간이 지나면 만료되는 정보입니다.
파일 다운로드. Files 섹션에서 여전히 필요한 모든 파일을 다운로드합니다.
2단계: Zed의 지침 레이어 설정 및 섀도잉 파일 확인
이제 특정 함정이 도사리고 있는 부분입니다.
Zed의 프로젝트 지침 로더는 다음 목록에서 가장 먼저 일치하는 파일 하나만 사용합니다: .rules, .cursorrules, .windsurfrules, .clinerules, .github/copilot-instructions.md, AGENT.md, AGENTS.md, CLAUDE.md, GEMINI.md.
모든 파일이 아니라 첫 번째로 일치하는 파일만 적용됩니다. 리포지토리에 이전 도구에서 남겨진 .cursorrules가 있다면 그것이 우선 적용되어 새로 만든 AGENTS.md는 전혀 읽히지 않습니다. 무언가를 작성하기 전에 남아 있는 파일들을 삭제하거나 통합하세요.
그런 다음 추출한 내용을 다음과 같이 나누어 정리합니다:
항상 적용되는 지침 → AGENTS.md. Computer 관련 내용을 제외한 Perplexity 프로젝트 지침입니다. 리포지토리 컨벤션, 선호하는 톤앤매너, 프로젝트 제약 조건 등이 이에 해당하며, Zed 문서에서도 이를 지침 자료의 예시로 명시하고 있습니다.
공통 환경설정 → ~/.config/zed/AGENTS.md. 여는 모든 프로젝트에 공통으로 적용되는 내용입니다.
반복 가능한 절차 → Skills. Zed의 구분은 명확합니다. 지침은 상시 활성화되는 안내용이고, Skills는 이름으로 호출하는 "재사용 가능한 작업 워크플로우"를 위한 것입니다. Perplexity 지침에 빌드해 둔 연구 또는 검토 절차는 상시 활성화 파일이 아닌 여기에 속해야 합니다.
One more documented caveat if you use Zed with other agents: "External Agents and Terminal Threads may read their own native instruction files directly. Do not assume Zed's instruction loader controls those agents." AGENTS.md를 설정하면 Zed Agent가 구성되는 것이지, Zed 내부에서 실행하는 모든 에이전트가 구성되는 것은 아닙니다.
Zed의 이전 Rules 시스템에서 전환하는 경우의 매핑도 문서화되어 있습니다. 온디맨드 Rules는 Skills가 되었고, 상시 활성화 Rules는 개인 AGENTS.md가 되었으며, 프로젝트 .rules 파일은 호환성 지침 파일로 계속 지원됩니다. 관련 내용은 why Zed forgets project context에서 다루고 있습니다.
더 나은 방법: 에디터가 담을 수 없는 곳에 연구 지식 보관하기
방금 수행한 작업을 돌아보면 한계가 명확히 보입니다. 지침은 파일로 이동했고, 파일은 디스크로 이동했습니다. 하지만 구축하는 데 몇 달이 걸렸던 정보, 즉 Brain이 프로젝트, 소스, 시행착오에 대해 수집한 모든 정보는 모든 요청과 함께 전송되는 마크다운 파일에 수동으로 다시 입력되거나 유실되었습니다.
이것은 Zed의 단점이 아닙니다. 에디터의 지침 파일은 에이전트를 제어하기 위한 것이며, 이것이 바로 Zed가 상시 활성화되는 Instructions와 온디맨드 Skills를 애초에 분리한 이유입니다. 연구 지식은 제3의 카테고리이며, 두 컨테이너 모두에 적합하지 않습니다.
이것이 바로 MemoryLake가 해결하는 문제입니다. 전체 문서를 통째로 로드하는 대신, 도구들이 읽을 수 있는 검색 가능한 항목으로 지속적인 프로젝트 지식을 보관합니다. 설정은 3단계로 진행됩니다.
1단계: API 키 생성
MemoryLake에 로그인하고 API 키를 생성합니다. 연결하는 여러 도구에서 이 하나의 자격 증명을 공유하여 사용합니다.
2단계: 첫 번째 메모리 업로드
방금 읽은 Brain 탭의 내용을 바탕으로, 하나의 사실(claim)당 하나의 짧은 항목으로 작성합니다.
출처가 포함된 분석 결과. "2025년 제출 파일이 보존 기간에 대한 2024년 지침을 대체함"과 같은 내용과 그 출처를 함께 기록합니다. 연구 프로젝트의 가치는 결론에 있으며, 출처가 없는 결론은 나중에 검증할 수 없습니다.
신뢰할 수 있는 것으로 판명된 소스와 그렇지 않은 소스. Perplexity의 우선순위 도메인 설정이 이 역할을 일부 수행했습니다. 단순히 도메인 목록만 적지 말고 이에 대한 판단을 함께 기록해 두세요.
종결된 조사 방향. 다시 찾아내기에 가장 비용이 많이 들고, 어떤 결과물에도 기록되지 않는 정보입니다.
의사 결정에 영향을 미친 제약 조건. 규제적 제한, 데이터 가용성 격차, 철저한 대안을 배제하게 만든 마감 기한 등이 있습니다.
상태 업데이트에 불과한 내용은 건너뛰세요. 2주만 지나도 쓸모없어질 정보라면 그것은 프로젝트 요약에 속하는 것이지, 여기에 둘 내용이 아닙니다.
3단계: AI 및 에이전트 연결
사용하는 도구들을 연결합니다. MemoryLake는 MCP 및 API를 통해 접근할 수 있으므로, Claude Code, Codex, OpenClaw 같은 MCP 네이티브 에이전트들은 MCP 서버를 지정하여 연결하고, 다른 어시스턴트들은 API를 통해 동일한 메모리를 읽습니다. 따라서 지식이 Zed나 다른 도구 내부에 종속되지 않으면서도, Zed와 사용 중인 다른 모든 도구에서 지식을 활용할 수 있습니다.
솔직한 세 가지 한계가 있으며, 첫 번째가 여기서 중요합니다. MemoryLake는 Perplexity나 Brain을 직접 읽지 않습니다. 즉, Project를 자동으로 내보낼 수 없으며 위의 2단계는 사용자가 직접 Brain 탭을 읽고 수행해야 하는 수동 작업입니다. 또한 Zed 에이전트를 제어하는 방식인 AGENTS.md나 Skills를 대체하지도 않습니다. 그리고 협업 플랫폼이 아니므로, Perplexity에서 사용하던 역할, 범위, 채널 바인딩과 같은 고유 기능들은 포기해야 합니다.
실제 적용 시 변화하는 점
Brain의 결과물이 마이그레이션 후에도 보존됩니다. 자동이나 완벽하게는 아니지만, 한 번 읽고 항목으로 기록해 두면 지속 가치가 있는 절반의 정보는 플랫폼 수명보다 더 오래 살아남습니다.
AGENTS.md를 가독성 있게 짧게 유지할 수 있습니다. 지침은 방향성을 제시해야 합니다. 연구 말뭉치(corpus)를 담는 곳이 아니며, 이를 분리해야 상시 활성화되는 콘텐츠의 분량을 적절하게 유지할 수 있습니다.
남겨진 rules 파일이 모르는 사이에 우선 적용되는 일을 방지합니다. Zed가 첫 번째로 일치하는 파일을 선택한다는 사실을 알고 나면, .cursorrules는 나중에 디버깅하느라 애먹는 대상이 아니라 설정 과정에서 미리 삭제하는 대상이 됩니다.
협업 기능 상실을 예상치 못한 문제가 아닌 의도된 선택으로 받아들일 수 있습니다. Enterprise Project에서는 최대 9,999명의 기여자를 둘 수 있었고 Slack 채널 바인딩도 가능했습니다. Git과 공유 메모리 레이어의 조합은 다른 모델이며, 이를 인지하고 선택하는 것이 중요합니다.
다음 도구로의 전환 비용이 저렴해집니다. 에디터 외부에 보관된 연구 지식은 어떤 에디터에서도 읽을 수 있습니다. 이에 대한 전반적인 개념은 why RAG isn't memory에서 다루고 있습니다.
마이그레이션 모범 사례
서비스를 취소하기 전에 반드시 Brain 탭을 읽어보세요. 플랫폼이 학습한 내용을 볼 수 있는 유일한 창구이며, 액세스가 종료되면 다시는 볼 수 없습니다.
상태가 아닌 사실(claims)을 추출하세요. 출처가 있는 분석 결과는 지속되지만, 진행 중인 상태 업데이트는 그렇지 않습니다.
리포지토리에서 .cursorrules, .windsurfrules, .clinerules를 삭제하세요. 첫 번째 일치 파일 로딩 방식 때문에 오래된 파일이 새 AGENTS.md보다 우선 적용될 수 있습니다.
상시 활성화 항목과 온디맨드 항목을 분리하세요. Zed의 자체 구분 기준에 따르면, Instructions는 지속적인 안내용이고 Skills는 재사용 가능한 작업 워크플로우용입니다. 상시 활성화 파일에 절차를 넣는 것이 파일을 불필요하게 비대하게 만드는 가장 흔한 원인입니다.
우선순위 도메인은 텍스트 형태로 유지하세요. 설정 자체는 이전되지 않지만, 그 설정 뒤에 숨은 판단 기준은 텍스트로 남겨두어야 합니다.
외부 에이전트는 자체 파일을 읽는다는 점을 기억하세요. AGENTS.md를 구성하는 것은 Zed Agent를 제어하는 것이지, Zed 내부에서 실행하는 모든 에이전트를 제어하는 것이 아닙니다.
떠나기 전에 Brain의 실행 모드를 결정하세요. 전환 기간 동안 Project를 계속 활성화해 두는 경우, 자동 Brain 실행 비용은 프로젝트 생성자에게 청구되므로 나중에 청구서를 보고 놀라기 전에 미리 확인하는 것이 좋습니다.
항목에 날짜를 기록하세요. 연구 분석 결과는 코드 컨벤션보다 더 빠르게 노후화됩니다. 이에 대한 일반적인 문제는 what AI memory is and isn't에서 다루고 있습니다.
결론
Spaces는 이제 Projects가 되었으며, Project는 단순한 지침 파일 그 이상입니다. Search 대화, Computer 작업, 파일, 커넥터, Enterprise의 경우 최대 9,999명의 협업 참여자, Slack 및 Teams 연동, 진행 중인 프로젝트 요약, 그리고 프로젝트 활동을 통해 실시간 메모리를 구축하는 Brain 등이 포함됩니다. 반면 Zed의 에이전트는 완전히 다른 성격을 가집니다. 로컬 파일 시스템을 읽으며, 상시 활성화되는 AGENTS.md 지침과 온디맨드 Skills로 구성됩니다.
따라서 마이그레이션 과정은 다음과 같습니다. 지침은 AGENTS.md로 깔끔하게 이동하고, 파일은 디스크로 이동하며, 절차는 Skills가 되고, 협업 기능은 함께 가져갈 수 없습니다. 이번 이동이 가치 있는 결과를 낳을지 결정하는 핵심 단계는 Brain 탭을 열고 몇 달간의 작업으로 축적된 내용을 읽은 다음, 지속 가치가 있는 사실들을 두 플랫폼 모두에 종속되지 않는 곳에 항목으로 기록해 두는 것입니다. 그렇게 하면 Zed가 충분한 정보를 바탕으로 시작할 수 있습니다. 이 단계를 건너뛰면 단순히 설정 파일 하나만 마이그레이션한 셈이 됩니다.