지금 C++26을 도입해도 되는가

표준 확정과 실무 도입은 다른 질문이다

이 책 첫 장에서 "C++26은 2026년 3월에 정식으로 확정됐다"고 했습니다. 그런데 표준 문서에 들어갔다는 것과 여러분 팀의 CI 파이프라인에서 오늘 컴파일된다는 것은 완전히 다른 이야기입니다. 이 마지막 장은 그 간극을 실제로 얼마나 좁혀야 하는지 정리합니다.

컴파일러별 지원 현황 — 이 책을 쓰는 시점 기준

기능	GCC	Clang	MSVC
정적 리플렉션 (P2996)	trunk에서 실험적 지원, 릴리스 버전 미포함	-freflection 플래그로 실험적 지원	실험적 지원, 프로덕션 비권장
Contracts (P2900)	부분 지원, 위반 핸들러 동작 미완성	부분 지원	부분 지원
std::execution (P2300)	표준 헤더 미포함	표준 헤더 미포함	표준 헤더 미포함

std::execution은 특히 주의할 점이 있습니다. 표준에는 채택됐지만 아직 어느 주요 컴파일러의 표준 라이브러리에도 <execution> 헤더로 정식 포함되지 않았습니다. 지금 이 모델을 실제로 써보려면 NVIDIA의 stdexec 같은 헤더 온리 참조 구현을 직접 프로젝트에 끌어와야 합니다. 이건 "아직 안 됐다"는 뜻이 아니라 오히려 좋은 소식에 가깝습니다 — 참조 구현이 이미 실전에서 검증되고 있고, 표준 라이브러리에 들어갈 버전도 그 구현과 크게 다르지 않을 가능성이 높기 때문입니다.

각 컴파일러의 지원 버전과 플래그는 계속 바뀌므로, 이 표의 구체적인 버전 번호보다는 **"셋 다 실험적 단계"**라는 결론 자체를 기억해두시길 권합니다. 실제 도입 전에는 반드시 cppreference의 컴파일러 지원 표(compiler support pages)를 그 시점 기준으로 다시 확인해야 합니다.

빌드 스크립트에서 기능 지원 여부를 하드코딩된 컴파일러 버전 대신 기능 테스트 매크로로 확인해두면, 컴파일러가 업데이트될 때마다 이 코드를 다시 손볼 필요가 없습니다.

#if defined(__cpp_impl_reflection) && __cpp_impl_reflection >= 202506L
    // 리플렉션 코드 경로
#else
    // 기존 매크로 기반 직렬화로 폴백
#endif

지금 당장 할 수 있는 것 / 기다려야 하는 것

지금 시도해볼 만한 것:

• 사이드 프로젝트나 신규 내부 도구에서 stdexec로 센더/리시버 패턴을 미리 연습하기
• 컴파일러의 최신 실험 플래그로 리플렉션 문법을 학습용 코드에 적용해보기 (프로덕션 배포 대상이 아닌 코드)
• 팀 내에서 Contracts의 audit/axiom 구분을 어떻게 쓸지 컨벤션을 미리 논의해두기

아직 기다려야 하는 것:

• 공개 API에 Contracts를 붙여서 배포하는 것 (위반 핸들러 동작이 컴파일러마다 다를 수 있어 ABI 리스크가 큽니다 — 5장 참고)
• 프로덕션 코드베이스의 직렬화 계층을 리플렉션 기반으로 전면 재작성하는 것
• std::execution을 표준 헤더로 가정하고 빌드 스크립트를 짜는 것 (지금은 서드파티 의존성 취급이 맞습니다)

사라진 기능도 기억해둘 것 — trivial relocatability

1장에서 짧게 언급했듯, trivial relocatability는 C++26에 들어가지 못했습니다. 이 기능은 객체를 복사 생성자 호출 없이 memcpy로 안전하게 옮길 수 있는지 타입 시스템 차원에서 표시하려던 것으로, std::vector의 재할당 같은 상황에서 상당한 성능 이득을 줄 것으로 기대됐습니다. 구현체 사이의 버그와 의미론적 이견 때문에 이번 표준에서 빠지고 다음 표준으로 미뤄졌습니다.

이걸 언급하는 이유는, 인터넷에서 "C++26 새 기능" 목록을 검색하면 여전히 이 기능이 섞여서 소개되는 경우가 있기 때문입니다. 제안됐다는 뉴스와 표준에 채택됐다는 사실을 항상 구분해서 읽어야 합니다. 특히 이런 대형 표준 개정 시기에는 논의 중인 제안서와 확정된 기능이 뒤섞여 보도되는 일이 흔합니다.

마치며

이 책에서 다룬 세 기능 — 리플렉션, Contracts, std::execution — 은 전부 "C++라는 언어가 20년 넘게 각자도생으로 풀어온 문제를 표준 문법으로 흡수하는" 흐름 위에 있습니다. 매크로와 코드 생성기 대신 리플렉션을, assert의 관례 대신 Contracts를, 콜백 지옥 대신 센더/리시버를 놓겠다는 방향입니다.

다만 방향이 맞다는 것과 오늘 프로덕션에 쓸 준비가 됐다는 것은 다른 문제입니다. 이 책을 지금 읽어야 하는 이유는 그 준비 기간 — 표준이 확정되고 컴파일러가 완전히 따라잡을 때까지의 1~2년 — 을 남들보다 먼저 이해하고 있으면, 실제로 컴파일러가 안정화됐을 때 팀에서 이 전환을 주도할 수 있는 사람이 되기 때문입니다.