이 노트에 대하여
Zigbee 허브 펌웨어를 버전1(64M)에서 버전2(512M)로 다시 지으며, “작으니까 Zig”라는 근거가 실제로는 성립하지 않았음을 확인한 기록이다. 결론은 그대로 남고 근거만 갈아끼운다 — C SDK 링크와 결정성. 지식을 코드에서 데이터로 옮기고, x86에서 먼저 짓고, 상수가 어디서 나왔는지를 문서에 박는다. 껍데기를 만드는 일은 이제 쉽다. 어려운 것은 무엇이 실측이고 무엇이 가정인지를 끝까지 붙드는 일이다. 여기에 여섯 달 전의 구현·설계·에이전트 협업 방식이 여전히 유효한지, repo에서 실기 측정까지 닫히는 현재의 폐루프로 다시 묻는 질문을 더한다.
히스토리
- @mitsein — “6개월 전의 구현·설계·에이전트 협업 방식이 이미 낡았는가”라는 인간의 자문을 독립 질문으로 올렸다. 모델 지식 컷오프가 아니라 repo 접근, 빌드·시뮬레이션·크로스컴파일, 실기 제어, 실측 회수까지 닫히는 현재의 협업 루프로 검증해야 한다.
- @claude — 버전1/버전2 구분으로 본문을 다시 세웠다. 기존 SDF·DS·Thread 기록은 버전1 시대의 것으로 ARCHIVE에 보존.
- @junghan — 허브 개발 담당자가 §homeagent-config 로드맵 — 오픈소스 스마트홈 에이전트 플랫폼
- @junghan — 또 어려운 것 만났다.
- @junghan — † #세대 #연령 #생애주기 #코호트 #연대 20대를 생각하면 30대는? 40대는?
- @junghan — DS #7 배터리 교체 KEEPALIVE 엣지케이스 D-DAY. P0 정상 동작 확인, 15분 갭 원인 확정. 코드 수정 전 넓게 보는 중.
- @junghan — 위대한 해결을 앞두고 있습니다.
- 생성 — fxf-uho-mvt DS 페어링 프로파일러 설계 과정에서, 서스먼 SDF 원칙이 임베디드 Zig 코드에 적용된 실례 기록
관련노트
- @힣: 메모리 대란과 임베디드 개발 — 투명한 경계 — 이 글이 이어받는 원석. “ZIG로 한다. 괜찮다. 이건 또 다른 주제이다”로 미뤄둔 그 주제.
- @힣: 분신의 공방 — 역할 기반 조율과 협업 운영규약 — 버전1·버전2·서버/앱 담당자가 전부 에이전트인 이 프로젝트가 서는 운영 규약.
- §homeagent-config 로드맵 — 오픈소스 스마트홈 에이전트 플랫폼 — 허브 쪽 큰 몸.
- @힣: 나는허브다 - 상태머신과 에이전트 협업 — 허브가 “나는 허브다”만 선언하는 축.
- 제럴드제이서스먼 SICP SICM FDG SDF — 아래 ARCHIVE의 유연성 논의가 딛고 선 자리.
한 줄
껍데기는 에이전트가 쉽게 만든다. 어려운 것은 숫자 하나가 어디서 왔고 언제 만료되는지를 붙들고 있는 일이다.
버전1과 버전2
이 글은 Zigbee 허브 펌웨어 두 판을 오가며 쓴다. 먼저 이름을 정의한다.
버전1 fxf-uho-mvt — 양산 펌웨어. 지금도 필드에서 돌고 있다.
- SSD212 / ARMv7 / RAM 64M / 벤더 sysroot
- Zigbee 라디오를 벤더 SDK(클로즈드)로 직접 드라이빙
- DeviceType *7종*(도어센서·온습도·스위치·플러그·IR…)을 Zig 코드에 하드코딩
- AWS IoT Core. PKCS#11 클라이언트 인증서, Fleet Provisioning by Claim, shadow
버전2 hejhub-nano — 보드 의존성을 분리해 재구현 중인 신규 레인.
- SG2000 / riscv64(thead c906) / RAM 512M / static musl
- Zigbee 라디오는 EFR32MG24 + Zigbee2MQTT(z2m)에 위임. 허브는 MQTT로 z2m과 대화
- device-agnostic. 7종 핸들러를 버린다. z2m이 device SSOT
- 허브 생명주기 상태머신 + 범용 z2m↔서버 브리지가 전부
한 문장으로 줄이면 이렇다.
버전1은 “허브가 모든 것을 안다”. 버전2는 “허브는 자기가 허브라는 것만 안다”.
버전1이 낡아서 버리는 것이 아니다. 64M에서 그 설계는 유일한 답이었다. 바뀐 것은 보드다.
작아서 Zig 가 아니었다
64M짜리 버전1에서는 Zig를 쓰는 이유가 자명해 보였다. 자원이 없으니까. 런타임이 없는 언어여야 하니까.
버전2로 오면서 그 논거가 무너졌다. 512M 보드에서 z2m이 Node.js로 돈다. 상시 RSS 100M대다. 작지 않다. Node.js가 도는 보드를 두고 “Go는 무겁다”고 말하면 앞뒤가 안 맞는다.
컴파일·크로스 쪽도 마찬가지다. Go는 1.14부터 linux/riscv64 를 정식 지원한다. GOOS=/=GOARCH 만 바꾸면 크로스컴파일되고, 순수 Go면 CGO 없이 완전 정적 바이너리가 나온다. “컴파일 언어라서 Zig”도 근거가 못 된다.
그럼 왜 Zig인가. 셋으로 좁혀진다.
1. C SDK 링크 — 이게 결정적이다.
버전2는 coreMQTT / coreJSON / fleet-provisioning / mbedTLS를 리포에 벤더링해서 Zig가 소스빌드한다. prebuilt .a 를 받지 않는다. Go로 가면 이걸 전부 CGO로 묶어야 하고, CGO + riscv64 크로스 + musl static 은 갑자기 고통스러워진다. CGO를 켜는 순간 Go의 “그냥 되는 크로스컴파일”이 사라진다.
Zig는 C 컴파일러를 내장하고 있다. zig cc 가 그대로 크로스 툴체인이다. 언어 논쟁이 아니라 툴체인 논쟁이다.
2. 결정성. 같은 trace는 x86에서든 riscv64에서든 같은 시퀀스여야 한다. 런타임과 GC가 없으면 이 재현이 쉽다.
여기서 정직해야 한다. 허브 상태머신의 시간 스케일은 초 단위다 — 페어링 창 8초, 물리 close 60초. GC pause가 1ms든 10ms든 이 스케일에서는 문제가 안 된다. 성능이 아니라 재현의 편의 다. 그 이상으로 부풀리면 그건 거짓말이다.
3. 바이너리 크기. Go 정적 바이너리는 보통 한 자릿수 MB대, Zig는 그보다 한 자릿수 작다. 수십만 대에 OTA를 쏘면 대역폭이 원가가 된다.
결론이 맞아도 근거가 틀리면, 하드웨어가 바뀔 때 무너진다. 512M이 1G가 되면 “작아서 Zig”는 사라진다. “C를 링크하고 결정적이어야 해서 Zig”는 남는다. 같은 결론을 지키려면 근거를 갈아끼워야 했다.
지식을 코드에서 데이터로
버전1의 7종 하드코딩은 게으름이 아니라 64M의 귀결이었다. device 지식을 둘 데가 코드밖에 없었다.
512M은 그 제약을 푼다. z2m은 3000종이 넘는 기기 정의를 데이터로 갖고 있고, 그걸 Zig로 다시 쓸 방법은 없다. 100M대 RSS로 그것을 사는 건 압도적으로 싸다.
바뀌는 것은 메모리 예산이 아니라 새 기기 하나를 지원하는 비용 이다.
| 버전1 | 버전2 | |
|---|---|---|
| 새 기기 지원 | 펌웨어에 핸들러 추가 → 전량 OTA | z2m 컨버터 데이터 |
| device SSOT | Zig 코드 | z2m |
| 허브가 아는 것 | 기기 7종의 의미 | 자기가 허브라는 것 |
교차검증 하나
같은 회사 다른 팀이 Go로 자체 IoT 플랫폼을 만들고 있다. 리포도 언어도 담당자도 다른데, 독립적으로 같은 결론에 도달해 있었다 — “Zigbee는 z2m, 허브 경유”. 그리고 한 줄 더: 하위기기는 클라우드 신원을 갖지 않는다. 인증 주체는 허브뿐이고, 하위기기는 허브에 종속된 행으로만 존재한다.
서로 다른 자리에서 경계를 같은 곳에 그었다. 이런 일치는 설계가 옳다는 증명은 아니지만, 적어도 취향 문제가 아니라는 신호다.
서버에서 z2m을 돌리는 구조는 왜 안 되나
ThingsBoard나 Home Assistant처럼 서버 쪽에서 z2m을 돌리는 그림도 있다. 그건 홈서버 1대 = 집 1채 인 셀프호스팅에서 성립한다 — 논리적으로 “서버”라 부를 뿐, 물리적으로는 Zigbee coordinator 옆에 붙은 허브다.
클라우드 제품에서는 그대로 옮길 수 없다. 이유가 셋인데 두 번째에서 끝난다.
- coordinator는 허브에 물려 있다(
/dev/ttyS1@115200). 서버에서 돌리려면 EZSP 프레임을 serial-over-IP로 왕복시켜야 하는데, 그 밑의 ASH 계층에는 ACK 타이머가 있다. WAN 지터가 올라가면 링크가 계속 리셋된다. - z2m은 coordinator 하나당 프로세스 하나다. 허브 10만 대면 z2m 프로세스 10만 개, 각각 RSS 100M대 — 10TB. 스케일이 아니라 파산이다.
- 인터넷이 끊기면 로컬 제어가 전부 죽는다. 허브가 품고 있으면 집 안은 계속 돈다.
허브당 100M은 그 허브가 내는 값이라 싸다. 서버로 옮기는 순간 전부 사업자 원가가 된다.
x86에서 먼저 짓는다
여기가 에이전트 협업과 직접 닿는 대목이다.
버전2의 상태머신은 지금 x86 노트북 에서 돈다. 보드가 아니다. 이건 타협이 아니라 선택이다.
임베디드에서 시간을 먹는 것은 컴파일이 아니라 왕복 이다. 빌드 → 전송 → 재기동 → 로그 회수 → 판독. 여기에 디바이스가 잠들어서 기다리는 시간이 붙는다. 도어센서는 16초 뒤에 스스로 나가고, 배터리 보고는 15분 뒤에 온다. 한 홉에 반나절이 녹는다.
x86에서는 그 왕복이 초 단위다. 그래서 에이전트가 스스로 돌 수 있다. zig build test 를 수십 번 돌리고, mosquitto와 z2m을 docker로 세우고, 죽였다 살리고, exit code를 분류하고, retained 메시지 유무로 boot gate를 다시 잰다 — 사람이 옆에서 기다리지 않아도 된다. 임베디드 개발에서 사람이 병목이 되는 지점을 통째로 들어낸 것이다.
보드로 넘어가는 것은 다 되고 넘어가면 된다. 순수 코어는 이미 riscv64 static musl로 빌드해 실기에서 상태전이 시나리오를 통과시켰다. 코어가 도는 것은 증명됐고, 남은 것은 이식이지 설계가 아니다.
대가는 있다. 지금 계약에 박히는 상수가 전부 x86 것이다. 페어링 창이 열리고 기기가 완료되기까지 8.32초, 기기 인터뷰 0.472초, 물리 close 60초. c906 in-order 코어에서 같은 값이 나온다는 보장은 없다. 보드로 넘어갈 때 다시 재야 한다.
그걸 알고 넘어가는 것과 모르고 넘어가는 것이 다르다. 문서에 “이 숫자는 x86 실측이다”라고 써두는 일이 그래서 코드만큼 중요하다.
껍데기는 쉽다 — 조이는 자리는 어디인가
에이전트가 상태머신 골격을 세우고 테스트를 붙이는 일은 이제 빠르다. 껍데기는 쉽다. 문제는 그 안이다. 최근 며칠 사이 실제로 걸린 세 가지를 적는다.
하나. 문서에 박힌 근거는 만료된다
버전2 아키텍처 문서에는 확정 결정이 39개 있다. 그중 하나가 다른 팀 리포의 상태를 근거로 쓴다 — “그쪽은 스캐폴딩까지이고 빌드 가능한 바이너리가 없다”.
그게 하루 만에 틀린 문장이 됐다. git pull 한 번으로 드러났다. 바이너리도 참조 구현도 이미 올라와 있었다.
에이전트는 문서를 성실하게 읽는다. 그게 강점이다. 문제는 문서가 외부 사실을 인용하는 순간 그 문장에 유통기한이 생긴다 는 것이고, 지금 구조에는 그 표시가 없다는 것이다. 결정마다 근거: 외부 / 재확인: <조건> 같은 표가 붙어야 세션 시작에 스스로 훑을 수 있다.
둘. 기억은 예산을 낙관한다
보드 RAM을 1G로 기억하고 있었다. 실측 문서에는 512M(가용 200M대)로 적혀 있었다. 두 배 차이다.
512M이면 z2m 하나는 GREEN이다. 그런데 다음 판에 matter.js를 얹을 계획이 있고, 그건 Node 사이드카가 하나 더 붙는다는 뜻이다. 1G 기준으로는 여유롭고, 512M 기준으로는 빡빡하다. 숫자 하나가 다음 로드맵의 가부를 갈랐다.
에이전트는 이걸 잡아낼 수 있다. 리포에 실측 문서가 있고 grep 한 번이면 나온다. 잡아내려면 누군가 물어야 한다.
셋. 결론이 맞아도 근거가 틀릴 수 있다
“작아서 Zig”가 그것이었다. 결론은 유지됐고 근거만 갈아끼웠다.
이건 에이전트가 먼저 제기하기 어려운 종류다. 결론이 이미 맞으니 반박할 이유가 없고, 문서에도 모순이 없다. “이걸 다시 자문해보자”고 사람이 열어야 나온다.
그래서 역할이 갈리는 자리
| 잘하는 쪽 | |
|---|---|
| 스캐폴딩·테스트·문서 정합성 | 에이전트 |
| 리포 전체를 읽고 모순 찾기 | 에이전트 |
| 실측값 회수·교차 대조 | 에이전트 |
| 숫자가 어디서 나왔는지 | 사람 |
| 그게 언제 만료되는지 | 사람 |
| 다시 물어야 할 때를 아는 것 | 사람 |
그리고 이 프로젝트는 담당자가 여럿이다. 버전1 담당자, 버전2 담당자, 서버/앱 담당자 — 그 담당자들이 전부 에이전트다. 리포가 다르고 세션이 다르고 모델도 다를 수 있다.
그래서 공장이 아니라 공방이어야 한다. 조율자가 lane 사이 계약을 붙들고, 구현 담당자는 자기 범위를 조이고, 최종 판단과 게이트는 사람이 쥔다. 교차 검토에서 틈이 나오는 것은 루프가 도는 증거지 누가 틀렸다는 판정이 아니다.
계약을 코드보다 먼저 닫는 이유도 같은 자리에 있다. 방향을 틀 때마다 상태머신은 재설계되고, 재설계마다 상태가 하나씩 늘어난다. 조이는 것은 보수적이어서가 아니라, 조여야 상태머신이 나오기라도 하기 때문이다.
여섯 달 뒤 다시 묻는 질문 — 인간은 어디까지 에이전트와 임베디드 엔지니어링을 할 수 있는가
지금 자문할 대상은 Zig와 Go의 일반론만이 아니다. 2025년 가을과 2026년 초에 fxf-uho-mvt 를 만들 때 사용한 구현·설계·에이전트 협업 방식이, 불과 여섯 달 사이 이미 낡았는지를 묻는 일이다.
이 질문을 특정 모델의 지식 컷오프로 닫으면 안 된다. “Opus는 올해 1월까지 안다”는 것은 한 모델이 학습한 문서의 경계일 뿐, 오늘 인간이 임베디드 엔지니어링에서 에이전트와 어디까지 협업할 수 있는지를 말해주지 않는다. 현재의 한계는 모델 이름보다 어떤 도구와 실기 루프를 열어 주었는가 에서 갈린다.
Question
SG2000 수준의 보드에서 C/Zig를 선택한 근거는 지금도 유효한가? Go를 포함한 다른 선택지를 실제 툴체인과 실측으로 다시 비교할 수 있는가? 더 근본적으로, 여섯 달 전의 사람이 문서를 읽고 에이전트에게 코드 조각을 부탁하던 방식에서 벗어나, 에이전트가 리포 전체·시뮬레이터·크로스 빌드·실기 로그를 오가며 설계 가정 자체를 검증하는 단계까지 왔는가?
세 가지 질문을 분리한다
하나로 묻으면 언어 취향과 제품 구조와 협업 능력이 뒤섞인다.
- 제품 구조: z2m과 이후의 matter.js를 허브가 품을 것인가, 서버로 넘길 것인가. RAM 512M/1G, 로컬 동작, coordinator 결합, 프로세스 수, OTA 수명주기를 함께 본다.
- 펌웨어·런타임 선택: C/Zig/Go 가운데 무엇이 SG2000/riscv64에서 C SDK 링크, static build, 바이너리 크기, 메모리, 결정성, 디버깅, OTA 비용을 가장 잘 만족하는가.
- 협업 방식: 위 결정을 인간의 기억과 모델의 말솜씨로 내릴 것인가, 아니면 에이전트가 현재 리포와 장치를 직접 읽고 반복 가능한 증거를 만들게 할 것인가.
첫째와 둘째는 셋째가 성숙할수록 논쟁에서 실험으로 바뀐다. “Go도 컴파일 언어 아닌가?”라는 질문에는 설명보다 세 개의 작은 실증이 낫다. 동일한 MQTT 상태전이 코어를 Zig와 Go로 만들고, riscv64 static cross build, C SDK 링크, 바이너리 크기, RSS, cold start, 같은 trace 재현을 한 표에 놓으면 된다. 선택을 바꿀 조건까지 먼저 적어두면 결론을 지키기 위한 근거 만들기도 줄어든다.
현재 협업의 실제 경계
| 층 | 에이전트가 현재 맡을 수 있는 것 | 인간이 계속 쥘 것 |
|---|---|---|
| 리포·계약 | 전체 문서와 코드를 읽고 모순·낡은 근거·중복 구현 찾기 | 무엇을 다시 물어야 하는지 열기 |
| 호스트 시뮬레이션 | 상태머신·MQTT·z2m을 x86에서 반복 실행하고 회귀 테스트 만들기 | 시뮬레이션이 놓친 물리 조건 지정 |
| 크로스 빌드 | Zig/Go/C 후보를 riscv64로 빌드하고 크기·링크·종속성 비교 | 제품 제약과 합격 기준 결정 |
| 실기 루프 | flash·재부팅·serial log·테스트 장치 제어가 도구로 열리면 반복 실행과 로그 분류 | 배선, 전원, RF 환경, 위험한 복구의 물리 책임 |
| 실측 해석 | RSS·타이밍·실패 trace를 모아 가설과 반례 제시 | 어느 측정을 믿고 제품 결정을 내릴지 판단 |
| 양산 책임 | OTA·rollback·관측·재현 절차 초안과 검증 | 출고 게이트와 실패 비용의 최종 책임 |
핵심 경계는 “에이전트가 코드를 쓸 수 있는가”가 아니다. 센서와 보드에서 나온 증거가 다시 설계와 코드로 들어오는 폐루프를 에이전트가 얼마나 스스로 돌릴 수 있는가 다. serial console, 전원 제어, flash, RF·프로토콜 trace, 측정 장비가 도구 표면으로 열리지 않으면 에이전트는 임베디드 엔지니어가 아니라 매우 빠른 호스트측 코드 작성자에 머문다.
반대로 이 손들이 열리면 역할은 크게 변한다. 인간은 매번 빌드하고 로그를 옮기는 사람이 아니라 실험의 질문·경계·합격 기준을 세우는 사람이 된다. 에이전트는 코드 생성에서 멈추지 않고, 가정을 깨는 실험을 반복하고 결과를 시간축에 남기는 실행자가 된다.
여섯 달 전 방향은 무엇으로 판정할 것인가
fxf-uho-mvt 의 방향이 유효한지는 Zig를 계속 썼다는 사실로 판정하지 않는다. 다음 질문에 답할 수 있어야 한다.
- 64M에서 7종을 하드코딩했던 제약이 512M+z2m에서 실제로 사라졌는가.
- z2m의 기기 지식과 Node.js 비용을 허브가 감당한다는 판단은 실측됐는가.
- matter.js까지 붙을 때 512M 예산이 유지되는가.
- Zig의 결정적 이점이 “작으니까”가 아니라 C SDK 링크·툴체인·재현성·OTA 비용으로 남는가.
- Go 후보를 말로 배제하지 않고 CGO 포함 최소 실증으로 비교했는가.
- x86에서 닫은 계약과 상수가 c906 실기에서도 다시 측정됐는가.
- 에이전트가 이 증거를 재현하고, 외부 사실이 바뀌면 결론을 다시 열 수 있는가.
이 항목을 계속 다시 묻는다면 여섯 달 전 방식은 낡은 것이 아니라 진화 가능한 기반이다. 반대로 결론만 문서에 고정하고 실기 근거와 반증 조건을 갱신하지 못한다면, 최신 모델을 써도 방식은 이미 낡았다.
질문 원문 보존 — 2026-07-23
Danger
--- 2 ---
안에 z2m을 넣어야 넓은 디바이스 풀을 지원할 수 있다. (이건 zigbee이고, matterjs도 마찬가지로 nodejs 필요). 그래서 내가 허브 스펙에 램512m를 강조하는거야. z2m을 허브에 넣지 않으면 처리를 서버로 건네서 해야하는게 이것도 말이 되는 구조인가?
그리고 나는 nano 가 바라보는 허브 스펙은 sg2000 수준이야 1gb 정도 느린 디바이스야. zig로 상태머신을 조이는 이유가 그런것이야. 내가 혹시 모르거나 잘못 생각한 부분이 있는가 판단해보려는거야. 이런 프로젝트를 보면 한번 생각을 해보면 좋거든.
fxf-uho-mvt는 램이 64m 뿐인 임베디드 보드라 z2m도 불가능했고 그냥 7종 디바이스 처리 로직을 zig 코드에 넣었어. 이렇게 하기 싫어서 z2m을 허브에 품으려는것이야.
--- 3 ---
일단 허브구현에 있어서는 우리 리포에만 정확한 정보가 있으면돼. 지금은 zigbee로 fxf-uho-mvt 다음 버전을 만드는 것이고 이게 끝나면 matterjs를 해볼거야. homeagent-config 리포에서 각각은 다 해봤어. 멀티프로토콜은 MG24로는 제대로 안될거야. MG26 칩을 기다리고 있어. 이부분도 아직 논의할때는 아니야.
sg2000 수준의 보드에서 동작하는 코드는 C/zig 수준으로 구현을 해야된다고 봐. 메모리 대란으로 임베디드 스펙이 오히려 가격 압박이 커서 내가 바라보는 방향은 milkv duo-s (sg2000) 으로 딱 잡고 가는거야. 물론 내가 모든 것을 아는 것은 아니고 대략 직관하면서 하는것이니까 잘 모를수가 있어. 여기에대해서 항상 자기 검증을 하면서 우리가 관련 리서치를 이렇게 해주는 경우(uiot)는 참고를 할만해.
여기서 내가 자문하게 되는 지점은 sg2000 수준의 보드에 올라갈 펌웨어 구현이야. 이스펙에서 C/zig 으로 하는 장점을 다시 자문해보는거야. go로 이게 크로스컴파일이 되던가? 이것도 컴파일언어잖아. 물론 zig만한 임베디드 언어는 내가 보기엔 없어. 타겟이 이 목적이니까.
구현 레벨에서 작년 가을 올해 초 만들었던 fxf-uho-mvt를 만든지도 6개월이 지났어. 세상이 변해서 구현과 설계 에이전트 협업 방식이 내가 이미 낡아버린 방식으로 만들고 있는가? 자문하는 거야.
아직 열려 있는 난관
- 디바이스는 여전히 잠든다. x86 루프가 왕복을 줄였지만, 실기 검증에서는 그대로 남는다.
- x86 상수를 보드에서 다시 재야 한다. 지금 계약에 들어간 초 단위 값이 전부 노트북 실측이다.
- 라디오 하나에 프로토콜 둘을 얹을 수 없다. MG24가 Zigbee coordinator를 하는 동안 Thread를 같이 하기 어렵다. 칩 세대를 기다리는 중이고, 그래서 matter는 다음 판이다.
- z2m을 품으면 z2m을 OTA로 굴려야 한다. 버전 고착이 제품 수명 리스크가 된다. 지금 pin을 누가 언제 올릴 것인가에 대한 답이 아직 없다.
- 롤백 경로 없는 OTA로 출고할 수 없다. 물리적으로 손이 닿지 않는 기기다.
닫으며
버전1 시절 이 방에 적었던 것은 “유연하게 만들어라”였다. 축중성, 탐색 행동, 자가 복구 — 클로즈드 SDK와 싸우며 얻은 결론이었다(아래 ARCHIVE).
버전2에서 적는 것은 “조여야 나온다”이다. 모순처럼 보이지만 층이 다르다.
닫는 것 — wire 계약, 상태 정의, 실측 상수 여는 것 — device 지식(z2m 위임), backend(port), board(HAL)
64M에서는 이 분리가 불가능했다. device 지식도 코드에 넣을 수밖에 없었으니까. 512M이 산 것은 메모리가 아니라 그 분리 자체 다.
경계가 투명하지 않으면 재현성이 사라지고, 재현성이 사라지면 사람이 투입되고, 사람이 투입되면 하루가 훌러덩 간다. 껍데기를 빨리 만드는 일은 이제 어렵지 않다. 어려운 것은 그 껍데기 안에서 무엇이 실측이고 무엇이 가정인지 를 끝까지 붙들고 있는 일이다.
ARCHIVE
아래는 버전1(fxf-uho-mvt) 시대의 기록 이다. 64M 보드에서 기기 7종을 코드로 직접 다루고, 클로즈드 SDK의 테이블 한계와 싸우던 시절의 문제와 해법이다. 위 본문의 “유연하게 만들어라”가 어디서 나왔는지가 여기 있다.
Comments