AI 보강 워크플로우에서 Zed가 VS Code를 대체하는 이유
출처: Dev.to
VS Code는 모든 것이 제공되고 최적화된 것이 없는 IDE의 월마트가 되면서 에디터 전쟁에서 승리했습니다. AI 코딩 어시스턴트가 등장해 기본 에디터의 속도가 다시 중요한 요소가 되기 전까지는 괜찮았죠. 워크플로우에 Claude Code 세션을 띄우고, 터미널에서 에이전트를 실행하며, 파일 간 전환과 인라인 편집을 빠르게 오가야 할 때, Electron 셸에 파묻힌 VS Code의 지연 시간이 눈에 띄게 쌓이기 시작합니다.
나는 약 4개월 전 Zed로 옮겼습니다. 실험 차가 아니라, 그대로 남아있어요.
VS Code는 Electron 위에서 동작합니다. 즉, Chromium, Node.js, 그리고 여러분과 코드 사이에 존재하는 JavaScript UI 레이어가 있다는 뜻이죠. 여러 작업을 동시에 할 때—예를 들어 언어 서버가 실행되고, 터미널 프로세스가 살아있으며, AI 제안이 로드되고, 분할 뷰에 두 번째 파일이 열려 있는 경우—성능은 감당할 만하지만 매 행동마다 오버헤드 세금을 내는 셈입니다.
Zed는 Rust로 작성되었습니다. Zed 팀이 직접 만든 GPU 가속 UI 프레임워크인 GPUI를 사용합니다. 에디터가 GPU에 직접 렌더링되죠. 이것은 마케팅용 주장만이 아니라, 스크롤 성능, 파일 전환, 커서 반응 속도에서 체감할 수 있는 차이입니다. 같은 머신, 같은 파일, 같은 작업이라면 Zed가 눈에 띄게 빠릅니다.
이 점은 3년 전보다 지금이 더 중요합니다. AI 보조 코딩은 세션당 처리량이 늘어나기 때문이죠: 인라인 완성 스트리밍, diff 렌더링, 다중 파일 컨텍스트 관리 등. 불필요한 지연 1 ms도 누적됩니다.
Zed는 처음부터 멀티플레이어를 염두에 두고 설계되었습니다. 두 사람이 같은 파일을 동시에 편집하면서 실시간 커서 위치를 볼 수 있는데, 이는 당연히 기대되는 기능입니다. 덜 눈에 띄는 점은, 이 아키텍처가 싱글 유저 작업에서도 에디터를 더 민첩하게 만든다는 것입니다—동시성 모델이 코어에 내장돼 있어 별도의 확장 레이어가 필요하지 않으니까요.
혼자 작업할 때는 멀티플레이어 인프라가 거의 방해가 되지 않습니다. 하지만 보안 연구 보고서나 공유 스크립트를 작성할 때, 별도 플러그인·계정 연동·서비스 티어 없이도 페어 세션이나 비동기 협업에 유용합니다.
VS Code의 Live Share는 설계되지 않은 무언가에 플러그인을 억지로 붙인 느낌이었지만, Zed에서는 구조적으로 내재돼 있습니다.
이 부분이 나를 움직이게 했습니다. Zed는 확장이 아니라 에디터 아키텍처 자체에 AI 통합을 제공하죠. AI 패널, 인라인 완성, 어시스턴트 창이 모두 일등급 인터페이스입니다.
Claude를 Zed에서 직접 AI 백엔드로 사용할 수 있습니다. settings.json에 다음과 같이 설정하면 됩니다:
{
"assistant": {
"default_model": {
"provider": "anthropic",
"model": "claude-sonnet-4-20250514"
},
"version": "2"
}
}Zed의 어시스턴트 창은 에디터와 나란히 지속적인 컨텍스트 창으로 동작합니다. @filename 으로 파일을 직접 언급하거나, 진단 정보를 끌어오고, 현재 선택 영역을 포함하거나, 프로젝트 전체 트리를 참조할 수 있습니다. 컨텍스트 삽입은 수동이며 명시적입니다—무엇을 넣을지는 여러분이 직접 결정합니다.
이 명시성 자체가 기능입니다. Copilot 스타일 자동완성은 모델이 어떤 컨텍스트를 가지고 있는지 추측해야 하지만, Zed의 어시스턴트 창에서는 정확히 보낸 내용을 알 수 있습니다.
인라인 완성도 같은 모델 백엔드를 사용합니다. Claude 기반 인라인 완성의 지연 시간은 VS Code 확장 호스트가 추가적인 오버헤드를 발생시키는 것보다 낮습니다.
Claude Code는 터미널에서 실행됩니다. Zed의 통합 터미널은 빠르고 세션 간에 지속되며, 분할 창도 깔끔하게 처리합니다. 이것은 기본적인 기능이죠. 실제로 내 워크플로우를 바꾼 부분은 Zed의 파일 감시와 에디터 상태가 Claude Code의 파일 시스템 작업과 잘 연동된다는 점입니다.
Claude Code가 파일을 쓸 때, Zed는 즉시 이를 감지합니다. 재로드 프롬프트도, 오래된 버퍼 경고도, “디스크에서 파일이 변경되었습니다” 대화상자도 없습니다. 파일이 바로 업데이트됩니다. 프로젝트 전반에 걸쳐 10개의 파일을 건드리는 Claude Code 에이전트 루프를 돌릴 때, 이런 마찰 없는 동기화는 큰 차이를 만듭니다.
내가 가장 많이 쓰는 워크플로우는 다음과 같습니다:
- Zed에서 프로젝트 열기
- 프로젝트 루트에서 통합 터미널로 Claude Code 실행
- 특정 질문 및 코드 리뷰를 위한 AI 어시스턴트 창 열기
- 채워넣기 작업을 위한 인라인 완성 활성화
이렇게 하면 하나의 에디터 안에 세 개의 AI 인터페이스가 생기며, 확장은 전혀 필요 없습니다. VS Code에서도 Copilot + Claude 확장 + 터미널 세션으로 비슷하게 구현할 수는 있지만, 서로 다른 컨텍스트 모델과 지연 프로파일을 각각 관리해야 합니다. Zed에서는 하나의 일관된 시스템이 됩니다.
Zed는 VS Code의 방대한 확장 라이브러리를 가지고 있지는 않습니다. 이것은 실질적인 트레이드오프죠. 특정 언어 도구, 특수 포매터, 워크플로우 플러그인 등 VS Code 전용 확장은 아직 Zed에 대응되는 것이 없을 수 있습니다.
하지만 내가 하는 보안·임베디드 작업에서는 그 격차가 예상보다 작았습니다. Zed는 Rust 지원이 뛰어나죠—에디터 자체가 Rust로 구현돼 있기 때문입니다. Python, TypeScript, Go, C/C++ 언어 서버는 LSP를 통해 동작합니다. Tree‑sitter 기반 구문 강조는 내가 일상적으로 다루는 언어들을 충분히 커버합니다.
잃은 것: CAN DBC 파일 파싱을 위한 몇몇 VS Code 확장, 수년간 구축한 맞춤 스니펫(조금만 구조를 바꾸면 Zed에서도 사용 가능), Git blame 시각화 플러그인 몇 개.
얻은 것: 작업에 진짜 중요한 모든 것.
특정 VS Code 확장에 깊이 의존하고 그에 상응하는 Zed 대체품이 없다면, Zed는 여러분을 막을 수 있습니다. 전환하기 전에 실제로 사용 중인 확장을 점검하세요. 대부분의 사람들은 30개 정도의 확장을 설치하고 실제로는 6개만 사용합니다.
Zed는 VS Code 키맵 임포트를 지원합니다. 변환이 완벽하진 않지만 첫 주에 완전한 재훈련이 필요할 정도는 아닙니다.
// settings.json에서 VS Code 스타일 바인딩을 사용하려면:
{
"base_keymap": "VSCode"
}갭은 가장자리 경우에 존재합니다—특정 멀티 커서 조합, 패널 포커스 단축키, 일부 터미널 키바인드 등. 커맨드 팔레트(Cmd+Shift+P macOS, Ctrl+Shift+P Linux)는 동일하게 동작하며, 키바인드 차이를 대부분 메워줍니다.
두 주 정도 사용해 보세요.
첫 3일은 불편할 수 있습니다. 2주 차가 되면 에디터 속도가 가끔 발생하는 근육 기억 오류를 보상해 줍니다.
솔직한 평가
- 확장 생태계: 가장 명백한 차이점입니다. 원격 SSH 개발과 완전한 IntelliSense가 필요하다면, VS Code의 Remote Development 확장 세트는 아직 Zed에 동등한 것이 없습니다. Zed도 원격 편집을 진행 중이지만 기능 동등성은 아직 부족합니다.
- Jupyter Notebook 지원: VS Code는
.ipynb파일을 네이티브하게 다룹니다. 2026년 중반 현재 Zed는 이를 지원하지 않으므로, 노트북 중심 워크플로우라면 큰 장애물입니다. - 디버거 GUI: VS Code의 디버거 UI는 성숙했습니다. Zed의 디버깅 지원도 개선 중이지만, VS Code의 DAP 기반 디버거와 변수 검사 패널이 대부분의 경우 앞서 있습니다. 임베디드 작업에서 openocd·GDB를 사용할 때는 아직 VS Code를 쓰고 있습니다.
그 외의 일상적인 작업에서는 Zed가 속도 면에서 승리하고, AI 통합의 일관성이 트레이드오프를 충분히 상쇄합니다.
Zed는 설정을 전부 JSON으로