첫 실행 주기에는 신뢰된 작업만 상시 Mac Runner에서 시험하고, 외부 코드나 높은 권한이 필요한 작업은 일회성 Runner와 호스트 재설정을 함께 평가합니다. 이번 주에는 Runner 등록 해제, 호스트 정리, 자격 증명 회수, 로그 보존을 각각 증명할 수 있는지 확인하세요.
이 글은 자체 호스팅 Mac Runner를 운영하는 IT 책임자, iOS·macOS CI 보안 경계를 설계하는 플랫폼 엔지니어, 빌드 기반 시설의 운영 책임을 정해야 하는 기술 총괄을 위한 안내입니다.
작업 신뢰도: Runner 위치만으로 코드의 신뢰를 판단하지 않습니다
조직이나 저장소에 속한 Runner라도 그곳에서 실행되는 모든 코드가 신뢰되는 것은 아닙니다. 외부 기여 코드, 권한이 넓은 게시 작업, 배포 자격 증명에 접근하는 워크플로는 서로 다른 위험을 가집니다. GitHub는 자체 호스팅 Runner에서 신뢰할 수 없는 워크플로가 실행될 때 환경이 영향을 받을 수 있다고 경고합니다. 자체 호스팅 Runner의 보안 고려 사항을 기준으로 작업의 출처와 실행 권한을 따로 검토하세요.
pull_request_target은 기본 브랜치 문맥에서 실행되는 특성이 있으므로, 신뢰하지 않는 풀 리퀘스트 코드와 결합하는 방식에 각별한 주의가 필요합니다. 트리거 조건만 읽지 말고 워크플로가 체크아웃하는 코드와 토큰 권한까지 확인해야 합니다. pull_request_target 보안 안내에는 피해야 할 구성과 안전한 사용 경계가 설명되어 있습니다.
| 판단 기준 | 상시 Runner | 일회성 Runner |
|---|---|---|
| 작업 종료 뒤 등록 | 등록 상태와 호스트를 다음 작업에 재사용할 수 있습니다 | 작업 뒤 Runner 등록을 해제하도록 구성할 수 있습니다 |
| 호스트의 다음 작업 준비 | 작업 공간과 로컬 상태를 직접 정리하고 점검해야 합니다 | 등록 해제 뒤에도 호스트 초기화 또는 재구축을 확인해야 합니다 |
| 도구 체인과 캐시 | 설치된 도구와 캐시를 유지하기 쉽지만 변경 상태를 관리해야 합니다 | 매 작업의 기준 환경을 검증하기 쉽지만 재구축 과정이 필요합니다 |
| 자격 증명 경계 | 작업 간 키체인과 파일 잔류를 막는 통제가 중요합니다 | 다음 작업의 접근을 차단하도록 자격 증명 회수와 호스트 처리가 필요합니다 |
| 조사와 감사 | 호스트와 Runner 로그를 함께 보존해야 합니다 | 실행 환경을 없애기 전에 로그와 정리 증거를 외부에 남겨야 합니다 |
| 운영 책임 | 패치, 잔류 상태, 복구와 용량 관리가 이어집니다 | 등록 생성뿐 아니라 폐기, 재설정, 재구축의 성공 확인이 필요합니다 |
작업 격리: 등록 해제와 깨끗한 호스트는 다른 상태입니다
GitHub의 자체 호스팅 Runner 문서는 일회성 실행을 지원하지만, Runner가 작업을 마친 뒤 등록 해제되는 것과 Mac 자체가 초기화되는 것은 별개입니다. 따라서 “일회성”이라는 설정만 확인해서는 Mac CI 환경 격리가 완료됐다고 판단할 수 없습니다. Runner 설정 및 실행 방식 안내와 실제 호스트의 처리 기록을 함께 확인하세요.
두 번째 표는 배포 전에 확보해야 할 증거를 정리합니다.
| 검증 항목 | 확인할 증거 | 통과하지 못하면 |
|---|---|---|
| Runner 수명 | 작업 종료 뒤 등록 해제 여부와 등록 기록 | 일회성 실행 완료로 간주하지 않습니다 |
| Mac 정리 | 작업 공간, 임시 파일, 캐시, 시뮬레이터 상태의 처리 기록 | 호스트를 격리된 다음 작업에 재사용하지 않습니다 |
| 키체인과 서명 자료 | 작업 뒤 키와 인증 정보가 남지 않거나 접근 불가함을 보여주는 확인 | 서명 작업을 분리하고 자격 증명 접근을 차단합니다 |
| 기준 환경 | Xcode, 의존성, 작업 공간의 기준 상태 확인 | 깨끗한 재구축을 검증할 때까지 배포 작업을 옮기지 않습니다 |
| 로그 | Runner 로그와 작업 조사 자료의 외부 보존 및 조회 확인 | 실행 환경을 폐기하지 말고 보존 절차를 먼저 마련합니다 |
주의: Runner 그룹이나 워크플로 승인 규칙은 작업의 배치나 실행 승인에 도움이 되지만, 같은 Mac에서 작업끼리 파일과 키체인을 보지 못한다는 증거는 아닙니다. 호스트 수준의 격리는 별도로 확인해야 합니다.
자격 증명 경계: 작업에 필요한 권한만 전달합니다
작업이 읽을 수 있는 저장소 비밀, 토큰, 키체인 신원, 사내 네트워크 경로를 목록으로 만드세요. 그다음 일반 테스트, 외부 기여 코드, 서명, 배포 작업별로 접근 범위가 필요한 만큼만 열려 있는지 확인합니다. GitHub의 토큰 권한 설명과 비밀 관리 안내는 권한과 비밀을 구분해 검토할 때 참고할 수 있습니다.
환경 보호 규칙이나 승인은 배포 허용 조건을 제어하는 장치입니다. 이를 Mac 호스트의 사용자 계정, 파일, 키체인 분리와 같은 의미로 취급하지 마세요. 환경과 배포 보호 규칙 문서를 확인하되, 실제 자격 증명 접근과 네트워크 경계도 별도로 시험해야 합니다.
환경 일관성: 재사용 편의와 재구축 검증을 비교합니다
상시 Mac은 도구와 캐시를 유지할 수 있어 관리가 편리할 수 있습니다. 반면 설치 버전이나 작업 공간 잔류가 바뀌면 빌드 환경이 기준에서 벗어날 수 있습니다. 일회성 환경은 기준 이미지를 다시 적용하는 절차를 검증하기 좋지만, 그 과정에서 Xcode 버전, 의존성, 시뮬레이터 상태가 의도한 대로 재현되는지 확인해야 합니다. 실제 측정 없이 어느 쪽이 더 빠르다고 단정하지 마세요.
운영 절차: 여섯 단계로 수명 주기를 확인합니다
첫 단계: 작업을 신뢰 수준으로 분류합니다. 외부 기여 코드, 일반 검증, 서명, 배포를 나누고 각 작업이 접근하는 저장소와 네트워크를 기록합니다. 트리거와 체크아웃 대상을 함께 검토하세요.
둘째 단계: 권한을 대조합니다. 토큰 권한, 저장소 비밀, 키체인 신원, 내부 서비스 접근을 작업별로 확인합니다. 서명 자료가 필요한 작업과 필요하지 않은 작업을 분리합니다.
셋째 단계: Runner 종료를 확인합니다. 일회성 설정을 적용한 뒤 작업 완료 후 등록 해제가 이루어지는지 등록 기록으로 검증합니다. 등록 해제가 호스트 초기화까지 수행했다고 가정하지 않습니다.
예시 설정은 비밀이 아닌 자리표시자만 사용합니다.
./config.sh --url "$REPOSITORY_URL" --token "$RUNNER_TOKEN" --ephemeral
위 명령은 일회성 Runner 등록을 보여주는 예시입니다. 토큰은 실제 로그나 코드에 넣지 말고, 조직의 권한 정책에 따라 안전하게 전달해야 합니다. 예상 확인 결과는 다음처럼 상태를 분리해 기록하는 것입니다.
runner_registration: removed
host_cleanup: verified
credential_access_after_job: denied
이 출력은 설명을 위한 기록 형식이며, 명령을 실행하면 자동으로 생성되는 GitHub 결과가 아닙니다.
넷째 단계: 호스트 정리를 검증합니다. 작업 공간과 임시 파일, 캐시, 시뮬레이터 상태, 키체인 항목을 점검합니다. 정리 스크립트가 성공 코드를 내는지만 보지 말고, 다음 작업이 민감 자료를 읽을 수 없는지 확인하세요.
다섯째 단계: 도구 체인의 기준 상태를 기록합니다. Xcode와 의존성의 버전, 작업 공간 초기화 방식, 시뮬레이터 준비 상태를 관리 기준과 비교합니다. 상시 방식과 재구축 방식 모두 같은 테스트 작업으로 검증하고, 측정하지 않은 성능 차이는 판단 근거로 쓰지 않습니다.
여섯째 단계: 로그와 복구 책임을 정합니다. 실행 환경을 폐기하기 전에 Runner 진단 자료와 작업 조사에 필요한 기록을 외부에 보존합니다. GitHub의 Runner 모니터링 및 문제 해결 안내는 진단 로그 확인에 참고할 수 있습니다. Runner를 제거하는 절차는 Runner 제거 문서에서 확인하고, Mac 초기화 책임자와 로그 보존 위치는 별도로 정하세요.
경험상 점검 기록에서 가장 자주 혼동되는 것은 “작업 완료”, “Runner 등록 해제”, “Mac 정리”, “기준 환경 재구축”을 하나의 상태로 취급하는 일입니다. 이 네 가지를 각각 완료 조건으로 기록하면 복구 책임과 감사 증거가 분명해집니다.
운영 선택: 신뢰도와 정리 증거를 기준으로 결정합니다
관리되는 코드와 범위가 제한된 반복 작업이라면, 권한과 정리 상태를 검증하는 조건으로 상시 Runner를 평가할 수 있습니다. 외부 코드나 높은 권한을 다루는 작업은 일회성 Runner를 우선 검토하고, 작업 뒤 호스트를 폐기하거나 검증된 상태로 다시 만드는 절차를 붙이세요. 기반 Mac이 깨끗해졌다는 증거가 없다면 일회성 등록만으로 격리가 끝났다고 판단하지 않습니다.
| 조건 | 우선 검토할 방식 | 적용 전 필수 확인 |
|---|---|---|
| 신뢰된 코드이며 도구 체인 유지가 중요함 | 상시 Runner | 작업 간 잔류 차단, 패치, 정리와 복구 책임 |
| 신뢰하기 어려운 코드가 실행됨 | 일회성 Runner | 작업 후 등록 해제와 호스트 재설정 증거 |
| 서명 키나 배포 권한이 필요함 | 별도 권한 경계가 있는 실행 환경 | 키체인 접근, 비밀 회수, 네트워크 제한 |
| 로그 보존과 실패 조사가 필요함 | 두 방식 모두 가능 | 환경 폐기 전 외부 로그 전송과 조회 시험 |
| 정리 여부를 확인할 수 없음 | 해당 호스트의 민감 작업 배치 보류 | 폐기 또는 깨끗한 재구축 절차부터 마련 |
자주 묻는 내용
일회성 Mac Runner를 쓰면 다음 작업의 잔류 위험도 사라지나요?
아닙니다. 일회성 실행은 Runner 등록 수명을 제한할 수 있지만, Mac의 파일이나 키체인까지 자동으로 지워졌다는 뜻은 아닙니다. 작업 공간, 임시 파일, 캐시와 시뮬레이터 상태를 확인하고, 다음 작업이 앞선 작업의 자료에 접근할 수 없는지 검증하세요. 초기화 또는 재구축 증거가 없다면 같은 호스트를 깨끗한 환경으로 취급하지 않는 편이 안전합니다.
Mac CI의 서로 다른 작업 사이에서 자격 증명 위험을 어떻게 줄이나요?
작업별 토큰과 저장소 비밀의 권한을 필요한 범위로 제한하고, 서명용 키체인은 서명이 필요한 작업에서만 접근하도록 나눕니다. 작업이 끝난 뒤 키와 비밀에 다시 접근할 수 있는지 시험하고, 호스트와 네트워크 경계도 점검하세요. Runner 그룹이나 승인 규칙은 호스트 격리의 대체 증거가 아닙니다. 권한 설정과 정리 기록을 함께 남겨야 합니다.
기업 iOS CI 작업은 어떤 기준으로 일회성 Runner에 배치해야 하나요?
외부 기여 코드처럼 신뢰도를 확인하기 어려운 작업과 서명 키처럼 권한이 큰 자료를 다루는 작업을 먼저 평가하세요. 일반적인 검증 작업은 코드 출처와 권한이 관리되고 정리 책임이 명확할 때 상시 Runner를 검토할 수 있습니다. 작업의 트리거, 체크아웃 대상, 필요한 토큰과 네트워크를 확인한 뒤 배치 방식을 정하세요.
상시 Runner와 일회성 Runner의 차이는 어디서 확인하나요?
Runner 등록이 작업 뒤 유지되는지, 호스트가 다음 작업에 재사용되는지, 정리와 로그 보존이 어떻게 이루어지는지를 나누어 확인해야 합니다. GitHub 문서에서 일회성 실행과 Runner 제거 절차를 살펴보되, Mac의 초기화는 실제 호스트 기록으로 검증하세요. 등록 해제와 환경 정리를 같은 상태로 기록하면 남은 위험을 놓칠 수 있습니다.
다음 검토: 현재 기반 시설과 원격 Mac을 같은 기준으로 비교합니다
자체 운영 Mac은 지속적인 호스트 정리 책임이 있고, 상시 노드는 작업 간 잔류와 자격 증명 노출을 직접 통제해야 하며, 일회성 환경도 재구축과 로그 보존 체계를 마련해야 합니다. 임시 CI 용량이 필요하다면 NodeMini의 원격 Mac 이용 안내를 검토하되, 실제 Mac 종류와 접속 방식, 환경 초기화 책임, 인도 조건을 먼저 확인하세요. 이런 조건을 확인할 수 있을 때만 원격 Mac 임대를 선택지로 비교하는 것이 타당합니다. 팀의 기준과 운영 조건은 NodeMini 서비스 안내에서도 확인할 수 있습니다.