클라우드 없이, 벤더 종속 없이: 직접 제어하는 하드웨어에서 AI 에이전트 실행하기

AI 에이전트(AI agents)를 구축하는 대부분의 사람들은 빌려온 인프라 위에서 작업하고 있습니다. 모델은 타인의 GPU에서 실행됩니다. 게이트웨이(Gateway)는 관리형 서비스(Managed service)입니다. 자동화 스크립트는 다음 분기에 가격 정책을 변경할 SaaS 플랫폼에 존재합니다. 전체 스택(Stack)은 임대된 상태이며, 제공업체가 결정할 때마다 비용은 상승합니다.

이것을 구축하는 다른 방법이 있습니다. 설정에는 더 많은 노력이 필요합니다. 하지만 그 대가로 당신은 그것을 소유하게 됩니다.

"스택을 소유한다"는 것이 실제로 의미하는 것

여기서 소유권은 이념적인 것이 아닙니다. 운영적인 것입니다.

자체 게이트웨이를 실행하면, 가동 시간(Uptime)을 제어하고, 라우팅(Routing)을 제어하며, 에이전트가 호출하는 모델을 제어할 수 있습니다. 물리적 에이전트 엔드포인트(Endpoints)가 직접 플래싱(Flashing)한 마이크로컨트롤러(Microcontrollers)에서 실행될 때, 지연 시간(Latency)은 클라우드 API로의 왕복 시간이 아닌 유선 속도(Wire speed)가 됩니다. 자동화 레이어(Automation layer)가 직접 작성한 Python 및 Bash 스크립트라면, 무슨 일이 일어나고 있는지 모든 줄을 읽을 수 있습니다.

그 대안은 검사할 수 없는 추상화(Abstractions)의 집합이며, 만질 수 없는 하드웨어에서 실행되고, 현재 결제 주기 이후에는 보장되지 않는 가격 모델을 따르는 것입니다.

셀프 호스팅(Self-hosted) 스택에는 실제 비용이 따릅니다. 직접 구축해야 하기 때문입니다. 하지만 한 번 구축하면 됩니다.

하드웨어 레이어: ESP32 기반의 물리적 에이전트

웹 API만 호출할 수 있는 AI 에이전트는 물리적 에이전트가 아닙니다. 그것은 라우팅이 잘 되는 챗봇(Chatbot)일 뿐입니다.

물리적 에이전시(Physical agency)는 에이전트가 세상의 무언가를 작동시킬 수 있을 때 시작됩니다. 서보 모터(Servo motor), 릴레이(Relay), 센서 읽기(Sensor read), GPIO 토글(Toggle) 등이 그것입니다. 이를 위해서는 LLM의 도구 호출(Tool-calling) 인터페이스와 하드웨어와 통신하는 마이크로컨트롤러 사이의 브리지(Bridge)가 필요합니다.

표준적인 접근 방식은 ESP32에서 실행되는 WebSocket 데몬(Daemon)을 사용하여 구조화된 JSON 명령을 수신하고, 이를 하드웨어 동작에 매핑하며, 상태를 반환하는 것입니다. LLM 측면에서는 도구 호출(Tool call)로 보입니다. ESP32 측면에서는 소켓(Socket) 상의 메시지로 보입니다. 어느 레이어도 상대방이 내부적으로 어떻게 작동하는지 알 필요가 없습니다.

ESP32는 이를 위해 적합한 보드입니다. 칩 내부에 Wi-Fi가 탑재되어 있고, 외부 하드웨어 없이도 WebSocket 서버를 실행할 수 있을 만큼 충분한 RAM을 갖추고 있으며, 400달러짜리 IDE 라이선스가 필요 없는 개발 생태계를 보유하고 있습니다. ESP32-WROOM-32 [AFFILIATE: ESP32-WROOM-32]는 표준 개발 폼 팩터(form factor)입니다. 더 많은 GPIO 여유 공간이 필요한 경우에는 펌웨어 아키텍처를 변경하지 않고도 ESP32-S3가 이를 처리할 수 있습니다.

데몬(Daemon)은 한 가지 일만 수행합니다. 즉, 소켓 메시지를 하드웨어 호출(hardware calls)로 변환하는 것입니다. 가능한 한 상태를 유지하지 않는(stateless) 방식으로 유지하세요. 만약 에이전트(Agent)가 잘못된 형식의 명령을 보내면, 데몬은 이를 로그에 기록하고 에러 페이로드(error payload)를 반환합니다. 재시도 로직(retry logic)은 에이전트가 처리합니다. 펌웨어는 영리할 필요가 없습니다.

// 최소한의 WebSocket 메시지 핸들러 패턴
void onWebSocketMessage(uint8_t *data, size_t len) {
  StaticJsonDocument<256> doc;
...

WebSocket 서버는 기본적으로 81번 포트에서 실행됩니다. config.h에서 포트를 설정 가능하게 유지하세요. 동일한 네트워크에 4개의 ESP32가 있는 경우, 펌웨어를 다시 플래싱(reflashing)하지 않고도 포트를 통해 이들을 구분하고 싶을 것입니다.

게이트웨이 계층: 24/7 로컬 실리콘 (Local Silicon)

WebSocket 데몬은 통신할 대상이 필요합니다. 그 대상은 바로 여러분의 로컬 AI 게이트웨이(gateway)입니다. 이는 저전력 SBC(Single Board Computer)에서 실행되는 지속적인 프로세스로, 에이전트의 요청을 수락하고, 이를 올바른 모델로 라우팅하며, 응답 라이프사이클(lifecycle)을 처리합니다.

여기서 OpenClaw는 게이트웨이 소프트웨어 역할을 합니다. 이는 Linux 사용자 공간(userspace)이 있고 프로세스를 유지할 수 있을 만큼 충분한 RAM이 있는 환경이라면 무엇이든에서 실행됩니다. Raspberry Pi 4가 이를 처리할 수 있으며, 오래된 Intel NUC도 마찬가지입니다. 관리형 추론 서비스(managed inference service) 한 달 비용보다 저렴한 보드 하나로 충분히 커버할 수 있습니다.

로컬 전용 방식의 문제는 노출(exposure)입니다. 만약 게이트웨이가 LAN에서만 연결을 수락한다면, 에이전트는 외부에서 게이트웨이에 도달할 수 없습니다. 표준적인 해결책은 VPN 터널(VPN tunnel)이지만, 이는 지연 시간(latency)을 추가하고 어딘가에 VPN 서버를 구축해야 합니다. 이 사용 사례에 대한 더 나은 해결책은 Cloudflare Tunnel입니다.

Cloudflare Tunnel은 로컬 머신에서 Cloudflare의 에지 (edge)로 나가는 방향(outbound-only)의 암호화된 연결을 생성합니다. 열려 있는 포트도, 고정 IP도, 라우터 설정도 필요하지 않습니다. 터널 프로세스는 게이트웨이와 동일한 SBC (Single Board Computer) 상에서 systemd 서비스로 실행됩니다.

# cloudflared 설치
curl -L https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg > /dev/null
echo 'deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared any main' | sudo tee /etc/apt/sources.list.d/cloudflared.list
...

터널 설정은 서브도메인을 OpenClaw가 리스닝(listening) 중인 localhost:8080에 매핑합니다. 에이전트들이 https://your-subdomain.yourdomain.com을 호출하면, 괜찮은 수준의 가정용 인터넷 연결 환경에서 100ms 미만의 오버헤드로 로컬 게이트웨이에 요청이 도달합니다.

게이트웨이와 터널 프로세스 모두에 대해 터널 서비스를 Restart=always 설정이 포함된 systemd 유닛(unit)과 결합하십시오. SBC가 재부팅될 때, 두 서비스 모두 별도의 개입 없이 다시 시작됩니다.

# /etc/systemd/system/openclaw.service
[Unit]
Description=OpenClaw AI Gateway
...

이제 게이트웨이는 Cloudflare 무료 티어(free tier)를 넘어선 관리형 서비스(managed service)에 대한 의존성 없이, 여러분이 소유한 하드웨어에서 실행되며 어디에서나 접속 가능합니다.

자동화 계층: 이를 하나로 묶어주는 스크립트들

하드웨어 계층과 게이트웨이 계층은 인프라(infrastructure)입니다. 자동화 계층은 이들을 일상적으로 유용하게 만들어 주는 요소입니다.

셀프 호스팅(self-hosted) AI 스택에서 운영 작업의 대부분은 추론(inference) 호출이 아닙니다. 그것은 주변의 스캐폴딩(scaffolding, 구조물): 상태 확인(health checks), 로그 로테이션(log rotation), 모델 라우팅 규칙(model routing rules), 에이전트 오케스트레이션 트리거(agent orchestration triggers), 응답 파싱(response parsing), 오류 복구(error recovery) 등입니다. 이것들은 모두 이미 해결된 문제들입니다. 또한, 깨끗하게 정리된 패턴 모음이 공개된 적이 없기 때문에 대부분의 개발자가 매번 처음부터 다시 작성하게 되는 문제들이기도 합니다.

이 스택에서 중요한 스크립트들은 몇 가지 범주로 나뉩니다:

서비스 관리 (Service management): 게이트웨이 상태를 확인하고, 멈춘 프로세스를 재시작하며, 디스크가 가득 차기 전에 로그를 순환(rotate)시키고, cloudflared가 단순히 느린 것인지 아니면 실제로 무언가 고장 난 것인지 판단하여 사용자에게 알림(page)을 보내는 셸 스크립트 (Shell scripts)입니다.

에이전트 오케스트레이션 (Agent orchestration): 특정 에이전트 클래스에 대한 요청 생명주기 (request lifecycle)를 처리하는 Python 래퍼 (wrappers)입니다. 작업 설명을 입력받아 구조화된 결과를 반환하며, 내부적으로 재시도 (retries) 및 타임아웃 (timeout) 로직을 처리합니다.

데이터 파이프라인 유틸리티 (Data pipeline utilities): 에이전트에 컨텍스트 (context)를 공급하기 위한 스크립트입니다. 문서를 청킹 (chunking)하고, 검색 인덱스 (retrieval indexes)를 구축하며, 데이터가 모델에 도달하기 전에 입력 데이터를 정제 및 정규화 (cleaning and normalizing)합니다.

ESP32 프로비저닝 (ESP32 provisioning): 단일 머신에서 여러 보드에 펌웨어를 대량으로 플래싱 (mass-flashing)하기 위한 Bash 스크립트입니다. 하드코딩된 값 대신 파티션 쓰기 (partition writes)를 통해 장치별 설정을 지정합니다.

이 모든 스크립트에 적용되는 원칙은 다음과 같습니다: 한 가지 일만 수행해야 하며, 하드코딩된 경로 대신 환경 변수 (environment variables)나 인자 (arguments)로부터 입력을 받아야 하고, 잘못된 출력을 조용히 생성하는 대신 유용한 에러 메시지와 함께 명확하게 실패 (fail loudly)해야 합니다.

# 에이전트 오케스트레이션 래퍼 패턴 (Agent orchestration wrapper pattern)
import anthropic
import os
...

인프라 상태를 처리하는 스크립트는 멱등성 (idempotent)을 유지해야 합니다. 상태 확인 스크립트를 두 번 실행한다고 해서 두 개의 알림이 생성되어서는 안 됩니다. 이미 올바르게 플래싱된 보드에 프로비저닝 스크립트를 실행하면 깔끔하게 종료되어야 합니다. 이는 이론적으로는 당연하지만, 실제로는 끊임없이 생략되곤 합니다.

종합하기

전체 스택은 다음과 같습니다: WebSocket 데몬 (daemons)을 실행하는 ESP32 보드들, LAN을 통해 SBC 상의 로컬 게이트웨이에 연결됨, Cloudflare Tunnel을 통해 노출됨, 그리고 모든 것을 실행 가능하고 관찰 가능하게 (observable) 유지하는 자동화 스크립트 세트에 의해 관리됨.

이 중 어느 것도 상당한 비용이 드는 클라우드 계정을 필요로 하지 않습니다. Cloudflare Tunnel은 개인 용도로 무료입니다. SBC는 일회성 비용입니다. ESP32 보드는 대량 구매 시 개당 10달러 미만입니다. 그리고 스크립트는 온전히 당신의 것입니다.

초기 설정 비용은 실제로 존재합니다. 첫 번째 인스턴스를 올바르게 실행하기 위해 주말 내내 작업해야 할 수도 있지만, 일단 스크립트가 존재하면 이후 배포에는 하루도 채 걸리지 않습니다. 그 이후에는 새로운 물리적 에이전트 엔드포인트(endpoint)를 추가하는 데 드는 한계 비용(marginal cost)이 마이크로컨트롤러(microcontroller) 가격과 한 시간 정도의 설정 비용뿐입니다.

에이전트를 몇 개 이상 운영하게 되면, 이러한 계산 방식은 관리형 인프라(managed infrastructure)의 가격 책정 방식과는 다르게 보일 것입니다.

이 스택을 전체적으로 다루는 세 가지 가이드는 numbpilled.gumroad.com에서 확인할 수 있습니다: 물리적 에이전트를 위한 ESP32 WebSocket 데몬 설정, 오프그리드(off-grid) OpenClaw 게이트웨이 배포, 그리고 AI 자동화 워크플로(workflow)를 위한 Python 및 Bash 스크립트 모음입니다. 각 가이드는 독립적이며, 이들을 함께 사용하면 여기서 설명한 전체 스택을 모두 다룰 수 있습니다.