C++26 DIS 부결, 창시자 Bjarne Stroustrup의 반대가 WG21의 90% 합의를 넘어선 이유

들어가며

C++26 국제표준안(DIS)이 부결됐습니다. 기술적 이견이나 절차 논란은 예전에도 있었지만, 이번에는 성격이 다릅니다. 언어 창시자 Bjarne Stroustrup이 위원회(WG21)가 합의한 DIS의 승인에 반대했고, 이는 WG21 36년 역사에서 처음 있는 일입니다.

쟁점은 contracts(계약 기반 프로그래밍) 기능입니다. 이 글은 Herb Sutter가 정리한 분석을 바탕으로 이번 사태의 경과, 다른 언어의 비슷한 사례, C++26이 고를 수 있는 선택지를 살펴봅니다.

핵심 요약

WG21은 contracts를 C++26에 넣는 데 약 90%의 지지를 얻었습니다.
Bjarne은 안전성, 구현 정의 동작, 제한적인 위반 처리 등 설계 결함이 심각하다며 반대했습니다.
국가표준기관(NB)들은 이번 투표에서 위원회의 합의보다 창시자의 반대를 더 무겁게 봤습니다. 다만 그 반대가 부결의 결정적 원인이었다는 판단은 Herb Sutter의 분석입니다.
C, JavaScript, Perl, Python 등에서도 창시자와 운영 주체가 충돌했습니다. 결과는 기능 철회부터 언어 분리, 창시자 이탈까지 다양했고, 이런 갈등을 완전히 막은 지배구조는 없었습니다.

1. 투표 숫자와 양측의 시각

2026년 3월 Croydon 회의에서 현재 형태의 C++26 출하에 114명이 찬성하고 12명이 반대했습니다. 숫자만 보면 압도적입니다. 하지만 양측의 인식은 크게 다릅니다.

찬성 측 입장

반론을 여러 번 충분히 들었고 설계도 여러 차례 고쳤습니다.
직원과 계약자를 포함해 기업별 중복을 걸러내고 다시 세어도 결과는 사실상 같았습니다.
contracts는 2024년 초 EWG로 넘어온 뒤 2년 동안 논의됐습니다. 때로는 전문가 70명이 여러 날에 걸쳐 반론을 검토했습니다.
SG21에는 한 기업의 참여가 몰려 있었지만, EWG와 전체회의는 한 기업이 결과를 좌우하기 어려울 만큼 규모가 큽니다.

반대 측 입장

반론이 공정하게 다뤄지지 않았다고 봅니다.
기존 결정을 뒤집으려면 3:1 다수가 필요해 실질적인 수정이 막혔다고 주장합니다.
EWG가 연구그룹을 신뢰하고 변경 문턱이 높다 보니, 기술 쟁점을 깊이 이해하지 않은 찬성표가 늘 수 있다고 봅니다. 그런 인상만으로도 합의에 대한 신뢰가 떨어진다는 지적입니다.

그 밖에도 위협적인 언행, 특정 기업의 인원 동원, NB에 전달된 정보의 정확성을 두고 양측 판단이 엇갈렸습니다. 양측 모두 상대를 이해하려고 애썼지만 형식적으로만 들었다는 평가를 받았다고 느꼈습니다.

2. 강한 소수 반대는 처음이 아닙니다

C++ 역사에서 10% 이상이 꾸준히 반대한 기능은 여럿 있었습니다.

C++98의 export
C++11의 constexpr
C++20의 코루틴과 모듈

당시에는 소수 의견을 충분히 들은 뒤에도 합의가 유지되면, 이견은 기록으로 남기고 결정에는 협력하는 방식으로 DIS를 만장일치 승인했습니다. export, concepts, 예외 명세, C++20 contracts를 뺄 때도 DIS 투표 전에 WG21의 합의와 Bjarne의 지지가 함께 있었습니다. Bjarne은 과거의 만장일치에 자신이 공개적으로, 또 비공개적으로 승인을 독려한 것도 기여했다고 말합니다.

C++20과 C++26은 무엇이 다를까요?

C++20: contracts를 넣기로 합의한 뒤, 다시 빼기로 합의했습니다.
C++26: EWG와 전체회의가 도입 의사를 거듭 압도적으로 확인했고, 현재 작업 초안에도 contracts가 들어 있습니다.

3. Bjarne은 왜 반대했을까요?

Bjarne은 **P4334R0, 「P2900 Contracts' Fundamental Flaws」**에서 다음 문제를 지적했습니다.

새로운 보안 취약성
핵심 기능이 구현 정의 동작으로 처리됨
제한적인 위반 처리
추가 오버헤드
불완전성
컴파일러 스위치에 따라 달라지는 의미론

그는 예전에도 P0977R0 「Remember the Vasa!」 등으로 WG21의 방향을 경고한 적이 있습니다. 하지만 이번에는 기능 결정이 너무 잘못돼 DIS를 승인해서는 안 된다는 데까지 나아갔습니다.

4. NB 투표는 어떻게 흘러갔을까요?

NB는 위원회 결정을 자동으로 승인하는 기관이 아닙니다. Sutter가 직접 파악한 범위에서 정리한 내용은 이렇습니다.

WG21에 등록된 전문가는 약 600명입니다. 그중 Croydon 이후 다른 NB에 조직적으로 반대표를 요청한 사람은 5명, 승인을 독려한 사람은 1명이었습니다.
그가 본 반대 메시지는 모두 Bjarne의 반대를 핵심 근거로 들었습니다.
반대표를 던진 NB의 절반 이상은 WG21에 참여한 적이 없거나, C++26 contracts에 우려를 표한 적이 없었습니다.
일부 NB는 자체 기술 전문가 다수가 찬성했는데도 기권했습니다.
추가 설득으로 반대 NB가 두 배 이상 늘었습니다. 표 차이는 아주 근소해서, 추가로 반대한 NB 중 한 곳이 찬성하고 다른 한 곳이 기권했다면 통과했을 정도였습니다.

Sutter는 이를 창시자의 반대가 사실상 거부권으로 작동한 결과로 해석합니다. 그리고 Bjarne이 승인을 권고했다면 통과했을 것이라고 봅니다. 물론 이는 반사실적 분석이지 확인된 사실은 아닙니다.

5. 다른 언어에서는 어땠을까요?

창시자와 운영 주체의 충돌은 C++만의 일이 아닙니다.

| 언어 | 무슨 일이 있었나 | 결과 | |---|---|---| | C | Dennis Ritchie가 ANSI X3J11에 noalias 제거를 요구하고 const도 비판 | noalias 제거. 이후 Ritchie는 관여를 중단 | | Pascal | Niklaus Wirth가 Modula-2와 Oberon으로 옮겨 감 | 창시자 없이 표준화된 Extended Pascal은 널리 채택되지 못함 | | Perl | Larry Wall이 Perl 6를 추진했지만 커뮤니티 상당수는 Perl 5에 남음 | 영구 분리. 2019년 Raku로 이름 변경 | | JavaScript | Brendan Eich가 추진한 ES4가 TC39 합의를 얻지 못함 | 폐기됐지만 많은 아이디어가 ES5와 ES2015에 반영됨. Eich도 계속 참여 | | Java | James Gosling이 추진한 완전한 클로저 지원이 여러 해 미뤄짐 | 2010년 Oracle을 떠나며 조직문화 문제를 이유로 듦 | | Rust | Graydon Hoare의 의견이 여러 설계 논쟁에서 받아들여지지 않음 | Rust를 떠난 뒤 「The Rust I Wanted Had No Future」를 씀 | | Python | Guido van Rossum이 강한 반대 속에 PEP 572(:=)를 관철 | BDFL에서 물러나고 운영위원회 체제로 전환. 이후 일반 참여자로 복귀 | | Swift | Chris Lattner가 핵심 팀 회의의 유해한 환경을 지적 | Swift 핵심 팀과 Swift Evolution을 떠남 |

이번 사태와 **가장 닮은 선례는 C89의 noalias**입니다. Ritchie는 1988년 최종 검토 막바지에 기능 하나를 빼라고 최후통첩처럼 요구했습니다. 이듬해에는 협상할 수 없는 요구라고 못 박지 않으면 위원회가 움직이지 않을 것이라 판단했다고 밝혔습니다. 당시 위원회의 「정치적으로 불가능하다」는 말은 사실상 「Dennis가 받아들이지 않는다」는 뜻이기도 했습니다. 38년 뒤의 C++ contracts 갈등과 무척 닮았습니다.

6. 역사에서 보이는 세 가지 패턴

창시자의 영향력은 공식 직위가 아니라 평판에서 나옵니다. Ritchie는 X3J11 투표권이 없었고, Eich는 ECMA에서 특별한 지위가 없었으며, Bjarne도 ISO 절차상 특권이 없습니다. 그래도 창시자는 언어의 비전, 구현, 산업 현장의 사용 경험, 교육 관행을 두루 아우르는 독특한 위치에 있습니다.
반대는 좁고, 기술적이고, 드물수록 효과적입니다. Ritchie는 5년 동안 위원회를 믿고 맡긴 뒤 단 하나의 기능을 정확한 기술적 근거로 문제 삼았습니다. 위원회 전체의 방향이나 안목을 부정하지는 않았습니다.
양측 모두 물러서지 않으면 분리나 이탈로 끝나기 쉽습니다. 여러 구현이 하나의 표준을 공유한다는 데 가치가 있는 C++에서, 「창시자의 C++」와 「위원회의 C++」로 갈라지는 것은 최악의 결과입니다.

7. C++26 앞에 놓인 선택지

현재 합의를 바꾸려면 새로운 합의가 필요합니다. A를 뺀 나머지 선택지는 Búzios 회의에서 2026년 안에 기술 작업을 끝낼 수 있습니다. contracts를 백서로 옮기는 식의 변형도 가능합니다.

A. C++26 ISO 발행을 건너뛰고 C++29로 진행 설계, 구현, 배포 경험이 더 쌓여 판단이 바뀌기를 기다리는 방식입니다. 3년 뒤 같은 충돌이 되풀이될 위험이 있습니다.
B. contracts를 빼고 DIS를 다시 투표하고, 대안을 재검토 P2900과 P4324 같은 경쟁 제안을 기존 설계를 기본안으로 두지 않고 비교합니다. Bjarne이 가장 바라는 선택지이며, 그는 6주 안에 새 DIS 초안을 만들기를 희망합니다. 다만 contracts 자체가 무산되거나, 전문가들이 창시자의 사전 지지 없이는 제안에 투자하기를 꺼리게 될 위험이 있습니다.
C. 근거를 보강해 NB를 설득한 뒤 재투표 반론을 어떻게 검토했고 왜 동의하지 않았는지 정리한 근거 부록을 붙입니다. 공개 대립이 더 깊어질 위험이 있습니다.
D. Búzios 이후 초안을 새 DIS로 투표하고 P3911도 검토 가상 함수 지원 부족에 관한 NB 의견 두 건을 일부 반영한 초안을 씁니다. P3911의 pre!를 추가하는 방안도 있지만, Bjarne의 지지 없이는 NB 합의를 충분히 얻지 못할 수 있습니다.
F. 국가 표준 발행과 함께 단일 NB나 Linux Foundation으로 작업 이전을 검토 ANSI/INCITS나 Linux Foundation은 국제 참여를 허용하므로 대안이 될 수 있습니다. 다만 구성원과 조직 구조가 달라지는 만큼 신중한 검토가 필요합니다.

마치며

이번 부결은 contracts라는 기능 하나를 넘어 오픈 표준을 누가, 어떻게 이끌어야 하는가라는 질문을 던집니다. 90%의 합의도 창시자의 강한 반대 앞에서 충분하지 않을 수 있다는 점이 드러났습니다. 반대로 창시자가 반대한다고 해서 그 판단이 늘 옳다는 보장도 없습니다.

Sutter가 내놓은 장기 처방은 분명합니다. 창시자의 중대한 반대를 최대한 일찍 확인하고, 찬반 양측이 무엇을 보면 판단을 바꿀지 측정 가능한 증거에 미리 합의하자는 것입니다. C++이 둘로 갈라지지 않고 이 위기를 넘길 수 있을지 지켜볼 만합니다.

원문: https://news.hada.io/topic?id=36875&utm_source=geeknews&utm_medium=rss&utm_campaign=news