Zed editor 리뷰: AI 활용법과 VS Code 전환 전 확인할 점

Zed editor는 빠른 네이티브 개발 환경을 원하고 코딩 에이전트도 자유롭게 고르고 싶을 때 전환을 고려할 만한 에디터입니다. AI를 사용하는 경로는 3가지입니다. Zed 자체 에이전트를 쓰거나, 외부 에이전트를 연결하거나, 에디터 안에서 명령줄 에이전트를 실행할 수 있습니다. 다만 매일 사용하는 확장 프로그램과 디버그 설정을 다시 구축할 여유가 없다면 Visual Studio Code나 Cursor를 유지하는 편이 낫습니다.

Zed editor는 어떤 코드 에디터인가요?

Zed는 Rust로 개발한 오픈 소스 코드 에디터로, 공동 편집과 AI 지원 기능을 앱 자체에 갖추고 있습니다. Visual Studio Code 계열 밖에서 대안을 찾으면서도 특정 코딩 에이전트에 묶이고 싶지 않은 개발자를 위한 선택지입니다. 기본 Zed Agent를 사용하거나, 연동 기능으로 Anthropic의 Claude Agent 또는 OpenAI의 Codex를 연결하거나, 터미널 스레드에서 Claude Code 같은 명령줄 툴을 실행할 수 있습니다. AI는 선택 사항입니다. 어떤 에디터를 쓸지, 어떤 모델이 프롬프트에 응답할지, 어떤 에이전트가 실행할 툴을 결정할지는 각각 별개의 선택입니다. Zed의 AI 빠른 시작 가이드에서 각 경로를 설명합니다.

2026년 10월 15일 기준 공식 문서와 요금 페이지를 확인했습니다. 이 글은 문서를 바탕으로 한 평가이며, 공개 페이지 캡처와 워크플로 분석을 포함합니다. 로그인한 상태에서의 사용 테스트나 비교 성능 벤치마크는 진행하지 않았습니다. 편집 과정의 불편함, AI 변경 사항 검토, 기존 개발 툴과의 호환성, 팀 관리 기능을 기준으로 판단했습니다.

Zed로 옮겨도 좋은 개발자와 기존 에디터를 유지할 개발자

Zed는 하루 대부분을 코드를 탐색하고 수정하는 데 쓰고, 에디터 확장 프로그램 없이도 프로젝트의 툴을 실행할 수 있으며, 에이전트 선택권을 열어 두고 싶은 개발자에게 잘 맞습니다. 같은 코드를 함께 살펴보는 페어 프로그래밍을 자주 한다면 검토할 가치가 있습니다.

선택지를 좁히려면 지금 무엇을 유지해야 하는지부터 따져야 합니다.

비교의 근거는 Zed 마이그레이션 가이드, Cursor 마이그레이션 문서, VS Code 확장 프로그램 문서, Devin Desktop의 현재 시작 가이드입니다. 속도 순위가 아니라 작업 방식에 따른 판단입니다.

Zed와 VS Code 비교: 반복 가능한 개발 환경을 유지할 수 있나요?

프로젝트가 특정 테스트 탐색기, 디버거 확장 프로그램, 컨테이너 연동 또는 팀 전용 확장 프로그램에 의존한다면 Visual Studio Code가 여전히 더 안전한 선택입니다. Zed도 자체 마이그레이션 가이드에서 확장 프로그램 목록이 더 작고, 일부 DevOps·컨테이너·테스트 실행 툴에는 일대일로 대응하는 대체재가 없다고 밝힙니다.

소스 파일, 언어 서버, 터미널 명령, Git 변경 사항 검토를 중심으로 일하는 개발자라면 이 차이를 감당할 수 있습니다. 언어 서버는 자동 완성, 진단, 코드 탐색 기능을 제공하는 백그라운드 프로세스입니다. 이런 핵심 기능이 프로젝트에서 정상 작동한다면 Zed를 시험 도입할 만한 근거가 생깁니다. 반면 전문 확장 프로그램을 통해 배포하거나 디버깅한다면 에디터 전환은 외형 취향의 문제가 아니라 개발 도구를 옮기는 작업입니다.

Zed와 Cursor 비교: 에이전트 선택의 자유와 익숙한 환경

주변 개발 환경을 익숙하게 유지하고 싶다면 VS Code에서 Cursor로 옮기는 편이 수월합니다. 가져오기 기능으로 확장 프로그램, 테마, 설정, 키 바인딩을 이전할 수 있습니다. Cursor 문서에는 파일 수정, 셸 명령 실행, 브라우저 사용을 위한 통합 에이전트 툴도 안내되어 있습니다. Cursor Agent

바꾸고 싶은 대상이 에디터 자체이고 에이전트는 따로 고르고 싶다면 Zed의 장점이 더 분명해집니다. 이미 Claude Code에 만족하는 개발자는 그 에이전트를 먼저 교체하지 않고도 Zed를 검토할 수 있습니다. 다만 어떤 연동 방식에서나 에이전트가 똑같이 작동한다는 뜻은 아닙니다. 아래에서 설명할 설정의 적용 범위를 구분해야 합니다.

전환 때문에 필수 툴을 쓰지 못하거나 계정·인증 요구 사항을 충족할 수 없다면 Zed를 팀의 의무 표준으로 삼지 않는 편이 좋습니다. Cursor의 익숙함은 장점이지만, 공식 문서에서도 기반 VS Code 버전이 조금 뒤처질 수 있다고 설명하므로 호환성은 확인해야 합니다. Windsurf의 현재 문서는 제품을 Devin Desktop으로 부르며, 호환되지 않는 확장 프로그램도 명시합니다. 모든 VS Code 포크가 기존 기능을 전부 유지한다고 가정해서는 안 됩니다.

후보를 더 넓히려면 Cursor 대안 목록을, 통합형 에디터 환경끼리 비교하는 것이 주목적이라면 Windsurf와 Cursor 비교를 참고할 수 있습니다.

코드 안에서 오래 작업할수록 빠른 편집이 빛납니다

Zed의 반응성은 대용량 파일로 시험해 볼 이유가 됩니다. 다만 이를 전체 빌드나 AI 작업 흐름이 빨라진다는 약속으로 확대해서는 안 됩니다. Zed의 Rust 소개 페이지는 큰 파일에서도 구문 강조가 빠르게 반응한다고 설명합니다. 이는 편집에 관한 공급업체의 주장입니다. 저장소가 Cursor나 VS Code보다 몇 배 빠르게 열린다는 근거는 아닙니다. Zed의 Rust 기능 소개

일상적으로 활용하기 좋은 작업은 여러 파일에 걸친 이름 변경이나 코드 정리입니다. 이전 설정 필드를 검색하고, 각 검색 결과를 문맥 속에서 확인한 뒤 필요한 부분을 수정합니다. Zed의 멀티버퍼는 여러 파일에서 발췌한 편집 가능한 영역을 한 화면에 모아 보여 줍니다. 덕분에 탭을 계속 열고 닫지 않아도 검색 결과를 차례로 수정할 수 있습니다. 발췌 영역을 수정하면 원본 소스 파일에도 반영됩니다. 멀티버퍼 문서

수정 범위가 작고 개발자가 에이전트보다 내용을 더 잘 이해하는 작업에서 유용합니다. 서비스 내부 옵션의 이름은 바꾸되, 이름이 비슷한 공개 응답 필드는 그대로 유지해야 한다고 가정해 보겠습니다. 일괄 치환은 잘못된 결과를 만들고, 에이전트에게 맡길 필요까지는 없을 수 있습니다. 일치하는 코드 조각을 한꺼번에 보면 넓게 살펴보면서도 직접 통제할 수 있습니다.

대용량 파일 테스트에는 생성된 스키마나 긴 소스 모듈처럼 실제로 살펴보는 파일을 사용합니다. 스크롤, 선택, 검색, 편집, 저장을 확인한 다음 프로젝트에서 평소 사용하는 언어 서비스를 켠 상태로 반복합니다. 빈 에디터가 부드럽게 작동하는 것보다 평상시 작업 환경에서의 경험이 더 유용한 판단 근거입니다.

병목은 백그라운드 작업에 있을 수 있습니다. Zed의 Rust 문서는 rust-analyzer의 기본 저장 시 검사 동작이 cargo check --workspace --all-targets를 실행해 워크스페이스 전체와 그 타깃을 검사할 수 있다고 경고합니다. 대규모 프로젝트에서는 이 방식의 확장성이 좋지 않다는 점도 명시합니다. 검사 범위를 줄이거나 별도 태스크로 실행할 수 있지만, 검사를 끄면 의존하던 진단 결과도 사라집니다. Rust 성능 관련 가이드

텍스트 편집 화면이 빨라도 느린 워크스페이스 검사가 사라지지는 않습니다. 무엇이 개선됐는지 판단할 때는 에디터 반응성, 언어 서버 작업, 에이전트 응답 시간을 구분해야 합니다. 그렇지 않으면 에디터를 옮기고도 비용이 큰 백그라운드 명령은 그대로 둔 채 엉뚱한 이유로 실망할 수 있습니다.

멀티플레이어로 에디터 안에서 함께 작업합니다

두 사람이 같은 프로젝트를 탐색하고 수정해야 할 때 Zed의 실시간 협업 기능이 유용합니다. 멀티플레이어 기능은 동시에 이루어지는 편집과 각자의 커서를 보여 줍니다. 채널은 프로젝트 공유와 음성 채팅을 지원하는 상시 협업 공간이며, 연락처를 통해 필요할 때 비공개 세션을 시작할 수도 있습니다. 협업 기능을 사용하려면 로그인해야 합니다. 협업 기능 문서

개발자와 리뷰어가 실패한 테스트의 원인을 찾는 상황을 생각해 보겠습니다. 개발자는 구현을 따라가고, 리뷰어는 검증문과 주변 픽스처를 살펴봅니다. 같은 소스를 가리키며 필요한 부분을 수정하고 그 영향을 공유 프로젝트 안에서 논의할 수 있습니다. 한 사람이 다른 사람에게 계속 스크롤을 요청해야 하는 회의보다 이런 작업에 잘 맞습니다.

장점은 작업 맥락을 공유한다는 데 있습니다. 회의 시간이 얼마나 줄어드는지를 측정한 결과는 아닙니다. 온보딩, 장애 조사, 민감한 변경 사항을 커밋하기 전 함께 검토하는 작업에서 특히 의미가 있습니다. 협업 대부분을 비동기 풀 리퀘스트 리뷰로 처리하는 팀에는 상대적으로 중요성이 낮습니다.

접근 권한의 범위도 명확히 알아야 합니다. 프로젝트를 공유하면 협업자는 해당 프로젝트 범위 내의 로컬 파일시스템에 접근할 수 있습니다. 이를 전제로 참여자를 초대해야 합니다. 멀티플레이어는 화면 공유보다 더 많은 일을 할 수 있으므로 권한도 그에 맞게 이해해야 합니다.

Zed AI 활용: 모델뿐 아니라 에이전트도 선택합니다

Zed의 Agent Panel은 여러 파일에 걸친 작업에 유용합니다. 다만 인증 정보를 설정하기 전에 어떤 에이전트 경로를 사용할지 먼저 정해야 합니다. 모델은 응답을 생성하고, 에이전트는 모델에 지침과 툴을 결합해 프로젝트를 살펴보거나 수정합니다. Zed에 Anthropic 키를 등록하는 것과 Claude Code를 실행하는 것은 서로 다른 설정입니다.

기본 Agent Panel에서 변경 사항을 검토합니다

Zed Agent는 Zed에 내장된 툴로 코드를 검색하고 읽고 수정하고 실행할 수 있습니다. @ 멘션으로 필요한 맥락을 명시적으로 추가하고, 설정된 모델과 공급자를 선택한 뒤, 결과를 멀티버퍼에서 검토할 수 있습니다. 검토 화면에서는 diff에서 연속된 변경 영역을 뜻하는 개별 헝크를 수락하거나 거부할 수 있고, 전체 변경 사항을 한꺼번에 처리할 수도 있습니다. Agent Panel 문서

예를 들어 잘못된 요청이 데이터베이스 쿼리까지 도달하기 전에 차단하는 티켓을 맡았다고 가정해 보겠습니다. 라우트 핸들러와 기존 테스트를 첨부합니다. 에이전트에게 먼저 유효성 검사 흐름을 설명하게 한 다음, 실패하는 최소한의 테스트를 추가하고 변경 사항을 구현하도록 요청합니다. 핸들러와 테스트를 함께 검토하고, 프로젝트의 일반적인 검사를 실행하며, 관련 없는 코드 정리는 거부합니다.

이 순서는 툴에 범위가 명확한 일을 맡기고 개발자가 구체적인 결과를 판단하게 해 줍니다. 핵심은 패치를 생성하는 데 그치지 않습니다. 패치를 저장소에 반영할지 결정하는 동안 입력한 맥락과 결과 diff를 계속 확인할 수 있다는 점이 중요합니다.

모델에 접근할 수 있다는 사실만으로 이 작업 방식이 가능해지는 것은 아닙니다. 선택한 모델이나 공급자가 에디터 동작을 요청하는 기능인 툴 호출을 지원하지 않으면 Zed 패널에 “No tools”라는 표시가 나타날 수 있습니다. 에이전트 작업에는 툴을 사용할 수 있는 모델을 골라야 합니다. 질문에 답하는 모델이라고 해서 편집 작업까지 실행할 수 있다고 가정해서는 안 됩니다.

외부 에이전트를 연결해 기존 선택을 유지합니다

Zed는 에디터와 에이전트 프로세스 사이의 통신 인터페이스인 **Agent Client Protocol(ACP)**로 외부 에이전트를 연결합니다. 에디터가 스레드를 표시하고 관리하는 동안, 외부 에이전트는 보통 자체 런타임, 인증, 모델 선택, 툴, 고유 설정을 담당합니다. 공식 문서에는 Claude Agent와 Codex 등의 연동이 안내되어 있습니다. 외부 에이전트 문서

실용적인 활용법은 지금 쓰는 에이전트를 유지하면서 결과를 읽고 검토하는 환경만 바꾸는 것입니다. Zed의 ACP Registry에서 에이전트를 설치하고 스레드를 시작한 뒤, 해당 에이전트의 인증 절차를 따르면 됩니다. 기본 Zed Agent용으로 저장한 API 키가 Claude Agent나 Codex의 인증까지 자동으로 처리하지는 않습니다.

이런 분리는 Zed에서 AI 작업을 할 가장 설득력 있는 이유입니다. 동시에 관리할 책임도 생깁니다. 모델, 권한, 지침이 예상과 다르게 작동할 때 그 설정을 Zed가 관리하는지 외부 에이전트가 관리하는지 알아야 합니다. 연동 문제를 진단할 때는 Zed의 dev: open acp logs 명령으로 양쪽 사이의 통신을 확인할 수 있습니다.

명령줄 사용 경험 자체를 선호한다면 Terminal Thread를 이용합니다. ACP 에이전트를 Zed의 에이전트 UI로 보여 주는 방식 대신, Zed가 구성한 스레드 안에서 CLI나 터미널 인터페이스를 실행합니다. Claude Code와 Codex 모두 이 경로를 사용할 수 있습니다. 각 에이전트의 인증 정보와 설정은 그대로 적용됩니다. Zed는 저장해 둔 공급자 키를 터미널에 복사하지 않습니다. 터미널 스레드

구분은 간단합니다. Zed가 동작을 관리하게 하려면 Zed Agent, 외부 에이전트를 에디터에 통합하려면 ACP, 에이전트의 터미널 인터페이스를 유지하는 것이 가장 중요하다면 Terminal Threads를 선택합니다. 작업 방식부터 정한 다음 모델 접근 권한을 설정합니다.

작은 수정에는 편집 예측이 잘 맞습니다

직접 타이핑을 주도하면서 짧고 국소적인 변경을 할 때는 Zed의 편집 예측 기능이 적합합니다. 작업 중 한 줄 또는 여러 줄의 변경을 제안합니다. 기본 예측 공급자는 Zeta이며 GitHub Copilot을 비롯한 다른 공급자도 지원합니다. 이 공급자는 Agent Panel에서 사용하는 모델과 별도로 설정합니다. 편집 예측 문서

직렬화 코드에 새 속성을 추가한 다음 인접한 매핑을 수정하는 상황을 생각해 보겠습니다. 편집 예측은 그 자리에서 내용을 확인하는 동안 다음으로 필요한 관련 수정을 제안할 수 있습니다. 저장소 전반을 탐색해야 하는 작업에는 에이전트를 쓰고, 다음에 무엇을 바꿀지 이미 알면서 입력을 돕는 기능이 필요할 때는 예측을 사용합니다.

기본 eager 모드에서는 Tab으로 예측을 수락할 수 있지만, 언어 서버의 자동 완성 메뉴가 열려 있으면 그 메뉴가 우선합니다. Escape를 누르면 예측을 닫습니다. 자동 제안이 코드를 읽는 데 방해된다면 subtle 모드로 전환할 수 있습니다. 이 모드에서는 설정된 보조 키를 누르고 있는 동안에만 예측이 코드 안에 표시되며, 기본 키는 Alt입니다.

AI 도움은 원하지만 커서 아래 제안이 계속 바뀌는 것은 불편한 개발자에게 유용한 도입 방식입니다. 필요할 때만 도움을 받는 방식으로 시작한 뒤, 예측이 더 자주 나타나는 편이 유익한지 판단하면 됩니다. 이 리뷰에서는 예측 품질이나 수락한 제안 수를 측정하지 않았습니다.

Zed 사용법: 실제 프로젝트로 시작하는 설정 순서

기존 에디터를 유지한 채 Zed를 함께 시험할 수 있습니다. 평소 작업하는 프로젝트에서 작은 변경부터 시작합니다. 다음 절차는 공개 문서로 재현할 수 있으며, 인증 단계는 각자 자신의 계정으로 진행해야 합니다.

1. 1

   안정 버전 에디터 설치

   공식 Zed 다운로드 페이지를 이용합니다. 설치 문서에는 macOS용 brew install --cask zed와 Windows용 winget install -e --id ZedIndustries.Zed 명령도 안내되어 있습니다. Linux에서는 설치 가이드의 공식 설치 프로그램과 시스템 요구 사항을 따릅니다. 저장소 폴더를 열고, 에이전트를 도입하기 전에 평소 사용하는 빌드나 테스트 명령이 정상 작동하는지 확인합니다.

2. 2

   기본 에이전트의 모델 선택 또는 API 키 등록

   명령 팔레트를 열어 agent: open settings를 실행합니다. AI > LLM Providers에서 API 키로 Anthropic이나 OpenAI 같은 지원 공급자를 설정하거나, Zed가 호스팅하는 모델을 선택합니다. Zed를 통해 저장한 키는 시스템 키체인에 보관됩니다. agent: new thread를 실행한 뒤 패널에서 사용할 모델과 공급자를 선택합니다. 같은 모델이 서로 다른 과금 공급자를 통해 제공될 수 있으므로 둘 다 확인해야 합니다. 공급자 설정

3. 3

   외부 에이전트 연결

   zed: acp registry를 실행해 Claude Agent나 Codex를 선택하고 설치합니다. 또는 Agent Settings > External Agents > Add Agent > Install from Registry를 이용합니다. 새 스레드 메뉴에서 설치한 에이전트의 스레드를 시작합니다. Claude Agent는 자체 인증에 /login을 사용한다고 안내합니다. Codex는 자체 로그인 절차를 사용하며, 가능한 인증 방식은 설치된 버전과 환경에 따라 달라집니다. 앞 단계의 키가 그대로 적용된다고 가정하지 말고 해당 연동의 안내를 따릅니다. 외부 에이전트 설정

4. 4

   범위를 좁힌 변경으로 확인

   선택한 에이전트에게 기존 테스트를 설명하고 그 테스트가 실행하는 코드를 찾아 달라고 요청합니다. 이어서 범위가 작은 변경을 요청하고, diff를 검토한 다음 저장소에서 평소 사용하는 검증 명령을 실행합니다. 의도한 지침, 툴, 과금 계정이 적용되어 있는지 확인합니다. Claude Code의 터미널 UI를 쓰는 것이 주목적이라면 패널의 새 스레드 메뉴에서 Terminal을 선택한 뒤 이미 설치한 CLI를 그 안에서 실행합니다.

작업을 시작하기 위해 기본 에이전트와 외부 에이전트를 모두 설정할 필요는 없습니다. 모델과 키를 설정하는 단계는 기본 에이전트 경로를, 레지스트리 단계는 외부 에이전트 경로를 준비합니다. 둘 다 사용할 수 있게 해 두는 것도 유용하지만, 의도치 않게 중복 설정하기보다 필요에 따라 선택해야 합니다.

Zed 에디터는 무료인가요? 작업 방식에 맞는 요금제

현재 Zed 요금제는 Personal: 자체 API 키나 외부 에이전트를 사용하면 무료, Pro: 월 $10, Business: 좌석당 월 $30입니다. 2026년 10월 15일 공식 요금 페이지에서 확인했습니다.

이미 사용하는 에이전트나 공급자 계정을 네이티브 에디터에서 활용하려는 목적이라면 Personal로 시작하면 됩니다. 에디터가 무료라고 외부 공급자 사용료까지 무료가 되는 것은 아닙니다. Zed가 호스팅하는 모델과 무제한 편집 예측을 원하는 개인에게는 Pro가 맞습니다. $5 상당의 토큰이 포함되며, 이후 호스팅 모델 사용량에는 API 정가에 10%를 더한 금액이 청구됩니다. 지출 한도도 설정할 수 있습니다. Personal에는 이 Pro 구성이 포함되지 않습니다. 요금제 상세

Business는 좌석당 고정된 모델 크레딧을 제공하기보다 조직 관리 기능과 지출 현황 파악 기능을 추가합니다. 필요한 관리 기능을 기준으로 구매해야 하며, 좌석 요금만 내면 에이전트를 무제한으로 사용할 수 있다고 가정해서는 안 됩니다. 팀 도입에서는 요금제 이름보다 아래의 계정·인증 및 관리 기능 한계가 더 중요합니다.

전환 전에 확인해야 할 Zed의 한계

Zed의 남은 한계는 도입 전에 구체적으로 확인할 수 있는 항목들입니다. 매일 필요한 작업을 지원하지 못한다면 편집 경험이 아무리 좋아도 그보다 큰 문제가 됩니다.

Zed 확장 프로그램: 적은 선택지가 전환의 제약이 됩니다

Zed는 VS Code 확장 프로그램이나 사용자 지정 키 바인딩을 가져오지 않습니다. 지원하는 에디터 설정은 가져올 수 있지만, 자체 가이드에서도 확장 프로그램의 범위가 더 작고 일부 전문 툴에는 동등한 대체재가 없다고 밝힙니다. VS Code 마이그레이션 가이드

설치한 테마를 전부 나열하기보다 실제로 일을 끝내는 데 쓰는 확장 프로그램 목록을 작성합니다. 필수 항목마다 Zed의 대체 확장 프로그램, 내장 기능 또는 기꺼이 사용할 수 있는 터미널 명령이 있는지 확인합니다. 없다면 해당 작업에는 VS Code나 Cursor를 계속 사용합니다. 팀 도입 후 처음으로 긴급 운영 버그를 조사하는 순간에 이런 공백을 발견해서는 안 됩니다.

디버거는 있지만 기존 디버깅 환경은 다시 구성해야 할 수 있습니다

Zed에는 디버거가 있습니다. 에디터와 언어별 디버깅 툴을 연결하는 인터페이스인 Debug Adapter Protocol을 통해 중단점, 단계별 실행, 변수 확인을 지원합니다. 공식 문서에는 Rust, Python, JavaScript, TypeScript, Go, C/C++ 등의 내장 어댑터가 나열되어 있습니다. Zed에 디버거가 없다는 설명은 잘못입니다. 디버거 문서

제약은 설정과 어댑터 지원 범위에 있습니다. 일부 프로젝트에는 .zed/debug.json이 필요합니다. Zed 설정 파일에서 구성을 찾지 못하면 .vscode/launch.json을 불러옵니다. 이 가져오기 경로가 모든 확장 프로그램, 어댑터 옵션, 디버깅 방식과의 호환성을 보장하지는 않습니다. 현재 문서상 프로세스 선택기는 Node로 제한됩니다. 실행 중인 프로세스를 직접 선택해 디버거를 연결하는 일이 일상적이라면 중요한 차이입니다.

실제 프로젝트에서 debugger: start를 실행해 봅니다. 실패한 테스트를 디버깅하는 경로, 환경 변수, 중단점, 평소 사용하는 프로세스 연결 방식을 확인합니다. VS Code는 여러 구성을 함께 시작하는 복합 실행 구성을 명시적으로 지원합니다. 여러 프로세스가 연동되는 개발 환경에 의존한다면, Zed에서 받아들일 만한 대안을 검증할 때까지 기존 구성을 유지합니다. VS Code 디버그 설정

Zed 스킬: 에디터가 같아도 에이전트 설정은 다릅니다

Zed 스킬은 SKILL.md 파일을 중심으로 구성한 재사용 가능한 지침 패키지입니다. 기본 Zed Agent는 프로젝트 또는 전역 스킬 디렉터리에서 이를 불러올 수 있습니다. 그러나 외부 에이전트 문서는 Zed Skills가 외부 에이전트에 Zed Skills로서 적용되지는 않는다고 명시합니다. 고유 지침의 적용 방식은 에이전트마다 다르며, 연동 문서에서 별도로 안내하지 않는 한 Zed Agent 프로필도 적용되지 않습니다. 스킬, 외부 에이전트의 설정 적용 범위

따라서 팀이 같은 에디터에서 같은 저장소를 열어도 어떤 에이전트 경로를 쓰는지에 따라 동작이 달라질 수 있습니다. 프로젝트에서 사용할 에이전트, 지침이 저장된 위치, 실제로 적용되는 툴 권한을 문서로 정리해야 합니다. 같은 모델 이름을 쓴다는 사실만으로 동일한 작업 방식이 보장되지는 않습니다.

Terminal Threads에는 또 다른 차이가 있습니다. 스레드를 보관하는 대신 닫으며, Zed의 Thread History에도 남지 않습니다. 검색 가능한 대화 기록을 에디터가 관리하는 것이 업무에 필수라면, 기본 에이전트 스레드와 같을 것이라 가정하지 말고 터미널 에이전트 자체의 기록 관리 방식을 확인해야 합니다. 터미널 스레드의 수명 주기

Business 관리 기능만으로 팀 도입 요건을 모두 충족하지는 못합니다

Zed Business는 현재 중앙 집중식 로그인, 연합 인증, 자동 계정 프로비저닝을 위한 SSO, SAML, SCIM을 제공하지 않습니다. 요금 페이지에는 도입 예정으로 표시되어 있습니다. 또한 조직 관리 기능이 Zed의 호스팅 서비스에만 적용되며, 외부 에이전트는 자체 공급자 관계를 유지한다고 설명합니다. Business 기능

중앙 집중식 계정·인증 관리가 필수라면 현재 Zed를 표준으로 채택하지 않을 이유가 됩니다. Cursor는 이미 Teams와 Enterprise의 SAML SSO를 문서로 안내합니다. 비교 기준은 로드맵의 약속이 아니라 지금 충족할 수 있는 요구 사항입니다. Cursor SSO 문서

이런 관리 기능이 필요 없는 소규모 팀에도 실무 준비는 남습니다. 지원할 언어, 에이전트 인증 방식, 승인된 공급자, 디버깅 절차를 정해야 합니다. 조직용 요금제를 구매한다고 이 설정 작업이 사라지거나 모든 외부 프로세스가 자동으로 관리되는 것은 아닙니다.

Zed editor 리뷰 결론: 언제 옮기는 것이 좋을까요?

Zed의 편집·협업 방식이 실제 일과를 개선하고, 필수 툴이 정상 작동하며, 에이전트를 별도로 고를 자유를 원한다면 옮길 만합니다. 에디터를 바꾸는 것보다 확장 프로그램, 디버깅 환경, 필수 관리 기능을 유지하는 것이 더 중요하다면 VS Code나 Cursor를 계속 사용하는 편이 낫습니다.

명령줄 툴에 이미 익숙한 개인 개발자라면 Zed Personal에 기존 에이전트를 조합하는 것이 합리적인 출발점입니다. 팀 리더라면 표준으로 지정하기 전에 희망자부터 시험 도입하게 합니다. 네이티브 편집, 멀티플레이어, 에이전트 선택권은 분명한 강점이지만, 어느 것도 프로젝트의 일상적인 개발 작업을 지원해야 한다는 조건을 없애지는 않습니다.

다음 업무일에는 평소 쓰는 저장소를 열어 작은 변경을 완료하고, AI가 만든 diff를 검토하고, 테스트를 실행하고, 디버거까지 사용해 봅니다. 멀티플레이어가 전환 이유 중 하나라면 함께 작업해 봅니다. 기존 에디터로 돌아가게 만드는 작업을 기록합니다. 그런 작업이 필수적이고 자주 발생한다면 기존 에디터를 기본으로 유지합니다. 주변적인 작업에 그친다면 Zed의 사용 범위를 넓혀도 좋습니다.

자주 묻는 질문

Linux에서는 어떤 코드 에디터를 쓰는 것이 좋을까요?

네이티브 편집과 다양한 에이전트 선택권을 원하고 시스템이 Vulkan 1.3 드라이버를 포함한 그래픽 요구 사항을 충족한다면 Zed를 검토할 수 있습니다. 필수 확장 프로그램이나 기존 디버그 환경이 선택을 좌우한다면 VS Code를 유지합니다. Zed 설치 요구 사항

Zed가 Cursor보다 나은가요?

네이티브 에디터와 에이전트를 독립적으로 선택하고 싶다면 Zed가 더 잘 맞습니다. VS Code 기반 환경을 유지하는 것이 우선이라면 Cursor가 더 안전한 전환 경로입니다. 이 리뷰에서는 속도나 모델 품질을 비교하는 벤치마크를 진행하지 않았습니다.

2026년에 VS Code 대신 쓸 만한 에디터는 무엇인가요?

네이티브 편집과 기본 제공 멀티플레이어 기능을 원한다면 Zed가 선택지입니다. 익숙한 에디터에 AI 툴을 통합하고 싶다면 Cursor가 맞습니다. 현재 Devin Desktop으로 바뀐 Windsurf도 통합 에이전트 환경입니다. 인터페이스 취향에 앞서 필수 확장 프로그램의 호환성으로 후보를 좁혀야 합니다.

Visual Studio Code는 어떤 용도로 쓰는 에디터인가요?

Visual Studio Code는 소스 코드를 편집하고 언어 툴, 디버깅, 확장 프로그램을 중심으로 개발 환경을 구성하는 데 사용합니다. Zed로 옮길 때는 기존에 구축한 이 툴 구성이 기준점입니다. 무엇을 유지하고, 대체하고, 의도적으로 단순화할지 결정해야 합니다.

VS Code보다 더 좋은 코드 에디터가 있나요?

자신의 작업 방식에 더 잘 맞는 에디터는 있을 수 있습니다. 네이티브 편집, 공동 작업, 유연한 에이전트 선택을 원한다면 Zed를 고려할 만합니다. 반면 기존 확장 프로그램과 디버그 설정이 업무의 중심이라면 VS Code가 여전히 더 적합합니다.

Zed 에디터는 오픈 소스인가요?

그렇습니다. Zed는 오픈 소스이며 AI는 선택 사항입니다. 다만 호스팅 모델 사용료나 외부 에이전트 공급자의 서비스까지 무료라는 뜻은 아닙니다. Zed

뉴스레터에서 실무에 도움이 되는 개발 워크플로 리뷰를 받아볼 수 있습니다.