구현 아이디어

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 명령 등으로 로그를 파싱하게 하는 것보다 도구 호출의 리턴 값을 전이된 상태명을 전달하면, 상태전이 테이블은 코드에 있으므로 스스로 알아서 테스트를 할 것 이다.