C++26 부결

요약

C++26 국제 표준 최종안이 ISO 각국 표준 기구 투표에서 처음으로 부결됐습니다.

C++ 표준 위원회(WG21) 위원이자 독일 표결에 참여하는 안드레아스 페르티히가 쓴 글입니다. 형식적 절차로 여겨졌던 10월 23일 투표가 승인 기준인 3분의 2 찬성을 넘지 못하자, 그 배경과 남은 선택지를 정리했습니다.

왜 중요한가

C++ 역사에서 국제 표준 최종안(DIS)이 부결된 첫 사례라서, 다음 표준이 언제 나올지 알 수 없게 됐습니다.
각국 기구는 새 정보나 절차상 오류가 있을 때만 반대해 왔는데, 필자는 이번 표결로 그 관행이 깨졌다고 봤습니다.
어느 길을 택해도 표준이 늦어지고, 필자는 C++29 작업에도 영향이 갈 가능성이 크다고 했습니다.

핵심 내용

각국 의견서는 주로 계약(Contracts, 함수의 사전·사후 조건을 코드에 적는 기능)이 아직 덜 됐다고 지적했습니다.
WG21은 2026년 3월 계약을 넣은 초안을 큰 표 차로 승인했고, 필자는 반대 측 논거가 새 정보가 아니라고 반박했습니다.
ISO 절차상 수정 최종안 제출, 위원회 초안 단계로 복귀, 기술 명세 발행, 프로젝트 취소 가운데 하나를 골라야 합니다.
C++26을 버리고 C++29로 넘어가면 이미 승인된 기능마다 논문과 지지자가 다시 필요합니다.
필자는 진 쪽이 결과에 승복하지 않아 신뢰가 흔들렸다며, 11월 16일 회의의 최우선 과제는 교착 상태를 푸는 일이라고 했습니다.

HN 반응

고신뢰성 C++을 쓴다는 이용자들은 계약이 C++20 콘셉트와 constexpr로 이미 할 수 있는 일을 표준화하는 데 그친다고 봤습니다.
토론은 국방 소프트웨어 언어로 번져, Ada가 더 맞았다는 주장과 당시엔 C++ 말고 현실적인 선택지가 적었다는 반론이 맞섰습니다.

30개 표시 · 전체 356개

jandrewrogers1일 전 HN

고신뢰성 C++를 쓰지만 표준화 과정과는 완전히 무관한 사람으로서, C++ Contracts의 문제점이 눈에 들어옵니다. 특히 C++20 concepts가 나온 뒤로는, 이 기능이 실제 코드베이스에서 누군가가 겪는 문제를 해결해 주는지조차 분명하지 않습니다.

이미 고신뢰성 C++를 써 왔다면 이득이 얼마나 되는지 가늠하기 어렵습니다. 고신뢰성 C++를 쓰지 않았다면, 이미 쓸 수 있었던 고신뢰성 C++의 표준 관용구를 아주 조금 더 비용을 들여 쓰는 것과 비교해 아낄 수 있는 게 거의 없습니다. 좁은 범위에서 표현 방식을 표준화해 주긴 합니다만, 그 대가로 얻는 이득은 미미해 보입니다.

C++ Contracts가 내놓는 대부분은 constexpr과 C++20 Concepts로 이미 할 수 있는 것들을 섞어 놓은 수준입니다. 저는 신뢰성 기능을 좋아하지만, 이미 신뢰성 기능을 쓰고 있다면 지금 나온 형태의 이 기능은 꽤 쓸모없어 보입니다. 설득력 있는 표준이 되려면 기본으로 훨씬 더 깊은 보장을 제공해야 합니다. 게다가 컴파일러는 constexpr과 C++20 concepts를 조합한 대부분의 코드를 이미 꿰뚫어 볼 수 있고, 그 조합만으로도 표현력은 충분히 높습니다.

C++ Contracts는 지금의 표준 기능들이 생기기 훨씬 전에 설계된 기능처럼 보입니다.
throwaway20371일 전 HN
```
    > high-reliability
```
C++에서 이 용어를 쓰는 건 처음 봅니다. 좀 더 설명해 주실 수 있습니까? 가능하다면 이를 명확하게 보여 주는 짧은 코드 예시도 보여 주실 수 있습니까?
zaphirplane1일 전 HN

구글에서 검색하면 상위 두 결과가 이 게시물이랑 이 기사예요.
Rexxar1일 전 HN

구글은 새 콘텐츠, 특히 HN처럼 참조가 아주 많고 활발한 사이트의 콘텐츠에 엄청난 우선순위를 줘요. 그러니 생각만큼 큰 의미는 없을 거예요.
Maxatar1일 전 HN

최근 HN에 올라와서 댓글에도 나오는 기술 용어를 여러 개 검색해 봐도 HN이 첫 페이지에 안 뜨는걸요. 첫 두 개 결과는 말할 것도 없고요.
arein31일 전 HN

방위 소프트웨어에서 쓰는 규칙 집합입니다. 인터넷에서 찾아볼 수 있습니다.
weitendorf1일 전 HN

아마 https://en.wikipedia.org/wiki/High_Integrity_C%2B%2B 를 말씀하시는 것 같습니다.

저는 제가 생각하는 "고신뢰성" C++(방어적 프로그래밍을 하고, 불변 조건·오류 상황·의도한 사용법을 명시적으로 드러내는 C++)가 일반 C++와 어떻게 다른지 설명하는 댓글을 썼습니다. 제 생각에 이는 결국 요즘의 "구글/핀테크 스타일 C++"로 귀결되고, 이는 방위·자동차 분야와는 개발 문화도 생태계도 다릅니다.
fpoling1일 전 HN

가장 큰 갈림길은 예외를 쓰지 않고, 메모리가 부족하면 abort로 처리하느냐입니다. 프로그래밍 스타일이 그만큼 크게 달라져서 다른 언어처럼 느껴질 정도입니다.
NSUserDefaults1일 전 HN

예를 들어 실패한 F-35 프로젝트가 그걸 썼죠. 기본적으로 안전한 언어를 쓰는 것에 비하면 허세 같고 위험해 보여요.
Cthulhu_1일 전 HN

그럼 어떤 언어를 제안하시나요?

(미리 말해 두자면 "Rust"라고 하실 거라면, Rust는 최근까지 없었고 F-35 프로젝트는 93년에 시작됐어요. 이런 프로젝트는 수십 년에 걸치는데, 그만큼 오래가는 프로그래밍 언어는 몇 개 안 되거든요)
LiamPowell1일 전 HN

너무나 뻔한 답은 Ada죠. 국방부가 의뢰해서 만든 언어이고 F-22에도 쓰였으니까요.
fpoling1일 전 HN

국방부가 더 큰 C++ 프로그래머 풀을 활용하려다 보니, 고신뢰성 코드를 쓰도록 훈련받지 않은 사람들도 많이 들어온 건 아닐까 싶네요.
tialaramex1일 전 HN

1993년의 C++는 표준도 없던, "뭐, 그냥 알아서 해" 식 언어였어요.

비야네의 2005년 JSF 규칙은 "직원은 손을 씻어야 함"이라는 안내문과 효과가 똑같아요. 최저임금 직원이 안내문을 안 지켜서 식중독이 생겼다고 수십억 달러짜리 패스트푸드 체인 탓은 아니잖아요. 안내문은 붙여 놨으니까요!
pjmlp1일 전 HN

그분은 그 규칙이 있었는데도 F-35가 겪은 항공전자 버그가 얼마나 많았는지는 늘 빼놓더라고요.
SolarNet1일 전 HN

Ada는 Rust보다 훨씬 안전합니다(메모리 할당 같은 엣지 케이스 문제는 제외하고, 일상적인 애플리케이션 프로그래밍에서는 그렇습니다). 게다가 당시에도 이미 존재했고, 항공 분야의 업계 표준이었습니다(그럴 만한 이유가 있었죠). Ada를 위한 교육 과정과 인력 양성 체계도 통째로 갖춰져 있었습니다.

보잉을 비롯한 방위산업체들이 Ada를 버린 건 장부상으로는 C++ 프로그래머가 더 쌌기 때문입니다(실력 좋은 C++ 엔지니어가 오히려 더 비싸다는 건 모르거나 신경 쓰지 않았죠).
cestith1일 전 HN

지금 제 동료 중 한 명이 군용기 탑재 시스템을 개발했습니다. 그에게 들은 이야기로는, 자기가 맡았던 항공기들은 핵심 시스템이 Ada였고 그 밖의 시스템은 C++일 수 있었다고 합니다.
amelius1일 전 HN

기본적으로 안전한 언어와 비교하면.

이 말도 허세처럼 들리는데요...
NSUserDefaults1일 전 HN

그런 언어가 없다고 생각하시거나, 적어도 C++보다 나은 언어가 없다고 생각하시는 건가요? 저도 아직은 C++가 좀 좋아요... 게임에서는요. 그래도 전투기에 넣는 건 절대 못 하죠, 제발요.
fps-hero1일 전 HN

논란을 일으키려는 건 아니니 사실만 이야기하겠습니다. F-35는 90년대에 설계된 시험 항공기가 구현된 결과물입니다. 그 시대의 소프트웨어는 대체로 싱글 스레드였고, 하드웨어는 두말할 것도 없었습니다. 또 당시 최신 최고 사양의 하드웨어를 쓰지 않고, 그 십 년 안에서도 한참 전으로 거슬러 올라가는 하드웨어를 쓰는, 검증된 비행 플랫폼을 택했습니다. 그래서 성능은 매우 부족했고 메모리 제약도 빡빡했습니다.

당시 소프트웨어를 만들 때 정당한 선택지는 사실상 Ada뿐이었을 텐데, Ada는 그 용도에 맞춰 만들어졌는데도 어째서인지 자리를 잡지 못했습니다. 그 시절 C++는 새로 뜨는 언어였고, 인기가 있었고, 아키텍처 문제를 해결해 주었으며, 이를테면 Java와 달리 성능도 좋았습니다.

"나라면 C++는 절대 안 쓴다"고 말하는 건 꽤 순진한 소리입니다. 그 시절 C++ 프로그래머들은 Fortran이나 COBOL을 똑같은 수준의 경멸로 바라봤을 겁니다. 우리는 더 나은 선택지가 있는 시대에 살고 있고, 곧 다가올 코드 이후의 미래를 맞이할 수 있어서 운이 좋습니다.
tialaramex1일 전 HN

당시 소프트웨어를 만들 때 정당한 선택지는 달리 ADA뿐이었을 것입니다

이런 작업에는 Ada가 20년 전의 C++보다 훨씬 더 합리적입니다.
bluGill1일 전 HN

Ada도 말이 안 됐어요. 아무도 배우고 싶어 하지 않았거든요.
pjmlp1일 전 HN

아니요, 배우고 싶어 했습니다. 가장 큰 걸림돌은 컴파일러 가격과 UNIX 워크스테이션 의존이었습니다. UNIX 워크스테이션에서는 이미 깔려 있던 C와 C++에 더해 Ada 컴파일러는 별도로 사야 하는 추가 품목이었으니까요.

에이다코어가 GNAT을 커뮤니티에 제공하기 전까지는 감당할 만한 가격의 컴파일러가 없었습니다.

그런데도 컴파일러를 파는 업체 6곳이 먹고살 만한 사업은 지금도 남아 있습니다.
Maxatar1일 전 HN

아니요, 아무도 배우고 싶어 하지 않았던 게 아니라, 당시에는 Ada 개발자가 C++ 개발자보다 훨씬 비쌌고 기업들이 그 돈을 내기 싫어했던 겁니다.
SolarNet1일 전 HN

컴퓨터 공학을 가르치는 학교들, 공인된 대학들에서 Ada를 집중적으로 가르쳤습니다(제가 다닌 곳에서는 프로그래밍 언어 입문 실습 3개 중 하나로 C++, 파이썬과 나란히 있었고, 전 과정에서 쓸 수 있었습니다). 이런 학교 중 일부는 졸업생의 3분의 1이 Ada 일자리를 얻었습니다. 안정적이고 보수도 좋은 일자리였으니까요.

그러다 업계가 C++로 갈아탔습니다. 국방부의 강제가 아니라, 보잉 같은 기업들이 C++ 개발자를 써서 엔지니어 급여를 3분의 1에서 2분의 1 줄이려 했기 때문입니다(졸업생 통계로 Ada 개발자의 초봉은 9만~14만 달러, C++ 개발자의 초봉은 6만~18만 달러였습니다). 물론 결국 실력 좋은 C++ 개발자가 예전의 Ada 개발자보다 더 비싸다는 걸 깨달았지만요. 그렇다고 실력 좋은 C++ 개발자를 굳이 뽑으려 한 것도 아니었고요.
NSUserDefaults1일 전 HN

"이 새 전투기에는 최신 유행하는 걸 써 보자"라는 말을 들으니 상황이 좀 이해가 가네요.

요즘으로 치면 그냥 "멋있다"는 이유로 화성 탐사선을 바이브코딩하는 거나 마찬가지죠.
drysine1일 전 HN

그것[C++]은 아키텍처 문제를 해결해 주고 있었습니다

무슨 뜻입니까?
AnimalMuppet1일 전 HN

F-35 프로젝트가 어떤 면에서 실패였다는 거죠?
pjmlp1일 전 HN

항공전자 문제와 그 밖의 제작상 결함 때문에 불어난 총비용 때문입니다.
rerdavies1일 전 HN

그리고 프로젝트 요구 사항을 충족하지 못한 것도요.

예: https://responsiblestatecraft.org/f-35-failure/
weitendorf1일 전 HN
원 댓글 작성자가 구글이나 Envoy proxy 같은 프로젝트에서 볼 수 있는, 기본적으로 모범 사례를 따르는 방어적 C++를 말하는 것이고, 다른 답글은 아마 high integrity C++ [0]와 헷갈린 것이라고 가정하면,

여기 컴파일 타임 타입 단언(static_assert, C++가 이미 할 수 있는 것), 런타임 오류(CHECK, 잘못된 상태와 불변 조건을 명시적으로 처리하기 위한 구글/abseil의 표준 관행), 테스트/개발용 검사(방어적 프로그래밍, 말하자면 인라인 테스트), 래퍼/오류 처리 타입을 써서 contracts에 기대할 만한 일을 하는 예시가 있습니다.
```
  template <typename T>
  absl::StatusOr<double> Percentile(std::span<const T> sorted_values, double p) {
    static_assert(std::is_arithmetic_v<T>, "T must be numeric");
    CHECK(p >= 0.0 && p <= 100.0) << "p out of range: " << p;
    DCHECK(std::ranges::is_sorted(sorted_values)) << "input not sorted";

if (sorted_values.empty()) {
      return absl::InvalidArgumentError("empty input");
    }

const std::size_t last = sorted_values.size() - 1;
    const double rank = p / 100.0 * last;
    const auto lo = static_cast<std::size_t>(rank);
    const std::size_t hi = std::min(lo + 1, last);
    const double result = std::lerp<double>(sorted_values[lo], sorted_values[hi],
                                          rank - lo);

DCHECK(result >= sorted_values.front() && result <= sorted_values.back());
    return result;
  }
```
(함수 구현은 AI가 쓴 것으로, contract와 인접한 비구현 코드를 보여 주는 뼈대로만 필요했습니다)

이런 스타일의 C++를 접하고 쓰는 법을 익히기 전에는 C++가 사실상 다른 언어처럼 느껴졌습니다. C++ 표준 위원회와 언어 설계자들은 대부분의 빅테크·금융권 회사와는 우선순위도 개발자 문화도 다르다고들 하는데, 제 생각에 그 이유는 구글 등에서 나온 기능과 도구[1]를 알고는 있어도 지금 하는 일상 업무에서는 쓰지 않으면서, 그 기능을 C++ 핵심 툴체인에 넣고 싶어 하기 때문이라고 봅니다.

제 생각에 그들이 추가하려는 것 가운데 상당수는 이미 서드파티 도구로 "해결"되어 있습니다. 그런데 어떤 이유에서인지 그 도구들을 일상 업무에 쓰지 않다 보니, 때로는 지나치게 복잡하거나 엉뚱한 문제를 푸는 언어 기능을 내놓습니다. 그런 문제를 푸는 서드파티 도구를 이미 정기적으로 쓰고 계시다면 직관적으로 이해되실 겁니다.

제가 여기서 잘못 해석하고 있을 수도 있으니, 뻔한 얘기이거나 원 댓글 작성자가 말한 "고신뢰성"이 그게 아니었다면 죄송합니다.

[0] https://en.wikipedia.org/wiki/High_Integrity_C%2B%2B

[1] https://abseil.io/about/ C++를 덜 정신 나간 언어로 만들어 주는 여러 서드파티 방법 중 하나

Hacker News에서 보기 ↗