TECH 으로 돌아가기
TECH HACKER NEWS 7분 읽기 30 READS

C++26 표준 초안, ISO 투표에서 처음으로 부결되다 — 쟁점은 '계약(contracts)'

C++26 표준 초안, ISO 투표에서 처음으로 부결되다 — 쟁점은 '계약(contracts)'
SOURCE IMAGE · HACKER NEWS

국제 표준화 기구(ISO)의 C++26 최종 국제 표준 초안(DIS) 투표가 2026년 10월 23일 마감됐고, 결과는 부결이었다. C 위원회 의장 로버트 시코드(Robert Seacord)는 다음 날 링크드인에 결과를 공개하면서, SC22 산하의 어떤 언어 표준도 투표에서 떨어진 전례가 없는 것으로 안다고 적었다. WG21 방향성 그룹(P5000R1) 소속 다비드 반데보르데(Daveed Vandevoorde)도 이전의 어떤 C++ 초안은 반대표가 단 한 표도 나오지 않았다고 언급했다. 즉 리플렉션, std::execution, 라이브러리 하드닝, 그리고 계약(contracts)까지 모두 담긴 이번 초안이 ISO의 승인을 받지 못한 채 묶였고, 지연 기간이 얼마나 될지는 아직 아무도 모른다.

숫자가 말하는 부결

DIS가 통과하려면 두 조건을 동시에 충족해야 한다. 투표에 참여한 20개국의 3분의 2, 즉 14표의 찬성이 필요했지만 찬성은 12표에 그쳤다. 또 참여국 22개국 기준으로 반대는 4분의 1인 5표까지만 허용되는데 반대가 9표였다. 두 조건 중 어느 하나만 어긋나도 부결이다. 반대한 아홉 나라는 덴마크, 핀란드, 이란, 이탈리아, 일본, 룩셈부르크, 루마니아, 스페인, 스웨덴이며, 각국은 투표와 함께 의견서를 제출했다. 프랑스와 아일랜드는 기권하면서도 의견을 냈고, 폴란드와 미국은 의견 없이 기권했다. 결과적으로 11개국이 코멘트를 남긴 셈이다.

의견서 전문은 아직 공개되지 않았다. ISO/IEC 지침(Part 1의 2.6.5 조항)은 투표 종료 후 12주 안에 결과와 의장 결정, 코멘트 전문을 담은 보고서를 내도록 요구한다. 10월 23일 마감 기준으로는 늦어도 2027년 1월 중순이다. 위원회 초안 단계에서 WG21은 이런 성격의 보고서를 N5028로 공개한 바 있는데, 이번에도 같은 방식을 택할지는 알 수 없다.

왜 '계약'이 지목되는가

원문 필자는 반대표의 핵심이 계약 기능이었다고 본다. 반대 진영의 입장은 투표 전부터 공개돼 있었다. C++26을 투표에 부친 크로이던 총회에서 제기된 두 건의 반대가 모두 계약에 관한 것이었고, 위원회 초안에 대한 여러 국가의 코멘트가 계약을 빼자고 요청했다. 문서 P4238R1은 계약의 설계와 그것이 위원회를 통과한 방식을 이유로 각국이 반대표를 던질 것을 요청하기도 했다. 다만 이 모든 것은 코멘트가 공개돼야 확정적으로 말할 수 있는 영역이다.

계약은 함수의 사전·사후 조건을 코드 안에 기술하는 기능이다. 쟁점은 이 조건 검사를 '빌드가 건너뛸 수도 있는 검사'로 볼 것이냐, '프로그램이 의존할 수 있는 보장'으로 볼 것이냐에 있다. 초안은 ignore, observe, enforce, quick-enforce라는 네 가지 평가 의미를 정의하되, 그중 무엇을 쓸지는 구현체에 맡긴다. 예컨대 GCC 16에서는 컴파일러 플래그로 하나를 고른다. 바로 이 선택권을 둘러싼 논쟁이 반대의 상당 부분을 차지한다.

부결 이후, 위원회의 선택지

지침은 DIS 부결 후 네 가지 경로를 규정한다. 그중 세 가지는 SC22 의장이 SC22 사무국, WG21 의장과 협력하고 ISO/IEC 중앙 사무국과 협의해 결정하며, '취소'만은 SC22 전체가 정해야 한다. WG21의 몫은 코멘트에 답하고 경로를 권고하며, 필요하면 수정 초안을 준비하는 것이다. 원문 작성 시점에는 어느 경로를 택했는지에 대한 발표가 없었다. 다음 WG21 회의는 2026년 11월 16~21일 브라질 부지오스에서 열린다. 부결 이후 위원회 전체가 처음 모이는 자리이며, 무엇을 해야 하는지에 대한 의견은 갈려 있다.

설계를 어떻게 개선할지는 더 까다로운 문제다. 반대 측이 내놓은 방향은 제각각이다. 컴파일러가 검사하는 더 강한 보장, 설계의 더 많은 부분을 라이브러리로 옮기기, 기술 명세(TS)를 먼저 내기, 끌 수 없는 검사 등이다. 반대하는 모든 이가 받아들일 단일 대안은 아직 보이지 않으며, 그래서 어떤 한 가지 변경이 모두를 만족시킬지 말하기 어렵다.

지금 C++26으로 짠 코드는

실무 관점에서 중요한 점은, 새 판이 나오기 전까지 현행 C++ 표준은 여전히 ISO/IEC 14882:2024, 즉 C++23이라는 사실이다. 그러나 컴파일러는 작업 초안의 기능을 구현하며, 이번 투표가 이미 출시된 것을 바꾸지는 않는다. GCC 16은 -std=c++26을, Clang은 -std=c++2c를 받아들인다. GCC 16은 실험적 C++26 지원의 일부로 계약을 구현했고, Clang 쪽 계약 구현은 아직 병합되지 않았다. 각 벤더가 초안의 모든 기능을 해당 플래그 아래 계속 유지할지는 전적으로 벤더에 달려 있으며, 오늘 그것을 장담할 수 있는 사람은 없다.

따라서 팀이 이미 C++26 기능을 쓰고 있거나 배우는 중이라도 당장 되돌릴 일은 없다. 다만 지금 컴파일러가 구현한 것은 어디까지나 초안이며, 최종 공개 표준과 일치하지 않을 수 있다는 점은 분명히 인식해야 한다. 반대 의견 가운데 하나는 실제 운영·배포 경험의 부족인데, 이는 사람들이 쓸 수 있는 구현이 있어야 쌓이는 경험이라는 점에서 닭과 달걀의 문제를 안고 있다. 계약이 다음 표결에 다시 오를 때 같은 지적이 되풀이되지 않으려면, 역설적으로 지금의 실험적 구현이 유지되는 편이 그 경험을 축적하는 데 유리하다.

SOURCE · HACKER NEWS
원문 전체 보기 → https://train-it.eu/blog/cpp26-contracts-the-ballot-result/
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기 →
처리 중...