C++26이 벽에 부딪혔다. 한 가지 기능이 원인이다

C++26의 표준화 여정은 2026년 10월 24일 전례 없는 장애물에 부딪혔습니다. 초안이 ISO DIS(Draft International Standard) 투표에서 부결되었으며, 이는 C++ 표준이 이 중요한 단계에서 거부된 첫 사례입니다. 이 '전부 아니면 전무(all-or-nothing)' 방식의 투표는 회원국들이 개별 기능이 아닌 전체 초안을 승인하도록 요구했습니다.

투표 결과는 냉혹했습니다. 참여 회원국 중 60%(20개국 중 12개국)만이 찬성하여 필요한 3분의 2 과반수에 미치지 못했습니다. 설상가상으로 22개 회원국 중 9개국이 반대표를 던져, 부결 허용 한도인 25%를 넘어선 41%라는 경악스러운 수치를 기록했습니다. 이는 C++의 취소나 C++26의 모든 기능에 대한 전면 거부가 아니었습니다. 단 하나의 논쟁적인 제안에 대한 깊은 의견 차이로 인해 전체 패키지에 대한 결정적인 거부권이 행사된 것입니다.

이번 결과는 각국 위원회가 단순한 거수기가 아님을 확인시켜 주었습니다. 이번 부결은 작성된 C++26 표준이 진행되지 않음을 의미합니다. 커뮤니티는 이제 초안을 재평가하고 수정해야 하는 복잡한 과제에 직면했으며, 이로 인해 릴리스가 상당히 지연될 가능성이 있습니다.

C++26을 위해 제안된 런타임 검사 기능인 Contracts가 논란의 여지 없는 결렬의 원인이 되었습니다. P2900에 자세히 설명된 이 기능은 preconditions, postconditions, assertions를 언어에 직접 도입하여 개발자가 예상되는 프로그램 상태와 동작을 명시할 수 있도록 하는 것을 목표로 했습니다.

이는 사소한 추가 사항이 아니었습니다. Contracts 하나만으로도 표준 초안이 약 56페이지나 늘어났습니다. 이 제안은 ignore, observe, enforce, quick-enforce라는 네 가지 구현 정의 평가 모드를 명시했습니다. 다양한 배포 시나리오에 적응하기 위한 이 유연성은 오히려 상당한 반발을 불러일으켰습니다.

C++ 창시자인 Bjarne Stroustrup을 포함한 비판자들은 Contracts를 위험 요소가 가득한 거대하고 불완전한 설계로 보았습니다. 그들은 이것이 불필요한 복잡성, undefined behavior의 새로운 경로, 그리고 프로덕션 빌드에서 비활성화될 수 있고(실제로 그럴 가능성이 높은) 런타임 검사라는 근본적인 설계 결함을 도입한다고 주장했습니다. 그들은 이것이 C++의 핵심 원칙인 'zero-overhead'를 훼손하며, 현대적인 정적 분석으로 더 잘 해결할 수 있는 문제에 대해 1980년대식 해결책을 제시한다고 비판했습니다.

C++의 창시자인 Bjarne Stroustrup은 단순히 Contracts를 싫어한 것이 아니라, 반대 운동을 주도했습니다. 지난 8월, Stroustrup과 4명의 공동 저자(J. Daniel Garcia, Vinnie Falco, John Spicer, Ville Voutilainen)는 “P2900 Contracts' Fundamental Flaws”라는 제목의 P4334R0 문서를 발표했습니다. 이 문서는 해당 제안을 “C++에 대한 실존적 위협”으로 규정하고, 그 접근 방식을 “약 50년간의 발전을 무시하는 1980년대식 접근법”이라고 일축했습니다.

핵심적인 설계 분열은 명확합니다. Stroustrup을 포함한 비판자들은 일관된 정적 분석과 강력한 안전 보장을 옹호하며, 런타임 전용 검사는 프로덕션 빌드에서 제거됨으로써 C++의 zero-overhead 원칙을 위반한다고 주장합니다. 또한 그들은 이 제안이 새로운 undefined behavior 위험과 검증되지 않은 상속 모델을 도입한다고 주장했습니다.

반면 지지자들은 런타임 Contracts를 프로그램 가정을 표현하고 검사하는 데 즉각적으로 유용한 실용적인 도구이자 현대 개발에 필요한 기능으로 보고 있습니다. 해당 제안에 대한 자세한 내용은 P2900: Contracts for C++를 참조하십시오.

Stroustrup의 제로 오버헤드 우려에 대한 반론도 똑같이 설득력이 있습니다. 제대로 작동하는 표준화 프로세스라면 위원회의 타협안을 무비판적으로 승인하기보다는 이처럼 제안을 깊이 있게 검토해야 합니다. C++26 부결은 국가별 위원회가 주의 깊게 지켜보고 있음을 증명하며, 표준 제정이 지연되더라도 새로운 기능이 가장 높은 기준을 충족하도록 보장합니다. 이는 단순히 Contracts에 관한 문제가 아니라 표준화 프로세스 전체의 무결성에 관한 문제입니다.

C++26 투표의 '전부 아니면 전무(all-or-nothing)' 방식은 Contracts가 단독으로 실패한 것이 아니라 전체 표준을 함께 무너뜨렸음을 의미합니다. static reflection 및 std::execution과 같이 많은 기대를 모았던 기능들이 현재 불확실한 상태에 놓여 있습니다. 이러한 부수적 피해는 발전을 갈망하는 커뮤니티에게는 쓰라린 결과입니다.

이러한 교착 상태는 C++가 소프트웨어 안전성과 신뢰성을 개선해야 한다는 점점 더 커지는 압박에 직면한 가운데 발생했습니다. Rust나 Swift와 같은 경쟁 언어들은 메모리 안전성 보장과 강력한 동시성 모델을 제공하며, C++ 표준 위원회가 진화해야 한다는 압박을 가하고 있습니다. 업계는 단순한 성능 이상의 것, 즉 증명 가능한 정확성을 요구합니다.

이제 위원회는 어려운 길을 가야 합니다. 국가별 의견을 검토하고 우려 사항을 해결하거나, 더 극단적으로는 일정을 구하기 위해 Contracts를 완전히 제거하는 방안 등이 있습니다. 더 좁은 범위의 타협안이 나올 수도 있지만, 최종 경로와 일정은 여전히 매우 불확실합니다. 이번 투표는 하나의 기능이 실제로 모든 것을 지연시킬 수 있음을 증명했습니다.

C++26 초안이 ISO 투표에서 실패한 이유는 무엇인가요?

초안이 요구되는 승인 임계값에 미치지 못했고 허용된 반대 투표 비율을 초과했기 때문입니다. Contracts 제안에 대한 의견 불일치가 주요 원인으로 널리 인식되고 있습니다.

C++에서 Contracts란 무엇인가요?

Contracts는 런타임에 확인할 수 있는 사전 조건, 사후 조건 및 어설션을 표현하기 위해 제안된 언어 기능입니다.

투표가 C++26의 모든 기능을 거부한 것인가요?

투표는 전체 초안 표준을 대상으로 했기 때문에 초안 전체가 실패한 것입니다. 소스에 설명된 반대 의견은 모든 C++26 기능이 아닌 주로 Contracts에 집중되었습니다.

투표 실패 후 C++26은 어떻게 되나요?

위원회는 국가별 위원회의 의견을 검토하고 Contracts를 제거할지, 제안을 수정할지, 아니면 다른 경로를 모색할지 결정해야 합니다. 출시 일정은 불확실합니다.