C++: 다큐멘터리: 세계에서 가장 중대한 프로그래밍 언어

• Bell Labs의 시작부터 전 세계 채택과 현재 성장세까지를 한 편으로 정리한 C++ 40년사 다큐멘터리로 C++ 역사와 표준화, 도구 생태계에 참여한 인물들이 출연
• C++ 는 Bjarne Stroustrup이 Bell Labs에서 C의 하드웨어 제어력과 Simula의 객체지향 추상화를 결합하려 만든 C with Classes에서 출발했고, 대규모 시스템을 위한 효율적 추상화 언어로 커짐
• 초기 구현 CFront는 C++를 C 코드로 변환해 기존 C 인프라와 라이브러리를 그대로 쓰게 했고, 1983년 이후 사용자가 늘면서 호환성이 핵심 과제로 떠오름
• IBM, HP, Sun의 압박으로 시작된 ANSI/ISO 표준화는 벤더별 구현 분열을 막았고, 1997년 표준에는 namespace, exception, template, STL이 포함됨
• 2000년대 초 Java와 C#, 닷컴 붕괴, 빠른 CPU 성능 증가로 C++ winter가 왔지만, 2004년경 주파수 스케일링이 멈추고 병렬성이 중요해지며 C++11이 르네상스를 만듦
• 오늘날 C++는 CERN, 게임, 금융, CUDA 기반 AI·HPC, 임베디드 시스템 등에서 쓰이며, 메모리 안전성, 복잡성, 표준위원회 규모, 자금 부족이 주요 과제로 남아 있음

---

Bell Labs에서 시작된 C with Classes

• C++는 40년이 넘은 언어이며, 처음 만들어질 당시에는 에디터, 구문 강조, 코드 탐색, 자동 완성, 리팩터링 같은 도구가 없었고 많은 개발자가 BASIC이나 칩마다 다른 어셈블리 언어를 사용했음
• 더 크고 복잡한 프로그램이 필요해지던 시기에 Bjarne Stroustrup은 Bell Labs에서 분산 시스템을 만들려 했고, 장치 드라이버, 네트워크 인터페이스, 메모리 관리자, 프로세스 같은 요소를 다루려면 저수준 언어가 필요했음
• C는 하드웨어를 완전히 제어할 수 있고 시스템 프로그래밍에 적합했지만, 프로그램이 커질수록 모듈, 통신 채널, 프로토콜 같은 구조를 표현하기에는 부족했음
• Stroustrup은 Cambridge에서 사용한 Simula의 강한 타입 안전성, 사용자 정의 타입, 클래스, 클래스 계층을 좋아했지만 Simula가 너무 느리고 메모리를 많이 쓴다고 봤음
• 그래서 Simula의 기본 기능을 C에 넣는 방식으로 C with Classes를 만들었고, 이후 거의 40년 동안 C++가 Simula와 C가 할 수 있는 일을 모두 하게 만드는 방향으로 발전시킴

CFront, 이름, 초기 확산

• C with Classes는 처음에 C 전처리기 형태로 만들어졌고, 다른 사람들이 쓰기 시작하면서 Stroustrup은 C와의 차이가 충분하지 않다고 판단해 1년 동안 컴파일러와 언어 개선에 투자함
• CFront는 전통적인 백엔드로 기계어를 만들지 않고 C 코드로 컴파일했으며, C++ 사용자가 새로운 인프라나 라이브러리를 전부 도입하지 않고 기존 C 환경을 유지할 수 있게 했음
• CFront는 1983년에 만들어졌고, 어휘 분석, 구문 분석, 타입 검사, 트리 표현 생성, 트리 최적화를 수행하는 실제 컴파일러였음
• C++라는 이름은 C의 ++ 연산자가 증가를 뜻한다는 점에서 나왔고, 의미상으로는 ++C가 맞지만 색인과 참조 편의를 위해 C++가 됨
• AT&T는 컴퓨터와 소프트웨어 사업에 뛰어들며 C++ 컴파일러 판매를 시도했지만 하드웨어가 충분히 팔리지 않았고, 초기 C++ 구현은 테이프 비용과 낮은 상업 사용료 수준으로 사실상 널리 배포될 수 있었음
• Stroustrup은 한동안 문서, 컴파일러, 언어 구현, 헬프데스크를 모두 맡았고, AT&T의 투자는 매우 작았으며 한 번은 범용 프로그래밍 언어 보급에 3년간 5,000달러가 배정됨
• CFront 2.0에서는 다중 상속 처리 버그가 발견됐고, 이미 약속한 핵심 기능이 현장에 나가면 고칠 수 없는 방식으로 깨질 수 있어 며칠 안에 수정본을 만들어 배포함
• 같은 릴리스 번호를 유지해야 했기 때문에 버전은 2.0.1 대신 2.0.0으로 배포됐고, 호환성은 농담처럼 “C word”라고 불릴 만큼 지배적인 요구가 됨

표준화와 STL

• C++는 AT&T 내부 생산성을 높이는 도구였지만, 단일 기업에 갇힌 언어로는 성공할 수 없었고 외부 개발자와 라이브러리 생태계가 필요했음
• 웹 이전에는 Usenet의 comp.lang.c++ 같은 그룹과 Byte 같은 컴퓨터 잡지가 정보 확산 경로였고, Stroustrup은 1980년대 후반 여러 회사와 조직에서 강연하며 언어를 알림
• 광고 캠페인이나 강력한 후원자 없이 사용이 늘었지만, Borland, Microsoft, IBM, Sun 등 여러 벤더가 각자 C++ 구현과 template 설계를 만들면서 코드 호환성이 심각하게 갈라짐
• IBM, HP, Sun을 대표한 사람들이 Stroustrup에게 ANSI 규칙 아래 C++ 표준화를 요구했고, Stroustrup은 너무 이르다고 봤지만 결국 1년 뒤 표준화 기반 문서를 만들기로 함
• Annotated Reference Manual, 즉 ARM은 표준화 입력 문서가 됐고, template, exception, namespace 같은 기능을 포함하는 방향으로 이어짐
• 표준은 C++ 코드를 쓰는 사람과 C++ 구현 사이의 계약으로 정의됐고, 여러 벤더가 같은 코드를 같은 의미로 받아들이게 만드는 장치가 됨
• Alexander Stepanov가 만든 STL은 알고리듬을 적용 가능한 모든 자료구조에서 동작하게 하고, 자료구조들이 서로 데이터를 채울 수 있게 하는 것을 중심 아이디어로 삼음
• STL 이전에는 각자 array, list, tree, container, 알고리듬 방식을 만들었지만, STL은 알고리듬과 컨테이너를 정의하는 하나의 강력한 방식을 제시함
• STL 제안은 표준화 일정상 너무 늦고 너무 크다는 반대를 받았고 Microsoft 등 주요 회사도 반대했지만, 발표와 논의를 거쳐 위원회 약 80%가 찬성하면서 표준에 들어감
• C++는 1997년 11월 표준화됐고, namespace, exception, template, Standard Template Library가 주요 기본 기능으로 추가됨
• LLVM은 이 표준화 이후 시작됐기 때문에 이전 코드 마이그레이션 부담 없이 새 기능을 의도된 방식으로 사용할 수 있었음

겨울과 C++11 르네상스

• C++는 1990년대에 CERN 같은 고에너지 물리 소프트웨어와 컴퓨팅 분야에서 Fortran 중심 개발을 바꾸는 언어가 됐고, 기존 라이브러리와 코드가 C++로 포팅되거나 C++에 맞게 다시 만들어짐
• 게임 개발에서는 비디오 카드와 API가 저수준 작업을 담당하면서 C와 어셈블리에서 C++로 올라가는 흐름이 생겼고, Unreal 같은 엔진 생태계에서 C++가 쓰임
• 금융에서는 프로그램 매매와 고빈도 매매가 등장하면서 마이크로초 단위 지연시간이 중요해졌고, C++는 모든 줄을 미세 최적화하지 않아도 낮은 지연시간을 얻을 수 있는 언어로 쓰임
• 2000년 닷컴 붕괴와 함께 Java가 Sun의 강한 마케팅으로 “미래의 언어”와 “인터넷의 언어”로 부상했고, Java는 C++의 복잡성에 대한 명시적 반응으로 등장함
• Microsoft 내부에서는 Visual Basic의 쉬운 폼 기반 개발과 C++의 성능·표현력을 결합하려는 욕구가 있었고, 그 결과 C#이 만들어짐
• 2000~2005년 사이에는 단순한 정체가 아니라 C++의 쇠퇴가 있었고, CPU 주파수가 계속 올라가던 시기라 많은 언어 설계자와 개발자는 성능을 덜 중요하게 봄
• 2004년경 프로세서 주파수 스케일링이 끝나고 단일 코어의 성능·전력 한계와 명령어 수준 병렬성의 수확 체감이 나타나면서, 하드웨어가 자동으로 프로그램을 빠르게 만들어주던 시대가 끝남
• 멀티코어와 병렬성이 중요해졌지만 당시 C++ 표준에는 threading이 전혀 없었고, Herb Sutter의 “C++ multi-threading: is the standardization committee listening” 메일이 이 문제를 부각함
• C++0X는 2002년에 시작됐고 2007~2009년 완료를 목표로 했지만, 중요한 기능을 더 넣기 위해 계속 지연되면서 13년이 걸림
• C++11은 move semantics, concurrency, auto, range-based for loop, smart pointer, lambda, constexpr 등을 도입했고, C 계열 언어 중 threading을 공식적으로 다룬 첫 표준이 됨
• C++11은 더 쉽고 안전한 언어 기능과 하드웨어 성능을 최대한 활용하려는 필요가 동시에 맞물리면서 르네상스가 됨
• 이후 정해진 시간에 표준을 내는 train model이 도입됐고, 위원회는 2년 주기 대신 3년 주기를 택함
• C++14는 C++11에 넣지 못한 사항과 버그 수정을 담은 작은 릴리스였고, C++17과 C++23에서는 많은 언어 및 표준 라이브러리 기능이 추가됨

현재의 규모와 과제

• C++는 복잡성이 계속 커졌고, 변수 초기화 방식이 여러 가지라는 비판과 “이해하기 어려운 복잡성”이라는 혹평을 받음
• 표준위원회도 커져 527명 규모가 됐고, 시작 당시 전체 구성원 수만큼의 위원회와 위원장이 생겼다는 우려가 있음
• 언어 설계에서는 추가는 가능하지만 제거는 거의 불가능하기 때문에, 무엇을 넣을지보다 언제 거절할지가 중요한 문제가 됨
• C++는 전력 생산, 풍력 터빈, 밥솥, 볼링장, 할리우드 영화, 자동차, 금융, 카메라 등 다양한 곳에 쓰이며, “대략 어디에나” 있다는 표현이 나옴
• HRT의 C++ 코드베이스는 100만 줄 이상, 15,000개 파일로 구성되어 있고, 2025년에만 약 800명의 개발자가 84,000개 커밋을 만들었음
• 게임에서는 Unity가 C#을 쓰는 반면 Unreal은 C++를 쓰며, Call of Duty처럼 높은 프레임률과 빠른 그래픽이 필요한 게임은 속도 때문에 C++를 사용함
• Nvidia와 가속 컴퓨팅에서도 C++는 중요하고, 표면에서는 Python을 쓰더라도 실제 계산 부담은 고도로 최적화된 CUDA 라이브러리가 담당함
• 빠르게 성장하는 언어로 Rust와 C++가 꼽혔고, C++ 개발자는 2022년 940만 명에서 2025년 1,630만 명으로 늘었다는 수치가 제시됨
• 성능 대비 전력 효율이 중요한 언어에 대한 수요가 계속되고 있어 C++는 뛰어나고 대체하기 어려운 사용처를 확보함
• 동시에 대형 플레이어들이 AI로 이동하면서 C++에 대한 자금이 줄어들 수 있다는 우려가 있음
• 팬데믹 기간 정부와 규제 기관에서 기본적으로 메모리 안전성을 제공하지 않는 C++에서 벗어나려는 움직임이 있었고, 메모리 안전성은 해결해야 할 가장 중요한 문제로 제시됨
• C++26에서는 소프트웨어 강화를 위해 초기화되지 않은 변수가 더 이상 undefined behavior가 아니게 되고, C++26 표준 라이브러리에서는 string, span, vector 같은 공통 타입에 bounds safety 옵션이 제공됨
• C++26의 static reflection은 프로그램 코드가 프로그램 코드를 볼 수 있게 하는 기능이며, 표준화된 단일 기능 중 가장 영향력이 큰 기능으로 평가됨
• AI가 언어 안전성과 프로그래밍 언어 사용 방식에 큰 영향을 줄 가능성은 있지만, 앞으로 어떤 일이 일어날지는 아직 알 수 없다는 결론으로 남음

[GN⁺]

Hacker News 의견들

• Ken Thompson이 C++를 일관성 없고 복잡한 아이디어 더미라고 비판한 말이 아직도 와닿음. 업무로 쓴 건 C++98이 마지막이고, 11/17/20은 호기심으로 조금 만져본 정도임
  c++/cfront가 C의 후광을 타지 않았다면 널리 쓰였을지 의심스럽고, 그 점이 정체성이면서도 C++가 바꾸려 하지 않은 한계였다고 봄. 컴파일러가 처리할 수 있었을 일을 Coverity/Valgrind 같은 도구로 구현을 정화하는 데 비슷한 시간을 쓰는 건 매우 짜증남
  C++98 시절에는 Bjarne의 내부 구조 책으로 무슨 일이 벌어지는지 꽤 이해할 수 있었지만, 이후에는 “effective, more effective, proficient, performant C++”류 책들이 산업처럼 불어나서, LLM이 나오기 전까지는 남이 쓴 기존 코드를 이해할 수 있다는 기대를 접어야 했음. 차라리 문제 영역을 배우는 데 시간을 쓴 게 만족스러움
  그래도 Kernighan, Stepanov 같은 좋아하는 인물들이 나와서 다큐멘터리는 볼 생각임

  • 잘 알려지지 않은 사실인데, Zortech C를 C++로 확장할지 고민하던 때 AT&T의 지식재산권이 걱정돼서 AT&T IP 변호사 Ryan Williams에게 연락했음
    C++ 컴파일러를 만들려면 라이선스가 필요한지, 이름을 C++가 아닌 다른 것으로 불러야 하는지 물었더니 웃으면서 마음대로 해도 된다고 했고, 허락을 물어본 컴파일러 사람이 나뿐이라며 고맙다고도 했음. 몇 년 전 부고를 봤는데, 괜찮은 사람이었음
  • C++ 성공의 발판은 Zortech C++ 였음. 당시 프로그래밍의 90%는 MS-DOS에서 이뤄졌고, cfront는 DOS에서 거의 못 쓸 수준이었음
    컴파일이 고통스러울 정도로 느렸고, 사소하지 않은 앱에 필수였던 near/far 포인터를 지원하지 않았음. Zortech C++가 그 문제들을 해결했고 불티나게 팔리면서 C++ 성공에 필요한 임계질량을 만들었음
    comp.lang.c++ 트래픽이 급격히 늘었고, Borland는 우리 판매량을 보고 자체 객체지향 언어 제품을 포기한 뒤 Turbo C++를 만들었음. Microsoft도 Borland의 성공을 보고 자체 C++를 만들었음
    Microsoft에도 Zortech C++ 컴파일러를 많이 팔았고, 그들은 그것으로 COM을 개발했음. Microsoft가 C*라는 자체 객체지향 C를 만들고 있다는 소문도 들었지만 확인한 적은 없음
  • 많이들 놓치지만, C++가 존재했기 때문에 C가 살아남았을 가능성이 큼. C++가 없었다면 C 자체에 더 많은 기능을 넣으라는 압력이 엄청났을 것임
    C 위원회가 오랫동안 많은 것을 추가하지 않고 버틸 수 있었던 이유 중 하나는 C++를 가리키며 “그건 저쪽 일이지 우리 일이 아니다”라고 할 수 있었기 때문임. C++가 없었다면 C가 클래스, 템플릿, 람다를 가진 어떤 언어가 됐을지 알 수 없음
  • C++98은 C++11과도 꽤 다름. Bjarne의 C++11 책은 98판과 완전히 다르게 읽혔음
  • Ken Thompson과 옛 UNIX 인물들을 매우 존경하지만, 현실 세계는 지저분하고 고립된 최선의 해법이 항상 이기지는 않는다는 점은 그들도 인정하지 않을까 싶음
    그들이 만든 C와 UNIX도 더 진보된 LISP와 Smalltalk 시스템을 이겼는데, 구현이 더 단순했기 때문임. 그들 자신의 더 진보된 Plan 9 기반 운영체제조차 더 널리 퍼진 유닉스 계열 시스템을 밀어내지 못했음
    결국 배포력과 “충분히 좋음”이 늘 이기는 듯함. Perl, Python, Ruby, JavaScript, PHP 같은 동적 언어와 강하게 마케팅된 Java가 충분히 좋은 고수준 기능을 제공하면서 사람들이 Lisp와 Smalltalk로 가지 않게 만들었다고 봄
    이런 관점에서는 C++가 널리 채택된 저수준 고성능 언어에 고수준 기능을 얹어, 광범위한 채택에 충분히 좋은 기술로 만든 수단이었을 수 있음

• 요즘 C++로 많이 일하고 있어서 빌드가 끝나길 기다리며 영상을 보기로 했음. 길이가 딱 맞았고, 다행히 영상도 아주 좋았음

  • C++ 역사에 관해 읽을 수 있는 건 최대한 읽어왔고, 이 영상도 기대됨. C++가 진화해 온 과정이 정말 흥미롭다고 느낌
  • 이게 그냥 장난 글인지, 아니면 빌드가 실제로 한 시간쯤 걸리는 건지 궁금함. 그렇다면 정말 말도 안 됨

• 개인적으로 C++는 15년 정도 써본 언어 중 가장 우아한 언어임. “체계화하는 사람” 유형이고, 마지막 비트까지 자신이 쓴 것에 대해 극도로 정밀한 정신 모델을 갖고 싶다면 C++만 한 게 없음
  컴파일러 등에서 오는 한계와 불확실성은 인정하지만 그래도 그렇다고 봄

  • 어떤 대상에 대한 정밀한 정신 모델을 말하는지 예를 들어줄 수 있나?
  • 같은 말은 Rust에도 할 수 있다고 봄
  • 우아한 언어란 아주 적은 것으로 많은 것을 해내는 언어임. Forth와 Scheme이 우아한 언어임
    C++로 일하는 걸 좋아할 자유는 있고, C++로 많은 것을 이룰 수 있는 것도 맞지만, C++가 “아주 적은 것”으로 그걸 해낸다고 보기는 어렵다는 데는 논란이 크지 않을 듯함

• 이 다큐멘터리에 Andrei Alexandrescu가 포함돼서 반가움. 그의 _Modern C++ Design_은 읽을 당시 사고를 확 열어준 책이었고, 지금도 그럴 수 있음. 읽어본 사람 있나?

  • 그의 강연은 내가 가장 좋아하는 강연들 중 일부임. 훌륭한 발표자이고, 몰입감이 좋으며 유머 감각도 뛰어나 그걸 아주 잘 활용함
  • 아직도 재미있지만, Andrei의 책들은 내가 여러 해 동안 C++에서 멀어지게 만든 마지막 한 방이었음. 정말 좋은 책들이었고, 동시에 다른 언어로 넘어가고 싶다는 생각을 굳히게 해줬음. 당시에는 Go였음
  • 동의함. _Modern C++ Design_은 아마 내 커리어에서 가장 많은 것을 얻은 프로그래밍 책임
  • 나도 같은 느낌임. 뮌헨 Meetup에서 Andrei를 한 번 만났고, 그가 내게 생각하는 법을 가르쳐줬다고 말했더니 대화가 약간 어색해졌음. 그래도 즐거운 시간이었음
  • 최근에 읽었음. 몇몇 장이 좋았고, 특히 정책 클래스가 객체지향 설계의 일부 문제를 어떻게 고치는지 흥미로웠음
    각 장을 AI 챗봇에 요약시키고 현대적 대응물이 무엇인지 물어보길 권함. 일부 관용구는 이미 개선됐고, 한 섹션 전체는 std::variant와 std::visit 사용으로 대체된 듯했음

• C++는 사라져야 함. 많은 사람이 투자했고 엄청난 코드가 C++로 쓰였다는 건 이해함. 예전엔 팬이었고 지금도 주 업무 언어지만, 2026년에 LLM이 모든 취약점을 찾을 수 있고 공격자도 늘어나는 상황에서는 안전이 기본값인 언어가 필요함
  C++는 안전을 얻으려면 선택적으로 켜고 극도의 경계가 필요한 언어임. 작동하지 않고, 수십 년의 경험이 그걸 증명함

  • 그럼 무엇으로 대체해야 하나?
  • LLM이 소스 코드 없이도 모든 취약점을 찾는다면, 코드가 있을 때는 더 쉽게 찾지 않겠나?
  • C++는 그 시대에는 훌륭한 언어였음. 그만큼 강력한 추상화를 제공하면서 더 빠른 언어는 없었음. C++11에서 shared_ptr 같은 것들이 들어오며 언어를 얼마나 크게 바꿀 수 있는지도 보여줬음
    거의 모든 아이디어를 받아들였고, 전장에서 무엇이 통하고 무엇이 안 통하는지 알게 됐음. RAII, 이동과 복사 구분, 스마트 포인터, placement-new, 제네릭은 남길 수 있음
    반대로 auto_ptr, 기본 복사, 특정 예외 구현 방식, 다중 가상 상속, 코드를 통째로 치환하는 템플릿은 버릴 수 있음. 내 생각에는 싸움은 끝났고, Rust가 작동한 것들을 가장 잘 정리한 결과임. 컴파일 시간까지 물려받은 건 덤임

• C++ 개발 흐름이 계속되는 게 놀라움. 게임이나 프로그램이 C++로 만들어지면 보통 성능이 대체로 보장돼서 좋지만, 직접 C++를 쓰라고 하면 울 것 같음
  외울 게 너무 많고 표준도 너무 다양함. 유지보수하러 간 프로젝트가 C++이면 곧바로 기운이 빠짐. 그냥 너무 어려움. 남이 작성해주면 좋겠지만, 직접 쓰고 싶은 언어는 아님

  • 개인적으로 C++ 프로그래밍이 그렇게 어렵다고 느끼지는 않음. 단점은 두뇌 예열이 필요하다는 점이고, 프로젝트마다 다시 해야 하지만 일단 플라이휠이 돌기 시작하면 거의 힘들이지 않고 코드를 쓰게 됨
    어떤 언어를 쓰든 비슷한 예열은 필요해서, 내게는 Python, Go, Java를 쓰는 것과 크게 다르지 않음
  • 게임에서는 C++가 훨씬 단순한 언어가 됨. 게임 코드베이스는 보통 C++ 표준 라이브러리를 대부분 무시하기 때문이고, 그럴 만한 이유도 있음. 예를 들면 [0] 참고
    표준 라이브러리 없이 보면 C++는 그럭저럭 괜찮은 편임
    C++ 생태계의 주된 문제는 모두가 자기만의 언어 부분집합을 깎아 만든다는 데 있음. 그래서 하나의 생태계가 아니라, 서로 충돌하는 스타일과 언어/표준 라이브러리 부분집합을 가진 여러 생태계가 됨. 이 때문에 라이브러리를 통한 코드 재사용이 필요 이상으로 어려워짐
    [0] https://hftuniversity.com/post/the-c-standard-library-has-be...
  • C++에 기능이 많은 건 맞음. 하지만 다른 곳에서도 말했듯 대부분 프로젝트는 자체 규칙과 사용하는 기능 부분집합을 정함
    기능 집합이 큰 장점은 C++가 매우 저수준부터 매우 고수준까지 좋은 추상화를 쓸 수 있게 해준다는 것임. 인라인 어셈블리, 비트 연산, 직접 메모리 조작 같은 저수준도 가능하고, 거의 스크립트 언어처럼 고수준으로도 쓸 수 있음. 문제 영역이 무엇을 요구하든 C++로 감당할 수 있음
  • 언어의 70%만 알아도 꽤 생산적으로 쓸 수 있음. C++가 게임 엔진 같은 영역에만 적합하다는 건 흔한 오해이고, 애플리케이션 영역에도 충분히 괜찮음
    덧붙여 프로필 정보를 보면, 북한에 있는 게 아니라면 단가에 0 하나는 더 붙이는 게 좋겠음. 그래야 더 장기적이고 품질 높은 고객을 얻을 수 있음
  • 취미 중 하나가 중고품 가게를 뒤지며 지나간 시대의 촌스러운 물건을 감상하고, 잘못 만들어진 현대 잡동사니를 걸러내고, 찾을 수 있다면 단순하고 튼튼한 도구에 기뻐하는 것임
    C++ 프로그래머로 산다는 게 딱 그런 느낌임

• 웹 개발자들을 가르칠 때마다 인터넷의 언어는 JavaScript가 아니라 C++ 라고 말함. 웹 개발자들은 C++ 개발자가 만든 프로그램 안에서 노는 사용자일 뿐임

  • 그 비유를 이어가면, 브라우저 개발자는 C/운영체제/커널 프로그램 안에서 노는 사용자일 뿐임
  • 나는 웹과 인터넷을 서로 다른 것으로 보는 편임. 웹의 언어라면 아마 HTML을 꼽겠음
    인터넷의 언어가 무엇인지는 훨씬 덜 명확함

• 내가 열정을 가진 주제의 무료 다큐멘터리는 정말 좋음. 고마움
  다만 나는 좀 특이해서, 사람들이 짧은 문장을 이어 말하는 방식으로 만든 다큐멘터리는 볼 수가 없음. “그들이 이야기를 들려주게 한다”는 의도는 이해하지만, 산만해지기 때문에 무엇을 생각해야 할지 말해주는 내레이터가 필요함
  그래도 제작자들에게는 애정을 보냄

• 요즘 흐름을 놓쳤는데, 최근 Python, Clojure, 그리고 아마 다른 언어 다큐도 있었음. 같은 사람들이 여러 언어를 다루는 시리즈를 만드는 건가? 우연인가? 아니면 이제 모든 프로그래밍 언어가 자기 영상 다큐멘터리를 만들려고 달려드는 추세인가?

  • 맞음, 같은 사람들이 만든 것임: https://www.cultrepo.com/
    오픈소스 소프트웨어에 대한 다큐멘터리를 만드는 듯함

• 이 주제에 대한 Chandler Carruth의 흥미로운 생각이 있음: https://hachyderm.io/@chandlerc/116694268329657881

  • 일리가 있음. 영상은 확실히 성인전에 더 가까워 보였고, 비판적 목소리가 부족하다는 점도 느꼈음
    마지막 10분에서야 커지는 복잡성이나 메모리 안전성 같은 흔한 비판을 조금 다뤘음. 그래도 즐겁게 보긴 했음