Xcode Cloud가 기업 내부망에 접근할 수 있나요? 2026 비공개 의존성 방안

애플 공식 문서는 Xcode Cloud 빌드가 격리된 임시 환경에서 실행된다고 설명합니다. 따라서 Xcode Cloud 기업 내부망 연동은 “저장소가 연결되었는가”가 아니라 네트워크 도달성, 인증 권한, 빌드 환경에서의 사용 가능성이라는 세 조건을 모두 통과했는지로 판단해야 합니다. 하나라도 빠지면 외부에 안전하게 공개할 수 있는 의존성은 Xcode Cloud에 남기고, VPN 전용 자원과 민감한 서명 작업은 통제된 원격 Mac으로 보내는 혼합 구성이 가장 안전합니다. 애플의 Xcode Cloud 보안 설명

증상: 소스 저장소는 연결되었지만 내부 패키지나 사내 제작물이 내려받아지지 않습니다.
빠른 해법: 저장소 인증과 내부망 접근을 분리해 검사하고, 핵심 의존성이 VPN 안에 남으면 전용 원격 Mac으로 작업을 분기합니다.

이 글을 읽어야 하는 사람

Xcode Cloud를 검토하지만 코드나 패키지가 기업 내부망에 있는 IT 책임자에게 적합합니다.
비공개 Swift Package, Git 하위 모듈, 내부 제작물 저장소를 관리하는 개발 생산성 팀도 대상입니다.
방화벽 허용, 자격 증명 감사, 배포 서명 분리를 담당한다면 아래 절차를 그대로 시험 계획으로 사용할 수 있습니다.

Xcode Cloud 기업 내부망 접근은 전면 연결과 다릅니다

Xcode Cloud는 지원되는 클라우드 또는 자체 운영 소스 코드 관리 시스템에 연결하고, 지원되는 서비스의 비공개 의존성에 접근하도록 권한을 설정할 수 있습니다. 그러나 이것이 임의의 VPN, 사설 서브넷, 전용 회선에 들어갈 수 있다는 뜻은 아닙니다. 애플이 안내한 SCM 연결과 방화벽 설정은 Xcode Cloud 프로젝트 설정 문서에서 확인해야 합니다.

판정 대상은 다음 네 종류로 나누는 편이 좋습니다.

여기서 “저장소를 볼 수 있다”와 “빌드가 모든 의존성을 내려받는다”는 서로 다른 주장입니다. 사내 브라우저에서 GitHub Enterprise를 열 수 있어도 Xcode Cloud 실행 환경의 연결과 인증이 보장되지는 않습니다.

첫 번째 확인: 네트워크가 실제로 닿는가

자체 운영 저장소는 지속적으로 사용할 수 있는 HTTPS 연결과 애플이 공개한 주소 범위에 맞춘 방화벽 허용이 필요합니다. 사무실 네트워크에서 접속된다는 사실만으로는 충분하지 않습니다. Xcode Cloud의 실행 환경에서 같은 주소가 해석되고, 허용 목록을 통과하며, 필요한 인증 지점까지 도달해야 합니다.

방화벽 검토에서는 임의의 포트를 추측해 열기보다 다음 증거를 남겨야 합니다.

• 애플이 안내한 주소 범위와 현재 방화벽 규칙의 일치 여부
• 저장소 주소의 DNS 해석 결과
• 최소 테스트 저장소를 대상으로 한 복제 시도 기록
• 실패한 빌드의 네트워크 또는 SCM 오류 내용

방화벽을 넓게 열어 문제를 숨기면 나중에 철회하기 어렵습니다. 먼저 읽기 전용 테스트 저장소 하나로 범위를 제한하고, 성공 뒤에 실제 프로젝트로 확대해야 합니다.

두 번째 확인: 네트워크 허용과 권한 부여를 따로 봅니다

SCM 애플리케이션 승인, 조직 역할, 저장소 읽기 권한은 네트워크 허용과 별개입니다. 관리자가 자신의 브라우저에서 승인했다고 해서 Xcode Cloud의 빌드 주체가 같은 권한을 받는 것은 아닙니다.

이 표의 핵심은 실패 지점을 책임 팀에 바로 연결하는 것입니다. 관리자 계정으로 한 번 통과한 화면이 아니라, 최소 권한의 빌드 연결과 테스트 저장소의 실제 기록을 승인 증거로 삼으십시오.

비공개 패키지와 Git 하위 모듈은 어디서 갈립니다

Xcode Cloud에서 비공개 Swift Package를 가져올 수 있는 조건

Xcode Cloud는 지원되는 SCM에서 비공개 의존성에 접근하도록 인증을 구성할 수 있습니다. 다만 새 패키지를 추가하거나 여러 SCM 인스턴스에 걸친 의존성을 처음 해석할 때는 별도 검증이 필요합니다. 비공개 의존성 연결 절차는 패키지 주소와 인증 구성을 함께 확인하는 기준이 됩니다.

검사 순서는 다음과 같이 고정하십시오.

첫째, 프로젝트의 패키지 주소가 실제 SCM 인스턴스와 일치하는지 확인합니다.
둘째, Package.resolved에 기록된 버전과 브랜치 상태를 확인합니다.
셋째, Xcode Cloud가 사용하는 인증 주체에 해당 패키지의 읽기 권한이 있는지 확인합니다.
넷째, 패키지 저장소만 포함한 최소 빌드를 실행합니다.
다섯째, 빌드 보고서와 저장소 권한 기록을 함께 보관합니다.

Git 하위 모듈도 같은 방식으로 분리해야 합니다. 상위 저장소 복제에 성공했지만 하위 모듈 주소가 다른 SCM이거나 별도 인증을 요구하면 빌드는 중단됩니다. “소스 복제 성공”을 전체 의존성 승인으로 기록하지 마십시오.

의존성 자산표로 실패 원인을 고정합니다

각 자산에 대해 저장소 주소, SCM 인스턴스, 인증 주체, 필요한 네트워크 경로, 버전 고정 방식, 실패 시 대체 경로를 기록하십시오. 이 표가 있어야 버전 해석 실패와 인증 실패를 혼동하지 않습니다.

Swift Package를 CI에서 빌드하는 애플 안내도 함께 검토하면 패키지 해석과 프로젝트 빌드를 나누어 점검할 수 있습니다. 패키지 미러를 선택한다면 쓰기 권한 없이 읽기만 허용하고, 원본 저장소와 미러 사이의 갱신 책임도 정해야 합니다.

스크립트 실행과 내부망 접근은 같은 문제가 아닙니다

Xcode Cloud의 사용자 설정 스크립트는 도구 설치, 외부 서비스 호출, 비밀 환경 변수 사용에 활용할 수 있습니다. 그러나 스크립트가 실행된다는 사실이 내부망 경로를 만들어 주지는 않습니다. 또한 실행 환경은 임시이며, sudo로 관리자 권한을 얻어 장기 설정을 남기는 방식도 사용할 수 없습니다. 사용자 설정 빌드 스크립트의 제한을 기준으로 설계해야 합니다.

최소 구조는 다음처럼 목적을 좁게 유지하는 편이 좋습니다.

#!/bin/sh
set -e

./ci/check-dependency-access.sh
xcodebuild -resolvePackageDependencies

이 스크립트에서 점검할 항목은 도구 설치 경로, 비밀 주입 방식, 임시 파일 삭제, 실패 시 종료 코드입니다. 사내 인증서나 장기 캐시를 임시 노드에 남기지 마십시오. 외부 호출이 실패했는데도 스크립트가 성공 상태를 반환하면 CI가 잘못된 결과를 배포 단계로 넘길 수 있습니다.

VPN 전용 자원은 Xcode Cloud와 원격 Mac을 나누어야 합니다

다음 조건 중 하나라도 해당하면 Xcode Cloud에 전체 파이프라인을 억지로 넣지 않는 편이 좋습니다.

• 이름 해석이 기업 DNS에서만 가능합니다.
• VPN 연결 없이는 내부 제작물 서버에 도달할 수 없습니다.
• 상호 인증서나 고정된 네트워크 신원이 필요합니다.
• 비밀 서명 키와 내부 저장소를 외부 실행 환경에 노출할 수 없습니다.
• 장기 캐시와 고정된 도구 상태가 빌드 재현성에 필수입니다.

이때 외부에 제한적으로 공개할 수 있는 읽기 전용 미러, 사전 제작된 제작물, 통제된 HTTPS 게이트웨이를 먼저 검토할 수 있습니다. 다만 게이트웨이나 미러가 가능하다는 가정만으로 안전성을 승인해서는 안 됩니다. 기업의 네트워크 정책, 인증서 운영, 실제 연결 시험이 모두 필요합니다.

특히 사용자 설정 스크립트에서 네트워크 명령이 실행된다는 이유로 VPN 전용 자원에 접근할 수 있다고 판단하면 안 됩니다. 스크립트 실행 권한과 네트워크 경로는 서로 다른 계층입니다.

혼합 파이프라인을 선택하는 조건

다음 조건 분기를 의사 결정 기록으로 사용하십시오.

• 외부에서 HTTPS로 접근할 수 있고 비공개 SCM 권한을 최소 범위로 부여할 수 있다면, 일반적인 PR 검사와 패키지 테스트는 Xcode Cloud에 둡니다.
• 코드 저장소는 외부에 있지만 패키지 하나가 VPN 전용이라면, 해당 패키지를 읽기 전용 미러 또는 제한된 제작물 전달 경로로 바꾼 뒤 다시 시험합니다.
• 내부 제작물 서버가 외부에 공개될 수 없거나 고정된 네트워크 신원이 필요하다면, 그 작업은 통제된 원격 Mac으로 보냅니다.
• 생산 서명 키가 일반 빌드와 분리되어야 한다면, 서명 단계만 별도 원격 Mac으로 분리하고 Xcode Cloud에는 서명되지 않은 검증을 남깁니다.
• 장기 캐시, 고정 도구, 재시작 뒤 상태 복원이 필요하다면, 임시 Xcode Cloud 환경보다 관리되는 원격 Mac 노드를 우선 검토합니다.
• 위 조건을 시험할 수 있는 기록이 없다면, 어느 플랫폼도 승인하지 말고 격리된 개념 검증부터 진행합니다.

원격 Mac은 사내 물리 장비와 같은 방식으로 접근 정책을 설계해야 합니다. MacDate의 원격 Mac 운영 안내를 검토할 때도 저장소 권한, SSH 또는 화면 접근 권한, 비밀 삭제, 사용자 철회 절차를 함께 확인하십시오. 특정 지역의 실행 노드가 필요하다면 서울 원격 Mac 주문 안내처럼 실제 배치 조건을 먼저 확인한 뒤 시험 범위를 정하는 편이 안전합니다.

승인 전 검증 절차

첫 단계: 의존성 경계를 그립니다

소스 저장소, Swift Package, Git 하위 모듈, 내부 제작물, 서명 서비스, 배포 저장소를 한 목록에 넣습니다. 각각이 외부 접근 가능한지, VPN 전용인지, 별도 인증이 필요한지 표시합니다.

다음 단계: 최소 테스트 저장소를 만듭니다

앱 전체를 바로 연결하지 말고 패키지 하나와 하위 모듈 하나만 포함한 저장소를 만드십시오. 이 저장소는 운영 비밀을 포함하지 않아야 하며, 실패해도 배포에 영향을 주지 않아야 합니다.

그다음 단계: 연결과 권한을 따로 승인합니다

네트워크 팀은 DNS와 방화벽 기록을 확인하고, 개발 도구 팀은 SCM 앱과 저장소 권한을 확인합니다. 두 기록을 하나의 승인 항목으로 합치지 마십시오.

네 번째 단계: 실패 유형을 재현합니다

잘못된 패키지 주소, 권한이 없는 저장소, 접근할 수 없는 제작물 서버를 각각 시험합니다. 빌드 보고서가 네트워크 실패, 인증 실패, 버전 해석 실패를 구분하는지 확인해야 합니다.

다섯 번째 단계: 원격 Mac 경로를 시험합니다

내부 의존성이 Xcode Cloud에서 막히면 원격 Mac에서 같은 저장소를 가져오고 Xcode 빌드를 실행합니다. 재시작 뒤 다시 연결되는지, 실패한 작업이 재실행되는지, 담당자가 철회되었을 때 접근이 사라지는지 기록합니다. MacDate의 공유 원격 Mac 권한 관리 관련 안내도 이 검증 항목을 설계할 때 참고할 수 있습니다.

마지막 단계: 작업별 라우팅을 승인합니다

외부 PR 검증은 Xcode Cloud에, VPN 전용 의존성과 민감한 서명은 원격 Mac에 보냅니다. 소스 전달 방식, 제작물 무결성, 최소 권한, 실패 시 되돌림, 재시작 복구, 담당자 철회를 모두 확인한 뒤 노드 수를 확대하십시오.

결론: 연결 성공보다 실패 경계가 중요합니다

Xcode Cloud는 승인된 SCM과 비공개 의존성을 사용할 수 있지만, 임의의 기업 내부망에 자동으로 들어가는 도구는 아닙니다. 방화벽 허용, SCM 권한, 패키지 인증, 제작물 접근, 서명 권한을 각각 검증해야 합니다.

현재 구성이 Xcode Cloud 하나에 모든 작업을 넣는 방식이라면 VPN 의존성 때문에 빌드가 간헐적으로 실패하고, 임시 환경에서 캐시와 도구 상태를 유지하기 어렵고, 생산 서명 권한까지 같은 경계에 놓일 수 있습니다. 반대로 모든 작업을 사내 Mac에 고정하면 장비 확보, 원격 접근, 장애 복구와 사용자 철회가 운영 부담이 됩니다.

따라서 실제 비공개 의존성 하나를 골라 격리된 시험을 진행하십시오. 내부에 남겨야 한다면 MacDate의 원격 Mac으로 저장소 접근, Xcode 빌드, 재시작 복구와 권한 철회를 먼저 확인한 뒤, 증거가 쌓인 작업부터 혼합 파이프라인으로 확대하는 순서가 가장 현실적입니다.