▲

Neovim에 보내는 러브레터

 (caio.ca)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Neovim은 코드 편집을 빠른 타이핑이 아니라 이동, 변경, 삭제, 재구성, 테스트 확인이 이어지는 반복 루프로 다루게 함
  • Vim의 편집 문법은 ci", dap, ., 매크로, 텍스트 객체처럼 의미 단위 작업을 조합해 반복 편집의 마찰을 줄여줌
  • Neovim은 탐색기·터미널·Git 패널을 강제하지 않고, 버퍼를 중심으로 Telescope, Fugitive, LSP 등을 사용자가 고르게 만듦
  • 설정은 Git에 담긴 파일로 소유할 수 있고, 셸·tmux·ripgrep·git·language server와 함께 동작하는 시스템 일부로 남음
  • Lua, 내장 LSP, Treesitter, Lazy.nvim으로 현대화됐지만, 핵심 가치는 배운 동작이 오래 쌓여 워크플로가 직접 진화한다는 데 있음

Vim에서 Neovim으로 이어진 작업 감각

  • Vim 사용은 2011년에 시작됐고, 초반에는 .vimrc를 복사하거나 j가 문자를 입력하지 않고 커서를 움직이는 이유도 이해하지 못했음
  • 첫 주는 힘들고 첫 달은 낯설었지만, Vim의 모델이 익숙해진 뒤 다른 편집기는 코드와 사용자 사이에 완충층이 있는 것처럼 느껴짐
  • VS Code, JetBrains IDE, Sublime, Atom, Zed 등 여러 편집기를 써봤고, JetBrains 도구는 매우 강력하며 VS Code는 거의 모두에게 충분히 좋고 확장하기 쉬워 성공함
  • 그래도 Neovim을 계속 쓰는 이유는 작업 방식에 맞춰 움직이고, 코드 편집의 반복 루프를 직접적으로 지원하기 때문임

편집을 단축키가 아니라 언어로 다루는 방식

  • 코드 편집은 빠르게 타이핑하는 일이 아니라 이동, 작은 변경, 잘못된 추상화 삭제, 함수 재구성, 파일 이동, 테스트와 진단 확인이 반복되는 작업에 가까움
  • 대부분의 편집기는 텍스트를 문서로, 키보드를 입력 장치로 다루지만, Vim은 편집을 문법(grammar) 처럼 다룸
  • ci"는 따옴표 안을 바꾸고, dap는 문단을 지우며, .은 마지막 변경을 반복함
  • 매크로는 작은 루틴을 한 번 가르쳐 파일 전체에 반복 적용하게 하고, 텍스트 객체는 문자 수 대신 의미 단위에 작업을 적용하게 해줌
  • Vim 문법이 손에 익으면 마우스로 코드를 끌거나 사이드바를 클릭하거나 매일 수십 번 하는 작업마다 명령 팔레트를 여는 일이 줄어듦
  • 자주 하는 작업은 작고 직접적인 움직임이 되고, 편집기의 소음도 줄어듦

워크플로를 강제하지 않는 Neovim

  • GUI 중심 편집기는 탐색기, 터미널, Git 패널, 디버거의 위치와 형태에 대한 고정된 관점을 갖기 쉽고, 시간이 지나면 편집기가 조종석처럼 변함
  • Neovim은 버퍼에서 시작하며, 주변에 무엇을 둘지는 사용자가 결정함
  • 파일 트리가 필요하면 추가할 수 있고, 퍼지 검색은 Telescope나 fzf-lua처럼 맞는 도구를 고를 수 있음
  • Git 통합은 Fugitive를 사용할 수 있고, LSP, 진단, 포매팅, 스니펫, Treesitter, 테스트 러너, 자동완성도 느린 Electron 대시보드처럼 변하지 않은 채 처리 가능함
  • 속도는 시작 시간만이 아니라 신뢰의 문제임
    • 키를 누르면 즉시 반응해야 함
    • 큰 파일을 열 때 전체 UI가 멈칫하지 않아야 함
    • SSH 접속, tmux 페어링, 작은 터미널 창에서의 수정에서도 매일 쓰는 편집기 감각이 유지되어야 함
  • 로컬 프로젝트, 원격 서버, 빠른 설정 변경, 큰 Rails 앱, 작은 셸 스크립트, Markdown 글 작성까지 같은 이동, 같은 명령, 같은 근육 기억을 사용할 수 있음
  • 이런 일관성은 경력 전체에 걸쳐 누적됨

소유 가능한 설정과 시스템의 일부로 남는 도구

  • Neovim 설정은 Git에 들어 있는 파일이라서 직접 읽고, 망가뜨리고, 필요 없는 플러그인을 깨달았을 때 절반을 지울 수 있음
  • 미스터리한 설정 데이터베이스, 반쯤만 이해하는 동기화 계정 상태, 몇 릴리스 전 체크박스 변경 때문에 백그라운드에서 이상하게 동작하는 확장에 의존하지 않음
  • 현대 편집기 상당수는 모든 일이 벌어지는 장소가 되려 하지만, Neovim은 더 큰 시스템의 날카로운 일부로 남는 데 만족함
  • 셸을 대체하려 하지 않고 tmux, ripgrep, git, language server, formatter, linter, test runner와 함께 동작함
  • 전체 책상을 소유할 필요가 없다는 점도 Neovim이 오래 지속된 이유 중 하나임
  • 2011년 이후 여러 편집기, 확장 생태계, 테마, 마켓플레이스, AI 패널이 등장했지만, Vim은 이미 오래된 도구였고 Neovim은 사람들이 중요하게 여긴 이유를 버리지 않은 채 필요한 부분을 현대화함

현대화와 오래 지속되는 학습 보상

  • Lua는 설정을 더 좋게 만들었고, 플러그인 생태계도 크게 개선됨
  • 내장 LSP는 IDE 기능을 편집기에 가져오면서도 부풀어 오른 느낌을 주지 않음
  • Treesitter는 구문 강조와 코드 인식을 현대적으로 만들었고, Lazy.nvim은 플러그인 관리를 빠르고 단순하게 만듦
  • Neovim의 핵심 매력은 시간이 지나도 배운 것이 계속 쓸모 있다는 데 있음
    • 하나의 motion을 배우면 계속 도움 됨
    • 매크로를 작성하면 지루한 편집이 사라짐
    • 텍스트 객체를 발견하면 귀찮은 리팩터링이 쉬워짐
    • 명령 하나를 조정하면 손의 일부가 됨
  • 편집기는 회사가 새 사이드바를 출시해서 좋아지는 것이 아니라, 사용자가 더 잘 다루게 되면서 좋아짐
  • 생산성은 “여기서 5초를 아꼈다”만으로 측정하기 어렵고, 수천 번의 작은 편집에서 마찰이 줄어드는 데 있음
  • 코드, 테스트, git diff, 검색 결과를 오가면서 다른 방으로 이동한 느낌 없이 문제에 집중할 수 있음
  • Neovim은 프로그래밍 가능성이 높아 기본값을 받아들이기보다 워크플로를 직접 형성하게 만듦
  • 불편한 일이 두 번 반복되면 매핑, 명령, 작은 Lua 함수, 더 나은 플러그인, 또는 플러그인 삭제로 대개 고칠 수 있음
  • 설정은 실제 작업 방식에 맞춰 진화하고, 원하는 변경이 분명할 때 생각과 편집 사이에 놓이는 것이 매우 적음
  • 15년 동안 언어, 프레임워크, 머신 성능, 업계 유행은 바뀌었지만, Vim과 Neovim은 계속 가장 좋은 작업이 이뤄지는 중심 편집기로 남음

함께 보면 좋은 글 β

▲
GN⁺   [-]
Lobste.rs 의견들

  • 12~14년 전 vim을 쓰기 시작한 건, 코드를 바로 앞에 보여주는 가벼운 편집기가 필요했기 때문이었음
    마우스를 빼고 배우기 시작했고, 나중에 Mitchell Hashimoto도 비슷하게 vim을 배웠다는 걸 알고 반가웠음
    neovim은 TJ DeVries(https://www.youtube.com/@teej_dv)와 그의 YouTube 채널을 통해 알게 됐고, 그가 neovim, telescope 등 여러 프로젝트를 해킹하는 모습을 봤음
    Lua로의 이동이 자연스럽게 느껴졌고, 이미 좋아하던 작은 언어라 마음에 들었음
    처음 쓴 플러그인은 treesitter와 telescope였고, 지금도 몇 가지 작은 플러그인과 함께 neovim을 쓰고 있음
    neovim은 나한테 깨진 적이 없고 그냥 잘 동작함. LLM 플러그인은 쓰지 않으며, 그 생태계는 편집기 밖에 있어도 된다고 봄
    팀이 계속 가볍고 집중된 코드 편집기만 제공해 주길 바람

    • 비슷한 경험임. 수년간 vim과 emacs를 썼고 vim을 더 선호했지만, elisp가 꽤 괜찮은 프로그래밍 언어인 반면 vimscript는 좀 그랬다는 점이 늘 부러웠음
      그래서 neovim이 Lua를 추가한 게 아주 매력적으로 보였음

  • 20년쯤 전, 단순히 생산적인 것과 별개로 일상을 즐겁게 만드는 요소가 무엇인지 떠올려 본 적이 있음
    목록 맨 위에는 linux와 vim이 있었음
    어떤 일을 하든, 어떤 기술 스택을 쓰든, 이 둘은 인체공학적이면서도 익숙하고 아늑한 작업 환경을 보장해 줬음

  • 2009년 면접을 보던 때 :wq 이상으로 vim을 배우기 시작했음. 직원들이 모두 vim을 써서 같이 작업하려면 그 방법밖에 없었기 때문임
    일부는 방향키까지 비활성화해 두기도 했음
    그전에는 대학 시절 pico를 쓴 정도의 터미널 편집기 경험만 있었고, 평소에는 당시 유행하던 GUI 편집기를 썼음
    다행히 채용됐고, 그때부터 vim을 계속 쓰게 됐음
    최근에는 vim식 사고가 소프트웨어 생활의 다른 부분으로도 스며든 걸 깨달았음
    macOS에서 Hammerspoon으로 창 관리용 하위 맵을 위한 가상 키보드를 만들던 게 시작이었던 듯하고, 작년 말 Arch Linux를 써 보면서 타일링 창 관리가 아주 쉬워졌음
    한동안 전에 neovim으로 넘어왔고 정말 훌륭하다고 봄
    편집기 농담과 논쟁이 많다는 건 알지만, 몇몇 예외를 제외하면 코드를 직업으로 쓰는 사람들이 vim, emacs 또는 비슷한 편집기를 쓰지 않는다는 걸 아직도 이해하기 어렵다
    어떤 직업이든 일에 맞는 최고의 도구를 고르는 건 중요하고, 편집을 언어처럼 다루는 것은 소프트웨어에서 큰 장점임

    • 글의 핵심은 “Neovim을 왜 사랑하는가”이지, “왜 써야 하는가”는 아님
      위의 “이해하기 어렵다”는 부분에 대해 말하자면, VS Code 같은 편집기의 동작, 단축키, 플러그인도 매우 유용함
      VS Code 문서를 제대로 읽어볼 만하고, 실제로 많은 일을 해 줌
      그리고 나를 포함한 일부에게는 마우스로 버퍼의 임의 위치로 커서를 옮기고 임의 범위를 선택하는 게 단순하고 충분히 빠름
      KISS가 맞음
    • vi 모드와 이동 명령은 거의 everywhere에서 쓰지만, vi, vim, neovim, emacs의 viper는 가끔만 씀
      다른 편집기가 그 작업에 더 나은 도구인 경우가 많기 때문임
      요즘 가장 자주 쓰는 Python에서는 PyCharm이 그들보다 더 나은 도구라고 느낌
      다행히 IDEAVim이라는 아주 좋은 플러그인이 있어서 근육 기억은 유지할 수 있음
      mac에서 쓰면 시스템 단축키가 vi 단축키와 겹치지 않아, 상황에 맞는 쪽을 골라 쓸 수 있는 것도 장점임
      C++를 쓸 때는 CLion이 더 나은 도구라고 보지만, 거기서도 IDEAVim이 동작함
      범주가 애매한 잡일에는 zed를 자주 쓰고, vim 에뮬레이션도 꽤 좋음
      원격 시스템에 접속할 때 좋은 터미널 편집기가 있는 건 분명 좋지만, 완전한 GUI를 쓸 수 있을 때는 터미널 편집기를 그다지 좋아하지 않음
      모달 편집 자체는 좋아하지만, 근육 기억을 버릴 필요가 없다면 GUI 편집기를 쓸 이유도 충분하다고 봄

  • VS Code는 기본 상태만으로도 많은 용도에 충분히 좋음
    이미 ctrl-p 파일 검색, 분할 창, 구문 강조, 인기 언어 지원이 있음
    neovim도 적어도 기본으로 ctrl-p 정도는 제공하고, 보안 우려와 설정 장벽을 낮춘 vim식 편집기의 Linux Mint 같은 무언가가 되길 바랐음
    SSH로 접속한 머신에서 tmux 세션으로 페어 프로그래밍을 하거나 작은 터미널 창에서 문제를 고칠 때, 매일 쓰는 것과 같은 편집기 감각을 쓰고 싶다는 점은 공감함
    SSH 위의 screen/vim으로 많은 코드를 돈 받고 작성해 왔고, Slack이 언제든 울리는 식의 상시 방해가 있기 전이라 실제로 굉장히 생산적이었음
    Visual Studio나 Jetbrains IDE의 CLion, Rider 같은 시각적 디버거는 어떤 vim 편집기에서도 좋은 대체물을 찾지 못한 한 가지였음
    cgdb 같은 것보다 접근하기 쉬운 강력함이 있음
    속도는 시작 시간만의 문제가 아니고 neovim도 그 점에서 좋지만, 기본 neovim 종료는 vim보다 눈에 띄게 느림
    아주 길진 않아도 내 환경에서는 약 1초 정도 걸림

  • vim 모델을 좋아함. 모달 편집은 그중 작은 일부일 뿐이고, helix나 일반 IDE보다 vim에서 더 높게 사는 건 점진적으로 배울 수 있다는 점임
    처음에는 키 바인딩과 옵션 설정을 이해하고, Windows에서 뭔가 안 되면 설정에 조건문을 넣고, 그다음 autocmd와 함수를 작성하며, 앞서 배운 것들로 작은 플러그인까지 확장하게 됨
    그렇다고 vim이나 neovim을 진심으로 사랑하진 않음
    vim은 수십 년째 같은 이상한 버그가 고쳐지지 않은 채 남아 있고, neovim은 많은 버그를 고쳤지만 또 다른 버그를 들여왔음
    neovim의 가장 큰 죄는 업데이트마다 Lua API를 깨뜨리는 것임
    실행할 때마다 사용 중단 알림을 보고, 하려던 일을 하기 전에 설정을 고쳐야 하는 데 지쳤음
    새 기능 일부가 Lua 전용이 아니었다면 그나마 덜했을 것임
    그렇지 않았다면 vimscript만 계속 쓰면서 20년 넘게 이어진 호환성에 만족할 수 있었을 것임

답변달기