AI가 짠 펌웨어: 233개 테스트, Sonnet 68% vs Haiku 57%

지난 두 글에서 던진 숫자들이 있다. 35%p 격차, 그리고 DMA, ISR 실패 패턴. 출처는 하나다. EmbedEval이라는 임베디드 펌웨어용 LLM 벤치마크를 직접 만들어 돌린 결과다. 오늘 그 벤치마크를 통째로 공개한다.

리포지토리는 github.com/Ecro/embedeval. 라이선스는 Apache-2.0.

왜 또 다른 벤치마크인가

LLM 코딩 벤치마크야 이미 넘친다. HumanEval은 일반 Python 함수, SWE-bench는 Python 리포 단위 이슈, Aider Polyglot은 멀티 언어 편집을 잡는다. 다 좋은 벤치다. 하지만 임베디드 펌웨어를 건드리는 건 없다. 임베디드 쪽으로는 EmbedAgent (ICSE’26)가 Arduino, MicroPython, Pico, ESP-IDF(ESP32)를 다룬다. 시리즈 1편에서 인용한 ESP-IDF 29.4%가 바로 거기서 나온 숫자다. 그런데 프로덕션 임베디드의 나머지가 통째로 빠져 있다. Zephyr, STM32 HAL, FreeRTOS, 리눅스 커널 드라이버, Yocto. 여전히 사각지대다.

내가 재고 싶었던 건 딱 하나였다. LLM한테 임베디드 코드를 시킬 때, 프롬프트에 안전 패턴을 안 적어주면 얼마나 무너지는가. 시리즈 1편에서 눈으로 본 그 격차를 숫자로 박고 싶었다.

무엇을 측정하는가

233 케이스. 공개 185에 비공개 held-out 48. held-out은 학습 데이터 오염을 막으려고 별도 리포에 숨겨뒀다. 23개 카테고리, 6개 플랫폼. 케이스 하나가 거치는 파이프라인은 이렇다.

L0부터 L3까지는 뻔한 단계다. 진짜는 L4다. L3가 regex 휴리스틱이라는 지적은 맞다. 그래서 L4 mutation testing을 붙였다. 레퍼런스 코드에 일부러 버그를 심는다. volatile을 떼고, lock 순서를 뒤집고, 헤더를 뺀다. 그러고 L0/L3 체크가 그 버그를 잡는지 본다. 못 잡으면? 그건 LLM이 잘나서가 아니고 체크 자체가 허술한 것이다. 그러니까 L4가 재는 건 모델 점수가 아니라 벤치마크 자체의 신뢰도다.

기본 모드는 Docker 없이 L0에 L3만 돈다. 이게 제일 빠르고, 모델을 가르는 변별력도 이걸로 충분하다. L1/L2는 Docker SDK 빌드 환경이 깔려 있을 때만 돈다.

n=3 결과

Sonnet 4.6과 Haiku 4.5를 각각 3번씩 돌린 결과다. Wilson 95% 신뢰구간은 pooled 699 trial 위에서 계산했다.

모델	pass@1 (n=3 평균)	95% CI	케이스 안정성
Sonnet 4.6	68.0%	[64.4%, 71.3%]	87%
Haiku 4.5	56.9%	[53.2%, 60.6%]	73%

CI가 안 겹친다. 두 모델 사이 11.1%p 차이는 통계적으로 유의하다 (p < 0.05). 케이스 안정성은 “3번 다 같은 결과, 그러니까 다 통과거나 다 실패인 케이스의 비율”이다. Sonnet은 233개 중 143개가 매번 통과, 60개가 매번 실패, 30개만 flaky였다. Haiku는 99 / 71 / 63. n=3이다 보니 stable과 flaky 경계는 noisy하다. v0.2에서 n=5로 올릴 생각이다.

어디서 약한가 (DMA, ISR, Threading)

카테고리별로 pass@1을 펼치면 패턴이 딱 보인다.

선언적인 영역은 두 모델 다 잘한다. device tree, Kconfig, boot 시퀀스는 90에서 100%를 친다. 무너지는 영역은 늘 같다. 아래 숫자는 pooled n=3 기준이다. 시리즈 2편은 초기 n=1 run을 인용했으니 카테고리별 절대값은 다르게 나온다. ISR처럼 모델 순위가 뒤집힌 데도 있다. 9 TC에 n=3이면 이 정도 flip은 변동 범위 안이다.

• DMA 캐시 일관성: Sonnet 31% / Haiku 8%. 시리즈 2편에서 파고든 그 패턴이다.
• ISR 동시성: Sonnet 23% / Haiku 38%. volatile, memory barrier, ISR-thread 공유 상태.
• Threading: 두 모델 모두 33%. mutex 순서, 데드라인 처리.
• 메모리 최적화: Sonnet 67% / Haiku 33%. memory domain, slab allocator.
• Storage: Sonnet 54% / Haiku 31%. flash wear leveling, NVS 라이프사이클.

이 5개 영역이 시리즈 1편에서 말한 implicit knowledge gap의 실체다. 함수 안만 봐서는 안 보이는 컨텍스트에 의존하는 패턴들이다. 데이터시트, 인터럽트 컨텍스트, 캐시 동작, 플래시 마모 특성. 시리즈 2편에서 6가지 패턴으로 분류한 것과 거의 겹친다.

한계 (먼저)

벤치마크를 내놓으면서 제일 먼저 짚어둘 것들.

1. 모델이 두 개뿐이다. Sonnet 4.6과 Haiku 4.5만 n=3로 돌렸다. GPT, Gemini, DeepSeek, Qwen은 v0.2의 몫이다. v0.1은 모델 수보다 통계 신뢰성을 앞세웠다. 같은 모델을 여러 번 돌려서 CI를 잡는 쪽에 걸었다. 다른 모델 결과는 PR로 받을 수 있게 contributing 워크플로우를 정리해뒀다.

2. Zephyr 편향이 세다. 233개 중 대략 81%가 Zephyr다. ESP-IDF, STM32 HAL, FreeRTOS, Linux driver, Yocto는 각각 5에서 10개 수준이다. v0.2에서 FreeRTOS와 Linux 드라이버 케이스를 늘릴 계획이다. 이유는 단순하다. Zephyr가 native_sim이랑 Docker 빌드에 제일 잘 붙어서, L1/L2까지 돌릴 수 있는 케이스가 많다.

3. L1/L2는 절반만 돈다. 233개 중 대략 106개만 L1 컴파일과 L2 런타임을 탄다. 나머지는 하드웨어 보드 타겟(nrf52840dk 같은)이거나 ESP-IDF/STM32라 native_sim에서 안 돈다. 얘들은 L0+L3로 잰다. METHODOLOGY에 케이스별로 다 적어뒀다.

4. 범위가 단일 파일이다. 한 케이스가 한 파일이다. 멀티 파일 스캐폴딩은 v0.3 얘기다. 헤더/소스 분리, CMakeLists, Kconfig 일관성 같은 거. LLM이 매일 하는 작업의 큰 덩어리인데, 검증 파이프라인을 처음부터 다시 짜야 한다.

5. L3는 regex 휴리스틱이다. L4 mutation testing이 이걸 검증하긴 하지만 한계는 뚜렷하다. 진짜 의미 분석은 L1+L2가 돌 때만 가능하고, 그건 케이스 절반뿐이다.

벤치마크 로드맵

ROADMAP에 v0.2 / v0.3 / v1.0을 풀어놨다. 모델 커버리지 확장, FreeRTOS 케이스 추가, HF Space 제출 플로우, 멀티파일 스캐폴딩, agent 모드 강화 순이다.

지금 당장 제일 도움 될 PR은 이 셋이다.

• 새 모델 결과: 가진 API key로 n=3 돌려서 results/runs/<date>_<model>/ 로 PR
• 약한 카테고리 케이스: DMA, ISR, threading 쪽에서 프로덕션에서 겪은 실패 패턴이 있으면 케이스로
• L3 체크 강화: 특정 카테고리에서 false positive/negative를 본 적 있으면 negatives.py 추가

Issue 템플릿은 세 개 만들어뒀다. model evaluation request, case contribution, methodology question. 비판은 환영이다. 발표 전보다 발표 후에 발견되는 게 더 비싸기 때문이다.

• 리포: github.com/Ecro/embedeval
• 인터랙티브 leaderboard: huggingface.co/spaces/ecro/embedeval
• 방법론: docs/METHODOLOGY.md
• Roadmap: ROADMAP.md

이 시리즈에서 인용한 숫자가 어디서 나왔는지 궁금했다면, 이제 직접 돌려보면 된다.

---

다음 편은 이 숫자를 어떻게 움직이느냐다. 카테고리 히트맵으로 짠 리스크 티어 (Critical / High / Moderate / Low), Sonnet vs Haiku per-model 선택 가이드, 모듈별 프롬프트 템플릿 9개 (ISR, DMA, sensor, OTA…), pre-commit에 박는 grep 한 줄짜리 체크 9개. 측정에서 실전으로.