Swift Package Manager 기업 프록시 어떻게 설정할까? 2026 Mac CI 가이드

Swift Package Manager 기업 프록시는 Runner에 HTTP_PROXY만 넣어 해결할 문제가 아닙니다. 먼저 소스 저장소, Swift Package Registry, 바이너리 산출물, Apple 서비스의 흐름을 나누고, 각 흐름에 맞는 Git 설정과 인증서 예외를 적용한 뒤 실제 CI 서비스 계정과 깨끗한 작업 공간에서 검수해야 합니다. 기업 네트워크에 넣기 어려운 작업은 별도 원격 Mac 노드 풀로 분리하는 편이 안전합니다.

이 글은 기업 프록시와 방화벽, 내부 인증 기관을 관리하며 Mac 빌드 노드의 출구 정책을 정하는 IT 책임자를 위한 내용입니다.
또한 Xcode 파이프라인과 Swift 의존성을 운영하면서 로컬 성공과 CI 실패의 차이를 없애려는 플랫폼 팀, 자체 장비와 원격 Mac 노드의 대량 배치를 비교하는 기술 의사 결정자를 대상으로 합니다.

시작 전: 의존성 흐름을 네 갈래로 나눕니다

Swift Package Manager가 내려받는 모든 항목이 같은 네트워크 경로를 사용하는 것은 아닙니다. 다음 네 흐름을 별도로 기록해야 합니다.

• 소스 제어 의존성: HTTPS Git 또는 SSH Git으로 저장소에 접근합니다.
• Swift Package Registry: 패키지 식별자와 레지스트리 주소를 사용합니다. Swift 공식 문서는 레지스트리 인증과 패키지 조회 방식을 별도로 설명합니다. Swift Package Registry 사용 문서를 기준으로 정책을 확인합니다.
• 바이너리 산출물: 바이너리 타깃이나 압축 파일을 별도 저장소에서 받습니다.
• Apple 서비스: 개발 도구 업데이트, 서명 관련 서비스, 기타 Apple 출구가 포함될 수 있습니다.

각 흐름마다 목표 주소, 인증 방식, 실제 실행 도구, 실행 계정을 기록합니다. 네트워크 팀은 그 결과를 바탕으로 직결, 프록시, 내부 미러 가운데 하나를 정해야 합니다. 확인하지 않은 주소나 포트를 미리 허용 목록에 넣으면 나중에 실패 원인을 분리하기 어렵습니다.

기준선 만들기: 깨끗한 해석과 로그를 남깁니다

관리자 터미널에서 한 번 내려받기에 성공했다고 배포 가능 상태가 된 것은 아닙니다. 먼저 캐시가 없는 작업 공간에서 의존성 해석을 실행하고, DNS 해석, 프록시 연결, TLS 협상, 애플리케이션 인증을 구분해 기록합니다.

이때 시스템 프록시, HTTP_PROXY, HTTPS_PROXY, Git 설정, SSH 설정, 키체인은 서로 자동으로 합쳐지지 않습니다. 한 위치에 프록시를 등록해도 다른 도구가 같은 값을 물려받는다는 보장은 없습니다. Git의 프록시와 TLS 관련 설정은 Git 설정 문서에서 적용 범위와 옵션을 먼저 확인해야 합니다.

Git이 프록시를 사용하는 방식과 환경 변수, 설정 파일의 우선순위를 더 넓게 확인해야 한다면 Git 공식 네트워크 관련 자주 묻는 질문을 함께 검토합니다. 프록시 주소를 한 곳에 넣는 것보다 실제 Git 프로세스가 어떤 설정을 읽는지 확인하는 것이 중요합니다.

주의: 개인 터미널의 프록시 자격 증명이나 개인 키체인을 공유 Mac 노드에 복사하지 않습니다. 서비스 계정과 노드 전용 자격 증명을 분리하지 않으면 담당자가 바뀐 뒤에도 접근 권한이 남습니다.

Mac CI 서비스 계정은 프록시와 인증서 설정을 어떻게 물려받습니까?

CI 실행기는 로그인한 관리자의 셸 환경을 그대로 사용하지 않을 수 있습니다. 따라서 다음 순서로 실제 서비스 계정의 실행 범위를 확인합니다.

• [ ] CI 작업이 사용하는 계정 이름과 홈 디렉터리를 기록합니다.
• [ ] 해당 계정에서 env로 프록시 환경 변수를 확인합니다.
• [ ] 해당 계정의 Git 전역 설정과 저장소별 설정을 따로 확인합니다.
• [ ] SSH 설정 파일과 키체인 접근 권한을 계정별로 확인합니다.
• [ ] 내부 인증 기관이 시스템 신뢰 저장소에 정식으로 배포되었는지 확인합니다.
• [ ] 관리자 계정에서만 성공하는 설정은 통과 판정에서 제외합니다.

프록시 환경 변수는 셸에서 실행되는 프로그램에 영향을 줄 수 있지만, macOS 시스템 프록시나 Git의 자체 설정을 대신하지 않습니다. 반대로 Git 설정을 바꾸어도 바이너리 산출물 다운로드 도구나 Apple 서비스의 네트워크 경로까지 바뀐다고 볼 수 없습니다.

xcodebuild는 시스템 Git의 프록시 설정을 어떻게 사용합니까?

xcodebuild는 빌드와 패키지 해석을 지휘하지만, 모든 네트워크 동작을 하나의 자체 프록시 설정으로 처리한다고 가정하면 안 됩니다. Apple은 CI에서 Swift 패키지를 빌드할 때 의존성 잠금과 자동화 환경을 함께 검토하도록 안내합니다. Apple의 CI Swift 패키지 안내를 기준으로 현재 Xcode 흐름을 확인합니다.

실무에서는 다음처럼 최소 범위만 확인합니다.

git config --global --get http.proxy
git config --global --get https.proxy
xcodebuild -resolvePackageDependencies

첫 명령의 결과가 비어 있다고 해서 오류는 아닙니다. 조직 정책에 따라 시스템 프록시나 저장소별 설정을 사용할 수 있기 때문입니다. 반대로 관리자 셸에서 Git 설정이 보인다고 해서 CI 계정에도 같은 설정이 있다고 판단해서는 안 됩니다.

HTTPS Git, SSH Git, Registry, 바이너리 다운로드를 각각 시험해야 합니다. HTTPS Git만 성공한 뒤 전체 Swift 의존성이 정상이라고 판정하면 안 됩니다. Package.resolved를 저장소에 고정하고, CI가 매번 자동으로 의존성 버전을 다시 선택하지 않도록 파이프라인 동작도 함께 통제합니다.

기업 HTTPS 검사가 Swift 패키지 해석을 막을 수 있습니까?

막을 수 있습니다. 프록시가 TLS 연결을 중간에서 종료하고 자체 인증서를 다시 발급하면, 클라이언트가 그 인증 기관을 신뢰하지 않거나 Apple 서비스가 중간 검사를 허용하지 않는 경우 연결이 실패합니다. Apple의 기업 네트워크와 소프트웨어 업데이트 요구 사항을 확인해 Apple 출구의 예외 정책을 별도로 정해야 합니다.

내부 Git, 내부 Registry, 내부 산출물 저장소는 기업 인증서 정책으로 관리할 수 있습니다. 그러나 Apple 서비스까지 같은 방식으로 가로채도 된다고 확장해서는 안 됩니다. 내부 인증 기관 설치와 신뢰 변경은 기기 관리 절차, 배포 기록, 철회 절차를 갖춰야 하며 인증서 검사를 끄는 방식으로 우회하지 않습니다.

실패 지점은 세 가지 증거로 나눕니다.

• 목표 주소에 연결되지 않음: DNS 또는 프록시 전달 정책을 확인합니다.
• 인증서 체인이 신뢰되지 않음: 내부 인증 기관 배포와 TLS 검사 예외를 확인합니다.
• 연결은 되지만 인증 실패: 저장소 토큰, Registry 자격 증명, 계정 권한을 확인합니다.

이 구분이 없으면 인증서 문제를 저장소 권한 문제로 오인하거나, 반대로 프록시 차단을 잘못된 토큰 탓으로 돌리게 됩니다.

원격 Mac은 기업 Git과 내부 Package Registry에 어떻게 접근합니까?

원격 Mac에서도 같은 흐름 지도를 사용해야 합니다. 먼저 기업망에 연결되는 전용 경로가 필요한지, 공용 의존성만 받는 탄력 노드로 충분한지 나눕니다. 내부 Git과 Registry를 사용한다면 네트워크 허용 정책, DNS, 프록시 인증, 내부 인증 기관 배포를 노드 단위로 검증합니다.

기업 원격 Mac 네트워크 출구 검수에 사용할 환경을 비교할 때도 관리자의 브라우저 접속이 아니라 CI 서비스 계정의 비대화형 실행을 기준으로 판단해야 합니다. 원격 접속이 된다는 사실과 빌드 프로세스가 필요한 주소에 접근한다는 사실은 다릅니다.

원격 Mac을 도입하기 전에는 다음 조건을 문서로 고정합니다.

• 기업 Git과 내부 Registry의 허용 경로
• 노드에 설치할 내부 인증 기관과 철회 방법
• 프록시 자격 증명의 보관 위치와 교체 담당자
• 서명 작업과 일반 의존성 작업의 신뢰 경계
• 재부팅 뒤 CI 실행기, 키체인, 프록시 설정의 복구 방식

자체 장비가 사내망에 이미 연결되어 있어도 노드마다 설정이 달라지면 운영 비용이 커집니다. 반대로 원격 Mac은 네트워크 위치와 복구 절차를 먼저 검증해야 하므로, 한 대를 격리한 시험 노드로 시작하는 편이 적절합니다.

첫 번째 실제 파이프라인을 어떤 순서로 승인합니까?

승인 기준은 의존성 하나가 내려왔는지가 아니라, 깨끗한 작업 공간에서 의존성 해석부터 산출물 생성까지 반복되는지입니다. 다음 목록을 그대로 검수 기록으로 사용합니다.

• [ ] 캐시와 기존 체크아웃이 없는 작업 공간을 준비합니다.
• [ ] 실제 CI 서비스 계정으로 Swift 의존성을 해석합니다.
• [ ] HTTPS Git과 SSH Git을 필요한 경로별로 검증합니다.
• [ ] Swift Package Registry 인증과 패키지 조회를 검증합니다.
• [ ] 바이너리 타깃 다운로드를 별도로 검증합니다.
• [ ] Package.resolved와 동일한 버전으로 빌드되는지 확인합니다.
• [ ] 테스트 실행과 최종 산출물 생성을 완료합니다.
• [ ] 노드를 재시작한 뒤 같은 파이프라인을 다시 실행합니다.
• [ ] 프록시 장애, 자격 증명 교체, 서비스 재로그인 뒤 복구를 확인합니다.
• [ ] 네트워크 도달, 의존성 해석, 반복 가능한 빌드, 작업 복구를 각각 승인합니다.

프록시가 잠시 내려간 뒤 복구되는지까지 봐야 합니다. 한 번의 다운로드 성공은 생산 작업의 복구 능력을 증명하지 않습니다. 특히 서명 작업은 내부 의존성 접근과 다른 신뢰 경계를 가져야 하므로, 일반 빌드 노드와 같은 자격 증명을 공유하지 않는 편이 좋습니다.

첫 배포는 비생산 작업부터 시작합니다. 실패 로그에서 반복되는 주소와 실행 단계를 확인한 뒤, 기업망 접근이 필요한 노드와 공용 의존성만 받는 노드를 나눕니다. 생산 서명 작업은 독립된 신뢰 경계를 유지합니다.

기존 Mac이 프록시 정책을 안정적으로 적용하지 못하거나 원격 복구가 어렵다면, 장비를 계속 개조하기 전에 전용 노드 추가와 원격 Mac 노드 풀을 비교합니다. 기업용 원격 Mac 임대 환경을 시험할 때도 같은 흐름 지도와 검수 목록을 적용해야 합니다.

자체 Mac 구매는 물리 장비와 네트워크를 직접 통제할 수 있다는 장점이 있습니다. 그러나 장비 조달, 교체, 고장 대응, 재택 접근, 노드별 인증서 차이를 기업이 부담합니다. 일반 클라우드 가상 머신은 비용과 확장성이 좋아도 macOS 도구, Apple 서비스, 서명 요구 사항을 그대로 만족하지 못할 수 있습니다.

반면 원격 Mac 임대는 초기 장비 구매와 유지 관리 부담을 줄이고 시험 노드를 빠르게 만들 수 있습니다. 대신 기업 프록시, 내부 Registry, 인증서, 재부팅 복구가 모두 통과된 뒤에만 팀 노드 풀로 확대해야 합니다. 장기간 고정 부하가 계속되거나 특정 물리 인터페이스가 꼭 필요하다면 자체 장비가 더 적합할 수 있습니다.

관리자 터미널 성공만으로 운영 승인을 내리는 현재 방식은 계정 범위가 다르고, 인증서 정책이 섞이며, 재부팅 뒤 설정이 사라지는 문제가 있습니다. 같은 흐름 지도와 검수 목록으로 격리된 원격 Mac 한 대를 먼저 시험하고, 프록시와 내부 의존성, 무인 복구가 모두 확인된 경우에만 팀 규모로 확장하는 것이 비용과 장애 위험을 함께 줄이는 경로입니다.