왜 Zed 에디터를 쓰기 시작했는가

Zed 팀이 이전에 만들던 것은 Atom이었습니다.

Atom은 Chromium의 fork였고, 그것을 만드는 과정에서 겸사겸사 나온 것이 Electron이었습니다. 즉 훗날 VS Code의 토대입니다. 나쁘게 말하면 VS Code가 서 있는 그 땅을 판 것이 바로 이 사람들 자신이고, 그들은 지금 그 옆에 그 토대를 쓰지 않는 집을 지은 셈입니다.

Zed의 1.0이 나온 것은 2026년 4월 29일. 오 년에 걸쳐, 백만 줄이 넘는 Rust입니다.

제가 VS Code에서 옮긴 이유는 그렇게 시적이지 않습니다. 어느 날 서버를 96°C까지 태워 먹고, 그러고 나서 이게 제 머신에 무엇을 남겨 두고 있었는지를 재 본 것뿐입니다.

먼저 청구서를 본다#

로컬 쪽, 둘 다 프로젝트를 하나 열어 둔 상태에서:

서버 쪽 차이는 더 큽니다. 원격 개발은 접속하는 머신에 자기 런타임을 남겨 두는데, VS Code의 것은 이랬습니다.

7.9 GB 대 107 MB. 일흔 배입니다.

VS Code의 7.9 GB를 분해하면 cli 3.2 GB, bin 2.9 GB, extensions 945 MB, data 412 MB. 게다가 그 안에는 rust-analyzer 확장이 두 버전으로 나란히 눌러앉아 있었고, 오래된 쪽은 아무도 치우지 않았습니다.

솔직히 이 숫자만으로 한번 써 볼 마음이 들었고, 실제 사용감도 거기에 맞습니다. 스크롤, 파일 열기, 검색, 탭 전환이 전부 즉각적이고, 그 "잠깐 생각 좀 하고"라는 걸림이 없습니다.

공식 이사 경로가 있다#

이건 나중에 안 것인데, Zed에는 How to Migrate from VS Code to Zed라는 공식 문서가 한 페이지 통째로 있고, 첫 실행 설정 마법사가 VS Code 설정을 가져올지, 어느 AI와 연결할지를 물어봅니다.

마법사를 건너뛰었어도 명령 팔레트에서 부를 수 있습니다.

무엇을 가져오고, 무엇을 가져오지 않는가#

공식에 대응표가 있습니다. 몇 개만 발췌하면:

탭, 파일 탐색기, Git, 터미널, 폰트, 그리고 에디터 설정 대부분을 커버합니다.

다만 확장은 가져오지 않고, 키 바인딩도 가져오지 않습니다. 이 둘은 직접 해야 합니다.

키맵: 기본값이 이미 VS Code#

base_keymap의 기본값이 애초에 VS Code라서 아무것도 하지 않아도 됩니다. 확인하거나 다른 것으로 바꾸고 싶다면:

{ "base_keymap": "VSCode" }

고를 수 있는 건 VS Code, Atom, Emacs(Beta), JetBrains, Sublime Text, TextMate, Cursor, 그리고 None. 설정 창에서도 고를 수 있고, 명령 팔레트의 zed: toggle base keymap selector로도 바꿉니다.

일상적으로 가장 많이 누르는 것들은 완전히 같습니다. Ctrl + Shift + E로 파일 목록, Ctrl + Shift + G로 Git. 손가락을 다시 훈련할 필요가 없습니다.

공식에는 "VS Code 키맵을 골라도 다른 것"의 목록이 있는데, 그 표는 macOS 표기로 쓰여 있고 게다가 두 열의 플랫폼이 서로 다릅니다. 그대로 베끼면 헷갈립니다.

Windows와 Linux에서는 Cmd를 Ctrl로 읽습니다. Zed의 키맵 정의에는 바로 이걸 위한 secondary-라는 수식 키가 있습니다. 실제로 찾아볼 거라면 저장소에 있는 플랫폼별 기본 키맵을 보는 편이 확실합니다.

더 편한 건 내장 Keymap Editor(Ctrl + K 다음 Ctrl + S)로, 모든 동작과 현재 할당이 한눈에 보이고 그 자리에서 바꿀 수 있습니다. 거기서 한 변경은 keymap.json에 다시 기록됩니다.

확장 23개가 옮기고 나니 8개#

이 이사에서 가장 체감이 컸던 게 여기입니다. VS Code에는 확장을 23개 넣어 뒀는데, Zed로 옮겨서 실제로 "설치"가 필요했던 건 8개뿐이었습니다.

기능이 줄어서가 아닙니다. 분류를 나누는 방식이 다르기 때문입니다.

basedpyright   bash-language-server   eslint   json-language-server
package-version-server   ruff   rust-analyzer   tailwindcss-language-server
vscode-css-language-server   vtsls   yaml-language-server

공식은 이 점을 꽤 솔직하게 적어 뒀는데, 그게 제가 잃은 것에 그대로 들어맞습니다.

Zed does not offer as many extensions as VS Code. You won't find one-to-one replacements for every VS Code extension, especially if you rely on tools for DevOps, containers, or test runners.

반대 방향으로, "VS Code에서는 확장이 필요하지만 Zed에서는 내장"인 것도 열거되어 있습니다. 실시간 공동 편집(Live Share 불필요), AI 보조, 터미널 패널, 프로젝트 전체 퍼지 검색, 태스크 러너, LSP 진단.

설정: GUI가 있고, 생각보다 완성도가 높다#

Zed는 JSON으로만 설정할 수 있다고 믿고 있었는데, 이 글을 쓰는 도중에 아니라는 걸 알았습니다. Ctrl + ,로 열리는 건 검색 상자, 분류, 토글, 드롭다운을 갖춘 완전한 설정 창입니다.

분류는 열다섯 개. 그리고 각 항목 옆에 "Edit in settings.json"이 있어 바로 원본 파일로 갈 수 있습니다. GUI와 JSON은 같은 설정으로 들어가는 두 개의 입구이지 양자택일이 아닙니다.

파일을 직접 편집하고 싶다면 명령 팔레트의 zed: open settings file, 또는 Ctrl + Alt + ,입니다.

프로젝트 단위 설정은 꽤 적다#

이건 실제로 쓰다 보면 반드시 부딪히는 제약입니다. 설정 창 위쪽에서 범위를 바꿀 수 있는데, 프로젝트 쪽으로 바꾸면 분류가 열다섯에서 다섯으로 떨어집니다.

프로젝트 설정은 프로젝트 안의 .zed/settings.json에 놓이고, 거기에 쓸 수 있는 건 에디터 동작과 언어 도구 계열뿐입니다(tab_size, formatter, format_on_save 등).

그래서 "이 프로젝트만 auto_fold_dirs를 끄고 싶다", "여기만 Auto Reveal을 끄고 싶다" 같은 요구는 현재로서는 전역에서만 바꿀 수 있습니다. VS Code 헤비 유저인 동료가 가장 먼저 부딪힌 게 이거였습니다.

패널 위치#

겸사겸사 적어 두면, 패널을 반대쪽으로 옮기는 데 설정을 열 필요가 없습니다. 패널 아이콘에서 오른쪽 클릭하면 나옵니다.

settings.json에서 각 패널의 dock을 고정할 수도 있고, 저는 그렇게 하고 있습니다.

제 설정, 그대로 가져가세요#

레이아웃과 배색이 마음에 든다면 통째로 가져가서 고치시면 됩니다. 원격 접속 부분은 빼고 주석 템플릿으로 남겨 뒀습니다.

{
  // base_keymap은 기본값이 VSCode. 이 줄은 명시일 뿐
  "base_keymap": "VSCode",

  // CLI로 파일을 열 때 새 창이 아니라 기존 창을 쓴다
  "cli_default_open_behavior": "existing_window",

  // 원격 접속(host는 ~/.ssh/config의 별칭)
  // "ssh_connections": [
  //   {
  //     "host": "my-server",
  //     "args": [],
  //     "projects": [
  //       { "paths": ["/home/you/projectA"] },
  //       { "paths": ["/home/you/projectB"] }
  //     ]
  //   }
  // ],

  // 패널 위치
  "project_panel": { "dock": "left" },
  "git_panel": { "tree_view": true, "dock": "left" },
  "collaboration_panel": { "dock": "left" },
  "outline_panel": { "dock": "right" },
  "agent": { "sidebar_side": "right", "dock": "right" },

  // 외부 agent(다음 절에서 설명합니다)
  "agent_servers": {
    "claude-acp": {
      "type": "registry",
      "default_config_options": { "fast": false }
    }
  },

  // 외관
  "theme": {
    "mode": "dark",
    "light": "Gruvbox Light",
    "dark": "Catppuccin Macchiato - No Italics"
  },
  "icon_theme": {
    "mode": "dark",
    "light": "Zed (Default)",
    "dark": "Material Icon Theme"
  },
  "ui_font_size": 16,
  "buffer_font_size": 15,
  "minimap": { "show": "always" },

  "telemetry": {
    "diagnostics": true,
    "metrics": false,
    "anthropic_retention": false
  },

  // 원격 프로젝트를 열 때마다 신뢰 확인이 뜨는 건 번거롭지만,
  // 이건 모든 worktree를 무조건 신뢰한다는 뜻. 각자 판단할 것
  "session": { "trust_all_worktrees": true }
}

두 가지만 덧붙이면, telemetry.metrics는 꺼 뒀습니다. session.trust_all_worktrees는 편하지만 그 확인 절차를 포기하는 것이기도 하니 스스로 저울질하시기 바랍니다.

인터페이스의 차이#

VS Code는 여기저기에 버튼이 있습니다. 예를 들어 파일 탐색기 헤더에 있는 새 파일·새 폴더·새로 고침·전부 접기 줄.

Zed는 반대 방향이라 대부분의 조작이 명령 팔레트와 오른쪽 클릭에 있습니다. 처음에는 뭔가 빠진 느낌이지만, 익숙해지면 손이 키보드를 떠나지 않게 됩니다.

솔직히 이 이사에서 가장 큰 비용이 이것이었습니다. 기능이 아니라 습관입니다. 실제 기능 차이는 아주 소수(뒤에 정리)이고, 첫 이틀의 어색함은 거의 전부 근육 기억이 따라오지 못한 것뿐이었습니다.

원격 개발#

저에게는 여기가 출발점이니 조금 자세히 씁니다.

원격 프로젝트는 설정 파일의 ssh_connections에 직접 씁니다. host는 ~/.ssh/config의 별칭이므로 키도 점프 호스트도 포트도 전부 SSH 쪽 일이고, Zed가 별도 체계를 갖지 않습니다.

콜드 스타트에서 코드를 쓰기 시작할 때까지:

첫 접속에서 원격 서버를 올려 보내고(앞의 그 107 MB가 그것입니다), 이후 그 프로세스는 상주하므로 재접속은 빠릅니다. 제 머신의 원격 서버 프로세스는 이레 동안 연속으로 떠 있습니다.

끊김이 VS Code보다 훨씬 안정적이다#

이건 예상하지 못한 수확이었습니다. VS Code Remote-SSH는 회선 품질이 나쁠 때 자주 재접속과 창 다시 불러오기가 필요하고, 가끔 "Reconnecting..."에서 멈춥니다. 같은 네트워크 환경에서 Zed는 재접속에 실패하는 횟수가 눈에 띄게 적고, 대개는 눈치채지 못하는 사이에 다시 붙어 있습니다.

같은 창에서 원격 프로젝트를 전환한다#

이건 VS Code에 없습니다. VS Code에서 두 번째 원격 프로젝트를 열면 두 번째 창이 되고, 창과 탭이 점점 쌓입니다. Zed는 같은 창 안에서 갈아 끼울 수 있어 시각적으로 훨씬 정리됩니다. 여기는 저도 생각보다 마음에 들었습니다.

내장 Git이 예상보다 완성되어 있다#

GitLens 대체를 찾게 될 줄 알았는데 그럴 필요가 없었습니다. Git 패널은 트리 표시로 바꿀 수 있고, 커밋 이력도 diff도 에디터 안에서 끝납니다.

인라인 blame도 내장이라 마우스를 올리면 카드가 뜹니다.

Markdown 미리보기가 mermaid를 그린다#

이건 처음에 걱정했던 부분입니다. 글을 쓸 때 mermaid를 많이 쓰는데 VS Code 쪽에서는 확장으로 받치고 있었기 때문입니다. 결과적으로 Zed의 내장 미리보기는 그냥 그려 줬습니다.

ACP: agent를 에디터에서 떼어내다#

이건 옮기고 나서야 처음 접한 것이고, 이 글에서 가장 쓰고 싶었던 부분이기도 합니다.

ACP의 위치는 아주 분명합니다.

LSP는 "언어의 지능"을 IDE에서 떼어냈다. ACP는 agent에 대해 같은 일을 하려 한다.

LSP 이전에는 모든 에디터가 각 언어의 자동 완성과 정의 이동을 직접 구현해야 했습니다. LSP 이후에는 언어 쪽이 서버를 한 번 쓰면 모든 에디터가 씁니다. ACP가 노리는 건 정확히 같은 모양의 문제입니다. 지금은 모든 AI agent가 에디터마다 플러그인을 써야 하고, ACP는 그것을 한 번으로 끝내게 합니다.

JetBrains, Google, GitHub가 이미 참여했고 레지스트리에는 스물다섯 개가 넘는 agent가 있습니다. Zed의 첫 실행 마법사는 어디와 연결할지를 물어봅니다.

이렇게 생겼습니다#

설정에 agent server를 더하면 사이드바에 agent가 나타납니다.

오른쪽 아래 줄을 보세요. Opus (1M context), High, Fast mode.

이 줄이 핵심이고, ACP의 분담을 설명합니다. 공식 문서는 이렇게 씁니다.

Zed hosts the thread in the Agent Panel, while the External Agent usually owns its own runtime, auth, model selection, tools, and native configuration.

즉 모델 선택, 인증, 도구, 설정은 전부 agent 쪽 것이고, Zed가 빌려주는 건 인터페이스뿐입니다. 스레드 표시, 다중 파일 편집, 프로젝트 문맥, diff 리뷰.

제 처음 의문은 "agent panel을 통하는 것과 CLI를 직접 쓰는 것은 모델이 다른가"였습니다. 아무리 찾아도 답이 나오지 않았고, 나중에야 깨달았습니다. 그 질문 자체가 틀렸다는 것을요. ACP는 모델을 전혀 건드리지 않습니다. 양쪽 다 같은 것을 돌립니다.

과거 대화를 가져올 수 있다#

이건 좀 깊숙이 있지만 유용합니다. Ctrl + Alt + J로 Threads Sidebar를 열고, Ctrl + G(또는 왼쪽 아래 시계 아이콘)로 Thread History를 엽니다.

그 안에 Import Threads 버튼이 있습니다.

가져올 agent를 고르면 Zed가 ACP를 통해 그 agent가 로컬에 남긴 과거 세션을 가져와 이력에 더해 줍니다. 가져온 것은 보관 상태라 열면 이어서 이야기할 수 있습니다. 이미 이력에 있는 것은 자동으로 건너뛰므로 중복해서 가져와도 안전합니다.

Terminal Threads: 사실 둘 중 하나를 고를 필요가 없다#

"네이티브 agent panel을 쓴다"와 "터미널에서 CLI를 돌린다"가 양자택일이라고 믿고 있었는데, Zed는 이미 이걸 해결해 뒀습니다.

Terminal Threads를 쓰면 Agent Panel의 + 메뉴에서 Terminal을 고를 수 있습니다. 열린 터미널은 Threads Sidebar 안의 스레드 하나가 됩니다. 거기서 claude든 amp든 codex든 원하는 것을 돌릴 수 있고, 사이드바 제목은 돌고 있는 프로그램에 맞춰 자동으로 갱신됩니다.

Zed 자신의 agent 스레드나 ACP 스레드와 자유롭게 섞을 수 있고, 키보드 조작도 알림도 똑같습니다. 즉 CLI 본래의 환경과 사용량을 유지한 채 Zed의 인터페이스를 얻을 수 있는 것입니다.

그래도 CLI는 일반 터미널에 두고 있습니다#

이유는 하나뿐입니다.

/rc(remote control)는 CLI에만 있습니다.

차이는 기능의 많고 적음이 아니라 세션을 누가 갖고 있는가입니다.

저는 세션을 열 때마다 자동으로 /rc가 돌게 해 뒀습니다. 어디에 있든 Claude Desktop에서 탭을 하나 열면 같은 세션을 이어받을 수 있고, 저쪽 머신에서 Zed가 켜져 있을 필요조차 없습니다.

영상의 Resume session (2 of 27)이라는 선택 화면이 바로 이 구조로, 세션은 에디터와 독립해서 존재하고 에디터는 그 입구 중 하나일 뿐이라는 뜻입니다.

바꿔 말하면 저는 더 통합된 인터페이스를 버리고 어떤 머신에도 묶이지 않는 것을 택했습니다. 머신을 넘나들 필요가 없다면 agent panel이든 Terminal Threads든 그쪽이 더 편하니 말리지 않습니다.

부족한 것#

이 절은 이사를 검토하는 분들을 위한 것입니다. 제가 직접 부딪힌 것과 찾아본 것을 합치면 대략 이렇습니다.

반대로 Dev Container는 2026년 1월에 지원됐습니다. 인터넷에 있는 비교적 오래된 Zed 리뷰들은 이걸 단점으로 들기 쉬운데, 그 항목은 이제 지울 수 있습니다. 그리고 그게 다음 절의 이야기이기도 합니다.

번체 중국어의 커뮤니티 방안#

공식은 착수할 기미가 없지만 커뮤니티에는 zed-i18n이 있습니다.

다만 무통은 아닙니다. 몇몇 기능이 빠지고 추가 설정도 필요합니다. 동료가 Windows 11 오른쪽 클릭 메뉴 쪽에서 겪은 기록을 써 뒀으니, 넣을 거라면 먼저 읽어 보기를 권합니다.

다만 이 목록의 유통기한은 짧다#

위에 든 결함들에 대해 저는 그다지 걱정하지 않습니다. 이유는 시간축입니다.

Zed가 오픈소스가 된 지 아직 몇 년 되지 않았고, 1.0은 2026년 4월 29일에 막 나왔습니다. 오 년의 개발, 백만 줄이 넘는 Rust. 지금은 거의 매주 새 버전이 나오고 있고, 이 글을 쓰는 도중에도 "찾아봤을 때는 없다고 되어 있었는데 실제로 열어 보니 있더라"에 두 번 부딪혔습니다. 설정 GUI가 한 번, Terminal Threads가 또 한 번. Dev Container도 올해 1월에 추가된 것입니다.

그만큼 빠르게 움직일 수 있는 이유는 토대에 있습니다. Zed 팀은 1.0 글에서 그 경위를 분명히 적어 뒀습니다.

Atom은 Chromium의 fork였고 그 과정에서 Electron을 낳았으며, Electron은 훗날 VS Code의 토대가 됐다. 웹 기술은 출시를 쉽게 했지만 동시에 천장도 세웠다 —— 아무리 노력해도 Atom을, 그것이 올라탄 플랫폼보다 좋게 만들 수는 없었다.

그래서 그들은 다시 시작했고, 에디터 전체를 비디오 게임처럼 썼습니다. 데이터를 GPU 위의 셰이더로 흘려보내고, UI 프레임워크 GPUI도 직접 처음부터 깎았습니다. 앞의 "4 GB 대 200 MB"는 최적화로 깎아 낸 숫자가 아니라 처음부터 그 짐을 지지 않았다는 얘기일 뿐입니다.

Rust 개발자에게 특히 친절하다#

여기는 사견입니다. 제가 Rust를 쓰기 때문에 넣었습니다.

Zed는 그 자체가 Rust로 쓰여 있고 팀은 자기 제품의 헤비 유저이기도 합니다. 다만 분명히 해 두면, 아래는 Rust 전용 작업이 아니라 LSP 경로 전체에 대한 공학입니다. rust-analyzer가 무겁기로 유명해서 마침 가장 덕을 볼 뿐입니다.

그래서 결론은 정확히 이렇게 말해야 합니다. rust-analyzer는 빨라지지 않았고 메모리도 여전히 먹습니다. 바뀐 건 그 옆에 있는 에디터가 추가 부담이 아니게 됐다는 것이고, 원격 개발에서는 그게 차이의 전부가 됩니다.

만물은 Rust여도 좋습니다. 이번에는 이견 없습니다.

VS Code를 지우지는 않았습니다#

여기까지 쓰면 판촉처럼 읽히니 분명히 말해 두겠습니다. 이 글은 확실히 Zed 쪽으로 기울어 있습니다. 그 리소스 숫자가 너무 설득력 있고, 실제로 써 봐도 정말 쾌적하기 때문입니다.

다만 둘 다 남겨 두고 상황에 따라 나눕니다.

• 집에서 LAN을 통할 때 —— VS Code Remote-SSH. 같은 세그먼트라 지연이 낮고, 확장도 익숙한 UI도 그대로. 게다가 머신 바로 옆에 있으니 타기 시작해도 보이고 멈출 수 있습니다.
• 밖에서 장시간 접속할 때 —— Zed와 Claude CLI. 원격 지연은 VS Code를 꽤 쓰기 어렵게 만들고, 앞 글에서 서버를 96°C까지 태운 세 범인은 전부 "접속해 있는 동안 알아서 타오르는" 유형입니다. 현장에 없는 것이 최악의 상황이 됩니다.

이렇게 나누는 건 이 두 도구의 비용 구조가 다르고, 저에게는 마침 성질이 다른 두 가지 사용 방식이 있기 때문입니다.

옮겨야 하는지에 대한 제 견해는 이렇습니다. VS Code에 깊이 묶여 있지 않다면 장벽은 기능이 아니라 습관입니다. 저는 헤비 유저가 아니고 특정 확장에 의존하는 워크플로도 없어서 이사가 거의 아프지 않았습니다. 다만 매일 File Nesting을 쓰고, 데이터베이스를 열고, 프로젝트마다 설정을 세세히 바꾸는 —— 그런 사용 방식이라면 지금의 Zed는 아직 받아 주지 못합니다.

이 이사의 가장 큰 수확을 꼽으라면 아낀 몇 GB가 아닙니다. 확장 23개를 전부 다시 훑어보게 강제당한 것입니다. 그중 다섯은 Python 생태계가 중복해서 쌓인 것이었고, 둘은 같은 확장의 다른 버전이 치워지지 않고 남은 것이었으며, 몇 개는 왜 넣었는지조차 기억나지 않았습니다. 이 재고 조사는 평소에는 하지 않습니다. 도구를 바꿀 때만 강제로 하게 됩니다.