REPL만 있으면 충분합니다.

AI 에이전트가 하드웨어를 직접 제어할 수 있게 하는 개방형 표준에 대한 19세 소년의 제안.

문제점: 화면 속에 갇힌 AI 에이전트

AI 에이전트는 코드를 작성하고, 웹을 검색하며, 서버를 배포하고, 데이터베이스를 관리할 수 있습니다. 컨테이너 내부에서는 믿을 수 없을 정도로 유능합니다.

하지만 여러분이 좋아하는 AI에게 릴레이(relay)를 작동시키거나, 온도 센서를 읽거나, I2C 버스를 스캔해달라고 요청하면 할 수 없습니다. 방법을 몰라서가 아닙니다. machine.Pin(5, Pin.OUT)이 무엇을 하는지는 정확히 알고 있습니다. 단지 그 코드를 실행할 곳이 없을 뿐입니다.

AI 에이전트에게는 물리적 실행 터미널(physical execution terminal)이 부족합니다.

CLI 도구들은 LLM에게 디지털 세계에서의 손(df -h, pip install, docker compose up)을 제공했습니다. 임베디드 시스템은 현실 세계에서의 손(GPIO.on(), ADC.read(), I2C.scan())을 제공할 수 있습니다. 하지만 에이전트가 하드웨어와 어떻게 통신해야 하는지에 대한 표준은 아무도 정의하지 않았습니다.

그것이 바로 PAL이 존재하는 이유입니다.

현황: 기존 방식과 그 한계

ESP-Claw (Espressif 공식)

Espressif의 "Chat Coding" 프레임워크는 ESP32-S3 위에 완전한 AI 에이전트를 구현합니다 — ReAct 루프, LLM 호출, 도구 레지스트리(tool registry), IM 채널(Telegram, WeChat), 이벤트 라우터(Event Router)를 포함합니다. 인상적인 엔지니어링이지만, 잘못된 아키텍처이기도 합니다.

• 에이전트가 MCU에서 실행됨 — 최소 8MB PSRAM 필요, $15 이상의 BOM(Bill of Materials) 비용 발생
• Lua 사용 — LLM은 Lua보다 Python을 50배 더 정확하게 생성함
• 사전 등록 필요 — 모든 GPIO는 Lua 도구 모듈로서 C 구조체(struct)로 등록되어야 함
• MCU에서 LLM API 호출 — 단 한 번의 네트워크 타임아웃으로 전체 FreeRTOS 태스크가 중단될 수 있음

mimiclaw

더 가벼운 ESP32 에이전트입니다. 동일한 아키텍처를 가지며, GPIO 버그가 확인되었습니다. 장난감 수준(Toy-grade)입니다.

Bare-metal C + UART 명령

매우 견고합니다. 하지만 새로운 동작을 추가하려면 C 작성 → 컴파일 → 플래싱(flash) → 재부팅 과정을 거쳐야 합니다. 최소 10분이 소요됩니다. 에이전트는 그 속도로 반복(iterate)할 수 없습니다.

Raspberry Pi + GPIO

어디에나 Python 라이브러리가 있지만, 30초의 부팅 시간, 5W의 전력 소모, $35 이상의 비용, 하드 실시간(hard real-time) 미지원 등의 문제가 있습니다. 릴레이 하나를 제어하기에는 과합니다(Overkill).

핵심 통찰: MicroPython REPL이 바로 에이전트 인터페이스다

모두가 놓치고 있는 사실이 여기 있습니다: Python의 REPL과 AI 에이전트의 상호작용 모델은 동형(isomorphic)입니다.

REPL 루프:                    에이전트 루프:
  >>> 코드 입력                 태스크 수신
  실행                         추론 → 코드 생성
...

도구 레지스트리(Tool registry)가 필요 없습니다. JSON 스키마(JSON schema)도 필요 없습니다. 스킬 레지스트리(Skill Registry)도 필요 없습니다. REPL은 세상에서 가장 단순한 IPC(Inter-Process Communication, 프로세스 간 통신)입니다.

그리고 Python은 어떻습니까? LLM이 가장 잘 생성하는 언어입니다. Lua가 GitHub 공개 저장소의 0.5% 미만인 것에 비해, Python은 25%를 차지합니다. Claude는 학습 데이터에서 수백만 개의 machine.Pin() 호출을 보았습니다. 이 코드를 어떻게 작성해야 하는지 이미 알고 있습니다.

아키텍처: 두 개의 코어로 구성된 PAL

┌──────────────────────────────────────┐
│         Cloud Agent (AstrBot)         │  ← 추론, 계획
└──────────────┬───────────────────────┘
...

Core 0은 브레이크 페달입니다. 절대 변하지 않습니다. Core 1은 스티어링 휠(핸들)입니다. 에이전트는 자신이 원하는 방식대로 이를 잡을 수 있습니다.

에이전트가 무한 루프를 작성한다면? Core 0이 하트비트 타임아웃(heartbeat timeout)을 감지하여 Core 1 VM을 재시작합니다. 에이전트가 시스템 핀(system pins)에 접근하려고 시도한다면? machine.Pin()이 OSError를 반환합니다. 에이전트가 충돌(crash)한다면? Core 0은 계속 실행됩니다. 물리적 제어 링크는 절대 끊어지지 않습니다.

프로토콜: Python을 실행하는 JSON

도구 스키마(tool schemas)도, 사전 등록(pre-registration)도 없습니다. 그저 WebSocket을 통해 전달되는 Python 코드뿐입니다:

에이전트 → 터미널:

{
  "version": "1",
  "id": "msg_001",
...

터미널 → 에이전트:

{
  "version": "1",
  "id": "msg_001",
...

그게 전부입니다. WiFi를 통한 한 번의 왕복(round-trip): <10ms. Python 실행: <1ms.

왜 온디바이스(On-Device) 에이전트가 아닌 클라우드 에이전트인가

1. 뇌와 손은 서로 다른 하드웨어를 사용해야 합니다

물리적 실행에는 결정론적 동작(determinism), 낮은 지연 시간(low latency), 24/7 안정성이 필요합니다. AI 추론에는 탄력적 컴퓨팅(elastic compute), 대용량 메모리, 빈번한 반복(iteration)이 필요합니다. 이 두 가지를 하나의 MCU에 강제하는 것은 하나의 칩에 서로 모순되는 두 가지 일을 하라고 요구하는 것과 같습니다.

2. 하나의 뇌, 여러 개의 손

단일 클라우드 에이전트 (Cloud agent)는 공장 바닥 전체에 걸쳐 수십 개의 PAL 터미널을 관리할 수 있습니다. 반면, 디바이스 온 에이전트 (Agent-on-Device) 방식은 노드당 하나의 에이전트 인스턴스가 필요하며, 전체적인 관점 (Global perspective)을 가질 수 없습니다.

3. 뇌를 언제든 멈출 수 있습니다

클라우드 에이전트 (Cloud agent)가 오작동하나요? WebSocket을 끊으십시오. 그것으로 끝입니다. MCU에서 디바이스 온 에이전트 (Agent-on-Device)가 오작동하나요? 하드웨어 워치독 (Hardware watchdog)이 트리거될 때까지 기다려야 합니다. 그것이 유일한 복구 메커니즘입니다.

4. 기술, MCP, 도구들은 클라우드 인프라에서 실행됩니다

Hermes 스타일의 기술 축적 (Skill accumulation), 벡터 데이터베이스 (Vector databases), MCP 도구 체인 (MCP tool chains), SQLite 지속성 (SQLite persistence) — 이 모든 것은 성숙한 AI 인프라입니다. 이 중 그 어떤 것도 8MB의 PSRAM에 억지로 구겨 넣을 필요가 없습니다.

PAL이란 무엇인가, 그리고 무엇이 아닌가

PAL은 다음과 같습니다:

• ✅ 에이전트 친화적인 임베디드 터미널 표준 (ESP32급, MicroPython, 듀얼 코어)
• ✅ 하드웨어에서 Python 코드를 실행하기 위한 JSON 프로토콜
• ✅ 안전 모델 (5계층 방어, 핀 소유권, Core 0 격리)

PAL은 다음과 사항이 아닙니다:

• ❌ I2C/SPI 버스 프로토콜
• ❌ 에이전트 프레임워크 (Agent framework)
• ❌ 하드웨어 레퍼런스 디자인 (Hardware reference design)
• ❌ 특정 MCU 또는 주변 장치에 종속됨

현재 상태

PAL은 **초안 사양 (draft specification, v0.1)**입니다. 저는 안후이 과학기술대학교 (Anhui University of Science and Technology)의 신입생입니다. 레퍼런스 구현체 (ESP32-S3 Core 0/1)는 현재 개발 중입니다.

참고: 저는 현재 시험을 준비 중이며 기술적인 아이디어를 영어로 유창하게 표현하는 법을 배우고 있는 단계이기에, 이 포스트의 초안 작성과 다듬기에는 Claude의 도움을 받았습니다. 모든 아이디어, 아키텍처, 그리고 PAL 사양 자체는 저의 독자적인 작업물입니다.

이 사양은 논의에 열려 있습니다. 저는 다음 사항들에 대한 의견을 찾고 있습니다:

• 아키텍처에 대한 피드백
• Core 0 경계 정의
• 다중 터미널 조정 (Multi-terminal coordination)
• MCP 통합 (리포지토리의 Phase 1-4 로드맵)

링크

• GitHub (International): github.com/hanasite/pal-spec
• Gitee (China): gitee.com/yosakun/pal-spec

_"미래를 예측하는 가장 좋은 방법은 그것을 정의하는 것이다."

— PAL v0.1, 2026