보안과 그 개발, 그 어딘가

[이더리움/Foundry] Permit ERC2612 서명값(ERC712) 가져오기

초보 & 뉴비 — Sun, 26 Apr 2026 05:52:58 +0900

(uint8 v, bytes32 r, bytes32 s) = vm.sign(privateKey, digest);

// Permit 내에 구현된 해시 (그대로 사용해야 함 )
bytes32 permitTypeHash = keccak256("Permit(address owner,address spender,uint256 value,uint256 nonce,uint256 deadline)");


address spender = 0x;
uint256 value = 1; // 1 wei
uint256 nonce = contractInstance.nonces(owner); // 서명 재사용 방지, ERC20Permit을 상속하는 contractInstance 메소드
uint256 deadline = block.timestamp + 1 hours;

bytes32 digest = keccak256(
  abi.encodePacked(
    "\x19\x01", // 고정
    contractInstance.DOMAIN_SEPARATOR(), // 서명 재사용 방지, ERC20Permit을 상속하는 contractInstance 메소드
    keccak256(abi.encode(permitTypeHash, owner, spender, value, nonce, deadline))
  )
);

(uint8 v, bytes32 r, bytes32 s) = vm.sign(digest);

Foundry 사용 시 사실상 PrivateKey를 알고 있기 때문에 ECDSA 서명을 만들 수 있음 => vm.sign()
서명 함수 리턴 값인 v r s 를 가지고 ecrecover, ECDSA.recover, permit() 등에 넣어서 서명을 검증 할 수 있음

[인공지능/Hermes] 헤르메스 슬랙 연동하기

초보 & 뉴비 — Sat, 25 Apr 2026 23:25:13 +0900

헤르메스 에이전트와 슬랙을 연동하는 방법을 알아보기 전에, 굳이 슬랙을 선택한 이유는 간단하다.

메신저 공식 비교 테이블를(혹은 아래 사진 참고) 보면 모든 기능을 지원하는 메신저 중 쓸만한게(최소 내가 써본것들이) 슬랙(및 디스코드)였기 때문이다.

Hermes Agent Slack 연동 가이드

한 줄 요약

Hermes Agent는 Slack App의 Socket Mode를 사용해서 Slack과 연결할 수 있다.

Slack 사용자
   ↓
Slack App / Bot
   ↓
Socket Mode WebSocket
   ↓
Hermes Messaging Gateway
   ↓
Hermes Agent

공식 문서 기준으로 Hermes Slack 연동은 slack-bolt / slack_sdk 기반 Socket Mode를 사용하고, 필요한 토큰은 Bot Token인 xoxb-와 App-Level Token인 xapp- 두 가지다.

Slack 연동 방식

Socket Mode란 무엇인가

Slack Bot을 외부 서비스와 연결하려면 일반적으로 Slack이 이벤트를 보낼 수 있는 공개 (Hook) URL이 필요하다.

하지만 Socket Mode를 사용하면 공개 URL이 필요 없다.

Hermes Gateway가 Slack 쪽으로 WebSocket 연결을 열고, 그 연결을 통해 이벤트를 받는 구조다.

일반 이벤트 방식:
Slack → 공개 HTTP URL → 내 서버

Socket Mode:
내 Hermes Gateway → Slack WebSocket 연결
Slack → 열린 WebSocket으로 이벤트 전달

이 방식의 장점은 다음과 같다.

내 PC에서 바로 테스트할 수 있다.
ngrok, ssh tunneling 같은 터널링 도구가 필요 없다.
방화벽 뒤 서버에서도 사용할 수 있다. ( 기업 환경에서는 꽤나 편리함 )
외부에 공개 엔드포인트를 열지 않아도 된다. ( 기업 환경에서는 꽤나 편리함 )

필요한 토큰

Slack 연동에는 토큰이 2개 필요하다.

토큰	형식	용도
Bot Token	`xoxb-...`	봇이 메시지를 읽고 보내는 데 사용한다
App-Level Token	`xapp-...`	Socket Mode WebSocket 연결에 사용한다

Hermes에서는 이 토큰을 보통 다음 환경변수로 설정한다.

SLACK_BOT_TOKEN=xoxb-your-bot-token-here
SLACK_APP_TOKEN=xapp-your-app-token-here

Slack App 생성

Slack App 만들기

먼저 Slack API 페이지에서 새 앱을 만든다.

https://api.slack.com/apps

진행 순서는 다음과 같다.

Create an App을 클릭한다.
From scratch를 선택한다.
앱 이름을 입력한다.
연결할 Slack workspace를 선택한다. ( 최소 1개의 워크스페이스가 미리 생성되어 있어야 한다 )
Create App을 클릭한다.

앱 이름은 예를 들어 다음처럼 정하면 된다.

Hermes Agent

생성 후에는 Slack App의 Basic Information 페이지로 이동하게 된다.

Bot Token Scopes 설정

Slack App 설정 화면에서 다음 메뉴로 이동한다.

Features → OAuth & Permissions

그리고 Scopes(범위) → Bot Token Scopes(봇 토큰 범위) 항목에 필요한 권한을 추가하면 된다.

주요 Scope 추가

Hermes Slack Bot에 필요한 주요 Bot Token Scope는 다음과 같다.

Scope	용도
`chat:write`	봇이 메시지를 보낼 수 있게 한다
`app_mentions:read`	채널에서 봇이 멘션된 것을 감지한다
`channels:history`	봇이 들어간 공개 채널의 메시지를 읽는다
`channels:read`	공개 채널 목록과 정보를 읽는다
`groups:history`	봇이 초대된 비공개 채널 메시지를 읽는다
`im:history`	DM 메시지 기록을 읽는다
`im:read`	DM 기본 정보를 읽는다
`im:write`	DM을 열고 관리한다
`users:read`	사용자 정보를 조회한다
`files:read`	첨부파일, 음성 파일, 오디오 파일을 읽는다
`files:write`	이미지, 오디오, 문서 파일을 업로드한다

비공개 채널 정보까지 포함하고 싶으면 다음 Scope도 추가한다.

Scope	용도
`groups:read`	비공개 채널 목록과 정보를 읽는다

자주 빠뜨리는 Scope

채널에서 봇이 응답하지 않는 가장 흔한 원인은 다음 Scope 누락이다.

channels:history
groups:history

channels:history가 없으면 공개 채널 메시지를 제대로 받지 못할 수 있다.

groups:history가 없으면 비공개 채널 메시지를 제대로 받지 못할 수 있다.

DM만 동작하고 채널에서 동작하지 않는다면 이 Scope부터 확인하면 된다.

Socket Mode 활성화

Socket Mode 켜기

Slack App 설정에서 다음 메뉴로 이동한다.

Settings → Socket Mode

그리고 Enable Socket Mode를 켠다.

Socket Mode를 켜면 App-Level Token 생성을 요구한다.

App-Level Token 생성

App-Level Token 생성 시 다음처럼 설정하면 된다.

Token name: 원하는 값으로
Scope: connections:write

생성된 토큰은 xapp-로 시작한다. ( 나중에 써야 하니 복사해두자. )

이 토큰이 Hermes의 SLACK_APP_TOKEN이 된다.

SLACK_APP_TOKEN=xapp-your-app-token-here

App-Level Token은 나중에 다음 메뉴에서도 확인하거나 재생성할 수 있다.

Settings → Basic Information → App-Level Tokens

Event Subscriptions 설정

이벤트 구독 켜기

* 중요한 단계이다, 봇이 읽을 수 있는 메시지의 종류가 여기에서 결정 된다.

Slack App 설정에서 다음 메뉴로 이동한다.

Features → Event Subscriptions

그리고 Enable Events를 켠다.

그 다음 Subscribe to bot events 항목에 이벤트를 추가한다.

필요한 Bot Event

Hermes Slack Bot에 필요한 이벤트는 다음과 같다.

Event	필수 여부	용도
`message.im`	필수	봇이 DM을 받는다
`message.channels`	필수	봇이 들어간 공개 채널 메시지를 받는다
`message.groups`	권장	봇이 초대된 비공개 채널 메시지를 받는다
`app_mention`	필수	채널에서 봇이 멘션된 것을 처리한다

이벤트를 추가한 뒤에는 반드시 페이지 하단의 Save Changes를 눌러야 한다.

가장 흔한 설정 실수

Slack Bot이 DM에서는 잘 동작하는데 채널에서 응답하지 않는다면 대부분 다음 둘 중 하나다.

message.channels 누락
message.groups 누락

공개 채널에서 응답하지 않으면 message.channels를 확인하면 된다.

비공개 채널에서 응답하지 않으면 message.groups를 확인하면 된다.

Messages Tab 활성화

App Home 설정

DM으로 Hermes Bot에게 메시지를 보내려면 Messages Tab을 켜야 한다.

Slack App 설정에서 다음 메뉴로 이동한다.

Features → App Home

그리고 Show Tabs 섹션에서 다음을 설정한다.

Messages Tab을 ON으로 켠다.
Allow users to send Slash commands and messages from the messages tab을 체크한다.

이 단계를 하지 않으면 DM에서 다음과 같은 메시지를 볼 수 있다.

Sending messages to this app has been turned off

이 문제는 Hermes 설정 문제가 아니라 Slack App 설정 문제라고 보면 된다.

Workspace에 App 설치

Install App 실행

Slack App 설정에서 다음 메뉴로 이동한다.

Settings → Install App

그리고 다음 순서로 진행한다.

Install to {워크스페이스명}를 클릭한다.
권한 목록을 확인한다.
Allow를 클릭한다.
설치 후 Bot User OAuth Token을 복사한다.

Bot User OAuth Token은 xoxb-로 시작한다.

이 값이 Hermes의 SLACK_BOT_TOKEN이다.

SLACK_BOT_TOKEN=xoxb-your-bot-token-here

Scope 변경 후 재설치 필요

중요한 점이 있다.

Slack App의 Scope나 Event Subscription을 나중에 변경했다면 App을 workspace에 다시 설치해야 한다.

그렇지 않으면 새 권한이 실제 봇에 적용되지 않을 수 있다.

즉 아래 중 하나의 행위라도 했으면 반드시 재설치해야 한다.

Bot Token Scope 추가
Event Subscription 추가
Socket Mode 관련 설정 변경

Allowlist용 Slack Member ID 찾기

Member ID가 필요한 이유

Hermes Gateway는 허용된 사용자만 메시지를 처리하도록 설정하는 것이 기본이다.

Slack에서는 사용자 이름이나 표시 이름이 아니라 Member ID를 사용한다.

Member ID는 보통 다음처럼 생겼다.

U01ABC2DEF3

Hermes 설정에서는 이 값을 SLACK_ALLOWED_USERS에 넣는다.

SLACK_ALLOWED_USERS=U01ABC2DEF3

Member ID 찾는 방법

Slack에서 Member ID를 찾는 방법은 다음과 같다.

Slack에서 사용자 이름이나 아바타를 클릭한다.
View full profile을 클릭한다.
⋮ 버튼을 클릭한다.
Copy member ID를 선택한다.

최소한 자신의 Member ID는 반드시 등록하는 게 좋다.

Hermes 환경변수 설정

.env 파일 수정

Hermes 설정 파일은 기본적으로 다음 위치를 사용한다.

~/.hermes/.env

여기에 Slack 설정을 추가하면 된다.

# Required
SLACK_BOT_TOKEN=xoxb-your-bot-token-here
SLACK_APP_TOKEN=xapp-your-app-token-here
SLACK_ALLOWED_USERS=U01ABC2DEF3

# Optional
SLACK_HOME_CHANNEL=C01234567890
SLACK_HOME_CHANNEL_NAME=general

각 값의 의미는 다음과 같다.

환경변수	필수 여부	의미
`SLACK_BOT_TOKEN`	필수	Slack Bot User OAuth Token
`SLACK_APP_TOKEN`	필수	Socket Mode용 App-Level Token
`SLACK_ALLOWED_USERS`	필수 권장	Hermes를 사용할 수 있는 Slack Member ID 목록
`SLACK_HOME_CHANNEL`	선택	cron, scheduled message를 보낼 기본 채널 ID
`SLACK_HOME_CHANNEL_NAME`	선택	사람이 읽기 쉬운 기본 채널 이름

여러 사용자를 허용하려면 쉼표로 구분하면 된다.

SLACK_ALLOWED_USERS=U01ABC2DEF3,U04XYZ9AAAA

Interactive Setup 사용

직접 .env를 수정하지 않고 대화형 설정을 사용할 수도 있다.

hermes gateway setup

실행 후 Slack을 선택하고 토큰과 사용자 ID를 입력하면 된다.

Gateway 실행

Foreground 실행

처음 테스트할 때는 foreground로 실행하는 게 좋다.

hermes gateway

이 방식은 터미널에 로그가 바로 나오기 때문에 문제를 확인하기 쉽다.

User Service로 설치

개인 개발 머신이나 일반 사용자 환경에서는 user service로 설치하면 된다.

hermes gateway install
hermes gateway start
hermes gateway status

중지하려면 다음 명령을 사용한다.

hermes gateway stop

Linux System Service로 설치

VPS나 서버에서 부팅 시 자동 실행하고 싶다면 system service로 설치할 수 있다.

sudo hermes gateway install --system
sudo hermes gateway start --system
sudo hermes gateway status --system

일반 개발 머신에서는 user service가 더 적합하고, 서버에서는 system service가 적합하다고 보면 된다.

Bot을 채널에 초대

채널 초대

Gateway를 실행한 뒤에는 Hermes Bot을 사용할 Slack 채널에 초대해야 한다.

채널에서 다음 명령을 입력하면 된다.

/invite @봇이름
/invite @Hermes

봇은 자동으로 모든 채널에 들어가지 않는다.

사용할 채널마다 직접 초대해야 한다.

비공개 채널 주의

비공개 채널에서 사용하려면 다음 조건이 필요하다.

groups:history Scope가 있어야 한다.
message.groups Event Subscription이 있어야 한다.
App을 재설치해야 한다.
해당 비공개 채널에 봇을 초대해야 한다.

이 중 하나라도 빠지면 비공개 채널에서 응답하지 않을 수 있다.

Hermes Bot 응답 방식

DM에서의 동작

DM에서는 봇이 모든 메시지에 응답한다.

즉 별도로 @Hermes Agent를 멘션하지 않아도 된다.

사용자: 오늘 할 일 정리해줘.
Hermes: ...

채널에서의 동작

채널에서는 기본적으로 @mention이 필요하다.

@Hermes 이 에러 로그 원인 분석해줘.

채널에서 Hermes는 보통 해당 메시지의 thread에 답변한다.

이 방식은 다른 메시지랑 섞일 수 있는 채널에서 봇 응답이 메인 채널을 어지럽히지 않도록 하기 위한 구조라고 보면 된다.

Thread에서의 동작

이미 Hermes가 활성화된 thread 안에서는 이후 답글에 매번 멘션하지 않아도 대화를 이어갈 수 있다.

흐름은 다음과 같다.

채널:
@Hermes 이 로그 분석해줘.

Thread:
Hermes: 원인은 kubelet 설정 문제로 보인다.

사용자:
해결 명령어만 정리해줘.

Hermes:
앞서 분석한 kubelet 문제 기준으로 명령어를 정리하면...

즉 채널에서 대화를 시작할 때는 멘션하고, thread 안에서는 자연스럽게 이어가면 된다.

Slack 동작 설정

Thread 응답 설정

Slack Bot의 thread 응답 방식은 ~/.hermes/config.yaml에서 조정할 수 있다.

platforms:
  slack:
    reply_to_mode: "first"
    extra:
      reply_in_thread: true
      reply_broadcast: false

각 설정의 의미는 다음과 같다.

설정	기본값	의미
`platforms.slack.reply_to_mode`	`"first"`	여러개의 메시지가 있을 때 thread 처리 방식
`platforms.slack.extra.reply_in_thread`	`true`	채널 메시지에 thread로 답할지 여부
`platforms.slack.extra.reply_broadcast`	`false`	thread 답변을 메인 채널에도 보낼지 여부

reply_to_mode는 다음 값 중 하나를 사용할 수 있다.

값	의미
`off`	원본 메시지에 thread로 묶지 않는다
`first`	첫 번째 응답 조각만 원본 메시지에 thread로 묶는다
`all`	모든 응답 조각을 원본 메시지에 thread로 묶는다

사용자별 세션 분리

공유 채널에서는 사용자별로 대화 세션을 분리하는 게 기본값이다.

group_sessions_per_user: true

이 값이 true이면 같은 채널에서 여러 사람이 Hermes에게 말을 걸어도 각자의 대화 맥락이 분리된다.

예를 들면 다음과 같다.

#general 안에서

A 사용자 → Hermes와 Kubernetes 문제 상담
B 사용자 → Hermes와 블로그 글 작성 상담

두 대화의 컨텍스트는 서로 섞이지 않음

반대로 협업 모드처럼 채널 전체가 하나의 대화 세션을 공유하게 하려면 다음처럼 설정할 수 있다.

group_sessions_per_user: false

다만 이 경우에는 주의가 필요하다.

여러 사용자의 대화 맥락이 섞일 수 있다.
토큰 사용량이 늘어날 수 있다.
한 사용자의 /reset이 전체 채널 세션을 초기화할 수 있다.

멘션 트리거 설정

Slack 채널에서는 기본적으로 멘션이 필요하다.

명시적으로 설정하려면 다음처럼 할 수 있다.

slack:
  require_mention: true
  mention_patterns:
    - "hey hermes"
    - "hermes,"
  reply_prefix: ""

mention_patterns를 사용하면 @mention 외에도 특정 문구로 봇을 호출할 수 있다.

예를 들면 다음 문구도 트리거로 만들 수 있다.

hey hermes
hermes,

특정 채널에서 자유 응답 허용

Slack은 기본적으로 채널에서 @mention이 필요하지만, 특정 채널은 멘션이 필요 없는 자유 응답 채로 설정할 수 있다.

환경변수 방식은 다음과 같다.

SLACK_FREE_RESPONSE_CHANNELS=C01234567890,C09876543210

또는 config.yaml에서 설정할 수 있다.

slack:
  free_response_channels:
    - C01234567890
    - C09876543210

이 기능은 전용 봇 채널처럼 Hermes가 모든 메시지를 읽고 응답해도 되는 채널에서만 사용하는 게 좋다.

Home Channel 설정

Home Channel 용도

SLACK_HOME_CHANNEL은 Hermes가 예약 메시지, cron 결과, proactive notification을 보낼 기본 Slack 채널이다.

예를 들면 다음과 같은 작업 결과를 받을 수 있다.

매일 아침 서버 상태 점검 결과
예약된 리포트 생성 결과
백그라운드 작업 완료 알림

설정 예시는 다음과 같다.

SLACK_HOME_CHANNEL=C01234567890
SLACK_HOME_CHANNEL_NAME=general

Channel ID 찾는 방법

Slack Channel ID는 다음 방법으로 찾을 수 있다.

Slack에서 채널 이름을 우클릭한다.
View channel details를 클릭한다.
하단으로 스크롤한다.
Channel ID를 확인한다.

주의할 점은 SLACK_HOME_CHANNEL에는 채널 이름이 아니라 채널 ID를 넣어야 한다는 것이다.

또한 Hermes Bot이 해당 채널에 초대되어 있어야 한다.

/invite @Hermes Agent

채널별 Prompt 설정

Per-Channel Prompt란 무엇인가

슬랙 채널별로 임시 시스템 프롬프트를 지정할 수 있다.

이 프롬프트는 매 응답마다 주입되지만 대화 기록에는 저장되지 않는다.

즉 설정을 바꾸면 즉시 반영되고, 대화 기록 자체에는 남지 않는다.

문서 예시는 다음과 같다.

slack:
  channel_prompts:
    "C01RESEARCH": |
      너는 연구원을 보조하는 역할이야. 학술적인 부분에 집중해.
    "C02ENGINEERING": |
      코드 리뷰 모드. 엣지 케이스와 퍼포먼스 영향도 주의.

멀티 워크스페이스 설정

여러 Slack Workspace 연결

Hermes는 하나의 Gateway 인스턴스로 여러 Slack workspace에 연결할 수 있다.

여러 Bot Token을 쉼표로 구분해서 넣으면 된다.

SLACK_BOT_TOKEN=xoxb-workspace1-token,xoxb-workspace2-token,xoxb-workspace3-token
SLACK_APP_TOKEN=xapp-your-app-token

또는 config.yaml에 넣을 수 있다.

platforms:
  slack:
    token: "xoxb-workspace1-token,xoxb-workspace2-token"

OAuth Token File 사용

토큰 파일을 사용할 수도 있다.

파일 위치는 다음과 같다.

~/.hermes/slack_tokens.json

형식은 다음과 같다.

{
  "T01ABC2DEF3": {
    "token": "xoxb-workspace-token-here",
    "team_name": "My Workspace"
  }
}

이 파일의 토큰은 SLACK_BOT_TOKEN으로 지정한 토큰과 병합된다.

중복 토큰은 자동으로 deduplicate 된다.

멀티 워크스페이스 동작 방식

동작 방식은 다음과 같다.

첫 번째 Bot Token이 primary token이 된다.
각 token은 시작 시 auth.test로 검증된다.
Hermes는 team_id별로 WebClient와 bot_user_id를 매핑한다.
메시지가 들어오면 해당 workspace에 맞는 client로 응답한다.

일반적인 개인 사용에서는 멀티 워크스페이스가 필요하지 않다.

회사 workspace와 개인 workspace를 하나의 Hermes Gateway에서 함께 관리하고 싶을 때 고려하면 된다.

[인공지능/Hermes] 헤르메스 메시징 게이트웨이 이해하기

초보 & 뉴비 — Sat, 25 Apr 2026 19:56:24 +0900

Hermes Messaging Gateway 정리

한 줄 요약

Hermes Messaging Gateway는 Telegram, Discord, Slack, WhatsApp 같은 외부 메시징 플랫폼에서 Hermes Agent와 대화할 수 있게 해주는 백그라운드 게이트웨이라고 보면 된다.

쉽게 말하면 터미널에서만 hermes를 쓰는 것이 아니라, 메신저 앱에서도 Hermes Agent를 호출하고 작업을 시킬 수 있게 해주는 중간 서버 역할을 한다.

사용자 메시지
   ↓
Telegram / Discord / Slack / WhatsApp
   ↓
Hermes Messaging Gateway
   ↓
Hermes Agent
   ↓
응답 반환

Messaging Gateway가 하는 일

여러 메시징 플랫폼 연결

Hermes Messaging Gateway는 여러 플랫폼을 하나의 프로세스에서 연결할 수 있다.

지원 플랫폼은 다음과 같다.

Telegram
Discord
Slack
WhatsApp
Signal
SMS
Email
Home Assistant
Mattermost
Matrix
DingTalk
Feishu / Lark
WeCom
Weixin
BlueBubbles
QQ
Open WebUI
Webhooks

즉 하나의 Hermes Agent를 여러 채널에서 사용할 수 있다.

예를 들면 이런 식이다.

Telegram에서는 개인 비서처럼 사용
Discord에서는 개발 서버 봇처럼 사용
Slack에서는 팀 작업 도우미처럼 사용
Email에서는 비동기 작업 처리용으로 사용
Home Assistant에서는 홈 자동화 제어용으로 사용

세션 관리

Gateway는 플랫폼별, 채팅별 세션을 관리한다.

즉 Telegram에서 나눈 대화와 Discord에서 나눈 대화는 서로 다른 세션으로 관리될 수 있다.

이 구조 덕분에 각 채팅방마다 대화 맥락을 따로 유지할 수 있다.

Telegram DM 세션
Discord 채널 세션
Slack 채널 A 세션
Slack 채널 B 세션

세션은 메시지를 보낼 때마다 이어지고, 특정 조건이 되면 초기화될 수 있다.

cron 작업 실행

Gateway는 단순 메시지 중계만 하는 것이 아니라 cron scheduler도 함께 실행한다.

문서 기준으로 Gateway는 60초마다 due job이 있는지 확인한다.

즉 예약 작업이나 반복 작업을 Hermes Agent와 연결해서 사용할 수 있다.

예를 들면 다음과 같은 작업이 가능하다.

매일 아침 서버 상태 점검
매시간 특정 서비스 health check
정해진 시간에 요약 리포트 생성
주기적으로 파일 정리

음성 메시지 처리

Gateway는 플랫폼에 따라 음성 관련 기능도 처리할 수 있다.

지원 범위는 플랫폼마다 다르지만, 기본적으로 다음과 같은 기능을 기대할 수 있다.

음성 메시지 transcription
TTS 음성 응답
Discord voice-channel 대화
메시징 플랫폼에서 음성 답변 전달

다만 모든 플랫폼이 동일한 음성 기능을 지원하는 것은 아니다.

전체 아키텍처

기본 흐름

Messaging Gateway의 기본 흐름은 다음과 같다.

Platform Adapter
   ↓
Per-chat Session Store
   ↓
AIAgent
   ↓
Platform Adapter
   ↓
사용자에게 응답

각 플랫폼에는 adapter가 있다.

예를 들어 Telegram에는 Telegram adapter, Discord에는 Discord adapter, Slack에는 Slack adapter가 있다고 보면 된다.

Adapter는 외부 플랫폼에서 들어온 메시지를 받아 Hermes Agent가 이해할 수 있는 형태로 넘기고, Hermes Agent의 응답을 다시 해당 플랫폼으로 돌려보낸다.

플랫폼 Adapter

Platform Adapter는 각 메시징 서비스와 직접 통신하는 부분이다.

역할은 다음과 같다.

메시지 수신
사용자 인증 확인
첨부파일 처리
이미지 처리
음성 메시지 처리
typing indicator 표시
streaming 응답 업데이트
thread 처리
reaction 처리

지원 기능은 플랫폼마다 다르다.

예를 들어 Discord와 Slack은 thread, reaction, typing, streaming 같은 기능을 폭넓게 지원하지만, SMS는 기능이 제한적이다.

Session Store

Session Store는 채팅별 대화 상태를 관리한다.

즉 사용자가 이전에 어떤 질문을 했고, Hermes가 어떤 답을 했는지 기억하는 역할을 한다.

세션이 유지되면 다음과 같은 대화가 가능하다.

사용자: 이 서버 로그 분석해줘.
Hermes: 이 로그에서는 kubelet 문제가 보인다.

사용자: 그럼 해결 명령어만 정리해줘.
Hermes: 앞서 분석한 kubelet 문제 기준으로 해결 명령어를 정리하면...

반대로 세션이 초기화되면 이전 대화 맥락 없이 새 대화로 시작한다.

AIAgent 처리

Gateway가 메시지를 받으면 최종적으로 Hermes의 AIAgent로 전달된다.

AIAgent는 다음을 수행할 수 있다.

일반 질의응답
코드 분석
터미널 명령 실행
파일 작업
웹 검색
MCP 도구 호출
스킬 실행
백그라운드 작업 실행

중요한 점은 메시징 플랫폼에서도 Hermes의 도구 기능을 사용할 수 있다는 것이다.

따라서 보안 설정을 반드시 신경 써야 한다.

세션 관리

Session Persistence

Gateway 세션은 메시지 사이에서 유지된다.

즉 한 번 질문하고 끝나는 구조가 아니라, 같은 채팅방에서는 이전 대화 맥락을 이어서 사용할 수 있다.

예를 들어 다음과 같은 흐름이 가능하다.

사용자: 이 Docker Compose 파일 분석해줘.
Hermes: redis, api, db 서비스로 구성되어 있다.

사용자: 여기서 db 볼륨만 분리하려면 어떻게 해?
Hermes: 앞서 본 compose 구조 기준으로 db service의 volumes를 이렇게 바꾸면 된다.

이런 맥락 유지는 메시징 환경에서 매우 중요하다.

Reset Policy

세션은 설정된 정책에 따라 초기화될 수 있다.

대표 정책은 다음과 같다.

정책	기본값	의미
Daily	오전 4시	매일 특정 시간에 세션 초기화
Idle	1440분	일정 시간 동안 대화가 없으면 초기화
Both	조합	둘 중 먼저 발생하는 조건으로 초기화

플랫폼별로 reset 정책을 다르게 줄 수도 있다.

설정 파일은 다음 위치를 사용한다.

~/.hermes/gateway.json

예시는 다음과 같다.

{
  "reset_by_platform": {
    "telegram": { "mode": "idle", "idle_minutes": 240 },
    "discord": { "mode": "idle", "idle_minutes": 60 }
  }
}

이렇게 하면 Telegram은 4시간 idle 후 초기화되고, Discord는 1시간 idle 후 초기화된다.

보안 설정

기본 보안 모델

Messaging Gateway는 기본적으로 allowlist에 없는 사용자를 거부한다.

이 기본값은 매우 중요하다.

Hermes Agent는 터미널 실행, 파일 접근, 도구 호출 같은 강력한 기능을 가질 수 있기 때문이다.

즉 아무나 봇에게 DM을 보내서 내 서버 명령을 실행하게 만들면 안 된다.

Allowlist 설정

플랫폼별로 허용할 사용자를 지정할 수 있다.

예시는 다음과 같다.

TELEGRAM_ALLOWED_USERS=123456789,987654321
DISCORD_ALLOWED_USERS=123456789012345678
SIGNAL_ALLOWED_USERS=+155****4567,+155****6543
SMS_ALLOWED_USERS=+155****4567,+155****6543
EMAIL_ALLOWED_USERS=trusted@example.com,colleague@work.com
MATTERMOST_ALLOWED_USERS=3uo8dkh1p7g1mfk49ear5fzs5c
MATRIX_ALLOWED_USERS=@alice:matrix.org
DINGTALK_ALLOWED_USERS=user-id-1
FEISHU_ALLOWED_USERS=ou_xxxxxxxx,ou_yyyyyyyy
WECOM_ALLOWED_USERS=user-id-1,user-id-2

공통 allowlist를 사용할 수도 있다.

GATEWAY_ALLOWED_USERS=123456789,987654321

Allow All 주의

모든 사용자를 허용하는 설정도 있다.

GATEWAY_ALLOW_ALL_USERS=true

하지만 이 설정은 터미널 접근 권한이 있는 봇에서는 권장하지 않는다.

개발 서버, 개인 PC, 운영 서버에 연결된 Hermes라면 반드시 allowlist를 사용하는 게 좋다.

Tool Progress Notification

도구 실행 상태 표시

Hermes가 작업 중 어떤 도구를 실행하는지 메시징 플랫폼에 표시할 수 있다.

설정은 다음 파일에서 한다.

~/.hermes/config.yaml

예시는 다음과 같다.

display:
  tool_progress: all
  tool_progress_command: false

tool_progress는 다음 값을 가질 수 있다.

값	의미
`off`	도구 진행 상황을 표시하지 않는다
`new`	새 도구 실행만 표시한다
`all`	도구 실행 상황을 표시한다
`verbose`	더 자세히 표시한다

예를 들어 Hermes가 작업하면서 다음과 같은 상태 메시지를 보낼 수 있다.

`ls -la`...
web_search...
web_extract...
execute_code...

언제 켜면 좋은가

Tool Progress Notification은 다음 상황에서 유용하다.

Hermes가 멈춘 것처럼 보이는 문제를 줄이고 싶을 때
장시간 작업 중 어떤 명령을 실행하는지 보고 싶을 때
터미널 명령 실행 여부를 확인하고 싶을 때
팀 채널에서 Agent 작업 과정을 투명하게 보여주고 싶을 때

반대로 메시지가 너무 많이 오는 것이 싫다면 off 또는 new로 줄이면 된다.

Background Sessions

개념

Messaging Gateway에서는 /background 명령으로 별도 백그라운드 세션을 실행할 수 있다.

예시는 다음과 같다.

/background Check all servers in the cluster and report any that are down

이 명령을 보내면 Hermes는 별도 Agent instance를 만들어 작업을 수행한다.

사용자는 메인 채팅을 계속 사용할 수 있고, 작업이 끝나면 같은 채팅방으로 결과가 돌아온다.

동작 방식

Background session은 다음 특징을 가진다.

별도 세션으로 실행된다.
현재 채팅 맥락을 자동으로 공유하지 않는다.
prompt에 적은 내용만 전달된다.
현재 Gateway 설정의 model, provider, toolset, reasoning 설정을 상속한다.
메인 채팅은 계속 사용할 수 있다.
작업 완료 시 같은 채팅방에 결과가 전달된다.

즉 독립적인 작업 큐처럼 사용할 수 있다.

사용 예시

서버 상태 점검을 백그라운드로 실행할 수 있다.

/background 모든 서비스에 대해 헬스체크를 하고 다운 상태가 있으면 알려줘

긴 빌드 작업을 맡길 수도 있다.

/background staing 환경 빌드하고 배포해

조사 작업도 가능하다.

/background 경쟁사의 제품에 대해 분석을 하고 테이블(표)로 요약해줘

파일 정리 작업도 시킬 수 있다.

/background ~/Downloads 폴더에 있는 사진을 날짜순으로 정리해줘

Background Process Notification

백그라운드 작업 중 장기 실행 프로세스의 상태 알림을 받을 수 있다.

설정 예시는 다음과 같다.

display:
  background_process_notifications: all

사용 가능한 값은 다음과 같다.

값	의미
`all`	실행 중 출력과 최종 완료 메시지를 모두 받는다
`result`	최종 완료 메시지만 받는다
`error`	실패했을 때만 최종 메시지를 받는다
`off`	프로세스 watcher 메시지를 받지 않는다

환경변수로도 설정할 수 있다.

HERMES_BACKGROUND_NOTIFICATIONS=result

메시징 플랫폼별 기능 차이

기능 비교 관점

모든 메시징 플랫폼이 같은 기능을 지원하는 것은 아니다.

비교할 때는 다음 기능을 보면 된다.

기능	의미
Voice	TTS 응답 또는 음성 메시지 transcription
Images	이미지 송수신
Files	파일 첨부 송수신
Threads	thread 기반 대화
Reactions	emoji reaction
Typing	처리 중 typing indicator
Streaming	응답을 점진적으로 업데이트

예를 들어 Telegram, Discord, Slack은 비교적 많은 기능을 지원한다.

SMS는 기능이 매우 제한적이다. ( 문자로 쓸일이 있을까... )

Email은 이미지, 파일, thread에는 강점이 있지만 typing이나 streaming 같은 실시간 기능은 기대하기 어렵다. ( 마찬가지로 이메일로 쓸일이 있을까... )

플랫폼 선택 기준

개인용으로는 Telegram이 간단하다.

팀 채널에서는 Discord나 Slack이 적합하다.

자동화와 시스템 연동은 Webhooks나 Home Assistant가 적합하다. => 단순 작업이면 오픈클로가 훨씬 가볍다.

이메일 기반 비동기 작업은 Email integration을 고려할 수 있다.

정리하면 다음과 같다.

목적	추천 플랫폼
개인 비서처럼 사용	Telegram
개발 커뮤니티 또는 팀 서버	Discord
업무 채널 연동	Slack
모바일 메신저 중심	WhatsApp, Signal
서버 자동화	Webhooks
홈 자동화	Home Assistant
비동기 업무 처리	Email
자체 UI 연동	Open WebUI

운영 시 주의할 점

allowlist는 필수로 보는 게 좋다

Gateway는 기본적으로 allowlist에 없는 사용자를 거부한다.

이 기본값을 유지하는 게 좋다.

특히 Hermes가 다음 권한을 가진다면 더더욱 allowlist가 필요하다.

터미널 실행
파일 수정
서버 접속
API 호출
배포 명령 실행
Home Assistant 제어

GATEWAY_ALLOW_ALL_USERS=true는 테스트 환경이 아니라면 피하는 게 좋다.

user service와 system service를 동시에 쓰지 않는 게 좋다

Linux에서는 user service와 system service를 둘 다 설치할 수 있다.

하지만 둘 다 설치하면 start, stop, status 대상이 모호해질 수 있다.

문서에서도 두 service unit을 동시에 유지하는 것을 피하라고 안내한다.

개발 머신은 user service를 쓰고, 서버는 system service를 쓰는 식으로 하나만 선택하면 된다.

background 작업은 현재 대화 맥락을 자동 공유하지 않는다

/background는 독립 세션으로 실행된다.

따라서 현재 대화에서만 알고 있는 정보를 바탕으로 백그라운드 작업을 시키면 원하는 결과가 나오지 않을 수 있다.

나쁜 예시는 다음과 같다.

/background 아까 말한 서버들 점검해줘

더 좋은 예시는 다음과 같다.

/background Check these servers: node01, node02, node03. Verify SSH, disk usage, kubelet status, and containerd status. Report failures only.

background prompt는 독립적으로 이해할 수 있게 구체적으로 작성하면 된다.

[인공지능/Hermes] 헤르메스 메모리 시스템 이해하기

초보 & 뉴비 — Sat, 25 Apr 2026 19:32:08 +0900

헤르메스 에이전트 메모리 시스템 정리

한 줄 요약

Hermes Agent의 메모리는 항상 필요한 핵심 사실은 Markdown 파일에 저장하고, 과거 대화는 SQLite 검색으로 찾고, 더 깊은 장기 기억은 외부 Provider로 확장하며, 반복 작업은 Skill로 절차화하는 다층 메모리 구조라고 보면 된다.

전체 구조

Hermes Agent의 메모리 시스템은 크게 보면 다음 계층으로 나눌 수 있다.

내장 영구 메모리
세션 검색 메모리
외부 메모리 Provider
스킬 기반 절차적 메모리
사용자 모델링 메모리

정리하면 단순히 기억 파일 하나를 두는 구조가 아니라, 짧고 중요한 사실은 항상 프롬프트에 넣고, 과거 대화는 검색으로 가져오고, 더 깊은 장기 기억은 외부 메모리 Provider로 확장하는 방식이라고 보면 된다.

내장 영구 메모리

MEMORY.md

MEMORY.md는 에이전트가 기억해야 하는 개인 노트에 가깝다.

저장 위치는 다음과 같다.

~/.hermes/memories/MEMORY.md

주로 이런 정보를 저장한다.

사용자의 개발 환경
프로젝트 정보
자주 쓰는 명령어
특정 서버나 도구의 특이사항
에이전트가 작업하면서 학습한 사실
나중에도 반복적으로 도움이 될 운영 지식

예를 들면 이런 내용이 들어갈 수 있다.

User runs macOS with zsh and Homebrew. Main editor is VS Code.
Project ~/code/api uses Go 1.22, sqlc, chi router. Run tests with make test.
Staging server requires SSH port 2222 instead of 22.

이 메모리는 에이전트의 개인 작업 노트라고 보면 된다.

USER.md

USER.md는 사용자 프로필에 가깝다.

저장 위치는 다음과 같다.

~/.hermes/memories/USER.md

주로 이런 정보를 저장한다.

사용자의 선호
응답 스타일
커뮤니케이션 방식
장기적인 목표
반복적으로 나타나는 기대사항
사용자가 원하는 작업 방식

예를 들면 이런 내용이 들어갈 수 있다.

User prefers concise technical answers with concrete commands.
User likes explanations structured as problem, cause, fix, and verification.
User works mostly on infrastructure, blockchain, and backend systems.

즉 MEMORY.md가 작업 환경과 지식 중심이라면, USER.md는 사용자 자체에 대한 이해를 저장하는 공간이라고 보면 된다.

프롬프트 주입 방식

MEMORY.md와 USER.md는 세션 시작 시 시스템 프롬프트에 삽입된다.

중요한 특징은 frozen snapshot 방식이라는 점이다.

즉 세션 시작 시점의 메모리 내용이 프롬프트에 들어가고, 세션 중간에 메모리를 수정하더라도 현재 프롬프트에는 바로 반영되지 않는다.

대신 디스크에는 즉시 저장되고, 다음 세션부터 새 메모리 내용이 반영된다.

이렇게 하는 이유는 프롬프트 캐시 효율과 세션 안정성을 유지하기 위해서라고 보면 된다.

세션 검색 메모리

session_search

Hermes Agent는 모든 과거 대화를 무조건 MEMORY.md에 넣지 않는다.

대신 과거 세션 전체를 SQLite에 저장하고, 필요할 때 session_search 도구로 검색한다.

저장 위치는 다음과 같다.

~/.hermes/state.db

검색 방식은 SQLite FTS5 기반이다.

즉 과거 CLI 대화나 메신저 대화가 세션 단위로 저장되고, 나중에 에이전트가 다음과 같은 질문을 받으면 검색해서 찾아올 수 있다.

지난주에 내가 말한 Kubernetes 문제 기억나?
전에 설정했던 서버 IP 뭐였지?
저번에 분석한 설치 스크립트 다시 찾아줘.

Persistent Memory와 Session Search 차이

MEMORY.md / USER.md와 session_search는 목적이 다르다.

구분	Persistent Memory	Session Search
저장 대상	핵심 사실	모든 과거 세션
저장 위치	`~/.hermes/memories/`	`~/.hermes/state.db`
검색 방식	프롬프트에 항상 주입	필요할 때 검색
용량	제한 있음	사실상 세션 누적
속도	즉시 사용 가능	검색과 요약 필요
용도	항상 알아야 하는 정보	과거 대화 회상

쉽게 말하면 다음과 같다.

MEMORY.md, USER.md는 항상 기억해야 하는 핵심 메모리다.
session_search는 과거 대화 전체를 뒤지는 검색 메모리다.

외부 메모리 Provider

개념

Hermes Agent는 기본 메모리 외에 외부 메모리 Provider를 붙일 수 있다.

외부 Provider는 MEMORY.md와 USER.md를 대체하는 것이 아니라 추가로 붙는 구조다.

즉 기본 메모리는 항상 유지되고, 그 위에 외부 장기 기억 시스템을 하나 더 연결하는 방식이다.

중요한 제약은 한 번에 하나의 외부 Provider만 활성화할 수 있다는 점이다.

설정은 다음처럼 할 수 있다.

hermes memory setup
hermes memory status
hermes memory off

또는 config.yaml에서 직접 지정할 수 있다.

memory:
  provider: honcho

사용 가능한 Provider는 다음 8개다.

Honcho
OpenViking
Mem0
Hindsight
Holographic
RetainDB
ByteRover
Supermemory

Honcho

특징

Honcho는 사용자 모델링에 강한 메모리 Provider다.

단순히 사용자가 말한 내용을 저장하는 수준이 아니라, 대화를 분석해서 사용자의 성향, 목표, 선호, 커뮤니케이션 패턴을 추론한다.

핵심 기능은 다음과 같다.

cross-session user modeling
dialectic reasoning
session-scoped context injection
semantic search
persistent conclusions
peer 기반 사용자/AI 모델 분리

적합한 경우

Honcho는 이런 경우에 적합하다.

사용자를 장기적으로 이해하는 에이전트를 만들고 싶을 때
여러 프로필 또는 여러 에이전트가 같은 사용자와 상호작용할 때
단순 기억보다 사용자 성향 추론이 중요할 때
AI가 사용자의 작업 방식과 목표를 점점 더 잘 파악하게 만들고 싶을 때

OpenViking

특징

OpenViking은 ByteDance 계열 Volcengine의 context database를 기반으로 한 self-hosted 메모리 Provider다.

핵심 특징은 다음과 같다.

filesystem-style knowledge hierarchy
tiered retrieval
automatic memory extraction
viking:// URI 기반 지식 탐색
self-hosted 구조

OpenViking은 기억을 계층형 지식 저장소처럼 다루는 방식에 가깝다.

적합한 경우

OpenViking은 이런 경우에 적합하다.

클라우드 메모리 서비스 대신 직접 호스팅하고 싶을 때
지식을 폴더나 파일 시스템처럼 계층적으로 탐색하고 싶을 때
프로젝트 지식 베이스를 에이전트와 연결하고 싶을 때

Mem0

특징

Mem0는 서버 측 LLM 기반 fact extraction을 제공하는 메모리 Provider다.

핵심 특징은 다음과 같다.

자동 사실 추출
semantic search
reranking
automatic deduplication
cloud 기반 저장

즉 에이전트가 대화를 일일이 정리하지 않아도 Mem0 쪽에서 기억할 만한 사실을 추출하고 관리하는 방식이다.

적합한 경우

Mem0는 이런 경우에 적합하다.

메모리 관리를 최대한 자동화하고 싶을 때
cloud 기반 장기 기억을 빠르게 붙이고 싶을 때
fact extraction과 deduplication을 직접 구현하고 싶지 않을 때

Hindsight

특징

Hindsight는 knowledge graph 기반 장기 메모리 Provider다.

핵심 특징은 다음과 같다.

knowledge graph
entity resolution
multi-strategy retrieval
cross-memory synthesis
full conversation turn retention
session-level document tracking

단순 검색보다 엔티티 관계와 기억 간 연결을 중시하는 구조라고 보면 된다.

적합한 경우

Hindsight는 이런 경우에 적합하다.

엔티티 관계를 기반으로 기억을 검색하고 싶을 때
여러 기억을 종합해서 결론을 내리는 기능이 필요할 때
프로젝트, 사람, 문서, 사건 사이의 관계가 중요한 경우
cloud 또는 local PostgreSQL 기반 메모리를 쓰고 싶을 때

Holographic

특징

Holographic은 로컬 SQLite 기반 fact store다.

핵심 특징은 다음과 같다.

local SQLite 저장
FTS5 full-text search
trust scoring
HRR 기반 compositional query
conflicting fact detection
외부 서비스 의존성 없음

가장 큰 장점은 로컬에서만 동작할 수 있다는 점이다.

적합한 경우

Holographic은 이런 경우에 적합하다.

외부 클라우드 없이 로컬 메모리만 쓰고 싶을 때
SQLite 기반으로 단순하게 관리하고 싶을 때
fact 단위 저장, 검색, 신뢰도 점수 관리가 필요할 때
conflicting fact를 탐지하고 싶을 때

RetainDB

특징

RetainDB는 cloud memory API 기반 Provider다.

핵심 특징은 다음과 같다.

Vector search
BM25
reranking
hybrid search
7 memory types
delta compression

검색 품질과 memory type 분류를 중시하는 클라우드 기반 메모리라고 보면 된다.

적합한 경우

RetainDB는 이런 경우에 적합하다.

팀 단위로 RetainDB 인프라를 이미 쓰고 있을 때
vector search와 BM25를 함께 쓰는 hybrid search가 필요할 때
memory type 기반 정리가 필요한 경우
클라우드 API 기반 메모리를 선호할 때

ByteRover

특징

ByteRover는 brv CLI 기반의 local-first 메모리 Provider다.

핵심 특징은 다음과 같다.

hierarchical knowledge tree
fuzzy text search
LLM-driven search
local-first storage
optional cloud sync
pre-compression extraction

특히 context compression 전에 중요한 내용을 먼저 추출해서 저장하는 기능이 특징이다.

적합한 경우

ByteRover는 이런 경우에 적합하다.

개발자 친화적인 CLI 기반 메모리를 원할 때
로컬 우선 저장 방식을 선호할 때
지식을 knowledge tree 형태로 관리하고 싶을 때
필요하면 cloud sync도 붙이고 싶을 때

Supermemory

특징

Supermemory는 semantic long-term memory Provider다.

핵심 특징은 다음과 같다.

semantic recall
profile recall
semantic search
explicit memory tools
session-end conversation ingest
graph-level knowledge building
context fencing
multi-container support

context fencing은 회수된 메모리가 다시 저장되어 메모리 오염이 반복되는 문제를 줄이기 위한 장치라고 보면 된다.

적합한 경우

Supermemory는 이런 경우에 적합하다.

semantic search 중심의 장기 메모리가 필요할 때
사용자 프로필과 최근 맥락을 함께 쓰고 싶을 때
세션 종료 시 대화 전체를 그래프 형태로 흡수하고 싶을 때
프로젝트별 container를 나눠서 메모리를 관리하고 싶을 때

메모리 저장 위치 정리

기본 파일 구조

Hermes Agent의 기본 메모리 관련 파일은 대략 다음 구조로 볼 수 있다.

~/.hermes/
├── memories/
│   ├── MEMORY.md
│   └── USER.md
├── state.db
├── skills/
└── config.yaml

각 파일의 역할은 다음과 같다.

위치	역할
`~/.hermes/memories/MEMORY.md`	에이전트 개인 노트
`~/.hermes/memories/USER.md`	사용자 프로필
`~/.hermes/state.db`	세션 저장 및 검색
`~/.hermes/config.yaml`	메모리 설정 및 Provider 지정

설정 예시

기본 메모리 설정

~/.hermes/config.yaml에서 기본 메모리 설정은 다음과 같이 구성할 수 있다.

memory:
  memory_enabled: true
  user_profile_enabled: true
  memory_char_limit: 2200
  user_char_limit: 1375

각 항목의 의미는 다음과 같다.

설정	의미
`memory_enabled`	`MEMORY.md` 사용 여부
`user_profile_enabled`	`USER.md` 사용 여부
`memory_char_limit`	에이전트 메모리 글자 수 제한
`user_char_limit`	사용자 프로필 글자 수 제한

외부 Provider 설정

외부 Provider를 쓰려면 다음처럼 설정할 수 있다.

memory:
  provider: honcho

다른 Provider를 쓰려면 값만 바꾸면 된다.

memory:
  provider: openviking

사용 가능한 값은 다음과 같다.

honcho
openviking
mem0
hindsight
holographic
retaindb
byterover
supermemory

각 메모리 시스템 비교

비교표

메모리 시스템	저장 방식	주요 용도	특징
`MEMORY.md`	로컬 Markdown 파일	에이전트 개인 노트	항상 프롬프트에 주입
`USER.md`	로컬 Markdown 파일	사용자 프로필	선호, 스타일, 기대사항 저장
`session_search`	SQLite + FTS5	과거 대화 검색	필요할 때 검색 후 요약
Honcho	Cloud 또는 self-hosted	사용자 모델링	dialectic reasoning
OpenViking	self-hosted	계층형 지식 관리	tiered retrieval
Mem0	Cloud	자동 사실 추출	deduplication, reranking
Hindsight	Cloud 또는 local	지식 그래프	entity relationship, reflect
Holographic	Local SQLite	로컬 fact store	trust scoring, conflict detection
RetainDB	Cloud	hybrid search	Vector + BM25 + reranking
ByteRover	Local 또는 Cloud	knowledge tree	CLI 기반 local-first
Supermemory	Cloud	semantic long-term memory	context fencing, graph ingest
Skills	Markdown/스킬 파일	절차적 메모리	작업 루틴 재사용

실제 사용 관점 정리

개인 개발자 기준 추천

개인 개발자가 로컬에서 Hermes Agent를 써보는 정도라면 처음에는 기본 메모리만으로도 충분하다.

우선 다음 조합이면 된다.

MEMORY.md
USER.md
session_search
skills

이 조합만으로도 다음이 가능하다.

내 개발 환경 기억
프로젝트별 규칙 기억
내 답변 스타일 기억
과거 대화 검색
반복 작업 스킬화

로컬 우선 메모리가 필요할 때

외부 클라우드 없이 로컬에서만 쓰고 싶으면 다음 Provider가 적합하다.

Holographic
ByteRover
OpenViking

각각의 느낌은 다음과 같다.

Provider	추천 상황
Holographic	SQLite 기반 로컬 fact store가 필요할 때
ByteRover	CLI 기반 knowledge tree를 원할 때
OpenViking	self-hosted 지식 계층과 tiered retrieval이 필요할 때

사용자 모델링이 중요할 때

사용자 성향과 장기적 선호를 깊게 모델링하고 싶으면 Honcho가 가장 특화되어 있다.

Honcho

Honcho는 단순 기억보다 사용자를 이해하는 모델에 가깝다.

검색 품질이 중요할 때

검색 품질이나 semantic search가 중요하면 다음 Provider를 고려할 수 있다.

Mem0
RetainDB
Supermemory
Hindsight

각각의 방향은 조금 다르다.

Provider	강점
Mem0	자동 fact extraction
RetainDB	hybrid search
Supermemory	semantic recall + graph ingest
Hindsight	knowledge graph + synthesis

결론

핵심 요약

Hermes Agent의 메모리 시스템은 다음처럼 정리할 수 있다.

MEMORY.md는 에이전트가 기억해야 할 작업 지식이다.
USER.md는 사용자 선호와 프로필을 저장하는 공간이다.
session_search는 과거 대화 전체를 SQLite FTS5로 검색하는 기능이다.
외부 Provider는 기본 메모리를 대체하지 않고 확장한다.
외부 Provider는 한 번에 하나만 활성화할 수 있다.
사용 가능한 외부 Provider는 Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory다.
Skills System은 작업 절차를 저장하고 재사용하는 절차적 메모리로 볼 수 있다.

[인공지능/Hermes] 헤르메스 리눅스에 설치하기

초보 & 뉴비 — Sat, 25 Apr 2026 19:17:58 +0900

설치 명령어

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

설치 명령어 실행 시 위 사진처럼 자동으로 필요한 과정들을 진행하며 설치한다.

참고로 설치하고자 하는 서버에 오픈클로가 설치되었을 경우 위 사진의 상단부 노란색처럼 오픈클로 데이터를 가져올지 물어본다.
초록색으로 표시 된 "Wolud import"가 가져올 수 있는거고 "Would skip"이 가져오지 못하는 데이터인데 생각보다 가져오지 못하는 데이터가 많은 것을 볼 수 있다.

오픈클로 데이터 마이그레이션에 대해 워닝 메시지인데 그대로 진행하면 기존에 연동 된 메신저가 제대로 동작하지 않을 수 있기에 나는 "N"을 선택 후 세팅은 직접 하기로 했다.

헤르메스 셋업 여부를 결정하는데 간단하게 사용하기 위해 "Quick setup"으로 진행한다.

프로바이더 선택화면인데 원하는 프로바이더를 선택하면 된다. 나는 OpenAI (ChatGPT)를 메인으로 사용하고 있어서 코덱스를 선택했다.

가이드되로 인증하면 된다.

설치 과정에서 선택 여부에 따라 현재 사용 가능한 것과 가능하지 않은 것들을 보여주는데 추후 필요에 따라 부분 설정하면 모든 툴을 사용할 수 있다.
제일 하단에 노란색 글씨로 헤르메스 채팅을 런칭할지 물어보는데 Y를 누른다.

그러면 위 사진처럼 헤르메스 채팅이 런칭된다.

이하 내용 스크립트 상세 분석

스크립트 개요

이 스크립트는 Hermes Agent를 사용자의 홈 디렉터리 아래에 설치하고, Python/Node.js 의존성, CLI 명령어, 설정 파일, 브라우저 도구, 메시징 게이트웨이까지 한 번에 구성하는 설치 스크립트라고 보면 된다.

기본 설치 위치

기본 경로

스크립트는 기본적으로 아래 경로를 사용한다.

~/.hermes
~/.hermes/hermes-agent

구체적으로는 다음 변수를 사용한다.

HERMES_HOME="${HERMES_HOME:-$HOME/.hermes}"
INSTALL_DIR="${HERMES_INSTALL_DIR:-$HERMES_HOME/hermes-agent}"

즉 기본 구조는 이렇게 된다.

~/.hermes/
├── hermes-agent/      # 소스 코드
├── .env               # API 키 설정
├── config.yaml        # Hermes 설정
├── SOUL.md            # 페르소나 설정
├── cron/
├── sessions/
├── logs/
├── pairing/
├── hooks/
├── image_cache/
├── audio_cache/
├── memories/
└── skills/

지원 옵션

실행 옵션

스크립트는 다음 옵션을 받을 수 있다.

--no-venv
--skip-setup
--branch NAME
--dir PATH
--hermes-home PATH
--help

옵션 의미

옵션	의미
`--no-venv`	Python 가상환경을 만들지 않는다
`--skip-setup`	설치 후 대화형 설정 마법사를 실행하지 않는다
`--branch NAME`	설치할 Git 브랜치를 지정한다. 기본값은 `main`이다
`--dir PATH`	Hermes Agent 소스 설치 위치를 지정한다
`--hermes-home PATH`	Hermes 데이터 디렉터리를 지정한다
`--help`	도움말을 출력한다

예시는 이렇게 쓸 수 있다.

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh \
  | bash -s -- --skip-setup

OS 감지

감지 대상

스크립트는 uname -s와 Termux 환경 변수를 이용해서 OS를 감지한다.

Linux
macOS
Android Termux
Windows 계열

Windows 처리

Windows가 감지되면 이 Bash 설치 스크립트는 중단된다.

대신 PowerShell 설치 방식을 안내한다.

irm https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.ps1 | iex

즉 이 install.sh는 Windows용이 아니라 Linux/macOS/Termux용이라고 보면 된다.

설치되는 주요 구성 요소

uv 설치 또는 확인

uv는 Python 패키지 관리자이자 Python 버전 관리 도구로 사용된다.

스크립트는 다음 순서로 uv를 찾는다.

PATH에 있는 uv
~/.local/bin/uv
~/.cargo/bin/uv
없으면 https://astral.sh/uv/install.sh를 통해 설치

curl -LsSf https://astral.sh/uv/install.sh | sh

이 부분도 원격 스크립트를 다시 받아 실행하는 구조다.

즉 이 설치 스크립트는 직접적으로 다음 원격 코드를 실행한다.

https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh
https://astral.sh/uv/install.sh

보안상으로는 다운로드 후 직접 검토하고 실행하는 방식이 더 안전하다.

Python 3.11 확인 또는 설치

스크립트는 Python 3.11을 요구한다.

PYTHON_VERSION="3.11"

일반 Linux/macOS에서는 uv를 통해 Python 3.11을 찾고, 없으면 설치한다.

uv python find 3.11
uv python install 3.11

Termux에서는 uv 대신 시스템 Python + venv + pip를 사용한다.

Python이 없으면 아래처럼 설치한다.

pkg install -y python

Git 확인 또는 설치 안내

스크립트는 git이 있는지 확인한다.

Git이 없으면 OS별 설치 방법을 안내한다.

Ubuntu/Debian 계열은 다음 명령을 안내한다.

sudo apt update && sudo apt install git

Fedora 계열은 다음 명령을 안내한다.

sudo dnf install git

Arch 계열은 다음 명령을 안내한다.

sudo pacman -S git

macOS는 다음 명령을 안내한다.

xcode-select --install

또는 Homebrew를 통해 설치할 수 있다.

brew install git

Termux에서는 다음 명령을 사용한다.

pkg install git

Termux에서는 Git을 자동 설치하려고 한다.

Node.js 확인 또는 설치

Node.js는 Hermes의 브라우저 도구, Playwright, TUI 관련 기능에 사용된다.

스크립트는 Node.js 22 버전을 기준으로 설치한다.

NODE_VERSION="22"

이미 node가 있으면 그대로 사용한다.

없으면 다음 경로도 확인한다.

~/.hermes/node/bin/node

그래도 없으면 OS/아키텍처에 맞는 Node.js 바이너리를 다운로드해서 설치한다.

설치 경로는 아래와 같다.

~/.hermes/node/

그리고 다음 심볼릭 링크를 만든다.

~/.local/bin/node
~/.local/bin/npm
~/.local/bin/npx

Termux에서는 아래 명령으로 설치한다.

pkg install -y nodejs

ripgrep, ffmpeg 설치

스크립트는 다음 도구를 확인한다.

도구	용도
`ripgrep` / `rg`	빠른 파일 검색
`ffmpeg`	TTS 음성 메시지 관련 기능

macOS에서 Homebrew가 있으면 자동 설치를 시도한다.

brew install ripgrep ffmpeg

Ubuntu/Debian 계열에서는 다음 명령을 사용한다.

sudo apt install -y ripgrep ffmpeg

Fedora 계열에서는 다음 명령을 사용한다.

sudo dnf install -y ripgrep ffmpeg

Arch 계열에서는 다음 명령을 사용한다.

sudo pacman -S --noconfirm ripgrep ffmpeg

Termux에서는 다음 패키지들을 설치하려고 한다.

pkg install -y clang rust make pkg-config libffi openssl ripgrep ffmpeg

Linux에서는 sudo가 필요할 수 있다.

스크립트는 ripgrep과 ffmpeg를 선택적 시스템 패키지로 보고, 설치 실패 시 Hermes 설치 자체를 반드시 중단하지는 않는다.

Git 저장소 클론 또는 업데이트

새 설치

설치 디렉터리가 없으면 저장소를 클론한다.

먼저 SSH를 시도한다.

git clone --branch main git@github.com:NousResearch/hermes-agent.git ~/.hermes/hermes-agent

SSH가 실패하면 HTTPS로 재시도한다.

git clone --branch main https://github.com/NousResearch/hermes-agent.git ~/.hermes/hermes-agent

SSH는 BatchMode=yes와 ConnectTimeout=5를 사용해서 키가 없을 때 오래 멈추지 않도록 되어 있다.

기존 설치가 있는 경우

이미 설치 디렉터리가 있고 .git 저장소라면 업데이트한다.

수행 흐름은 이렇다.

설치 디렉터리로 이동한다.
로컬 변경사항을 확인한다.
변경사항이 있으면 자동 stash 한다.
git fetch origin을 실행한다.
지정 브랜치로 checkout 한다.
git pull --ff-only를 실행한다.
stash 했던 변경사항 복원을 시도한다.

즉 기존 설치를 덮어쓰기 전에 로컬 변경사항을 보존하려고 한다.

Python 가상환경 생성

기본 동작

기본적으로 venv를 만든다.

~/.hermes/hermes-agent/venv

일반 Linux/macOS에서는 uv를 사용한다.

uv venv venv --python 3.11

Termux에서는 Python 표준 venv를 사용한다.

python -m venv venv

no-venv 사용 시

--no-venv 옵션을 주면 가상환경 생성을 생략한다.

--no-venv

다만 이 경우 시스템 Python 환경에 설치될 수 있으므로 충돌 가능성이 커진다.

Python 패키지 설치

일반 Linux/macOS

기본적으로 editable install을 수행한다.

먼저 모든 extra를 포함해서 설치를 시도한다.

uv pip install -e ".[all]"

실패하면 base install로 fallback한다.

uv pip install -e "."

Ubuntu/Debian 계열에서는 Python 패키지 빌드를 위해 다음 패키지 설치를 제안하거나 시도한다.

build-essential
python3-dev
libffi-dev

Termux

Termux에서는 다음 순서로 설치한다.

python -m pip install --upgrade pip setuptools wheel
python -m pip install -e '.[termux]' -c constraints-termux.txt

실패하면 기본 설치로 fallback한다.

python -m pip install -e '.' -c constraints-termux.txt

또한 Android 빌드 환경을 위해 ANDROID_API_LEVEL을 설정한다.

값을 못 가져오면 기본값으로 24를 사용한다.

Node.js 의존성 설치

루트 package.json

저장소 루트에 package.json이 있으면 아래 명령을 실행한다.

npm install --silent

이건 브라우저 도구 관련 Node 의존성을 설치하는 부분이다.

Playwright Chromium 설치

브라우저 자동화 도구로 Playwright Chromium을 설치한다.

Ubuntu/Debian 계열에서는 다음을 시도한다.

npx playwright install --with-deps chromium

Arch/Manjaro에서는 필요한 시스템 라이브러리를 pacman으로 설치하려고 한다.

sudo pacman -S --noconfirm --needed \
  nss atk at-spi2-core cups libdrm libxkbcommon mesa pango cairo alsa-lib

Fedora/RHEL/CentOS 계열은 자동 의존성 설치를 완전히 지원하지 않으므로 수동 설치 안내를 출력한다.

sudo dnf install nss atk at-spi2-core cups-libs libdrm libxkbcommon mesa-libgbm pango cairo alsa-lib

TUI 의존성 설치

아래 경로에 package.json이 있으면 TUI 의존성을 설치한다.

~/.hermes/hermes-agent/ui-tui/package.json

실행 명령은 다음과 같다.

cd ~/.hermes/hermes-agent/ui-tui
npm install --silent

hermes 명령어 등록

심볼릭 링크 생성

설치 후 hermes 명령어를 전역처럼 사용할 수 있도록 심볼릭 링크를 만든다.

일반 Linux/macOS에서는 다음 위치에 만든다.

~/.local/bin/hermes

Termux에서는 다음 위치에 만든다.

$PREFIX/bin/hermes

가상환경을 쓰는 경우 원본 바이너리는 보통 아래 위치다.

~/.hermes/hermes-agent/venv/bin/hermes

그리고 이렇게 링크된다.

ln -sf ~/.hermes/hermes-agent/venv/bin/hermes ~/.local/bin/hermes

PATH 설정

~/.local/bin이 PATH에 없으면 셸 설정 파일에 추가한다.

zsh에서는 다음 파일을 대상으로 한다.

~/.zshrc
~/.zprofile

bash에서는 다음 파일을 대상으로 한다.

~/.bashrc
~/.bash_profile
~/.profile

fish에서는 다음 파일을 대상으로 한다.

~/.config/fish/config.fish

추가되는 내용은 일반 셸 기준으로 다음과 같다.

# Hermes Agent — ensure ~/.local/bin is on PATH
export PATH="$HOME/.local/bin:$PATH"

fish는 다음 형식이다.

fish_add_path "$HOME/.local/bin"

설정 파일 생성

생성 디렉터리

스크립트는 ~/.hermes 아래에 설정 파일과 데이터 디렉터리를 만든다.

~/.hermes/cron
~/.hermes/sessions
~/.hermes/logs
~/.hermes/pairing
~/.hermes/hooks
~/.hermes/image_cache
~/.hermes/audio_cache
~/.hermes/memories
~/.hermes/skills

.env 생성

없으면 다음 파일을 생성한다.

~/.hermes/.env

저장소에 .env.example이 있으면 복사한다.

cp ~/.hermes/hermes-agent/.env.example ~/.hermes/.env

config.yaml 생성

없으면 다음 파일을 생성한다.

~/.hermes/config.yaml

저장소에 cli-config.yaml.example이 있으면 복사한다.

cp ~/.hermes/hermes-agent/cli-config.yaml.example ~/.hermes/config.yaml

SOUL.md 생성

없으면 기본 페르소나 파일을 만든다.

~/.hermes/SOUL.md

내용은 최소 형태다.

# Hermes Agent Persona

주의할 점은 여기서 # Hermes Agent Persona는 스크립트가 생성하는 파일 내용이다. 이 글의 제목 규칙과는 별개다.

skills 동기화

번들 skills를 사용자 디렉터리로 동기화한다.

~/.hermes/skills/

우선 Python 스크립트로 동기화를 시도한다.

~/.hermes/hermes-agent/tools/skills_sync.py

실패하면 단순 복사 fallback을 수행한다.

설치 후 setup wizard 실행

기본 동작

기본적으로 설치가 끝나면 대화형 설정 마법사를 실행한다.

python -m hermes_cli.main setup

가상환경 사용 시 정확히는 다음처럼 실행된다.

~/.hermes/hermes-agent/venv/bin/python -m hermes_cli.main setup

skip-setup 사용 시

--skip-setup 옵션을 주면 이 단계는 생략된다.

--skip-setup

터미널이 없는 Docker build나 CI 같은 환경에서는 자동으로 생략하고 나중에 실행하라고 안내한다.

hermes setup

메시징 게이트웨이 처리

토큰 감지

설치 후 .env 파일에서 메시징 플랫폼 토큰이 설정되어 있는지 확인한다.

확인하는 변수는 다음과 같다.

TELEGRAM_BOT_TOKEN
DISCORD_BOT_TOKEN
SLACK_BOT_TOKEN
SLACK_APP_TOKEN
WHATSAPP_ENABLED

이 값들이 설정되어 있으면 게이트웨이 실행 또는 서비스 등록을 제안한다.

WhatsApp pairing

WHATSAPP_ENABLED=true인데 세션 파일이 없으면 QR 페어링을 위해 다음 명령 실행을 제안한다.

hermes whatsapp

세션 파일 위치는 다음과 같다.

~/.hermes/whatsapp/session/creds.json

systemd 서비스 설치

Linux에서 systemctl이 있으면 다음 명령을 실행하려고 한다.

hermes gateway install
hermes gateway start

systemd가 없거나 Termux인 경우에는 백그라운드 프로세스로 실행한다.

nohup hermes gateway > ~/.hermes/logs/gateway.log 2>&1 &

설치 완료 후 안내되는 명령어

주요 명령어

설치 완료 후 다음 명령어들이 안내된다.

hermes
hermes setup
hermes config
hermes config edit
hermes gateway install
hermes update

각 의미는 다음과 같다.

명령어	의미
`hermes`	Hermes 채팅 시작
`hermes setup`	API 키 및 설정 구성
`hermes config`	설정 확인/관리
`hermes config edit`	설정 파일 편집
`hermes gateway install`	메시징/cron용 게이트웨이 서비스 설치
`hermes update`	최신 버전으로 업데이트

[인공지능/Hermes] 헤르메스란 ( feat. 오픈클로와의 차이 )

초보 & 뉴비 — Wed, 15 Apr 2026 20:18:01 +0900

OpenClaw vs Hermes Agent 비교

AI 에이전트가 주목받으면서 OpenClaw와 Hermes Agent도 자주 함께 언급된다.
두 프로젝트 모두 “실제로 일을 수행하는 에이전트”를 지향하지만, 설계 방향은 분명히 다르다.

간단히 말하면:

OpenClaw는 채널에 연결해 바로 활용하는 개인 비서형 에이전트
Hermes Agent는 서버에 상주시켜 기억·자동화·학습을 수행하는 운영형 자율 에이전트

즉 둘 다 비슷한 범주에 속하지만, 실제로는 사용 목적과 운영 방식이 꽤 다르다.

한눈에 보는 차이

항목	OpenClaw	Hermes Agent
핵심 성격	개인 AI 비서	운영형 자율 에이전트
중심 UX	메신저/채널 기반	서버/런타임 기반
강점	빠른 실사용, 채널 연동	장기 기억, 자동화, 분업
기억	문맥 유지 중심	장기 기억과 재사용 중심
확장 방식	Tools / Skills / Plugins	Skills / Subagents / Runtime
적합한 환경	개인용, 즉시 활용	VPS, 서버, 장기 운영

1. OpenClaw: 바로 써먹는 AI 비서

OpenClaw는 “지금 바로 쓸 수 있는 assistant”에 가깝다.
슬랙, 텔레그램, 디스코드 같은 채널에 연결해 사용자가 요청하면 도구를 호출하고 실제 작업을 수행하는 구조다.

예를 들어 다음과 같은 성격에 잘 맞는다.

메신저에서 바로 AI를 호출하고 싶은 경우
이메일, 일정, 간단한 업무 자동화가 필요한 경우
복잡한 운영보다 빠른 도입과 사용성이 중요한 경우

핵심은 채널 친화성과 즉시 활용성이다.
즉 OpenClaw는 “운영 플랫폼”이라기보다 실사용 중심의 AI 비서라는 표현이 더 잘 어울린다.

2. Hermes Agent: 운영하며 키우는 에이전트

Hermes Agent는 단순 assistant보다 장기 운영형 agent runtime에 가깝다.
서버에 상주시켜 기억을 유지하고, 반복 작업을 자동화하고, 필요하면 여러 작업을 분업시키는 구조를 지향한다.

특히 다음과 같은 환경에서 강점이 있다.

VPS나 서버에서 24/7 실행해야 하는 경우
반복 업무를 자동화하고 싶은 경우
장기 기억과 학습 효과가 중요한 경우
하나의 assistant보다 에이전트 시스템을 운영하고 싶은 경우

즉 Hermes의 핵심은 지속성과 자기개선 가능성이다.
단순히 “한 번 잘 답하는 AI”가 아니라, 계속 돌리면서 더 잘하게 만드는 에이전트에 가깝다.

3. 가장 큰 차이: 기억과 학습

두 프로젝트의 가장 큰 차이는 기억을 다루는 방식이다.

OpenClaw

OpenClaw도 문맥 유지와 메모리 개념이 있지만, 그것은 어디까지나 작업 수행을 돕는 요소에 가깝다.
핵심은 여전히 도구 사용, 스킬 실행, 실제 액션 수행이다.

Hermes Agent

Hermes Agent는 기억이 단순 보조 기능이 아니라 정체성 자체에 가까운 요소다.
과거 경험을 쌓고, 반복 작업을 재사용하고, 장기적으로 더 나은 방식으로 일하도록 설계되어 있다.

정리하면 다음과 같다.

OpenClaw: 기억하는 assistant
Hermes Agent: 기억하고 학습하는 agent

4. 어떤 경우에 무엇을 선택해야 할까

OpenClaw가 더 적합한 경우

다음과 같은 상황이라면 OpenClaw가 더 잘 맞는다.

메신저에서 바로 쓸 AI 비서가 필요하다
빠르게 붙여서 실사용하고 싶다
일정, 메시지, 간단한 액션 자동화가 중요하다
채널 연동이 핵심이다

Hermes Agent가 더 적합한 경우

다음과 같은 상황이라면 Hermes Agent가 더 잘 맞는다.

서버에서 상주시켜 운영하고 싶다
반복 작업을 자동화하고 싶다
장기 기억과 자기개선이 중요하다
병렬 작업이나 분업 구조가 필요하다

결론

OpenClaw와 Hermes Agent는 모두 강력한 오픈소스 AI 에이전트이지만, 지향점은 다르다.

OpenClaw는 잘 연결된 AI 비서
Hermes Agent는 기억하고 성장하는 AI 작업 런타임

따라서 선택 기준은 단순하다.

즉시 활용성과 채널 기반 사용성이 중요하다면 OpenClaw
장기 운영, 자동화, 학습형 구조가 중요하다면 Hermes Agent

결국 두 프로젝트의 차이는 기능의 많고 적음보다,
AI를 “비서”로 볼 것인지, “운영하는 시스템”으로 볼 것인지에 더 가깝다.

샤오미 공기청정기(미에어 mb3) 3H 스마트싱스 연동 (엣지드라이버)

초보 & 뉴비 — Wed, 1 Apr 2026 16:08:52 +0900

스마트싱스 채널 초대 링크

https://bestow-regional.api.smartthings.com/invite/adMK96OEA1l9

SmartThings. Add a little smartness to your things.

account.smartthings.com

지원 기기

zhimi.airpurifier.mb3 ( 3H 모델 )

연동 정보

IP 및 Token

- Vevs 개조판 미홈에서 획득 가능

지원 기능

- 전원 on/off
- 공기질 ( 좋음, 보통, 약간 나쁨, 나쁨, 위험 )
- PM 2.5 미세먼지
- 온/습도
- *팬 모드 ( 자동, 야간, 선호, 약/중/강 == Level 1/2/3 )
- 설정 메뉴에서 기기 추가 토글

* 팬모드 관련

- 미홈 앱에서는 팬 모드가 자동/야간/선호 3개 있고, 블록 위치 모드로 가야 팬 속도(Level 1, 2, 3) 설정이 됩니다.
- 다만 저걸 스싱에서도 굳이 나누자니 UX만 늘어나는 느낌이 있어 팬모드로 합쳐놨습니다.
- 약 = Level 1, 중 = Level 2, 강 = Level 3 입니다.

[인공지능/OpenClaw] 클로드 사용량 보여주기

초보 & 뉴비 — Mon, 23 Feb 2026 19:34:21 +0900

디스코드랑 연결 된 오픈클로에서 클로드(모델)의 사용량 (5시간 세션, 주간 리밋)을 보여주고 싶었다.

메인 프로바이더를 OpenAI로 쓰고 있기는 한데 복잡한 코딩을 할 때에는 클로드(앤트로픽)을 사용하라고 설정한 상태이다.

단 오픈클로 사용량이 95% 이상이 되면 백업으로 OpenAI로 코딩을 하라고 설정하고 싶었고, 전제 조건으로 어떻게든 클로드 사용량을 가져와야만 했다.

처음 시도한 방법은, 오픈클로가 설치 된 우분투에 xrdp를 연결하여 크롬 브라우저를 실행해서 사용량 페이지(https://claude.ai/settings/usage)를 띄어놓고 캡쳐해서 OCR을 통해 사용량을 보여주게 했는데 크게 2가지 문제가 있었다.

1. 해상도나 xrdp 상태에 따라서 캡쳐가 안되거나 OCR이 제대로 안 돈다.

2. 이미지 OCR 해석하는 API 초과 ( 딱히 어디라고 지정 안 했는데 오픈클로가 어딘가랑 연동하고 알아서 해석하고 있었다 )

위와 같은 이유로 다른 방법을 찾던 중 GUI가 아닌 TUI를 이용하면 될까 싶어서 진행했는데 너무 잘 되서 방법을 작성한다.

준비사항

1. (오픈클로 설치 환경에서) 클로드 CLI 설치

2. (오픈클로 설치 환경에서) tmux 설치 및 세션 실행

3. 이전 단계에서 생성 tmux 세션에서 claude 실행

준비사항을 끝마쳤으면 위 사진처럼 클로드 대화창이 나타나 있어야 한다.

그럼 이제 오픈클로한테 적당한 프롬프트를 주면 되는데 몇 가지 조건을 붙였다.

1. 현재 & 주간 전부 보여줄 것

2. 세션 초기화 시간이랑 그때까지 얼마나 남았는지 보여줄 것 ( 0 단위 제외 )

3. 현재 또는 주간 세션 중 하나라도 85% 이상이면 디스코드에서 나를 태그에서 알람 전송

시간을 들여 몇번씩 수정하면서 테스트를 했고 만족스럽게 실행이 되서, 오픈클로한테 설정 방법을 프롬프트로 만들어 달라고 했더니 아래처럼 나왔다.

## OpenClaw용 Claude 사용량 수집 프롬프트

Claude 사용량을 **이미지 OCR 없이 tmux 텍스트만**으로 수집하세요.

### 1) 대상
- tmux pane: `openclaw_claude_usage:1.1`

### 2) 실행 순서
1. pane에 `/usage` 입력 후 Enter
2. **10초 대기**
3. 아래 명령으로 텍스트 캡처
- `tmux capture-pane -p -J -t openclaw_claude_usage:1.1 -S -160`
4. 캡처 텍스트에서 아래 항목 파싱
- `Current session`의 `% used` + `Resets ...`
- `Current week (all models)`의 `% used` + `Resets ...`
5. 수집 후 **Esc 1회** 눌러 usage 패널 닫기
6. 값이 안 나오면 **최대 3회 재시도**

### 3) 시간 처리 규칙 (Asia/Seoul)
- `Resets Feb 24, 2am`처럼 날짜+시간이면 그대로 사용
- `Resets 2am`처럼 **시간만 있으면**:
- 아직 안 지난 시각이면 **오늘**
- 이미 지난 시각이면 **내일**
- 남은 시간 표기:
- 앞쪽 0 단위는 생략
- 중간 0 단위는 유지
- 예: `47분`, `2일 0시간 47분`

### 4) 출력 형식 (한국어)
- `Claude 현재 세션: <percent>% 사용 / <리셋시각> 재설정 / <남은시간> 남음`
- `Claude 주간 한도: <percent>% 사용 / <리셋시각> 재설정 / <남은시간> 남음`
- `판정: <주의|정상>`

### 5) 판정 기준
- 현재 세션 또는 주간 한도 중 하나라도 **85% 이상**이면 `주의`
- 그 외는 `정상`

프롬프트 잘 넘겨주면 디코로 알람이 잘 온다.

[인공지능/OpenClaw] 오픈클로 구글(지메일, 캘린더 등) 연동하기 (feat. Gog 스킬)

초보 & 뉴비 — Sun, 15 Feb 2026 03:21:59 +0900

업데이트
- 2026.03.08
> 해외 포럼에서 구글 계정 차단(사유: 구글 약관을 우회하기 위한 다중 계정 사용 혹은 봇에서 생성 된 계정) 소식이 들려오고 있습니다.
> 가급적 부계정을 이용하는걸 권장합니다. ( 계정 차단에 대한 책임은 사용자 본인에게 있습니다 )

ClawHub에서 제일 유명한 스킬 중 하나가 구글 계정을 연동하는 "Gog" 스킬이다.

https://clawhub.ai/steipete/gog

Gog — ClawHub

Google Workspace CLI for Gmail, Calendar, Drive, Contacts, Sheets, and Docs.

clawhub.ai

개인적으로는 이메일이랑 일정 관리 해주면 편하다 싶어서 연동을 하기로 결정했다.

OAuth 클라이언트 만들기

원하는 구글 서비스 API 활성화

https://console.cloud.google.com/

https://accounts.google.com/v3/signin/identifier?continue=https%3A%2F%2Fconsole.cloud.google.com%2F&dsh=S1898337448%3A1771089762574420&followup=https%3A%2F%2Fconsole.cloud.google.com%2F&ifkv=ASfE1-ohpi6L-KPjXgdjdJsLQp5MZZhWjlEa5kFS1OLq4t2I91Fx33kfRBNfOir8hXSXTO0XyyFneA&osid=1&passive=1209600&service=cloudconsole&flowName=WebLiteSignIn&flowEntry=ServiceLogin

accounts.google.com

구글 클라우드 콘솔로 이동

좌측 상단의 "프로젝트 선택" 후 나타나는 창에서 "새 프로젝트" 클릭한다.

적절한 프로젝트 이름을 넣고 만들기를 누른다.

별다른 문제가 없으면 10초 이내로 성공 메시지가 나타난다.

그러면 좌측에서 "API 및 서비스" - "라이브러리"를 눌러서 내가 원하는 서비스(메일, 캘린더 등)에 대해서 활성화를 해야한다.

gmail 검색 후 선택하면 세부정보 화면이 나타나는데 저기서 "사용"을 눌러주면 된다.

- 이런 식으로 다른 서비스 (캘린더, 드라이브 등등)도 설정해주면 된다.

OAuth 인증 구성

"API 및 서비스"의 "OAuth 동의 화면"으로 들어간다.

시작하기를 눌러 기본 정보를 구성해야 한다.

총 4가지 단계를 거치면 인증 구성은 완료 된다.

사용자 인증 정보 생성

클라이언트까지 생성하면 마지막에 위와 같은 화면이 나타나는데 "JSON" 다운로드를 하면 "client_secret_xxxxx.json" 파일이 다운로드 되며, 해당 파일을 오픈클로가 설치 된 환경으로 복사까지 해야 한다.

테스트 사용자 추가

테스트 사용자에 오픈클로랑 연동하고자 하는 메일이 있어야 하는데 없으면 "Add Users"를 눌러 추가하면 된다.

오픈클로 설정하기

brew tap steipete/tap
brew install steipete/tap/gogcli
gog --version

오픈클로가 설치 된 환경에 "gog" 명령어가 있어야 하는데 없으면 위 명령어를 설치하면 된다.

gog auth add xxxx@gmail.com --services gmail,calendar,drive

오픈클로 설치 된 환경에서 위 명령어를 실행하면 URL 하나 주는데 연동하고자 하는 구글 계정이 로그인 된 브라우저에서 열어야 한다.

"계속" 클릭

위 화면까지 나타나면 연동은 성공된거고 재빠르게 터미널을 다시 가야 한다.

그러면 비밀번호를 요구하는데 추후에 다시 사용할 수 있으니 기억할만한 비밀번호를 입력하면 된다.

연동 후 디스코드에서 저렇게 부탁을 해보자.

그러면 실제로 구글 캘린더에 등록 된다.

[인공지능/OpenClaw] 오픈클로 디스코드 연동하기

초보 & 뉴비 — Sun, 15 Feb 2026 00:02:00 +0900

ChatGPT와의 연동이 끝났으니 이제는 "채널"을 연동하고자 한다.

오픈클로에서 "채널(이하 메신저)"은 오픈클로와 대화할 수 있는 메신저를 의미하는데, 각 메신저는 게이트웨이를 통해 연결된다.

지원하는 메신저 목록은 여기서 확인할 수 있는데 아쉽게도 카카오톡은 없다.

그나마 한국에서 좀 쓸만한 것들 중에는 아래와 같은 사유로 디스코드로 선택했다.

- 왓츠앱 ( 본인이 사용하지 않음 )

- 텔레그램 ( 텔레그램의 경우 한 채널에 여러 봇을 못 붙인다는 얘기가 좀 있음 )

- 디스코드

- 슬랙 ( 개인용보단 업무용 아닐까 )

- 라인 ( 본인이 사용하지 않음 )

디스코드 서버 만들기

윈도우 기준 디스코드 설치하고 아래와 같은 단계로 우선 서버를 만들어야 한다

디스코드 좌측 상단에 위치한 "+" 버튼을 눌러 서버를 추가한다.

직접 만들기 클릭

질문을 건너뛰기

서버 이름을 적당히 넣어주고 만들기를 누르면

나만의 서버가 만들어진다.

디스코드 봇 만들기

서버를 만들었으니 이제 봇을 만들어야 한다. 봇은 오픈클로의 복사본 느낌으로 생각하면 된다. 우리가 디스코드에 어떤 채팅을 입력하면 그걸 복사본인 봇이 받아서 오픈클로에 넘기는 구조이다.

우선 디스코드 개발자 포탈로 이동한다.

"New Application" 클릭 후 앱의 이름을 입력한다.

그러면 앱의 페이지로 이동되는데 "Installation" 메뉴에 들어가서 "Install Link"을 "None"으로 바꾼다.

"OAuth2" 메뉴에서 Scopes와 Bot Permissions를 위와 같이 체크한다.

- Scopes의 경우 "bot"은 필수이며 "application.commands"는 슬래시 기반 명령어를 사용할 거면 추가 아니면 안 해도 된다.

- "Bot Permissions"의 경우 "View Channels", "Send Messages", "Read Message History"는 필수이며 나머지 것들은 원하는만큼 추가하면 된다. ( 나는 파일 첨부와 쓰레드 기능을 위해 위 사진과 같이 선택했다. )

그러면 URL 값이 나오는데 반드시 메모해두자.

"Bot" 메뉴에서 "Reset Token"을 눌러 토큰을 재발급 후 나오는 값을 반드시 메모한다.

(권장) 공용 봇 옵션은 기본으로 켜져 있는데 굳이 공용으로 할 필요가 없으니 나만 추가할 수 있게 끈다.

(옵션) Server Members Intent

- 디스코드 서버의 멤버 목록이나 멤버 상태 변화(서버 참가, 퇴장, 역할 변경 등) 관련 이벤트를 받아올 수 있게 해준다.

- 특정 역할을 가진 사람만 봇을 쓰게 한다거나, 역할에 따라 다른 규칙을 처리하게 한다거나 할 수 있게 해준다.

- 서버를 공용으로 쓸 꺼면 활성화 해주고, 개인용도로 쓸꺼면 꺼주면 된다.

(필수) Message Content Intent

- 서버의 메시지를 처리할 수 있게 해준다.

- 안 키면 멍청한 깡통 봇이 되버린다. 오픈클로와 대화를 하지 못하니 반드시 켜야 한다.

자 그러면 이제 "OAuth2" 메뉴 마지막에 나온 링크를 브라우저에 복사하면 위 사진처럼 나오는데 본인이 생성한 서버에 추가한다.

그러면 권한을 다시 한번 확인해서 승인하는 창이 뜨고, 승인까지 하면 성공 창이 뜬다.

봇이 성공적으로 추가 되면 디스코드 서버에 "착륙" 메시지가 나타난다.

다만 아직 오픈클로에서 그 어떠한 설정도 하지 않았기에 말을 걸어도 딱히 반응을 하지 않는다.

오픈클로 설정하기

이전에 메모한 토큰 값을 사용할 차례이다.

openclaw config

이전 포스팅에서 OpenAI 연동하듯이 config 명령어를 이용해서 채널(메신저) 설정을 진행한다.

채널까지 선택하면 현재 상황이 나오는데 "install plugin to enable"로 된것들은 플러그인 설치 후 연동이 가능하며, 나머지는 바로 연동이 가능한 것들이다.

디스코드를 선택하면 봇 토큰을 입력하라고 하는데 기존에 메모한 값을 입력하면 된다.

그리고 나서 디스코드 채널 액세스를 오픈으로 설정하면 된다.

- 기본값이면서도 권장값은 허용할 특정 서버를 고르는건데 어차피 디스코드쪽에서 봇을 직접 추가했기에 오픈으로 설정하여도 무방하다.

디스코드 채팅하기 ( @ 태그 필수 )

기본적으로 봇과 채팅할 때는 여타 다른 SNS 마냥 "@" 태그를 해줘야한다.

디스코드 채팅하기 ( @ 태그 없이 )

위 사진처럼 봇과 대화를 하려면 꼭 태그를 해야 하는데 이게 여간 불편한게 아니다. 공용 서버면 어쩔 수 없겠지만 개인 서버라면 어차피 1:1 대화이기 때문에 태그 없이 바로 입력하는게 편한데 설정 파일을 약간 수정해야 한다.

설정 파일이 보통 "~/.openclaw/openclaw.json"에 있을텐데 아래처럼 디스코드 부분을 수정하면 된다.

{
  "channels": {
    "discord": {
      "enabled": true,
      "token": "xxxxxxxxxxxxxxxxxxxxxxxx",
      "groupPolicy": "open",
      "guilds": {
        "*": {
          "requireMention": false,
          "channels": {
            "*": { "allow": true, "requireMention": false }
          }
        }
      }
    }
  }
}