Vim+Tmux와 풀 IDE 사이 언제

솔직한 답은 "경우에 따라"야

Vim+tmux가 언제나 낫다고 말하는 사람도, JetBrains가 언제나 낫다고 말하는 사람도 뭔가를 팔고 있는 거야. 두 스택 다 각자의 영역에서는 세계 최고 수준이거든. 성숙한 태도는 각각이 뭘 잘하는지 알고 그때그때 의식적으로 고르는 거야. 경력 있는 엔지니어 대부분은 둘 다 쓰고, 같은 주에 둘 다 쓰기도 해.

Vim+tmux가 압도하는 영역

리모트 개발. 어디로 SSH를 하든 에디터와 작업 공간이 따라와. "Remote Development" 확장도, 따로 도는 데몬도, 그래픽 지연도 필요 없어.
여러 언어를 오가는 일상 작업. Python이든 TypeScript든 Lua든 셸이든 YAML이든, 같은 에디터에 같은 키야. 언어마다 IDE를 갈아탈 일이 없어.
속도와 반응. 웬만한 하드웨어에서 1밀리초 아래로 반응해. 터미널의 이 반응 속도는 JetBrains가 못 따라와.
내 손에 맞추기. 키 하나, 동작 하나까지 다 설정할 수 있어. 몇 달 지나면 에디터가 진짜로 손에 맞아.
자원 사용량. Raspberry Pi에서 50MB로 돌아. JetBrains는 열기만 해도 2GB가 필요하고.
텍스트를 다루는 힘. 매크로, regex, 대량 편집을 위한 셸 연동까지 — 서랍에서 제일 날카로운 칼이 Vim이야.
같이 짜기. tmux 세션을 공유하면 추가 도구 없이 실시간으로 함께 작업할 수 있어.

제대로 된 IDE가 이기는 영역

타입이 강한 언어의 큰 리팩터링. JetBrains의 Java / Kotlin / C# 리팩터링 도구는 어떤 LSP보다도 수십 년 앞서 있어. 타입을 가로지르는 이름 바꾸기, 인터페이스 추출, 클래스 사이 메서드 옮기기 같은 건 IntelliJ의 정확도를 아직 아무도 못 따라잡았어.
눈으로 보는 디버깅. 그래픽 breakpoint 관리, 변수 들여다보기, 호출 스택 시각화, 시간을 되감는 디버거까지. nvim-dap이 있긴 한데 복잡한 디버깅 세션에서는 한 발 뒤처져.
새 언어 배우기. completion, IDE 안에서 바로 보이는 문서, 예제 검색 — 이 셋이 낯선 API를 만난 첫 달을 크게 앞당겨줘.
GUI가 필요한 작업. UI 배치 디자인, 데이터베이스 GUI, 통합 프로파일러, 눈으로 보는 diff 도구.

결국 다들 도착하는 절충안

기본 에디터는 Neovim+tmux로 두고 일상을 다 여기서 해.
그날 할 일이 큰 리팩터링이거나, 복잡한 디버깅이거나, 낯선 API 탐색이면 JetBrains IDE를 꺼내.
IDE 안에서는 Vim 키를 켜서 (IdeaVim plugin) motion 머슬 메모리를 그대로 들고 가.

군더더기 없는 starter config — 파일 두 개면 끝

이 퀘스트를 마치면 짧은 파일 두 개에 들어가는, 취향이 분명한 config를 갖게 돼. 트랙 6의 .tmux.conf랑 트랙 4의 init.lua야. 아래에 둘 다의 최소 형태를 담아뒀어. 새 머신을 잡을 때마다 여기서 출발하면 돼.

설정 가능하다는 건 수단이지 목적이 아니야. Vim+tmux의 핵심은 "무한히 바꿀 수 있다"가 아니야. "2년 차쯤 되면 에디터가 손처럼 느껴진다"지. 그건 작게 시작해서 진짜 아쉬웠던 만큼만 config를 키워갈 때만 일어나. 설정을 취미 삼는 사람은 지쳐 나가떨어지고, 도구를 길들이는 사람은 평생 남아.

Code

Minimum-viable ~/.tmux.conf — 짧게 유지·tmux

unbind C-b
set -g prefix C-a
bind C-a send-prefix

set -g mouse on
set -g base-index 1
setw -g pane-base-index 1
set -g renumber-windows on
set -sg escape-time 0
set -g history-limit 50000
setw -g mode-keys vi
set -g focus-events on
set -g default-terminal "tmux-256color"
set -ag terminal-overrides ",xterm-256color:RGB"

bind | split-window -h -c "#{pane_current_path}"
bind - split-window -v -c "#{pane_current_path}"
bind r source-file ~/.tmux.conf \; display "Reloaded"

bind h select-pane -L
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R

Minimum-viable init.lua — 위 tmux와 짝지어·lua

-- lazy.nvim bootstrap
local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not (vim.uv or vim.loop).fs_stat(lazypath) then
  vim.fn.system({ "git", "clone", "--filter=blob:none",
    "https://github.com/folke/lazy.nvim.git", "--branch=stable", lazypath })
end
vim.opt.rtp:prepend(lazypath)
vim.g.mapleader = " "

-- 설정
local opt = vim.opt
opt.number = true; opt.relativenumber = true; opt.cursorline = true
opt.signcolumn = "yes"; opt.scrolloff = 8; opt.termguicolors = true
opt.expandtab = true; opt.tabstop = 4; opt.shiftwidth = 4
opt.ignorecase = true; opt.smartcase = true; opt.incsearch = true; opt.hlsearch = true
opt.mouse = "a"; opt.clipboard = "unnamedplus"; opt.undofile = true
opt.splitright = true; opt.splitbelow = true; opt.updatetime = 250

-- 키맵 몇 개
local map = vim.keymap.set
map("i", "jk", "<Esc>")
map("n", "<Esc>", "<cmd>nohlsearch<CR>")
map("n", "<leader>w", "<cmd>w<CR>")

-- Plugin
require("lazy").setup({
  { "nvim-treesitter/nvim-treesitter", build = ":TSUpdate",
    opts = { highlight = { enable = true } } },
  { "nvim-telescope/telescope.nvim",
    dependencies = { "nvim-lua/plenary.nvim" },
    keys = {
      { "<leader>ff", "<cmd>Telescope find_files<CR>" },
      { "<leader>fg", "<cmd>Telescope live_grep<CR>" },
    } },
  { "folke/which-key.nvim", event = "VeryLazy", opts = {} },
  { "christoomey/vim-tmux-navigator", lazy = false },
})

Exercise

솔직한 목록을 하나 만들어봐. 지금 손대고 있는 프로젝트마다 정하는 거야. 이건 Vim+tmux 프로젝트인가, IDE 프로젝트인가, 아니면 둘 다 괜찮은가? 취향을 고르라는 게 아니라 각 도구가 진짜로 제 몫을 하는 자리를 알아보라는 거야. 노트에 프로젝트 이름 옆에 답을 적어둬. 세 달 뒤에 다시 보고 어떤 판단을 뒤집게 되는지 확인해봐. 진짜 능숙함은 어떤 칼을 잡을지 아는 데서 오고, 이 연습이 그 첫걸음이야.

솔직한 답은 "경우에 따라"야

Vim+tmux가 압도하는 영역

제대로 된 IDE가 이기는 영역

결국 다들 도착하는 절충안

군더더기 없는 starter config — 파일 두 개면 끝

Code

External links

Exercise

Progress

댓글 0