Embedded C++ for Real Systems · 9/41

임베디드 RAII 기초 — 리소스 안전성과 결정적 소멸 보장

2026년 4월 29일 · Hawk · 6분 읽기

cpp embedded raii resource destructor exception-safety

#한 줄 요약

“자원 = 객체, 해제 = 소멸자.” — 함수가 어떻게 끝나든 소멸자가 반드시 호출됨을 언어가 보장합니다.

#어떤 문제를 푸는가

자원(메모리, 파일, mutex, peripheral)을 획득한 뒤 해제하지 않으면 누수가 발생합니다. C에서는 호출자가 직접 짝을 맞춰 줘야 합니다.

1
// C: 짝 맞추기 어려움
2
void process() {
3
    char* buf = malloc(1024);
4
    FILE* f = fopen("data.bin", "rb");
5

6
    if (read_data(buf, f) < 0) {
7
        fclose(f);
8
        free(buf);     // 두 번 적어야
9
        return;
10
    }
11

12
    if (validate(buf) < 0) {
13
        fclose(f);
14
        free(buf);     // 또 두 번
15
        return;
16
    }
17

18
    fclose(f);
19
    free(buf);         // 또
20
}

경로마다 정리 코드를 반복해야 하고, 새 경로를 추가할 때 빠뜨리기 쉽습니다. 예외가 도는 환경에서는 거의 불가능에 가깝습니다.

RAII (Resource Acquisition Is Initialization)는 이 문제를 언어 차원에서 해결합니다.

1
// C++: 짝 자동
2
void process() {
3
    std::array<char, 1024> buf;       // stack 자동 해제
4
    std::ifstream f("data.bin", std::ios::binary);   // 소멸자가 close
5

6
    if (read_data(buf.data(), f) < 0) return;
7
    if (validate(buf.data()) < 0) return;
8
}

return이 어디서 일어나든 소멸자가 반드시 호출되므로 자원 누수가 원천적으로 불가능합니다.

#RAII의 정의

자원을 객체 생명주기에 묶는 idiom입니다.

생성자가 자원을 획득합니다 (메모리 할당, mutex lock, peripheral enable).
소멸자가 자원을 해제합니다 (메모리 free, unlock, disable).
객체의 scope가 곧 자원의 lifetime이 됩니다.

C++ 표준이 다음 시점에 소멸자 호출을 보장합니다.

함수가 return하면 모든 local 객체의 소멸자가 호출됩니다.
함수에서 예외가 throw되면 stack unwinding이 모든 소멸자를 호출합니다.
객체가 delete되면 소멸자가 호출됩니다.
프로그램 종료 시 static 객체의 소멸자가 호출됩니다(임베디드에서는 보통 호출되지 않습니다).

#임베디드의 RAII — 5가지 자원

임베디드 RAII가 다루는 주요 자원은 다음 다섯입니다.

Mutex / Lock — RTOS sync primitive
Peripheral — GPIO, UART, SPI 활성/비활성
Interrupt — critical section
Memory — pool 할당 / 반환
DMA — channel 획득 / 해제

각각의 RAII 패턴을 차례로 살펴봅니다.

#RAII 패턴 1 — Mutex Lock

가장 흔한 RAII 예입니다. unlock을 빠뜨리는 사고를 막아 줍니다.

1
// 위험 — 수동 lock/unlock
2
void shared_function() {
3
    osMutexAcquire(my_mutex, osWaitForever);
4

5
    if (some_condition()) return;   // unlock 누락!
6

7
    do_work();
8

9
    osMutexRelease(my_mutex);
10
}
11

12
// RAII — 자동 unlock
13
class MutexLock {
14
public:
15
    explicit MutexLock(osMutexId_t m) : mutex_(m) {
16
        osMutexAcquire(mutex_, osWaitForever);
17
    }
18
    ~MutexLock() {
19
        osMutexRelease(mutex_);
20
    }
21

22
    // 복사 금지 — 자원의 소유권 unique
23
    MutexLock(const MutexLock&) = delete;
24
    MutexLock& operator=(const MutexLock&) = delete;
25

26
private:
27
    osMutexId_t mutex_;
28
};
29

30
// 사용
31
void shared_function() {
32
    MutexLock lock(my_mutex);   // 획득
33

34
    if (some_condition()) return;   // 자동 unlock
35
    do_work();
36
    // 자동 unlock
37
}

핵심은 다음과 같습니다.

생성자에서 osMutexAcquire를 호출합니다.
소멸자에서 osMutexRelease를 호출합니다.
복사를 금지해 자원은 한 객체만 소유하도록 합니다.

C++17의 std::scoped_lock이 표준 라이브러리에서 제공하는 같은 패턴입니다. 자세한 내용은 Part 2-02에서 다룹니다.

#RAII 패턴 2 — Peripheral

UART, SPI 같은 peripheral 활성화도 RAII로 묶을 수 있습니다.

1
class UartGuard {
2
public:
3
    UartGuard() {
4
        RCC->APB1ENR |= RCC_APB1ENR_USART2EN;   // clock 활성
5
        USART2->CR1 |= USART_CR1_UE;            // peripheral 활성
6
    }
7
    ~UartGuard() {
8
        USART2->CR1 &= ~USART_CR1_UE;           // 비활성
9
        RCC->APB1ENR &= ~RCC_APB1ENR_USART2EN;  // clock 끔 (power saving)
10
    }
11
};
12

13
void log_data() {
14
    UartGuard uart;   // UART on
15
    USART2->DR = 'A';
16
    while (!(USART2->SR & USART_SR_TC));
17
    USART2->DR = 'B';
18
    while (!(USART2->SR & USART_SR_TC));
19
    // 자동 UART off — power saving
20
}

함수가 끝나면 UART가 자동으로 꺼지므로 전력 관리가 함께 처리됩니다.

#RAII 패턴 3 — Critical Section (Interrupt Disable)

ISR과 데이터를 공유할 때는 짧은 critical section이 필요합니다.

1
// Bad — disable/enable 짝 맞춰야
2
void shared() {
3
    __disable_irq();
4
    counter++;
5
    if (counter > MAX) {
6
        __enable_irq();   // 까먹기 쉬움
7
        return;
8
    }
9
    __enable_irq();
10
}
11

12
// RAII
13
class InterruptGuard {
14
    uint32_t prev_;
15
public:
16
    InterruptGuard() {
17
        prev_ = __get_PRIMASK();
18
        __disable_irq();
19
    }
20
    ~InterruptGuard() {
21
        if (!prev_) __enable_irq();   // 진입 시 disabled였으면 그대로
22
    }
23

24
    InterruptGuard(const InterruptGuard&) = delete;
25
};
26

27
void shared() {
28
    InterruptGuard guard;   // disable
29
    counter++;
30
    if (counter > MAX) return;   // 자동 enable
31
}

핵심은 이전 상태를 보존하는 데 있습니다. 이미 disabled 상태에서 진입했다면 다시 enable하지 않으므로, nested critical section에서도 안전합니다.

#RAII 패턴 4 — Pool Allocator Handle

custom allocator에서 할당된 블록도 RAII로 감쌀 수 있습니다.

1
class PoolHandle {
2
public:
3
    PoolHandle(Pool* p, void* block) : pool_(p), block_(block) {}
4
    ~PoolHandle() {
5
        if (block_) pool_->free(block_);
6
    }
7

8
    // Move OK (소유권 이전), copy 금지
9
    PoolHandle(PoolHandle&& other) noexcept
10
        : pool_(other.pool_), block_(other.block_) {
11
        other.block_ = nullptr;
12
    }
13
    PoolHandle& operator=(PoolHandle&& other) noexcept {
14
        if (this != &other) {
15
            if (block_) pool_->free(block_);
16
            pool_ = other.pool_;
17
            block_ = other.block_;
18
            other.block_ = nullptr;
19
        }
20
        return *this;
21
    }
22
    PoolHandle(const PoolHandle&) = delete;
23
    PoolHandle& operator=(const PoolHandle&) = delete;
24

25
    void* get() { return block_; }
26

27
private:
28
    Pool* pool_;
29
    void* block_;
30
};

자원이 unique하므로 한 블록은 한 핸들만 가질 수 있고, 이전은 move로만 일어납니다. 자세한 pool 구현은 Part 3-03에서 다룹니다.

#RAII 패턴 5 — DMA Channel

DMA channel은 제한된 자원이므로 획득과 해제를 RAII로 묶습니다.

1
class DmaChannel {
2
public:
3
    explicit DmaChannel(uint8_t ch) : channel_(ch) {
4
        // 채널 활성화
5
        DMA->CCR[channel_] |= DMA_CCR_EN;
6
    }
7
    ~DmaChannel() {
8
        DMA->CCR[channel_] &= ~DMA_CCR_EN;
9
        // 채널 인터럽트 끔
10
        NVIC_DisableIRQ(static_cast<IRQn_Type>(DMA1_Channel1_IRQn + channel_));
11
    }
12

13
    void start_transfer(void* src, void* dst, size_t len) { /* */ }
14
    bool is_done() const { /* */ }
15

16
    DmaChannel(const DmaChannel&) = delete;
17

18
private:
19
    uint8_t channel_;
20
};
21

22
void send_buffer(const uint8_t* data, size_t len) {
23
    DmaChannel ch(1);   // 채널 1 획득
24

25
    ch.start_transfer(const_cast<uint8_t*>(data), &UART->TX, len);
26
    while (!ch.is_done());
27

28
    // 자동 해제
29
}

#RAII의 핵심 — 3 of 5 규칙

C++의 기본 복사/이동 동작은 자원 관리에 부적합합니다. RAII 클래스는 이를 명시적으로 정의해야 합니다.

1
class Resource {
2
public:
3
    Resource();                                 // 기본 생성자
4
    ~Resource();                                // 소멸자 (자원 해제)
5

6
    // *복사 금지* — 자원은 unique
7
    Resource(const Resource&) = delete;
8
    Resource& operator=(const Resource&) = delete;
9

10
    // *이동 허용* — 소유권 이전
11
    Resource(Resource&&) noexcept;
12
    Resource& operator=(Resource&&) noexcept;
13
};

Rule of Three (C++98): 소멸자, 복사 생성자, 복사 대입 중 하나를 정의하면 셋 다 정의합니다.

Rule of Five (C++11): 위 셋에 이동 생성자와 이동 대입을 더해 다섯을 모두 정의합니다.

Rule of Zero: 직접 자원을 관리하지 않고 표준 RAII 클래스(std::unique_ptr 등)에 위임합니다. 가장 권장되는 방식입니다.

#RAII vs `defer` — 다른 언어와의 비교

Go의 defer, Java의 try-with-resources도 비슷한 의도를 가집니다.

1
// Go defer
2
func process() {
3
    f := open("data.bin")
4
    defer f.close()   // 함수 끝에서 호출
5

6
    // ...
7
}

1
// Java try-with-resources
2
try (var f = new FileInputStream("data.bin")) {
3
    // ...
4
}

1
// C++ RAII — 가장 깔끔
2
void process() {
3
    std::ifstream f("data.bin");
4
    // 자동 close — 별도 표시 불필요
5
}

C++ RAII는 추가 키워드가 필요 없습니다. 객체 scope 자체가 자원 lifetime이며, 가장 통합된 접근입니다.

#임베디드 특화 — Move semantics 주의

자원 이전 시 move가 복사보다 효율적입니다. 다만 예외 환경과 임베디드 환경에서 주의할 점이 있습니다.

1
class Buffer {
2
public:
3
    Buffer(size_t n) : data_(new uint8_t[n]), size_(n) {}
4
    ~Buffer() { delete[] data_; }
5

6
    // Move
7
    Buffer(Buffer&& other) noexcept
8
        : data_(other.data_), size_(other.size_) {
9
        other.data_ = nullptr;
10
        other.size_ = 0;
11
    }
12

13
    // Copy 금지
14
    Buffer(const Buffer&) = delete;
15

16
private:
17
    uint8_t* data_;
18
    size_t size_;
19
};
20

21
Buffer create_buffer() {
22
    Buffer b(1024);
23
    return b;   // 복사 X, move (또는 RVO)
24
}

Move 생성자는 noexcept로 표시하는 것이 강력히 권장됩니다. std::vector 등은 noexcept가 없으면 copy로 fallback해 성능이 떨어집니다.

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

#1. 소멸자에서 예외

소멸자에서 예외를 던지면 stack unwinding 중 terminate됩니다. -fno-exceptions 환경에서도 abort로 이어질 수 있으므로, 소멸자는 항상 noexcept여야 합니다.

1
~Resource() noexcept {
2
    release();   // try/catch로 모든 예외 잡기
3
}

#2. Copy 허용

1
class MutexLock {
2
public:
3
    MutexLock(osMutexId_t m) : mutex_(m) { osMutexAcquire(mutex_); }
4
    ~MutexLock() { osMutexRelease(mutex_); }
5
    // copy 정의 안 함 → 컴파일러 자동 생성 → double-release crash
6
};
7

8
void shared() {
9
    MutexLock l(m);
10
    MutexLock l2 = l;   // copy → 둘 다 release → double release
11
}

복사 연산자는 = delete로 명시적으로 막아야 합니다.

#3. 전역 RAII로 long-lived 자원

1
static MutexLock g_lock(some_mutex);   // 영원히 lock

RAII는 지역 객체에 어울립니다. 전역에 쓰면 해제 시점이 프로그램 종료(임베디드에서는 거의 일어나지 않음)가 되어 의도가 모호해집니다.

#4. Constructor에서 실패

1
class Uart {
2
public:
3
    Uart(int baud) {
4
        if (init_uart(baud) < 0) {
5
            // 어떻게 실패 처리?
6
            // 예외 throw → -fno-exceptions에서 불가
7
            // return → 안 됨 (생성자)
8
        }
9
    }
10
};

대안은 factory function이 std::optional<Uart>를 반환하도록 만드는 것입니다.

1
std::optional<Uart> make_uart(int baud) {
2
    if (init_uart(baud) < 0) return std::nullopt;
3
    return Uart(/* private constructor */);
4
}

#5. Move 후 사용

1
Buffer b1(1024);
2
Buffer b2 = std::move(b1);
3
b1.write(...);   // b1은 moved-from 상태 → null 접근

move한 객체는 더 이상 사용하지 않는 것이 관례입니다.

#6. RAII 객체의 scope가 너무 작음

1
{
2
    MutexLock l(m);
3
    counter = 0;
4
}   // 즉시 unlock

scope가 너무 짧으면 필요한 critical section을 모두 덮지 못합니다. 의도가 정말 그것인지 확인합니다.

#측정 — RAII overhead

같은 코드를 C 수동 정리와 C++ RAII로 비교합니다(ARM Cortex-M4, -O2).

1
# C 수동 (mutex acquire/release)
2
shared:
3
    push    {r4, lr}
4
    bl      osMutexAcquire
5
    ldr     r3, [counter]
6
    adds    r3, r3, #1
7
    str     r3, [counter]
8
    bl      osMutexRelease
9
    pop     {r4, pc}
10
# 24 bytes
11

12
# C++ RAII (MutexLock 사용)
13
shared:
14
    push    {r4, lr}
15
    bl      osMutexAcquire
16
    ldr     r3, [counter]
17
    adds    r3, r3, #1
18
    str     r3, [counter]
19
    bl      osMutexRelease
20
    pop     {r4, pc}
21
# 24 bytes — 동일

완전히 동일합니다. 생성자와 소멸자가 인라인되어 오버헤드가 0이며, 전형적인 zero-cost abstraction입니다.

#정리

RAII는 자원 lifetime을 객체 lifetime에 묶어 생성자에서 획득하고 소멸자에서 해제합니다.
임베디드의 5가지 RAII 자원은 Mutex, Peripheral, Interrupt, Memory, DMA입니다.
Rule of Three/Five/Zero로 자원 관리를 명시하며, 복사 금지와 이동 허용을 택하거나 표준 클래스에 위임합니다.
소멸자는 noexcept여야 하며 예외를 던지면 terminate됩니다.
컴파일러가 생성자와 소멸자를 인라인하므로 오버헤드가 0입니다.

#관련 항목

Part 2-02: RAII 실전 패턴 — std::scoped_lock, Handle 패턴, ScopedXxx
Part 3-05: No-Exception 설계 — 예외 없는 환경의 RAII
Part 3-09: 스마트 포인터 선택 — unique_ptr의 RAII
GoF 14: Command — Command + RAII undo

#다음 글

Part 2-02: RAII 실전 패턴 — std::scoped_lock, std::unique_ptr 커스텀 deleter, ScopedXxx 패턴.

Embedded C++ for Real Systems · 10 of 41

임베디드 RAII 실전 패턴 — Lock·Pin·DMA·Power 관리

scoped_lock, unique_ptr with custom deleter, ScopedXxx, Finally — 임베디드에 자주 등장하는 RAII 표준 패턴.

2026년 4월 29일·cpp

Embedded C++ for Real Systems — 임베디드 모던 C++ 시리즈 소개

어디까지 C++를 써도 되는가? RAII, constexpr, no-exception 설계부터 lock-free 패턴까지. 임베디드에서 안전하게 C++를 쓰는 법.

2026년 4월 28일·cpp

임베디드 HAL 설계 패턴 — Static·Dynamic·Hybrid 비교

범용 HAL 구조 — 벤더 종속성 격리, 다중 보드/MCU 지원, 시리즈 마무리.

2026년 5월 2일·cpp

임베디드 RAII 기초 — 리소스 안전성과 결정적 소멸 보장

#한 줄 요약

#어떤 문제를 푸는가

#RAII의 정의

#임베디드의 RAII — 5가지 자원

#RAII 패턴 1 — Mutex Lock

#RAII 패턴 2 — Peripheral

#RAII 패턴 3 — Critical Section (Interrupt Disable)

#RAII 패턴 4 — Pool Allocator Handle

#RAII 패턴 5 — DMA Channel

#RAII의 핵심 — 3 of 5 규칙

#RAII vs `defer` — 다른 언어와의 비교

#임베디드 특화 — Move semantics 주의

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

#1. 소멸자에서 예외

#2. Copy 허용

#3. 전역 RAII로 long-lived 자원

#4. Constructor에서 실패

#5. Move 후 사용

#6. RAII 객체의 scope가 너무 작음

#측정 — RAII overhead

#정리

#관련 항목

#다음 글

Embedded C++ for Real Systems · 10 of 41

관련 글

임베디드 RAII 실전 패턴 — Lock·Pin·DMA·Power 관리

Embedded C++ for Real Systems — 임베디드 모던 C++ 시리즈 소개

임베디드 HAL 설계 패턴 — Static·Dynamic·Hybrid 비교

이 글을 참조하는 글 (8)

#한 줄 요약

#어떤 문제를 푸는가

#RAII의 정의

#임베디드의 RAII — 5가지 자원

#RAII 패턴 1 — Mutex Lock

#RAII 패턴 2 — Peripheral

#RAII 패턴 3 — Critical Section (Interrupt Disable)

#RAII 패턴 4 — Pool Allocator Handle

#RAII 패턴 5 — DMA Channel

#RAII의 핵심 — 3 of 5 규칙

#RAII vs defer — 다른 언어와의 비교

#임베디드 특화 — Move semantics 주의

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

#1. 소멸자에서 예외

#2. Copy 허용

#3. 전역 RAII로 long-lived 자원

#4. Constructor에서 실패

#5. Move 후 사용

#6. RAII 객체의 scope가 너무 작음

#측정 — RAII overhead

#정리

#관련 항목

#다음 글

Embedded C++ for Real Systems · 10 of 41

관련 글

임베디드 RAII 실전 패턴 — Lock·Pin·DMA·Power 관리

Embedded C++ for Real Systems — 임베디드 모던 C++ 시리즈 소개

임베디드 HAL 설계 패턴 — Static·Dynamic·Hybrid 비교

이 글을 참조하는 글 (8)

#RAII vs `defer` — 다른 언어와의 비교