Apple의 Xcode Cloud 릴리스 노트에는 출구 IP 범위가 2026년 2월 10일 변경됐다고 기록되어 있습니다. 따라서 Xcode Cloud 출구 IP 방화벽 업데이트는 이전에 저장해 둔 주소 목록을 그대로 쓰지 말고, Apple의 현재 공식 주소 범위를 확인한 뒤 저장소 측 allowlist와 방화벽 규칙을 함께 검토하는 방식으로 진행해야 합니다. 마지막에는 대표 워크플로를 실행해 실제 저장소 접근이 되는지 확인하세요.
판단: Apple 공식 범위를 기준으로 규칙을 갱신하고 CI 작업으로 검증할 수 있다면 적합합니다. 오래된 목록이나 출처가 불분명한 IP 목록에 의존하는 방식은 적합하지 않습니다.
이 글이 필요한 담당자
기업 IT 네트워크 담당자: 방화벽과 게이트웨이에서 Xcode Cloud의 저장소 접근 경로를 관리합니다.
보안 담당자: allowlist 변경의 근거와 영향 범위, 승인 기록을 검토합니다.
코드 저장소 관리자: 자체 호스팅 Git 서비스나 저장소 접근 제한을 관리합니다.
마지막 검토: 2026년 10월 26일. Apple 개발자 공식 릴리스 노트와 Xcode Cloud 프로젝트 설정 문서를 대조했습니다. 주소 목록과 적용 범위는 이후 Apple 문서가 바뀔 수 있으므로 실제 변경 시점에 다시 확인해야 합니다.
Xcode Cloud 출구 IP 방화벽 업데이트는 무엇을 기준으로 해야 하나요?
Apple은 릴리스 노트에서 변경 사실을 알리고, 프로젝트 설정 문서에서 Xcode Cloud가 코드 저장소에 접근할 때 참고할 IP 범위를 안내합니다. 최신 주소는 Apple의 Xcode Cloud 프로젝트 설정 문서에서 직접 확인하세요. 이 문서가 Xcode Cloud IP ranges를 확인할 기준이며, 오래된 내부 문서나 제삼자 목록으로 현재 범위를 대신해서는 안 됩니다.
먼저 문제가 된 연결이 Xcode Cloud에서 저장소로 향하는 경로인지 파악하세요. 저장소 접속 규칙과 다른 외부 서비스의 접근 규칙은 같은 변경으로 취급할 수 없습니다. Apple이 게시한 출구 범위는 주소의 근거이고, 어떤 출발지와 목적지, 프로토콜을 허용할지는 조직의 네트워크 정책에 따라 별도로 결정해야 합니다.
프로젝트 설정 문서의 주소 정보를 확인할 때는 IPv4와 IPv6 항목을 각각 살펴보세요. 두 주소 계열을 모두 지원하는 조직이라면 한쪽만 갱신한 상태로 완료 처리하지 말고, 방화벽과 저장소 제한 정책 양쪽에서 적용 여부를 확인해야 합니다. Apple 문서에 기재된 범위와 조직의 실제 규칙이 일치하는지는 담당자가 직접 대조해야 합니다.
네트워크 담당자는 어떤 방화벽 규칙을 재검토해야 하나요?
첫째, 저장소가 외부에서 HTTPS 접속을 받도록 설정되어 있다면 해당 저장소의 인바운드 규칙과 연결된 방화벽·게이트웨이 규칙을 확인하세요. Apple의 소스 코드 관리 연결 안내는 Xcode Cloud와 소스 코드 관리 연결을 설정할 때 참고할 공식 자료입니다. 조직에서 사용하는 실제 접속 방식과 제한 조건은 이 문서만으로 확정하지 말고, 저장소 및 네트워크 설정과 함께 확인해야 합니다.
둘째, 규칙에 사용된 객체가 Apple의 현재 IP 범위를 참조하는지 살펴보세요. 수동으로 적어 둔 주소, 이름이 비슷한 규칙 객체, 변경이 중단된 자동 갱신 절차가 남아 있다면 그 출처와 관리 책임자를 확인합니다. 셋째, 승인 기록과 이전 규칙으로 되돌리는 방법을 변경 전에 남겨 두세요. 적용 뒤에는 정책이 배포된 장비나 게이트웨이까지 반영됐는지도 확인합니다. Apple이 범위를 발표했다는 사실만으로 기업 내부 규칙이 자동 갱신되거나 실제 연결이 복구되는 것은 아닙니다.
아래 기록 형식은 변경 증거를 모으는 템플릿입니다. 실제 규칙 이름과 검토 결과를 담당자가 채워야 하며, 예시 값은 포함하지 않았습니다.
변경 근거: Apple Xcode Cloud 프로젝트 설정 문서
검토한 주소 계열: IPv4 / IPv6
대상 서비스와 규칙 객체: [조직의 실제 값]
승인 및 적용 기록: [변경 관리 기록]
워크플로 검증: [실행 기록과 저장소 접근 결과]
되돌리기 담당자와 절차: [조직의 실제 값]
변경 작업을 어떤 조건에서 진행하거나 되돌려야 하나요?
- Apple 공식 문서의 현재 범위를 확인했고, 저장소 접근 제한이 그 범위를 사용한다면 해당 규칙 객체와 영향을 받는 방화벽 정책을 함께 갱신하세요.
- 자체 호스팅 Git 서비스에서 출발지 IP 제한을 사용한다면 저장소 쪽 제한도 별도로 검토하세요. 방화벽만 허용해도 저장소의 IP 제한이 남아 있으면 접근이 차단될 수 있습니다.
- 공식 범위와 기존 규칙의 차이를 설명할 근거가 없거나 대상 서비스가 불분명하다면 변경을 보류하세요. 담당자와 적용 범위를 확인한 뒤 승인 절차를 밟는 편이 안전합니다.
- 적용 뒤 대표 워크플로에서 저장소 연결이 실패하고 원인을 특정하지 못했다면 임의로 출발지 제한을 넓히지 마세요. 변경 기록을 확인하고, 준비한 되돌리기 절차를 적용한 뒤 네트워크·저장소·워크플로 설정을 나누어 조사하세요.
저장소 관리자와 보안 담당자는 무엇을 따로 확인해야 하나요?
네트워크 허용과 저장소 권한은 별개의 검사 항목입니다. 기업 방화벽 allowlist를 수정했더라도 저장소 계정, 연결된 인증 정보, 저장소 접근 권한이 맞지 않으면 코드 가져오기는 실패할 수 있습니다. 반대로 저장소 권한이 올바르더라도 네트워크에서 접속을 거부하면 워크플로가 저장소에 도달하지 못합니다.
자체 호스팅 Git 서비스 관리자는 Xcode Cloud가 사용하는 연결 방식과 저장소의 IP 제한 조건을 확인하세요. Apple의 Xcode Cloud 보안 안내와 저장소 설정 문서를 기준 자료로 삼되, 내부 Git 서비스의 프록시, 인증, 접근 정책이 실제로 어떻게 동작하는지는 자체 설정에서 검증해야 합니다.
보안 담당자는 변경이 필요한 출발지와 목적지, 허용할 프로토콜이 목적에 한정되어 있는지 검토해야 합니다. 빠른 복구를 이유로 임의의 출발지를 허용하면 변경 범위가 불필요하게 커질 수 있습니다. 승인 근거, 변경 대상, 검증 결과를 함께 남기고, 통제 항목을 관리하는 조직이라면 NIST 보안 통제 자료와 내부 정책에 따라 증거 보존 방식을 정하세요.
IP 제한을 제공하는 코드 플랫폼을 사용하는 경우에는 플랫폼의 제한 정책도 확인해야 합니다. 예를 들어 기업 IP allowlist 관리 문서는 기업 차원의 네트워크 허용 목록 설정을 설명합니다. 해당 설정이 조직의 저장소 접근에 실제로 적용되는지, 변경 권한과 승인 절차가 무엇인지는 플랫폼 및 조직 구성에 따라 점검하세요.
| 담당 역할 | 주로 확인할 항목 | 완료를 뒷받침할 기록 |
|---|---|---|
| 네트워크 담당자 | 공식 범위와 방화벽·게이트웨이 규칙의 일치 여부 | 규칙 변경 및 배포 기록 |
| 저장소 관리자 | 자체 호스팅 서비스의 IP 제한과 저장소 인증·권한 | 저장소 정책 및 연결 설정 확인 |
| 보안 담당자 | 변경 근거, 최소 허용 범위, 승인과 되돌리기 책임 | 승인 기록과 영향 검토 |
| CI 담당자 | 대표 워크플로의 저장소 연결과 코드 가져오기 결과 | 워크플로 실행 기록 |
CI 담당자는 실제 워크플로로 어떻게 확인하나요?
규칙을 저장한 뒤에는 대표적인 Xcode Cloud 워크플로를 선택해 저장소 연결과 코드 가져오기가 성공하는지 확인하세요. 워크플로 설정은 첫 Xcode Cloud 워크플로 구성 안내를 참고하고, 필요한 작업과 실행 조건은 워크플로 작업 설정 문서에서 확인할 수 있습니다.
검증은 다음 순서로 진행합니다.
- Apple 공식 문서의 주소 범위와 변경 대상 규칙을 대조합니다.
- 네트워크 담당자가 방화벽과 게이트웨이의 변경 적용 여부를 확인합니다.
- 저장소 관리자가 IP 제한과 인증·권한 설정을 따로 확인합니다.
- CI 담당자가 대표 워크플로를 실행해 저장소 연결과 코드 가져오기 결과를 살핍니다.
- 실패하면 규칙 배포, 저장소 권한, 워크플로 구성으로 원인을 나누어 확인하고 결과를 기록합니다.
단일 실행이 실패했다는 사실만으로 IP 범위가 잘못됐다고 결론 내리지 마세요. 반대로 한 번 성공했다고 해서 모든 저장소나 워크플로의 접근이 확인된 것도 아닙니다. 어떤 저장소와 워크플로를 검증했는지, 실행 기록에서 무엇을 확인했는지 남겨야 다음 검토자가 변경 범위를 다시 판단할 수 있습니다.
팀의 결정 기록에는 Apple 공식 자료의 확인 시점, 변경한 규칙과 승인 내역, 저장소 정책의 검토 결과, 대표 워크플로의 실행 증거를 함께 묶어 두세요. 이후 Apple이 출구 범위나 프로젝트 설정, 저장소 접근 안내를 수정하면 누가 문서를 확인하고 재검증할지도 지정해야 합니다. 원격 Mac의 팀 운영 방식과 선택지를 함께 비교하려면 팀 단위 Mac 환경 비교 자료를 참고할 수 있습니다.
네트워크 규칙을 이미 검증했더라도 팀에 macOS 전용 빌드나 별도 테스트 환경이 더 필요할 수 있습니다. 기존 Xcode Cloud 작업을 유지하면서 해당 작업의 실행 환경을 따로 확보하려는 경우에는 자체 Mac 구매의 초기 비용과 유지 관리를 고려하고, 필요 기간이 한정적이라면 OakVM의 원격 Mac 렌탈을 대안으로 비교해 보세요. 렌탈은 Xcode Cloud의 주소 허용 규칙이나 저장소 권한을 대신하지 않으며, 장기간 계속 사용하는 환경이나 물리 장비 연결이 필요한 작업에는 구매 또는 자체 운영이 더 적합할 수 있습니다. 팀 환경에 맞는 운영 방식을 문의하려면 OakVM에 상담을 요청하세요.
방화벽 변경 이후에도 빌드 흐름을 안정적으로 이어가세요
OakVM의 전용 애플 실리콘 물리 노드에서 원격 빌드를 실행해 사무실 맥에 집중된 작업을 분산할 수 있습니다.