임베디드 C++ vs C — 런타임·코드 크기·ABI 관점 비교

#한 줄 요약

“Modern C++는 추상화 비용을 거의 0으로 만든다.” 단, 그 zero가 성립하는 전제 조건들을 알아야 합니다.

#어떤 문제를 푸는가

새 임베디드 프로젝트의 언어를 정할 때 가장 먼저 부딪히는 질문입니다. “C로 갈까 C++로 갈까.”

C++를 택하면 다음 두려움이 따라옵니다.

• 코드 크기가 폭증할 것 같습니다
• 런타임 비용을 가늠하기 어렵습니다
• 디버깅이 더 까다로워질 것 같습니다
• 인증(MISRA, DO-178C)에서 막힐 것 같습니다

이 두려움 중 일부는 1990년대 C++의 잔영입니다. Modern C++(11/14/17/20)는 측정 가능한 zero-cost abstraction을 약속합니다. 다만 모든 기능이 그렇지는 않습니다. 어느 기능이 무료이고 어느 기능이 유료인지를 정확히 아는 것이 핵심입니다.

#C++가 C에 더하는 것

C++는 C의 superset에 가깝지만 동일하지는 않습니다. C++가 더하는 도구는 크게 네 가지입니다.

핵심: C와 동등한 런타임 비용을 가지는 기능이 대부분입니다. 비용을 가지는 것은 예외, RTTI, iostream, 동적 다형성 정도입니다. 이들을 끄거나 사용하지 않으면 C와 같은 영역에서 출발합니다.

한눈에 보면 다음과 같이 정리됩니다.

#측정 — 단순 함수의 어셈블리

말로는 부족합니다. 어셈블리를 직접 봅니다.

같은 일을 하는 두 코드를 비교합니다. ARM Cortex-M4, -O2, GCC 13 환경입니다.

1
// C 버전
2
int add_one(int x) {
3
    return x + 1;
4
}

1
// C++ 버전
2
struct Counter {
3
    int value;
4
    Counter(int v) : value(v) {}
5
    int add_one() const { return value + 1; }
6
};
7

8
int caller(int x) {
9
    Counter c(x);
10
    return c.add_one();
11
}

어셈블리 결과:

1
# C: add_one(int)
2
add_one:
3
    adds    r0, r0, #1
4
    bx      lr
5

6
# C++: caller(int)
7
caller(int):
8
    adds    r0, r0, #1
9
    bx      lr

완전히 동일합니다. C++의 생성자 호출과 멤버 함수 호출이 컴파일러에 의해 사라졌습니다. 이것이 zero-cost abstraction의 가장 단순한 예입니다.

#측정 — Blink LED 비교

조금 더 현실적인 예를 봅니다. STM32 보드의 GPIO blink입니다.

1
// C 버전
2
#define GPIOA_BSRR (*(volatile uint32_t*)0x40020018)
3

4
void blink_on(void)  { GPIOA_BSRR = 1 << 5; }
5
void blink_off(void) { GPIOA_BSRR = 1 << 21; }

1
// C++ 버전 (RAII + 템플릿)
2
template<uint32_t Address, uint8_t Pin>
3
struct Gpio {
4
    static void on()  { *reinterpret_cast<volatile uint32_t*>(Address + 0x18) = 1u << Pin; }
5
    static void off() { *reinterpret_cast<volatile uint32_t*>(Address + 0x18) = 1u << (Pin + 16); }
6
};
7

8
using Led = Gpio<0x40020000, 5>;
9

10
void blink_on()  { Led::on(); }
11
void blink_off() { Led::off(); }

-O2 어셈블리:

1
# C: blink_on
2
blink_on:
3
    ldr     r3, =0x40020018
4
    movs    r2, #32
5
    str     r2, [r3]
6
    bx      lr
7

8
# C++: blink_on
9
blink_on:
10
    ldr     r3, =0x40020018
11
    movs    r2, #32
12
    str     r2, [r3]
13
    bx      lr

역시 동일합니다. C++의 템플릿은 컴파일 타임 추상화입니다. Address와 Pin이 상수로 박혀 어셈블리에서는 C 매크로와 같은 결과가 나옵니다.

장점은 타입 안전성입니다. Gpio<0x40020000, 5>와 Gpio<0x40020400, 12>는 다른 타입이라 서로 섞어 쓸 수 없습니다. C의 매크로로는 불가능한 보호입니다.

#비용이 진짜로 발생하는 영역

zero-cost가 아닌 영역도 있습니다. 이것들을 알고 끄는 것이 임베디드 C++의 절반입니다.

#1. 예외 처리

예외는 unwind table과 런타임 핸들러를 함께 데려옵니다.

1
// 예외 사용
2
int divide(int a, int b) {
3
    if (b == 0) throw std::runtime_error("divide by zero");
4
    return a / b;
5
}

이 함수 하나가 3-10KB의 런타임을 요구합니다. 임베디드는 보통 예외 자체를 끕니다.

1
CXXFLAGS += -fno-exceptions

대안으로는 std::optional, std::expected (C++23), error code 반환이 있습니다. 자세한 내용은 Part 3-05: No-Exception 설계에서 다룹니다.

#2. RTTI

dynamic_cast와 typeid는 type info 테이블을 데려옵니다. 보통 수 KB 정도입니다.

1
CXXFLAGS += -fno-rtti

대안으로는 tagged union, std::variant, visitor 패턴(CRTP 기반)이 있습니다.

#3. iostream

std::cout은 50KB 이상의 코드를 데려옵니다. 임베디드에서는 printf보다 무겁습니다.

대안으로는 printf(C 라이브러리), fmt(header-only, 작음), 직접 UART 출력 등이 있습니다.

#4. 가상 함수

vtable 간접 호출이 1회 발생합니다. 무료는 아니지만 대부분 무시할 수 있습니다. 인라인되지 않는다는 점이 단점입니다.

대안은 CRTP(static polymorphism, Part 2-08)입니다.

#5. std::function

내부적으로 heap 할당과 type erasure를 사용합니다. 임베디드에서는 함수 포인터나 FixedFunction(etl::delegate)을 씁니다.

#코드 크기 비교 — 실측

같은 기능을 C와 C++로 작성했을 때의 실제 크기 비교입니다. STM32F4, -Os -flto -fno-exceptions -fno-rtti 환경입니다.

적절히 끄면 C++가 C와 같거나 수 바이트 차이입니다. 기본을 모르고 쓰면 수십 KB의 bloat가 한 번에 들어옵니다.

#자주 보는 함정과 안티패턴

#1. -fno-exceptions 없이 시작

GCC 기본값은 예외 활성입니다. 임베디드 프로젝트는 처음부터 -fno-exceptions를 켜야 합니다. 늦게 끄면 기존 코드가 깨집니다.

#2. std::vector를 무심코 사용

vector는 heap 할당을 합니다. 자유 메모리가 없는 환경에서는 런타임 실패로 이어집니다. std::array, etl::vector(고정 크기)로 대체합니다.

#3. virtual을 모든 곳에 적용

“OOP니까 virtual”은 아닙니다. 진짜 런타임 다형성이 필요한 곳에만 씁니다. 그 외에는 CRTP를 씁니다.

#4. iostream 사용 후 크기 폭증에 놀람

<< 한 번에 50KB가 따라옵니다. printf 또는 fmt를 씁니다.

#5. std::shared_ptr로 모든 소유권 표현

shared_ptr은 atomic 카운터와 heap을 함께 끌고 옵니다. 임베디드는 unique_ptr이 기본이며 raw pointer와 명확한 소유자 지정도 괜찮습니다.

#6. C++ 표준 라이브러리 전부 사용 가능하다고 가정

<filesystem>, <thread>, <chrono>의 일부는 OS 의존입니다. bare-metal에서는 링크 실패로 이어집니다. ETL, EASTL 같은 임베디드 친화 라이브러리를 검토합니다.

#Modern C++가 가져온 변화

C++11 이전과 이후는 거의 다른 언어에 가깝습니다.

이 중 대부분이 zero-cost입니다. 템플릿 기반 + 컴파일 타임 기능들이 핵심입니다.

#C가 여전히 옳은 자리

C++가 만능은 아닙니다. C가 더 적합한 경우는 다음과 같습니다.

• 부트 코드 / 인터럽트 벡터 테이블: 매우 초기 단계라 C++ 런타임이 초기화되지 않았습니다
• 극소형 MCU: ATtiny 같은 4KB 미만 Flash 환경에서는 C++ 런타임 자체가 부담입니다
• 인증 제약: DO-178C Level A 같은 환경에서는 C++ 도구 인증 비용이 큽니다
• legacy 코드: 수십만 줄의 C 코드베이스에 C++ 일부만 섞으면 복잡성이 커집니다
• 팀 역량: C++ 숙련도가 낮은 팀에서는 느린 도입이 빠른 도입보다 안전합니다

특히 부트 코드는 거의 항상 C 또는 어셈블리입니다. __libc_init_array가 호출되기 전에는 static 생성자가 돌지 않았기 때문에 C++ 객체를 생성할 수 없습니다. 자세한 내용은 Part 1-06: 스타트업 코드에서 다룹니다.

#C와 C++의 공존 전략

대부분의 임베디드 프로젝트는 C와 C++가 섞여 있습니다.

• HAL/드라이버: C(벤더 제공, 검증된 코드)
• 부트/스타트업: C 또는 어셈블리
• 애플리케이션 로직: C++(RAII, 타입 안전, 추상화 활용)
• 외부 라이브러리 wrapper: C++(C API를 RAII로 감쌉니다)

C/C++ 혼합 시에는 name mangling과 ABI가 문제가 됩니다. extern "C" 블록과 헤더 분리 패턴이 표준 해법입니다. 자세한 내용은 Part 1-05: ABI 호환성에서 다룹니다.

#핵심 질문 — 언어가 아닌 사용법

C와 C++의 선택은 언어 자체의 우열 문제가 아닙니다. 어떤 기능을 어떻게 쓰는지가 결정합니다.

C++를 안전하게 쓰려면 시리즈 전체를 관통하는 네 질문을 각 결정마다 던집니다.

1. 이 기능이 런타임 비용을 추가하는가? 어셈블리로 확인합니다
2. 이 기능이 디버깅을 더 쉽게 만드는가? 타입 안전과 명확한 의도가 핵심입니다
3. 이 기능이 코드 품질을 끌어올리는가? RAII, const, constexpr이 그 예입니다
4. 바이너리 크기가 감당 가능한가? 측정과 -Os -flto로 확인합니다

C++의 강점인 추상화가 부담 없이 가능한지를 프로젝트마다 평가합니다.

#정리

• Modern C++의 대부분은 zero-cost abstraction이며 어셈블리는 C와 동일하게 나옵니다.
• 비용이 발생하는 영역은 예외, RTTI, iostream, 동적 할당, std::function이며 알고 끄거나 대체합니다.
• C는 부트 코드, 극소형 MCU, 인증 환경에서 여전히 적합합니다.
• 결정은 언어 선택이 아니라 사용법 선택입니다. 위 네 가지 핵심 질문으로 매 결정을 평가합니다.

#관련 항목

• Part 1-02: 컴파일러 플래그 가이드 — -fno-exceptions, -fno-rtti, -Os 설정
• Part 1-04: 코드 크기 분석 — bloat 측정과 통제
• Part 2-08: Static Polymorphism — virtual 없이 다형성
• Part 3-05: No-Exception 설계 — 예외 없이 에러 처리
• GoF 5: Singleton (avoid) — 임베디드의 DI 대안

#다음 글

Part 1-02: 컴파일러 플래그 가이드 — C++를 임베디드 모드로 만드는 정확한 플래그 조합과 그것이 어셈블리에 미치는 영향을 다룹니다.