단일 GPIO 핀을 토글하는 것에서부터 엣지(edge)에 지능형 저전력 펌웨어(firmware)를 배포하기까지의 과정 — 그리고 그 과정에서 나를 성장시킨 교훈들에 대하여.

내가 마이크로컨트롤러(microcontroller)에서 처음으로 실행했던 프로그램은 정확히 한 가지 일만 수행했습니다. 바로 LED를 깜빡이는 것이었습니다.
운영체제(OS)도 없었고, 프레임워크(framework)도 없었으며, 안전장치도 없었습니다. 오직 나의 코드, 레지스터(register), 그리고 초당 수백만 번씩 흐르는 클록(clock)뿐이었습니다. 그 LED가 마침내 내가 의도한 속도로 — 너무 빠르지도, 계속 켜져 있지도 않게 — 깜빡였을 때, 나는 이전에 소프트웨어를 작성하며 느껴보지 못한 무언가를 느꼈습니다. 베어메탈(bare-metal) 시스템에서는 당신이 직접 실행하지 않으면 아무 일도 일어나지 않습니다. 당신의 뒤를 조용히 정리해 주는 런타임(runtime) 같은 것은 없습니다. 완전한 통제권과 완전한 책임감이 뒤섞인 그 느낌이 나를 임베디드 시스템(embedded systems)의 세계로 끌어들였고, 결국 그 흐름이 나를 엣지(edge)에서 머신러닝(machine learning) 모델을 실행하는 단계까지 이끌었습니다.
이것은 단 하나의 깜빡이는 핀에서 시작하여, 스스로 감지하고 결정하며 행동하는 지능형 장치에 이르기까지의 여정에 대한 이야기입니다.

베어메탈(Bare-Metal)의 시작
베어메탈 펌웨어(bare-metal firmware)는 컴퓨터가 실제로 무엇인지 배우는 곳입니다.
GPIO를 토글하기 위해 메모리 맵 레지스터(memory-mapped register)에 값을 쓰거나, UART 주변 장치(peripheral)를 한 번에 1비트씩 설정할 때, 하드웨어를 가려주는 추상화(abstraction)는 존재하지 않습니다. 데이터시트(datasheet)를 읽어야 합니다. 레퍼런스 매뉴얼(reference manual)을 읽어야 합니다. 클록 설정(clock configuration)을 잘못하면 아무것도 작동하지 않습니다. 에러 메시지조차 없이 그저 침묵할 뿐입니다. 그러다 문제를 수정하면, 갑자기 내가 설정한 보드 레이트(baud rate)에 맞춰 핀에서 바이트(bytes)가 흘러나오기 시작합니다.
나의 초기 성장의 대부분은 ARM Cortex-M 플랫폼에서 UART, SPI, I2C, GPIO, ADC와 같은 저수준 주변 장치 드라이버(low-level peripheral drivers)를 작성하며 이루어졌습니다. 이것들은 화려하지는 않지만, 임베디드 작업이 요구하는 규율을 가르쳐주는 기초적인 구성 요소들입니다:

• 모든 바이트와 모든 밀리와트(milliwatt)가 중요합니다. 자원이 제한된 MCU (Microcontroller Unit)에서는 메모리나 전력을 소홀히 다룰 여유가 없습니다.
• 타이밍(Timing)은 최우선 순위 요소입니다. 50마이크로초(microseconds) 늦게 발생하는 인터럽트(interrupt) 하나가 시스템 전체를 망가뜨릴 수 있습니다.
• 하드웨어는 언제나 옳습니다. 당신의 코드와 오실로스코프(oscilloscope)의 결과가 일치하지 않는다면, 오실로스코프가 승리합니다.

마지막 교훈은 제 머릿속에 깊이 박혔습니다. 저는 J-Link 디버거(debugger)와 로직 분석기(logic analyzer)를 가지고 긴 시간을 보내며, 실제 핀(pin)에서 흐르는 실제 신호를 관찰했습니다.

• 태스크 설계는 곧 시스템 설계입니다 (Task design is system design). 무엇을 별도의 스레드(thread)로 만들 것인지, 그리고 그 우선순위(priority)를 어떻게 설정할 것인지를 결정하는 것은 여러분이 내리는 가장 중요한 아키텍처적 선택 중 하나입니다.
• 공유 상태(Shared state)는 위험합니다. 태스크 간 통신(Inter-task communication) — 큐(queues), 세마포어(semaphores), 뮤텍스(mutexes) — 가 존재하는 이유는 두 태스크가 잘못된 순간에 동일한 변수에 접근하는 것이 곧 발생하기 직전의 버그이기 때문입니다.
• 결정론(Determinism)이 단순한 속도보다 중요합니다. 미션 크리티컬(mission-critical) 시스템에서는 때로는 빠르고 때로는 늦는 응답보다, 항상 제시간에 맞춰 이루어지는 응답이 더 중요합니다.

베어메탈(bare-metal)에서 RTOS로 넘어가는 것은 단일 기계를 만드는 것에서 오케스트라를 지휘하는 것으로 넘어가는 기분이었습니다. 개별 악기들은 이전에 제가 작성했던 드라이버(driver)들과 같았지만, 이제는 그것들이 서로 박자에 맞춰 함께 연주해야 했습니다.

장치에 목소리를 부여하기:
연결성(Connectivity)과 IoT
감지하고 계산할 수 있는 장치는 유용합니다. 하지만 통신할 수 있는 장치는 강력합니다.
제 여정의 다음 장은 연결성(connectivity)이었습니다. 임베디드 장치들이 더 넓은 세상과 신뢰할 수 있게, 그리고 무엇보다 아주 적은 전력 예산(power budget) 내에서 대화할 수 있도록 만드는 것이었습니다. 이는 단거리 연결을 위한 BLE와, nRF9160과 같은 플랫폼을 활용하여 장거리 저전력 산업용 원격 측정(telemetry)을 수행하는 NB-IoT를 다루는 것을 의미했습니다.
IoT 펌웨어(firmware)는 베어메탈 작업에서는 걱정할 필요가 없었던 완전히 새로운 종류의 문제들을 가져왔습니다:

• 네트워크는 기본적으로 신뢰할 수 없습니다. 연결은 끊어집니다. 패킷(packet)은 유실됩니다. 여러분의 펌웨어는 영원히 멈춰버리는 대신 우아하게 복구(recover)할 수 있어야 합니다.
• 전력이 실질적인 제약 사항입니다. 배터리로 이틀 동안 작동하는 장치는 프로토타입(prototype)입니다. 몇 달 동안 작동하는 장치가 제품입니다. 모든 무선 송신은 전력 예산에서의 인출이므로, 공격적으로 슬립(sleep) 모드를 사용하고 반드시 필요할 때만 깨어나도록(wake) 배워야 합니다.
• 무선 업데이트(Over-the-air updates)는 선택 사항이 아닙니다. 장치가 현장에 배치되면, 장치를 벽돌(bricking)로 만들지 않고 펌웨어를 업데이트할 수 있는 안전한 방법이 필요합니다.

nRF9160에서 Zephyr를 사용하여 저전력 모니터링 시스템을 구축한 경험은 저에게 장치의 전체 수명 주기(lifecycle)를 생각하도록 가르쳐 주었습니다. 단순히 "내 책상 위에서 작동하는가"가 아니라, "몇 달 후에도 관리자 없이 계속 작동할 것인가"를 고민하게 된 것입니다.

엣지를 생각하게 만들기: TinyML과 엣지 AI (Edge AI)

여기서부터 여정이 흥미로워집니다.
오랫동안 "스마트" 장치들은 실제로 스마트하지 않았습니다. 그저 가공되지 않은 데이터(raw data)를 클라우드 서버로 전송했을 뿐이며, 지능(intelligence)은 다른 어딘가에 존재했습니다. 그 모델에는 지연 시간(latency), 대역폭(bandwidth), 개인정보 노출, 그리고 존재하지 않을 수도 있는 네트워크 연결에 대한 강력한 의존성이라는 실제적인 비용이 따릅니다.
엣지 AI (Edge AI)는 이를 뒤집습니다. 데이터를 지능으로 보내는 대신, 지능을 데이터로 가져오는 것입니다. 즉, 센서 바로 옆에 있는 마이크로컨트롤러(microcontroller)에서 머신러닝 (machine learning) 모델을 직접 실행하는 것입니다.
과제는 매우 가혹합니다. 수 킬로바이트(KB)의 RAM을 가진 장치에 어떻게 신경망(neural network)을 집어넣을 수 있을까요? 그 답은 TinyML입니다. 이는 클라우드 왕복 과정 없이 밀리초(ms) 단위로 추론(inference)을 수행하는 양자화(quantized)되고 고도로 최적화된 모델(종종 8비트 정수형)을 의미합니다. TensorFlow Lite 및 Edge Impulse와 같은 도구들이 이를 가능하게 하지만, 진정한 엔지니어링은 트레이드오프(tradeoffs)에 있습니다. 즉, 모델 크기 대 정확도, 추론 속도 대 전력 소모 사이의 균형입니다.
엣지 AI (Edge AI)를 제대로 이해하게 된 프로젝트는 **스마트 발 무게 분석 시스템 (Smart Foot Weight Analytics system)**이었습니다. 이는 고밀도 힘 센서 어레이(force-sensor array)를 사용하여 자세 불균형과 근골격계 문제의 조기 지표를 감지하는 휴대용 ML 기반 장치였습니다. 임상 등급의 진단은 보통 비싸고 휴대할 수 없는 장비를 필요로 합니다. 압력 중심(center-of-pressure) 궤적을 추출하고 장치 내에서 분류(classification)를 실행함으로써, 조기 진단을 접근 가능하고 휴대 가능하게 만드는 것이 목표였습니다. 이것이 바로 엣지(edge)의 약속입니다. 데이터 센터에 갇혀 있는 것이 아니라, 필요한 곳에 지능이 존재하는 것입니다.

또한 해커톤 기간 동안 이 분야의 더 실험적인 측면을 탐구할 기회도 있었습니다. 바로 물리적 하드웨어에 대화형 AI 음성 에이전트(conversational AI voice agents)를 배포하는 것이었는데, ElevenLabs 기반의 에이전트를 Raspberry Pi 4에서 실행함으로써 임베디드 하드웨어와 클라우드 AI를 하나의 상호작용 시스템으로 연결했습니다. 규모는 다르지만 핵심 아이디어는 동일합니다. 바로 물리적 세계에 지능을 부여하는 것입니다.

이 여정이 내게 가르쳐준 것들

베어메탈(bare metal)부터 엣지(edge)에 이르기까지의 여정을 되돌아보니, 모든 계층을 관통하는 몇 가지 교훈이 있습니다.

1. 기초는 복리로 쌓인다. 베어메탈에서 레지스터(register) 및 타이밍(timing)과 씨름하며 배운 모든 것은 RTOS로, 그다음에는 IoT로, 그리고 엣지 AI(Edge AI)로 넘어갔을 때 결실을 보았습니다. 기초는 결코 뒤처지는 것이 아니라, 그 위에 쌓아 올리는 것입니다.
2. 추상화(abstraction)는 도구이지 진리가 아니다. RTOS, HAL(Hardware Abstraction Layer), 그리고 ML(머신러닝) 프레임워크는 강력하지만, 그 아래의 하드웨어는 결코 사라지지 않습니다. 최고의 디버깅(debugging)은 여전히 "실리콘(silicon)이 실제로 무엇을 하고 있는가?"라는 질문에서 시작됩니다.
3. 제약 조건이 더 나은 엔지니어를 만든다. 제한된 메모리, 제한된 전력, 그리고 실시간 마감 시간(real-time deadlines)은 명확성을 강요합니다. 마이크로컨트롤러(microcontroller) 위에서는 허술한 설계를 숨길 곳이 없습니다.
4. 신뢰성이 진짜 제품이다. 누구나 장치를 한 번 작동하게 만들 수는 있습니다. 하지만 관리자 없이 수개월 동안 매번 작동하게 만드는 것 — 그것이 바로 중요한 엔지니어링입니다.

내가 나아갈 방향

여정은 끝나지 않았습니다. 현재 저는 디지털 신호 처리(Digital Signal Processing, DSP) — FFT(고속 푸리에 변환) 기반의 스펙트럼 분석, 디지털 필터링, 변조 방식(modulation schemes) — 분야를 더 깊게 파고들고 있으며, **SDR(Software Defined Radio) 및 SATCOM(위성 통신)**에 대한 관심도 커지고 있습니다. DSP, 통신 시스템, 그리고 엣지 AI 사이에는 자연스러운 수렴이 일어나고 있으며, 저는 그 교차점에서 무언가를 구축하고 싶습니다. 즉, 단순히 세상을 감지하는 것을 넘어 세상의 신호를 이해하는 장치를 만드는 것입니다.

깜빡이는 단 하나의 LED부터 지능형 엣지 장치에 이르기까지, 관통하는 핵심은 항상 동일했습니다. 바로 실리콘이 당신이 의도한 대로, 실제 세계에서 신뢰할 수 있게 정확히 작동하도록 만드는 데서 오는 만족감입니다.

저는 임베디드 시스템 (Embedded Systems), 펌웨어 (Firmware), ARM Cortex-M, RTOS, IoT, TinyML, 그리고 DSP에 대해 글을 씁니다. 만약 여러분이 이 분야에서 무언가를 작업하고 있거나, 혹은 그저 전문적인 이야기를 나누고 싶다면, 기꺼이 소통하고 싶습니다.

포트폴리오 (Portfolio): shafqat-ashraf.vercel.app
LinkedIn: muhammad-shafqat-ashraf
GitHub: Shafqat-16

이 글이 유익했다면 ❤️를 남기거나 댓글을 달아주세요. 그리고 임베디드 스택 (Embedded Stack) 중 다음번에 어떤 부분에 대해 글을 쓰길 원하는지 알려주세요.