C++의 이야기: 세상에서 가장 영향력 있는 언어의 40년 — CultRepo 다큐멘터리 정리

영상 정보

제목: The Story of C++: The World’s Most Consequential Programming Language (The Official Story)

채널: CultRepo · 다큐멘터리

업로드: 2026-06-04 · 길이 1시간 11분 34초 · 조회수 약 238,741회(정리 시점)

주요 출연: Bjarne Stroustrup(C++ 창시자), Alexander Stepanov(STL 설계자), Brian Kernighan, Andrew Koenig, Barbara Moo, Herb Sutter(ISO C++ 위원회 전 의장), Anders Hejlsberg(C#·TypeScript 창시자), Chris Lattner(LLVM·Swift·Mojo), Andrei Alexandrescu, Gabriel Dos Reis, Nina Ranns, Danilo Piparo(CERN), John Romero(Doom·Quake) 등

영상 링크: https://www.youtube.com/watch?v=lI7tMxzSJ7w

Articles 카테고리는 읽을 만한 외부 콘텐츠를 골라 핵심을 정리하고 내 관점으로 분석하는 공간이다. 이번엔 글이 아니라 71분짜리 다큐멘터리를 영상용 article 형식으로 정리했다.

정리 방식 메모: 이 영상에는 사람이 만든 영어 자막(manual subtitle) 이 있어, 앞서 정리한 ASR 자막 영상보다 텍스트 정확도가 높다. 발화를 충실히 옮기되, 화자가 빠르게 교차하는 다큐 특성상 발언의 화자가 분명한 경우에만 이름을 붙였다. 챕터 구분과 제목은 영상 설명란의 24개 타임라인을 따랐다.

한 줄 요약 (TL;DR)

C++은 한 천재의 머릿속에서 완성된 게 아니라, “Simula의 추상화를 C의 효율 위에 얹자” 는 단순한 아이디어(C with Classes)에서 출발해 40년간 사람들이 다투고 표준화하고 확장하며 자란 언어다. 두 번의 “겨울”(닷컴·Java, 그리고 지금의 메모리 안전성)을 넘기며, 성능이 다시 중요해질 때마다 부활했다. 이 다큐는 그 부침의 역사를 만든 사람들의 입으로 들려준다.

왜 이 영상을 골랐나

언어를 쓰는 법을 다룬 자료는 많지만, 언어가 왜 그렇게 생겼는지를 만든 사람들의 입으로 듣는 자료는 드물다. C++의 역사는 곧 소프트웨어 엔지니어링의 핵심 긴장들 — 추상화 대 효율, 호환성 대 진화, 개인 설계 대 위원회 합의, 그리고 지금의 성능 대 안전성 — 이 실제로 어떻게 부딪혔는지를 보여주는 살아 있는 교과서다. 이 위키의 We Programmers(프로그래밍의 역사·문화)와 Rust Essential(C++의 자리를 노리는 안전성 중심 언어) 사이를 잇기에도 좋은 글감이라 골랐다.

핵심 내용

영상의 24개 챕터를 시대순 흐름으로 묶어 정리한다.

시작 — Bell Labs, 그리고 “C with Classes”

1979~80년경 Bjarne Stroustrup은 케임브리지에서 AT&T Bell Labs로 건너간다. 당시 AT&T는 거의 100만 명을 고용한 미국 최대 기업이었고, 사실상 보장된 통신 수익의 일부를 떼어 Bell Labs를 운영했다 — C 언어, Unix, 수많은 기초 연구가 거기서 나왔다. “컴퓨팅을 하고 싶다면 거기가 그곳”이었다.

Bjarne는 Unix 기반 분산 시스템을 만들려다 벽에 부딪힌다. 하드웨어를 직접 다루려면 저수준 언어(C)가 필요했지만, 프로그램이 커질수록 구조를 통제하기 어려웠다. 그는 케임브리지·오르후스에서 쓰던 Simula(최초의 객체지향 언어)의 강한 타입 안전성·클래스·클래스 계층을 좋아했지만, Simula는 너무 느리고 무거웠다. 그래서 “Simula의 기본 기능을 C에 넣자” — 이것이 C with Classes 였다. 그는 이후 “거의 40년을 C++이 Simula와 C가 하던 모든 걸 할 수 있게 만드는 데 썼다”고 말한다. 그 끝없는 도전이 역설적으로 C++을 성공시켰다.

이름의 탄생과 CFront

C with Classes는 C의 전처리기로 시작했지만, Bjarne는 “C에서 충분히 큰 도약이 아니다”라고 판단하고 1년을 들여 컴파일러를 만든다. 그것이 CFront(1983) — 기계어가 아니라 C 코드로 컴파일하는 진짜 컴파일러였다. 덕분에 사용자는 새 인프라·새 라이브러리를 살 필요 없이 기존 C 생태계 위에서 바로 쓸 수 있었다.

이름은 친구들에게 20~25개 후보를 받아 C++ 로 정했다. ++ 는 C의 증가 연산자, 즉 “C에 1을 더한다”는 뜻. “의미상 ++C 가 맞지만, 색인 만드는 사람들이 가여워서 C++로 했다”는 농담이 붙는다.

“버그투성이 제품” — 2.Oh.Oh

다큐는 C++이 “하룻밤 성공”이 아니었음을 강조한다. Bjarne의 말 — “Being an overnight success takes decades”(하룻밤 성공에는 수십 년이 걸린다). 초기엔 Bjarne 혼자 문서·컴파일러·구현·헬프데스크를 다 했고, AT&T의 투자는 미미했다.

상징적인 사건이 CFront 2.0 릴리스다. 출하 후 다중 상속 처리에 치명적 버그가 발견됐는데, “필드에 나가면 절대 고칠 수 없는” 종류였다. 며칠 만에 패치했지만, 이미 같은 번호로 나간 버전과 구분해야 했다(오늘날 말하는 slipstreaming 문제). “2.0.1로 부르면 첫 릴리스도 못 냈다고 망신”이라, 대신 2.0.0(애정을 담아 2.Oh.Oh 라 불렀다)으로 내보냈다. 여기서 다큐가 반복하는 엔지니어링 교훈 하나 — 호환성(compatibility)은 “the C word”, 즉 무엇보다 우선한다. 사용자가 기존 코드를 갖고 있으면, 언어를 바꿨다고 코드를 고치게 만들어선 안 된다.

퍼져나가다 — Usenet, Byte, 그리고 너무 많은 버전

웹 이전 시대, C++은 Usenet(comp.lang.c++)과 Byte 매거진(전화번호부 두께의 “성경”) 같은 채널로 퍼졌다. 광고도 후원도 없이 그냥 번졌다. Bjarne는 1980년대 후반 어느 회사든 찾아가 강연하며 끈질기게 전도했다.

문제는 인기와 함께 파편화가 왔다는 것. Borland·Microsoft·IBM·Sun이 각자 구현했고, 특히 템플릿이 제각각이라 호환되지 않았다. “한 쪽 코드가 다른 쪽에선 컴파일되지 않는” 상황이 계속되면 언어는 결국 붕괴한다.

표준화 — IBM·HP·Sun이 팔을 비틀다

어느 날 IBM·HP·Sun 대표들이 Bjarne의 사무실에 찾아와 “ANSI 규칙으로 C++을 표준화하라”고 요구한다. Bjarne는 “아직 실험 중이라 이르다”고 거절했지만, 그들은 “네가 안 하면 우리가 한다, 그리고 우리는 망칠 거다” 라며 한 시간을 압박했다. 표준에 대한 다큐의 비유가 좋다 — “표준은 종종 멍청하지만, 교통법규처럼 따르지 않으면 죽는다.” 표준은 코드 작성자와 구현 사이의 계약이다.

결국 Bjarne는 1년만 달라고 해 ARM(Annotated Reference Manual)을 쓰고, 이를 토대로 ISO 위원회가 꾸려진다(당시 100~120명 규모). 다큐는 위원회의 어수선함도 보여준다 — “호주 대표가 편지 한 장으로 뉴질랜드까지 대표해 두 표를 행사했다”는 일화. 처칠의 “민주주의는 최악의 제도지만 나머지보다는 낫다”가 인용된다.

STL — Alexander Stepanov의 혁명

표준화가 순항하던 중 Alexander Stepanov라는 “불꽃”이 등장한다(타파스집에서 “레드와인 네 병 — 한 병은 다 같이, 세 병은 나”라고 주문한 일화로 그의 열정이 소개된다). 그의 STL(Standard Template Library) 은 당시 제각각이던 컨테이너·알고리즘을 수학적으로 일반화했다 — “모든 알고리즘이 모든 적용 가능한 자료구조에서 동작하도록”.

위원회는 “너무 늦었고 너무 크다”며 난색을 표했지만, Andrew Koenig가 공정한 청문 기회를 만들었고(“The Science of C++ Programming” 발표), Stepanov는 기립박수를 받았다. Bjarne는 처음엔 이해하지 못했지만 곧 “매우 유망하다”며 언어 기능으로 뒷받침했다. Stepanov의 회고 — 자신의 “이상한” 설계가 좋은 기초 라이브러리의 12개 기준 중 11개를 만족했고, 다른 어떤 라이브러리도 그러지 못했다. Microsoft 등 강자들이 반대했지만 약 80%가 찬성해 STL은 표준이 됐다. 한 출연자의 표현 — “It was order in chaos. It was rigor in a mess.” Bjarne조차 “STL은 C++ 자체만큼이나 사람들의 프로그래밍 방식에 영향을 줬다”고 평한다.

C++98 — 그리고 게임·트레이딩·CERN으로

C++은 1997년 11월 표준화됐다(흔히 C++98) — 네임스페이스·예외·템플릿·STL이 추가됐다. (재밌는 일화: 표준 문서 안에 Studebaker · Vivisectionist 라는 암호 단어와 limerick(5행시)을 몰래 숨겨 넣었다.) Bjarne의 평가 — 표준화가 없었다면 C++은 “영원히 서부 개척시대”였을 것이고, 진지한 기업은 채택하지 않았을 것이다.

표준화 이후 C++은 빠르게 번진다.

CERN: 1990년대 초 Fortran을 대체하는 패러다임 전환. 데이터 분석·제어·시각화가 모두 C++의 강점과 맞았다(ROOT 프레임워크).
게임: 비디오카드가 저수준을 가져가며 C/어셈블리 개발자들을 C++로 끌어올렸다. “Call of Duty처럼 고프레임·고속 그래픽이면 무조건 C++ — 속도 때문에.”
트레이딩: 월스트리트의 고빈도 트레이딩(HRT). “마이크로초가 중요한” 세계에서, C++은 모든 줄을 미세 최적화하지 않고도 그 지연시간을 달성하게 해줬다. Scott Meyers의 인용 — “C++ is for demanding programming problems.”

첫 번째 겨울 — 닷컴 붕괴와 Java

2000년 닷컴 붕괴, 그리고 Java의 부상. Sun은 Java를 “미래·인터넷의 언어”로 대대적으로 마케팅했고, 임원들은 “Java가 2년 안에 C++을 죽인다”고 했다. Java는 C++의 (체감) 복잡성에 대한 명시적 반작용이었다.

여기에 결정적 요인이 하나 더 있었다 — CPU 주파수가 지수적으로 빨라지던 시대. “어차피 1년 기다리면 하드웨어가 빨라진다”는 생각이 퍼지며 성능은 중요하지 않다는 분위기가 비효율 언어들을 띄웠다. 이 조합이 C++의 겨울(early 2000s) 을 불렀다 — 정체가 아니라 쇠퇴였다.

C#, 그리고 “전쟁은 없었다”

Microsoft의 Anders Hejlsberg는 “Visual Basic의 쉬움 + C++의 힘”을 노려 C# 을 만들었다(당시 사람들은 앱을 VB로 프로토타이핑하고 배포용으로 C++로 다시 짜고 있었다). 하지만 그는 언어 전쟁 서사를 거부한다 — “It was never a war.” 모든 성공한 언어는 저마다의 자리가 있고, “어떤 언어도 모두를 위한 최고일 수 없다.” C++과 C#은 경쟁이 아니라 보완이라는 것.

다시 효율의 시대 — 멀티코어와 Modern C++(C++11)

2004년경, 50년 컴퓨팅 역사상 처음으로 주파수 스케일링이 멈췄다. 단일 코어 성능 향상이 한계에 부딪히며 세상은 병렬로 간다. “1년 기다리면 빨라진다”가 더는 통하지 않으니, 효율적 언어가 다시 필요해졌다 — C++의 자리였다(게다가 임베디드에서도 충분히 쓸 만해졌다).

이 무렵 회자된 유명한 이메일 한 통 — “C++ multi-threading: is the standardization committee listening?” 당시 C++ 표준엔 스레딩이 한 줄도 없었다(동시성 모델은 IBM·Sun이 자사 Java 구현 성능을 이유로 사실상 거부해, 더 정교한 모델을 2년 더 다듬어야 했다). 그리고 다큐가 분명히 공을 돌리는 사람은 Herb Sutter 다 — “새 표준을 만들어 멀티스레딩과 이 문제들을 다뤄야 한다”고 밀어붙인 그가 “모든 걸 바꿨다”고 한다.

표준은 2002년 C++0x 로 시작했지만(원래 2007~09년 출시 목표) “이 기능이 중요하니 늦추라”가 반복되며 미뤄졌고, 첫 표준 C++98에서 13년 만인 2011년, C++11 로 결실을 맺는다. Herb는 “왜 미루나? 이미 몇 년 늦었다. 지금 낼 수 있지 않나?”라며 위원회를 밀어붙였다. C++11은 move semantics, 동시성(Hans Boehm 등), auto, range-based for, 람다, 스마트 포인터, constexpr 을 담았다 — “문법은 같지만 문제를 생각하는 방식이 완전히 다른” 르네상스의 순간. Hejlsberg조차 “C#을 잠시 서랍에 넣고 C++을 다시 꺼내볼까” 한다.

복잡성 논쟁 — “더할 수는 있어도 뺄 수는 없다”

C++11 이후 시간 기반 릴리스(train model) 가 도입된다 — 3년마다 “기차가 떠나고”, 못 타면 다음 기차를 기다린다. 덕분에 업계는 다시는 “표준이 나오긴 하나” 의심하지 않게 됐다. C++14(버그픽스)·C++17(고점)·C++23으로 이어진다.

그러나 복잡성 논쟁이 불붙는다. “변수를 초기화하는 방법이 20가지”, “풀 수 없는 복잡성의 매듭” 같은 비판. 위원회는 527명까지 불었고(“C++의 리얼 하우스와이프”라는 농담까지), 다큐는 이를 공유지의 비극으로 정리한다 — 누구나 기능을 더하긴 쉽지만, 그 누적이 문제다. 언어 설계자가 배우는 한 가지 — “You can add, but you can never take away.”(더할 수는 있어도, 결코 뺄 수는 없다.)

어디에나 있는 C++ — 그리고 두 번째 겨울(안전성)

C++은 “대략 모든 곳” 에 있다 — 카메라, 풍력 터빈, 밥솥, 자동차, 금융, 할리우드. “지구 인구의 절반을 매일 건드린다.” HRT는 코드베이스가 100만 줄·1.5만 파일, 2025년 한 해에만 약 8.4만 커밋(약 800명 개발자). Nvidia에서는 Python이 표면이지만 그 아래 CUDA 라이브러리(C++) 가 계산을 짊어진다 — 즉 C++이 AI·HPC 생태계를 떠받친다. 개발자 수는 2022년 940만 → 2025년 1,630만, 가장 빠르게 성장하는 언어는 Rust와 C++.

하지만 다큐는 지금을 “두 번째 겨울” 이라 부른다 — 메모리 안전성 이슈다. 팬데믹 이후 각국 정부·규제기관이 “C++은 기본적으로 메모리 안전하지 않다”며 이탈을 압박했다. 다큐는 이를 “가장 중요하게 풀어야 할 문제”로 본다. 대응으로 C++26 에서 초기화되지 않은 변수의 undefined behavior 제거, 표준 라이브러리 타입(string·span·vector)의 경계 안전(bounds safety) 옵션 등이 들어온다. 또 하나의 큰 사건은 static reflection — “프로그램 코드가 프로그램 코드를 들여다본다.” 한 출연자는 이를 “우리가 표준화한 단일 기능 중 가장 영향력 있는 것” 이라 평한다.

Bjarne의 유산

다큐는 Bjarne에 대한 동료들의 헌사로 닫힌다. 40여 년간 “자비로운 종신독재자(benevolent dictator for life)”로 한 언어에 헌신한 사람. 그가 증명한 것 — 이식 가능한 코드에서, 규모 있는 효율적 추상화가 가능하다는 것. Bjarne를 계속 움직이는 것은 응용과, 그것을 만든 사람들과의 대화다. “세상에 이걸 내놓았으니, 더 낫게 만들 의무가 있다.”

분석과 인사이트

여기서부터는 영상 요약이 아니라 내 관점이다.

C++의 역사는 “추상화 대 효율”이라는 한 문장의 40년짜리 변주다. Simula의 추상화를 C의 효율 위에 얹겠다는 출발점이, 게임·트레이딩·CERN·CUDA까지 모든 부활의 공통 이유였다. 성능이 공짜처럼 느껴질 때(주파수 스케일링 시대) C++은 겨울을 맞았고, 성능이 다시 비싸질 때(멀티코어·performance-per-watt) 부활했다. “효율적 추상화”라는 틈새가 사라지지 않는 한 C++은 죽지 않는다 — 이건 언어 선택을 고민하는 엔지니어에게도 그대로 적용되는 판단 기준이다.
“호환성은 the C word”가 이 다큐의 가장 실무적인 교훈이다. 2.Oh.Oh 사건부터 “더할 수는 있어도 뺄 수는 없다”까지, C++의 모든 고통과 복잡성은 기존 사용자를 깨뜨리지 않겠다는 약속에서 나온다. API·라이브러리·플랫폼을 설계하는 사람이라면 똑같은 청구서를 받는다 — 한번 내보낸 인터페이스는 영원히 짊어진다. 빠른 진화와 깨지지 않는 호환성은 늘 충돌하고, 그 사이를 관리하는 게 곧 설계 역량이다.
표준화는 “개인의 비전”을 “산업의 계약”으로 바꾸는 고통스러운 거래다. IBM·HP·Sun이 Bjarne의 팔을 비튼 장면은 거버넌스의 본질을 압축한다 — 표준은 최적이 아니라 합의다(교통법규처럼). 그 대가로 진지한 기업이 채택할 수 있는 신뢰를 얻지만, 위원회가 527명이 되면 “공유지의 비극”으로 복잡성이 쌓인다. 합의의 힘과 비대화의 저주는 동전의 양면이다. 이 긴장은 Craftsmanship Essential이 다룬 “좋은 설계는 더하기가 아니라 빼기”라는 장인의 감각과도 맞닿는다.
지금의 “두 번째 겨울”(안전성)은 Rust라는 거울 앞에 선 C++의 이야기다. “가장 빠르게 성장하는 언어는 Rust와 C++”이라는 대목이 의미심장하다. 둘은 같은 틈새(저수준 + 효율)를 두고, 한쪽은 소유권(ownership)으로 기본값을 안전하게 만들었고, 다른 쪽은 40년 호환성을 지키며 사후에 안전성을 덧대는 중이다(C++26의 bounds safety·UB 제거). C++의 강점(생태계·관성)과 약점(누적된 복잡성·기본 비안전)이 정확히 Rust의 약점·강점과 거울상이다. 어느 쪽이 옳다기보다, “안전을 기본값으로 둘 것인가, 호환성을 기본값으로 둘 것인가” 라는 설계 철학의 분기를 보여준다.
이 다큐의 진짜 주인공은 언어가 아니라 사람과 공동체다. Bjarne 혼자 헬프데스크까지 하던 시절, Koenig가 Stepanov에게 발언 기회를 준 순간, Herb가 위원회를 떠민 이메일 — 언어의 진화는 기술 결정이 아니라 누가 무엇을 밀어붙였는가의 연속이었다. We Programmers가 말한 “프로그래밍은 결국 사람의 일”이라는 명제를, C++ 40년사가 그대로 증명한다.

적용 포인트

언어/도구를 고를 때 “성능이 비싼 문제인가”를 먼저 묻는다. 성능이 병목이 아니면 생산성 언어가 낫고, 마이크로초·와트가 돈인 영역(트레이딩·게임·임베디드·HPC)에선 C++/Rust가 답이다. C++의 모든 부활이 이 질문에서 갈렸다.
공개 인터페이스는 “영원히 짊어진다”는 각오로 설계한다. 한번 내보낸 API·스키마·포맷은 빼기 어렵다. 처음부터 작게, 확장 여지를 남기고 내보낸다. (2.Oh.Oh와 “add but never take away”의 교훈)
표준·컨벤션은 최적이 아니라 합의임을 받아들인다. 팀의 규칙이 비효율적으로 보여도, 모두가 같은 계약 위에 서는 가치가 종종 더 크다. 단, 위원회가 커질수록 “더하기”를 경계하고 “아니오”를 말하는 규율이 필요하다.
메모리 안전성을 강 건너 불로 보지 않는다. 규제·정부가 비안전 언어를 압박하는 흐름은 실재한다. C++을 쓴다면 C++26의 안전 기능을, 새 시스템이라면 Rust의 소유권 모델을 적어도 이해해 둔다.

마무리

C++의 40년은 “완벽한 설계”의 역사가 아니라 타협과 끈기의 역사다. 너무 복잡하다고 욕먹고, 두 번이나 죽는다는 소리를 들었지만, 효율적 추상화라는 틈새가 사라지지 않는 한 매번 돌아왔다. 이 다큐가 남기는 가장 큰 울림은 기술이 아니라 태도다 — 한 사람이 평생을 한 언어에 헌신할 수 있고, 그 헌신이 세상의 절반이 매일 쓰는 인프라가 될 수 있다는 것. “하룻밤 성공에는 수십 년이 걸린다.”