Zeno + speak-mcp

16GB Mac에서 35B 로컬 AI를 돌리는 흥미로운 실험, 그러나 아직은 실험에 가깝다

최근 Icosa Computing이 공개한 Zeno라는 macOS용 로컬 AI를 설치해 보았다. 회사 설명에 따르면 전체 MoE expert를 메모리에 올리지 않고, 사용되지 않는 expert weight는 SSD에 두었다가 필요한 expert만 RAM으로 읽어들이는 방식을 사용한다. 따라서 inactive expert를 SSD에 보관하고 필요한 expert만 가져온다. Icosa 역시 Reddit에서 Zeno가 inactive MoE expert weights를 disk에 유지하고 active expert만 RAM으로 불러온다고 설명하고 있다.

뭐… 설명이 어떻든, 결국 내가 하고자 하는 일인문구조학에는 쓸수가 없다. Qwen 모델의 문제인지, 아니면 하려는 일의 사이즈가 이 방식에 맞지 않는지 솔직히 잘 모르겠다.

매 턴마다 영어/한국어를 macOS TTS로 출력하게 했다

앞서와는 다른 목적으로, 로컬에서 음성으로 말하고 음성으로 듣기 위해 speak-mcp를 조금 뜯어고쳐 각 언어마다 다른 Voice를 쓰게 했는데, AGENTS.md 규정을 따를 때가 있는가 하면, 개무시하고 기본적으로 박혀있는 system prompt를 따라가곤 했다. Qwen 35B 모델의 멍청함이란;;; 휴… 인수가 2개인 MCP 도구를 호출하는 것도 매번 명시적으로 지정해야만 제대로 읽는다. 읽는다해도 한국어 Voice로는 영어 단어나 문장 표현을 병맛스럽게 읽기 때문에 이걸 써먹기는 정말… 애매;; 하다. Voice가 영어인 경우 선택지는 좀 있으나, 다른 언어가 섞이면 영락없이 해당 부분은 무음이 된다.

사용할수록 Qwen 모델의 Weight를 변화시킨다는데… 글쎄; 그걸 확인할 방법도 UI도 없다. 가지고 노는 정도 외에, 제품으로서는 아직 추천할 정도가 아님. 그러나 32B 모델이 이렇게 돌아간다는 건 고무적인 일임에는 틀림없다. 누군가에겐 쓸만할지도.

더 흥미로운 것은 LMShop이다

LMShop은 현재 IBM Granite 4B, Google Gemma 12B, Qwen 3.6 35B 등을 기반으로 사용자가 올린 문서에서 training set을 만들고 LoRA tuning을 한 뒤 결과 모델을 GGUF로 다운로드하게 한다. 그리고 이 모델을 다시 Zeno에서 로컬로 사용하는 그림을 그리고 있다. Zeno/LMShop 이 오픈소스가 된다면 로컬 AI를 구동하는 방법에 획기적인 방향전환이 일어날 수 있겠다는 생각이 든다.

Saffron Ink – VSCode Theme

Gray background: Github Light Theme – Gray 테마를 기반으로 내 취향에 맞게 수정하였다.

  • 원래 테마보다 좀 더 어두운 배경, 강한 텍스트 대비를 주었다.
  • 선택영역 색상 및 커서 색상을 쪼매 튀게.
  • 각 영역의 border-radius 제거.
  • scrollbar 색상을 배경색 대비 3% 어둡게.

https://marketplace.visualstudio.com/items?itemName=andrwj.saffron-ink

Pebble QEMU Development on uConsole with Physical Controls

의도

기본 생각은 단순하다:

uConsole의 Joystick Keys 와 물리키보드를 이용해 Pebble QEMU Emulator에 직접 버튼/터치/가속도데이터 등을 전송하여 개발/디버깅 하겠다는 것이다.

왼쪽 이미지에 보이는 Pebble앱은 한국어(한글) 모르스부호 연습기 앱인데, 단순히 한글 자모를 출력하는게 아니라 한글 오토마타를 내장해서 모르스부호를 입력하면 한국어 문장이 조립된다. 죽도록 버튼을 누르지 않고 화면 터치만 사용하게 했기 때문에, 제대로 동작하는지 확인하려면 Pebble Time 2 실물기기에서 테스트하는 것이 가장 정확하겠지만, 심각한 배터리 사용이 걱정스러웠다. 실제 기기를 오래쓰려면 이런 개발 과정을 Emulator에서 실행해야하지만, macOS 상태에서 테스트하는 것보다, 벽에 달려 놀고있는 uConsole을 활용하자는 생각이 떠올랐다.

구현 아이디어

GamePad 키를 QEMU로 전송하는 방식은 오래전에 이미 사용했던 방법이 있다. RetroPie Joy2Key 방식이다. 그때는 AI가 없어서 직접 코드를 내가 원하는 방향으로 쓰기위해 시간을 제법 쏟아 부었던 적이 있으나, 지금은 뭐 AI 도움을 받아 거의 막힘이 없다. 구현 제한 사항은, 반드시 페블 앱에서 발생하는 Audio를 QEMU를 통해 들을 수 있어야 한다는 점이다. 그게 아니면, 이딴 건 의미 없다.

삽질로 드러난 아이디어 구현의 걸림돌

① 실제 Touch 처럼 자유롭게 입력을 넣는 건 좀 더 시간이 걸리듯.

  • Touch 인식은 QEMU 앱 소관이라서 외부에서는 Virtual Touch Event Signal 정도만 날릴 수 있다.
  • QEMU 화면이 resize 되면 touch 위치 인식 불능. Pebble Firmware를 수정하거나 페블 앱을 작성할 때 상대크기로 작성해야 한다.
  • Ctrl+마우스 움직임 또는 Ctrl+Drag 등의 키 조합을 가상 이벤트로 날릴 수 밖에 없다.

② 입력 종류마다 다른 방식으로 처리해야 함.

  • QEMU와 통신 방식이 4가지: pypkjs, WebSocket, QMP(unix socket), raw_tcp
  • 포트는 두가지: 포트마다 적절한 시그널을 보내는게 제한된다. 올바르지 않은 채널에 시그널 부어버리면 페블앱을 전환할 때 마다 WebSocket이 죽어버릴 수 있음.

③ pypkjs는 Settings 때문 필수.

  • 따라서 실질적으로 QEMU와 통신수단으로써 남은 선택지는 WebSocket 또는 raw_tcp 채널을 써야 한다.
  • pypkjs process의 생존 여부 + QEMU process 생존여부 + WebSocket server process 생존여부가 조합된 상태에 따라 강제 재 기동 혹은 멈춤을 결정해야 함. 이게 뭥미;;
  • raw_tcp를 사용할 경우 포트 충돌.

④ Audio 품질이 개 구림.

  • PebbleSDK에 포함된 emulator.py 스크립트에 audio 드라이버가 아예 누락됨. 수정해서 써야하는데, 현재로써는 SDK 업데이트마다 배포된 emulator.py 파일을 수정해서 사용해야 한다.
  • 찌그러짐, 늦게 반응, 버퍼 밀림 등의 이상 증상을 보임.
  • Gemini-3.8-Flash High + gpt-5.5 High 조합으로 12시간 넘게 추적 결과 어이없게도 QEMU RTC 모듈의 말도 안되는 시간처리 코드 때문인 것으로 드러남.
  • 같은 맥락으로 Firmware speaker_service.c 에서도 time_ms() 가 개판이라 buffer underrun 및 지터링 발생할 수 밖에 없는 코드로 확인됨.
  • PebbleOS speaker stream과 QEMU pebble-audio 장치의 시작 시퀀스가 맞지 않고, SDL audio driver 대신 PipeWire PulseAudio(pa)로 전환해야 했음.

Audio 문제 원인 파악을 위해 사용한 접근법

아래와 같이 문제를 발생시키는 원인을 특정하거나 좁혀가는 방법을 적용했다.

① 추측 금지

  • Local macOS에 PebbleOS 소스를 clone 받아두고 Pebble Firmware 및 QEMU 동작관련 코드를 확인케 했다.
  • 실제 동작은 Remote uConsole 에서 확인해야 하므로 ssh로 접근하는 데서 많은 토큰 소모가 발생했다.

② 고치라고 요구하는 내용에 더해, 완료시 접하게될 상태를 더 했다

  • “이 요청이 계획에 따라 수행되면 사용자는 다음과 같은 상태를 기대한다” 라는 식으로, 어떤 상태를 기대하는지, 해야하는지를 기술했다. LLM모델이 학습한 방식을 적용한 것이다.
  • 그치만, Gemini 병신은 단정적이고, GPT 고자놈은 뭘 어떻게 해도 멋대로 확장해서 해석한다. 오지게 패고싶다…

③ 문맥 유지를 위해 kontexus-mcp를 사용했다

  • 엄청난 양의 출력을 굳이 문서로 만들 필요없이, LLM이 Chatting 내용을 언제든 검색할 수 있으므로, 토큰을 아끼고 문맥 포화를 최대한 막기위해 세션을 여러번 재시작 하며 이어갔다.
  • LLM 스스로 가설을 나열하고 하나씩 실행하면서 범위를 좁혀갈 때, 문맥포화로 인해 멍청해 지지 않도록 kontexus-mcp가 지속적으로 상태를 유지하고 결과를 기록하여 끊임없이 LLM에게 주입하였다.

그럼에도 불구하고 실제 원인 파악은 인간인 내가 감으로 때려잡았다. LLM ㅅㄲ들은 자꾸만 문제를 확장시키거나 돌아가는데, 어떤 특정 오류 패턴에서 시간 문제인 것 같다는 느낌이 들어 RTC(realtime clock) 코드를 팠던 것이 핵심.

최종 삽질 결과

  • Dynamic Audio Generator 류의 페블 앱을 제외한다면 거의 모든 영역의 페블앱을 uConsole 에서 생성/테스트/디버깅을 할 수 있다.
  • 이 삽질을 하게 만들었던 모르스부호연습기 앱은 안타깝게도 소리가 시작되는 시점에서 음이 갈라져서, 지금은, 실제로 활용을 할 수가 없다.
  • 언젠가 다시 QEMU와 Firmware를 건드릴지 모르겠지만, 어디 격리되서 할 짓이 마땅이 없을 때 해결해볼 꺼리로 남겨둔다.
  • 페블 실제 기기에서는 아무런 문제가 없지만 QEMU에서만 발생하는 문제다.
  • 덕분에 pebble-mcp 도구를 어떻게 만들지에 대해 아이디어가 정리됐다.

pebble-mcp 도구 설계 스케치

  • PYPKJS는 CLI에서 직접 처리하고, QMP 채널로 signal을 날리게, 그리고 도구의 리턴값은 전이된 상태명을 돌리게 하는 방식이 적절할 것 같다.
  • MCP는 앱의 특정 동작을 유도하기 위해 상태전이를 시키는 시그널을 날리는 것으로 족하다.
  • 그리고 --logs 명령 등으로 로그를 파싱하게 하는 것보다 도구 호출의 리턴 값을 전이된 상태명을 전달하면, 상태전이 테이블은 코드에 있으므로 스스로 알아서 테스트를 할 것 이다.