[빌드 시스템] Bazel 기본 개념 및 안드로이드 AOSP 전환 실패 이유

Bazel 빌드 시스템의 기본 개념, 장단점, 원격 캐시(Remote Cache) 메커니즘을 알아보고, 안드로이드 AOSP의 Bazel 마이그레이션 실패 이유와 Yocto, Buildroot 등 타 시스템과의 차이점을 분석합니다.

1. Bazel 탄생 배경

대규모 소프트웨어 프로젝트를 진행하다 보면 필연적으로 "내 PC에서는 빌드되는데 서버에서는 안 돼요"라는 문제에 직면하게 된다. 구글 내부 빌드 툴인 'Blaze'에서 파생된 오픈소스 빌드 시스템 Bazel(베이젤)은 바로 이 문제를 근본적으로 해결하기 위해 탄생했다.

 

최신 버전을 기준으로 보더라도 Bazel의 존재 이유는 명확하다. 완벽한 재현성(Reproducibility)과 빌드 속도의 극단적인 단축이다. 이번 글에서는 Bazel의 뼈대가 되는 핵심 개념을 살펴보고, 이 강력한 도구가 왜 특정 환경에서는 실패할 수밖에 없는지 아키텍처 관점에서 정리해 보겠다.

 

Bazel Remote Cache

2. Bazel의 핵심 철학: 밀폐성과 점진성

2.1. Hermetic Build (밀폐형 빌드)

Bazel은 빌드가 실행되는 호스트 환경(로컬 PC의 시스템 라이브러리, 환경 변수 등)을 철저히 불신한다. 모든 빌드는 외부와 격리된 샌드박스(Sandbox) 내에서 이루어지며, 빌드에 필요한 컴파일러, 헤더 파일, 의존성 라이브러리를 명시적으로 선언해야만 접근이 허용된다. 이로 인해 누가, 어디서, 언제 빌드하든 바이트 단위까지 동일한 결과물이 보장된다.

2.2. Incremental & Remote Cache (점진적 빌드와 원격 캐시)

Bazel은 소스 파일과 빌드 타겟 간의 의존성을 거대한 방향성 비순환 그래프(DAG)로 관리한다. 소스 코드가 한 줄 변경되면, 전체 트리를 다시 빌드하는 것이 아니라 해당 변경점의 영향을 받는 노드만 정확히 추적하여 재빌드한다.

 

특히 원격 캐시(Remote Cache) 기능은 Bazel의 핵심이다. CI 서버나 동료 엔지니어가 이미 빌드해 놓은 결과물(Action Cache)이 중앙 서버에 있다면, 내 PC에서는 컴파일을 수행하는 대신 캐시된 바이너리를 그대로 다운로드한다. 대규모 모노레포(Monorepo) 환경에서 빌드 시간을 수십 분에서 몇 초 단위로 줄일 수 있는 핵심 메커니즘이다.

2.3. 치명적인 허들: BUILD 파일의 압박

이러한 마법 같은 캐싱과 재현성을 얻기 위한 대가가 있다. 개발자는 프로젝트 내 모든 디렉터리에 BUILD.bazel (또는 BUILD) 파일을 작성하여 타겟, 소스 파일, 의존성을 수동으로 꼼꼼하게 선언해야 한다. Bzlmod 같은 새로운 의존성 관리 시스템이 도입되고 있지만, 여전히 레거시 프로젝트를 Bazel로 전환하는 것은 엄청난 리소스가 소모되는 작업이다.

3. 안드로이드(AOSP)는 왜 Bazel 전환에 실패했을까?

구글은 야심 차게 안드로이드 OS(AOSP)의 빌드 시스템을 전면 Bazel로 교체하려 했으나, 최근 이 프로젝트를 중단했다. 가장 큰 이유는 투자 대비 실익(ROI)의 부족이었다.

• 이미 존재하는 대안: 안드로이드는 이미 Android.bp (Blueprint) 기반의 Soong 빌드 시스템을 통해 선언형 아키텍처와 빠른 Ninja 빌드 파이프라인을 구축해 둔 상태였다.
• 구조적 중복성: Android Blueprint 문법은 사실상 Bazel의 BUILD 문법과 매우 유사하다. 이미 최적화된 시스템을 걷어내고 방대한 플랫폼 코드를 다시 Bazel 규칙으로 재작성하는 것은 비용 낭비에 가까웠다.
• 플랫폼 코드의 파편화: 수천 개의 개별 저장소(repo)와 하드웨어 벤더 종속적인 복잡한 빌드 조건들을 Bazel의 엄격한 밀폐성에 끼워 맞추는 과정에서 심각한 병목이 발생했다.

4. 빌드 시스템 스펙 비교

단일 애플리케이션이나 모노레포를 넘어, 인프라 및 OS 레벨에서 사용되는 타 빌드 시스템들과 Bazel의 포지션을 비교해 보면 각 툴의 목적성이 더욱 뚜렷해진다.

 

빌드 시스템	핵심 지향점 및 특징	주요 사용처
Bazel	멀티 랭귀지 모노레포 최적화, 원격 캐시를 통한 완벽한 재현성. (의존성 관리 난이도 높음)	Eclipse Foundation (Score 등), 대형 IT 기업 백엔드
Yocto Project	커스텀 임베디드 리눅스 배포판(BSP) 생성. 레이어 구조와 bitbake 레시피 기반.	Automotive OS, 산업용 임베디드 디바이스
Buildroot	단일하고 가벼운 임베디드 리눅스 이미지 생성. kconfig 기반으로 학습이 쉬움.	리소스가 극도로 제한된 라우터, 소형 IoT 기기
Soong / Blueprint	AOSP 전용. Bazel과 유사한 선언형 구조(Android.bp)를 파싱해 Ninja 파일로 변환.	안드로이드 오픈소스 프로젝트 (AOSP, AAOS)

5. 마무리

Bazel은 러닝 커브가 높고 초기 세팅 비용이 크다. 하지만 프로젝트 규모가 커지고 빌드 시간이 개발자 생산성을 갉아먹기 시작하는 임계점을 넘어서는 순간, 원격 캐시와 밀폐형 빌드가 가져다주는 장점은 다른 어떤 시스템으로도 대체하기 힘들다. 본인의 프로젝트가 마이크로서비스나 다양한 언어가 얽힌 거대 저장소라면 Bazel 도입은 충분히 검토해 볼 만한 가치가 있다.