개발자 컴퓨터에서는 사설 패키지를 가져오는데 CI 서비스 계정에서는 실패한다면, 먼저 캐시를 지우거나 공유 키를 열지 마십시오.
가장 빠른 해결 순서는 Package.resolved를 커밋하고 자동 해석을 통제한 뒤, 신뢰 영역마다 읽기 전용 SSH 신원을 분리하고, 마지막에 캐시를 검증하는 것입니다. 사설 의존성 해석 노드와 애플 서명 노드는 기본적으로 분리해야 하며, 공유 원격 맥은 계정·인증 정보·작업 공간이 모두 분리될 때만 사용해야 합니다.
SECTION 01 적용 대상과 이번 주 실행 순서
이 글은 사설 스위프트 패키지를 포함한 아이오에스·맥 프로젝트의 CI를 관리하는 개발 책임자를 위한 내용입니다. 젠킨스, 깃허브 액션, 깃랩 또는 자체 운영 맥 에이전트를 담당하는 플랫폼 팀에도 해당합니다.
보안·IT 책임자는 저장소 인증 정보와 서명 자산의 분리 여부를 확인하는 기준으로 활용할 수 있습니다. 이번 주에는 다음 순서로 증거를 남기십시오.
- 1일 차: 의존성 해석, 깃 연결, 이진 파일 다운로드, 컴파일 로그를 별도 보관합니다.
- 2일 차: 실제 CI 서비스 계정으로 같은 커밋을 깨끗한 작업 공간에서 재현합니다.
- 3일 차: 저장소별 읽기 전용 키와 권한 범위를 검토합니다.
- 4일 차: 캐시가 없는 노드와 기존 노드에서 최소 빌드를 비교합니다.
- 5일 차: 서명 노드와 의존성 노드의 분리 또는 공유 노드 유지 여부를 결정합니다.
SECTION 02 실패 경계와 책임 분리
기술 책임자: 실패 지점 고정
스위프트 패키지 매니저 의존성 CI 실패는 하나의 오류처럼 보이지만, 실제로는 네 단계가 섞여 있을 수 있습니다. 먼저 각 단계의 로그와 종료 상태를 따로 저장해야 합니다.
| 확인 단계 | 확인할 증거 | 다음 팀에 넘길 조건 |
|---|---|---|
| 의존성 해석 | Package.resolved, 해석 로그, 프로젝트 경로 |
잠금 상태와 실제 대상이 일치함 |
| 깃 연결 | 저장소 주소, 호스트 키, 연결 오류 | 서비스 계정으로 저장소 주소에 접근함 |
| 이진 파일 다운로드 | 이진 대상의 실제 끝점과 인증 결과 | 모든 전달 의존성의 끝점이 확인됨 |
| 컴파일 | 모듈 오류, 엑스코드 빌드 종료 상태 | 의존성 문제가 아닌 컴파일 문제로 분리됨 |
애플은 연속 통합 빌드에서 의존성 버전 상태를 관리하고 자동 해석을 통제하는 방법을 안내합니다. 배포용 빌드는 승인된 잠금 상태에서 실행하고, 의존성 갱신은 별도 작업으로 분리하십시오. 자세한 기준은 애플의 스위프트 패키지 연속 통합 안내에서 확인할 수 있습니다.
애플리케이션 팀: 잠금 상태 고정
Package.resolved가 올바른 프로젝트 또는 작업 공간 경로에 있는지 확인하십시오. 파일이 버전 관리에 들어갔는지, 변경이 코드 검토를 거쳤는지도 함께 확인해야 합니다.
개발자가 의존성을 자동으로 최신화하는 흐름과 운영 CI가 재현 빌드를 수행하는 흐름은 목적이 다릅니다. 두 작업을 하나의 명령으로 합치면 개발자 컴퓨터의 해석 결과가 운영 빌드에 섞일 수 있습니다.
같은 커밋으로 다음을 각각 실행하십시오.
git checkout <검증할 커밋>
xcodebuild -resolvePackageDependencies -workspace <작업공간>.xcworkspace -scheme <구성표>
위 명령은 재현 절차의 예시입니다. 실제 작업 공간과 구성표 이름은 저장소에 맞춰 지정해야 합니다. 스위프트 패키지 매니저의 버전 해석과 잠금 파일 작동 방식은 공식 버전 해석 문서를 기준으로 검토하십시오.
사설 구성 요소 담당자: 끝점과 권한 목록화
최상위 패키지만 확인하면 부족합니다. 직접 의존성, 전달 의존성, 이진 대상이 실제로 접근하는 저장소와 다운로드 끝점을 모두 목록으로 만드십시오.
특히 다음 변경이 서비스 계정의 실패를 만들 수 있습니다.
- 저장소 이름 변경 뒤에도 오래된 주소가 잠겨 있는 경우
- 주소 재작성 또는 미러 설정이 개발자와 CI에서 다르게 적용된 경우
- 하위 패키지가 별도의 신뢰 영역에 있는 경우
- 소스 패키지와 이진 패키지가 서로 다른 인증 방식을 요구하는 경우
- 승인되지 않은 주소로 의존성이 이동한 경우
패키지 주소와 버전 조건은 애플의 패키지 의존성 설명 및 의존성 추가 공식 문서와 대조하십시오. 권한은 작업에 필요한 저장소의 읽기 전용 범위로 제한하고, 생성·교체·폐기 기록을 남겨야 합니다.
주의: 관리자 터미널에서 성공한 SSH 연결은 CI 성공의 증거가 아닙니다. 실제로
xcodebuild를 실행하는 계정과 동일한 홈 경로 및 설정으로 재현해야 합니다.
SECTION 03 CI 계정과 인증 문맥
플랫폼 팀: 실제 서비스 계정 재현
CI에서 실행되는 맥 계정으로 다음 항목을 확인하십시오.
HOME이 예상한 서비스 계정의 경로인지 확인합니다.known_hosts가 실행 계정의 홈 디렉터리에 존재하는지 확인합니다.- SSH 설정 파일과 키 파일의 소유자 및 접근 권한을 검토합니다.
- 에이전트가 필요한 구조라면 해당 계정의 에이전트 상태를 확인합니다.
- 시스템 깃 설정, 대리 서버, 주소 재작성 규칙이 실제 작업에 적용되는지 확인합니다.
- 소스 관리 제공자 설정을 명시하고, 관리자 계정의 환경을 암묵적으로 상속하지 않습니다.
사설 저장소를 읽는 인증 정보는 애플 서명 개인 키, 배포용 인증 정보, 공유 관리자 계정과 함께 보관하지 마십시오. 인증 방식과 패키지 레지스트리를 사용하는 경우에는 공식 패키지 레지스트리 사용 문서를 별도로 확인해야 합니다.
수정 후에는 아래 순서로 재검증하십시오.
- 서비스 계정으로 의존성 해석을 실행합니다.
- 최소 대상 하나만 컴파일합니다.
- 작업 노드를 재시작합니다.
- 재시작 후 같은 잠금 상태로 다시 해석합니다.
- 새 작업 공간에서 최소 빌드를 반복합니다.
이 과정을 거치면 대화형 터미널에서만 작동하는 SSH 에이전트, 남아 있는 작업 공간, 관리자 계정의 깃 설정을 구분할 수 있습니다.
보안·배포 팀: 자격 증명 경계
외부 변경 요청이나 신뢰되지 않은 브랜치가 실행되는 작업에는 운영 사설 의존성과 서명 자산을 동시에 제공하지 않아야 합니다. 임시 키체인, 독립 서비스 계정, 저장소 단위 권한, 작업 종료 후 작업 공간 정리를 기본 경계로 두십시오.
공유 맥을 사용해야 한다면 프로젝트마다 다음을 분리해야 합니다.
- 실행 계정 또는 작업 단위의 격리된 계정
- 저장소 읽기만 허용하는 SSH 신원
- 임시 키체인과 별도 작업 공간
- 작업 종료 후 삭제되는 인증 파일
- 로그에 비밀 값이 출력되지 않는 환경 변수 처리
- 운영 서명 노드로의 네트워크와 권한 경로
패키지 레지스트리 기반 인증을 선택하는 조직은 패키지 레지스트리 구조 설명도 함께 검토해야 합니다. 저장소 서비스의 권한 동작은 공급자마다 다를 수 있으므로, 문서에 없는 권한 상속을 전제로 설계하지 마십시오.
SECTION 04 중부 비교: 노드 운영 방식
| 운영 방식 | 의존성 인증 위치 | 서명 자산 위치 | 적합한 조건 | 주요 위험 |
|---|---|---|---|---|
| 기존 공유 맥 | 여러 작업이 같은 계정 또는 작업 공간을 사용할 수 있음 | 같은 노드에 남을 가능성 있음 | 신뢰된 내부 작업만 있고 강한 정리 절차가 있을 때 | 인증 정보와 캐시가 서로 섞임 |
| 분리된 의존성 맥 | 읽기 전용 서비스 계정과 저장소별 키 사용 | 운영 서명 키를 두지 않음 | 사설 패키지 해석과 일반 빌드를 분리할 때 | 노드 전달과 교체 검증이 필요함 |
| 전용 서명 맥 | 승인된 배포 작업만 접근 | 임시 또는 제한된 키체인 사용 | 공식 배포와 서명 보호가 우선일 때 | 처리량 부족 시 대기열이 생길 수 있음 |
| 임시 원격 맥 | 작업마다 인증과 작업 공간을 주입 | 서명 작업과 별도 운영 가능 | 깨끗한 환경 재현과 탄력적 용량이 필요할 때 | 전달 후 초기 검증 절차가 필요함 |
여기서 원격 맥은 사설 의존성 문제를 자동으로 해결하는 제품이 아닙니다. 서비스 계정과 키를 잘못 설계한 상태에서 장비만 바꾸면 실패가 반복됩니다. 반대로 기존 노드의 잔여 캐시 때문에 성공하는 상황이라면 깨끗한 원격 맥이 문제의 경계를 확인하는 검증 도구가 될 수 있습니다.
SECTION 05 조건별 운영 결정
다음 조건으로 현재 노드를 유지할지, 격리 노드를 추가할지 판단하십시오.
Package.resolved가 커밋되어 있고 서비스 계정의 읽기 전용 인증이 검증되면 기존 노드에서 최소 빌드를 진행합니다. 그렇지 않으면 자동 해석과 공유 키 사용을 중지하고 잠금 상태와 계정을 먼저 고정합니다.- 서명 자산이 의존성 노드와 분리되어 있으면 두 노드의 재시작 복구를 각각 검증합니다. 그렇지 않으면 서명 노드를 별도로 구성한 뒤 운영 배포를 재개합니다.
- 깨끗한 작업 공간에서도 같은 저장소 끝점에 접근하면 캐시를 원인으로 보지 않습니다. 그렇지 않으면 캐시와 작업 공간 잔여물을 분리해 재현합니다.
- 여러 프로젝트가 서로 다른 신뢰 영역을 사용하면 프로젝트별 계정 또는 저장소별 읽기 전용 신원을 선택합니다. 그렇지 않으면 최소 범위의 공용 계정을 사용할 수 있지만, 작업 공간과 인증 파일은 분리해야 합니다.
- 공유 노드가 재시작 후에도 계정·키체인·작업 공간을 초기화하지 못하면 해당 노드를 생산 서명에 사용하지 말고 격리된 노드로 회귀합니다.
- 현장 맥의 교체와 용량 확장이 늦어 CI 대기열이 누적되면 임시 원격 맥을 별도 의존성 해석 풀로 시험합니다. 단, 서명 작업은 승인된 전용 자원에 남겨야 합니다.
기업용 원격 맥을 검토할 때는 VPSNIX의 맥 원격 이용 안내에서 접근 방식과 운영 조건을 확인한 뒤, 실제 조직의 계정 분리 요구와 대조하십시오. 비용을 비교할 때는 VPSNIX 요금 안내와 함께 노드 교체, 인증서 관리, 장애 대응에 드는 내부 비용까지 계산해야 합니다.
SECTION 06 인프라 팀: 깨끗한 노드 인수 기준
사이트의 실제 노드별 제공 구성, 지역, 대여 기간, 최초 해석과 빌드 기록은 이 글에서 확인할 수 없으므로 특정 성능이나 복구 시간을 제시하지 않습니다. 대신 인수 기록에는 다음 항목을 포함하십시오.
- 새로 전달된 맥에서 서비스 계정과 홈 경로를 확인합니다.
- 저장소별 읽기 전용 키를 주입하고 접근 범위를 기록합니다.
Package.resolved가 있는 커밋으로 최초 의존성 해석을 실행합니다.- 캐시가 없는 작업 공간에서 최초 빌드를 수행합니다.
- 노드를 재시작한 뒤 인증과 작업 공간 초기화 상태를 확인합니다.
- 다른 노드로 교체한 뒤 같은 커밋을 다시 실행합니다.
- 기존 노드와 새 노드의 로그, 끝점, 종료 상태를 비교합니다.
이 증거가 있어야 수정이 특정 장비의 잔여 상태에 의존하지 않는다고 말할 수 있습니다. 현재 공유 맥이 계정과 작업 공간을 분리하지 못한다면, 먼저 격리된 원격 맥에서 의존성 해석을 검증하고 이후 서명 풀과 용량 계획을 따로 세우는 편이 안전합니다.
SECTION 07 자주 묻는 운영 판단
FAQ는 위 메타데이터에 함께 제공했습니다. 핵심은 캐시 삭제가 아니라 실행 정체성과 의존성 상태를 먼저 고정하는 것입니다.
현재 방식이 개발자 개인 맥에 의존하면 개인 키와 대화형 SSH 에이전트가 장애 원인이 되고, 공유 맥에 의존하면 작업 공간 잔여물과 서명 자산 노출 범위가 커집니다. 필요한 기간만 원격 맥을 임대하면 새 노드에서 깨끗한 의존성 해석을 검증하고, 기존 장비의 교체 지연과 하드웨어 유지 부담을 피할 수 있습니다. 다만 장기간 고정 부하가 계속되거나 물리 장치 접근이 필요하다면 직접 구매가 더 적합할 수 있습니다.
서비스 계정과 Package.resolved를 바로잡은 뒤 격리된 원격 맥에서 재현하려는 경우, VPSNIX의 주문 절차에서 기업용 맥 노드 시험 조건을 확인하십시오. 핵심은 맥을 추가하는 것이 아니라, 인증·계정·작업 공간·서명 자산이 서로 섞이지 않는다는 증거를 남기는 것입니다.