Apple의 기업 네트워크 문서는 서비스에 따라 필요한 호스트와 포트를 따로 확인하도록 안내합니다. Apple 기업 네트워크 호스트와 포트 안내를 기준으로 보면, Xcode 27 CI 네트워크 허용 목록을 *.apple.com 한 줄로 끝내는 방식은 검증 가능한 정책이 아닙니다. 이번 주에는 소스, 의존성, Xcode 구성 요소, 서명과 배포, 알림과 관리 서비스를 분리하고 각 규칙을 실제 파이프라인으로 시험하십시오.
이 글을 읽어야 하는 사람
기업 네트워크와 보안 담당자는 맥 CI의 최소 출발 권한과 변경 승인 근거를 정해야 합니다.
플랫폼 엔지니어링 담당자는 Xcode 27, Apple Silicon, CI 실행 노드를 운영 환경에 배치해야 합니다.
구매와 인프라 담당자는 원격 맥 노드가 프록시, 사설 의존성, 서명 배포와 장애 복구를 실제로 지원하는지 확인해야 합니다.
주의: 아래의 외부 서비스 주소와 포트는 고정된 만능 목록이 아닙니다. Apple 서비스 변경, 기업 프록시 정책, 저장소 구성에 따라 다시 확인해야 합니다. 주소를 추가할 때는 반드시 요청 로그와 승인 기록을 함께 남기십시오.
SECTION 01 첫 단계: 실패한 요청을 네트워크 단계로 분리합니다
CI가 실패했다는 결과만으로 방화벽 문제라고 결론 내리면 안 됩니다. 같은 빌드라도 다음 여섯 단계에서 서로 다른 출발지가 사용됩니다.
- 소스 저장소와 서브모듈 가져오기
- Swift Package, CocoaPods, LFS와 사설 의존성 해석
- Xcode 구성 요소와 시뮬레이터 실행 환경 확보
- 개발자 계정 인증과 서명 자산 접근
- App Store Connect, TestFlight, 공증 서비스로 업로드
- 실행 결과, 상태 조회와 알림 회신
먼저 실패 단계, 요청한 주소, 실행 계정, 프록시 경로, 응답 코드와 원문 로그를 기록하십시오. 관리자 셸에서 성공한 요청은 서비스 계정의 성공을 증명하지 않습니다.
Xcode 27 빌드 기기에 어떤 네트워크 주소를 열어야 하나요?
정답은 빌드 작업이 실제로 호출하는 주소의 집합입니다. Apple 주소는 공식 문서에서 확인하고, 저장소와 사설 패키지 저장소는 기업이 관리하는 목록에서 별도로 관리해야 합니다. 주소가 정해지지 않은 상태에서 전체 도메인을 허용하면 변경 추적과 사고 조사가 어려워집니다.
| 트래픽 영역 | 허용 대상의 기준 | 확인해야 할 증거 |
|---|---|---|
| 소스 | 기업 저장소, 서브모듈, LFS 저장소 | 서비스 계정의 가져오기 로그 |
| 의존성 | Swift Package, CocoaPods, 사설 저장소 | 잠금 파일과 해시 검증 결과 |
| 도구 구성 요소 | Xcode 추가 구성 요소와 시뮬레이터 실행 환경 | 설치 로그와 캐시 제거 후 재설치 |
| 계정과 서명 | 개발자 계정, 인증과 자격 증명 서비스 | 인증 성공, 서명 실패 로그 |
| 배포 | App Store Connect, TestFlight, 공증 API | 업로드, 상태 조회, 로그와 티켓 |
| 관리와 통지 | CI 제어면, 로그 저장소, 알림 경로 | 작업 결과와 감사 이벤트 |
Xcode 추가 구성 요소는 Apple의 구성 요소 다운로드 안내에 따라 설치 동작을 확인해야 합니다. 설치 화면이 열리는지만 확인하지 말고, 캐시가 없는 깨끗한 노드에서 다운로드와 설치가 끝나는지 시험하십시오.
SECTION 02 소스와 의존성은 Apple 서비스와 분리해 관리합니다
소스 저장소, LFS, Swift Package, CocoaPods, 사설 바이너리 저장소는 Apple 서비스가 아닐 수 있습니다. 따라서 이 트래픽을 Apple 주소 허용 규칙에 합치면 사설망 접근 범위가 불필요하게 넓어질 수 있습니다.
서비스 계정으로 다음 조건을 각각 재현하십시오.
- 읽기 전용 저장소 인증이 정상인지 확인합니다.
- 잠금 파일과 실제 해석된 의존성의 차이를 기록합니다.
- 캐시를 비운 뒤 같은 의존성을 다시 가져옵니다.
- 사설 패키지 저장소의 인증 만료와 권한 부족을 구분합니다.
- 프록시를 거치기 전과 거친 뒤의 주소, 인증서, 응답 코드를 비교합니다.
자체 관리 실행 노드를 사용하는 경우에는 작업 라벨과 실행 노드 그룹을 네트워크 영역과 연결해야 합니다. 자체 관리 실행 노드의 공식 안내는 실행 노드의 라우팅과 관리 방식을 설명하며, 라벨 설정 안내는 작업을 특정 노드로 제한하는 기준을 제공합니다. 특정 서비스 이름보다 중요한 것은 사설 의존성이 필요한 작업이 사설망이 없는 노드로 이동하지 않는 구조입니다.
개발자 맥에서는 되는데 iOS CI에서 Apple 서비스 접근이 실패하면 어떻게 확인하나요?
관리자 계정과 CI 서비스 계정의 DNS, 인증서 저장소, 프록시 환경 변수, 키체인 권한을 나란히 비교하십시오. ping이나 브라우저 접속만으로 성공을 판정하지 말고, DNS 조회, TCP 연결, TLS 교섭, 인증과 권한, 실제 업무 요청, 전체 작업 결과를 순서대로 기록해야 합니다.
SECTION 03 두 번째 표: 신뢰 영역별로 출발 권한을 나눕니다
일반적인 풀 리퀘스트 빌드와 생산 서명 작업은 같은 출발 정책을 사용하지 않아야 합니다. 특히 외부 코드가 포함될 수 있는 작업과 개인 키를 사용하는 작업을 한 노드에서 처리하면 의존성, 코드, 자격 증명의 노출 경로가 겹칩니다.
| 노드 유형 | 허용 범위 | 금지하거나 별도 승인할 항목 | 합격 기준 |
|---|---|---|---|
| 일반 빌드 노드 | 소스, 공개 의존성, 필요한 Apple 개발 서비스 | 생산 서명 키, 배포 권한 | 빌드와 테스트 로그 확보 |
| 의존성 전용 노드 | 사설 패키지와 내부 저장소, 검증된 Apple 구성 요소 | 생산 업로드 권한 | 캐시 삭제 후 잠금 상태 일치 |
| 생산 서명 노드 | 필요한 계정, 서명, 업로드와 공증 경로 | 신뢰하지 않은 분기의 의존성 실행 | 서명, 업로드, 상태 조회 완료 |
| 재해 복구 노드 | 승인된 동일 출발 정책과 복구 저장소 | 평상시의 광범위한 접근 | 격리 시험과 복구 로그 확보 |
App Store Connect API 키는 Apple의 API 키 생성 문서에 따라 역할 범위를 제한하십시오. 업로드가 성공했다는 사실만으로 배포 경로가 검증된 것은 아닙니다.
공증을 자동화한다면 제출, 상태 조회, 로그 가져오기와 티켓 장착까지 확인해야 합니다. Apple Notary API 문서는 이 자동화 경로의 요청 구조를 설명합니다. 마지막 단계가 빠지면 공증 서버에 파일을 올렸지만 배포 대상에서 검증되지 않는 상태를 놓칠 수 있습니다.
기업 서명 배포 노드는 어떤 출발 권한을 가져야 하나요?
일반 빌드와 분리된 좁은 출발 정책이 적합합니다. 서명 노드는 필요한 저장소와 업로드, 공증 경로만 사용하고, 외부 분기의 임의 의존성 다운로드나 범용 디버깅 작업은 받지 않는 편이 안전합니다. 인증서와 개인 키의 접근 계정도 작업 유형별로 구분하고, 로그에는 비밀 값이 남지 않게 해야 합니다.
SECTION 04 프록시와 TLS 검사가 같은 주소를 다르게 만듭니다
명시적 프록시는 실행 계정에 환경 변수를 전달하지 못할 수 있습니다. 투명 프록시는 경로를 바꾸고, TLS 해독 장비는 내부 인증 기관을 요구할 수 있습니다. DNS 재작성과 리다이렉트까지 겹치면 관리자 터미널과 CI 서비스 계정이 같은 주소에서 서로 다른 결과를 얻습니다.
Apple 소프트웨어의 통신 포트는 Apple의 TCP와 UDP 포트 안내와 서비스별 문서를 함께 확인하십시오. 포트 번호를 복사하는 것보다 중요한 것은 실제 요청이 어느 프록시와 주소를 거쳤는지 기록하는 일입니다.
맥 CI 프록시와 기업 방화벽 허용 목록은 어떻게 설계하나요?
주소, 포트, 목적, 실행 노드, 프록시 필요 여부, 인증 방식, 담당자와 만료일을 한 행으로 관리하십시오. 임시 허용은 종료 날짜를 반드시 두고, TLS 검사를 우회할 때는 보안 승인을 별도로 남겨야 합니다. 전체 주소 허용보다 서비스별 규칙과 검증 명령을 연결하는 방식이 변경 영향도 파악에 유리합니다.
다음 표를 각 주소마다 채우면 됩니다.
| 검증 층 | 확인 방법 | 저장할 결과 |
|---|---|---|
| DNS | 실행 노드에서 주소 조회 | 응답 주소와 조회 시각 |
| TCP | 대상 포트 연결 시험 | 연결 성공 또는 거부 기록 |
| TLS | 인증서와 교섭 확인 | 인증 기관, 이름, 실패 원인 |
| 인증 | 서비스 계정 또는 API 자격 증명 사용 | 권한과 응답 코드 |
| 업무 요청 | 다운로드, 업로드, 상태 조회 실행 | 요청 식별자와 원문 로그 |
| 전체 작업 | 깨끗한 노드에서 CI 재실행 | 최종 상태와 산출물 |
운영 경험: 브라우저에서 로그인되는 주소를 CI의 성공 주소로 간주하지 마십시오. 브라우저는 사용자 인증서와 세션을 사용하지만, CI는 서비스 계정과 별도 키체인, 별도 프록시 설정을 사용할 수 있습니다.
SECTION 05 세 번째 단계: 출시 전 검증 표를 승인 문서로 바꿉니다
원격 맥 빌드 노드도 같은 증거를 제출해야 합니다. 임대형 환경을 검토할 때는 “인터넷이 된다”는 설명보다 기업 프록시 연결, 사설 의존성 접근, 서명 작업, 재연결 후 상태 보존을 직접 시험해야 합니다. VPSNIX의 맥 원격 환경 안내를 확인하더라도, 최종 판단은 네트워크 시험 기록과 조직의 보안 기준으로 내려야 합니다.
다음 항목을 노드 유형별로 체크하십시오.
- [ ] 규칙 번호와 변경 승인자를 기록했습니다.
- [ ] 대상 주소, 포트, 업무 목적을 한 행에 작성했습니다.
- [ ] 실행 계정과 실행 노드 그룹을 명시했습니다.
- [ ] DNS, TCP, TLS, 인증, 업무 요청을 모두 확인했습니다.
- [ ] 캐시를 비운 뒤 의존성 해석을 다시 실행했습니다.
- [ ] Xcode 구성 요소 다운로드와 설치를 확인했습니다.
- [ ] 서명, 업로드, 상태 조회, 공증 로그와 티켓 장착을 확인했습니다.
- [ ] 프록시 장애와 DNS 변경 시 실패 로그를 확보했습니다.
- [ ] 원격 연결이 끊긴 뒤 작업 상태와 재연결 동작을 확인했습니다.
- [ ] 규칙 변경 책임자, 재검토 날짜와 롤백 방법을 기록했습니다.
- [ ] 일반 빌드 노드와 생산 서명 노드의 권한 차이를 승인받았습니다.
- [ ] 재해 복구 노드에서 동일한 검증을 반복했습니다.
판정은 네 가지로 제한하는 것이 좋습니다. 모든 증거가 있으면 허용으로 처리합니다. 일부 규칙에 담당자나 재검토 날짜가 없으면 기한을 정한 수정으로 남깁니다. 원격 맥이나 새 프록시가 아직 검증되지 않았다면 격리된 시험 운영으로 제한합니다. 서명 키가 일반 분기와 공유되거나 업무 요청 로그가 없으면 출시 금지가 맞습니다.
2026년 9월 21일 기준 재검토 일정
이 글의 최신성은 Xcode 27 출시 기록, Apple 네트워크 문서, 계정과 공증 문서를 기준으로 확인해야 합니다. Xcode 27이 시험판에서 정식판으로 바뀌거나 Apple 서비스 주소가 변경되면 해당 규칙을 다시 검증하십시오.
이번 주에는 먼저 실패한 작업 하나를 선택해 여섯 단계의 요청 기록을 만들고, 다음 영업 주기에는 일반 빌드와 생산 서명 노드를 분리한 허용 표를 승인받으십시오. 이후 프록시 정책 변경 때마다 깨끗한 노드에서 전체 파이프라인을 재실행하면 됩니다.
현재 방식이 개발자 맥의 수동 접속이나 무제한 출발이 허용된 공용 환경이라면, 주소 변경을 추적하기 어렵고 서비스 계정별 차이를 놓치며 서명 자격 증명과 외부 의존성이 같은 경로에 놓이는 문제가 있습니다. 이런 조건에서는 장비를 더 사는 것보다 검증 가능한 원격 맥 노드로 먼저 시험하는 편이 현실적일 수 있습니다. 다만 VPSNIX를 선택하더라도 프록시, 사설망, 서명 배포와 실시간 복구가 조직 기준을 충족하는지 먼저 확인해야 합니다. 구매 전에는 VPSNIX의 도움말 센터와 요금 정보를 함께 검토하고, 체크리스트의 증거를 확보한 뒤 PoC 범위를 정하십시오.