공고 기술 스택 — 무엇을 왜 요구하나
공고가 요구한 기술이 여덟 가지쯤 나열돼 있는데 전부 같은 무게가 아니다. "C언어 활용 역량이 가장 핵심" 이라고 두 번 못 박았고, 나머지는 "등", "해당시" 로 붙어 있다.
각 항목이 ADAS 개발에서 실제로 어디에 쓰이는지를 알면 무게가 보인다. 그리고 근무지가 영남대 내 연구소 라는 점이 이 목록의 성격을 설명한다.
공고를 무게순으로 다시 쓰면
반드시 C — "가장 핵심", 면접 중요 요소로 재언급
반드시 영어 — "가산점" 이라 적혔지만 면접 중요 요소로 재언급
있으면 강함 임베디드 프로젝트 경험 ("경험자 유리함")
있으면 강함 CAN · SPI · I2C
RTOS
플러스 C++ · Python
Embedded Linux
ROS · MATLAB/Simulink
AUTOSAR · ISO 26262 ("해당시")
"해당시" 와 "등" 이 붙은 항목은 없어도 된다는 뜻이다. 인턴에게 AUTOSAR 실무를 기대하지 않는다. 다만 무엇인지 알고 있으면 다르게 보인다.
목록이 뒤섞여 보이는 이유는 세 세계가 한 공고에 들어 있기 때문이다. 왼쪽이 신입 임베디드가 먼저 만나는 자리이고, 오른쪽 둘은 알아 두면 대화가 되는 영역이다.
왜 이런 목록인가 — 근무지가 설명해 준다
근무지: 영남대 내 연구소 → 양산 공장이 아니라 R&D
R&D 조직은 센서 펌웨어(C·MCU)부터 알고리즘 프로토타이핑(Simulink·ROS)까지 한 흐름으로 다룬다. 그래서 목록이 저렇게 넓다 — 한 사람이 다 하는 것이 아니라 조직이 그 범위를 다룬다는 뜻이다.
센서 하드웨어·펌웨어 C · MCU · CAN/SPI/I2C · RTOS ← 임베디드 자리
알고리즘 개발·검증 MATLAB/Simulink · Python · ROS
컴퓨팅 유닛 소프트웨어 C++ · Embedded Linux
양산 전개 AUTOSAR · ISO 26262
C — 왜 "가장 핵심" 인가
ADAS 센서는 MCU 에서 돌고, 그 위에 OS 가 없거나 RTOS 뿐이다. 그러면 C 밖에 선택지가 없다.
초음파 센서 하나가 하는 일
압전 소자를 구동하고 타이머·GPIO 레지스터 조작
반사파 도착 시각을 잰다 입력 캡처 인터럽트
거리로 환산하고 필터링 정수·고정소수점 연산
CAN 으로 내보낸다 통신 레지스터
전부 레지스터를 포인터로 다루는 일이다. C 가 하드웨어에 가장 가까운 언어라서 쓰는 것이지 취향이 아니다.
면접에서 실제로 묻는 것
"volatile 은 언제 왜 쓰나" ★ 거의 확실히 나온다
→ 컴파일러가 값을 레지스터에 캐시하면 하드웨어가 바꾼 값을 못 읽는다
→ 상태 레지스터를 폴링하는 루프가 무한 루프가 된다
→ 다만 원자성은 보장하지 않아 ++ 나 64비트 접근은 여전히 안전하지 않다
"구조체 크기가 예상과 다른 이유"
→ 정렬 패딩. 큰 멤버부터 배치하면 준다
→ 통신에는 구조체를 그대로 쓰지 않고 바이트로 직렬화한다
"임베디드에서 malloc 을 왜 피하나"
→ 실패했을 때 할 수 있는 일이 없다 · 단편화가 재부팅까지 회복 안 된다
→ 할당 시간이 불확정이라 실시간성이 깨진다
→ 정적 할당은 링크 시점에 메모리 부족을 알려 준다
"int 대신 uint32_t 를 쓰는 이유"
→ int 의 크기는 표준이 정하지 않는다. 8비트 MCU 에서 16비트인 경우가 있다
백지에 쓸 수 있어야 하는 것
void set_bit(volatile uint32_t *reg, int n); // 세트·클리어·토글
int ring_push(Ring *q, uint8_t v); // 링 버퍼 ★ 단골
uint16_t crc16(const uint8_t *d, size_t n); // CRC
uint32_t swap32(uint32_t v); // 엔디안 변환
링 버퍼와 비트 조작은 반드시 준비한다. 임베디드 면접의 기본이다. → 비트 조작 · 임베디드 C 함정
C++ — 어디에 쓰이나
MCU 센서 펌웨어 대개 C. C++ 를 쓰더라도 예외·RTTI·동적할당은 금지
컴퓨팅 유닛 C++ 가 주력 — 인지 알고리즘·미들웨어
AUTOSAR Adaptive C++ 기반
ROS C++ 또는 Python
"임베디드 C++" 는 일반 C++ 와 다르다.
// 임베디드에서 금지되거나 제한되는 것
try { } catch { } // 예외 — 코드 크기·비결정적 시간
dynamic_cast<T>(p); // RTTI — 메타데이터가 Flash 를 먹는다
new / delete // 동적 할당 — 단편화
std::string // 내부적으로 힙을 쓴다
std::function // 힙을 쓸 수 있다
-fno-exceptions -fno-rtti 로 빌드하는 것이 관행이고, std::array·std::span 처럼 힙을 안 쓰는 것만 골라 쓴다.
Embedded Linux — 왜 이 목록에 있나
센서는 MCU 지만 컴퓨팅 유닛은 리눅스다.
초음파·레이더 센서 MCU (Cortex-M) · 베어메탈 또는 RTOS
수십 KB SRAM · 즉시 부팅 · 결정적 타이밍
Domain / Central 제어기 SoC (Cortex-A) · Embedded Linux 또는 QNX
수 GB RAM · 카메라·라이다 대용량 처리 · AI 추론
같은 차 안에 성격이 다른 두 세계가 있다. 공고에 RTOS 와 Embedded Linux 가 나란히 있는 이유다.
무엇을 알면 되나
크로스 컴파일 · 툴체인 arm-linux-gnueabihf-
디바이스 트리 하드웨어 구성을 커널에 알려 주는 방식
커널 모듈 · 드라이버 기초 사용자 공간에서 하드웨어에 접근하는 경로
Yocto / Buildroot 임베디드 리눅스 이미지를 만드는 도구
systemd · 부팅 시간 최적화
/dev · /sys 로 하드웨어 접근 GPIO·SPI·I2C 를 리눅스에서 다루는 법
// 리눅스에서 SPI 를 쓰면 이런 모양이 된다 — 레지스터가 아니라 파일이다
int fd = open("/dev/spidev0.0", O_RDWR);
struct spi_ioc_transfer tr = { .tx_buf = (unsigned long)tx,
.rx_buf = (unsigned long)rx, .len = n };
ioctl(fd, SPI_IOC_MESSAGE(1), &tr);
MCU 에서 하던 일을 리눅스에서는 파일과 ioctl 로 한다. 같은 하드웨어를 다르게 만지는 것이라, 한쪽을 알면 다른 쪽이 빠르다.
리눅스 자체의 개념(프로세스·가상 메모리·스케줄링)은 운영체제 트랙에 정리돼 있다.
RTOS — 언제 필요한가
베어메탈로 되는 경우 작업이 적고 주기가 비슷하다
RTOS 가 필요한 경우 선점이 필요하다 · 블로킹 코드를 그대로 쓰고 싶다
RTOS 가 파는 것은 기능이 아니라 "선점" 과 "기다리는 코드" 다. 비용은 태스크마다의 스택(RAM)이다.
면접에서 묻는 것
"우선순위 역전이 뭔가" ★ RTOS 질문의 단골
→ 낮은 태스크가 잡은 뮤텍스를 높은 태스크가 기다리는데,
무관한 중간 태스크가 낮은 것을 선점해 높은 것이 계속 밀린다
→ 해법은 우선순위 상속. 화성 탐사선 Pathfinder 사례
"세마포어와 뮤텍스의 차이"
→ 세마포어는 신호 전달, 뮤텍스는 상호 배제
→ 뮤텍스는 소유자가 있고 우선순위 상속을 지원한다
→ ISR 에서 뮤텍스를 못 쓰는 이유가 소유자 개념 때문
"ISR 에서 하면 안 되는 것"
→ printf · malloc · 블로킹 대기
→ 특히 지연 함수는 자기보다 낮은 우선순위의 틱을 기다려 영원히 멈출 수 있다
CAN · SPI · I²C — 차량 통신
공고가 이 셋을 명시했다. 각각 쓰이는 자리가 다르다.
SPI · I²C 센서 칩과 MCU 사이 (보드 안)
CAN ECU 와 ECU 사이 (차량 전체)
CAN 이 가장 중요하다
"CAN 에서 우선순위는 어떻게 정해지나"
→ ID 가 작을수록 높다. 와이어드 AND 로 0(우성)이 1(열성)을 이긴다
→ 진 쪽은 데이터를 잃지 않고 물러난다 (비파괴 중재)
→ 그래서 최악 지연을 계산할 수 있어 안전 시스템에 쓴다 ★ 여기까지가 좋은 답
"종단 저항은 왜 필요하고 몇 옴인가"
→ 반사 방지. 120Ω 을 버스 양 끝에만
→ 전원 끄고 CAN_H↔CAN_L 을 재서 60Ω 근처면 정상
"Bus Off 가 뭔가"
→ 오류 카운터가 256 을 넘으면 스스로 버스에서 빠진다
→ 고장난 노드가 버스를 망치는 것을 막는 안전 장치
SPI 와 I²C 의 구분
SPI 선 4개 + 슬레이브당 CS · 수십 MHz · 전이중 · ACK 없다
CPOL/CPHA 4가지 모드 — 틀리면 값이 밀려 나온다
I²C 선 2개 · 주소로 구분 · ACK 있다
오픈드레인 + 풀업이 필수 — 없으면 통신이 시작조차 안 된다
"I2C 에서 풀업이 왜 필요한가"
→ 오픈드레인이라 HIGH 를 만들 수 없다. 풀업이 올려 준다
→ 그 덕분에 여러 장치가 한 선을 공유해도 단락이 안 난다 (와이어드 AND)
"SPI 모드를 틀리면 어떻게 되나"
→ 통신이 안 되는 게 아니라 값이 한 비트 밀려 나온다. 그래서 진단이 어렵다
Python — 어디에 쓰나
제품에 들어가지 않는다. 개발 도구로 쓴다.
테스트 자동화 HIL 테스트 러너 · 회귀 시험
CAN 로그 분석 python-can 으로 캡처·재생·파싱
데이터 처리 센서 로그를 모아 통계·시각화
스크립트 플래시 굽기 · 빌드 · 보고서 생성
# CAN 로그를 다루는 전형적인 코드
import can
bus = can.interface.Bus(channel='can0', bustype='socketcan')
for msg in bus:
if msg.arbitration_id == 0x123:
distance_cm = int.from_bytes(msg.data[0:2], 'big')
"센서 값이 가끔 튄다" 를 조사할 때 이런 스크립트를 쓴다. 수만 개 프레임을 눈으로 볼 수는 없다.
ROS — 왜 자동차에 나오나
양산 차량에는 안 들어간다. ROS 는 결정적 실시간성을 보장하지 않아 안전 시스템에 못 쓴다.
그런데 R&D 에서는 널리 쓴다.
프로토타이핑 알고리즘을 빨리 만들어 붙여 본다
데이터 수집·재생 rosbag 으로 주행 데이터를 녹화하고 반복 재생
시각화 rviz 로 점군·물체·경로를 눈으로 확인
모듈 분리 노드 단위로 나눠 개별 개발·교체
"실차에서 한 번 녹화해 사무실에서 백 번 돌린다" 가 ROS 를 쓰는 가장 큰 이유다. 알고리즘을 고칠 때마다 차를 몰고 나갈 수는 없다.
개념만 알아 두면 되는 것
노드 · 토픽 · 퍼블리시/서브스크라이브 (발행-구독 모델)
메시지 타입 · TF(좌표 변환) · rosbag · rviz
ROS 1 과 ROS 2 의 차이 (ROS 2 는 DDS 기반, 실시간성 개선)
임베디드 지원자가 ROS 를 깊이 알 필요는 없다. 다만 "프로토타이핑과 데이터 재생에 쓰는 미들웨어" 라고 답할 수 있으면 개발 흐름을 이해한 것으로 보인다.
MATLAB / Simulink — 모델 기반 설계
전통적 흐름 요구사항 → 사람이 C 코드 작성 → 시험
모델 기반 설계 요구사항 → Simulink 모델 → 시뮬레이션 검증 → 자동 코드 생성
알고리즘을 코드가 아니라 모델로 만드는 방식이다. 자동차 업계에서 널리 쓰인다.
왜 쓰나
① 시뮬레이션으로 먼저 검증한다 — 차를 몰기 전에
② 모델에서 C 코드를 자동 생성한다 — 손으로 옮기며 생기는 실수를 없앤다
③ 같은 모델을 ROS 프로토타입과 AUTOSAR 양산 타깃에 모두 배포할 수 있다
④ 요구사항 → 모델 → 코드 → 시험의 추적성이 만들어진다 (A-SPICE 요구)
④가 자동차에서 특히 중요하다. ISO 26262·A-SPICE 가 추적성을 요구하는데, 모델 기반 설계가 그 요구에 잘 맞는다.
ADAS 에서 실제로 쓰는 곳
센서 모델링 초음파·레이더의 동작을 시뮬레이션
제어 알고리즘 조향·속도 제어 로직
센서 퓨전 알고리즘
HIL 테스트 모델을 실시간 하드웨어에 올려 실제 ECU 와 연결
임베디드 지원자에게 요구되는 것은 "이런 흐름이 있다" 는 이해 정도다. 모델을 직접 만드는 것은 알고리즘 팀의 일이지만, 생성된 코드를 MCU 에 통합하는 것은 임베디드 몫이라 접점이 있다.
AUTOSAR — "해당시" 지만 알아 두면
Classic Platform ECU 용 · 정적 구성 · 실시간 · C
Application Layer
RTE (Runtime Environment)
BSW ─ OS · 통신 스택 · 진단 · 메모리 관리
Adaptive Platform 고성능 컴퓨팅용 · 동적 · POSIX · C++
핵심은 "애플리케이션이 하드웨어를 직접 만지지 않게 계층을 나눈다" 는 것이다.
왜 필요한가
완성차 업체가 여러 부품사의 소프트웨어를 조립해야 한다
→ 인터페이스가 표준화돼 있지 않으면 조립이 안 된다
→ 그래서 업계가 공통 아키텍처를 정했다
한 줄로 답할 수 있으면 충분하다. "애플리케이션과 하드웨어를 분리하는 표준 계층 구조이고, ECU 용 Classic 과 고성능용 Adaptive 가 있다."
ISO 26262 · Functional Safety — 자동차의 차이
공고가 교육 이수 예시로 이것을 들었다. 자동차 임베디드가 일반 임베디드와 다른 지점이라 그렇다.
ASIL A < B < C < D 위험도에 따른 안전 무결성 등급
ASIL D 브레이크·조향 — 고장이 치명적
ASIL B 주차 보조 센서 정도
QM 안전과 무관 (일반 품질 관리로 충분)
"고장이 나도 안전한 상태로 간다" 를 문서로 증명하는 체계다.
실무에서 요구하는 것
진단 커버리지 SRAM 검사 · Flash CRC · 이중화 · 값 범위 확인
안전 상태 전이 이상이 감지되면 정지·차단 등 정해진 상태로
문서화 "이런 고장을 이런 방법으로 이만큼 검출한다"
앞서 본 임베디드 관행이 여기서 요구사항으로 굳는다.
워치독을 '모든 작업이 돌았음을 확인한 뒤에만' 먹인다
센서가 가려진 것을 스스로 감지한다 (블로키지 감지)
통신이 끊기면 마지막 값을 유지하지 않고 안전 상태로 간다
이 연결을 말할 수 있으면 차별화된다 — 규격 이름을 아는 것보다 "왜 그렇게 코드를 쓰는가" 로 이으면 실무 감각이 보인다.
관련해 ISO 21448(SOTIF) 도 있다 — 고장이 없어도 성능 한계로 위험할 수 있다는 것(센서가 정상인데 안개 때문에 못 보는 경우). ADAS 에 특히 중요하다.
영어 — 왜 중요 요소인가
"어학 능력 (특히 영어) ※가산점※"
"면접은 ... C언어 활용과 영어능력이 중요 요소"
가산점이라 적어 놓고 면접 중요 요소로 다시 언급했다. 발레오는 프랑스 본사이고, R&D 는 본사·타 지역 거점과 계속 협업한다. 문서·회의·코드 리뷰가 영어로 오간다.
실제로 필요한 것
읽기 데이터시트 · 레퍼런스 매뉴얼 · 규격 문서 — 전부 영문이다
쓰기 이슈·설계 문서·코드 주석
듣기·말하기 화상 회의 · 기술 논의
읽기가 가장 실용적이다. MCU 레퍼런스 매뉴얼이 1,700쪽 영문인데 그것을 읽어야 일이 된다.
공인 점수가 없으면 서술식으로 쓸 수 있다 (공고가 허용)
✗ "영어 회화 가능"
✓ "영문 기술 문서(데이터시트·레퍼런스 매뉴얼·man page)를 사전 없이 읽습니다.
기술 주제에 대해 영어로 설명·질의응답이 가능하며,
(구체적 학습 계획) 을 진행 중입니다."
면접 대비로 둘만 준비한다.
① 자기소개 1분 배경 · 해 온 것 · 왜 이 자리
② 프로젝트 설명 3분 가장 자신 있는 것 하나를 영어로
완벽한 문장보다 끊기지 않는 것이 중요하다. 모르는 단어에서 막힐 때 쓸 표현("Let me rephrase that")을 하나 준비해 두면 당황하지 않는다.
우선순위와 학습 순서
시간이 한정돼 있으면 이 순서로 한다.
1주차 C 를 임베디드 관점으로 다시 본다
volatile · 고정폭 정수 · 구조체 패딩 · 비트 조작 · 정적 할당
→ 임베디드 C 함정 · 비트 조작 편
2주차 보드로 직접 해 본다 (Nucleo/Discovery 2~3만 원)
LED(레지스터 직접) → 버튼 디바운싱 → UART → 타이머 1ms → PWM → ADC
→ MCU란 · GPIO · 인터럽트 · 타이머·PWM · ADC 편
3주차 통신과 디버깅
I2C 센서 붙이기 · 링 버퍼 + UART 인터럽트 수신
일부러 HardFault 를 내고 CFSR 로 원인 찾기 ★ 면접에서 쓸 이야기
CAN 개념 정리 (중재 · 종단 · Bus Off)
→ I²C · CAN · 폴트 해독 편
여유 있으면
RTOS 개념 (우선순위 역전까지)
ISO 26262 · AUTOSAR 한 줄 답변 준비
영어 자기소개·프로젝트 설명 소리 내어 연습
2·3주차의 실습이 "임베디드 경험자 유리함" 에 대한 답이 된다. 학교 수업이나 책으로만 본 것과, 보드에서 안 돌아가는 이유를 찾아본 것은 면접에서 바로 갈린다.
특히 HardFault 를 일부러 내 보는 것을 권한다.
*(volatile uint32_t*)0 = 1; // 널 포인터 쓰기
*(volatile uint32_t*)0x20000001 = 1; // 정렬 위반
((void(*)(void))0x20000000)(); // 잘못된 함수 포인터
CFSR 비트를 읽어 원인을 맞혀 보면, "디버깅을 어떻게 하나" 라는 질문에 구체적으로 답할 수 있다.
한눈에 정리
- 공고의 여덟 항목이 같은 무게가 아니다 — C 와 영어만 두 번 언급됐고, 나머지는 "등"·"해당시"
- 근무지가 R&D 라서 목록이 넓다 — 조직이 그 범위를 다루는 것이고 한 사람이 다 하는 게 아니다
- C 가 핵심인 이유는 선택지가 없어서다 — 센서는 MCU 에서 OS 없이 돌고, 레지스터를 포인터로 다룬다
volatile은 거의 확실히 나온다. 링 버퍼와 비트 조작은 백지에 쓸 수 있어야 한다- 임베디드 C++ 는 예외·RTTI·동적 할당을 금지한다 — 일반 C++ 와 다르다
- Embedded Linux 가 목록에 있는 이유 — 센서는 MCU, 컴퓨팅 유닛은 SoC + 리눅스다
- CAN 이 셋 중 가장 중요하다. "비파괴 중재라 최악 지연 계산이 가능하다" 까지가 좋은 답
- Python 은 제품이 아니라 도구 — 테스트 자동화·CAN 로그 분석
- ROS 는 양산에 안 들어간다 — 프로토타이핑과 데이터 재생용 미들웨어
- Simulink 는 모델 기반 설계 — 자동 코드 생성과 추적성이 자동차에서 중요한 이유
- AUTOSAR 는 한 줄로 답하면 충분 — 애플리케이션과 하드웨어를 분리하는 표준 계층
- ISO 26262 는 "증명" — 임베디드 관행이 요구사항으로 굳은 것. 코드 습관으로 이으면 차별화된다
- 영어는 읽기가 가장 실용적 — 레퍼런스 매뉴얼이 1,700쪽 영문이다
- 3주면 보드로 9개를 해 볼 수 있다. 그것이 "경험자 유리함" 에 대한 답이 된다
회사·기술 배경은 대구 사업 · ADAS · 센서 기술 · 자율주차 편에, 학습 순서 전체는 공부할 것 편에 있다.
공고의 제출 기한·일정은 반드시 원문을 다시 확인할 것.