Hermes에서 Even G2 안전 연동하기 | 툴셋 격리·VPS 가이드

Hermes AI linked securely to G2 smart glasses via VPS

Hermes로 Even G2를 붙이는 방법이 원본 튜토리얼과 전혀 다른 이유

Kim Jongwook · 2026-08-01

핵심 요약

Architecture diagram linking G2 glasses, phone, and Hermes VPS

Hermes용 G2 플러그인은 이미 존재한다.
안경 토큰은 root 자격증명과 같다.
platform_toolsets로 안경 툴셋만 분리 가능하다.
앱 서빙 위치가 원격 사용 가능 여부를 좌우한다.
1 vCPU에선 whisper-tiny만 실용적이다.

Table of Contents

Hermes로 Even G2를 붙이는 방법이 원본 튜토리얼과 전혀 다른 이유

Hermes 에이전트를 이미 운영 중이라면, Even Realities G2 안경을 붙이는 순간 문제가 완전히 달라진다. 더 이상 “되게 만드는 것”이 아니라, 기존 운영 컨텍스트에 어떻게 안전하게 끼워 넣느냐가 핵심이다. 특히 브리지 토큰이 새는 순간 서버 셸이 그대로 노출되는 구조라면, 튜토리얼을 그대로 따라 했다가 보안 측면에서 되돌리기 어려운 빚을 지게 된다.

여기서 다루는 구성은 원본 OpenClaw + Windows 조합이 아니라 Hermes + Ubuntu VPS 조합이다. 그 과정에서 얻은 것은 두 가지다. 하나는 Hermes의 platform_toolsets를 이용한 플랫폼별 툴 권한 격리이고, 다른 하나는 실제로 발에 걸렸던 함정 여덟 개의 목록이다. 한국어 음성 인식은 하드웨어 한계 때문에 절반의 성공에 그쳤지만, 그 지점까지 가는 경로와 실패 양상까지 정리한다.

왜 OpenClaw 대신 Hermes인가?

Hermes platform tool isolation limiting G2 smart glasses access

이미 운용 중인 Hermes 에이전트 인프라를 전제로 G2를 붙이는 시나리오에서 핵심은 하나다. 새 에이전트를 추가로 띄우지 않고, 기존 Hermes 인스턴스의 기억과 세션을 그대로 안경까지 확장하는 것.

원본 영상은 Windows PC 위에 OpenClaw를 설치하고, 공식 스킬 OcuClaw·Tailscale·Soniox를 연결해 G2 안경에서 개인 AI 에이전트를 구동하는 구조였다. 그런데 이미 Slack·Telegram과 붙어 있고, 장기간 세션과 메모리가 쌓인 Hermes 인스턴스를 운영하고 있다면 상황이 달라진다. 안경 질문과 Slack 대화를 같은 타임라인에서 이어 가야 하고, 별도 에이전트를 하나 더 운영하는 건 유지 비용만 늘린다.

“안경에서 물어본 걸 Slack에서 그대로 이어가고 싶다”는 요구는, 에이전트 개수를 늘리는 방식으로는 해결되지 않는다. 플랫폼을 하나 더 추가하되 에이전트는 그대로 유지해야 한다.

이 제약 아래서 목표는 네 가지였다.

집 밖, 셀룰러 네트워크에서도 동작할 것
맥을 켜 두지 않아도 될 것
운영 Hermes 에이전트와 컨텍스트(기억·세션)를 공유할 것
맥의 평문 포트를 없애고 TLS 환경으로 옮길 것

결과적으로 이 네 가지는 모두 달성됐고, 여기에 플랫폼별 툴셋 격리라는 다섯 번째 보너스가 붙었다. 사실 이 글에서 가장 실용적인 부분은 이 보너스다.

Hermes용 G2 플러그인은 이미 있는가?

Secure VPS and reverse proxy setup for Hermes G2 bridge

결론부터 말하면, 세 가지 구현이 공개 저장소에 이미 존재한다. 이걸 먼저 찾는 게 직접 이식보다 훨씬 비용 효율적이다.

초기 접근은 “OcuClaw를 Hermes로 이식할 수 있는가”라는 질문이었다. 이 방향으로는 두 번 모두 막혔다. 질문을 “Hermes용 G2 플러그인은 따로 있는가”로 바꾸자, 3분 만에 이 목록이 나왔다.

프로젝트	성격
`huntsyea/hermes-evenhub-bridge`	Hermes 플랫폼 플러그인 — `even_g2`를 Hermes 게이트웨이 플랫폼으로 등록
`huntsyea/hermes-even-hub-app`	위 브리지에 대응하는 G2 WebView 클라이언트 앱
`wingk1314/even-g2-hermes`	AI-proxy / Terminal Mode / Even Hub 플러그인을 한 데 묶은 3모드 통합

세 프로젝트 모두 pangoleen/awesome-even-realities-g2라는 G2 생태계 큐레이션 목록에 정리돼 있다. OpenClaw 쪽 브리지도 같은 목록에 있으니, 에코시스템 단위로 먼저 검색하는 것이 이식·자작보다 항상 빠르다.

이날 가장 비싼 실수는 코드 레벨의 오판이 아니었다. 질문 프레임 자체가 틀렸던 거다. 빠르게 성장하는 생태계에서는 이식 가능성을 분석하기 전에 대체재의 존재부터 확인하는 게 맞다.

덤으로 중요한 차이도 있다. 이 Hermes용 플러그인은 ASR을 온디바이스로 처리한다. Soniox 같은 클라우드 STT API 키가 필요 없고, 원본 튜토리얼에서 5분 이상을 차지하던 Soniox 온보딩 전 단계가 통째로 사라진다. 다만 이는 “설치만 하면 끝”이 아니라, 유지보수 책임까지 함께 떠맡는 선택이다.

유지보수 상태는 어떤가?

Korean speech recognition tradeoffs on G2 with Whisper models

OSS 플러그인을 운영 환경에 붙이기 전에, 커밋 로그를 보는 게 스타 개수보다 훨씬 정확한 신호다. 이 플러그인의 로그는 다음과 같다.

2026-06-27  chore(deps-dev): bump ruff             ← 마지막 커밋 (봇)
2026-06-04  fix: list all g2 sessions from sqlite  ← 마지막 실제 수정

2026-06-04 이후 기능 개발은 사실상 멈췄다. 열린 PR 12건 중 11건이 의존성 갱신이고, 유일한 기능 PR도 아직 머지되지 않고 있다.

실무적으로 이게 의미하는 바는 명확하다.

코드는 2026-06-04 기준으로 “동작하던 상태”에 고정돼 있다.
환경이 바뀌어 깨질 경우, 유지보수 책임은 전적으로 사용자에게 있다.
라이선스는 MIT라 포크·수정은 자유롭지만, 저자의 버그 픽스를 기대하긴 어렵다.

실제로 이 구성에서 세 군데를 직접 패치해야 했다. 이후 플러그인 업데이트가 나오면 이 패치들이 덮어쓰여 깨질 수 있고, 재적용 스크립트를 별도로 남기지 않으면 문제 발생 시점조차 추적하기 어렵다.

어떤 인프라 구성이 필요한가?

실제로 사용한 구성은 다음과 같다.

항목	내 구성
안경	Even Realities G2
폰	iPhone (Even 공식 앱 사용)
서버	Ubuntu VPS, Docker, 1 vCPU / RAM 3GB
에이전트	Hermes Agent (Docker, 운영 인스턴스)
도메인	와일드카드 DNS + Traefik + Let’s Encrypt
추가 비용	없음 (온디바이스 ASR, 기존 VPS 재사용)

원본 영상과 크게 다른 지점은 STT 비용 구조다. Soniox 같은 클라우드 STT를 쓰지 않으니 분당 과금은 0원이다. 대신 음성 인식이 서버 CPU를 직접 소모한다. 한국어 ASR 모델을 올리면 1 vCPU 환경에서 이 선택이 치명적인 병목으로 돌아오는데, 이건 뒤에서 자세히 다룬다.

왜 먼저 맥에서 관통을 확인했는가?

네트워크·배포로 복잡도를 키우기 전에 플러그인 자체가 정상 동작하는지 최소 경로에서 검증하는 단계다. 이걸 먼저 하면, 이후 VPS로 옮겼을 때 실패 지점을 네트워크/배포 층으로 한정할 수 있다.

실행한 최소 구성은 세 줄이다.

hermes plugins install huntsyea/hermes-evenhub-bridge
hermes even-g2 setup
hermes pairing approve even_g2 <코드>

이 상태에서 폰의 Even 앱에서 개발자 QR을 스캔해 WebView 클라이언트를 열고, 브리지 URL과 토큰을 입력하면 G2 안경에서 말한 내용이 Hermes 에이전트로 전달된다. 실제 데이터 경로는 다음과 같다.

G2 안경 → 온디바이스 ASR → ws://192.168.1.100:8766 → 맥 Hermes → LLM

로컬에서 한 번이라도 관통을 확인했다면, 이후에 생기는 문제는 거의 모두 네트워크·TLS·도메인·라우터 레벨로 축소된다. 플러그인 자체의 버그와 인프라 문제를 구분하는 가장 싼 방법이다.

다만 이 상태는 목표 네 가지를 하나도 충족하지 못한다.

집 LAN 안에서만 동작
맥이 깨어 있어야 함
WebSocket이 평문 ws://
이 맥의 Hermes 인스턴스는 운영 에이전트와 프로필이 분리

즉, 이 지점은 튜토리얼의 끝이 아니라 실질적인 작업의 시작점이다.

VPS로 옮길 때 무엇이 달라지는가?

G2 앱과 브리지가 모두 외부에서 접근 가능한 HTTPS/WebSocket 엔드포인트를 사용하도록 구조를 바꾸는 작업이다. Traefik이 이미 돌고 있다면, 브리지 컨테이너에 다음 라벨을 달아 라우터와 서비스를 구성할 수 있다.

- traefik.http.routers.hermes-g2.rule=Host(`g2.example-vps.your-host.cloud`)

traefik.http.routers.hermes-g2.entrypoints=websecure
traefik.http.routers.hermes-g2.tls.certresolver=letsencrypt
traefik.http.routers.hermes-g2.service=hermes-g2
traefik.http.routers.hermes-g2.middlewares=g2-ratelimit
traefik.http.services.hermes-g2.loadbalancer.server.port=8765
traefik.http.middlewares.g2-ratelimit.ratelimit.average=30
traefik.http.middlewares.g2-ratelimit.ratelimit.burst=60

service= 라벨을 명시한 이유는 뒤의 함정 섹션에서 설명한다. 요지는, 서비스가 둘 이상인 컨테이너에서 이 라벨을 빼면 Traefik 자동 연결이 모호해져 기존 라우터까지 깨진다는 점이다.

WebSocket이 실제로 관통하는지는 curl로 확인할 수 있다.

curl -s -i --http1.1 \
  -H "Connection: Upgrade" \
  -H "Upgrade: websocket" \
  -H "Sec-WebSocket-Version: 13" \
  -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
  https://g2.example-vps.your-host.cloud

응답에서 HTTP/1.1 101 Switching Protocols를 보면 성공이다. --http1.1 옵션을 빼면 curl이 HTTP/2를 사용해 426을 반환하는데, 이는 WebSocket 업그레이드 실패가 아니라 HTTP/2에서 Connection: Upgrade 헤더 자체가 무효이기 때문이다. 실제 G2 WebView는 HTTP/1.1로 붙으므로 문제없다.

왜 안경 토큰이 root 자격증명과 같은가?

이 플러그인의 SECURITY.md는 다음을 분명히 한다. “토큰을 가진, 페어링된 사람은 Hermes 에이전트를 그 툴 권한 그대로 조종할 수 있다.”

운영 Hermes 에이전트가 다음 툴 권한을 가지고 있다고 가정해 보자.

terminal — 서버 셸 명령 실행
file — 파일 읽기·쓰기
code_execution — 코드 조각 실행
computer_use — 브라우저·OS 제어

이 상태에서 G2 브리지 토큰 하나가 외부로 유출되면, 사실상 서버의 root 자격증명과 비슷한 파급력을 갖게 된다. 특히 브리지를 VPS에 올려 공개 엔드포인트를 열어 둔 상태라면, 이 토큰이 공격자에게 넘어가는 순간 단일 토큰으로 전체 서버를 장악할 수 있다.

그래서 목표는 단순히 HTTPS를 얹는 수준이 아니라, 플랫폼(안경)별로 툴 권한을 강제 분리하는 것이다. 이 지점에서 Hermes의 platform_toolsets 기능이 결정적인 역할을 한다.

Hermes `platform_toolsets`로 어떻게 권한을 분리했는가?

동일한 에이전트 프로필을 공유하더라도, Telegram·Slack·안경(G2) 같은 각 플랫폼이 사용할 수 있는 툴 목록을 독립적으로 설정하는 메커니즘이다. 안경에서만 terminal·file·code_execution·computer_use를 차단하고, 다른 플랫폼은 기존 17개 툴을 그대로 유지할 수 있다.

처음엔 플러그인 레벨에서 이를 제어하려 했다. 하지만 플러그인은 EVENHUB_* 환경변수로 호스트·포트·토큰·ASR만을 노출하고, 권한 관련 옵션은 없다. Hermes CLI도 다음처럼 even_g2 플랫폼을 아예 인정하지 않았다.

✗ Unknown platform 'even_g2'. Valid: cli, telegram, discord, slack, whatsapp, ...

소스 코드를 직접 확인했다.

plat_info = PLATFORMS.get(platform)
if plat_info:
    default_ts = plat_info["default_toolset"]
else:
    default_ts = f"hermes-{platform}"   # 플러그인 플랫폼

런타임은 플러그인 플랫폼을 완전히 지원한다. 막고 있는 건 CLI의 하드코딩된 플랫폼 목록뿐이다. config.yaml에 직접 platform_toolsets를 기술하면, CLI 도움 없이도 원하는 툴셋을 적용할 수 있다.

platform_toolsets:
  even_g2:
    - web
    - memory
    - session_search
    - clarify

이 설정으로 같은 Hermes 프로필을 쓰면서도, 안경에만 고위험 툴을 제거했다. Slack·Telegram은 여전히 17개 툴 전체를 사용한다. 컨텍스트 통합과 권한 격리가 동시에 성립한다.

부가적으로 드러난 더 불편한 사실이 하나 있다. 기본 툴셋 hermes-even_g2가 레지스트리에 없어, 툴셋을 명시하지 않으면 안경 권한이 사실상 “정의되지 않은 상태”가 된다. 명시적인 툴셋 설정은 단순한 권한 제한이 아니라 정상 동작의 조건에 가깝다.

권한 격리가 실제로 작동하는지 어떻게 검증했는가?

Hermes 서버 로그의 api_calls 필드가 여기서 유용하다. 실제 안경 질의와 api_calls 값의 조합은 다음과 같다.

안경에 한 질문	api_calls	해석
“지금 디스크 용량 알려줘”	1	툴 호출 왕복 없음 → `terminal` 차단
“내 프로젝트 코드명이 뭐야”	2	툴 왕복 1회 → `memory` 조회
“How’s the weather?”	3	툴 왕복 다수 → `web` 호출

Hermes에서 툴을 실행하면 최소 두 번 모델 호출이 일어난다.

사용자의 요청을 분석해 “툴을 사용할지” 결정하는 호출
툴 결과를 받아 최종 답변을 생성하는 호출

api_calls = 1이면 툴이 전혀 사용되지 않았다는 의미다. 실제로 “디스크 용량”을 물었을 때, 안경 쪽 응답은 명령을 실행하지 않고 “서버에서 이 명령을 실행하면 확인할 수 있다”는 형태로 안내했다. 같은 질문을 Slack에서 하면 실제 셸 명령이 실행된다.

이 정도 수준의 검증이 있어야, 안경 토큰이 새져도 최소한 셸·파일·코드 실행까지는 노출되지 않는다고 말할 수 있다.

앱 설치·서빙 방식을 왜 다시 설계해야 했는가?

Even Hub WebView 앱이 어느 호스트에서 로딩되는지를 가볍게 보면 “집 밖에서 동작하지 않는 안경”을 얻게 된다.

개발자 QR로 앱을 여는 방식은 근본적으로 URL을 띄우는 것이다. 이 URL이 맥 개발 서버(192.168.1.100:5173)를 가리키고 있으면, 브리지를 VPS로 옮기더라도 앱 자체는 여전히 사설 IP를 참조한다. 그 결과는 단순하다.

Wi-Fi(LAN)에서는 정상 동작
셀룰러로 전환하면 앱 화면 자체가 열리지 않음

실제로 셀룰러 전환 후 연결이 끊겼고, 서버 로그에는 요청 흔적조차 남지 않았다. 문제는 브리지가 아니라 앱이 로드되지 않은 것이었다.

해결 전략은 두 가지다.

앱 번들을 VPS에서 서빙
npm build 등으로 생성한 dist/ 폴더를 nginx 같은 정적 서버 컨테이너에 올린다.
개발자 QR에 이 공개 URL을 넣는다.
맥 의존성이 사라지지만, 실행할 때마다 QR 스캔은 여전히 필요하다.
Even Hub Beta Testing으로 상주 설치
WebView 앱을 .ehpk 포맷으로 패킹한다.
Even 개발자 콘솔에 업로드하고, Beta Testing 그룹에 자신의 계정을 추가한다.
폰의 Developer hub에 앱이 Open 버튼과 함께 상주하고, 이후 QR 스캔 없이 바로 실행할 수 있다.

CLI에는 upload 명령이 없다. 지원하는 건 init, login, qr, self-check, pack 정도고, Beta 업로드는 웹 콘솔에서만 가능하다. 빌드 상태를 Private으로 두면 스토어 공개 없이 테스팅 그룹에게만 노출된다.

앱을 어디서·어떻게 서빙하느냐가 “집 밖에서 쓸 수 있는가”를 사실상 전부 결정한다. 브리지만 VPS에 올려서는 문제가 해결되지 않는다.

한국어 ASR은 왜 절반의 성공에 그쳤는가?

한 문장으로 요약하면: 1 vCPU 환경에서는 whisper-tiny가 유일한 실용 선택지다.

실측 결과를 먼저 보면, 한국어 인식은 이런 오류를 보였다.

“디스크 용량” → “디스쿨용량”
“코드명” → “코드념”

개선을 위해 가능한 대안들을 하나씩 검토했다.

시도	결과
Even SDK의 전사 API 사용	❌ 타입 정의 1,292줄에 `transcri`/`speech`/`asr` 키워드 0건 — 원시 PCM만 노출
WebView 음성 인식(`webkitSpeechRecognition`)	❌ API 호출은 가능하나 실행 시 `not-allowed` — 권한 거부
`parakeet` 다국어 모델	❌ 백엔드가 macOS 전용 — Linux VPS에서는 구동 불가

WebView 케이스는 진단 페이지를 별도로 만들어 실측했다. iOS 설정에서 앱의 음성 인식 권한을 켜 둔 상태에서도 Web Speech API 호출은 not-allowed로 거부됐다. WKWebView가 Web Speech API를 차단하고, 앱이 가진 음성 인식 권한은 네이티브 기능에만 적용된다는 뜻이다.

남는 선택지는 서버 측 whisper 모델 스케일링뿐이었다. 1.9초짜리 한국어 발화를 기준으로 모델별 처리 시간을 측정했다.

모델	1.9초 발화 처리 시간	4초 발화 환산
tiny	1.84초	약 4초
base	3.03초	약 6초
small	6.22초	약 13초

G2 UX를 고려하면 small 모델은 사실상 불가다. ASR에만 10초 이상, LLM 응답까지 포함하면 20초를 넘기기 때문이다. 그런데 진짜 차이는 속도가 아니라 잡음 환경에서의 실패 양상이다. SNR 5dB 정도의 잡음을 섞어 테스트했을 때 결과는 다음과 같다.

모델	결과
tiny	`Chỉ cần thịt tuyền nhanh lại là do` — 베트남어로 언어 붕괴
base	`지금 디스틱 육면 날려줘` — 한국어 유지, 심한 발음 왜곡
small	`지금 비스 용량 알려줘` — 한국어 유지, 의미 보존에 가장 근접

LLM이 뒤에 붙어 있다면, 뭉개진 한국어는 상당 부분 복원 가능하다. 하지만 언어 자체가 다른 언어로 붕괴되는 경우는 LLM이 되살리기 어렵다. 이게 tiny의 진짜 한계다. “철자·발음이 틀린 결과”는 보정되지만, “언어 자체가 붕괴”되면 복구가 거의 불가능하다.

그럼에도 1 vCPU 환경에서는 tiny를 유지할 수밖에 없었다. 최종 전략은 이렇다.

레지스트리에 whisper-small까지 모두 등록해 둔다.
운영 환경의 기본 ASR 모델은 환경변수로 tiny로 고정한다.
VPS 스펙을 4 vCPU 이상으로 올릴 수 있다면, 환경변수 한 줄만 바꿔 small로 전환할 수 있게 준비해 둔다.
compute_type="int8"을 사용해 출력 품질 변화 없이 약 30% 속도를 확보한다.

CPU·RAM 업그레이드가 이 병목을 풀 유일한 레버라는 건 인정할 수밖에 없다.

실제로 만난 함정 여덟 가지는 무엇인가?

“만날 확률” 기준으로 정리한 체크리스트다.

1. 프로필 지정은 `HERMES_PROFILE`이 아니라 `HERMES_HOME`

Hermes는 환경변수 HERMES_HOME이 직접 profiles/<이름> 디렉터리를 가리키는 방식으로 프로필을 선택한다. HERMES_PROFILE 같은 변수는 없다. 이 값을 잘못 지정하면 루트 설정을 읽어 버리고, 그 결과 변경이 적용되지 않은 것처럼 보인다.

실제로 하루에 세 번 정도 이 함정을 밟았다. 프로필이 다른데도 “왜 설정이 바뀌지 않지?”라고 느낀다면 HERMES_HOME을 먼저 의심해야 한다.

2. 페어링은 서버별 상태

G2 페어링 상태는 package_id와 무관하게 서버 인스턴스별로 유지된다. 맥에서 승인한 페어링을 VPS에서도 그대로 쓸 수 있을 거라 예상했지만, 서버를 옮기는 순간 페어링 승인은 초기화됐다. VPS로 옮겼다면 G2에서 다시 페어링을 요청하고, Hermes 측에서 재승인해야 한다.

3. 인증 실패는 서버 로그를 남기지 않는다

브리지 토큰이 틀리면 WebSocket 서버는 코드 1008(Policy Violation)으로 연결을 조용히 닫는다. 이때 Hermes 서버 로그에는 인증 실패 기록이 남지 않는다. 서버 로그가 비어 있는 것이 오히려 정상 동작인 셈이다.

이 상황을 진단하려면 클라이언트 쪽에서 직접 재현하거나, WebSocket 핸드셰이크를 캡처해야 한다. 서버 로그만 보고 “아무 문제가 없다”고 판단하면 놓치기 쉽다.

4. `hermes tools` CLI는 플러그인 플랫폼을 거부하지만 런타임은 지원

앞에서 다룬 것처럼, Hermes CLI는 even_g2 플랫폼을 알지 못해 계속 에러를 낸다. 그러나 런타임은 플러그인 기반 플랫폼을 정식으로 지원한다. CLI의 거부 메시지를 최종 권위로 받아들이면 안 된다. 권한 제어는 config.yaml의 platform_toolsets에서 직접 해야 한다.

5. 컨테이너에 서비스를 추가하면 기존 Traefik 라우터가 깨진다

Traefik에서 라우터에 service= 라벨이 없으면, 라우터는 동일 컨테이너 내 단일 서비스에 자동 연결된다. 컨테이너에 두 번째 서비스를 추가하는 순간 이 매핑이 모호해져 다음 에러가 뜬다.

ERR Router xxx cannot be linked automatically with multiple Services

새 G2 브리지 라우터를 추가하면서 기존 대시보드 라우터를 함께 깨뜨리는 상황을 실제로 겪었다. 해결책은 기존 라우터에도 service= 라벨을 명시해 자동 매핑에 의존하지 않도록 만드는 것이다.

6. `.ehpk`는 zip이 아니다

Even Hub 패키지 포맷 .ehpk는 일반 zip이 아니다. 파일 헤더 매직 바이트가 EHPK인 독자 포맷이며, 공식적으로 unpack 명령도 없다. 패키지 내용을 검증하려면 폰에 설치해 보는 수밖에 없다. 보안·무결성 검증 측면에서는 불편하지만, 현 시점엔 우회 수단이 없다.

7. 같은 Telegram 봇 토큰을 두 곳에서 쓰면 폴링 충돌

운영 Hermes 인스턴스와 G2 실험용 인스턴스가 같은 TELEGRAM_BOT_TOKEN을 공유하고 있었다. Telegram 폴링이 서로 경쟁하면서 다음 에러를 내고, 재시도 5회 뒤 연결이 종료된다.

Conflict: terminated by other getUpdates request

해결법은 단순하다. 실험용 인스턴스에서 Telegram 토큰을 주석 처리하거나, Telegram 플랫폼을 끄면 된다. 브리지용 임시 Hermes 인스턴스가 운영과 자격증명을 공유하고 있지 않은지 먼저 확인해야 한다.

8. Hermes 대시보드의 Host/Port 입력은 동작하지 않는다

플러그인 이슈 트래커(#24)에 기록된 대로, Hermes 대시보드 UI에서 설정하는 Host/Port는 실제 브리지 어댑터에 반영되지 않는다. 어댑터는 환경변수를 읽고, 대시보드는 config.yaml을 수정한다. 저자 표현을 빌리면 “사용자가 바꾸면 적용된다고 착각하게 만드는 UI”다.

브리지 관련 설정은 환경변수 경로로만 관리하고, 대시보드 UI는 참고용으로만 보는 편이 안전하다.

지금 구성의 상태와 남은 숙제는 무엇인가?

최종적으로 동작하는 구조는 다음과 같다.

G2 안경 ──BT── iPhone ── https://g2app.example-vps.your-host.cloud  (앱)
                    └──── wss://g2.example-vps.your-host.cloud      (브리지)
                                    ↓
                     Hermes (Docker) ─ even_g2 / slack / telegram

초기 목표 네 가지는 모두 달성됐다.

집 밖 셀룰러 환경에서도 동작
맥이 꺼져 있어도 VPS가 상시 응답
운영 Hermes 인스턴스와 기억·세션 공유
브리지는 TLS(WebSocket over HTTPS)로 노출

여기에 더해 platform_toolsets로 안경 플랫폼에만 툴 권한을 제한하는 플랫폼별 권한 격리도 얻었다. 다만 솔직하게 남겨야 할 미검증·미해결 항목이 몇 가지 있다.

앱 네트워크 화이트리스트의 실제 강제 여부 미검증
앱의 app.json에 네트워크 화이트리스트를 정의해 뒀지만, 개발 URL 모드에서 이 화이트리스트가 실제로 적용되는지 확인하지 못했다.
허용되지 않은 호스트로 접근 시도가 차단되는지 실험하면 30초 안에 판명되지만, 아직 수행하지 않았다.
수동 패치 세 군데
플러그인 코드 세 군데를 수작업으로 패치했다.
플러그인 업데이트가 이 변경을 덮어쓰면, 브리지가 조용히 깨질 수 있다.
재적용 스크립트를 별도 저장해 두지 않으면, 문제 발생 시 원인 식별에 시간이 많이 걸린다.
한국어 인식률의 하드웨어 한계
1 vCPU / 3GB RAM 환경에서는 whisper-tiny 이상으로 올릴 여유가 없다.
CPU 스케일링 없이 인식률·지연을 동시에 개선할 수 있는 소프트웨어적 여지는 거의 없다.

원본 튜토리얼이 “된다”를 보여 주는 수준이었다면, 여기에 정리한 건 “되고 나서 무엇이 남는가”다. 안경에 대고 말하면 답이 오는 것은 출발점일 뿐, 운영 환경에 안전하게 편입시키는 과정이 진짜 본론이다.

자주 묻는 질문 (FAQ)

Q: 왜 OpenClaw 대신 Hermes를 선택해야 할 이유가 있나요?

A: 이미 Hermes 에이전트를 운영 중이고 Slack·Telegram·메모리·세션이 쌓여 있다면, 새 에이전트를 하나 더 띄우기보다는 G2를 기존 Hermes 인스턴스의 또 다른 플랫폼으로 붙이는 편이 유지보수 비용이 훨씬 낮다. 안경 대화와 Slack 대화를 같은 기억 공간에서 이어갈 수 있다는 점도 Hermes 쪽의 큰 이점이다.

Q: Hermes에서 안경(G2)만 셸·파일 권한을 차단하려면 어떻게 해야 하나요?

A: config.yaml의 platform_toolsets 항목에 even_g2 플랫폼을 추가하고, 이 플랫폼에 허용할 툴만 나열하면 된다. web, memory, session_search, clarify만 두고 terminal, file, code_execution을 빼면 안경은 이 위험 툴을 전혀 실행하지 못한다.

Q: VPS 없이 로컬 맥만으로도 실사용이 가능한가요?

A: 실험·개발 용도로는 가능하다. 다만 집 LAN 안에서만 동작하고, 맥이 항상 켜져 있어야 하며, WebSocket이 평문으로 노출된다는 제약이 있다. 셀룰러·외부 네트워크까지 고려한다면 HTTPS가 가능한 서버 인프라가 사실상 필수다.

Q: 한국어 음성 인식 품질을 올리려면 어떤 업그레이드가 필요합니까?

A: 소프트웨어보다 하드웨어가 병목이다. whisper-tiny에서 small로 올리려면 최소 4 vCPU, 쾌적하게 쓰려면 8 vCPU / 8GB RAM 수준이 필요하다. 이 정도 스펙이 되면 모델을 small로 바꾸고 compute_type="int8"을 설정하는 것만으로 지연과 정확도가 모두 개선된다.

Q: Even Hub 앱은 꼭 Beta Testing으로 배포해야 하나요?

A: 강제는 아니지만, 실제 사용성을 생각하면 Beta Testing이 정답에 가깝다. 개발자 QR 방식은 LAN에 묶이고 실행할 때마다 QR 스캔이 필요하다. Beta Testing으로 .ehpk를 올리면 폰 Developer hub에 앱이 상주해, 셀룰러 환경에서도 한 번 탭으로 바로 실행할 수 있다.

결론

직접 구성하면서 정리된 요점은 다음과 같다.

Hermes용 G2 브리지는 이미 존재한다. OpenClaw 이식을 시도하기 전에 생태계 큐레이션 목록부터 확인했다면 시간을 많이 아꼈을 거다.

G2 브리지 토큰은 root 자격증명에 가까운 권한을 갖는다. 공개 엔드포인트를 열어 두는 순간 이건 선택의 문제가 아니라 구조의 문제가 된다. Hermes platform_toolsets로 안경에만 위험 툴을 차단하는 구성은 사실상 필수에 가깝다.

앱 서빙 위치가 “집 밖에서 쓸 수 있는가”를 결정짓는다. 브리지만 VPS에 올려서는 반쪽짜리다. Beta Testing 상주 설치까지 가야 비로소 일상 도구가 된다.

한국어 ASR의 품질 상한선은 지금 CPU 코어 수가 정한다. 소프트웨어 쪽에서 할 수 있는 건 거의 다 해 봤다. 남은 레버는 VPS 스펙 업그레이드뿐이다.

이 구조 위에서 G2 안경은 기존 Hermes 에이전트의 또 하나의 입·귀가 된다. 인프라 스케일업, 권한 화이트리스트 검증, 플러그인 패치 자동화 세 가지를 정리하면, “개인용 스마트 안경 + 자가호스팅 AI 에이전트” 조합이 일회성 해킹을 넘어 실제로 매일 쓰는 도구가 될 거라 생각한다.

이 글은 시리즈의 첫 번째다. 이 작업을 AI 에이전트와 함께 하며 판정을 세 번 뒤집은 과정은 2편 — 하루에 판정을 세 번 뒤집은 기록에 정리했다.

Found this article helpful?

Get more tech insights delivered to you.

Subscribe to Blog via Email