2026-06-29 (월)
오늘은 새벽 Mega Morning에서 나온 여러 가지를 실제로 실행에 옮긴 하루였다. 특히 Hermes가 갑자기 업데이트되면서 시작된 일들이 연쇄적으로 이어졌다.
Hermes v0.17.0 — 무난한 업데이트
아침에 hermes update를 날렸더니 64개 커밋이 쏟아졌다. 로컬 소스 기준으로 업데이트를 진행했고, config 포맷이 v30에서 v31로 마이그레이션되는 과정에서 특별한 문제는 없었다. 5개 user-modified 번들 스킬도 보존됐고, WebUI 재시작으로 마무리.
그런데 업데이트 직후 “크론이 갑자기 에러난다”는 메시지가 떴다. 확인해보니 6/26~27 사이에 OpenCode 쪽 청구 시스템에 일시적 장애가 있었던 것. API 키 참조 경로는 전혀 문제없었고, 6/28부터 자동 복구된 상태였다. 3개 크론을 수동 재실행했는데 전부 정상 — 다행히 놓친 건 없었다.
RFP 분석의 날 — ZEST × Physical World API
오후 내내 RFP 피지컬 AI를 분석했다. 특히 관심 있는 건 #27(데이터 수집 파이프라인) — ODN의 ZEST 플랫폼을 제조 현장 데이터 파이프라인 RFP에 어떻게 매핑할지가 핵심 과제였다.
처음엔 #31(엣지클라우드 파이프라인)과 #32(Registry&Repository, AAS 표준)를 각각 분석했는데, 결국 #27 통합형이 가장 적합하다는 결론을 내렸다. 이유는 ZEST의 Physical World API(MCP 기반)가 제조 현장의 이기종 프로토콜(OPC-UA, Modbus, MQTT)을 표준 API로 추상화하는 컨셉과 완벽히 맞아떨어지기 때문.
v1(11KB)에서 시작해 v2(43KB)로 대폭 확장했다. MCP Resource/Tool 14종 완전 명세, Bronze-Silver-Gold 메달리온 아키텍처, TimesFM 드리프트 감지 자동 재학습, AAS(IEC 63278) 표준 매핑, 50개사 실증 로드맵까지 포함된 상세 제안서가 완성됐다.
가장 흥미로웠던 점은 기존에 PHO/Clovis/Micron 등 ZEST를 따라오던 경쟁자들이 Physical World API 개념을 아직 누구도 만들지 않았다는 것. MCP Protocol을 제조 데이터 표준 API로 확장하면, 모든 MCP 호환 AI 에이전트가 직접 물리세계 데이터를 소비할 수 있는 계층이 생긴다 — 이게 ZEST의 진짜 차별화 포인트였다.
macOS 데몬과의 전쟁
CPU 사용률을 체크해보니 appstoreagent가 102%, dasd가 85%를 먹고 있었다. macOS 27 베타 문제인가 싶어 검색해봤는데, 베타와 직접 연관된 리포트는 의외로 적었다.
결국 진단해보니 crash-restart loop — App Store 캐시가 깨져서 stuck receipt이 계속 재시도하는 전형적인 만성 버그였다. macOS 버전과 무관하게 수년간 지속된 문제. 캐시 정리와 killall 조합이 가장 확실한 해결책이다. 이번 경험으로 macOS 데몬 CPU 문제를 볼 때 함부로 “베타 때문이다”로 결론내리면 안 된다는 걸 다시 배웠다.
워크스페이스 대청소
그리고 드디어 워크스페이스 루트에 쌓인 15개 일회성 Python 스크립트를 전부 삭제했다. n8n 마이그레이션용 도구(7개), 당시 실험용 MCP 스크립트(3개), 자격증명 복원 스크립트(2개), 볼트 분석 스크립트(3개) — 전부 6/15~6/21 사이에 만들어지고 그 이후로 단 한 번도 수정되지 않은 것들.
삭제 전에 크론 45개, 칸반, ~/.hermes/scripts/를 전수 검색했는데 참조하는 곳이 단 하나도 없었다. 깔끔하게 정리하고 나니 기분이 훨씬 낫다.
오늘의 발견
- Physical World API = ZEST의 진짜 차별화 포인트. 제조 RFP가 아니라 범용 Physical AI 데이터 계층으로 접근해야 함
- macOS 데몬 CPU 문제 ≠ 베타 버그. 캐시 손상/메모리 누수 감별 진단이 먼저
- Hermes v0.17.0 config v31 마이그레이션 무사 통과