C++: Some Assembly Required
📺 원본 영상: C++: Some Assembly Required - Matt Godbolt - CppCon 2025 🎙️ 채널: CppCon 📅 정리 일자: 2026-04-11 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. Compiler Explorer 라이브 데모, 레지스터 다이어그램, WG21 조직도 등 화면에 표시된 시각 자료는 포함되지 않을 수 있으므로, 상세 내용은 원본 영상을 확인하세요.
개요
CppCon 2025의 마지막 강연자로 나선 Matt Godbolt는 Compiler Explorer(godbolt.org)의 창시자로 잘 알려진 인물이다. 그는 이 강연에서 “assembly”라는 단어의 사전적 의미 여섯 가지를 하나씩 짚어가며, 어셈블리 언어(assembly language) 그 자체를 넘어 C++이라는 언어를 떠받치는 모든 것—라이브러리 생태계, 빌드 도구, 표준위원회, 그리고 커뮤니티—을 “어셈블리”의 한 형태로 풀어낸다. 단순한 기술 발표가 아니라 C++ 개발자 모두에게 보내는 참여의 초대장이기도 한 이 강연은, 40년의 프로그래밍 여정이 담긴 개인적 서사와 실용적인 기술 인사이트가 촘촘하게 엮여 있다.
1. 한 프로그래머의 어셈블리 여정
1986년 런던 교외의 차고 방
강연은 Matt Godbolt의 어린 시절 사진 한 장으로 시작된다. 1986년, 런던 남서부의 차고를 개조한 방에서 그는 당시 열 살 남짓의 나이에 ZX Spectrum 앞에 앉아 있었다. 단열재도 없이 추운 그 방에서, 그는 잡지나 책에 실린 프로그램 코드를 직접 손으로 타이핑해 카세트 테이프에 저장하는 방식으로 프로그래밍을 익혔다. 타이핑 실수로 프로그램이 작동하지 않으면 직접 오류를 찾아야 했는데, 강연자는 이를 “디버깅 예술에 대한 나의 첫 번째 입문”이었다고 회고한다.
처음에 게임들은 BASIC으로 작성되었지만, 점차 더 정교해지면서 BASIC만으로는 충분하지 않게 되었다. 그 한계를 넘어서려면 어셈블리(assembly language)를 써야 했고, 그 시점이 그가 어셈블리의 중요성과 가능성을 처음 깨달은 순간이었다.
BBC Micro, 아키메데스, 그리고 상업적 첫 발걸음
이후 그는 BBC Micro와 아키메데스(Archimedes) 컴퓨터로 넘어갔다. 이 컴퓨터들은 ARM 프로세서를 사용하는 기기였는데, ARM은 지금은 전 세계 모바일 기기를 지배하는 아키텍처이지만 당시에는 영국의 한 소규모 회사(Acorn)가 만든 비교적 생소한 칩이었다. 열네다섯 살이 되었을 무렵 그는 이미 잡지에 프로그램을 투고하는 수준이 되었고, 그 댓가로 프로그램당 50파운드를 받았다. 1994년 기준으로 15살 학생에게는 꽤 큰 돈이었다. 이 프로그램들은 전부 순수 어셈블리로 작성되었으며, 잡지에는 약 20페이지 분량의 작은 글씨로 인쇄되어 독자들이 직접 타이핑해야 하는 형태였다.
IRC 클라이언트: 어셈블리로 구현한 네트워크 애플리케이션
인터넷을 발견한 후, 그는 자신의 아키메데스 컴퓨터용 IRC(Internet Relay Chat) 클라이언트가 존재하지 않는다는 사실을 알게 되었다. 그래서 직접 만들었다. 이 클라이언트는 TCP 통신, 메시지 파싱, 직접 클라이언트 간 파일 전송, 그리고 자체 제작한 BASIC 기반 스크립팅 언어까지 갖추고 있었다. 동적 메모리 할당을 구현하면서 참조 카운팅(reference counting)을 도입했는데, 순환 참조(cycle) 문제를 발견하고 직접 해결책을 고안했다. 훗날 친구에게 이 이야기를 했을 때 친구가 말했다. “그거 Mark-and-Sweep 가비지 컬렉션 아니야?” 그는 물리학과 재학 중이었고 컴퓨터 과학 이론을 전혀 모른 상태에서 독자적으로 이를 발명한 것이다. 이 클라이언트의 모든 코드는 100% 어셈블리였으며, 아직도 GitHub에서 찾아볼 수 있다고 한다. 코드에는 “Womble Loop Jedi” 같은 수수께끼 같은 레이블 이름들이 즐비하다.
MUD에서 C로, 그리고 C++로
대학 시절 그는 “XeniaMUD”라는 멀티유저 던전(Multi-User Dungeon) 서버를 운영했다. 이 MUD의 소스코드는 C 언어, 그것도 표준화 이전(pre-ANSI) 형식으로 작성된 코드였다. 대학 측에서 장기 프로세스 실행을 금지하자 여러 시스템을 전전하게 되었는데, 바로 이 경험을 통해 C의 이식성(portability)이 어셈블리보다 얼마나 큰 강점인지를 피부로 실감했다. 아키텍처가 달라질 때마다 어셈블리를 다시 작성하는 것은 불가능에 가까웠기 때문이다. 이후 게임 산업에 취직해서도 C와 C++이 주력 언어였고, 컴파일러가 아직 미숙하던 시대에는 게임 성능 최적화를 위해 여전히 어셈블리 코드를 손으로 작성해야 했다. Dreamcast 게임 “Red Dog: Superior Firepower”의 코드가 그 시절의 흔적으로 슬라이드에 등장하는데, 어린 시절의 코드보다 훨씬 나아졌고 주석도 제대로 달려 있다는 것이 그의 자평이다.
Compiler Explorer의 탄생
금융 업계로 이직한 후 어느 날, 그는 상사와 range-based for 루프가 기존 인덱스 기반 for 루프와 성능이 같은지를 두고 논쟁을 벌이게 되었다. 벤치마크만으로는 결론이 나지 않자, 그는 간단한 쉘 스크립트를 만들어 Vim에서 코드를 편집하면 오른쪽 터미널에 어셈블리 출력이 실시간으로 갱신되도록 했다. 정규식으로 노이즈를 제거하고 c++filt로 파이핑하니 꽤 쓸 만한 도구가 되었고, 그 순간 “이거 뭔가 있다”라는 직감이 들었다. 그렇게 Compiler Explorer가 탄생했다.
2. 어셈블리 언어란 무엇인가
기계어와 어셈블리 언어의 차이
강연자는 먼저 흔히 혼용되는 두 용어를 명확히 구분한다. **기계어(machine code)**는 0F AF FF와 같은 바이트 시퀀스로, CPU가 직접 읽고 실행하는 숫자들의 나열이다. 반면 **어셈블리 언어(assembly language)**는 그 기계어를 사람이 읽을 수 있는 형태로 표현한 것으로, 두 사이에는 (일부 예외를 제외하면) 1:1 대응 관계가 존재한다. 어셈블러(assembler)는 어셈블리 언어를 기계어로 변환하고, 역어셈블러(disassembler)는 그 반대 방향으로 변환한다. 컴파일 과정에서 주석이나 표현식은 당연히 사라진다.
세 아키텍처 비교: Intel x86, ARM, RISC-V
강연자가 예시로 사용하는 함수는 정수를 받아 제곱값을 반환하는 단순한 square 함수다.
17:34 - Compiler Explorer에서 square 함수의 Intel x86 / ARM / RISC-V 어셈블리 출력 비교 화면. 각 아키텍처별 명령어 수와 고정 4바이트(ARM) vs 가변 길이(x86) 차이가 시각적으로 드러남
**Intel x86(Linux/System V ABI)**의 경우, 입력값은 EDI 레지스터로 들어온다. IMUL EDI, EDI 명령어가 EDI × EDI를 수행하며 결과를 EDI에 저장하는데, 문제는 System V ABI에서 반환값은 반드시 EAX 레지스터에 있어야 한다는 것이다. 그래서 불필요해 보이는 MOV EAX, EDI 명령이 뒤따른다. x86 명령어의 특성상 대부분의 명령어는 두 개의 피연산자를 가지며, 왼쪽 피연산자가 소스이자 목적지가 되는 파괴적 연산(destructive operation) 구조다.
ARM의 경우는 훨씬 단순하다. 모든 명령어가 정확히 4바이트로 고정되어 있어 처리하기 편리하고(x86은 명령어마다 길이가 다르다), 첫 번째 파라미터이자 반환값 레지스터가 모두 W0이기 때문에 MUL W0, W0, W0 한 줄로 정수 제곱이 완성된다. RISC-V도 비슷한 깔끔함을 보여준다.
ABI: 누가 어느 레지스터를 쓰는가
ABI(Application Binary Interface)는 함수 호출 시 어느 레지스터에 어떤 값을 담을지에 대한 약속이다. 강연자는 Compiler Explorer 출력을 읽을 때 이 ABI를 파악하는 것이 가장 중요하다고 강조한다.
| 아키텍처 | 첫 번째 파라미터 | 반환값 | 주요 특징 |
|---|---|---|---|
| Intel x86 (Linux) | RDI | RAX | 최대 6개 정수 파라미터 레지스터 |
| Intel x86 (Windows) | RCX | RAX | 최대 4개 파라미터 레지스터 |
| ARM64 | X0 | X0 | X0~X7까지 8개, 30개의 범용 레지스터 |
| RISC-V | a0 | a0 | 레지스터에 역할명 부여 (t=임시, s=저장, a=인수) |
Intel의 경우 RAX는 64비트, EAX는 그 하위 32비트, AX는 하위 16비트, AH/AL은 각각 8비트 상위/하위로 같은 물리적 레지스터를 다른 이름으로 접근하는 구조다. 이는 8080 시절의 누산기(accumulator) 레지스터 A에서 수십 년에 걸쳐 확장된 결과다.
21:03 - Intel x86 레지스터 이름 체계 슬라이드. RAX(64비트) → EAX(32비트) → AX(16비트) → AH/AL(8비트) 계층 구조와 R8~R15 신규 레지스터 명명 규칙
강연자는 “이 레지스터들을 절대 외우지 못하겠다”며 모니터 왼쪽 하단에 포스트잇을 붙여두고 참고한다고 솔직하게 인정하는데, 이를 해결하기 위해 Compiler Explorer 공식 머그컵에 ABI 요약표를 새겨 판매하고 있다고 너스레를 떤다.
한 가지 더 주의할 점은, 멤버 함수를 호출할 때 this 포인터도 첫 번째 레지스터(RDI)로 전달되어 실제 첫 번째 인수는 그다음 레지스터(RSI)로 밀려난다는 것이다. 반환값 최적화(RVO)가 적용될 때는 컴파일러가 결과를 저장할 주소를 은밀한 첫 번째 파라미터로 전달하기도 한다.
3. Compiler Explorer 라이브 데모
분석 대상 코드: is_valid_identifier
강연자가 라이브 데모에서 사용하는 예제는 16자리 16진수 문자열(0-9, A-F)의 유효성을 검사하는 is_valid_identifier 함수다. 이 함수는 std::string_view를 인자로 받는데, string_view는 내부적으로 포인터와 크기 두 개의 멤버를 가진 구조체다. ABI 규칙에 따라 이 두 값은 첫 번째와 두 번째 레지스터로 분해되어 전달된다.
28:16 - is_valid_identifier 함수를 GCC 15.2 O1으로 컴파일한 Compiler Explorer 화면. C++ 코드와 어셈블리 코드 간 색상 하이라이팅 대응 관계 시연
최적화 레벨별 비교 (O1 → O2 → O3)
O1에서는 먼저 크기가 16인지 확인하고, 아니면 즉시 EAX에 0(false)을 넣고 반환하는 구조가 명확하게 보인다. 이후 STL 내부 함수들이 인라인(inline)되면서 memchr 호출이 코드 중간에 등장하는 것을 볼 수 있다. 강연자 자신도 find_first_not_of가 내부적으로 memchr을 사용한다는 사실을 몰랐다고 솔직하게 말한다.
O2로 올리면 코드 구조는 유사하지만 양이 줄어든다. L4 레이블로 점프하는 JNE L4 패턴이 보이는데, 강연자는 루프를 찾을 때 항상 이런 “레이블 + 역방향 점프” 패턴을 먼저 찾는다고 설명한다. 이 지점이 내부 루프의 핵심이며, 포인터가 얼마씩 이동하는지를 보면 한 번에 몇 개의 원소를 처리하는지 파악할 수 있다.
O3에서는 흥미로운 변화가 일어난다. 루프가 사라지는 대신 memchr 호출 코드가 16번 펼쳐진다(loop unrolling). 입력이 정확히 16자임을 이미 검증했기 때문에, 컴파일러가 루프를 완전히 풀어버린 것이다. 이는 루프 오버헤드를 없애지만, 명령어 캐시(instruction cache)를 많이 소비할 수 있다는 트레이드오프가 있다. O2의 루프 방식이 더 나은지, O3의 언롤링이 더 나은지는 memchr이 루프 내에서 호출된다는 점을 고려하면 단순히 판단하기 어렵다.
30:16 - O3 최적화 결과 화면. memchr 호출이 16회 언롤링(loop unrolling)된 어셈블리 출력
GCC vs Clang: 비트 조작 기법
Clang으로 바꾸자(라이브 데모 중 버전 트러블로 잠시 혼란이 있었지만), 전혀 다른 접근법이 등장한다. memchr이 사라지고 복잡해 보이는 비트 연산 명령어들이 나타난다. Compiler Explorer가 팝업으로 BT 명령어를 “bit strings에서 특정 비트를 선택(select the bit in a bit string)“한다고 설명해 준다.
32:08 - Clang 21 x86 최적화 화면. BT(Bit Test) 명령어를 활용한 비트 마스크 기반 문자 유효성 검사 기법. 의심스러운 64비트 상수(bitmask)가 화면에 표시됨
Clang이 선택한 방식은 우아한 비트 조작 기법이다. 각 문자(0-9, A-F)가 유효한지를 64비트 정수의 특정 비트 위치로 인코딩해 놓고, ASCII 값을 시프트하여 해당 비트가 설정되어 있는지 BT 명령어로 확인한다. 즉, 룩업 테이블을 하나의 64비트 상수로 압축한 것이다. 이처럼 컴파일러마다 같은 코드에서도 전혀 다른 최적화 전략을 선택한다는 점이 Compiler Explorer 탐구의 묘미다.
Claude Explain: AI 기반 어셈블리 해설 기능
강연자는 Compiler Explorer에 새로 추가되는 “Claude Explain” 기능을 시연한다. 코드와 어셈블리 출력을 LLM에 제출하면 어셈블리 코드에 주석을 달고, 레지스터 역할을 설명하며, 컴파일러가 사용한 최적화 기법을 자연어로 풀어준다. 비트 테스트 기법의 경우, AI는 “유효 문자 여부를 64비트 값의 한 비트로 인코딩한 뒤, ASCII 값을 시프트해 해당 비트가 설정되었는지 확인한다”고 정확하게 설명했다.
34:32 - Compiler Explorer의 ‘Claude Explain’ 베타 기능 데모. 어셈블리 코드에 AI가 주석을 달고 비트 조작 최적화 기법을 자연어로 설명하는 화면
다만 강연자는 이 기능에 대해 몇 가지 중요한 경고를 덧붙인다. 완전한 동의하에만(full consent) 사용되어야 하며, 비용이 많이 들거나 오해를 유발하는 것으로 판명되면 언제든 제거될 수 있는 베타 기능이다. “제가 의도한 것보다 훨씬 자신감 있게 말한다”는 점도 주의해야 한다. 이와 함께 그는 AI를 맹목적으로 신뢰하지 말라는 당부로 자신의 차량이 오솔길(bridle path)에 박혀 네다섯 시간 동안 갇혔던 에피소드를 들려준다. 내비게이션의 자신감 넘치는 안내를 그대로 따랐다가 사유 도로로 진입하고 만 것이다. 이후 그는 OpenStreetMap에서 직접 해당 도로를 차량 통행 불가로 수정했다고 한다.
4. C++ 생태계의 어셈블리: 조각들의 결합
STL의 탄생: Alexander Stepanov의 제네릭 프로그래밍
강연자는 “assembly”의 두 번째 의미—“조각들이 함께 작동하는 집합”—로 넘어가며 C++ 생태계를 구성하는 라이브러리들의 이야기를 시작한다. 그 출발점은 STL(Standard Template Library)이다.
Alexander Stepanov는 1970년대 후반~1980년대 초반부터 “모든 시대에 통용되는 정렬 알고리즘을 한 번만 작성하겠다”는 목표로 제네릭 알고리즘(generic algorithm)을 연구해 왔다. 1981년 GE 재직 시절 최초의 논문을 쓸 때는 자신이 직접 고안한 Tecton이라는 언어를 사용했고, 이후 Scheme, Ada를 거쳐 마침내 C++으로 정착했다. 흥미로운 사실은 그가 처음에는 Bjarne Stroustrup과 템플릿 인스턴스화 방식에 대해 논쟁을 벌였다는 점이다. Stepanov는 Ada처럼 명시적 인스턴스화(explicit instantiation)가 옳다고 주장했지만 Bjarne은 암묵적 인스턴스화(implicit instantiation)를 고집했고, 훗날 Stepanov 스스로 “암묵적 인스턴스화 없이는 STL이 존재할 수 없었을 것”이라고 인정했다.
1994년 1월, C++ 표준화가 진행 중이던 시점에 Andrew Koenig가 Stepanov에게 표준화 제안서 작성을 요청했다. 마감은 불과 20일 후였다. Stepanov와 그의 동료 Meng Lee는 주 80시간을 일하며 전체를 재작성하고 수많은 버그를 수정해 제안서를 완성했다. 이 제안서는 지금까지도 C++ 위원회가 수용한 가장 큰 제안으로 기록되며, 80% 찬성으로 통과되었다. 강연자는 “그때 기준이 낮았거나, 정말 대단한 작업이었거나 둘 중 하나”라며 웃음을 자아낸다.
Boost와 Beman 프로젝트
1999년 처음 공개된 Boost 프로젝트는 고품질 C++ 라이브러리들의 실험장 역할을 해왔다. 오늘날 표준 라이브러리의 상당 부분—ranges(Eric Niebler), format(Victor Zverovich), date library(Howard Hinnant), span, mdspan 등—이 Boost 또는 개인 프로젝트에서 시작되어 표준화의 과정을 거쳤다. 특히 mdspan은 GPU 벤더들과 대규모 HPC 설치 업체들로 구성된 대형 컨소시엄의 지원을 받았다는 점에서 독특한 사례다.
2020년 Boost 공동 창립자 Beman Dawes가 세상을 떠났고, 그를 기리는 뜻에서 David Sankel이 2024년 Beman 프로젝트를 시작했다. Boost와 달리 Beman 프로젝트에 포함되는 모든 라이브러리는 표준 편입을 목표로 하며, 기여자들에게 표준 라이브러리 병합과 제안서 작성에 대한 상당한 지원을 제공하는 빠른 트랙(fast track)을 지향한다. 강연자는 optional<T&> 같은 기능이 곧 실현될 것에 기대감을 표했다.
5. 빌드의 과정으로서의 어셈블리
컴파일러, 에디터, 빌드 시스템, 패키지 관리자
“assembly”의 세 번째 의미—“조각들을 조립하는 과정”—는 C++ 코드를 실행 가능한 바이너리로 만드는 전체 과정을 의미한다. GCC, Clang, MSVC, EDG 등 다양한 고품질 컴파일러가 있고, 처음 C++ 컴파일러가 C 코드를 생성하는 트랜스파일러(CFront)였던 시절에서 얼마나 멀리 왔는지를 강연자는 환기시킨다.
빌드 시스템의 다양성은 다른 언어와 비교해 C++의 가장 뚜렷한 특징 중 하나다. Rust나 Go처럼 빌드 시스템이 컴파일러와 함께 딸려오는 방식과 달리, C++는 CMake, Make, Bazel, Pixi(이번 컨퍼런스에서 처음 알게 됐다고 한다) 등 선택지가 방대하다. 이는 때로는 혼란스럽지만, 프레임워크가 지원하지 않는 요구사항에 부딪혔을 때 유연하게 대처할 수 있다는 장점이기도 하다.
패키지 관리 측면에서는 tarball, Git 서브모듈, vcpkg, Conan, CPM(CMake 기반 패키지 매니저) 등이 언급된다. 완벽한 해결책은 없지만 선택지는 늘어나고 있다는 것이 강연자의 평가다.
프로젝트의 접근성과 사람의 중요성
강연자는 기술적 도구들보다 더 중요한 것은 사람이라고 역설한다. Compiler Explorer를 14년 넘게 유지보수하면서, 프로젝트에 기여하는 자원봉사자들을 유지하는 일이 얼마나 어려운지를 배웠다고 한다. 핵심은 단순하다. 프로젝트를 쉽게 빌드할 수 있어야 한다. git clone 후 make 한 번으로 빌드가 되는 프로젝트에는 외부 기여자들이 버그를 발견하면 스스로 수정해서 PR을 보내는 선순환이 일어난다. 반대로 설치 절차가 복잡하면 아무도 기여하지 않는다. 이는 AI 에이전트가 코드베이스를 탐색할 때도 마찬가지라는 통찰을 덧붙인다.
6. C++ 표준위원회: 입법 기관으로서의 어셈블리
WG21의 복잡한 계보
“assembly”의 네 번째 의미—“입법 기관”—는 C++ 표준위원회인 WG21(Working Group 21)로 연결된다. WG21은 ISO/IEC JTC1/SC22 산하의 작업 그룹으로, 정확한 공식 명칭은 ISO/IEC JTC1/SC22/WG21이다. 강연자는 자신이 항상 “WG22”라고 잘못 말했다며 자기 자신을 사기꾼 취급하는 농담을 던진다.
C++ 위원회는 같은 SC22에 속한 COBOL, Fortran, Ada, C, Prolog 등의 다른 언어 작업 그룹들과 비교해 압도적으로 크다. WG21 내부에는 다시 핵심 작업 그룹(Core WG), 라이브러리 진화 작업 그룹(LEWG), 진화 작업 그룹(EWG), 그리고 수많은 연구 그룹(SG)들이 있다. 활성화된 그룹들 중에는 미정의 동작(undefined behavior)을 다루는 그룹도 있는데, 강연자는 청중을 향해 “undefined behavior에 시달리는 분 손들어 보세요”라고 묻다가 “아, 저는 아닌데요”라고 슬쩍 덧붙여 웃음을 얻는다.
59:01 - WG21 조직 구조 슬라이드. ISO/IEC JTC1/SC22 산하의 C++ 작업 그룹과 활성/비활성 하위 연구 그룹(SG)들의 전체 계층도
표준화 과정: 아이디어에서 C++32까지
아이디어가 C++ 표준에 반영되기까지의 여정은 길고 험하다. 먼저 제안서(paper)를 작성해 메일링 리스트(reflector)에 제출하면, 해당 분야의 연구 그룹(SG)에서 전문가들의 검토와 반복적인 수정이 이루어진다. 충분히 성숙해지면 라이브러리 기능은 LEWG, 언어 기능은 EWG로 넘어가 더 넓은 검토를 받는다. 최종적으로 핵심 그룹에서 표준 문서의 워딩이 수정되고, 전체 위원회의 총회(plenary) 투표를 거쳐 C++32나 C++35 같은 미래 버전에 포함된다. 이 과정에서 위원회 구성원들이 쏟아붓는 시간과 노력은 경이로운 수준이라고 강연자는 경의를 표한다.
타 언어 거버넌스와의 비교
Rust는 공식 스펙 문서 대신 컴파일러 내의 테스트 모음(test suite)이 사실상의 표준 역할을 한다. 구현과 스펙이 일치하므로 변경을 빠르게 반영할 수 있는 대신, 단일 구현에 종속된다. Python은 오랫동안 Guido van Rossum이 “자비로운 종신 독재자(Benevolent Dictator for Life)“로서 결정권을 가졌지만 2018년 은퇴 후, 5인 운영위원회와 PEP(Python Enhancement Proposal) 프로세스로 전환했다. JavaScript는 ECMA라는 표준 기구가 있지만 실질적으로는 브라우저 벤더들 간의 합의로 방향이 결정된다. C++의 공식적이고 다소 느린 프로세스는 이들과 대조적이지만, 그 대신 수십 년에 걸친 안정성과 하위 호환성이라는 강력한 가치를 제공한다.
7. 커뮤니티: 모임으로서의 어셈블리
컨퍼런스의 회복과 성장
“assembly”의 다섯 번째 의미—“공통 목적을 위해 한 자리에 모인 사람들”—는 청중들 자신을 가리킨다. 강연자는 팬데믹으로 잠시 위축되었던 C++ 컨퍼런스가 빠르게 회복해, 2025년에는 사상 최고인 11개의 주요 국제 C++ 컨퍼런스가 열렸다는 사실을 공유한다.
컨퍼런스의 가치는 비단 강연 콘텐츠에만 있지 않다. “복도 트랙(hallway track)“—공식 세션 사이 우연히 이루어지는 대화들—이나, 유튜브로 찾아볼 생각을 하지 않았을 강연에 우연히 발걸음을 옮기는 경험이 컨퍼런스에서만 얻을 수 있는 것들이다.
밋업과 온라인 커뮤니티
컨퍼런스에 참석할 수 없다면, 전 세계 133개 이상의 C++ 밋업이 대안이 된다. 강연자는 밋업의 형식이 얼마나 유연한지를 강조한다. 노트북을 들고 카페에 홀로 앉아 메시지를 보내는 소박한 형태부터, 회사가 공간을 제공하고 외부 연사가 발표하는 공식적인 행사까지 다양하다. 온라인으로는 C++ Alliance의 C++ Slack, 다수의 Discord 서버들, 그리고 Compiler Explorer의 Discord가 활발한 커뮤니티를 형성하고 있다. cppreference.com 역시 커뮤니티 기반으로 운영되는 핵심 레퍼런스 자료다.
마무리: 참여의 촉구
강연의 마지막 “assembly” 의미—“군대를 집결시키는 북소리”—에 이르러, 강연자는 청중 모두에게 C++ 커뮤니티의 능동적 참여자가 되길 촉구한다. C++은 대기업들뿐 아니라, 개인 기여자들, 오픈소스 유지보수자들, 밋업 조직자들, 표준위원회 자원봉사자들 모두가 함께 만들어가는 언어다. 지역에 밋업이 없다면 직접 시작할 수 있고, 유용한 라이브러리가 있다면 오픈소스로 공개할 수 있으며, 더 나아가 표준위원회에 참여하는 것도 가능하다.
“C++은 다소의 어셈블리를 필요로 합니다(C++ requires some assembly)“—이 말이 단순한 언어유희가 아니라는 것을, 강연을 통해 우리는 다시 한번 확인한다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | C++: Some Assembly Required - Matt Godbolt - CppCon 2025 |
| 채널 | CppCon |
| 리포트 작성 | 2026-04-11 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.
📎 참고 자료 (강연 내용과 별개)
강연에서 언급된 주요 자료들로, 더 깊은 이해를 원하는 독자를 위해 정리한다.
- Compiler Explorer: godbolt.org — 강연자가 창시한 실시간 컴파일러 탐색 도구
- Compiler Explorer Shop: shop.compilerexplorer.com — ABI 요약표가 새겨진 머그컵 등 판매 (수익은 Compiler Explorer 운영 지원)
- Beman Project: 2024년 Beman Dawes를 기리며 시작된 표준 라이브러리 편입 목표 라이브러리 프로젝트
- cppreference.com: 커뮤니티 운영 C++ 레퍼런스 (강연 당시 일시적으로 읽기 전용 상태였다고 언급됨)
- Boost: 1999년 출범, C++ 라이브러리 실험장. boost.org
- WG21 공식 사이트: isocpp.org/std/the-committee 에서 위원회 구조 및 진행 중인 제안서 확인 가능