자동차 속도 기반 IoT 장식 만들기 02 - 하드웨어 스펙 설계

🔬 하드웨어 결정은 "감"이 아니라 "Trade Study"로

이 프로젝트에서 처음 시도한 방법론이 있습니다. Trade Study입니다.

NASA와 INCOSE 시스템 엔지니어링 핸드북에서 쓰이는 의사결정 방법론으로, 핵심 원리는 단순합니다:

1. 평가 기준을 먼저 정한다 — 부품을 보기 전에 "무엇이 중요한가"를 숫자로
2. 가중치가 결론을 만든다 — 같은 부품도 프로젝트 상황에 따라 정답이 달라진다
3. 근거를 문서로 남긴다 — "왜 이걸 골랐는가"를 나중에 설명할 수 있어야 한다

이하 모든 결정은 이 방식으로 점수를 매긴 결과입니다. 직관이 아닌 데이터로 결정했고, 나중에 다시 검토할 때 "왜 이렇게 됐는지"를 추적할 수 있습니다.

 

 

① MCU 선택 — ESP32 vs Raspberry Pi

교수님은 컴퓨팅 파워를 이유로 Raspberry Pi를 제안하셨습니다. 실제로 세 가지 전략을 비교했습니다.

전략	프로토타입	양산	코드 재작성
A+: ESP32 일관	ESP32-WROVER DevKit	ESP32 커스텀 PCB	0%
B: RPi → ESP32	Raspberry Pi 4 (Python)	ESP32 커스텀 PCB	~90% 재작성
C: RPi → CM4	Raspberry Pi 4 (Python)	RPi CM4 커스텀 PCB	~10% 재작성

가중치 기준으로 가장 높게 설정한 두 가지는 "1~2개월 데드라인"(가중치 5)과 "$50 소매가"(가중치 4)였습니다.

• B 전략 탈락 이유: 프로토타입에서 Python/pygame으로 만든 화려한 애니메이션을 양산 ESP32에서 C++로 완전 재작성해야 합니다. 코드 재사용율 10~30%, 사업화 일정에 치명적입니다.
• C 전략 탈락 이유: RPi CM4 모듈만 $25~45. 여기에 디스플레이·PCB·케이스·조립비를 더하면 BOM이 $50 소매가를 초과합니다. 사업 자체가 불가능해집니다.
• A+ 전략 선택 이유: 프로토타입 코드가 그대로 양산 코드가 됩니다. 전환 비용 0. 종합 점수 104/120 (86.7%) 1위.

 

 

WROOM → WROVER: 숨겨진 메모리 함정

ESP32로 방향을 정하고 나서 예상치 못한 문제가 나왔습니다.

TFT_eSPI의 스프라이트 더블버퍼를 쓰려면 240×320 해상도 기준으로 153KB가 필요합니다. ESP32-WROOM의 DRAM은 320KB인데, 여기서 WiFi 스택 ~40KB, WebServer ~10KB를 빼면 스프라이트 버퍼를 올릴 여유가 없습니다.

해결책은 ESP32-WROVER-E-N16R8로 교체하는 것이었습니다. WROOM과 핀/코드가 100% 호환되지만 8MB PSRAM이 추가됩니다. 단가는 $1~2 차이. 개발 중 실제 메모리 사용량을 측정한 뒤 양산에서 WROOM으로 다운그레이드할 수 있어 "오버스펙으로 시작, 데이터로 결정"하는 전략이 됩니다.

 

 

② 디스플레이 선택 — 2.8" IPS ILI9341

디스플레이 선택의 핵심 제약은 두 가지였습니다:

• 드라이버 IC: ILI9488은 18-bit SPI only — ESP32와 비호환. 반드시 ILI9341 계열이어야 합니다.
• 동작 온도: 차량 대시보드는 여름철 80°C+에 달합니다. -20°C ~ 70°C 이상 스펙이 필수입니다.

크기는 처음에 2.4"로 결정했다가 거치 방식이 바뀌면서 2.8"로 업그레이드했습니다. 프로토타입용 Hosyond B0CMGF4Q68(Amazon Prime 1~2일 배송)과 양산 검증용 BuyDisplay ER-TFT028A2-4(40MHz SPI 검증 대상)를 동시에 주문해, 배송 기간에 PCB 설계를 병행하는 방식을 취했습니다.

 

③ 거치 방식 — 3번의 피벗

이 프로젝트에서 가장 많이 바뀐 결정입니다. Rev A → B → C, 총 세 번 방향이 바뀌었습니다.

Rev A: 송풍구 클립 → 대시보드 VHB 접착

처음에는 당연하게 송풍구 클립을 생각했습니다. 그런데 문제가 있었습니다:

• 차량 모델마다 송풍구 형상이 달라 범용성이 낮습니다
• 디스플레이 크기를 2.8" 이하로 제한합니다
• 에어컨 바람을 차단해 사용자 불만을 유발합니다

또 한 가지 결정적인 발견이 있었습니다. 미국 28개 이상의 주에서 앞유리 부착물이 불법입니다. 캘리포니아(Irvine 기반) CVC §26708은 앞유리에 거치할 수 있는 위치를 하단 모서리 작은 구역으로만 제한합니다. Amazon US 전국 판매 제품으로서 흡착컵 거치는 선택지에서 제외됩니다.

그래서 Rev A에서 대시보드 3M VHB 접착 방식으로 전환했습니다.

Rev B: VHB → 3M Dual Lock SJ3550

VHB 접착을 결정한 뒤, 실제 소비자 피드백에서 문제가 드러났습니다:

"뗄 때마다 드라이어 꺼내야 하는 건 제품 경험으로 받아들이기 어렵다"

3M VHB는 영구 접착입니다. 제거할 때 열풍기 + 낚싯줄 + IPA 잔여물 제거가 필요합니다. Amazon 소비자 제품에서 이건 1-star 리뷰 공장입니다.

그래서 3M Dual Lock SJ3550을 발견했습니다. 버섯 모양 후크가 맞물리는 구조로, VHB 수준의 접착력을 유지하면서 "딸깍" 원터치로 1,000회 이상 재개폐가 가능합니다. 차량 OEM에서도 검증된 방식입니다.

Rev C (현행): Dual Lock → Beanbag + Magnet

Dual Lock을 결정한 다음 날, 다시 피드백이 들어왔습니다:

"Dual Lock도 결국 스티커 아닌가? 차량은 비싼 자산인데, 대시보드에 뭔가 남는 게 싫다"

이 한 마디가 R0 요건을 만들었습니다: "대시보드에 영구 접착제/잔여물 금지".

R0 필터를 적용하자 VHB, Dual Lock, Nano Gel, Microsuction이 전부 탈락했습니다. 최종 결정된 방식이 Beanbag + N45SH 자석 (MagSafe 방식)입니다:

[대시보드] ← 무접촉 (빈백은 얹기만)
[빈백 베이스: 100×80×20mm, ~150g, 바닥 논슬립]
              ⇅ 자력 800~1100 gf
[Carpybara 케이스 바닥: SUS430 강판]

자석 등급이 중요합니다. 일반 N42 자석은 80°C에서 감자(demagnetization)가 시작됩니다. SoCal 여름 대시보드는 80°C+를 넘기 때문에 N45SH (MagSafe 규격, 150°C 안정) 이상을 사용해야 합니다.

결과적으로 거치 방식의 변경이 디스플레이 크기 제약도 해제했습니다 — 송풍구 클립의 제약이 사라지면서 2.8"로 업그레이드할 수 있었습니다.

 

④ OBD2 통신 — ELM327 BT → CAN 직결

프로토타입에서는 ELM327 블루투스 동글(Veepeak VP11)을 사용합니다. 기존 코드 재활용이 가능하고 추가 하드웨어 설계가 불필요합니다.

하지만 양산에서는 NXP TJA1051T/3 CAN 트랜시버를 PCB에 직접 실장하는 방향으로 전환합니다. ELM327은 소량 제품이라 공급 안정성이 낮고, OBD2 응답 레이턴시도 CAN 직결 방식이 유리합니다.

 

⑤ 전원 아키텍처 — 2-stage Buck

차량 OBD2 포트에는 점화 스위치 순간에 Load Dump 서지가 발생합니다. ISO 7637 기준으로 순간 60V+까지 치솟을 수 있습니다.

이에 대응하기 위해 2단 Buck 구조를 채택했습니다:

• Stage 1: TPS54360B — 60V 내압, AEC-Q100 차량 인증 등급 → 서지 흡수
• Stage 2: MP2315GJ-Z → 3.3V 출력, 95% 효율

💰 BOM 원가 요약

부품	파일럿 100개	양산 10K
ESP32-WROVER-E-N16R8	$6.00	$4.50
2.8" IPS TFT ILI9341	$12.00	$4.50
4레이어 PCB (75×90mm)	$6.00	$1.50
PC-ABS 케이스	$15.00	$3.50
Beanbag + N45SH 자석 거치 키트	$5.00	$1.40
SMT 실장 + 조립	$10.00	$2.50
소계 (관세 제외)	~$60	~$21
중국산 25% 관세 포함	~$66~75	~$26~32

소매가 $50 목표는 파일럿 단계에서는 적자이지만, 양산 10K 수준에서 멕시코 EMS (USMCA 무관세) 활용 시 달성 가능합니다.

 

 

🔗 다음 편 예고

3편에서는 소프트웨어 개발 이야기를 다룹니다. WiFi 스택이 올라오자마자 OOM 크래시를 일으키던 메모리 문제를 어떻게 해결했는지, 6마리 캐릭터를 5KB 이하 Flash로 구현한 방법, iOS/Android/Windows를 모두 잡아채는 Captive Portal 구현기를 이야기할 예정입니다.