[TIL][C++] 250730 MMO 서버 개발 69일차: vcpkg를 쓰지 않았던 이유 - 라이브러리 수의 부족, 지금도 부족할까?

주의사항: 해당 글은 일기와 같은 기록용으로, 다듬지 않은 날것 그대로인 글입니다. 

vcpkg를 쓰지 않았던 이유 - 라이브러리 수의 부족

• 어제 깃헙에서 직접 라이브러리를 다운로드하여 CMake를 통해 빌드하는 방식에 대해 다루면서, 왜 이렇게 어렵게 하는지 잘 모르겠다는 이야기를 잠깐 했다. 글은 쓴 당시에 글을 쓰면서 vcpkg의 존재를 알게 된 터라 ‘대충 무슨 이유가 있겠지’라 생각하고 넘어갔는데, 오늘을 이에 대해 좀 더 자세히 알아보았다.
• 파이썬이나 node.js와 같은 다른 언어들에서 사용하는 패키지 관리자 npm을 c++에서 사용하지 못하기 때문에 MS에서 제공하는 vcpkg를 사용해야 한다.
• 이러한 vcpkg는 특히 MSVC+Windows 환경에 특화되어 있기 때문에 현재 프로젝트 환경에서 사용하기 굉장히 적합했고, 그래서 더더욱 “왜 강의에서 vcpkg를 사용하지 않았을까?’ 하는 의문을 지울 수 없었다. 그렇게 강의 QA들을 뒤져보던 도중 그 이유가 ‘등록된 라이브러리 수의 부족’이라는 것을 알게 되었다.

 

vcpkg는 정말 라이브러리 수가 적을까?

• 결론만 말하자면, 현재는 그렇지 않다. 상대적으로 최근에 출시된(2016년) vcpkg는 지원하는 라이브러리 수가 상대적으로 적었다. 하지만 시간이 지나면서 라이브러리의 수가 증가하였고, 지금은 결코 적다고 할 수 없는 수의 라이브러리를 지원한다. 대충 알아보면 아래와 같다.
  • 2020년 4월: 2019 후반 ~2020년 초반에 MS의 지속적인 투자와 함께 오픈소스 커뮤니티의 기여가 폭발적으로 증가함에 따라, 2020년 4월 공식적으로 1300개 이상의 라이브러리를 지원한다고 발표.
  • 2022년 9월: 2000개 이상의 고유 라이브러리를 지원한다고 발표.
  • 현재(2025년 기준): 2024년 12월에 2500개 이상의 라이브러리를 지원한다고 발표.

 

그래도 라이브러리가 2500개면 적은 게 맞지 않은가?

• 언어와 관계없이 모든 패키지 매니저에 등록된 라이브러리 수를 따지고 들면 매우 적은 개수가 맞다. 주요 패키지 매니저들의 규모를 보면 아래와 같이 기본만 단위로 시작하기 때문이다.
• 대규모 패키지 매니저들:
  • npm (JavaScript): 200만 개 이상
  • PyPI (Python): 50만 개 이상
  • Maven Central (Java): 50만 개 이상
  • RubyGems (Ruby): 18만 개 이상
  • Cargo (Rust): 13만 개 이상
• 중간 규모:
  • NuGet (. NET): 30만 개 이상
  • Go Modules: 수십만 개
  • Composer (PHP): 35만 개 이상

• 이런 맥락에서 2,500개는 매우 적은 것이 사실이다. 그럼에도 2,500개 적지 않은 편이라고 말할 수 있는 이유는 1) C++ / 윈도라는 보다 좁은 범위의 패키지 매니저라는 점, 2) 스크립트 언어(Python, Js 등)가 아닌 컴파일 언어에 대한 패키지 매니저라는 점, 3) 라이브러리 하나하나가 C++ 개발에 핵심적이고 광범위하기 사용되는 기반 기술 또는 대규모 라이브러리이기 때문이다.
• 컴파일 언어 방식은 스크립트 언어보다 패키지나 라이브러리를 만들기 굉장히 어렵다. 이것저것 고려해야 할 사항이나 제한되는 것도 많고, 무엇보다 컴파일 과정이 굉장히 복잡하기 때문이다. 그래서 라이브러리 수가 스크립트 언어보다 절대적으로 더 많기는 어렵다.
• 결론적으로, 절대적인 라이브러리 수를 따지면 다른 패키지 매니저들보다 매우 적지만, “꼭 써야 하는 필수적인 라이브러리가 없을 정도”는 아닌 상황이기에 현시점에선 vcpkg를 활용하는 것이 기존 방식보단 낫다고 본다.