1979년 한 연구원이 분산 시스템을 만들다 부딪힌 문제를 해결하려고 C 언어에 클래스를 얹었다. 그 임시방편은 47년 뒤 전 세계 1,600만 명이 쓰는 언어가 되어, 운영체제와 게임 엔진과 금융 거래 시스템과 인공지능 연산의 바닥을 떠받치고 있다. 두 번의 겨울을 거치고도 살아남은 이 언어의 역사를 탄생부터 2026년 최신 표준까지 추적한다.
C++가 어디에 쓰이느냐는 질문에 가장 정확한 답은 "거의 모든 곳"이다. 스마트폰 카메라의 이미지 처리, 자동차의 제어 장치, 풍력 터빈과 발전 설비의 제어 소프트웨어, 밥솥의 펌웨어, 할리우드 영화의 시각효과 렌더러, 게임 엔진, 증권사의 주문 체결 시스템, 웹 브라우저의 렌더링 엔진, 그리고 데이터베이스와 운영체제 커널의 상당 부분이 C++로 쓰여 있다. 지구 인구의 절반 이상이 매일 자기도 모르게 C++ 코드를 실행시킨다.
인공지능 시대에도 사정은 같다. 겉에서 보이는 언어는 파이썬이지만, 파이썬 코드가 호출하는 순간 실제 연산을 수행하는 것은 CUDA(Compute Unified Device Architecture) 라이브러리와 딥러닝 프레임워크의 코어, 즉 고도로 최적화된 C++ 코드다. 표면의 언어와 바닥의 언어가 분업하는 구조에서 C++는 일관되게 바닥을 맡아 왔다.
이런 언어가 어떻게 만들어졌는지를 따라가 보면, 흔히 상상하는 그림과 정반대의 역사가 나온다. 대기업의 전략 사업도, 천재의 완성된 설계도 아니었다. 시작은 한 신참 연구원이 자기 연구를 진행하기 위해 만든 도구였고, 마케팅 예산은 사실상 없었으며, 회사는 이 프로젝트의 가치를 끝까지 제대로 이해하지 못했다. 본 보고서는 그 47년의 궤적을 살펴본다.
1970년대 말의 프로그래밍 환경은 지금과 비교하면 원시적이었다. 문법 강조도, 자동 완성도, 코드 탐색 기능도 없었다. 일부 컴퓨터에는 줄 단위 편집기밖에 없어서 한 줄에서 글자 하나를 고치려면 그 줄 전체를 다시 입력해야 했다. 취미 프로그래머는 BASIC(Beginner's All-purpose Symbolic Instruction Code)을 썼고, 성능이 필요한 작업은 칩 종류마다 다른 어셈블리 언어로 해야 했다. 그러나 컴퓨터의 주소 공간이 커지면서 소프트웨어도 커졌고, 더 크고 복잡한 프로그램을 감당할 새 언어들이 필요해지던 시점이었다.
이 무렵 덴마크 출신의 젊은 연구자 비야네 스트롭스트룹이 영국 케임브리지 대학에서 분산 시스템 연구로 박사 학위를 마치고 미국 뉴저지의 AT&T(American Telephone and Telegraph) 벨 연구소에 합류했다. 당시 AT&T는 미국 전화망을 사실상 독점한 거대 기업이었다. 안정적으로 보장된 수익의 일부를 떼어 벨 연구소를 운영했고, '전화 서비스 개선'이라는 사명을 매우 넓게 해석했기 때문에 연구자들은 사실상 원하는 주제를 자유롭게 팔 수 있었다. 트랜지스터, 유닉스(Unix) 운영체제, C 언어, 정보 이론이 모두 이곳에서 나왔다. 컴퓨팅 분야에서 무언가를 하고 싶다면 그곳이 바로 '있어야 할 곳'이었다.
스트롭스트룹이 잡은 주제는 유닉스 커널을 모듈로 분해해 네트워크로 분산시키는 시스템이었다. 그런데 설계를 코드로 옮기려는 순간 벽에 부딪혔다. 이 작업에는 상충하는 두 가지 능력이 동시에 필요했다.
첫째, 하드웨어를 직접 다루는 능력. 디바이스 드라이버, 네트워크 인터페이스, 메모리 관리자, 프로세스 스케줄러를 짜려면 기계를 바닥까지 제어할 수 있어야 한다. 둘째, 커지는 프로그램에 구조를 부여하는 능력. "이것은 하나의 모듈이고, 저것은 통신 채널이며, 이 부분이 저 부분과 이런 규약으로 대화한다"라고 코드 안에서 명시적으로 말할 수 있어야 한다. 메모리를 공유하지 않는 분산 환경에서는 포인터가 뒤엉킨 코드로는 아무것도 표현할 수 없기 때문이다.
첫째 요구의 답은 가까이 있었다. C 언어를 만든 데니스 리치(Dennis Ritchie)와 「The C Programming Language」의 공저자 브라이언 커니핸(Brian Kernighan)이 같은 부서의 복도 건너편에 있었다. C는 필요할 때는 기계의 모든 것을 제어할 수 있으면서도, 원할 때는 기계의 세부 사항을 잊을 수 있게 해 주는, 시스템 프로그래밍을 위해 탁월하게 설계된 언어였다.
둘째 요구의 답은 스트롭스트룹이 유학 시절 사용했던 시뮬라(Simula)였다. 1960년대 노르웨이에서 올레요한 달(Ole-Johan Dahl)과 크리스텐 뉘고르(Kristen Nygaard)가 만든 시뮬라는 최초의 객체지향 언어로, 클래스(class)와 클래스 계층, 강한 타입 안전성을 갖추고 있었다. 거대하고 무정형인 프로그램에 질서와 구조를 부여하는 데 이상적인 도구였다. 문제는 속도였다. 시뮬라는 너무 느렸고 메모리를 너무 많이 썼다. 연구용으로는 우아했지만 실전 시스템에는 쓸 수 없었다.
C는 모든 배선과 배관에 직접 손이 닿는 공구함이고, 시뮬라는 초고층 건물을 지을 때 쓰는 설계도면 체계다. 공구함만으로는 단독주택은 지어도 100층 건물은 못 짓는다. 어디서 무엇이 무엇과 연결되는지 사람의 머리로 감당이 안 되기 때문이다. 반대로 설계도면 체계만 있고 공구가 없으면 도면은 아름답지만 공사가 한없이 느려진다. C++의 기획은 단순했다. 설계도면 체계(시뮬라의 클래스)를 공구함(C) 위에 얹어, 도면대로 짓되 필요하면 배선 하나까지 직접 만질 수 있는 건축 방식을 만드는 것이다.
1979년 스트롭스트룹은 시뮬라의 핵심 기능을 C에 이식하는 작업에 착수했고, 그 결과물을 그대로 'C with Classes(클래스가 붙은 C)'라고 불렀다. 초기 구현은 독립 컴파일러가 아니라 C 코드로 변환해 주는 전처리기(preprocessor)였다. 이후 그는 거의 40년에 걸쳐 "시뮬라와 C가 할 수 있는 모든 것을 한 언어로"라는 목표를 추구하게 되는데, 훗날 그는 바로 이 끝나지 않는 도전이 C++를 성공시킨 원동력이었다고 회고했다.
C with Classes는 사내에서 사용자를 얻으며 '중간 정도의 성공'을 거뒀다. 그러나 몇 년 뒤 스트롭스트룹은 냉정한 결론에 도달했다. 이 언어는 C에서 출발한 도약의 폭이 충분히 크지 않아서, 영원히 중간 정도의 성공에 머무를 운명이라는 것이었다. 선택지는 둘이었다. 접거나, 훨씬 좋게 만들거나. 그는 후자를 골랐고 약 1년을 들여 제대로 된 컴파일러를 만들면서 언어 자체를 대폭 개선했다. 컴파일러를 직접 가진 사람만이 할 수 있는 방식의 개선이었다.
이 컴파일러가 'Cfront'다. Cfront는 어휘 분석, 구문 분석, 타입 검사, 트리 표현 생성과 최적화까지 수행하는 완전한 컴파일러 전단부였지만, 최종 출력은 기계어가 아니라 C 코드였다. 이 설계는 전략적으로 결정적이었다. C 컴파일러는 이미 모든 기계에 있었으므로, C++를 쓰고 싶은 조직은 새 도구 체계나 새 라이브러리 기반 시설에 투자할 필요 없이 기존 C 환경 위에서 바로 시작할 수 있었다. 낮은 진입 비용은 초기 확산의 핵심 조건이 됐다.
1983년에는 이름도 바꿨다. 'C with Classes'는 낡은 느낌이었고 'Cfront'는 구현물의 이름일 뿐이었다. 주변에서 받은 20여 개의 후보 중 채택된 것이 동료 릭 마스치티(Rick Mascitti)가 제안한 'C++'였다. ++는 C 언어에서 값을 1 증가시키는 연산자이므로, C++는 "C의 증분(增分)", 곧 C를 한 단계 키운 언어라는 의미가 된다. 엄밀히 따지면 연산자의 의미상 ++C가 더 정확하다는 농담이 따라붙지만, 색인을 만들고 언어를 지칭해야 할 사람들을 배려해 C++가 되었다고 전해진다.
1985년 10월 C++의 첫 상용 릴리스가 나왔고, 같은 시기 스트롭스트룹의 교과서 「The C++ Programming Language」 초판이 출간됐다. 당시 막 통신 시장 규제 완화와 회사 분할을 겪은 AT&T는 컴퓨터·소프트웨어 사업 진출을 선언하고 C++ 컴파일러 판매도 시도했으나, 하드웨어 사업 자체가 부진하면서 이 시도는 상업적으로 성공하지 못했다. 역설적으로 그 실패가 언어에는 약이 됐다. 회사가 큰 기대를 걸지 않은 덕분에 초기 구현을 테이프 실비 수준의 헐값에 외부로 배포할 수 있었고, 개발팀은 간섭 없이 일할 수 있었다.
투자 규모는 놀라울 만큼 작았다. 언어와 컴파일러를 합쳐 전담 인력이 다섯 명 안팎이었고, 초창기에는 문서 작성, 컴파일러 개발, 언어 설계, 사용자 지원 데스크 역할을 한 사람이 전부 겸했다. 광고 캠페인도, 자금을 대는 후원 기업도 없었다.
그런데도 언어는 퍼졌다. 경로는 셋이었다. 첫째는 사내 수요다. AT&T 내부 개발 조직들이 C++로 더 작은 팀이 더 좋은 코드를 더 빨리 쓴다는 사실을 입증하면서 언어는 생존에 필요한 최소한의 지원을 확보했다. 둘째는 당시의 인터넷 전신인 유즈넷(Usenet)이다. 프로그래밍 언어별 게시판에서 정보가 오갔다. 셋째는 전화번호부만큼 두꺼웠던 컴퓨터 잡지들로, 잡지에 실린 C++ 기사를 보고 "우리도 한번 써 보자"라고 결심하는 개발자들이 늘었다. 여기에 개발자 본인이 불러 주는 곳이면 어디든 가서 강연하는 끈질긴 전도 활동이 더해졌다. 어느 회고의 표현을 빌리면, "하룻밤 사이의 성공에는 수십 년이 걸린다."
성장에는 진통도 있었다. 다중 상속 등 대형 기능을 추가한 1989년의 릴리스 2.0은 오랜 신뢰성 문제를 정리한 사실상의 상업용 릴리스였는데, 출하 직후 핵심 신기능에서 심각한 결함이 발견돼 며칠 만에 수정판을 급히 만들어 배포하는 소동을 겪었다. 한번 현장에 깔린 컴파일러의 결함은 사실상 회수가 불가능했고, 이미 작성된 코드와의 호환성은 무엇보다 무거운 제약이었다. 언어가 커질수록 "작은 비호환 변경 하나가 수십만 명을 화나게 한다"는 현실이 분명해지고 있었다.
1990년 무렵 C++는 단일 기업의 도구를 넘어서고 있었다. 볼랜드(Borland), 마이크로소프트(Microsoft), IBM(International Business Machines), 선 마이크로시스템즈(Sun Microsystems) 등이 각자 컴파일러를 만들었는데, 문제는 이들이 서로 미묘하게 달랐다는 점이다. 특히 템플릿(template) 같은 신기능은 회사마다 구현 방식과 동작이 갈렸다. 한 컴파일러에서 짠 코드가 다른 컴파일러에서 컴파일되지 않는 일이 흔해졌고, 각 회사가 "우리가 더 좋게 만들겠다"며 독자 확장을 거듭하면 언어가 방언으로 쪼개져 붕괴하리라는 우려가 커졌다.
해법은 공적 표준화였다. 주요 컴퓨터 제조사들은 C++가 특정 기업(AT&T)의 통제 아래 있는 한 본격적으로 채택할 수 없다는 입장이었고, 설계자 자신은 "아직 실험 중이라 이르다"며 버텼지만 결국 설득됐다. 표준의 기초 문서가 될 주석 달린 참조 설명서, 통칭 ARM(The Annotated C++ Reference Manual, 1990)이 집필됐고, ANSI(American National Standards Institute, 미국표준협회) 산하 위원회가 1989~1990년에 출범했으며 곧 ISO(International Organization for Standardization, 국제표준화기구) 차원의 작업으로 확대됐다.
표준이란 무엇인가. 프로그래밍 언어의 표준은 코드를 쓰는 사람과 컴파일러를 만드는 사람 사이의 계약서다. 표준에 부합하는 코드를 쓰면 어떤 회사의 컴파일러에서든 같은 의미로 동작한다는 보증이다. 이 보증이 있어야 기업은 특정 공급사에 종속될 걱정 없이 수백만 줄의 코드를 그 언어로 작성할 수 있다. C++가 '서부 개척 시대'처럼 방언으로 갈라지지 않고 기간 시스템의 언어가 될 수 있었던 결정적 기반이 표준화였다는 데에는 이견이 거의 없다.
표준화 위원회는 초기에 전 세계 주요 기업과 자원자 100~120명 규모였다. 표결과 합의로 굴러가는 이 체제는 더디고 때로 우스꽝스러웠지만(국가 대표 자격이 사실상 자기 추천이던 시절도 있었다), 여러 이해관계자가 공존하는 언어에는 불완전한 합의가 한 기업의 독단보다 낫다는 것이 시간이 지나며 입증됐다.
표준화 작업이 마무리 단계로 가던 1993~1994년, 일정표를 뒤흔드는 사건이 일어났다. 러시아 출신 수학자이자 휴렛팩커드(HP, Hewlett-Packard) 연구소 소속이던 알렉산더 스테파노프(Alexander Stepanov)가 동료 멍 리(Meng Lee)와 함께 만든 라이브러리, 훗날 STL(Standard Template Library, 표준 템플릿 라이브러리)이라 불리게 될 작업물이 위원회에 소개된 것이다.
당시 C++에는 공식 표준 라이브러리가 없었다. 회사마다, 팀마다 자기만의 배열 클래스, 리스트, 트리, 정렬 함수를 만들어 썼고 어느 것이 나은지 비교조차 어려웠다. 스테파노프의 접근은 차원이 달랐다. 그는 1970년대부터 "알고리즘은 수학적 구조와 결부되어 있으며, 자료구조에 대해 형식적으로 추론할 수 있는 라이브러리를 만들 수 있다"는 신념으로 제네릭 프로그래밍(generic programming)을 연구해 온 인물이었다. 덧셈과 곱셈, 최솟값과 최댓값 연산이 모두 결합법칙을 만족한다는 단순한 관찰에서 출발해, 하나의 알고리즘이 적용 가능한 모든 자료구조 위에서 동작하도록 라이브러리 전체를 설계한 것이다.
알고리즘이 가전제품이고 자료구조가 건물의 전기 설비라고 하자. STL 이전의 세계는 제품마다 전용 플러그를, 건물마다 전용 콘센트를 만들던 세계다. 알고리즘 m개를 자료구조 n개에서 쓰려면 m×n개의 조합을 일일이 구현해야 한다. STL은 그 사이에 반복자(iterator)라는 표준 콘센트 규격을 끼워 넣었다. 알고리즘은 반복자에만 맞추면 되고 자료구조도 반복자만 제공하면 되므로, 필요한 구현은 m+n개로 줄어든다. 정렬 알고리즘 하나가 배열에서도, 사용자가 만든 어떤 컨테이너에서도 그대로 동작하는 이유다.
위원회의 첫 반응은 "훌륭하지만 너무 늦었고 너무 크다"였다. 일정표가 있었기 때문이다. 그러나 위원회 내부의 지지자들이 발표 기회를 만들었고, 그 발표는 기립 박수를 받을 만큼 강렬했다. 정작 제안자 본인은 채택 가능성을 0으로 봤고, 당시 소프트웨어 업계의 지배자였던 마이크로소프트를 포함한 주요 라이브러리 업체들은 "너무 복잡하고 구현이 어렵다"며 반대했다. 그럼에도 1994년 표결에서 위원회의 압도적 다수가 찬성해 STL은 표준에 편입됐다. 언어 설계자가 필요한 언어 기능을 보강해 주고 과도한 의욕을 다듬어 주는 협업이 그 과정을 떠받쳤다.
결과적으로 STL은 혼돈에 질서를 부여했다. 컨테이너를 정의하는 한 가지 방법, 알고리즘을 정의하는 한 가지 방법이 생기자 난립하던 사설 라이브러리들은 경쟁 자체가 무의미해졌다. 많은 평가자들은 STL이 사람들의 프로그래밍 방식에 미친 영향이 C++라는 언어의 존재 자체에 못지않다고 본다. STL이 C++를 다음 천 년으로 실어 날랐다는 표현도 과장이 아니었다.
1997년 11월 최종 표결을 거쳐 1998년 발효된 첫 국제표준, 통칭 C++98은 네임스페이스, 예외 처리, 템플릿, STL을 갖춘 언어를 확정했다. 이후 표준을 기준 삼아 출발한 도구들은 과거 방언들의 호환성 부담 없이 "언어가 의도된 대로" 사용될 수 있었고, 보수적인 대기업들도 안심하고 채택을 결정했다. 1990년대 말~2000년 무렵 C++는 사실상 모든 분야에 들어가 있었다. 대표적인 세 영역만 보자.
거대과학. 유럽입자물리연구소(CERN, Conseil Européen pour la Recherche Nucléaire)를 비롯한 고에너지 물리학계는 1990년대에 수십 년 된 포트란(Fortran) 기반 체계를 C++로 전환했다. 입자 충돌 실험이 쏟아내는 막대한 데이터의 분석, 가속기 공정 제어, 시각화 소프트웨어가 모두 C++의 강점과 맞아떨어졌고, 분석 프레임워크들이 C++로 재발명됐다.
게임. 그래픽 카드가 저수준 처리를 흡수하면서 게임 개발자들은 어셈블리와 C에서 C++와 API(Application Programming Interface) 중심으로 올라왔다. 프레임마다 모든 CPU(Central Processing Unit) 사이클을 쥐어짜야 하는 고사양 게임에서, 추상화를 제공하면서도 실행 시점의 비용을 통제할 수 있는 C++는 사실상 유일한 선택지였다. 오늘날에도 고성능 게임 엔진 진영은 C++가 지배한다.
금융. 객장에서 사람이 소리치며 주문하던 거래가 2000년대 초 전산화되면서 초단타매매(HFT, High-Frequency Trading) 산업이 탄생했다. 이 세계에서는 마이크로초 단위의 지연 시간 차이가 경제성을 가른다. 코드 한 줄 한 줄을 수작업으로 미세 최적화하지 않고도 그런 지연 시간을 달성하게 해 주는 언어로 C++가 선택됐고, 주요 트레이딩 회사들은 현재까지도 수백 명의 개발자가 수백만 줄의 C++ 코드베이스에 연간 수만 건의 변경을 쌓는 규모로 이 언어를 쓴다.
2000년을 전후해 세 가지 흐름이 겹치며 C++는 정체를 넘어 쇠퇴 국면에 들어갔다. 이른바 'C++의 겨울'이다.
첫째, 닷컴 붕괴로 기술 산업 전반이 위축됐다. 둘째, 자바(Java)의 부상이다. 1995년 선 마이크로시스템즈가 내놓은 자바는 'C++의 복잡성에 대한 명시적 반작용'으로 설계된 언어였고, 객체지향의 이점을 더 단순한 형태로 제공한다는 메시지와 함께 막대한 마케팅이 투입됐다. "자바가 2년 안에 C++를 죽인다"는 식의 공언이 업계 임원들 사이에 돌았고, 실체를 모르면서도 "어쨌든 자바를 해야 한다"는 분위기가 형성됐다. 마이크로소프트도 2000년대 초 C#을 내놨다. 터보 파스칼(Turbo Pascal)을 만든 아네르스 하일스베르(Anders Hejlsberg)가 설계한 C#은, 비주얼 베이식(Visual Basic)의 생산성과 C++의 표현력을 한 언어에 담아 "프로토타입은 비주얼 베이식으로, 배포판은 C++로 두 번 짜는" 당시 기업 개발의 비효율을 해소하려는 시도였다.
셋째이자 구조적으로 가장 중요한 요인은 하드웨어였다. 당시 CPU 클럭 주파수는 몇 년마다 두 배로 뛰고 있었다. 소프트웨어가 비효율적이어도 1년만 기다리면 하드웨어가 해결해 주는 시대였고, "성능은 중요하지 않다, 기계가 알아서 빨라진다"는 사고가 언어 설계 전반에 퍼졌다. 비효율적인 언어들이 만개하기에 완벽한 환경이었고, 효율을 핵심 가치로 삼는 C++에는 최악의 환경이었다.
흥미로운 점은 이 시기를 통과한 관계자들이 '언어 전쟁'이라는 프레임 자체를 부정한다는 사실이다. C++ 진영과 C# 진영 모두에서, 각 언어는 서로 다른 종류의 프로그래밍과 결합해 각자의 자리를 차지하는 상호 보완적 존재이며, 기업용 응용을 C++로 짜는 것도 운영체제를 C#으로 짜는 것도 똑같이 부적합하다는 회고가 나온다. 모든 일에 최선인 단일 언어는 존재하지 않는다는 것이다. 자바와 C# 컴파일러의 상당 부분이 C++로 작성됐다는 사실은 이 분업 구조를 상징적으로 보여 준다.
2004~2005년, 50년간 지속되던 흐름이 갑자기 끝났다. CPU의 클럭 주파수 향상이 단일 코어의 전력·발열 한계에 부딪혀 멈춘 것이다. 제조사들은 코어 하나를 더 빠르게 만드는 대신 코어 여러 개를 칩에 싣는 방향으로 선회했고, 업계에서는 이 전환을 "공짜 점심은 끝났다(The Free Lunch Is Over)"라는 유명한 문구로 요약했다. 가만히 있어도 프로그램이 빨라지던 시대가 끝났으니, 이제 성능은 병렬 처리와 효율적인 언어로 직접 벌어야 한다는 선언이었다.
판이 뒤집혔다. 효율적인 언어에 대한 수요가 되살아났고, 화면 달린 컴퓨터보다 훨씬 수가 많은 임베디드 시스템 영역에서도 C++가 쓸 만한 수준으로 성숙해 있었다. 남은 문제는 C++ 자신이었다. 멀티코어 시대가 왔는데 당시 표준은 스레드(thread)라는 단어조차 언급하지 않았고, 표준화 리더십은 안주해 있다는 내부 비판을 받았다. "위원회는 듣고 있는가"라는 공개적 문제 제기가 표준화 공동체를 흔들었고, 동시성(concurrency)을 포함한 대수술이 시작됐다. 동시성 메모리 모델 설계에서는 자바의 모델을 가져오자는 안이 유력했으나, 그렇게 하면 자사 자바 구현의 속도가 반토막 난다는 대형 벤더들의 반대로 무산되어 2년을 더 들여 더 정교한 모델을 만들어야 했다. 다중 이해관계자 표준화의 비용과 편익을 동시에 보여 주는 일화다.
이 대수술의 결과가 2011년 발효된 C++11이다. 원래 2008년경 완성을 목표로 'C++0x'라 불렸으나 "이 기능만은 꼭 넣어야 한다"는 요구가 연쇄적으로 일정을 밀어내며 첫 표준 이후 13년 만에야 나왔다. 내용은 그 기다림에 값했다. 이동 의미론(move semantics), 람다(lambda) 표현식, auto 타입 추론, 범위 기반 반복문, 스마트 포인터, 컴파일 시점 계산을 여는 constexpr, 그리고 C 계열 언어 최초로 표준 차원에서 정식화된 스레딩과 메모리 모델까지. 문법은 같지만 문제를 사고하는 방식 자체가 달라져 "새 언어를 쓰는 기분"이라는 반응이 일반적이었고, 이때부터의 C++를 '현대 C++(Modern C++)'라고 부른다. 다른 언어로 떠났던 개발자들이 돌아오기 시작했고, 입자물리학계처럼 멀티코어 전환을 강제당하던 분야는 C++11이 기본 제공하는 도구들 덕에 데이터 처리 체계를 병렬 중심으로 재설계할 수 있었다.
13년 공백의 교훈으로 표준화 절차도 바뀌었다. 정해진 시각에 기차가 떠나고, 못 탄 기능은 기차를 세우는 게 아니라 다음 기차를 기다린다는 기차 모델(train model)이다. 2년 주기 주장과 절충해 3년 주기로 확정됐고, 이후 C++14(소규모 정비), C++17, C++20(콘셉트·레인지·코루틴·모듈 등 대형 릴리스), C++23이 한 번의 연착도 없이 출발했다. 업계는 더 이상 "다음 표준이 나오긴 하는가"를 궁금해하지 않게 됐다.
그러나 성공은 새로운 문제를 낳았다. 위원회가 커진 것이다. 초기 100여 명이던 참가자는 500명을 넘어섰다. 참여의 문이 넓어진 것은 건강함의 증거지만, 위원회에는 '공유지의 비극'의 변형이 작동한다. 기능 하나를 추가하는 것은 상대적으로 쉽고, 개별 제안은 대부분 그 자체로는 합리적이다. 문제는 합리적인 추가가 누적되면 언어 전체가 개념적으로 비대해진다는 점이다. 변수 초기화 방법이 수십 가지라는 자조, "끝은 어디인가"라는 질문, 언어 설계는 결국 거절하는 법을 아는 게임이라는 경구가 공동체 안에서 반복적으로 제기된다. 한번 추가한 기능은 호환성 때문에 사실상 제거할 수 없으므로, 이 긴장은 C++가 존속하는 한 계속될 구조적 숙제다.
2020년대 들어 C++는 첫 번째 겨울과는 성격이 다른 압력에 직면했다. 이번에는 마케팅이 아니라 보안 통계가 상대였다.
C와 C++는 프로그래머에게 메모리에 대한 직접적 권한을 준다. 배열 경계를 넘는 접근, 해제된 메모리 참조, 초기화되지 않은 변수 읽기를 언어가 막아 주지 않는다. 이런 실수가 만드는 취약점이 바로 메모리 안전성(memory safety) 문제이며, 마이크로소프트와 구글이 각각 자사 제품을 분석한 결과 심각한 보안 취약점의 약 70%가 메모리 안전성 결함에서 비롯됐다는 통계가 2019년을 전후해 공개되면서 논쟁에 불이 붙었다. 1988년의 모리스 웜부터 2014년의 하트블리드(Heartbleed)까지, 역사적 대형 보안 사고의 상당수가 이 범주에 속한다.
압력은 점차 공식화됐다. 2022년 11월 미국 NSA(National Security Agency, 국가안보국)가 메모리 안전 언어 사용을 권고하는 지침을 냈고, 2023년 말에는 CISA(Cybersecurity and Infrastructure Security Agency, 사이버안보·인프라보안청)와 파이브 아이즈(Five Eyes) 동맹국 기관들이 메모리 안전 로드맵을 요구하는 공동 문서를 냈다. 2024년 2월에는 미국 백악관 ONCD(Office of the National Cyber Director, 국가사이버국장실)가 보고서를 통해 메모리 안전 언어로의 전환을 산업계에 공개적으로 촉구했다. 명시적으로 거명된 '안전하지 않은 언어'가 C와 C++였다. 같은 시기, 소유권 검사로 메모리 오류 대부분을 컴파일 시점에 차단하는 러스트(Rust)가 시스템 프로그래밍의 대안으로 빠르게 성장하며, 자동차 브레이크 같은 안전 필수 시스템의 언어 선택을 두고 'C++의 두 번째 겨울'이라는 표현까지 등장했다.
표준이 계약서라면, UB(Undefined Behavior, 미정의 동작)는 계약서에 "이 경우 무슨 일이 일어나는지는 정하지 않는다"라고 비워 둔 조항이다. 초기화 안 한 변수를 읽거나 배열 끝을 넘어가면 무엇이든 일어날 수 있다 — 우연히 잘 돌아갈 수도, 멀리 떨어진 데이터가 조용히 깨질 수도, 공격자가 그 공란을 파고들어 임의의 코드를 실행할 수도 있다. 역사적으로 이 공란은 컴파일러가 최대한의 최적화를 하도록 허용하는 성능의 원천이었지만, 보안의 관점에서는 공격자에게 열어 둔 뒷문이었다. 최근 표준화 작업의 핵심은 이 공란들을 하나씩 "잘못이지만 결과는 예측 가능하고 진단 가능"한 조항으로 메워 가는 것이다.
이 압력에 대한 표준 차원의 응답이 2026년 3월 런던 회의에서 초안이 기술적으로 확정된 C++26이다(2025년 6월 소피아 회의에서 기능 동결, 정식 발간은 2026년 내 예정). 핵심은 두 갈래다.
첫째, 안전성. 초기화되지 않은 지역 변수를 읽는 행위가 더 이상 미정의 동작이 아니다. 대신 '오류 동작(EB, Erroneous Behavior)'이라는 새 범주가 도입되어, 잘못이긴 하되 결과가 구현이 정한 값으로 한정되고 진단이 권장되는 동작이 된다. 기존 코드를 재컴파일하는 것만으로 효과를 본다는 점이 중요하다. 또한 강화 모드(hardened mode)의 표준 라이브러리에서는 vector, string, span 등 핵심 타입의 흔한 경계 침범 오류가 미정의 동작에서 탐지 가능한 위반으로 바뀐다. 함수의 사전·사후 조건을 명시해 검사하는 계약(contracts) 기능도 들어왔다. 러스트 수준의 컴파일 시점 보증에는 못 미치지만, 수억 줄의 기존 코드를 다시 쓰지 않고 위험을 줄인다는 실용 노선이며, 차기 표준(C++29)을 향해서는 안전성 프로파일(profiles) 등 후속 작업이 진행 중이다.
둘째, 정적 리플렉션(static reflection). 프로그램 코드가 컴파일 시점에 프로그램 코드 자신을 들여다보고, 그 정보로 새 코드를 생성할 수 있게 하는 기능이다. 2025년 6월 채택 당시 회의장에서 박수가 터져 나왔고, 표준화 역사상 가장 큰 단일 전환점이라는 평가와 함께 "통째로 새 언어"라는 촌평이 회자됐다. 지금까지 외부 코드 생성기나 매크로 곡예에 의존하던 직렬화, 객체-데이터 매핑, 인터페이스 바인딩 같은 작업이 언어 안에서 해결될 수 있어, 향후 10년의 C++ 사용 방식을 규정할 기능으로 꼽힌다. 주요 컴파일러들은 표준 발간 전부터 구현을 진행해 상당 부분을 이미 갖춘 상태다.
겨울 담론과 별개로, 사용 통계는 뚜렷한 성장을 보여 준다. 개발자 조사 기관 슬래시데이터(SlashData)에 따르면 전 세계 개발자 수는 2022년 약 3,100만 명에서 2025년 약 4,720만 명으로 늘었는데, 같은 기간 C++ 개발자는 940만 명에서 1,630만 명으로 늘어 러스트와 함께 증가율 기준 가장 빠르게 성장한 주요 언어로 꼽혔다. 현재의 C++ 개발자 수는 4년 전 1위 언어의 전체 사용자 수보다 많다.
성장의 구조적 배경으로 가장 자주 거론되는 것은 와트당 성능(performance per watt)이다. 인공지능 데이터센터의 제약이 GPU(Graphics Processing Unit) 수량에서 전력 공급량으로 옮겨 가면서, 같은 전력으로 더 많은 연산을 뽑아내는 언어의 가치가 구조적으로 커졌다. 풀어야 할 문제의 크기가 하드웨어의 성장 속도를 항상 앞지른다는 것, 즉 "소프트웨어는 하드웨어가 주는 것보다 빨리 가져간다"는 오래된 격언이 인공지능 시대에 다시 유효해진 셈이다. 게임, 임베디드, 고성능 컴퓨팅이라는 전통적 거점도 건재하다.
물론 통계가 모든 우려를 지우지는 않는다. 같은 시기의 커뮤니티 설문들에는 언어의 복잡성과 진화 속도에 대한 불만이 광범위하게 나타나고, 구글의 카본(Carbon)처럼 'C++ 후계 언어'를 표방하는 실험도 진행 중이며, 표준화 작업을 떠받칠 인력과 자금이 인공지능 분야로 쏠린다는 걱정도 공동체 안에서 제기된다. 성장과 위기 담론이 동시에 참인 상태, 그것이 2026년의 C++다.
47년의 역사에서 C++는 두 번 사망 선고를 받았고 두 번 모두 틀렸음이 입증됐다. 그 생존을 설명하는 요인은 대체로 네 가지로 정리된다.
첫째, 비용 없는 추상화라는 자리. 문제를 추상적으로 사고하게 해 주면서도 C에 준하는 성능을 내는 언어, 즉 "추상화의 사다리를 오르내릴 수 있는" 언어의 자리는 비어 있을 수 없는 자리다. 하드웨어가 성능을 공짜로 나눠 주던 짧은 시기에만 이 자리의 가치가 가려졌을 뿐, 멀티코어 전환과 인공지능 인프라 경쟁은 매번 이 자리의 주인을 다시 호출했다.
둘째, 호환성에 대한 집착. 수십 년 전의 코드가 오늘의 컴파일러에서 돌아간다는 보증은 화려하지 않지만, 수백만 줄의 코드를 운용하는 조직에는 어떤 신기능보다 무거운 가치다. C++ 공동체가 호환성을 농담 삼아 'C로 시작하는 그 단어'라고 부를 만큼 지배적 제약으로 받아들여 온 것은 약점이자 해자(垓字)였다.
셋째, 주인 없는 언어라는 지배구조. C++는 특정 기업의 소유물이 아니라 국제표준이다. 500명이 넘는 위원회의 합의 절차는 느리고 비대화의 위험을 안고 있지만, 어느 한 기업의 사업 전략 변경으로 언어의 운명이 좌우되지 않는다는 신뢰를 만들었다. 단일 기업에 묶인 언어는 결코 지금의 C++처럼 산업 전반의 기간 언어가 될 수 없었으리라는 것이 표준화를 밀어붙였던 이들의 일관된 평가다.
넷째, 멈추지 않은 진화. C with Classes가 그대로 머물렀다면 중간 규모의 성공으로 끝났을 것이다. 템플릿과 STL, C++11의 대수술, 기차 모델, 그리고 C++26의 안전성 개혁과 리플렉션까지 — 환경이 바뀔 때마다 언어가 따라 바뀌었다. 언어는 도구이고, 도구는 실제 프로그래머가 실제 코드에서 마주하는 문제의 좋은 해법인 동안만 살아남는다. 문제는 계속 변하므로, 살아남으려는 언어는 계속 변해야 한다.
1979년의 신참 연구원은 분산 시스템을 끝내 완성하지 못했다. 대신 그 시스템을 만들려고 제작한 도구가 세계의 기반 시설이 됐다. 작은 비호환 변경 하나가 수십만 명을 화나게 하고, 언어의 개선 하나가 사회 전체의 인프라 품질에 외부 효과를 일으키는 규모. 그 무게를 진 채로 C++는 지금도 3년에 한 번씩 기차를 출발시키고 있다.