Mac을 재시작한 뒤 GitLab Runner가 오프라인으로 남거나, 자동 로그인을 켜야 할지 고민하고 있나요?
판정: 조건부 적합. macOS 자동 로그인은 Runner가 사용자 세션을 필요로 하는 환경에서 복구에 도움이 될 수 있지만, 기본 보안 설정으로 간주해서는 안 됩니다. FileVault 정책, 실행 계정 권한, 작업이 신뢰할 수 있는지부터 확인하고 통제를 만족하지 못하면 보호 수준을 낮추지 말고 노드와 작업 경계를 조정해야 합니다.
기업 IT 책임자: 재시작 후 Mac CI 노드의 복구 방식이 단말 보안 정책에 맞는지 검토할 때 참고하세요.
플랫폼 엔지니어: GitLab Runner의 실행 방식과 작업 계정의 실제 권한을 확인할 때 활용할 수 있습니다.
보안 담당자: 자동 로그인, FileVault, Keychain, 신뢰되지 않은 코드의 조합을 검토할 때 필요한 승인 기준을 확인하세요.
00사용자 세션과 Runner 상태 구분
GitLab은 macOS에서 Runner를 사용자 수준 LaunchAgent로 실행하는 구성을 안내하며, 재시작 뒤 이용 가능 상태를 유지하기 위해 자동 로그인을 고려할 수 있다고 설명합니다. 따라서 자동 로그인이 해결하는 것은 사용자 세션 복구 문제입니다. 이것만으로 CI 서비스와 빌드 환경이 운영 가능하다고 판정할 수는 없습니다. GitLab의 macOS Runner 설치 안내와 macOS 설정 문서를 기준으로 실제 실행 구성을 대조하세요.
다음 상태는 각각 확인해야 합니다.
- Mac이 켜져 있고 디스크가 잠금 해제된 상태
- 빌드 계정의 사용자 세션이 열린 상태
- LaunchAgent가 해당 세션에서 실행 중인 상태
- Runner가 작업을 받을 수 있고 대표 작업이 성공한 상태
앞 단계가 확인됐다고 뒤 단계까지 보장되는 것은 아닙니다. 예를 들어 화면에 로그인된 사용자가 보여도 Runner 등록이나 작업 실행이 정상이라는 증거는 아닙니다. 반대로 Runner 프로세스가 보이는 것만으로 서명과 테스트 작업의 성공을 승인해서도 안 됩니다.
01실행 계정의 권한 범위
GitLab Runner macOS 노드의 보안은 자동 로그인 여부뿐 아니라 작업을 실행하는 계정이 무엇을 읽고 바꿀 수 있는지에 따라 달라집니다. 계정이 관리자 권한을 갖거나 개발자 홈 디렉터리와 공유 디렉터리에 접근할 수 있다면, 작업이 그 권한을 물려받을 수 있습니다.
- 실행 계정이 관리자 그룹에 속하는지 확인합니다. 관리자 권한이 필요한 작업이 명확하지 않다면 일상 빌드 계정에서 제거하는 방안을 검토합니다.
- 계정이 접근할 수 있는 저장소, 작업 디렉터리, 네트워크 경로와 개발 도구를 목록으로 남깁니다.
- CI 로그나 작업 설정에 적힌 계정이 아니라, 실제 프로세스의 실행 사용자와 파일 접근 권한으로 확인합니다.
권한 목록에는 키체인 접근 여부도 포함해야 합니다. 작업마다 필요한 파일과 도구가 다른데 계정 하나가 모두 접근한다면, 작업별로 필요한 권한을 구분할 수 있는지 먼저 확인하세요. 구분할 수 없다면 이를 운영상 위험으로 기록하고 승인 여부를 별도로 판단해야 합니다.
02Shell executor의 작업 경계
GitLab Shell executor는 작업을 Runner 호스트에서 실행하며 격리가 제한적입니다. GitLab도 이 실행기의 보안 경계가 제한적이라는 점을 명시합니다. 이는 Shell executor의 특성에 관한 설명이며, 모든 executor에 같은 위험이 있다고 일반화해서는 안 됩니다. Shell executor의 보안 안내를 확인한 뒤 실제 구성에 적용하세요.
작업 출처를 다음처럼 나눠 검토합니다.
- 신뢰된 저장소와 승인된 배포 작업
- 외부 기여 코드나 검토 전 변경 사항
- 서로 다른 프로젝트의 일반 테스트와 서명 작업
여러 출처의 작업이 같은 계정과 호스트를 공유하면 작업 디렉터리, 설치된 도구, 접근 가능한 자격 증명을 경계로 삼기 어렵습니다. 따라서 Runner 할당 정책이 프로젝트별 신뢰 수준을 반영하는지 확인합니다. 신뢰되지 않은 코드가 서명 환경에 닿지 않도록 할 수 없다면, 작업을 별도 노드나 별도 실행 경계로 옮기는 방안을 검토하세요.
03FileVault와 자동 로그인 정책
Apple은 FileVault가 켜진 경우 자동 로그인 설정을 사용할 수 없을 수 있다고 안내합니다. 그러므로 기업 정책상 디스크 암호화를 요구한다면 Runner를 계속 온라인 상태로 만들기 위해 FileVault를 끄는 것을 전제로 삼으면 안 됩니다. Apple의 자동 로그인 설정 안내와 FileVault 보안 안내를 함께 검토하세요.
아키텍처 관점에서 확인할 것은 자동 로그인 기능의 유무만이 아닙니다. 재시작 뒤 디스크 잠금 해제에 필요한 절차와 사용자 세션을 여는 방법, 그 이후 Runner가 작업을 받는 상태가 되는 조건을 분리해 기록해야 합니다. 정책과 충돌하는 경우에는 예외를 먼저 만들기보다 승인된 복구 절차와 운영 책임자를 정하고, 해당 절차가 실제로 작동하는지 시험합니다.
04서명 인증서와 Keychain 접근
iOS 서명 작업에는 일반 테스트보다 민감한 자격 증명이 포함될 수 있습니다. 서명 작업을 일반 빌드와 같은 실행 계정에 맡기면 그 계정으로 실행되는 다른 작업이 인증서나 Keychain 자료에 접근할 가능성을 검토해야 합니다. 이 위험은 특정 executor에만 한정되는 것이 아니라, 실제 권한과 호스트 공유 방식으로 판단해야 합니다.
- 서명 작업을 실행할 수 있는 브랜치, 프로젝트, 승인 조건을 문서화합니다.
- 빌드 계정이 읽을 수 있는 Keychain 항목, 인증서와 배포 자격 증명을 점검합니다.
- 자격 증명 사용 기록을 남기고, 테스트 작업과 서명 작업의 권한 경계가 지켜지는지 확인합니다.
권한을 분리할 수 없다면 서명 자료를 같은 환경에 두는 것이 정책에 맞는지 보안 담당자의 승인을 받으세요. 서명 작업의 신뢰 범위가 일반 테스트와 다르다는 사실을 Runner 배정 규칙과 작업 권한에 반영하지 못하면, 자동 로그인 설정만 바꾸어도 핵심 위험은 해소되지 않습니다.
05운영 승인 전 재시작 검수
다음 항목을 격리된 시험 환경에서 확인한 뒤, 결과와 승인 책임자를 남깁니다. 화면에 Runner가 온라인으로 보이는지만으로 검수를 끝내지 마세요.
- [ ] 자동 로그인 사용 여부가 조직의 FileVault 및 단말 보안 정책에 부합하는지 확인합니다.
- [ ] 재시작 뒤 디스크 잠금 해제와 사용자 로그인에 필요한 절차를 기록합니다.
- [ ] LaunchAgent가 의도한 사용자 세션에서 시작되고, 세션 종료 시 어떻게 동작하는지 확인합니다.
- [ ] Runner가 등록된 상태로 작업을 수신하는지 확인합니다.
- [ ] 대표 테스트 작업을 실행해 결과물 생성과 필요한 테스트가 완료되는지 확인합니다.
- [ ] 서명 작업과 일반 테스트 작업의 실행 계정, Keychain 접근 범위를 대조합니다.
- [ ] 복구가 자동으로 되지 않을 때 조치할 담당자와 재가동 절차를 지정합니다.
- [ ] 시험 결과, 정책 예외, 승인자와 재검토 조건을 기록합니다.
최종 판정은 세 가지로 나눌 수 있습니다. 정책을 만족하고 세션부터 대표 빌드까지 재검증했다면 적용을 검토합니다. 세션은 복구되지만 계정이나 작업 경계가 불충분하다면 권한과 노드 구성을 조정합니다. FileVault 요구와 복구 방식이 충돌하거나 신뢰되지 않은 작업을 분리할 수 없다면 생산 투입을 보류합니다.
06자주 확인하는 복구와 격리 질문
macOS에서 GitLab Runner가 사용자 로그인에 의존하는 이유는 무엇인가요?
GitLab의 macOS 설치 안내는 사용자 수준 LaunchAgent 방식의 Runner 실행을 다룹니다. 따라서 운영자는 기기의 부팅과 사용자 세션의 개방을 별개로 확인해야 합니다. 등록 상태, 실제 작업 실행과 대표 빌드 결과까지 검증해야 재시작 복구를 승인할 근거가 됩니다.
FileVault가 켜져 있으면 재시작 뒤 Runner가 자동 복구되나요?
설정만 보고 자동 복구를 가정할 수 없습니다. Apple은 FileVault가 켜진 경우 자동 로그인 설정이 제공되지 않을 수 있다고 안내합니다. 조직의 암호화 정책을 유지한 상태에서 디스크 잠금 해제, 사용자 로그인, Runner 상태와 작업 결과를 따로 시험하고, 자동 복구에 실패할 때의 수동 조치도 정해야 합니다.
Shell executor로 여러 프로젝트의 작업을 격리할 수 있나요?
Shell executor는 Runner 호스트에서 작업을 실행하고 격리 수준이 제한적이므로, 프로젝트 이름만 나누었다고 충분한 격리가 성립하지 않습니다. 실행 계정과 호스트, 작업이 접근할 수 있는 파일 및 자격 증명을 확인해야 합니다. 신뢰되지 않은 코드와 배포 작업을 같은 경계 안에 둘 수 없다면 Runner 할당이나 노드 구성을 분리하는 편이 안전합니다.
iOS 서명 자료를 어떤 Runner 환경에 두어야 하나요?
일반 테스트와 서명 작업이 서로 다른 권한 및 신뢰 경계를 갖도록 설계할 수 있는 환경인지가 기준입니다. 서명 계정의 Keychain 접근과 인증서 사용 조건을 정하고, 승인된 작업만 해당 환경에 배정합니다. 별도 경계를 만들 수 없다면 자료를 배치하기 전에 보안 승인을 받고 접근 기록과 복구 책임을 문서화해야 합니다.
07임시 용량과 전용 노드 선택
기존 Mac을 CI에 재사용하면 즉시 시작할 수 있지만, 개발자 업무와 빌드 작업의 권한이 섞이거나 재시작 복구 담당이 불분명해질 수 있습니다. 자체 구매 노드는 장기간 안정된 부하와 직접 관리 역량이 있을 때 적합하지만, 장비 조달과 유지보수 책임도 함께 고려해야 합니다. 특히 테스트 환경을 검증하는 단계라면 전용 장비를 먼저 구매하는 결정이 부담이 될 수 있습니다.
임시 용량이나 격리된 검증 환경이 필요한 경우에는 원격 Mac 임대를 대안으로 비교할 수 있습니다. NUKCLOUD의 요금 안내를 살펴볼 때도 표시된 조건을 기준으로 비용을 비교하고, 구매 전에는 도움말에서 안내하는 접근 및 이용 조건과 로그인 복구 조건, 실제 제공되는 작업 환경을 확인해야 합니다. 어떤 방식이든 자동 로그인 자체를 보안 승인으로 대신하지 말고, 이 글의 재시작 검수 결과와 권한 경계를 근거로 노드 도입을 결정하세요.