단주기 급증 빌드에서 가장 무서운 상황은 두 가지입니다. 머신은 열렸는데 큐에 붙지 않거나, 마감 압박으로 고권한 토큰을 Runner에 그대로 넣는 경우입니다. 클라우드 Mac이 준비된 직후 첫 시간에는 Runner 온라인, Git·아티팩트 도달, 자격 증명의 최소 분리를 한 번에 닫는 것이 우선입니다. 아래는 자체 호스팅 macOS Runner 기준 30–60분 안에 체크할 수 있는 순서입니다. 탄력 풀과 상주 노드 선택은 2026년 단주기 피크 빌드: GitHub Actions 자체 호스팅 macOS Runner는 클라우드 Mac 탄력 풀과 상주 노드 중 무엇을 쓸까? 지연·캐시·대기열 결정 매트릭스(실행 가능한 파라미터 목록)와 함께 보시고, 연계 직후 캐시를 어디에 둘지는 2026 단주기 클라우드 Mac CI: 원격 빌드 캐시(DerivedData/Pods/sccache)와 노드 로컬 디스크 비교—콜드 스타트·동기 대역폭·재사용 결정 매트릭스(실행 가능한 파라미터 목록)에서 이어서 정리하면 좋습니다.
30–60분 실무 체크리스트(순서대로)
각 행은 콘솔이나 로그로 바로 검증할 수 있게 썼습니다. 첫 실제 workflow를 돌려 보기 전에 터지는 문제를 줄이려는 목적입니다.
| 구간 | 작업 | 합격 기준 |
|---|---|---|
| 0–10분 | 전용 시스템 사용자, 절전·잠금으로 끊기지 않게 설정, 호스트 이름과 runs-on 라벨 일치. |
리스너 상주, 중복 등록 없음. |
| 10–25분 | Runner와 동일 셸에서 git ls-remote, Git·아티팩트 도메인에 curl -I; 필요 시 회사 DNS 고정. |
TLS·HTTP 상태 정상, 프록시나 체인 오설정 없음. |
| 25–45분 | 큐에 등록 후 checkout과 echo만 있는 최소 workflow로 라벨·동시 슬롯 검증. | queued에서 in_progress로 전환, 본기 로그에 흔적. |
| 45–60분 | 코드는 읽기 전용 Deploy Key, 아티팩트는 스코프가 좁은 토큰, 비밀은 키체인·시크릿 스토어. | 토큰 하나를 폐기해도 해당 단계만 영향. |
네트워크 자가 점검: 느림을 컴파일에서 떼어 내기
DNS와 첫 패킷 왕복은 종종 컴파일 시간으로 오인됩니다. Runner와 같은 환경에서 프로브를 실행하고 결과를 런북 첫 페이지에 붙여 두세요. 지역이 나뉜 팀이라면 호스팅 PoP와 Runner 리전 조합도 적어 두면, 대양 횡단 RTT를 컴파일 저하로 착각하는 일을 줄일 수 있습니다.
# Git 호스팅과 아티팩트 각각 curl -Iv https://github.com 2>&1 | head -n 20 git ls-remote https://github.com/your-org/your-repo.git HEAD # 서브모듈이 SSH면 known_hosts와 에이전트 확인 ssh -T [email protected]
HTTPS와 SSH 성능이 다르면 기업 프록시 허용 포트를 대조하고, 결론을 workflow 환경 템플릿에만 반영해 재사용하세요.
최소 권한 토큰: 아티팩트에 쓰기만 주고 저장소 삭제 권한은 주지 않기
「일단 내 PAT로 통과」는 피합니다. 코드는 읽기 전용 Deploy Key, 아티팩트는 fine-grained PAT나 머신 사용자의 스코프 토큰으로 나누고, 교체 시 영향 범위가 단계 단위로 남도록 합니다. Runner 작업 디렉터리와 전역 셸 프로파일에 평문 백업을 두지 않는 것이 원칙입니다. 도구별로 토큰 경계를 나누는 사고방식은 2026 OpenClaw를 MCP Server로 개발 워크플로에 붙이기: openclaw mcp serve부터 토큰 인증·도구 허용 목록·세션 격리까지의 실무 단계와 FAQ에서도 같은 맥락으로 다룹니다.
FAQ
온라인인데 잡이 안 잡힌다? Runner 그룹 권한, runs-on과 라벨 대소문자를 다시 확인하세요.
checkout만 유난히 느리다? shallow와 서브모듈을 모두 켠 상태인지 보고, 네트워크가 정상이면 클론 깊이를 줄인 뒤 스펙 업을 논의하세요.
새 토큰인데 401? NTP, 키 문자열에 섞인 줄바꿈, Runner 재시작 여부를 보고, 최소한의 curl로 재현하는 편이 긴 workflow 안에서 추측하는 것보다 빠릅니다.
클라우드 Mac mini에서는 연계가 더 단순해집니다
자체 Runner의 절반은 하드웨어, 나머지 절반은 깨끗한 macOS 베이스라인입니다. Apple Silicon Mac mini는 통합 메모리와 약 4W 수준의 대기 전력 덕분에 피크에 swap을 타며 CPU 이점을 잃는 일이 적고, 단주기 상주·탄력 풀의 표준 유닛으로 쓰기 좋습니다. Unix, Homebrew, SSH가 기본으로 갖춰져 있어 이 글의 네트워크 점검 명령을 로컬과 동일한 습관으로 적을 수 있습니다.
Gatekeeper·SIP·FileVault와 예측 가능한 업데이트 리듬은 임시 Windows 빌드기보다 컴플라이언스 설명이 쉽고, 소형 무팬 설계는 장기 운영 비용도 낮춥니다.
급증 빌드를 복제 가능한 연계 플로로 만들고 싶다면 VPSSpark 클라우드 Mac mini M4를 통일된 하드웨어 프로필로 삼는 것이 좋습니다——지금 바로 플랜 확인하고 새 노드에서도 Runner와 네트워크 점검을 같은 속도로 반복하세요.