Embedded C++ for Real Systems · 24/41

임베디드 에러 처리 패턴 — Result·errno·optional 비교

2026년 4월 30일 · Hawk · 4분 읽기

cpp embedded error-handling result-type error-chain fatal-error

Twitter LinkedIn

#한 줄 요약

“에러 처리는 세 가지 결정으로 정리됩니다.” 어디서 발견할지, 어떻게 전파할지, 어떻게 복구할지를 정합니다.

#어떤 문제를 푸는가

Part 3-05에서 도구를 소개했습니다. 이 글은 그것을 엮은 전체 시스템 이야기입니다.

대부분의 임베디드 프로젝트가 에러 처리에 일관성을 갖추지 못합니다.

어떤 곳은 error code, 어떤 곳은 bool, 어떤 곳은 exception을 씁니다.
전파 방식이 함수마다 다릅니다.
fatal과 recoverable 구분이 모호합니다.
로깅, 알람, 무시 사이의 결정이 산발적입니다.

시스템 차원의 패턴이 필요합니다. 이 글은 네 가지 결정으로 정리합니다.

#결정 1 — Fatal vs Recoverable

모든 에러는 둘 중 하나로 분류됩니다.

Fatal은 시스템을 유지할 수 없는 경우입니다.

Heap corruption
Stack overflow
Hardware bus fault
Watchdog reset 임박

Recoverable은 처리 가능한 경우입니다.

Sensor reading invalid
Buffer full
Timeout
Invalid user input

각각 다른 반응 전략을 가집니다.

1
// Fatal — 즉시 복구 시도 또는 안전 모드
2
[[noreturn]] void fatal_error(const char* msg) {
3
    __disable_irq();
4
    log_to_persistent_storage(msg);
5
    NVIC_SystemReset();   // 또는 안전 상태로 강제
6
}
7

8
// Recoverable — 호출자에 보고
9
tl::expected<Data, Error> read_sensor() {
10
    if (!ready()) return tl::unexpected(Error::Timeout);
11
    return parse_data();
12
}

#결정 2 — Error code 표준화

프로젝트 전체에서 통일된 에러 종류를 정의합니다.

1
// errors.h — 프로젝트 전체 공유
2
enum class Error : uint16_t {
3
    // 0-99: 공통
4
    Ok = 0,
5
    InvalidParam,
6
    NotInitialized,
7
    NotImplemented,
8

9
    // 100-199: 시간 관련
10
    Timeout = 100,
11
    NotReady,
12

13
    // 200-299: 메모리
14
    OutOfMemory = 200,
15
    BufferOverflow,
16
    AlignmentError,
17

18
    // 300-399: I/O
19
    IoError = 300,
20
    DeviceBusy,
21
    DeviceNotFound,
22

23
    // 400-499: protocol
24
    ProtocolError = 400,
25
    ChecksumMismatch,
26
    InvalidResponse,
27

28
    // 500-599: domain-specific
29
    SensorFault = 500,
30
    CalibrationFailed,
31
};
32

33
constexpr const char* error_name(Error e) {
34
    switch (e) {
35
        case Error::Ok:               return "Ok";
36
        case Error::InvalidParam:     return "InvalidParam";
37
        // ...
38
        default: return "Unknown";
39
    }
40
}

숫자 범위로 분류해 두면 새 에러를 해당 범위 안에서 추가할 수 있습니다.

#결정 3 — Result type 통일

모든 함수가 같은 Result 타입을 반환하면 일관성이 생깁니다.

1
// 프로젝트 전체 표준
2
template<typename T>
3
using Result = tl::expected<T, Error>;
4

5
// 사용
6
Result<int> divide(int a, int b);
7
Result<Data> read_sensor();
8
Result<void> write_register(uint8_t addr, uint8_t value);   // 반환값 없음
9

10
// void 특수
11
inline tl::unexpected<Error> err(Error e) { return tl::unexpected(e); }

함수 호출은 다음과 같이 이어집니다.

1
auto result = read_sensor()
2
    .and_then([](Data d) -> Result<float> {
3
        return process(d);
4
    })
5
    .or_else([](Error e) -> Result<float> {
6
        if (e == Error::Timeout) return 0.0f;   // 기본값
7
        return err(e);   // 다른 에러는 전파
8
    });

#결정 4 — 에러 chain 전파

저수준 에러를 고수준 에러로 wrap해 디버깅 정보를 보존합니다.

1
// 옵션 1 — 단순 변환 (정보 손실)
2
Result<float> read_temperature() {
3
    auto raw = read_register(0x10);
4
    if (!raw) return err(Error::SensorFault);   // 원본 에러 손실
5
    return celsius(*raw);
6
}
7

8
// 옵션 2 — Context 추가
9
struct ErrorContext {
10
    Error code;
11
    const char* function;
12
    int line;
13
    Error cause;   // 원인 에러
14
};
15

16
#define ERR_CTX(e, c) ErrorContext{(e), __func__, __LINE__, (c)}
17

18
Result<float> read_temperature() {
19
    auto raw = read_register(0x10);
20
    if (!raw) return tl::unexpected(ERR_CTX(Error::SensorFault, raw.error()));
21
    return celsius(*raw);
22
}

옵션 2는 디버깅 정보가 풍부하지만 코드 크기가 늘어납니다. 트레이드오프입니다.

#패턴 — Try Macro

C++23 이전에는 반환 후 검사가 반복됩니다. 매크로로 단순화할 수 있습니다.

1
#define TRY(expr) \
2
    ({ \
3
        auto _result = (expr); \
4
        if (!_result) return tl::unexpected(_result.error()); \
5
        std::move(*_result); \
6
    })
7

8
// 사용
9
Result<float> process() {
10
    auto raw = TRY(read_register(0x10));
11
    auto celsius = TRY(convert(raw));
12
    return celsius * 1.8f + 32.0f;
13
}

Rust의 ? operator와 유사한 형태입니다. GCC extension인 statement expression을 쓰므로 gnu++ 모드에서만 동작합니다.

C++23의 monadic chain(and_then)으로 표준적으로 대체할 수 있습니다.

#Logging 통합

에러 발생 시 위치, 내용, 시점을 함께 기록합니다. 로그가 디버깅의 1차 정보입니다.

1
// 매크로로 자동 file:line 정보
2
#define LOG_ERROR_RESULT(result) \
3
    do { \
4
        if (!(result)) { \
5
            log_error("%s:%d: error %s in %s", \
6
                __FILE__, __LINE__, \
7
                error_name((result).error()), __func__); \
8
        } \
9
    } while (0)
10

11
auto r = risky_operation();
12
LOG_ERROR_RESULT(r);
13
if (!r) return err(r.error());

C++20의 std::source_location을 함수 매개변수의 default로 두면 위치가 자동으로 채워집니다.

1
template<typename T>
2
void log_if_error(const Result<T>& r,
3
                  std::source_location loc = std::source_location::current()) {
4
    if (!r) {
5
        log_error("%s:%d in %s: error %s",
6
                  loc.file_name(), loc.line(), loc.function_name(),
7
                  error_name(r.error()));
8
    }
9
}

#패턴 — 우아한 복구

1
Result<Data> read_with_retry(int max_retries = 3) {
2
    for (int i = 0; i < max_retries; ++i) {
3
        auto result = read_sensor();
4
        if (result) return result;
5

6
        if (result.error() == Error::Timeout) {
7
            // 잠시 대기 후 재시도
8
            sleep_ms(10);
9
            continue;
10
        }
11

12
        // 다른 에러는 즉시 반환
13
        return result;
14
    }
15

16
    return err(Error::Timeout);   // 최종 실패
17
}
18

19
Result<float> read_or_default() {
20
    return read_temperature()
21
        .or_else([](Error e) -> Result<float> {
22
            if (e == Error::Timeout || e == Error::NotReady) {
23
                return last_valid_temperature();   // fallback
24
            }
25
            return err(e);
26
        });
27
}

복구 가능한 에러는 재시도나 fallback으로 처리하고, 진짜 에러는 그대로 전파합니다.

#State Machine + 에러

상태 머신에서는 에러를 상태 전이 트리거로 사용합니다.

1
enum class DeviceState { Idle, Initializing, Ready, Error, Recovering };
2

3
void device_loop() {
4
    static DeviceState state = DeviceState::Idle;
5

6
    switch (state) {
7
        case DeviceState::Idle:
8
            if (auto r = init(); r) state = DeviceState::Ready;
9
            else state = DeviceState::Error;
10
            break;
11

12
        case DeviceState::Ready:
13
            if (auto r = process(); !r) {
14
                log_error("process failed");
15
                state = DeviceState::Error;
16
            }
17
            break;
18

19
        case DeviceState::Error:
20
            attempt_recovery();
21
            state = DeviceState::Recovering;
22
            break;
23

24
        case DeviceState::Recovering:
25
            if (auto r = recovery_check(); r) state = DeviceState::Ready;
26
            break;
27
    }
28
}

자세한 state machine은 Part 4-06에서 다룹니다.

#Fatal error handling

fatal_error는 마지막 수단입니다. 호출 직전까지 최대한 정보를 보존합니다.

1
struct CrashInfo {
2
    uint32_t magic;       // 0xCAFEBABE
3
    uint32_t reset_count;
4
    Error last_error;
5
    uint32_t stack_pointer;
6
    uint32_t program_counter;
7
    char message[64];
8
    uint32_t crc;
9
};
10

11
static_assert(sizeof(CrashInfo) <= 128);
12

13
// 비휘발성 메모리 (battery-backed RAM, FRAM, ...)
14
__attribute__((section(".noinit")))
15
CrashInfo g_crash_info;
16

17
[[noreturn]] void fatal_error(const char* msg, Error code) {
18
    __disable_irq();
19

20
    g_crash_info.magic = 0xCAFEBABE;
21
    g_crash_info.last_error = code;
22
    g_crash_info.stack_pointer = __get_MSP();
23
    // current PC 등...
24
    strncpy(g_crash_info.message, msg, sizeof(g_crash_info.message) - 1);
25
    g_crash_info.crc = calculate_crc(&g_crash_info);
26

27
    NVIC_SystemReset();
28
}
29

30
// 부팅 시
31
void check_crash_info() {
32
    if (g_crash_info.magic == 0xCAFEBABE &&
33
        g_crash_info.crc == calculate_crc(&g_crash_info)) {
34
        // 이전 crash 정보 있음
35
        log_persistent("Recovered from crash: %s", g_crash_info.message);
36
    }
37
}

reset 이후에도 g_crash_info가 보존되므로 반복 crash를 추적할 수 있습니다.

#인증 환경 — DO-178C, ISO 26262

인증 환경에서는 에러 처리에 추가 제약이 붙습니다.

모든 에러 경로를 테스트해야 합니다.
recovery time을 명시하고 검증해야 합니다.
fail-safe behavior(예: power-off)를 정의해야 합니다.
로깅이 critical 메모리에 안전하게 기록되어야 합니다.

1
// 인증 환경 표준 패턴
2
[[nodiscard]] Error perform_operation(Input* in, Output* out) {
3
    // pre-condition
4
    if (!in || !out) return Error::InvalidParam;
5
    if (!is_initialized()) return Error::NotInitialized;
6

7
    // operation
8
    auto result = do_work(in, out);
9

10
    // post-condition
11
    if (result == Error::Ok && !validate_output(out)) {
12
        return Error::InternalError;
13
    }
14

15
    return result;
16
}

pre/post-condition을 명시하고 모든 분기 코드를 커버해야 합니다.

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

#1. Silent failure

1
bool foo();   // false 반환만 — 이유 모름

enum과 [[nodiscard]]를 함께 씁니다.

#2. 에러를 magic value로

1
int read();   // -1 반환 = 에러 (?)

-1이 valid 값일 수 있습니다. 명시적으로 optional이나 expected를 사용합니다.

#3. 예외와 error code 혼용

1
void foo() {
2
    throw std::exception();   // -fno-exceptions에서 abort
3
}
4
ErrorCode bar();

프로젝트 전체에서 통일합니다. exception을 끄면 어디에서도 throw하지 않습니다.

#4. 에러 로그 너무 많음

1
if (auto r = read(); !r) {
2
    log_error("read failed");   // 매 호출
3
}

timeout처럼 빈번한 에러는 logging level로 통제합니다.

#5. fatal_error가 너무 흔함

recoverable한 경우까지 fatal로 처리하면 시스템이 자주 reset됩니다. 분류를 신중히 합니다.

#6. try/catch + -fno-exceptions

1
try { foo(); } catch (...) {}   // 컴파일 에러

예외를 끄면 try를 금지합니다.

#측정 — 에러 처리 패턴의 코드 영향

같은 함수를 다른 에러 처리 방식으로 비교합니다.

1
# bool 반환
2
bool f() { return true; }
3
크기: 8 B
4

5
# error code
6
ErrorCode f() { return ErrorCode::Ok; }
7
크기: 10 B
8

9
# optional<T>
10
std::optional<int> f() { return 42; }
11
크기: 16 B (return value + has_value flag)
12

13
# expected<T, E>
14
tl::expected<int, ErrorCode> f() { return 42; }
15
크기: 18 B
16

17
# 예외 (-fexceptions)
18
int f() { throw std::runtime_error("err"); }
19
크기: 312 B + unwind table 추가

예외가 압도적으로 크고, optional과 expected는 거의 동일합니다.

#정리

에러 처리는 네 가지 결정으로 정리됩니다 — fatal과 recoverable 구분, error code 표준화, Result type 통일, chain 전파.
프로젝트 전체에서 Result<T> = tl::expected<T, Error>로 통일합니다.
Try macro나 and_then으로 체인을 단순화합니다.
Logging은 source_location이나 매크로로 통합합니다.
Recovery 패턴은 retry, fallback, state machine 전이로 구성됩니다.
Fatal error는 비휘발성 메모리에 정보를 보존한 뒤 reset합니다.