AI 에이전트 2대 체제 실전기: OpenClaw vs Hermes 무엇이 다른가

들어가며

AI 에이전트를 하나 도입하고 나면 자연스럽게 이런 궁금증이 생깁니다. 다른 에이전트는 어떻게 다를까, 하나면 충분할까. 저는 홈서버 한 대에 OpenClaw와 Hermes라는 두 에이전트를 함께 띄우고 3주 넘게 실제 업무를 번갈아 맡겼습니다. 블로그 글 작성, 서버 점검, 코드 개발, 정보 검색까지요. 이 글은 두 에이전트를 실제로 함께 운영해 본 비교 사용기입니다. 어느 쪽이 더 낫다는 결론보다, 구조와 성격이 어떻게 다른지, 어떤 상황에서 어느 쪽이 편한지를 실측을 바탕으로 정리합니다.

핵심 개념

두 에이전트는 목표는 같지만 구조가 다릅니다.

• OpenClaw: 게이트웨이 중심 구조. 텔레그램 같은 메신저가 기본 입구이고, 웹 Control UI에서 세션·작업·자동화를 관리합니다. 정기 작업 예약, 하위 에이전트 실행, 외부 코딩 에이전트(ACP) 연결 같은 오케스트레이션 기능이 강점입니다.
• Hermes: 에이전트에 자체 웹 대시보드가 붙는 구조. 대시보드에 채팅과 터미널이 함께 있고, OpenAI 호환 API를 제공해서 다른 도구에서 이 에이전트를 하나의 모델처럼 호출할 수 있습니다.

공통점도 분명합니다. 둘 다 Docker 컨테이너로 같은 서버에서 구동하고, 같은 저비용 LLM을 기본 모델로 쓰며, /shared 공유 폴더로 파일을 주고받습니다. 그래서 비교가 공정합니다.

1단계: 설치와 구조

OpenClaw는 Docker 컨테이너 하나와 설정 파일 하나로 구동됩니다. 플러그인을 더하고 뺄수록 기능이 늘어나는데, 메신저 채널 연결은 설정 파일에 채널을 추가하는 수준으로 끝납니다.

Hermes는 컨테이너 안에 에이전트 본체와 웹 대시보드가 함께 있습니다. 대시보드는 별도 포트로 서비스되고, HTTPS 프록시를 앞에 두어 LAN 안에서 안전하게 접속합니다. 재부팅 후 자동 시작 구성은 OS의 서비스 관리자에 등록하는 방식입니다.

• 설치 난이도: 둘 다 Docker 한 대면 끝납니다. 차이는 접속 방식의 차이입니다.
• 이 단계의 성공 기준: 두 에이전트가 각각 자기 포트에서 응답하면 성공입니다.

2단계: 사용 인터페이스, 메신저 대 대시보드

사용 경험의 가장 큰 차이는 인터페이스입니다.

• 클로(OpenClaw): 텔레그램 대화창이 주 무대입니다. 이동 중에 휴대폰으로 지시하고, 결과 알림이 같은 대화창에 도착합니다. 작업 이력이 곧 대화 기록이라 나중에 검색하기 쉽습니다.
• 헬메(Hermes): 웹 대시보드가 주 무대입니다. 화면을 보면서 터미널을 직접 만지고, 파일 구조를 눈으로 확인하며 작업합니다. 대시보드 자체가 오픈 소스여서 UI를 직접 수정할 수 있습니다.

실제로 저는 대시보드의 한글 입력 문제를 직접 고쳐본 경험이 있습니다. Hermes 대시보드가 오픈 소스라서 소스를 고쳐 빌드할 수 있었고, 아이패드 사파리의 한글 조합 문제를 해결했습니다. 이런 커스터마이징 자유도는 헬메 쪽이 확실히 높습니다. 반대로 이동 중 휴대폰으로 지시하고 싶을 때는 클로가 압도적으로 편합니다.

한글 입력 문제를 조금 더 구체적으로 풀면 이렇습니다. 아이패드 사파리(WKWebView)는 표준 브라우저와 다르게 한글 조합 과정을 알려주는 이벤트를 아예 보내지 않습니다. 글자 하나하나가 완성된 형태로 입력되고, 지우기도 단순한 키 이벤트로 보고됩니다. 그 결과 터미널에서 한글이 자모로 분해되거나, 이전 글자가 남는 증상이 나타납니다. 해결 과정은 세 단계였습니다.

• 실기기에서 입력 이벤트를 직접 기록하는 디버그 오버레이를 붙여, 어떤 이벤트가 어떤 순서로 오는지 캡처합니다
• 사파리는 조합 이벤트가 없으므로, 자모가 단독으로 오면 새 음절의 시작으로 판단하고 조합 상태를 직접 관리하는 입력 모드를 만듭니다
• 크롬 계열은 또 다른 방식(키다운 이벤트로 자모가 옴)을 쓰므로, 이 경우에는 표준 두벌식 조합 규칙을 코드로 직접 구현해 글자를 합성합니다

조합 이벤트에 의존하지 않고 자모 조합 규칙을 자체 구현하는 방식이라, 어떤 브라우저에서도 한글이 온전히 입력됩니다. 이런 문제는 에이전트 선택보다 브라우저와 터미널 조합에서 오는 것이지만, 웹 대시보드를 직접 고칠 수 있는 오픈 소스 구조라서 해결이 가능했습니다. 같은 문제를 클로의 메신저 중심 구조에서 만나면, 메신저 앱 자체가 입력을 처리하므로 애초에 발생하지 않습니다.

3단계: 권한과 승인 구조, 그리고 어제의 실측 사례

가장 흥미로운 차이는 권한 체계입니다.

클로는 외부에 영향을 주는 작업에 승인 카드를 띄웁니다. 파일을 지우거나, 설정을 바꾸거나, 외부로 무언가를 보낼 때 사람의 승인을 기다립니다. 안전하지만, 자동화 흐름에서 권한 요청이 사람에게 닿지 않으면 작업이 멈춘다는 단점이 있습니다.

어제 실제로 겪은 사례입니다. 코딩 에이전트(Claude Code)를 하위 세션으로 실행해 SPFx 프로젝트를 개선하려 했는데, 하위 세션이 파일 쓰기 권한을 얻지 못해 멈췄습니다. 권한 설정 변경을 시스템에 요청했는데, 시스템은 사용자 본인이 직접 입력한 승인만 받도록 설계되어 있었습니다. 에이전트가 대신 전달한 승인은 세 번 모두 거부됐습니다. 결국 안전장치를 우회하는 대신, 메인 에이전트가 직접 구현으로 전환해 작업을 완료했습니다.

이 사례가 주는 교훈은 두 가지입니다.

• 엄격한 승인 구조는 실수를 막지만, 자동화 흐름 안에서는 사전에 권한을 정리해 둬야 멈추지 않습니다
• 승인 요청은 반드시 사용자가 직접하는 구조여야, 에이전트가 몰래 권한을 넓히는 일을 원천 차단합니다

헬메 쪽은 이런 승인 카드 체계가 상대적으로 단순합니다. 대신 자율성이 높아서, 최근 버전 업그레이드(8.2에서 9.1)를 스스로 설치하고 검증까지 마쳤습니다. 자율성과 안전장치의 균형점이 두 에이전트에서 다르다고 요약할 수 있습니다.

4단계: 메모리와 지식 관리

• 클로: 대화마다 메모리 파일과 일일 노트를 갱신하고, 컴파일된 위키에 회고를 쌓습니다. 세션이 바뀌어도 기억이 파일로 남습니다.
• 헬메: 전용 위키 폴더를 스스로 관리합니다. 폴더의 위키 문서로 장기 지식을 정리합니다.

두 에이전트가 같은 파일을 동시에 고치면 마지막 저장만 남는 사고가 실제로 있었습니다. 이후 일일 노트는 읽기 후 추가 방식으로만 저장하는 규칙을 만들었습니다. 에이전트가 여러 개라면 기록 규칙부터 정하는 것이 협업의 출발점입니다.

5단계: 협업 구조

두 에이전트는 /shared 공유 폴더로 협업합니다. 대표적인 예가 이 블로그 글입니다.

• 주제풀: 두 에이전트가 함께 쓰는 글 주제 목록. 누가 어떤 주제를 진행 중인지 상태를 갱신합니다
• 플레이북: 글 작성 절차의 단일 기준점. 한쪽이 개선하면 다른 쪽이 그대로 따릅니다
• 발행 방식 공유: 한쪽이 개발한 네이버 스마트에디터 발행 방식을 다른 쪽이 도입해 썼습니다

주의할 함정도 있습니다. 공유 폴더의 파일은 만든 쪽 사용자 권한으로 저장되어, 상대 에이전트가 직접 수정하면 권한 에러가 납니다. 삭제 후 다시 쓰는 우회법이 있지만, 가급적 파일 소유권 규칙을 미리 정하는 것이 낫습니다.

6단계: 선택 가이드

상황	추천
메신저로 지시하고 알림 받기	OpenClaw
웹 화면에서 눈으로 보며 조작	Hermes
다른 도구에서 에이전트를 API로 호출	Hermes (OpenAI 호환 API)
정기 자동화, 다중 채널, 하위 에이전트	OpenClaw
두 대 모두 운영하며 역할 분담	실제로 가장 효과적

보안과 주의사항

• 에이전트 API는 터미널 접근 권한이 따라오므로 인터넷에 노출하면 안 됩니다. LAN에서만 접근하게 합니다
• 공유 폴더의 실제 서버 주소나 계정명이 외부 자료에 노출되지 않게 플레이스홀더로 바꿉니다
• 승인 제도는 번거로워도 끄지 않는 것을 권합니다. 어제의 사례에서 승인 구조는 오히려 올바르게 작동했습니다

트러블슈팅

1. 공유 폴더 파일을 상대 에이전트가 못 고침: 파일 소유권 문제입니다. 삭제 후 다시 쓰거나 소유자에게 요청합니다

2. 웹 대시보드가 열리지 않음: 프록시의 Host와 Origin 헤더 설정을 확인합니다. 헤더 검증에 걸리면 웹소켓이 끊깁니다

3. 하위 코딩 에이전트가 권한에서 멈춤: 비대화형 세션의 권한 정책을 사전에 점검합니다. 프롬프트가 사람에게 전달되지 않으면 승인 대기로 멈춥니다

4. 터미널에서 한글이 깨짐: 모바일 사파리 계열 브라우저는 조합 이벤트를 보내지 않으므로, 자모 조합 규칙을 직접 구현하거나 브라우저를 바꿔야 합니다. 본문 2단계의 해결 과정 참고

마무리

두 에이전트를 함께 운영한 결론은 단순합니다. 인터페이스와 권한 철학이 다르기 때문에, 하나만 쓸 때보다 두 대를 역할별로 나눠 쓰는 체제가 실제로 더 강했습니다. 메신저 중심의 일상 지시와 정기 자동화는 클로, 화면 보며 하는 개발과 실험은 헬메가 맡는 식입니다.

확장 팁: 두 에이전트가 같은 공유 폴더를 보게 만들고, 한쪽이 만든 절차 문서를 다른 쪽이 따르게 하면, 각자의 강점이 서로를 보완합니다.