원격 Mac SSH 연결이 끊긴 뒤 빌드는 멈출까? 2026 지속 작업 방안

Apple 문서에서 xcodebuild의 종료 상태 0은 빌드가 성공적으로 끝났음을 뜻합니다. 반대로 SSH 창이 멈추지 않았거나 프로세스가 보인다는 사실만으로는 성공을 확인할 수 없습니다. Xcode의 종료 상태 설명을 기준으로 보면, 원격 Mac SSH 연결이 끊긴 뒤의 빌드는 재접속 가능한 세션에 넣고 로그, 종료 상태, 결과물을 따로 보존해야 안전합니다. 반복 빌드는 CI Runner나 관리되는 백그라운드 작업으로 넘겨야 합니다.

이 글은 로컬 Mac이 없고 SSH로 원격 Mac에서 Archive와 테스트를 실행하는 Windows·Linux 개발자, 야간 빌드와 TestFlight 배포를 운영하는 작은 팀, 네트워크가 끊긴 뒤 작업 상태를 판별해야 하는 운영자를 위한 내용입니다.

다음 순서로 판단하면 됩니다.

• 빌드 시작 전: 직접 연결된 SSH 셸이 아니라 재접속 가능한 세션 또는 자동 실행 환경을 선택합니다.
• 빌드 실행 중: 표준 출력, 오류 출력, 종료 상태, 결과물 경로를 별도로 기록합니다.
• SSH 재접속 후: 화면이 다시 보이는지보다 프로세스, 로그, xcresult, xcarchive를 확인합니다.
• 이번 주: 같은 작업을 세 번 재현해 SSH 단절, 사용자 로그아웃, 원격 Mac 재시작 뒤 복구 여부를 기록합니다.

직접 SSH에 접속한 뒤 다음처럼 xcodebuild를 전면에서 실행하면, 연결이 끊겼을 때 결과를 일반화할 수 없습니다.

xcodebuild \
  -workspace "<PROJECT>.xcworkspace" \
  -scheme "<SCHEME>" \
  -configuration Release \
  archive \
  -archivePath "<ARCHIVE_PATH>/<APP>.xcarchive" \
  > "<LOG_PATH>/archive.out.log" \
  2> "<LOG_PATH>/archive.err.log"
printf '%s\n' "$?" > "<LOG_PATH>/archive.exit"

위 명령은 로그와 종료 상태를 남기는 예시입니다. 다만 명령 자체가 SSH 연결과 독립된다는 뜻은 아닙니다. 작업을 어떤 셸과 세션에서 시작했는지가 먼저 확인되어야 합니다.

SSH 연결은 원격 Mac의 Remote Login을 통해 로그인하는 통로입니다. Apple은 Remote Login 설정과 SSH 접속 형식을 설명하지만, 연결 종료 뒤 실행 중인 셸과 자식 프로세스가 항상 같은 방식으로 처리된다고 보장하지는 않습니다.

실제 점검에서는 다음 세 결과를 분리해야 합니다.

1. 작업 자체가 끝난 경우
   셸이 종료되면서 xcodebuild도 끝났을 수 있습니다. 이때는 archive.exit와 결과물 경로를 확인해야 합니다.

2. 작업은 계속됐지만 화면 기록을 잃은 경우
   빌드는 끝났지만 SSH 창에서 보던 출력만 사라질 수 있습니다. 별도 로그가 없으면 경고와 오류를 나중에 복원하기 어렵습니다.

3. 프로세스는 남았지만 실제 진행이 막힌 경우
   서명, 사용자 로그인, 시뮬레이터, Keychain 접근을 기다리며 프로세스가 살아 있을 수 있습니다. 프로세스가 존재한다는 사실은 성공의 증거가 아닙니다.

따라서 top이나 ps의 화면만 보고 재실행해서는 안 됩니다. 같은 버전과 빌드 번호를 다시 만들면 중복 Archive, 잘못된 업로드, 오래된 결과물 선택이 발생할 수 있습니다.

한 번 실행하는 Build, Test, Archive라면 재접속 가능한 터미널 세션을 사용할 수 있습니다. 중요한 점은 도구 이름보다 세션이 사라져도 명령이 어떤 방식으로 유지되는지와 로그가 어디에 남는지를 검증하는 것입니다.

실행 절차는 다음과 같습니다.

1. 원격 Mac에서 프로젝트, Scheme, 서명 자산, 저장 공간을 먼저 확인합니다.
2. 재접속 가능한 터미널 세션을 만들고 세션 이름을 작업 번호와 연결합니다.
3. xcodebuild의 표준 출력과 오류 출력을 서로 다른 로그 파일에 저장합니다.
4. 종료 상태를 별도 파일에 기록하고 Archive 경로를 고정합니다.
5. 일부러 SSH 연결을 끊습니다.
6. 다시 로그인해 세션에 재접속하거나 백그라운드 프로세스와 로그를 확인합니다.
7. 종료 상태, 로그의 마지막 줄, xcarchive 또는 xcresult의 존재를 함께 확인합니다.

테스트 결과를 남길 때는 다음처럼 기록하면 됩니다.

작업 번호: <JOB_ID>
시작 시각: <START_TIME>
빌드 번호: <BUILD_NUMBER>
로그 경로: <LOG_PATH>
결과물 경로: <ARCHIVE_PATH>
종료 상태: <EXIT_CODE>
재접속 시각: <RECONNECT_TIME>
판정: 성공 / 실패 / 재검증 필요

Apple의 Xcode 명령줄 도구 참고 자료는 명령줄에서 사용할 수 있는 Xcode 작업을 확인하는 기준으로 사용할 수 있습니다. 여기서도 문서의 명령 사용법과 SSH 단절 뒤 세션 유지 여부는 별개의 문제이므로, 운영 환경에서 직접 끊어 보는 검증이 필요합니다.

긴 작업을 안정적으로 운영하려면 다음 단계를 분리해야 합니다.

• Archive: 서명된 앱 보관 파일인 xcarchive를 만드는 단계입니다.
• exportArchive: 보관 파일에서 배포용 앱 패키지를 내보내는 단계입니다.
• 업로드 명령: 생성된 패키지를 App Store Connect로 전송하는 단계입니다.
• 백그라운드 처리: 업로드 뒤 App Store Connect가 빌드를 처리하고 배포 대상으로 표시하는 단계입니다.

Apple의 Archive 및 내보내기 절차와 베타 테스트 및 출시 배포 흐름은 이 단계가 같은 결과가 아니라는 점을 확인하는 자료입니다.

업로드 명령이 성공해도 App Store Connect의 처리가 끝났다는 뜻은 아닙니다. 네트워크가 다시 연결된 뒤에는 전체 파이프라인을 무조건 처음부터 실행하지 말고 다음을 확인합니다.

• xcarchive가 완성되어 있는가
• export 폴더와 배포 파일이 남아 있는가
• 업로드 명령의 종료 상태가 성공인가
• 앱 버전과 빌드 번호가 이미 전송되었는가
• App Store Connect에서 같은 빌드가 처리 중인지 실패했는가

이미 업로드된 빌드를 다시 보내기 전에 버전과 빌드 번호를 대조해야 합니다. 파일이 남아 있고 업로드만 실패했다면 업로드 단계만 재시도할 수 있지만, Archive가 불완전하면 이전 결과물을 성공한 것으로 간주해서는 안 됩니다.

모든 작업을 같은 방식으로 운영하면 관리 비용이 커집니다. 아래 표는 도구의 기능 목록이 아니라, 작업 장면에 따른 선택 기준입니다.

반복 제출, 야간 테스트, 정기 배포는 사람이 SSH로 접속해 시작하는 방식에서 분리하는 편이 낫습니다. CI Runner는 실행 기록과 작업 단위를 관리하기 쉽고, launchd는 시스템 시작 또는 사용자 로그인과 연결된 작업에 사용할 수 있습니다. Apple의 launchd 작업 구성 설명을 참고하되, 사용자 작업과 시스템 작업의 권한 문맥은 동일하지 않습니다.

Apple의 프로세스와 로그인 세션 설명처럼, 작업이 실행되는 계정과 로그인 상태를 분리해서 확인해야 합니다.

주의: launchd 등록, 백그라운드 권한 변경, 프로세스 종료는 영향 범위를 먼저 기록해야 합니다. 기존 작업을 중단할 수 있으므로 등록 전 설정 파일을 백업하고, 실패하면 해당 파일을 제거하거나 이전 파일로 되돌리는 절차를 함께 준비합니다.

순수 명령줄 Build와 Test는 로그인 상태의 영향을 상대적으로 덜 받을 수 있지만, 모든 iOS 작업이 같은 조건은 아닙니다. 시뮬레이터 테스트, Keychain 서명, 그래픽 승인 창이 포함되면 다음 네 가지 원인을 나눠야 합니다.

• 네트워크 연결이 끊겼는가
• 원격 Mac의 사용자 세션이 종료되었는가
• Keychain이 잠겼거나 접근 승인이 필요한가
• Simulator 또는 그래픽 세션이 준비되지 않았는가

테스트 작업은 xcresult와 Xcode 테스트 결과 해석 자료를 함께 확인해야 합니다. Keychain 접근을 무조건 허용하거나 보안 설정을 넓히는 방식은 기본 해결책이 아닙니다. 변경 전에는 대상 키체인, 영향받는 계정, 복구 방법을 기록하고, 변경 후에는 원래 설정으로 되돌려 서명 작업을 다시 검증합니다.

원격 Mac이 재시작된 뒤 자동으로 작업을 복구해야 한다면, 먼저 CI Runner나 launchd가 올바른 사용자 계정으로 시작되는지 확인합니다. 로그인 세션이 필요한 작업을 시스템 시작 작업으로만 등록하면 프로세스는 시작되어도 서명이나 시뮬레이터 단계에서 멈출 수 있습니다.

아래 점검표는 이론이 아니라 실제 배포 전에 실행할 승인 기준입니다.

• [ ] Archive가 실행되는 동안 SSH 연결만 끊고 다시 로그인합니다.
• [ ] 재접속 뒤 프로세스 상태와 로그의 마지막 기록을 확인합니다.
• [ ] 종료 상태 파일이 존재하고 값이 성공인지 확인합니다.
• [ ] xcarchive, xcresult, export 결과물이 실제 경로에 남아 있는지 확인합니다.
• [ ] 사용자를 로그아웃한 뒤 테스트와 서명 작업의 결과를 비교합니다.
• [ ] 원격 Mac을 재시작한 뒤 CI Runner 또는 launchd 작업이 다시 시작되는지 확인합니다.
• [ ] 재시작 뒤 작업이 이전 작업을 중복 실행하지 않는지 확인합니다.
• [ ] 이미 업로드된 버전과 빌드 번호를 확인한 뒤 업로드 재시도를 결정합니다.
• [ ] 실패한 작업이 조회 가능한 로그와 실패 상태를 남기는지 확인합니다.
• [ ] 권한이나 Keychain 설정을 변경했다면 원래 설정으로 되돌리는 데 성공합니다.

판정 기준도 미리 정합니다. SSH만 끊어도 작업이 사라지거나 로그가 불완전하면 임시 수동 방식에서 멈춰야 합니다. SSH 단절은 통과하지만 사용자 로그아웃이나 재시작에서 실패하면 CI Runner 또는 관리되는 백그라운드 작업으로 올려야 합니다. 세 검증을 모두 통과해도 GUI 승인과 서명 단계는 별도 출시 테스트를 남겨야 합니다.

개인 컴퓨터나 임시 서버를 계속 켜 두는 방식은 초기 비용을 아낄 수 있지만, 전원 절전, 네트워크 변경, 사용자의 로그아웃, 저장 공간 부족 때문에 야간 빌드가 끊길 수 있습니다. 로그가 로컬 터미널에만 남거나 재시작 뒤 자동 복구가 없으면 장애 원인도 추적하기 어렵습니다.

반대로 JEXCLOUD의 원격 Mac을 사용하면 장기간 온라인 상태가 필요한 빌드 환경과 개발용 Mac을 분리할 수 있습니다. 원격 Mac 환경과 이용 방식을 먼저 확인한 뒤, 실제 작업 빈도와 로그인 세션 요구 사항을 기준으로 선택하는 편이 합리적입니다. 장기 고정 부하가 있고 물리 장치나 직접 연결된 주변 기기가 필요하다면 Mac을 직접 보유하는 편이 맞을 수 있습니다. 그러나 임시 Archive, 야간 Test, TestFlight 업로드처럼 지속 온라인 환경이 필요하고 개인 컴퓨터를 계속 켜 둘 수 없다면 원격 Mac 대여가 더 관리하기 쉬운 선택이 될 수 있습니다.

이번 주에는 가장 긴 Archive 하나를 골라 SSH 단절과 재시작 검증부터 진행하면 됩니다. 결과물이 보존되지 않거나 자동 복구가 되지 않는다면 원격 Mac 대여 환경 선택을 검토하고, 새 환경에서도 같은 점검표를 다시 실행해야 합니다. 연결이 끊기지 않는 것보다 중요한 기준은 작업 상태를 다시 확인할 수 있고, 중복 실행 없이 다음 단계로 이어갈 수 있는가입니다.