Vim+Tmux 와 풀 IDE 사이 언제

정직한 답: 상황에 따라

Vim+tmux 가 항상 더 좋다고 말하는 사람 — 또는 JetBrains 가 항상 더 좋다고 말하는 사람 — 은 뭔가 팔고 있어. 두 스택 모두 다른 일에 world-class 야. 성숙한 입장은 각자가 뭘 잘하는지 알고 의식적으로 고르는 거. 대부분 시니어 엔지니어가 둘 다 써, 가끔 같은 주에.

Vim+tmux 가 지배하는 곳

리모트 개발. 어디든 SSH; 에디터와 워크스페이스가 따라옴. "Remote Development" 익스텐션 불필요, 두 번째 데몬 X, GUI 지연 X.
Polyglot 일상 작업. Python, TypeScript, Lua, 셸, YAML 뭐 만지든 같은 에디터, 같은 키 바인딩. 언어 별 IDE 전환 X.
속도와 지연. 거의 어떤 하드웨어에서든 sub-millisecond 응답 시간. JetBrains 가 터미널 지연 못 따라잡아.
커스터마이징. 모든 키스트로크와 동작이 설정 가능. 몇 달 후 에디터가 진짜로 손에 맞아.
리소스 사용. Raspberry Pi 에서 50MB 로 돌아. JetBrains 가 열기만 해도 2GB 필요.
텍스트 처리 파워. 매크로, regex, 대량 편집 위한 셸 통합 — Vim 이 서랍의 가장 날카로운 칼.
페어 프로그래밍. 공유 tmux 세션 = 추가 도구 없는 실시간 협업.

풀 IDE 가 이기는 곳

강한 타입과 함께 무거운 refactor. JetBrains 의 Java / Kotlin / C# refactor 도구가 어떤 LSP 보다 수십 년 앞서. 타입 가로지르는 rename, extract interface, 클래스 사이 method 이동 — IntelliJ 의 정확도가 unmatched.
비주얼 디버깅. 그래픽 breakpoint 매니저, 변수 inspector, call-stack visualizer, time-travel 디버거. nvim-dap 존재하지만 복잡한 디버그 세션엔 한 발 뒤져.
새 언어 학습. Auto-complete + IDE 안 inline docs + 예시 검색이 익숙하지 않은 API 의 첫 달을 가속.
GUI 무거운 작업. UI 레이아웃 디자인, 데이터베이스 GUI, 통합 profiler, 비주얼 diff 도구.

대부분 사람이 도착하는 하이브리드 패턴

기본 에디터: 모든 일상에 Neovim+tmux.
그날의 task 가 무거운 refactor, 복잡한 디버그, 새-API 탐험이면 JetBrains IDE 잡음.
IDE 안에서 Vim 바인딩 사용 (IdeaVim plugin) 해서 motion 머슬 메모리 옮겨감.

린 starter config — 두 파일 한 자리에

이 퀘스트 끝나면 두 짧은 파일에 들어가는 의견 있는 config 갖게 돼. 트랙 6 의 .tmux.conf 와 트랙 4 의 init.lua. 아래는 둘 다의 절대 minimum-viable — 어떤 새 머신의 시작점으로 어디 핀.

설정 가능성은 수단이지 목적 아냐. Vim+tmux 의 포인트는 "무한 customizable" 가 아냐. 포인트는 "2년 차에 에디터가 손같이 느껴짐." 그게 작게 시작하고 felt 필요와 함께 config 가 자라게 할 때만 일어나. 설정을 스포츠로 다루는 사람들은 burnout; 적응하는 도구로 다루는 사람들은 영원히 머물러.

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 프로젝트인가, 아니면 둘 다 OK 인가? 선호 고르는 게 아니라 — 각 도구가 진짜로 자기 자리 버는 곳을 인식하는 거야. 노트의 프로젝트 이름 옆에 답 쓰기. 3 개월 후 다시 보고 어떤 결정 뒤집을지 봐. 진짜 fluency 는 어떤 칼 잡을지 아는 거; 이 연습이 첫 걸음.

Vim+Tmux 와 풀 IDE 사이 언제

정직한 답: 상황에 따라

Vim+tmux 가 지배하는 곳

풀 IDE 가 이기는 곳

대부분 사람이 도착하는 하이브리드 패턴

린 starter config — 두 파일 한 자리에

Code

External links

Exercise

Progress

댓글 0