2026 가이드: Apple Silicon에서 스테이징·프로덕션 Mac CI 풀 분리

클라우드상의 모든 Mac을 “그냥 또 하나의 러너”로만 취급하는 플랫폼 팀은 결국 프로덕션 서명 키가 풀 리퀘스트 작업으로 새어 나가거나, 앱 스토어 심사와 동일한 하드웨어를 거치지 않은 빌드를 출하하는 상황에 직면합니다. 본 2026 가이드는 풀 분리가 필요한 조직을 구분하고, 한 장의 매트릭스로 세 가지 격리 모델을 비교하며, 시크릿 라우팅 규칙을 정리하고, SSH로 접속 가능한 전용 Mac mini M4 노드에서 바로 실행할 수 있는 구현 단계 아홉 가지를 제시합니다.

이미 Mac mini M4에서 셀프호스팅 GitHub Actions를 운영 중이라면, 두 번째 제품 라인이나 외부 기여자를 온보딩하기 전에 환경 분리는 반드시 넘어야 할 성숙도 관문입니다.

혼합 풀이 만드는 보안·릴리스 부채

Apple의 툴체인은 프로비저닝 프로필, Xcode 캐시, 파생 데이터, 공증 자격 증명처럼 오래 살아 있는 상태를 장려합니다. 엔지니어에게는 편리하지만, 동일한 사용자 계정이 포크된 워크플로와 릴리스 업로드를 모두 실행하면 위험합니다.

• 풀 리퀘스트 스크립트의 영향 반경: 악의적이거나 부주의한 run: 블록은 러너 홈 디렉터리의 파일을 읽을 수 있습니다. 프로덕션 App Store Connect API 키가 한 번이라도 디스크에 있었다면 그 범위 안에 있습니다.
• 비결정적 릴리스 품질: 스테이징에서 베타 Xcode를 설치하거나 Rosetta 설정을 바꾸면, 불변 이미지를 강제하지 않거나 호스트를 나누지 않는 한 다음 프로덕션 작업이 그 변경을 그대로 물려받을 수 있습니다.
• 감사 피로: 규정 준수 심사에서는 어떤 머신이 고객 데이터나 서명 자료에 닿았는지 묻습니다. 단일 풀이면 답이 “전부”가 되어 설문이 길어지고 출시 속도가 느려집니다.

의사결정 매트릭스: Mac CI 티어를 얼마나 강하게 격리할까

감사를 통과하는 시크릿·서명·승격 경로

격리는 하드웨어만이 아니라 자격 증명이 어떻게 이동하느냐의 문제입니다. 프로덕션 러너는 필수 검토자가 있는 GitHub Environments를 통해서만 시크릿을 받아야 하고, 스테이징 러너는 다른 환경 네임스페이스에서 가져와야 합니다. 두 환경이 같은 클라우드 리전을 가리키더라도 마찬가지입니다.

1. 시크릿을 티어에 매핑: App Store Connect 키, 엔터프라이즈 배포 프로필, 서드파티 SaaS 토큰을 목록화합니다. 고객 대면 바이너리를 출하할 수 있는 것은 오직 프로덕션 라벨 호스트에만 둡니다.
2. 승격 워크플로 사용: 스테이징 빌드는 서명 없거나 임시 서명 아티팩트를 만들고, workflow_dispatch 또는 보호된 브랜치에서만 실행되는 별도 워크플로가 runs-on: [self-hosted, macOS, prod]에서만 돌도록 합니다.
3. 사고 후 24시간 내 순환: 포크 PR이 잘못 태그된 러너에서 실행된 경우 키체인을 지우고 API 키를 무효화하는 온콜 체크리스트를 문서화합니다.
4. 디스크 스냅샷 분리: 스테이징 Mac에는 주간 정리 작업을 예약하고, 프로덕션 머신은 유지보수 윈도우에서만 변경 통제된 업그레이드를 받습니다.
5. 머신 ID 기록: 감사인이 어떤 물리 Mac이 특정 빌드에 닿았는지 추적할 수 있도록 일련번호나 NodeMac 인스턴스 식별자를 러너 이름 옆에 보관합니다.

라벨 치트 시트: 스케줄러를 정직하게

NodeMac 클라우드 Mac에 분리 풀을 배포하는 아홉 단계

다음 런북은 홍콩, 도쿄, 서울, 싱가포르, 미국 등 지역에서 NodeMac으로 전용 Mac mini M4를 SSH/VNC로 임대했다고 가정합니다. 연결 기본기는 도움말 문서를 참고하세요. GUI로 서명 문제를 디버깅할 때는 VNC 안내가 유용합니다.

1. 최소 두 대의 Mac mini를 준비합니다—스테이징용 한 대, 프로덕션용 한 대—Xcode 서명에 절대 닿지 말아야 할 AI 에이전트·자동화용 샌드박스 티어를 두려면 세 대가 낫습니다.
2. 별도 OS 사용자(runner-stg vs runner-prod)를 만들어 홈 디렉터리 유출이 경계를 넘지 않게 합니다.
3. 서로 다른 GitHub 러너 이름을 등록하고 해당 티어 라벨만 붙입니다. 동일 OS 사용자에 두 라벨 패밀리를 함께 등록하지 마세요.
4. Xcode 버전을 의도적으로 맞춥니다: 프로덕션은 단일 고정 빌드에 두고, 스테이징은 최대 한 단계 마이너까지만 앞서 컴파일러 회귀를 미리 잡습니다.
5. GitHub Environments에 프로덕션 보호 규칙을 설정하고, 첫 기여자에 대한 필수 검토자를 둡니다.
6. 스테이징에만 디스크 위생 자동화: 여유 공간이 120 GB 아래로 떨어지면 DerivedData를 정리하는 cron을 둡니다. 프로덕션은 캐시를 조용히 지우기보다 알림을 보냅니다.
7. 텔레메트리보내기: 러너 로그를 관측 스택으로 보내고, 프로덕션 Mac에서 작업 시간이 롤링 중앙값의 2배를 넘으면 알림—하드웨어 경합이나 잘못 라우팅된 작업의 전조입니다.
8. 분기별 게임 데이: 가짜 포크 PR로 프로덕션 라벨 스케줄을 시도하고, GitHub가 워크플로 그래프에서 차단하는지 확인합니다.
9. 롤백 문서화: 프로덕션에 잘못된 Xcode 업그레이드가 들어오면, 이전 .xip를 콜드 스토리지에 두고 45분 이내 재설치 연습을 합니다.

FAQ: 스테이징 vs 프로덕션 Mac CI 풀

스테이징과 프로덕션 CI에 물리적으로 별도의 Mac이 필요한가요?

항상 그런 것은 아니지만, 프로덕션 작업이 신뢰할 수 없는 풀 리퀘스트 워크플로를 실행하는 머신에서 스케줄되지 않도록 별도의 러너 ID, 라벨, 시크릿 범위가 필요합니다. 티어별 전용 Mac mini M4 노드가 가장 강한 격리 모델이며, 규제 팀이 감사 질문표에 답하는 방식과도 맞습니다.

프로덕션 Mac당 동시에 몇 개의 작업을 받는 것이 좋나요?

코드 서명 및 아티팩트 업로드를 하는 릴리스 빌드는 Mac당 프로덕션 작업 1개로 시작하세요. 스테이징 풀은 디스크 I/O, Swift 패키지 그래프 크기, UI 테스트가 시뮬레이터를 여러 개 띄우는지에 따라 M4당 가벼운 작업 2~4개까지 실행할 수 있습니다.

크로스 환경 오염을 가장 빨리 감지하는 방법은?

풀 리퀘스트 이벤트에서 시작됐는데 프로덕션 라벨을 쓰는 워크플로에 알림을 걸고, 스테이징 전용 호스트에 프로비저닝 프로필이나 App Store Connect 키가 있는지 모니터링하세요. 새 모바일 스쿼드를 온보딩할 때는 VNC로 현장 점검을 병행하면 좋습니다.

지리적으로 분산된 풀이 필요하면 HK, JP, KR, SG, US 노드에 Mac을 추가해 스테이징은 개발자가 매일 쓰는 네트워크 경로를 미러링하고, 프로덕션은 공증 엔드포인트에 가장 가까운 리전에 두세요. 한 대 호스트에 과도하게 올리지 말고 티어별 머신 규모를 잡으려면 NodeMac 요금제를 비교하세요.

Mac mini M4 하드웨어는 계층형 CI를 경제적으로 만듭니다. Apple Silicon은 Xcode가 병렬 워크로드에서도 만족할 만한 CPU·GPU·Neural Engine 처리량을 주면서, 유휴 전력은 전용 프로덕션 러너를 켜 두어도 낭비로 느껴지지 않을 정도로 낮습니다. NodeMac은 과도하게 공유된 VM이 아닌 전용 물리 Mac mini를 제공하며, SSH와 VNC를 모두 지원해 운영자가 서명 실패를 대화형으로 디버깅할 수 있습니다. 홍콩·일본·한국·싱가포르·미국을 아우르므로 엔지니어 옆에 스테이징을 두고 Apple 공증 인프라 옆에 프로덕션을 두는 구성을 자본 지출 없이 구현할 수 있습니다. 월 단위 임대로 TCO를 예측 가능하게 유지한 뒤, 분리 풀 모델을 검증하고 전체 플릿으로 확장하면 됩니다.