Bazel에 Content-Defined Chunking이 들어왔다 - 대용량 빌드 캐시가 빨라지는 이유

Bazel과 빌드 캐시, 잠깐 짚고 갈게요

Bazel 들어보셨나요? 구글이 내부에서 쓰던 빌드 시스템을 오픈소스로 공개한 거예요. 대규모 프로젝트, 그러니까 수만 개의 파일과 수십 개의 언어가 섞여 있는 코드베이스를 효율적으로 빌드하기 위해 만들어졌어요. Bazel이 강력한 이유 중 하나가 바로 원격 캐시(remote cache) 인데요, 이게 뭐냐면 누군가 한 번 빌드한 결과물을 클라우드에 저장해 놓고 다른 개발자나 CI 서버가 같은 입력으로 빌드할 때 그냥 결과만 다운로드해서 쓰는 기능이에요.

예를 들어 동료가 어제 빌드한 라이브러리 바이너리가 100MB라면, 내가 같은 코드를 빌드할 때 컴파일을 다시 하지 않고 그냥 100MB를 받아오기만 하면 되는 거죠. 빌드 시간이 분에서 초로 줄어들어요. 그런데 여기에 한 가지 문제가 있어요. 코드를 한 줄만 바꿔도 결과 바이너리는 살짝 달라지거든요. 그러면 캐시 키가 바뀌고, 또 100MB를 통째로 새로 업로드하고 다운로드해야 해요. 작은 변경에도 매번 전체 파일이 오가는 비효율이 생기는 거죠.

Content-Defined Chunking이 뭔가요?

BuildBuddy 팀이 Bazel에 도입한 게 바로 Content-Defined Chunking(CDC) 이에요. 우리말로 풀면 "내용 기반 조각내기" 정도가 돼요. 파일을 일정한 크기로 자르는 게 아니라, 파일 내용 자체를 보고 자연스러운 경계선에서 자르는 방식이에요.

비유하자면 이래요. 책을 그냥 100페이지마다 끊어서 분권하면, 한 페이지만 추가해도 그 뒤의 모든 분권이 다 어긋나잖아요. 그런데 책의 "챕터" 단위로 끊으면 한 챕터에 페이지가 좀 늘어나도 다른 챕터들은 그대로예요. CDC가 바로 이런 식이에요. 파일을 슬라이딩 윈도우로 훑으면서 해시값이 특정 패턴을 만족하는 지점을 찾고, 거기를 경계로 삼아요. 그러면 파일 중간에 데이터가 살짝 삽입되거나 수정돼도 대부분의 청크는 그대로 유지되거든요.

이 방식은 사실 새로운 게 아니에요. rsync, Borg, Restic, bup 같은 백업 도구들이 오래 전부터 써온 기술이고, Git의 LFS나 Dropbox의 파일 동기화 내부에도 비슷한 아이디어가 있어요. Rabin fingerprint나 FastCDC 같은 알고리즘이 대표적이죠. 이걸 빌드 캐시에 본격적으로 적용한 게 이번 BuildBuddy의 작업이에요.

실제로 얼마나 빨라지나요?

빌드 캐시에 CDC가 들어오면 두 가지 큰 이득이 있어요. 첫째, 업로드/다운로드 대역폭이 확 줄어요. 큰 바이너리 파일에서 일부만 바뀌었을 때, 바뀐 청크만 새로 전송하고 나머지는 캐시 서버에 이미 있는 청크를 재사용하면 되거든요. 100MB 파일 중에 실제로 변경된 부분이 1MB뿐이라면 1MB 정도만 오가게 돼요.

둘째, 스토리지 비용이 줄어요. 비슷한 빌드 산출물들이 서로 청크를 공유하니까 디스크에 저장되는 실제 데이터 양이 훨씬 작아져요. 대규모 모노레포에서 매일 수십 번씩 빌드가 돌아간다고 생각해 보면, 이게 시간이 갈수록 누적되는 이득이 어마어마해요. BuildBuddy 측 벤치마크에 따르면 큰 산출물에서 작은 변경이 일어날 때 전송량이 수십 배 줄어드는 경우가 흔하다고 해요.

기술적으로는 Bazel의 Remote Execution API(REAPI)를 확장하는 방식으로 구현됐어요. 클라이언트가 파일을 통째로 보내는 대신 청크 단위로 해시를 먼저 보내서 서버에 없는 청크만 업로드하는 프로토콜을 추가한 거죠. 기존 Bazel과의 호환성도 유지하면서요.

업계 흐름과 비교

빌드 캐시 분야에서 BuildBuddy의 주된 경쟁자는 EngFlow, Bitrise, 그리고 자체 호스팅을 하는 회사들이에요. Meta의 Buck2, Microsoft의 BuildXL도 비슷한 영역이고요. 이들도 다 원격 캐시를 지원하지만, CDC 같은 콘텐츠 기반 압축을 빌드 캐시 레이어에 직접 통합한 사례는 아직 흔하지 않아요.

반면 컨테이너 이미지 쪽은 이미 비슷한 방향으로 가고 있어요. OCI 이미지의 zstd:chunked 포맷이라든가, Nydus, eStargz 같은 lazy pulling 기술들이 다 "필요한 청크만 가져오기"를 목표로 하거든요. 빌드 시스템이 이 흐름을 따라잡는 셈이에요.

한국 개발자에게 주는 시사점

국내에서 Bazel을 본격적으로 쓰는 회사는 아직 많지 않지만, 카카오나 라인 같은 큰 회사들 일부 팀에서 도입을 검토하거나 사용 중인 걸로 알려져 있어요. 모노레포가 커지고 CI 빌드 시간이 점점 길어지는 회사라면 한번쯤 살펴볼 가치가 충분해요. 특히 머신러닝 모델 가중치나 게임 에셋처럼 큰 바이너리를 빌드 산출물로 다루는 팀에는 정말 매력적인 기능이에요.

Bazel을 안 쓰더라도 이 아이디어 자체는 다른 곳에 응용할 수 있어요. 도커 이미지 레이어 설계, S3 같은 오브젝트 스토리지에 큰 파일을 자주 업데이트해야 하는 경우, 또는 자체 파일 동기화 시스템을 만들 때 CDC 원리를 이해하고 있으면 큰 자산이 돼요. FastCDC 알고리즘은 구현도 어렵지 않아서 한번 직접 짜보면 재미있어요.

마무리

빌드 시스템 같은 인프라 레이어의 최적화는 평소엔 눈에 잘 안 띄지만, 누적되면 팀 전체의 생산성을 좌우해요. CI 한 번에 5분 줄어드는 게 별것 아닌 것 같아도, 하루 100번 돌면 8시간 이상이 절약되는 거니까요. BuildBuddy의 이번 작업은 그 "보이지 않는 최적화"의 좋은 사례예요.

여러분 팀의 CI/CD 빌드 시간은 얼마나 걸리시나요? 빌드 캐시는 어떻게 운영하시는지, 그리고 큰 빌드 산출물을 어떻게 관리하시는지 경험 공유해 주시면 좋겠어요.