SSH로 VPS에 접속해서 빌드를 돌리고 있는데, 카페 와이파이가 끊겼습니다. 빌드 로그가 화면에서 사라지고, 서버에서 돌던 프로세스도 같이 죽었습니다. 30분짜리 작업을 처음부터 다시 시작해야 합니다. 이런 경험, VPS를 써본 사람이라면 누구나 한 번쯤 겪습니다. tmux 하나면 이 문제가 사라집니다.
문제: SSH 연결이 끊기면 프로세스도 죽는다
SSH가 끊기면 서버 프로세스가 죽는 이유는 단순합니다. SSH 세션이 종료되면 운영체제가 해당 터미널에 연결된 모든 프로세스에게 SIGHUP(Signal HangUP) 신호를 보냅니다. SIGHUP을 받은 프로세스는 종료됩니다. 이건 버그가 아니라 유닉스의 기본 동작입니다 — 터미널이 사라졌으니 거기 붙어있던 프로세스도 정리하는 것이죠.
그래서 SSH로 접속해서 직접 빌드 명령어를 실행하면, SSH가 끊기는 순간 빌드 프로세스도 같이 종료됩니다. 노트북을 덮거나, 와이파이가 바뀌거나, 4G가 끊기거나 — 끊김의 원인은 중요하지 않습니다. 결과는 같습니다. 처음부터 다시.
이 문제는 클라우드 환경에서 더 자주 발생합니다. AWS EC2, Google Cloud Compute Engine, Azure VM 같은 클라우드 인스턴스는 SSH 연결의 유휴 타임아웃이 기본적으로 짧게 설정되어 있습니다. 아무것도 입력하지 않으면 5~10분 만에 연결을 끊어버리는 경우가 흔합니다. SSH keepalive 설정(ServerAliveInterval)으로 연장할 수 있지만, 근본적으로 네트워크 불안정이나 노트북 절전 모드까지 막을 수는 없습니다.
해결책: tmux 세션 안에서 작업한다
tmux(Terminal Multiplexer)는 SSH가 끊겨도 서버에서 계속 실행되는 가상 터미널 세션을 만들어 줍니다. 핵심 원리는 간단합니다 — tmux 서버가 서버 프로세스로 실행되고, SSH 클라이언트는 그 서버에 “접속”만 합니다. SSH가 끊겨도 tmux 서버는 계속 살아있고, 세션 안의 프로세스도 계속 돌아갑니다.
기본 사용법은 3단계입니다:
# 1. 새 세션 만들기
tmux new -s work
# 2. 세션 안에서 평소처럼 작업
# (빌드, 마이그레이션, 스크립트 실행 등)
# 3. 세션에서 빠져나오기 (작업은 계속됨)
# Ctrl+B 누른 뒤 Dtmux new -s work에서 -s work는 세션 이름입니다. 이름을 지정하면 나중에 쉽게 찾을 수 있습니다. 세션에서 빠져나오는 것을 detach(분리)라고 합니다. Ctrl+B는 tmux의 prefix 키입니다 — 이걸 먼저 누르고 그 다음에 D를 누르면 detach됩니다. 세션은 서버에 그대로 남아있고, 작업도 계속 돌아갑니다.
재접속: 이어서 작업하기
SSH로 다시 서버에 접속한 뒤, detach했던 세션에 다시 들어가려면:
# 세션에 다시 접속
tmux attach -t work
# 만약 세션이 하나뿐이면 이름 생략 가능
tmux attachattach -t work로 다시 들어가면, detach하기 전의 화면이 그대로 나타납니다. 커서 위치도 그대로, 출력 로그도 그대로, 빌드가 진행 중이었다면 진행 상황도 그대로 보입니다. 마치 화면을 “일시정지”했다가 “재생”한 것과 같습니다.
어떤 세션이 있는지 확인하려면:
# 세션 목록 보기
tmux ls
# 출력 예시:
# work: 1 windows (created Mon Jul 13 10:00:00 2026)
# build: 1 windows (created Mon Jul 13 11:30:00 2026)서버마다, 프로젝트마다 세션을 나눠서 쓰면 됩니다. 예를 들어 work 세션에서는 개발 서버를 돌리고, build 세션에서는 프로덕션 빌드를 돌리는 식으로 관리할 수 있습니다. 세션 이름을 프로젝트 이름이나 작업 종류로 지정해 두면, 나중에 tmux ls만 봐도 어떤 작업이 진행 중인지 한눈에 파악할 수 있습니다.
실전 시나리오: 긴 빌드를 안전하게 돌리기
VPS에서 Docker 이미지를 빌드하거나, 대용량 데이터베이스 마이그레이션을 실행할 때 tmux를 쓰는 전체 흐름을 보겠습니다.
# 1. SSH 접속
ssh user@example.com
# 2. tmux 세션 만들기
tmux new -s deploy
# 3. 빌드 실행 (시간이 오래 걸림)
docker build -t myapp .
# 또는
npm run build:prod
# 4. 중간에 와이파이가 끊겼다! -> 자동으로 detach됨
# 하지만 서버에서는 빌드가 계속 진행 중
# 5. 와이파이 복구 후 다시 SSH 접속
ssh user@example.com
# 6. 세션에 재접속
tmux attach -t deploy
# 7. 빌드 완료 확인 -> 로그도 그대로 보임tmux 없이 그냥 SSH에서 빌드를 돌렸다면 4번 단계에서 모든 것이 끝났을 것입니다. tmux를 쓰면 와이파이가 끊겨도, 노트북을 덮어도, 심지어 SSH 클라이언트를 종료해도 서버에서 작업이 계속됩니다.
스크롤과 복사: 로그를 확인하는 방법
tmux 세션 안에서는 일반 터미널처럼 마우스 스크롤이 기본적으로 작동하지 않습니다. 위로 스크롤해서 과거 로그를 보려면 copy mode에 진입해야 합니다. Ctrl+B를 누른 뒤 [를 누르면 copy mode가 됩니다. 이 상태에서 방향키나 Page Up/Down으로 자유롭게 스크롤할 수 있습니다. 빠져나올 때는 q나 Esc를 누릅니다.
copy mode에서 텍스트를 복사하려면, 시작 위치에서 Space를 누르고 방향키로 선택 영역을 잡은 뒤 Enter를 누르면 됩니다. 복사된 텍스트는 tmux 버퍼에 저장되며, Ctrl+B 다음 ]로 붙여넣을 수 있습니다. 빌드 에러 로그를 복사해서 다른 창에 붙여넣거나, 이슈 트래커에 올릴 때 유용합니다.
스크롤백 버퍼(저장되는 과거 로그 양)는 기본적으로 2,000줄입니다. 대용량 빌드 로그를 다루려면 ~/.tmux.conf에 set-option -g history-limit 50000처럼 설정해서 늘릴 수 있습니다. 빌드 중간에 스크롤해서 처음 부분의 에러를 확인해야 할 때 버퍼가 부족하면 곤란하니, 서버에 설정해 두는 것을 권장합니다.
여러 서버 동시 작업: pane 동기화
서버가 여러 대일 때 같은 명령을 모든 서버에서 실행해야 하는 경우가 있습니다. 예를 들어 5대 서버에 같은 보안 패치를 적용하거나, 같은 설정 파일을 배포하는 작업입니다. tmux의 pane 동기화 기능을 쓰면 분할된 모든 pane에 같은 키입력이 동시에 전송됩니다.
동기화를 켜려면 prefix 키 다음 :을 누르고 setw synchronize-panes on을 입력합니다. 이후 좌우로 5개 pane을 분할하고 각각 다른 서버에 SSH 접속해 둔 상태에서 명령어를 입력하면, 5개 서버에 동시에 명령이 실행됩니다. 작업이 끝나면 synchronize-panes off로 끄면 됩니다. Ansible이나 Chef 같은 구성 관리 도구가 있지만, 간단한 일회성 작업이나 긴급 패치에는 pane 동기화가 훨씬 빠릅니다.
주의할 점은 동기화 모드에서 실수로 rm이나 shutdown 같은 명령을 입력하면 모든 서버에 동시에 적용된다는 것입니다. 위험한 명령은 동기화를 끄고 개별 pane에서 실행하는 습관을 들이는 것이 안전합니다.
유용한 단축키 정리
tmux에서 자주 쓰는 단축키는 prefix 키(Ctrl+B)를 먼저 누르고 다음 키를 누르는 방식입니다:
| 단축키 | 기능 |
|---|---|
| Ctrl+B, D | detach (세션에서 빠져나오기, 작업은 유지) |
| Ctrl+B, C | 새 창(window) 만들기 |
| Ctrl+B, N | 다음 창으로 이동 |
| Ctrl+B, P | 이전 창으로 이동 |
| Ctrl+B, % | 화면 좌우 분할 |
| Ctrl+B, “ | 화면 상하 분할 |
| Ctrl+B, 방향키 | 분할된 화면 간 이동 |
한 세션 안에서 여러 창을 만들 수 있고, 창을 분할해서 동시에 여러 작업을 볼 수도 있습니다. 예를 들어 좌측 화면에서는 로그를 보고, 우측 화면에서는 명령어를 입력하는 식으로 작업할 수 있습니다. 창(window)은 탭처럼 전체 화면을 교체하는 단위이고, pane은 하나의 창 안에서 화면을 분할하는 단위입니다. 이 두 가지를 조합하면 하나의 세션에서 여러 서비스를 동시에 모니터링할 수 있습니다.
tmux 설치와 기본 설정
대부분의 리눅스 배포판에 기본 패키지 매니저로 설치할 수 있습니다:
# Ubuntu / Debian
sudo apt update && sudo apt install tmux
# CentOS / RHEL / Fedora
sudo dnf install tmux
# 확인
tmux -V
# tmux 3.2 이상 권장설치 후 별도 설정 없이 바로 tmux new -s work로 세션을 만들어 쓸 수 있습니다. 설정 파일(~/.tmux.conf)을 만들어서 마우스 스크롤 활성화, 기본 단축키 변경, 테마 설정 등을 커스터마이징할 수도 있습니다. 공식 tmux GitHub Wiki에 상세한 설정 가이드가 있습니다.
가장 많이 추가하는 설정은 마우스 지원입니다. set -g mouse on 한 줄을 넣으면 마우스 스크롤, 클릭으로 pane 이동, 드래그로 pane 크기 조절이 모두 가능해집니다. 터미널 작업에 익숙하지 않은 초보자도 tmux를 훨씬 쉽게 쓸 수 있게 해주는 설정입니다. 변경 후에는 tmux source-file ~/.tmux.conf로 즉시 적용하거나, 기존 세션을 detach했다가 다시 attach하면 됩니다.
nohup과의 차이
“nohup이나 screen으로도 되지 않나요?” 하는 분도 있을 것입니다. 맞습니다. nohup도 SIGHUP을 무시하게 해주고, screen도 tmux와 비슷한 기능을 제공합니다. 하지만 tmux가 더 많이 쓰이는 이유가 있습니다.
nohup은 백그라운드 실행만 해줄 뿐, 나중에 그 화면에 다시 접속할 수 없습니다. 로그는 파일로 남지만, 실시간으로 진행 상황을 보거나 상호작용할 수 없습니다.
screen은 tmux와 거의 같은 기능을 제공하지만, 개발이 느리고 기능이 적습니다. 화면 분할, 세션 관리, 스크립팅 기능 모두 tmux가 더 강력합니다.
tmux는 detach/attach, 화면 분할, 여러 창, 세션 관리를 모두 제공하면서도 활발히 유지보수되고 있습니다. VPS 작업의 표준 도구로 자리잡은 이유가 있습니다.
systemd 서비스와 tmux를 조합하면 더 강력한 환경을 만들 수 있습니다. 서버 재부팅 시 자동으로 tmux 세션을 생성하는 systemd 서비스 유닛을 등록해 두면, 재부팅 후에도 개발 환경이 그대로 복구됩니다. tmux new -d -s dev 명령을 systemd ExecStart로 지정하고, 서버 시작 시 자동 실행되게 설정하면 됩니다. 이렇게 하면 서버가 재부팅되어도 tmux attach -t dev 한 번이면 원래 작업하던 환경으로 돌아갈 수 있습니다.
실전 .tmux.conf: 바로 복사해서 쓰는 설정
tmux를 처음 설치하면 단축키가 익숙하지 않아서 불편합니다. 다음 설정은 실제 VPS 작업에서 자주 쓰는 구성입니다. 이 설정을 ~/.tmux.conf에 복사하면 마우스 스크롤, 직관적인 창 분할, 더 긴 스크롤백 버퍼를 바로 사용할 수 있습니다. 서버에 처음 접속해서 제일 먼저 하는 일이 바로 이 설정 파일을 만드는 것입니다.
# ~/.tmux.conf
# 마우스 지원 (스크롤, 클릭, 드래그)
set -g mouse on
# 스크롤백 버퍼 증가 (기본 2000 -> 50000)
set-option -g history-limit 50000
# 창 번호를 1부터 시작 (0은 키보드에서 너무 멈)
set -g base-index 1
setw -g pane-base-index 1
# | 로 좌우 분할, - 로 상하 분할
bind | split-window -h
bind - split-window -v
# 색상 지원
set -g default-terminal "screen-256color"이 설정의 핵심은 마우스 지원과 스크롤백 버퍼 증가입니다. 마우스를 켜면 터미널이 익숙하지 않은 사용자도 스크롤과 pane 이동을 쉽게 할 수 있습니다. 스크롤백을 50,000줄로 늘리면 긴 빌드 로그도 처음부터 끝까지 놓치지 않고 확인할 수 있습니다. 기본값인 2,000줄로는 대규모 빌드 로그의 앞부분이 잘리는 경우가 자주 있습니다.
창 분할 키를 |와 -로 바꾸는 것은 시각적으로 직관적이어서 추천합니다. Ctrl+B 다음 |를 누르면 화면이 좌우로 분할되고, -를 누르면 상하로 분할됩니다. 기본 단축키인 %와 "는 기호 자체가 분할 방향을 나타내지 않아서 처음에는 헷갈립니다. 이 설정 한 줄로 tmux 사용 경험이 크게 좋아집니다.
설정을 변경한 후에는 tmux source-file ~/.tmux.conf로 즉시 적용하거나 기존 세션에서 detach했다가 다시 attach하면 됩니다. 서버를 재부팅할 필요가 없다는 점을 기억하세요. 설정 파일만 만들어 두면 다음에 새 세션을 만들 때 자동으로 적용됩니다.
서버 재부팅 후 tmux 세션 자동 복구
VPS가 재부팅되면 tmux 서버 프로세스도 종료되면서 기존 세션이 모두 사라집니다. 재부팅 후에도 기본 작업 환경이 자동으로 준비되도록 systemd 서비스를 등록할 수 있습니다. 이 설정은 서버 시작 시 자동으로 tmux 세션을 하나 만들어 둡니다.
# /etc/systemd/system/tmux-dev.service
[Unit]
Description=Auto-start tmux session
After=network.target
[Service]
Type=oneshot
ExecStart=/usr/bin/tmux new-session -d -s dev
RemainAfterExit=yes
[Install]
WantedBy=multi-user.targetsudo systemctl enable tmux-dev로 등록하면 서버 재부팅 시 자동으로 dev라는 이름의 tmux 세션이 생성됩니다. 재부팅 후 SSH로 접속해서 tmux attach -t dev 한 번이면 바로 작업 환경으로 들어갈 수 있습니다. 개발 서버나 CI 서버처럼 항상 같은 환경이 필요한 경우에 특히 유용합니다.
주의할 점은 이 세션은 빈 세션이라는 것입니다. 재부팅 전에 돌고 있던 프로세스가 자동으로 복구되는 것이 아닙니다. 프로세스 자동 복구가 필요하다면 tmux-resurrect 플러그인을 사용하면 세션 상태를 주기적으로 파일로 저장하고 복원할 수 있습니다. tmux-continuum을 함께 쓰면 저장과 복원을 완전 자동화할 수 있습니다. 이 플러그인들은 TPM(Tmux Plugin Manager)을 통해 설치할 수 있습니다.
VPS 환경에서 tmux를 쓸 때 SSH 연결이 끊기는 것은 언제든 발생할 수 있습니다. 와이파이 불안정, 노트북 절전 모드, VPN 연결 해제 등 원인은 다양합니다. tmux 세션 안에서 작업하는 습관만 들여도 이런 상황에서 작업을 처음부터 다시 시작하는 일을 막을 수 있습니다. tmux new -s work 한 줄이면 충분합니다.
정리: 긴 작업은 tmux 세션부터
SSH로 서버에서 작업할 때, 특히 시간이 걸리는 작업(빌드, 마이그레이션, 대용량 다운로드)을 할 때는 tmux 세션 안에서 하는 것이 기본입니다. tmux new -s work로 세션을 만들고 작업하고, Ctrl+B D로 빠져나오고, tmux attach -t work로 다시 들어가는 것. 이 세 가지만 기억하면 SSH 끊김을 더 이상 두려워하지 않아도 됩니다.
다음에 VPS에서 긴 작업을 할 때는 tmux 세션부터 만드세요. 연결이 끊겨도 다시 이어할 수 있습니다. Nginx로 서비스를 배포하는 작업을 한다면 Nginx reverse proxy 설정 가이드도 함께 참고하세요.
