엔지니어링 철학: Bjarne Stroustrup, 오버헤드 없는 추상화

핵심 요점

• 오버헤드 없는 추상화. Stroustrup는 명료한 코드와 하드웨어에 밀착한 속도 사이의 거짓된 선택을 끝내기 위해 C++를 만들었습니다. 표현력 있는 버전과 손수 최적화한 버전이 같은 기계어로 컴파일되어야 한다는 것입니다.
• 제로 오버헤드 원칙. “쓰지 않는 것에는 비용을 내지 않는다. 그리고 쓰는 것은, 직접 손으로 짠다 해도 더 잘 짤 수 없다”는 것이 모든 C++ 기능이 통과해야 하는 규칙입니다.
• RAII가 이를 구체화합니다. 자원의 수명을 스택 객체에 묶으면, 가비지 컬렉터 없이도 결정론적이고 예외에 안전한 정리가 가능합니다. 훗날 Rust가 거의 통째로 받아들인 패턴입니다.
• 아래에 자리를 남기지 마라. C++는 실리콘과의 사이에 어셈블러 외에는 아무것도 두지 않는, 가장 고수준의 언어로 남아야 합니다. 그렇지 않으면 더 저수준의 언어가 그 자리를 차지하게 됩니다.

원칙

“쓰지 않는 것에는 비용을 내지 않는다. 그리고 더 나아가, 쓰는 것은 직접 손으로 짠다 해도 더 잘 짤 수 없다.” – Bjarne Stroustrup, 제로 오버헤드 원칙¹

이 문장은 시스템 프로그래밍에서 가장 중요한 한 문장이며, 두 가지 약속을 담고 있습니다. 앞부분은 추상화가 쓰지 않는 지점에서는 공짜여야 한다고 말합니다. 어떤 기능을 건드리면 그만큼 비용이 들지만, 무시하면 아무 비용도 들지 않습니다. 메모리 한 바이트도, 실행 시간 한 사이클도요. 뒷부분은 더 어려운 약속입니다. 추상화를 실제로 쓸 때, 컴파일러는 유능한 프로그래머가 바로 그 작업을 위해 손수 짰을 코드만큼은 좋은 기계어를 만들어내야 한다는 것입니다. 릴리스 모드에서 경계 검사를 전혀 하지 않는 vector. 맨 포인터로 컴파일되는 스마트 포인터. 원시 루프 속으로 사라지는 이터레이터. 명료함은 공짜입니다.

대부분의 언어는 거래를 강요합니다. 느린 고수준 표현형을 택하거나, 읽기 어려운 저수준 고속형으로 내려가거나입니다. 그리고 결국 그 기예 전체가 어느 날 어느 고통을 감수할지 고르는 일이 되어버립니다. Stroustrup의 경력 전체는 그 거래에 대한 거부였습니다. 그는 그 고통을 몸으로 겪었습니다. 박사 과정 학생 시절 그는 Simula의 추상화를 사랑했지만 실제 작업에는 너무 느리다는 것을 알았고, BCPL의 속도를 사랑했지만 큰 무언가를 짓기에는 너무 저수준이라는 것을 알았습니다.² C++가 존재하는 이유는, 그가 양자택일을 할 필요가 없어야 한다고 결심했기 때문입니다. 효율과 추상화는 균형을 맞춰야 할 상반된 다이얼이 아니었습니다. 그것들은 같은 코드 한 줄 안에서 함께 도착해야 하는 것이었습니다.

그 신념은 성능은 나중에 더하는 기능이 아니라 잃지 않아야 할 속성이라는 주장의 밑바탕에 깔린 것과 같습니다. 제로 오버헤드 추상화는 느린 언어 위에 얹은 빠른 무언가가 아닙니다. 그것은 컴파일러가 당신이 손수 짰을 바로 그것까지 다시 갈아내는 명료한 무언가이며, 그래서 당신은 명료함의 대가를 결코 치르지 않습니다. “나는 내 코드가 우아하면서 효율적이기를 좋아한다”고 그는 말했습니다. 여기서 중요한 단어는 동시에입니다. 그는 둘 사이에서 골라야 하는 것을 싫어합니다.³

배경

Bjarne Stroustrup는 1950년 12월 30일 덴마크 오르후스에서 태어났습니다.⁴ 그는 오르후스 대학교에서 수학과 컴퓨터 과학을 공부한 뒤, 영국으로 건너가 케임브리지 대학교 컴퓨팅 연구소에서 박사 과정을 밟아 1979년에 마쳤습니다. 그의 학위 논문 – “분산 컴퓨터 시스템에서의 통신과 제어” – 은 운영체제의 작업을 컴퓨터 네트워크 전반에 어떻게 분산시킬 것인가에 관한 것이었습니다.⁴

그 문제를 연구하려면 시뮬레이터를 만들어야 했고, 그는 첫 번째 버전을 Simula로 작성했습니다. Simula는 클래스와 객체를 세상에 처음 소개한 노르웨이 언어로, Ole-Johan Dahl과 Kristen Nygaard가 설계했습니다. Stroustrup는 그것을 사랑했습니다. Simula의 클래스 추상화 덕분에 그는 크고 복잡한 프로그램을 기계의 방식이 아니라 문제가 조직된 방식대로 구성할 수 있었고, 그 프로그램은 작성하고 고치는 일이 즐거웠습니다. 그런데 그것을 대규모로 돌려보자, 추상화는 자기 비용의 무게에 짓눌려 무너졌습니다. 구현이 너무 느려서 실용적이지 못했습니다. 그는 시뮬레이터를 군더더기를 걷어낸 시스템 언어인 BCPL로 다시 작성해 속도를 되찾았지만, BCPL은 너무 저수준이어서 그것으로 큰 무언가를 짓는 일은 고역이었습니다.² 이 급격한 반전이 그의 형성기를 결정지은 상처였습니다. 그는 표현력 있는 언어를 써서 성능으로 그 대가를 치렀고, 그다음 빠른 언어를 써서 나머지 모든 것으로 대가를 치렀습니다. 어느 쪽도 받아들일 수 없었습니다. 두 절반은 동시에 가능했어야 했습니다.

그는 그 불만을 안고 1979년 뉴저지의 Bell Labs로 옮겨갔고, 거기서 다시 분산 시스템 문제와 마주했습니다. 네트워크 전반에 걸친 UNIX 커널의 트래픽을 분석하는 일이었습니다. 케임브리지를 떠올린 그는, 이미 빠르고 하드웨어에 가까운 언어이자 UNIX의 시스템 언어였던 C에, C의 속도를 한 톨도 포기하지 않은 채 Simula의 조직화 능력을 더하기로 마음먹었습니다.⁴⁵ 그는 그 결과물을 “C with Classes”라고 불렀습니다. 1983년 동료 Rick Mascitti가 C++라는 이름을 제안했는데, 이는 C 자체에 적용한 증가 연산자였습니다. 다음 C, 한 단계 더 나은 C, 그 밑의 기계는 같은 C라는 뜻이었습니다.⁵

그가 한 일

C with Classes에서 C++로: 아무 비용도 들지 않는 더 나은 C

최초의 행보(1979–1983)는 의도적으로 절제되어 있었고 정확히 옳았습니다. 이미 빠르고, 이미 하드웨어에 직접 대응되며, 이미 사람들이 신뢰하는 시스템 언어였던 C를 가져다가, Simula가 그에게 갈망하도록 가르친 것들 – 클래스, 더 나은 타입 검사, 데이터 추상화 – 을 더하는 것이었습니다.⁵ 결정적으로, 그는 그것들을 C 프로그래머가 비용을 치를 필요가 없는 계층으로 더했습니다. C 프로그램은 여전히 유효한 C++ 프로그램이었습니다. 새 기능을 하나도 쓰지 않은 struct는 늘 그랬던 것과 똑같은 바이트로 컴파일되었습니다. 새로운 능력은 선택적이었고, 그것을 쓰는 비용은 같은 일을 손으로 짠 C가 치렀을 비용만큼이었습니다. 그것이 바로 배아 상태의 제로 오버헤드 원칙입니다. 이름을 붙이기도 전에 이미 있었던 것이죠. 기능을 쓰지 않는 사람에게 세금을 매기지 말 것, 그리고 그 기능이 사람들이 직접 짰을 것보다 나쁜 코드를 만들어내지 못하게 할 것.

그는 The C++ Programming Language(1985)에서 언어를 문서화하고 안정화했고, 이 책으로 C++는 널리 쓸 수 있게 되었습니다. 그리고 이후 수십 년에 걸쳐 후대의 모든 기능을 설계하면서 그 핵심을 지켜냈습니다.⁴

제로 오버헤드 원칙

제로 오버헤드 원칙은 하중을 지탱하는 핵심 발상이자, 모든 C++ 기능을 가늠하는 잣대입니다. Stroustrup는 이를 두 부분으로 진술합니다. “쓰지 않는 것에는 (시간으로든 공간으로든) 비용을 내지 않는다. 그리고 더 나아가, 쓰는 것은 직접 손으로 짠다 해도 더 잘 짤 수 없다.”¹ 첫 번째 절은 세금 정책입니다. 어떤 기능도 그것을 쓰지 않는 코드에 비용을 지울 수 없습니다. 두 번째 절은 품질 기준입니다. 당신이 실제로 쓰는 기능은, 신중한 프로그래머가 그 특정 작업을 위해 손으로 만들어냈을 코드보다 나쁘지 않게 컴파일되어야 합니다. 템플릿, constexpr, 이동 의미론, 그리고 표준 라이브러리의 컨테이너와 알고리즘은 모두 이 원칙을 지키도록 설계되었습니다. 유명한 두 예외인 런타임 타입 정보(RTTI)와 예외는, 바로 컴파일러가 끄는 스위치를 제공하는 그 두 기능입니다. 이 규칙을 어기기 때문이죠.⁶

그 보상은 어셈블리를 직접 보기 전까지는 불가능하게 들리는 바로 그것입니다. 표현력 있는 방식과 손수 최적화한 방식이 같은 기계어를 만들어낸다는 것.

그 동일성 – 표현력 있는 것과 손수 최적화한 것이 하나의 출력으로 합쳐지는 것 – 이야말로 이 원칙이 기술적인 동시에 도덕적인 이유입니다. 그것은 엔지니어의 상투적인 변명을 없애버립니다. 명료함이 정말로 비싸다면, 추하고 빠른 버전을 짜면서 “빨라야 하니까”라고 정당화할 수 있을 것입니다. Stroustrup의 베팅은 그 변명이 대개 거짓말이라는 것입니다. 잘 설계된 추상화는 읽기 좋은 버전과 빠른 버전을 동시에 가질 수 있게 해준다는 것, 왜냐하면 그 둘이 같은 버전이기 때문이라는 것입니다. 비용은 언어 설계자가 단 한 번 치렀고, 그래서 프로그래머가 다시는 치르지 않게 되었습니다.

RAII와 결정론적 자원 관리

이 원칙에는 시스템 프로그래밍에서 가장 지저분한 부분 – 획득한 다음 확실하게 해제해야 하는 자원, 즉 메모리, 파일, 락, 소켓 – 을 위한 메커니즘이 필요했습니다. 가비지 컬렉션은 결정론을 포기함으로써 이 문제에 답합니다. 정리는 컬렉터의 일정에 따라 언젠가는 일어나는데, 이는 락이나 파일 핸들에는 견딜 수 없는 일입니다. Stroustrup의 답은 그가 RAII – Resource Acquisition Is Initialization(자원 획득은 곧 초기화) 라고 이름 붙인 것으로, 자원의 수명을 스택 위 객체의 수명에 묶습니다.⁷ 자원을 생성자에서 획득하고 소멸자에서 해제합니다. 그리고 C++는 스택 객체의 소멸자가 그 객체가 범위를 벗어나는 바로 그 순간 – 정상적으로든 아니면 예외를 통해서든, 생성의 역순으로 – 실행됨을 보장하므로, 자원은 정확히 해제되어야 할 때 결정론적으로 해제됩니다. 컬렉터도 없고, 잊어버릴 수동 free도 없습니다.⁷

RAII는 구체화된 제로 오버헤드입니다. 소멸자 호출은 어차피 당신이 손으로 짰어야 할 코드이고, 언어는 그저 당신이 그것을 잊을 수 없게 보장해줄 뿐입니다. 당신은 자동적이고 예외에 안전하며 결정론적인 정리를 얻으면서, 정리를 직접 손으로 짰을 때 치렀을 비용 이상은 아무것도 치르지 않습니다. 이것은 후대의 언어들, 가장 두드러지게는 Rust가 거의 통째로 받아들인 C++ 패턴입니다.

표준화, 그리고 “더 저수준 언어에 자리를 남기지 마라”

Stroustrup는 C++를 개인 프로젝트로 묶어두지 않았습니다. 그는 그것을 표준화 위원회로 가져갔고 – 1989년부터 ANSI, 1991년부터 ISO – 수십 년간 위원으로 활동하며 Evolution Working Group의 의장을 맡았습니다. C++가 한 회사의 방언이 아니라 안정적이고 벤더 중립적인 표준이 되도록 하기 위해서였습니다.⁴ 그리고 그는 위원회에 The Design and Evolution of C++의 설계 원칙에서 끌어낸 헌법적 규칙을 주었습니다. “C++ 아래에 (어셈블러를 제외하고) 더 저수준 언어가 들어설 자리를 남기지 마라.”⁸ 그 논리는 정확합니다. 만약 C++와 맨 하드웨어 사이에 있는 어떤 언어로 더 효율적인 코드를 짤 수 있다면, 그 언어가 선택받는 시스템 언어가 될 것이고 C++는 존재 이유를 잃게 됩니다.⁸ 살아남으려면 C++는 C의 직접적인 하드웨어 접근, 데이터 배치에 대한 제어, 그리고 기계에 일대일로 대응되는 원시 타입을 유지해야 합니다.⁸ 추상화와 실리콘 사이에는 어셈블러 외에 아무것도 자리해서는 안 됩니다. 제로 오버헤드 원칙을, 경쟁의 경계선으로 진술한 것입니다. 여전히 무엇 하나 남기지 않는, 가장 고수준의 언어가 되라는 것.

그의 방법

그 방법은 하나의 베팅 – 추상화를 올바르게 설계하면 명료함과 속도는 같은 것이다 – 을, 일련의 엄격한 규칙으로 강제하는 것입니다.

모든 기능을 제로 오버헤드에 비추어 가늠하라. 어떤 기능도 그것을 쓰지 않는 코드에 세금을 매겨서는 안 되며, 어떤 기능도 손으로 짠 등가물보다 나쁜 코드를 만들어내서는 안 됩니다. 이것이 40년간 모든 C++ 추가 기능이 통과해야 했던 관문입니다.¹⁶

프로그래머를 신뢰하고, 다중 패러다임을 유지하라. C++가 절차적, 객체 지향적, 제네릭, 함수형 스타일을 모두 지원하는 것은, Stroustrup가 당신의 문제를 어떻게 조직할지 대신 결정하기를 거부했기 때문입니다. 언어는 도구를 주고, 당신이 당신의 영역을 언어 설계자보다 더 잘 안다고 가정합니다.⁶

하드웨어에 직접 대응시켜라. 원시 타입, 데이터 배치, 그리고 기계 사이의 C식 일대일 대응을 유지하세요. 추상화는 그것을 감추는 런타임 위가 아니라, 금속 위에 직접 자리합니다.⁸

정리를 언젠가가 아니라 결정론적으로 하라. RAII는 자원의 수명을 객체의 수명에 묶어, 해제가 알려진 순간에, 예외에 안전하게, 가비지 컬렉터 없이, 해제하기를 기억해야 할 것 없이 일어나게 합니다.⁷

공개적으로 안정화하라. 언어를 소유하는 대신 국제 표준화 위원회에 넘겨, C++가 견고한 공공 표준이 되고 어떤 단일 벤더도 그것을 분기시킬 수 없게 하세요.⁴

영향의 사슬

누가 그를 빚었는가

Ole-Johan Dahl과 Kristen Nygaard, Simula를 통해. Simula는 Stroustrup에게 추상화가 무엇을 위한 것인지 – 프로그램이 문제가 조직된 방식대로 구성될 수 있게 하는 것 – 를 가르쳤고, 그 느림은 그에게 교훈의 나머지 절반을 가르쳤습니다. 쓸 수 있을 만큼 감당되지 않는 추상화는 쓸모가 없다는 것입니다. C++는 Simula의 선물은 지키되 그 비용은 하나도 치르지 않으려는 시도입니다. (직접적이고 형성적인 영향)

BCPL, 그리고 C와 UNIX를 둘러싼 시스템 프로그래밍 문화. BCPL은 그에게 대조되는 고통 – 큰 무언가를 조직할 방법이 전혀 없는 맨 속도 – 을 주었고, Bell Labs에서 UNIX의 언어였던 C는 그에게 C++를 대신이 아니라 그 위에 지을 수 있는, 빠르고 하드웨어에 대응되는 토대를 주었습니다.²⁵ (직접적 영향)

Bell Labs. C와 UNIX를 낳은 바로 그 기관이 Stroustrup에게 “C with Classes”를 시작하게 한 분산 시스템 문제를, 그리고 언어를 제대로 다듬는 데 여러 해를 쏟을 수 있게 해준 연구 문화를 주었습니다. (형성적 영향)

그가 빚은 이들

세계의 인프라가 그의 언어 위에서 돌아갑니다. 운영체제, 브라우저, 데이터베이스, 게임 엔진, 컴파일러, 고빈도 거래 시스템, 화성 탐사선의 비행 소프트웨어 – 현대 컴퓨팅의 성능이 결정적인 핵심부는 유독 C++에 치우쳐 있습니다. 이만큼 하중을 지탱하는 엔지니어의 작업은 드뭅니다.

제로 코스트 추상화 운동. “제로 코스트 추상화(zero-cost abstractions)”로 이름이 바뀐 Stroustrup의 원칙은 Rust의 명시적인 창립 목표가 되었습니다. Rust는 RAII(소유권과 Drop으로), 결정론적 소멸, 그리고 고수준 구문이 최적의 기계어로 컴파일되어야 한다는 규칙을 받아들였습니다. D와 Carbon 같은 언어들도 같은 혈통에서 내려왔습니다. 명료함에 대가를 치러서는 안 된다는 발상은 이제 주류이며, 그것은 그의 것입니다.⁶

관통하는 선

John Carmack은 안쪽 루프가 물리법칙이 허용하는 최소한의 일만 하기를 바랍니다. “빛의 속도는 너무 느리고”, 기계는 단단한 한계에 지배되며, 낭비된 모든 사이클은 하나의 선택입니다. Stroustrup는 Carmack에게 그 루프를 읽기 좋게 짤 도구를 건넵니다. 제로 오버헤드 추상화란 명료한 버전과 금속에 가장 가까운 버전이 같은 기계어라는 약속이며, 그래서 당신은 결코 둘 중 하나를 고를 필요가 없습니다. Barbara Liskov가 추상화에 그 이론 – 데이터 추상화, 타입이 그 사용자에게 지는 계약, “사물이 어떻게 작동하는지가 아니라 무엇을 하는지에 맞춰 프로그래밍해야 한다”는 Simula에서 CLU로 이어지는 계보 – 을 주었다면, Stroustrup는 그 이론에 실행하는 데 아무 비용도 들지 않는 몸을 주었습니다. 그리고 Alan Kay가 객체를 메시지를 주고받는 작은 컴퓨터들, 즉 늦게 바인딩되는 런타임 대화로 상상했다면, Stroustrup는 같은 단어에 이르는 정반대의 길을 택했습니다. 그의 객체는 컴파일 시점에 결정되어 맨 기계어 속으로 녹아 사라지며, OOP는 살아 있는 메시지 버스가 아니라 오버헤드 없는 조직화 도구가 됩니다. 같은 어휘, 두 개의 철학 – 하나는 유연성을 최적화하고, 다른 하나는 런타임에 치를 청구서를 최적화합니다. (시리즈 다리)

내가 여기서 얻는 것

내가 간직하는 교훈은, “표현력 있거나 아니면 빠르거나”는 거의 언제나 나쁜 설계가 당신에게 강요하는 거짓된 선택이라는 것입니다. 내가 추한 버전을 “빨라야 하니까”라며 짜고 있는 나 자신을 발견할 때, Stroustrup의 원칙은 하나의 고발입니다. 그것은 컴퓨팅의 법칙이 아니라, 그 자체로 빠른 것으로 컴파일되는 추상화를 찾아내지 못한 실패라는 것입니다. 해야 할 일은 명료한 버전을 아주 잘 설계해서 기계가 그것으로부터 최적의 코드를 만들어내게 하는 것입니다. 비용을 단 한 번, 설계 단계에서 치러서, 그것을 쓰는 모든 줄에서 다시는 치르지 않게 하는 것입니다. 그것은 품질이 유일한 변수라는 것과 같은 기준입니다. 질문은 결코 “이걸 명료하게 만들 여유가 있는가?”가 아니라 “내 추상화가 왜 이렇게 새서 명료함에 비용이 드는가?”입니다.

내가 지금 짓고 있는 세계 – 에이전트, 도구 루프, AI 시스템 – 에서 유혹은 제로 오버헤드의 정반대입니다. 래퍼 위에 래퍼를 쌓고, 느린 경로를 가리려고 모델 호출 하나를 더 잡아먹고, 편리한 추상화마다 아무도 측정하지 않는 지연을 슬그머니 더하는 것이죠. Stroustrup식 행보는 편리한 인터페이스가 효율적인 인터페이스로 컴파일되기를 요구하는 것입니다. 깔끔한 API와 빠른 경로가 같은 경로가 되게 하되, 그 비용을 그곳을 흐르는 모든 호출에 청구하는 대신 하니스의 설계에서 치르게 하는 것입니다. 그 신념 – 취향은 기술적 시스템이며, 당신이 우긴다고 되는 분위기가 아니라 엄격한 규칙을 들이댈 수 있는 대상이라는 신념 – 이야말로 너무 느리게 돌아갔던 1979년의 시뮬레이터에서 그래서는 안 되는 2026년의 에이전트 하니스로 관통하는 선입니다.

자주 묻는 질문

Bjarne Stroustrup의 엔지니어링 철학은 무엇인가요?

Stroustrup의 신념은 표현력 있는 고수준 코드와 하드웨어에 밀착한 성능 사이에서 결코 양자택일해서는 안 된다는 것입니다. 그는 제로 오버헤드 원칙 위에 C++를 세웠습니다. 언어 기능은 당신이 쓰지 않을 때는 아무 비용도 들지 않아야 하고, 쓸 때는 그 작업을 위해 당신이 손으로 짰을 코드보다 나쁘지 않게 컴파일되어야 한다는 것입니다.¹ 그는 이를 프로그래머에 대한 신뢰(C++는 의도적으로 다중 패러다임입니다), 하드웨어에의 직접 대응, RAII를 통한 결정론적 자원 관리, 그리고 언어를 소유하는 대신 개방형 ISO 표준으로 안정화하는 것과 짝지었습니다.⁴⁶⁷

제로 오버헤드 원칙이란 무엇인가요?

Stroustrup가 두 부분으로 진술한 규칙입니다. “쓰지 않는 것에는 (시간으로든 공간으로든) 비용을 내지 않는다. 그리고 더 나아가, 쓰는 것은 직접 손으로 짠다 해도 더 잘 짤 수 없다.”¹ 앞부분은 쓰지 않는 기능이 아무런 실행 시간이나 메모리 비용도 지우지 않는다는 뜻이고, 뒷부분은 당신이 쓰는 기능이 유능한 프로그래머가 손으로 짰을 것만큼은 좋은 코드를 만들어낸다는 뜻입니다. 이것이 모든 C++ 기능이 통과해야 하는 관문입니다. 이를 어기는 두 기능 – 런타임 타입 정보(RTTI)와 예외 – 은 바로 대부분의 컴파일러가 끌 수 있게 해주는 그 두 기능입니다.⁶ 이 원칙이 있기에 스마트 포인터나 이터레이터 같은 C++ 추상화가 맨, 손수 최적화한 버전과 같은 기계어로 컴파일될 수 있는 것입니다.

RAII란 무엇이고, Stroustrup는 왜 그것을 발명했나요?

RAII – Resource Acquisition Is Initialization(자원 획득은 곧 초기화) 는 Stroustrup가 이름 붙인 C++ 패턴으로, 자원의 수명을 스택 객체의 수명에 묶습니다. 자원을 객체의 생성자에서 획득하고 소멸자에서 해제하는 것이죠.⁷ C++는 스택 객체의 소멸자가 그 객체가 범위를 벗어나는 순간 – 함수가 정상적으로 반환하든, 예외가 스택을 풀어내든 – 실행됨을 보장하므로, 메모리, 파일, 락, 소켓 같은 자원은 알려진 순간에 결정론적으로, 가비지 컬렉터 없이, 수동으로 해제할 것 없이 해제됩니다. 이는 자동적이고 예외에 안전한 정리를 오버헤드 없이 제공하며, 훗날 Rust가 소유권과 Drop으로 거의 통째로 받아들였습니다.⁷

Stroustrup는 왜 C++를 만들었고, 그것은 어디서 비롯되었나요?

분산 시스템에 관한 케임브리지 박사 논문을 쓰는 동안(1979년 완료), Stroustrup는 Simula로 시뮬레이터를 만들었고 그 클래스 추상화를 사랑했지만 대규모에서는 너무 느리다는 것을 알았습니다. 그는 그것을 BCPL로 다시 작성했는데, 빠르긴 했지만 큰 무언가를 짓기에는 너무 저수준이었습니다.² 어느 절충도 받아들일 수 없었기에, Bell Labs에서 – 네트워크 전반에 걸친 UNIX 커널 분석 문제와 마주하며 – 그는 C의 속도를 잃지 않은 채 C에 Simula의 조직화 능력을 더하기로 마음먹었습니다. 그는 그것을 “C with Classes”(1979)라고 불렀고, 동료 Rick Mascitti가 1983년에 C++라는 이름을 제안했습니다.⁴⁵ 2018년 미국 공학한림원(National Academy of Engineering)은 C++ 프로그래밍 언어를 설계하고 구현한 공로로 그에게 찰스 스타크 드레이퍼 상(Charles Stark Draper Prize) – 미국 공학계 최고의 영예이자 흔히 공학의 노벨상이라 불리는 50만 달러의 상 – 을 수여했습니다.⁹

출처