💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

프롤로그 — 2026년, 에디터는 다시 흥미로워졌다

10년 전 에디터 시장은 끝났다고 했다. VS Code가 모든 걸 먹었고, JetBrains는 자기 자리를 지켰고, Vim/Emacs 사용자는 자기 동굴에서 행복했다. 그게 끝이라고 했다.

2026년, 그 예측은 절반만 맞았다. VS Code는 여전히 지배적이다. Stack Overflow Developer Survey 2024에서 73.6%의 개발자가 VS Code를 쓴다고 답했고, 그 수치는 2025년에도 안정적이다. 하지만 그 아래에서 흥미로운 일이 벌어졌다.

- **Cursor**는 VS Code를 포크해서 AI-first 에디터로 만들었고, 2024년 시리즈 B에서 25억 달러 밸류에이션을 받았다. 2025년 시리즈 C에서는 90억 달러로 뛰었다.

- **Zed**는 Atom 창업자들이 만든, GPU로 렌더링되는 Rust 에디터다. 2024년 stable 출시 후 1년 만에 multiplayer-native라는 포지셔닝으로 visible한 점유율을 확보했다.

- **Neovim**은 0.10에서 0.11을 거치며 진짜 IDE처럼 쓸 수 있게 됐다. LazyVim, NvChad, AstroNvim 같은 디스트로가 진입장벽을 결정적으로 낮췄다.

- **Helix**는 Kakoune에서 영감을 받은 post-modal 에디터로, LSP가 빌트인이라는 점에서 Neovim과 차별화된다.

- **Sublime Text 4**는 2021년 출시 후 5년이 지났지만 여전히 살아있다. "그냥 빨라야 한다"는 사람들에게 최적이다.

- **JetBrains**는 큰 코드베이스의 헤비유저들에게 여전히 절대 강자다. AI Assistant + Junie로 자기만의 에이전틱 워크플로를 만들었다.

그리고 이 모든 위에 **Claude Code**가 있다. 에디터 안에 AI를 넣는 게 아니라, AI 안에 에디터를 넣는 발상. 터미널 네이티브로, IDE에 종속되지 않는 에이전트.

이 글은 일곱 도구를 솔직하게 비교한다. 마케팅 문구가 아니라 실제로 쓸 때 무엇이 좋고 무엇이 나쁜지. 그리고 마지막에는 "당신은 어떤 걸 써야 하는가"에 대한 결정 프레임워크를 준다.

1. VS Code — 여전히 디폴트, 그러나 디폴트가 갖는 무게

왜 아직도 이긴 게임인가

VS Code의 강점은 단순하지 않다. 여러 레이어가 동시에 작동한다.

1. **Extension ecosystem.** Marketplace에 60,000개가 넘는 익스텐션이 있고, 거의 모든 언어/도구가 first-class 지원을 받는다.

2. **Remote development.** SSH, Container, WSL, Codespaces — 원격 개발을 표준화시킨 게 VS Code다. Remote-SSH 한 번 쓰면 다른 에디터로 돌아가기 어렵다.

3. **GitHub Copilot 통합.** 2026년 시점에서 Copilot Chat과 Copilot Workspace는 에디터 안에서 가장 매끄러운 AI 경험을 제공한다. Copilot Agent Mode가 추가되면서 Cursor와의 격차가 좁혀졌다.

4. **모든 OS, 모든 코퍼레이트 환경에서 동작한다.** 회사가 "이 에디터만 허용" 정책을 쓰면 십중팔구 VS Code다.

솔직한 단점

- **Electron의 무게.** 2GB짜리 프로젝트 열면 부팅에 5-10초, 메모리는 1-2GB. Zed/Sublime 사용자가 보면 충격적이다.

- **Workspace trust, 권한 다이얼로그**가 종종 흐름을 끊는다.

- **UI density가 낮다.** 같은 화면에 들어가는 정보가 JetBrains/Neovim에 비해 적다.

- **AI 통합이 익스텐션 기반이다 보니** 컨텍스트 관리가 Cursor보다 거칠다. 파일 첨부, diff 적용, multi-file refactor에서 차이가 난다.

누가 써야 하는가

- 팀의 표준 환경이 필요한 경우.

- 다양한 언어/스택을 오가는 풀스택 개발자.

- Copilot을 적극적으로 쓰고, 그 이상은 필요 없는 개발자.

- 원격 개발이 일상인 경우 (Codespaces, Remote-SSH).

// .vscode/settings.json — VS Code를 빠르게 만드는 최소 설정

{

"editor.minimap.enabled": false,

"editor.formatOnSave": true,

"files.exclude": {

"**/node_modules": true,

"**/.next": true,

"**/dist": true

"search.useIgnoreFiles": true,

"telemetry.telemetryLevel": "off"

}

2. Cursor — AI-first 포크가 점유율을 만들어낸 첫 사례

무엇이 다른가

Cursor는 VS Code 포크다. UI/UX의 90%는 VS Code와 같다. 익스텐션도 거의 다 호환된다. 그런데 왜 사람들은 VS Code + Copilot 대신 Cursor를 쓸까?

차이는 디테일에 있다.

- **Cmd+K / Cmd+L 인라인 편집.** 코드 위에서 바로 자연어로 수정 지시. Apply 시 diff로 보여준다.

- **Composer / Agent 모드.** 멀티파일 작업을 한 번에. 파일 트리에서 컨텍스트를 추가하고 변경을 한꺼번에 적용.

- **Cursor Tab.** Copilot의 자동완성과 비교해 multi-line, multi-cursor jump을 더 잘 한다는 평가가 많다.

- **모델 선택 자유.** Claude Sonnet/Opus, GPT, Gemini를 사용자가 직접 선택. Copilot은 모델 선택권이 더 제한적이다 (2026년 기준 점차 개선 중이지만).

가격과 비즈니스 현실

- Free tier: 제한된 fast request.

- Pro: 월 20달러, fast request 500회/월 + slow unlimited.

- Business: 월 40달러/사용자, 팀 기능 + privacy mode.

- 2026년 시리즈 C에서 90억 달러 밸류, ARR이 5억 달러를 넘었다고 보도됐다. 즉, 이건 단기 실험이 아니라 자리 잡았다.

솔직한 단점

- **VS Code 업스트림 따라잡기 지연.** 새 기능이 VS Code에 먼저 들어가고 Cursor에는 몇 주 늦게 들어온다. 익스텐션 호환성도 가끔 깨진다.

- **인터넷 의존.** Cursor는 본질적으로 클라우드 inference에 의존한다. 오프라인에서는 무용지물.

- **프라이버시.** 코드가 Cursor의 서버를 거친다. Privacy mode가 있지만 기본은 그렇다.

- **AI 비용이 가격에 반영되어 있다.** 헤비유저는 fast request를 금방 소진.

누가 써야 하는가

- AI 페어 프로그래밍이 워크플로의 핵심인 사람.

- 여러 모델을 비교하면서 쓰고 싶은 사람.

- VS Code 단축키/익스텐션에 익숙하면서 AI는 더 적극적으로 쓰고 싶은 사람.

3. Zed — GPU 렌더링, multiplayer 네이티브, Rust로 다시 쓴 미래

Atom의 망령에서 태어난 에디터

Zed는 Atom과 Tree-sitter를 만들었던 GitHub의 Nathan Sobo가 창립했다. Atom이 2022년 sunset된 후, 같은 사람들이 "이번엔 Electron 안 쓰겠다"고 결심하고 처음부터 Rust로 다시 짰다.

- **GPU 렌더링.** GPUI라는 자체 프레임워크로, Metal/Vulkan/Direct3D를 통해 직접 그린다. 120Hz 디스플레이에서 진짜 120fps로 움직인다.

- **Multiplayer 네이티브.** 두 명, 세 명이 같은 파일에 동시에 커서를 두고 작업할 수 있다. 별도 익스텐션이 아니라 코어 기능.

- **Tree-sitter 빌트인.** 신택스 하이라이팅과 구조 인식이 핵심 레이어.

- **LSP 빌트인.** 별도 설정 거의 없이 동작.

- **AI 통합.** Anthropic, OpenAI, Ollama 등을 inline assist와 assistant 패널에서 직접 호출. Edit Prediction 기능으로 multi-line 제안.

2026년 상태

- 2024년 1월 stable 첫 출시. Linux 지원이 2024년 후반에 따라왔다.

- 2025년에 vim mode가 진짜 쓸 만한 수준으로 올라옴.

- 익스텐션 시스템이 점진적으로 열리고 있다 (WASM 기반). 하지만 VS Code 만큼의 ecosystem은 아직 멀었다.

- macOS와 Linux가 우선이고, Windows 지원은 2025년에 베타로 등장.

솔직한 단점

- **익스텐션 부족.** "Zed에 X를 위한 확장 있나?"의 답이 70% 확률로 "아직"이다.

- **디버거가 약하다.** 2025년 후반에 DAP 지원이 들어왔지만 VS Code/JetBrains에 비해 미숙.

- **모바일/Remote 옵션 약함.** SSH 원격 편집은 2025년에 추가됐지만 VS Code의 Remote-SSH만큼 매끄럽지 않다.

- **AI 통합은 좋지만 Cursor만큼 깊지 않다.**

누가 써야 하는가

- 속도가 종교인 사람.

- 페어 프로그래밍을 진짜로 하는 팀.

- Rust/Go/TS같은 모던 스택만 다루고, Marketplace 60,000개가 필요 없는 사람.

// ~/.config/zed/settings.json — Zed 초기 설정

{

"theme": "One Dark",

"vim_mode": true,

"buffer_font_family": "JetBrains Mono",

"buffer_font_size": 14,

"format_on_save": "on",

"assistant": {

"default_model": {

"provider": "anthropic",

"model": "claude-sonnet-4-5"

}

4. Neovim — 진짜로 IDE가 된 Vim

왜 2026년에 Vim을 쓰는가

Neovim은 Vim의 포크다. 2014년 시작됐고, 2017년 1.0이 나왔고, 2024년 0.10, 2025년 0.11로 매년 메이저 릴리스가 안정적으로 나오고 있다.

차이를 만든 건 세 가지다.

1. **빌트인 LSP 클라이언트** (0.5부터). 더 이상 coc.nvim, YouCompleteMe 같은 무거운 플러그인 필요 없음. nvim-lspconfig로 한 줄에 설정.

2. **Tree-sitter 빌트인** (0.5부터). 신택스 하이라이팅과 텍스트 오브젝트가 정밀해짐.

3. **Lua 스크립팅** (vimscript 대체). 플러그인이 진짜 빠르고 모던하게 만들어짐.

디스트로 — 진입장벽을 부순 결정타

벅맘하게 lua로 설정 파일을 짜는 대신, 디스트로를 쓰면 30분 안에 풀 IDE 환경이 만들어진다.

- **LazyVim** — 가장 추천하는 디스트로. lazy.nvim 기반, 모듈러, 거의 모든 언어 지원이 "extra" 한 줄로 켜진다.

- **NvChad** — UI 미적으로 가장 다듬어진 디스트로. 풍부한 UI 컴포넌트.

- **AstroNvim** — 균형 잡힌 옵션. 디폴트가 합리적이라 후처리가 적다.

- **kickstart.nvim** — 디스트로라기보다 "내가 직접 짠 거 같은" starter. 750줄짜리 한 파일.

-- LazyVim에서 Rust 지원을 켜는 한 줄

-- ~/.config/nvim/lua/plugins/rust.lua

return {

{ import = "lazyvim.plugins.extras.lang.rust" },

}

AI 통합

- **avante.nvim**, **CopilotChat.nvim**, **codecompanion.nvim** — 2025년에 폭발적으로 늘어난 AI 플러그인.

- **Copilot.vim** + **copilot.lua** — GitHub Copilot 공식/커뮤니티 통합.

- **claude-code.nvim** — Claude Code를 Neovim 안에서 띄우는 래퍼. 터미널 분할로 띄우는 게 표준 패턴.

솔직한 단점

- **러닝커브.** modal editing을 처음 배우는 사람에게는 1-2주의 생산성 손실을 각오해야 한다.

- **플러그인 에코시스템이 파편화.** 같은 기능을 하는 플러그인이 5-10개씩 있고, 어느 게 살아남을지 6개월 후엔 모른다.

- **GUI 안 함.** 터미널 안에서 모든 게 일어난다 (Neovide 같은 GUI 프론트엔드가 있지만 주류는 아님).

- **이미지/PDF 같은 비텍스트 워크플로** — 거의 무력.

누가 써야 하는가

- modal editing이 이미 자연스러운 사람.

- SSH로 원격 서버에서 자주 작업하는 사람.

- 모든 키 입력을 자기 손에 맞게 커스터마이즈하고 싶은 사람.

5. Helix — Kakoune이 영감을 준 post-modal 에디터

패러다임이 다른 모달 에디팅

Vim의 모달은 "동사 + 명사"다. `d w`는 "삭제 + 단어". Helix(그리고 그 영감인 Kakoune)는 "명사 + 동사"다. `w d`는 "단어 선택 + 삭제". 즉, **선택이 먼저, 동작이 나중**.

이게 왜 중요한가? **시각적 피드백이 즉시 따라온다.** `w`를 누르면 단어가 하이라이트되고, 그 상태에서 `d`를 누르면 삭제된다. Vim에서는 `dw`를 누르고 "이게 맞나?" 짐작해야 한다.

빌트인 LSP

Helix의 결정적 차별점은 LSP가 코어다. 별도 플러그인 시스템조차 없다 (2026년 현재 플러그인 시스템은 design 중이고 v25에서도 일반 사용자용은 아직). Rust, Go, TS, Python — 그냥 LSP 서버만 설치되어 있으면 바로 동작한다.

v25에서 v26으로

2025년 후반 v25.x 릴리스 사이클에서 들어온 굵직한 것:

- **DAP** (Debug Adapter Protocol) 지원 본격화.

- **Soft wrap** 개선.

- **Workspace symbols, code actions** 안정화.

- 플러그인 시스템 (Steel 기반 Scheme/Lisp)이 design RFC에서 점진적으로 알파로 이동.

솔직한 단점

- **플러그인 없음.** Neovim의 ecosystem이 부럽다면 Helix는 답이 아니다.

- **익숙해진 Vim 키 매핑이 안 통한다.** 첫 한 주는 손이 자기 의지로 안 움직인다.

- **AI 통합이 약하다.** 외부 도구와 함께 써야 한다 (예: Claude Code를 별도 터미널에서).

- **윈도우 분할 UX**가 Vim과 미묘하게 다르다.

누가 써야 하는가

- modal editing은 좋아하지만 Neovim 설정에 6시간을 쓰기 싫은 사람.

- "에디터는 텍스트 편집기다, AI는 별도 도구다"라는 철학을 가진 사람.

- Rust나 Go같은 LSP가 강한 언어를 주로 다루는 사람.

~/.config/helix/config.toml — Helix 기본 설정

theme = "onedark"

[editor]

line-number = "relative"

cursorline = true

true-color = true

bufferline = "multiple"

[editor.lsp]

display-messages = true

display-inlay-hints = true

[keys.normal]

space-space로 파일 검색

space.space = "file_picker"

6. Sublime Text 4 — 살아남은 자

왜 죽지 않았나

Sublime Text는 2008년에 처음 나왔고, ST4가 2021년에 나왔다. 그 사이 4년 동안 거의 죽었다고 했다. 2026년에도 살아있는 이유는 하나다 — **빠르다**. 그것도 미친 듯이 빠르다.

- 200MB짜리 로그 파일을 열어도 즉시 스크롤된다.

- 부팅 시간이 0.5초 이하.

- 메모리 사용량이 VS Code의 1/10.

- C++로 짜여졌고, 자체 GUI 프레임워크를 쓴다.

ST4의 업그레이드

- **GPU 렌더링** (ST4에서 추가).

- **TypeScript 1st-class**.

- **LSP 지원** (Package Control 익스텐션으로).

- **탭 미리보기, multi-select** 개선.

솔직한 단점

- **AI 통합이 부재.** 2026년 시점에서 Copilot/Cursor에 해당하는 first-class 옵션이 없다. 비공식 패키지로 LLM을 붙일 수는 있지만 어색하다.

- **익스텐션 ecosystem이 정체.** Package Control은 살아있지만 신규 패키지 활동이 적다.

- **유료.** 99달러 (3년 업데이트 포함). 이게 비싸다는 게 아니라, 무료 옵션이 워낙 많은 시대라 결정 비용이 든다.

누가 써야 하는가

- 로그 파일/CSV/거대한 텍스트 파일을 자주 다루는 사람.

- AI는 별도 도구 (Claude Code, Cursor를 보조로)로 쓰고, 메인 에디터는 그냥 빠른 텍스트 에디터를 원하는 사람.

- 한 번 사고 평생 쓰는 클래식한 비즈니스 모델이 마음에 드는 사람.

7. JetBrains — 큰 코드베이스의 절대 강자

IntelliJ 패밀리는 왜 여전히 이기는가

JetBrains IDE는 큰 코드베이스에서 다른 어떤 에디터보다 우수하다. 이유는 단순하다.

1. **Static analysis가 깊다.** 단순 LSP가 아니라, IntelliJ의 자체 코드 인덱싱 엔진이 프로젝트 전체를 의미 단위로 이해한다.

2. **리팩토링이 진짜로 안전하다.** Rename, Extract Method, Move Class — 수백 파일에 걸친 변경을 단일 액션으로.

3. **디버거가 최고.** 멀티스레드, async, JVM bytecode, native debugging까지 — VS Code/Cursor가 따라잡기 어려운 영역.

4. **언어별 특화 IDE.** IntelliJ IDEA(Java/Kotlin), PyCharm, WebStorm, GoLand, RustRover, CLion 등 — 각각이 그 언어에 최적화.

AI Assistant와 Junie

JetBrains는 2024년 AI Assistant를 출시했고, 2025년에 Junie라는 에이전트를 발표했다. 2026년 시점에서 Junie는 Cursor의 Composer/Agent와 비슷한 포지셔닝이다.

- **AI Assistant** — 인라인 자동완성, chat, 코드 설명.

- **Junie** — task-level 에이전트. 이슈를 던지면 멀티파일 작업을 수행하고 PR을 만든다.

솔직한 단점

- **무겁다.** VS Code의 2-3배 메모리. 큰 프로젝트 인덱싱에 수 분.

- **부팅 느림.** Splash screen + 인덱싱 = 30초-2분.

- **유료.** All Products Pack이 연 300달러+. 학생/오픈소스는 무료지만, 회사 카드로 사는 게 일반적.

- **JetBrains "느낌"이 좋고 싫음이 갈린다.** 메뉴/단축키/UI가 VS Code/Sublime/Zed 와 완전히 다른 문화.

누가 써야 하는가

- 모노레포, 큰 Java/Kotlin/Python 코드베이스를 다루는 사람.

- 리팩토링이 일상인 시니어 개발자.

- 디버거를 자주 쓰는 사람.

- 회사가 라이선스를 사주는 경우 — 거의 항상 가치 있다.

8. Claude Code — 에디터가 아니라 "에이전트 표면"이라는 발상

다른 카테고리

지금까지의 6개는 모두 "에디터 + AI 보조"였다. Claude Code는 반대다. **AI 에이전트 + 텍스트 편집 능력**.

- 터미널에서 동작한다.

- 어떤 에디터에서도 띄울 수 있다 (VS Code, Cursor, Neovim, Helix, Zed, JetBrains — 그냥 터미널만 있으면 된다).

- 파일을 읽고, 편집하고, 명령을 실행하고, MCP 서버를 통해 외부 시스템에 접근한다.

- 서브에이전트로 병렬 작업, 훅으로 자동화, Agent SDK로 커스텀 워크플로.

왜 이게 중요한가

에디터에 종속된 AI는 그 에디터를 떠나면 무용지물이다. Cursor는 Cursor 안에서만, Copilot은 VS Code/JetBrains/Vim의 익스텐션이 있는 곳에서만 동작한다. **Claude Code는 그런 종속이 없다.** SSH로 들어간 서버 위에서도, tmux 분할 안에서도, dotfiles repo 옆에서도 동작한다.

통합 패턴

- **Neovim/Helix 사용자**: 터미널 분할(`:terminal`)로 Claude Code를 옆에 띄움. 파일 변경은 양쪽에서 보인다.

- **Zed 사용자**: 내장 터미널에 Claude Code. Zed의 AI 패널과 병행.

- **VS Code/Cursor 사용자**: 통합 터미널에서 Claude Code. Cursor의 Composer와는 역할이 겹치지만, agentic 워크플로(긴 task 자율 실행)에서는 Claude Code가 우위.

솔직한 단점

- **시각적 UI 부재.** diff 보기, 파일 트리 — 다 에디터에 의존.

- **러닝커브.** 슬래시 커맨드, 서브에이전트, MCP, 훅 — 익히는 데 며칠.

- **모델 종속.** Anthropic 모델만 (다른 모델을 띄울 수는 있지만 디폴트는 Claude).

- **비용.** API 사용량이 헤비하게 나간다. Pro/Max 구독으로 어느 정도 cap이 있지만.

누가 써야 하는가

- 에디터를 자주 바꾸지만 AI 워크플로는 일관되길 원하는 사람.

- 멀티 머신, SSH, 컨테이너 안 — 환경이 떠도는 사람.

- 자율 에이전트 워크플로(긴 작업을 던지고 결과만 검수)에 적극적인 사람.

9. 비교표 — 한눈에 보는 7개 도구

|---|---|---|---|---|---|---|---|

| **러닝커브** | 낮음 | 낮음 | 낮음 | 높음 | 중간 | 낮음 | 중간 |

10. 결정 프레임워크 — 당신은 어떤 걸 써야 하는가

질문 1: AI 페어 프로그래밍이 매일 4시간 이상인가?

- **그렇다** → Cursor 또는 Zed (Anthropic 모델). 둘 다 inline + composer 패턴이 좋다.

- **아니다** → 다음 질문으로.

질문 2: 모달 편집을 이미 쓰고 있는가, 또는 1-2주 투자해서 배울 의지가 있는가?

- **그렇다, 미니멀하게** → Helix.

- **그렇다, 풀 IDE급 커스터마이즈** → Neovim (LazyVim 추천).

- **아니다** → 다음 질문으로.

질문 3: 모노레포, 거대 Java/Kotlin 코드베이스, 깊은 리팩토링이 일상인가?

- **그렇다** → JetBrains (IntelliJ/PyCharm/WebStorm).

- **아니다** → 다음 질문으로.

질문 4: 회사/팀 표준이 정해져 있는가?

- **그렇다** → 그 표준을 따라라. 의외로 이게 가장 강한 변수다.

- **아니다** → VS Code가 안전한 디폴트.

질문 5: 속도가 모든 것의 위에 있는가?

- **그렇다, 그러나 modal은 싫음** → Zed 또는 Sublime Text 4.

- **그렇다, modal도 OK** → Neovim/Helix.

그리고 Claude Code는 거의 항상 추가하라

위 결정과 무관하게, Claude Code는 메인 에디터와 별개로 쓸 수 있다. 터미널만 있으면 동작하니까. 자율 에이전트 워크플로(긴 task를 던지고 결과를 받는)에 익숙해지면 어떤 에디터를 쓰든 생산성이 뛴다.

11. AI 통합의 4가지 패턴 — 2026년 표준화

2026년 시점에서 에디터의 AI 통합은 4가지 패턴으로 수렴했다.

1. **인라인 자동완성** (Copilot, Cursor Tab, Zed Edit Prediction). 가장 보편적. 모든 에디터에서 어떤 형태로든 제공.

2. **인라인 채팅 / 인스트럭션 편집** (Cmd+K). 코드 위에서 자연어로 수정 지시. Cursor가 가장 잘 한다.

3. **사이드 패널 채팅** (Copilot Chat, Cursor Composer, Zed Assistant). 컨텍스트를 첨부하고 멀티턴 대화.

4. **에이전트 모드** (Cursor Agent, Copilot Agent, JetBrains Junie, Claude Code). task를 던지면 자율적으로 멀티스텝 실행.

각 패턴이 어떤 에디터에서 가장 강한지 정리하면:

- **1번 (인라인 완성)**: Copilot in VS Code, Cursor Tab, Zed Edit Prediction.

- **2번 (인라인 채팅)**: Cursor Cmd+K, Zed Inline Assist.

- **3번 (사이드 채팅)**: Cursor Composer, Copilot Chat in VS Code, Zed Assistant.

- **4번 (에이전트)**: Cursor Agent, Copilot Agent Mode (2025), JetBrains Junie, Claude Code.

Claude Code가 4번에서 독특한 이유는 **에디터에서 분리됐기 때문**이다. 다른 모든 에이전트는 특정 에디터 안에서 동작하지만 Claude Code는 그렇지 않다.

12. 모달 편집의 르네상스 — 왜 다시 뜨는가

2026년에 modal editing이 다시 주목받는 이유는 흥미롭다.

1. **AI가 자동완성을 잘 해주니, 타이핑 자체가 줄었다.** 그런데 코드를 "이동하고 선택하고 조작"하는 능력은 여전히 인간이 한다. modal editing은 정확히 그 영역에서 강하다.

2. **터미널 워크플로 회귀.** Docker, Kubernetes, 원격 서버 — 터미널 안에서 일이 많아졌다. 터미널 네이티브인 modal editor가 자연스럽다.

3. **AI 도구가 분리됐다.** Claude Code 같은 외부 에이전트가 강해지면서, 에디터 자체는 "그냥 빠른 텍스트 편집기"로 충분하다는 인식이 늘었다.

4. **Helix의 등장.** Vim의 진입장벽을 낮춘 modal editor가 modal editing을 새 세대에 소개했다.

이게 일시적 유행이냐? 아니다. 2024년 Stack Overflow Survey에서 Neovim은 사용자 만족도(loved) 1위였고, 2025년에도 상위권. Helix는 신규 사용자 채택 속도가 가장 빠른 에디터 중 하나다.

13. 안티패턴 — 자주 보이는 실수들

안티패턴 1: 도구를 자주 바꾼다

매달 새 에디터로 갈아타면 근육 기억이 안 쌓인다. 한 번 정하면 최소 3개월은 써라.

안티패턴 2: AI 자동완성을 무비판적으로 수락

Tab 누르면 끝나는 게 아니다. 자동완성은 hallucination을 한다. 짧은 변수명을 다른 의미로, 라이브러리 API를 잘못, type을 어림짐작한다. 검토하지 않은 자동완성은 부채다.

안티패턴 3: 익스텐션을 50개 깐다

VS Code/Cursor에서 자주 보이는 패턴. 매 익스텐션이 0.5초 부팅 지연을 만들면, 50개면 25초다. 본인이 매주 쓰는 것만 남겨라.

안티패턴 4: 디스트로(LazyVim 등)를 깐 다음 init.lua를 손도 안 댄다

디스트로는 시작점이다. 자기 워크플로에 맞게 후속 튜닝을 안 하면 디스트로의 의견이 자기 의견이 된다. 좋은 경우도 있지만, 시간이 지나면 답답해진다.

안티패턴 5: 에디터로 모든 걸 하려 한다

에디터는 텍스트 편집기다. CI/CD, 클라우드 운영, 데이터 쿼리 — 다른 도구가 더 잘 하는 일이 많다. 모든 걸 IDE 안으로 끌어들이려는 익스텐션 폭주를 경계하라.

에필로그 — 2026년의 진짜 변화

10년 전 예측은 절반만 맞았다. VS Code는 이겼다. 그러나 그 위에서 새로운 게 자랐다.

- **Cursor**는 "AI-first 에디터"라는 카테고리를 만들었다. VS Code의 ecosystem을 그대로 쓰면서 AI 경험을 한 단계 위로 올렸다.

- **Zed**는 "에디터는 GPU로 그려야 한다"는 명제를 증명했다.

- **Neovim/Helix**는 modal editing이 죽지 않았음을 보였다. 오히려 AI 시대에 더 잘 맞는다.

- **Claude Code**는 "에디터가 곧 AI 인터페이스다"라는 가정을 깼다. AI는 에디터 위가 아니라 옆에 있을 수 있다.

당신이 2026년에 코드를 쓴다면 — 한 도구를 사랑하되, 다른 도구의 존재를 인지하라. **사일로화는 도태의 시작이다.** Cursor만 쓰는 사람도 Neovim의 modal editing을 한 번은 경험해 봐라. Vim 베테랑도 Cursor의 Composer를 30분만 만져봐라. 시야가 넓어진다.

체크리스트 — 지금 당신의 에디터 설정 점검

- [ ] 매일 쓰는 단축키 10개를 머슬 메모리로 기억하고 있는가?

- [ ] 자동완성을 수락하기 전에 검토하는 습관이 있는가?

- [ ] 익스텐션/플러그인 중 6개월간 안 쓴 게 있는가? 정리했는가?

- [ ] 원격 작업 워크플로가 매끄러운가? (SSH, 컨테이너, 클라우드)

- [ ] AI 도구를 1개 이상 매일 워크플로에 통합했는가?

- [ ] 본인 환경의 에디터 설정을 dotfiles로 백업하고 있는가?

안티패턴 요약

- 도구를 자주 바꾸기 → 근육 기억 손실

- AI 자동완성 무비판 수락 → hallucination 누적

- 익스텐션 50개 → 부팅 지연 누적

- 디스트로 그대로 → 자기 의견 부재

- 에디터로 모든 걸 → 도구 선택 실패

다음 글 예고

다음 글에서는 **Claude Code의 internals — 서브에이전트, 훅, Agent SDK의 implementation 디테일**을 다룬다. 어떻게 한 터미널 프로세스가 멀티 에이전트 워크플로를 오케스트레이션하는지, MCP가 그 아래에서 어떻게 동작하는지.

참고 / References

공식 홈페이지

- VS Code: https://code.visualstudio.com/

- Cursor: https://www.cursor.com/

- Zed: https://zed.dev/

- Neovim: https://neovim.io/

- Helix: https://helix-editor.com/

- Sublime Text: https://www.sublimetext.com/

- JetBrains: https://www.jetbrains.com/

- Claude Code: https://www.anthropic.com/claude-code

- GitHub Copilot: https://github.com/features/copilot

- Windsurf (구 Codeium): https://codeium.com/windsurf

디스트로 / 플러그인

- LazyVim: https://www.lazyvim.org/

- NvChad: https://nvchad.com/

- AstroNvim: https://astronvim.com/

- kickstart.nvim: https://github.com/nvim-lua/kickstart.nvim

- avante.nvim: https://github.com/yetone/avante.nvim

- CopilotChat.nvim: https://github.com/CopilotC-Nvim/CopilotChat.nvim

데이터 / 트렌드

- Stack Overflow Developer Survey 2024 — Most popular IDE: https://survey.stackoverflow.co/2024/technology/

- GitHub Octoverse — Copilot adoption: https://github.blog/news-insights/octoverse/

- Cursor funding (Series C, 2025): https://www.cursor.com/blog

- Zed release notes: https://zed.dev/releases/stable

- Helix release notes: https://github.com/helix-editor/helix/blob/master/CHANGELOG.md

- Neovim releases: https://github.com/neovim/neovim/releases

MCP / 에이전트 표준

- Model Context Protocol: https://modelcontextprotocol.io/

- Claude Code docs: https://docs.claude.com/en/docs/claude-code/overview