The Right Way To Build A Hermes Agent (2026 Edition)

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Hermes 에이전트를 제대로 구축하려면 업무를 먼저 정의하고, 맥락·스킬·권한·검증 체계를 갖춘 제품으로 운영하며 신뢰에 따라 자율성을 넓혀야 한다.

📌 핵심 요점

1. 업무 정의가 출발점이다. 발표자는 고객 지원·제품 개발·마케팅을 핵심 업무로 정하고, Agent Smith를 정보와 작업을 배분하는 중심 에이전트로 설계했다.
2. 맥락·스킬·실행 주기가 함께 필요하다. 회사 정보와 도구를 연결하고 반복 업무를 스킬로 정리한 뒤, 정기 실행할 구체적인 일을 부여해야 한다.
3. 권한은 읽기 전용부터 시작한다. 쓰기 권한은 업무 위험도에 따라 부여하고, 브랜치 보호처럼 시스템이 강제하는 제한을 마련해야 한다.
4. 에이전트도 제품처럼 관리한다. Git 변경 관리, 백업, 테스트 환경을 갖추고, 업데이트로 사라질 수 있는 코어 수정 대신 스킬·플러그인·MCP 등으로 확장한다.
5. 사람의 검토를 개선으로 연결한다. 팀이 활용법을 익히고 결과의 오류를 시스템에 반영해야 하며, 자율성은 작은 성공과 신뢰를 쌓으며 확대한다.

🧩 배경과 문제 정의

발표자는 자신의 사업에서 사용하던 Hermes 에이전트를 한 달 동안 다시 구축한 경험을 바탕으로 25가지 교훈을 소개한다. 핵심 문제는 모델과 도구를 연결하는 것만으로는 원하는 업무가 안정적으로 수행되지 않는다는 점이다. 무엇을 맡길지 정의하고, 필요한 정보와 반복 절차를 제공하며, 실행 권한과 변경 관리 체계를 함께 설계해야 한다.

사례의 중심은 Agent Smith라는 이름의 에이전트다. 고객 지원·제품 개발·마케팅 관련 정보와 도구를 연결하고 하위 에이전트에 일을 배분한다. 발표자는 이를 지속적으로 개선해야 할 사업 운영 시스템으로 설명하며, 현재 운영 사례와 향후 자율화 구상을 함께 제시한다.

🕒 시간순 섹션별 상세정리

1. 재구축의 출발점은 맡길 업무 정의

• 발표자는 한 달간 Hermes 에이전트를 다시 구축했으며, 실제 사업에서 얻은 25가지 교훈을 공유하겠다고 보여준다. [00:23]
• 모델이 제안하는 방향에 끌려가지 않으려면 해결할 문제를 먼저 정해야 한다. 자신의 사례에서는 고객 지원·제품 개발·마케팅을 주요 업무로 삼았다. [01:44]

2. 이름과 성격으로 협업 방식 정하기

• Agent Smith라는 이름을 붙여 팀의 공통 접점으로 삼고, 정보 전달과 작업 위임을 맡겼다. 개발 작업에는 Cursor를 실행하는 사례를 든다. [02:34]
• Hermes를 실행 기반으로 사용하며, soul.md를 조정해 대화 성격과 말투를 팀에 맞춘다고 보여준다. [03:22]

3. 회사 맥락과 외부 도구 연결

• 코드베이스, 고객 정보, 웹사이트, 내부·외부 지식베이스를 에이전트가 이용할 수 있게 하되, 접근 범위는 신뢰가 쌓이는 만큼 확대한다. [04:12]
• 도구 연결에는 MCP를 권하며, ChartMogul MCP로 사업의 재무 성과와 SaaS 지표를 조회하는 사례를 보여준다. [04:56]

4. 쓰기 권한에는 강제 가능한 제한 필요

• 민감한 정보 접근은 읽기 전용부터 시작하고, 검증 후에도 명확한 경계를 세운 뒤 쓰기 권한을 부여한다고 보여준다. [05:47]
• GitHub에서 main 브랜치 직접 푸시를 막고 PR을 거치게 하는 규칙을 예로 든다. 기능을 추가할 때마다 사고를 막을 장치도 함께 설계해야 한다고 강조한다. [06:33]

5. 반복 업무를 스킬로 만들고 위험도 구분

• 스킬을 직원에게 주는 표준 업무 절차에 비유한다. 반복 업무를 스킬로 만들되 중복과 과도한 증가를 점검하고, 분기별 검토를 제안한다. [07:36]
• 제품 코드·결제 정보·웹사이트와 복구하기 쉬운 내부 지식베이스를 구분해, 사고의 사업 영향에 따라 권한을 다르게 관리한다. [08:29]

6. 에이전트를 제품으로 운영

• 브랜치 기반 변경 관리, 되돌리기, 백업을 갖추고 에이전트를 제품처럼 개발한다. 자신의 에이전트는 매일 GitHub에 백업한다고 드러낸다. [09:03]
• 테스트 환경에서 검증한 뒤 팀이 사용할 수 있도록 배포하는 절차를 보여준다. [09:20]

7. 업데이트를 고려한 확장과 사전 검증

• 코어 파일을 직접 수정했다가 업데이트로 변경 내용이 사라진 경험을 공유하며, 스킬·플러그인·MCP·페르소나 등으로 사용자화를 유지하라고 권한다. [10:16]
• 새로운 하위 에이전트처럼 큰 변경은 스테이징에서 시험하고, 정상 동작을 확인한 뒤 운영 브랜치에 병합한다. [10:55]

8. 팀의 활용 역량과 대화 맥락 분리

• 자신의 사업에서는 에이전트 도입을 기존 직원의 역량을 확대하는 방향으로 설명한다고 드러낸다. 팀이 업무를 더 잘 수행하는 방법을 함께 익혀야 한다고 강조한다. [12:05]
• 영업·마케팅·개발 등 업무별 하위 에이전트와 Slack 채널을 나누고, 필요한 정보와 업무 절차를 제공하는 일을 신입 직원의 온보딩에 비유한다. [13:25]

9. 정기 업무로 연결을 실제 실행으로 전환

• 맥락과 스킬을 마련한 다음에는 cron이나 예약 작업으로 구체적인 일을 부여해야 한다고 보여준다. [13:43]
• 매주 월요일과 목요일 7시에 Help Scout 티켓을 분석해 공개 도움말의 공백을 찾고 GitHub 이슈를 만든다. 매일 실행하면 알림이 너무 많았다고 덧붙인다. [14:35]

10. 중심 에이전트의 라우팅과 건설적 반론

• 장기적으로 업무와 맥락이 에이전트를 거치게 하되, 실제 실행은 하위 에이전트·루틴·외부 시스템에 배분하는 구조를 지향한다. [15:42]
• soul.md에는 무조건 동의하지 말고, 놓친 점이 있으면 예의 바르고 건설적으로 반론하라는 지침을 넣었다고 보여준다. [16:17]

11. 작업별 대화에서 대시보드로 확장

• 현재는 Slack의 업무별 채널과 작업별 스레드에 맥락을 모으고, 새로운 일은 새 대화로 시작한다. [17:10]
• 앞으로는 칸반 형태의 자체 대시보드에서 에이전트·하위 에이전트·진행 작업을 카드로 관리하려 한다. 이는 향후 인터페이스 구상이다. [17:26]

12. 구축 난도와 자율성의 경계

• 에이전트 구축을 회사 운영 시스템을 만드는 일로 보여준다. 현재 구성은 아직 장애를 겪지 않았지만 업데이트나 모델 변경으로 문제가 생길 가능성과 복구 체계의 필요성을 언급한다. [18:42]
• 업무를 에이전트로 연결하면 부족한 접근 권한·스킬·도구 연결을 발견할 수 있다고 본다. 자율성은 이런 보완 과정을 거치며 얻어야 한다고 드러낸다. [19:34]
• 은행 계좌 접근과 급여 지급은 허용하지 않는다. 지원 문서 공백 탐색과 달리 당장 맡길 의사가 없는 민감 업무가 있음을 분명히 한다. [20:04]

13. 사람의 검토를 시스템 개선으로 연결

• 미래 업무상으로 개발자는 준비된 PR을 검토하고, 마케터는 페이지 초안을 확인하며, 지원 담당자는 에이전트가 해결하지 못한 티켓을 넘겨받는 모습을 제시한다. [21:15]
• 잘못된 결과를 수정하는 데서 끝내지 않고 사람의 피드백으로 시스템을 개선해야 한다고 강조한다. 이 순환 구조는 자신의 팀도 계속 개발 중이라고 드러낸다. [21:53]

14. 불편한 지표를 마주하고 작은 성공 축적

• 에이전트가 버그와 움직이지 않는 마케팅 지표를 지적하면서, 창업자가 익숙해져 외면하던 문제를 다시 보게 된 경험을 공유한다. [22:54]
• 구축에는 수개월의 집중과 많은 시간이 필요하다고 말하며, 쉬운 업무에서 성공을 만든 뒤 범위를 점진적으로 확대하라고 권한다. [23:37]

15. 장기 투자와 직무 변화라는 마무리

• Hermes를 선택한 이유로 개방성·투명성·사용자화 가능성을 들고, 구축을 사업의 미래 성과에 대한 투자로 보라고 드러낸다. [24:18]
• 모든 기업이 도입해 업무량이 5배가 될 것이라는 전망을 제시하며 경쟁 압력을 강조한다. 이는 영상에서 측정으로 입증한 성과가 아니다. [25:04]
• 마지막에는 직원의 역할이 바뀔 것이라고 말하며, 창업자·기업·직원 모두 변화에 적응해야 한다는 메시지로 마무리한다. [25:31]

🧾 결론

• 설치만으로 사업 운영이 완성되지는 않는다. 발표자는 구축과 개선에 상당한 시간과 의도적인 설계가 필요하다고 강조한다.
• 중심 에이전트의 역할은 정보와 업무를 연결하고, 하위 에이전트와 외부 도구에 실행을 맡기는 것이다.
• 자동화 범위는 업무별로 달라야 한다. 발표자는 지원 문서의 빈틈 탐색은 맡기지만 은행 계좌 접근과 급여 지급은 제외한다.
• 장기적인 운영 품질은 검토 결과를 맥락·스킬·절차의 개선으로 되돌리는 체계에 달려 있다. 이 피드백 체계는 발표자도 계속 개발 중이다.

📈 투자·시사 포인트

• 기업의 도입 판단에서는 모델 선택과 함께 정보 연결, 권한 설정, 테스트, 팀 교육에 드는 구축·운영 노력을 고려필요가 있다.
• 영상의 사례는 반복 업무 하나를 정기적으로 수행하게 하는 접근을 보여준다. 지원 티켓에서 문서 공백을 찾는 식의 작은 업무가 초기 적용 지점이 될 수 있다.
• 발표자는 에이전트 구축을 사업의 미래 성과와 존속 가능성에 대한 투자로 본다. 다만 비용, 절감 시간, 수익성 개선을 입증하는 수치는 제시하지 않는다.
• 경쟁사의 업무량이 5배로 늘 것이라는 주장은 발표자의 전망이다. 검증된 생산성 수치로 받아들이기보다, 조직의 업무 방식 변화에 대한 문제 제기로 읽어야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

• 사업 규모와 운영 경험은 발표자의 자기 보고이며, 에이전트 도입 전후의 성과를 비교할 자료는 제공되지 않는다.
• 모든 업무를 에이전트로 연결하는 구조와 아침마다 검토할 결과물이 준비되는 업무 방식은 상당 부분 목표와 전망이다. 현재 구현된 범위와 구분해야 한다.
• 코어 업데이트가 사용자 확장에 미치는 영향과 권한 제한의 실제 강제 방식은 구체적인 버전·설정 수준으로 설명되지 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 고객 지원·개발·마케팅 중 반복 업무 하나를 골라 목적, 필요한 정보, 산출물을 명시한다.
• 연결할 시스템을 목록화하고 읽기·쓰기 권한과 사고 발생 시 영향을 구분한다.
• 쓰기 권한을 열기 전에 브랜치 보호와 PR 절차 등 시스템이 강제하는 제한을 설정한다.
• 반복 업무를 스킬로 만들고 중복·불필요한 스킬을 정기적으로 점검한다.

❓ 열린 질문

• 읽기 전용에서 쓰기 권한으로 전환할 때 신뢰를 판단할 구체적인 기준은 무엇인가?
• 사람의 수정과 피드백을 어떤 절차로 축적해야 같은 오류의 재발을 줄일 수 있는가?
• 업무를 중심 에이전트로 모으는 목표와 민감한 업무를 제외하는 원칙의 경계는 어떻게 정할 것인가?