▲

Helix: 포스트모던 텍스트 에디터

 (helix-editor.com)
1P by GN⁺ 5시간전 | ★ favorite | 댓글 1개
  • Helix는 터미널 기반의 모달 텍스트 에디터로, 현대적 기능을 통합한 오픈소스 프로젝트
  • Tree-sitter 통합을 통해 구문 강조, 들여쓰기 계산, 코드 탐색 등 구문 인식 편집 기능을 제공
  • Language Server Protocol을 지원해 자동 완성, 정의 이동, 문서 보기, 진단 등 IDE 수준 기능을 구현
  • Rust로 작성되어 Electron이나 JavaScript 없이 작동하며, SSH·tmux·터미널 환경에서 효율적으로 사용 가능
  • 플러그인 시스템과 GUI 프론트엔드는 향후 개발 예정으로, 가벼운 코드베이스와 현대적 기본 설정을 특징으로 함

주요 특징

  • Helix는 Kakoune에서 영감을 받은 멀티 셀렉션 및 커서 시스템을 핵심 편집 단위로 사용
    • 명령이 여러 선택 영역을 동시에 조작해 병렬 코드 편집이 가능
  • Tree-sitter를 이용해 오류 허용 구문 트리를 생성
    • 이를 통해 정확한 구문 강조, 자동 들여쓰기, 코드 탐색 기능을 지원

코드 조작 및 탐색 기능

  • 함수, 클래스, 주석 등 구문 트리 노드 단위 선택 및 이동 기능 제공
    • 단순 텍스트가 아닌 구문 구조 기반 편집이 가능
  • 언어 서버 프로토콜(LSP) 을 통해 언어별 자동 완성, 정의 이동, 문서 보기, 진단 기능을 제공
    • 추가 설정 없이 IDE 수준의 기능을 터미널 환경에서 활용 가능

기술적 기반

  • Rust로 작성되어 안정성과 성능을 확보
    • Electron, VimScript, JavaScript를 사용하지 않음
    • SSH, tmux, 일반 터미널 환경에서 구동 가능
    • 경량 구조로 배터리 효율성 향상

내장 현대적 기능

  • 퍼지 파인더(fuzzy finder) 로 파일 및 심볼 탐색, 프로젝트 전역 검색 지원
  • 자동 괄호 닫기, surround 통합, 테마 커스터마이징 등 다양한 편의 기능 내장
  • 별도 플러그인 없이도 기본 기능이 풍부하게 통합된 구조

자주 묻는 질문

  • “포스트모던”이라는 표현은 Neovim이 ‘모던 Vim’이라면 Helix는 그 이후 세대라는 농담적 의미
  • GUI 프론트엔드는 향후 WebGPU 기반 프로토타입으로 개발 예정
  • 현재 플러그인 시스템은 미구현 상태이며, 향후 도입 계획 있음
  • Kakoune과의 차이는 Helix가 더 많은 기능을 내장하고, Tree-sitter 기반 코드 분석을 사용하는 점
  • Vim과 달리 Helix는 처음부터 새로 설계되어 코드베이스가 작고, 설정 파일 조정이 최소화된 현대적 기본값을 제공

커뮤니티 및 참여

  • GitHub에서 코드 기여 가능
  • Matrix 채널에서 프로젝트 토론 진행
  • OpenCollective를 통해 개발 후원 가능
▲
GN⁺ 5시간전  [-]
Hacker News 의견들

  • “Post-modern?!”이라는 농담을 보고 흥미로웠음
    많은 엔지니어들이 ‘postmodern’을 단순히 modern의 다음 단계로 이해하는데, 이는 예술·인문학에서의 본래 의미와는 다름
    물론 이런 용법이 큰 문제는 아니지만, 그래도 진짜 ‘포스트모던’한 창의성을 기대했기에 눈에 띄었음

    • Thiel과 Luckey가 Tolkien을 오해했다는 말이 있었는데, 구체적인 예시가 궁금함
    • Helix의 농담을 처음 봤을 때 나도 같은 생각을 했음
      하지만 ‘postmodernism’이 본래 modernism 이후의 반응으로 생긴 개념이라는 점에서, 단순히 “modern 다음”이라는 해석도 완전히 틀린 건 아니라고 봄
      다만 시간이 지나면서 그 의미가 훨씬 복잡해졌고, 지금은 “dated af”처럼 느껴지는 게 웃기기도 함
      “Helix, 거대 서사를 믿지 않는 첫 에디터. Helix, 상대주의적 에디터. Helix, Foucault와 Derrida 최신 업데이트 탑재”
    • 이 모든 건 Perl 탓임. 그들이 이런 식의 명명법을 시작했음

  • 몇 년째 Helix를 메인 에디터로 쓰고 있음 (Sublime → Atom → Vim → Helix)
    대부분의 LSP가 거의 설정 없이 작동하고, 설정 파일도 예전 .vimrc보다 훨씬 간결함
    Vim의 근육 기억을 바꾸는 데 며칠밖에 안 걸렸지만, 여전히 모달 에디터에 대한 복잡한 감정이 있음
    코드 폴딩 기능은 아직 기다리는 중임

    • Emacs와 Vim을 병행해 쓰는 입장에서, 모달 편집의 불편함이 궁금함
      Emacs에서는 multiple cursors와 treesitter 기반 플러그인을 써서 비모달 방식에서도 강력한 편집이 가능함
      혹시 비슷한 이유로 Helix의 모달 방식이 불편한지 궁금함
    • 내 불만은 여전히 Escape 키 때문임
      예전 Unix 키보드에서는 홈 로우 근처였지만 지금은 너무 멀리 있음
      대부분의 튜토리얼이 대체 키를 언급하지 않아서, 여전히 절반 이상의 사용자가 Escape를 그대로 쓰는 게 이해가 안 됨

  • 며칠 전 Helix를 다시 써봤는데, AI를 LSP를 통해서만 쓸 수 있는 점은 괜찮지만
    외부에서 파일이 바뀌어도 자동 새로고침이 안 되는 점이 너무 불편했음
    AI가 수정한 파일이 최신 상태인지 계속 걱정하게 됨

    • GitHub Copilot, Claude Code, Codex는 IDE API를 통해 파일을 직접 수정하고 diff 뷰도 제공함
      이런 방식이 훨씬 안정적이고 매력적임
      반면 일부 AI 툴은 “IDE는 필요 없다”며 CLI 중심으로 가는데, 그건 완전 헛소리라고 생각함
    • 완벽한 해결책은 아니지만 Helix에는 :reload와 :reload-all 명령이 있음
      나는 Ctrl-r에 reload-all을 바인딩해둠
    • 간단한 패치로 해결 가능함 → GitHub PR 링크
    • 나도 같은 문제를 겪다가 lazygit으로 파일 변경 감시를 하고, Helix로만 수정하는 워크플로로 바꿈
      또 다른 옵션은 mux인데, LLM이 제안한 변경사항을 라인·블록 단위로 코멘트할 수 있음 (아직 초기 버전)
    • 시간이 지나면서 오히려 자동 새로고침이 없는 게 편해졌음
      Claude Code로 작업할 때 파일이 자동으로 바뀌지 않는 게 마음에 듦

  • Vim은 C, Helix는 C++, Ki Editor는 Rust 같음
    Helix는 Vim의 아이디어를 많이 물려받았지만 키바인딩 일관성이 부족하고, 개념적 조합도 약함
    예를 들어 버퍼에서는 k로 이동하지만 파일 탐색기에서는 ctrl+n을 써야 함

    • Ki가 Rust 같은 이유가 궁금함. Helix도 충분히 멋진 에디터라고 생각함
    • Helix에 파일 탐색기가 생겼다는 말이 놀라움. 그게 없어서 안 썼었음
    • Vim에서도 비슷한 상황이 있음. 자동완성 창에서는 k가 입력 문자로 쓰이기 때문에 다른 키를 써야 함
      Helix도 같은 이유일 듯
    • 키 위치 기반 바인딩 개념이 납득이 안 됨
      SSH 접속 시 키보드 레이아웃이 다르면 어떻게 되는지 의문임
    • “Helix는 C++”이라는 말은 과장된 비유 같음. Vim이 C라면 Neovim이 C++에 더 가까움

  • Helix를 정말 좋아하고 싶었음
    기본 설정이 잘 되어 있고, 배우기 위해 Vim 습관을 일부러 버렸지만
    결국 키바인딩이 단순 구현을 위한 타협이라는 결론에 도달했음
    지금은 작은 수정엔 Neovim, 큰 작업엔 Zed(vim 모드)로 돌아감

    • Ki Editor를 써봤는지? UX 관점에서 Helix보다 진보된 모델임
    • 오랜 Vim 사용자로서 Helix의 지나친 의견 중심적 설계가 불편했음
      예를 들어, 파일을 다시 열면 이전 커서 위치로 돌아가지 않음
      LLM으로 수정은 가능했지만, 결국 Helix 포크를 유지보수하고 싶진 않았음
    • evil-helix라는 Vim 바인딩 버전도 있음. 시도해볼 만함
    • Vim과 다른 바인딩이 결국 포기하게 만든 이유였음
      수년간 쌓인 근육 기억을 버리는 일은 정말 힘듦
    • Helix UI가 단순하지 않다는 말에 동의하지 않음
      나는 hx + Zed 조합이 꽤 훌륭하다고 느낌

  • Helix가 라이브 파일 업데이트를 지원하지 않아서, 코드 에이전트와 함께 쓰기엔 불편함

  • Helix의 FAQ 두 번째 질문을 보라고 권함
    Python LSP가 설정 없이 바로 작동해서 인상 깊었음
    하지만 25년간 쌓인 Vim 근육 기억 때문에 Helix의 미묘한 차이가 너무 헷갈림
    결국 문제는 Helix가 아니라 내 근육 기억임

    • 인체공학 키보드를 오래 쓰다가 일반 키보드로 돌아가는 게 처음엔 힘들었지만, 결국 양쪽 모두 익숙해짐
      Vim과 Helix도 그렇게 될 수 있을 것 같음
    • Emacs에서는 M-ESC ESC를 무해한 명령으로 바인딩하면 창이 닫히는 문제를 피할 수 있음
      예: (global-set-key (kbd "M-ESC ESC") 'keyboard-quit)
    • Emacs의 Evil 모드를 써봤는지? Vim에서 거의 무리 없이 전환 가능했음
    • 나도 25년간 Vim을 썼지만, Helix로 완전히 넘어왔음
      dd, G 같은 차이만 익숙해지면 점점 좋아짐
    • Zed는 Helix 철학(LSP 기본 지원)을 유지하면서 정확한 vi 바인딩을 제공함

  • 지난 몇 년간 Helix를 기본 에디터로 사용 중임
    단순함, 속도, 키보드 중심 내비게이션, 그리고 Elixir LSP 통합이 특히 마음에 듦

  • Helix를 메인으로 쓰며 많은 코드를 배포했음
    설정 파일이 50줄도 안 되고, 일부 Vim 키만 추가했음
    Vim과 Helix를 오가도 큰 문제 없음
    내 설정은 여기에 있음

  • VS Code에서 직접 모달 모드 확장을 만들었는데, Kakoune과 Helix의 접근이 흥미로웠음
    “변경될 부분을 미리 보여주는” 구조와 멀티 커서 중심 설계가 합리적으로 느껴졌음
    하지만 몇 주 후엔 결국 고전적인 Vim 스타일로 되돌림
    멀티 커서 방식은 화면에 모든 변경점을 볼 수 있을 때만 유용했음
    요즘은 AI 덕분에 코드보다 문장 작성이 많아져서, 이런 편집 방식의 가치가 줄어든 느낌임

    • Emacs에는 mc-hide-unmatched-lines 명령이 있어서 커서가 있는 줄만 보이게 할 수 있음
      멀티 커서는 짧고 단순한 편집에는 좋지만, 복잡한 수정에는 배치 편집 도구가 더 효율적임
    • Ki Editor의 Reveal Cursors 기능은
      화면 밖 커서 문제를 해결하기 위해 만들어졌음
    • “모든 변경점을 한눈에 볼 수 있다”는 점만으로도 기존 방식보다 순이익이라고 생각함
답변달기