임베디드 도구의 늦은 봄 — STM32CubeMX2 해부에서 본 네 가지 신호

나는 주로 소프트웨어를 만들지만, 평소 관심사는 좀 산만하다. 펌웨어, 통신 프로토콜, 배터리, 자동차, 칩 — 하드웨어와 맞닿은 영역에 항상 한쪽 발을 걸쳐 두고 있다. 그런데 이런 영역에는 공통점이 하나 있다. 기술 수용이 느리다는 것. 일반 SW에서 5년 전에 당연해진 도구나 사고방식이, 하드웨어 쪽으로 넘어오는 데는 또 5년이 걸린다.

그래서 늘 궁금했다. 이 시차가 어느 시점에 좁혀질까? 요즘처럼 AI가 모든 영역의 기술 도입 속도를 동시에 끌어올리는 시기에, 이 느린 동네는 언제 그 흐름에 합류할까.

지난 며칠 STM32CubeMX2 — STMicroelectronics가 내놓은 차세대 STM32 구성 도구 — 의 macOS 1.0.0 빌드를 디스크 단위로 해부해 봤다. 약 839MB에 5,628개 파일. /Applications이 아니라 ~/Library/Application Support/STMicroelectronics/ 아래에 통째로 풀려나오는 모양새부터 어딘가 익숙하지 않았다. 들여다볼수록 "어, 이 동네에도 마침내 이게 왔구나" 싶은 신호가 곳곳에 있었다.

네 가지로 정리된다.

첫 번째 — UI를 NetBeans/Swing에서 Theia/Electron으로 갈아엎었다

클래식 STM32CubeMX는 NetBeans + Java Swing 위에 얹힌 도구였다. "자바 데스크탑 GUI"라는 한 단어로 시대 감각이 다 설명되는 종류의 스택이다. 클럭 트리를 마우스로 끌어 맞추는 그 화면은 2010년대 초반부터 거의 그대로였다.

CubeMX2는 이 토대를 통째로 갈아엎었다. Eclipse Theia 위에 Electron으로 묶은 IDE다. Theia는 VS Code와 같은 가족 — 같은 Monaco 에디터, 같은 플러그인 API, 같은 키바인딩 모델을 쓴다. package.json의 theia.target이 그냥 "electron"이라고 박혀 있다. ST는 자기 기능을 @prg-cube/*라는 네임스페이스의 Theia 확장으로 잘게 쪼갰다. 핀아웃, 클럭 트리, DMA, NVIC, EXTI, 미들웨어, HW 플랫폼 합성 — 각각이 독립된 모듈이고, 각자의 semver를 가진다.

이게 일반 SW 세계에선 새로운 이야기가 아니다. VS Code는 2015년에 나왔고, Theia는 2017년부터 공개됐다. 하지만 임베디드 벤더 주력 도구가 거기에 올라타는 건 ST가 거의 처음이다. 도구의 모양이 시대를 따라잡는 데 10년이 걸린 것이다.

두 번째 — 빌드 시스템을 표준에 위임했다

이게 더 의미심장한 신호였다. 클래식 CubeMX는 자체 Makefile을 토해냈다. 빌드도, 컴파일러 추상화도, 의존성도 ST가 직접 짠 매크로 위에 있었다.

CubeMX2는 이걸 안 한다. cube mx ide-project generate --format 명령에 옵션이 셋이다.

--format <CMake | EWARM | Open-CMSIS>

ST는 이제 빌드를 만들지 않는다. 구성과 코드 생성만 책임지고, 결과물을 셋 중 하나의 표준 형식으로 export 한다. CMake로 뽑으면 그대로 VS Code/CLion에 붙고, EWARM으로 뽑으면 IAR IDE에서 열리고, Open-CMSIS로 뽑으면 csolution.yml + cproject.yml + clayer.yml 세트가 나와서 cbuild로 빌드된다.

그리고 동봉된 게 Open-CMSIS-Toolbox 2.11.0의 vanilla 바이너리 한 묶음이다 — csolution, cbuild, cpackget, svdconv. 흥미로운 건 그 bin/ 디렉터리 안에 launch-MCUXpressoConfigTools(NXP)와 launch-Infineon_Dev_Config(인피니언) 런처가 같이 들어 있다는 점이다. ST가 자기 회사 MCU만이 아니라 이종 벤더 통합까지 의식하면서 도구를 만들고 있다는 뜻이다.

자기 빌드 시스템에 사용자를 묶어 두는 건 단기적으로는 벤더에게 유리하다. 그걸 ST가 자발적으로 풀고 표준 위로 옮긴 건, 장기적으로 STM32 생태계가 다른 Cortex-M 벤더들과 같은 빌드 파이프라인 위에서 동작할 수 있어야 한다는 그림을 그리고 있다는 의미다. 이런 결정은 일반 SW 세계에서는 흔하다 — 자기만의 빌드 도구를 버리고 표준에 합류한 사례가 한둘이 아니다. 그런데 임베디드 벤더가 이걸 한다는 건, 동네 분위기가 바뀌고 있다는 신호다.

세 번째 — 데이터를 패키지처럼 다룬다

이 부분이 개인적으로 제일 마음에 들었다. CubeMX2 본체 안의 cube-dcm.json(dependency/capability matrix로 추정)을 열어 보면 이런 게 박혀 있다.

{
  "dependencies": {
    "descriptors": {
      "pinout":      { "compatibleWith": ">=1.0.0 <2.0.0-0" },
      "peripherals": { "compatibleWith": ">=1.3.0 <2.0.0-0", "developedWith": "1.3.0" },
      "DMA":         { "compatibleWith": ">=1.1.0 <2.0.0-0" },
      "middlewares": { "compatibleWith": ">=1.0.0 <2.0.0-0" },
      "bom-pcb":     { "compatibleWith": ">=1.0.0 <2.0.0-0" },
      "netlist":     { "compatibleWith": ">=1.0.0 <2.0.0-0" }
    }
  }
}

ST는 디바이스 데이터를 디스크립터 단위로 잘게 나누고, 각 디스크립터에 semver 호환 범위를 박았다**. 핀아웃 모델, 페리페럴 모델, DMA 모델, 심지어 PCB/BoM/네트리스트 같은 보드 레벨 데이터까지 각자 독립된 버전을 가진다. 도구가 어떤 디스크립터 메이저까지 받아들일지가 매트릭스로 정의되어 있다. 데이터/모델/스키마를 코드처럼, 아니 정확히는 **npm 패키지처럼 버전 관리한다.

같은 사고방식이 도구 전체에 깔려 있다. bundles/ 디렉터리 안에는 node/22.22.0+st.1, open-cmsis-toolbox/2.11.0+st.1, codegen/8.29.3, conversion-manager/0.2.13 같은 식으로 모든 외부 도구가 자기 버전 폴더 안에 들어 있다. cube CLI는 --with <bundle@version> 옵션으로 특정 번들 버전을 강제할 수 있다. 회귀 디버깅이나 A/B 실험에 그대로 쓸 수 있게 되어 있다.

여기에 더해, 부수적으로 따라오는 게 데이터 모델이 칩에서 보드로 확장됐다는 사실이다. 클래식 CubeMX는 MCU 한 칩의 핀 매핑/클럭/주변기기에 집중했지만, CubeMX2는 PCB, BoM, 네트리스트, 커넥터, 상호연결까지 1차 시민으로 다룬다. @prg-cube/stm32-cube-hw-platform-composition-feature라는 모듈이 따로 있을 정도다. 단일 MCU 구성기에서 HW 플랫폼 합성기로 무게중심이 옮겨가고 있다.

npm/Cargo 식의 의존성 사고방식이 하드웨어 벤더 도구에 그대로 들어와 있는 걸 보는 게 좀 신기했다. 그리고 이걸 하필 보드 레벨 데이터까지 같은 방식으로 관리한다는 점이, 여기 뭔가 더 큰 그림이 있다는 느낌을 줬다.

네 번째 — 자동화가 1급 시민이다

마지막 신호이자 가장 분명한 신호다. 모든 GUI 동작이 cube mx ... CLI에 1:1로 노출되어 있다. 핀 할당, 클럭 설정, DMA 구성, 페리페럴 활성화, 보드 검색, 팩 설치, 빌드 export — 전부. 그리고 거의 모든 서브커맨드가 --port/--host 옵션을 가진다.

이게 무슨 뜻이냐면, MX는 사실 HTTP 백엔드 서버고 GUI도 CLI도 모두 그 서버에 붙는 클라이언트라는 것이다. cube mx start로 백엔드를 띄워 두면, 셸 스크립트로 모든 작업이 가능하다. 같은 백엔드에 GUI와 CLI가 동시에 붙어, CI에서 만든 구성을 GUI로 시각 검증하는 워크플로우도 자연스럽다.

이건 "GUI를 먼저 만들고 CLI를 나중에 끼워 넣은 도구"의 모양이 아니다. 처음부터 자동화를 의식하고 그 위에 GUI를 얹은 도구의 모양이다. 일반 SW 세계에서는 익숙한 분리지만, 임베디드 벤더 도구가 이렇게 설계된 건 처음 본다. (이 부분은 할 말이 더 많아서 다음 글에서 따로 풀어볼 생각이다.)

그래서 왜 흥미로운가

이 네 가지가 따로따로 보이면, 그냥 ST가 도구를 새로 잘 짰다는 정도의 이야기다. 그런데 다 모아 놓으면 패턴이 나온다.

임베디드/하드웨어 도구 영역이, 마침내 일반 SW의 사고방식에 합류하기 시작했다. Electron 기반 IDE, 표준 빌드 시스템에 위임, 패키지 매니저식 의존성 관리, GUI/CLI 동등 분리 — 이 네 가지는 일반 SW에서는 10년 전부터 점점 당연해진 것들이다. 그게 한 도구에 동시에 들어왔다는 건, 그동안 쌓여 있던 시차가 한 번에 좁혀지고 있다는 뜻이다.

왜 지금일까. 짐작은 두 가지다.

하나는 임베디드 개발자의 인구 구성이 바뀌었다는 것. 자바 Swing GUI에서 클럭 트리를 마우스로 끌어 맞추는 데 익숙한 세대 옆에, VS Code에서 git으로 협업하고 CI에 모든 걸 올리는 세대가 합류했다. 후자가 다수가 되는 시점이 오면, 도구가 그쪽으로 따라간다. 펌웨어와 자동차 쪽 친구들과 이야기해 보면, 최근 5년 사이에 이 비율이 체감상 확연히 기울었다.

다른 하나는 AI 시대가 도구의 평가축 자체를 바꾼다는 것. AI 에이전트가 사람을 대신해 도구를 다루려면, 도구가 GUI 뒤에 숨어 있으면 안 된다. 자동화가 1급 시민이고, 모든 동작이 CLI나 API로 노출되어 있고, 결과가 표준 포맷이어야 한다. 이걸 의식해서 만든 도구는 의식하지 않고 만든 도구와 한눈에 구별된다. CubeMX2는 분명히 의식해서 만든 쪽이다.

시차가 좁혀지면

내가 늘 궁금했던 건, 이런 느린 동네에 새로운 패러다임이 도착하는 정확한 시점이었다. 자동차, 배터리, 산업용 펌웨어, 통신 장비 — 이 영역들에서 도구와 워크플로우가 일반 SW를 따라잡는 순간이 언제 올지.

CubeMX2를 해부해 보고 든 생각은, 그 시점이 생각보다 가까이 와 있을지도 모른다는 것이다. 그리고 한 번 도착하면, AI가 이 영역에 들어가는 속도도 그 도구의 모양에 비례해서 빨라진다. 칩 벤더 도구가 패키지 매니저처럼 동작하고, 빌드가 표준이고, 모든 동작이 CLI로 노출되어 있으면, 그 위에 에이전트를 얹는 일은 더 이상 SF가 아니다. 도구가 먼저 그런 모양이 되고, 그 위에 에이전트가 따라 들어오는 — 그게 맞는 순서처럼 느껴진다.

ST가 이걸 한 두 번째, 세 번째 벤더가 분명히 따라온다. 그리고 그 흐름이 자동차/배터리/IoT 영역의 개발 도구까지 번져 나가는 건 시간 문제일 것이다. 하드웨어와 펌웨어처럼 한 박자 느린 영역을 늘 궁금해 하던 사람 입장에서, STM32CubeMX2 1.0.0이 보낸 신호는 꽤 반가웠다. 오래 기다리던 봄이 드디어 동네에 도착한 기분이다.