Heeyaa

기록

Hermes Agent 밋업 후기

2026. 5. 13.

Hermes Agent 밋업 후기: 에이전트를 진짜 일 시키려면 뭐가 필요할까

AI 에이전트를 실제 업무에 쓰려면 뭐가 필요할까?

결론부터 말하면, 좋은 모델 하나만으로는 부족하다.
상태 관리, 메모리, 도구 연결, 검증, 실패 기록, 그리고 사람이 개입하는 방식까지 모두 필요하다.

이번 밋업은 그걸 여러 발표와 데모로 보여준 자리였다.

Hermes는 코딩 도구를 넘어가고 있다

Hermes Agent는 단순한 코딩 도구라기보다, 장기 실행되는 작업 에이전트에 가까운 방향으로 가고 있었다.

가장 먼저 눈에 들어온 건 Kanban 구조였다.

여러 에이전트가 하나의 작업 보드를 공유하고, 작업은 triage, todo, ready, running, done, blocked 같은 상태를 가진다.
이건 단순한 할 일 목록이 아니다. 에이전트들이 협업하는 작업 큐이자 운영 대시보드에 가깝다.

또 중요한 개념은 long-running loop였다.

기존 챗봇은 한 번 답하고 끝난다.
하지만 실제 작업은 그렇지 않다. 중간에 실패하기도 하고, 추가 확인이 필요하기도 하고, 다 끝난 줄 알았는데 아닌 경우도 많다.

Hermes는 목표가 끝날 때까지 계속 돌고, 중간에 judge 모델이 “이 작업이 정말 끝났는지” 평가한다.
끝나지 않았다고 판단되면 continuation prompt로 다시 이어간다.

여기서 발표 전체를 관통하는 문장이 있었다.

에이전트의 척추는 상태 머신이다.

이 말이 꽤 오래 남았다.
오래 일하는 에이전트는 지금 무엇을 하고 있는지, 어디서 막혔는지, 무엇을 끝냈는지 알아야 한다. 그게 없으면 그냥 긴 채팅 로그일 뿐이다.

Hermes를 AI CTO처럼 쓰기

Salomon이라는 발표자는 Hermes를 AI CTO처럼 쓰는 구조를 소개했다.

흐름은 대략 이랬다.

  • Hermes를 VPS나 서버에 설치한다.
  • Telegram이나 Discord로 명령한다.
  • 여러 sub-agent를 만든다.
  • 각 agent가 기획, 코딩, 배포, 모니터링, 보안 체크를 나눠 맡는다.

데모에서는 GitHub, Vercel, Supabase 토큰을 연결해서 이벤트 등록 앱을 만들고 배포하는 흐름을 보여줬다.

여기서 중요한 건 로컬에서 Claude Code를 켜놓고 계속 지시하는 방식이 아니었다.
서버 위에 상주하는 에이전트 팀을 두고, 필요할 때 메시지로 일을 맡기는 방식이었다.

AI를 단순 도구가 아니라 작은 개발 조직처럼 다루는 느낌이었다.

K-Skill: Hermes의 한국화

개인적으로 가장 현실적으로 와닿았던 부분은 K-Skill이었다.

미국산 모델이나 에이전트는 한국 생활 맥락을 잘 모른다.
예를 들면 이런 것들이다.

  • HWP
  • 부동산 등기
  • 법원 경매
  • DART 공시
  • KBO 경기
  • 기상청 날씨
  • 네이버 블로그와 카카오맵
  • 주차장, 화장실, 지하철
  • 법령, 청약 공고

한국 사용자에게는 이런 것들이 정말 중요한데, 기본 모델은 잘 다루지 못한다.

발표에서는 KBO 일정과 기상청 날씨를 조합해서 기아 타이거즈 경기 우천 취소 가능성을 판단하는 예시가 나왔다.
강남 3구 경매 물건을 법원 경매, 실거래가, 뉴스, 법령과 함께 분석하는 흐름도 있었다.

HWP 법인 등기 서류를 자동 작성하는 데모도 있었다.

이 부분을 보면서 Hermes의 skill 시스템은 로컬 생활과 행정 데이터에 붙을 때 훨씬 실용적이 된다고 느꼈다.
한국에서 쓰는 AI 에이전트라면, 단순히 영어권 SaaS를 잘 다루는 것보다 이런 생활 밀착형 도구를 잘 다루는 게 더 중요할 수 있다.

접근성 좋은 웹은 에이전트에게도 좋은 웹이다

시각장애 접근성 발표도 인상적이었다.

기존 스크린 리더는 웹페이지를 순서대로 읽어주는 방식이다.
쇼핑몰이나 검색 결과처럼 복잡한 페이지에서는 사용자가 원하는 정보를 찾기까지 너무 오래 걸린다.

Hermes와 Playwright MCP 같은 브라우저 자동화를 붙이면, 에이전트가 대신 웹을 탐색하고 후보를 추려준다.
사용자는 긴 페이지를 전부 듣는 대신, 정리된 결과만 들으면 된다.

예시 요청은 이런 식이었다.

20대 남자에게 줄 10만 원대 선물 쿠팡에서 찾아줘.

이건 접근성 이야기이면서 동시에 웹의 미래에 대한 이야기처럼 들렸다.

앞으로 좋은 웹은 사람뿐 아니라 AI 에이전트도 잘 이해하고 조작할 수 있어야 한다.
agent-friendly web이 accessibility-friendly web과 가까워질 수 있다는 점이 흥미로웠다.

바로 실행하지 말고, 먼저 계획하라

Ouroboros라는 라이브러리 발표에서는 계획의 중요성을 다뤘다.

사용자가 “카트라이더 같은 게임 만들어줘”라고 하면 에이전트가 바로 코딩을 시작하면 안 된다.
먼저 질문해야 한다.

  • 2D인지 3D인지
  • 싱글인지 멀티인지
  • 조작 방식은 어떤지
  • 핵심 기능은 무엇인지
  • 어디까지 만들면 성공인지

이런 질문을 통해 모호성을 줄이고, 그다음 계획을 세워야 한다.

이건 실제 에이전트 제품에서 정말 중요하다.
사용자는 대충 말한다. 그런데 에이전트가 그 대충 말한 요청을 그대로 실행하면 높은 확률로 엉뚱한 결과가 나온다.

사람은 방향성과 최종 판단을 맡고, 에이전트는 질문, 계획, 실행, PR까지 밀어붙이는 구조가 더 현실적이다.

메모리는 근거가 아니다

Trace Guard와 Evidence Validation 발표에서는 에이전트의 신뢰 문제를 다뤘다.

핵심 문장은 이거였다.

메모리는 근거가 아니다.

에이전트가 “전에 봤다”, “기억한다”, “아마 그렇다”고 말해도 그건 근거가 아니다.
실제로 본 파일, 로그, 웹페이지, 실행 결과, 도구 응답 같은 evidence가 있어야 한다.

자기 개선하는 에이전트일수록 이 문제가 더 중요해진다.
메모리를 기반으로 점점 똑똑해지는 것처럼 보이지만, 그 메모리가 오염되면 잘못된 확신도 같이 커진다.

그래서 child run manifest, evidence, deterministic validation, trace guard 같은 검증 레이어가 필요하다는 얘기였다.

이건 코드 리뷰나 문서 자동화에서도 그대로 적용된다.
에이전트가 “수정했다”고 말하는 것과 실제 수정된 것은 다르다. 반드시 확인해야 한다.

Kanban은 멀티에이전트 운영 콘솔이다

Hermes Kanban을 실전 작업 큐처럼 쓰는 발표도 있었다.

큰 작업을 작은 task로 쪼갠다.
orchestrator가 task를 만들고, frontend, backend, devops, marketer 같은 profile에 할당한다.
worker는 ready 상태의 task를 가져가서 수행하고, 막히면 blocked로 올린다. 사람이 코멘트를 달면 다시 ready로 돌아간다.

여기서 중요한 팁은 profile을 역할별로 나누는 것이었다.

하나의 프로필에 모든 역할을 넣으면 세션 기록과 스킬이 섞인다.
그렇게 되면 에이전트 성능이 떨어지고, 맥락도 지저분해진다.

결국 Kanban은 단순 보드가 아니라 멀티에이전트 운영 콘솔에 가깝다.

GitHub 이벤트와 AI Native workflow

GitHub issue, PR, webhook 처리를 Hermes Kanban으로 옮긴 경험도 소개됐다.

흐름은 이렇다.

  • GitHub 이벤트를 받는다.
  • task queue로 변환한다.
  • Hermes가 issue나 PR을 triage한다.
  • 필요한 작업을 만든다.
  • 개발, 리뷰, merge 판단까지 이어간다.

다만 발표자는 AI에게 모든 걸 맡기면 안 된다고 했다.

사람이 아는 제약은 명확히 말해야 한다.
에이전트가 still working 상태로 멈춘 것처럼 보일 때도 조심해야 한다.
막히면 Discord Hermes, CLI Hermes, ChatGPT/Codex/Gemini 웹 UI 순으로 폴백하는 식의 우회 경로도 필요하다.

좋았던 조언은 이거였다.

자동화는 처음부터 만들지 말고, 반복되는 병목을 먼저 찾고 나서 harness로 만들 것.

AI Native는 코드를 안 본다는 뜻이 아니다.
반복적이고 귀찮은 운영 작업을 점점 에이전트에게 넘기는 사고방식에 가깝다.

에이전트의 다음 단계는 평가다

후반부에는 에이전트를 어떻게 평가할 것인지에 대한 발표도 있었다.

요지는 간단하다.

에이전트를 만드는 건 쉬워졌다.
하지만 사용자가 신뢰할 수 있는지, 실제 비즈니스에 도움이 되는지는 별개의 문제다.

그래서 persona 기반 평가가 필요하다.

예를 들어 한국 사용자 페르소나 데이터셋을 만들고, 소상공인 상담 에이전트가 실제로 쓸 만한 답을 하는지 평가한다.

평가 결과는 Markdown 리포트로 만들고, 다시 개선 루프에 넣는다.

이걸 보면서 나랑 같은 생각을 하는 사람이 있구나 생각이 들었다.

최근에 공모전을 참여하면서 구상한 아이디어를 기반으로 개발중인 프로젝트가 있는데 이런 루프를 쓰고 있다.

이와 관련해서 자세한 내용은 다음에 자세하게 다뤄보겠습니다.

메모리는 많이 저장하는 것보다 잘 버리는 게 중요하다

Manbase라는 외부 메모리 레이어 발표도 있었다.

문제의식은 현실적이었다.

Hermes의 기본 메모리는 작고 단순하다.
memory.md, user.md 같은 파일은 오래 쓰면 오염될 수 있다.
Obsidian이나 LLM Wiki도 좋지만, 문서가 많아지면 관리가 힘들다.

Manbase는 Slack, Gmail, Calendar, Notion, Claude/Codex 대화 같은 여러 소스를 연결해서 필요한 기억을 검색해주는 레이어다.
Vector DB와 Graph DB를 섞고, 오래된 정보는 최신화하고, 중요하지 않은 정보는 낮은 가중치로 둔다.

여기서 중요한 건 “많이 기억하기”가 아니었다.

뭘 기억하지 않을지, 어떻게 최신화할지가 더 중요하다.

구형 안드로이드폰으로 만드는 음성 AI 장치

재밌는 발표도 있었다.
집에 굴러다니는 구형 안드로이드폰을 개인용 AI 음성 장치로 쓰자는 아이디어였다.

폰은 마이크, 카메라, 스피커 역할을 한다.
실제 추론은 Mac mini나 GPT API 같은 외부 brain이 한다.

구조는 이렇다.

  • wake word를 듣는다.
  • “Hey Ray” 같은 호출어를 감지한다.
  • 사용자 말을 듣는다.
  • 외부 LLM과 도구를 호출한다.
  • 음성으로 답한다.

Tailscale로 네트워크를 연결하고 Kotlin 앱으로 구현했다고 한다.

이건 꽤 실용적인 아이디어다.
비싼 AI 디바이스를 새로 살 필요 없이, 구형 폰을 개인 AI의 껍데기로 쓸 수 있다.

LLM Wiki: RAG보다 구조화된 지식 정리

LLM Wiki 발표도 있었다.

일반적인 RAG는 문서 조각을 검색해서 프롬프트에 붙이는 방식이다.
LLM Wiki는 자료를 LLM이 소화해서 마크다운 위키 구조로 다시 정리한다.

구조는 대략 이런 식이다.

  • raw 원본
  • entity
  • concept
  • comparison
  • query
  • index
  • schema
  • log

Obsidian으로 열면 그래프처럼 볼 수 있고, Syncthing으로 서버와 로컬을 동기화할 수도 있다.

활용처도 많다.

  • 논문 정리
  • 강의자료
  • 공식문서 분석
  • 회의록
  • 인터뷰
  • 프로젝트 대화방 정리

하지만 발표자는 LLM에게 전부 맡기면 산으로 간다고 했다.
사람은 큰 구조와 철학을 잡고, LLM은 그 안에서 정리하게 해야 한다.

이 말이 꽤 맞는 것 같다.
AI에게 전부 맡기면 깔끔해 보이지만 이상하게 쓸모없는 문서가 나온다. 구조는 사람이 잡아야 한다.

실패를 기록하는 원장

Kuma Studio Dispatch 발표에서는 멀티에이전트에서 실패를 어떻게 다룰지 이야기했다.

여러 에이전트가 동시에 일할 때 중요한 건 성공이 아니라 실패와 막힘을 추적하는 것이다.

Dispatch는 에이전트 간 대화를 이메일이나 원장처럼 남긴다.

메시지 유형은 이런 식이다.

  • 지시
  • 질문과 응답
  • 상황 보고
  • 메모
  • blocker
  • 완료
  • 실패

상태도 단순하다.

  • dispatched
  • work done
  • pass
  • reject
  • fail

재밌었던 건 실패를 상위자가 일방적으로 판단하지 않는다는 점이다.
작업자가 스스로 fail을 올리고, 그 실패가 상위로 전파된다.

멀티에이전트는 많이 돌리는 것보다, 실패를 기록하고 다음 실행에 반영하는 원장이 더 중요하다는 메시지였다.

문서 업무로 확장되는 에이전트

마지막 쪽에서는 Docs, PPT, HWP 문서를 만드는 에이전트도 소개됐다.

흐름은 이렇다.

  1. Plan mode로 문서 구조를 정한다.
  2. 자료를 조사한다.
  3. 이미지 생성이나 검색을 한다.
  4. 문서를 만든다.
  5. Review agent가 검토한다.
  6. De-slop agent가 AI스러운 문장을 제거한다.
  7. Vision agent가 PPT 깨짐 여부를 확인한다.
  8. 최종 문서를 전달한다.

이 부분은 특히 중요해 보였다.

AI 에이전트는 개발자만 쓰는 도구로 남으면 안 된다.
대부분의 사무직이 매일 하는 일은 코드가 아니라 문서다. 보고서, 발표자료, 신청서, HWP, 회의록 같은 것들이다.

한국에서는 특히 HWP가 들어가는 순간 실용성이 확 올라간다.

내가 가져갈 포인트

이 영상을 보고 나서, 에이전트를 진짜 일 시키려면 필요한 것들이 조금 선명해졌다.

첫째, 상태 관리가 필요하다.
지금 무엇을 하고 있는지, 끝났는지, 막혔는지 알아야 한다.

둘째, 메모리 관리가 필요하다.
기억은 중요하지만 오염되면 오히려 위험하다.

셋째, 스킬과 도구 연결이 필요하다.
GitHub, 브라우저, HWP, 캘린더, 문서, 한국 생활 서비스 같은 실제 도구와 붙어야 한다.

넷째, 검증이 필요하다.
에이전트가 했다고 말하는 것과 실제로 한 것은 분리해서 봐야 한다.

다섯째, 실패 기록이 필요하다.
실패를 숨기면 다음 실행에서도 같은 문제가 반복된다.

마지막으로, 사람의 역할이 바뀐다.
사람이 모든 작업을 직접 하는 대신 방향성, 판단, blocker 해소, 최종 리뷰를 맡는 쪽으로 이동한다.

마무리

이번 Hermes 밋업에서 가장 크게 느낀 건, 에이전트의 경쟁력이 모델 자체보다 운영 구조에 있다는 점이었다.

좋은 답변을 한 번 만드는 건 이제 많은 모델이 할 수 있다.
하지만 오래 일하고, 상태를 기억하고, 실패를 기록하고, 도구를 쓰고, 근거를 검증하는 것은 별개의 문제다.

결국 실용적인 에이전트는 똑똑한 챗봇이 아니라 작은 운영체제에 가까워질 것 같다.
그리고 그 운영체제가 한국 생활, 문서, 취업, 일정, 로컬 도구와 잘 붙는다면 꽤 쓸모 있는 개인 비서가 될 수 있을 것 같다.