Vim vs Neovim, 같은 뿌리 다른 설계 철학

Vim과 Neovim, 같은 뿌리에서 갈라진 두 설계 철학

터미널 편집기를 둘러싼 가장 흔한 오해는 “Vim은 낡았고 Neovim이 완전히 대체했다”는 단순화다. 실제 두 도구의 관계는 그보다 훨씬 미묘하다. 같은 뿌리에서 출발했지만 내부 설계 사상이 갈렸을 뿐, 한쪽이 다른 쪽을 폐기한 것이 아니다. 이 글은 두 에디터의 출발점, 내부 구조, 운영체제별 설치, 대용량 파일 처리, 설정 이식성, 코드 내비게이션까지 핵심 쟁점을 차근차근 비교한다.

📜 출발점 — 무엇이 갈라졌나

Vim(Vi IMproved)은 1991년 출시되어 30년 넘게 터미널 편집기의 표준으로 군림해 왔다. Neovim은 2014년 Vim의 C 코드베이스를 포크(fork)해 출발한 프로젝트로, “Vim의 정신은 유지하되 내부 구조를 현대적으로 다시 짠다”는 목표를 내걸었다. 즉 둘은 적이 아니라, 같은 혈통에서 갈라져 나온 사촌에 가깝다.

아래는 두 에디터의 흐름을 가른 네 가지 핵심 분기점이다.

2016년 Vim 8.0이 비동기를 들였고, 2021년 Neovim 0.5가 내장 LSP·Treesitter·Lua 설정을 선보이며 두 진영의 색채가 확연히 달라졌다. 즉 분기는 한 번에 끝난 사건이 아니라, 양쪽이 서로를 의식하며 진화한 긴 과정이다.

두 진영이 비동기를 받아들인 방식은 다음과 같이 갈린다.

▶ Neovim: 처음부터 libuv 기반으로 “async-by-default(기본이 비동기)”를 지향해 코어를 재작성했다.

▶ Vim 8.0+: 기존의 방대한 C 코드 위에 비동기 기능을 덧붙이는(bolted-on) 보수적 방식을 택했다.

이 차이는 호환성 문제로 직결된다. Vim은 job_start·ch_open을, Neovim은 jobstart를 쓰는 식으로 비동기 API가 파편화됐다. 그 결과 플러그인 개발자는 두 환경을 분기 처리하는 호환 레이어(예: async.vim)를 따로 짜야 하는 부담을 안게 됐다.

🏗️ 내부 아키텍처 — 구조적 차이의 핵심

두 에디터의 가장 결정적 차이는 클라이언트-코어 분리와 이벤트 루프의 유무다. Vim은 UI·편집 로직·비동기가 하나의 프로세스에 뭉쳐 있고, 비동기는 그 위에 덧붙은 형태다. 반면 Neovim은 편집 코어를 떼어내고, 그 코어를 RPC(원격 호출) 프로토콜로 감싸 여러 클라이언트가 붙을 수 있게 했다.

🔗 다이어그램 요약: Vim은 UI·코어·비동기가 한 프로세스에 묶인 단일 구조이고, Neovim은 편집 코어를 RPC로 분리해 터미널·GUI·외부 에디터 임베드 등 여러 클라이언트가 같은 코어에 붙는 분산 구조다.

이 분리가 만드는 실질적 차이는 “누가 화면을 그리느냐”다. Neovim에서는 코어가 편집 상태만 책임지고, 화면 렌더링은 클라이언트가 맡는다. 덕분에 GPU 가속 GUI인 Neovide 같은 별도 프런트엔드가 자연스럽게 붙고, VS Code 같은 에디터가 Neovim을 편집 엔진으로 임베드하는 것도 가능해졌다. Vim에서는 코어와 UI가 한 몸이라 이런 분리가 구조적으로 어렵다.

💻 운영체제별 설치 방법

두 에디터 모두 공식 패키지 매니저로 설치하는 것이 이식성·업데이트 측면에서 권장된다. Neovim의 실행 명령은 nvim이라는 점만 기억하면 된다.

🐧 우분투 / 데비안 계열

sudo apt update && sudo apt install vim       # Vim
sudo apt update && sudo apt install neovim    # Neovim (실행: nvim)

단, 배포판 저장소의 Neovim은 버전이 낮을 수 있다. 최신 내장 LSP API가 필요하면 공식 PPA를 등록하거나 AppImage를 직접 내려받는 방식이 주로 쓰인다.

🍎 macOS (Homebrew가 사실상 표준)

brew install vim       # Vim
brew install neovim    # Neovim (실행: nvim)

🪟 Windows (Winget 또는 Scoop)

winget install vim.vim              # Vim
winget install Neovim.Neovim        # Neovim

⚡ 대용량 파일과 성능을 둘러싼 엇갈린 평가

수십만 줄짜리 로그나 거대한 데이터 파일을 열 때, 두 에디터는 같은 혈통답게 비슷한 기본기를 보인다. 코어 편집 자체는 두 쪽 모두 견고하지만, 체감 속도를 좌우하는 변수는 따로 있다 — 바로 구문 강조나 LSP·Treesitter 같은 부가 기능을 켜 둔 상태다. 이런 무거운 기능은 파일이 클수록 비용이 커지므로, 대용량 파일에서는 이를 끄는 것이 양쪽 모두에서 효과적이다.

Neovim이 LuaJIT을 품으면서 “플러그인이 압도적으로 빨라진다”는 기대가 컸다. 다만 실제 체감에 대해서는 평가가 갈린다.

정리하면, LuaJIT은 분명한 이론적 우위를 갖지만 그 이득이 모든 상황에서 똑같이 드러나는 것은 아니다. 무거운 연산을 직접 도는 플러그인이라면 이점이 또렷하고, 단순히 코어 기능을 호출만 하는 작업이라면 차이가 거의 안 느껴진다 — 결국 “무엇을 하느냐”에 달린 문제다.

🔧 설정 이식성 — vimrc는 어디까지 통하나

설정의 출발점은 둘 다 Vimscript다. Vim은 ~/.vimrc를 쓰고, Neovim은 ~/.config/nvim/init.vim(Vimscript) 또는 init.lua(Lua)를 쓴다. Neovim은 기존 Vimscript 문법을 상당 부분 그대로 받아들이므로, 오래 다듬은 .vimrc를 큰 손질 없이 옮겨 쓰는 경우가 많다.

하지만 이식성은 한 방향이다. Neovim의 Lua 설정과 내장 LSP API에 의존한 구성은 Vim으로 거꾸로 옮길 수 없다. 즉 “Vim → Neovim”은 비교적 매끄럽지만, “Neovim → Vim”은 기능 손실을 동반한다. 두 환경을 오가야 한다면, 공통으로 통하는 Vimscript 핵심만 한 파일로 분리하고 Lua 전용 설정은 따로 두는 방식이 안전하다.

🧭 코드 내비게이션 — LSP와 구문 분석

정의로 점프, 참조 찾기, 자동 완성 같은 코드 내비게이션이야말로 두 진영의 색채가 가장 선명하게 갈리는 영역이다.

▶ Neovim은 0.5부터 LSP 클라이언트를 코어에 내장했다. 별도 외부 플러그인 없이도 언어 서버에 붙어 진단·정의 이동·완성을 받을 수 있고, Treesitter로 구문 트리를 직접 파싱해 더 정확한 강조와 구조 기반 이동을 제공한다.

▶ Vim은 LSP를 코어가 아닌 외부 플러그인(coc.nvim, vim-lsp, ALE 등)에 맡긴다. coc.nvim처럼 성숙한 생태계가 있어 결과물 자체는 강력하지만, Node.js 같은 외부 런타임을 끌어오거나 별도 설정 비용을 치러야 하는 경우가 있다.

정리하면 Neovim은 “코어에 다 들어 있다”는 통합성을, Vim은 “검증된 플러그인을 골라 붙인다”는 모듈성을 택한 셈이다.

📊 한눈에 보는 비교

🤔 그래서 무엇을 골라야 하나

정답은 없다. 다만 작업 환경과 우선순위에 따라 합리적인 선택은 갈린다. 아래 흐름이 대략의 길잡이가 된다.

🔁 다이어그램 요약: Lua 기반 현대 플러그인·내장 LSP가 필요하면 Neovim, 서버나 최소 환경에서 기본 탑재와 검증된 안정성이 우선이면 Vim을 고르면 된다.

서버나 컨테이너처럼 대부분의 환경에 기본 설치돼 있고, 추가 런타임 없이 즉시 쓸 수 있는 안정성이 중요하다면 Vim이 여전히 강력하다. 반대로 IDE에 가까운 통합 경험, Lua 기반의 풍부한 현대 플러그인 생태계, GUI·임베드 확장성을 원한다면 Neovim이 앞선다. 두 도구를 모두 갖춰 두고 상황에 맞춰 꺼내 쓰는 것도 충분히 합리적인 전략이다.

개발 도구 선택은 취향과 작업 맥락의 문제입니다. 본문의 설치 명령과 버전 정보는 작성 시점 기준이며, 실제 환경에서는 각 프로젝트 공식 문서의 최신 안내를 함께 확인하시길 권합니다.