SSH 연결이 끊긴 뒤에도 tmux 작업은 계속 실행되나요?

작업을 tmux 세션 안에서 시작했고 tmux 서버와 작업 프로세스가 계속 살아 있다면 SSH 연결이 끊겨도 작업은 보통 이어집니다. 다시 접속한 뒤 세션 목록을 먼저 확인하고, 같은 명령을 바로 다시 실행하지 마십시오. 프로세스와 로그를 확인한 다음 필요한 경우 기존 세션에 다시 연결해야 합니다.

원격 Mac을 재시작하면 tmux 세션을 다시 불러올 수 있나요?

일반적인 tmux 분리 세션은 Mac 재시작 뒤 자동으로 복원되지 않습니다. 세션 상태는 tmux 서버 프로세스에 의존하기 때문입니다. 재시작 뒤에도 작업을 자동으로 시작해야 한다면 launchd나 CI 실행기처럼 부팅과 실패 처리를 담당하는 별도 관리자를 사용하고, 명령과 로그 경로도 함께 저장해야 합니다.

Mac이 잠자기에 들어가면 tmux 작업이 멈추는 이유는 무엇인가요?

tmux는 터미널 세션을 유지할 뿐 Mac의 전원 상태를 제어하지 않습니다. 호스트가 잠들면 네트워크 연결과 작업 실행이 제한될 수 있으며, 작업이 끝난 뒤 세션만 남아 보일 수도 있습니다. 원격 노드의 잠자기 정책을 확인하고, 임시 작업과 상시 작업에 서로 다른 전원 설정을 적용해야 합니다.

원격 tmux 세션에서 빌드 로그를 어떻게 확인하나요?

다시 SSH로 접속한 뒤 tmux 세션 목록을 확인하고, 정확한 이름을 지정해 기존 세션에 연결하십시오. 화면에 출력이 없다고 작업이 끝났다고 판단하지 말고 ps와 로그 파일을 함께 확인해야 합니다. 빌드 명령을 실행할 때 표준 출력을 파일에 기록하면 화면 스크롤이나 터미널 재연결에 의존하지 않고 결과를 검증할 수 있습니다.

장시간 실행할 스크립트는 tmux와 macOS 백그라운드 서비스 중 무엇이 적합한가요?

사람이 중간에 확인하는 컴파일, 테스트, 데이터 처리에는 tmux가 간단하고 적합합니다. 반면 부팅 뒤 자동 시작, 실패 시 재시도, 실행 계정과 로그 관리가 필요한 스크립트는 macOS 백그라운드 서비스나 CI 실행기가 더 알맞습니다. 재시작 뒤 사람이 다시 명령을 입력해야 한다면 이미 tmux만으로는 운영 요구를 충족하지 못한 것입니다.

tmux 원격 Mac 작업은 끊기면 멈출까? 2026 설정 안내

SSH가 끊겨도 tmux 안의 작업은 보통 계속 실행되지만, 잠자기와 재시작까지 보장하지는 않습니다. 이 글에서는 세션과 작업 프로세스를 구분하고, 로그 확인과 복구 시험을 거쳐 tmux와 백그라운드 서비스 중 알맞은 실행 방식을 선택하는 절차를 설명합니다.

SSH가 끊겨도 tmux 안에서 실행한 작업은 보통 계속됩니다. 다만 tmux는 잠자기, Mac 재시작, 프로세스 오류, 호스트 회수까지 막아 주지 않으므로, 이번 주에는 작은 테스트 작업으로 단절·잠자기·재시작을 차례로 검증한 뒤 운영 방식을 결정해야 합니다.

이 글은 다음 독자를 위한 안내입니다.

SSH로 원격 Mac에 접속해 빌드, 테스트, 데이터 처리 작업을 실행하는 개발자
세션 유지와 실제 무인 운영을 구분해야 하는 DevOps 엔지니어
원격 Mac의 네트워크, 전원 상태, 재시작 복구를 검수하는 플랫폼 담당자

tmux 원격 Mac 작업의 생존 범위부터 나눠야 합니다

SSH 연결, 로그인 셸, tmux 클라이언트, tmux 서버, 실제 작업 프로세스는 서로 다른 계층입니다. SSH 클라이언트가 끊기면 클라이언트 화면은 사라지지만, tmux 서버와 그 안의 셸 및 작업 프로세스가 남아 있으면 다시 연결할 수 있습니다.

tmux 공식 안내도 세션을 서버 프로세스 안에 두고, 클라이언트는 세션에 붙거나 떨어지는 역할을 한다고 설명합니다. 따라서 빈 터미널을 보고 작업이 끝났다고 판단해서는 안 됩니다. 먼저 세션과 프로세스, 출력 파일을 확인해야 합니다.

반대로 Mac이 잠들거나 재시작하면 판단이 달라집니다. tmux는 터미널 세션 관리자이지 전원 관리자나 작업 복구 관리자가 아닙니다. 일반적인 분리 세션은 tmux 서버가 종료되는 재시작 뒤까지 보존된다고 볼 수 없습니다. 이 경계는 tmux 공식 시작 문서와 tmux 공식 매뉴얼에서 확인할 수 있습니다.

실패 유형별로 확인할 항목을 분리합니다

상황	먼저 확인할 것	낮은 위험의 처리	계속 맡겨도 되는 작업
SSH만 끊김	세션 목록, 작업 PID, 로그	기존 세션에 다시 연결	사람이 확인하는 빌드와 테스트
셸이 종료됨	tmux 안에서 실행했는지	명령 재실행 전 프로세스 조사	실행 상태가 확인된 작업
Mac이 잠듦	전원 설정, 네트워크, 작업 상태	깨운 뒤 로그와 PID 비교	짧은 임시 작업
Mac이 재시작됨	부팅 시각, 세션 존재 여부, 로그	저장한 명령으로 안전하게 복구	수동 복구가 허용된 작업
프로세스가 오류로 종료됨	종료 상태, 오류 로그	원인 수정 후 재실행	재시도 경계가 명확한 작업

이 표에서 가장 중요한 구분은 “SSH 연결이 끊겼다”와 “작업 프로세스가 종료됐다”가 같은 사건이 아니라는 점입니다. 세션을 삭제하거나 소켓을 지우거나 호스트를 재시작하면 조사에 필요한 흔적이 사라질 수 있으므로, 원인 확인 전에는 그런 조작을 미뤄야 합니다.

첫 단계: 이름 있는 세션을 만들고 실행 위치를 고정합니다

새 접속마다 이름 없는 셸을 사용하는 방식은 재연결 뒤 대상을 찾기 어렵습니다. 프로젝트 경로와 실행 계정을 먼저 확인한 뒤, 의미 있는 세션 이름을 지정하십시오.

ssh <user>@<mac-host>
whoami
pwd
tmux new-session -s <task-name>
cd <project-directory>
<build-or-test-command> 2>&1 | tee <log-file>

<user>, <mac-host>, <task-name>, <project-directory>, <build-or-test-command>, <log-file>은 실제 값으로 바꾸되, 이 글의 점검 명령에는 비밀 키나 토큰을 직접 넣지 마십시오.

작업을 시작한 뒤에는 tmux의 분리 명령으로 세션을 남긴 채 SSH 연결을 종료할 수 있습니다. 다시 접속하면 다음 순서로 기존 세션을 찾습니다.

tmux list-sessions
tmux attach-session -t <task-name>

세션 이름이 보이지 않으면 곧바로 같은 빌드를 다시 시작하지 마십시오. 다른 사용자 계정으로 접속했거나, 다른 Mac에 연결했거나, 세션을 만들기 전에 일반 셸에서 명령을 실행했을 가능성이 있습니다.

둘째 단계: 빈 화면보다 PID와 로그를 먼저 확인합니다

재연결 뒤 화면에 새로운 출력이 없더라도 작업이 실행 중일 수 있습니다. 반대로 tmux 창이 남아 있어도 실제 프로세스가 이미 종료되었을 수 있습니다. 다음 정보를 함께 비교해야 합니다.

tmux list-sessions
tmux list-windows -t <task-name>
ps -ax | grep -E '<process-name>|<build-name>'
tail -n 80 <log-file>

확인할 기준은 세 가지입니다.

SSH를 끊기 전과 같은 사용자 계정인지 확인합니다.
작업 PID가 존재하고 프로젝트 경로가 예상한 위치인지 확인합니다.
로그의 마지막 줄이 정상 진행, 정상 종료, 오류 종료 중 무엇을 의미하는지 읽습니다.

PID가 바뀌었다는 사실만으로 작업이 사라졌다고 판단해서도 안 됩니다. 셸이 새로 만들어졌거나 하위 프로세스가 교체되었을 수 있습니다. 로그의 시간 흐름과 종료 상태를 함께 보십시오. 반대로 로그가 멈춘 상태에서 프로세스도 없다면, 기존 작업을 안전하게 재실행할 조건을 먼저 정해야 합니다.

빌드 로그를 파일로 남기는 방식은 터미널 스크롤보다 검수에 유리합니다. 로그 파일을 프로젝트와 분리된 보관 경로에 둘 경우에는 권한과 디스크 사용량도 확인해야 합니다. 인증 정보가 명령 인자나 로그에 노출되지 않는지도 점검하십시오.

셋째 단계: 새 셸의 환경과 기존 셸의 환경을 비교합니다

tmux 세션에 다시 연결했다고 해서 새로 연 셸의 환경이 모두 같아지는 것은 아닙니다. 로그인 셸, PATH, Homebrew 경로, 환경 변수, SSH Agent는 접속 방식과 셸 초기화 파일에 따라 달라질 수 있습니다.

다음 값을 기존 작업의 기록과 비교하십시오.

echo "$SHELL"
echo "$PATH"
echo "$HOME"
which tmux
which <tool-name>
env | sort
ssh-add -l

tmux 공식 FAQ는 새 클라이언트가 연결될 때 환경이 갱신되는 방식과 이미 실행 중인 세션의 환경이 자동으로 완전히 바뀌지 않는 경계를 설명합니다. 환경 문제를 작업 손실로 오해하지 않으려면 tmux 공식 FAQ를 기준으로 확인해야 합니다.

특히 다음 상황을 분리하십시오.

기존 창에서는 도구가 실행되지만 새 창에서는 command not found가 나오는 경우
HOME이 달라져 설정 파일이나 캐시를 찾지 못하는 경우
SSH Agent가 새 접속에 전달되지 않아 저장소 접근이 실패하는 경우
같은 세션 이름이 다른 계정에 있어 잘못된 작업을 보고 있는 경우

이 단계에서 PATH를 임시로 고치는 것은 가능하지만, 운영 작업에서는 셸 초기화 파일과 실행 계정을 명시하는 편이 안전합니다. 키 파일의 권한을 낮추거나 소켓을 삭제하는 조치는 접근 경로를 끊을 수 있으므로 원인과 복구 방법을 확인한 뒤 진행해야 합니다.

넷째 단계: 잠자기와 재시작은 tmux 바깥에서 검증합니다

Mac의 화면이 꺼진 것과 Mac 자체가 잠든 것은 같은 상태가 아닙니다. 디스플레이만 꺼졌다면 작업이 계속될 수 있지만, 시스템 잠자기 정책이 적용되면 네트워크와 프로세스 실행이 예상과 달라질 수 있습니다. macOS의 잠자기와 깨우기 설정 안내에서 현재 전원 설정을 확인하십시오.

임시로 작업을 지켜보는 동안에는 전원 상태를 별도로 관리할 수 있습니다. 그러나 임시 방지 명령을 장기 운영 정책으로 착각해서는 안 됩니다. 화면 끄기, 네트워크 깨우기, 완전한 잠자기 방지는 서로 다른 기능이며, 하나를 바꿨다고 나머지 상태까지 보장되지 않습니다.

재시작 시험은 더 엄격하게 다뤄야 합니다. tmux 서버가 종료되면 기존 세션도 사라질 수 있으므로, 다음 자료를 먼저 저장하십시오.

실행한 명령과 옵션
프로젝트 경로와 실행 계정
로그 파일 위치
필요한 환경 변수와 도구 경로
재실행해도 되는 조건과 중단해야 하는 조건

부팅 뒤 자동 실행이 필요하다면 tmux를 억지로 복원 장치처럼 사용하지 마십시오. macOS의 launchd 작업 생성 안내와 서비스 관리 문서를 검토해 실행 계정, 로그, 실패 처리, 중복 실행 방지를 설계해야 합니다.

다섯째 단계: 작업 성격에 따라 실행 방식을 선택합니다

tmux는 사람이 접속해 상태를 확인하는 인터랙티브 작업에 적합합니다. 예를 들어 원격 Mac에서 수동으로 빌드를 실행하고, 중간 로그를 읽고, 실패 원인을 조사하는 경우에는 설치 부담이 작고 복구 동작도 명확합니다.

반면 다음 조건이 있으면 백그라운드 서비스나 CI 실행기가 더 적합합니다.

Mac이 재시작된 뒤 자동으로 다시 시작해야 합니다.
실패 횟수와 재시도 간격을 기록해야 합니다.
사람이 접속하지 않아도 정해진 일정에 실행해야 합니다.
여러 작업이 겹칠 때 중복 실행을 막아야 합니다.
로그 보관과 종료 상태를 다른 시스템에서 읽어야 합니다.

이 구분은 macOS 서비스 관리 기능의 등록 설명과도 맞닿아 있습니다. 단순히 “항상 켜 둔 tmux 세션”을 만드는 것은 자동 복구 정책을 만드는 것과 다릅니다.

끊김 시험으로 실제 배포 방식을 결정합니다

설정값을 믿기보다 같은 계정과 같은 시험 작업으로 상태를 재현하십시오. 아래 목록은 원격 Mac을 운영에 투입하기 전 실행할 수 있는 최소 검수 절차입니다.

[ ] <task-name>으로 tmux 세션을 만들고 작업 PID와 로그 경로를 기록합니다.
[ ] 작업을 분리한 뒤 SSH 연결을 정상적으로 종료하고 다시 접속합니다.
[ ] tmux list-sessions로 세션을 찾은 뒤 기존 세션에 다시 연결합니다.
[ ] 작업 PID, 현재 경로, 로그의 마지막 상태를 끊기 전 기록과 비교합니다.
[ ] 클라이언트 네트워크를 끊은 뒤 작업이 계속되는지 확인합니다.
[ ] 장시간 유휴 상태에서 Mac의 실제 전원 상태와 네트워크 접근성을 확인합니다.
[ ] 수동 재시작 뒤 tmux 세션, 로그, 부팅 후 복구 절차를 확인합니다.
[ ] 같은 작업을 다시 실행해도 되는 조건과 실행하면 안 되는 조건을 문서화합니다.
[ ] 자동 시작이 필요한 작업은 launchd 또는 CI 실행기로 옮기고 실패 경계를 시험합니다.

시험 결과에 따라 작업을 세 등급으로 나누면 됩니다. 사람이 확인하는 단발성 작업은 tmux에 남깁니다. 재시작 뒤 수동 복구가 필요한 작업은 로그와 재실행 절차를 보강합니다. 무인 실행과 자동 복구가 필요한 작업은 백그라운드 서비스나 CI 조정기로 이전합니다.

자주 확인하는 tmux 원격 Mac 문제

SSH가 끊긴 뒤 tmux 작업은 계속 실행됩니다

tmux 안에서 시작한 작업이라면 SSH 클라이언트가 종료되어도 tmux 서버와 작업 프로세스가 살아 있는 동안 계속될 수 있습니다. 다만 이 결론은 잠자기나 재시작까지 포함하지 않습니다. 재접속 후 세션 목록, PID, 로그를 함께 확인하고 같은 명령을 중복 실행하지 않아야 합니다.

원격 Mac 재시작 뒤 세션을 찾을 수 없는 이유

재시작은 tmux 서버 프로세스를 종료시킬 수 있습니다. 따라서 분리된 세션이 재부팅 뒤 자동 복원된다고 가정하면 안 됩니다. 재시작 복구가 요구되면 실행 명령과 로그를 저장하고 launchd 또는 CI 실행기의 자동 시작 기능으로 전환해야 합니다.

잠자기 뒤 작업이 멈춘 것처럼 보이는 이유

tmux는 화면과 셸 세션을 유지하지만 호스트의 전원 정책을 바꾸지 않습니다. Mac이 잠들면 작업 실행과 네트워크 접근이 제한될 수 있으며, 깨어난 뒤에는 세션만 남아 있을 수 있습니다. 화면 꺼짐과 시스템 잠자기를 구분해 전원 설정과 작업 로그를 함께 확인하십시오.

빌드 로그를 잃지 않는 방법

작업 출력을 화면에만 남기지 말고 로그 파일에도 기록하십시오. 재접속 뒤에는 세션에 연결하기 전에 로그의 마지막 부분과 프로세스 상태를 읽는 것이 안전합니다. 로그 안에 키, 토큰, 개인 경로가 포함되지 않는지 확인하고, 로그가 보존되는 위치와 삭제 정책도 정해야 합니다.

tmux와 백그라운드 서비스의 선택 기준

작업 중간에 사람이 접속해 확인해야 한다면 tmux가 편리합니다. 부팅 자동 실행, 실패 재시도, 중복 방지, 중앙 로그가 필요하다면 macOS 백그라운드 서비스나 CI 실행기가 맞습니다. 장기 스크립트를 tmux 하나에 맡기는 방식은 재시작과 장애 복구 요구가 커질수록 한계가 분명해집니다.

현재 방식이 개인 컴퓨터에서 직접 실행하는 것이라면 전원 차단, 로컬 네트워크 단절, 작업 중단 뒤의 재접속 준비가 부담이 됩니다. 일반 클라우드 Linux 서버는 macOS 전용 도구 체인과 실제 Mac 환경을 제공하지 못하고, 가상 환경은 하드웨어와 전원 상태가 실제 원격 Mac과 다를 수 있습니다. 고정된 macOS 환경을 일정 기간 유지하면서 SSH와 웹 접속을 함께 사용해야 한다면 VPSMAC의 원격 Mac 환경이나 서울 노드 선택지를 검토할 수 있습니다. 다만 물리 장비가 반드시 필요하거나 장기간 고정 부하가 확실한 경우에는 직접 구매가 더 합리적일 수 있습니다.

tmux 원격 Mac 작업을 계속 사용할지는 “SSH 단절 뒤 살아남았는가” 하나로 결정하지 마십시오. 단절, 잠자기, 재시작 시험에서 로그와 복구 절차가 실제로 확인된 경우에만 현재 방식을 유지하고, 하루 종일 무인 실행해야 한다면 처음부터 macOS 서비스나 CI 조정기로 설계하는 편이 안전합니다.