Swift 6.4는 2026년 9월 15일 공개됐으며, SwiftPM의 기본 빌드 플랫폼으로 Swift Build를 사용한다고 Swift 공식 릴리스 노트가 밝힙니다. (공식 릴리스 노트)
CI가 실제로 호출하는 Swift와 SwiftPM부터 확인한 뒤 기존 작업과 분리해 빌드와 테스트를 실행하세요. 새 도구 체인에서 프로젝트 결과가 재현될 때만 단계적으로 전환해야 합니다. 이 변경만으로 모든 Xcode 프로젝트의 빌드 과정이 자동 전환되는 것은 아닙니다.
이 글은 Swift Package 빌드 파이프라인을 유지 관리하며 의존성, 빌드, 테스트 증거를 확인해야 하는 엔지니어를 위한 안내입니다.
Swift 도구 체인 업그레이드의 도입 조건을 정하려는 팀과 macOS CI 작업을 운영하는 담당자도 대상입니다.
마지막 업데이트: 2026년 11월 11일. Swift 공식 릴리스 노트와 SwiftPM 6.4 공식 문서를 기준으로 확인했습니다.
[ SECTION_01 ] 먼저 확인할 기준은 CI 작업의 도구 체인입니다
CI 머신에 Swift 6.4가 설치됐다는 사실만으로 작업이 그 버전을 사용한다고 볼 수 없습니다. 실행 계정의 셸 환경, PATH 우선순위, 작업 설정에 따라 다른 바이너리가 호출될 수 있습니다. 먼저 시험 작업과 기존 작업에서 같은 진단 명령을 실행하고 결과를 로그로 남깁니다.
which swift
swift --version
swift package --version
Xcode 명령을 사용하는 작업에는 다음 결과도 기록합니다.
xcode-select -p
xcodebuild -version
Apple의 명령줄 도구 참고 자료와 Swift의 macOS 설치 안내를 기준으로 명령과 설치 경로를 확인합니다. 로그에는 명령의 출력뿐 아니라 실행한 작업 이름, 커밋 식별 정보, 실행 환경도 함께 남깁니다. 개발자가 셸에서 확인한 결과와 CI 실행 결과가 다르면 CI 쪽 결과를 기준으로 조사해야 합니다.
[ SECTION_02 ] 의존성 조건과 잠금 결과를 같은 커밋에서 비교합니다
도구 체인을 바꾸기 전후의 의존성 결과는 같은 커밋과 같은 저장소 조건에서 대조해야 합니다. 먼저 잠금 파일의 변경 여부를 확인하고, 미러 설정과 비공개 의존성 접근 조건도 함께 보존합니다. Swift Package의 의존성 선언과 버전 조건은 Swift Package 설명 문서를 참고해 점검할 수 있습니다.
| 검수 항목 | 기존 작업에서 남길 증거 | 시험 작업에서 대조할 내용 | 판단 |
|---|---|---|---|
| 도구 실행 | Swift 및 SwiftPM 버전 출력, 실행 경로 | 같은 작업에서 실제 호출된 버전과 경로 | 다르면 전환 전 원인 조사 |
| 의존성 | 커밋, 잠금 파일, 저장소 설정 | 동일 조건의 해석 결과와 변경 내역 | 설명되지 않은 차이는 보류 |
| 빌드 | 명령, 대상, 종료 결과, 로그 | 필요한 대상의 산출물과 실패 위치 | 실패 지점을 재현할 수 있어야 함 |
| 테스트 | 발견·실행 결과와 로그 | 동일 범위 테스트의 실행·결과 | 빌드 성공만으로 통과 처리 금지 |
| 캐시 | 사용 조건과 실행 환경 | 정리 또는 재사용 후의 재현성 | 단일 성공만으로 안정성 판정 금지 |
의존성 결과에 차이가 있다고 해서 곧바로 SwiftPM의 일반적인 회귀로 결론 내리지 마세요. 잠금 파일, 미러, 저장소 인증, 네트워크 접근 조건을 하나씩 비교하고 차이가 다시 발생하는지 확인합니다. 로그와 재현 절차가 확보되지 않은 위험은 해당 프로젝트에서 확인되지 않은 상태로 기록합니다.
[ SECTION_03 ] 빌드 대상과 테스트 결과는 따로 검수합니다
SwiftPM 빌드 작업에서는 프로젝트가 실제로 사용하는 명령과 빌드 대상을 기준으로 컴파일 완료 여부, 산출물 생성 여부, 실패 로그를 확인합니다. Swift 공식 빌드 안내는 Swift 빌드와 명령 사용을 확인할 때 참고할 수 있습니다. CI에서 쓰는 명령을 그대로 시험하고, 어떤 대상에서 실패했는지 로그에 남겨야 합니다.
여기서 SwiftPM 작업과 Xcode 프로젝트 작업의 경계를 분명히 해야 합니다. SwiftPM 기본 빌드 플랫폼에 관한 변경을 Xcode 프로젝트 전체의 빌드 시스템이나 Apple 플랫폼 아카이브 과정에 그대로 적용해서는 안 됩니다. 아카이브가 CI 단계에 포함된다면 Apple의 아카이브 과정 설명을 참고해 해당 단계를 별도 작업으로 검수합니다.
빌드 성공과 테스트 통과도 분리해 기록합니다. 테스트가 실제로 발견되고 실행됐는지, 실패 시 어떤 로그가 남는지, 같은 조건에서 다시 실행했을 때 결과가 재현되는지 확인합니다. 실패가 나면 도구 체인, 프로젝트 코드, CI 환경 가운데 무엇이 달라졌는지 증거를 모아 구분합니다. 한 번의 실패나 성공만으로 원인을 확정하지 않습니다.
[ SECTION_04 ] 캐시를 바꿔 가며 재현성과 전환 조건을 평가합니다
캐시를 재사용한 실행과 정리한 뒤의 실행을 비교하면 캐시 상태가 결과에 영향을 주는지 확인할 수 있습니다. 환경 변수, 실행 계정, 의존성 접근 조건처럼 빌드에 영향을 줄 수 있는 차이도 기록합니다. 캐시 동작을 특정하게 단정하려면 Swift 공식 자료로 확인하거나, 환경과 실행 날짜를 명시한 실측 근거가 있어야 합니다. 한 번 통과한 결과만으로 반복 실행의 안정성을 증명할 수는 없습니다.
| 판정 | 검수 근거 | 다음 조치 |
|---|---|---|
| 통과 | 대상 프로젝트의 빌드와 테스트가 같은 커밋 및 의존성 조건에서 재현됨 | 제한된 작업부터 적용하고 결과를 계속 기록 |
| 보류 | 실행 경로, 의존성 또는 테스트 결과 차이가 설명되지 않음 | 차이를 분리해 재현한 뒤 다시 검수 |
| 회귀 | 필요한 빌드 대상이나 테스트가 기존 기준을 충족하지 못함 | 기존 도구 체인으로 되돌리고 실패 증거 보존 |
이 판정표는 CI에서 수집한 결과를 분류하는 기준입니다. 실제 검수 결과가 없는 상태에서 특정 프로젝트의 통과 여부를 미리 정하지 않습니다. 시험 작업에서는 버전 출력, 실행 경로, 커밋, 의존성 변경, 빌드 로그, 테스트 결과, 캐시 조건을 한 묶음으로 남기면 뒤따르는 재검수에서 비교가 쉬워집니다.
[ SECTION_05 ] 작업 분리 여부와 결과 증거로 전환을 결정합니다
실행 절차는 다음 순서로 진행합니다.
- 기존 macOS CI 작업에서 Swift와 SwiftPM의 버전 및 실행 경로를 저장합니다.
- 같은 커밋을 대상으로 별도 시험 작업을 만들고 변경 전후의 실행 조건을 기록합니다.
- 잠금 파일, 의존성 미러, 비공개 저장소 접근 조건을 비교합니다.
- 프로젝트가 실제 사용하는 SwiftPM 빌드 명령과 대상을 실행하고 산출물과 실패 로그를 확인합니다.
- 테스트가 발견되고 실행됐는지 별도로 확인한 뒤 실패 결과를 같은 조건에서 재실행합니다.
- 캐시를 재사용한 경우와 정리한 경우의 결과를 비교하고, 위 판정표에 따라 통과·보류·회귀로 분류합니다.
팀에 격리된 macOS 시험 환경이 없다면, 현재 환경을 계속 공유하는 방식과 별도 원격 Mac을 사용하는 방식을 운영 책임까지 포함해 비교할 수 있습니다. 임시 검수 노드가 필요한 경우에는 NOVAKVM의 맥 미니 렌탈 안내에서 이용 조건을 먼저 확인하고, 한국에서 사용할 노드의 주문 조건은 한국 지역 맥 미니 주문 안내에서 확인할 수 있습니다. CI에 필요한 접근 방식과 작업 범위가 맞는지 판단하세요. 반대로 장기간 일정한 부하를 지속하거나 물리 인터페이스가 필요한 팀은 자체 Mac 운영이 더 적합할 수 있습니다.
[ SECTION_06 ] 자주 묻는 질문
Swift 6.4에서 SwiftPM의 기본 빌드 플랫폼은 어떻게 바뀌었나요?
Swift 공식 릴리스 노트에 따르면 Swift 6.4에서 SwiftPM의 기본 빌드 플랫폼은 Swift Build입니다. 이는 SwiftPM을 호출하는 작업에서 검수할 변화입니다. Xcode 프로젝트나 Apple 플랫폼 아카이브까지 자동으로 바뀐다고 해석하지 말고, 각각의 CI 명령과 결과를 확인해야 합니다.
macOS CI가 실제로 Swift 6.4를 쓰는지 어떻게 확인하나요?
CI 작업 안에서 swift --version, which swift, swift package --version을 실행해 출력과 경로를 저장합니다. Xcode 명령을 쓰는 작업은 xcode-select -p와 xcodebuild -version도 함께 확인합니다. 개발자 셸이 아닌 CI 작업의 실행 계정과 환경에서 수집한 결과를 기준으로 삼습니다.
업그레이드 후 Swift Package 빌드가 실패하면 어디부터 살펴봐야 하나요?
먼저 실제 실행된 도구 경로와 버전, 실패 명령과 대상, 전체 로그를 확인합니다. 같은 커밋의 잠금 파일과 의존성 미러, 비공개 저장소 조건도 비교합니다. 동일한 조건에서 다시 실패하는지 확인하기 전에는 도구 체인의 문제라고 단정하지 말고 프로젝트와 CI 환경의 차이도 함께 조사합니다.
Swift 6.4를 정식 CI에 바로 적용해도 되나요?
프로젝트의 빌드와 테스트가 새 도구 체인에서 재현되기 전에는 정식 작업 전체를 전환하지 않는 편이 안전합니다. 먼저 기존 작업과 분리해 같은 커밋과 의존성 조건으로 시험하고, 빌드 및 테스트 결과를 따로 남깁니다. 결과가 불분명하면 전환을 보류하거나 기존 도구 체인으로 회귀합니다.
Swift 6.4 도입은 설치 여부가 아니라 실제 CI 작업의 실행 경로, 의존성, 빌드와 테스트 증거를 기준으로 판단해야 합니다. 독립 시험 환경이 없어 반복 검수가 어렵다면 원격 Mac을 임시 검증 환경으로 쓸 수 있는지 살펴보세요. 다만 지속적인 고정 부하나 물리 장비 연결이 필요하다면 자체 Mac 운영이 더 맞을 수 있습니다.
자주 묻는 질문
Swift 6.4에서 SwiftPM의 기본 빌드 방식은 무엇이 달라졌나요?
Swift 공식 릴리스 노트는 Swift 6.4에서 SwiftPM이 기본 빌드 플랫폼으로 Swift Build를 사용한다고 설명합니다. 이는 SwiftPM 명령을 사용하는 프로젝트에서 확인할 변화입니다. Xcode 프로젝트의 모든 빌드나 Apple 플랫폼 아카이브 과정까지 자동으로 전환된다는 뜻은 아닙니다. 실제 CI가 실행하는 명령과 대상에 맞춰 별도로 검수해야 합니다.
macOS CI 작업이 실제로 Swift 6.4를 사용하는지 어떻게 확인하나요?
작업 로그에 swift --version 결과뿐 아니라 which swift로 확인한 실행 경로도 남깁니다. Xcode 도구를 쓰는 작업이라면 xcode-select -p와 xcodebuild -version 결과도 함께 기록합니다. 셸에서 수동 실행한 결과만으로 판단하지 말고, CI 설정의 실제 실행 계정과 명령에서 같은 정보를 출력해야 합니다. 그래야 다른 경로의 Swift가 선택되는 경우를 구별할 수 있습니다.
Swift 6.4로 바꾼 뒤 Swift Package 빌드가 실패하면 무엇부터 확인하나요?
먼저 실패한 CI 작업의 실행 경로와 도구 버전을 기준선과 대조합니다. 다음으로 같은 커밋에서 Package.resolved, 의존성 미러와 비공개 저장소 설정을 비교합니다. 그 뒤 실패한 빌드 명령, 대상, 전체 로그를 보존하고 동일 조건으로 다시 실행합니다. 재현 결과가 없으면 도구 체인 결함이나 일반적인 호환성 문제라고 단정하지 않는 편이 안전합니다.
Swift 6.4를 정식 CI에 바로 적용해도 괜찮을까요?
기존 작업과 분리한 시험 작업에서 프로젝트의 실제 빌드와 테스트를 먼저 실행하는 것이 안전합니다. 같은 커밋과 의존성 조건을 유지하고, 빌드 성공과 테스트 성공을 각각 기록합니다. 결과가 재현되고 필요한 대상까지 확인되면 일부 작업부터 적용합니다. 로그가 부족하거나 결과가 달라졌다면 원인을 찾을 때까지 기존 도구 체인으로 회귀할 수 있도록 전환을 보류합니다.