macOS 27에서 CodeQL 추적이 멈춘다: 보안 CI 전환 점검
새 Xcode로 빌드는 성공해도 보안 분석은 작동하지 않을 수 있습니다. 추적 빌드가 필요한 언어와 빌드 없는 분석의 차이를 구분하고 CI 고정·검증·복구 절차를 정리합니다.
GitHub는 2026년 10월 19일 macOS 27·Xcode 27에서 CodeQL의 추적 기반 분석에 제한이 생긴다고 공지했습니다. Apple이 일부 시스템 바이너리와 라이브러리에서 Intel 코드를 더 이상 제공하지 않아 빌드를 추적하는 방식이 영향을 받습니다. 앞서 소개한 Xcode 27 러너 도입과는 다른 소식으로, 이번에는 보안 분석이 유지되는지를 별도로 점검해야 합니다.
영향을 받는 언어
Xcode 27이 설치된 환경에서는 C/C++·C#·Go·Java·Kotlin·Swift의 traced extraction을 사용할 수 없습니다. macOS 27에서도 해당 언어의 추적 추출을 사용할 수 없을 수 있습니다. 특히 Swift 6.4는 플랫폼과 무관하게 지원하지 않는다고 공지했습니다. Intel Mac 지원은 2026년 12월 중순 종료 예정이라는 별도 일정도 포함됩니다.
모든 CodeQL 분석이 같은 방식으로 고장 난다는 뜻은 아닙니다. 공식 공지는 C/C++·C#·Java에 대해 빌드를 추적하지 않는 none 모드 전환을 대안으로 제시합니다. 이를 Swift나 Kotlin에도 그대로 적용하면 안 됩니다. Java와 Kotlin이 섞인 저장소에서 none을 선택하면 Kotlin은 분석되지 않고 경고가 발생한다는 공식 문서의 제한을 함께 읽어야 합니다.
변경 전 준비
저장소의 code scanning 사용 자격과 관리자 권한을 확인하고 현재 기본 설정인지 고급 설정인지 기록합니다. 공개 저장소와 조직의 비공개 저장소는 사용 조건과 계약이 다를 수 있습니다. 기존 워크플로 파일과 마지막 성공 로그, 러너 이미지, Xcode 버전, 분석 언어, 분석 대상을 보존하세요. 이 글의 예제는 공식 문서 기준이며 실제 GitHub Actions 실행은 하지 않았습니다.
Swift 또는 다른 언어의 추적 빌드를 유지해야 한다면 공식 권고는 macOS 26 이하·Xcode 26 이하로 고정하는 것입니다. 운영체제 라벨만 바꿔서는 도구 체인이 보장되지 않습니다. 조직에서 사용 가능한 이전 이미지와 설치된 Xcode 경로를 확인한 후 명시적으로 선택해야 합니다. 자동으로 최신 버전을 따라가는 latest 라벨은 이번 호환성 문제의 회피책이 아닙니다.
빌드 없는 최소 예
다음은 Kotlin이 없는 Java 시험 저장소에서 사용할 고급 설정 예입니다. 기존 기본 설정이 있다면 관리자가 전환 절차를 확인한 뒤 중복 분석이 생기지 않게 구성합니다. .github/workflows/codeql-java-none.yml에 저장하고 수동 실행합니다. 액션의 주 버전은 공식 문서 예시를 따르며 조직의 SHA 고정 정책이 있으면 승인된 커밋으로 고정하세요.
name: CodeQL Java without build
on:
workflow_dispatch:
permissions:
contents: read
security-events: write
jobs:
analyze:
runs-on: ubuntu-latest
timeout-minutes: 20
steps:
- uses: actions/checkout@v6
- uses: github/codeql-action/init@v4
with:
languages: java-kotlin
build-mode: none
- uses: github/codeql-action/analyze@v4위 예제는 macOS에서 Swift를 분석하는 해결책이 아니라 Java 소스 분석을 별도 Linux 작업으로 분리한 실무 예입니다. 빌드 명령과 배포 인증서 없이 실행해 코드 스캔 결과를 올립니다. Actions 로그에서 초기화·데이터베이스 생성·분석 및 업로드가 성공했는지 확인하고 Security의 code scanning에서 최신 커밋과 분석 언어를 대조하세요. 경고 개수 0만으로 성공을 판단하지 않습니다.
결과의 범위 확인
none은 실제 빌드를 실행하지 않으므로 빌드 과정에서 생성하는 코드가 분석되지 않습니다. 의존성 추정이 부정확하면 결과 정확도가 낮아질 수 있습니다. 코드 생성이 많은 고위험 프로젝트라면 단순히 파이프라인을 녹색으로 만들기 위해 none으로 전환하지 말고 기존 추적 가능한 환경을 유지하며 비교해야 합니다.
주요 설정인 languages는 분석 언어, build-mode는 추출 방식입니다. timeout-minutes는 대기 시간을 제한할 뿐 분석 품질을 높이지 않습니다. 수동 트리거는 시험 실행 횟수를 통제하기 위한 선택입니다. 본격 적용 전 기존 결과와 새 결과에서 분석 파일 범위와 경고 차이를 검토하고, 의도하지 않은 언어 누락이 없는지 확인합니다.
권한과 비용
security-events: write는 결과 업로드를 위해 부여한 권한입니다. 읽기만 하는 임의 작업에 이 권한을 재사용하지 마세요. 코드와 분석 산출물이 GitHub 서비스에서 처리되므로 조직의 코드 처리 정책을 확인해야 합니다. 비공개 저장소의 보안 기능 계약과 Actions 사용량 비용도 따로 검토해야 하며 예제가 무료 실행을 보장하지는 않습니다. fork 등 신뢰할 수 없는 코드에는 비밀과 높은 권한을 제공하지 않습니다.
오류와 복구
추출 실패가 나면 먼저 Xcode·macOS·Swift의 실제 버전을 로그와 대조하고 init 단계가 선택한 언어와 모드를 확인합니다. Java none에서 Kotlin 경고가 보이면 무시하지 말고 별도 빌드 기반 분석이 필요한지 결정하세요. 업로드 권한 오류는 권한과 저장소 자격을 확인하고, 호환성 오류를 토큰 권한 확대나 무조건적인 액션 버전 변경으로 해결하려 하지 않습니다.
시험을 되돌리려면 새 워크플로를 제거하거나 변경 커밋을 되돌리고 기존의 마지막 성공 구성으로 복구합니다. 단, 이미 호환되지 않는 최신 이미지로 이동한 상태라면 파일 롤백만으로 해결되지 않습니다. 제공 중인 이전 러너와 Xcode를 함께 복원해야 합니다. 기존 경고나 이미 발생한 Actions 비용은 워크플로 삭제로 사라지지 않습니다.