쿠버네티스는 데이터센터의 대규모 서버 군집을 조율하기 위해 만들어진 시스템이다. 그런데 이 제어 모델을 손톱만 한 마이크로컨트롤러 위로 옮겨 놓으면 어떤 모습일까. 'kube32'는 바로 그 질문에 대한 답으로 공개된 프로젝트로, ESP32-S3 마이크로컨트롤러를 대상으로 쿠버네티스 호환 컨트롤 플레인과 WebAssembly 기반 파드 런타임을 구현했다. 수백 메가바이트 메모리를 전제하는 기술을 수십 킬로바이트급 환경으로 끌어내린 시도라는 점에서, 실무자 입장에서도 설계상의 타협점을 들여다볼 만한 사례다.
하나의 펌웨어, 두 가지 역할
kube32의 구조에서 가장 눈에 띄는 부분은 모든 보드가 동일한 하나의 펌웨어 이미지로 동작한다는 점이다. 역할은 하드웨어 사양에 따라 자동으로 갈린다. PSRAM을 갖춘 보드는 컨트롤 플레인 역할을 맡으면서 자체 kubelet도 함께 돌리고, PSRAM이 없는 보드는 워커로 클러스터에 합류한다. 이 방식은 배포와 유지보수 측면에서 이점이 분명하다. 노드별로 별도 빌드를 관리할 필요 없이 같은 이미지를 플래싱한 뒤, 보드가 가진 메모리 자원에 따라 역할이 결정되기 때문이다. 쿠버네티스에서 컨트롤 플레인과 워커를 물리적으로 분리하던 개념이, 여기서는 메모리 유무라는 하드웨어 조건으로 재해석된 셈이다.
관리 도구 역시 기존 생태계를 그대로 끌어왔다. 사용자는 익숙한 kubectl과 k9s로 보드 클러스터를 다루며, 제어 통신은 Wi-Fi 또는 USB 시리얼을 통해 이뤄진다. kubectl을 컨트롤 플레인 IP로 지정한 뒤 매니페스트를 적용하는 흐름은 일반적인 쿠버네티스 운영 경험과 크게 다르지 않다. 보드 초기 설정은 115200 보드레이트의 시리얼 콘솔에 접속해 Wi-Fi와 보드 프로파일을 프로비저닝하는 방식으로 처리한다. TLS 설정을 포함한 전체 절차는 프로젝트의 quickstart 문서에 정리돼 있다.
컨테이너 대신 WebAssembly
마이크로컨트롤러에는 리눅스 컨테이너를 돌릴 여유가 없다. kube32는 이 문제를 WebAssembly로 풀었다. 파드는 컨테이너 이미지가 아니라 WebAssembly 모듈이며, 이를 wasm3 인터프리터가 실행한다. wasm3는 메모리 사용량이 작고 이식성이 높은 WebAssembly 인터프리터로, 자원이 극도로 제한된 환경에 적합하다. 즉 kube32에서 '파드를 배포한다'는 것은 컨테이너를 끌어오는 것이 아니라 WebAssembly 모듈을 해당 보드의 인터프리터에 올리는 것을 의미한다. 쿠버네티스의 오케스트레이션 개념은 유지하되, 실행 단위만 임베디드 환경에 맞게 치환한 접근이다.
실제 하드웨어가 없더라도 구조를 체험할 수 있도록, 동일한 소스에서 호스트 시뮬레이터인 kube32-sim이 함께 빌드된다. macOS와 리눅스에서 두 노드짜리 클러스터를 띄우고 kubectl로 예제를 배포해 볼 수 있어, 보드를 구매하기 전에 동작 모델을 확인하려는 개발자에게 유용하다. 실제 보드에 올릴 때는 PlatformIO로 펌웨어를 빌드해 각 보드에 플래싱하며, 핀 배치와 메모리 예산은 별도의 하드웨어 사양 문서에 명시돼 있다.
Tessera라는 실증 사례
개념만으로는 이 플랫폼이 무엇을 할 수 있는지 와닿기 어렵다. 프로젝트는 Tessera라는 이슈 트래커를 예제로 제시한다. Tessera는 네 개의 WebAssembly 파드로 구성되며 Ingress가 이들 사이의 요청을 라우팅한다. 컨트롤 플레인에서는 웹 UI를 제공하는 tessera-web과 인메모리 검색 인덱스를 담당하는 tessera-api가 돌아가고, Cardputer 워커에서는 tessera-db가 마이크로SD 카드의 추가 전용(append-only) 로그에 레코드를 영속화하며 tessera-hud가 LCD와 키패드를 구동한다. tessera-hud의 소리는 기본적으로 꺼져 있고, HUD_SOUND=1 환경 변수와 스피커 권한(capability)을 통해 선택적으로 활성화된다. 샘플 데이터셋을 생성해 워커의 마이크로SD에 올린 뒤 배포하면, 컨트롤 플레인 IP나 시뮬레이터의 로컬 주소로 접속해 mara 계정(비밀번호 demo)으로 로그인할 수 있다.
이 구성은 kube32가 단순한 데모를 넘어, 여러 파드가 서로 다른 보드에 분산 배치되고 영속 저장과 물리적 입출력까지 아우르는 실제 애플리케이션을 지탱할 수 있음을 보여준다. 웹 서비스와 검색은 자원이 넉넉한 컨트롤 플레인에, 저장과 디스플레이·입력 같은 하드웨어 밀착 작업은 워커에 배치하는 역할 분담도 자연스럽다.
실무적 의미와 한계
실무자 관점에서 kube32의 매력은 익숙한 선언형 운영 모델과 기존 도구 체계를 임베디드 영역까지 확장한다는 데 있다. 소규모 센서·엣지 디바이스 군집을 kubectl 매니페스트로 선언적으로 관리하고, WebAssembly 모듈로 기능을 교체·배포한다는 발상은 펌웨어를 매번 다시 굽는 전통적 방식과 비교하면 운영 유연성이 크다. 라이선스도 Apache License 2.0으로 열려 있고(내장된 wasm3는 MIT), 기여 가이드와 별도의 보안 정책 문서까지 갖춰 협업과 검증의 토대를 마련해 뒀다.
다만 냉정하게 볼 지점도 있다. wasm3는 JIT가 아닌 인터프리터이므로 실행 성능에는 본질적인 제약이 따르고, ESP32-S3의 메모리 예산 안에서 돌릴 수 있는 워크로드의 규모 역시 제한적이다. 쿠버네티스 '호환'이라고 해도 전체 API와 스케줄링 기능을 그대로 지원한다는 뜻으로 받아들여서는 안 되며, 어디까지 재현됐는지는 문서와 실제 동작으로 확인해야 한다. 보안 모델 또한 공개된 SECURITY.md에 정의된 배포 가정 위에서만 유효하므로, 신뢰 경계가 느슨한 네트워크에 그대로 노출하는 운영은 신중해야 한다. 결국 kube32는 당장의 프로덕션 도구라기보다, 오케스트레이션 개념을 극한의 저사양 환경으로 옮겼을 때 무엇이 남고 무엇을 포기해야 하는지를 보여주는 흥미로운 실험으로 보는 편이 적절하다.