임베디드 시스템 해부 — MCU·펌웨어·드라이버·RTOS·인터럽트·메모리를 테스터의 눈으로

개념

웹 테스트와 무엇이 다른가

웹 서비스를 테스트할 때 우리는 운영체제·브라우저·네트워크가 대부분의 일을 알아서 해 준다고 가정한다. 메모리가 부족하면 운영체제가 관리하고, 시간은 충분하며, 오류가 나면 로그가 남는다. 임베디드 시스템에서는 이 가정이 하나씩 깨진다.

이 차이 때문에 임베디드 테스터는 시스템이 어떻게 생겼는지 를 웹 테스터보다 훨씬 깊이 알아야 한다. 모듈 9의 "코드 읽기"가 여기서는 "구조 읽기"까지 확장된다.

층으로 보는 임베디드 시스템

┌─────────────────────────────────────┐
│ 응용 계층   제어 로직, 상태 머신, 통신 프로토콜 처리  │
├─────────────────────────────────────┤
│ 미들웨어    RTOS, 통신 스택, 파일 시스템            │
├─────────────────────────────────────┤
│ 드라이버    UART·SPI·I2C·CAN·ADC·PWM·GPIO 제어    │
├─────────────────────────────────────┤
│ 부트로더    시작, 무결성 확인, 펌웨어 업데이트       │
├─────────────────────────────────────┤
│ 하드웨어    MCU 코어, 주변장치, 클럭, 전원, 센서     │
└─────────────────────────────────────┘

위 그림의 드라이버 칸에 낯선 약어가 몰려 있다. 이 모듈 전체에서 계속 나오므로 여기서 한 번 정리한다. 지금 외울 필요는 없고, 읽다가 막히면 이 표로 돌아오면 된다.

메모리도 세 가지가 나온다. 플래시 는 전원이 꺼져도 내용이 남는 저장 공간(펌웨어가 여기 구워진다), RAM 은 전원이 꺼지면 사라지는 작업용 공간, EEPROM 은 설정값처럼 자주 바뀌는 작은 데이터를 전원과 무관하게 담아 두는 공간이다. 쓸 수 있는 횟수에 한계가 있어 몇 번까지 쓰느냐가 시험 항목이 된다.

뒤 레슨에서 FW(펌웨어의 줄임말)와 HAL 도 나온다. HAL 은 칩마다 다른 부분을 한 겹으로 감싸 윗층 코드가 칩을 몰라도 되게 만든 층이다 — 그 덕에 실제 칩 없이도 윗층만 따로 시험할 수 있다(레슨 8).

MCU(마이크로컨트롤러) 는 CPU 코어·메모리(플래시·RAM)·주변장치(타이머·ADC·통신 컨트롤러)를 한 칩에 넣은 것이다. 주변장치는 레지스터라는 특수한 메모리 주소를 통해 제어된다. 드라이버는 이 레지스터를 읽고 쓰는 코드다.

펌웨어 는 이 모든 층의 소프트웨어를 합쳐 플래시에 굽는 하나의 이미지다. 웹처럼 "서버만 재배포"하는 개념이 없다. 드라이버 한 줄을 고쳐도 전체 이미지를 다시 만들고 다시 굽는다.

층마다 생기는 전형적 결함

베어메탈과 RTOS

작은 시스템은 운영체제 없이 슈퍼루프 로 동작한다.

int main(void) {
    init_hardware();
    while (1) {            // 영원히 반복
        read_sensors();
        update_control();
        send_status();
    }
}

단순하지만, 한 함수가 오래 걸리면 나머지가 모두 늦어진다. send_status() 가 통신 대기로 50ms 걸리면 센서는 50ms 동안 읽히지 않는다. 테스터는 최악의 루프 한 바퀴 시간 을 재야 한다.

복잡한 시스템은 RTOS(실시간 운영체제 — FreeRTOS, Zephyr, AUTOSAR OS 등)를 쓴다. 기능을 여러 태스크로 나누고 우선순위에 따라 스케줄링한다. 이때 새로운 결함 유형이 생긴다.

우선순위 역전은 1997년 화성 탐사선 Mars Pathfinder의 반복 리셋 원인으로 유명하다. 지상 시험에서 드물게 재현되던 현상을 무시했다가 화성에서 문제가 됐다. "드물게 재현되는" 은 임베디드에서 가장 위험한 말이다.

인터럽트 — 언제든 끼어드는 코드

인터럽트는 하드웨어 사건(타이머 만료, 데이터 수신, 버튼 눌림)이 생기면 현재 코드를 멈추고 인터럽트 서비스 루틴(ISR) 을 실행하는 구조다. 임베디드의 비결정적 결함 대부분이 여기서 나온다.

• 공유 변수 경쟁 — 메인 루프가 변수를 읽는 도중 ISR이 그 변수를 바꾼다. 16비트 MCU에서 32비트 값을 두 번에 나눠 읽는 사이에 ISR이 끼어들면 반쪽만 바뀐 값 이 읽힌다
• ISR이 너무 길다 — 다른 인터럽트가 밀리고, 통신 데이터를 놓친다
• 인터럽트 폭주 — 버튼 채터링(접점 떨림)이나 잡음으로 인터럽트가 수천 번 발생

시험 관점은 타이밍을 흔드는 것 이다. 통신 수신 속도를 최대로 올리면서 타이머 인터럽트를 겹치고, 버튼을 빠르게 연타하고, 잡음을 주입한다.

메모리 — 어디에 무엇이 있나

많은 임베디드 코딩 규칙(MISRA C 등, 모듈 35 레슨 4)이 동적 할당을 금지하거나 제한하는 이유가 힙 단편화다. 몇 시간 테스트로는 드러나지 않고, 현장에서 몇 주 운영한 뒤에 나타난다. 그래서 장시간 연속 시험(soak test) 이 임베디드에서 특히 중요하다.

EEPROM에 1초마다 상태를 기록하는 설계를 보면 즉시 계산한다. 수명 10만 회라면 약 28시간이면 수명이 끝난다. 이것은 코드 리뷰나 설계 리뷰 단계에서 테스터가 잡을 수 있는 결함이다.

실무에서 왜 필요한가

임베디드 결함은 발견이 늦을수록 비싸다. 현장에 설치된 장치의 결함은 회수·방문 수리·리콜로 이어지고, 안전과 관련되면 사고가 된다. 구조를 이해한 테스터는 "기능이 동작하는가"를 넘어 "어떤 조건에서 동작하지 않을 수 있는가" 를 물을 수 있다. 우선순위 역전, 스택 오버플로, EEPROM 수명 같은 결함은 기능 테스트로는 거의 잡히지 않고, 구조에서 출발한 시험으로만 잡힌다.

채용시장에서의 위치

임베디드 검증 면접은 "RTOS 태스크 간 동기화 문제를 어떻게 시험하나", "스택 오버플로를 어떻게 찾나", "인터럽트와 메인 루프가 공유하는 변수의 문제는" 같은 구조 질문으로 시작하는 경우가 많다. C 코드를 직접 짜지 않더라도 이 질문에 구조와 시험 방법으로 답할 수 있으면 웹 QA 출신이라도 진지하게 검토된다.

실습 과제

과제 1 — 층별 결함 지도 (15분)

가정용 스마트 도어락(지문 센서, 모터, BLE 통신, 배터리)을 가정해 다섯 층마다 전형적 결함을 두 개씩 적고, 각 결함을 드러낼 시험 방법을 한 줄씩 붙인다.

과제 2 — 슈퍼루프 최악 시간 (10분)

슈퍼루프가 센서 읽기(2ms), 제어 계산(1ms), 상태 전송(평균 3ms, 통신 재시도 시 최대 40ms)으로 구성되어 있다. 센서를 10ms마다 읽어야 한다는 요구가 있다면 무엇이 위험하고 어떻게 시험할지 적는다.

과제 3 — EEPROM 수명 계산 (10분)

쓰기 수명 10만 회인 EEPROM 영역에 (a) 1초마다, (b) 상태가 바뀔 때만(하루 평균 200회) 기록하는 두 설계의 수명을 계산하고, 제품 수명 10년 요구와 비교한다.

자가 체크리스트

• 웹 서비스와 임베디드 시스템 테스트의 가정이 어떻게 다른지 말할 수 있다
• 하드웨어·부트로더·드라이버·미들웨어·응용 층과 층별 전형적 결함을 말할 수 있다
• 베어메탈 슈퍼루프와 RTOS의 차이, RTOS 고유 결함 네 가지를 설명할 수 있다
• 인터럽트가 만드는 비결정적 결함과 시험 관점을 설명할 수 있다
• 메모리 영역별 결함과 장시간 연속 시험이 필요한 이유를 말할 수 있다

흔한 실수

• 기능 동작만 확인한다. 임베디드 결함은 조건(타이밍·전원·부하)에 숨는다.
• "드물게 재현된다"를 무시한다. 현장 장치 수만 대에서는 드문 일이 매일 일어난다.
• 평균 루프 시간만 잰다. 실시간 요구는 최악 시간으로 판정한다.
• 장시간 시험을 생략한다. 힙 단편화·메모리 누수·EEPROM 마모는 며칠 뒤에 드러난다.
• 구조 질문을 개발자에게만 맡긴다. 스택 여유, 쓰기 빈도 같은 질문은 테스터가 먼저 던질 수 있다.

참고 자료

• FreeRTOS — Stack Usage and Stack Overflow Checking — 스택 여유(high-water mark) 측정과 오버플로 검사
• Glenn Reeves, "What really happened on Mars?" (1997) — Mars Pathfinder 우선순위 역전 사례
• 레슨 s2-m35-l04 — MISRA C 지침의 범주와 분석 범위
• 레슨 s3-m09-l01 — 코드 읽기의 기초