5P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • 코드 에디터 Zed가 이제 Windows에서 정식 출시됨
  • DirectX 11을 활용하여 렌더링, 텍스트 렌더링에는 DirectWrite를 사용해 Windows 특유의 시각 경험 구현
  • Windows Subsystem for Linux(WSL)과 직적 통합SSH 리모트 접속 지원으로 원격 개발 환경 강화
    • WSL 터미널에서 zed 명령어로 폴더를 바로 열 수 있음
    • Zed 내부에서도 File > Open Remote 또는 명령 팔레트에서 project: open remote 선택 후 원하는 WSL Distro 추가 지원
    • 리눅스 원격 서버 연결을 위해 Connect New Server 옵션 제공
    • WSL 또는 SSH 환경에서 파일 I/O 처리는 Zed의 경량 원격 서버 프로세스(wsl.exe/ssh.exe) 를 통해 이루어짐
    • 파일 편집, git 통합, 터미널, 태스크, 랭귀지 서버, 디버거 등 주요 기능이 원격 환경에서도 모두 작동함
  • 확장 프로그램 및 WebAssembly 통합
    • Windows용 확장 프로그램은 별도 추가 설정 없이 바로 사용 가능함
    • 새 확장 개발 시 Windows 특화 처리할 필요 없음
    • Zed 확장 프로그램은 WebAssembly Components 기반이며, WASI 인터페이스로 파일 시스템에 샌드박스 접근 가능
    • 파일 경로 변환 처리는 Zed가 자동으로 담당해 Windows와 Unix 경로 차이의 부담 없이 개발 가능
  • AI 기능 및 추가 사항
    • AI 기반 편집 예측ACP(Agent Client Protocol) 엔진 에이전트 등 Zed의 모든 AI 기능이 Windows 및 원격 환경(WSL/SSH)에서 완전히 지원됨
    • ACP를 통한 Claude Code 직접 활용 가능
    • Zed Pro 14일 무료 체험 혹은 개인 API 키 연동 사용 가능
  • Mac, Linux와 동일하게 Windows 버전도 매주 업데이트가 제공되며, 여러 Zed 엔지니어가 Windows를 주력 개발 환경으로 사용하며, Windows 전담 개발팀 상시 유지
Hacker News 의견
  • 기본적인 Windows OS의 키보드 단축키가 동작하지 않는 부분을 언급하고 싶음. 예를 들어 ALT+F로 파일 메뉴를 여는 기능이나 ALT+SPACEBAR로 시스템 컨텍스트 메뉴(최대화, 최소화, 닫기 메뉴 등)를 띄우는 것도 동작하지 않음. DirectX 렌더링 백엔드 특성상 애플리케이션이 네이티브 win32 프로세스보다는 비디오 게임처럼 렌더링되는 것 같음. 설치 후 디렉토리 용량이 400MB가 넘는 것도 놀랄 만함. VSCode가 380MB 정도임을 생각하면, Electron 앱이 아니라는 건 믿겠지만 무얼 이리 많이 넣었는지 궁금함. Rust 앱이 원래 가벼운 줄 알았으나, 설치 사이즈가 Java 수준의 바이너리/의존성 비대화에 근접한 느낌임
    • Rust의 Hello World 바이너리가 Git보다 큼. 그래도 Java나 Electron보다는 작지만, 딱히 작다고 할 수는 없음
    • PSPad는 40MB이고, 아직까지도 업데이트되는 레거시 소프트웨어임. Notepad++는 17MB임. 최신의, 컴파일된 최고의 Rust 프로젝트가 400MB를 차지한다는 건 말도 안 된다고 생각함
    • 400MB가 넘는 설치 용량의 비대함은 많은 사람들에게 불쾌감을 줄 수 있음. 이 용량이 왜 필요한지 빠르게 설명할 필요가 있음
    • Electron이 아니라고 해도, Electron의 절반인 Node.js가 기본적으로 포함된 느낌임. 대부분의 LSP가 .js 기반이고, 확장 기능이 WASM임. VSCode는 확장 기능을 별도의 설정 디렉토리에 두지만, Zed는 설치 디렉토리에 다 들어 있음
    • 참고로, 한 창에서 그래픽 컨텍스트와 Win32 메뉴바를 동시에 갖는 것도 가능함
  • Zed가 서브픽셀 폰트 렌더링을 구현했는지 궁금함. 예전에 UI 렌더러를 Mac의 HiDPI 디스플레이에 맞게 설계해서, LoDPI 디스플레이를 사용하는 리눅스(그리고 윈도우) 사용자는 흐릿한 폰트로 고통받았던 기억이 있음
    • 서브픽셀 렌더링은 모르겠지만, 최근 패치 이후 리눅스의 폰트 렌더링이 상당히 좋아졌음 관련 링크
    • 이 부분이 궁금함. Zed도 Mac에서는 CoreText, 윈도우에서는 DirectWrite를 사용하는 걸로 알고 있음. CoreText가 모든 걸 처리해주지 않나?
    • 윈도우 빌드는 DirectX 11로 렌더링하고, 텍스트는 DirectWrite로 처리해서 윈도우 감성을 살림. DirectWrite 폰트 렌더링이 윈도우의 서브픽셀 렌더링을 사용함. 내 모니터에서는 (리눅스보다) 괜찮아 보였음. 이런 문제를 미리 고려해 잘 설계한 것 같음
    • macOS에서 1440p 외부 모니터를 사용하는데, 폰트가 정말 끔찍했음. 랩탑의 Retina 디스플레이에선 괜찮은데 외부 모니터에선 너무 흐릿해서 두통이 올 정도였음
    • 나도 1440p 모니터에서 다양한 폰트로 테스트했는데 보통 수준임. 하지만 이건 Zed의 문제가 아니라 윈도우 자체의 폰트 렌더링이 원래 별로여서 그렇다고 생각함. VSCode도 마찬가지임. 고퀄리티 폰트 렌더링을 원하면 4K 이상의 화면이 정답인 것 같음
  • 수개월 동안 Zed를 주력으로 썼는데, 최근 다시 VSCode로 돌아옴. 이유는 둘인데, 하나는 내 실수고 하나는 어디에 문제가 있는지 확실치 않음. 1. 밤 늦게까지 코딩하다가 파일을 체크인 전에 이름을 바꾼 다음, 새 버전을 실수로 삭제해서 몇 시간치 작업을 날려버림. Zed의 우클릭 메뉴에 "Delete"와 "Trash"가 바로 붙어 있는데, Delete는 휴지통 통과 없이 바로 삭제됨. Ctrl+Z도 아직 구현 안 되어 있어서 백업 없으면 복구 불가임(버전 컨트롤에도 아직 안 올림). 2. Rust 워크스페이스에서 특정 crate의 에러·워닝 표시가 에디터에 전혀 안 나왔음. 이것저것 설정 만져보다가 안돼서 VSCode 켰더니 별다른 설정 없이 잘 됨
    • macOS 터치바 쓸 때 생각남. 커밋 관리 메뉴에서 "Cancel"이 "Force Push" 옆에 있었음
    • Zed에 Ctrl+Z가 안 된다는 점이 믿기 힘들 만큼 중요한 기능의 부재임
    • 이렇게 기본 기능이 없는 에디터를 어떻게 써야 하는지 의문임. 어떤 장점이 있는 건지 궁금함
  • Zed는 정말 멋지게 보이고 실제로 <i>느낌</i>도 끝내줌. 리눅스에서 잠깐 써 봤는데 이 에디터의 느낌은 직접 경험해보지 않으면 설명하기 힘듦. GPU 가속 에디터의 차별성을 쉽게 간과할 수 있는데, 직접 써보면 반드시 반하게 됨. 내가 Zed로 완전히 못 옮기는 유일한 이유는 아직 DevContainer 지원이 없기 때문임. devcontainer 설정을 엄청 공들여 세팅해놨기 때문에, 이걸 버리고 로컬에 툴과 라이브러리, 설정을 다 다시 설치하는 건 너무 후퇴로 느껴짐. 이 기능을 기다리는 사람이 많으니, 언젠가 지원될 것으로 기대함 관련 이슈
    • 커스텀 DevContainer에 대해 더 자세히 이야기해줄 수 있나 궁금함
    • DevContainer가 어떤 점에서 도움이 되는지 알고 싶음. 내 환경을 세세하게 문서화하긴 하겠지만, 그 이상 어떤 이점이 있는지 궁금함
    • devpods와 호환됨
  • 에디터의 메모리와 CPU 사용량이 내가 작업하던 웹앱 브라우저 탭보다 적다는 점이 정말 신선함. 지금까지 매우 만족함
    • zed가 lsp 실행에 node도 띄우니 확실히 확인하고 쓰는 게 좋음
    • 바이너리 크기가 0.5GB 수준이라, 브라우저처럼 특별히 가볍다는 느낌은 아님
  • Zed를 데일리 드라이버로 사용하려 했으나 TypeScript 경험이 기대 이하였음. 에디터 자체는 빠르지만 "jump to declaration"같은 LSP 액션이 우리 코드베이스에서는 VSCode/ Cursor 대비 매우 느렸음
    • typescript-go를 LSP로 지원하는지 확인해보길 추천함. IDEA에서 최근 추가됐고, 몇 개월간 써봤는데 정말 환상적임
    • 나도 같은 경험, 같은 결론임. Zed는 편집 속도는 빨랐지만 고급 기능들이 느려서, 결국 전체적으로 VSCode보다 체감 속도가 느렸음
    • 둘 다 tsserver를 내부적으로 쓰는 걸로 아는데, 왜 느린지 이해가 안 됨
    • Electron은 NodeJS를 v8 pointer compression과 함께 빌드해서 메모리 사용을 최대 50% 줄이고 속도도 올려줌
  • 괜찮지만, 나는 이미 리눅스로 넘어갔고 Zed도 그 환경에서 아주 잘 돌아가고 있음
[Window Title]
Critical

[Main Instruction]
Unsupported GPU

[Content]
Zed uses DirectX for rendering and requires a compatible GPU.

Currently you are using a software emulated GPU (Microsoft Basic Render Driver) which
will result in awful performance.

For troubleshooting see: https://zed.dev/docs/windows
Set ZED_ALLOW_EMULATED_GPU=1 env var to permanently override.

[Skip] [Troubleshoot and Quit]

아쉽게도 이런 이슈가 발생했음

  • 이건 사실 Zed의 문제가 아니라 시스템 이슈임. 요즘 DirectX 안 되는 환경 찾기 힘든데, 혹시 VM에서 윈도우 돌리는 중인지 궁금함
  • 텍스트 에디터가 소프트웨어 렌더링에서 도대체 무슨 짓을 하길래 "끔찍한 성능"까지 나오는지 궁금함
  • Zed는 정말 멋짐. 내가 원하는 건 다 할 수 있음. 필요한 걸 쉽게 찾을 수 있고, 정말 빠름. ACP 모드에서 IDE에서 CLI 터미널을 포크할 수도 있음. 이렇게 되면 Cerebras나 Qwen code 480b 같은 엄청 스마트한 CLI 에이전트를 저렴하고 강력하게 쓸 수 있음
  • 오래 기다렸는데 여전히 x86_64 바이너리만 있음. ARM Surface Pro를 정말 좋아해서, Zed가 이 하드웨어에서 돌아가면 정말 좋을 것 같음. Zed 팀에서 이 댓글을 보면 꼭 생각해줬으면 좋겠음
    • 나는 직접 소스 빌드해서 Windows aarch64에서 돌림. 16GB Surface Pro에서 빌드가 꽤 느리긴 해도 문제없이 잘 됨. 공식 바이너리도 기대함
    • 어떤 이유인지 모르지만, Windows에서 msvc로 zed를 빌드하면 리눅스에 비해 굉장히 느리게 느껴짐. 관련 이슈까지 열렸음