원격 서버 개발용 편집기로 Helix 에디터를 활용하는 방법

• 원격 서버 개발용 편집기로 Helix를 선택한 이유는 Vim/Neovim처럼 수십 개의 플러그인 설치 없이도 사용 가능하며, 공급망 공격 위험을 줄일 수 있기 때문
• tmux 연동 설정을 통해 Helix에서 부족한 파일 탐색기와 Git TUI 기능을 보완하고, yazi 파일 관리자, lazygit 등을 팝업으로 실행할 수 있게 구성
• Vim 스타일 키바인딩을 이식하여 줄 선택, 커서 이동, 텍스트 삭제 등의 작업을 Vim과 유사하게 동작하도록 설정하고, ESC로 멀티 커서를 초기화하도록 변경
• 상태 표시줄(statusline) 에 Git 브랜치, 인코딩, 포지션 등의 정보를 추가해 생산성을 높임
• Tree-sitter 인젝션을 활용해 Python/Go 내부의 SQL 쿼리, Markdown의 코드 블록 등을 문법 강조 처리하여 가독성 개선
• LSP, 자동 저장, 색상 모드 등 고급 설정을 활용해 작업 생산성 높이고 세밀하게 커스터마이즈

---

Helix 선택 배경

• 최근의 공급망 공격 증가와 플러그인 의존성 문제로 인해 Vim/Neovim 대신 Helix를 원격 서버 개발용 편집기로 채택
• Neovim의 수십 개 플러그인 없이도 기본 기능만으로 사용 가능한 점이 주요 장점
• Helix로 전환 이후, 익숙한 Neovim 경험을 최대한 재현하기 위해 설정 커스터마이징 작업을 진행하였음
• 이를 공유하여 다른 사용자의 시간 절약을 목표로 함

Tmux 설정

• 터미널 멀티플렉서로 Tmux를 사용하며, 파일 관리자와 Git TUI 부재를 해결하기 위해 커스텀 키바인딩 추가
• Helix는 파일 탐색기에서 파일 편집을 지원하지 않아, 여러 파일을 빠르게 이동할 때 불편함이 있었음
• Tmux 설정 파일에 다음 바인딩 추가
  • prefix - y: Yazi 파일 관리자를 팝업 창으로 실행 (화면의 95% 크기)
  • prefix - g: Lazygit을 팝업 창으로 실행
  • prefix - e: Tmux 출력 히스토리를 Helix 편집기로 열어 검색 및 복사 작업 수행
• 기본 prefix는 Ctrl + b이지만, Ctrl + \로 변경하여 사용 중
• 터미널 출력 작업에 유용하며, 특히 ClickHouse 클라이언트 출력(CSV/JSON)을 Slack으로 복사할 때 활용
  • 파일로 출력하는 대신 직접 복사가 가능하여 작업 단계 절감
  • 마우스로도 가능하지만 Tmux 버퍼 스크롤이 불편하여 편집기로 처리하는 것이 효율적
• Yazi와 Lazygit은 보통 Helix 편집기 위에 오버레이로 표시됨

Vim 키바인딩 이식

• Helix 키바인딩에 익숙해졌지만, 여전히 일부 Vim 바인딩을 이식하여 사용 중
• Select 모드 바인딩
  • 0: 줄 시작으로 이동
  • $: 줄 끝으로 이동
  • ^: 첫 번째 공백이 아닌 문자로 이동
  • G: 파일 끝으로 이동
  • D: 줄 끝까지 선택 후 삭제하고 노멀 모드로 전환
  • k/j: 위/아래 줄 전체 선택 (Helix 기본 동작은 부분 선택이라 불편함)
• Normal 모드 바인딩
  • D: 커서 오른쪽 텍스트 전체 삭제 (Helix는 키 입력이 너무 많아 이식)
  • V: Select 모드로 전환 후 줄 전체 선택
  • ESC: 다중 커서 리셋 (Helix 기본값은 쉼표인데 불편함)
• Helix의 비주얼 모드 줄 선택 방식이 마음에 들지 않아 Vim 스타일로 변경
  • 위/아래로 이동 시 전체 줄이 선택되도록 설정

개선된 상태바

• 기본 상태바에 현재 Git 브랜치 같은 중요 정보가 부족함
• 상태바 설정 구성
  • 왼쪽: 모드, 스피너, 버전 관리, 파일명, 읽기 전용 표시, 수정 표시
  • 중앙: 비어 있음
  • 오른쪽: 진단, 작업 공간 진단, 위치, 전체 줄 수, 위치 백분율, 파일 인코딩, 줄 끝 형식, 파일 타입, 레지스터, 선택 수
  • 구분자: │ 문자 사용
• 작업 상황을 한눈에 파악 가능

유용한 키바인딩

• 커스텀 키바인딩으로 작업 효율성 대폭 향상, 발견하는 데 시간이 걸렸음
• 가장 유용한 기능: 파일 리로드, 소프트 랩 토글, Git undo, Git blame, Git diff
• 전체 커스텀 바인딩 목록
  • space - e - w: 현재 버퍼를 파일로 저장
  • space - e - c: 현재 버퍼 닫기
  • space - e - x: 다른 버퍼 모두 닫기 (수십 개 버퍼 열려 있을 때 유용)
  • space - e - l: 인레이 타입 힌트 토글 (유용하지만 항상 표시하면 노이즈가 많음)
  • + - f: 현재 파일 포맷
  • + - w: 공백 문자 렌더링 (문서 내 보이지 않는 문자 확인용)
  • + - W: 공백 문자 렌더링 비활성화
  • space - f - .: 파일 피커에서 Git 무시 파일 표시/숨김
  • space - f - r: 모든 파일 리로드 (Helix가 자동 리로드를 지원하지 않아 매우 유용, 외부 변경이나 커밋 후 gutter 업데이트용)
  • space - f - x: 현재 커서의 Git 변경 사항 undo
  • space - f - w: 현재 줄의 Git blame 표시
  • space - f - d: Git diff 표시

편집기 설정

• 6개월 사용 후 터미널 탭 전환 시 자동 저장 기능이 있다는 것을 발견
• Helix의 일부 최신 기능은 기본적으로 비활성화되어 있어, 기존 사용자가 예상치 못한 변경을 겪지 않도록 배려
• 각 옵션을 직접 확인해야 새로운 기능 발견 가능
• 주요 설정 옵션
  • line-number = "relative": 상대 줄 번호 표시
  • rulers = [120]: 시각적 수직 눈금자 설정 (자동 포맷 없이 최대 줄 길이 제한 시 유용)
  • true-color = true: 트루 컬러 강제 지원
  • completion-replace = true: 자동 완성이 단어 전체를 대체
  • trim-trailing-whitespace = true: 후행 공백 제거
  • color-modes = true: 모드 표시를 색상으로 구분
  • rainbow-brackets = true: 중첩 괄호에 다른 색상 사용 (최신 기능, 아직 정식 릴리스 전)
  • editor.file-picker.hidden = false: 파일 피커에 숨김 파일(dot files) 표시
  • editor.indent-guides.render = true: 시각적 들여쓰기 가이드 추가
  • editor.inline-diagnostics.cursor-line = "warning": 진단 표시 개선 (스크린샷 참조)
  • editor.auto-save.focus-lost = true: 포커스 잃을 때 자동 저장 (터미널 지원 필요)
  • editor.auto-save.after-delay.enable = true: 지정된 지연 시간 후 자동 저장 (300초로 설정)

LSP 조정

• 모든 언어에 대해 harper-ls LSP를 추가하여 주석 내 문법 오류 강조 표시

커스텀 Tree-sitter 인젝션

• Helix는 커스텀 Tree-sitter 인젝션 지정을 허용하여, 한 언어 안에서 다른 언어를 강조 표시 가능
• 사용 사례
  • Python과 Go 내부의 SQL 쿼리 문법 강조
  • Markdown의 YAML front matter와 코드 블록 강조
  • HTML 스니펫 강조에도 활용 가능
• GitHub에 설정 파일 업로드하여 커스텀 인젝션과 설정 공유

• Helix는 플러그인 최소화, 보안성, 직관적 커스터마이징이라는 장점이 두드러진 차세대 터미널 에디터임

[xguru]

20년간 Vim을 사용해온 개발자가 Vim에서 Helix로 전환한 후기

[GN⁺]

Hacker News 의견

• 최근 에디터 설정을 다시 구축하는 작업을 하고 있음. 20년째 Emacs, 15년째 Vim을 병행 사용 중이고 둘 중 하나를 고를 수가 없음. 목표는 엔터프라이즈급 Python 소프트웨어 작업에 바로 쓸 수 있을 정도의 완성 세팅을 얼마나 빠르게 만들 수 있는지 알아보는 것임. 이번엔 특히 서드파티 확장에 대한 의존도를 최대한 줄이고 필요한 기능만 남길 수 있는지 시도 중임. 현재 내 Neovim 세팅은 내가 써본 것 중 최고치라 생각하지만, 예상보다 더 많은 플러그인을 쓰게 되었음. Emacs의 경우는 아직 초기 단계이지만, 30버전 이상에서 서드파티 플러그인 필요성이 크게 줄어들 정도로 많이 발전했다는 게 흥미로움. 예전엔 lsp-mode를 썼지만 지금은 Eglot에 만족하고 있음. completion preview mode도 corfu를 완전히 대체하진 않지만 꽤 괜찮은 수준임. 내 Emacs 필수 플러그인 리스트는 Magit, Expreg(teeesitter expand region), Multiple cursors, dape(Eglot과 연동한 디버깅)임. 아마도 Consult와 orderless도 추가할 것 같음. 내 Neovim 설정은 여기에서 볼 수 있음

  • 새로운 nvim은 플러그인 필요성도 점점 줄여주는 중임. 내장 플러그인 매니저, diff 뷰어, lsp가 다 제공됨

  • 꽤 많은 nvim 플러그인을 관리 중임! 나는 지난주에 nvim 세팅을 mini.nvim 포함 4개 플러그인으로 다시 썼음. 플러그인을 많이 붙이면 nvim 안정성과 신뢰성이 확 쳐지는 걸 느꼈음. Emacs에서는 2개만 필요하다니 부럽고, 확실히 그게 훨씬 안정적으로 동작할 것 같음. 내 세팅은 여기에서 볼 수 있음

  • 몇 달을 써본 뒤에도 Pycharm+IdeaVIM의 기본 제공 세팅과 비슷한 수준이 나온다고 생각하는지 궁금함. 물론 직접 설정을 만지는 재미도 있지만, IDE를 효율적으로 쓰는 목적에만 집중하면 Neovim 설정에 시간을 많이 들이는 게 좀 비효율적이지 않나 싶음

  • Expreg(teeesitter expand region)은 combobulate(아직 안 써봤지만 멋져 보임)를 떠올리게 함. 다만 Expreg가 훨씬 더 간단하고 가벼운 느낌임

  • 오래된 Emacs 사용자들 이야기 정말 궁금함. Helix/Vim과 비교하면 어떤지 알고 싶음. 처음 Helix/Vim 써봤다는 사람들은 좋다고 하는데, 오래 쓴 Emacs의 진가를 모르고 이야기하는 걸로 보임. 사실 Vim 스타일 키나 모드가 요즘 편집기에서는 더 잘 통합되는 건 같은데, 정작 써보면 내 손가락이 익숙해질 때까지 참는 인내가 부족했음. 진짜 hardcore Emacs 유저의 전환후기가 듣고 싶음

• 나는 Emacs → VS Code → Helix 순으로 갈아탄 입장임. 지금까지는 최대한 기존 키바인딩을 익히고, 설정을 거의 건드리지 않고 효과적으로 쓰려고 노력했음. Helix가 할 수 있는 모든 것을 외우는 게 힘들어서, 직접 키를 인쇄해 책상에 둘 데스크매트를 만들어봄. 실제로 프린트해서 써봐야 얼마나 도움이 되는지 알 수 있을 듯함. 내 책상매트는 여기에서 볼 수 있음

  • Emacs를 얼마나 오래 썼는지 궁금함

• 지난 10년간 Emacs를 주력으로 쓰고 있고, 그 전에는 Sublime Text를 썼음. 간단한 파일 편집이나 원격 서버에서는 가끔 Vim을 쓰긴 하는데, Vim만을 완전히 사용할 필요성은 못 느낌. Emacs에서 나만의 모듈과 함수들을 만들어서 딱 맞는 환경을 썼음. 지난 달 Helix를 써봤는데, 시작하기가 놀랄 정도로 심플했음. 기본적인 사용법—이동, 검색, 붙여넣기, 버퍼/윈도우 전환—도 빨리 적응했음. Helix의 역사에 대해선 잘 모르지만 아주 훌륭한 디자인임. 글로벌 서치가 특히 좋고, lsp 연동도 딱 맞게 동작하고, 속도가 정말 빠름. 기본값이 일관성 있고 쓸모있게 잘 정해져 있다는 느낌이 정말 쾌적함. 앞으로 더 익숙해지려고 꾸준히 쓸 계획이고, 기본 편집기는 Emacs이지만, Helix가 너무 빨라서 코딩 편집용으로는 메인 에디터가 될 수 있을 것 같음

• Helix를 처음 써보고 있는데, 두 가지 단점이 크게 느껴짐

  • 모달 편집이 핵심인데 Vim은 기존의 muscle memory를 어디서든 그대로 쓸 수 있음 (Vim 모드는 거의 모든 곳에 쓰이고, Vimium 같은 확장도 많고, ssh 환경이면 거의 무조건 Vim 있음)
  • Helix는 단순함을 지향해 터미널 통합이 없고, 플러그인 확장성도 높지 않은데 (lint기능도 lsp기반만 지원), 이런 조합은 에디터 위에 따로 셋업을 만들어야 한다는 뜻이라 한계로 보임(tmux 등 활용 필요) 단점을 비난하려는 것이 아니라, 이런 점을 상쇄할 만큼의 강점이 뭔지 궁금함

  • LSP가 단점이 되는 이유가 뭔지 잘 모르겠음. LSP가 별도 프로세스로 동작한다는 느낌인데 오히려 플러그인 샌드박스화에 좋다고 생각함. 실제로는 오히려 전통 편집기 플러그인보다 더 잘 동작할 수도 있을 듯함. tmux 통합이 없는 것도 Emacs를 주로 쓰지만 나는 내부 터미널을 거의 안 써서 못 느꼈고, muscle memory만 이사하면 빠른 rust로 만든 편집기라면 충분히 설득력 있음

  • Vim 모션은 muscle memory로 익혀서 어디서든 쓸 수 있다는 주장이 있는데, 실제로 기본 Vim 환경을 플러그인/설정 없이 그대로 쓰고 싶어하는 개발자는 거의 없음. 대부분은 자신만의 셋업과 기능을 세밀하게 맞춘 에디터를 원함. 예외는 진짜 여러 대 머신에 ssh 접속하며 기본 에디터 환경이 꼭 필요한 사람 정도임. Helix의 단순성과 플러그인 제한성에 대해 언급했는데, 원래 Helix는 올인원 에디터를 지향했으나 커뮤니티에서 원하지 않아서 플러그인 시스템이 개발 중임. 메인 릴리즈엔 미포함이지만 별도 브랜치에서 이미 여러 플러그인이 만들어지고 활용 중임. 플러그인 시스템이 충분히 안정되기 전까지 릴리즈를 미루는 것이 옳은 선택이라 생각함. Helix의 가장 큰 장점은 vi/vim/neovim에 남아 있는 불편한 UX를 개선했다는 점임. 즉, 작업 순서를 바꿔 커밋 전에 바뀐 내용을 쉽게 볼 수 있어, 의도치 않은 부작용을 줄임

• 이 정도 설정이면 그냥 vim을 쓰는 게 나을 것 같음. Helix 안에서 vim 기능을 재현하려고 하고, Helix도 내부적으로 많은 의존성을 가짐(nvim처럼 표면에 보이지 않을 뿐임). 내 vim8 세팅은 8년 이상 단순하게 유지하고 있음. vim8을 쓰는 이유는 LTS 배포판에 탑재된 버전이기 때문임. 자동로드되는 플러그인은 하나뿐이고(vim-tmux-navigator로 vim 분할창과 tmux 분할창을 쉽게 이동), 코드를 검토했고 업데이트도 안 함. "선택적" 플러그인 두 개는 vim의 내장 패키지 매니저로 필요할 때 :packadd!로 켬. ale(lsp, 진단, 저장 시 자동 포맷), vim-fugitive(git 연동)만 사용. ale는 의존성이 없음. vim-fugitive는 한번 설치해두면 그냥 쓰면 됨. 플러그인을 자동으로 로드하지 않는 이유는, vim은 보통 빠른 편집이 주 목적이기 때문이고, 장기 프로젝트에서만 git/lsp를 켬. 불필요한 플러그인은 굳이 쓸 필요가 없음

  • 나도 modern Neovim이 좋아서 python 패키지를 하나 만들어서(특히 이미 python 생태계에 있거나 uv, pipx를 쓰는 사람들에게 맞게) 이 문제를 해결하고 있음. uv tool install binwheels-neovim이나 pipx install binwheels-neovim으로 최신 Neovim을 설치할 수 있고, 윈도, mac, 리눅스에서 바로 동작함. 이 패키지는 공식 Neovim 릴리즈를 랩핑해서 uv나 pipx를 써서 운영체제/아키텍처에 맞는 바이너리를 가져옴. 리눅스의 경우 공식 릴리즈보다 더 오래된 GLIBC 지원이 필요해서 따로 빌드해서 제공함. 관련 내용은 PyPI, Github 메인, 빌드 로그 참고

  • Helix는 nvim+플러그인들에 비해 공급망 공격의 표면적이 극히 작음. Helix 자체만으로 관리되고, 플러그인마다 벤더가 따로 있는 nvim보다 훨씬 안전함. Helix는 릴리즈가 느리고 신중하게 진행되어서 취약점이 나와도 큰 문제가 없도록 운영되고 있음

  • Helix의 편집 모델이 더 우수함

• Helix를 쓰면서 TUI가 필요하다면, 왜 neovim 대신 Helix를 써야 할지 궁금함. Helix의 기본값은 맘에 드는데, 어느 순간부터 바꿔야 하는 부분이 생기면 점점 번거로워지는 느낌임. 그리고 Helix로 '완전한 IDE 경험'을 원한다면 Zed, VSC, JetBrains IDE를 쓰지 않을 이유도 잘 모르겠음. 나는 간단한 게 필요하면 nvim을, 더 많은 기능이 필요하면 WebStorm을 띄우거나 동료가 뭔가 찾으려면 그걸 같이 씀

  • 저사양 장비에서 ssh로 작업할 때 헬릭스가 거의 즉시 실행됨. 같은 기능을 nvim으로 구성하려면 느려지고, 설정/플러그인 업데이트 관리비용이 커짐. 또 rust를 알기 때문에 버그 수정에도 기여할 수 있음. c계열 언어는 몰라서 오픈소스 프로젝트는 아는 언어로 이루어진 걸 선호함. 나는 12년간 n/vim만 쓰다가 최근 2년 헬릭스로 넘어온 취미 코더임. 사실 nvim에서 그리운 부분도 많고 더 자연스럽게 느껴지는 부분도 있지만, helix는 정말 ‘즉시 실행’이 되고 그 쾌적함이 다 씹어먹음

  • 지난 몇 년간 neovim, helix, emacs, nano를 각각 한동안 써봤는데, 헬릭스의 out-of-the-box 경험이 압도적으로 최고였음. 기본값이 정말 잘 잡혀있고, 컨텍스트별 도움말과 힌트가 아주 잘 나와서 잘 쓰는 명령은 잊어도 되고, 드물게 쓰는 것도 쉽게 찾을 수 있음. 또, 내 머릿속에선 helix의 명령어 작동 순서가 vim보다 더 자연스럽게 와닿음. nvim/spacemacs 같이 요즘 에디터들은 플러그인/설정의 장벽이 너무 높음. 플러그인 생태계 덕분에 helix가 지금은 못하는 일도 할 수 있겠지만(예: emacs는 어떤 lisp 언어든 IDE처럼 쓸 수 있고 helix는 repl 로드 불가), 그만큼 에디터 자체만이 아니라 숱한 플러그인까지 배워야 하고, 검색해도 답이 버전/조합마다 달라서 혼란스러움. 새로 만들 때는 결국 남의 추천을 믿고 쓰거나, 직접 써보고 배우는 시간이 추가로 들게 됨. 헬릭스는 신생 프로젝트라 옛날 결정의 부담이 없고, 현대 개발패턴에 맞는 의사결정과 기본값을 택할 수 있음. 완벽하진 않지만, TUI 초보자에게 지금 바로 쓸만한 것/설정없이 손쉽게 시작할 걸 원하면 helix를 추천하고 싶음

  • hx는 시작, 실행 모두 빠르고 예쁘기까지 함. 기본값도 꽤 만족스러워서 살짝 수정만 했고, endless improvement loop에 빠져 살던 emacs/neovim과 달리 hx는 끝이 보임. TUI는 원격 서버에서도 잘 동작해서, mac, linux, 서버 어디서든 똑같은 환경을 씀(타 편집기도 다 가능하긴 한데 hx도 잘 지원함). 필요한 lsp 전부 잘 지원하고, languages.toml 설정이 살짝 번거로웠지만, 다른 에디터들 설정도 마찬가지였음

  • 단순한 설정, 그리고 selection-first editing model을 좋아함. 관련해 참고문헌은 여기. Vim 적응에 어려움을 겪는 사람들과 이야기해보니, 나는 원래 Helix처럼 '먼저 선택' 모델에 익숙했던 듯함. Vim처럼 타겟 텍스트가 보이지 않는 동작(명령 후에 영향범위가 보이는 것)엔 적응이 힘들었음

  • 에디터 선택은 엄청 합리적인 결정이기보다는 자기 취향이나 신선함, 재미 같은 심리적인 요인이 훨씬 큼

• " :reset-diff-change " 명령은 처음 알았음. 나는 git에서 " checkout -p "만 써왔는데, Helix 내부에서 바로 하는 게 훨씬 편리함

• Helix를 사용해보고 열심히 적응해서 지금은 능숙하게 쓸 수 있게 됐음. 그런데, 되려 이 '역순 작업 흐름'이 배우기도 쉽고 구현도 쉽지만, 막상 쓰면 속도가 느려진다는 걸 깨달았음. 그래서 결국 다시 Vim, 그리고 Zed(Vim모드)로 돌아감

• Helix 오늘 처음 써봤는데, 정말 잘 디자인된 편집기임. 그렇지만 y2$, dw 같은 Vim의 빠른 작업 단축키가 빠져서 아쉬웠음

  • 사실 단축키가 없는 게 아니라, y2$는 2xy, dw는 wd로 쓰면 됨

• Helix에서 빈 줄도 포함해 현재 줄을 삭제하는 방법을 아직 못 찾겠음. "xd"는 non-empty line일 때 한 줄 삭제인데, 빈 줄인 경우엔 두 줄이 동시에 지워짐

  • x는 현 줄을 선택, 이미 선택된 상태에서는 다음 줄 확장임. X는 선택을 줄 경계로 확장함(line-wise 선택). X를 쓰면 됨

  • 빈 줄에는 그냥 "d"를 씀

  • 은근히 불편함. 나도 x 동작을 빈 줄에서 다르게 바꾼 trivial fork를 돌리고 있음. 자세한 내용은 여기 PR 참고