tmux 공식 입문 문서는 터미널에서 세션을 분리한 뒤 나중에 다시 연결하는 흐름을 설명합니다. 세션 분리와 재접속 안내를 근거로 보면, SSH 연결이 끊긴 뒤 Xcode 빌드가 반드시 멈추는 것은 아닙니다. 다만 연결이 끊겼다는 사실만으로 빌드가 계속 실행 중이거나 성공했다고 판단할 수도 없습니다.
판단: 원격 Mac의 터미널에서
tmux로 빌드를 실행했다면 재접속해 세션을 확인합니다. 일반 SSH 터미널에서 실행했다면 새 연결로 프로세스와 로그, 결과 파일을 각각 확인합니다. 호스트 재시작이나 프로세스 종료까지tmux가 복구해 주지는 않습니다.
이 글은 불안정한 네트워크에서 원격 Xcode 빌드를 실행하는 독립 개발자, CI 디버깅 중 로그를 확인해야 하는 엔지니어, 원격 Mac 상태를 관리하는 운영자를 위한 안내입니다.
SSH 연결과 빌드 프로세스는 별개입니다
SSH는 로컬 컴퓨터와 원격 Mac 사이의 터미널 연결입니다. xcodebuild는 Xcode 프로젝트를 명령줄에서 빌드하거나 테스트할 때 사용하는 도구입니다. Apple의 Xcode 명령줄 도구 참고 문서는 이 도구의 명령과 사용 범위를 설명하지만, SSH 연결이 끊긴 뒤 특정 작업이 계속될지는 보장하지 않습니다.
연결이 끊겼을 때 확인해야 할 상태는 서로 다릅니다.
- SSH 클라이언트: 로컬 네트워크나 터미널이 끊겼는지 확인합니다.
- 원격 세션: 터미널 작업을
tmux가 유지하고 있는지 확인합니다. - 빌드 프로세스: 원격 Mac에서
xcodebuild가 아직 실행 중인지 확인합니다. - 호스트와 결과: Mac에 접근 가능한지, 로그와 빌드 결과물이 남았는지 확인합니다.
네트워크가 순간적으로 끊겼더라도 원격 호스트와 빌드 프로세스가 살아 있을 수 있습니다. 반대로 SSH 접속이 다시 된다고 해서 이전 빌드가 성공한 것은 아닙니다. 터미널이 종료되며 명령이 함께 종료됐거나, 빌드가 오류로 끝났을 수도 있습니다.
SSH가 끊긴 뒤에도 원격 Mac에서 xcodebuild가 실행 중인지 어떻게 확인하나요?
새 SSH 연결로 접속한 다음 프로세스와 로그를 살펴봅니다. 아래 검색은 참고용이며, 프로세스가 목록에 있다는 사실만으로 빌드 성공을 판단해서는 안 됩니다.
ps -axo pid,stat,etime,command | grep '[x]codebuild'
프로세스가 보이지 않으면 빌드가 이미 끝났거나 종료됐을 수 있습니다. 프로세스가 보여도 멈춰 있는지, 오류를 기다리는지, 정상 진행 중인지는 로그와 결과물로 추가 확인해야 합니다. 원격 Mac에 다시 연결하는 기본 절차는 SSH 연결과 개발 환경 설정 안내에서 확인할 수 있습니다.
연결이 끊긴 상황별로 확인할 항목
| 발생한 상황 | 우선 확인할 내용 | 다음 조치 |
|---|---|---|
| 네트워크만 끊겼을 가능성 | 새 SSH 연결 가능 여부, 빌드 프로세스, 로그 | 실행 중이면 상태를 계속 관찰하고 결과를 확인합니다 |
| 터미널을 닫았거나 명령이 종료됐을 가능성 | 프로세스 존재 여부, 로그 끝부분, 결과 파일 | 성공 여부를 판정한 뒤 필요하면 다시 실행합니다 |
| 원격 Mac에 접속할 수 없음 | 호스트 상태와 네트워크 경로 | 호스트 복구 전에는 빌드 상태를 단정하지 않습니다 |
| 호스트가 재시작됐거나 프로세스가 사라짐 | 시스템 상태, 기록된 로그, 남은 결과물 | 원인을 점검하고 작업을 재실행할지 결정합니다 |
이 표는 상황을 나누기 위한 출발점입니다. 단일 프로세스 조회 결과만으로 작업의 성공이나 실패를 확정하지 마세요. 특히 터미널에 남아 있던 출력은 세션이 사라지면 함께 확인하지 못할 수 있으므로, 빌드 로그를 파일로 남기는 편이 안전합니다.
SSH 재접속 후 실행 중인 빌드 세션에 어떻게 돌아가나요?
tmux는 원격 Mac에서 실행하고 있어야 합니다. 로컬 컴퓨터에서 tmux를 열어 두는 것만으로 원격 세션이 유지되지는 않습니다. 프로젝트의 tmux 입문 문서와 공식 매뉴얼은 세션을 분리하고 다시 연결하는 동작을 설명합니다.
tmux로 세션을 만들고 다시 연결하기
먼저 원격 Mac에 SSH로 접속합니다. tmux가 설치돼 있지 않다면 해당 Mac의 환경과 권한을 확인한 뒤 설치해야 합니다. tmux 설치 여부나 명령 사용법은 운영체제와 설치 방식에 따라 다를 수 있으므로, 대상 호스트에서 직접 확인합니다.
새 세션을 만들고 이름을 지정합니다.
tmux new -s ios-build
세션 안에서 프로젝트에 맞는 빌드 명령을 실행합니다. 아래는 형식 예시입니다. 스킴, 대상, 프로젝트 경로는 실제 프로젝트 설정에 맞게 바꿔야 합니다.
xcodebuild -scheme MyScheme -destination 'generic/platform=iOS' build > build.log 2>&1
빌드 출력을 build.log에 기록하면 터미널 화면을 놓쳤을 때도 로그를 확인할 수 있습니다. 로그 파일 위치와 결과물 경로는 프로젝트에서 지정한 값을 사용하세요. 예시 경로가 모든 프로젝트에 적용되는 것은 아닙니다.
작업을 계속 실행한 채 세션에서 빠져나오려면 tmux의 분리 키 조합을 사용합니다.
Ctrl-b를 누른 다음 d
이 동작은 세션을 터미널에서 분리하는 것이지 빌드를 종료하는 것이 아닙니다. 이후 SSH 연결이 끊기더라도 세션이 원격 호스트에 남아 있다면 다시 연결할 수 있습니다.
새 SSH 연결을 연 뒤 세션에 돌아갑니다.
tmux attach -t ios-build
세션 이름이 목록에 있는지 확인하려면 다음 명령을 사용할 수 있습니다.
tmux ls
세션에 돌아오면 빌드가 성공한 것으로 봐도 되나요?
아닙니다. 세션 화면은 작업 상태를 확인하는 단서일 뿐입니다. 빌드가 끝났는지, 명령이 실패했는지, 결과물이 생성됐는지는 별도로 검증해야 합니다.
로그와 결과 파일로 성공 여부 판정하기
가능하면 명령의 출력과 종료 상태를 함께 기록합니다. 예를 들어 다음처럼 실행하면 명령이 끝난 뒤 종료 상태를 로그에 남길 수 있습니다.
xcodebuild -scheme MyScheme -destination 'generic/platform=iOS' build > build.log 2>&1
result=$?
printf 'xcodebuild exit status: %s\n' "$result" >> build.log
이 기록은 명령이 완료된 뒤에만 추가됩니다. 세션에 다시 연결했을 때 프로세스가 계속 실행 중이라면 종료 상태 줄이 아직 없을 수 있습니다. 로그의 마지막 부분도 함께 살펴보세요.
tail -n 40 build.log
명령의 종료 상태와 로그만으로 배포 가능한 결과가 만들어졌다고 단정하지 말고, 프로젝트가 지정한 결과 경로에 파일이 실제로 생성됐는지 확인합니다. 테스트를 실행한 경우에는 테스트 결과도 확인해야 합니다. Apple은 테스트 실행과 결과 해석 안내에서 결과 확인 방법을 설명하며, 테스트 계획을 명령줄 작업에 연결하는 내용은 테스트 구성 안내에서 다룹니다.
로그가 없거나 일부만 남았다면 화면 출력만으로 성공을 추정하지 마세요. 프로젝트가 결과물을 저장하는 위치와 실제 파일 생성 여부를 확인한 뒤, 확인할 수 없는 항목은 미검증 상태로 남겨야 합니다.
재실행과 세션 복구 중 어느 쪽을 선택할까요?
아래 조건에 따라 진행하면 불필요한 재실행과 근거 없는 성공 판정을 줄일 수 있습니다.
- 새 SSH 연결이 되고,
tmux세션과 빌드 프로세스가 모두 확인되면: 세션에 다시 연결해 로그가 갱신되는지 관찰합니다. - 세션은 있지만 빌드 프로세스가 보이지 않으면: 로그 끝부분, 종료 상태, 결과 파일을 확인한 뒤 성공 또는 실패를 판정합니다.
- 프로세스는 보이지만 로그나 결과가 불분명하면: 완료를 선언하지 말고 프로세스 변화와 빌드 출력을 추가로 확인합니다.
- 호스트가 재시작됐거나 세션과 프로세스가 사라졌으면: 남은 기록과 결과물을 조사합니다. 재실행 전에는 작업이 중복 실행돼도 문제가 없는지 확인합니다.
- 결과 파일이 없고 성공 근거도 없으면: 환경을 점검한 뒤 빌드를 다시 실행합니다.
tmux가 빌드의 중단 지점부터 이어서 실행해 주지는 않습니다.
tmux가 해결하지 못하는 복구 상황
tmux는 터미널에서 분리한 세션을 다시 연결하는 데 유용하지만, 원격 Mac이 재시작되거나 시스템 오류가 나거나 빌드 프로세스가 종료되는 상황까지 해결하지는 않습니다. 디스크 공간 부족으로 빌드가 실패했을 수도 있습니다. 이런 경우에는 호스트의 상태와 시스템 기록, 빌드 로그, 결과물을 확인한 뒤 환경 문제를 해결하고 다시 실행할지 판단해야 합니다.
Xcode 명령줄 도구가 준비되지 않았다면 Apple의 명령줄 도구 설치 안내를 기준으로 원격 Mac의 개발 도구 상태를 점검합니다. 빌드 결과와 테스트 기록이 필요한 팀은 작업 전에 저장 위치와 보존 방식을 정하고, 실제 연결을 끊었다가 다시 접속하는 방식으로 복구 절차를 검증해야 합니다.
로컬 장비만으로 장시간 빌드를 운영하면 컴퓨터가 절전 상태가 되거나, 개발 환경이 macOS가 아니거나, 개인 작업과 빌드 작업이 자원을 함께 쓰는 문제가 생길 수 있습니다. 반면 원격 Mac은 macOS 도구 체인이 필요한 작업을 별도 호스트에서 실행하는 선택지입니다. 다만 물리 장비에 직접 연결해야 하거나 지속적인 중부하 작업이 필요한 경우에는 원격 사용 조건과 비용을 따져 직접 보유하는 편이 나을 수 있습니다.
원격 환경이 필요한지 먼저 판단하고, 네트워크 연결과 데이터 처리 조건도 확인하세요. 운영 조건을 살펴볼 때는 HopVM의 개인정보와 데이터 처리 안내를 참고할 수 있습니다. Mac을 구매하지 않고 Xcode 빌드 환경을 시험해 보려면 HopVM의 원격 Mac 이용 계획을 확인해 프로젝트의 도구 체인과 로그 보존 방식에 맞는지 검토하세요.
끊김 이후에도 이어갈 원격 빌드 환경을 준비하세요
HopVM의 전용 물리 맥을 대여해 원격 개발과 빌드 작업을 관리하세요.
