Hermes를 처음부터 배울 필요는 없습니다 — 기존 실력을 활용했습니다

I’m happy to translate the article for you, but I need the full text of the post (the paragraphs, headings, code snippets, etc.) in order to do the translation. The source link you provided is fine to keep unchanged at the top, but please paste the article’s content here so I can translate it while preserving the original formatting, markdown, and technical terms.

Source: …

나는 Hermes로 시작하지 않았다

6개월 전, 나는 소프트웨어를 구축하는 방식을 위한 에이전트 스킬과 페르소나 세트를 만들기 시작했다. 일반적인 프롬프트가 아니라, 의견이 반영된 역할 파일들이다:

• /backend-architect – 스키마와 추천 로직을 담당한다.
• /test-engineer – Vitest 커버리지를 작성하고 약한 수용 기준을 표시한다.
• /project-manager – 계획 문서를 유지하고 반복을 깔끔하게 종료한다.

이 역할들은 여러 프로젝트에 걸쳐 진화해 왔다. 레이어링 규칙, 탐색 체크리스트, 기본 엔지니어링‑discipline 파일로부터의 상속을 가지고 있다. 역할이 명확히 범위가 정의돼 있기 때문에 일관되고 검토 가능한 결과물을 만든다 — 백엔드 아키텍트는 테스트 파일을 건드리지 않고, 테스트 엔지니어는 스키마를 재설계하지 않으며, 각 페르소나는 정의된 임무를 가지고 깔끔하게 종료한다.

Hermes Agent에 대해 들었을 때, 내 첫 번째 반응은 “새 시스템을 배워야겠다”가 아니었다. 오히려:

내 기존 시스템을 여기서 실행할 수 있을까?

답은 예다. 이 글은 바로 그 이야기를 다룬다 — 성숙한 워크플로우를 Hermes에 가져올 때 어떤 모습인지, 얻을 수 있는 이점, 어디에서 한계가 발생하는지, 그리고 내가 다르게 할 부분은 무엇인지.

이미 워크플로우가 있는 사람에게 Hermes가 무엇이고, 무엇이 아닌가

Hermes는 LLM에 구애받지 않는 오케스트레이션 레이어입니다. 자체 스킬 시스템, 지속적인 에이전트 정체성을 위한 soul.md 개념, 내장된 크론 스케줄링, 그리고 MCP 관리를 갖추고 있습니다. 이 모든 것이 실제이며 유용합니다.

하지만 이것은 동시에 런타임이기도 합니다. 작동하는 스킬이 있다면 그대로 가져올 수 있습니다.

저는 로컬 Hermes 인스턴스를 설치했습니다 — 몇 번의 클릭으로 간단히 설정하고, 기존 퍼소나 파일을 가리키는 VS Code 통합 터미널 안에서 실행했습니다. 마이그레이션도, 재작성도 필요 없었습니다. 제 /backend-architect는 Hermes 안에서도 Claude Code 안에서와 똑같이 실행됩니다.

이렇게 결정하기 전에 몇 가지 다른 방법을 시도해 보았습니다:

1. 아이디어 구상을 위한 텔레그램 인터페이스가 있는 VPS 인스턴스.
2. 브라우저 기반 터미널.

VPS는 아이디어 스케치를 하는 데는 괜찮았습니다. 브라우저 터미널을 사용해 보니, 적절한 로컬 환경 없이 프로덕션 급 도구를 만들려는 것이 잘못된 길이라는 것이 명확해졌습니다. VS Code 내 로컬 Hermes는 그 마찰을 없애 주었습니다.

놀라웠던 점: “Hermes를 직접 배우는 것”과 “이미 잘 쓰는 것을 계속 쓰는 것” 사이에서 선택할 필요가 없다는 것입니다. 두 가지를 동시에 할 수 있습니다. Hermes는 런타임이 되고, 여러분의 스킬은 구조를 유지합니다.

The Build: Production in 3 Days on a New System

제가 이 설정으로 만든 프로젝트는 Brew Guide — 공개 MCP 서버로 제공되는 커뮤니티 커피 지식 베이스입니다. 실제 브루 실험을 기록하고, 그 데이터를 기반으로 합의된 추천을 만들며, 다섯 가지 MCP 도구를 통해 기술 가이드(블룸 타이밍, 붓기 단계, 교반 스타일)를 반환합니다. 프로덕션 엔드포인트이며, 인증 없이 지금 바로 라이브됩니다.

저는 3일 만에 이를 구축했습니다 — 이전에 한 번도 사용해 보지 않은 Hermes 위에서 말이죠.

이 숫자가 중요한 이유는 빌드가 단순했기 때문이 아니라(Neon Postgres, Prisma migrations, 55개의 통과 테스트, Railway auto‑deploy, 전반에 걸친 엄격한 TypeScript), 그 3일을 Hermes를 배우는 데 쓰지 않았기 때문입니다. 그 시간을 빌드하는 데 사용했습니다. 워크플로우가 이미 성숙해 있었기 때문에, 익숙하지 않은 런타임에서도 무거운 작업을 대신해 주었습니다.

경쟁 스프린트 — 스크래퍼, 스키마상의 technique JSONB, 랜딩 페이지, 그리고 경쟁 기사 등 7개의 전달물 — 은 첫 번째 리뷰 통과에서 “verified” 상태에 도달했습니다. 한 번의 반복으로 말이죠. 이는 워크플로우가 제대로 작동했음을 의미하며, AI가 완벽했다는 뜻은 아닙니다.

모델을 교체할 때 깨지는 것

여기서 더 흥미로운 부분이 있는데, 솔직히 말씀드리겠습니다.

이전 단계에서 같은 코드베이스에 다른 모델을 사용해 동일한 스킬 세트를 실행했습니다. 동일한 페르소나 파일, 동일한 작업 범위, 동일한 Hermes 오케스트레이션. 목표는 내 워크플로우가 LLM 간에 이식 가능한지 확인하는 것이었습니다.

관찰된 실패 유형은 툴‑콜 준수였습니다. 다른 모델은 호출을 더 자주 실수했으며—재시도, 구조화된 오케스트레이션을 따르기보다 자체 경로를 찾아가는 순간이 있었습니다. Claude에서는 30분 걸리던 작업이 대부분의 근무일을 차지했습니다. 출력물은 다음과 같은 수정을 필요로 했습니다:

• 프로덕션을 크래시시킨 Node‑버전 API 호출.
• 배관은 확인했지만 AC가 요구하는 스코어링 불변성을 확인하지 못한 수용 기준 테스트.
• 코드와 점점 멀어지는 문서.

당시 Hermes의 네이티브 모델 어댑터를 사용하지 않았습니다—스킬은 Claude용으로 만든 동일한 인터페이스를 통해 실행되고 있었습니다. 따라서 격차가 모델 능력 때문인지 Hermes‑모델 통합 문제 때문인지 확정적으로 말할 수 없습니다. 두 경우 모두 가능성이 있습니다.

내가 말할 수 있는 점은:

동일한 지시사항, 동일한 페르소나, 사양에 대한 준수도가 크게 달라짐.
내 스킬은 Claude가 구조화된 지시를 파싱하는 방식에 맞춰 작성·다듬어졌습니다. 같은 지시를 파싱 방식이 다른 모델에 넘기면 준수도가 떨어지고—툴‑콜 신뢰성이 가장 먼저 깨집니다.

이것이 Hermes가 해결하려는 이식성 질문입니다. 정말 어려운 문제이며, 제가 해결한 것은 아닙니다. 하지만 어디서 깨지는지를 드러내는 것은 유용한 발견입니다.

내가 다르게 구축할 부분

내가 전체 과정에서 느낀 격차는 한 단계, 내 기술을 네이티브 Hermes 형식으로 마이그레이션하지 않은 것에서 비롯되었습니다.

Hermes에는 soul.md 개념이 있습니다 — 세션 간에 에이전트 정체성을 형성하는 지속 문서입니다. 이는 에이전트가 매 대화에 가져가는 컨텍스트, 즉 가치관, 작업 방식, 제약 조건이라고 생각하면 됩니다. 내 기술은 soul.md 없이도 동작하지만, 앵커가 부족합니다. 내가 구축하는 방식을 반영한 soul.md(규칙 레이어링, 페르소나 경계, 모든 역할을 지배하는 엔지니어링 규율)를 만들면 현재 내 머리 속에만 존재하는 Hermes 네이티브 컨텍스트가 제공되고, 모델 교체 시에도 기술이 더 견고해집니다.

두 번째 누락된 단계: 모델‑특정 기술 검증. 내 기술은 Claude의 지시‑추종 행동을 전제로 작성되었으며, 다른 모델에 대해 스트레스 테스트를 거치지 않았습니다. 지원되는 어댑터(Claude, GPT‑4 등)마다 각 기술을 실행해 보는 검증 스위트를 구축하면 호환성 문제를 조기에 발견할 수 있어, 모델에 구애받지 않는 폴백을 추가하거나 기술 정의를 조정할 수 있습니다.

TL;DR

• Hermes는 기존의 성숙한 에이전트 기술 파일을 마이그레이션 없이도 실행할 수 있습니다.
• Hermes를 런타임으로 사용하면 워크플로우를 유지하면서 오케스트레이션 기능(크론, MCP, soul.md)을 얻을 수 있습니다.
• LLM 간 이식성은 아직 해결되지 않은 문제이며, 툴‑콜 준수는 모델마다 다릅니다.
• Hermes를 최대한 활용하려면 네이티브 형식(soul.md, 모델‑특정 검증)으로 마이그레이션하고 이를 페르소나의 정규 런타임으로 다루세요.

솔직한 평결

6개월 동안 진화된 Claude 스킬이 Hermes의 기본 설정을 능가합니다 — 제가 소프트웨어를 구체적으로 구축하는 방식에서는 말이죠.

하지만 그 비교는 잘못되었습니다. 올바른 질문은: Hermes가 이미 가지고 있는 것 외에 뭔가를 제공하나요?

저에게는 두 가지가 중요합니다:

1. LLM 이식성 – 로컬 모델이나 다른 제공자를 사용해 스킬을 재구축 없이 실행할 수 있는 능력.

   • 품질 요구가 엄격한 프로덕션 작업 → Claude의 신뢰성을 원합니다.
   • 실험, 로컬 자동화, 비용에 민감한 빌드 → Hermes는 재작성 비용 없이 옵션을 실현시켜 줍니다.

2. 인프라 계층 – Cron, MCP 관리, soul.md 영속성. 하나의 프로젝트를 위해 만들지는 않겠지만, 한 번 존재하면 즉시 유용합니다.

시작하는 개발자에게 조언한다면: 먼저 기존 워크플로를 가져오세요. Hermes를 네이티브하게 배우기 전까지 아무것도 구축하지 마세요. 현재 스킬을 실행해 보고, 모델 경계에서 무엇이 유지되고 무엇이 깨지는지 확인한 뒤, 그 신호를 활용해 무엇을 제대로 마이그레이션할지 결정하세요. 이식성이 핵심이며, 처음부터 새로 시작해서는 얻을 수 없습니다.

이 워크플로가 만든 프로젝트

• Web: — 로그인 없이, 지금 바로 사용해 보세요
• MCP: https://brew-guide-production.up.railway.app/mcp
• GitHub: