[Optimization(C++) 00] Introduction: Low-latency C++ 언어 최적화

**Low-latency C++**란 마이크로초(µs) 단위 지연이 중요한 환경에서, 언어·라이브러리 수준의 비용을 정량적으로 알고 줄이는 작성 방식을 말합니다. 이 트랙은 “C++를 더 잘 쓰면 해결되는 성능"에만 집중합니다.

“Premature optimization is the root of all evil.” — Donald Knuth (1974). 이 말은 “측정 없이 맹목적으로 최적화하지 말라"는 뜻으로 쓰이지만, Low-latency 시스템에서는 어떤 추상화가 얼마나 비용을 부르는지 수치로 알고, 필요할 때 대체할 수 있는 능력이 전제됩니다. 이 트랙은 그 “알고 줄이는” 단계를 언어·라이브러리 수준에서 체계화합니다.

µs 단위에서는 작은 추상화·할당·복사 비용이 누적되어 핫패스를 지배하므로, 언어 레벨 비용을 수치로 확인하고 제거하는 능력이 핵심입니다. 프로파일러로 “무엇이 느린가"를 본 뒤, 이 트랙에서 다루는 항목(가상 호출, STL, 문자열, 수명·임시, 예외 등)을 하나씩 격리 측정하고 대체하는 흐름을 익히게 됩니다.

여기서 µs(마이크로초, 10⁻⁶초)는 네트워크·금융·게임 등 end-to-end 지연 예산을 잡을 때 자주 쓰는 단위이고, 핫패스는 프로파일러에서 실행 시간·샘플의 상당 부분을 차지하는 코드 경로를 가리킵니다. 언어 레벨 비용은 C++ 문법·표준 라이브러리 선택(가상 호출, 컨테이너·문자열, 복사/이동, 예외 등)에서 발생하는 CPU·메모리 오버헤드로, 컴파일러 플래그·CPU 캐시·OS·락 같은 다른 요인과 구분합니다.

아래 책임 범위 목록은 같은 주제를 “여기서 다룬다”는 관점에서만 묶은 것입니다. 목록만 훑어도 요지가 전달되도록, 한 문장으로 먼저 짚으면 다음과 같습니다. 이 트랙은 호출 규약·컨테이너·문자열·객체 수명·임시·템플릿·코루틴·에러 표현·뷰·람다·SBO·전달 방식처럼, 소스 한 줄·타입 한 개를 바꿨을 때 비용이 어떻게 달라지는지 언어·표준 라이브러리 선택으로 설명할 수 있는 영역에 집중합니다. 불릿은 그 범위를 세부 항목으로 쪼갠 보조 표입니다.

참고 자료

• SI/시간 단위: Microsecond — µs(10⁻⁶초) 정의와 다른 시간 단위와의 관계.
• 핫패스 개념: Hot spot (computer programming) — 프로파일러에서 지배적인 코드 경로.
• 마이크로벤치마크: google/benchmark, nanobench — 격리 측정용 프레임워크.
• CPU 프로파일링: gperftools, perf wiki — 핫패스 식별 도구·개요.
• 트랙 내부: C++ 실행 모델·µs 최적화 어휘 (챕터 01), 추상화 비용 분석 (챕터 03).

이 트랙이 책임지는 범위

• 언어 추상화 비용(가상화, RTTI, 예외, 캡슐화 경계)
• STL/표준 라이브러리 사용 비용(컨테이너, 알고리즘, string)
• 객체 수명/복사/이동 비용, 임시 객체 제거
• 메모리 할당/해제 비용과 회피(가능한 범위)
• 템플릿/constexpr 기반의 비용 제어와 인라이닝 유도(언어 관점)

이 트랙이 다루지 않는 것은 프로파일상 “느리다”는 증상이 비슷해 보여도, 원인 분석과 처방이 CPU 마이크로아키텍처·OS·동시성 설계로 귀결되는 주제입니다. 즉 “C++ 문법·라이브러리만으로 끝나지 않는다”는 뜻이지, 그 주제가 덜 중요하다는 뜻은 아닙니다. 아래 불릿은 각각 어느 트랙에서 이어지는지 가리키는 경계 표지 역할을 합니다.

이 트랙이 다루지 않는 것 (경계)

• CPU 파이프라인/분기 예측/캐시 미스 “원인"의 하드 분석 (→ CPU 트랙)
• OS 스케줄링, CPU pinning, syscall 비용 (→ OS/런타임 트랙)
• 락 경합/메모리 모델/false sharing 같은 동시성 구조 (→ 동시성 트랙)

커리큘럼

난이도 범례: 기초(입문) · 중급(실무 핵심) · 심화(깊은 분석·전문 주제) · 전문(극한·니치).

트랙 약어 Tr.NN: 본문에서 Tr.05처럼 표기하는 것은 이 Low-latency 최적화 시리즈의 다른 트랙을 가리키는 약어입니다(NN = 트랙 번호). 예컨대 **Tr.05는 프로파일링·성능 분석 트랙**이고, **Tr.02는 컴파일러·빌드 최적화 트랙**입니다. 이 글(C++ 언어 최적화)이 Tr.01이며, 범위 밖 주제를 가리킬 때 “→ Tr.NN"으로 어느 트랙에서 이어지는지 표시합니다. 트랙 이름을 누르면 각 트랙의 도입 장으로 이동합니다.

각 트랙의 전체 목록·권장 순서·심화 진입 조건은 맨 아래 **Low-latency 최적화 시리즈 개요**에서 확인할 수 있습니다.

이 트랙은 번호 순서대로(01 → 19) 읽으면 됩니다. 먼저 0102장에서 실행 모델·소유권 비용의 공통 어휘를 맞추고, 0317장에서 추상화·STL·문자열·수명·임시·템플릿·코루틴·예외·뷰·람다·SBO·전달 방식의 비용을 실전 패턴으로 확장한 뒤, 18장(ABI·링크, 전문)과 19장(type erasure, 심화)에서 경계·소거까지 정리하고 트랙을 닫습니다. 01·02장은 본편 곳곳에서 쓰는 용어(실행 모델·핫패스·소유권 비용)를 한곳에 모아 둔 기초 정리 장이라 맨 앞에 두었고, 각 본편 챕터는 필요한 용어를 본문에서 그때그때 짚으므로 어느 장부터 펼쳐도 막히지 않습니다. 챕터끼리 연결되는 부분은 이미 읽은 앞 장을 되짚는 형태로 두고, 뒤 장을 가리킬 때는 “먼저 읽으라"가 아니라 “뒤에서 더 다룬다"는 안내로만 적었습니다.

Tr.01과 Tr.03의 경계도 먼저 잡아 두면 좋습니다. Tr.01은 언어·표준 라이브러리 사용 방식 자체의 비용을 다루고, Tr.03은 그 이후에도 남는 할당 정책·수명 그룹화·데이터 레이아웃 문제를 다룹니다.

각 챕터는 정의·원칙·예시(코드 또는 다이어그램)·비교·마무리(요약·평가 기준·판단 기준·비판적 시각) 순서로 구성되어 있으며, 필요 시 역사/배경 절과 인용(blockquote + 출처)을 포함합니다. 게시 전에는 educational-content-writing 스킬(.cursor/skills/educational-content-writing/SKILL.md)의 품질 체크리스트로 본문 구성·전문가 양성 요소·길이·깊이·시각 요소를 점검합니다.

측정과 검증 (이 트랙 기준)

• 마이크로벤치마크로 “추상화 1개"의 비용을 분리 측정
• 컴파일 결과(인라이닝/코드 크기)와 런타임 수치를 함께 확인
• 변경 전/후 회귀 검증(최소한의 자동화 포함)

왜 언어 레벨부터인가: CPU 캐시 미스나 분기 예측 실패는 프로파일러에서 “어디서” 발생하는지 보여 주지만, 그 원인이 “가상 호출 때문인지”, “컨테이너 접근 패턴 때문인지”, “불필요한 복사 때문인지"는 코드와 격리 측정으로 나눠야 합니다. 이 트랙은 그 격리와 대체를 언어·라이브러리 수준에서 체계적으로 다룹니다.

측정 도구와 사용 예

Google Benchmark와 nanobench는 반복 횟수·안정화 루프를 자동으로 조절해 “한 가지 연산"의 평균/중앙값 나노초(또는 사이클)를 보고합니다. nanobench는 헤더 온리로 도입이 쉽고, Google Benchmark는 CMake 연동과 CSV/콘솔 리포트가 풍부합니다. 예를 들어 가상 함수 한 번 호출 vs 직접 호출을 동일한 로직으로 벤치마크에 올려 두면, 두 연산의 차이가 추상화 오버헤드로 해석됩니다. 벤치마크 코드는 변경 전/후로 나누어 두고 CI 또는 로컬에서 회귀 검증에 사용할 수 있습니다.

아래는 “추상화 1개"를 격리 측정하는 최소 Google Benchmark 예제입니다. 핵심은 컴파일러가 결과를 버리지 못하도록 benchmark::DoNotOptimize로 묶고, 비교 대상(여기서는 직접 호출 합산) 외의 로직을 동일하게 두는 것입니다. 빌드는 Release 수준 플래그(-O2/-O3, 필요 시 -flto)로 합니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

#include <benchmark/benchmark.h>

static int add(int a, int b) { return a + b; }

static void BM_DirectCall(benchmark::State& state) {
  int x = 0;
  for (auto _ : state) {
    x = add(x, 1);
    benchmark::DoNotOptimize(x);  // 결과 폐기 방지
  }
}
BENCHMARK(BM_DirectCall);

BENCHMARK_MAIN();

g++ -O2 bench.cpp -lbenchmark -lpthread로 빌드해 실행하면 BM_DirectCall 0.3 ns ... 형태로 연산당 시간이 보고됩니다(수치는 CPU·플래그에 따라 다름). 같은 틀에서 직접 호출을 가상 호출로 바꾼 BM_VirtualCall을 추가하면, 두 행의 ns 차이가 곧 “가상 호출 한 번"의 추상화 비용입니다. 챕터 03에서 이 비교를 구체화합니다.

컴파일러 진단으로는 GCC/Clang의 -fopt-info-inline, -fopt-info-vec 등으로 어떤 함수가 인라인되었는지, 벡터화되었는지 확인할 수 있습니다. -S 옵션으로 어셈블리 출력을 보면 실제로 call *reg(간접 호출)인지 call _ZNK7...(직접 호출)인지 구분할 수 있어, devirtualization·인라이닝 적용 여부를 검증할 때 유용합니다. 메모리 프로파일러(예: Valgrind massif, sanitizer, 플랫폼별 할당 훅)로 할당 횟수·크기를 보면 “추상화 1개"가 할당을 유발하는지 정량적으로 확인할 수 있습니다.

실무에서는 먼저 프로파일러로 병목을 찾고, 해당 구간에 어떤 추상화(가상 호출, map 접근, string 할당 등)가 있는지 코드로 확인한 뒤, 위 도구로 격리 측정합니다. 벤치마크는 CI에 넣어 회귀를 방지하는 것이 좋고, 각 챕터에서 제시하는 “추상화 1개” 단위 벤치마크 패턴을 그대로 재사용할 수 있습니다.

벤치마크 작성 시 유의사항

• 격리: 한 번에 하나의 요인만 바꾼다. 가상 vs 직접 호출을 비교할 때는 나머지 로직이 동일해야 한다.
• 안정화: 초기 몇 회는 캐시 워밍·JIT 등으로 편차가 크므로, 도구가 제안하는 반복 횟수·워밍 루프를 사용한다.
• 환경: CPU 주파수 고정(터보 끄기), 다른 프로세스 최소화, 동일 머신에서 변경 전/후를 비교한다.
• 해석: 나노초 차이가 “통계적으로 유의한지” 표준편차·신뢰구간을 보고 판단한다. 한 번의 측정으로 결론 내리지 않는다.

자주 하는 실수와 팁

• 실수: 프로파일러에서 보인 “가상 호출"을 전부 제거하려 드는 것. 먼저 격리 측정으로 “한 번당 비용"을 확인하고, 핫패스에서 호출 횟수와 곱한 값이 전체 시간의 일부 이상일 때만 대체 설계를 검토한다.
• 팁: 컴파일러·LTO 옵션을 바꾸면 devirtualization이 갑자기 적용될 수 있다. Release 빌드와 동일한 옵션으로 벤치마크를 돌린다.
• 팁: 문자열·컨테이너 벤치마크는 할당자 훅으로 “할당 횟수"를 함께 보면, 단순 시간보다 원인 파악에 도움이 된다.

학습 목표 (이 트랙 수강 후 달성할 수 있는 것)

이 트랙을 마친 후 독자는 다음을 할 수 있도록 구성되어 있습니다.

• 설명: 가상 함수·RTTI·예외·STL 컨테이너·문자열·객체 수명·임시·템플릿/constexpr·코루틴·variant/optional/expected·span·람다·SBO·파라미터 전달·실행 모델 어휘·ABI/링크 경계·스마트 포인터·type erasure가 성능에 미치는 영향을 구체적으로 설명할 수 있다.
• 구분: “언어/추상화 비용"과 “CPU·OS·동시성 트랙에서 다루는 비용"의 경계를 구분하고, 이 트랙 범위 내에서 해결할 수 있는지 판단할 수 있다.
• 선택: 접근·삽입·순회 패턴과 N 크기에 따라 vector/map/unordered_map·flat 구조 등을 선택할 수 있다. string vs string_view, 예외 vs 에러 코드/expected 등 상황별 선택 기준을 적용할 수 있다.
• 측정: 마이크로벤치마크로 “추상화 1개” 단위 비용을 분리 측정하고, 컴파일 결과(인라이닝·어셈블리)와 런타임 수치를 함께 해석할 수 있다.
• 리팩토링: 핫패스에서 가상 호출 제거·devirtualization 유도, 임시 제거, reserve/이동·noexcept 보강 등 구체적인 리팩토링을 수행할 수 있다.

핵심 메시지 요약

추천 선행/병행 트랙

• 선행: Low-latency Profiling & Performance Analysis (Tr.05) — 프로파일러로 핫패스와 병목 지점을 찾는 방법을 먼저 익히면, 이 트랙에서 “어떤 항목을 격리 측정할지” 결정하기 쉽습니다.
• 병행: Compiler & Build Optimization (Tr.02), Memory & Allocation (Tr.03), Concurrency (Tr.04) — 인라이닝 실패·LTO·PGO는 Tr.02에서, 할당 패턴·풀 할당자는 Tr.03에서, 락·메모리 모델은 Tr.04에서 다룹니다. 언어 레벨에서 제거할 수 있는 비용을 먼저 줄인 뒤, 컴파일·메모리·동시성 요인을 다루는 순서가 효율적입니다.

선행 트랙을 읽지 않았더라도, “프로파일러로 병목을 본 뒤 의심되는 추상화를 격리 측정한다"는 루프만 이해하면 이 트랙을 따라갈 수 있습니다. 병행 트랙은 챕터 12(인라이닝)·컨테이너·할당·동시성 관련 주제를 깊이 다룰 때 함께 참고하면 좋습니다.

트랙 읽기 순서 요약: 01~02장(실행 모델·스마트 포인터)으로 공통 어휘를 맞춘 뒤, 03(추상화) → 04(STL) → 05(문자열) → 06(객체 수명) → 07(임시) 순서로 “비용의 종류"를 체계적으로 배웁니다. 08(템플릿/constexpr)부터는 컴파일 타임·최적화 유도로 넘어가고, 10(코루틴)·11(예외)·13(variant/optional/expected)은 비동기·에러 처리 설계와 맞닿아 있습니다. 12(인라이닝)·14(span)·15(람다)·16(SBO)·17(파라미터 전달)은 API 설계와 호출 비용을 다루므로, 프로파일러로 호출·할당이 보일 때 해당 챕터를 참고하면 됩니다. 마지막 18(ABI·링크)·19(type erasure)는 경계·소거로 범위를 넓히고 트랙을 닫습니다. 번호 순서가 곧 권장 학습 순서입니다.

평가 기준과 이 장을 읽은 후 확인

• 이 트랙이 다루는 범위와 다루지 않는 범위(언어·라이브러리 vs CPU·OS·동시성)를 구분해 설명할 수 있는가?
• “프로파일 → 격리 측정 → 대안 적용 → 회귀 검증” 흐름을 자신의 말로 설명할 수 있는가?
• 01~02장(실행 모델·스마트 포인터)을 기초 정리 장으로 맨 앞에 둔 이유를 한두 문장으로 설명할 수 있는가?
• Google Benchmark·nanobench, -fopt-info-inline, -S, 메모리 프로파일러의 역할을 구분할 수 있는가?

용어 정리 (이 장에서 사용한 표현)

• 핫패스: 도입에서 정의한 바와 같이, 프로파일러 상 지배적인 코드 경로. 최적화는 보통 핫패스부터 대상으로 한다.
• 언어 레벨 비용: C++ 문법·표준 라이브러리 선택에서 발생하는 CPU·메모리 오버헤드. CPU·OS·동시성 병목과 구분한다.
• 격리 측정: 다른 요인을 고정한 채 “한 가지 추상화(예: 가상 호출 한 번)“만의 비용을 벤치마크로 측정하는 것.
• 회귀 검증: 코드 변경 후 기존 벤치마크를 다시 돌려, 의도한 개선이 나왔는지·다른 부분이 나빠지지 않았는지 확인하는 것.
• devirtualization: 컴파일러가 가상 호출을 직접 호출(또는 인라인)로 바꾸는 최적화. final, LTO 등으로 유도할 수 있다.

이 트랙의 활용 흐름

실제 프로젝트에서는 먼저 프로파일러로 핫패스를 찾고, 그 경로에서 본 트랙의 항목이 얼마나 기여하는지 격리한 뒤, 대안을 적용하고 회귀 검증합니다. 아래 흐름도를 참고하세요.

flowchart LR
  A["1단계
프로파일러로
핫패스 식별"] --> B["2단계
의심 추상화
격리 측정"]
  B --> C["3단계
대안 설계·
코드 변경"] --> D["4단계
마이크로벤치마크·
회귀 검증"]
  D -->|회귀 시| B

예를 들어 가상 호출이 많이 나오면 챕터 03(추상화 비용)의 벤치마크로 “가상 한 번” 비용을 측정한 뒤, final·LTO·대체 설계로 제거 가능한지 검토합니다. STL 접근·문자열 할당·반환값 복사 등도 같은 방식으로 “한 가지 요인"만 바꾼 마이크로벤치마크를 두고, 변경 전/후 회귀 검증을 하면 됩니다.

구체적 예: 프로파일러에서 std::map::operator[] 접근이 핫패스에 많이 등장한다면, 챕터 04의 비용 모델을 참고해 “동일 키로 N번 접근” 벤치마크를 만들어 vector+정렬·unordered_map·flat_map과 비교합니다. 개선안 적용 후 동일 벤치마크로 회귀가 없는지 확인하고, 필요하면 Tr.02(LTO·인라이닝)와 함께 검증합니다. 컴파일러·빌드(Tr.02), 메모리·할당(Tr.03), 동시성(Tr.04) 트랙과 병행하면, 언어 레벨에서 제거할 수 있는 비용을 먼저 줄인 뒤 나머지 요인을 다루는 순서가 효율적입니다.

비판적 시각

“언어 레벨 최적화"만으로 해결되지 않는 병목도 많습니다. 캐시 미스·분기 예측 실패·시스템 콜·락 경합 등은 이 트랙 범위 밖이므로, 프로파일러 결과를 보고 먼저 “원인이 언어·추상화인지” 판단한 뒤 이 트랙의 챕터를 고르는 편이 효율적입니다. 모든 코드를 낮은 추상화로 바꾸는 것은 유지보수 비용을 올리므로, 핫패스에 한정해 적용하는 것이 좋습니다.

다음 장에서는

첫 장은 본편 어휘를 맞추는 C++ 실행 모델·µs 최적화 어휘입니다. 프로세스 메모리·스택/힙·캐시·핫패스·추상화 비용 같은 용어를 한 그림으로 정리해, 이후 챕터의 벤치마크 숫자를 같은 언어로 읽을 수 있게 합니다. 가상 함수·RTTI·예외의 정량적 비용은 챕터 03(추상화 비용 분석)부터 본격적으로 다룹니다.

→ C++ 실행 모델·µs 최적화 어휘 (챕터 01)

시리즈 전체 로드맵

12개 트랙의 권장 순서·심화 진입 조건은 **Low-latency 최적화 시리즈 개요**에서 정리합니다.