- tmux와 SSH, nvim, 강력한 검색·자동화 스크립트를 결합하여, 원격 서버의 파일을 GUI 없이도 즉시 탐색·수정·검색하는 독특한 워크플로우를 구현
- 키 조합 하나로 tmux 복수 창에서 파일명 자동 검색 및 바로 열기, 파일 전환, 버퍼 관리까지 모두 단축키로 처리함
- VSCode의 느린 속도와 키 바인드 충돌에 불만을 느껴 직접 스크립트로 모든 조작을 통합함
- regex, perl, tmux, nvim 등 유닉스 도구들을 조합해 파일 경로·라인 정보 자동 인식 및 열기를 실현함
- 직접 구현 과정이 매우 복잡하지만, 터미널의 강력함과 확장성을 극대화할 수 있음을 보여줌
나만의 터미널 사용법
- 이 글은 터미널과 도구를 결합해 효율적인 개발 환경을 구축한 경험을 공유함
- 일반적으로 동영상이 필요한 복잡한 과정이기 때문에 텍스트와 함께 실동영상을 연동함(영상 감상 필수)
- 영상의 일부 단계는(0:11, 0:21, 0:41)은 많은 사람들이 "이게 가능하냐?"고 놀라는 부분임
영상 속 터미널 워크플로우 단계별 요약
- 0:00 : Windows Terminal을 노트북에서 실행
- 0:02 : ctrl + shift + 5 단축키로 새 터미널 탭을 열고,
ssh로 집에 있는 데스크탑에 접속, 바로 tmux 실행 - 0:03 : tmux에서 기본 쉘 zsh 실행, 프롬프트 표시 및 전체 설정을 비동기로 로드
- 0:08 :
zoxide로 최근 디렉토리 fuzzy 검색 후 이동 - 0:09 : ripgrep 명령어 입력 시작, zsh가 이전 사용 이력 기반으로 자동완성, ctrl + f로 수락
- 0:11 :
ctrl + kf단축키로 tmux 스크롤백 전체에서 파일명 검색, 파일명이 파란색으로 하이라이팅 - 0:12 :
n키를 계속 눌러 검색된 파일 리스트 중 원하는 파일을 탐색 - 0:21 :
o키로 선택한 파일을 기본 앱(nvim)에서 열기, tmux가 새 창에서 실행(여전히 원격 서버에서 작동) - 0:26 : rust-analyzer로 코드 내 여러 레퍼런스를 이동 시도, 일부 매크로는 인식 실패, 0:32에 정상적으로 이동 성공
- 0:38 :
ctrl + kh로 tmux 포커스를 왼쪽 창으로 전환 - 0:39 :
n키를 다시 눌러 "copy-mode" 상태에서 이전 파일 검색 결과를 계속 탐색 - 0:41 :
o키로 이번엔 다른 파일을 기존 nvim 인스턴스에 열기 - 0:43 :
b키로 열려 있는 파일 버퍼 목록 확인, 두 파일을 번갈아 전환하며 마무리
왜 이렇게 터미널 워크플로우를 쓰게 됐는가?
-
VSCode가 느리고, 특히 vim 플러그인 사용 시 매우 버벅거림
- 에디터, vim 플러그인, 터미널, 윈도우 관리 기능 간에 키 바인드 충돌이 자주 발생해 불편함
- Zed 에디터도 시도해봤으나, 당시엔 아직 미성숙했고 키 바인드 충돌 문제도 여전했음
-
nvim(Neovim)을 터미널에서 직접 사용하기 시작했지만,
- ripgrep 등으로 검색한 파일명을 일일이 복사해서 에디터에 붙여넣는 과정이 너무 번거로움
- 특히 ripgrep 결과에서 파일명과 라인 번호가 함께 나오면,
- 붙여넣을 때마다 구문 오류 발생
- 실제로 파일을 열기 전에 불필요하게 편집하는 일이 많아짐
- VSCode의 ctrl-click처럼 파일 경로를 바로 열 수 있는 워크플로우가 필요하다고 느낌
- 그래서 tmux를 활용해 원하는 기능을 직접 구현하게 됨
- 사람들이 왜 tmux를 쓰냐고 물으면, 바로 이 자동화와 세션 유지 때문이라고 설명
- 터미널은 생각보다 훨씬 강력하지만, 기본 기능만으로는 이러한 자동화가 드러나지 않음
- tmux는 비록 오래되고 문법이 복잡하며 버그도 있지만, 확장성과 커스터마이징 가능성 때문에 선택함
주요 구현 방법
tmux에서 전체 스크롤백 파일명 검색
- tmux copy-mode에서 복잡한 정규표현식으로 파일명 패턴 매칭
- 직접 제작한 regex 스크립트(
search-regex.sh)로 파일 경로, 라인, 컬럼까지 하이라이팅 - 예시 tmux 설정:
bind-key f copy-mode \; send-keys -X search-backward '정규표현식'
선택 파일을 새 창/현재 창에서 열기
- tmux 단축키로 선택 파일을 디폴트 앱 또는 에디터(nvim 등)로 열도록 커스텀
- 상대경로 지원 및 tilde 확장 포함
bind-key -T copy-mode-vi o send-keys -X copy-pipe 'cd #{pane_current_path}; ...' bind-key -T copy-mode-vi O send-keys -X copy-pipe-and-cancel 'tmux send-keys ...'
파일을 이미 열린 nvim 인스턴스에서 열기
- perl 스크립트로 tmux가 특정 nvim pane을 찾아, 해당 pane에 파일/라인 정보까지 직접 키 입력 전달
-
file:line:column구문을 vim 명령으로 변환해 자동 오픈
이 방식의 장점과 한계
- 로컬 터미널의 기능 한계 극복: tmux를 통한 원격 서버의 자유로운 파일 탐색/수정/검색 구현
- 에디터가 원격 편집 프로토콜을 지원하지 않아도 동일 워크플로우 가능
- 모든 키 바인드·검색·파일 전환·버퍼 관리 등을 완전히 내 입맛에 맞게 통합
- VSCode 플러그인 제작보다 더 빠르고 쉽게 자동화 가능
- 직접 제작한 스크립트들은 깨지기 쉽고 유지보수 어렵기 때문에, 남에게 추천하긴 힘듦
대체 솔루션
- 대체로 추천하는 오픈소스/도구 조합:
-
fish + zoxide + fzf: 퍼지 디렉토리, 명령 검색, 일부 파일 검색 워크플로우 대체 가능 - 에디터 내장 기능(탭, 윈도우, fuzzy finder 등)도 대부분의 사용자에게 충분함
-
qf: 터미널 출력에서 파일 선택이 가능하지만, 상호작용적인 도구와는 연동 불가, vi-like CLI 사용 -
e: file:line 경로를 인식하는 소도구(에디터 종류별로 별도 스크립트 필요) -
vim --remote,code filename,emacsclient등도 비슷한 효과, 단 file:line 인식은 불완전함
-
결론 및 교훈
- 터미널은 생각보다 훨씬 강력하며, 직접 스크립트로 조합하면 GUI 툴에서 불가능한 자동화 가능
- 단, 유지보수성, 스크립트 내재된 버그 등 실용적 한계 존재
- 터미널 워크플로우 자동화에 관심 있다면 커스텀 tmux/nvim/fzf 환경부터 단계적으로 구축하는 것이 현실적임
Hacker News 의견
-
나도 비슷한 트릭을 쓰고 있음. tmux 스크롤백을 활용하고, 토크나이즈된 출력을 zsh로 파이프해서 tmux 화면에 보이는 모든 것에 대해 자동완성 기능을 쓸 수 있음. 관련 쓰레드 포스트와 gist 코드 공유함. 정말 쓸모 많았음
-
이런 워크플로우 방식 정말 마음에 들어서, 나도 비슷한 걸 수년간 반복하며 다듬고 있음. 시간이 흐르면서 커스텀 계층을 최대한 줄이려고 하고 있는데, 그 이유는 오버레이가 많아질수록 유지보수에 비용이 커지기 때문임. 순정 Vim(별도 tmux 없이)에서도 게시글에서 소개한 대부분을 할 수 있는데, 예를 들자면
rg --vimgrep restore_tool | vim -c cb -로 가능함 (vim -c cb -는 Vim에서 가장 좋아하는 기능이고, 다들 거의 안 쓰는 게 신기할 정도임). 물론 rg 검색을 매번 다시 실행하는 건 부담이 클 수 있어서, 나는 결과를 터미널에서 분석하다가 필요하면 tmux 커스텀 명령어로 마지막 명령의 출력을 복사해서 vim에 보내는 식으로 사용함. 이 때 프롬프트에 유니코드 문자를 활용하는 트릭을 쓰기도 하고,tmux saveb - | vim -c cb -로 넘기기도 함- 10년 전 방대한 멀티파일, 멀티패키지 vim 설정을 버리고, 매년 1~2줄 정도씩 아주 간단한 vimrc만 만들면서 점점 단순화 중임. 오래된 소프트웨어의 디폴트 설정에는 이유가 있기 마련이고, 무작정 바꾸지 말고 그 이유부터 이해해 보길 추천함
- (
vim -c cb -가 Vim에서 좋아하는 기능이라고 했는데 그게 뭘 하는지 설명해 줄 수 있는지 궁금함.ls | vim -와ls | vim -c cb -를 해봐도 바로 차이가 뭔지 모르겠음) - 'vim -q <(ripgrep --vimgrep restore_tool)'와 같은 용도인지 궁금함
-
이 셋업은 tmux, fzf, rg, zoxide, 그리고 깔끔한 nvim이 모두 포함되어 있어서 보기 좋음. 만약 없다면 atuin, starship, bat, glow, duf, dogdns, viddy, gum/sesh, dust, btop 등도 추천하고 싶음. GitHub의 Awesome Terminal XYZ 리스트에서 다 찾을 수 있음. atuin은 정말 필수급이고, zoxide가 없다면 운동선수인데 신발이 잘못 맞는 느낌임. 터미널 영상을 찍을 때는 asciinema가 더 나은 선택임. 사실 옛날에는 이런 셋업을 "프로그래머다"라고 불렀음. 요즘은 VSCode, Zed, Cursor 등의 툴도 필수고, 어떤 LLM에 어떤 걸 맡겨야 하는지도 꿰고 있어야 함. 이런 툴은 이제 새로운 “최소한”일 뿐이고, 기존 환경을 대체하지는 않음. Claude Code, gptel 등을 아무리 잘 써도 때로는 트리 망가질 수도 있고, magit 없이 git을 쓴다는 건 상상 불가임. 혹시 Cursor 순정으로 OP보다 더 빠르다고 생각하면, 그 사람이 직접 LLM을 실전으로 쓰는 영상 한 번 찍어보라고 함
- 프로그래머라는 건 개발환경 세팅이 전부가 아님. 어떤 유명 프로그래머는 ex 에디터를 애용하고, 어떤 초보자는 IDE만 번지르르해도 근본적인 이해가 부족한 경우가 많음. 물론 좋은 도구가 도움될 수 있겠지만, 실제 성공에 미치는 영향은 보통 작았음. LLM이 이걸 바꿀 수도 있겠지만. 예를 들어 운동화가 잘못 맞아서 5% 느리다고 해도, 스타트업에서 성공과 실패를 가르는 건 그런 미세한 것들이 아님. 원인은 대부분 공동창업자 불화, 동기 상실, 제품-시장 미스매치 같은 더 큰 문제임
- 네 툴 리스트는 좋지만, atuin, dogdns, btop 등 대부분의 툴 이름을 모르는 사람 입장에서는 다소 생소하게 보일 수도 있겠음
- 명령어 리스트 정말 좋아함. 난 여기다가 fd(작성자: sharkdp)도 꼭 추가하겠음. find의 대체제인데 사용성 측면에서 훌륭함. 그리고 atuin은 내 CLI 인생에서는 가장 큰 업그레이드임. 6개월 전에 쳤던 희귀한 명령어도 아주 쉽게 찾을 수 있게 해줌
- 도구 선택에 너무 집착하는 것 같음. 정말 좋은 개발자는 벌거벗은 환경에서도 빠르게 결과물을 냄. 물론 좋은 도구가 미세하게 더 도움될 수 있지만, 대부분은 나만의 재미와 취향 문제임. 생산성이 IDE에 얼마나 달려 있는지 정말로 느껴진다면, 아직 앞으로도 배우며 성장할 여정이 한참 남았다는 의미임. 예전부터 “도구를 아는 것 = 프로그래머”라는 공식은 아니었음. 내가 봤던 최고의 개발자들은 대부분 more/grep/vi에 사색만 얹어서 압도적인 결과물을 냄. 가치 창출은 결국 생각에서 나옴. 심지어 LLM 시대에도 이건 마찬가지임
-
모든 vim/tmux 유저는 반쯤은 버그도 있고 빠르긴 한 비공식 “에미테이션 Emacs”를 직접 만들었을 확률이 높음
- 나는 두 키 tmux 프리픽스를, 모든 명령을 위한 단일 ctrl-modified 키로 바꾸는 터미널 에뮬레이터까지 만들었음. 프로젝트 링크
- 나처럼 vim/tmux와 emacs 양쪽을 쓰는데(그리고 예전엔 emacs만 오래 썼는데), 내 emacs 환경이 훨씬 더 즉흥적이고 문서화 덜 되고 버그도 많았음. vim+tmux 셋업은 상대적으로 안정적임
- 그 말에 깊이 공감함. 나는 지금 워크플로우에서 nvim 안에서 :Term을 돌림
- vim+tmux 환경은 파이프, 파일, 시그널, 스크롤백 같은 시스템 프리미티브에 많이 의존함. 그래서 툴링이 다양한 환경이나 ssh, 제한된 쉘에서도 자연스럽게 투명하게 작동함. 이게 이식성과 디버깅에서 큰 장점임. 즉, 이런 기본 보장 위에서 내 워크플로우가 자유롭게 조각나가는 느낌이라 vim 설정을 직접 만드는 게 너무 당연한 선택처럼 느껴짐
-
그가 Windows에서 tmux를 쓴다는데 실제로 어떻게 사용하는 건지 궁금함. 설명 가능한 사람이 있으면 좋겠음
- 내 생각에는 Unix 시스템에 원격 접속해서 실제 작업을 한다고 봄. Unix 서버에서 tmux를 완벽하게 돌릴 수 있음. 나도 VirtualBox VM에 SSH 접속해서 WSL보다 더 깔끔한 호환성 계층을 쓰기도 함. 이런 점에서 tmux가 다른 방법보다 강한 이유기도 함. 서버에 설치만 되어 있으면 원격으로도 본연의 역할을 다 함. 관련 설명 링크
-
이런 워크플로우 공유 방식 정말 좋아함. 타깃 독자에게 딱 맞음. 나는 동영상에 소리가 있었으면 했지만, 액션 리스트를 나중에 읽는 것도 괜찮았음. 내 워크플로우에도 참고할만한 게 있어서 배웠음. tmux의 난해한 키보드 단축키를 언급했는데, 혹시 여기서 byobu 써본 사람? byobu는 tmux의 래퍼로, 대부분의 커맨드를 F# 키에 할당함. 10년 전에 처음 접해서 그 이후로 쭉 쓰고 있음. 그 전에 몇 년은 순수 tmux만 썼었음
- 콘텐츠 재미있게 봤다니 기쁨 :) 최대한 명확하면서도 한눈에 볼 수 있게 만들려 노력함. 난 tmux 단축키 대부분을 리매핑해서 쓰고 있음.
ctrl-k가 프리픽스로,h는 "왼쪽 패널 선택" 기본값이 아님. byobu는 사용해본 적 없지만 내용만 봐서는 기본 단축키가 좀 더 편한 정도라 크게 추가로 얹고 싶진 않음
- 콘텐츠 재미있게 봤다니 기쁨 :) 최대한 명확하면서도 한눈에 볼 수 있게 만들려 노력함. 난 tmux 단축키 대부분을 리매핑해서 쓰고 있음.
-
이런 식으로 직접 거대한 정규식 없이도 tmux 플러그인으로 복사 모드 기능 등을 확장할 수 있음. tmux-fpp, tmux-copycat, tmux-fingers, tmux-urlview 등이 있음. 내장 기능에 최대한 의존하는 게 속도에서 유리할 수 있으니 참고 바람. 난 특히 tmux-resurrect(세션 저장/복구), tmux-continuum(자동화 기능), Oh-My-Fish용 tmux-zen도 아주 좋아함. tmux-resurrect, tmux-continuum, tmux-zen 소개함. 멋진 tmux 환경 세팅은 생각보다 정말 쉽다는 점 강조함
- 나도 tmux-copycat에서 원본 정규식을 가져왔음. 하지만 a) 그 정규식은
:를 잘 못 잡아내고, b) copycat은 자체 뷰어 추상화를 쓰다 보니 한 번의 검색에 오직 하나의 액션만 할 수 있음. 내 방법은 tmux 내장 검색을 재활용해서 하이라이트되는 파일에 원하는 액션을 자유롭게 바인딩할 수 있음. 대부분 플러그인이 복사/붙여넣기만 지원하거나 자체 모드를 만들어 올리는 이유도, tmux가 하이라이트 컨트롤을 거의 내장 검색에서만 할 수 있게 해줌
- 나도 tmux-copycat에서 원본 정규식을 가져왔음. 하지만 a) 그 정규식은
-
이런 셋업은 정말 아름다움. 그런데 아직 제대로 된 AI 타입어헤드가 터미널에 등장하지 않은 게 미스테리임. Cursor 탭이 딱 맞을 것 같은데 터미널 적용이 막혀있음. 임시로 터미널 출력을 가짜 파일로 파이프해서 cursor로 보내는 제품을 뚝딱 만들고 싶은 마음도 듦
-
기사 제목이 사실은 "How I use my terminal"임
- HN 자동 기능이 제목 첫 단어가 How이면 잘라버림. 딱히 근거는 없고, 관리자가 클릭베이트 방지라 설명하지만 실제로 혼란만 줌
- 처음엔 이 글이 영화 '데어 윌 비 블러드' 패러디 같은 건 줄 알았음(현재 제목이 'I use my terminal'이라 그렇게 생각함)
- 나도 이 글이 누군가 직접 만든 터미널 에뮬레이터 사용기인 줄 알았음
- 나도 그거 알게 되었음. 글 훑어보니 전체 제목은 "I use my terminal (and so should you )"쯤일 듯. 터미널 관련 글은 언제나 반갑고, 크롬북(Chromebook) 사용자 입장에선 브라우저와 터미널만 있으면 충분했음. 맥으로 넘어가면 너무 방만해서, 평소엔 터미널 아니면 브라우저만 사용함
- HN에서 제목 등록 시 보통 흔한 접두어나 접미어는 자동으로 잘라냄