[심층분석] 터미널을 떠나 브라우저로: Hermes WebUI가 보여주는 자율 AI 에이전트의 새로운 사용 경험

서버에서 혼자 자라는 AI 에이전트, 이제 휴대폰으로도 만난다

요즘 개발자 커뮤니티를 둘러보면 'AI 에이전트(Agent)'라는 말이 정말 자주 등장하는데요. 이게 뭐냐면, 그냥 챗봇처럼 한 번 질문하고 한 번 답 받고 끝나는 게 아니라, 스스로 목표를 정하고, 도구를 쓰고, 기억하면서 점점 더 똑똑해지는 프로그램을 말해요. 예를 들어 "내 서버 로그 좀 분석해서 이상한 패턴 있으면 매일 아침 메일로 알려줘"라고 시켜놓으면, 알아서 cron 비슷한 스케줄을 잡고, 로그를 파싱하고, 패턴을 학습하고, 메일까지 보내는 그런 친구예요.

Hermes Agent도 이런 부류 중 하나거든요. 그런데 Hermes의 독특한 점은 "서버에 상주하면서 시간이 지날수록 더 유능해진다" 라는 컨셉을 정면으로 내세웠다는 거예요. 클로드 코드(Claude Code)나 Codex CLI처럼 터미널에서 잠깐 띄워서 작업하고 끄는 방식이 아니라, 마치 작은 비서를 한 명 채용해서 내 서버에 살게 하는 느낌인 거죠. 그래서 그동안 Hermes는 SSH로 접속해서 터미널이나 메신저 봇으로만 쓸 수 있었어요.

이번에 공개된 nesquena/hermes-webui는 바로 이 Hermes Agent를 웹 브라우저와 휴대폰에서도 똑같이 쓸 수 있게 해주는 프로젝트예요. 별것 아닌 것 같지만, 자율 에이전트의 사용 경험(UX)을 진지하게 다시 디자인했다는 점에서 살펴볼 가치가 충분해요. 특히 "빌드 단계도 없고, 프레임워크도 없고, 번들러도 없다(No build step, no framework, no bundler)"라고 당당하게 선언한 부분이 흥미로운데, 요즘 Next.js, Vite, Webpack이 당연한 시대에 굳이 바닐라 JS와 파이썬으로만 만들었다는 거니까요. 왜 그랬는지, 이게 어떤 의미인지 하나씩 풀어볼게요.

세 개의 패널, 그리고 컨텍스트 링: UI 설계 철학 뜯어보기

Hermes WebUI의 화면은 세 개의 패널(three-panel) 로 나뉘어 있어요. 왼쪽에는 세션 목록과 내비게이션, 가운데는 채팅 화면, 오른쪽은 워크스페이스(작업 폴더)의 파일 브라우저예요. 이 구조 자체는 새롭지 않아요. VS Code도 그렇고, 슬랙(Slack)도 그렇고, 디스코드도 비슷하잖아요. 그런데 여기서 디테일이 재미있어요.

컴포저 푸터(Composer Footer)에 모인 컨트롤

메시지를 입력하는 박스 바로 아래에 모델 선택, 프로필, 워크스페이스 컨트롤이 항상 떠 있어요. 이게 왜 중요하냐면, 자율 에이전트를 쓸 때 가장 자주 바뀌는 변수가 바로 이 세 가지거든요.

• 모델: GPT-5에게 시킬지, Claude Opus에게 시킬지, 로컬 Llama에게 시킬지. 작업 난이도와 비용에 따라 매번 바뀌어요.
• 프로필: 같은 모델이라도 "코드 리뷰용", "문서 작성용", "데이터 분석용"처럼 시스템 프롬프트와 도구 권한이 달라지죠.
• 워크스페이스: 어느 폴더를 컨텍스트로 줄 건지. 회사 프로젝트 폴더와 개인 사이드 프로젝트 폴더는 당연히 분리되어야 하니까요.

이걸 메뉴 깊숙이 묻어두지 않고 입력창 바로 옆에 둔 건, "매번 바뀌는 건 손에서 멀어지면 안 된다" 라는 UI 원칙을 따른 거예요. 일종의 '운전대 옆에 자주 쓰는 버튼 배치하기'와 같은 거죠.

원형 컨텍스트 링(Circular Context Ring)

개인적으로 이 디자인이 가장 똑똑하다고 느꼈어요. AI 에이전트를 써본 분들은 다 아실 텐데, 가장 무서운 게 컨텍스트 윈도우(Context Window) 초과거든요. 컨텍스트 윈도우란, 쉽게 말하면 AI가 한 번에 기억할 수 있는 대화의 양이에요. 종이 한 장에 적을 수 있는 글자 수가 정해진 것처럼, AI도 "이번 대화에서 20만 토큰까지만 기억 가능" 이런 한계가 있어요. 이걸 넘어가면 앞부분을 잊어버리거나, 오류가 나거나, 비용이 폭증해요.

Hermes WebUI는 이 토큰 사용량을 원형 게이지(반지처럼 둥근 표시) 로 항상 보여줘요. 차 계기판에서 연료 게이지 보는 것과 똑같은 원리예요. "아 슬슬 가득 차네, 세션을 새로 파야겠다" 또는 "아직 여유 있으니 더 깊이 파고들어도 되겠다" 하는 직관적인 판단을 가능하게 해주는 거죠. 이거 없이 작업해본 분들은 알 거예요. 갑자기 응답이 이상해지고 나서야 "아, 컨텍스트 꽉 찼구나" 깨닫는 답답함을요.

"빌드도, 프레임워크도, 번들러도 없다"는 선언의 무게

자, 이제 가장 논쟁적인 부분이에요. 요즘 웹 프론트엔드는 React, Vue, Svelte 같은 프레임워크 없이는 상상하기 어렵잖아요? 그런데 Hermes WebUI는 파이썬 백엔드 + 바닐라 JavaScript 만으로 만들어졌어요. 빌드 명령어(npm run build)도 없고, 의존성 트리를 관리하는 번들러(Webpack, Vite)도 없어요.

왜 이런 선택을 했을까?

첫째, 설치와 배포가 미친듯이 간단해져요. start.sh 하나만 실행하면 바로 떠요. 이게 자율 에이전트 도구에서 왜 중요하냐면, Hermes 사용자들은 보통 자기 개인 서버나 홈서버에 띄워두고 SSH 터널로 접속해서 쓰거든요. node_modules 폴더가 1GB씩 깔리는 걸 피하고 싶은 거예요. 도커 이미지 크기도 작아지고요.

둘째, 유지보수 부담이 적어요. React 16에서 18로 올리다가 일주일 날린 경험 있는 분들 많죠? 프레임워크가 없으면 "의존성이 깨져서 갑자기 안 돌아가는" 일이 거의 없어요. 5년 뒤에 봐도 똑같이 돌아가는 게 바닐라 JS의 힘이에요.

셋째, 읽기 쉬워요. 컨트리뷰터들이 PR을 보낼 때 "이 컴포넌트는 이 상태 라이브러리에 묶여 있고, 이 훅은 저 컨텍스트 프로바이더 안에서만 동작하고..." 같은 복잡한 멘탈 모델이 필요 없어요. static/ 폴더 안에 HTML, CSS, JS 파일이 있고, 그게 전부예요.

단점은 없을까?

물론 있어요. 컴포넌트 재사용성이나 상태 관리는 프레임워크가 훨씬 우아하게 해결해 줘요. 화면이 복잡해질수록 바닐라 JS의 코드는 점점 스파게티가 되기 쉽고요. 다만 Hermes WebUI의 UI 복잡도가 "세 패널 + 채팅" 수준이라면, 굳이 React를 가져올 필요는 없다는 판단인 거예요. "도구는 문제 크기에 맞춰야 한다" 는 엔지니어링의 오래된 격언을 정확히 따른 거죠.

다른 AI 에이전트 UI들과 비교해보면

자율 에이전트를 웹 UI로 감싸는 시도는 사실 여러 곳에서 나왔어요. 몇 가지를 쉬운 비유로 비교해볼게요.

Open WebUI (LLM 채팅 허브)

이건 ChatGPT를 자기 서버에 띄우는 느낌이에요. 모델 여러 개를 등록하고, 사용자 계정을 만들고, RAG(검색 증강 생성)도 붙일 수 있어요. "여러 사람이 쓰는 사내 ChatGPT" 가 목표예요. Hermes WebUI보다 훨씬 무겁고 기능이 많아요. 대신 "내 서버에서 자라는 에이전트" 컨셉은 아니에요. 그냥 잘 꾸며진 채팅 인터페이스에 가까워요.

LibreChat

이것도 비슷한 결인데, 더 기업용에 가까워요. 인증, 모더레이션, 멀티 테넌시(여러 조직이 한 서버 공유) 같은 기능이 강해요. "회사용 챗봇 플랫폼" 이라고 보면 돼요.

Claude Code / Codex CLI / Aider

이쪽은 터미널 기반 에이전트예요. 코드 작업에 특화되어 있고, git과 깊이 연동돼요. "코드 에디터 옆에서 일하는 페어 프로그래머" 느낌이죠. Hermes는 코드뿐 아니라 일반적인 자율 작업(스케줄링, 모니터링, 메모 정리 등)까지 다루기 때문에 결이 살짝 달라요.

Hermes WebUI의 포지션

그러니까 Hermes WebUI는 "내 서버에 사는 자율 비서를 휴대폰으로도 부려먹기 위한 가벼운 창문" 이에요. 다른 UI들이 "기능을 많이 넣자"로 갔다면, 이쪽은 "CLI와 1:1 동등성을 유지하면서 가볍게"로 갔어요. SSH 터널로 접속해서 쓰라고 권장하는 것도, 외부 노출을 최소화하고 보안을 본인이 직접 통제하라는 의도예요.

한국 개발자에게 어떤 의미가 있을까

시나리오 1: 1인 개발자의 사이드 프로젝트 운영

홈서버나 라즈베리파이, 또는 저렴한 VPS를 한 대 가지고 있는 분이라면 딱이에요. 거기에 Hermes Agent를 띄워두고, 외출 중에도 휴대폰으로 "어제 크롤링한 데이터 정리해서 슬랙으로 보내줘" 같은 명령을 던질 수 있는 거죠. 클라우드 AI 서비스에 매달 구독료를 내는 것보다, 로컬 모델 + 가끔 API 호출 조합이 장기적으로 더 쌀 수 있어요.

시나리오 2: 회사 내 개인 보조 도구

회사에서 ChatGPT나 Claude 사용이 보안상 제한된 곳도 많죠. 사내 서버에 Hermes를 띄우고, 사내 네트워크 안에서만 접속 가능한 웹 UI로 쓰면, 코드는 외부로 안 나가면서도 AI의 도움은 받을 수 있어요. 다만 이건 보안 담당자와 충분히 협의하고 진행해야 해요. 모델 API를 외부로 호출하는 순간 데이터가 나가니까요.

시나리오 3: 학습용 토이 프로젝트

주니어 개발자라면 이 프로젝트 자체를 읽는 것만으로도 공부가 돼요. 빌드 도구 없이 SSE(Server-Sent Events)나 WebSocket으로 실시간 스트리밍을 어떻게 구현하는지, 세션 상태를 SQLite로 어떻게 관리하는지, 파이썬 백엔드와 JS 프론트엔드를 어떻게 깔끔하게 연결하는지 같은 걸 코드로 직접 볼 수 있거든요. React 튜토리얼만 백번 보는 것보다 이런 "진짜 도구"의 소스를 한 번 정독하는 게 훨씬 남는 게 많아요.

도입 시 고려할 점

1. 보안: 절대 그냥 0.0.0.0으로 열어놓고 인터넷에 노출하지 마세요. SSH 터널이나 Cloudflare Tunnel, Tailscale 같은 걸 꼭 끼워서 쓰세요. 패스워드 기능이 있긴 하지만, AI 에이전트는 권한이 너무 강해요.
2. 모델 비용: 자율 에이전트는 사람보다 토큰을 훨씬 많이 써요. 컨텍스트 링을 자주 확인하고, 작업 단위를 잘게 쪼개는 습관이 필요해요.
3. 백업: 에이전트가 "기억"한다는 건 어딘가에 데이터가 쌓인다는 뜻이에요. 세션 DB와 워크스페이스 폴더 백업 전략을 꼭 세우세요.

학습 로드맵 제안

• 1주차: 그냥 띄워서 써보기. CLI도 같이 써보면서 "1:1 parity"가 진짜인지 확인하기.
• 2주차: server.py와 static/ 폴더 코드 읽기. 라우팅과 SSE 스트리밍 부분 집중.
• 3주차: 나만의 도구(tool) 하나 추가해보기. MCP(Model Context Protocol) 서버도 같이 살펴보면 좋아요.
• 4주차: 본인의 워크플로우에 통합. 매일 아침 일정 정리, 코드 리뷰 보조 같은 작은 자동화부터.

마무리: 자율 에이전트의 UI는 어떻게 진화할까

Hermes WebUI가 우리에게 던지는 메시지는 두 가지예요. 첫째, 자율 에이전트는 더 이상 터미널의 전유물이 아니다. 휴대폰에서, 태블릿에서, 침대에 누워서도 내 서버의 비서에게 일을 시킬 수 있어야 한다는 거죠. 둘째, 그렇다고 도구가 무거워질 필요는 없다. 빌드 단계 없이도 충분히 쓸 만한 웹 UI를 만들 수 있고, 그게 오히려 장기적으로 더 건강하다는 메시지예요.

앞으로 비슷한 결의 프로젝트가 더 많이 나올 것 같아요. "내 서버에 사는 작은 AI 비서"라는 개념은 클라우드 의존도가 점점 부담스러워지는 흐름과도 잘 맞거든요. 특히 로컬 LLM 성능이 빠르게 좋아지면서, 굳이 모든 걸 클라우드로 보낼 필요가 없어지고 있어요.

여러분은 어떠세요? 지금 AI를 어떤 방식으로 쓰고 계신가요? 클라우드 서비스에 모든 걸 맡기고 계신지, 아니면 로컬에 뭔가 띄워서 직접 다루고 계신지 궁금해요. 그리고 만약 자율 에이전트를 본인 서버에 띄운다면, 가장 먼저 어떤 일을 시키고 싶으신가요? 매일 반복되는 그 귀찮은 일, 한 번 댓글로 풀어보면 의외로 좋은 자동화 아이디어가 나올지도 모르겠네요.