▲

Vim에서 Helix로 전환한 후기

 (jvns.ca)
8P by GN⁺ 2일전 | ★ favorite | 댓글 2개
  • 20년간 Vim을 사용해온 개발자가 Helix 에디터로 전환하여 3개월간 사용한 경험을 공유
  • Helix는 복잡한 설정 없이 언어 서버(LSP) 를 기본 지원하는 점에서 매력적임
  • 특히 Vim/Neovim 대비 뛰어난 검색 기능과 다중 커서 등이 개선되어, 여러 파일 내에서 맥락(context) 파악과 일괄 편집이 편리함
  • 키 입력 시 빠른 참조 팝업(quick reference) 으로 단축키를 잊지 않고 활용 가능함
  • Markdown 리스트 자동 생성 미지원, 영구 undo 부재, 주 1회 정도의 크래시 등 일부 불편한 점이 있지만 전반적으로 만족스러운 사용 경험
  • 20년간 쌓인 Vim 근육 기억을 재학습하는 과정이 예상보다 쉬웠으며, Vim 방식을 강제하지 않고 "Helix 방식"을 학습하는 것이 훨씬 효과적이었음

Helix로 전환한 이유

  • Helix를 사용하게 된 계기는 언어 서버 통합 기능을 간편히 이용하기 위함임
    • Vim/Neovim에서 언어 서버 설정은 복잡했으며, Helix는 별도 설정 없이 즉시 정의 이동이나 심볼 이름 변경 등이 가능함
    • 기존에는 수많은 플러그인과 설정 파일을 유지해야 했으나 Helix는 기본 지원으로 부담이 줄어듦

Helix의 주요 장점

  • 검색 시스템의 우수성
    • 저장소 전체에서 문자열 검색 시 결과를 미리보기 창으로 표시해 매칭되는 파일을 스크롤하며 주변 코드를 함께 볼 수 있음
    • Vim의 ripgrep 플러그인과 달리 결과 맥락이 풍부해 빠른 판단이 가능함
  • 빠른 단축키 참조 기능
    • g 키를 누르면 이동 가능한 명령 목록이 도움말 팝업으로 표시되어 직관적임
    • 자주 사용하지 않는 단축키도 쉽게 확인 가능해 학습 곡선이 완만함

Vim과 Helix의 차이점

  • 마크 기능은 ma, 'a 대신 Ctrl+O, Ctrl+I로 커서 이동 이력을 추적함
  • 매크로 대신 멀티 커서 편집을 주로 사용함
    • 문서 내 일괄 변경 작업 시 %로 전체 선택 → s로 정규식 선택 → 필요한 다중 편집 수행
    • 매크로를 항상 작성하는 것보다 다중 커서가 훨씬 편리
  • 탭 대신 space + b로 버퍼 스위처를 활용해 빠르게 전환 가능함

Helix의 불편한 점

  • 텍스트 리플로우 기능이 Vim의 gq보다 덜 효과적임
    • 리스트와의 호환성이 떨어짐
  • Markdown 리스트 자동 생성 미지원
    • 리스트 항목 끝에서 "Enter"를 눌러도 리스트가 계속되지 않음
    • 불릿 리스트에 대한 부분적 해결책은 있으나 번호 리스트에는 없음
  • 영구 undo 기능 아직 미구현
    • Vim에서는 undofile을 사용하여 종료 후에도 변경사항 취소 가능했으나 Helix는 아직 이 기능이 없음
  • 파일 자동 리로드 미지원
    • 디스크에서 파일이 변경된 후 :reload-all (:ra<tab>)을 수동으로 실행해야 함
  • 가끔 크래시 발생
    • 주 1회 정도, Markdown을 많이 편집하는 것과 관련이 있을 수 있음
    • 다시 열면 되므로 크게 문제되지 않음
  • 그럼에도 불구하고 Helix를 계속 사용하고 있음

전환 과정과 학습 경험

  • 20년간 쌓인 Vim 근육 기억을 재학습하는 것이 매우 어려울 것으로 걱정했음
  • 휴가 중 사이드 프로젝트에서 Helix를 사용하기 시작했고, 1~2주 후 더 이상 혼란스럽지 않았음
  • 처음에는 Vim과 유사한 키 바인딩을 강제하려 했으나 실패했고, "Helix 방식"을 학습하는 것이 훨씬 쉬웠음
  • 여전히 혼란스러운 부분 존재
    • Vim의 w와 Helix의 w는 "단어"에 대한 정의가 다름 (Helix는 단어 뒤의 공백 포함, Vim은 미포함)

터미널 기반 편집 환경

  • 수년간 주로 GUI 버전의 vim/neovim을 사용했기 때문에 터미널에서 편집기를 사용하는 것이 약간의 적응 필요
  • 최종 결정한 워크플로우
    • 각 프로젝트마다 별도의 터미널 윈도우를 사용하고, 해당 윈도우의 모든 탭이 동일한 작업 디렉토리를 가짐
    • Helix 탭을 터미널 윈도우의 첫 번째 탭으로 배치
  • 여러 프로젝트를 병렬로 다루기 편리해, 이전 워크플로우보다 더 나을 수도 있음

설정

  • Neovim 설정이 수백 줄이었던 것에 비해 매우 간단한 설정을 유지
    • 주로 4개의 키보드 단축키만 설정
  • 주요 설정 내용
    • 테마: solarized_light
    • 기본 yank 레지스터를 +로 설정하여 시스템 클립보드와 동기화
    • #을 주석 토글 단축키로 설정 (기본 Ctrl+C가 마음에 들지 않았음)
    • ^와 $를 줄의 시작/끝으로 이동하도록 재매핑 (다른 방식을 배우고 싶지 않았음)
    • <space>l을 :reflow로 설정 (텍스트를 많이 작성하므로 자주 리플로우 필요, vim의 gq 단축키가 그리웠음)
  • 별도의 languages.toml 설정 파일에서 언어별 선호도 설정
    • Python의 경우: black 포매터 사용, pyright 언어 서버, 자동 포맷 비활성화

결론: 3개월간의 인상

  • 3개월은 그리 긴 시간이 아니며, 언젠가 Vim으로 돌아갈 가능성도 있음
    • 과거 nix로 전환했다가 8개월 후 Homebrew로 돌아간 경험이 있음 (단, 한 서버 관리에는 여전히 NixOS 사용 중이며 만족)
  • Helix는 아직 완성형은 아니지만 “설정 없는 편집기”의 방향성이 명확함
  • 단순함과 기본 내장 기능 덕분에 장기적으로 Vim 대체 가능성을 지님
  • 다만 지속적 사용 여부는 향후 안정성 개선과 기능 확장에 따라 달라질 전망임
▲
GN⁺ 2일전  [-]
Hacker News 의견
  • 에디터가 가끔 segfault로 인해 일주일에 한 번씩 크래시 발생함, 하지만 크게 신경 쓰지 않음, 단순히 다시 열면 됨이라는 식의 데이터 손실 접근 방식이 신기함, Helix에는 persistent undo가 없으니 다시 열어도 이전 상태로 돌아가지 않음
    오랫동안 Vim/Neovim을 사용해왔고, 직접 커스텀 설정도 해보고 이미 만들어진 설정도 써봤으나, Vim을 정말 좋아함에도 Helix에서 따로 설정 작업 없이 바로 사용할 수 있는 부분이 매우 매력적임
    그런데 Helix config 자체는 굉장히 원시적이라고 느껴서, 사실 Vim 첫 몇 년만 써봐도 Helix에서 얻는 환경을 복제할 수 있었을 것이라는 생각이 듬, 그리고 그렇게 해서 더 이상 설정 지옥이 없었음을 말하고 싶음
    헬프 팝업이 가야 할 경로나 키바인드를 안내해줘서 너무 좋음, 평소에 "정의로 이동"이나 "레퍼런스로 이동" 같은 기능 자주 안 써서 단축키를 까먹기 쉬움, 이런 맥락 팝업이 널리 도입되면 좋겠고, 만약 입력을 망설일 때에만 똑똑하게 뜬다면 정말 유용하겠음
    • 모든 앱에서 복잡한 키바인드를 쓸 때 맥락 도움말 팝업이 있으면 엄청나게 편할 것 같음, 특히 입력이 멈칠 때만 똑똑하게 보여주면 더욱 좋겠음
      20년 간 Vim/Neovim을 써 왔지만, 최근 6개월 전에야 which-key라는 플러그인을 설치해서 매우 유용하게 쓰고 있음
      which-key.nvim GitHub
    • Vim에서의 세팅 문제 맥락을 놓친 것 같음
      주 언어 서버 세팅(예: "정의로 이동" 가능)을 제대로 구축하려고 계속 시도해봤는데, Vim이나 Neovim에서 쾌적한 환경을 만들기가 너무 어렵게 느껴졌음
    • Vim 세팅 복제에 동의하지만, Helix를 서버에 바로 설치해서 쓸 수 있다는 점이 매우 편리함
      Vim 설정 및 관련 의존성 옮기는 번거로움이 없음, 개발 환경이 훨씬 포터블하게 느껴짐 (다만 복잡한 Vim 세팅만큼은 아니고 좀 더 기본적임)
    • 헬프 팝업 기능에 100% 동의함, 이런 기능이 여러 곳에서 적용되면 매우 도움이 될 것임
      특히 해당 아티클에서 관련 설명과 스크린샷을 보고 아주 강하게 이 기능을 갈망하게 됨
      똑똑하게 timeout 등의 조건으로 팝업이 뜨면, 필요하지 않을 때는 방해받지 않고, 망설일 때만 자동으로 안내받을 수 있어서 훌륭함
    • Helix를 3년간 거의 매일 썼지만 segfault로 다운된 것은 손에 꼽을 정도로 드문 경험임, 거의 없는 일임
  • Helix에 푹 빠져서 모든 개발에 사용하고 있음
    이전까지 neovim과 VS Code를 주로 썼는데, Helix가 특별한 장점을 채우고 있음
    • 디자인이 아름다움 (디테일에 신경 많이 씀)
    • 빠른 퍼포먼스 (느릴 거란 생각이 든 적 없음)
    • 기본 키바인드가 몸에 착 달라붙는 인체공학적 설계
    • 설치하자마자 설정 없이 바로 쓸 수 있음
      neovim을 설정하거나 vim을 계속 쓰는 게 귀찮아서, VS Code와 nvim의 중간 지점이 필요했는데 Helix가 딱임
      만약 vimscript 마스터였으면 고민이 달랐을 수 있으나 나는 아니기에 딱 좋음
      Helix가 더 모듈식이거나 UNIX처럼 동작할 필요 없이 지금처럼만 가주면 좋겠음
      이미 다양한 도구 Ecosystem이 존재하고, Claude Code와도 연동하여 쓸 수 있음(버퍼 리프레시로 새 편집 적용)
      최고의 에디터 중 하나라서 매달 프로젝트 후원도 시작함
      앞으로 발전을 바란다면, 에디터에서 이미지나 수식 렌더링이 되는 기능이 가장 아쉬움, 이 부분은 Kitty terminal 프로토콜이나 sixel같은 플러그인으로 구현되길 기대함
      마크다운 파일로 노트/블로그 작업할 때 특히 유용하게 쓰고 싶음
      Helix의 건승을 바람
    • Helix처럼 설치 직후 바로 쓸 수 있는 앱은 supply chain attack에 대한 걱정이 줄어들어서 매우 안심임
      VSCode나 (neo)vim은 여러 군데에서 플러그인을 받아와야 해서 항상 불안했음
    • nvim과 vscode 사이 중간이 필요하다면, 그냥 vscode에 vim 플러그인 써도 되지 않느냐는 의문이 있음
    • 나는 helix도 좋아하지만 nvim도 포기할 건 아님
      lua 개발자는 아니지만, LLM이 nvim 설정을 하거나 수정하는 데 큰 도움을 줌
      helix로 오게 된 가장 큰 계기는 LSP/린트 설정이 너무 잘 되어있다는 점임
    • “vimscript 마스터”라는 표현 대신 사실 neovim은 Lua를 써야 하지 않느냐는 의견
  • neovim에서 helix로 몇 주 동안 옮겨 보려고 했으나, 필수적인 기능이 아직 구현되어 있지 않아서 기록함
    • 저장 시 자동 코드 액션(예: Go import 추가): PR #6486
    • telescope+rg 같이 파일픽커와 연동된 퍼지 서치: PR #11285
    • 디스크 파일 변경 시 자동 버퍼 업데이트: 이슈 #1125
    • 파일 트리 브라우저 기능: 플러그인 시스템의 일환으로 도입 거절, 아직 미구현 PR #5768 이 외에 감수할 만한 사소한 것들도 있었음, 1~2년 후 다시 도전해볼 생각임
    • 나는 homebrew로 HEAD에서 자주 빌드하여 Helix 사용 중인데, Julia가 크래시가 잦다고 한 것에 놀람
      HEAD에서 이미 머지된 기능에 대해 몇 가지 공유함 —

      저장 시 코드 액션: 저장 시 훅으로 해결 가능(Go에는 적용), 하지만 다른 언어에는 적용 어려울 수 있음
      퍼지 서치: 아주 오래전부터 내장되었고, 최근 리워크로 크게 개선됨
      자동 버퍼 업데이트: 수시로 에디터를 백그라운드로 두는 경우가 많아 꼭 필요한 기능임
      파일 트리: HEAD에서는 Space+e/E로 계층적 탐색기 가능, 비교적 최근 추가됨

    • 링크된 파일 탐색기는 중단됐지만, vim-telescope 스타일의 탐색기가 올해 초에 Helix에 머지됨
      이미 내장된 퍼지서치 기반 파일픽커가 있기에 일반 파일 탐색기가 추가적인 유틸리티를 많이 제공하지는 않음
    • 나도 neovim에서 helix로 옮기려 했으나, 수십 년간 익숙해진 vim 명령어 근육 기억 때문에 작은 실수들이 쌓여서 금방 포기했음
      Helix용 vim 키바인드 플러그인도 썼지만 부분적으로만 맞아서 더 실망감이 컸음
    • 외부 프로그램(templ, sqlc 등)이 파일을 수정할 때 Helix가 자동으로 파일을 감지해 재로드하지 않는 점이 아쉬움
      숙련된 Helix 유저는 어떻게 해결하고 있는지 궁금함
  • Helix를 쓰게 된 동기는 주로 언어 서버(LSP) 세팅 과정에서 옴
    Vim/Neovim에서 쾌적하게 언어 서버 세팅하는 게 너무 일이 되어버려서 Helix로 옮기게 됨
    하지만 지난 5년간 Neovim엔 배터리 포함처럼 모든 게 갖춰진 배포판이 생겨서 아주 쉽게 세팅할 수 있게 됨
    많은 개발자들이 에디터 디버깅에 시간을 쓰고 싶어하지 않는 건 동의함, 그렇기에 JetBrains가 인기 있는 이유라 생각함
    단, 20년 Neovim 사용자가 LSP 환경을 제대로 구축 못 해봤다는 부분은 좀 납득이 어렵고, 작성자의 솔직한 경험인지 의심이 드는 부분임
    • Vim에서 10년 넘게 써도 LSP 세팅을 한 번도 안 한 사례가 있음
      결국 그마저도 전체 IDE를 쓰는 게 더 편해서 설치와 세팅에 늘 망설임이 있었음
    • 나도 20년 넘게 vim → neovim을 사용해왔으나 LSP가 깨지고 단축키도 같이 안 먹히면 뭔가 원인 찾고 싶지 않아지는 심리 장벽이 큼
      작성자의 사례가 공감됨
    • 놀라움, og나 neovim에서 LSP 세팅에 힘들지 않았음
      나도 설정은 최소화해서 barebones로 쓰는 편인데 어렵지 않았고, Lua가 vimscript보다 훨씬 인체공학적이라 느낌
      ALE 같은 툴을 계속 쓰게 되는 이유임
      Helix 사용하는 것도 행복하길 바라는 마음임
    • 완전히 이상하게 느껴짐, 네오빔의 LSP 내장된 지 두 해 넘었지 않았느냐는 질문
    • 중견 기업들이 vscode 툴링으로 표준화하는 현상이 눈에 띔
      다른 에디터도 쓸 수는 있지만, 거의 모든 디버깅, 설정이 vscode 중심이라 사용을 권장하는 분위기
      Neovim+treesitter+LSP 세팅도 이미 아주 부드럽게 잘 되고 있음, 과거엔 힘들었어도 요즘은 큰 이슈 아님
      Helix로 가는 동기가 LSP 때문이라면 의문, 혹시 작성자가 LSP에 불만이 맞는지 모르겠음
  • Helix의 noun-verb(객체-동작) 모델은 처음엔 신선했으나, 써보니 verb-noun(동작-객체)이 훨씬 잘 맞음
    noun-verb 방식의 단점 중 하나가 반복 명령(.)이 불가능함
    Vim에서는 dd.., dap.. 등 반복 동작이 가능한데, noun-verb 모델은 이게 어려움
    더욱 근본적으로 키 수가 부족해지는 문제가 있음
    너무 많은 기본 조작에 Alt 키를 써야 하고, vim처럼 normal/visual/insert 모드가 없고 visual/insert만 있음
    motion/객체 구분까지도 명확하지 않아서 키 맵핑 난이도가 올라가고 키 모자람 현상이 생김
    • verb-noun 방식은 사고방식까지 바꿔줌
      실제로 코드를 작성할 때 필요한 사고와도 더 잘 맞는 느낌임
  • nvim의 최근 최고의 변화는 mini.nvim임
    echasnovski가 만든 플러그인 모음집으로, 다양한 필요와 일관성·문서화를 충족시켜줌
    nvim 0.12(nightly)부터 내장 플러그인 매니저(vim.pack)로 mini.nvim과 lspconfig만 설치하면 충분함
  • lsp 같은 “고급” 에디터 도구를 아예 포기하는 게 얼마나 자유로운 경험인지 감탄을 멈출 수 없음
    neovim에서 플러그인, 자동완성, 심지어 문법 하이라이트도 없이 사용 중
    이런 방식을 통한 자기 규율이 더 좋은 코드를 쓰게 만든다고 느낌
    모두에게 맞는 건 아니겠지만 꼭 한번 해볼 것을 추천함
    • 플러그인 없이나 자동완성 없이도 살겠다는데 문법 하이라이트까지 끄는 건 괜한 고생 아닌가 싶은 의견임
    • 아직 나도 완전히 전환하진 않았지만, Emacs에서 자동완성이 1년째 고장인데 별로 아쉽지 않음
      코드 액션이나 goto definition도 쓰지 않고, 실시간 에러만 가끔 있지만 컴파일러가 워낙 빨라서 크게 의미가 없음
      LSP를 꺼버리고 싶은 마음, 20년 전보다 LSP가 내 프로그래밍 실력을 대단히 끌어올려 준 건 아니라는 생각
      문법 하이라이트 관련해서는, 알록달록한 테마가 오히려 집중을 깨고 의미도 없다고 생각함
      단일색 혹은 2색 위주 테마를 선호하고, 변수명·함수명 색 구분조차 필요 없다고 느낌
    • Mitchell Hashimoto가 이 방법으로 업무를 잘한다고 듣고, 최신 툴링 없이도 충분히 생산적일 수 있다는 확신을 얻게 됨
      다만 모든 걸 기억해야 하니 피로도가 누적되지 않는지, 또는 이 방식이 실제로 더 좋은 코드를 만드는지에 대한 의문이 있음
    • 나도 그 어떤 보조 도구 없이 코딩하지만, 문법 하이라이트만은 항상 켜둠
      색상은 코드에서 실수나 에러를 눈에 더 잘 띄게 하고, 코드 탐색도 빠르게 해주는 한 차원 더 많은 정보임
    • 개인 프로젝트에서는 이런 미니멀 세팅을 도입함
      너무 극단적으로 까지는 안 하고, 문법 하이라이트와 LSP를 통한 문법 오류 피드백까지만 유지함
      오토컴플릿이나 문서 자동 링크는 사용하지 않음
  • Helix 배우고 싶다면, nic-revs가 만든 Helix 문서 리뉴얼 버전을 추천함
    helix-editor.vercel.app
    공식 문서보다 훨씬 보기 편하고, 팁/트릭도 많아서 효율적인 편집법이나 키바인드 등 Helix의 단점(터미널 내장 없는 점 등)을 완화할 수 있음
    • 공식 문서의 가독성에 늘 답답함을 느꼈는데, 정말 고마운 정보임
  • 네오빔 배포판의 과도한 부가 기능이 실제로 거슬림
    오랜 vim 유저라면 kickstart(특히 모듈식 포크 kickstart-modular.nvim)를 추천함
    kickstart.nvim
    아주 미니멀한 시작점이라 훌륭함
    • kickstart의 장점은 모든 설정이 하나의 파일에 있다는 점임
      다만 덩치가 커서 난 fold marker로 구간을 접어가며 관리를 더 쉽게 만듦
답변달기
▲
qdr7h 16시간전  [-]

LSP, plugin 설정등의 간편함을 이유로 helix에 관심을 종종 갖게 되지만 손이 너무 vi/vim에 익숙해져서 쉽지 않습니다.

답변달기