▲

Zed 디버거, 드디어 출시

 (zed.dev)
5P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • 2,000명 이상의 개발자가 요청한 디버깅 기능이 마침내 Zed에 구현됨
  • 속도, 익숙함, 구성 가능성을 중심으로 디버거가 설계됨
  • Rust, C/C++, JavaScript, Go, Python 등 인기 언어와 Debug Adapter Protocol (DAP) 기반 확장 지원이 제공됨
  • 직관적인 LOCATORS 시스템으로 별도의 설정 없이 대부분의 프로젝트에서 간편하게 디버깅 가능함
  • UI와 데이터 레이어의 분리된 아키텍처로 협업 디버깅 및 확장성에 뛰어난 기반이 마련됨

Zed 디버거 출시

  • 2,000명 이상의 개발자들의 요청에 따라 Zed 에디터에 공식적인 디버깅 기능이 도입됨. 이는 Zed 1.0으로 나아가기 위한 매우 중요한 진전

주요 목표

  • 속도: 빠른 환경 전환과 효율적인 디버깅 경험 제공
  • 익숙함: Zed의 디자인 언어와 조화를 이루며, 전형적인 디버거 흐름에 기대되는 모든 기능 지원
  • 구성 가능성: UI, 키 바인딩, 디버그 설정 등 사용자가 자유롭게 맞춤 설정 가능

언어 및 확장 지원

  • Rust, C/C++, JavaScript, Go, Python 등 주요 언어를 기본적으로 지원함
  • Debug Adapter Protocol (DAP) 을 구현한 모든 디버그 어댑터와 연동 가능
  • 확장 시스템을 통해 보다 다양한 언어 및 디버깅 기능을 손쉽게 추가할 수 있음

간편한 디버깅 설정

  • LOCATORS라는 새로운 시스템을 도입하여 빌드 설정을 디버그 설정으로 변환함
    • 한 번 tasks.json에서 빌드 태스크를 작성한 뒤, debug.json에서 참조하거나, Zed의 자동 설정 기능을 활용할 수 있음
  • Zed가 내장 또는 Language Server의 실행 가능한 파일에서 자동으로 locators를 실행함
  • 대부분의 경우 별도의 디버그 설정 없이 바로 사용 가능함
  • 현재 Cargo, Python, JavaScript, Go에 대한 locator 지원 제공 (추가 언어 예정)

디버깅 세션의 기능

  • Zed 내에서 스레드, 변수, 브레이크포인트, 콜스택 등 프로그램 상태를 쉽게 확인 가능
  • 디버거 패널은 완전히 사용자화 할 수 있어서, 탭을 드래그·정렬하거나 패널을 자유롭게 이동 가능
  • 키보드 중심의 디버깅도 지원하여, 마우스 없이 코드 탐색, 브레이크포인트 토글, 세션 이동 가능

확장성 높은 아키텍처

  • 다양한 언어 디버깅, 협업 환경, 확장 지원, 효율적 데이터 캐싱 및 관리가 가능한 구조를 위해 2계층 아키텍처를 설계함
    • 데이터 레이어: 디버그 어댑터와 직접 통신, 세션 상태 유지, 응답 캐싱, 오래된 데이터 무효화 관리 담당
    • UI 레이어: 필요한 데이터만 요청, 인터페이스 렌더링에 주력
  • 이 분리 덕분에 협업(멀티플레이어) 디버깅 기능 구현이 용이하고, 네트워크 대역폭 절약 효과도 높음

확장 API와 DAP 적용

  • 70개 이상의 다양한 DAP 구현체가 존재하여, 모든 것을 기본 지원하는 대신 Zed의 확장 API를 확장하여 디버거 통합을 가능하게 함
  • 직접 스키마 정의, 어댑터 다운로드 및 실행 로직 구현, 디버그 설정 기본값 주입, locator와 자동 연동 등으로 DAP 지원 확장 가능
  • LSP(언어 서버 프로토콜) 확장 방식과 유사하게, 개발자가 자신만의 디버그 어댑터를 Zed에 손쉽게 통합 가능

인라인 변수 값 지원

  • 인라인 변수 값 표시 기능은 DAP가 아니라 LSP에 속해, DAP와 LSP가 모두 연계된 경우에만 기존 방식으로 제공 가능
  • 정규표현식 등 단순 매칭은 스코프, 주석 등의 이슈로 정확도가 떨어짐
  • Tree-sitter를 활용하여, 실행 중인 코드의 스코프 내 변수 식별이 정교하게 이루어짐
    • 별도의 LSP 연동 없이 .scm 파일을 통한 언어별 지원 가능
    • 출시 시점에 Python, Rust, Go 지원, 추후 더 많은 언어 추가 예정
  • Zed는 Tree-sitter의 창시자들이 만든 에디터임

향후 계획

  • 새로운 뷰: 워치 리스트, 메모리 뷰, 디스어셈블리 뷰, 스택 트레이스 등 고급 기능 추가 예정
  • 자동 설정: 더 많은 언어와 빌드 시스템에 대한 자동 설정 지원 확대 목표
  • 다듬기와 확장: Discord, GitHub 등을 통해 피드백을 받고, 적극적인 개선 의지 보유

부록

  • macOS, Linux에서 Zed를 사용할 수 있음
  • 개발자 채용 중 (관심 있으면 공식 사이트 참고)
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • 디버거에 대한 작업이 진행 중인 것을 보니 정말 기쁜 감정임. 이 기능이야말로 내가 완전히 zed로 전환하지 못하게 막는 주된 기능임. 다만, “여기”라고 말하기에는 아직 부족함이 있음. 워치 윈도우, 스택 트레이스 뷰 부재 그리고 데이터 브레이크포인트 언급이 없는 점이 아쉽고, 이 때문에 베타 단계로 간주함. 해당 기능들이 언젠가 추가될 것이란 사실은 알고 있지만, 지금 제공되는 것은 내 디버깅 세션의 97%를 감당하기에는 충분하지 않음. 동시에 여러 디버깅 세션 지원, 멀티스레드 디버깅 계획이 발표에 더 명확하게 언급되었으면 좋겠음. 특히 RemedyBG처럼 특정 스레드를 ‘프리즈’하거나 하나만 ‘솔로’로 돌리는 등 멀티스레드 디버깅에서 쿨한 아이디어들도 궁금함

    • Laserbeam 님 안녕하세요, 저는 디버거를 개발했고 해당 글을 작성한 개발자임. 기본적인 스택 트레이스 뷰는 이미 지원하고 있음. 곧 멀티 버퍼 시스템 내에서 스택 트레이스 뷰가 도입될 예정이고, 현재도 디버깅 세션 중 “show stack trace” 액션으로 멀티 버퍼에 콜스택을 확장해서 각 프레임을 볼 수 있음. 다만, Zed 기준의 높은 품질에는 아직 못 미쳐 공개적으로 어필을 안 한 상태임. 워치 변수/식 기능 PR도 며칠 안에 머지될 예정임. 기능 완성은 됐지만, 출시에 임박해서 충분히 테스트되지 않은 기능을 넣는 것이 조심스러웠음. 데이터 브레이크포인트는 중요한 우선순위지만, 한동안 자동 설정 쪽에 집중할 계획이라 정확한 일정 안내는 어려움. 여러 세션과 멀티스레드 디버깅도 동시에 지원 중이며, 보완할 점은 남아있지만 기본 지원은 됨

    • 블로그 포스트에 고급 뷰가 개발 중임이 언급되어 있음. 이번 첫 출시와 발표는 기반을 다지는 데 초점이 맞춰져 있음. 앞으로 워치 리스트, 메모리 뷰, 디스어셈블리 뷰, 스택 트레이스 뷰 같은 고급 뷰가 추가될 예정임 [관련 링크]

    • 내 디버깅 세션은 항상 일반 브레이크포인트와 스테핑만으로 진행됨. 그래서 내 입장에서는 충분한 수준임

    • 나도 동의하는데, Zed 팀이 개발하는 속도를 보면 이런 기능들이 곧 따라올 듯한 예감임

    • 디버거는 아직 써보지 않았지만, 내 경우 Git 기능 때문에 비슷한 감정을 느낌. Zed에서 기본적인 Git 기능은 있지만 내 기존 워크플로 전체를 대체하기엔 아직 부족함. Git 쪽 개발도 계속 집중해주길 바라는 입장임

  • Zed는 정말 괜찮은 에디터임. 최근에 neovim에서 zed로 넘어가고 있는데 만족도가 높음. 모든 동작이 매우 빠르고 vim 바인딩도 잘 통합되어 있음. 에이전트 모드도 편리한 점임. VSCode에 비해 확장 생태계는 아직 부족하지만 내가 필요로 한 많은 작업은 충분히 커버됨. 디버거가 그동안 큰 결핍이었는데 이제 추가되어 정말 반가움

    • vim 바인딩이 얼마나 진짜 vim 느낌인지 궁금함. 대부분의 vim 에뮬레이터는 충분히 비슷하지만 오히려 너무 애매해서 키 입력이 자주 잘못되고 그게 더 답답함. 차라리 vim 느낌이 전혀 없는 에디터가 손가락이 계속 ‘틀리는’게 덜 짜증난다는 경험이 있음

    • Rust 코드 자동완성은 Zed에서 어떤지 궁금함. Windsurf나 Cursor처럼 “tab-tab-tab”으로 모든 것이 자연스럽게 자동완성되는 마법같은 환경이 있다면 정말 좋겠음. 특히 TypeScript나 스크립트 언어에서는 이런 방식의 자동완성이 거의 리팩토링 자동화라 할만큼 잘 작동함. IntelliJ/RustRover는 JetBrains 모델이나 Co-pilot을 써도 Cursor나 Windsurf 수준을 따라가지 못했음. Rust 자체 특성 때문이라고 생각함. 1) Rust에서도 그런 자연스러운 자동완성이 가능해졌는지, 그리고 Zed에서 되는지 궁금함. 2) Zed와 Cursor, Windsurf와 비교해서, 또 RustRover 및 JetBrains가 Rust AST를 다루는 방식과 비교해서 어떤 느낌인지 궁금함

  • Zed는 Lapce, Helix, Neovim이 그동안 이루지 못했던 것을 실현하는 느낌임. 2021~2022년쯤 Helix를 썼을 땐 버그나 통합 부족 때문에 결국 포기했고, 특히 예전 회사에서 쓰던 PHP 지원이 거의 없었음. Neovim은 제일 편했지만 유명한 커뮤니티 플러그인 중 강경한 스타일이 많았고 대안 플러그인은 너무 느림. 뭔가 안정적인 환경을 갖추기 위해 너무 많은 선택지를 고민해야해서 힘들었음. Lapce는 그냥 “VSCode 복제판” 같았고, 뭐가 특별한지 못 느꼈음. 아직도 데일리 드라이버로 쓸 수준이 아니라는 생각임. 그런 점에서 Zed는 짧은 시간 내 최고 애디터가 되었고, 요즘 매일 감사한 감정임. 디버거 추가도 정말 반가움

    • PHP 지원에 (예전 회사라서)라는 설명은 굳이 필요없음

    • “VSCode 복제판”이라 평가하는 것도 흥미로운 관점임. 인류 역사상 가장 인기 많은 에디터에 대한 재밌는 해석임

  • Zed가 점점 완성도 높은, 가볍고 여러 기능을 가진 IDE로 발전해가는 모습에 감탄하는 상황임. 내 생각에 DAP와 LSP는 지난 10년간 프로그래밍 도구에 일어난 최고의 혁신임

  • 처음에는 Zed에 관심이 있었지만, “AI”가 통합되기 시작하면서 흥미가 사라진 입장임. “AI”가 너무 많아져서 지친 시점임. 뭔가 더 괜찮은 게 나올 때까지는 Neovim을 계속 쓸 계획이고, 이런 변화는 “AI 버블”이 터진 뒤에야 올 것 같음

    • Zed는 내가 처음으로 AI 기능을 써보고 싶게 만든 에디터임. 전반적으로 탄탄한 기본기를 느꼈고 AI 느낌도 다른 에디터에서의 자동완성 정도로만 존재함. “당신이 원하는 건 AI가 아닌 좋은 빠른 에디터다, 우리는 그걸 만들었고 AI 기능도 넣었다”는 태도가 느껴짐. 경쟁사들은 “우린 AI가 메인이고 에디터는 그냥 곁들임” 같은 느낌인데, Zed는 중심이 다름

    • neovim을 찾아보니 두 개의 AI 제품에게 후원까지 받고 있어서 놀람. 직접 AI를 통합하는 수준은 아니지만, 이제 아예 피하기도 점점 힘든 상황임

    • 난 그냥 AI 관련 옵션을 모두 꺼 두고 사용함. 꽤 괜찮은 에디터임. 여전히 머지 컨플릭트 해결은 VSCode로 들어가야 하는 상태지만 만족함

    • Zed의 AI 기능이 실제로 얼마나 침습적인지, 설정으로 비활성화가능한지 궁금함

    • 평소 Zed를 쓸 때 AI 기능이 전혀 거슬리지 않음. 가끔 유용하게 쓰긴 하지만 자주 사용하지는 않음

  • 리눅스 지원이 나온 이후로 매번 일반 디스플레이(LoDPI) 지원이 생겼는지 확인하는 중임. 아직도 지원이 안 되어 아쉬운 감정임

    • 정말 답답한 상황임. 텍스트 렌더링이 코드 에디터의 기본인데 Zed 팀에서 일반(non-retina) 스크린을 쓰는 사람이 없는 것 같음. 관련 깃허브 이슈 링크

    • 임시방편이지만 BetterDisplay(무료 도구)를 설치하고 LoDPI 화면을 HiDPI로 바꾸면 텍스트 렌더링이 괜찮아짐

    • 리눅스의 1920x1200 노트북 화면에서 매일 사용하고 있는데 전혀 이상 없음

    • Windows 지원도 없고, 리눅스에서도 일반 스크린 미지원이라면 사실상 Mac 중심의 회사가 아닌지 궁금함

  • 현재 Python 프로젝트에서 Pyright를 쓸 때 Cursor 대신 Zed로 옮기고 싶은데 배터리 사용량이 너무 높아 정당화할 수 없는 수준임. 이 이슈가 이미 깃허브에 있고, 팀에서 우선순위를 높이지 않아 매우 아쉬움

    • 나는 오히려 Cursor에서 몇 시간 열어두면 맥북 M3 Max가 뜨거워지고 팬이 돌며 CPU를 거의 다 점유하는 문제가 발생함. 반면 Zed는 아무 문제 없이 잘 동작함. 결국 기술 스택이 조금만 달라도 사용 경험이 극과 극으로 갈린다는 점이 흥미로움

  • Zed가 진짜 제품 개발의 예시라고 생각함. 또 다른 크롬 엔진 재포장이 아니라서 정말 만족스러운 선택지임

  • 솔직히 느린 부분이 있어서 놀람. 탭 목록에서 파일 전환 시 딜레이가 있고, 타이핑 반응도 Emacs(lsp-mode 활성화)나 웹 브라우저보다 느림. 메모리도 Emacs보다 60MiB 가량 더 씀. 대신 시작 속도는 정말 빠름. 단순히 ‘빠른 에디터’라는 슬로건과 달리 Emacs Lisp + C 코어보다도 느린 상황임. 플러그인 구조를 살펴보니 WASM으로 컴파일되어 VM에서 도는 형식인 것 같음. 그게 원인인지 궁금함

    • 어떻게 해서 emacs보다 zed가 더 느려졌는지 궁금함. 내 경험상 zed는 거의 지연이 없을 정도로 빠름. Edting, lsp, 파일스위칭 모두 즉각적임. 오히려 emacs는 지연 문제 때문에 결국 포기한 적이 많음(특히 원격 개발 환경에서)

    • 플러그인들이 WASM으로 VM에서 돌아서 느린 것 아니냐는 질문에, 내가 본 플러그인들은 서버 런칭 같은 것만 해주기 때문에 타이핑 반응과 직접 관련 없음. 오히려 GPU 사용이 원인일 것 같음. GPU 컴포지팅에서 딜레이 생기기 쉽고, 이미 OS단의 렌더링과 중첩될 수 있음. emacs도 이벤트 루프 건너뛰고 UI를 직접 갱신하는 트릭을 사용해 호환성 문제가 생겼던 기억 있음

    • emacs에는 dape 패키지라는 잘 설계된 DAP 기반 디버거가 있음. 관련 링크 의존성 없이 설계되어 차후 기본 emacs에 포함될 가능성이 있음

    • 렌더링 파이프라인의 이슈일 수도 있음. 사용하는 운영체제가 궁금함

  • zed 팀에게 부탁하고 싶은 점은 제대로 된 C와 C++ 언어 감지를 해달라는 점임. 모든 에디터가 C를 C++처럼 다루는 실수를 반복함(C는 C++와 다르며, 혼동하면 안 됨), compile_commands.json에서 C스탠다드 지정해도, C++ 문법 오류 코드인데도 C++로 인식하는 일이 많음. 언어 감지만 제대로 되면 매우 좋은 에디터임

    • 설정에서 파일명/경로 기준 언어 감지 규칙을 커스터마이즈할 수 있음. 다만 새 파일을 만들 때는 에디터가 언어를 추측해야 하는 상황임
답변달기