# Bazel: 언제 사용해야 할까? (2023)

> Clean Markdown view of GeekNews topic #18232. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=18232](https://news.hada.io/topic?id=18232)
- GeekNews Markdown: [https://news.hada.io/topic/18232.md](https://news.hada.io/topic/18232.md)
- Type: news
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2024-12-13T09:31:01+09:00
- Updated: 2024-12-13T09:31:01+09:00
- Original source: [earthly.dev](https://earthly.dev/blog/bazel-build/)
- Points: 10
- Comments: 3

## Summary

Bazel은 Google이 대규모 모노레포를 효율적으로 빌드하기 위해 개발한 오픈 소스 빌드 시스템으로, 복잡한 프로젝트를 정확하고 빠르게 빌드하며 특히 대규모 코드베이스와 다중 언어 종속성을 다룰 때 효과적입니다. Netflix와 Open Systems와 같은 기업들은 Bazel을 도입하여 빌드 시간을 크게 단축하고 개발 효율성을 높였습니다. 그러나 Bazel은 초기 학습 곡선이 높고 인프라 구축이 필요하며, 소규모 프로젝트에는 적합하지 않을 수 있습니다.

## Topic Body

- Bazel은 Google이 대규모 모노레포를 효율적으로 빌드하기 위해 개발한 오픈 소스 빌드 시스템  
- 복잡한 프로젝트를 정확하고 빠르게 빌드하며, 특히 대규모 코드베이스와 다중 언어 종속성을 다룰 때 효과적  
- Bazel의 핵심 개념  
  - **정확성 기반의 속도**: Bazel은 빌드를 순수 함수로 간주, 동일한 입력이 동일한 출력을 생성하도록 보장  
  - **효율적인 캐싱**: Google의 대규모 환경에서 캐싱은 필수이며, 정확성이 이를 가능하게 함  
  - **청소 없는 빌드**: 소스 변경 후 "clean build" 없이도 안정적 빌드 가능  
- Bazel의 사용 시점  
  - 사용 권장  
    - **대규모 모노레포**: 코드 라인이 수백만에 이르고 여러 언어를 사용하는 경우  
    - **다양한 언어의 종속성 관리**: 예를 들어 Python으로 모델 학습, Scala로 데이터 처리 등  
    - **빠르고 정확한 CI/CD 요구**: 개발 속도를 높이고 충돌 방지  
  - 사용 비추천  
    - **소규모 프로젝트**: 코드 라인이 10만 이하이고, 단일 언어를 사용하는 경우  
    - **오픈 소스 라이브러리**: Bazel은 배포 가능한 아티팩트 생성에는 적합하지만, 재사용 가능한 라이브러리 배포에는 미흡  
- Bazel 도입 시 고려 사항  
  - 초기 학습 곡선이 높고, 빌드 파일 작성 및 유지보수에 추가 리소스 필요  
  - 캐시 서버 및 원격 실행 설정 등의 인프라 구축이 필수  
- 성공적인 Bazel 사례  
  - Netflix  
    - **문제점**: 25만-30만 라인의 코드가 포함된 레포에서 CI 시간이 45분-1시간 소요  
    - **해결책**: Bazel 도입 후 빌드 시간이 20분에서 6분으로 감소  
    - **효과**: 병합 충돌 감소, PR 처리 속도 개선  
  - Open Systems  
    - **문제점**: 느린 빌드 시간과 비효율적인 작업 흐름  
    - **해결책**: Bazel로 전환 후 피드백 루프를 20분에서 5분으로 단축  
    - **교훈**: 개발자 교육과 소통이 중요  
- Bazel 도입의 장단점  
  - 장점  
    - **빠른 빌드 시간**: 캐싱 및 증분 빌드로 속도 개선  
    - **정확성과 재현성**: 복잡한 종속성 그래프를 정확히 표현  
    - **다중 언어 통합**: Haskell, TypeScript, Python 등 다양한 언어 지원  
  - 단점  
    - **높은 도입 비용**: 초기 설정 및 학습 곡선이 가파름  
    - **빌드 파일 관리 필요**: 입력/출력 명시가 필수적이며, 자동화 도구 활용 필요  
    - **JavaScript 및 프론트엔드 툴링**: 핫 리로딩 등 기존 워크플로와 호환 어려움  
- Bazel 마이그레이션 팁  
  - **핵심 팀 구성**: Bazel을 이해하고 설정할 수 있는 전문가 확보  
  - **교육 및 소통**: 도입 초기, 개발자 교육과 기대치 설정 필수  
  - **언어별 복잡성**: 각 언어마다 다른 빌드 설정 요구  
  - **빌드 파일 자동화**: [Gazelle](https://github.com/bazelbuild/bazel-gazelle) 같은 도구 활용  
- 결론  
  - Bazel은 대규모 모노레포와 복잡한 종속성을 처리하는 데 탁월하지만, 도입 비용이 높음  
  - 수백만 라인의 코드와 다중 언어를 다루는 조직에 적합  
  - 소규모 프로젝트나 점진적 전환을 원하는 경우, Bazel 대신 [Earthly](https://earthly.dev/) 같은 대안 검토

## Comments



### Comment 32313

- Author: ganadist
- Created: 2024-12-13T12:11:59+09:00
- Points: 1

Bazel 도입 실패사례도 언급이 되면 좋을 것 같군요.  
  
AOSP의 경우 최근 몇년동안 BazelCon 에서 기존의 빌드시스템(Soong)에서 Bazel로 마이그레이션하는 부분에 대해 몇가지 발표를 하였습니다.  
  
https://developers.googleblog.com/en/welcome-android-open-source-project-aosp-to-the-bazel-ecosystem/  
  
하지만 [올해 Bazelcon](https://events.linuxfoundation.org/bazelcon/program/schedule/) 에서는 AOSP관련 내용 공유가 빠져있고, 최근 AOSP의 빌드관련 문서에서는 [Bazel 이전이 중단되었다는 안내](https://source.android.com/docs/setup/build/make-to-soong?hl=en)가 나왔습니다.  
  
Bazel 마이그레이션 관련해서 AOSP팀이라면 많은 도움을 받을 수 있을텐데, 도입을 포기했다는 것에 대해 많은 시사점을 보여주는 것 같습니다.

### Comment 32308

- Author: iolothebard
- Created: 2024-12-13T10:50:21+09:00
- Points: 1

아마… 당신의 소프트웨어는 Bazel이 필요없을겁니다.

### Comment 32306

- Author: kandk
- Created: 2024-12-13T10:45:41+09:00
- Points: 1

ㅋㅋ Earthly에서 Earthly광고를 하는군요.  
bazel은 빠른 빌드와 빠른 "테스트"에 방점이 있습니다. 테스트이야기가 많지 않네요.