Previous
Next
C++ 템플릿 템플릿 인자 | template template parameter 가이드

C++ 템플릿 템플릿 인자 | template template parameter 가이드

· 13분 읽기 · 수정 고급 튜토리얼
C++ 템플릿 템플릿 인자 | template template parameter 가이드

이 글의 핵심

템플릿 템플릿 인자(template template parameter) 는 템플릿이 다른 템플릿을 인자로 받게 하는 문법입니다. vector<int>처럼 이미 구체화된 타입이 아니라, 어떤 컨테이너 템플릿을 받아서 그… 개념과 예제 코드를 단계적으로 다루며, 실무·학습에 참고할 수 있도록 구성했습니다.

템플릿 템플릿 인자란?

템플릿 템플릿 인자(template template parameter) 는 템플릿이 다른 템플릿을 인자로 받게 하는 문법입니다. vector<int>처럼 이미 구체화된 타입이 아니라, “어떤 컨테이너 템플릿”을 받아서 그 템플릿에 요소 타입만 넘기고 싶을 때 사용합니다. 템플릿 기초와 템플릿 특수화를 먼저 익히면 이해하기 쉽습니다.

기본 예시

#include <vector>
#include <list>
#include <iostream>
template<template<typename> class Container, typename T>
struct Wrapper {
    Container<T> data;
    
    void add(T value) {
        data.push_back(value);
    }
    
    void print() const {
        for (const auto& item : data) {
            std::cout << item << " ";
        }
        std::cout << '\n';
    }
};
template<typename T>
using Vec = std::vector<T>;
int main() {
    Wrapper<Vec, int> w;  // Wrapper 내부는 std::vector<int>
    w.add(1);
    w.add(2);
    w.add(3);
    w.print();  // 1 2 3
    return 0;
}

동작 원리: Container는 “한 개의 타입 인자를 받는 템플릿”이고, Wrapper는 그 템플릿과 요소 타입 T를 받아 Container<T>를 멤버로 가집니다. 이렇게 하면 Wrapper를 vector, list, deque 등 다양한 컨테이너와 함께 사용할 수 있습니다. CTAD와의 차이: 클래스 템플릿 인자 추론(CTAD)은 “생성자 인자로부터 템플릿 인자 추론”이고, 템플릿 템플릿 인자는 “템플릿 자체를 인자로 받는 것”입니다. 역할이 다릅니다.

C++17: typename으로도 선언

C++17부터는 class 대신 typename을 쓸 수 있어, 템플릿 인자라는 것이 더 분명해집니다.

template<template<typename> typename Container, typename T>
void use(Container<T>& c) { }

표준 컨테이너에 적용할 때 주의

std::vector, std::list 등은 두 번째 기본 템플릿 인자(할당자)를 갖습니다. 템플릿 템플릿 인자로 그대로 넘기려면 인자 개수를 맞춰야 합니다.

// std::vector의 실제 정의
// template<typename T, typename Alloc = std::allocator<T>> class vector;
// ❌ 인자 개수 불일치
// template<template<typename> class Container, typename T>
// struct Adapter {
//     Container<T> data;  // 에러: vector는 2개 인자 필요
// };
// ✅ 해결 1: 인자 개수 맞추기
template<template<typename, typename> class Container, typename T>
struct Adapter {
    Container<T, std::allocator<T>> data;
};
Adapter<std::vector, int> a;  // OK
// ✅ 해결 2: using으로 래핑 (더 간결)
template<typename T>
using Vec = std::vector<T>;
template<template<typename> class Container, typename T>
struct SimpleAdapter {
    Container<T> data;
};
SimpleAdapter<Vec, int> b;  // OK

왜 이런 문제가?: 템플릿 템플릿 인자는 정확한 인자 개수를 요구합니다. std::vector는 2개 인자(타입, 할당자)를 받지만, template<typename>은 1개만 받으므로 불일치가 발생합니다. 실무 패턴:

  1. using 별칭: 표준 컨테이너를 한 인자 템플릿으로 래핑
  2. 가변 인자: C++17 이후 template<typename...>로 유연하게 받기
// C++17: 가변 인자로 유연하게
template<template<typename...> class Container, typename T>
struct FlexibleAdapter {
    Container<T> data;  // vector, list, set 모두 OK
};
FlexibleAdapter<std::vector, int> v;
FlexibleAdapter<std::list, int> l;
FlexibleAdapter<std::set, int> s;

실전 예시 1: 컨테이너 정책 주입

여러 컨테이너를 같은 인터페이스로 쓰는 유틸을 만들 때, 템플릿 템플릿 인자로 “컨테이너 템플릿”을 받을 수 있습니다.

#include <vector>
#include <list>
#include <iostream>
template<typename T>
using Vec = std::vector<T>;
template<typename T>
using List = std::list<T>;
template<template<typename> class Container, typename T>
class Repository {
    Container<T> items;
public:
    void add(T x) { items.push_back(x); }
    size_t size() const { return items.size(); }
    
    void print() const {
        for (const auto& item : items) {
            std::cout << item << " ";
        }
        std::cout << '\n';
    }
};
int main() {
    // vector 기반
    Repository<Vec, int> repo_vec;
    repo_vec.add(1);
    repo_vec.add(2);
    repo_vec.print();  // 1 2
    
    // list 기반 (list는 push_back 있음)
    Repository<List, int> repo_list;
    repo_list.add(10);
    repo_list.add(20);
    repo_list.print();  // 10 20
    
    return 0;
}

실무 활용: 데이터 저장소의 내부 구현을 유연하게 바꿀 수 있습니다. 성능 테스트 시 vector vs list를 쉽게 비교할 수 있습니다.

실전 예시 2: 스마트 포인터 정책

#include <memory>
#include <iostream>
template<template<typename> class Ptr, typename T>
class ResourceManager {
    Ptr<T> resource;
public:
    ResourceManager(T* raw) : resource(raw) {}
    
    T* get() { return resource.get(); }
    void reset(T* raw = nullptr) { resource.reset(raw); }
};
// unique_ptr 기반 (독점 소유)
ResourceManager<std::unique_ptr, int> mgr1(new int(42));
// shared_ptr 기반 (공유 소유)
ResourceManager<std::shared_ptr, int> mgr2(new int(100));

실무 의미: 소유권 정책을 템플릿 인자로 받아, 같은 코드로 독점/공유 소유를 선택할 수 있습니다.

실전 예시 3: 표준 라이브러리 패턴 - Allocator

#include <memory>
#include <vector>
template<typename T, template<typename> class Allocator = std::allocator>
class CustomVector {
    std::vector<T, Allocator<T>> data_;
public:
    void push_back(const T& value) {
        data_.push_back(value);
    }
    size_t size() const { return data_.size(); }
};
// 기본 allocator 사용
CustomVector<int> v1;
// 커스텀 allocator 사용
template<typename T>
using CustomAlloc = std::allocator<T>;  // 실제로는 커스텀 구현
CustomVector<int, CustomAlloc> v2;

실무 활용: 메모리 풀, 커스텀 할당자를 주입하여 성능을 최적화할 수 있습니다.

관련 개념과 함께 보기

자주 발생하는 문제

문제 1: 표준 컨테이너 인자 개수 불일치

증상: error: template template argument has different template parameters

// ❌ 에러
template<template<typename> class Container, typename T>
struct Bad {
    Container<T> data;  // vector는 2개 인자 필요
};
// Bad<std::vector, int> b;  // 컴파일 에러

해결:

// ✅ 해결 1: using 래퍼
template<typename T> using Vec = std::vector<T>;
Bad<Vec, int> b1;
// ✅ 해결 2: 인자 개수 맞추기
template<template<typename, typename> class Container, typename T>
struct Good {
    Container<T, std::allocator<T>> data;
};
Good<std::vector, int> b2;
// ✅ 해결 3: 가변 인자 (C++17)
template<template<typename...> class Container, typename T>
struct Flexible {
    Container<T> data;
};
Flexible<std::vector, int> b3;

문제 2: 구체화된 타입 전달

증상: error: template argument must be a class template

// ❌ 구체화된 타입 전달
// Wrapper<std::vector<int>, int> w;  // 에러
// ✅ 템플릿 이름만 전달
Wrapper<Vec, int> w;

핵심: 템플릿 템플릿 인자는 템플릿 자체(예: std::vector)를 받지, 구체화된 타입(예: std::vector<int>)을 받지 않습니다.

문제 3: 기본 인자와 호환성

// std::map은 4개 인자
// template<typename Key, typename T, typename Compare = std::less<Key>, 
//          typename Alloc = std::allocator<std::pair<const Key, T>>> class map;
// using으로 래핑 필요
template<typename K, typename V>
using Map = std::map<K, V>;
template<template<typename, typename> class Container, typename K, typename V>
struct MapWrapper {
    Container<K, V> data;
};
MapWrapper<Map, int, std::string> mw;

실무 패턴

패턴 1: 컨테이너 추상화 레이어

// 컨테이너 인터페이스 통일
template<template<typename> class Container, typename T>
class DataStore {
    Container<T> storage_;
public:
    void store(T value) { storage_.push_back(value); }
    T retrieve(size_t index) { return storage_[index]; }
    size_t count() const { return storage_.size(); }
};
// 성능 테스트: vector vs deque
using VecStore = DataStore<Vec, int>;
using DequeStore = DataStore<Deque, int>;

패턴 2: 정책 기반 설계 (Policy-Based Design)

template<typename T, template<typename> class StoragePolicy>
class Cache {
    StoragePolicy<T> storage_;
public:
    void put(const T& item) { storage_.add(item); }
    T get() { return storage_.retrieve(); }
};
// 다양한 저장 정책
template<typename T> class VectorStorage { /* ....*/ };
template<typename T> class ListStorage { /* ....*/ };
template<typename T> class SetStorage { /* ....*/ };
Cache<int, VectorStorage> cache1;  // vector 기반
Cache<int, SetStorage> cache2;     // set 기반 (중복 제거)

정리

항목설명
문법template<template<typename> class C, typename T> (C++17부터 typename 가능)
용도컨테이너·할당자 등 “템플릿인 타입”을 유연하게 받을 때
표준 컨테이너인자 개수·기본 인자 때문에 using 래퍼를 두고 쓰는 경우가 많음
실무정책 기반 설계, 컨테이너 추상화, 성능 테스트에 활용

FAQ

Q1: 템플릿 템플릿 인자는 언제 사용하나요?

A: 컨테이너, 스마트 포인터, 할당자 등 “템플릿 자체”를 정책으로 주입하고 싶을 때 사용합니다.

Q2: std::vector를 직접 넘길 수 없나요?

A: std::vector는 2개 인자를 받으므로, using으로 1개 인자 템플릿으로 래핑하거나, template<typename...>로 가변 인자를 받아야 합니다.

Q3: class vs typename 키워드?

A: C++17 이전에는 class만 가능했고, C++17부터 typename도 사용할 수 있습니다. 의미는 동일합니다.

Q4: 실무에서 자주 사용하나요?

A: 라이브러리 설계, 정책 기반 설계, 제네릭 컨테이너 래퍼에서 사용합니다. 일반 애플리케이션 코드에서는 드물지만, 재사용 가능한 컴포넌트를 만들 때 유용합니다.

Q5: 디버깅 팁은?

A:

  • 에러 메시지에서 “template template parameter” 키워드 확인
  • 인자 개수 불일치는 using 래퍼로 해결
  • static_assert로 컨테이너 요구사항 검증

Q6: 학습 리소스는?

A:

같이 보면 좋은 글 (내부 링크)

이 주제와 연결되는 다른 글입니다.

관련 글

심화 부록: 구현·운영 관점

이 부록은 앞선 본문에서 다룬 주제(「C++ 템플릿 템플릿 인자 | template template parameter 가이드」)를 구현·런타임·운영 관점에서 다시 압축합니다. 도메인별 세부 구현은 글마다 다르지만, 입력 검증 → 핵심 연산 → 부작용(I/O·네트워크·동시성) → 관측의 흐름으로 장애를 나누면 원인 추적이 빨라집니다.

내부 동작과 핵심 메커니즘

flowchart TD
  A[입력·요청·이벤트] --> B[파싱·검증·디코딩]
  B --> C[핵심 연산·상태 전이]
  C --> D[부작용: I/O·네트워크·동시성]
  D --> E[결과·관측·저장]
sequenceDiagram
  participant C as 클라이언트/호출자
  participant B as 경계(런타임·게이트웨이·프로세스)
  participant D as 의존성(API·DB·큐·파일)
  C->>B: 요청/이벤트
  B->>D: 조회·쓰기·RPC
  D-->>B: 지연·부분 실패·재시도 가능
  B-->>C: 응답 또는 오류(코드·상관 ID)
  • 불변 조건(Invariant): 버퍼 경계, 프로토콜 상태, 트랜잭션 격리, FD 상한 등 단계별로 문장으로 적어 두면 디버깅 비용이 줄어듭니다.
  • 결정성: 순수 층과 시간·네트워크·스케줄에 의존하는 층을 분리해야 테스트와 장애 분석이 쉬워집니다.
  • 경계 비용: 직렬화, 인코딩, syscall 횟수, 락 경합, 할당·GC, 캐시 미스를 의심 목록에 둡니다.
  • 백프레셔: 생산자가 소비자보다 빠를 때 버퍼·큐·스트림에서 속도를 줄이는 신호를 어디에 둘지 정의합니다.

프로덕션 운영 패턴

영역운영 관점 질문
관측성요청 단위 상관 ID, 에러율·지연 p95/p99, 의존성 타임아웃·재시도가 대시보드에 보이는가
안전성입력 검증·권한·비밀·감사 로그가 코드 경로마다 일관적인가
신뢰성재시도는 멱등 연산에만 적용되는가, 서킷 브레이커·백오프·DLQ가 있는가
성능캐시·배치 크기·커넥션 풀·인덱스·백프레셔가 데이터 규모에 맞는가
배포롤백 룬북, 카나리/블루그린, 마이그레이션·피처 플래그가 문서화되어 있는가
용량피크 트래픽·디스크·FD·스레드 풀 상한을 주기적으로 검증하는가

스테이징은 데이터 양·네트워크 RTT·동시성을 프로덕션에 가깝게 맞출수록 재현율이 올라갑니다.

확장 예시: 엔드투엔드 미니 시나리오

앞선 본문 주제(「C++ 템플릿 템플릿 인자 | template template parameter 가이드」)를 배포·운영 흐름에 맞춰 옮긴 체크리스트입니다. 도메인에 맞게 단계 이름만 바꿔 적용할 수 있습니다.

  1. 입력 계약 고정: 스키마·버전·최대 페이로드·타임아웃·에러 코드를 경계에 둔다.
  2. 핵심 경로 계측: 요청 ID, 단계별 지연, 외부 호출 결과 코드를 로그·메트릭·트레이스에서 한 흐름으로 본다.
  3. 실패 주입: 의존성 타임아웃·5xx·부분 데이터·락 대기를 스테이징에서 재현한다.
  4. 호환·롤백: 설정/마이그레이션/클라이언트 버전을 되돌릴 수 있는지 확인한다.
  5. 부하 후 검증: 피크 대비 p95/p99, 에러율, 리소스 상한, 알림 임계값을 점검한다.
handle(request):
  ctx = newCorrelationId()
  validated = validateSchema(request)
  authorize(validated, ctx)
  result = domainCore(validated)
  persistOrEmit(result, idempotentKey)
  recordMetrics(ctx, latency, outcome)
  return result

문제 해결(Troubleshooting)

증상가능 원인조치
간헐적 실패레이스, 타임아웃, 외부 의존성, DNS최소 재현 스크립트, 분산 트레이스·로그 상관관계, 재시도·서킷 설정 점검
성능 저하N+1, 동기 I/O, 락 경합, 과도한 직렬화, 캐시 미스프로파일러·APM으로 핫스팟 확인 후 한 가지씩 제거
메모리 증가캐시 무제한, 구독/리스너 누수, 대용량 버퍼, 커넥션 미반납상한·TTL·힙/FD 스냅샷 비교
빌드·배포만 실패환경 변수, 권한, 플랫폼 차이, lockfileCI 로그와 로컬 diff, 런타임·이미지 버전 핀
설정 불일치프로필·시크릿·기본값, 리전스키마 검증된 설정 단일 소스와 배포 매트릭스 표준화
데이터 불일치비멱등 재시도, 부분 쓰기, 캐시 무효화 누락멱등 키·아웃박스·트랜잭션 경계 재검토

권장 순서: (1) 최소 재현 (2) 최근 변경 범위 축소 (3) 환경·의존성 차이 (4) 관측으로 가설 검증 (5) 수정 후 회귀·부하 테스트.

배포 전에는 git add → git commit → git push 후 npm run deploy 순서를 권장합니다.

이 글에서 다루는 키워드 (관련 검색어)

C++, template, template template parameter, container 등으로 검색하시면 이 글이 도움이 됩니다.