원 글: https://earthly.dev/blog/bazel-build/
번역기로 기계번역한 후 다듬은 글입니다.
Earthly에서는 빌드에 대해 많은 관심을 가지고 있으며 많은 사람들과 빌드 및 CI에 대한 어려움을 이야기합니다. 특히 모노레포와 500명 이상의 개발자가 있는 조직에서 자주 논의되는 주제는 Google의 오픈 소스 모노레포 빌드 시스템인 Bazel입니다.
저는 Google이나 다른 곳에서 Bazel을 사용하여 빌드를 진행한 적이 없기 때문에, Bazel 튜토리얼을 살펴볼 수는 있지만 일상적으로 사용하는 것과 Bazel로 마이그레이션하는 것이 어떤 것인지에 대한 감각이 부족하다고 느꼈습니다. 그래서 6명의 Bazel 전문가를 인터뷰하여 Bazel의 어떤 점이 마음에 드는지, 언제 사용하는지, Bazel 마이그레이션을 하기 전에 무엇을 기대하거나 고려해야 하는지 물어보았습니다.
Bazel 마이그레이션을 고려 중이신 분들, 그리고 여러 Bazel 마이그레이션의 노력 수준과 결과를 포함한 자세한 내용을 읽고 싶으신 분들은 이 글을 읽어보세요.
이 글에 참여한 전문가들은 모두 Bazel로 마이그레이션하여 일상적으로 사용하고 있는 경험이 있습니다. Bazel 마이그레이션을 생업으로 하는 두 사람, 최소 한 명의 Bazel 기여자, 그리고 트위터, Stripe, Netflix에서 Bazel 프로젝트에 참여했던 한 사람인 오스카 보이킨을 포함합니다.
긴 글이지만 그만한 가치가 있습니다. 간단히 요약하자면, Bazel은 대규모 모노레포 빌드 문제를 매우 잘 해결할 수 있지만 채택 곡선이 가파르다는 것입니다.
Bazel은 간단하지만 강력한 아이디어를 기반으로 합니다. 오스카 보이킨이 설명합니다:
오스카 보이킨
Bazel의 아이디어는 실제로 사물을 올바르게 빌드한다는 것입니다. 빌드는 순수한 함수입니다. 소스가 들어오고 아티팩트가 나갑니다. 소스가 동일하면 다른 쪽에서 나오는 아티팩트도 비트 단위로 동일합니다. 정말 멋지네요.
그래서 Bazel의 핵심은 정확함으로써 속도를 높일 수 있다는 것입니다. 구글 규모에서는 캐싱을 하지 않을 수 없습니다. 그리고 캐싱이 안전한 유일한 방법은 캐싱이 정확할 때입니다. 그래서 '정확성을 통한 속도 향상'이라는 아이디어가 나온 것입니다. 많은 사람들은 이 둘이 서로 긴장 관계에 있다고 보았습니다.
모든 프로그래머는 '아 빌드가 망가졌어! 그냥 청소하자.'라고 생각한 경험이 있을 겁니다. 빌드를 재부팅하는 것과 마찬가지죠. 끔찍하죠. 왜 빌드를 재부팅해야 하나요?
Bazel을 사용하면 그럴 필요가 없습니다. 청소할 필요 없이 빌드할 수 있습니다. 정말 놀랍네요. 말하는 바가 그 정도까지인 것은 안타깝지만, 이는 현실입니다. Bazel은 이를 정말로 실현하고 있습니다.
Google 초창기에는 거대한 Makefile을 대체하기 위해 Bazel을 설계했습니다.
오래 전, Google은 대규모로 생성된 Makefile을 사용하여 소프트웨어를 구축했습니다. 이로 인해 빌드 속도가 느리고 불안정해져 개발자의 생산성과 회사의 민첩성에 지장을 초래하기 시작했습니다. Bazel은 이러한 문제를 해결할 수 있는 방법이었습니다.
당시 Google은 대량의 C++ 및 Java 코드가 포함된 대규모 모노레포를 보유하고 있었고, 이 모든 코드를 빌드하고 테스트할 수 있는 균일하고 정확하며 성능이 우수한 방법을 원했기 때문에 Bazel이 필요했습니다. Qarik Group의 확장형 빌드 컨설턴트인 손 루옹 응옥은 많은 대기업이 이러한 문제에 직면하기 시작했다고 말합니다.
손 루옹 응옥
백엔드가 Go나 Java로 되어 있을 수 있죠? 프론트엔드는 리액트 JS로 되어 있죠. 그리고 데이터 사이언티스트들은 파이썬과 스칼라를 사용하고 있죠? 그리고 여기 인프라 담당자들은 Go, Rust, C, C++, Lua를 사용하고 있죠? 어떻게 이 모든 것을 하나로 묶어 일관된 개발자 환경을 만들 수 있을까요? 최근 몇 년 동안 많은 기업이 이 규모에 도달하기 시작했습니다.
이전에는 대부분 Google과 Facebook을 제외하고는 아무도 이 정도 규모에 도달하지 못했습니다. 이들은 다른 시장보다 8~10년 정도 앞서 있었습니다. 그래서 그들은 실제로 이런 종류의 문제에 관심을 가졌습니다. 하지만 이제는 다른 모두가 따라잡고 있습니다.
사람들이 구글을 떠나 대규모 모노레포가 있는 곳에서 일하게 되면서 결국 Bazel의 포트를 작성하게 되었습니다. Pants는 트위터와 포스퀘어에서 사용된 Bazel의 클론이었습니다. 벅(Buck)은 Facebook에서 만든 Bazel 클론입니다. 모노레포가 없거나 사용 언어가 많지 않은 알리바바나 넷플릭스 같은 곳에서는 각기 다른 방식으로 문제를 해결하는 자체 솔루션을 구축했습니다.
손 루옹 응옥
네, 실제로 사람들이 자체 솔루션을 구축했지만 비용이 매우 많이 들었습니다. 여러분처럼 이런 종류의 플랫폼을 구축하려면 소규모 스타트업 규모의 팀이 필요합니다. 그럴 돈이나 시간이 있는 사람은 아무도 없죠? 비즈니스 목표에 집중하고 싶을 뿐입니다.
그러던 중 Bazel은 오픈소스로 공개되었습니다. 그때 손 루옹 응옥은 이 아이디어가 확산되는 것을 목격했습니다:
손 루옹 응옥
Dropbox는 Bazel을 가장 먼저 채택한 기업 중 하나가 되었고, 그다음에는 BMW도 채택했습니다. 그리고 천천히, 천천히 생태계가 Bazel을 중심으로 수렴하기 시작했습니다.
대기업들이 Bazel을 채택하도록 이끄는 것은 다양한 언어 변경뿐만이 아닙니다. 이는 많은 서비스가 포함된 모노레포 때문이기도 합니다. 손 루옹 응옥은 Booking.com에서 모노레포 중 하나에서 이를 겪었습니다:
손 루옹 응옥
모든 푸시가 모노레포의 메인 브랜치인 트렁크로 직접 연결되는 것으로 시작했는데, 각각 약 120개의 CI 작업이 생성되었고, 저는 이 120개의 작업을 모두 가져와 동적 CI 파이프라인을 사용하여 합리적인 작업을 만들라는 지시를 받은 사람이었습니다.
그리고 저는 GitLab 러너와 아티팩토리를 위한 설정도 관리했습니다. 개발자가 너무 빨리 커밋하여 CI 시스템이 DDoS를 받거나, 테스트를 위해 수백 개의 컨테이너를 생성하고 코드를 가져오는 것만으로도 GitLab 스토리지 레이어가 다운되어 CI 시스템이 GitLab 인스턴스에 DDoS를 가할 때를 위해 제가 대기했습니다. 어떻게 확장할 수 있을까요?
결국 저희는 이렇게 생각했습니다: 프로덕션의 종속성 정보를 CI에 캡처하는 것은 올바른 방법이 아닐 수도 있겠다는 생각이 들었습니다. 이 모노레포의 코드 베이스 내에서 선언적으로 종속성을 처리해야 할지도 모른다는 생각이 들었고, Bazel이 딱 맞는 솔루션이 되었습니다.
Oscar는 트위터, Stripe, Netflix에서 Bazel 프로젝트에 참여해 온 Bazel 기여자입니다. 그는 흥미로운 방식으로 Bazel에 참여하게 되었습니다:
오스카 보이킨
2011년에 트위터에 입사했습니다. 그리고 Pants가 성장하는 모습을 지켜봤죠. 그러던 중 2015년에 Bazel이 오픈소스로 공개되었습니다. 그래서 저희는 Bazel을 도입해야 할까라는 질문을 던졌습니다.
저는 Pants 쪽에 그다지 귀속되지 않았기 때문에 Bazel을 조사하는 팀의 일원이 된 셈이었죠.
그때 Bazel에 깊은 인상을 받았어요. 디자인이 정말 훌륭하고 모든 원칙이 정말 훌륭하다고 생각했어요. 그래서 실제로 첫 번째 스칼라 규칙을 작성했습니다. 그리고 그 규칙이 rules_scala라는 것이 되었고, 거의 모든 사람들이 스칼라에서 Bazel을 사용할 때 이 규칙을 사용하고 있다고 생각합니다.
저는 2016년 초에 Stripe에 입사했고, Netflix에서도 이 규칙을 프로덕션에 사용했기 때문에 Bazel에 대한 많은 경험을 가지고 있습니다.
Bazel은 매우 특정한 도구입니다. 오스카는 꼭 필요하지 않다면 이를 도입하는 것은 실수라고 생각합니다.
오스카 보이킨
Bazel을 추천하겠습니까? 추천하지 않겠습니다. 반지의 제왕에서 산 아래로 가야 하느냐고 묻는 장면에서 간달프가 "다른 기회가 없는게 아니라면 그 길을 택하지 않겠다"고 말하는 장면 아시죠?
기본적으로 Bazel은 꼭 필요한 경우가 아니면 사용하지 말라는 것입니다.
따라서 한 가지 언어로만 작업하고 코드의 양이 비교적 적은 경우, 예를 들어 10만 줄 미만인 경우, 저라면 거의 확실하게 Bazel을 사용하지 않을 것입니다. 오픈 소스 라이브러리 작업을 하는 경우라면 Bazel은 다른 사람을 위해 재사용 가능한 라이브러리를 게시하는 데 그다지 좋지 않기 때문에 거의 사용하지 않을 것입니다. 배포 가능한 아티팩트는 꽤 쉽게 게시할 수 있지만, 재사용 가능한 라이브러리를 게시하는 데는 현재로서는 좋지 않으며 앞으로도 좋지 않을 것입니다.
언제 꼭 사용하게 될까요?
유감스럽게도 코드가 백만 줄 이상일 때 확실히 사용할 것입니다. 여러 언어 간에 종속성이 있는 경우, 예를 들어 넷플릭스의 경우 많은 머신러닝을 수행하지만 스칼라로 데이터 처리를 하고, 그런 다음 몇 가지 앱을 패키지화하여 모델 스코어링이나 모델 훈련에 파이썬을 사용하는 경우처럼 – 이러한 시스템 간에 데이터가 전송되기 때문에 종속성이 발생할 수 있습니다. 그럴 때 Bazel을 고려해 볼 만합니다. 각각은 아마도 Bazel을 사용할만한 상황이겠죠? 그리고 이러한 상황이 충분하게 누적되면 Bazel을 시도해 보세요. 코드가 5백만 줄 이상이 되면, 정말로 Bazel 이외의 것을 사용하지 않을 것 같습니다. 그 정도면 Bazel이 거의 유일한 선택지가 되어버립니다.
하지만 모든 사람이 수백만 줄을 기다렸다가 Bazel을 사용하진 않을 것입니다. Google의 TensorFlow 팀에서 ML 컴파일러 엔지니어로 일하고 있는 Jason Steving은 다른 견해를 가지고 있습니다:
제이슨 스티빙
항상. 항상 Bazel을 사용하세요.
그래서 저는 모노레포를 구축하는 것만이 코드 재사용에 이점이 있다고 생각하는 매우 편향된 의견을 가지고 있습니다. 반면 대안은 작업하기 어렵습니다.
제가 다른 빌드 시스템을 그다지 많이 사용해 보지 않았기 때문에 좋은 반대의견을 드리기 어렵습니다. 1년 전에 구글을 그만두고 아마존에서 8개월 정도 일했는데, 거기서 빌드 시스템을 사용했었습니다. 그 후 다시 구글로 돌아온 이유는 솔직히 제가 가장 싫어했던 부분 중 하나가 빌드 시스템이었기 때문입니다.
Amazon, 적어도 프라임 비디오는 코드를 재사용하지 않습니다. 아무리 사소한 코드라도 모두 똑같은 것을 다시 작성합니다. 정말 나쁜 관행입니다. 예를 들어, 로그인 사용자 지정과 같은 아주 간단한 작업의 경우 모든 사람이 이 작업을 수행해야 하는데 모두가 해당 코드를 작성합니다. 말 그대로 복사해서 붙여넣기하죠. 그건 제 영혼을 거스르는 일이에요!
파일 복사를 중심으로 구축된 빌드 시스템을 사용하고 있었기 때문에 이런 일이 발생했습니다. 그리고 파일이 어디에 있는지 알려줘야 했죠. 그래서 결국 모든 파일을 복사하기 때문에 빌드 파일을 복제해야 했고, 코드를 생성하기 위해 어떤 작업을 수행하든 코드를 생성하기 위해 여러분의 빌드 파일에서도 수행해야 했습니다. 반면 Bazel에서는 코드를 생성할 때 타깃이 정해져 있습니다. 타깃에 의존하기만 하면 생성된 코드를 얻을 수 있습니다.
따라서 제 경험상 프로젝트가 파일 몇 개를 넘어서서 중요해지면 이미 Bazel을 사용할 준비가 되었다고 생각합니다. 예를 들어 Java 패키지처럼 코드 패키지가 두 개 이상 있다면, 특히 코드 생성을 한다면 Bazel을 사용할 준비가 된 것입니다.
제이슨의 의견은 구글 내에서 드물지 않다고 생각합니다. Blaze와 마찬가지로 Bazel은 Google 코드 베이스의 문제를 해결하기 위해 만들어졌기 때문에 그곳에서 잘 작동하는 것은 놀라운 일이 아니며, 많은 시간을 사용해 본 사람들이 이를 사용하는 모든 사람을 위해 강력한 사례를 제시합니다.
하지만 다른 곳에서는 Bazel 없이도 잘 작동하는 것 같다고 손은 말합니다:
손 루옹 응옥
저는 지난 몇 년 동안 여러 조직을 거쳐 왔습니다. 알리바바는 멀티 리포지토리로 운영되는 회사로, 멀티 리포지토리 설정으로도 성공할 수 있습니다. 그들은 Maven과 Spring Java를 사용하여 완전히 살아남았기 때문에 Bazel과 같은 것이 필요하지 않습니다.
따라서 Bazel이 성공의 열쇠가 아니라는 것은 매우 분명합니다.
하나의 언어나 하나의 소프트웨어 스택만 사용하는 스타트업이 있는데, 이는 매우 쉽게 구축할 수 있습니다. 비용과 투자 수익률 간의 절충점을 찾아야 하며, 조직은 그 결정을 내려야 합니다. 저는 규모의 문제를 해결하는 데 있어 다양한 고객들이 서로 다른 해답에 도달하는 것을 보았습니다.
Netflix는 Java 코드가 주를 이루는 멀티 리포지토리 회사입니다. 하지만 오스카가 말했듯이, 멀티 리포지토리 조직에서도 특정 코드 베이스가 상당히 커지기 시작하면 빌드 속도가 느려질 수 있습니다.
오스카 보이킨
저는 Netflix에서 일하고 있는데, Netflix는 대부분 멀티 리포지토리 스타일을 사용합니다. 자유와 책임이 보장되는 문화로 매우 유명하죠. 그래서 각 팀이 원하는 것을 거의 다 할 수 있습니다.
저는 추천 알고리즘을 담당하고 있는데, 최근에 제가 속한 팀에서는 전체 추천 제품의 일부인 여러 가지 알고리즘을 하나의 팀과 하나의 리포지토리에 통합했습니다. 넷플릭스 전체는 아니지만, 서로 관련이 없는 여러 프로젝트가 하나의 리포지토리에 모여서 빌드 성능이 상당히 나빴기 때문에 일종의 모노레포 같은 느낌이 들었습니다.
그래서 이전에 Bazel을 사용해 본 적이 있는데, 이걸 망치고 싶지 않다는 생각이 들었습니다. 그냥 계속 일하고, 계속 사용하고, 관여하지 않고, 다시는 이런 일에 휘말리지 않겠다고요.
하지만 CI 시간이 너무 길었어요. 이 리포지토리에 25만 줄, 30만 줄의 코드가 있었어요. 엄청난 양의 코드는 아닙니다. 그리고 CI 시간이 어떤 경우에는 45분, 어떤 경우에는 1시간이 걸리기도 해서 생산성에 큰 영향을 미쳤습니다.
그래서 우리는 이러한 문제에 직면하게 되었습니다. 소규모 조직이나 소규모 리포지토리에서 일하는 많은 사람들은 생각하지 않는 것이죠.
오스카의 팀이 겪고 있던 문제는 충돌하는 코드가 병합되는 것이었습니다.
오스카 보이킨
당신의 PR도 초록색이고 제 PR도 초록색일 수 있습니다. 하지만 둘을 병합하면 빌드가 깨지겠죠? 왜냐하면 실제로 충돌하기 때문입니다. 그리고 누군가가 PR을 양립할 수 없는 방식으로 변경하는 일이 점점 더 빈번하게 발생했습니다. 한 CI는 녹색이고 다른 하나는 녹색입니다. 이제 45분이 됐습니다. 그것들을 가지고 장난치고 싶지 않아서 계속해서 병합해버립니다. 병합 후 배포하기 전에 메인 브랜치에서도 CI를 실행하기 때문에 나중에 장애를 감지할 수 있지만, 여전히 성가신 일이죠. 메인 브랜치는 들어가기 전에 이미 테스트를 거쳤어야 하므로 절대 고장 나서는 안 됩니다.
하지만 이 문제에 대한 해결책이 있습니다.
오스카 보이킨
그거 아세요? 메인으로 빨리 감기 병합(Fast-forward merge)만 허용하겠습니다. 이제 45분 또는 1시간의 CI 시간은 사실상 작업이 불가능한 상태가 되었습니다. 왜냐면 이것들은 선형화해야 하고 다른 누군가가 당신보다 먼저 병합하면 당신은 다시 병합해야 합니다. 이제 또 다른 1시간이 걸리게 되는 거죠.
그래서 저는 이렇게 생각했죠. Bazel을 써야겠어요. Bazel은 피치에 정말 잘 맞거든요. 빌드를 설정하고 좋은 규칙이 있고 캐싱이 작동한다면 잘 작동할 것입니다.
이전에는 45분이나 1시간이라고 하면 90번째 백분위수 정도였을 겁니다. 빌드 시간 중앙값이 20분에서 6분으로 줄었거나 그보다 조금 더 짧아졌을 수도 있습니다.
이제 코드를 푸시하고 PR을 작성하고 있는데 CI가 이미 녹색 또는 빨간색으로 표시되어 있습니다. 블록을 느끼지 못하며 PR의 선형화가 전혀 문제가 되지 않습니다. 아무도 눈치채지 못하고 신경 쓰지 않습니다. 그리고 저희도 멋지게 만들고 싶어서 작은 (선형화) 봇을 만들었습니다. 그리고 사람들은 더 이상 그것에 대해 생각하지도 않습니다. 그래서 메인 선형화는 더 이상 문제가 되지 않습니다.
평균 빌드 시간이 20분에서 6분으로 단축된 것은 인상적인 개선 사항으로 보이며, 특히 테일 빌드 시간도 비슷한 수준으로 개선된 것을 보면 더욱 그렇습니다. 빌드 마이그레이션 전문가인 Tweag의 안드레아스 헤르만에게 이러한 유형의 개선이 기대할 수 있는 수준인지 문의해 보았습니다.
안드레아스 헤르만
이러한 종류의 수치의 문제점은 특정 프로젝트에 따라 크게 달라진다는 것입니다. 따라서 일반적인 주장을 하기가 매우 어렵습니다. 예를 들어, 제가 참여했던 한 프로젝트에서는 Bazel로 전환하면서 빌드 시간을 40% 단축했습니다. 이는 일반적인 증분 빌드 주기에 따른 것이었습니다. 이전 빌드에서는 네이티브 툴을 사용했습니다. 그것 또한 증분 빌드를 수행하고 있었지만 그럼에도 불구하고 개선이 이루어졌습니다.
그 프로젝트는 얼마나 많은 컴포넌트를 추가하느냐에 따라 처음부터 빌드하는 데 1시간에서 2시간 정도 걸렸습니다. 하지만 일반적인 개발자의 빌드 사용 사례는 4분 미만이었습니다.
따라서 Bazel로 마이그레이션한 후에도 빌드는 여전히 1~2시간이 걸리지만 모든 캐싱 및 증분 기능을 사용하면 실제로는 원래의 증분 빌드인 4분보다 40% 단축됩니다.
따라서 4분의 증분 빌드 시간을 40% 단축할 수 있었습니다! 하지만 안드레아스는 일부 프로젝트는 통합 테스트 속도에 제한이 있기 때문에 Bazel이 속도를 높이는 데는 한계가 있다는 사실을 발견했습니다:
안드레아스 헤르만
이상적으로는 빌드 시간이 몇 분 이내가 되어야 합니다. 하지만 실제로는, 특히 장기간에 걸친 통합 테스트와 같은 작업이 있는 경우에는 Bazel로도 이를 달성하기 어려울 수 있습니다. 과거에 경험한 바에 따르면 Bazel을 사용하면 빌드가 매우 빠르게 만들어지지만 여전히 대규모 통합 테스트가 필요했고, 팀에서는 여전히 병합 전 검사를 선호하는 경우가 있었습니다. 그리고 한 번의 통합에 30분이 걸린다면 빌드 시스템으로 개선할 수 있는 부분이 거의 없습니다.
통합 테스트로 인해 빌드 시간이 제한되더라도 다른 이점이 있을 수 있습니다. 예를 들어, 안드레아스는 증분 컴파일에 대한 Bazel 이외의 솔루션에 문제가 있는 경우가 많다는 사실을 발견했습니다.
안드레아스 헤르만
일반적으로 이전에는 증분 빌드에 대해 몇 가지 해결 방법을 찾았습니다. 영구 빌드 워커를 사용하거나 하는 식으로요. 하지만 다른 종류의 비용이 발생하죠. 예를 들어 빌드가 덜 안정적이거나 가끔 나쁜 상태가 될 수 있습니다.
Bazel을 올바르게 사용하면 이러한 문제가 발생하지 않습니다. 빌드가 더 정확하기 때문에 빌드가 더 빠르게 실행됩니다. 안드레아스도 오스카와 마찬가지로 정확성이라는 속성을 중요하게 생각합니다.
안드레아스 헤르만
Tweag는 강력하게 유형화된 함수형 프로그래밍을 전문으로 합니다. 따라서 정확성과 재현성, 순수성은 우리에게 중요합니다. 2015년에 Google이 Bazel을 오픈소스화했을 때 저희는 완전히 정의된 빌드 종속성에 초점을 맞추고 있다는 점에서 큰 관심을 가졌습니다. 우리가 추구하는 가치와 잘 맞았기 때문입니다.
정확성은 단순히 속도만이 아닙니다. 안드레아스는 여러 언어로 코드를 생성하는 경우 정확성이 특히 중요해질 수 있다고 말합니다:
안드레아스 헤르만
Haskell 백엔드가 있는 간단한 웹 앱이 있고 API를 설명하는 데 servant를 사용한다고 가정해 봅시다. 그러면 모든 API 정의가 Haskell 코드로 되어 있습니다.
이상적으로는 프론트엔드에 대한 모든 API 정의를 복제하고 싶지 않을 것입니다. 이를 생성할 수 있는 도구가 필요합니다. 그리고 많은 브리지 패키지가 있습니다. 하지만 네이티브 빌드 도구로는 이를 수행할 수 있는 좋은 방법이 없기 때문에 '새로 만들기'를 실행하고 새로 빌드를 수행해야 하는 경우가 많습니다. Bazel은 이러한 문제를 해결하는 데 매우 적합합니다. API를 정의하는 라이브러리에 대한 Bazel 대상을 정의하고, 코드 생성을 수행하는 바이너리에 대한 Bazel 대상을 정의하면 생성된 소스는 빌드 아티팩트가 될 뿐입니다.
그런 다음 생성된 파일을 일반 코드 소스 입력으로 사용하는 프론트엔드용 라이브러리 타깃을 정의하면 자동으로 작동합니다. 따라서 이러한 종류의 복잡한 종속성 그래프는 네이티브 도구에서는 매우 어렵지만 Bazel에서는 매우 쉽게 표현할 수 있습니다.
Andreas와 Tweag의 다른 직원들은 Bazel(그리고 Nix도 마찬가지지만 다른 기사로 다룰 수 있습니다)의 열렬한 팬이었기 때문에 이를 널리 알리기 위해 글을 쓰기 시작했습니다. 그 후 다른 사람들도 Bazel을 알게 되었습니다. 당시 오픈 시스템즈에서 일하던 줄리앙 페로셰도 마찬가지였습니다.
줄리앙 페로셰
아마 2018년이나 2019년쯤에 처음 들었던 것 같아요.
학습 곡선은 꽤나 하드코어했습니다. 그래서 저희는 이 아이디어를 한동안 보류했습니다. 그러던 중 저희 회사가 기존 Java 업체(오픈 시스템즈)를 인수합병했습니다. 그 회사는 25년 정도 존재했고 빌드 시간이 느렸습니다. 그래서 Bazel에 대한 모든 연구가 시작되었습니다. 그래서 저희는 Bazel을 재평가해보자고 결정했습니다.
Julien과 소규모 팀은 Bazel에 대한 사례를 만들고 회사로부터 동의를 얻었습니다. 문제는 개발자들을 설득하는 것이었습니다:
줄리앙 페로셰
변화에 대한 자연스러운 저항이 있습니다. 사람들은 워크플로에 익숙해져 있기 때문에 관성이 있습니다. 그리고 여러분은 더 작은 빌드, 더 작은 타겟과 같은 완전히 엉뚱한 아이디어를 가지고 오는 것과 같습니다. 설득이 필요하죠.
이 일을 다시 해야 한다면 개발자와 소통하는 데 더 많은 시간을 할애할 것입니다. 사람들을 교육하고, 누가 동기가 있고 누가 관심이 있는지 파악한 다음, 이 사람들을 참여시키는 데 더 많은 시간을 할애할 것입니다.
Open System에서 전환에 대해 우왕좌왕하는 데 많은 시간이 걸렸기 때문에, Julien은 Bazel로 전환하는 것에 대해 확고한 약속을 받으라고 조언합니다.
줄리앙 페로셰
"작동하는 것을 보여줘야 약속할 수 있어"라고 주고받는 상황이 저희에게 반복되었습니다.
그러다가 저흰 어느 순간에 "좋아, 집어 치워. 다 강행하겠어. 이 모든 것을 마이그레이션할 거야."라고 말했습니다. 휴일 동안 그다지 우아하지 않은 방식으로 이 작업을 수행했습니다.
전환 후 약간의 적응 시간이 지나자 개발자들은 피드백 시간이 단축된 Bazel의 이점을 인정하기 시작했습니다:
줄리앙 페로셰
테스트가 통과할지 여부 등 무언가를 시도하기 전에 최소 20분 이상, 일반적으로는 그 이상의 피드백 루프가 있습니다.
코드 기반이 꽤 방대하군요. 이제 그냥 무언가를 시도해 보기만 하면 됩니다. 그러면 금방 빌드를 망가뜨리고 있는지 알 수 있습니다. 코드를 작성하고 나면 5분도 채 되지 않아 '이게 모든 것을 망가뜨리는 건가, 아니면 실제로 작동할 가능성이 있는가'에 대한 답을 얻을 수 있습니다.
그게 최고였어요. 실행하기는 매우 어렵지만, 일단 사람들에게 이 기능을 제공하고 나면 그들은 빠르게 다시 반복할 수 있는 기본적인 제어력을 갖게 됩니다. 갑자기 그들은 BUILD 파일을 작성하는 법을 배우는 것을 기뻐합니다. 그래서 2년 동안의 모험이었습니다.
Julien은 최근 2년간 대규모 조직의 마이그레이션을 완료한 경험이 있기 때문에 Bazel로의 마이그레이션과 예상되는 사항에 대해 많은 유용한 팁을 공유합니다.
줄리앙 페로셰
Bazel을 이해할 수 있는 핵심 인력이 필요합니다. 많을 필요는 없지만 한 명보다는 많아야 합니다. 그렇지 않으면 시간 낭비일 수 있습니다.
스스로 생각할 수 있는 사람이 필요합니다. 스택오버플로에서 빌드 엔지니어링을 복사해서 붙여넣는 데 익숙한 사람들이 있다면 최적이 아닐 수 있습니다.
따라서 PM과 마찬가지로 기꺼이 시간을 할애할 수 있는 사람이 몇 명 있어야 합니다. 경영진도 마찬가지입니다. "왜 이런 시간이 필요한지 이해한다"고 말하는 관리자가 있어야 합니다.
Julien은 또한 사용 중인 언어의 수가 프로젝트 일정에 큰 영향을 미친다고 말합니다.
줄리앙 페로셰
일부 Java를 마이그레이션했습니다. Scala를 위해 마이그레이션했습니다. Go도 일부 마이그레이션했고, 타입스크립트와 파이썬도 일부 마이그레이션했습니다. 그리고 매번 함정 중 하나는 'Go로 해냈고 오랜 시간을 썼으니 Bazel Java는 쉬울 거야'라고 생각하는 것입니다.
Bazel의 잘못은 아니지만, 자바 컴파일러나 타입스크립트 컴파일러 등 다른 빌드 시스템을 실행하기 위한 프리미티브를 제공하는데, 빌드 도구마다 조금씩 다르기 때문에 이런 것들을 추상화하지 못한다는 점이 문제입니다.
한 언어에서 다른 언어로의 이식성은 주어진 것이 아닙니다. 매번 새로운 것이죠. 매번 새로운 작업을 할 때마다 '그래, 일주일 정도 걸리겠지'라고 생각했는데 한 달이 지나면 완료되곤 했죠. 실제로 조사하고 배워야 할 것이 엄청나게 많습니다.
그래서 장점은 빌드 시스템을 훨씬 더 깊이 이해하게 되고, 결국 모든 시스템을 똑같이 싫어하게 된다는 것입니다.
긍정적인 면을 보면 Julien은 Bazel을 통해 특정 문제를 해결하는 방식이 바뀌었다는 것을 알게 되었습니다. 그는 더 이상 엉망으로 만드는 것을 두려워하지 않습니다.
줄리앙 페로셰
다른 곳에서는 찾아볼 수 없는 매우 자연스러운 기능들이 Bazel에 있습니다. 예를 들어 더티 배시 스크립트로 작업을 수행하다가 실행하는 것을 잊어버리면 문제가 되지만, Bazel은 훌륭한 추상화 계층을 제공합니다: 여기에 도구를 넣고 무엇이 들어가고 무엇이 나가는지 정의하기만 하면 이러한 것들을 쌓아 올리거나 무한대로 조합할 수 있습니다.
Bazel 이전에는 타입스크립트가 뱉어내는 오픈 API 정의 언어처럼 매우 더럽다고 생각했던 것들입니다. Makefile로 이 작업을 수행하면 정말 부서지기 시작합니다. Bazel을 사용하면 정말 지저분한 덕트 테이핑을 함께 할 수 있고, 일단 작동하면 꽤 좋은 Bazel 보증을 받을 수 있습니다.
세 가지 도구와 세 가지 언어를 함께 덕트 테이프로 붙이면 잘 작동한다는 점이 Bazel의 이상한 부작용이었습니다.
Open System에서 근무하는 Julien의 Bazel 도입 경험은 Netflix에서 근무하는 Oscar의 경우와 마찬가지로 Bazel 원칙을 이해하고 이를 도입하기로 결정한 데 그 뿌리를 두고 있습니다. Bazel을 도입하는 또 다른 일반적인 방법은 이전 Google 출신이 회사에 합류하여 Google의 내부 개발 도구를 재창조하는 것입니다.
핀테크 스타트업인 Tink에서 근무하던 옌스 란틸은 이런 방식으로 Bazel을 도입했습니다:
Jens Rantil
재미있는 이야기는 우리 팀에 구글러 혹은 구글러였던 사람이 6개월 정도 잠깐 합류해서 여러 가지 구글러 도구를 추가했다는 것입니다. 그는 Kubernetes를 추가하고 Prometheus를 도입하고 Bazel을 도입한 후 사라졌습니다.
Tink에 도움이 된 Bazel의 큰 기능은 아직 언급되지 않았습니다:
Jens Rantil
정말 놀라운 기능 중 하나는 빌드 대상을 쿼리할 수 있는 뛰어난 쿼리 기능이 있다는 점입니다. 이 특정 라이브러리에 의존하는 모든 Java 바이너리를 여기 저장소에 제공해야 할 때 더 큰 저장소에 대한 쿼리를 할 수 있습니다. 갑자기 일부 종속성에 대한 보안 업그레이드를 수행해야 할 때나 어떤 영향이 있는지 파악하고 싶을 때, 또는 리팩터링 방법을 이해하고 싶을 때 많은 도움이 되었습니다.
또한 CI 파이프라인에서 서비스를 다시 배포해야 하는지 여부를 실제로 확인하기 위해 Bazel 쿼리 로직을 사용했습니다.
Open Systems의 Julien은 Java 사용자들에게도 몇 가지 어려움을 겪었습니다.
줄리앙 페로셰
모든 것이 완벽할 거라고 기대하는 경우, Maven이나 Gradle을 사용하고 있고 IDE가 빌드 시스템과 완벽하게 통합되는 데 익숙하다면 그렇게 할 수 있지만 리소스가 많이 필요합니다. 그리고 사람들이 '난 그냥 자바 코드만 작성하고 싶은데 그건 내 일이 아니야'라고 생각한다면 문제가 생길 수 있습니다.
하지만 일반적으로 제가 인터뷰한 모든 사람들은 Java가 Bazel과 상당히 원활하게 작동한다고 언급했습니다. 다른 언어에서는 좀 더 어려움을 겪을 수 있습니다.
Open Systems의 Julien은 Bazel에서 수용 가능한 프런트엔드 환경을 구현하는 것이 언어별로 가장 어려운 과제라고 생각했습니다. 프론트엔드 개발자들은 핫 리로딩을 잃는 것을 좋아하지 않았습니다.
줄리앙 페로셰
특히 백엔드에서 작업할 때, 즉 Java 서비스를 실행해야 할 때 이 기능을 채택할 수 있었기 때문에 여전히 이 기능을 사용하는 것이 이득이었습니다. 하지만 신입 사원을 온보딩할 때면 백엔드 서비스를 가동하는 데 어려움을 겪었던 기억이 전혀 없었습니다. 1분이면 좋다고 하면 그는 10초 정도면 된다고 말하곤 했습니다.
Julien은 숙련된 프론트엔드 개발자가 원하는 대로 Bazel 워크플로를 작동시킬 수 있다는 것을 알게 되었지만, 그 과정이 간단하지는 않았습니다:
줄리앙 페로셰
프런트엔드 도구가 어떻게 작동하는지 이해하는 프런트엔드 담당자가 있는 경우(매우 드문 경우이긴 하지만)에는 핫 리로딩을 통해 작업을 수행할 수 있습니다. 하지만 스택 오버플로에서 복사하여 붙여넣기하는 방식으로는 어렵습니다.
무슨 일이 일어나고 있는지 이해해야 하며, 그래야만 다른 사람이 툴을 사용하여 작업하고 합리적으로 효율적으로 작업할 수 있습니다. 시니어 프론트엔드 개발자가 있다면 빌드 툴체인에 대해 물어보면 의외로 잘 걸러낼 수 있고, 복잡하게 얽혀 있기 때문에 어떤 개발자가 자신의 것을 잘 알고 있는지 빠르게 파악할 수 있습니다.
Tweag의 Andreas도 이러한 어려움을 극복해야 했습니다. 그는 자바스크립트의 툴링은 더 큰 기능 세트를 가지고 있으며, Bazel은 이를 모두 재현할 수 없다고 말합니다:
안드레아스 헤르만
예를 들어, 특정 위치에 존재하고 전체 하위 트리가 있는 노드 모듈 폴더나 실행 중인 서버 인스턴스에 변경 사항을 코딩하는 방법 등은 샌드박스를 시도하는 시스템에 통합하기가 매우 어렵고, 채택하는 데 저항이 있을 수 있습니다.
이 경우 특정 컴포넌트가 두 빌드 시스템을 모두 유지하도록 하는 것도 유효한 접근 방식이 될 수 있습니다. 사람들이 빠른 피드백 주기를 얻기 위해 기본 도구로 개발하도록 한 다음 전체 통합을 위해 Bazel을 사용하도록 하는 것이죠.
하지만 언어 도구에 대한 그림이 경고와 불만만 있는 것은 아닙니다. Tweag의 Andreas는 일부 언어 커뮤니티에서 Bazel의 인체공학적 이점을 누리고 있으며 매우 빠르게 도입하고 있다고 말합니다:
안드레아스 헤르만
그 좋은 예로 C++를 들 수 있습니다. 도구 자체가 훌륭하지 않다는 것은 아닙니다. 다만 C++의 역사가 워낙 길고 에디터 통합이나 패키지 관리자 같은 것이 존재하지 않던 시절에 만들어졌기 때문이죠. 따라서 이질적인 생태계가 형성되어 있고 툴링이 좋지 않은 상황도 많습니다. 따라서 Bazel은 이전에 사용하던 것보다 훨씬 개선된 기능을 제공하므로 사람들은 사용하기가 훨씬 쉬워졌다는 사실을 깨닫고 매우 빠르게 참여하게 됩니다.
Andreas는 Bazel로의 마이그레이션을 수행하면서 관련된 노력 수준에 대한 기대치를 미리 설정하는 것이 중요하다는 것을 배웠습니다:
안드레아스 헤르만
Bazel은 프로젝트에 복잡성을 더하고 유지 관리 비용이 상당히 많이 든다는 점은 분명합니다. 따라서 마이그레이션 프로젝트는 시간이 오래 걸립니다. 그 이유는 Bazel이 작동하는 방식대로 빌드 작업의 입력과 출력을 매우 정확하게 추적하기 때문입니다. 모든 개별 파일을 추적하고 파일 시스템에서 파일이 표시되는 위치, 출력을 쓸 수 있는 위치 등에 대한 특정 기대치를 가지고 있습니다. 이는 모든 도구가 공유하지 않는 가정 또는 제약 조건입니다. 따라서 마이그레이션 측면에서 오버헤드가 발생합니다.
또한 Bazel을 위한 인프라 설정에 시간이 걸릴 수 있으므로 이를 고려해야 합니다:
안드레아스 헤르만
인프라가 필요하며 이는 아직 개발 중인 공간입니다.
그래서 프로젝트에 적합한 원격 캐시 및 원격 실행을 설정하기 위한 통합 작업이 필요할 것입니다. 따라서 만약 소규모 프로젝트이거나, 이러한 작업에 일정 인원을 할당할 수 없는 소규모 팀인 경우 아직은 좋은 선택이 아닐 수 있습니다.
따라서 일부 서버를 프로비저닝하고 관리할 준비가 되어 있지 않다면 분산형 시스템인 Bazel은 적합하지 않을 수 있습니다. 하지만 Bazel을 고려하는 대부분의 규모에서는 이 문제가 크게 문제가 되지 않습니다.
Bazel로 마이그레이션할 때 가장 큰 변화는 빌드 파일 작성 및 유지 관리입니다. 입력과 출력이 추론되는 빌드 시스템에 익숙하다면 이런 작업이 부자연스럽고 보일러 플레이트처럼 느껴지거나 바쁜 작업처럼 느껴질 수 있습니다. Google의 Jason은 이러한 오버헤드 때문에 리팩토링 속도가 느려진다고 말합니다.
제이슨 스티빙
리팩터링을 할 때 가끔 작은 변경을 한 것처럼 느껴지는데, 예를 들어 리팩터링을 하면 IntelliJ가 파일을 이동하고 이 파일을 가리키는 다른 파일의 모든 참조를 업데이트하는데 이는 정말 멋지죠.
하지만 IntelliJ는 내 빌드 대상에 대해 알지 못합니다. 빌드 대상이 다른 모든 것과 함께 이동한 것 역시요. 가끔은 그게 동작하기도 합니다. 예를 들어 구글에서 도구를 사용하면 빌드 대상이 자동으로 업데이트되기도 합니다.
하지만 claro에서 작업할 때는 모든 대상을 업데이트하기 위해 Bazel 오류 메시지를 수동으로 따라가야 합니다. 그러면 모든 빌드 대상을 업데이트하는 것이 너무 귀찮아서 리팩터링을 할 수 없게 될 것입니다. 그래서 나는 이를 '오늘 내가 할 일은 빌드 대상을 이리저리 옮기는 것뿐이야' 같은 프로젝트로 저장합니다.
Andreas는 빌드 파일을 관리, 생성 및 업데이트하는 솔루션이 현재 Bazel 커뮤니티가 집중하고 있는 분야라고 말합니다.
안드레아스 헤르만
Bazel 커뮤니티 전체가 자동화를 위해 노력하고 있습니다. 이 모든 작업을 일일이 손으로 할 필요가 없도록 말이죠. 가장 인기 있는 아이디어는 빌드 파일 생성이며, 가장 인기 있는 도구는 Go에서 유래했지만 확장성이 뛰어나고 다양한 언어 지원으로 확장되고 있는 Gazelle이라고 생각합니다.
이 도구는 프로젝트를 살펴보고 소스 파일을 살펴보고 특정 소스 파일이 어떤 모듈에 종속되어 있는지 확인한 다음 빌드 정의를 생성하거나 빌드 정의를 업데이트하여 새로운 종속성을 캡처하는 등의 작업을 수행할 수 있습니다.
그리고 흥미로운 점은 결과를 기존 빌드 구성 파일과 통합할 수 있는 방식으로 작동한다는 것입니다. 이런 종류의 자동화가 항상 모든 경우에 100% 작동하도록 만드는 것은 매우 어렵기 때문에 흥미롭습니다. 대부분의 언어에는 이런 종류의 자동화를 만드는 것을 정말 어렵게 만드는 이상한 메커니즘이 있기 때문입니다.
따라서 사용자 지정 지점에서 이 타겟이 조금 이상하다고 말할 수 있습니다. 이유를 모르겠고, 역사적인 이유도 있고, 그래서 몇 가지 사용자 지정 변경을 할 거고, 도구에 이것이 이상하다는 것을 알고 있지만 아주 가만히 내버려 두세요라는 특별한 주석을 넣을 수 있습니다.
넷플릭스의 오스카는 결국 자신만의 빌드 파일 생성 도구를 만들었습니다.
오스카 보이킨
Gazelle은 스칼라를 지원하지 않으며, 제 구글 프로젝트 경험상 스칼라가 잘 작동한다면 사용해도 됩니다. 하지만 외부인으로서 프로젝트에 기여하고 싶지는 않을 것입니다. 하지만 스칼라에서 제너레이터가 어떻게 작동해야 하는지에 대해서는 깊이 관여하고 싶지 않았기 때문에 그냥 그 일을 하는 도구를 만들었습니다.
오스카의 도구는 모든 추천 코드를 파싱하고, 어렵다고 여겨지던 스칼라 코드에서도 의존성 그래프를 작성하고 빌드 파일을 생성합니다.
오스카 보이킨
한 달 동안 Java와 Scala용 빌드 생성기를 만들었는데, 수동으로 주석을 거의 달지 않고도 사용할 수 있었습니다. 아마 25만 줄의 코드가 있는 리포지토리에 10개 정도 있을 겁니다.
따라서 충분히 동기가 부여된 팀이라면 Gazelle이 적합하지 않은 경우 사용 사례에 맞는 BUILD 파일 생성기를 구축할 수 있습니다.
빌드 파일 생성에 대한 지원이 늘어남에 따라 Jason(자체 프로그래밍 언어 Claro를 빌드하고 있음)은 Bazel이 범용 빌드 솔루션이 되기를 희망합니다. 그는 모든 프로그래밍 언어에 Bazel 규칙이 적용되어 대규모 빌드 작업을 Bazel에 맡길 수 있게 되기를 상상합니다. 나는 이 아이디어를 Oscar에게 물어봤습니다.
오스카 보이킨
저는 그가 설명하는 비전이 실현되기를 바랍니다. 그가 묘사하는 것이 실제로 이루어질 수 있고, 지금도 가능할 수 있다는 것을 알 수 있습니다. 그러나 그것이 일어날 것이 분명하지는 않습니다. 왜냐하면 모멘텀이 없기 때문입니다. 매일 20개의 회사가 Bazel에 PR을 보내는 것도 아니고요.
저는 Bazel이 프로그래밍을 위한 리눅스형 프로젝트가 될 수 있다고 홍보하곤 했어요. 무료 BSD를 사용할 수도 있고, 그렇게 하는 사람들도 있지만, 대부분의 사람들은 리눅스를 배포할 것이고, 우리는 Bazel로 코드를 작성하는 세상에 도달할 수 있을 것입니다.
새로운 언어를 만들었으니 새로운 빌드 시스템이나 패키지 관리자를 만들지 않아도 됩니다. 그냥 Bazel 규칙을 작성하기만 하면 되죠. 저도 그 비전에 전적으로 동의합니다. 차이점은 리눅스가 어떻게 개발되었는지를 살펴보는 것입니다.
누구나 리눅스에 기여할 수 있고 실제로 기여합니다. 리눅스에는 자체적인 방향이 있습니다. 리눅스에는 그의 까다로움이 어떻든 간에 프로젝트를 작동시킬 리더가 있습니다. 궁극적으로 Bazel은 구글에서 승진하려는 몇몇 사람들 뿐이라서 리누스(Linus)와 같은 존재는 없습니다.
Bazel의 문제점은, 7년이 지났고 Bazel이 점점 좋아지고 있지만, Google 오픈소스 제품이라는 점입니다. 그리고 구글은 기본적으로 '이봐요, 그냥 우리 방식대로 하세요. 당신은 멍청한 사람이고 우리 규모도 없으니까요. 여러분의 문제는 구글의 인턴이라면 누구나 해결할 수 있는 문제입니다. 진짜 문제가 아니야'라고 말하지만 그건 사실이 아닙니다.
그래서 여러분은 이 문제를 해결하기 위해 씨름해야 하고, PR을 보내도 응답이 없을 수도 있습니다. Bazel 빌드에서 이슈나 PR을 찾아보면 마치 무덤과도 같습니다. PR을 읽거나 응답하는 것은 아무도 할 일이 아닙니다. PR에 응답한다고 해서 Google에서 승진하는 사람은 아무도 없습니다. 따라서 지금 그들이 기본적으로 이야기하는 것은 2016년에 이야기하던 것들입니다.
rules_python을 보면 좀 당황스럽습니다. 구글의 지원을 전혀 받지 않은 것 같거든요. 그리고 정말 이해가 안 돼요. Bazel에서 무엇을 얻으려는 건지 모르겠어요. 정말 두세 명을 풀타임으로 투입해서 제대로 만들 여력이 없는 걸까요? 그렇게 하지 않기로 한 것 같긴 한데, 왜 그런지 모르겠어요.
그래서 오스카는 Bazel의 현재 모습에 실망했지만, Bazel이 처음 나왔을 때 많은 가능성을 보았기 때문일 뿐입니다. 그는 Bazel이 지금보다 더 발전하기를 원합니다. 제이슨은 오스카가 원래 Bazel에서 보았던 잠재력을 되새깁니다. 그는 프로그래밍 언어가 할 수 있는 일의 확장을 통해 좋은 디자인 결정을 내릴 수 있다고 생각합니다.
제이슨 스티빙
그래서 내가 좋아하는 것은 Bazel이 당신에게 요구하지는 않지만, 거의 강요하듯이 매우 작고 조립된 패키지를 만들게끔 한다는 것입니다. 그리고 그 위에 가시성 시스템을 레이어로 추가하면 갑자기 당신은 거의 어떤 것이 누구에게 의존할 수 있는지에 대한 완전한 통제를 얻게 됩니다. 이는 심지어 당신의 언어에서 제공하지 않는 방식으로입니다.
Jens는 스태프 엔지니어로서 개발자가 재사용할 수 있는 작은 단위의 코드를 작성하도록 안내하는 데 Bazel의 작은 패키지에 대한 강조가 도움이 되었다고 말했습니다. 이는 대규모 기술 조직에서 Bazel, 확장 가능한 테스트 관행 및 정적 분석을 사용하여 개발자가 조직 규모에 맞게 확장 가능한 코드를 작성하도록 안내하는 세상, 즉 Bazel의 가장 유망한 미래 비전을 암시하는 것이기도 합니다. 콘웨이의 법칙에서 벗어날 수 있는 방법입니다.
이 모든 Bazel 전문가들과 이야기를 나눈 후 제가 배운 것은 무엇일까요? 첫째, Bazel의 도입 비용이 높을 수 있지만 그만한 가치가 있다는 것을 알게 되었습니다. BUILD 파일을 작성하고 유지 관리하는 데 드는 비용은 잠재적 도입자가 계획해야 합니다. 이는 Bazel로 전환하는 것이 Maven에서 Gradle로 전환하거나 Dockerfile+Makefile에서 Earthfile로 전환하는 것과는 다르기 때문입니다. 이것은 빌드 및 캐시 서버를 설정하는 것을 포함하는 더 큰 작업이며, 당신이 작성하는 소프트웨어가 어떻게 빌드되는지 컴파일러 및 파일 시스템 수준에서 자세히 알아야 할 수도 있습니다.
둘째, 교육 및 훈련 측면도 간과해서는 안 된다는 것을 배웠습니다. 처음에는 개발자들이 이 접근 방식을 빠르게 익힐 수 있도록 시간을 할애할 계획을 세워야 합니다. 모든 사람이 비전을 이해했는지 확인하세요. 그렇지 않으면 어려움이 있을 것이라고 예상하세요.
하지만 가장 중요한 것은 제가 경험한 Bazel은 빠르고 정확한 빌드를 제공한다는 약속을 지킨다는 점입니다. Pants나 Buck과 같은 다른 도구도 있지만, Bazel이 이 카테고리의 확실한 리더입니다. 수백만 줄의 코드가 포함된 단일 리포지토리가 있다면, 일관된 방식으로 빌드하고 변경 사항에 대한 피드백을 빠르게 받을 수 있는 방법을 원할 것입니다. 개발자의 시간은 비용이 많이 들기 때문에 그렇게 하면 시간이 지남에 따라 그만한 가치가 있을 것입니다. Bazel은 바로 그런 작업을 위한 도구입니다.
코드 라인이 백만 줄 미만이거나 도입 비용이 걱정되거나 모노레포 빌드 성능에 대해 좀 더 점진적인 접근 방식을 원한다면 Earthly를 살펴볼 것입니다. 하지만 저는 Earthly에서 일하기 때문에 약간 편향되어 있습니다.