Hermes Agent 명령어, 어디서부터 찾아야 할까

Hermes Agent를 쓰다 보면 명령어보다 먼저 막히는 지점이 있습니다. 설치 상태를 확인하려는 건지, 모델을 바꾸려는 건지, 다른 프로필로 실행하려는 건지에 따라 찾아야 할 명령이 달라집니다. 터미널에서 쓰는 CLI 명령과 세션 안에서 쓰는 /... 명령도 서로 다른 표면입니다.

이 글은 긴 명령 목록을 처음부터 외우는 대신, 지금 하려는 일에서 출발해 필요한 명령을 찾는 방법을 설명합니다. 명령 전체 목록은 Core, Operations, Slash 세 문서로 나눴습니다. 이 글에서 방향을 잡은 뒤 필요한 참고 문서로 넘어가면 됩니다.

이 글의 검증 기준

아래 내용은 2026-08-01 03:04 UTC에 확인한 설치본을 기준으로 합니다.

• 설치본: Hermes Agent v0.19.1 (2026.7.30) · upstream e08870f6
• 설치 방식: git, NousResearch/hermes-agent
• 확인 범위: 최상위 canonical CLI 명령 64개, root를 포함한 argparse 명령 노드 357개, 옵션 정의 1,030개
• 실제 help 검증: root와 모든 하위 canonical 경로 357개에 --help 실행, 357/357 exit 0과 usage 확인
• 상태: 확인 당시 공식 upstream보다 98 commits 뒤

이 숫자는 Hermes의 영구 사양이 아니라 당시 설치본의 스냅샷입니다. 버전이 바뀌면 명령과 옵션도 달라질 수 있습니다. 실제 실행 전에는 현재 설치본의 --help를 다시 확인하세요.

먼저 실행할 일곱 줄

처음이라면 아래 순서로 설치, 대화, 설정, 프로필, 세션과 진단 상태를 한 번씩 확인합니다.

hermes --version
hermes --help
hermes chat -q "현재 디렉터리의 README를 요약해줘"
hermes config get model.provider
hermes profile list
hermes sessions list --limit 10
hermes doctor

사진: Jacek Rużyczka, Wikimedia Commons 원본 페이지, CC BY-SA 3.0. Wikimedia의 1,280px 미리보기 사용(크기 조정).

각 명령이 확인하는 대상은 다릅니다.

• hermes --version: 현재 버전과 설치 경로, 업데이트 상태
• hermes --help: 이 설치본에서 실제로 노출되는 최상위 명령
• hermes chat -q "...": 질문 한 번을 실행하는 가장 직접적인 진입점
• hermes config get model.provider: 현재 model provider 설정
• hermes profile list: 사용할 수 있는 프로필
• hermes sessions list --limit 10: 최근 세션
• hermes doctor: 인증, 설정과 주변 실행 조건을 포함한 진단

여기서 오류가 나면 긴 명령 목록을 보기 전에 --version, --help, doctor의 출력부터 확인하는 편이 빠릅니다.

명령을 찾는 가장 짧은 흐름

1. 하려는 일을 한 문장으로 정합니다

예를 들어 "모델을 바꾼다", "최근 세션을 찾는다", "Gateway 상태를 본다"처럼 목적을 먼저 적습니다. 목적이 분명하면 첫 명령도 짧아집니다.

2. 명령 뒤에 --help를 붙입니다

최상위 help에서 명령을 고른 다음, 선택한 경로에 --help를 붙여 옵션과 하위 명령을 좁혀 갑니다.

hermes COMMAND --help
hermes COMMAND SUBCOMMAND --help

예를 들어 프로필과 Kanban 명령을 찾을 때는 다음처럼 확인합니다.

hermes profile --help
hermes kanban --help

블로그나 과거 문서의 예시가 현재 설치본과 다르면 현재 --help를 우선합니다. 없는 옵션을 비슷한 이름으로 추측해 실행하지 않습니다.

3. 세부 참고 문서로 이동합니다

명령 전체는 쓰임에 따라 세 갈래로 나눴습니다.

Core와 Operations 참고 문서에는 설치본 parser에서 확인한 canonical CLI와 별칭을 담았습니다. Slash 참고 문서는 설치본 중앙 registry의 built-in canonical 90개와 별칭을 다룹니다.

터미널 명령과 슬래시 명령은 어디가 다를까

터미널에서는 hermes ... 형태의 CLI 명령을 사용합니다.

hermes model
hermes profile list
hermes gateway status

Hermes 세션 안에서는 /... 형태의 명령을 사용합니다.

/help
/version
/profile
/status
/model

둘은 이름이 비슷해도 실행 위치와 권한, 바꾸는 상태가 다를 수 있습니다. 터미널에서는 hermes --help와 hermes <command> --help를 보고, 세션 안에서는 /help와 /commands를 확인합니다.

전역 옵션은 실행 방식부터 바꿉니다

다음 옵션은 최상위 진입점에 적용됩니다. --profile/-p는 실행 초기에 처리되므로 설치본 argparse usage에는 보이지 않지만 실제 실행과 공식 문서에서 확인했습니다.

--yolo, one-shot, hook 자동 승인은 단순 출력 형식만 바꾸는 옵션이 아닙니다. 승인 경계까지 바꿀 수 있으므로 사용 전에 아래 안전 주의사항을 확인하세요.

문서에 있는 명령이 보이지 않을 때

명령은 버전, 프로필, 플러그인과 provider에 따라 달라질 수 있습니다.

• 플러그인·provider가 등록한 최상위 명령은 설치·활성화된 경우에만 hermes --help에 나타납니다. 공식 문서의 hermes photon setup, provider별 memory 명령이 예입니다.
• 설치된 skill은 /<skill-name>, bundle은 /<bundle-name>, 사용자 quick command는 설정된 /name으로 동적으로 노출됩니다.
• 이 설치본 스냅샷의 최상위 help에는 photon, honcho가 노출되지 않았습니다.
• 확인 당시 Frink 프로필에서는 non-bundled plugin ponytail 4.8.4가 활성화되어 /ponytail* 명령 6개를 추가했습니다. 다른 프로필에서는 상태가 다를 수 있습니다.
• gui, learning, memory-graph 같은 별칭은 상세 참고 문서에서 canonical 명령과 함께 표시합니다.

현재 환경을 확인할 때는 다음 세 가지를 함께 봅니다.

hermes --version
hermes --help
hermes plugins list

세션 안에서는 /commands를 확인합니다.

공식 문서와 설치본이 다른 이유

확인 당시 공식 CLI 페이지의 최상위 overview는 61행이었습니다. login / logout을 한 행으로 합치고, 설치본 help에 노출된 sync, monitoring은 overview에 싣지 않았습니다. 설치본은 이를 각각 세어 canonical 최상위 명령 64개였습니다.

공식 global options 표보다 설치본 root help에 더 많은 옵션도 있었습니다. -z, --usage-file, 모델·provider·toolset·skill override와 --safe-mode 등이 해당합니다. Slash 명령은 공식 문서의 CLI/Gateway 표와 예시에서 반복되므로, canonical 수는 설치본 중앙 registry의 90개로 계산했습니다. 활성 Ponytail plugin 명령 6개는 조건부 명령으로 따로 구분했습니다.

이 차이는 어느 한쪽이 늘 틀렸다는 뜻이 아닙니다. 설치본이 공식 upstream보다 98 commits 뒤였고, 공식 문서와 코드도 계속 바뀝니다. 지금 이 컴퓨터에서 실행할 명령은 현재 설치본의 help로 확인하고, 의미와 최신 흐름은 공식 문서와 함께 대조합니다.

실행 전에 멈춰야 하는 명령

다음 명령과 옵션은 외부 시스템이나 되돌리기 어려운 상태에 영향을 줄 수 있습니다.

• --yolo와 -z/--oneshot은 승인 보호를 우회할 수 있습니다. 신뢰하지 않는 repo나 prompt에서 사용하지 않습니다.
• --accept-hooks는 보지 못한 shell hook을 자동 승인합니다. CI나 headless 환경에서 hook 출처를 검토한 경우에만 사용합니다.
• --ignore-rules, --ignore-user-config, --safe-mode는 정상 작업의 기본 실행 방식이 아니라 격리·진단용입니다.
• send, Gateway 서비스 제어, webhook, update, uninstall, import, delete/remove, Kanban dispatch는 실행 전에 대상과 롤백 방법을 확인합니다.
• 삭제·전송 명령을 바로 실행하기 전에 read-only list, show, status, --check, --dry-run이 제공되는지 help에서 찾습니다.
• token, API key와 OAuth credential 원문은 명령행, Wiki와 로그에 남기지 않습니다. hermes auth 또는 Hermes가 안내하는 credential 흐름을 사용합니다.
• 설정은 hermes config get/set/unset을 우선합니다. YAML을 직접 수정하면 indentation 오류가 생길 수 있습니다.
• 프로필 경로를 하드코딩하지 말고 hermes config path, hermes config env-path와 세션의 $HERMES_HOME을 확인합니다.

자주 막히는 네 가지 경우

문서에는 있는데 실행되지 않습니다

설치 버전이나 플러그인 상태가 다를 수 있습니다.

hermes --version
hermes --help
hermes plugins list

다른 프로필의 설정이 보입니다

현재 프로필과 실제 config 경로를 함께 확인합니다.

hermes profile list
hermes config path

세션 안에서는 /profile을 실행합니다.

옵션 위치가 맞지 않습니다

Global option과 subcommand option은 parser가 다릅니다. 실행하려는 전체 경로에 --help를 붙입니다.

hermes COMMAND SUBCOMMAND --help

변경이나 전송이 걱정됩니다

먼저 조회 명령을 찾습니다. list, show, status, --check, --dry-run이 있는지 확인한 뒤 실제 변경 명령으로 넘어갑니다.

마지막 확인

필요한 명령을 찾았다면 아래 다섯 가지를 확인하고 실행합니다.

1. 현재 hermes --version이 이 글의 스냅샷과 같은지 봅니다.
2. 실행할 전체 명령 경로에 --help를 붙입니다.
3. 현재 프로필과 config 경로가 맞는지 확인합니다.
4. 외부 전송, 삭제, 업데이트나 승인 우회가 포함됐는지 봅니다.
5. 실행 후에는 목적에 맞는 read-only 명령으로 결과를 확인합니다.

명령을 외우는 것보다, 현재 설치본에서 목적에 맞는 명령을 다시 찾고 실행 경계를 확인하는 습관이 더 오래 갑니다.

Sources

• https://hermes-agent.nousresearch.com/docs/reference/cli-commands
• https://hermes-agent.nousresearch.com/docs/reference/slash-commands
• https://hermes-agent.nousresearch.com/docs/reference/profile-commands
• https://hermes-agent.nousresearch.com/docs
• hermes_cli/main.py
• hermes_cli/commands.py