Zed의 agent가 컨텍스트를 잊어버리는 이유
모든 스레드는 자체 컨텍스트로 시작됩니다
Agent Panel은 CLI 및 TUI 작업을 위한 Terminal Threads와 함께 여러 개의 동시 agent 스레드를 지원하며, 각 스레드는 독립적인 컨텍스트와 기록을 가집니다. 이러한 독립성 덕분에 병렬 agent를 유용하게 사용할 수 있지만, 한 스레드에서 설정한 내용이 다음 스레드에서는 전혀 보이지 않는다는 의미이기도 합니다. 이전 스레드를 명시적으로 @ 언급하거나, "New From Summary"를 통해 현재 대화의 요약본으로 새 스레드를 시작할 수 있지만, 이 두 가지 모두 사용자가 직접 기억하고 수행해야 하는 수동 작업입니다.
압축(Compaction)은 지식이 아닌 공간을 관리합니다
Zed는 긴 agent 스레드가 설정된 토큰 임계값에 도달하면 자동으로 이전 메시지를 요약하고 검사할 수 있는 "Context Compacted" 항목을 남겨 스레드를 압축합니다. /compact를 통해 수동으로 실행할 수 있으며, agent.auto_compact로 이 동작을 제어합니다. 이는 긴 세션을 위한 훌륭한 엔지니어링이며 메모리 기능으로 오해하기 쉽습니다. 하지만 압축은 이미 스레드에 있는 내용을 축소할 뿐입니다. 스레드 외부로 아무것도 내보내지 않으며, 요약본은 스레드가 종료되면 함께 사라집니다.
.rules는 축적이 아닌 지침입니다
Zed는 작업 트리 루트에서 프로젝트 규칙 파일을 읽어 모든 Agent Panel 상호작용에 자동으로 포함합니다. 이때 파일 이름의 우선순위 목록(.rules, .cursorrules, .windsurfrules, .clinerules, .github/copilot-instructions.md, AGENT.md, AGENTS.md, CLAUDE.md, GEMINI.md)을 확인하고 첫 번째로 일치하는 파일을 사용합니다. 이는 정말 유용하며, 새로운 스레드에서도 개발 규칙이 유지되는 이유입니다.
하지만 규칙 파일은 사용자가 직접 작성하는 것이지 agent가 채워 넣는 것이 아닙니다. 오후 4시에 agent가 발견한 사실이 오후 5시에 규칙 파일에 자동으로 나타나지 않습니다. 그대로 방치하면 낡은 정보가 되고, 부지런히 관리하더라도 매 상호작용마다 토큰 비용을 소모하고 정말 중요한 10가지 핵심 사실을 묻어버리는 텍스트 장벽이 됩니다.
Zed의 메모리는 직접 구성하는 것입니다
Zed는 context_servers 아래에서 MCP 서버를 지원합니다. 이는 확장 프로그램으로 설치하거나 명령 인수, URL 및 선택적 인증 헤더를 사용하여 로컬 또는 원격 서버로 직접 구성할 수 있으며, agent.tool_permissions.default에 의해 관리되는 권한으로 agent에 MCP Tools 및 Prompts를 노출합니다. 이것이 공식적으로 권장되는 영구 저장 경로입니다. 메모리 서버를 연결하면 agent는 스레드보다 오래 지속되는 지식을 읽고 쓸 수 있습니다. 기본적으로 미리 연결되어 제공되는 것은 없습니다.
Zed 사용자들이 가장 먼저 시도하는 방법들
이전 스레드를 @로 언급하기
어떤 스레드에 정답이 있었는지 기억할 때는 정확하고 유용합니다. 하지만 스레드가 30개로 늘어나고 재시도(retry)에 대한 결정이 어느 스레드에 있었는지 기억나지 않는 순간부터는 더 이상 감당할 수 없게 됩니다.
요약본으로 새로 시작하기 (New From Summary)
아무것도 없이 시작하는 것보다는 낫지만, 본질적으로 정보 손실이 발생하는 전달 방식입니다. 요약은 대화의 대략적인 형태만 유지할 뿐, 실제로 중요한 세부 사항(예: 특정 임시 방편이 존재하는 정확한 이유, 동작이 변경된 버전 등)은 누락시킵니다.
더 큰 .rules 파일 사용하기
가장 흔한 해결책이지만 한계가 명확합니다. 모든 상호작용마다 전체 파일 길이에 대한 비용을 지불해야 하고, 업데이트는 인간의 꼼꼼함에 의존해야 하며, 시간 제약이 있는 정보를 표현할 수 없습니다. 이는 지식 베이스인 척하는 브리핑 문서에 불과하며, Claude Code가 프로젝트 컨텍스트를 잊어버리는 이유에서 설명한 것과 동일한 한계에 부딪힙니다.
리포지토리 내의 스크래치패드 마크다운 파일
팀에서 notes.md 파일을 유지하고 이를 @로 언급하는 방식입니다. 한동안은 놀라울 정도로 잘 작동하지만, 결국 아무도 정리하지 않는 추가 전용(append-only) 로그가 되어 서로 모순되는 항목들이 쌓이고 어떤 것이 최신 정보인지 알 수 없게 됩니다.
해결책: Zed에 영구 메모리 서버 연결하기
Zed는 MCP를 통해 메모리가 제공되기를 기대하므로, 가장 깔끔한 해결책은 메모리 역할을 흉내 내는 파일 대신 이 작업을 위해 구축된 메모리 레이어를 제공하는 것입니다. MemoryLake는 아키텍처, 결정 사항, 컨벤션을 한 번만 저장하면 모든 스레드와 사용 중인 다른 모든 agent가 동일한 소스에서 이를 읽어옵니다.
1단계: API 키 생성하기
키를 생성하고 약 30초 만에 첫 번째 요청을 보낼 수 있습니다.
2단계: 첫 번째 메모리 업로드하기
프로젝트의 실제 컨텍스트가 담긴 문서, 이미지, 파일을 업로드하세요. 아키텍처 노트, ADR(아키텍처 결정 기록), 런북, API 사양서, 장애 보고서, 그리고 스레드들이 계속해서 다시 도출해 내는 결정 사항들이 여기에 해당합니다.
3단계: AI 및 agent 연결하기
Claude, Codex, OpenClaw 및 기타 agent에 MCP 또는 API를 통해 해당 메모리에 대한 액세스 권한을 부여하세요. Zed의 경우, 팀이 선호하는 방식으로 도구 권한을 설정하여 다른 MCP 항목과 함께 context server로 등록하면 됩니다. 그러면 새로운 agent 스레드가 열릴 때 빈 상태가 아니라 이미 프로젝트를 파악한 상태로 시작됩니다. 터미널에서도 작업하는 경우, Claude Code에 메모리 추가하기 및 MCP로 크로스 AI 메모리 설정하기를 통해 다른 클라이언트에서도 동일한 레이어를 활용할 수 있습니다.
실제 적용 시 달라지는 점
병렬 agent를 사용하면 컨텍스트를 잊어버리는 비용이 배로 증가합니다. 컨텍스트를 다시 설정하는 데 스레드당 약 1,500토큰과 2분이 소요된다고 가정해 봅시다. 하루에 6개의 스레드를 실행하면 매일 9,000토큰과 12분을 서론을 설명하는 데 소비하게 됩니다. 코드를 작성하기도 전에 한 달에 약 270,000토큰을 쓰는 셈입니다. 큰 .rules 파일은 이 비용을 없애주는 것이 아니라 무조건 지불하게 만듭니다. 단 두 줄만 필요한 스레드를 포함하여 모든 스레드에서 전체 파일에 대한 비용을 지불해야 하기 때문입니다.
행동의 차이는 더 큽니다. 스레드가 메모리를 공유하면, 두 번째 스레드는 첫 번째 스레드가 발견한 마이그레이션 순서 제약 조건을 이미 알고 있으므로 이를 불필요하게 "수정"하려 하지 않습니다. 이는 단일 에디터 내에서 발생하는 멀티 에이전트 메모리(multi-agent memory)와 동일한 범주의 문제이며, 동시 agent를 실행하는 팀들이 다른 누구보다 이 문제를 먼저 체감하는 이유이기도 합니다.
Zed agent 메모리 활용을 위한 모범 사례
지침과 지식 분리하기
.rules 파일은 스타일, 코드 리뷰 기대치, 금지된 경로 등 agent가 어떻게 행동해야 하는지에 대한 지침으로 유지하고, 시스템에 대한 사실 정보는 메모리에 보관하세요. 규칙은 매번 로드해도 부담 없을 정도로 짧게 유지되고, 지식은 모든 상호작용에 부담을 주지 않으면서 계속 확장될 수 있습니다.
스레드 시작할 때가 아니라 끝날 때 메모리 작성하기
긴 스레드의 가치 있는 결과물은 대개 '무엇이 결정되었고 그 이유는 무엇인가'라는 한두 문장입니다. 스레드를 닫을 때 이를 저장하는 습관을 들이세요. 그렇지 않으면 다음 스레드에서 이를 다시 알아내기 위해 비용을 지불해야 합니다. 압축(Compaction) 기능은 이를 대신해 주지 않습니다. 스레드 내부에서만 요약하고 스레드와 함께 사라지기 때문입니다.
항목 정리 및 날짜 기록하기
결정이 내려진 시기를 기록하고, 새로운 사실을 옆에 쌓아두기보다는 대체된 오래된 사실을 교체하세요. agent는 읽은 내용을 신뢰하므로, 오래된 정보는 누락된 정보보다 더 큰 해를 끼칩니다. 이는 스크래치패드가 모순된 로그로 변하지 않도록 관리하는 것과 동일한 원칙입니다.
결론
Zed의 agent가 프로젝트 컨텍스트를 잊어버리는 이유는 스레드가 설계상 격리되어 있고, 압축이 스레드 외부가 아닌 내부에서만 작동하며, .rules가 정적인 지침 파일이고, 메모리가 기본 제공되는 기능이 아니라 MCP를 통해 명시적으로 연결해야 하는 대상이기 때문입니다. 이 중 어느 것도 병렬 agent를 지원하는 빠른 에디터의 결함이 아닙니다. 이는 역할 분담일 뿐입니다.
이러한 역할 분담은 사용자가 자신의 역할을 다할 때만 효과를 발휘합니다. 아키텍처, 결정 사항, 컨벤션을 메모리 레이어에 넣고 이를 context server로 연결하세요. 그러면 Zed를 선택한 이유인 그 빠른 속도를 이전 스레드가 이미 알고 있던 내용을 다시 설명하는 데 낭비하지 않게 될 것입니다.