← 에세이 /Post · 21 of 21 · Thoughts

왜 EdgeLog를 시작했는가

LLM, zero-trust 보안, 현대 프레임워크를 실제 임베디드 하드웨어에 올려보면 어떻게 될까? 에지에서의 연구 기록.

·3 min read · · · #edge-computing#edge-ai#embedded-systems
왜 EdgeLog를 시작했는가
On this page

잘나가는 AI 기술은 죄다 클라우드에서 태어난다. LLM, RAG 파이프라인, zero-trust 보안, 실시간 ML 추론. 전부 RAM 넉넉하고 네트워크 안정적인 서버에서 데뷔한다. 그러다 누가 한마디 던진다. “이거 디바이스에서도 돌아가나?”

문서는 보통 딱 거기서 멈춘다.

아무도 답하지 않는 질문

512MB RAM짜리 에지 디바이스에 양자화된 LLM을 올리면 무슨 일이 벌어질까? 2초 안에 부팅해야 하는 Linux SBC에 zero-trust 보안을 어떻게 넣을까? Zephyr의 Kenning 런타임이 베어메탈 추론 파이프라인을 진짜로 대체할 수 있나? 지식 베이스가 4GB eMMC에 통째로 들어가 있는데 RAG가 말이 되긴 할까? 2W 전력 예산의 Cortex-A53에서 WASM 런타임으로 쓸모 있는 걸 만들어낼 수 있을까?

이건 다 실제 프로젝트에서 부딪히는 문제다. 제약 걸린 하드웨어에 새 기술을 밀어 넣는 사람이면 누구나 똑같이 겪는다. 다른 점이라면, 뭘 알아냈는지 아무도 안 적어둔다는 점이다.

기존 임베디드 블로그는 기초를 잘 짚어준다. Interrupt는 펌웨어 엔지니어링, Shawn Hymel은 MCU급 에지 AI를 다룬다. 그런데 프론티어는 빠르게 움직인다. “이런 기술이 있다”와 “실제 하드웨어에 올려봤더니 이랬다” 사이의 거리는 매달 벌어진다.

EdgeLog가 하는 일

EdgeLog는 연구 기록이다. 새로 나온 기술을 임베디드와 에지 디바이스에 얹어보고, 뭐가 진짜로 돌아가는지 확인한 다음, 그 경험을 적는다.

포스트마다 답하는 질문은 하나다. 이 기술이 실제 하드웨어 제약과 부딪히면 무슨 일이 일어나는가?

주제는 프론티어를 따라 움직인다. 지금 파고 있는 건 이런 것들이다.

온디바이스 인텔리전스. Raspberry Pi 5 (8GB)에 Q4_K_M로 양자화한 Qwen2.5-1.5B를 올려 llama.cpp를 돌려봤다. 초당 6 토큰쯤 나온다. 느리다. 그래도 클라우드 API 안 부르고 로컬에서 명령 파싱하고 로그 요약하는 정도는 충분히 쓴다. 진짜 질문은 “돌아간다” 다음부터 시작된다. 메모리 대역폭 병목(Pi의 50 GB/s LPDDR4X 대 데이터센터 GPU의 2 TB/s HBM), 동시 추론에 걸리는 스왑 압력, eMMC 위 SQLite에 벡터 확장 얹은 RAG, 플래시에 욱여넣을 만큼 작은 LoRA 어댑터로 하는 온디바이스 파인튜닝, 에지에서 클라우드로 뭘 올려보낼지 골라내는 하이브리드 구조.

차세대 프레임워크와 런타임. Zephyr 4.x는 Kenning 런타임과 LiteRT, IREE로 ML 추론을 굴리는 보드를 900개 넘게 지원한다. 2025년 12월부로 Linux 커널에서 Rust는 실험 딱지를 뗐고, DRM 서브시스템은 새 드라이버에 Rust를 요구할 참이다. WasmEdge, Ocre(Linux Foundation, Zephyr에서 128KB 풋프린트) 같은 WASM 런타임은 실험 단계를 지나 프로덕션으로 넘어오는 중이다. 복잡한 에지 디바이스에서는 하이브리드 OS 구조(Zephyr가 실시간 제어, Linux가 네트워킹과 UI)가 슬슬 기본값이 되고 있다. 이 중 뭐가 실제 데드라인, 실제 전력 예산과 부딪혀도 살아남는지 보고 싶다.

AI 기반 임베디드 개발. Yocto 레시피 디버깅하고 디바이스 트리 리뷰할 때 Claude를 매일 쓴다. compatible 문자열 빠진 걸 잡아내고 RDEPENDS 고칠 곳 짚어주는 건 확실히 잘한다. 레지스터 수준 드라이버 코드는 확실히 못한다. 컴파일은 되는데 레지스터 맵을 환각으로 지어내서 엉뚱한 오프셋에 값을 쓰는, 딱 그럴듯한 C를 뱉는다. 임베디드 작업마다 그 경계선이 어디쯤인지, 통과/실패 예시를 붙여서 정리해두고 싶다.

에지 보안, 프라이버시, CRA 준수. EU 사이버 복원력법(CRA)의 보고 의무는 2026년 9월 11일부터 걸린다. EU에 임베디드 Linux 제품을 파는 회사라면, 실제로 악용되는 취약점을 24시간 안에 ENISA에 신고해야 한다. 완전 준수 시한은 2027년 12월이다. 그런데 내가 본 Yocto 기반 제품 대부분은 빌드 파이프라인에 자동 CVE 스캐닝이 없다. ENISA가 인정할 SBOM은 말할 것도 없다. Zephyr는 벌써 Build SBOM을 자동으로 만들어준다. Yocto는 아직 쫓아가는 중이다. meta-security 기반 빌드에서 현실적인 준수 세팅이 어떤 모양인지, 커스텀 하드웨어에서 secure boot랑 anti-rollback OTA가 실제로 뭘 요구하는지 정리하고 있다.

이 목록은 계속 바뀐다. 그게 원래 의도다.

글쓰기 방식

실험 먼저, 글은 나중. 모든 포스트는 실제 하드웨어, 실제 코드, 실제 측정값에서 출발한다. 직접 빌드하고 플래시하고 돌아가는(또는 죽는) 걸 두 눈으로 안 봤다면, 그렇다고 밝힌다. 이 블로그에서 터미널 스크린샷 없는 글은 이 포스트 하나뿐이다. 다음부터는 전부 증거를 달고 나온다.

안 되는 것에 솔직하게. 가치의 절반은 막다른 길에 있다. README에선 그럴싸한데 메모리 빠듯한 디바이스에 올리면 무너지는 기술이라면, 그거야말로 적어둘 값어치가 있다. Cortex-A53 보드에서 WASM 기반 ML 추론을 돌려보겠다고 두 주를 쏟았다가, 결국 접고 네이티브 C로 돌아온 적이 있다. 그것도 포스트 하나다.

독자 시간을 아낀다. 군더더기 없이, 과장 없이, 버즈워드 없이. 바로 돌려볼 수 있는 코드, 비교할 수 있는 숫자, 각자 프로젝트에 대입해 따져볼 수 있는 트레이드오프. 그것만 준다.

다음에 올 내용

첫 실험들은 벌써 돌아가는 중이다.

누가 “이거 디바이스에서 돌아가나?”라고 물었을 때 눈이 반짝이는 엔지니어. 이 블로그는 그런 사람을 위한 곳이다. 구독은 RSS로 하면 된다.

클라우드는 10년을 누렸다. 이제 256KB에 넣어볼 차례다.

ecro
글쓴이 ecro

LLM 펌웨어 벤치마크를 만들었습니다. EmbedEval →

프로젝트에 맞는 Claude Code / Cursor / Codex 하네스를 생성하는 도구를 만듭니다. harness-maker →

Datasheet을 읽는 터미널을 만들고 있습니다. NeuroTerm →

댓글

댓글 불러오는 중...