macOS 14 라벨이 저장소 검색에서는 보이지 않는데, 빌드 작업이 어디서 실행되는지 확신하기 어렵습니다.
먼저 조직·저장소·재사용 워크플로·실제 실행 기록을 함께 조사하고, 확인된 작업을 업무별로 검증하세요. GitHub는 macOS 14 Runner 이미지가 2026년 11월 2일 퇴역한다고 공지했습니다. 자세한 사항은 GitHub의 퇴역 공지에서 확인할 수 있습니다.
GitHub 조직 관리자: 저장소마다 오래된 Runner 라벨을 쓰는지 확인해야 합니다.
CI 플랫폼 책임자: 재사용 워크플로, 동적 설정, 실행 기록까지 조사해야 합니다.
개발·출시 책임자: 빌드와 테스트, 배포 작업의 마이그레이션 검수 증거가 필요합니다.
마지막 확인: 2026년 10월 8일. 퇴역 날짜, 대상 라벨, 대체 라벨과 임시 중단 일정은 GitHub 공식 공지를 기준으로 다시 확인하세요.
조직 전체의 조사 범위
한 번의 코드 검색은 시작점이지, 조직 전체를 조사했다는 증거가 아닙니다. 저장소 목록과 접근 여부, 조사한 기본 브랜치, 활성 브랜치와 실행 기록의 범위를 함께 남겨야 합니다. 보관 저장소나 접근할 수 없는 저장소도 결과에서 빠뜨리지 말고 예외로 표시하세요.
GitHub Actions macOS 14 Runner는 언제 퇴역하나요?
GitHub 공지에 따르면 macOS 14 Runner 이미지는 2026년 11월 2일 퇴역합니다. 대상 라벨은 macos-14, macos-14-large, macos-14-xlarge입니다. 이 날짜와 라벨은 퇴역 공지의 대상 범위에 연결해 내부 점검 기록에도 남기세요. 이는 공지된 호스팅 Runner 이미지의 퇴역이며, 자체 관리하는 Mac의 상태까지 같은 일정으로 바뀐다는 뜻은 아닙니다.
주의: 공지된 임시 brownout 일정과 대체 라벨은 변경될 수 있습니다. 날짜나 대체 라벨을 문서에 옮겨 적을 때는 공지 원문을 다시 열어 확인하세요. 대체 라벨이 있다는 사실만으로 프로젝트의 호환성이 검증된 것은 아닙니다.
조직 저장소 인벤토리를 기준으로 다음 항목을 기록하세요.
- 저장소 이름과 담당 팀
- 조사한 브랜치와 워크플로 파일
- 접근하지 못했거나 보관된 저장소와 그 사유
- 최근 실행 기록을 확인할 수 있었는지
- 조사 담당자, 확인 시점, 후속 조치
라벨 검색과 설정 출처
macos-14 Runner 라벨을 쓰는 워크플로는 어떻게 찾나요?
먼저 조직 안의 접근 가능한 저장소에서 macos-14, macos-14-large, macos-14-xlarge를 검색합니다. 그다음 호출되는 재사용 워크플로와 생성 설정까지 따라가세요. runs-on은 문자열뿐 아니라 배열이나 표현식으로 구성될 수 있으므로, 단순 문자열 일치만으로 검색을 마치면 동적 설정을 놓칠 수 있습니다. 워크플로 구문 문서와 Runner 선택 문서를 함께 참고하세요.
검색 결과마다 설정을 작성한 곳과 그 설정을 실제로 사용하는 곳을 나누어 적습니다. 템플릿만 고치고 이미 복사된 워크플로를 놓치거나, 호출자만 변경하고 재사용 워크플로의 기본값을 남기는 실수를 막을 수 있습니다.
| 점검 위치 | 확인할 내용 | 결과에 남길 증거 |
|---|---|---|
| 저장소 워크플로 | runs-on에 고정 라벨이 있는지 확인합니다. |
저장소 경로, 파일, 작업 이름 |
| 재사용 워크플로 | 입력값, 기본값, 호출 위치를 함께 확인합니다. | 재사용 파일과 호출자 경로 |
| 매트릭스·표현식 | 라벨이 변수, 조건, 매트릭스에서 만들어지는지 확인합니다. | 참조 변수와 분기 조건 |
| 생성 설정 | 템플릿이나 스크립트가 워크플로를 생성하는지 확인합니다. | 생성 원본과 생성 결과 위치 |
재사용 워크플로의 macOS Runner 라벨은 어디까지 확인해야 하나요?
호출하는 워크플로만 보지 말고, 재사용 워크플로 내부의 runs-on 및 입력값 전달 경로를 확인하세요. 호출자에서 라벨을 넘기는지, 재사용 쪽에서 기본 라벨을 정하는지에 따라 수정 위치가 달라집니다. GitHub의 재사용 워크플로 문서를 기준으로 호출 관계와 값을 기록하면 검수자가 변경 지점을 다시 추적할 수 있습니다.
표현식으로 Runner를 선택한다면 변수의 값이 어디서 정해지는지도 확인해야 합니다. 컨텍스트 문서와 표현식 문서를 참고해 조건식과 입력값을 추적하세요. 예를 들어 기본 브랜치에 라벨 문자열이 직접 없더라도, 조직 변수나 호출 입력을 통해 런타임에 값이 만들어질 수 있습니다.
실제 실행 기록과 업무 영향
정적 검색 결과만으로 작업이 실제로 실행되는지, 어느 이벤트에서 사용되는지 알 수 없습니다. 반대로 최근에 실패하지 않았다는 이유로 영향이 없다고 판단해서도 안 됩니다. 특정 브랜치에만 연결된 검증이나 수동 실행, 정기 회귀, 출시 작업은 최근 실행이 없더라도 퇴역 영향권일 수 있습니다.
실행 기록에서는 워크플로 이름, 이벤트 종류, 브랜치, Runner 라벨, 확인 가능한 최근 결과를 한 행에 묶으세요. GitHub의 워크플로 실행 REST API는 실행 기록을 조회할 때 참고할 수 있습니다. API 결과만 저장하지 말고, 해당 실행이 어떤 저장소와 업무 흐름에 속하는지 내부 목록에 연결해야 합니다.
| 작업 종류 | 놓치기 쉬운 조건 | 영향과 검수 증거 |
|---|---|---|
| PR 검증 | 기본 브랜치 밖의 변경에서만 실행될 수 있습니다. | 이벤트·브랜치와 검증 결과 |
| 예약 회귀 | 실행 간격이 길어 최근 기록에 나타나지 않을 수 있습니다. | 스케줄 설정과 확인 가능한 실행 기록 |
| 서명·배포 | 수동 승인이나 특정 환경 조건에 묶일 수 있습니다. | 배포 단계, 승인 조건, 출시 검수 결과 |
| 생성형·조건부 작업 | 입력값이나 표현식에 따라 다른 Runner를 선택할 수 있습니다. | 조건식, 입력값, 실제 선택된 라벨 |
모든 저장소가 점검됐는지 어떻게 확인하나요?
조직의 저장소 목록과 점검 결과를 대조하고, 결과가 없는 저장소는 “영향 없음”으로 처리하지 마세요. 접근 불가, 보관 상태, 소유자 미확인, 실행 기록 미확인처럼 이유와 책임자를 남겨야 합니다. “검색 결과가 없음”과 “저장소를 조사하지 못함”을 서로 다른 상태로 관리하면 누락 여부를 검수할 수 있습니다.
마이그레이션 검수와 완료 기준
대체 라벨은 GitHub의 최신 공지에서 확인하되, 조직의 프로젝트에서 빌드와 테스트, 출시 과정이 통과하는지 따로 검증해야 합니다. 공식 권고는 검수의 입력 자료이지, 프로젝트별 승인 결과가 아닙니다. Xcode 버전 고정, 서명 자산, 캐시, 비밀 정보, 배포 환경처럼 작업에 필요한 조건을 실제 파이프라인에서 확인하세요.
이 체크리스트를 저장소별로 완료하고, 미확인 항목이 있으면 완료로 간주하지 마세요.
- [ ] 조사 대상에 조직 내 관련 저장소와 예외 저장소가 모두 포함되어 있습니다.
- [ ] 기본 브랜치 외에 유지 중인 브랜치와 실제 워크플로 경로를 확인했습니다.
- [ ] 세 가지 퇴역 라벨을 고정 문자열뿐 아니라 입력값과 표현식에서도 조사했습니다.
- [ ] 재사용 워크플로의 정의 위치와 모든 확인 가능한 호출 위치를 연결했습니다.
- [ ] 템플릿이나 생성 설정이 있다면 원본과 생성된 워크플로를 함께 대조했습니다.
- [ ] PR, 예약 실행, 수동 실행, 서명·배포 작업의 실행 기록과 조건을 확인했습니다.
- [ ] 대체 라벨로 실제 프로젝트 파이프라인을 실행하고 단계별 결과를 보관했습니다.
- [ ] 미통과 항목, 업무 영향, 담당자, 승인된 임시 예외와 해제 조건을 기록했습니다.
검수 증거에는 변경 전후 설정, 실행한 이벤트와 브랜치, 작업별 통과·실패 결과, 미해결 호환성 문제를 포함하세요. 일반 검증 작업의 실패와 서명·출시 경로의 차단은 업무 영향이 다르므로 같은 우선순위로 묶지 않는 편이 좋습니다. 대체 Runner의 대기 시간이나 성능은 별도로 측정하지 않았다면 추정치로 보고하지 마세요.
마감 판단은 “라벨을 바꿨다”가 아니라 “중요 작업의 새 설정을 실제 실행으로 확인했고, 남은 위험에 승인된 책임자와 대응이 있다”로 내려야 합니다. 마이그레이션이 끝났다고 볼 수 있는 시점은 언제인가요? 필수 작업의 실행 증거가 있고, 미검증 항목이 명시적으로 승인된 예외로 관리될 때입니다. 근거가 없으면 완료가 아니라 보류로 남기세요.
Mac 실행 환경의 보완 선택
호스팅 Runner의 퇴역 대응을 위해 곧바로 별도 Mac을 구매할 필요는 없습니다. 먼저 새 라벨로 기존 호스팅 작업이 통과하는지 검증하세요. 다만 고정된 도구 환경이나 서명·출시 경로 등 프로젝트 요건 때문에 자체 관리 Mac이 필요한 작업이 있다면, 해당 작업만 분리해 별도 실행 환경을 검토할 수 있습니다. 이 경우에도 호스팅 Runner 퇴역 공지를 자체 관리 Mac의 퇴역 일정처럼 적용해서는 안 됩니다.
공유 Mac 환경의 후보를 비교할 때는 작업 격리, 비밀 정보와 서명 자산 접근, 운영 책임, 장애 복구 방법을 먼저 정리하세요. 기업용 Mac CI 활용 사례를 살펴보고, 원격 개발 환경이 파이프라인 요구에 맞는지 판단할 때는 Mac CI 환경 안내도 참고할 수 있습니다. 구매와 임시 사용의 운영 조건을 비교할 때에는 요금 안내에서 현재 제공 정보를 직접 확인하세요.
현재 호스팅 방식만 유지하면 새 라벨 전환 뒤에도 호환성 확인이 필요하고, 특정 도구 체인이나 서명 환경을 팀이 원하는 대로 통제하기 어려울 수 있으며, 공용 실행 환경만으로 해결되지 않는 업무 경계가 남을 수 있습니다. 그렇다고 Mac을 구매하거나 임대하는 편이 모든 팀에 유리한 것은 아닙니다. 물리 연결이 필수이거나 장기간 일정한 부하를 자체 운영하는 편이 적합하다면 직접 보유하는 방안을 비교하세요. 반면 검수된 Mac CI 작업을 별도 환경에서 처리해야 하지만 하드웨어를 상시 구매하기는 부담스럽다면 KVMFLUX의 원격 Mac 임대가 대안이 될 수 있습니다. 제공 형태와 이용 조건은 실제 안내에서 확인하고, 먼저 이 글의 점검표로 어떤 작업을 옮길지 확정한 뒤 선택하세요.
더 읽어보기
안정적인 맥 빌드 노드를 준비하세요
KVMFLUX의 전용 맥미니 M4를 연결해 이전 뒤에도 빌드와 검수를 이어가세요. 물리 맥 한 대를 단독으로 사용해 다른 이용자와 자원을 나누지 않고 작업할 수 있습니다. 보안 셸이나 원격 화면으로 접속해 자동화 작업부터 개발 환경 점검까지 진행하세요. 하루부터 분기까지 필요한 기간만 대여하고, 한국을 포함한 여러 지역에서 빌드 노드를 선택하세요.