Neovim이 여전히 개발자 도구로 사랑받는 이유

Neovim이 여전히 개발자 도구로 사랑받는 이유

AI 뉴스 썸네일

요즘 개발 도구 이야기는 AI 에이전트와 자동완성으로 자주 흘러가요. 그런데 Neovim 이야기는 조금 다른 축을 보여줘요. 더 많은 기능을 한 화면에 넣는 대신, 편집이라는 일을 몸에 익는 언어처럼 다루는 방식이에요.

핵심 요약

구분	핵심	왜 볼 만한가요
개발 도구	Neovim은 코드 편집을 타이핑보다 이동, 수정, 삭제, 재구성의 반복으로 봐요	에디터 선택이 기능 목록보다 작업 감각의 문제라는 점을 다시 보여줘요
오픈소스 워크플로	설정 파일, 셸, tmux, Git, LSP 같은 도구와 느슨하게 이어져요	한 도구가 모든 걸 품는 방식과 반대편에 있는 개발 환경이에요
생산성	`ci"`, `dap`, `.`, 매크로, 텍스트 객체처럼 조합 가능한 편집 문법이 핵심이에요	반복 편집을 줄이는 방식이 AI 자동완성과는 다른 생산성 관점을 줘요

1. Neovim은 왜 아직도 개발자에게 선택받나요

Caio Bianchi는 2011년부터 Vim을 쓰기 시작했고, 여러 에디터를 거친 뒤에도 Neovim을 계속 고른다고 써요. 이유는 단순한 속도보다 작업 방식에 가까워요. 코드를 고치는 일은 긴 문장을 빨리 입력하는 일이 아니라, 함수 사이를 오가고 작은 단위를 바꾸고 테스트 결과를 확인하는 루프에 가까워요. Neovim은 이 루프를 키보드 중심의 짧은 동작으로 다루게 해요. 1

글에서 가장 눈에 띄는 대목은 Vim을 단축키 묶음이 아니라 편집 문법으로 본다는 점이에요. `ci"`는 따옴표 안을 바꾸고, `dap`은 문단을 지우고, `.`은 직전 변경을 반복해요. 매크로와 텍스트 객체까지 익숙해지면 같은 종류의 수정이 매번 손작업으로 남지 않아요. 이 감각은 VS Code나 JetBrains 같은 도구가 나쁘다는 말과는 달라요. 글쓴이도 그 도구들이 충분히 좋다고 인정해요. 다만 Neovim은 사용자가 배운 동작이 오래 쌓이고, 그 동작이 다른 프로젝트와 터미널 환경에서도 계속 이어진다는 쪽에 힘이 있어요. 2

요즘 에디터는 탐색기, 터미널, Git 패널, 디버거, AI 패널까지 한 화면 안에 배치하는 방향으로 커졌어요. Neovim은 그 반대에 가까워요. 버퍼를 중심에 두고, 파일 검색은 Telescope나 fzf-lua로 고르고, Git은 Fugitive로 붙이고, 검색은 ripgrep과 함께 써요. 셸과 tmux를 밀어내기보다 그 옆에서 일하는 방식이에요. 2

이 방식의 장점은 원격 서버나 작은 터미널 창에서도 같은 감각을 유지한다는 데 있어요. 로컬 프로젝트, SSH 세션, Markdown 글, 큰 Rails 앱을 오갈 때 편집기의 몸동작이 크게 바뀌지 않아요. 개발 환경을 계정 설정이나 마켓플레이스 상태에 맡기지 않고, Git에 담긴 설정 파일로 관리할 수 있다는 점도 Neovim 사용자가 자주 말하는 매력이에요.

Neovim은 오래된 Vim 감각만 붙잡고 있는 도구가 아니에요. Lua 설정, 내장 LSP, Treesitter, Lazy.nvim 같은 변화가 들어오면서 최신 개발 도구가 기대하는 기능도 꽤 많이 품었어요. 코드 진단, 포매팅, 자동완성, 구문 인식, 플러그인 관리는 예전보다 훨씬 자연스러워졌어요. 중요한 건 그 기능들이 거대한 대시보드로 합쳐지기보다, 필요한 조각을 고르는 식으로 남아 있다는 점이에요. 1

왜 중요한가요

이 글은 개발 생산성 논의가 자동 생성과 AI 보조로 쏠릴 때 다른 관점을 보여줘요. Neovim은 사용자가 직접 익힌 작은 동작의 누적을 중시해요. 한 번 익힌 motion, 한 줄짜리 매핑, 작은 Lua 함수, 필요 없어진 플러그인을 지우는 결정까지 모두 작업 환경을 조금씩 바꿔요. 생산성을 초 단위 절약으로만 보지 않고, 수천 번의 작은 편집에서 마찰이 줄어드는 감각으로 보는 글이에요. 2

Neovim을 쓰라는 결론으로 읽을 필요는 없어요. VS Code가 맞는 사람도 있고, JetBrains가 더 편한 팀도 있어요. 다만 좋은 개발 도구가 꼭 기능을 더 많이 품어야 하는지 묻게 해요. 내 작업 흐름을 어디까지 도구에 맞출지, 어디부터 도구를 내 손에 맞출지 생각하게 만들어요. 1

특히 팀에서 표준 개발 환경을 정할 때 참고할 만해요. 모두에게 같은 IDE를 강제하는 방식은 온보딩에는 편해요. 반대로 설정을 파일로 관리하고 셸 도구와 느슨하게 조합하는 방식은 오래 쓰는 사람에게 큰 자유를 줘요. 어느 쪽이든 중요한 건 도구가 코드를 보는 시간을 방해하지 않는 거예요.

참고 자료

1. Neovim에 보내는 러브레터 — GeekNews
2. A Love Letter to Neovim — Caio Bianchi