Hermes Agent 실사용기
Hermes Agent를 설치할 때 내가 기대한 건 꽤 분명했다. “AI 비서”였다. 단순히 질문에 답하는 챗봇이 아니라, 내가 하려는 일을 옆에서 같이 처리해주는 도구. OpenClaw보다 더 넓고 실용적인 상위호환처럼 보였고, 실제로 그런지 확인해보고 싶었다.
며칠 써보니 기대와 맞는 부분도 있었고, 생각보다 조심해야 할 부분도 있었다. 한마디로 말하면 Hermes는 “알아서 다 해주는 비서”라기보다 “도구를 쥐여주면 빠르게 움직이는 작업 파트너”에 가깝다. 이 차이를 이해하면 훨씬 편하게 쓸 수 있다.
이 글은 설치 이후 실제로 Hermes를 써보며 느낀 점을 정리한 사용기다. 설치와 기본 설정은 별도 글로 분리했다.
처음 기대했던 것
내가 Hermes를 처음 본 이유는 AI 비서에 대한 기대 때문이었다. 개발할 때 옆에서 파일을 찾아주고, 명령을 실행해주고, 문서를 정리해주고, 필요하면 서버 작업도 도와주는 그런 비서 말이다.
기존의 AI 도구는 대개 한쪽으로 치우쳐 있었다. 채팅형 도구는 설명을 잘하지만 내 환경에서 직접 움직이지 못했다. 코딩 에이전트는 코드 작업에는 강하지만, 개인 작업과 자동화까지 넓게 붙이기에는 답답한 부분이 있었다. OpenClaw도 흥미로웠지만, Hermes는 그보다 더 많은 표면을 가진 도구처럼 보였다.
CLI, desktop, dashboard, gateway, memory, skills, cron, webhook. 이 조합을 보고 “이건 개발 도구라기보다 개인 운영 레이어에 가깝겠는데?”라는 생각이 들었다.
실제로 써보니 가장 큰 차이는 실행이었다
Hermes를 쓰면서 가장 먼저 체감한 건 실행력이다.
예를 들어 블로그 글을 쓴다고 하자. 보통 AI에게 글을 부탁하면 초안을 준다. 그 다음에는 내가 파일을 만들고, frontmatter를 맞추고, 빌드를 돌리고, 미리보기를 띄운다.
Hermes에서는 그 흐름이 한 대화 안에서 이어진다. 프로젝트 구조를 확인하고, 기존 글 형식을 읽고, 새 MDX 파일을 만들고, lint와 build를 돌리고, dev server를 띄워서 직접 확인할 URL까지 만들어준다. 중간에 404가 나면 왜 그런지 코드를 읽고, preview에 필요한 변경을 넣고, 다시 검증한다.
이건 단순히 답변 품질이 좋은 것과 다르다. “내가 하려던 귀찮은 확인 작업”을 실제로 대신한다는 점에서 다르다.
글쓰기에도 꽤 잘 맞았다
이번 블로그 글도 Hermes와 같이 썼다. 내가 방향을 말하면 Hermes가 초안을 만들고, 내가 다시 읽으면서 “이 부분은 말하지 말자”, “내가 처음 기대한 맥락은 이거다”, “게시물은 둘로 나누자”처럼 피드백을 줬다. 그러면 Hermes가 파일을 다시 나누고 문장을 고쳤다.
여기서 좋았던 점은 글쓰기와 개발 작업이 끊기지 않는다는 것이다. 보통은 글을 쓰는 도구와 프로젝트에 반영하는 도구가 따로 있다. Hermes는 같은 대화 안에서 글을 고치고, MDX 파일을 만들고, 빌드까지 확인한다.
다만 바로 공개하면 안 된다. 특히 개인 경험 글에는 내부 경로, 서버 주소, 도구 설정, webhook URL 같은 정보가 자연스럽게 섞일 수 있다. 초안에는 이런 내용이 들어가기 쉽다. 그래서 게시 전에는 반드시 한 번 같이 읽고 빼야 할 정보를 걷어내는 시간이 필요하다.
앞으로 내 블로그 글은 이렇게 하려고 한다.
- 초안 작성
- 내부 정보와 공개 범위 점검
- 문장 다듬기
- 브라우저에서 직접 읽기
- 같이 최종 수정
- 그 다음에 게시 여부 결정
이 순서를 정해두면 글이 훨씬 안전해진다.
memory는 “매번 설명하지 않기”에 좋다
Hermes를 며칠 쓰면 memory의 가치가 보인다. 처음에는 “굳이 기억까지 필요할까?” 싶었는데, 같은 프로젝트를 계속 다루면 차이가 크다.
예를 들어 내가 어떤 형식의 보고서를 좋아하는지, 어떤 기술 스택을 쓰는지, 어떤 작업에서는 어떤 방식의 검증을 선호하는지 같은 정보가 쌓인다. 그러면 다음 대화에서 출발점이 달라진다. 매번 “이 프로젝트는 이런 구조고, 이 명령으로 빌드하고, 글은 이런 형식으로 써줘”라고 말하지 않아도 된다.
하지만 memory에는 아무거나 넣으면 안 된다. 오래 갈 사실만 넣는 게 좋다. 일시적인 작업 상태, PR 번호, 임시 branch 이름, 내부 URL, 한 번 쓰고 버릴 경로 같은 정보는 나중에 오히려 방해가 된다. 그런 건 대화 기록이나 작업 로그에 남기는 편이 낫다.
내가 느낀 기준은 간단하다. 일주일 뒤에도 맞을 정보면 memory 후보이고, 일주일 뒤에 틀릴 수 있으면 저장하지 않는 편이 좋다.
skills는 반복 절차를 저장한다
memory가 사실을 저장한다면, skills는 절차를 저장한다. 이 구분이 마음에 들었다.
예를 들어 “블로그 글을 쓸 때는 초안을 만든 뒤 바로 게시하지 않고, 한국어 윤문을 거치고, 사용자와 같이 최종 검토한 뒤 공개한다”는 단순한 사실이 아니라 절차다. 이런 건 skill이나 작업 규칙으로 남겨두는 편이 좋다.
Hermes의 skill은 특정 작업을 할 때 참고하는 작은 매뉴얼처럼 동작한다. Hermes 관련 설정을 볼 때는 Hermes용 skill을 읽고, 블로그 게시 작업을 할 때는 Next.js와 MDX 게시 흐름을 담은 skill을 읽는 식이다.
이 기능은 에이전트가 점점 내 작업 방식에 맞춰지는 느낌을 준다. 한 번 성공한 절차를 다음에도 다시 쓰게 만들 수 있기 때문이다.
dashboard와 gateway는 성격을 바꾼다
CLI만 쓸 때 Hermes는 터미널 안의 에이전트다. dashboard와 gateway를 붙이면 느낌이 달라진다.
dashboard는 설정과 상태를 브라우저에서 보기 좋다. CLI에서만 쓰면 놓치기 쉬운 부분을 한눈에 볼 수 있다.
gateway는 더 크게 바꾼다. Discord 같은 메시징 플랫폼에서 Hermes를 부를 수 있기 때문이다. 휴대폰으로 메시지를 보내고, Hermes가 작업을 확인한 뒤 결과를 알려주는 흐름이 가능해진다. 이때부터는 정말 “개인 비서” 같은 느낌이 조금 난다.
물론 gateway는 권한을 조심해야 한다. 메시징 플랫폼에 붙는 순간 접근 경로가 늘어난다. 어떤 채널에서 어떤 명령을 허용할지, 알림은 어디로 보낼지, 민감한 작업은 어떻게 승인할지 정해두는 편이 좋다.
cron과 webhook은 자동화의 시작점이다
Hermes는 반복 작업에도 붙일 수 있다. cron을 쓰면 정해진 시간에 prompt를 실행할 수 있고, webhook을 쓰면 외부 이벤트로 Hermes를 깨울 수 있다.
내가 관심을 둔 방향은 두 가지였다.
하나는 주기적인 리포트다. 매일 같은 시간에 데이터를 모으고, 조건에 맞을 때만 요약해주는 식이다. 단순 알림보다 한 단계 더 나아가 “보고서 초안”을 만들어주는 쪽에 가깝다.
다른 하나는 모니터링이다. 특정 공고나 이벤트가 새로 올라왔는지 확인하고, 필요할 때만 알려주는 흐름이다. 사람이 매번 새로고침하는 일을 Hermes에게 넘기는 셈이다.
이 기능은 편하지만 prompt를 잘 써야 한다. cron은 미래에 혼자 실행된다. 지금 대화 맥락을 기억한다고 가정하면 안 된다. 어떤 데이터를 볼지, 무엇을 새 소식으로 판단할지, 결과를 어디로 보낼지 prompt 안에 분명히 적어야 한다.
브라우저 자동화는 기대와 현실 사이에 있다
Hermes의 browser 기능도 써봤다. 로그인이나 예약 사이트처럼 UI가 필요한 작업에서는 꽤 유용하다. 단순 HTTP 요청으로는 안 되는 일을 브라우저로 확인할 수 있기 때문이다.
다만 웹 자동화는 변수가 많다. 로그인 상태, Cloudflare 같은 보호 장치, 브라우저 세션, 네트워크 경로, 사용 중인 기기까지 영향을 준다. 그래서 “Hermes가 알아서 다 뚫어준다”는 식으로 기대하면 안 된다.
내가 정한 기준은 이렇다. 정보 확인과 반복 클릭은 Hermes가 도울 수 있다. 하지만 로그인, 결제, 예약 확정, 비밀번호 입력, 권한 승인 같은 단계는 사람이 직접 확인해야 한다. AI 비서에게 맡길 일과 사람이 직접 해야 할 일을 나눠야 한다.
Kanban과 profile은 아직 더 써볼 영역
Hermes에는 profile과 Kanban도 있다. profile은 역할별로 환경을 나누는 기능에 가깝고, Kanban은 여러 작업을 durable board로 관리하는 기능이다.
처음부터 여러 profile을 만들 필요는 없다고 느꼈다. 혼자 쓰는 단계에서는 기본 profile 하나로도 충분하다. 다만 작업이 커지고 역할을 나누고 싶어지면 profile을 나누는 편이 좋아 보인다.
예를 들어 개발, 리뷰, 리서치, 운영을 서로 다른 profile로 나눌 수 있다. 각 profile에 필요한 tools와 skills를 다르게 설정하면 더 안정적인 multi-agent workflow를 만들 수 있다.
아직 이 부분은 내가 완전히 써봤다고 말하기 어렵다. 다만 Hermes가 단순 CLI 도구에서 끝나지 않고, 여러 에이전트가 함께 일하는 구조까지 염두에 두고 있다는 점은 흥미롭다.
좋았던 점
첫째, 내 환경 위에서 움직인다. 그냥 일반론을 말하는 것이 아니라 프로젝트 파일을 읽고, 실제 명령을 실행하고, 결과를 바탕으로 다음 행동을 한다.
둘째, 글쓰기와 개발 작업을 이어서 처리한다. 블로그 글을 고치고, MDX로 저장하고, 빌드하고, dev server에서 미리보는 흐름이 한 대화 안에서 이어진다.
셋째, memory와 skills 덕분에 같은 설명을 덜 하게 된다. 이건 며칠 이상 써봐야 체감된다.
넷째, CLI 밖으로 확장된다. dashboard, gateway, cron, webhook이 붙으면서 개인 자동화 도구에 가까워진다.
아쉬웠던 점
첫째, 권한이 강한 만큼 조심해야 한다. 파일 수정, 명령 실행, 브라우저 조작이 모두 가능하니 실수의 영향도 커진다.
둘째, 설정 면이 넓다. provider, toolset, memory, gateway, cron, profile까지 한 번에 이해하려 하면 복잡하다. 처음에는 CLI와 기본 toolset만 쓰고, 필요할 때 하나씩 붙이는 게 좋다.
셋째, 초안에는 내부 정보가 쉽게 섞인다. 에이전트가 실제 환경을 읽고 작업하기 때문에 경로, 주소, 설정 이름 같은 것이 글에 들어갈 수 있다. 게시 전 검토가 꼭 필요하다.
넷째, 자동화는 prompt 품질에 영향을 많이 받는다. 특히 cron이나 webhook은 나중에 혼자 실행되기 때문에, 대충 써두면 나중에 애매한 결과가 나온다.
OpenClaw 상위호환처럼 느껴졌나
처음 기대했던 질문으로 돌아가보면, 내 기준에서는 어느 정도 그렇다.
단순히 “코딩 에이전트”만 놓고 비교하면 사람마다 판단이 다를 수 있다. 하지만 내가 원한 건 코딩만이 아니었다. AI 비서처럼 내 작업 환경에 붙고, 기억하고, 반복 작업을 자동화하고, 메시징 플랫폼에서도 부를 수 있는 도구였다.
그 관점에서 Hermes는 확실히 더 넓다. CLI에서 시작하지만 거기서 끝나지 않는다. memory와 skills로 작업 방식을 쌓고, gateway로 대화 표면을 넓히고, cron과 webhook으로 자동화를 붙일 수 있다.
물론 넓다는 건 복잡하다는 뜻이기도 하다. 그래서 처음부터 모든 기능을 켜기보다, 내가 자주 하는 작업 하나에 붙여보는 게 좋다. 블로그 글 작성, 서버 상태 확인, 반복 리포트 생성 같은 작은 작업부터 시작하면 감이 빨리 온다.
지금 내 결론
Hermes Agent는 내가 기대했던 AI 비서에 꽤 가까웠다. 다만 “알아서 다 해주는 비서”라기보다는 “내가 방향을 정하면 실제 도구를 써서 빠르게 도와주는 비서”에 가깝다.
이 차이는 중요하다. Hermes에게 모든 판단을 맡기면 불안하다. 하지만 내가 목표와 범위를 정하고, Hermes가 확인과 실행을 맡는 구조로 쓰면 꽤 강력하다.
지금은 설치보다 사용 방식이 더 중요하다고 느낀다. 어떤 toolset을 켤지, 무엇을 memory에 남길지, 어떤 절차를 skill로 만들지, 어디까지 자동화할지. 이런 선택이 쌓이면서 Hermes는 점점 내 작업 방식에 맞춰진다.
그래서 당분간은 계속 써볼 생각이다. 블로그 작성, 서버 운영, 리포트 자동화, Discord 기반 작업 지시까지. 작은 것부터 붙여보면 Hermes가 어디까지 개인 비서가 될 수 있는지 더 잘 보일 것 같다.