Ninja 빌드 시스템: 크롬도 쓰는, 속도에 미친 빌드 도구

빌드 시스템이 왜 중요한가요?

개발하면서 가장 짜증나는 순간 중 하나가 빌드 기다리는 시간이에요. 코드 한 줄 고치고 빌드 돌리는데 5분, 10분 걸리면 집중력이 뚝 끊기잖아요. 특히 C/C++ 프로젝트처럼 컴파일이 필요한 대규모 코드베이스에서는 빌드 시간이 생산성에 직접적인 영향을 줘요. 이 문제를 해결하기 위해 만들어진 게 바로 Ninja라는 빌드 시스템인데요, 이름부터 빠를 것 같죠?

Ninja는 구글 크롬(Chromium) 프로젝트의 빌드 속도를 개선하기 위해 구글 엔지니어 에반 마틴(Evan Martin)이 만든 도구예요. 지금은 크롬뿐 아니라 Android, LLVM, Swift, CMake 기반 프로젝트 등 수많은 대형 프로젝트에서 사용되고 있어요.

Ninja는 뭐가 다른가요?

빌드 시스템이라고 하면 보통 Make를 떠올리시죠. Makefile 작성해서 make 명령어 치는 그거요. Ninja는 Make와 같은 역할을 하지만, 설계 철학이 완전히 달라요.

Make는 범용 도구예요. Makefile 안에 조건문도 쓸 수 있고, 함수도 쓸 수 있고, 꽤 복잡한 로직을 넣을 수 있거든요. 그런데 이 유연함이 오히려 성능의 발목을 잡아요. Make가 Makefile을 파싱하고 해석하는 데 시간이 꽤 걸리거든요. 특히 파일이 수만 개인 대규모 프로젝트에서는 "뭘 빌드해야 하는지 파악하는 것" 자체가 병목이 돼요.

Ninja는 이 문제를 아주 과감한 방식으로 해결했어요. "사람이 직접 작성하는 빌드 파일은 포기하자." Ninja의 빌드 파일(.ninja 파일)은 사람이 읽고 쓰기에는 불편해요. 대신 CMake, Meson, GN 같은 메타 빌드 시스템이 자동으로 생성하도록 설계했어요. 이게 뭐냐면, 설정 파일은 사람이 편하게 쓰고(CMakeLists.txt 같은 거), 실제 빌드 실행은 기계가 편한 형태(Ninja 파일)로 변환해서 돌리자는 거예요.

이런 설계 덕분에 Ninja는 빌드 파일을 파싱하는 시간이 극도로 짧아요. 실제로 크로미움 같은 거대한 프로젝트에서도 Ninja가 빌드 그래프를 로드하는 데 걸리는 시간은 1초 미만이에요. Make였으면 이 단계에서만 수십 초가 걸렸을 거예요.

기술적으로 어떻게 빠른 건가요?

Ninja의 속도 비결은 몇 가지가 있어요. 첫째, 빌드 파일 포맷이 극도로 단순해요. 변수 치환 정도만 지원하고, 조건문이나 반복문 같은 건 아예 없어요. 파서가 할 일이 거의 없으니 당연히 빨라지는 거죠.

둘째, 의존성 추적이 효율적이에요. 파일이 변경됐는지 확인할 때 타임스탬프를 사용하는데, 이걸 최소한의 시스템 콜로 처리해요. 수만 개 파일 중에서 실제로 바뀐 파일만 정확히 찾아내서 그것만 다시 빌드하는 거죠. 이걸 인크리멘탈 빌드(incremental build)라고 하는데, Ninja가 특히 잘하는 영역이에요.

셋째, 병렬 빌드가 기본이에요. CPU 코어 수에 맞춰서 동시에 여러 컴파일을 돌리는 게 기본 동작이에요. -j 옵션으로 병렬도를 조절할 수 있지만, 별도 설정 없이도 알아서 적절한 병렬도를 잡아줘요.

업계에서의 위치

빌드 시스템 생태계를 보면, 전통적인 Make가 여전히 광범위하게 쓰이고 있고, 구글의 Bazel은 대규모 모노레포에 특화된 빌드 시스템이에요. 마이크로소프트는 MSBuild를 쓰고요. 이 중에서 Ninja는 "저수준 빌드 실행기"라는 독특한 포지션을 차지하고 있어요.

Bazel이나 CMake 같은 도구가 "무엇을 빌드할지" 결정하는 상위 레벨이라면, Ninja는 "결정된 걸 최대한 빠르게 실행하는" 하위 레벨이에요. 실제로 CMake에서 -G Ninja 옵션을 주면 Makefile 대신 Ninja 파일을 생성하는데, 이것만으로도 빌드 속도가 눈에 띄게 빨라지는 경우가 많아요.

최근에는 Rust 생태계의 Cargo나 Zig의 빌드 시스템처럼 언어에 내장된 빌드 도구들도 늘어나고 있어요. 하지만 C/C++ 생태계에서 CMake + Ninja 조합은 사실상 표준처럼 자리 잡았어요.

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

만약 C/C++ 프로젝트를 다루고 있다면, CMake를 쓰면서 아직 Make를 빌드 백엔드로 쓰고 있다면 Ninja로 바꿔보세요. cmake -G Ninja .. 한 줄이면 되거든요. 체감 속도 차이가 꽤 클 거예요.

Android 개발자라면 이미 Ninja를 쓰고 있을 가능성이 높아요. Android NDK 빌드가 내부적으로 Ninja를 사용하거든요. 빌드가 느리다고 느꼈을 때, Ninja 레벨에서 뭘 최적화할 수 있는지 알아두면 도움이 돼요.

그리고 빌드 시스템의 설계 철학 자체도 배울 점이 있어요. "모든 걸 다 하려는 도구"보다 "한 가지를 극도로 잘하는 도구"가 결국 살아남는다는 유닉스 철학이 Ninja에 그대로 담겨 있거든요. 소프트웨어를 설계할 때도 이런 사고방식은 유효해요.

마무리

Ninja는 "빌드 실행"이라는 한 가지 일을 극한까지 최적화한 도구예요. 화려하지 않지만, 크롬부터 안드로이드까지 세계에서 가장 큰 소프트웨어 프로젝트들이 의존하고 있는 핵심 인프라죠.

여러분의 프로젝트에서 빌드 시간 때문에 고통받은 경험이 있으신가요? 어떤 빌드 시스템을 사용하고 계신지, 그리고 빌드 최적화를 위해 어떤 노력을 하고 계신지 궁금해요!