서문: 3개월의 OpenClaw, 그리고 새로운 시작
2026년 2월부터 약 3개월간 필자는 OpenClaw라는 에이전트 플랫폼 위에서 아침 뉴스 자동화, 날씨 알림, 블로그 포스팅, 서버 인프라 관리 등 다양한 작업을 자동화해 왔다. 시간이 지나면서 OpenClaw의 멀티 에이전트 구조가 주는 유연성보다는 관리 복잡도가 더 크게 다가오기 시작했다.
각 작업마다 별도의 에이전트(뉴스 에디터, 워드프레스 운영자, 코딩 에이전트)가 각자의 워크스페이스와 설정 파일, AGENTS.md, TOOLS.md, MEMORY.md, SOUL.md를 들고 있었고, 이들 간의 컨텍스트 전달은 점점 더 많은 토큰을 소비했다. 3개월간 쌓인 200개가 넘는 메모리 파일과 20개 이상의 에이전트 설정 파일은 시스템의 무게감을 더해갔다.
이런 상황에서 Hermes Agent를 만나게 되었다. Hermes는 단일 에이전트 구조에 스킬(Skill) 시스템을 결합한 새로운 접근법을 제시했다. 이 글은 OpenClaw에서 Hermes로의 플랫폼 마이그레이션을 결정하게 된 배경과 전체 과정을 담은 마이그레이션 전사(全史)다.
OpenClaw의 강점과 한계
OpenClaw 아키텍처
OpenClaw는 다중 에이전트 시스템으로 설계되어 있었다. 주요 에이전트는 다음과 같다:
| 에이전트 | 역할 | 모델 |
|---|---|---|
| main (오케스트레이터) | 전체 워크플로우 조정, 최종 검수 | deepseek-v4-pro |
| news_editor | 뉴스 수집·요약·파일 저장 | deepseek-v4-pro (fallback: glm4.7) |
| wordpress | 워드프레스 운영·포스팅 발행 | deepseek-v4-pro (fallback: glm4.7) |
| coding | 스크립트 작성·버그 수정 | deepseek-v4-pro (fallback: minimax-m2.7) |
| freelance-blogger | 육아·게임 일상 에세이 | gemini-3-flash-preview |
세 가지 주요 문제점
- 컨텍스트 분산: 각 에이전트가 독립된 워크스페이스를 가지고 있어, main이 서브에이전트에 지시를 내릴 때마다 goal과 context를 다시 전달해야 했다. 이 과정에서 정보 누락이나 오해가 발생하기 쉬웠다.
- 설정 파일 폭증: 각 에이전트마다 AGENTS.md, TOOLS.md, SOUL.md, IDENTITY.md, USER.md 등 5~7개의 설정 파일이 필요했다. 5개 에이전트 기준 약 30개의 파일을 유지보수해야 했다.
- LLM 호출 비효율: 아침 뉴스 하나를 만드는 데 7회의 LLM 호출이 필요했다. 특히 서브에이전트의 자체 검증 능력에 의존하다 보니 발행일 검증 실패(5/1, 5/4 사고)로 잘못된 기사가 포함되는 문제가 반복되었다.
Hermes Agent: 단일 에이전트 + 스킬의 힘
Hermes Agent는 이와 대비되는 접근법을 취한다. 하나의 에이전트가 모든 작업을 수행하되, 스킬(Skill) 시스템을 통해 역할과 규칙을 전환한다. 사용자가 “블로그 써줘”라고 말하면 tech-blog 스킬이 로드되고, “일상블로그 써줘”라고 말하면 daily-blog 스킬이 로드되는 방식이다.
왜 단일 에이전트인가?
- 컨텍스트 일관성: 모든 작업이 하나의 에이전트 컨텍스트 안에서 이루어지므로 정보 전달 과정에서 손실이 없다.
- 설정 단순화: 30개의 설정 파일 대신 2개의 스킬 파일로 모든 규칙을 정의할 수 있다.
- LLM 호출 최적화: cron 작업은 no_agent 모드로 LLM 호출을 0건으로 줄이고, 순수 Python 스크립트만으로 뉴스 수집·검증·전송을 처리한다.
마이그레이션 6대 워크스트림
마이그레이션은 다음 6개 영역에서 동시에 진행되었다:
- 아침 뉴스 파이프라인 이전
OpenClaw의 7회 LLM 호출 파이프라인 → Hermes cron no_agent 모드 + Python 스크립트. RSS/GNews 하이브리드 수집기, verify_article_dates.py 검증기, urllib 기반 텔레그램 전송기로 구성.
- 날씨 알림 자동화
Open-Meteo API 기반 날씨 데이터 수집 → 유효성 검증 → 텔레그램 전송. 매일 07:00 KST cron 발송.
- 블로그 포스팅 파이프라인 이식
OpenClaw의 3단계 서브에이전트(오케스트레이터→news_editor→wordpress) 방식 → 2개의 Hermes 스킬(tech-blog, daily-blog). 단일 에이전트가 스킬만 전환하며 글 작성부터 발행까지 end-to-end 처리.
- 웹 검색 엔진 전환
OpenClaw의 Tavily 검색 → Hermes에서도 동일한 Tavily 연동. Hermes는 TAVILY_API_KEY 환경변수만 설정하면 web_tools.py가 자동으로 감지하여 web_search 도구를 활성화한다.
- 설정 파일 통합
OpenClaw의 5개 에이전트 × 5~7개 설정 파일 → Hermes의 config.yaml + 2개 skill SKILL.md. cron 설정, 보안 정책(Tirith), approvals, web 백엔드 등 모든 설정을 단일 config.yaml에서 관리.
- 워크스페이스 분석 및 정리
OpenClaw의 방대한 아티팩트(설정 파일 20개+, 메모리 200개+, 로그 600개+)를 분석하여 Hermes로 가져갈 핵심 규칙과 지식만 추출. 스킬로 이식하고 나머지는 Cold Memory로 보관.
OpenClaw vs Hermes: 핵심 비교
| 항목 | OpenClaw | Hermes Agent |
|---|---|---|
| 에이전트 구조 | 다중 에이전트 (main + 4 sub) | 단일 에이전트 + 스킬 |
| 설정 파일 수 | ~30개 (에이전트당 5~7개) | ~5개 (config.yaml + 스킬) |
| 뉴스 파이프라인 LLM 호출 | 7회 | 0회 (no_agent 모드) |
| 블로그 포스팅 방식 | 서브에이전트 위임 (3단계) | 스킬 기반 직접 작성 (1단계) |
| 메모리 관리 | 파일 기반 (워크스페이스 로컬) | 내장 메모리 시스템 + 파일 |
| 크론 작업 | 스크립트 기반 | 내장 cronjob 시스템 |
| 모델 전환 | 에이전트별 고정 | 세션/크론별 지정 가능 |
마이그레이션 핵심 교훈 5가지
- 단순함이 복잡함을 이긴다: 다중 에이전트가 주는 유연성은 관리 비용을 상쇄하지 못했다. 단일 에이전트 + 스킬이 실제 운영에서는 더 효율적이었다.
- LLM의 역할을 축소하라: 뉴스 파이프라인에서 LLM을 완전히 제거하자(no_agent), 발행일 검증 실패율이 0이 되었다. LLM은 선택과 요약에만 쓰고, 검증은 프로그램적으로 처리하는 것이 정답이었다.
- 설정은 중앙화, 지식은 분산화: config.yaml 하나로 모든 설정을 관리하고, 작업별 세부 규칙은 스킬에 담아 필요할 때만 로드하는 방식이 가장 효율적이었다.
- 마이그레이션은 한 번에 하지 말라: 뉴스 → 날씨 → 블로그 → 검색 순으로 점진적으로 이전하면서 각 단계에서 문제를 해결하는 방식이 효과적이었다.
- 데이터 보존이 우선이다: OpenClaw의 3개월치 설정 파일, 메모리, 로그는 분석 대상일 뿐 아니라 과거 의사결정의 역사가 담긴 귀중한 자산이다. 모두 Cold Memory로 보관하여 필요 시 참조할 수 있게 했다.
마치며
OpenClaw에서 Hermes로의 이전은 단순한 플랫폼 변경이 아니라, 에이전트 운영 철학의 전환이었다. “많은 에이전트가 각자 전문 분야를 맡는다”는 다중 에이전트 패러다임에서 “하나의 에이전트가 다양한 스킬로 변신한다”는 단일 에이전트 + 스킬 패러다임으로의 전환이다.
다음 편에서는 가장 큰 변화를 겪은 아침 뉴스 파이프라인의 상세 이전 과정을 다룰 예정이다.