VS Code는 모든 것이 사용 가능하지만 최적화된 것은 없는, IDE계의 Walmart(월마트)가 됨으로써 에디터 전쟁에서 승리했습니다. 이는 AI 코딩 어시스턴트(AI coding assistants)가 기반이 되는 에디터의 속도를 다시 중요하게 만들기 전까지는 괜찮았습니다. 당신의 워크플로우가 Claude Code 세션을 실행하고, 터미널에서 에이전트(agents)를 구동하며, 파일과 인라인 편집(inline edits) 사이를 빠르게 컨텍스트 스위칭(context-switching)하는 것을 포함한다면, VS Code가 Electron 셸(shell) 속에 묻어둔 지연 시간(latency)은 눈에 띄기 시작하는 방식으로 누적됩니다. 저는 약 4개월 전에 Zed로 전환했습니다. 실험으로서가 아니라, 정착했습니다.

VS Code가 항상 가지고 있었던 아키텍처 문제
VS Code는 Electron 위에서 실행됩니다. 이는 Chromium, Node.js, 그리고 당신과 코드 사이에 JavaScript UI 레이어가 있음을 의미합니다. 성능은 여러 가지 일을 동시에 수행할 때까지는 수용 가능한 수준입니다. 즉, 언어 서버(language server)가 실행 중이고, 터미널 프로세스가 활성화되어 있으며, AI 제안(AI suggestion)이 로드되고, 분할 뷰(split view)에 두 번째 파일이 열려 있는 상황 말입니다. 그 시점에서 당신은 모든 동작에 대해 오버헤드 세금(overhead tax)을 지불하게 됩니다.

Zed는 Rust로 작성되었습니다. Zed 팀이 직접 구축한 커스텀 GPU 가속 UI 프레임워크인 GPUI를 사용합니다. 에디터는 GPU로 직접 렌더링됩니다. 이것은 마케팅용 주장이 아닙니다. 스크롤 성능, 파일 전환, 커서 반응에서 직접 느낄 수 있습니다. 동일한 기기, 동일한 파일, 동일한 작업에서 Zed는 눈에 띄게 더 빠릅니다. 이는 3년 전보다 지금 더 중요합니다. AI 지원 코딩(AI-assisted coding)은 에디터가 세션당 더 많은 일을 수행함을 의미합니다: 인라인 완성(inline completions) 스트리밍, 디프(diffs) 렌더링, 다중 파일 컨텍스트(multi-file context) 관리 등입니다. 불필요한 지연 시간의 매 밀리초가 복리로 쌓입니다.

덧붙여진 느낌이 없는 멀티플레이어와 협업
Zed는 처음부터 멀티플레이어(multiplayer)를 염두에 두고 구축되었습니다. 두 사람이 실시간 커서 가시성을 통해 동시에 동일한 파일을 편집할 수 있으며, 이는 기대할 수 있는 기능입니다. 덜 명백한 점은, 이를 가능하게 하는 아키텍처가 단일 사용자 작업에서도 에디터 전체를 더 빠릿하게 만든다는 것입니다. 동시성 모델(concurrency model)이 확장 레이어(extension layer)가 아닌 코어에 내장되어 있기 때문입니다. 혼자 작업할 때, 멀티플레이어 인프라는 대부분 방해되지 않고 유지됩니다.

보안 연구 보고서(writeup)나 공유 스크립트에 대한 페어 세션(pair sessions) 또는 비동기 협업(async collaboration)을 진행할 때, Zed는 플러그인, 계정 핸드셰이크(account handshake), 또는 서비스 티어(service tier)를 요구하지 않고도 실제로 유용하게 작동합니다. VS Code의 LiveShare는 항상 이를 위해 설계되지 않은 무언가에 플러그인을 덕테이프로 붙여놓은 듯한 느낌을 주었습니다. Zed에서는 그것이 구조적(structural)입니다.

AI 레이어(The AI Layer): 전환이 실제로 의미 있었던 지점
이 부분이 저를 움직인 지점입니다. Zed는 확장 프로그램(extension)을 통해서가 아니라, 에디터의 아키텍처(architecture) 내에 내장된 네이티브 AI 통합(native AI integration)을 제공합니다. AI 패널, 인라인 완성(inline completions), 그리고 어시스턴트 창(assistant pane)은 일급 시민(first-class surfaces)으로서 존재합니다. Zed에서는 Claude를 AI 백엔드(backend)로 직접 실행할 수 있습니다. settings.json에서 다음과 같이 설정하면 됩니다:

{ "assistant" : { "default_model" : { "provider" : "anthropic" , "model" : "claude-sonnet-4-20250514" }, "version" : "2" } }

Zed의 어시스턴트 창은 에디터와 나란히 지속적인 컨텍스트 창(context window)으로서 작동합니다. @filename을 사용하여 대화 중에 파일을 직접 참조하거나, 진단(diagnostics) 정보를 가져오고, 현재 선택 영역을 포함하거나, 프로젝트 트리 전체를 참조할 수 있습니다. 컨텍스트 삽입(context insertion)은 수동적이고 명시적(explicit)입니다. 무엇을 넣을지는 사용자가 결정합니다. 이러한 명시성은 사실 하나의 기능입니다. Copilot 스타일의 자동 완성(autocomplete)을 사용할 때는 모델이 어떤 컨텍스트를 가지고 있는지 항상 추측해야 합니다. 반면 Zed의 어시스턴트 창에서는 무엇을 보냈는지 정확히 알 수 있습니다. 인라인 완성(inline completions) 또한 동일한 모델 백엔드를 통해 작동합니다. Zed에서 Claude 기반의 인라인 완성 시 발생하는 지연 시간(latency)은 VS Code 확장 프로그램을 통한 동일한 요청보다 낮은데, 이는 오버헤드(overhead)를 추가하는 확장 프로그램 호스트 미들웨어(extension host middleware)가 없기 때문입니다.

Claude Code 통합: 아무도 말하지 않는 부분
Claude Code는 터미널(terminal)에서 실행됩니다. Zed의 통합 터미널은 빠르고, 세션 간에 지속되며, 분할 창(split panes)을 깔끔하게 처리합니다. 이는 기본 사양(table stakes)입니다. 실제로 제 워크플로우를 변화시킨 부분은 Zed의 파일 워칭(file watching)과 에디터 상태(editor state)가 Claude Code의 파일 시스템 작업(filesystem operations)과 잘 통합된다는 점입니다. Claude Code가 파일을 작성하면, Zed는 이를 즉시 감지합니다.

새로고침 프롬프트도, 오래된 버퍼 경고도, 닫아야 하는 "디스크에서 파일이 변경되었습니다" 대화 상자도 없습니다. 파일이 그냥 업데이트됩니다. 프로젝트 전반에 걸쳐 10개의 파일을 건드리는 Claude Code 에이전트 루프를 실행할 때, 이러한 마찰 없는 동기화(frictionless sync)는 매우 중요합니다. 제가 가장 자주 사용하는 워크플로우는 다음과 같습니다: Zed를 프로젝트에 열어두고, 통합 터미널(integrated terminal)에서 프로젝트 루트에 claude를 실행하며, 특정 질문과 코드 리뷰를 위해 AI 어시스턴트 창을 열어두고, 채우기 작업을 위해 인라인 완성(Inline completions)을 활성화하는 것입니다. 이는 별도의 확장 프로그램(extensions) 없이도 하나의 에디터 안에서 세 가지 AI 접점(surfaces)을 사용하는 것입니다. VS Code는 Copilot + Claude 확장 프로그램 + 터미널 세션을 통해 이를 비슷하게 구현할 수 있지만, 세 가지 서로 다른 컨텍스트 모델(context models)과 세 가지 서로 다른 지연 시간 프로필(latency profiles)을 관리해야 합니다. Zed에서는 이것이 하나의 일관된 시스템입니다.

확장 프로그램 생태계의 격차 (그리고 그것이 생각보다 덜 중요한 이유)
Zed는 VS Code의 확장 프로그램 라이브러리를 보유하고 있지 않습니다. 이는 실제적인 트레이드오프(tradeoff)입니다. VS Code 확장 프로그램으로 존재하는 특정 언어 도구, 니치 포매터(niche formatters), 워크플로우 플러그인들이 아직 Zed의 대응물로 존재하지 않을 수 있습니다. 하지만 제가 수행하는 보안 및 임베디드 작업의 경우, 그 격차는 예상보다 작습니다. Zed의 Rust 지원은 매우 훌륭하며, 이는 에디터 자체가 Rust로 작성되었다는 점을 고려하면 당연한 결과입니다. Python, TypeScript, Go, C/C++ 언어 서버는 LSP(Language Server Protocol)를 통해 작동합니다. Tree-sitter 구문 강조(syntax highlighting)는 제가 실제로 매일 사용하는 언어들을 모두 커버합니다. 제가 잃은 것: CAN DBC 파일 파싱을 위한 몇 가지 특정 VS Code 확장 프로그램, 수년간 구축해 온 일부 커스텀 스니펫(minor restructuring을 통해 Zed로 이식 가능), 그리고 몇 개의 Git blame 시각화 플러그인입니다. 제가 유지한 것: 업무에 중요한 모든 것들입니다. 만약 당신의 워크플로우가 대응물이 없는 특정 VS Code 확장 프로그램에 깊이 의존하고 있다면, Zed는 걸림돌이 될 것입니다. 전환하기 전에 실제 확장 프로그램 사용 현황을 점검하십시오. 대부분의 사람은 30개의 확장 프로그램을 설치해 두고 6개만 사용합니다.

키 바인딩(Keybindings)과 근육 기억(Muscle Memory) 문제
Zed는 VS Code 키맵(keymap) 임포트를 지원합니다. 변환이 완벽하지는 않지만, 첫 일주일 동안 완전히 새로 학습해야 할 정도는 아닐 만큼 충분히 가깝습니다.

// settings.json에서 VS Code 스타일의 바인딩을 사용하려면: { "base_keymap" : "VSCode" }

차이점은 예외적인 상황(edge cases)에서 나타납니다. 특정 멀티 커서(multi-cursor) 조합, 패널 포커스 단축키, 일부 터미널 키 바인딩 등이 그렇습니다. 커맨드 팔레트(Command Palette, Mac에서는 Cmd+Shift+P, Linux에서는 Ctrl+Shift+P)는 동일하게 작동하며, 키 바인딩의 공백을 메우지 못하는 대부분의 부분을 커버합니다. 결정을 내리기 전에 2주일 정도는 사용해 보세요. 처음 3일은 짜증이 날 것입니다. 하지만 2주 차에 접어들면, 에디터의 속도가 가끔 발생하는 근육 기억(muscle memory)의 오류를 상쇄하기 시작합니다.

VS Code가 여전히 가지고 있지만 Zed에는 없는 것

솔직한 평가: 확장 프로그램(extension) 생태계.
이것은 명백한 부분입니다. 완전한 IntelliSense를 갖춘 원격 SSH 개발이 필요하다면, VS Code의 Remote Development 확장 프로그램 제품군은 아직 Zed에서 대적할 만한 것이 없습니다. Zed도 원격 편집 기능을 개발 중이지만, 아직 기능적 동등성(feature parity)에는 도달하지 못했습니다.

Jupyter Notebook 지원.
VS Code는 .ipynb 파일을 네이티브로 처리합니다. Zed는 2026년 중반 기준으로 이 기능을 지원하지 않습니다. 만약 당신의 워크플로우가 노트북 기반이라면, 이는 차단 요소(blocker)가 됩니다.

디버거 GUI.
VS Code의 디버거 UI는 성숙해 있습니다. Zed의 디버깅 지원도 개선되고 있지만, 변수 검사(variable inspection) 패널을 갖춘 VS Code의 DAP(Debug Adapter Protocol) 기반 디버거는 대부분의 사용 사례에서 여전히 앞서 있습니다. OpenOCD 및 GDB를 사용하는 임베디드 작업의 경우, 저는 여전히 특정 상황에서 VS Code를 사용하고 있습니다.

그 외 실제 일상적인 워크플로우의 모든 부분에서는 Zed가 속도 면에서 승리하며, AI 통합의 일관성(coherence) 덕분에 이러한 트레이드오프(tradeoffs)를 감수할 가치가 있습니다.

설정 인터페이스 (The Configuration Surface)

Zed는 완전히 JSON으로 설정됩니다. 설정 UI 미로도 없고, 찾아 헤매야 할 GUI 토글도 없습니다. 당신의 settings.json과 keymap.json이 전체 설정 인터페이스입니다.

{ 
  "theme" : "One Dark", 
  "buffer_font_family" : "Zed Mono", 
  "buffer_font_size" : 14, 
  "vim_mode" : true, 
  "format_on_save" : "on", 
  "tab_size" : 2, 
  "soft_wrap" : "editor_width", 
  "terminal" : { 
    "font_family" : "Zed Mono", 
    "font_size" : 13 
  } 
}

설정 파일은 Linux에서는 ~/.config/zed/settings.json에, macOS에서는 ~/Library/Application Support/Zed/settings.json에 위치합니다. 이를 도트 파일(dot-file)로 관리하고, 버전 관리(version control)하며, 동기화하세요.

전환하기
AI 중심의 워크플로우를 가진 VS Code 사용자라면, 전환 시 발생하는 마찰(friction)은 예상보다 적을 것입니다. 먼저 VS Code의 확장 프로그램(extensions) 목록을 내보내세요. — 어떤 것이 진정으로 중요한지, 아니면 한 번 설치하고 잊어버린 것인지 식별하십시오. 이를 Zed의 대응 프로그램으로 매핑하거나, 아예 삭제해도 될지 결정하세요. $ code --list-extensions > vscode_extensions.txt

단번에 바꾸기보다는 2주 동안 VS Code와 Zed를 병행하여 사용해 보세요. 새로운 작업에는 Zed를 사용하고, 아직 해결되지 않은 확장 프로그램이 필요한 작업에는 VS Code를 사용하십시오. 2주가 지나면 귀하의 워크플로우가 적합한지 알 수 있을 것입니다. 성능 차이는 실재하며, 이는 복리로 작용합니다. 빠른 에디터, 빠른 AI 응답, 깔끔한 컨텍스트 관리(context management). 특히 AI 증강(AI-augmented) 작업의 경우, 아키텍처 선택이 이전과는 다른 방식으로 중요해지기 시작합니다.

Zed의 설정과 파워 유저(power-user) 워크플로우를 더 깊이 파고들고 싶다면, numbpilled.gumroad.com/l/zed-playbook 에 플레이북을 준비해 두었습니다. 터미널 에디션으로, 키맵(keymaps), AI 백엔드 설정(AI backend configuration), 멀티 프로젝트 설정(multi-project setups), 그리고 가장 먼저 배울 가치가 있는 단축키들을 다룹니다. 이 워크플로우의 Claude Code 측면에 대해서는, numbpilled.gumroad.com/l/claude-code-for-devs 에 생산성 팁 가이드가 있습니다. 에이전트 루프(agent loop)가 실제로 작동하는 방식을 변화시키는 21가지 패턴을 담고 있습니다.