맥 빌드 서버 고가용성: 2026년 아이오에스 재해 복구

출시 시간에 유일한 맥 노드가 오프라인이 되면, 노드가 평소 온라인이었다는 사실은 업무 연속성을 보장하지 못합니다. 대기 중인 작업은 멈추고, 이미 실행된 작업의 상태가 사라질 수 있으며, 배포 승인까지 연쇄적으로 지연됩니다.

먼저 세 가지 값을 따로 정의해야 합니다.

• 복구 시간 목표: 장애 감지부터 예비 노드가 작업을 받을 때까지 허용되는 시간
• 복구 시점 목표: 장애 시 다시 실행해야 하는 작업의 범위
• 출시 차단 범위: 개발 빌드, 테스트 빌드, 외부 배포 중 어디까지 멈추는지

이 값을 정하지 않고 노드 수부터 늘리면 과잉 구매가 발생합니다. 반대로 단일 노드만 유지하면 장애 때 선택지가 없습니다.

대부분의 기업은 처음부터 이중 활성으로 갈 필요가 없습니다. 우선 온간 예비 구조를 만들고, 실제 프로젝트가 예비 노드에서 서명된 산출물을 만드는지 확인하는 편이 안전합니다.

이번 주에는 다음 작업부터 시작합니다.

• [ ] 주 노드가 받는 작업을 중단하는 절차를 문서화합니다.
• [ ] 예비 노드의 작업 라벨과 접근 권한을 준비합니다.
• [ ] 같은 프로젝트를 예비 노드에서 빌드합니다.
• [ ] 서명된 산출물의 해시와 빌드 로그를 저장합니다.
• [ ] 전환 실패 시 사람이 개입하는 지점을 기록합니다.

운영 중인 엑스코드 버전을 바로 올리는 것은 장애 복구 설계가 아닙니다. 시스템 업데이트, 엑스코드 변경, 소프트웨어 개발 도구 모음 변경, 패키지 업그레이드는 모두 새로운 빌드 경로를 필요로 합니다.

주 사용 노드는 안정 버전을 유지합니다. 예비 노드는 다음 버전을 먼저 설치하고 실제 프로젝트로 검증합니다. 두 환경을 같은 시점에 바꾸면 문제가 생겼을 때 원인이 버전인지 인프라인지 구분하기 어렵습니다.

애플은 빌드 설정 파일로 프로젝트와 대상별 설정을 분리할 수 있다고 설명합니다. 이 파일에는 운영체제, 대상 플랫폼, 아키텍처, 빌드 형태별 조건을 기록할 수 있습니다. 따라서 설정을 작업자의 개인 맥이나 노드 내부 화면에만 두지 말고 저장소에서 검토 가능한 형태로 관리해야 합니다. 애플의 빌드 설정 파일 안내도 함께 확인합니다.

환경 기준선

다음 항목은 주 노드와 예비 노드에서 비교해야 합니다.

• 운영체제 버전과 보안 업데이트 상태
• 엑스코드 버전과 아이오에스 소프트웨어 개발 도구 모음
• 애플 실리콘 또는 인텔 계열 아키텍처
• 스위프트 패키지 잠금 파일과 외부 의존성
• 빌드 스킴, 배포 설정, 환경 변수
• 인증서, 프로비저닝 프로필, 키체인 접근 정책
• 저장소 접근용 에스에스에이치 자격 증명
• 빌드 캐시 사용 여부와 캐시가 없어도 성공하는지

애플의 빌드 시스템은 프로젝트 설정, 대상 설정, 빌드 단계와 스크립트를 조합해 산출물을 만듭니다. 따라서 “엑스코드만 같은 버전”인 상태는 동일한 환경이 아닙니다. 애플의 빌드 시스템 설명과 빌드 설정 기준 문서를 기준으로 차이를 확인해야 합니다.

두 대의 맥에서 엑스코드와 의존성을 어떻게 맞춥니까?

저장소에 잠금 파일과 빌드 설정 파일을 보관하고, 노드 준비 스크립트로 같은 순서의 설치를 실행합니다. 노드 전체 사용자 폴더를 복사하지 않습니다. 사용자 폴더에는 개인 키체인, 임시 캐시, 오래된 인증 정보가 섞일 수 있기 때문입니다.

맥 노드가 멈추는 방식에 따라 전환 절차가 달라집니다.

• 전원 중단: 호스트가 다시 켜져도 씨아이 러너가 자동으로 실행되는지 확인해야 합니다.
• 운영체제 무응답: 원격 재시작 명령이 작동하지 않을 수 있으므로 별도 관리 경로가 필요합니다.
• 암호화 디스크 잠금: 재부팅 뒤 저장 장치 잠금 해제가 필요할 수 있습니다.
• 원격 연결 중단: 노드가 살아 있어도 화면 공유나 에스에스에이치만 끊길 수 있습니다.

애플 실리콘 맥은 저장 장치 암호화와 보안 영역을 사용합니다. 파일볼트 복구 키는 24개의 문자와 숫자로 구성되며, 관리 조직은 복구 키를 별도 보관하고 사용 기록을 남겨야 합니다. 복구 키가 없으면 암호화된 디스크를 열지 못할 수 있습니다. 애플의 파일볼트 안내를 기준으로 복구 경로를 점검합니다.

주의: 원격 재시작이 성공했다는 로그만으로는 복구가 끝난 것이 아닙니다. 디스크 잠금 해제, 러너 온라인 상태, 저장소 접근, 서명된 테스트 산출물까지 확인해야 합니다.

예비 노드에서 다음 순서로 검증합니다.

1. 주 노드가 새 작업을 받지 않도록 라우팅을 중단합니다.
2. 실행 중인 작업의 상태와 마지막 로그 위치를 저장합니다.
3. 예비 노드의 원격 접속과 러너 상태를 확인합니다.
4. 필요한 경우 승인된 복구 키 절차로 저장 장치를 엽니다.
5. 러너 서비스와 빌드 도구가 자동으로 올라오는지 확인합니다.
6. 실제 프로젝트의 테스트 빌드를 실행합니다.
7. 배포용 서명 결과와 로그를 별도 저장소에 보관합니다.

깃허브 자체 러너는 운영체제와 하드웨어 구조를 라벨로 구분할 수 있습니다. 온라인 상태이고 유휴 상태인 러너가 조건에 맞지 않으면 작업은 대기합니다. 작업이 60초 안에 할당되지 않으면 다시 대기열로 돌아가며, 24시간 넘게 대기하면 실패할 수 있습니다. 깃허브 공식 러너 라우팅 문서를 확인해야 합니다.

맥 빌드 서버가 멈춘 뒤 예비 노드로 어떻게 전환합니까?

먼저 주 노드를 오프라인으로 표시하고, 예비 노드에 같은 운영체제·도구 모음·아키텍처 라벨을 부여합니다. 이후 테스트 작업을 한 건 실행하고, 성공한 뒤 배포 작업의 라우팅 조건을 예비 노드로 바꿉니다. 작업 대기열만 이동시키지 말고 러너 로그와 산출물 검증까지 완료해야 합니다.

빌드 대기열이 길어졌다고 곧바로 맥을 추가하면 안 됩니다. 먼저 빌드 시간이 늘어난 것인지, 동시에 실행할 작업 수가 부족한 것인지 구분해야 합니다.

다음 지표를 함께 봅니다.

• 작업별 대기 시간 추세
• 실행 중인 작업 수
• 작업별 실제 빌드 시간
• 실패 재시도 비율
• 캐시 적중률
• 배포 작업과 테스트 작업의 비율

대기 시간이 늘면서 실행 시간이 그대로라면 노드 수 부족일 가능성이 큽니다. 실행 시간 자체가 늘었다면 의존성 설치, 캐시, 소프트웨어 도구 모음 변경을 먼저 확인해야 합니다.

기본 용량과 피크 용량은 분리해 계산합니다.

총 운영 비용 = 상시 노드 비용 + 피크 노드 사용 비용 + 운영 인력 시간 + 저장 및 네트워크 비용

고정된 업무량은 장기 노드가 적합합니다. 출시 주간, 대규모 테스트, 엑스코드 이전 검증처럼 기간이 짧은 수요는 필요할 때 원격 맥을 추가하는 방식이 유리할 수 있습니다. 다만 실제 비용은 사용 기간, 노드 수, 운영 시간, 관리 작업에 따라 달라지므로 절약률을 미리 단정하면 안 됩니다.

깃랩 러너는 작업에 지정된 모든 태그를 만족해야 선택됩니다. 운영 환경에서는 보호된 브랜치와 보호된 태그에만 서명 작업을 허용하는 방식으로 라우팅 범위를 좁힐 수 있습니다. 깃랩 공식 러너 설정 문서를 기준으로 확인합니다.

기업용 맥 렌탈의 장기 비용을 검토할 때는 맥 미니 렌탈 가격 안내를 참고하되, 가격만 비교하지 말고 예비 노드 유지 비용과 복구 훈련 시간을 함께 계산해야 합니다. 주 노드와 별도 장소의 임시 노드가 필요한 경우에는 MESHLAUNCH의 원격 맥 이용 방식도 같은 기준으로 검토할 수 있습니다.

예비 노드가 코드를 컴파일했다고 해서 재해 복구가 성공한 것은 아닙니다. 다음 중 하나라도 빠지면 배포는 멈춥니다.

• 애플 배포 인증서와 개인 키
• 프로비저닝 프로필
• 애플 개발자 계정 권한
• 키체인 잠금 해제 절차
• 사설 저장소 접근용 에스에스에이치 키
• 외부 의존성 저장소와 패키지 캐시 접근
• 배포용 환경 변수와 비밀 값

애플 문서에 따르면 유효한 코드 서명 인증서가 키체인 경로에 없으면 빌드 오류가 발생할 수 있습니다. 프로비저닝 프로필은 권한을 승인하는 역할도 하므로 단순 파일 복사 대상으로 취급해서는 안 됩니다. 애플의 코드 서명 기준과 배포 서명 안내를 확인합니다.

아이오에스 서명 인증서를 예비 노드로 안전하게 옮기려면 어떻게 합니까?

인증서와 개인 키의 책임자를 먼저 정하고, 제한된 비밀 저장소에서 일회성으로 배포합니다. 설치 뒤에는 키체인 접근 권한, 프로필의 팀 식별자, 만료일, 서명 결과를 확인합니다. 사용한 자격 증명은 회수와 교체 절차까지 기록해야 합니다. 전체 사용자 폴더를 복사해 키체인을 동기화하는 방식은 피해야 합니다.

권한 목록에는 다음을 포함합니다.

• 발급 담당자
• 설치 담당자
• 폐기 승인자
• 복구 시 승인자
• 마지막 사용 시각
• 교체 예정일
• 폐기 완료 증거

재해 복구는 문서가 아니라 반복 가능한 작업이어야 합니다. 최소 한 개의 실제 아이오에스 프로젝트를 골라 주 노드의 작업 수락을 중단하고 예비 노드에서 검증된 산출물을 만드는 훈련을 진행합니다.

훈련 기록에는 다음을 남깁니다.

• 장애를 시작한 시각
• 주 노드의 작업 수락 중단 로그
• 예비 노드의 러너 온라인 로그
• 환경 기준선 비교 결과
• 저장소와 의존성 접근 결과
• 서명 성공 로그
• 빌드 산출물과 해시
• 사람이 개입한 단계
• 실패 원인과 재발 방지 조치

결과에 따라 냉간 예비를 유지할지, 온간 예비로 올릴지, 피크 기간에 원격 맥 노드를 추가할지 결정합니다. 정해진 방식이 항상 가장 저렴한 것은 아닙니다. 실제 복구 훈련에서 드러난 수동 작업과 실패 지점이 구매 규모를 결정해야 합니다.

재해 복구 승인 목록

• [ ] 주 노드 중단 절차가 승인되었습니다.
• [ ] 예비 노드가 원격으로 접근됩니다.
• [ ] 재시작 뒤 러너가 자동 복구됩니다.
• [ ] 암호화 디스크 잠금 해제 경로가 확인되었습니다.
• [ ] 운영체제와 엑스코드 기준선이 일치합니다.
• [ ] 패키지 잠금 파일로 의존성을 재현했습니다.
• [ ] 인증서와 개인 키의 책임자가 지정되었습니다.
• [ ] 프로비저닝 프로필의 만료와 팀 정보가 확인되었습니다.
• [ ] 실제 프로젝트의 서명 빌드가 성공했습니다.
• [ ] 배포 산출물과 로그를 감사 저장소에 보관했습니다.
• [ ] 피크 기간에 추가할 원격 맥의 승인 절차가 있습니다.
• [ ] 서비스 수준과 복구 범위를 계약 검토 항목에 반영했습니다.

현재 단일 맥 구매 방식은 장기적으로 고정 자산과 유지 보수 부담을 남기고, 피크 수요가 지나간 뒤에도 예비 자원이 유휴 상태가 되기 쉽습니다. 반대로 사내 한 곳에만 노드를 두면 전원, 네트워크, 원격 잠금 해제 문제가 동시에 발생할 수 있습니다. 기본 부하는 장기 노드로 유지하되, 실제 프로젝트로 검증할 예비 용량과 출시 피크 용량은 MESHLAUNCH의 주간 또는 월간 원격 맥으로 시험한 뒤 구매 규모를 정하는 편이 합리적입니다. 특히 기존 환경에 물리적 장비를 오래 보관하기 어렵다면, 먼저 전환 훈련을 진행하고 결과가 확인된 뒤 장기 계약 여부를 판단해야 합니다. 한국 지역 맥 미니 주문 안내도 검토 경로에 포함할 수 있습니다.

이번 주에는 가장 중요한 배포 흐름 하나를 골라 주 노드 작업 중단, 예비 노드 전환, 서명 산출물 검증까지 실행합니다. 훈련 결과가 기록으로 남지 않았다면, 맥 빌드 서버 고가용성은 아직 운영 상태가 아닙니다.