직접 기업 내부망에 접속하거나 방화벽에 정적 IP를 등록해야 한다면, GitHub Actions macOS larger runners를 기본 선택으로 삼지 마세요. 현재 네트워크 제한을 확인한 뒤 요구하는 경로를 갖춘 자체 관리 Mac을 검토하세요. 의존성이 공개되어 있거나 중개 접속 경로를 실제로 검증한 경우에만 호스팅 러너를 우선 평가하면 됩니다.
이 글은 사설 저장소와 내부 서비스 접근을 설계하는 IT 책임자, iOS/macOS 파이프라인을 나누는 플랫폼 엔지니어, 네트워크와 운영 책임을 함께 검토하는 보안·구매 담당자를 위한 안내입니다.
공개 의존성만 쓰는 빌드
소스 코드와 빌드 의존성이 러너에서 접근 가능하고, 기업 내부 서비스에 직접 연결할 필요가 없다면 호스팅 macOS 러너를 후보로 평가할 수 있습니다. 다만 저장소가 공개 URL을 제공한다는 사실만으로 빌드가 성공하거나 조직의 인증 조건을 통과한다고 볼 수는 없습니다.
| 확인 항목 | 공개 접근으로 충분한 경우 | 추가 검증이 필요한 경우 |
|---|---|---|
| 소스와 의존성 | 공개 주소에서 내려받을 수 있습니다 | 조직 계정, 토큰 또는 사설 레지스트리 인증이 필요합니다 |
| 빌드 서비스 | 외부에서 접근 가능하며 필요한 권한이 제한되어 있습니다 | 내부 API, 비밀 정보 서비스 또는 사내 아티팩트 저장소에 의존합니다 |
| 증거 | 워크플로 설정과 성공한 빌드 로그가 있습니다 | 로그에 접근 실패나 인증 오류가 있거나 경로를 확인할 수 없습니다 |
워크플로 파일, 의존성 목록, 빌드 로그를 함께 검토하세요. 소스 저장소 접근에 조직 인증이 필요하다면, 외부에서 접근 가능한 URL이라도 익명 공개와 동일한 조건은 아닙니다. GitHub의 macOS larger runners 네트워크 제한 문서에서 러너별 제한을 확인한 뒤 실제 워크플로 결과와 대조해야 합니다.
사설 저장소와 내부 서비스가 필요한 빌드
패키지 레지스트리, 아티팩트 저장소, 비밀 정보 서비스, 내부 API 중 하나라도 빌드에 필수라면, 주소와 인증 방식부터 나누어 기록하세요. 러너에서 서비스로 가는 요청의 출발 위치, 인증 주체, 허용 포트와 실패 시 확인할 로그가 핵심입니다.
| 의존성 | 점검할 접근 조건 | 통과 증거 |
|---|---|---|
| 사설 패키지 레지스트리 | DNS 경로, 인증 주체, 토큰 범위 | 의존성 다운로드 성공과 레지스트리 접근 기록 |
| 아티팩트 저장소 | 업로드·다운로드 권한, 네트워크 경로 | 빌드 산출물 조회 기록과 권한 거부 내역 |
| 내부 API·비밀 정보 서비스 | 접속 경로, 워크플로 신원, 비밀 정보 전달 방식 | 요청 로그에 남은 신원과 승인된 응답 |
GitHub-hosted 러너의 사설 네트워크 연결 안내에는 OIDC를 이용해 API 게이트웨이에 인증하는 방식과 WireGuard 기반 네트워크 오버레이가 소개되어 있습니다. 하지만 일반적인 안내가 곧 macOS larger runners에서 사용할 수 있다는 보장은 아닙니다. OIDC 게이트웨이 방식의 공식 안내와 WireGuard 연결 안내를 읽고 적용 대상과 제한을 확인하세요. 문서의 적용 범위가 분명하지 않으면 실험 환경에서 연결과 감사 기록을 검증하기 전까지는 미확인으로 남겨야 합니다.
정적 IP 허용 목록이 필요한 네트워크
방화벽에서 러너의 출발지 IP를 고정해야 한다면, macOS larger runners의 정적 IP 지원 여부를 먼저 확인하세요. GitHub 공식 문서에는 이 러너가 정적 IP를 제공하지 않는다고 명시되어 있습니다. macOS larger runners의 네트워크 제한을 기준으로 검토하고, 다른 운영 체제 러너의 설정을 macOS에 그대로 적용하지 마세요.
| 네트워크 요구 | macOS larger runners 판단 | 다음에 검토할 사항 |
|---|---|---|
| 방화벽 허용 목록에 고정 출발지 IP 필요 | 정적 IP가 제공되지 않으므로 기본 요구와 맞지 않습니다 | 기업 네트워크 안에서 경로를 제어할 수 있는 자체 관리 Mac |
| 허용 목록 대신 서비스 신원으로 인증 가능 | 대체 경로를 검토할 수 있지만 실제 적용 여부는 별도 확인이 필요합니다 | 게이트웨이, 신원 검증, 감사 로그 |
| 서비스가 공개되어 있고 내부 경로가 불필요 | 호스팅 러너를 후보로 둘 수 있습니다 | 조직 인증과 최소 권한이 충족되는지 확인 |
Azure private networking도 macOS larger runners의 기본 기능으로 간주하지 마세요. GitHub 문서는 Azure private networking의 적용 범위를 별도로 설명합니다. 적용 가능한 러너 유형과 현재 제한을 확인한 다음, 목표 macOS 러너에서 쓸 수 있다고 명시되어 있는지 판단해야 합니다.
IP 허용 목록은 네트워크 출발지 조건일 뿐입니다. 해당 주소가 허용되더라도 사용자의 신원 확인, 자격 증명 범위, 러너 권한이 적절하다는 뜻은 아닙니다.
중개 경로로 접근을 제한하는 구성
내부 서비스가 게이트웨이나 인증된 API 경로를 제공한다면 직접 내부망 접속을 허용하지 않고도 필요한 요청을 전달할 수 있는지 검토할 수 있습니다. 이 방식은 서비스와 인증 구조에 따라 달라지며, 모든 사설 패키지 저장소나 임의의 내부 주소에 적용되는 해법은 아닙니다.
설계 단계에서 다음을 분리하세요.
- 대상 서비스가 게이트웨이 경로를 지원하는지 확인합니다.
- 워크플로 신원이 어떤 자원에 접근할 수 있는지 제한합니다.
- 비밀 정보와 토큰이 러너에 전달되는 조건을 확인합니다.
- 네트워크 출구와 서비스 접근 기록을 보안 담당자와 함께 검토합니다.
연결이 성공했는지만 보지 마세요. 어떤 워크플로가 어떤 신원으로 요청했고, 서비스가 어떤 작업을 허용했는지 기록으로 확인해야 합니다. larger runners의 접근 제어와 네트워크 설정 안내도 검토하되, 문서에 명시되지 않은 macOS 적용 가능성은 실제 시험으로 확인하세요.
자체 관리 Mac이 필요한 네트워크 경로
내부망에 있는 서비스에 직접 연결해야 하거나 네트워크 팀이 출발지 경로를 통제해야 한다면 자체 관리 Mac이 더 적합할 수 있습니다. 자체 관리 Mac Runner를 등록했다고 내부망 권한이 자동으로 부여되는 것은 아닙니다. 호스트의 위치, 라우팅, 방화벽 규칙, 인증 설정을 별도로 구성하고 검증해야 합니다.
장점은 네트워크 경로와 호스트 운영을 조직의 요구에 맞춰 설계할 수 있다는 점입니다. 반면 유지보수, 업데이트, 장애 대응, 자격 증명 보호와 신뢰할 수 없는 워크플로의 위험을 직접 관리해야 합니다. 원격 접속이 된다는 사실도 호스트 격리를 보장하지 않습니다.
자체 호스팅 러너의 네트워크 통신 요구사항을 확인하고, 시험 워크플로에서 필수 도메인, 서비스 연결, 인증 거부, 로그 수집까지 점검하세요. 운영 환경에 투입하기 전에는 사용자가 실행할 수 있는 워크플로와 러너가 접근할 수 있는 비밀 정보의 범위도 정해야 합니다.
공개 작업과 내부 작업을 나누는 혼합 파이프라인
모든 단계를 하나의 러너에 몰아넣지 않아도 됩니다. 공개 의존성만 사용하는 컴파일·테스트 단계와 사설 서비스 또는 제한된 배포 경로가 필요한 단계를 분리할 수 있습니다. 다만 단계 사이에서 산출물과 권한이 어떻게 전달되는지 확인하지 않으면 분리 자체가 보안 경계가 되지 않습니다.
| 구분 | 공개 작업용 호스팅 러너 | 내부 접근용 자체 관리 Mac |
|---|---|---|
| 적합한 작업 | 공개 의존성으로 수행 가능한 빌드·검증 | 기업 네트워크 경로가 필요한 작업 |
| 네트워크 판단 | macOS의 정적 IP와 사설 네트워크 제한을 확인합니다 | 실제 호스트 경로와 접근 정책을 확인합니다 |
| 주된 운영 책임 | 러너 기능의 문서상 범위와 조직 권한 검증 | 호스트 유지보수, 네트워크, 자격 증명과 로그 관리 |
| 전환 전 증거 | 워크플로 실행 및 산출물 확인 | 내부 접근 로그, 인증 결과, 실패 관측 가능성 |
작업 분리 뒤에는 산출물의 출처와 무결성, 다음 작업이 사용할 수 있는 권한, 서명과 배포에 쓰이는 신원을 검증하세요. 먼저 실제 워크플로에서 작업 라우팅과 결과물 전달을 시험하고, 실패 시 어느 팀이 대응할지 정한 뒤에 구성 방식을 선택해야 합니다.
- [ ] 사설 레지스트리, 아티팩트 저장소, API, 비밀 정보 서비스 등 빌드 의존성을 목록으로 만들었습니다.
- [ ] 각 의존성의 접근 경로와 인증 주체, 허용 권한을 확인했습니다.
- [ ] 정적 IP가 필수인지, 서비스 신원이나 게이트웨이로 대체할 수 있는지 네트워크 팀과 합의했습니다.
- [ ] macOS larger runners의 공식 문서에서 대상 기능의 적용 범위를 확인했습니다.
- [ ] 실제 워크플로에서 접속 성공뿐 아니라 서비스 로그와 인증 기록을 확인했습니다.
- [ ] 혼합 파이프라인의 산출물 전달, 서명 권한, 실패 대응 책임을 시험했습니다.
자주 확인하는 접근 조건
macOS larger runners의 사설 패키지 저장소 접근
접근 가능 여부는 저장소가 사설인지 공개인지 한 가지 조건으로 결정되지 않습니다. 러너가 도달할 수 있는 네트워크 경로가 있고, 워크플로가 필요한 권한의 자격 증명을 안전하게 전달받아야 합니다. 문서에서 대상 러너에 대한 경로를 확인한 뒤 다운로드 작업과 저장소 접근 기록을 함께 검증하세요.
GitHub Actions macOS runner의 고정 IP 요구
방화벽 허용 목록에 고정된 출발지 주소가 필수라면, macOS larger runners는 그 조건을 충족하는 것으로 간주할 수 없습니다. 조직의 요구가 IP 주소인지, 서비스 신원인지, 별도 네트워크 경로인지 먼저 명확히 하세요. 다른 러너 유형의 기능을 가져와 판단하지 말고, 승인된 대체 경로를 실제로 확인해야 합니다.
기업 iOS CI의 호스팅 Mac과 자체 관리 Mac
내부 서비스에 직접 닿는 경로와 네트워크 정책을 직접 제어해야 한다면 자체 관리 Mac을 검토하세요. 반대로 공개 의존성으로 끝나는 작업은 호스팅 러너가 후보가 될 수 있습니다. 작업을 나눌 경우 산출물 전달, 서명 권한과 운영 책임도 함께 분리해야 하므로 시험 워크플로로 경계를 확인한 뒤 결정하세요.
게이트웨이 또는 네트워크 오버레이를 통한 접근
게이트웨이나 네트워크 오버레이는 대상 서비스, 인증 방식, 러너 적용 범위가 맞을 때만 후보가 됩니다. 모든 내부 서비스에 통하는 공통 연결 방법으로 취급하지 마세요. 연결 경로뿐 아니라 워크플로 신원, 자격 증명 범위, 출구 경로, 서비스 감사 로그까지 검증해야 하며, 적용 가능성이 확인되지 않은 구성은 미검증으로 남겨야 합니다.
현재 구성이 macOS larger runners라면 정적 IP 부재, 직접 내부망 연결의 불확실성, 러너별 기능 차이가 실제 제약이 될 수 있습니다. 자체 관리 Mac은 네트워크 경로를 직접 설계할 여지가 있지만, 호스트 운영과 자격 증명 보호, 장애 대응을 떠안습니다. 임시 빌드 환경이나 실제 작업 흐름을 검증할 원격 Mac이 필요하다면 MACCOME의 Mac 주문 안내를 살펴보고, 선택 전에 필요한 네트워크 접근 방식과 적용 범위를 확인하세요. 정적 IP나 특정 내부망 연결을 보장한다고 가정하지 말고, 기업 CI용 Mac 환경을 검토할 때 확인할 항목과 실제 워크플로를 기준으로 적합성을 판단해야 합니다.