Hacker News 의견
  • Zed가 추구하는 방향은 마음에 들지만, 기본 편집 기능의 안정성이 부족한 점이 답답함
    외부에서 파일을 수정하면 프로젝트 창이나 git diff에 반영되지 않고, 컨테이너 환경에서는 AI 기능이 깨짐
    ACP도 멋져 보이지만 실제로는 대부분의 CLI보다 불편함
    지금은 다시 NeoVIM으로 돌아감. Zed가 안정화되면 다시 시도해볼 생각임
    관련 이슈: github.com/zed-industries/zed/issues/38109

    • “컨테이너에서 작업해야 한다”는 말에 공감함. Nix를 농담 삼아 언급하지만, 실제로 컨테이너 기반 개발은 여전히 어색한 워크플로우
      2025년인 지금은 시스템 오염 없이 재현 가능한 툴체인을 구성할 다른 방법도 많음
    • 1.0 릴리스가 2026년 봄으로 예정되어 있다 하니, 그때쯤 다시 확인해볼 계획임
    • AI 관련 기능은 너무 일찍 투자한 느낌임
      예전 Agentic editing 데모는 흥미로웠지만, 지금은 CLI 도구들이 훨씬 효율적임
      나는 주로 Claude code - plan mode로 작업 후 에디터에서 수정함. AI 통합 여부는 이제 큰 의미가 없음
    • 사소하지만 1440p 화면에서 글자가 흐릿하게 보이는 문제가 가장 거슬림
    • 줄바꿈(line wrap) 을 끌 수 없는 게 불만임. 설정이 작동하지 않고, 코드 상에 하드 리밋이 있음
      큰 로그 파일을 볼 때 매우 불편함. 에디터라면 편집 기능이 최우선이어야 함
      그래도 전역 검색 결과를 바로 수정할 수 있는 점은 좋음
      관련 토론: github.com/zed-industries/zed/discussions/26344
  • 협업 기능을 꼭 써보고 싶지만, self-host가 가능해야 함
    프로젝트 데이터가 Zed 서버를 거친다면 기업 환경에서는 SLA 없이는 허용되지 않을 것 같음

  • IDE에 커뮤니케이션 도구나 멀티플레이 기능이 들어가는 건 원치 않음
    집중을 위해 사용하는 공간인데, 주의 분산 요소를 들여오는 건 싫음

    • 나도 흥미롭진 않지만, 어쩔 수 없이 써야 한다면 잘 작동하는 협업 기능은 필요함
      다른 원격 페어 프로그래밍 도구보다 Zed의 품질이 낫다고 느낌
      IDE 선택 기준은 완벽함보다 확장성과 유연성
    • 협업 패널을 하단 바에서 제거했더니 깔끔해짐. 추천함
    • 이런 기능은 IDE 본질에서 벗어난 불필요한 산만함처럼 느껴짐
      페어 프로그래밍은 거의 안 하고, 심각한 버그 때만 공유가 필요했음
  • Zed Pro를 구독 중이며, 통합 에이전트 기능이 마음에 듦
    하지만 소규모 팀에서는 Zed 팀이 추구하는 “도구를 만드는 도구” 방향이 꼭 필요하진 않음
    내가 원하는 건 가볍고 빠른 코드 탐색·이해·수정 경험
    Swift나 Kotlin 지원보다, 디렉터리 패널과 아웃라인 패널을 동시에 볼 수 있는 UI가 더 절실함

    • 사실 이건 이미 가능함. 패널을 오른쪽 도크로 옮기면 됨
  • 회사가 통제하는 클라우드 기반 코드 에디터는 불안함
    특히 Zoom, Slack 같은 협업 도구가 통합된 형태는 더 꺼려짐

    • 하지만 선택은 자유임. Zed, IntelliJ, VSCode 등 다양한 선택지가 있고
      모든 상용 IDE를 거부하는 건 소수 의견일 것임
  • Atom의 성능 문제를 Electron 탓으로 돌리는 건 책임 회피처럼 보임
    VSCode도 Electron 기반이지만 훨씬 빠름. 브라우저도 마찬가지임

    • Atom은 Emacs처럼 확장성이 높았고, VSCode는 제한된 API만 제공함
      그래서 성능 차이가 생김
    • Zed는 Rust로 작성된 네이티브 앱이라 Electron보다 훨씬 빠름
      웹 기술은 훌륭하지만, 성능 면에서는 한계가 분명함
  • Zed의 대규모 협업 기능은 흥미롭지만, 실시간 집단 코딩은 상상만 해도 부담스러움

    • 주니어 교육이나 코드 리뷰에는 유용할 수 있음
      즉각적인 피드백과 생산성 자극 효과가 있을 수 있음
      단, 조직이 강제로 요구하지 않는다면 새로운 패러다임으로 발전 가능성 있음
    • 페어 프로그래밍이나 코드 워크스루에는 좋을 듯함
      화면 공유보다 훨씬 효율적임
    • 코드를 예술처럼 다루는 장인정신이 필요하다는 농담 섞인 의견도 있음
    • 혼돈을 받아들이자는 시각도 있음
      버전 관리 없이 실시간으로 수정 가능한 환경을 상상함
      Feature Toggle핫스왑 배포를 통해 빠른 피드백 루프를 만들 수 있음
      관련 글: martinfowler.com/articles/feature-toggles.html
    • 결국 이건 페어 프로그래밍의 확장판일 뿐임. 개인적으로는 싫음
  • 기능은 흥미롭지만, 실제로 쓸 일은 많지 않음
    예전에 PabloDraw로 여러 사람이 동시에 ANSI 아트를 만들던 경험이 떠오름
    VSCode의 협업 기능도 써봤지만, 회사 정책상 self-host 제약이 많음

  • 협업 서버가 LSP처럼 표준화되어 여러 IDE에서 호환되면 좋겠음
    VSCode 사용자와도 함께 작업할 수 있기를 바람

    • 나도 같은 생각임. 대부분의 협업 도구는 같은 에디터를 써야 해서 활용도가 낮음
      Zed 팀은 내부적으로 문제를 느끼지 않겠지만, 이종 에디터 간 호환성이 필요함
    • 사실 이런 기능은 20년 전 SubEthaEdit에서도 가능했음. Coda 2, TextMate와도 연동됐음
  • 예전 Atom의 teletype 패키지를 기억하는 사람이라면, 협업 편집의 역사를 떠올릴 것임
    2000년대 초 HydraSubEthaEdit이 그 시초였음
    이번엔 조직 단위의 공유가 “새로운 해금” 포인트로 보임
    관련 링크: SubEthaEdit 위키, Apple Design Awards 2003

    • 사실 협업 편집은 1960년대부터 존재했음.
      “The Mother of All Demos”에서도 소개됨
      최근에는 CRDTs 기술이 성숙하면서 실시간 협업이 훨씬 안정적이 됨
      참고: The Mother of All Demos, Zed 블로그의 CRDT 글
    • SubEthaEdit은 소규모 팀이 짧은 기간에 실제 문제를 해결한 대표적 사례였음
      지금은 그런 “낮은 난이도의 혁신” 기회가 점점 줄어드는 느낌임
      Zed의 시도는 멋지지만, 차세대 에디터를 만드는 데 필요한 개발 리소스가 훨씬 커졌음
    • 2004년쯤 국제 협업에 SubEthaEdit을 썼던 기억이 있음
      지금도 무료 앱으로 남아 있는 게 반갑음