▶ 이전 글: 하네스의 구조와 설계 | 7가지 구성요소부터 스펙 주도 개발(SDD)까지
앞선 편에서는 에이전트가 무너지는 네 가지 패턴과 하네스를 이루는 일곱 가지 구성요소, 이너 하네스와 아우터 하네스를 살펴보았습니다. 그렇다면 하네스를 통째로 제품으로 만들어둔 도구는 없을까요? 누스 리서치(Nous Research)가 공개한 오픈소스 에이전트 프레임워크, 헤르메스 에이전트(Hermes Agent)가 그 사례입니다. 모델을 둘러싼 다섯 개의 층 구조와 경험에서 규칙을 스스로 만들어내는 자기개선 루프를 이해하고, 클로드 코드(Claude Code)와 어떤 점이 다른지 비교해보겠습니다.
하네스 엔지니어링은 AI 에이전트를 안정적으로 운영하기 위한 방법론입니다. 이 방법론을 구현한 도구로는 클로드 코드, 커서(Cursor), 오픈클로(OpenClaw), 헤르메스 에이전트가 있으며, 네 도구는 모두 같은 층위의 구현체입니다. 어느 하나가 다른 것의 상위 개념이 아니라, 같은 방법론을 서로 다른 철학과 방식으로 구현한 것입니다. 따라서 비교 대상은 '헤르메스 vs 하네스'가 아니라 '헤르메스 vs 클로드 코드'가 됩니다.

헤르메스 에이전트는 AI 연구 조직 누스 리서치(Nous Research)가 공개한 오픈소스 에이전트 프레임워크입니다. 표어는 “함께 성장하는 에이전트(The agent that grows with you)”로, 한 문장으로 요약하면 모델은 자유롭게 교체할 수 있도록 열어두되, 모델을 둘러싼 환경인 하네스는 제품 안에 단단히 구축해둔 도구입니다. 주요 특징은 다음 세 가지입니다.
하네스 엔지니어링 관점에서 보면 헤르메스는 매우 두꺼운 이너 하네스를 기본 제공하는 제품입니다. 시스템 프롬프트 구조, 도구 연결 방식, 메모리 관리, 검증 절차가 이미 제품에 내장되어 있습니다. 여기에 자기개선 루프까지 포함되어 있어, 메타 하네스(Meta Harness)의 일부 기능도 제품 수준에서 미리 구현해두었습니다. 따라서 사용자는 환경을 처음부터 설계하는 대신, 자신의 업무 방식과 규칙을 담은 아우터 하네스를 얹는 데 집중할 수 있습니다.
누스 리서치는 헤르메스의 설계 철학을 하네스 엔지니어링으로 설명합니다. 더 똑똑한 모델을 만드는 데만 집중하기보다, 모델이 안정적으로 작동하고 경험을 바탕으로 지속적으로 개선될 수 있도록 실행 환경을 설계하는 것이 핵심입니다. 이 철학은 모델을 중심에 두고 다섯 개의 계층이 감싸는 구조로 구현되어 있으며, 각 계층은 하네스의 구성요소와 다음과 같이 대응합니다.
| 헤르메스의 층 | 역할 | 대응하는 하네스 구성요소 |
| 지시(Instruction) | 역할·작업·출력 형식 정의 | 시스템 프롬프트 |
| 제약(Constraint) | 위험 행동 사전 차단 | 훅(가드레일) |
| 피드백(Feedback) | 결과 검증·재시도 | 훅(피드백 루프) |
| 메모리(Memory) | 세션·장기 상태 유지 | 메모리 |
| 오케스트레이션(Orchestration) | 작업 분할·도구·다른 에이전트 호출 | 서브 에이전트·도구/MCP |
"이 폴더에 있는 영수증 이미지를 정리해줘"라는 요청 하나로 다섯 층의 동작 흐름을 살펴볼 수 있습니다. 가장 먼저 지시 계층이 에이전트의 역할과 목표를 정의하고, 작업을 어떤 순서와 기준으로 수행할지 결정합니다. 다음으로 제약 계층이 '파일은 삭제하지 말고 이동만 허용한다' 같은 규칙으로 경계를 벗어나는 행동을 실행 전에 차단합니다. 작업이 완료되면 피드백 계층이 결과를 검증하고, 오류가 발견되면 다시 시도하도록 합니다.
이 계층은 '작업이 끝났다고 말하는 것'과 '실제로 올바르게 끝난 것'을 구분하는 최종 점검 단계입니다. 이 과정에서 메모리 계층은 '영수증은 receipts 폴더에 저장한다' 같은 이전 규칙과 작업 상태를 유지하고, 오케스트레이션 계층은 작업 분해와 도구 호출, 다른 에이전트로의 위임을 조율합니다.

사용자는 이 기본 구조 위에 '우리 회사 영수증은 부서별로 분류한다', '계약서 폴더는 절대 수정하지 않는다', '분석 결과는 항상 엑셀 파일로 저장한다'와 같은 자신의 규칙을 얹습니다. 이것이 아우터 하네스입니다. 같은 헤르메스를 사용하더라도 결과의 차이가 발생하는 이유는 모델이 아니라, 아우터 하네스를 얼마나 잘 설계하고 꾸준히 쌓아왔는지에 있습니다.
헤르메스를 다른 도구와 가장 뚜렷하게 구분 짓는 요소는 자기개선 루프입니다. 작업 하나가 끝날 때마다 다음 다섯 단계가 한 바퀴 돕니다.

예를 들어 사용자가 "영수증_3월.jpg는 images가 아니라 receipts 폴더로 옮겨줘"라고 교정했다고 가정해보겠습니다. 헤르메스는 해당 파일만 옮기는 데 그치지 않고, '파일명에 영수증이 포함되면 receipts 폴더로 분류한다'는 규칙을 추출해 하나의 스킬로 저장합니다. 며칠 뒤 '영수증_4월.jpg'가 들어오면 사용자가 별도로 지시하지 않아도 저장해둔 스킬을 활용해 receipts 폴더에 분류합니다.'
이 점에서 자기개선 루프와 메모리의 차이를 알 수 있습니다. 메모리가 과거 정보를 저장해두는 기능이라면, 자기개선 루프는 경험으로부터 규칙을 만들어 재사용하는 기능에 가깝습니다.
단, 자율성이 높아질수록 사람의 감독은 더 중요해집니다. 자기개선 과정에서 만들어진 규칙이 항상 옳은 것은 아니기 때문입니다. 한 번의 예외를 일반 규칙으로 오해하거나, 잘못된 패턴을 학습해 의도와 다른 행동을 할 수도 있습니다. 따라서 헤르메스를 사용할 때도 어떤 규칙이 새로 만들어졌는지 주기적으로 확인하고, 의도와 맞지 않는 것은 수정하거나 제거해야 합니다.
헤르메스와 클로드 코드는 모두 모델을 둘러싼 실행 환경을 갖춘 '완성된 하네스'입니다. 따라서 어느 도구가 더 우수한지를 가리기보다 각 도구의 성격과 적합한 용도를 살펴보는 것이 중요합니다. 두 도구의 차이는 다음과 같이 정리할 수 있습니다.
| 구분 | 클로드 코드 | 헤르메스 에이전트 |
| 만든 곳 | 앤트로픽의 공식 도구. 지원과 업데이트가 비교적 일관됨 | 누스 리서치의 오픈소스·MIT 라이선스 프로젝트. 자유도가 높지만 관리 책임은 사용자에게 있음 |
| 기반 모델 | 클로드 중심 | 여러 모델 선택 가능 |
| 주 인터페이스 | 터미널 중심(코딩 작업 특화) | 터미널·메신저·웹 대시보드 지원. 연결할 채널은 사용자가 직접 설정 |
| 실행 형태 | 사용자가 요청할 때 실행되는 세션 중심. 작업을 단계별로 확인하기에 유리 | 게이트웨이·크론잡 등을 이용한 상시 실행 가능. 감독 장치가 더 중요 |
| 자기개선 | 메모리·서브 에이전트 등을 활용해 비교적 예측 가능한 방식으로 동작 | 자기개선 루프가 핵심 특징. 새로 학습한 규칙을 주기적으로 점검해야 함 |
| 비용 구조 | 구독 또는 API 비용을 사용하므로 비교적 단순 | 작업에 따라 모델을 선택해 비용 절감 가능. 로컬 모델은 품질과 PC 사양을 함께 고려 |
| 강점 | 개발·정밀 작업 | 상시 실행, 개인화, 모델 전환, 다른 에이전트와의 작업 조율 |
두 도구의 선택 기준은 다음과 같이 정리할 수 있습니다. 코드 작성과 수정, 프로젝트 관리처럼 정밀한 개발 작업이 중심이며 작업 과정을 직접 확인하며 진행하고 싶다면 클로드 코드가 잘 맞습니다. 여러 모델을 조합해 비용과 성능을 최적화하고 싶거나, 장기간 사용하면서 점차 개인화되는 에이전트를 원한다면 헤르메스가 잘 맞습니다. 비유하자면 둘 다 완성도 높은 차량이지만 성격이 다릅니다. 클로드 코드는 정밀한 주행 성능에 초점을 맞춘 차량에 가깝고, 헤르메스는 다양한 연료를 사용할 수 있고 운전자의 습관에 적응하는 차량에 가깝습니다.
다만 두 도구 가운데 하나만 선택해야 하는 것은 아닙니다. 헤르메스와 클로드 코드는 경쟁 관계라기보다 서로의 강점을 보완하는 관계에 가깝습니다. 예를 들어 헤르메스가 전체 작업을 조율하는 오케스트레이터 역할을 맡고, 코드 작성이나 정밀한 파일 처리 같은 세부 작업은 클로드 코드에 맡길 수 있습니다. 반대로 클로드 코드 환경에 헤르메스의 자기개선 방식이나 자동화 아이디어를 적용할 수도 있습니다.
사용자가 자리를 비운 동안에도 에이전트가 계속 작동해야 하거나, 작업에 따라 모델을 바꿔 비용과 성능을 조절하고 싶다면 헤르메스가 더 적합합니다. 다운로드 폴더를 주기적으로 정리하거나 특정 웹페이지의 변경 사항을 계속 확인하는 작업이 헤르메스의 강점이 잘 드러나는 예입니다.
그러나 두 도구의 선택보다 더 중요한 사실이 있습니다. 한국어로 작성한 스펙(specs/*.md)은 사용하는 도구가 바뀌어도 그대로 활용할 수 있다는 점입니다. 시스템 프롬프트, 가드레일 규칙, 결과 검증 기준은 특정 도구에만 속한 기능이 아니라 사용자의 업무 방식과 의도를 담은 자산입니다. 따라서 클로드 코드에서 다듬은 스펙을 헤르메스로 가져오거나, 헤르메스를 운영하면서 얻은 경험을 클로드 코드의 스펙에 반영할 수 있습니다. 도구는 바뀔 수 있지만, 잘 설계된 하네스는 새로운 도구로 함께 옮겨갈 수 있습니다.

위 컨텐츠는 서지영 저자의
『하네스 엔지니어링, 클로드 코드로 내 일을 대신하는 AI 에이전트 만들기』를 재구성하여 작성되었습니다.
댓글