Zed의 External Agents가 상속받지 못하는 컨텍스트를 제공하는 방법 (2026)

Zed는 스레드를 호스팅하고, 에이전트는 그 외의 모든 것을 소유합니다

가장 핵심적인 문장은 문서의 첫 단락에 있습니다. "Zed는 Agent Panel 및 Threads Sidebar에서 스레드를 호스팅하는 반면, External Agent는 일반적으로 자체 런타임, 인증, 모델 선택, 도구 및 네이티브 설정을 소유합니다."

이것은 깔끔한 아키텍처적 분리이며, 우리가 겪는 거의 모든 의외의 상황을 설명해 줍니다. 패널은 Zed의 것입니다. 대화 목록도 Zed의 것입니다. 하지만 에이전트는 ACP를 통해 통신하는 별도의 프로세스이며, 자신만의 모든 것을 가져옵니다.

경계 테이블은 대부분의 질문에 "상황에 따라 다름"으로 답합니다

Zed는 설정 경계(Configuration Boundaries) 테이블을 제공합니다. 모호한 표현들을 포함하여 있는 그대로 읽어보세요.

두 개의 행은 단호하게 부정적입니다. Zed Agent 프로필은 적용되지 않으며, Zed Skills는 Zed Skills로 적용되지 않습니다. 그 외의 모든 것은 "보통", "~일 수 있음", 또는 "에이전트에 따라 다름"입니다.

이는 단순히 모호하게 만들기 위한 것이 아닙니다. Zed는 서드파티 프로세스가 설정 파일로 무엇을 하는지 보장할 수 없기 때문에 보장하지 않는 것뿐입니다. 하지만 이는 "내 지침이 읽힐까?"라는 질문에 대한 답을 Zed 측에서는 정말로 알 수 없으며, 에이전트별로 직접 확인해야 함을 의미합니다.

당연히 읽힐 것이라 믿었던 파일 하나조차 모호합니다

Claude Agent 섹션에는 다음과 같이 나와 있습니다. "CLAUDE.md와 같은 Claude 전용 파일은 Claude Agent가 직접 읽을 수 있습니다."

읽을 수 있습니다(May be). "읽습니다(are)"가 아닙니다. 이유는 동일한 아키텍처적 한계 때문입니다. 에이전트는 자체 런타임을 통해 자체 설정을 읽으므로, 파일이 감지되는지 여부는 해당 에이전트가 어떻게 실행되었는지와 무엇을 작업 디렉터리로 인식하는지에 따라 달라집니다. 이는 일반적으로 왜 에이전트들이 지침 파일을 무시하는가에 대한 문제와 동일한 범주에 속합니다.

자격 증명과 원격 프로젝트는 또 다른 레이어를 추가합니다

"로컬 키체인에 저장된 Zed LLM 프로바이더 API 키가 External Agent의 자격 증명과 자동으로 동일하게 적용되지는 않습니다." 그리고 원격 작업의 경우, "External Agent는 로컬, 원격 또는 자체 로그인 흐름을 통해 자격 증명을 읽을 수 있습니다."

따라서 Zed Agent를 위해 설정된 Anthropic API 키는 "Claude Agent를 자동으로 설정하지 않으며", Cursor 구독은 "Zed의 LLM 프로바이더 설정을 구성하지 않습니다." 각 에이전트는 스스로 인증을 처리합니다.

Zed Skills가 그대로 전달될 것이라 가정하기. 그렇지 않습니다. 표에 명확히 나와 있습니다. Zed Agent용으로 작성된 스킬은 외부 에이전트 스레드에서 Zed Skills로 사용할 수 없으며, 에이전트에 자체적인 대체 기능이 있는지 여부는 "에이전트에 따라 다릅니다."

Zed Agent 프로필을 설정하고 이것이 외부 에이전트를 제어하기를 기대하기. 프로필은 "통합 기능에서 달리 명시하지 않는 한 적용되지 않습니다." 특히 도구 권한은 Zed 설정이 아니라 에이전트 자체에 의존하므로 여기서 확인해 볼 가치가 있습니다.

Zed에서 MCP를 한 번 설정하고 끝났다고 생각하기. Zed MCP 서버는 "ACP를 통해 전달될 수 있으며" 네이티브 MCP 설정도 "에이전트가 읽을 수 있습니다." 두 가지 모두 불확실하므로, 가정하기보다는 직접 테스트하는 것이 실질적인 해결책입니다. 이는 MCP 레이어가 설계상 상태가 없는(stateless) 구조이기 때문에 발생하는 문제의 변형입니다.

이전 스레드를 가져와 실시간으로 이어지기를 기대하기. Zed는 설정된 외부 에이전트로부터 기존 스레드를 가져올 수 있으며, 이는 실제 유용한 기능입니다. "Zed는 ACP를 통해 선택된 각 에이전트에 연결하고 히스토리에 없는 세션을 추가합니다." 하지만 무엇을 얻게 되는지 주의 깊게 보세요. "가져온 스레드는 아카이브된 항목입니다. 하나를 열어 복원하고 중단된 지점부터 계속 진행하세요." 그리고 무엇이 누락되는지도 확인하세요. "연관된 작업 디렉터리가 없는 세션은 건너뜁니다."

Zed External Agents에는 컨텍스트가 전혀 없다고 결론 내리기. 부정적인 행만 읽었다면 이해할 수 있는 결론이지만, 틀렸습니다. 각 외부 에이전트는 자체 지침 시스템, 자체 메모리(있는 경우), 자체 네이티브 설정을 가져옵니다. 핵심은 그것들이 에디터(Zed)의 것이 아니라 에이전트의 것이라는 점입니다. 컨텍스트는 존재합니다. 단지 에디터에서 제공되지 않을 뿐입니다.

하나의 에이전트로 단일화하여 해결하기. 이 방법은 작동하긴 하지만, 애초에 External Agents를 설치한 이유를 포기하는 셈입니다. 이 기능은 한 작업에는 Claude Agent 스레드를 시작하고 다른 작업에는 Codex 스레드를 시작할 수 있도록 존재합니다. 두 개의 지침 레이어를 유지 관리하기 귀찮아서 단일 에이전트로 축소하는 것은 유연성을 위해 비용을 지불하고도 사용하지 않는 것과 같습니다.

동일한 지침 파일을 모든 에이전트의 위치에 복사하기. 뻔한 임시방편이며, 약 한 달 동안은 버틸 수 있습니다. 그러다 한 복사본에만 수정 사항이 반영되고 다른 복사본에는 반영되지 않으면, 동일한 에디터 내의 두 에이전트가 사용자의 컨벤션에 대해 서로 자신 있게 다른 주장을 펼치게 됩니다. 각자 자신에게 주어진 파일을 충실히 읽고 있기 때문에 에러조차 발생하지 않습니다.

1단계: 추측하지 말고 경계를 직접 테스트하기

사용하는 각 외부 에이전트에 대해, 표의 모호한 표현들을 맹신하기보다 의도적인 테스트를 한 번씩 실행해 보세요.

에이전트가 읽을 것으로 생각되는 파일에 독특하고 무해한 지침을 넣어보세요. 특정 포맷 선호도나 선호할 만한 엉뚱한 변수 이름 등 눈에 띄는 것이면 무엇이든 좋습니다. Agent Panel에서 외부 에이전트 스레드를 시작하고, 해당 지침이 반영되었는지 확인할 수 있는 질문을 던져보세요.

에이전트 자체 지침 파일, 네이티브 MCP 설정, 에이전트가 네이티브로 지원하는 스킬 등 각 레이어에 대해 이 작업을 개별적으로 수행하세요. 결국 사용자의 환경에서 실제로 작동하는 항목들로 구성된 에이전트별 간단한 표를 얻게 될 것입니다. 이는 에이전트가 어떻게 설치되고 실행되었는지에 따라 달라지기 때문에 Zed 문서가 대신 작성해 줄 수 없는 부분입니다.

테스트하는 김에 작업 디렉터리도 확인해 보세요. Zed의 스레드 가져오기 기능은 "연관된 작업 디렉터리가 없는 세션"을 건너뛰는데, 이는 작업 디렉터리가 이 통합에서 매우 중요한 역할을 한다는 강력한 힌트입니다. 지침 파일 탐색도 보통 이 작업 디렉터리를 기준으로 이루어집니다.

2단계: 각 에이전트의 자체 레이어를 네이티브로 설정하기

에이전트가 무엇을 읽는지 파악했다면, Zed가 아닌 해당 에이전트 자체에서 설정을 구성하세요.

Claude Agent의 경우 자체 인증(Claude Agent 스레드에서 /login 실행) 및 Claude 네이티브 설정을 의미합니다. Codex의 경우 "설치된 버전 및 환경에 따라 ChatGPT 로그인, Codex API 키, OpenAI API 키 또는 Codex 네이티브 설정"을 의미합니다. Gemini CLI의 경우 자체 Google 또는 Vertex AI 로그인입니다. OpenCode의 경우 자체 인증, 모델 선택 및 구독 동작입니다. Poolside의 경우 pool login입니다. Zed는 이 각각을 에이전트 소유로 문서화하고 있으며, 아키텍처에 저항하는 가장 빠른 방법은 이를 에디터에 중앙 집중화하려고 시도하는 것입니다.

ACP 에이전트를 개발 중이거나 레지스트리에 없는 에이전트를 실행 중인 경우, Custom Agents 경로를 통해 설정 파일에 agent_servers 항목을 추가할 수 있으며, 동일한 경계 규칙이 적용됩니다.

3단계: 두 에이전트 모두에 필요한 지식을 두 에이전트 외부의 공간에 두기

1단계와 2단계를 거치면 각 에이전트가 정상 작동하게 됩니다. 하지만 동일한 프로젝트를 설명하는 N개의 병렬 지침 레이어(에이전트당 하나씩)를 유지 관리해야 하는 상태가 됩니다.

이것이 바로 멀티 에이전트 에디터를 사용하는 실제 비용이며, Zed의 버그가 아니라 "External Agent는 자체 네이티브 설정을 소유한다"는 규칙의 정직한 결과입니다. N개의 복사본을 다시 하나로 축소할 수 있는 유일한 방법은 어떤 에이전트도 소유하지 않는 저장소를 사용하는 것입니다.

메모리 레이어가 바로 그 역할을 합니다. 이는 Zed 설정도 아니고 에이전트 설정도 아니므로, 경계 테이블의 어떤 행이 적용되는지 신경 쓸 필요가 없습니다. MemoryLake는 단 세 단계로 설정할 수 있습니다.

1단계: API 키 생성

로그인하고 대시보드에서 API 키를 생성합니다. 이 자격 증명은 에이전트가 아닌 사용자의 것이므로, Zed 문서에 언급된 인증 파편화 문제를 우회할 수 있습니다. Zed 키체인 키, Claude Agent 인증, Codex 인증은 모두 별개이며, 이 키 역시 이들과 완전히 독립적입니다.

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

그동안 중복해서 작성해 왔던 프로젝트 지식(컨벤션, 아키텍처 결정 사항 및 그 이유, 도메인 용어, 새 스레드를 시작할 때마다 반복해서 언급하는 기본 선호도 등)을 입력합니다. 두 개의 서로 다른 에이전트 지침 파일에 작성했던 모든 내용이 대상이 됩니다.

각 에이전트의 순수한 에이전트 전용 설정은 원래 있어야 할 곳에 그대로 두세요. 이 공간은 연결 설정이 아닌 실제 사실(facts)을 위한 공간입니다.

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

각 에이전트가 이 저장소를 바라보도록 설정합니다. 작업 중간에 Claude Agent 스레드에서 Codex 스레드로 전환할 때 프로젝트를 처음부터 다시 설명할 필요가 없어집니다. 이는 Agent Panel이 쉽게 만들어 주지만 경계 설정 때문에 비용이 많이 들었던 부분입니다.

첫 번째 변화는 에이전트 전환 비용이 저렴해진다는 것입니다. Zed의 핵심 강점은 스레드별로 적합한 에이전트를 선택할 수 있다는 점입니다. 하지만 이는 스레드를 전환할 때 컨텍스트를 다시 설정할 필요가 없을 때만 유효합니다. 현재는 보통 다시 설정해야 하죠.

두 번째는 경계 테이블이 더 이상 놀라움의 원인이 되지 않는다는 점입니다. 지속적인 지식이 외부에 존재하면, 모호하게 표현된 행들은 훨씬 덜 중요해집니다. 여전히 인증과 도구 권한은 신경 써야 하겠지만, 특정 지침 파일이 감지되는지 여부는 더 이상 신경 쓰지 않아도 됩니다. 사실 정보가 그 파일 안에 들어있지 않기 때문입니다.

세 번째는 스레드 가져오기 기능이 진정으로 유용해진다는 점입니다. 가져온 스레드는 계속 진행하기 위해 열어보는 아카이브된 항목으로 들어옵니다. 프로젝트 지식이 공유 레이어에 있으면, 이전 스레드를 이어 나갈 때 원래 컨텍스트가 대화 기록에 얼마나 남아 있었는지에 의존하지 않아도 됩니다. 이는 공유 레이어가 일반적인 cross-agent memory에 도움이 되는 이유와 동일합니다.

• 경계 테이블을 사양이 아닌 체크리스트로 취급하세요. 두 개의 행은 확실한 부정이며, 나머지는 테스트를 통해 확인해야 하는 에이전트별 사실입니다.
• 인증은 에이전트별로 설정하고, 공유되지 않을 것을 예상하세요. Zed 키체인 키는 Claude Agent를 설정하지 않으며, Cursor 구독은 Zed의 프로바이더 설정을 구성하지 않습니다.
• Zed Skills를 이식하려고 하지 마세요. 외부 스레드에서는 Zed Skills로 적용되지 않습니다. 대신 에이전트에 네이티브 대체 기능이 있는지 확인하세요.
• MCP 전달을 가정하지 말고 검증하세요. Zed MCP 서버는 ACP를 통해 전달될 수 있고 네이티브 설정도 읽힐 수 있습니다. 두 가지 가능성 모두 테스트를 통해 확인해야 합니다.
• 작업 디렉터리에 주의하세요. 작업 디렉터리가 없는 세션은 가져오기 시 건너뛰며, 지침 탐색도 일반적으로 작업 디렉터리에 의존합니다.
• 가져온 스레드는 아카이브로 예상하세요. 복원하려면 스레드를 여세요. 이미 히스토리에 있는 스레드는 건너뛰므로 다시 가져와도 안전합니다.
• 프로젝트 지식의 단일 소스(Canonical Source)를 유지하세요. 만약 특정 단락이 CLAUDE.md와 Codex 지침 파일 모두에 존재한다면, 두 곳 모두에 있어서는 안 됩니다.
• 업데이트 후에는 다시 테스트하세요. Codex의 인증 옵션은 "설치된 버전 및 환경에 따라" 달라지며, 이는 이러한 경계가 변할 수 있다는 강력한 신호입니다.

Zed의 External Agents 문서는 과장된 약속을 하지 않기 때문에 이례적으로 신뢰할 수 있습니다. 별도의 프로세스가 자체 설정을 소유할 때 "보통", "~일 수 있음", "에이전트에 따라 다름"은 가장 정확한 답변이며, 그렇지 않은 척하는 것은 단지 나중에 겪을 혼란을 미루는 것뿐입니다.

실질적인 교훈은 다음과 같습니다. 각 에이전트가 자체 연결 설정을 소유하도록 두고, 이를 에디터에 중앙 집중화하려는 시도를 멈추세요. 그리고 진정으로 공유되어야 할 단 한 가지, 즉 팀이 프로젝트에 대해 알고 있는 지식을 에이전트 외부로 완전히 분리하세요.