필사 모드: 모던 C++ 2026 — C++ 23 / 26 / Modules / Reflection / Senders / std::print / CMake 3.30 / Conan 2 / vcpkg 심층 가이드
한국어프롤로그 — "C++ 은 이미 죽었다"는 말은 매년 다시 죽는다
2010년대 내내 C++ 의 부고는 매년 새로 쓰였다. Go 가 나왔을 때, Rust 가 나왔을 때, Swift 가 나왔을 때, 그리고 Zig 가 나왔을 때마다 "이제 시스템 프로그래밍은 X 가 가져갈 것"이라는 이야기가 반복됐다. 2026년 5월 현재 그 말은 또 한 번 빗나갔다. C++ 23 은 2024년 10월에 ISO/IEC 14882:2024 로 공식 출간됐고, C++ 26 은 2026년 ratification 을 향해 마지막 마일스톤을 밟고 있다. Reflection (P2996) 이라는 거대한 기능이 들어가고, Senders/Receivers (P2300) 가 표준 async 모델로 자리잡고, Linear Algebra (P1673) 가 std 에 들어오고 있다.
동시에 현장은 어느 때보다 분주하다. 게임 엔진 — Unreal 5.5, Unity 의 네이티브 코드, CryEngine, in-house 엔진 — 은 여전히 C++ 이다. HFT (High-Frequency Trading) 의 마이크로초 단위 거래 시스템도 C++ 이다. Chromium·Firefox·WebKit 같은 브라우저 엔진도, LLVM·GCC·Clang 같은 컴파일러도, MySQL·PostgreSQL·ClickHouse 같은 데이터베이스 엔진도, CUDA·ROCm·oneAPI 같은 GPU 런타임도 모두 C++ 이다. 삼성·LG·소니·캡콤·NCSoft 가 만드는 거의 모든 디바이스와 게임이 그 위에서 돈다.
이 글은 2026년의 C++ 을 한 장의 지도로 펼친다. 표준 (C++ 23 / 26), 빌드 도구 (CMake 3.30 · Meson · xmake · build2 · Bazel), 패키지 (Conan 2 · vcpkg), 컴파일러 (Clang 19 · GCC 14 · MSVC), 표준 라이브러리 (libc++ vs libstdc++), Sanitizers, 그리고 후계 언어 후보 (Carbon · Hylo · Cppfront) 까지. 마지막에 한국과 일본의 현장이 어떻게 쓰고 있는지로 마무리한다.
1장 · 2026년 C++ — C++ 23 ISO 출간과 C++ 26 마무리
먼저 큰 그림.
C++ 23 — 2024년 10월 공식 출간
C++ 23 은 2024년 10월에 ISO/IEC 14882:2024 로 공식 출간됐다. 2020년에 출간된 C++ 20 의 뒤를 이어 3년 만이다. 핵심 기능은 다음과 같다.
- `std::expected<T, E>` — Rust 의 `Result` 와 비슷한 모나딕 에러 처리. 예외 없는 코드베이스의 새 표준이 됐다.
- `std::print` / `std::println` — `printf` 와 iostream 의 30년 묵은 자리를 가져간다. `{fmt}` 라이브러리를 표준화한 결과.
- `std::generator` — 코루틴 기반 lazy range. Python 의 `yield` 와 같은 패턴이 표준에 들어왔다.
- `std::flat_map` / `std::flat_set` — 정렬된 `vector` 위에 올린 cache-friendly 연관 컨테이너.
- `std::mdspan` — non-owning multidimensional view. BLAS·과학 계산용.
- `[[assume(expr)]]` — 최적화 힌트.
- `if consteval` — 컴파일 타임 분기.
- `static operator()` — 람다의 `this` 캡처 오버헤드 제거.
- Deducing `this` — 멤버 함수의 explicit object parameter.
C++ 26 — 2026년 ratification, 진짜 주연은 Reflection
C++ 26 은 2026년에 ratification 이 끝나고 ISO/IEC 14882:2026 으로 출간될 예정이다 (2025년 6월의 Sofia 회의에서 feature complete 가 선언됐다). 핵심은 다음과 같다.
- **Reflection (P2996)** — 컴파일 타임 reflection 과 splicing. C++ 의 metaprogramming 을 다시 쓴다.
- **Senders/Receivers (P2300)** — std::execution 으로 들어가는 async 모델. `std::future` 의 후계자.
- **Linear Algebra (P1673)** — BLAS 인터페이스가 표준에 들어온다.
- **Hazard pointers / RCU** — lock-free 자료구조용 메모리 관리.
- **Contracts (P2900)** — 함수 사전·사후 조건. C++ 20 에서 빠졌다가 다시 들어옴.
- **Pattern matching (P2688)** — `inspect` 키워드 기반.
- **`std::simd`** — 데이터 병렬 타입.
"왜 C++ 은 안 죽는가" — 시장 현실
2026년 기준 TIOBE 와 IEEE Spectrum 의 언어 랭킹에서 C++ 은 1~5위 사이를 유지한다. GitHub 의 PR 통계에서도 마찬가지다. 이유는 단순하다.
1. **레거시가 너무 크다.** Chromium·LLVM·Linux 의 일부·MySQL·Unreal 같은 거대 프로젝트가 C++ 로 짜여 있고, 이걸 옮기는 건 사실상 불가능하다.
2. **대체할 언어가 없다.** Rust 는 좋지만 모든 C++ 영역을 커버하지 못한다 (특히 게임·과학 계산·Windows GUI). Carbon 은 아직 alpha 다. Hylo 는 연구 단계.
3. **여전히 빠르다.** GCC 14·Clang 19 가 만드는 코드는 여전히 최고 수준이다. LTO·PGO·BOLT 까지 합치면 다른 컴파일된 언어와 동등하거나 더 빠르다.
4. **표준이 살아 있다.** C++ 23·26 은 단순한 정리가 아니라 **새 기능** 이 계속 들어온다.
2장 · C++ 23 (2024.10 ISO 출간) — std::expected / std::print / std::generator
C++ 23 의 가장 자주 쓰이는 신기능 셋을 짚는다.
std::expected — 모나딕 에러 처리
Rust 의 `Result<T, E>` 가 C++ 에 왔다. `std::expected<T, E>` 는 성공값 T 또는 에러값 E 를 담는다. 예외를 쓰지 않는 코드베이스 (게임·임베디드·HFT) 가 오랫동안 직접 만들어 쓰던 패턴이 표준화됐다.
#include <expected>
#include <string>
#include <print>
enum class ParseError { InvalidFormat, Overflow };
std::expected<int, ParseError> parse_int(std::string_view s) {
if (s.empty()) return std::unexpected(ParseError::InvalidFormat);
int v = 0;
for (char c : s) {
if (c < '0' || c > '9') return std::unexpected(ParseError::InvalidFormat);
if (v > (INT_MAX - (c - '0')) / 10) return std::unexpected(ParseError::Overflow);
v = v * 10 + (c - '0');
}
return v;
}
int main() {
auto r = parse_int("42")
.and_then([](int v) -> std::expected<int, ParseError> { return v * 2; })
.transform([](int v) { return v + 1; });
if (r) std::println("ok: {}", *r);
else std::println("err");
}
`and_then`·`transform`·`or_else` 같은 모나딕 연산자가 들어 있어서 체이닝이 자연스럽다. 게임 엔진의 asset 로더, HFT 의 주문 파서, 임베디드의 설정 파서가 곧장 갈아탔다.
std::print / std::println — printf 의 후계자
`{fmt}` 라이브러리 (Victor Zverovich) 가 C++ 20 의 `<format>` 으로 들어왔고, C++ 23 에서 마침내 출력 함수 `std::print` / `std::println` 까지 들어왔다. `printf` 의 format string 안전성과 iostream 의 type safety 를 합친 결과다.
#include <print>
#include <vector>
int main() {
std::println("hello {}, you are {} years old", "yj", 33);
std::vector<int> v{1, 2, 3, 4, 5};
std::println("vec = {}", v); // [1, 2, 3, 4, 5]
// Korean / Japanese 도 잘 나온다 (UTF-8)
std::println("한국어: {}, 日本語: {}", "안녕", "こんにちは");
}
벤치마크상 `std::print` 는 `printf` 보다 빠르고 `std::cout << ...` 보다 훨씬 빠르다 (locale·sync 오버헤드가 없기 때문). iostream 은 2026년 기준 사실상 deprecated 분위기다.
std::generator — 코루틴 기반 lazy range
C++ 20 에서 coroutine 키워드 (`co_await`·`co_yield`·`co_return`) 가 들어왔지만 표준 라이브러리 측의 제너레이터가 없어서 거의 못 썼다. C++ 23 에서 `std::generator<T>` 가 추가되면서 Python 의 `yield` 패턴이 C++ 에서도 자연스러워졌다.
#include <generator>
#include <print>
#include <ranges>
std::generator<int> fib() {
int a = 0, b = 1;
while (true) {
co_yield a;
auto t = a + b;
a = b;
b = t;
}
}
int main() {
for (int v : fib() | std::views::take(10)) {
std::println("{}", v);
}
}
Ranges 와 합쳐서 쓰면 굉장히 강력하다 (다음 장 참고).
3장 · C++ 26 — Reflection 의 시대
C++ 26 의 가장 큰 사건은 **Reflection (P2996)** 이다. Daveed Vandevoorde·Wyatt Childers·Andrew Sutton·Faisal Vali 가 수년간 다듬어 온 정적 reflection 제안이 마침내 표준에 들어간다.
기존의 SFINAE·`<type_traits>`·매크로 기반 metaprogramming 을 한꺼번에 대체할 가능성이 있다. 핵심은 `^^` 와 `[: ... :]` 라는 두 개의 새 operator 다.
- `^^X` — X 의 reflection 값을 얻는다 (`std::meta::info` 타입).
- `[: r :]` — reflection 값 r 을 splice 해서 원래 entity 로 돌려놓는다.
#include <meta>
#include <print>
struct Person {
std::string name;
int age;
std::string email;
};
template<typename T>
void print_struct(const T& t) {
constexpr auto members = std::meta::nonstatic_data_members_of(^^T);
template for (constexpr auto m : members) {
std::println("{} = {}",
std::meta::identifier_of(m),
t.[:m:]);
}
}
int main() {
Person p{"yj", 33, "yj@example.com"};
print_struct(p);
// name = yj
// age = 33
// email = yj@example.com
}
이 기능 하나로 JSON serializer, ORM, RPC stub, GUI binding, configuration loader 같은 라이브러리들이 **매크로 없이 / boost.pfr 없이 / cereal 없이** 짧고 안전하게 다시 짜인다. 2026년 하반기부터 Clang 의 trunk 와 EDG (Intel) 가 부분적으로 구현 중이다.
다른 C++ 26 의 큰 기능도 짚는다.
- **`std::simd`** — SIMD 가 표준 타입으로. 기존의 intrinsic 대신 portable 한 데이터 병렬 코드.
- **Contracts (P2900)** — `pre(expr)`·`post(expr)` 로 함수의 사전·사후 조건을 명시. C++ 20 에서 빠졌다가 다시 들어왔다.
- **Pattern matching (P2688)** — `inspect (x) { ... }` 로 Rust 의 `match` 와 비슷한 형태.
- **Hazard pointers / RCU** — lock-free 자료구조용 메모리 회수 기법.
4장 · Modules — 마침내 쓸 만한가
Modules 는 C++ 20 에 들어왔지만 2020~2023년 동안 거의 못 썼다. 컴파일러 (Clang·MSVC·GCC) 의 구현이 incomplete 였고, 빌드 도구 (CMake·Bazel) 와의 통합도 형편없었다. 2024년부터 상황이 빠르게 바뀌었고, 2026년 현재는 **마침내 production 에서 쓸 만하다**.
모듈 기본
기존 헤더 기반 (`#include`) 의 문제는 텍스트 전처리라는 것이다. 같은 헤더가 매 .cpp 파일마다 다시 파싱되고, 매크로가 leak 되고, ODR violation 이 생기고, 빌드가 느리다. Modules 는 컴파일된 인터페이스를 한 번만 생성해서 모든 곳에서 import 한다.
// math.cppm (module interface)
export module math;
export int add(int a, int b) {
return a + b;
}
export int sub(int a, int b) {
return a - b;
}
// main.cpp
int main() {
std::println("{}", add(1, 2));
}
빌드 도구 측
- **CMake 3.30 (2024년)** — C++ 20 modules 의 first-class 지원. Ninja 1.11+ 필요.
- **MSVC (Visual Studio 17.10+)** — modules 가장 안정적.
- **Clang 17~19** — modules 거의 완성. `-fmodules-ts` 가 아닌 표준 `-std=c++20` + `-fmodules`.
- **GCC 14~15** — modules 부분 지원, header units 는 아직 약함.
- **Bazel** — `cc_module` rule 이 2025년부터 정식.
효과
- 빌드 시간 — Chromium 의 일부 모듈 전환 후 incremental 빌드 30~50% 단축.
- ODR — 한 module 안의 매크로는 누출되지 않는다.
- IDE — IntelliSense·clangd 가 module 을 알아들으면 navigation 이 빨라진다.
함정
- 표준 라이브러리 `import std` 는 컴파일러·STL 조합에 따라 지원이 들쭉날쭉하다. 2026년 기준 libc++ + Clang 18+ 는 OK, libstdc++ + GCC 14 는 부분, MSVC STL 은 OK.
- 빌드 시스템이 module dependency 를 정확히 계산해야 한다. `cmake --build` 가 module graph 를 scan 한 뒤 컴파일하기 때문에 first build 는 오히려 느려질 수 있다.
5장 · Ranges (C++ 20) — 마침내 성숙
Ranges 는 C++ 20 에 들어왔지만 초기엔 거의 안 썼다. 컴파일 에러가 무서웠고 (수십 줄짜리 template instantiation), debugger 에서 type 이 흉측했고, 표준 라이브러리 측의 algorithm 이 다 들어오지 않았기 때문이다. C++ 23 에서 누락분이 채워졌고, 2026년 기준 일상 코드의 상당 부분이 ranges 로 쓰인다.
#include <ranges>
#include <vector>
#include <print>
int main() {
std::vector<int> v{1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
auto result = v
| std::views::filter([](int x) { return x % 2 == 0; })
| std::views::transform([](int x) { return x * x; })
| std::views::take(3);
for (int x : result) std::println("{}", x);
// 4
// 16
// 36
}
C++ 23 에서 추가된 것
- `std::views::enumerate` — Python 의 `enumerate` 같은 것.
- `std::views::zip` / `zip_transform`
- `std::views::join_with` — 문자열 join 처럼.
- `std::views::chunk` / `chunk_by` / `slide` — 윈도잉.
- `std::views::stride` — n 개씩 건너뛰기.
- `std::views::cartesian_product` — 모든 조합.
- `std::ranges::to<vector>` — view 를 container 로.
auto names = std::vector<std::string>{"alice", "bob", "charlie"};
auto ages = std::vector<int>{30, 25, 40};
for (auto [name, age] : std::views::zip(names, ages)) {
std::println("{}: {}", name, age);
}
성능
ranges 는 lazy evaluation 이므로 인터미디어트 벡터를 만들지 않는다. 컴파일러가 inline 만 잘 해주면 손코드 for-loop 와 동등하다 (godbolt 에서 확인). 다만 STL view 에는 reference invalidation 등 함정이 있어서 `std::ranges::to` 로 일찍 materialize 하는 게 안전할 때가 많다.
6장 · Senders/Receivers (P2300) — async 모델
`std::future` 는 C++ 11 에서 들어왔지만 거의 안 썼다. promise/future 의 비용이 컸고, composition 이 없었고, cancellation 이 빠졌고, allocator 가 hardcoded 였기 때문이다. C++ 26 의 **Senders/Receivers (P2300)** 는 이 모든 걸 다시 설계한다.
Eric Niebler·Lewis Baker·Kirk Shoop·Lee Howes 가 NVIDIA·Meta·Microsoft 의 실제 production 코드 (stdexec, libunifex) 에서 다듬어 온 모델이다.
핵심 개념
- **Sender** — "값을 비동기적으로 만들 것" 이라는 lazy description.
- **Receiver** — sender 의 결과를 받는 sink.
- **Scheduler** — sender 가 어디서 실행될지 결정 (thread pool, GPU stream, etc).
#include <execution>
#include <print>
namespace ex = std::execution;
int main() {
auto pool = ex::static_thread_pool(4);
auto sched = pool.get_scheduler();
auto work = ex::schedule(sched)
| ex::then([] { return 42; })
| ex::then([](int x) { return x * 2; });
auto [result] = std::this_thread::sync_wait(work).value();
std::println("result = {}", result); // 84
}
왜 중요한가
기존의 `std::async` 는 thread 를 직접 만들거나 launcher 가 알아서 정하거나 둘 중 하나였다. 어디서 실행될지를 모른다. Senders 는 **scheduler 가 명시적** 이라서 thread pool, fiber, GPU stream, Linux io_uring, Windows IOCP, Android JNI thread 같은 다양한 컨텍스트에 같은 코드를 올릴 수 있다.
또 composition 이 자연스럽다. `then`·`when_all`·`let_value`·`upon_error`·`stopped_as_optional` 같은 algorithm 으로 비동기 그래프를 짠다. cancellation 은 `stop_token` 으로 전파된다.
NVIDIA 의 CUDA 12·13 의 일부 비동기 API 가 이미 sender 인터페이스를 노출하고, 2026년 후반에는 표준 implementation 이 나올 것으로 보인다.
7장 · 선형대수 BLAS std (C++ 26)
C++ 26 에 들어가는 또 하나의 큰 기능은 **`std::linalg` (P1673)** — Bradley A. Lucier·Mark Hoemmen·Christian Trott·Daisy Hollman 이 주도한 BLAS 인터페이스의 표준화다.
수십 년 동안 C++ 의 선형대수는 Eigen·Blaze·Armadillo·xtensor 같은 외부 라이브러리에 의존해 왔다. 같은 BLAS 호출을 매번 다르게 wrap 한 결과 코드 이식성이 나빴고, ML/AI 의 부상으로 표준화가 늦었다는 비판이 커졌다.
`<linalg>` 는 `std::mdspan` (C++ 23) 위에 BLAS Level 1·2·3 의 표준 인터페이스를 올린다.
#include <linalg>
#include <mdspan>
#include <vector>
int main() {
std::vector<double> data(16);
auto A = std::mdspan(data.data(), 4, 4);
std::vector<double> x(4, 1.0);
std::vector<double> y(4, 0.0);
// y = alpha * A * x + beta * y
std::linalg::matrix_vector_product(
A, x, y);
}
뒷단의 구현은 vendor (Intel MKL, OpenBLAS, NVIDIA cuBLAS, AMD rocBLAS) 가 자유다. 표준 인터페이스만 같다.
ML 추론, 시뮬레이션, 컴퓨터 비전, 신호처리 분야에서 큰 변화를 가져올 것으로 보인다.
8장 · CMake 3.30 / Meson / xmake / build2 / Bazel C++ — 빌드 도구
C++ 의 영원한 골칫거리. 2026년의 빌드 도구 지형은 다음과 같다.
CMake — 사실상 표준
CMake 는 좋든 싫든 사실상 표준이다. 거의 모든 라이브러리가 `find_package` 또는 `FetchContent` 로 통합되고, IDE (CLion·Visual Studio·Qt Creator·VS Code) 가 모두 지원한다.
- **CMake 3.30 (2024년)** — C++ 20 modules first-class 지원, presets v8, 새 `cmake -E` subcommand.
- **CMake 3.31 / 3.32** — module 지원 개선, package manifest (vcpkg / Conan 통합) 강화.
기본 패턴.
cmake_minimum_required(VERSION 3.30)
project(myapp CXX)
set(CMAKE_CXX_STANDARD 23)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)
add_executable(myapp src/main.cpp)
find_package(fmt CONFIG REQUIRED)
target_link_libraries(myapp PRIVATE fmt::fmt)
CMake 의 단점은 잘 알려져 있다 — DSL 이 어색하고, error message 가 흉하고, 큰 프로젝트에서 generator expression 이 복잡해진다. 그래도 **모든 사람이 안다**는 게 장점이다.
Meson — Pythonic 한 대안
Meson 은 Python 으로 짠 build system 으로 syntax 가 깔끔하고 빠르다. GNOME·systemd·QEMU·GStreamer 가 쓴다. CMake 보다 빠르고 (Ninja 백엔드 기본), subproject 관리가 좋다.
project('myapp', 'cpp',
default_options : ['cpp_std=c++23'])
fmt_dep = dependency('fmt')
executable('myapp', 'src/main.cpp', dependencies : fmt_dep)
단점은 CMake 만큼 라이브러리 지원이 폭넓지 않다는 것. 하지만 GNOME 진영에서는 사실상 표준.
xmake — Lua 기반의 emerging 선수
xmake 는 중국에서 만든 Lua 기반 build system 으로, 매우 빠르고 모던하다 (`xmake init` → `xmake build` → `xmake install`). 패키지 매니저 (`xrepo`) 도 내장. 게임·임베디드 진영에서 빠르게 늘고 있다.
add_rules("mode.debug", "mode.release")
set_languages("c++23")
target("myapp")
set_kind("binary")
add_files("src/*.cpp")
add_packages("fmt")
build2 — 학문적·엄격한 대안
build2 는 매우 엄격하고 일관성 있는 build system + package manager. C++ Modules 지원이 가장 빠르고 정확하다. 사용자는 적지만 광신도가 있다.
Bazel — Google 식 monorepo
Bazel 은 Google 의 사내 build system Blaze 를 오픈소스화한 것. 거대 monorepo (TensorFlow, gRPC, Envoy) 에서 빛난다. hermetic build, remote cache, distributed execution 이 강점. 단점은 러닝 커브와 작은 프로젝트엔 과한 셋업.
BUILD.bazel
cc_binary(
name = "myapp",
srcs = ["src/main.cpp"],
copts = ["-std=c++23"],
deps = ["@fmt//:fmt"],
)
2026년 기준 google/bazel-cpp 의 modules 지원이 들어왔다.
선택 가이드 (대략)
- 일반 오픈소스 · 라이브러리 → CMake
- GNOME / systemd 진영 · 빠른 빌드 중시 → Meson
- 게임 · 임베디드 · 중국 진영 · Lua 친화 → xmake
- Modules 완벽 지원 필요 → build2
- Monorepo · 수만 타겟 · remote cache → Bazel
9장 · Conan 2 / vcpkg — 패키지 매니저
수십 년 동안 C++ 의 가장 큰 약점은 패키지 매니저 부재였다. 모두가 직접 빌드하거나 Linux distro 의 패키지에 의존하거나 git submodule 로 끌어왔다. 2020년대 들어 두 개의 큰 선수가 자리를 잡았다 — **Conan** 과 **vcpkg**.
Conan 2 (2023년 메이저 릴리스)
Conan 은 Python 으로 짠 분산형 패키지 매니저. JFrog 가 backing 한다. Conan 2 는 1.x 에 비해 깔끔하게 다시 짜였고 2026년 기준 매우 안정적.
conanfile.py
from conan import ConanFile
from conan.tools.cmake import CMake, cmake_layout
class MyAppRecipe(ConanFile):
settings = "os", "compiler", "build_type", "arch"
generators = "CMakeDeps", "CMakeToolchain"
def requirements(self):
self.requires("fmt/10.2.1")
self.requires("spdlog/1.13.0")
self.requires("nlohmann_json/3.11.3")
def layout(self):
cmake_layout(self)
conan install . --build=missing
cmake --preset conan-default
cmake --build --preset conan-release
Conan 의 강점은 **profile** 시스템이다. 동일한 패키지를 다양한 설정 (debug/release, GCC/Clang, x86/arm, libc++/libstdc++) 으로 빌드해서 cache 한다. 회사 차원의 Artifactory 와 연동해서 사내 patched 빌드를 공유한다.
vcpkg (Microsoft, 2017~)
vcpkg 는 Microsoft 가 만든 매니저. 처음엔 Windows 위주였지만 지금은 Linux·macOS 도 잘 된다. 카탈로그가 매우 크고 (3000+ 라이브러리), CMake 와의 통합이 자연스럽다.
// vcpkg.json
{
"name": "myapp",
"version": "0.1.0",
"dependencies": [
"fmt",
"spdlog",
"nlohmann-json"
]
}
vcpkg install
cmake -B build -S . \
-DCMAKE_TOOLCHAIN_FILE=$VCPKG_ROOT/scripts/buildsystems/vcpkg.cmake
cmake --build build
vcpkg 의 강점은 manifest mode + binary cache 다. 같은 의존성을 매번 다시 빌드하지 않고 cache 에서 가져온다. Azure DevOps / GitHub Actions 와의 통합이 잘 돼 있다.
Conan vs vcpkg — 어떻게 고르나
| 기준 | Conan 2 | vcpkg |
|------|---------|-------|
| 출신 | JFrog (스페인) | Microsoft |
| 언어 | Python recipe | CMake-flavored portfile |
| Profile | 매우 강함 | 약함 (triplet 기반) |
| 카탈로그 | 1500+ | 3000+ |
| 사내 cache | Artifactory 친화 | Azure Artifacts |
| 학습곡선 | 가파름 | 완만 |
| 윈도우 | OK | 최고 |
대략: **사내 다양한 빌드 매트릭스 필요** → Conan, **빠른 시작 / Windows 메인** → vcpkg.
10장 · Clang 19 / GCC 14 / MSVC — 컴파일러
2026년 5월 기준 주요 컴파일러의 상태.
Clang 19~20 (LLVM)
- C++ 23 거의 완전, C++ 26 의 절반 정도 (modules·reflection 트렁크).
- 가장 빠른 컴파일 속도 + 가장 좋은 진단 메시지.
- libc++ 와 가장 잘 매칭.
- macOS · iOS · Android (NDK) 의 사실상 표준.
- Apple Clang 은 LLVM trunk 보다 한두 버전 뒤.
GCC 14~15
- C++ 23 거의 완전, C++ 26 도 빠르게 따라옴.
- Linux 서버·임베디드의 사실상 표준.
- libstdc++ 와 함께. 표준 라이브러리 quality 면에서 가장 신뢰받음.
- `-O3` 의 코드 품질이 종종 Clang 보다 약간 좋음 (벤치마크에 따라).
MSVC (Visual Studio 17.10+)
- Windows 데스크탑·콘솔 (Xbox)·게임 (Unreal) 의 사실상 표준.
- 2010년대까지 C++ 표준 따라가는 게 느렸지만 지금은 빠름.
- Modules·coroutine 등에서 종종 가장 먼저 구현.
- C++ standard library (MSVC STL) 가 GitHub 에서 오픈소스 (microsoft/STL).
선택 가이드
| 환경 | 1순위 |
|------|------|
| Linux 서버 | GCC 14 |
| macOS / iOS | Apple Clang (또는 Homebrew LLVM) |
| Windows 데스크탑 / 게임 | MSVC |
| Android NDK | Clang |
| 임베디드 ARM | GCC arm-none-eabi 또는 Clang |
| HFT / 최신 표준 채용 | Clang trunk |
11장 · libc++ vs libstdc++ — 표준 라이브러리
C++ 표준 라이브러리는 사실 **표준의 일부일 뿐, 구현체는 따로** 다. 2026년 기준 주요 구현체.
- **libstdc++** — GCC 진영. 가장 보수적이지만 가장 완성도 높음. Linux 의 사실상 표준.
- **libc++** — LLVM 진영. macOS·iOS 의 표준. Linux 에서도 점점 늘어남.
- **MSVC STL** — Microsoft 의 표준 라이브러리. Windows 의 표준. GitHub 에서 오픈소스.
차이점
- ABI — libstdc++ 와 libc++ 는 **ABI 호환되지 않는다**. 같은 객체 파일을 mix 하면 깨진다 (특히 `std::string`·`std::list`).
- 성능 — 일부 알고리즘 (예 `std::sort`·`std::regex`) 의 성능이 다르다. libc++ 의 `std::regex` 가 더 빠르다는 벤치마크가 많고, libstdc++ 의 `<algorithm>` 이 더 잘 최적화되는 경우가 있다.
- 표준 따라잡기 — libc++ 가 일반적으로 더 빠르게 새 기능을 구현한다.
- Modules — 2026년 기준 libc++ + Clang 18+ 의 `import std` 가 가장 안정적. libstdc++ + GCC 14 는 부분, MSVC STL 은 OK.
선택
Linux 에서 둘 중 어느 걸 쓰느냐는 대부분 distro 와 기본 컴파일러에 따라간다. macOS 는 사실상 libc++ 강제. 직접 고르고 싶다면 Clang + `-stdlib=libc++` 로.
12장 · Sanitizers — ASan / UBSan / TSan / MSan
Sanitizer 는 LLVM 이 시작했고 GCC 가 따라온, 런타임 메모리·동기화 버그 검출 도구. C++ 코드의 quality 를 한 단계 끌어올렸다.
AddressSanitizer (ASan)
- 무엇 — heap-buffer-overflow, use-after-free, use-after-return, double-free, leak.
- 오버헤드 — CPU 2~3x, 메모리 1.5~3x.
- 사용 — `-fsanitize=address -fno-omit-frame-pointer`
clang++ -std=c++23 -O1 -g -fsanitize=address -fno-omit-frame-pointer main.cpp
ASAN_OPTIONS=detect_leaks=1 ./a.out
CI 에서 모든 테스트를 ASan 으로 돌리는 게 2026년의 baseline.
UndefinedBehaviorSanitizer (UBSan)
- 무엇 — signed integer overflow, null deref, divide by zero, misaligned access, etc.
- 오버헤드 — 거의 없음.
- 사용 — `-fsanitize=undefined`.
ASan 과 동시에 쓸 수 있다.
ThreadSanitizer (TSan)
- 무엇 — data race, deadlock 일부, mutex misuse.
- 오버헤드 — CPU 5~15x, 메모리 5~10x.
- 사용 — `-fsanitize=thread`.
멀티스레드 코드의 race 검출은 거의 TSan 이 유일한 자동 도구.
MemorySanitizer (MSan)
- 무엇 — uninitialized memory read.
- 오버헤드 — CPU 3x.
- 단점 — 표준 라이브러리까지 MSan 으로 빌드해야 false positive 가 없다 (libc++ 의 MSan build 사용).
권장 setup
- CI 에 ASan + UBSan 매트릭스 추가.
- 멀티스레드 코드는 별도 job 으로 TSan.
- nightly 로 fuzzer (libFuzzer + ASan) 돌림.
13장 · 후계 언어 — Carbon (Google) / Hylo / Cppfront (Herb Sutter)
C++ 의 "ABI 부담 / 안전하지 못한 기본값 / 거대한 표준" 을 어떻게 풀까에 대한 답으로 세 개의 큰 시도가 있다.
Carbon (Google, 2022~)
Chandler Carruth 가 주도하는 Google 의 C++ 후계 언어. 핵심 아이디어는 **bidirectional interop** — 같은 코드베이스 안에 C++ 과 Carbon 을 섞어 쓸 수 있게 한다. Swift 가 Objective-C 의 후계자였던 것처럼.
package Sample api;
fn Fib(n: i32) -> i32 {
if (n < 2) { return n; }
return Fib(n - 1) + Fib(n - 2);
}
fn Main() -> i32 {
Print("fib(10) = {0}", Fib(10));
return 0;
}
2026년 5월 현재 Carbon 은 아직 0.x experimental. self-hosting 도 안 됐고, 표준 라이브러리도 거의 없고, 일반 사용 권장 아님. **2030년 이전엔 production 사용 안 된다는 게 공식 입장.**
Hylo (옛 Val, 2020~)
Dimitri Racordon·Dave Abrahams 이 만드는 연구 언어. C++ 의 후계자라기보단 **mutable value semantics** 를 진지하게 탐구하는 언어. 변수가 기본적으로 unique 하고, mutation 이 명시적이라서 race 와 aliasing 문제가 사라진다.
Swift 의 일부 아이디어를 더 밀어붙인 형태. 연구 단계지만 학계와 산업계의 관심을 받고 있다.
Cppfront / cpp2 (Herb Sutter, 2022~)
C++ 표준 위원회의 chair 였던 Herb Sutter 가 만드는 **"C++ 의 alternative syntax"**. 별도 언어가 아니라 cppfront 가 cpp2 코드를 받아서 C++ 로 transpile 한다.
// hello.cpp2
main: () = {
print("hello, world!");
}
square: (x: int) -> int = x * x;
기존 C++ 과 자유롭게 섞어 쓸 수 있고, 안전한 기본값 (default const, bounds check) 을 깔고 가는 게 핵심. Carbon 보다 훨씬 가벼운 접근.
정리
2026년 기준 C++ 후계 언어들은 모두 **prototype / experimental** 이다. 향후 5~10년 안에 한 두 개가 자리를 잡을 가능성은 있지만, 그동안 C++ 자체도 진화한다. Reflection·Senders·Modules 가 들어가면 "C++ 을 떠나야 할 이유" 가 줄어든다.
대안으로 **Rust** 도 점점 더 많이 쓰인다. 시스템·임베디드·OS 영역에서는 Rust 가 C++ 와 직접 경쟁한다 (Linux kernel 의 Rust 모듈, Windows kernel 의 일부, Android 의 일부). 하지만 게임·과학 계산·Windows GUI·기존 거대 코드베이스 영역에서는 여전히 C++ 이 압도적이다.
14장 · 한국 — 삼성, LG, NCSoft, 토스 인프라
한국의 C++ 사용처를 짚는다.
삼성전자
- **시스템 LSI / 파운드리** — chip design 도구 (EDA) 의 일부가 C++.
- **무선 사업부 (모바일)** — Android 의 native layer, 카메라 ISP 펌웨어, 모뎀 firmware.
- **CE (가전)** — TV 의 Tizen OS, 냉장고·세탁기의 embedded controller.
- **반도체** — 메모리 컨트롤러의 verification (SystemVerilog + C++), DRAM/NAND 의 firmware.
- **Samsung Research** — AI/ML 의 일부, on-device LLM 추론 엔진.
LG전자
- **HE (TV)** — webOS 의 native components, picture quality engine.
- **VS (전장)** — 차량 인포테인먼트, 자율주행 SoC firmware.
- **H&A (가전)** — 세탁기·에어컨·로봇 청소기의 controller.
NCSoft
- **리니지·블레이드앤소울** — in-house engine (자체 C++ 기반).
- **TL (Throne and Liberty)** — Unreal Engine 5 + custom C++.
- **AI Center** — Vapor (자체 game AI), 음성합성 엔진.
토스 — 인프라 / 트레이딩 영역
- **토스증권 — 매칭 엔진** — 일부 latency critical 영역에 C++ 사용 (Java/Kotlin 메인이지만 핵심 매칭 일부).
- **인프라 — 일부 미들웨어**.
(주: 토스의 핵심 서비스는 Kotlin 이고 C++ 비중은 낮지만, latency-critical 영역에서 사용 사례가 있다.)
기타 한국 회사
- **카카오엔터테인먼트** — 게임 서버의 일부, 멀티미디어 처리.
- **크래프톤** — PUBG 의 client (Unreal Engine 4 + custom), server-side battle simulator.
- **펄어비스** — 검은사막의 자체 엔진 BlackSpace (C++).
- **스마일게이트** — 로스트아크 client (Unreal), 자체 server engine.
- **현대자동차 / Mobis** — 차량 ECU firmware, ADAS.
- **한화시스템 / LIG넥스원** — 방산 임베디드.
한국 C++ 커뮤니티
- **Modern C++ Korea** — Facebook 그룹 + meetup. 표준 위원회의 한국 NB (National Body) 활동도 있다.
- **NDC (NEXON Developers Conference)** — 게임 개발자 컨퍼런스. C++ track 많음.
- **공저서·번역서** — 옥찬호·박상수 등의 모던 C++ 책이 잘 쓰임.
15장 · 일본 — Sony PlayStation, Square Enix, Capcom, Bandai Namco
일본은 게임·가전·자동차의 본고장이고, 거의 모두 C++ 위에 돌아간다.
Sony Interactive Entertainment
- **PlayStation 5 / Pro / 6** — OS, SDK, devkit 의 거의 모든 게 C++. firmware 는 C + C++.
- **PSN backend** — 일부 C++, 일부 Java/Kotlin/Rust.
- **first-party 스튜디오** — Naughty Dog, Insomniac, Santa Monica, Polyphony, Guerrilla — 모두 자체 engine 또는 Unreal + C++.
Square Enix
- **Crystal Tools / Luminous Engine** — FF 시리즈의 자체 엔진들. 모두 C++.
- **드래곤 퀘스트** — Unreal Engine 또는 자체 engine.
- **외부 라이선스** — Unreal Engine 5 도 다수.
Capcom
- **RE Engine** — Resident Evil 7 부터 시작. Devil May Cry 5, Monster Hunter Rise / Wilds, Street Fighter 6 가 모두 RE Engine. 자체 C++.
- **MT Framework (구)** — 일부 레거시.
Bandai Namco
- **Tekken 8** — Unreal Engine 5.
- **엘든링 (Elden Ring) — FromSoftware** — 자체 engine (Souls engine). C++.
- **건담 시리즈** — Unreal Engine 또는 자체.
Konami
- **eFootball / Winning Eleven** — Unreal Engine.
- **모모타로전철** — 자체 endpoint.
SEGA
- **Phantasy Star Online** — 자체.
- **Yakuza / Like a Dragon** — Dragon Engine (자체 C++).
일본 자동차 (Toyota, Honda, Nissan)
- **차량 ECU / Autosar** — 거의 모두 C++ 또는 C. Autosar Adaptive 가 C++ 기반.
- **ADAS / 자율주행** — C++ 메인. ROS 의 일부 (ROS 2 는 C++).
일본 가전 (Sony, Panasonic, Sharp)
- **TV / 카메라 / 오디오** — embedded Linux + C++ 또는 RTOS + C++.
일본 C++ 커뮤니티
- **CppCon Japan / C++ MIX** — 도쿄·오사카 meetup.
- **C++ 한국NB / 일본NB** — 표준 위원회의 일본 representative 가 활발.
- **Cybozu / DeNA / GREE** — 일부 backend 에 C++ 사용.
16장 · 누가 C++ 을 골라야 하나 — 게임 / 임베디드 / HFT / 시스템
마지막으로 2026년에 **신규 프로젝트의 언어 선택** 에서 C++ 을 골라야 하는 경우와 그렇지 않은 경우를 짚는다.
C++ 이 정답인 경우
1. **게임 — Unreal Engine / 자체 engine** — 다른 선택지가 사실상 없다. Unreal 의 gameplay code 도 C++ (또는 Blueprint).
2. **HFT (High-Frequency Trading)** — 마이크로초 단위의 latency. JVM 의 GC 가 부담스러운 영역.
3. **OS / 시스템 프로그래밍 (일부)** — Linux kernel 은 C 메인 + Rust 일부지만, Windows kernel 의 일부, Apple Darwin 의 일부, embedded RTOS 는 C++ 도 많음.
4. **임베디드 / 펌웨어** — ARM Cortex-M, RISC-V, 자동차 ECU, 가전 — C++ 또는 C.
5. **CAD / 시뮬레이션 / EDA** — AutoCAD, SolidWorks, ANSYS, Synopsys, Cadence 의 거의 전부.
6. **데이터베이스 엔진** — MySQL, PostgreSQL, ClickHouse, MongoDB, RocksDB.
7. **컴파일러 / 런타임** — LLVM, GCC, V8, JVM HotSpot 자체.
8. **그래픽스 / GPU 런타임** — CUDA, ROCm, oneAPI, Vulkan implementation.
9. **AI 추론 엔진** — llama.cpp, PyTorch C++ runtime, TensorFlow Lite, ONNX Runtime.
Rust 가 더 나을 가능성이 큰 경우
1. **새 시스템 프로그래밍 프로젝트** (특히 메모리 안전이 중요한) — Rust.
2. **WebAssembly 타겟** — Rust 가 훨씬 자연스럽다.
3. **인터넷 인프라 (Cloudflare, Discord 등)** — Rust 가 사실상 표준이 됨.
4. **CLI 도구** — Go 또는 Rust.
Go / 자바 / TypeScript 가 정답인 경우
1. **백엔드 API 서버** — Go / TypeScript / Java / Kotlin.
2. **데이터 파이프라인** — Python / Scala / Java.
3. **GUI 데스크탑 앱** — Electron / TypeScript / C# (WPF) — 단 게임은 C++.
함정
- "안전" 이 절대적 요구사항이 아니라면 C++ 의 생산성도 모던 C++ (C++ 20·23·26) 에서는 나쁘지 않다. `std::expected`·`std::print`·Ranges·Modules 가 일상을 바꾼다.
- 기존 C++ 코드베이스에 새 기능 추가 → 거의 항상 C++ 로 계속 가는 게 맞다. Rust interop 은 가능하지만 ABI·빌드 시스템·CI 가 복잡해진다.
- 학습 곡선 — 모던 C++ 은 여전히 가파르다. Rust 가 어렵다고 하지만 C++ 의 UB 와 template metaprogramming 만큼 어려운 건 없다.
17장 · 마치며 — 모던 C++ 은 여전히 살아 있다
2026년의 C++ 은 1998년의 C++ 도 아니고, 2011년의 C++ 도 아니다. C++ 23 의 `std::expected`·`std::print`·`std::generator` 가 일상을 바꿨고, C++ 26 의 Reflection·Senders·Linear Algebra 가 라이브러리 생태계를 다시 짠다. Modules 가 마침내 빌드를 가볍게 하고, Ranges 가 코드를 읽기 좋게 만든다.
빌드 도구는 CMake 3.30·Meson·xmake·build2·Bazel 사이에서 고를 수 있고, 패키지는 Conan 2 와 vcpkg 둘 다 production-ready 다. 컴파일러는 Clang 19·GCC 14·MSVC 모두 C++ 23 거의 완성. Sanitizers 가 quality 의 baseline 이 됐다.
후계 언어 — Carbon·Hylo·Cppfront — 는 모두 흥미롭지만 아직 prototype. Rust 는 일부 영역을 가져갔지만 전체를 가져가진 못한다. 게임·임베디드·HFT·시스템 영역에서 C++ 은 여전히 압도적이고, 한국·일본의 거대 회사들이 그 위에 미래 제품을 짓는다.
"C++ 은 죽었다" 는 말은 또 한 번 빗나갔다. 그리고 그 말은 앞으로도 매년 빗나갈 것이다. 그동안 C++ 자체는 더 좋아진다.
참고 / References
ISO 표준 / 위원회 문서
- ISO/IEC 14882:2024 — Programming languages — C++ — [https://www.iso.org/standard/83626.html](https://www.iso.org/standard/83626.html)
- WG21 (C++ standards committee) — [https://www.open-std.org/jtc1/sc22/wg21/](https://www.open-std.org/jtc1/sc22/wg21/)
- P2300R10 — std::execution (Senders/Receivers) — [https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2300r10.html](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2300r10.html)
- P2996 — Reflection for C++26 — [https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2996r4.html](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2996r4.html)
- P1673 — A free function linear algebra interface based on the BLAS — [https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p1673r13.html](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p1673r13.html)
- P2900 — Contracts for C++ — [https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2900r6.pdf](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2900r6.pdf)
레퍼런스 / 학습
- cppreference — [https://en.cppreference.com/](https://en.cppreference.com/)
- Compiler Explorer (godbolt) — [https://godbolt.org/](https://godbolt.org/)
- C++ Core Guidelines — [https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines)
컴파일러 / 표준 라이브러리
- LLVM / Clang — [https://llvm.org/](https://llvm.org/)
- GCC — [https://gcc.gnu.org/](https://gcc.gnu.org/)
- MSVC STL (open source) — [https://github.com/microsoft/STL](https://github.com/microsoft/STL)
- libc++ — [https://libcxx.llvm.org/](https://libcxx.llvm.org/)
- libstdc++ — [https://gcc.gnu.org/onlinedocs/libstdc++/](https://gcc.gnu.org/onlinedocs/libstdc++/)
빌드 도구
- CMake — [https://cmake.org/](https://cmake.org/)
- Meson — [https://mesonbuild.com/](https://mesonbuild.com/)
- xmake — [https://xmake.io/](https://xmake.io/)
- build2 — [https://build2.org/](https://build2.org/)
- Bazel — [https://bazel.build/](https://bazel.build/)
패키지 매니저
- Conan — [https://conan.io/](https://conan.io/)
- vcpkg — [https://vcpkg.io/](https://vcpkg.io/)
Sanitizers
- AddressSanitizer — [https://clang.llvm.org/docs/AddressSanitizer.html](https://clang.llvm.org/docs/AddressSanitizer.html)
- UndefinedBehaviorSanitizer — [https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html](https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html)
- ThreadSanitizer — [https://clang.llvm.org/docs/ThreadSanitizer.html](https://clang.llvm.org/docs/ThreadSanitizer.html)
- MemorySanitizer — [https://clang.llvm.org/docs/MemorySanitizer.html](https://clang.llvm.org/docs/MemorySanitizer.html)
후계 언어 / 실험적 언어
- Carbon — [https://github.com/carbon-language/carbon-lang](https://github.com/carbon-language/carbon-lang)
- Hylo — [https://www.hylo-lang.org/](https://www.hylo-lang.org/)
- Cppfront — [https://github.com/hsutter/cppfront](https://github.com/hsutter/cppfront)
라이브러리 / 프로젝트
- fmt (std::format / std::print 의 원본) — [https://github.com/fmtlib/fmt](https://github.com/fmtlib/fmt)
- stdexec (NVIDIA / Senders 의 reference 구현) — [https://github.com/NVIDIA/stdexec](https://github.com/NVIDIA/stdexec)
- mdspan (reference 구현) — [https://github.com/kokkos/mdspan](https://github.com/kokkos/mdspan)
한국·일본 게임/엔진
- Unreal Engine — [https://www.unrealengine.com/](https://www.unrealengine.com/)
- Capcom RE Engine — [https://www.capcom-games.com/re-engine/](https://www.capcom-games.com/re-engine/)
- NCSoft — [https://kr.ncsoft.com/](https://kr.ncsoft.com/)
현재 단락 (1/448)
2010년대 내내 C++ 의 부고는 매년 새로 쓰였다. Go 가 나왔을 때, Rust 가 나왔을 때, Swift 가 나왔을 때, 그리고 Zig 가 나왔을 때마다 "이제 시스템 프로...