CodeQL 번들이 갈라진다는 것, 무엇을 의미하는가

오늘 GitHub Changelog에서 본 이 소식

원문을 확인해본 결과, GitHub은 2026년 9월 22일 CodeQL CLI 2.27.0부터 올인원 번들(all-platform CodeQL bundle, codeql-bundle.tar.gz와 codeql-bundle.tar.zst)에 대한 지원 종료(deprecation) 공지를 발표했습니다. 2027년 3월 중순에는 이 파일들을 완전히 제거할 예정입니다.

이건 겉으로는 번들 형식 변경처럼 보이지만, n8n이나 GitHub Actions 같은 자동화 인프라 위에서 CodeQL을 굴려온 입장에서는 꽤 직결된 문제입니다. 35년을 기술 생태계의 큰 흐름 속에서 지켜보면서 느낀 것은, 이런 알림들이 나올 때는 대개 배경에 실용적인 이유가 있다는 점입니다.

무엇이 정확히 바뀌는가

현재 상황은 이렇습니다. 지금까지 CodeQL 사용자는 codeql-bundle.tar.gz 같은 단일 파일을 다운로드하면 Linux, macOS, Windows 어느 환경이든 거기서 필요한 바이너리를 꺼내 쓸 수 있었습니다. 편의성 측면에서 좋은 방식이었죠.

GitHub의 새 방향은 이것입니다. 각 플랫폼과 아키텍처(architecture)에 맞는 번들을 따로 내려받으라는 겁니다. 특히 주목할 점은 Linux ARM64(예를 들어 Apple Silicon이나 Raspberry Pi 환경)의 바이너리가 이제 “플랫폼 전용 다운로드”를 통해서만 제공된다는 부분입니다. 올인원 번들에는 ARM64가 포함되지 않는다는 뜻입니다.

이것은 단순히 “파일을 여러 개 내려받아야 한다”는 불편함을 넘어, 자동화 워크플로우 구성 방식을 다시 생각해야 한다는 신호입니다.

1인 자동화 운영자 입장에서 보면

n8n 워크플로우 안에서 CodeQL 스캔을 자동으로 돌리거나, GitHub Actions 환경에서 보안 검사를 매번 따로 설정해온 분이라면 지금 질문이 생길 겁니다.

첫째, 배포 파이프라인에서 다운로드 URL을 어떻게 관리할 것인가. 지금까지는 “이 버전의 all-platform 번들”로 한 줄 지정하면 됐지만, 이제는 실행 환경(OS와 CPU 아키텍처)을 먼저 감지하고 그에 맞는 URL을 동적으로 구성해야 합니다.

둘째, ARM64 환경 지원. 요즘 자동화 인프라를 클라우드 위에 구축하는 사람이 많은데, 비용 절감 목표로 ARM 기반 인스턴스(AWS Graviton, Oracle Ampere 등)로 옮겨가는 추세입니다. 이런 환경에서는 이미 platform-specific 번들만 쓸 수밖에 없습니다. 그런데 이제 x86 환경도 같은 방식으로 가야 한다는 것입니다.

셋째, 버전 관리의 복잡도. 여러 환경에서 CodeQL을 돌려야 한다면, 각각 다른 번들 URL과 체크섬(checksum)을 추적해야 합니다. 자동화 스크립트가 한두 줄 더 늘어나고, 테스트할 환경 조합도 늘어납니다.

왜 이런 결정을 했을까

원문에는 직접 이유를 쓰지 않았지만, 업계 관관적으로 보면 몇 가지 추측이 가능합니다.

첫째는 저장소와 대역폭(bandwidth) 관리입니다. 모든 플랫폼을 담은 번들은 크기가 상당합니다. 매 릴리스마다 이를 유지하고 배포하는 비용은 꾸준히 들어갑니다. 각 플랫폼별 번들로 쪼개면 사용자는 필요한 것만 받고, GitHub은 스토리지와 네트워크를 효율화할 수 있습니다.

둘째는 빌드 프로세스의 간소화입니다. 모든 바이너리를 한 번에 컴파일하고 테스트하려면 CI/CD 파이프라인이 복잡해집니다. 플랫폼별로 분리하면 각 빌드를 독립적으로 관리하고 버전 관리도 유연해집니다.

셋째은 보안입니다. 자동으로 필요한 것만 받는다는 것은 불필요한 바이너리에 노출되지 않는다는 의미이기도 합니다.

다음 6개월간 뭘 준비해야 하나

지금부터 2027년 3월까지는 준비 기간입니다. GitHub이 충분한 노티스를 준 셈입니다.

현재 all-platform 번들을 쓰고 있다면 스크립트를 점검하세요. 특히 CI/CD 파이프라인이나 n8n 자동화 워크플로우에서 CodeQL 다운로드 부분을 찾아내고, 플랫폼 감지 로직을 추가하는 것을 추천합니다. GitHub의 문서(supported platforms 페이지)를 보면 현재 정확히 어떤 플랫폼 조합이 지원되는지 확인할 수 있습니다.

또 한 가지는, 혹시 CI/CD 환경에서 예상치 못한 플랫폼 조합을 쓰고 있지 않은지 확인하는 것입니다. 올인원 번들은 “일단 있는 것” 중심으로 동작했지만, 이제는 “공식 지원하는 것”만 제공됩니다. 그 차이는 생각보다 크게 작용할 수 있습니다.

계속 지켜봐야 할 지점

여기서 흥미로운 질문이 생깁니다. GitHub은 이 정책을 통해 실제로 올인원 번들 다운로드율이 얼마나 줄어들기를 기대하는 걸까요? 만약 많은 사용자가 “번들 여러 개를 일단 다 받아두는” 방식으로 대응한다면 결국 대역폭 절감 효과가 미미할 수도 있습니다. 이 부분은 계속 지켜봐야 할 지점입니다.

이 이슈는 다음 편에서 실제로 2027년 3월 제거가 진행되었는지, 또 그 시점에서 개발자 커뮤니티가 어떻게 대응했는지를 이어서 다뤄보겠습니다.