2What — 모던 C++ 프로젝트 도구란?
3- C++ 프로젝트를 빌드·의존성 관리·테스트·자동화하는 도구 생태계
4- 핵심 4대 도구:
5 • CMake — 크로스 플랫폼 빌드 시스템 생성기
6 • vcpkg / Conan — C++ 패키지 매니저
7 • Google Test — 단위 테스트 프레임워크
8 • GitHub Actions / CI — 지속적 통합·자동화 파이프라인
9---
10Why — 도구 없는 C++ 프로젝트의 구체적 고통
111. 빌드 지옥 — 헤더 하나 바꿨을 뿐인데 전체 빌드가 깨진다
12 • 수동 Makefile은 의존성 그래프를 사람이 관리 → 누락 시 링크 에러, 스테일 오브젝트 혼재
13 • "내 PC에선 되는데?" — 컴파일러 버전, 경로, OS 차이가 재현 불가능한 빌드 실패를 만든다
142. 의존성 충돌 — 동료 PC에서만 안 되는 라이브러리 버전 문제
15 • Boost 1.78 vs 1.82, OpenSSL 1.1 vs 3.0 — 수동 설치는 버전 고정이 불가능
16 • "금요일에 됐는데 월요일에 안 돼요" — 시스템 업데이트가 의존성을 조용히 파괴한다
173. 품질 붕괴 — PR마다 다른 코드 스타일, 회귀 버그 반복
18 • 테스트 없이 머지하면 한 기능 수정이 세 기능을 깨뜨린다
19 • 코드 리뷰에서 스타일 논쟁에 시간을 낭비한다 (탭 vs 스페이스, 네이밍 규칙)
20---
21How — 각 도구가 제거하는 고통
22- CMake → 빌드 지옥 제거
23 • \texttt{CMakeLists.txt} 하나로 Windows·Linux·macOS 빌드를 통일한다
24 • 타겟 기반 의존성 추적: 헤더가 바뀌면 영향받는 타겟만 정확히 재빌드
25 • 비유: CMake는 "건축 도면" — 어떤 현장(OS)에서든 같은 건물이 나온다
26- vcpkg → 의존성 충돌 제거
27 • \texttt{vcpkg.json} 매니페스트로 라이브러리 버전을 코드와 함께 버전 관리
28 • 바이너리 캐싱으로 팀 전원이 동일한 빌드 결과를 공유
29 • Microsoft가 내부 C++ 프로젝트 의존성 관리를 위해 개발 (Loughran, 2016)
30- Google Test → 회귀 버그 제거
31 • \texttt{TEST()}, \texttt{EXPECT\_EQ()} 매크로로 단위 테스트를 빠르게 작성
32 • CTest와 통합하여 빌드 직후 자동 테스트 실행
33 • Google 내부 수십억 줄 C++ 코드베이스의 품질을 유지하는 핵심 도구 (Whittaker et al., 2012)
34- GitHub Actions / CI → 수동 검증 제거
35 • 푸시·PR마다 빌드 → 테스트 → 린트를 자동 실행
36 • clang-format + clang-tidy로 스타일·정적 분석을 기계에 위임
37 • 비유: CI는 "24시간 근무하는 코드 리뷰어" — 사람이 자기 전에도 검증한다
38---
39산업 채택 사례 — 왜 표준이 되었는가
40- Google — 자체 빌드 시스템 Bazel 외에도 오픈소스(Abseil, gRPC)에 CMake + Google Test 공식 지원
41- Microsoft — vcpkg를 만들어 오픈소스화, Visual Studio에 CMake 네이티브 통합 (2017~)
42- Mozilla — Firefox의 C++ 컴포넌트에 CI 파이프라인 필수화, 빌드 실패 시 머지 차단
43- LLVM/Clang — CMake 단독 빌드 시스템, CTest + lit으로 수만 개 테스트 자동화
44이들의 공통점: 팀이 10명을 넘는 순간, 수동 프로세스는 확장 불가능(non-scalable)하다는 결론에 도달했다 (Winters et al., 2020)
45---
46핵심 메시지
47- 혼자 토이 프로젝트를 할 때는 \texttt{g++ main.cpp}로 충분하다
48- 그러나 팀 규모가 커지고 코드가 쌓이는 순간, 도구는 선택이 아니라 생존 조건이다
49- "좋은 도구가 좋은 개발자를 만드는 게 아니라, 좋은 도구가 나쁜 습관을 방지한다" — 자동화가 인간의 실수 공간을 줄인다