CMake CPS로 본격 C++ 의존성 관리 혁신하는 방법

C++ 프로젝트에서 라이브러리와 의존성 관리, 매번 골치 아프다고 느끼셨나요? 이번 글에서는 Bill Hoffman이 제안하는 새로운 접근법, CPS(Common Package Specification)와 CMake의 결합을 통해 C++ 의존성 지옥에서 벗어나고, 더 쉽고, 더 표준적인 빌드 환경을 만드는 방법을 소개합니다. C++ 개발자 설문을 보면 80% 이상이 라이브러리 관리에서 큰 고통을 느낀다고 답했는데, CPS는 바로 그 해답이 될 수 있습니다. 여기에 Conan, Spack 같은 패키지 관리자, C++20 모듈, 그리고 소프트웨어 BOM까지, CMake와 CPS가 만들어내는 변화의 핵심을 흥미롭게 안내합니다.

C++ 프로젝트, 왜 의존성 관리가 이렇게 힘들까?

C++을 본격적으로 다뤄본 분이라면 한 번쯤 '이 라이브러리 빌드만 되면 모든 게 해결될 텐데!'라며 절규해 본 적 있으실 거예요. 복잡한 컴파일러 플래그(flag soup), 어디서부터 꼬였는지 모를 링커 경로, 버전 충돌, OS별 빌드 환경 등 기존 도구들은 '주어진 정보만' 알고 있기 때문에 전체 의존성 그래프를 쉽게 다루지 못했습니다. 개발자들도 이런 불편함을 극복하려 다양한 방법을 썼지만, 결국은 포터블하지 않고 반복적인 시행착오를 낳았죠.

패키지 관리의 역사: flag soup에서 CPS까지

예전에 'pkg-config' 같은 도구를 써서 라이브러리 플래그를 받아 붙이는 방법을 사용했으나, 버전 관리와 복잡한 디펜던시(의존성) 구성에서는 항상 한계가 있었습니다. 뭐가 필요한지 알기 힘들고, 다른 패키지랑 충돌도 쉽고, "그냥 되는지 써보자" 식의 하이리스크 빌드가 반복됐죠.

CMake도 발전해왔습니다. 처음엔 직접 만들어 쓴 find-XXX.cmake 모듈에서 시작해서, 이후에는 각각의 라이브러리가 자신만의 CMake 스크립트를 만들어서 배포하기 시작했어요. 이런 변화는 좀 더 풍부한 정보와 쉬운 링크를 제공했지만, 여전히 CMake 스크립트 언어에 묶여있어서 타 빌드 도구와의 보편적 연동에는 한계가 있었습니다.

CPS(Common Package Specification), 무엇이고 왜 중요한가?

CPS는 C++ 프로젝트의 패키지 정보를 '파일 하나의 JSON'으로 표준화합니다. 여기에 어떤 헤더, 어떤 링커 플래그, 어떤 디펜던시가 있고, 버전은 어떻게 되는지 등 모든 정보를 모두가 읽을 수 있는 방식으로 담습니다. 다시 말해, "이게 바로 그 라이브러리야!"라고 명확히 정의할 수 있는 시대가 된 것입니다.

CPS 파일 덕분에 CMake뿐 아니라 Conan, Spack, 다른 빌드 시스템들도 쉽고 표준적으로 라이브러리를 가져올 수 있습니다. 앞으로는 'CPS 파일이 없으면 라이브러리가 없는 것'이라는 식의 자동 유효성 검사, 즉 '내가 이름 치고 typo 안 낸 거 맞니?'부터, 트랜잭션성/트랜스티브(연쇄) 디펜던시까지 쉽게 다룰 수 있게 됩니다.

CMake와 CPS: 앞으로의 표준적 의존성 관리 워크플로

CMake 3.31 이상에서는 실험적으로 CPS 파일을 생성하고, 이를 인식해 라이브러리를 바로 사용할 수 있게 되었습니다. 기존의 'find_package' 호출 하나면 CPS 파일이 있는 패키지를 자동으로 찾고, 필요하다면 기존 CMake Config와 CPS를 혼합해서 사용할 수 있습니다. 접점이 넓어지면서 여러 빌드 도구와의 협력도 쉬워졌습니다.

게다가 CPS는 소스 트리와 인스톨 디렉토리 모두에서 적용될 수 있도록 발전하고 있고, 앞으로는 "빌드 트리의 실시간 CPS"까지 구현되어 개발-테스트 속도도 향상될 예정입니다.

CPS와 패키지 매니저: Conan, Spack, Bloomberg의 도입 사례

이제 CPS의 힘은 패키지 관리자들도 인정하고 있습니다. Conan은 CPS 파일을 자동 생성해 CMake가 바로 인식하도록 개선했고, Spack 역시 슈퍼컴퓨터 환경에서 엄청난 의존성 그래프를 CPS 기반으로 관리할 수 있게 실험 중입니다. Bloomberg는 수만 개 프로젝트에서 자동 CPS 파일 생성과 검증을 통해 대규모 현장에 적용해보고 있습니다.

이로써 관리/배포/진단까지 훨씬 체계적으로 할 수 있게 되었습니다.

트랜지티브 의존성, 복잡한 버전 관리를 한 번에

여러 개 라이브러리가 얽힌 C++ 프로젝트. 이제 CPS의 구조화된 디펜던시 그래프로 트랜지티브 의존성을 자연스럽게 관리할 수 있습니다. "A는 B를, B는 C를..." 식의 복잡한 연결 고리가 CPS 하나로 명확하게 기술되어, 하위 패키지의 변경에도 유연하게 대처할 수 있습니다. 버전 관리도 단순한 번호에서, 범위나 호환성 조건까지 다양하게 지정할 수 있어서 라이브러리 업그레이드와 유지보수가 훨씬 쉬워집니다.

C++20 모듈 지원: 더 깨끗하고 안전한 빌드

C++20 모듈 시대가 오면서, CPS는 모듈 메타데이터까지 담는 확장성을 지니게 됩니다. 이제 'include' 실수나 헤더 순서 꼬임도 방지하고, 프로덕션 코드와 테스트 코드 각각의 요구사항도 세밀하게 관리할 수 있습니다.

소프트웨어 BOM과 CPS: 투명한 공급망 관리의 시작

요즘 소프트웨어 SBOM(Software Bill of Materials)도 이슈죠. CPS 파일은 라이브러리의 '성분표' 역할을 하며, 나중에는 SPDX 포맷 등과 결합해 "이 소프트웨어에 어떤 코드가, 어디서, 어떻게 들어왔나"를 자동으로 추적할 수 있습니다. 취약점 발생 시, 바로 영향 받는 소프트웨어를 역추적하는 것이 쉬워집니다.

실습과 현장 적용: 정말로 쉽게 시작할 수 있을까?

CMake에서 실험 기능을 활성화하면, 기존 방식과 똑같이 'find_package'로 라이브러리를 찾을 수 있습니다. 패키지 매니저가 CPS를 지원한다면 빌드가 더 깨끗하고, 진단 메시지도 훨씬 친절합니다. 무엇보다 CPS 파일만 챙기면, 비슷한 명령, 비슷한 워크플로로 다양한 라이브러리와 언어를 다룰 수 있습니다.

앞으로의 로드맵: 커뮤니티와 함께 성장하는 CPS

CPS는 아직 진화 중입니다. 빌드 트리 CPS, 더 강력한 경고/진단 메시지, 다양한 에코시스템 지원 등 더 많은 개선이 예정되어 있습니다. 여러 커뮤니티와 개발자가 직접 실습하고 피드백을 주면, 표준화와 도구 개선에 즉각 반영되어 더욱 실용적인 형태로 발전할 것입니다.

마무리: CPS와 CMake로 C++ 의존성 지옥에서 탈출하기!

이제 C++ 의존성을 관리하는 일이 훨씬 표준적이고, 투명하며, 쉽게 바뀝니다. 빌드 문제로 스트레스 받을 시간에 진짜 개발과 혁신에 집중해보세요. CPS와 CMake의 결합은 다양한 빌드 도구, 패키지 매니저, 언어 확장까지 연결해, '모두가 행복한 패키지 관리 생태계'를 만들어 나가고 있습니다.

저 역시 현장에서 CPS를 적용하며, 작은 패키지부터 대형 프로젝트까지 실무의 편의성을 점점 실감 중입니다. 아직 실험적이지만, 여러분도 가볍게 도전해보고, 문제나 개선점 발견 시 커뮤니티에 공유해주세요. 더 많은 사용자가 참여할수록 CPS는 실무 개발자에게 더 좋은 도구가 되어갈 것입니다.

실전 팁

• 최신 CMake와 CPS 실험 기능을 꼭 켜보고, 기존 프로젝트에 부분 적용해보세요.

• Conan, Spack 같은 패키지 매니저와의 연동도 곧장 시도해볼 만합니다.

• 테스트할 때는 CPS 파일 생성, 교차 빌드, 버전 충돌 등 여러 케이스를 한 번씩 실습하면 감을 잡기 좋습니다.

• 실전에서 생긴 궁금증/버그는 즉시 프로젝트 GitHub나 공식 커뮤니티에 피드백하면 발전에 직접 기여하는 셈입니다.

좋은 의존성 관리로 '빌드 스트레스 없는' 개발 환경, 우리 모두 만들어봅시다!

출처 및 참고 :