[임베디드기사 실기 20부작 20편] 장애 대응과 실기 최종 총정리 — 접수부터 원인분석·복구·재발방지까지
20부작의 마지막 편입니다. 지금까지 우리는 Startup Code, Bootloader, Linux Kernel, Device Driver, Memory, Interrupt, Synchronization, Build Toolchain, Communication, C 언어, 자료구조, UML과 Testing까지 실기 핵심 영역을 하나씩 살펴봤습니다.
마지막 20편에서는 이 모든 기술을 실제 문제 상황에 적용하는 장애 대응 관점으로 묶어 정리합니다. 장애 대응은 단순히 “고장난 것을 고치는 기술”이 아니라, 장애를 접수하고 → 심각도를 판단하고 → 원인을 분석하고 → 복구하고 → 검증하고 → 재발을 방지하는 체계적인 문제 해결 절차입니다.
임베디드 시스템의 장애는 하나의 원인으로만 발생하지 않습니다. Hardware, Firmware, Kernel, Driver, Network, Sensor, Power, Mechanical System이 서로 연결되어 있기 때문입니다.
예를 들어 Motor가 움직이지 않는 현상 하나만 보더라도 다음 가능성이 있습니다.
전원 문제 → Enable Signal 문제 → Driver Alarm → Firmware State 문제 → Communication Timeout → Limit Sensor 입력 오류 → Software Interlock 문제
따라서 장애 대응 문제에서는 단순히 원인을 하나 찍는 것이 아니라 현상을 구조적으로 분해하고 검증하는 능력이 중요합니다.
장애 접수 ↓ 분류 / 등급 지정 / 우선순위 결정 ↓ 현상 재현 및 영향도 확인 ↓ 로그 / 데이터 / 증거 확보 ↓ 원인 분석 ↓ 임시 조치 ↓ 근본 원인 제거 ↓ 복구 ↓ 반복 검증 ↓ 결과 공유 ↓ 이력 관리 ↓ 재발 방지
이 흐름은 실기 서술형 답안을 작성할 때 그대로 사용할 수 있는 기본 골격입니다.
장애 접수 단계에서는 “무엇이 고장났는가”보다 먼저 어떤 상황에서 어떤 현상이 발생했는가를 정확히 기록해야 합니다.
다음 항목을 확보하면 좋습니다.
발생 시각 / 발생 장비 / Software Version / Firmware Version / 재현 조건 / 사용자 동작 / Alarm Code / Log / Screen Capture / Sensor 상태 / Network 상태
좋지 않은 접수 내용은 “장비가 안 됩니다”이고, 좋은 접수 내용은 다음과 같습니다.
“14:32, Load Port Unloading Sequence 중 Step 17에서 Timeout 발생. FW v1.4.1, Motor Enable은 ON, Mapping Sensor는 Normal, 동일 조건에서 3회 중 2회 재현.”
모든 장애를 같은 우선순위로 처리하면 안 됩니다. 장애의 영향도와 긴급도를 기준으로 등급을 정해야 합니다.
예를 들면 다음처럼 분류할 수 있습니다.
| 등급 | 예시 | 대응 |
|---|---|---|
| Critical | 안전 위험, 생산 중단, 데이터 손상 | 즉시 대응 |
| Major | 주요 기능 불가, 우회 가능 | 높은 우선순위 |
| Minor | 부분 기능 저하 | 일정 내 처리 |
| Cosmetic | 표시 오류, UI 문제 | 낮은 우선순위 |
재현 가능한 장애는 해결 가능성이 높아집니다.
재현 단계에서는 다음 질문이 중요합니다.
① 항상 발생하는가?
② 특정 Sequence에서만 발생하는가?
③ 특정 Lot/Recipe/Device에서만 발생하는가?
④ Cold Boot와 Warm Boot에서 차이가 있는가?
⑤ 장시간 동작 후 발생하는가?
⑥ 특정 속도나 부하에서만 발생하는가?
재현 여부가 불확실하면 원인 분석보다 먼저 재현 조건 고정이 우선입니다.
장애 분석에서 가장 큰 실수는 문제를 재현한 직후 장비를 재부팅해 중요한 증거를 없애는 것입니다.
가능하면 다음 자료를 먼저 확보합니다.
Kernel Log / Application Log / Driver Log / Communication Packet / Register Dump / Sensor Input / Motor Alarm / CPU Usage / Memory Usage / Timestamp / Oscilloscope Waveform
Linux 환경에서는 dmesg, journalctl, Application Log, Network Capture 등을 활용할 수 있습니다.
장애를 한꺼번에 보지 말고 다음처럼 계층별로 분리합니다.
Application ↓ OS / Kernel ↓ Device Driver ↓ Firmware ↓ Communication ↓ Hardware ↓ Mechanical / Sensor / Power
이렇게 Layer를 나누면 “어디까지 정상이고 어디부터 비정상인가”를 빠르게 좁힐 수 있습니다.
복잡한 시스템에서는 원인을 하나씩 처음부터 끝까지 확인하는 것보다 중간 지점을 확인하여 범위를 절반씩 줄이는 방식이 효과적입니다.
예를 들어 Motor Command가 실행되지 않는다면 다음처럼 볼 수 있습니다.
Application에서 Command 생성 여부 → Driver 전달 여부 → UART/SPI Packet 송신 여부 → Motor Controller 수신 여부 → Enable Signal 여부 → Motor Output 여부
중간 단계 하나만 확인해도 문제 범위를 절반 이상 줄일 수 있습니다.
장애의 표면적 원인만 제거하면 재발합니다. 그래서 “왜?”를 반복하여 근본 원인에 접근하는 방식이 중요합니다.
예:
왜 장비가 멈췄는가? → Motor Alarm 발생
왜 Alarm이 발생했는가? → Overcurrent
왜 Overcurrent가 발생했는가? → Mechanism Jam
왜 Jam이 발생했는가? → Guide 조립 편차
왜 조립 편차가 발생했는가? → 조립 기준과 검사 기준이 없음
이 경우 진짜 개선책은 단순 Alarm Reset이 아니라 조립 기준과 검사 기준의 표준화입니다.
임시 조치(Containment)는 생산이나 서비스를 빠르게 복구하기 위한 조치입니다.
근본 조치(Corrective Action)는 실제 원인을 제거하여 동일 장애가 다시 발생하지 않도록 하는 조치입니다.
예를 들어 Timeout 값을 2초에서 5초로 늘려 장애가 사라졌다고 해도, 실제 원인이 Motor 응답 지연이라면 Timeout 증가는 임시 조치일 뿐입니다.
“한 번 정상 동작했다”는 것은 해결이 아닙니다.
복구 후에는 다음을 확인해야 합니다.
① 동일 조건 반복 시험
② Worst Case 조건 시험
③ Power Cycle 시험
④ 장시간 연속 시험
⑤ Boundary Condition 시험
⑥ 이전 정상 기능 Regression Test
장시간 장비에서는 수십 회 정상보다 수천 회 반복 시험이 더 의미 있을 수 있습니다.
장애 이력은 단순 보고서가 아니라 조직의 기술 자산입니다.
다음 항목을 기록해 두면 좋습니다.
발생 현상 / 발생 조건 / 영향 범위 / 원인 / 임시 조치 / 근본 조치 / 수정 Version / 검증 방법 / 재발 여부 / 담당자 / 완료일
같은 장애가 반복될 때 이전 이력을 검색할 수 있다면 문제 해결 속도는 크게 향상됩니다.
장애가 반복되는 이유는 Software Bug만이 아닙니다.
설계 Review 부족 / Test Coverage 부족 / Change Management 부족 / Calibration 기준 부재 / Version 관리 실패 / 인수인계 부족 / Log 부족
따라서 근본 개선은 Code Fix뿐 아니라 개발 프로세스까지 포함해야 합니다.
실제 장애는 지금까지 학습한 모든 영역과 연결됩니다.
Startup Code → Boot 실패
Kernel / Driver → Device Node 미생성
Memory → OOM / Leak / Double Free
Interrupt → ISR 미실행 / Interrupt Storm
Synchronization → Deadlock / Race Condition
TCP → Connection Failure / Timeout
UART/SPI → Framing Error / Mode 불일치
C Pointer → Crash / Memory Corruption
UML/Test → 설계 누락 / 검증 부족
점검 순서:
Baud Rate → TX/RX 배선 → GND → Framing/Parity Error → Buffer Overflow → ISR 실행 시간 → Ring Buffer 상태 → Thread 처리 지연 → Cable Noise
핵심은 Software와 Hardware를 동시에 열어 놓고 보는 것입니다.
점검 순서:
CS Timing → CLK Frequency → CPOL/CPHA → MOSI/MISO → Bit Order → Setup/Hold Time → DMA Buffer → Cache Coherency → Noise
단순히 Sensor 불량으로 결론 내리기 전에 Protocol Timing부터 확인해야 합니다.
점검 순서:
Memory Leak → Heap Fragmentation → Use After Free → Double Free → Stack Overflow → File Descriptor Leak → Thread 증가 → Log 증가 → OOM Killer
장시간 장애는 “시간이 원인”이 아니라 누적되는 자원이 원인인 경우가 많습니다.
점검 순서:
Limit Sensor → Encoder → Motor Alarm → Current → Mechanism Load → Motion Command → Interlock → Position Table → Cable Contact
특정 위치에서만 발생한다면 위치 의존 요소를 먼저 의심하는 것이 효율적입니다.
Kernel Panic 발생 시에는 재부팅 전에 가능한 한 다음을 확보합니다.
Call Trace / Panic Message / Module Version / Driver Load 상태 / 최근 변경사항 / Oops 주소 / Register Dump
Driver Pointer 오류, NULL Dereference, Use After Free, Stack Corruption 등이 주요 원인이 될 수 있습니다.
점검 순서:
Link 상태 → IP → Routing → Port → Firewall → SYN/SYN+ACK/ACK → Keepalive → Timeout → Server Process → Resource Exhaustion
Network 장애는 Application만 보지 말고 Packet Level까지 내려가 확인해야 합니다.
실기시험에서 상황형 문제가 나오면 다음 7단계로 답안을 구성하면 안정적입니다.
① 현상 정의
② 영향도와 우선순위 판단
③ 로그와 데이터 확보
④ 원인 후보 분리
⑤ 임시 조치
⑥ 근본 원인 제거
⑦ 반복 검증과 재발 방지
이 구조는 문제 종류와 관계없이 대부분의 장애 대응 서술형에 적용할 수 있습니다.
문제 1. 장애 접수 후 처리 절차를 설명하시오.
모범답안: 장애를 접수하면 발생 현상과 영향 범위를 확인하고 장애 등급 및 우선순위를 결정한다. 이후 로그와 재현 조건을 확보하여 원인을 분석하고, 임시 조치와 근본 조치를 수행한 뒤 반복 검증하여 정상 복구 여부를 확인한다. 마지막으로 장애 이력을 기록하고 재발 방지 대책을 반영한다.
문제 2. 임시 조치와 근본 조치의 차이를 설명하시오.
모범답안: 임시 조치는 장애 영향도를 줄이고 서비스를 빠르게 복구하기 위한 단기 조치이다. 근본 조치는 실제 원인을 제거하여 동일 장애가 다시 발생하지 않도록 하는 장기 개선 조치이다.
문제 3. 장애 복구 후 필요한 검증 항목을 쓰시오.
모범답안: 동일 조건 반복 시험, 경계 조건 시험, 장시간 시험, Power Cycle 시험, Regression Test 등을 수행하여 장애가 재발하지 않고 기존 기능에도 영향이 없음을 확인해야 한다.
문제 4. 장애 이력 관리의 목적은 무엇인가?
모범답안: 장애의 발생 조건, 원인, 조치 내용, 검증 결과를 기록하여 동일 장애 재발 시 대응 시간을 단축하고 조직의 기술 자산으로 활용하기 위함이다.
1. Startup Code는 Reset 이후 가장 먼저 실행되는 초기화 코드이다.
2. Bootloader는 Kernel Image를 Load하고 실행을 넘겨준다.
3. module_init()은 Kernel Module의 초기화 함수를 등록한다.
4. register_chrdev()는 Character Device Driver를 Kernel에 등록한다.
5. mknod는 Device Node를 생성한다.
6. Major Number는 Driver를, Minor Number는 Device를 구분한다.
7. SRAM은 Refresh가 필요 없고 DRAM은 필요하다.
8. ZONE_NORMAL은 Kernel이 선형 매핑으로 접근하는 영역이다.
9. Interrupt는 IVT를 통해 ISR 주소를 찾는다.
10. DMA는 CPU 대신 장치와 Memory 사이의 데이터를 전송한다.
11. Mutex는 Sleep 가능, Spinlock은 Busy-waiting이다.
12. $@는 Target, $^는 모든 Prerequisite이다.
13. readelf는 ELF 구조를 확인하는 도구이다.
14. TCP Server는 socket-bind-listen-accept 순서이다.
15. UART는 비동기, SPI는 Clock 기반 동기식이다.
16. Pointer는 주소를 저장하고 *p는 그 주소의 값을 의미한다.
17. Double Free는 같은 Heap Memory를 두 번 해제하는 오류이다.
18. Stack은 LIFO, Queue는 FIFO이다.
19. White-Box는 내부 구조, Black-Box는 외부 기능을 검증한다.
20. 장애 대응은 접수-분류-분석-조치-검증-이력-재발방지 순으로 기억한다.
서술형 답안이 막히면 다음 구조를 사용하면 좋습니다.
1문장: 정의
“○○은 ~~하기 위한 기술이다.”
2문장: 특징/동작
“주요 특징은 ~~이며, ~~ 방식으로 동작한다.”
3문장: 목적/용도
“이를 통해 ~~를 줄이고 ~~를 향상시킬 수 있다.”
시험 전날에는 새로운 내용을 공부하기보다 다음 순서로 압축 복습하는 것이 좋습니다.
Kernel/Driver → Memory → Interrupt → Synchronization → Build → Communication → C → Data Structure → UML/Test → 장애 대응
각 영역에서 “핵심 문장 3개”씩만 바로 말할 수 있으면 시험장에서 대부분의 서술형 문제를 풀 수 있는 기반이 마련됩니다.
이번 20편까지의 내용을 책으로 편집한다면 다음 5부 구조가 자연스럽습니다.
1부 — 부팅과 Kernel
Startup, Bootloader, Kernel, Kconfig
2부 — Driver와 Hardware
Device Driver, mknod, System Call, Interrupt, DMA
3부 — Memory와 동시성
SRAM/DRAM, Virtual Memory, Synchronization
4부 — Build, Communication, C
Makefile, ELF, TCP, UART, SPI, Pointer, Data Structure
5부 — 설계, 검증, 장애 대응
UML, Test, 장애 대응, 최종 모의정리
실기시험에서 중요한 것은 많은 용어를 외우는 것이 아니라, 하나의 문제를 만났을 때 관련 개념을 연결하여 답안을 구성하는 능력입니다.
Boot Failure를 보면 Startup Code와 Bootloader를 떠올리고, Device 문제를 보면 Driver와 Device Node를 떠올리고, Hang 문제를 보면 Deadlock과 Watchdog을 떠올리고, 장시간 장애를 보면 Memory Leak과 Resource Exhaustion을 떠올릴 수 있어야 합니다.
결국 임베디드 시스템은 하나의 연결된 시스템입니다. 그리고 실기시험은 그 연결을 이해했는지를 확인하는 시험이라고 볼 수 있습니다.
정의 → 구조 → 동작 → 장애 → 검증
이 다섯 단계로 개념을 정리하면 시험 대비뿐 아니라 실제 장비 개발과 문제 해결에도 그대로 활용할 수 있습니다.
#임베디드기사 #임베디드기사실기 #장애대응 #Troubleshooting #RootCauseAnalysis #RCA #장애분석 #장애복구 #재발방지 #5Why #로그분석 #DeviceDriver #LinuxKernel #Firmware #EmbeddedLinux #임베디드시스템 #실기시험 #자격증공부 #기술블로그 #20부작완결