모던 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 통계에서도 마찬가지다. 이유는 단순하다.

레거시가 너무 크다. Chromium·LLVM·Linux 의 일부·MySQL·Unreal 같은 거대 프로젝트가 C++ 로 짜여 있고, 이걸 옮기는 건 사실상 불가능하다.
대체할 언어가 없다. Rust 는 좋지만 모든 C++ 영역을 커버하지 못한다 (특히 게임·과학 계산·Windows GUI). Carbon 은 아직 alpha 다. Hylo 는 연구 단계.
여전히 빠르다. GCC 14·Clang 19 가 만드는 코드는 여전히 최고 수준이다. LTO·PGO·BOLT 까지 합치면 다른 컴파일된 언어와 동등하거나 더 빠르다.
표준이 살아 있다. 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
import math;
import std; // C++ 23 부터 표준 라이브러리도 module 로 쓸 수 있다

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++ 이 정답인 경우

게임 — Unreal Engine / 자체 engine — 다른 선택지가 사실상 없다. Unreal 의 gameplay code 도 C++ (또는 Blueprint).
HFT (High-Frequency Trading) — 마이크로초 단위의 latency. JVM 의 GC 가 부담스러운 영역.
OS / 시스템 프로그래밍 (일부) — Linux kernel 은 C 메인 + Rust 일부지만, Windows kernel 의 일부, Apple Darwin 의 일부, embedded RTOS 는 C++ 도 많음.
임베디드 / 펌웨어 — ARM Cortex-M, RISC-V, 자동차 ECU, 가전 — C++ 또는 C.
CAD / 시뮬레이션 / EDA — AutoCAD, SolidWorks, ANSYS, Synopsys, Cadence 의 거의 전부.
데이터베이스 엔진 — MySQL, PostgreSQL, ClickHouse, MongoDB, RocksDB.
컴파일러 / 런타임 — LLVM, GCC, V8, JVM HotSpot 자체.
그래픽스 / GPU 런타임 — CUDA, ROCm, oneAPI, Vulkan implementation.
AI 추론 엔진 — llama.cpp, PyTorch C++ runtime, TensorFlow Lite, ONNX Runtime.

Rust 가 더 나을 가능성이 큰 경우

새 시스템 프로그래밍 프로젝트 (특히 메모리 안전이 중요한) — Rust.
WebAssembly 타겟 — Rust 가 훨씬 자연스럽다.
인터넷 인프라 (Cloudflare, Discord 등) — Rust 가 사실상 표준이 됨.
CLI 도구 — Go 또는 Rust.

Go / 자바 / TypeScript 가 정답인 경우

백엔드 API 서버 — Go / TypeScript / Java / Kotlin.
데이터 파이프라인 — Python / Scala / Java.
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

빌드 도구

패키지 매니저

Conan — https://conan.io/
vcpkg — https://vcpkg.io/

Sanitizers

AddressSanitizer — https://clang.llvm.org/docs/AddressSanitizer.html
UndefinedBehaviorSanitizer — https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
ThreadSanitizer — https://clang.llvm.org/docs/ThreadSanitizer.html
MemorySanitizer — https://clang.llvm.org/docs/MemorySanitizer.html

후계 언어 / 실험적 언어

Carbon — https://github.com/carbon-language/carbon-lang
Hylo — https://www.hylo-lang.org/
Cppfront — https://github.com/hsutter/cppfront

라이브러리 / 프로젝트

fmt (std::format / std::print 의 원본) — https://github.com/fmtlib/fmt
stdexec (NVIDIA / Senders 의 reference 구현) — https://github.com/NVIDIA/stdexec
mdspan (reference 구현) — https://github.com/kokkos/mdspan

한국·일본 게임/엔진

Unreal Engine — https://www.unrealengine.com/
Capcom RE Engine — https://www.capcom-games.com/re-engine/
NCSoft — https://kr.ncsoft.com/