C++ 표준 라이브러리, 왜 계속 '퇴보'하는가?

본문은 C++ 표준 라이브러리가 지난 15년간 새로운 기능을 추가하면서도 기존의 잘못된 설계를 수정하지 못하고 '회귀'하는 패턴을 지적합니다. 특히 std::function과 같이 C++11에 도입된 기능이 이후 여러 대체재가 등장했음에도 불구하고 ABI 호환성 문제로 인해 제거되지 못하고 'Legacy'로 남는 사례를 제시합니다. 이는 C++ 위원회가 기존 코드와의 호환성을 유지하려는 구조적 제약 때문에 발생한다고 분석합니다.

커뮤니티에서는 C++ 표준 라이브러리의 가장 큰 문제점으로 ABI(Application Binary Interface) 호환성을 지적합니다. ABI 안정성 때문에 std::regex, std::unordered_map, std::list와 같은 컨테이너들의 근본적인 성능 개선이나 설계 오류 수정이 불가능하다는 점을 강조합니다. 이로 인해 C++ 개발자들은 표준 라이브러리의 기본 구현 대신 자체적인 헬퍼 함수나 외부 라이브러리를 사용하는 경향이 있다고 언급합니다.

논의에서는 Rust의 표준 라이브러리가 처음부터 올바른 기본값(Defaults)을 제공하고, 필요시 에디션(Edition) 시스템을 통해 점진적인 개선을 이루는 것과 대조적으로 C++는 잘못된 설계를 고수하는 경향이 있다고 지적합니다. Rust의 HashMap, BTreeMap, VecDeque와 같은 컨테이너는 높은 성능을 제공하는 반면, C++의 std::unordered_map, std::map, std::list는 성능 저하의 원인이 된다는 벤치마크 결과가 제시됩니다. 이는 언어 자체의 문제가 아닌 표준 라이브러리 설계의 차이에서 비롯된다는 의견입니다.

일부 개발자들은 C++ 표준 라이브러리의 방대한 헤더와 템플릿 사용이 컴파일 시간을 늘리고 언어 자체의 복잡성을 가중시킨다고 비판합니다. 특히 'Vasa 문제'를 인용하며, 개별적으로는 의미가 있을 수 있으나 전체 시스템 관점에서는 불필요하거나 오히려 해가 되는 기능들이 계속 추가되는 현상을 지적합니다. 이는 결국 C++ 개발자에게 요구되는 전문 지식의 깊이를 심화시켜 높은 연봉으로 이어지는 노동 시장의 신호로 작용한다고 분석합니다.

다른 언어들도 기능 추가 후 후회하는 경우가 있지만, C++는 ABI 제약으로 인해 이러한 기능을 제거하거나 수정하는 데 매우 보수적이라는 점이 강조됩니다. Python은 PEP를 통해 표준 라이브러리 모듈을 삭제하고, Java는 JEP를 통해 기능을 제거하며, Rust는 에디션 시스템을 활용하는 반면, C++는 잘못된 기능이 영구적으로 표준 라이브러리에 남는다는 것입니다. 이는 C++ 생태계가 비표준 라이브러리에 의존하게 되는 주요 원인으로 작용한다고 설명합니다.