훌리오 메리노(Julio Merino)는 암스테르담에서 열린 BazelCon 2026의 발표와 토론을 돌아보며, AI 에이전트가 늘린 빌드·테스트 수요와 대형 산출물·설정 그래프의 확장 문제를 주요 흐름으로 꼽았다. 행사에서는 Bazel 10의 성능 개선, 원격 캐시 최적화, macOS 샌드박싱과 Starlark 도구 개선 등이 다뤄졌다.
생태계와 AI 작업 부하
Bazel 생태계를 지원하는 중립 조직 BUILD Foundation이 출범했다. Google과 커뮤니티 사이에서 우선순위를 조율하고 프로젝트 자금을 지원하는 것이 목표이며, 회원과 지원 대상 제안을 찾고 있다. 참여 문의는 info@buildfoundation.dev로 보낼 수 있고, 생태계의 문제를 알리는 연례 Bazel 사용자 설문도 진행된다.
Google은 Bazel 10을 준비하며 일부 작업 부하에서 약 15%의 성능 향상과 메모리 사용량 감소를 보고했다. 개선에는 Java 25에서 27로의 업그레이드, 액션 되감기와 Skyframe 캐시 정리 최적화, 콘텐츠 정의 청킹이 포함됐다. Google 내부에서는 Bazel을 Rust로 점진적으로 다시 작성하는 방안도 ‘Skymetal’이라는 이름으로 검토 중이지만, 이는 평가 단계다.
Snowflake와 EngFlow의 발표에서는 AI 에이전트가 사람보다 빌드와 테스트를 더 자주 실행하고, 여러 접근법을 병렬로 시도한다고 설명했다. 여러 에이전트를 동시에 쓰려고 Git worktree를 활용하는 사례가 늘면서 개발자 컴퓨터에서 Bazel 서버 여러 개가 메모리와 디스크를 압박하는 문제도 나타났다. Plaid는 AI 지원 코딩으로 빌드량이 한 해 동안 두 배가 됐고, 2026년 초 기준의 네 배에 이를 전망이라고 밝혔다. 회사는 부하 테스트와 네트워크·클라우드 할당량·소스 관리·자동 확장·캐시 인프라 개선을 거쳐 목표 부하를 감당하도록 했다.
EngFlow가 소개한 any2bazel은 CMake 빌드의 컴파일·링크 작업을 기준 자료로 추출한 뒤, Bazel의 aquery 결과와 비교해 AI 에이전트가 빌드 파일을 반복 수정하도록 한다. 발표자들은 정확성과 격리성은 대체로 양호하고 효율성은 표준 규칙으로 표현할 수 있는 빌드에서 좋은 편이라고 평가했다. 반면 에이전트가 플랫폼과 툴체인 대신 설정 플래그로 차이를 표현하는 경향이 있어 유지보수성에는 전문가 검토가 중요하다고 했다.
BuildBuddy는 원격 빌드 로그와 프로파일을 분석하고 실패를 진단·수정하는 에이전트 기능을 소개했다. 발표에서는 빌드 이벤트 데이터, 프로파일, 원격 실행 메타데이터와 로그를 함께 분석할 수 있다는 점을 설명했다.
캐시와 대규모 빌드
BuildBuddy와 Meroton은 콘텐츠 정의 청킹(CDC)을 소개했다. Bazel이 파일 전체를 하나의 덩어리로 다루는 대신 파일을 크기가 달라질 수 있는 조각으로 나눠 각각 캐시하면, 일부만 바뀐 대형 파일을 통째로 다시 전송하거나 저장하지 않아도 된다. 발표자들은 GoLink 조각의 평균 재사용률 36%, CppLink 40%, PackageTar 96%, DockerSave 98%, OCITarball 99.5%를 보고했다. BuildBuddy 추산으로는 쓰기 바이트가 35% 줄고, 청킹된 바이트의 60%가 중복 제거되며, 전체 시스템에서 하루 약 400TB의 트래픽을 피한다. 프로젝트 중앙값 기준 원격 저장 공간은 약 70%, 로컬 디스크 캐시는 약 40% 줄었다고 밝혔다.
기존 사용자는 원격 CDC를 지원하는 서버와 함께 --experimental_remote_cache_chunking을 사용할 수 있다. 발표에서는 효과를 위해 최신 Bazel 8.x 또는 9.x를 권했다. 이전 버전에는 CDC가 데이터를 손상시키지 않는지 확인하는 데 필요한 검증이 없었다. bb-clientd와 Epic Games의 Lore는 콘텐츠 주소 저장소를 활용해 파일을 여러 작업 간 재사용하거나 Bazel과 공유하는 사례로 소개됐다. Lore의 Bazel 연동은 서버가 미리 계산한 파일 다이제스트를 Bazel에 제공한다.
설정 조합이 커져 액션 그래프가 불필요하게 불어나는 문제도 다뤄졌다. 한 발표 사례에서는 12개 매개변수가 7,200만 개의 가능한 설정을 만들었지만, 실제로 의미 있는 설정은 856개였다. 발표자는 설정값을 일찍 초기화하는 전이, 경로 매핑, 플래그 적용 범위를 제한하는 기능을 대응 방법으로 설명하면서 각각의 사용상 절충점도 짚었다.
EngFlow의 프로토타입인 지속형 테스트 실행기는 Bazel 자체 테스트 모음을 실행할 때 총 테스트 시간을 46% 줄였다고 발표됐다. JVM과 테스트 실행기를 재사용할 수 있는지 조정하는 방식이다. 코드는 Bazel 포크와 rules_java 포크의 persistent-test-workers 브랜치에서 확인할 수 있으며, --enable_persistent_test_runners=JvmTestRunner로 시험할 수 있다고 소개됐다.
샌드박싱과 개발 도구
macOS에서 빠르고 정확한 샌드박스를 구현하는 문제도 여러 발표에서 다뤄졌다. OpenAI의 actiond는 로컬 Linux 가상 머신을 원격 실행기처럼 사용하고, 가상 머신 안의 actiondFS로 작업 입력을 파일 시스템에 구성한다. 발표에서는 FUSE 대신 커널 모듈을 사용한다고 설명했다. Linux 커널을 Bazel로 빌드하는 linux.bzl도 함께 소개됐다.
다른 발표는 Apple의 FSKit으로 샌드박스를 파일 시스템처럼 구현하는 방안을 살폈다. FSKit은 디렉터리 구조를 만드는 데 유리했지만 마운트 지연, 앱 패키징·공증, 자동화 환경에서의 권한 알림, 이후 파일 작업의 성능 문제가 있었다. 발표의 결론은 하나의 구현을 제시하는 대신 Bazel이 입력 목록과 네트워크 접근 설정을 샌드박스 서비스에 전달하고, 서비스가 작업 공간과 결과를 관리하는 공통 프로토콜을 제안하는 것이었다.
Starlark 타입 주석은 Bazel 8.8과 9.3에서 해석되지만 실제 타입 검사는 하지 않는다. Bazel 10에서는 주석 파일을 검사하고 최종 릴리스 시점에는 타입 검사가 기본 활성화될 예정이라고 발표됐다. OpenAI의 sty는 Bazel 버전에 의존하지 않고 Starlark 타입 검사와 편집기 기능을 제공하려는 도구다. 별도 .bzli 파일로 의존성의 타입을 기술할 수도 있다.
OpenAI의 새 Rust 규칙 집합 rules_rs는 Cargo 메타데이터를 반복해서 조회하는 기존 방식을 피한다. 발표에 따르면 OpenAI에서 의존성 고정 갱신 시간은 약 10분에서 100밀리초로 줄었으며, 일반적인 bazel build 과정에 갱신을 포함할 수 있다. 이는 OpenAI의 관측 결과다.
EngFlow는 supply-chain 규칙 집합으로 패키지 출처와 라이선스 메타데이터를 모아 SPDX·CycloneDX 형식의 SBOM을 만들고 조직별 정책을 검증하는 방안을 소개했다. 다만 완전한 출처 증명을 위해서는 대상 그래프뿐 아니라 액션 그래프와 실행 환경도 살펴야 한다고 설명했다.
발표 전체 일정은 BazelCon 2026 공식 프로그램에서 확인할 수 있다. 발표 영상은 행사 당시 아직 공개되지 않았으며, BazelCon 유튜브 채널에 공개될 예정이라고 안내됐다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요