LabHub

블로그

모던 C++ 2026 — C++ 23 / 26 / Modules / Reflection / Senders / std::print / CMake 3.30 / Conan 2 / vcpkg 심층 가이드

2026-05-16 · 40 분 읽기 · #cpp#cpp-23#cpp-26#modules#ranges#std-expected#std-print#std-generator#reflection#senders-receivers#linear-algebra#cmake#meson#xmake#bazel#conan#vcpkg#clang#gcc#msvc#sanitizers#carbon#cppfront#hylo#deep-dive

한국어English日本語

프롤로그 — "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년 만이다. 핵심 기능은 다음과 같다.

C++ 26 — 2026년 ratification, 진짜 주연은 Reflection

C++ 26 은 2026년에 ratification 이 끝나고 ISO/IEC 14882:2026 으로 출간될 예정이다 (2025년 6월의 Sofia 회의에서 feature complete 가 선언됐다). 핵심은 다음과 같다.

"왜 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 다.

#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 의 큰 기능도 짚는다.

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));
}

빌드 도구 측

효과

함정

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 에서 추가된 것

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) 에서 다듬어 온 모델이다.

핵심 개념

#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_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 지원이 들어왔다.

선택 가이드 (대략)

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 2vcpkg
출신JFrog (스페인)Microsoft
언어Python recipeCMake-flavored portfile
Profile매우 강함약함 (triplet 기반)
카탈로그1500+3000+
사내 cacheArtifactory 친화Azure Artifacts
학습곡선가파름완만
윈도우OK최고

대략: 사내 다양한 빌드 매트릭스 필요 → Conan, 빠른 시작 / Windows 메인 → vcpkg.

10장 · Clang 19 / GCC 14 / MSVC — 컴파일러

2026년 5월 기준 주요 컴파일러의 상태.

Clang 19~20 (LLVM)

GCC 14~15

MSVC (Visual Studio 17.10+)

선택 가이드

환경1순위
Linux 서버GCC 14
macOS / iOSApple Clang (또는 Homebrew LLVM)
Windows 데스크탑 / 게임MSVC
Android NDKClang
임베디드 ARMGCC arm-none-eabi 또는 Clang
HFT / 최신 표준 채용Clang trunk

11장 · libc++ vs libstdc++ — 표준 라이브러리

C++ 표준 라이브러리는 사실 표준의 일부일 뿐, 구현체는 따로 다. 2026년 기준 주요 구현체.

차이점

선택

Linux 에서 둘 중 어느 걸 쓰느냐는 대부분 distro 와 기본 컴파일러에 따라간다. macOS 는 사실상 libc++ 강제. 직접 고르고 싶다면 Clang + -stdlib=libc++ 로.

12장 · Sanitizers — ASan / UBSan / TSan / MSan

Sanitizer 는 LLVM 이 시작했고 GCC 가 따라온, 런타임 메모리·동기화 버그 검출 도구. C++ 코드의 quality 를 한 단계 끌어올렸다.

AddressSanitizer (ASan)

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)

ASan 과 동시에 쓸 수 있다.

ThreadSanitizer (TSan)

멀티스레드 코드의 race 검출은 거의 TSan 이 유일한 자동 도구.

MemorySanitizer (MSan)

권장 setup

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++ 사용처를 짚는다.

삼성전자

LG전자

NCSoft

토스 — 인프라 / 트레이딩 영역

(주: 토스의 핵심 서비스는 Kotlin 이고 C++ 비중은 낮지만, latency-critical 영역에서 사용 사례가 있다.)

기타 한국 회사

한국 C++ 커뮤니티

15장 · 일본 — Sony PlayStation, Square Enix, Capcom, Bandai Namco

일본은 게임·가전·자동차의 본고장이고, 거의 모두 C++ 위에 돌아간다.

Sony Interactive Entertainment

Square Enix

Capcom

Bandai Namco

Konami

SEGA

일본 자동차 (Toyota, Honda, Nissan)

일본 가전 (Sony, Panasonic, Sharp)

일본 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++.

함정

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 표준 / 위원회 문서

레퍼런스 / 학습

컴파일러 / 표준 라이브러리

빌드 도구

패키지 매니저

Sanitizers

후계 언어 / 실험적 언어

라이브러리 / 프로젝트

한국·일본 게임/엔진

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다