pkglog
EN

C++ 메타프로그래밍의 진화: Template에서 Constexpr, 그리고 Reflection까지

작성 · · 16분 읽기 · 수정 고급 개념

들어가며

메타프로그래밍은 코드가 코드를 만들거나, 컴파일 타임에 타입과 값을 계산하는 프로그래밍을 말합니다. 런타임에 if로 분기하는 대신 컴파일러가 “이 타입이면 이 코드, 저 타입이면 저 코드”를 미리 골라 두기 때문에, 실행 파일에는 실제로 필요한 경로만 남습니다.

템플릿과 constexpr를 다뤘다면, 이 글에서는 C++ 메타프로그래밍이 어떻게 바뀌어 왔는지를 한 흐름으로 정리합니다. C++98 시절의 템플릿 메타프로그래밍(TMP)은 타입과 정수만 다룰 수 있었고, 반복은 재귀 인스턴스화로, 분기는 특수화로 표현해야 했습니다. C++11 이후 constexpr 함수, C++17의 if constexpr와 fold expression이 들어오면서 값 단위의 메타프로그래밍을 평범한 함수 코드처럼 쓸 수 있게 되었고, C++20의 Concepts는 타입 제약을 선언적으로 적게 해 주었습니다. 그리고 C++26에 채택된 정적 리플렉션은 지금까지 매크로나 코드 생성으로만 할 수 있던 “구조체의 멤버를 순회하는 일”을 표준 언어 기능으로 가져옵니다.

flowchart LR
    subgraph compile[컴파일 타임]
        C1[소스 코드] --> C2[템플릿 인스턴스화]
        C2 --> C3[constexpr 평가]
        C3 --> C4[타입 검사·조건 분기]
        C4 --> C5[기계어 생성]
    end
    subgraph runtime[런타임]
        R1[실행] --> R2[이미 결정된 코드만 실행]
    end
    C5 --> R1

메타프로그래밍이 필요해지는 상황

실무에서 메타프로그래밍을 찾게 되는 계기는 대체로 다음 몇 가지입니다.

첫째, 템플릿 함수가 정수형만 받아야 하는데 double이나 std::string이 들어오면 컴파일 에러로 막고 싶은 경우입니다. 일반 템플릿은 어떤 타입이든 받으므로, type traits와 enable_if 또는 Concepts로 “이 타입일 때만” 오버로드가 후보가 되도록 제한해야 합니다.

둘째, 멤버가 스무 개인 구조체에 to_json()을 손으로 쓰기 싫은 경우입니다. C++23까지의 표준만으로는 타입의 멤버 이름과 개수를 컴파일 타임에 조회할 수 없어서, 매크로·외부 코드 생성기·Boost.Hana/Describe/PFR 같은 라이브러리로 보완해 왔습니다. C++26 리플렉션이 이 문제를 겨냥합니다.

셋째, 문자열을 switch의 케이스로 쓰고 싶은 경우입니다. constexpr 함수로 문자열 해시를 컴파일 타임에 계산하면 케이스 라벨을 정수 상수로 만들 수 있습니다.

넷째, 가변 인자 템플릿에서 모든 타입이 조건을 만족할 때만 함수를 허용하고 싶은 경우입니다. 예전에는 재귀 템플릿을 따로 정의해야 했지만, C++17부터는 (std::is_integral_v<Ts> && ...) 한 줄로 끝납니다.

다섯째, 타입별로 구현이 조금씩 다른 함수를 enable_if 오버로드 여러 개로 쓰다 보니 읽기 어려워진 경우입니다. 대개 if constexpr로 한 함수 안에 정리할 수 있습니다.

템플릿 메타프로그래밍: type traits와 SFINAE

std::is_integral, std::is_pointer, std::is_same 같은 type traits는 타입에 대한 질문에 컴파일 타임 상수로 답합니다. 이 답을 std::enable_if에 넘기면 오버로드를 조건부로 켜고 끌 수 있고, if constexpr에 넘기면 함수 본문 안에서 분기할 수 있습니다.

SFINAE(Substitution Failure Is Not An Error)는 템플릿 인자를 시그니처에 치환하다가 실패하면 그것을 에러로 보지 않고 해당 후보만 오버로드 집합에서 제외하는 규칙입니다. enable_if는 이 규칙을 의도적으로 이용하는 도구였고, C++20의 requires와 Concepts가 같은 일을 훨씬 읽기 쉬운 문법으로 대신합니다.

TMP의 근본적인 한계는 다룰 수 있는 것이 타입과 상수뿐이라는 점입니다. 클래스의 멤버 이름이나 개수 같은 정보는 표준만으로는 얻을 수 없었고, Boost.Fusion·Boost.Hana는 매크로로 멤버를 다시 나열하게 하는 방식으로 이 빈틈을 메웠습니다.

flowchart LR
    subgraph cpp98[C++98/03]
        TMP1[템플릿 특수화]
        TMP2[재귀 템플릿]
    end
    subgraph cpp11[C++11]
        CE1[constexpr]
        SF1[SFINAE + enable_if]
    end
    subgraph cpp14[C++14]
        CE2[constexpr 확장]
        CE3[변수 템플릿]
    end
    subgraph cpp17[C++17]
        IF1[if constexpr]
        FE1[fold expression]
    end
    subgraph cpp20[C++20]
        CO1[Concepts]
        CE4[constexpr 확장]
    end
    subgraph cpp26[C++26]
        RF1[정적 Reflection]
    end
    TMP1 --> SF1
    TMP2 --> CE1
    CE1 --> CE2
    CE2 --> IF1
    SF1 --> CO1
    IF1 --> RF1

type traits 기본 사용법

#include <type_traits>
#include <iostream>
// std::is_integral_v<T>: C++17 변수 템플릿
// std::is_integral<T>::value: C++11 스타일
template <typename T>
void print_if_integral(T value) {
    if constexpr (std::is_integral_v<T>) {
        std::cout << "정수: " << value << "\n";
    } else {
        std::cout << "정수 아님\n";
    }
}
int main() {
    print_if_integral(42);      // 정수: 42
    print_if_integral(3.14);    // 정수 아님
}

SFINAE와 enable_if

#include <type_traits>
#include <iostream>
// 정수형일 때만 이 오버로드가 후보가 됨
template <typename T>
typename std::enable_if<std::is_integral_v<T>, T>::type
add_one(T x) {
    return x + 1;
}
// 부동소수형일 때만 이 오버로드가 후보가 됨
template <typename T>
typename std::enable_if<std::is_floating_point_v<T>, T>::type
add_one(T x) {
    return x + 1.0;
}
int main() {
    std::cout << add_one(10) << "\n";     // 11
    std::cout << add_one(3.14) << "\n";   // 4.14
    // add_one("hello");  // 컴파일 에러: 맞는 오버로드 없음
}

std::is_integral_v<T>가 false이면 std::enable_if<false, T>에는 type 멤버가 없습니다. 반환 타입을 만드는 치환이 실패하고, SFINAE 규칙에 따라 이 오버로드는 에러 없이 후보에서만 빠집니다.

constexpr, if constexpr, fold expression

C++11의 constexpr 함수는 본문이 사실상 return 문 하나로 제한되어 있어서 반복을 재귀로 써야 했습니다. C++14에서 지역 변수·반복문·여러 문장이 허용되었고, C++20에서는 try 블록, 가상 함수 호출, 컴파일 타임 동적 할당(평가가 끝나기 전에 해제되어야 함)까지 허용되면서 constexpr 함수는 거의 평범한 함수처럼 쓸 수 있게 되었습니다.

if constexpr는 컴파일 타임 조건에 따라 한 갈래만 인스턴스화합니다. 템플릿 안에서 타입별로 분기할 때 enable_if 오버로드를 여러 개 두지 않아도 됩니다.

fold expression은 파라미터 팩 전체에 이항 연산자를 한 번에 적용합니다. (std::is_integral_v<Ts> && ...)는 단항 우측 fold로, 각 타입에 대한 is_integral_v 결과를 &&로 이어 붙입니다. 따라서 all_integral<int, long, short>는 true, all_integral<int, double>는 false가 됩니다.

#include <type_traits>
// 모든 템플릿 인자가 정수형일 때 true
template <typename... Ts>
constexpr bool all_integral = (std::is_integral_v<Ts> && ...);
static_assert(all_integral<int, long, short>);
static_assert(!all_integral<int, double>);
// "모든 인자가 정수형일 때만" 오버로드 활성화
template <typename... Ts>
std::enable_if_t<all_integral<Ts...>, int> sum_all(Ts... args) {
    return (0 + ... + args);  // 이항 좌측 fold: 인자가 0개여도 동작
}
int main() {
    return sum_all(1, 2, 3);  // 6
}

if constexpr로 타입별 분기

#include <type_traits>
#include <cmath>
#include <string>
#include <iostream>
template <typename T>
auto process(T value) {
    if constexpr (std::is_integral_v<T>) {
        return value * 2;                       // 정수: 2배
    } else if constexpr (std::is_floating_point_v<T>) {
        return std::round(value);               // 부동소수: 반올림
    } else if constexpr (std::is_same_v<T, std::string>) {
        return static_cast<int>(value.size());  // 문자열: 길이
    } else {
        return 0;
    }
}
int main() {
    std::cout << process(21) << "\n";                  // 42
    std::cout << process(3.7) << "\n";                 // 4
    std::cout << process(std::string("hi")) << "\n";   // 2
}

일반 if였다면 T = std::string일 때도 std::round(value) 갈래가 인스턴스화되어 컴파일 에러가 납니다. if constexpr는 조건이 템플릿 인자에 의존할 때 선택되지 않은 갈래를 인스턴스화하지 않으므로 이 코드가 성립합니다. 또 각 인스턴스에서 살아남는 return이 하나뿐이라 auto 반환 타입이 인스턴스마다 다르게(int, double, int) 추론되는 것도 문제가 되지 않습니다.

constexpr로 컴파일 타임 문자열 해시

#include <cstdint>
#include <cstddef>
#include <string_view>
// djb2 해시. unsigned 오버플로는 모듈러 연산으로 정의된 동작
constexpr std::uint32_t hash_string(std::string_view s) {
    std::uint32_t hash = 5381;
    for (unsigned char c : s) {
        hash = hash * 33 + c;
    }
    return hash;
}
constexpr std::uint32_t operator""_hash(const char* str, std::size_t len) {
    return hash_string(std::string_view(str, len));
}
int dispatch(std::string_view cmd) {
    switch (hash_string(cmd)) {
        case "get"_hash: return 1;
        case "set"_hash: return 2;
        case "del"_hash: return 3;
        default:         return 0;
    }
}

케이스 라벨은 컴파일 타임 상수여야 하므로 사용자 정의 리터럴 _hash가 constexpr이어야 합니다. 케이스끼리 해시가 겹치면 “duplicate case value” 컴파일 에러로 드러나지만, 목록에 없는 입력이 우연히 같은 해시를 가질 수는 있습니다. 외부 입력을 받는 코드라면 케이스 안에서 cmd == "get"처럼 원래 문자열을 한 번 더 비교해 두는 편이 안전합니다. 참고로 operator"" _hash처럼 따옴표와 이름 사이에 공백을 두는 형태는 C++23에서 deprecated되었으니 붙여 쓰는 것이 좋습니다.

예제 모음

모든 인자가 정수형일 때만 동작하는 가변 인자 min

#include <type_traits>
#include <iostream>
template <typename T, typename... Rest>
std::enable_if_t<(std::is_integral_v<T> && ... && std::is_integral_v<Rest>), T>
min_integral(T first, Rest... rest) {
    T result = first;
    ((result = (rest < result) ? rest : result), ...);  // 콤마 fold로 순회
    return result;
}
int main() {
    std::cout << min_integral(3, 1, 4, 1, 5) << "\n";  // 1
    // min_integral(3, 1.5);  // 컴파일 에러
}

조건식은 (초기값 && ... && 팩) 형태의 이항 좌측 fold입니다. 타입이 서로 달라도(예: int와 long) 통과하며, 결과는 첫 인자 타입 T로 변환되므로 더 넓은 타입의 값이 잘릴 수 있다는 점은 주의해야 합니다. 부호 있는 타입과 없는 타입을 섞으면 비교 자체가 예상과 다르게 동작할 수도 있습니다.

타입 리스트에서 인덱스 찾기

#include <type_traits>
#include <cstddef>
template <typename T, typename... Ts>
struct index_of;
template <typename T, typename... Rest>
struct index_of<T, T, Rest...> : std::integral_constant<std::size_t, 0> {};
template <typename T, typename U, typename... Rest>
struct index_of<T, U, Rest...>
    : std::integral_constant<std::size_t, 1 + index_of<T, Rest...>::value> {};
static_assert(index_of<int, float, int, double>::value == 1);
static_assert(index_of<char, float, int, char>::value == 2);

찾는 타입이 리스트에 없으면 index_of<T>(팩이 빈 경우)에 정의가 없어 불완전 타입 에러가 납니다. 이것이 전형적인 TMP 스타일입니다. 반복은 재귀 특수화로, 종료 조건은 부분 특수화로 표현합니다.

컴파일 타임 팩토리얼

constexpr unsigned long long factorial(unsigned n) {
    return n <= 1 ? 1 : n * factorial(n - 1);
}
constexpr auto f10 = factorial(10);  // 3628800, 컴파일 타임에 계산
static_assert(factorial(5) == 120);

constexpr 변수의 초기화나 static_assert 안처럼 상수 표현식이 요구되는 문맥에서만 컴파일 타임 평가가 보장됩니다. 일반 변수에 대입하면 컴파일러가 런타임에 계산해도 됩니다. 반드시 컴파일 타임에 계산되어야 한다면 C++20의 consteval을 쓰면 됩니다.

if constexpr로 JSON 값 직렬화

#include <string>
#include <string_view>
#include <sstream>
#include <type_traits>
template <typename T>
std::string to_json(const T& value) {
    std::ostringstream oss;
    if constexpr (std::is_same_v<T, bool>) {       // bool을 먼저 검사해야 함
        oss << (value ? "true" : "false");
    } else if constexpr (std::is_arithmetic_v<T>) {
        oss << value;
    } else if constexpr (std::is_convertible_v<const T&, std::string_view>) {
        oss << '"' << std::string_view(value) << '"';  // 이스케이프 처리는 생략
    } else {
        static_assert(sizeof(T) == 0, "지원하지 않는 타입");
    }
    return oss.str();
}
// to_json(42)                → 42
// to_json(true)              → true
// to_json(std::string("hi")) → "hi"
// to_json("hi")              → "hi" (T = char[3])

분기 순서가 중요합니다. bool도 std::is_arithmetic_v를 만족하므로 산술 분기를 먼저 두면 true가 1로 출력됩니다. 또 to_json("hi")의 T는 std::string이 아니라 char[3]이므로, std::is_same_v<T, std::string>으로 검사하면 문자열 리터럴이 어느 분기에도 걸리지 않습니다. 여기서는 string_view로 변환 가능한지를 검사해 둘 다 처리했습니다.

Concepts로 제약 표현 (C++20)

#include <concepts>
#include <iterator>
#include <ranges>
#include <vector>
#include <iostream>
template <std::input_iterator It>
void print_range(It first, It last) {
    for (; first != last; ++first) {
        std::cout << *first << ' ';
    }
    std::cout << '\n';
}
// requires 절로 직접 쓰는 방법
template <typename C>
    requires requires(const C& c) {
        std::begin(c);
        std::end(c);
    }
void print_container(const C& c) {
    for (const auto& x : c) {
        std::cout << x << ' ';
    }
    std::cout << '\n';
}
int main() {
    std::vector<int> v = {1, 2, 3};
    print_range(v.begin(), v.end());
    print_container(v);
}

requires requires는 처음 보면 오타처럼 보이지만, 앞의 requires는 requires 절이고 뒤의 requires는 requires 표현식입니다. 이런 임시 제약이 반복되면 std::ranges::range 같은 표준 콘셉트나 이름 있는 콘셉트로 빼는 것이 좋습니다.

자주 만나는 컴파일 에러

조건이 모든 타입을 덮지 못해 오버로드가 하나도 남지 않음

error: no matching function for call to 'foo(const char*)'

enable_if 조건이 false인 오버로드는 후보에서 빠지므로, 어떤 조건도 만족하지 못하는 타입이 들어오면 후보가 하나도 남지 않습니다.

// 정수와 부동소수만 처리. const char*는 둘 다 탈락 → 에러
template <typename T>
std::enable_if_t<std::is_integral_v<T>> foo(T) {}
template <typename T>
std::enable_if_t<std::is_floating_point_v<T>> foo(T) {}

// 나머지 타입을 받는 fallback이 필요하다면 조건을 상호 배타적이면서 전체를 덮도록
template <typename T>
std::enable_if_t<std::is_integral_v<T>> bar(T) {}
template <typename T>
std::enable_if_t<!std::is_integral_v<T>> bar(T) {}

// Concepts로 쓰면 에러 메시지가 어떤 제약이 실패했는지 직접 알려 줌
template <std::integral T> void baz(T) {}
template <std::floating_point T> void baz(T) {}

반대로 두 조건이 동시에 참이 될 수 있으면(예: is_integral과 is_arithmetic) 두 오버로드가 모두 후보로 남아 모호한 호출 에러가 납니다. Concepts는 한 콘셉트가 다른 콘셉트를 포함(subsume)하면 더 구체적인 쪽을 고르지만, enable_if에는 그런 우선순위가 없습니다.

C++11 constexpr 함수에서 반복문 사용

error: body of constexpr function not a return-statement

C++11의 constexpr 함수는 본문에 return 문 하나(와 static_assert, using 등 몇 가지)만 허용합니다. 반복문을 쓰려면 C++14 이상이 필요하고, C++11에서는 삼항 연산자와 재귀로 바꿔야 합니다.

// C++11: 삼항 연산자와 재귀
constexpr int sum_below_11(int n) {
    return n <= 0 ? 0 : (n - 1) + sum_below_11(n - 1);
}
// C++14 이상: 반복문 허용
constexpr int sum_below_14(int n) {
    int s = 0;
    for (int i = 0; i < n; ++i) s += i;
    return s;
}

if constexpr의 버려진 갈래가 여전히 검사되는 경우

if constexpr가 선택되지 않은 갈래를 인스턴스화하지 않는 것은 템플릿 안에서, 그리고 조건이 템플릿 인자에 의존할 때뿐입니다. 템플릿이 아닌 함수에서는 버려진 갈래도 완전히 컴파일됩니다. 템플릿 안에서도 템플릿 인자에 의존하지 않는 코드는 정의 시점에 검사됩니다.

template <typename T>
auto foo(T x) {
    if constexpr (std::is_integral_v<T>) {
        return x + 1;
    } else {
        return x.size();  // T = int일 때는 인스턴스화되지 않으므로 OK
    }
}
void bar() {
    if constexpr (false) {
        int x = "invalid";  // 템플릿 밖이므로 에러
    }
}

static_assert(false, "...")를 템플릿의 else 갈래에 넣는 흔한 패턴도 이 규칙에 걸립니다. C++20까지는 조건이 템플릿 인자에 의존하지 않으므로 해당 갈래가 선택되지 않아도 ill-formed였고, 컴파일러는 정의 시점에 에러를 낼 수 있었습니다. 그래서 static_assert(sizeof(T) == 0)이나 template <class> inline constexpr bool always_false = false;를 만들어 static_assert(always_false<T>)처럼 의존적인 조건으로 바꾸는 우회법이 쓰였습니다. P2593이 C++23에서 이 제약을 풀었고 결함 보고(DR)로 이전 표준 모드에도 적용되었지만, 오래된 컴파일러를 지원해야 한다면 의존적 조건을 쓰는 편이 호환성이 좋습니다.

fold expression 괄호 누락

error: expected primary-expression before '...' token

fold expression은 괄호가 문법의 일부입니다.

template <typename... Ts>
constexpr bool all_int_bad = std::is_integral_v<Ts> && ...;    // 에러
template <typename... Ts>
constexpr bool all_int = (std::is_integral_v<Ts> && ...);      // OK

빈 파라미터 팩에 대한 단항 fold

단항 fold에서 팩이 비어 있을 때 값이 정의된 연산자는 &&(결과 true), ||(결과 false), 콤마(결과 void()) 세 가지뿐입니다. +나 *의 단항 fold에 빈 팩이 들어오면 컴파일 에러입니다.

template <typename... Ts>
auto sum_bad(Ts... args) {
    return (args + ...);      // sum_bad()는 에러
}
template <typename... Ts>
auto sum(Ts... args) {
    return (0 + ... + args);  // 이항 fold: sum()은 0
}

템플릿 인스턴스화 폭발

템플릿 인자 조합이 많거나 재귀 인스턴스화가 깊으면 컴파일 시간과 메모리가 크게 늘어납니다. 같은 인스턴스가 여러 번역 단위에서 반복 생성되는 것도 원인입니다. 대응 방법은 몇 가지가 있습니다. 공통 헤더에서 자주 쓰는 인스턴스는 extern template으로 선언하고 한 .cpp에서만 명시적 인스턴스화를 하면 다른 번역 단위의 중복 인스턴스화를 줄일 수 있습니다. 타입에 의존하지 않는 부분은 비템플릿 함수로 빼고, 타입 조합이 계속 늘어나는 경계에서는 타입 소거(std::function, 가상 인터페이스 등)를 고려합니다. 재귀 템플릿으로 짠 타입 리스트 연산은 fold expression이나 std::index_sequence로 바꾸면 인스턴스 수가 줄어드는 경우가 많습니다.

// header.h
template <typename T> void process(T& a) { /* ... */ }
extern template void process<int>(int&);   // 여기서는 인스턴스화하지 않음

// process.cpp
template void process<int>(int&);          // 명시적 인스턴스화는 여기서 한 번만

enable_if를 기본 템플릿 인자에 두었을 때의 재정의 에러

enable_if를 기본 템플릿 인자 위치에 두면 읽기는 좋지만, 조건만 다른 두 오버로드를 만들 수 없습니다. 기본 템플릿 인자는 함수 템플릿 시그니처의 일부가 아니므로 두 선언이 같은 템플릿의 재선언으로 취급되기 때문입니다.

// 에러: redefinition of 'template<class T, class> T f(T)'
template <typename T, typename = std::enable_if_t<std::is_integral_v<T>>>
T f(T x) { return x + 1; }
template <typename T, typename = std::enable_if_t<!std::is_integral_v<T>>>
T f(T x) { return x; }

// 해결 1: 반환 타입에 enable_if
template <typename T>
std::enable_if_t<std::is_integral_v<T>, T> g(T x) { return x + 1; }
template <typename T>
std::enable_if_t<!std::is_integral_v<T>, T> g(T x) { return x; }

// 해결 2: 비타입 템플릿 인자로 (타입이 달라지므로 서로 다른 시그니처)
template <typename T, std::enable_if_t<std::is_integral_v<T>, int> = 0>
T h(T x) { return x + 1; }
template <typename T, std::enable_if_t<!std::is_integral_v<T>, int> = 0>
T h(T x) { return x; }

TMP, constexpr, Reflection 비교

구분TMP (C++98~11)constexpr 계열 (C++11~20)정적 Reflection (C++26)
다루는 대상타입, 정수 상수값, 타입(if constexpr와 함께)타입, 멤버, 이름 등 선언 정보
대표 문법특수화, 재귀 인스턴스화constexpr 함수, if constexpr, fold^^T, [: r :], std::meta:: 함수
가독성낮음일반 함수에 가까움선언적
멤버 조회불가 (매크로·라이브러리로 우회)불가표준 지원
직렬화수동 작성, 매크로값 단위 분기까지만멤버 순회로 자동화 가능

컴파일 시간 측면에서는 재귀 인스턴스화가 깊은 TMP가 대체로 가장 불리하고, 같은 계산을 constexpr 함수로 옮기면 인스턴스 수가 줄어드는 경우가 많습니다. 다만 constexpr 평가도 컴파일러 내부 인터프리터로 실행되므로 반복 횟수가 크면 역시 느려지며, 컴파일러마다 평가 단계 수 제한(-fconstexpr-steps, -fconstexpr-ops-limit 등)이 있습니다.

같은 조건을 시대별로 쓰면 차이가 분명합니다.

#include <type_traits>
#include <concepts>
// C++11: 가변 인자 템플릿 + 재귀 특수화
template <typename... Ts>
struct all_integral_impl : std::true_type {};           // 빈 팩: true
template <typename T, typename... Rest>
struct all_integral_impl<T, Rest...>
    : std::integral_constant<bool,
        std::is_integral<T>::value && all_integral_impl<Rest...>::value> {};

// C++17: fold expression
template <typename... Ts>
constexpr bool all_integral = (std::is_integral_v<Ts> && ...);

// C++20: Concepts
template <std::integral... Ts>
void foo(Ts... args) {}

C++98/03에는 가변 인자 템플릿이 없었기 때문에, 이런 조건은 인자 개수별 오버로드를 여러 개 만들거나 Boost.MPL 같은 타입 리스트 라이브러리를 써야 했습니다.

어떤 도구를 고를까

flowchart TD
    A[타입에 따라 다른 코드?] --> B{함수 하나 안에서 분기?}
    B -->|예| C[if constexpr]
    B -->|아니오| D{오버로드 집합을 제한?}
    D -->|예| E[Concepts 또는 enable_if]
    D -->|아니오| F[템플릿 특수화]
    A --> G[값 계산?]
    G --> H[constexpr / consteval 함수]
    A --> I[멤버 순회?]
    I --> J[Reflection 또는 코드 생성]

한 함수 안에서 타입별로 로직만 조금 다르면 if constexpr가 가장 읽기 쉽습니다. 오버로드마다 인터페이스나 의미가 다르고, 호출자가 다른 오버로드를 제공할 수 있어야 한다면 Concepts(C++20 이전이면 enable_if)로 후보를 제한합니다. 특정 타입에 대해 클래스 전체의 표현이 달라져야 할 때는 템플릿 특수화를 씁니다. std::vector<bool>이 그 예입니다.

제 경험상 이 순서는 “도입 순서”로도 잘 맞습니다. 레거시 코드의 enable_if 오버로드 묶음을 정리할 때, 먼저 if constexpr로 본문을 한 함수로 모으고, 그다음 외부로 드러나는 제약만 Concepts로 옮기는 식으로 진행하면 동작 변화 없이 단계적으로 바꿀 수 있습니다. 한 번에 Concepts로 바꾸려다 보면 subsumption 규칙 때문에 예전에 모호하지 않던 호출이 갑자기 다른 오버로드로 해석되는 일이 생기기 쉽습니다.

컴파일 타임 검증에는 static_assert가 여전히 가장 직접적인 도구입니다.

#include <type_traits>
#include <cstdint>
struct Packet { std::uint32_t id; std::uint16_t len; std::uint16_t flags; };
static_assert(sizeof(void*) == 8, "64비트 빌드만 지원");
static_assert(std::is_trivially_copyable_v<Packet>, "memcpy로 복사할 수 있어야 함");
static_assert(sizeof(Packet) == 8, "와이어 포맷과 크기가 맞아야 함");

정적 Reflection으로의 진화

정적 리플렉션 제안 P2996(“Reflection for C++26”)은 2025년 6월 표준 위원회 회의에서 C++26 작업 초안에 채택되었고, 반복을 위한 확장 문(expansion statement, template for)도 함께 채택되었습니다. 핵심은 ^^T로 타입이나 선언을 std::meta::info라는 컴파일 타임 값으로 바꾸고, std::meta:: 네임스페이스의 consteval 함수로 그 값을 조회한 뒤, 스플라이서 [: r :]로 다시 코드 안에 끼워 넣는 것입니다. 초기 제안 개정판에서는 연산자가 ^T였다가 Objective-C 블록 문법과의 충돌 때문에 ^^T로 바뀌었고, 조회 함수의 시그니처도 개정 중에 접근 제어 문맥(access_context)을 받도록 바뀌었습니다. 아래 코드는 채택된 설계를 기준으로 한 스케치이며, 실제로 컴파일하려면 리플렉션을 구현한 실험적 컴파일러가 필요합니다.

// C++26 정적 리플렉션 스케치 (컴파일러 지원은 아직 실험 단계)
#include <meta>
#include <iostream>
#include <string>
struct User {
    int id;
    std::string name;
};
template <typename T>
void print_fields(const T& obj) {
    constexpr auto ctx = std::meta::access_context::current();
    template for (constexpr auto m :
                  std::define_static_array(
                      std::meta::nonstatic_data_members_of(^^T, ctx))) {
        std::cout << std::meta::identifier_of(m) << " = " << obj.[:m:] << "\n";
    }
}

리플렉션이 없는 지금은 멤버를 매크로로 한 번 더 나열하거나, 외부 스키마에서 코드를 생성하거나, Boost.PFR(집합체 타입의 멤버를 구조화된 바인딩 트릭으로 순회, 이름은 C++20과 최신 컴파일러에서 제한적으로 지원)이나 Boost.Describe(매크로로 멤버 목록을 등록) 같은 라이브러리를 씁니다. 매크로 방식의 가장 큰 문제는 구조체에 멤버를 추가하고 매크로 목록을 고치지 않았을 때 컴파일 에러 없이 직렬화에서만 조용히 빠진다는 점입니다. 리플렉션은 선언 자체를 조회하므로 이런 불일치가 원천적으로 생기지 않습니다.

flowchart TB
    subgraph now["현재 (TMP/매크로)"]
        A1[구조체 정의] --> A2[매크로로 멤버 나열]
        A2 --> A3[코드 생성 또는 수동 to_json]
        A3 --> A4[정의와 목록이 어긋날 위험]
    end
    subgraph future["C++26 Reflection"]
        B1[구조체 정의] --> B2[^^T로 멤버 정보 조회]
        B2 --> B3[template for로 멤버 순회]
        B3 --> B4[선언만으로 직렬화]
    end
    A1 -.->|동일| B1
방식장점단점
수동 작성명확하고 디버깅이 쉬움반복 작업, 멤버 추가 시 누락 위험
매크로반복 감소가독성 저하, 디버깅 어려움
코드 생성대량 자동화빌드 단계와 도구 의존성 추가
C++26 Reflection선언적, 표준컴파일러 지원이 아직 실험 단계

같이 보면 좋은 글

자주 묻는 질문 (FAQ)

Q. enable_if와 Concepts 중 무엇을 써야 하나요?

C++20 이상을 쓸 수 있다면 Concepts를 권장합니다. 선언이 읽기 쉽고, 실패한 제약을 에러 메시지가 직접 보여 주며, 콘셉트 사이의 포함 관계로 더 구체적인 오버로드를 고를 수도 있습니다. C++11/14/17 환경에서는 enable_if를 계속 쓰면 됩니다.

Q. if constexpr과 일반 if의 차이는 무엇인가요?

if constexpr는 조건을 컴파일 타임에 평가하고, 템플릿 안에서 조건이 템플릿 인자에 의존할 때 선택되지 않은 갈래를 인스턴스화하지 않습니다. 그래서 그 타입에서는 성립하지 않는 코드가 다른 갈래에 있어도 됩니다. 일반 if는 조건이 상수라도 모든 갈래가 컴파일되고 타입 검사를 받습니다.

이전 글: C++의 미래 #44-2: C++·Rust 상호 운용 다음 글: [커리어 가이드 #45-1] C++ 오픈소스 기여: 유명 라이브러리 분석부터 첫 Pull Request까지