Swift 6.4 SwiftPM SBOM을 macOS CI에 통합하는 방법 2026

Swift 6.4는 2026년 9월 15일 공개됐으며 SwiftPM의 SBOM 생성을 지원합니다(Swift 6.4 공식 릴리스 안내). 실제 빌드 의존성을 남기려면 빌드 명령에서 SBOM을 생성하고 CI 산출물로 함께 보관하는 방법을 먼저 검토하세요. 패키지 의존성 목록만 필요하다면 별도 생성 명령이 적합할 수 있습니다. SBOM은 취약점 검사나 규정 준수 판정 그 자체가 아닙니다.

Swift 패키지 유지관리자: 패키지나 제품의 의존성 목록을 만들어 배포해야 하는 경우에 적합합니다.
Apple 플랫폼 CI 엔지니어: macOS 빌드와 SBOM 생성, 산출물 보관을 한 흐름으로 묶으려는 경우에 적합합니다.
보안·릴리스 담당자: SBOM의 형식과 범위, 전달 시 한계를 확인하려는 경우에 적합합니다.

마지막 업데이트: 2026년 10월 26일. 날짜와 기능은 Swift 6.4 릴리스 안내, Swift 6.4.1 릴리스 안내, SE-0509 제안을 기준으로 확인했습니다. 실제 명령과 옵션은 적용할 Swift 툴체인에서 다시 확인해야 합니다.

시작 단계: SBOM의 범위부터 고정합니다

SBOM은 소프트웨어 구성 요소를 기술하는 목록입니다. 먼저 산출물이 설명해야 할 대상이 패키지 전체인지, 특정 제품인지, 실제 빌드에 사용된 의존성인지 정하세요. 범위를 정하지 않으면 파일은 생성돼도 릴리스나 감사에서 기대하는 내용과 어긋날 수 있습니다.

SE-0509는 SPDX와 CycloneDX 형식을 다루며, 빌드 명령과 독립적인 패키지 생성 명령이 참조하는 의존성 그래프가 다를 수 있음을 설명합니다. 빌드 명령은 SwiftBuild의 빌드 의존성 그래프를 이용할 수 있고, 독립 생성 명령은 패키지 의존성 그래프를 대상으로 합니다. 따라서 두 방법으로 만든 SBOM이 같은 항목을 담는다고 가정하지 마세요.

형식은 전달받는 도구와 요구사항에 맞춰 고릅니다. SPDX 공식 사양 목록과 CycloneDX 공식 사양 개요에서 각 형식의 사양을 확인하고, 사내 분석 도구나 릴리스 절차에서 읽을 수 있는지 검증하세요. 형식 이름만 맞추는 것으로는 소비 시스템과의 호환성이 보장되지 않습니다.

도구 체인 확인: 재현 가능한 입력을 준비합니다

macOS CI 작업이 시작되면 먼저 실행 중인 Swift 버전과 작업 디렉터리를 기록합니다. Swift 6.4.1은 2026년 10월 13일 발표된 유지보수 릴리스입니다(Swift 6.4.1 발표). 도구 체인이 해당 버전이라고 추정하지 말고 작업 로그에서 확인하세요. 설치와 도구 체인 선택은 Swift 공식 macOS 설치 안내를 기준으로 점검할 수 있습니다.

swift --version
pwd
git status --short

이어서 저장소의 의존성 해석 파일이 커밋돼 있는지, CI에서 의도한 브랜치와 커밋을 빌드하는지 확인합니다. Package.resolved가 생성되거나 갱신되는 프로젝트라면 해당 파일도 빌드 작업과 함께 보관하세요. SBOM만 별도로 남기고 소스 커밋이나 의존성 해석 상태를 기록하지 않으면 나중에 어떤 입력에서 생성됐는지 재구성하기 어렵습니다.

SwiftPM은 패키지 선언과 의존성 관리를 담당합니다. 패키지 구조와 선언 항목은 Swift Package Manager의 패키지 설명 문서에서 확인하세요. CI 로그에는 적어도 커밋 식별자, Swift 버전, 작업 경로, 의존성 해석 파일을 연결해 두는 편이 좋습니다.

독립 생성 결과를 빌드 결과와 같은 범위라고 판단하지 마세요. 조건에 따라 선택되는 의존성은 플랫폼과 빌드 설정에 좌우될 수 있습니다. 실제로 빌드된 범위를 추적해야 한다면 빌드 그래프를 사용하는 경로와 결과를 우선 확인하세요.

생성 경로 선택: 빌드 그래프와 패키지 그래프

Swift 6.4 SwiftPM SBOM 생성은 SPDX 또는 CycloneDX를 사용할 수 있습니다. 다만 swift build에서 생성하는 방식과 swift package generate-sbom 방식은 목적이 다릅니다. 옵션의 정확한 표기와 조합은 설치된 SwiftPM 버전의 도움말 및 SE-0509를 기준으로 정하세요. 문서에 없는 플래그를 복사해 CI에 고정하면 도구 체인 변경 시 작업이 실패할 수 있습니다.

생성 경로	적합한 용도	범위 확인 시 주의점
`swift build`와 SBOM 생성 옵션	특정 빌드 작업에 연결된 의존성을 함께 남기려는 경우	SwiftBuild의 빌드 의존성 그래프를 기준으로 결과를 확인합니다.
`swift package generate-sbom`	패키지 의존성 그래프를 별도로 내보내려는 경우	실제 빌드에 선택된 의존성 범위와 다를 수 있습니다.

swift build가 제공하는 기능과 옵션은 SwiftPM SwiftBuild 명령 문서에서 확인할 수 있습니다. SE-0509가 제시하는 두 경로의 의존성 범위도 함께 비교하세요. 이 방식으로 제품 단위와 패키지 단위의 산출물을 구별하고, 요구사항에 맞는 쪽을 선택할 수 있습니다.

선택 기준	빌드 시 생성 우선	독립 생성 우선
기준으로 삼을 대상	CI에서 실제 실행하는 빌드	패키지 의존성 그래프
주된 목적	빌드 기록과 SBOM을 함께 연결	패키지 구성 목록을 별도 생성
확인할 차이	빌드 설정과 플랫폼별 선택 조건	빌드에서 선택되지 않은 패키지 의존성의 포함 여부

SPDX와 CycloneDX 가운데 어느 형식을 택하든 결과 파일을 실제 소비 도구로 읽어 보세요. 확장자만 바꾸거나 형식 이름을 입력하는 것으로 변환이 끝난다고 볼 수 없습니다. 생성 옵션에서 형식을 지정하고, 파일 내용이 해당 사양에 맞는지도 확인해야 합니다.

macOS CI 연결: 생성부터 보관까지 이어 붙입니다

아래 절차를 기존 빌드 작업에 추가합니다. 도구 체인별 옵션은 명령 도움말에서 확인하고, 작업 로그에 선택한 형식과 범위를 남기세요.

[ ] 작업이 예상한 저장소 커밋에서 실행되는지 확인합니다.
[ ] swift --version 결과와 작업 디렉터리를 로그에 기록합니다.
[ ] 의존성 해석 파일이 의도한 상태인지 확인하고, 빌드와 연결해 보관합니다.
[ ] 대상 범위에 따라 swift build의 SBOM 옵션 또는 swift package generate-sbom을 선택합니다.
[ ] 생성 결과를 고정된 출력 디렉터리에 저장하고, 파일 존재 여부와 내용을 검사합니다.
[ ] SBOM, 빌드 로그, 커밋 식별자, 의존성 해석 파일을 동일한 CI 실행과 연결해 보관합니다.

별도 생성 명령의 기본 형태는 swift package generate-sbom입니다. 실제 형식·출력 경로 옵션과 유효한 조합은 사용하는 툴체인에서 다음처럼 확인하세요.

swift build --help
swift package generate-sbom --help

확인한 옵션을 CI 설정에 적용한 뒤, 첫 실행에서 산출물이 예상 디렉터리에 만들어지는지 검사합니다. 빌드가 성공했더라도 SBOM 파일이 없거나 비어 있을 수 있으므로 파일 검사와 형식 검증을 별도 단계로 두세요. 공식 제안의 오류 처리 동작을 확인하되, 조직의 릴리스 정책에 따라 SBOM 생성이나 검증 실패를 배포 차단 조건으로 둘지는 따로 결정해야 합니다. 빌드 명령이 성공했다는 사실만으로 SBOM의 생성과 보관이 완료됐다고 간주하면 안 됩니다.

macOS CI에서 여러 작업이 병렬 실행된다면 파일 이름에 커밋이나 작업 식별자를 포함하는 방식으로 서로 덮어쓰지 않게 관리합니다. 산출물 보관 기한과 접근 권한도 릴리스·감사 요건에 맞추세요. SBOM은 소스 저장소에 무조건 공개해야 하는 파일이 아닙니다. 내부 보관인지 외부 배포인지 먼저 정하고, 저장 위치와 접근 범위를 그 결정에 맞춥니다.

결과 검증: 조건부 의존성과 전달 범위 확인

첫 실행 뒤에는 파일이 존재하는지만 확인하지 말고 내용과 기준 그래프를 대조합니다. 패키지 이름과 버전, 제품 범위, 직접·간접 의존성이 의도한 대상과 맞는지 살펴보세요. 의존성 해석 파일과 CI 로그를 함께 두면 차이가 생겼을 때 입력 상태를 추적할 수 있습니다.

조건부 의존성은 특히 주의해야 합니다. 플랫폼이나 빌드 설정에 따라 실제 선택되는 의존성이 달라질 수 있기 때문입니다. 패키지 의존성 그래프만 사용한 결과는 특정 macOS CI 빌드에서 선택된 구성과 완전히 일치하지 않을 수 있습니다. 따라서 “SwiftPM이 생성했다”는 사실만으로 모든 운영체제 조건과 모든 빌드 변형이 반영됐다고 결론 내리지 말고, 대상 플랫폼에서 생성한 결과와 실제 빌드 그래프를 비교하세요.

마지막으로 SBOM은 취약점 검사 결과가 아니며 라이선스 준수나 특정 감사 기준 충족을 자동으로 증명하지 않습니다. 취약점 분석에는 별도 검사 절차가 필요하고, 라이선스와 감사 요구사항은 해당 정책 및 증거 자료에 따라 판단해야 합니다. 산출물의 목적, 범위, 생성 커밋, 도구 체인을 함께 기록해야 이후 검토자가 결과를 올바르게 해석할 수 있습니다.

macOS 실행 환경 선택: 기존 CI와 원격 Mac 비교

이미 관리되는 macOS 빌드 노드가 있고 도구 체인과 산출물 보관을 통제할 수 있다면 기존 환경에 SBOM 단계를 추가하는 것이 합리적입니다. 반대로 Mac 장비가 없거나 테스트용 노드를 잠시 확보해야 한다면 자체 구매, 다른 클라우드 환경, 원격 Mac을 요구사항에 맞춰 비교하세요.

Linux CI는 macOS 전용 빌드 검증을 대신할 수 없습니다. Mac을 직접 구매하면 장비 비용과 유지관리, 장기 유휴 시간의 부담이 발생하고, 임시 가상 환경은 필요한 Apple 도구 체인이나 실제 빌드 조건을 충족하지 못할 수 있습니다. 원격 Mac도 네트워크 지연과 외부 환경에 대한 접근 관리가 필요하므로 상시 고정 부하나 물리 장치 연결이 핵심인 팀에는 적합하지 않을 수 있습니다.

CI 실행 환경을 새로 마련해야 한다면 필요한 Swift 도구 체인, 접근 방식, 산출물 보관 절차를 먼저 정리한 뒤 원격 Mac 연결 안내와 한국어 Mac 환경 안내를 비교해 보세요. 단기간의 검증용 환경이 목적이라면 NowMini의 원격 Mac 이용을 검토할 수 있습니다. 반대로 장기간 지속되는 고정 작업이나 물리 인터페이스가 꼭 필요한 경우에는 자체 장비 등 다른 방식을 유지하는 편이 나을 수 있습니다.