42dot 모의 면접

진행 상태

#	주제	상태
1	BLE+UWB 디지털 키 시스템 설계	완료
2	가장 어려웠던 기술적 문제	완료
3	NFC fallback / 릴레이 어택 방어	완료 (Q1에 포함)
4	42dot 제품/기술 리서치 (TAP, AKit, 디지털 키)	완료
5	42dot Way 사례 매핑 (Agility, Cross-Team)	완료
6	지원 동기 / 하고 싶은 것 / 5년 후 방향	완료
7	1분 자기소개	완료

---

1분 자기소개 (~50초)

안녕하세요 저는 로봇과 스마트 가구 분야에서 IoT 시스템을 만들어왔습니다. Firmware, 유무선 통신, 리눅스, 클라우드 모니터링까지 넓은 영역에서 성장해 왔고, 이를 바탕으로 프로토타입을 빠르게 만들기도 하며, 양산까지 담당했습니다.

이러한 경험을 더 높은 안정성과 큰 스케일을 요구하는 자동차 분야에서 발휘하고 성장하고 싶어 지원하게 되었습니다.

---

Part 2. 42dot 리서치 + 컬처핏 준비

1. 42dot 제품/기술 리서치

TAP (T Autonomous Platform)

• 자율주행 모빌리티 서비스 플랫폼. 호출 → 탑승 → 하차까지의 라이드헤일링 + 차량 관제(FMS)
• 2022년 2월 상암동 런칭 → 청계천, 청와대, 여의도, 용인으로 확대
• 한국 최초 유상 자율주행 운송 면허 취득
• AWS CDK 기반 FMS, 멀티 오퍼레이터 통합 (서울시 공식 자율주행 교통 플랫폼)
• SDV 3축 전략 중 “Software-Defined Fleet” 담당

AKit (Autonomous Kit)

• 자율주행 풀스택 HW+SW 솔루션

구성요소	설명
AKit Core	인지-예측-판단-제어 AI 소프트웨어
AKit NCU	자율주행 연산 하드웨어 (Neural Computing Unit)
AKit OS	자율주행 스택 운영체제
AI Accelerator	전용 NPU (400 TOPS급)
SDx Map	경량 자율주행 맵 (HD맵 불필요)

• 센서 철학: 창립 때부터 LiDAR-free. 카메라 8대 + 레이더 1대 (테슬라와 동일 방향)
• Atria AI: E2E 딥러닝. 센서 raw 데이터 → 주행 명령을 단일 신경망으로 변환
• 내부 자체 평가 25/100 (테슬라 FSD 90, 화웨이 70, 모빌아이 50) — 격차를 솔직히 인정하는 문화

디지털 키 & 블록체인

• 42dot의 디지털 키 관여는 블록체인/ZKP 레이어
  • zk-SNARK 기반 프라이버시 보존 인증 (비밀키 노출 없이 차량 권한 증명)
  • 차량 ID 관리, 차폐형 모빌리티 결제, OTA 데이터 무결성
• 기존 현대 디지털 키 1(NFC)/2(UWB)와는 별개 — 42dot은 SDV 시대 차세대 키 인프라 담당
• 면접 연결: Q1에서 다뤘던 BLE+UWB 디지털 키의 상위 보안 레이어

SDV 전략 내 42dot 위치

• 현대차그룹 Global Software Center — SDV 소프트웨어 전체 총괄
• 핵심 산출물: Pleos Vehicle OS (Rust 기반), Atria AI, Pleos Connect (인포테인먼트), TAP!
• HW 파트너: 삼성 Exynos Auto SoC, NVIDIA Blackwell GPU 5만대 AI 팩토리
• 투자: 5,003억 원 유상증자 (2025.08), 2026-2030 한국 투자 50.5조 원

최근 동향 (2025-2026)

• CEO 교체: 송창현 사임 (2025.12) → 박민우 취임 (2026.01)
  • 전 Tesla Autopilot 리더 (Tesla Vision 최초 릴리스), 전 NVIDIA VP
  • “L2++/L3 양산 소프트웨어 + 확장 가능한 검증에 집중”
• 연구 → 양산 실행으로 전략 전환. 테슬라 FSD 한국 진출 임박이 긴급성의 배경

---

2. 42dot Way 사례 매핑

핵심 가치별 내 경험

가치	42dot 원문	내 사례
Impact-Driven	시장을 바꿀 실질적 변화에 집중	Ceily/Wally: 1인 개발로 양산 제품 2개 출시. 펌웨어→클라우드→CI/CD 전 스택 직접 구축
Agile + Grit	완벽보다 빠른 완성, 끝없는 끈기	Wally v1→v2: ESP32 단독 → RPi5+STM32 분산 구조 마이그레이션. 안 되면 구조 자체를 바꿔서 해결
Cross-Team	팀이 없는 것처럼 협업	Bear: CAN-over-UDP 리디자인. 펌웨어 4-6개 → 1개 유니버설 통합. 펌웨어팀/ROS팀 관심사 분리하면서 연결
Responsible Leadership	디테일을 알고 질문한다	HW 회로부터 클라우드까지 전 디테일 파악. 원격 텔레메트리로 고객 현장 마찰 문제 원격 진단
Open Communication	투명한 정보 공유	K8s Reconciler 패턴을 임베디드에 적용 제안 → 흩어진 retry 로직 제거. 기존 문제를 투명하게 지적

Leadership Principles 매핑

원칙	내 사례
역량이 기본	ESP32, STM32, ROS2, AWS IoT, CI/CD — 도메인을 넘나드는 풀스택 역량
자기 동기 문제 해결	충돌 감지: commanded value 기반 토크 예측 인사이트를 독자적으로 발견
팀 플레이어	CAN-over-UDP로 펌웨어/ROS 양쪽 유지보수 부담 동시 해결
빠른 완성 > 완벽	Modbus 직접 구현: 필요한 FC만 구현, ROM/RAM 92% 절감
반대하되 합류	아키텍처 전환 제안 시 트레이드오프 명시, 결정 후 전력 실행

---

3. 지원 동기 / 하고 싶은 것 / 5년 후

지원 동기

임베디드 시스템으로 물리 세계를 제어하는 일을 해왔다. Rovothome에서 가구, Bear에서 배달 로봇. 다음은 자동차다.

42dot이 흥미로운 이유 세 가지:

1. SDV 풀스택: HW(NCU/SoC) + OS(Rust) + 자율주행(Atria AI) + 플랫폼(TAP!)까지 수직 통합. 내가 해온 ‘펌웨어→클라우드 풀스택 소유’ 방식과 같은 구조
2. 양산 전환기: 2027 양산 목표로 실행에 집중하는 시점. 양산 품질 펌웨어/시스템을 만들어온 경험이 직접 기여할 수 있는 타이밍
3. 디지털 키/IoT: BLE+UWB 디지털 키, 차량 블록체인 인증. Rovothome에서 BLE/WiFi 디바이스 보안(Secure Boot, Flash Encryption)을 다뤘던 영역

입사 후 하고 싶은 것

IoT Software & Firmware 포지션에서:

• 차량 연결 디바이스 펌웨어: 디지털 키 모듈, 차량 내 IoT 컨트롤러 등 임베디드 소프트웨어
• OTA 시스템: CAN 부트로더 OTA를 Bear에서 직접 구현한 경험. 차량 규모 안전 OTA 파이프라인에 기여
• 디바이스 프로비저닝 & 보안: 6단계 멱등성 프로비저닝(eFuse 포함), 0건 브릭. 차량 양산 프로비저닝에 적용

5년 후 방향

SDV 시대 차량은 수십 개 ECU → 중앙 컴퓨터 + 존 컨트롤러 구조로 전환된다. 5년 후:

• 차량 IoT 시스템 아키텍트: 개별 디바이스 펌웨어를 넘어, 커넥티드 디바이스 전체의 통신/보안/업데이트 아키텍처 설계
• Bear에서 로봇 6종 펌웨어를 1개로 통합한 것처럼, 차량 IoT 디바이스의 SW 플랫폼화 주도
• 42dot SDV OS(Rust) + 블록체인 보안 위에서 IoT 디바이스 레이어 표준을 만드는 역할

---

Part 1. 모의 면접 결과

Q1. BLE+UWB 디지털 키 시스템 설계

점수: B

잘한 점:

• BLE 연결 → 상호 인증 → UWB 거리 측정의 큰 흐름을 정확하게 설명
• 공개키 기반 챌린지-리스폰스 인증 과정을 구체적으로 설명 (서버에서 키 배포 → 챌린지 → 개인키 서명 → 공개키 검증)
• NFC fallback을 즉시 답변, 이유(사용성)도 명확

보완할 점:

• Zone 판단: 거리 기반 Zone 분리(Far/Near/Inside/Away) 개념을 몰랐음. 면접에서 “거리 기준으로 Zone을 나누고, 앵커 다수의 삼각측위로 inside/outside를 구분할 것 같습니다” 정도로 답변 필요
• 릴레이 어택: 개념 자체를 몰랐음. 핵심만 기억할 것 — “BLE 신호를 중계해서 거리를 속이는 공격, UWB ToF의 물리적 왕복 시간으로 방어”
• UWB 앵커 배치/역할에 대한 이해가 부족했음. 최소 개념: 외부 앵커(접근 감지) + 내부 앵커(탑승 판단)

Q2. 가장 어려웠던 기술적 문제

점수: A-

잘한 점:

• 문제 정의가 명확: 움직이는 가구에서 모터 토크 기반 충돌 감지
• 핵심 인사이트를 정확히 설명: 실측값이 아닌 명령값(commanded velocity/accel)을 입력으로 써야 한다는 발견
• 구간별 입력 변수 차별화의 이유를 물리적으로 설명 (마찰 영향, 동역학과 다른 실제 거동)
• 구간별 변수 구체적: 가속(속도/가속도/저크), 등속(속도/시간), 감속(마지막 토크/시간)
• 검증 방법 제시: 100회 반복 테스트 + 원격 모니터링 이벤트 확인

보완할 점:

• 답변 구조를 “문제 → 시도 → 실패 이유 → 해결 → 결과” 순서로 더 명확하게 정리하면 좋겠음
• 첫 답변이 너무 추상적이었음. 면접에서는 처음부터 “토크 잔차 기반 충돌 감지인데, 예상 토크 모델링이 핵심 난제였습니다” 정도로 구체적으로 시작할 것
• 오탐률 수치(“0%에 가까움” 등)를 바로 말하면 임팩트가 커짐

---

예상 기술 질문 & 답변

디지털 키 / BLE+UWB

Q1. BLE와 UWB를 왜 함께 쓰는가? 하나만 쓰면 안 되나?

BLE는 저전력으로 상시 브로드캐스팅이 가능해 차량 접근을 감지(wake-up)하는 데 적합하지만, RSSI 기반 거리 추정은 ±2~3m 오차가 있어 정밀 위치 판단이 불가능하다. UWB는 ToF 기반으로 ±10cm 정밀도를 제공하지만 전력 소모가 크다. BLE로 접근을 감지해 UWB를 깨우고, UWB로 정밀 거리 측정 후 Zone(Far/Near/Inside)을 판단하는 구조가 전력과 정밀도를 모두 만족한다.

Q2. UWB의 DS-TWR(Double-Sided Two-Way Ranging)이 SS-TWR보다 나은 이유는?

SS-TWR은 응답 측 클럭 오차가 거리 오차에 직접 반영된다. DS-TWR은 양쪽에서 왕복 시간을 측정해 클럭 드리프트를 상쇄한다. 수식상 ToF = (T_round1 × T_round2 - T_reply1 × T_reply2) / (T_round1 + T_round2 + T_reply1 + T_reply2) 형태로, 양측 클럭 비율이 약분되어 소거된다.

Q3. 릴레이 어택이란? UWB는 어떻게 방어하나?

공격자 2명이 각각 차량과 키 옆에서 BLE 신호를 중계하면, 키가 멀리 있어도 차량이 “가까이 있다”고 판단한다. UWB는 물리적 전파 왕복 시간(ToF)을 측정하므로, 중계 장비를 거치면 수 ns~μs의 지연이 추가되어 거리가 비정상적으로 길게 계산된다. 추가로 STS(Scrambled Timestamp Sequence) 암호화를 적용하면 중계기가 타이밍을 조작할 수 없다.

Q4. 디지털 키에서 상호 인증 과정을 설명하라.

1. 서버에서 차량 공개키를 스마트폰에, 스마트폰 공개키를 차량에 사전 배포
2. BLE 연결 후, 차량이 랜덤 챌린지 생성 → 스마트폰에 전송
3. 스마트폰이 자신의 개인키로 챌린지를 ECDSA 서명 → 차량에 전송
4. 차량이 스마트폰 공개키로 서명 검증 → 스마트폰 인증 완료
5. 역방향도 동일하게 수행 → 차량 인증 완료
6. 양측 인증 완료 후 UWB 세션 키 교환 → 거리 측정 시작

Q5. NFC fallback은 왜 필요하고, 보안상 문제는 없는가?

스마트폰 배터리가 방전되면 BLE/UWB가 작동하지 않는다. NFC는 리더기의 전자기장에서 에너지를 공급받아 배터리 없이 동작한다. 통신 거리가 ~4cm로 매우 짧아 릴레이 어택 위험이 낮고, Secure Element에 저장된 키로 인증하므로 OS 레벨 공격에도 키가 노출되지 않는다.

Q6. Zone 판단은 어떻게 하나? (Far/Near/Inside/Away)

차량 외부/내부에 UWB 앵커를 배치한다. 외부 앵커(도어 핸들 근처)는 접근 감지, 내부 앵커(실내)는 탑승 판단에 사용한다. 거리 임계값으로 Far(>3m), Near(<1.5m) 등을 구분하고, 다수 앵커의 거리 데이터를 삼각측위해 inside/outside를 판단한다. Inside 판단 시 시동 허용, Away 전환 시 자동 잠금을 수행한다.

임베디드 시스템 / RTOS

Q7. FreeRTOS에서 mutex와 binary semaphore의 차이는?

Binary semaphore는 단순 신호 전달 용도로, 누구나 give/take 할 수 있다. Mutex는 소유권 개념이 있어 take한 태스크만 give할 수 있고, priority inheritance를 지원한다. 공유 자원 보호에는 mutex를 써야 priority inversion 문제를 방지할 수 있다. ISR에서는 mutex를 쓸 수 없고 binary semaphore를 써야 한다.

Q8. ESP32-S3에서 WiFi와 BLE를 동시에 쓸 때 어떤 문제가 생기나?

ESP32-S3는 2.4GHz 라디오를 하나 공유하므로, WiFi TX/RX 중 BLE 이벤트가 밀리거나 그 반대가 발생한다. 코어 내부 중재기(coexistence arbiter)가 시분할로 처리하지만, WiFi 대량 전송 시 BLE connection interval을 놓쳐 연결이 끊길 수 있다. 해결: BLE connection interval을 넓히고(예: 100ms), WiFi 전송을 burst가 아닌 주기적 소량 전송으로 분산시킨다. MQTT keepalive를 길게 잡고, BLE 이벤트 우선순위를 조정한다.

Q9. Secure Boot V2와 Flash Encryption을 함께 적용하는 이유는?

Secure Boot V2는 부트로더와 앱 이미지의 서명을 검증해 변조된 펌웨어 실행을 방지한다. Flash Encryption은 플래시 내용을 XTS-AES-256으로 암호화해 물리적 덤프로 코드/데이터를 읽을 수 없게 한다. 둘 다 eFuse에 키를 굽는 비가역 과정이고, 하나만 적용하면 서명 없는 암호화(코드 주입 가능) 또는 서명만 있는 평문(IP 유출 가능) 상태가 된다.

Q10. CAN 부트로더를 설계할 때 핵심 고려사항은?

1. CAN 프레임은 최대 8바이트이므로 펌웨어 바이너리를 블록 단위로 분할 전송한다
2. 블록마다 Stop-and-Wait ACK로 수신 확인 → 유실 시 재전송
3. 전체 수신 후 CRC/해시 검증 → 실패 시 기존 파티션 유지(롤백)
4. 듀얼 파티션 구조: 새 이미지를 백업 슬롯에 쓰고, 검증 통과 후 부트 플래그 전환
5. 전원 차단 대비: 쓰기 중 전원이 꺼져도 기존 파티션이 유효해야 한다(atomic swap)

통신 프로토콜

Q11. BLE GATT에서 Notification과 Indication의 차이는?

Notification은 서버가 클라이언트에 데이터를 보내되 ACK를 받지 않는다. 빠르지만 전송 보장이 없다. Indication은 클라이언트가 Confirmation을 보내야 다음 전송이 가능하다. 신뢰성이 필요한 인증 데이터에는 Indication, 센서 스트리밍에는 Notification이 적합하다.

Q12. MQTT QoS 0/1/2의 차이와 IoT에서 적절한 선택은?

• QoS 0: 최대 1회 전송(fire-and-forget), 손실 가능
• QoS 1: 최소 1회 전달 보장, 중복 가능 (PUBACK)
• QoS 2: 정확히 1회 전달 (4-way handshake), 오버헤드 큼

텔레메트리(센서 데이터)는 QoS 1이 적합하다. 간혹 중복되어도 타임스탬프로 구분 가능하고, 손실은 방지해야 한다. 명령/제어(도어 잠금 등)는 QoS 2가 이상적이지만, 실무에서는 QoS 1 + 앱 레벨 중복 제거(idempotent 설계)를 많이 쓴다.

Q13. Modbus RTU 직접 구현 경험에서 ESP-Modbus 대비 92% ROM/RAM 절감을 어떻게 달성했나?

ESP-Modbus는 범용 라이브러리로 master/slave 양쪽, 다수 function code, 파라미터 테이블 추상화 등을 모두 포함한다. 실제 필요한 건 slave 모드 + FC03(Read Holding Registers), FC06(Write Single Register) 정도였다. 필요한 function code만 구현하고, 파라미터 테이블 대신 직접 레지스터 맵을 배열로 관리하고, FreeRTOS 태스크 대신 이벤트 루프에서 폴링 처리해 불필요한 스택/힙 할당을 제거했다.

보안 / 암호

Q14. ECDSA와 RSA의 차이는? 왜 IoT에서 ECDSA를 쓰나?

동일 보안 수준(128-bit security)에서 RSA는 3072-bit 키, ECDSA(P-256)는 256-bit 키를 사용한다. 키 크기가 ~12배 작아 저장 공간, 전송 대역폭, 연산 속도 모두 유리하다. MCU의 제한된 RAM/ROM에서 RSA 키 저장과 모듈러 지수 연산은 부담이 크다. 서명 크기도 RSA 384바이트 vs ECDSA 64바이트로, BLE MTU(최대 247바이트) 내에서 전송 가능하다.

Q15. X.509 인증서 체인에서 루트 CA, 중간 CA, 디바이스 인증서의 역할은?

• 루트 CA: 신뢰 앵커. 디바이스에 사전 설치. 자체 서명
• 중간 CA: 루트가 서명. 실제 디바이스 인증서 발급을 담당. 루트 키 노출 위험 분리
• 디바이스 인증서: 중간 CA가 서명. 디바이스의 공개키를 포함

TLS 핸드셰이크 시 디바이스가 자신의 인증서 + 중간 CA 인증서를 보내면, 서버가 루트 CA까지 체인을 검증한다. 중간 CA가 탈취되면 해당 CA만 폐기(CRL/OCSP)하면 되어, 루트를 직접 노출시키지 않는다.

모터 제어 / 충돌 감지

Q16. 토크 잔차 기반 충돌 감지의 원리를 설명하라.

모터에 명령을 내리면 ‘예상 토크’가 있고, 실제 측정 토크가 있다. 이 차이(잔차)가 임계값을 넘으면 외부 충돌로 판단한다. 핵심 난제는 예상 토크 모델링이다. 이론적 동역학 모델(F=ma + 마찰)은 실제 기구의 비선형 마찰, 백래시, 케이블 장력 등을 반영하지 못한다. 그래서 실측 데이터 기반 회귀 모델을 구간별(가속/등속/감속)로 나눠 학습시켰다. 입력 변수도 구간마다 다르다: 가속 구간은 속도/가속도/저크, 등속은 속도/경과시간, 감속은 마지막 토크/경과시간.

Q17. 왜 실측 속도가 아닌 명령값(commanded velocity)을 모델 입력으로 썼나?

실측 속도는 모터 제어기의 PID 보상이 이미 반영된 값이다. 충돌이 발생하면 부하가 증가하고, PID가 이를 보상하려 전류를 높이며, 실측 속도는 거의 변하지 않는다. 즉 실측값은 충돌 정보를 이미 “흡수”한 상태라 잔차가 작아진다. 명령값은 충돌과 무관하게 프로파일대로 나오므로, “충돌 없는 정상 상태”를 더 정확하게 표현한다.

시스템 설계 / 아키텍처

Q18. 단일 MCU에서 RPi5+STM32 분산 구조로 마이그레이션한 이유와 UART 동기화 방식은?

단일 ESP32로 WiFi/BLE/모터제어/센서/클라우드를 모두 처리하면, 무선 통신 지연이 모터 제어 실시간성을 해치고, 하나의 태스크 장애가 전체에 전파된다. RPi5(Linux)에서 네트워크/클라우드/UI를, STM32에서 실시간 모터 제어를 분리했다. UART로 명령/상태를 주고받되, 고정 길이 프레임 + 헤더 + CRC로 구조화한다. RPi→STM32: 모션 명령, STM32→RPi: 상태/이벤트. 타임아웃 시 STM32가 독립적으로 안전 정지(fail-safe)한다.

Q19. OTA 업데이트에서 “벽돌(brick) 방지”를 위한 설계는?

1. 듀얼 파티션(A/B): 새 이미지를 비활성 슬롯에 쓰고, 부트로더가 슬롯 전환
2. 다단계 검증: 다운로드 후 CRC → 서명 검증 → 부팅 후 self-test
3. 롤백: 새 이미지 부팅 후 self-test 실패 시 자동으로 이전 슬롯 복귀
4. 쓰기 중 전원 차단 대비: 부트 플래그를 마지막에 atomic하게 전환, 플래그 전환 전까지는 이전 이미지가 유효
5. Idempotent 설계: 같은 OTA 요청을 여러 번 보내도 안전

Q20. 42dot 차량 IoT 시스템에서 Edge(차량) vs Cloud 간 역할 분리를 어떻게 설계하겠는가?

Edge(차량 ECU)에서 처리해야 할 것:

• 디지털 키 인증/인가 (지연 불가, 오프라인 동작 필수)
• UWB 거리 측정 및 Zone 판단 (실시간, <100ms)
• 충돌 감지/비상 정지 (안전 관련, 네트워크 불가 시에도 동작)

Cloud에서 처리해야 할 것:

• 키 권한 관리 (등록/폐기/공유)
• 텔레메트리 수집/분석 (배터리, 센서 이력)
• OTA 펌웨어 배포/버전 관리
• 차량 간 정책 동기화

원칙: 안전/실시간/오프라인 필수 기능은 Edge, 관리/분석/배포는 Cloud. 키 폐기처럼 양쪽이 걸리는 경우, Cloud에서 폐기 명령 → Edge가 다음 연결 시 동기화하되, 동기화 전까지는 Edge의 로컬 키 목록 기준으로 동작한다.