🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

30명 개발사의 Hermes 실전 운영법은 설치 자체보다 프로필·스킬·채널·업무 데이터 연결을 조직 운영 규칙으로 만드는 데 핵심이 있다.

📌 핵심 요점

1. Hermes 도입의 출발점은 단순 자동화가 아니라 영업, CRM, 백오피스, Slack 협업을 묶어 전사 생산성을 높이는 운영 체계 구축이었다.
2. 데스크톱 앱은 비개발자의 진입 장벽을 낮추지만, 프로필 표시 오류나 채널 설정 문제처럼 운영용으로는 아직 주의가 필요한 불안정성이 언급됐다.
3. 실제 운영 품질은 모델 선택, 프로필 구조, 스킬 위치, 숨김 폴더 이해, CLI와 대시보드의 역할 구분 같은 기초 설정 이해도에 크게 좌우된다.
4. Slack 연동에서는 앱 토큰, 봇 토큰, 채널 ID, 유저 ID, 멘션 규칙, 홈 채널 설정이 중요하며, 명시적 호출 규칙이 없으면 불필요한 응답과 토큰 사용이 늘어날 수 있다.
5. 똑똑한개발자의 사례는 Hermes를 만능 에이전트로 쓰기보다, 톡빌더·CRM·프로젝트 현황·인력 배정 데이터와 연결해 반복적이고 패턴화된 업무를 위임하는 방식에 가깝다.

🧩 배경과 문제 정의

• 국내에서 Hermes Agent를 단순 설치나 스킬 제작을 넘어 실제 회사 업무에 깊게 적용한 공개 사례는 드물다. 따라서 온보딩, 작업 방식, 개발, 소통까지 포함한 운영 관점의 사례가 필요하다.
• 똑똑한개발자는 엔터프라이즈 AI 프로덕트와 AX 자동화 납품을 수행하며, 대기업 신사업·AX 팀과 협업하는 과정에서 내부 생산성 개선과 업무 표준화의 필요성을 크게 느꼈다.
• 초기에는 영업 최적화와 CRM 연동 에이전트에서 출발했지만, 전사 도입을 위해 백오피스 시스템과 Hermes Agent 인터페이스를 함께 구축하는 방향으로 확장됐다.
• Hermes는 설치만으로 완성되는 도구가 아니라, 프로필, 스킬, 모델 선택, 폴더 구조, 채널 연동, 업무 데이터 연결 방식이 운영 품질을 좌우하는 업무 인프라에 가깝다.
• 이 영상의 핵심 문제의식은 “AI 에이전트를 회사에 어떻게 배치하고, 어디까지 맡기며, 어떤 내부 시스템과 연결해야 실제 협업 도구가 되는가”에 있다.

🕒 시간순 섹션별 상세정리

1. Hermes 실전 사례와 똑똑한개발자의 도입 맥락

• 국내에는 Hermes를 설치하거나 스킬을 만드는 수준을 넘어, 실제 회사 업무에 적용한 공개 사례가 거의 없으며, 개발 에이전시에서 개발자들이 어떻게 온보딩·작업·개발·소통에 활용하는지가 핵심 공백으로 남아 있다 [00:30]
• 똑똑한개발자는 엔터프라이즈급 AI 프로덕트와 AX 자동화 납품을 주력으로 하며, 대기업 신사업·AX 팀과 협업하는 업무 구조 속에서 내부 시스템 역시 AX로 생산성을 높이는 시도를 이어왔다 [01:19]

2. Mac 기준 설치와 데스크톱 앱의 장단점

• Hermes는 GPT Codex 기반으로 세팅되며, 설치는 Codex 설치와 Hermes 설정을 단계적으로 진행하는 흐름으로 압축된다 [02:20]
• 데스크톱 앱은 최근 제공되기 시작했지만 아직 버그가 많아 운영용으로는 부담이 있고, 대신 비개발자가 환경 설정에 접근하는 진입 장벽을 낮춘다는 장점이 있다 [02:39]

3. 터미널 설치, 운영 자유도, 초기 모델 설정

• 기존처럼 터미널로 설치하면 장기 운영에서 세부 튜닝과 자유도 확보가 가능하고, Mac뿐 아니라 Windows·Linux·가상 머신 환경으로도 확장해 적용할 수 있다 [03:29]
• Mac 기준 학습은 AI 작업을 위해 Mac으로 넘어오는 사용자층이 많다는 현실적 이유와 맞물리며, 설치 후 API 설정이 끝나기 전에 기본 설치가 먼저 완료되는 흐름도 나타난다 [04:01]

4. Codex 선택 이유와 모델 버전별 운영 리스크

• Claude·Anthropic·Gemini 계열을 같은 방식으로 쓰면 계정 밴 리스크가 커질 수 있고, OpenAI 계열 에이전트 모델은 성능도 좋은 편이라 Codex 기반 선택의 실무적 근거가 된다 [04:53]
• 실제 운영 중 Claude 사용 계정이 정지된 사례가 있었고, 영업 에이전트 계정도 Codex로 변경했지만 결과 품질은 비슷하게 유지된 것으로 보인다 [05:17]

5. 숨김 폴더, 프로필 구조, 스킬 위치를 이해해야 하는 이유

• 데스크톱 앱의 메뉴와 폴더 접근 기능은 일부 숨겨져 있어 처음 사용하는 사람은 Chrome이나 폴더 조회 위치를 찾기 어렵고, 실제 설치 코드와 파일 구조를 직접 확인해야 이해가 빨라진다 [06:29]
• Mac에서는 사용자 메인 폴더에서 Command+Shift+.로 숨김 폴더를 표시하면 .hermes 폴더를 확인할 수 있고, 설치된 값과 파일을 보며 Hermes의 동작 원리를 더 빠르게 익힐 수 있다 [07:06]

6. 대시보드와 슈퍼셀의 역할 분리

• Hermes 대시보드는 설치 후 바로 열 수 있으며, 작업 지시보다는 설정과 운영 상태 확인에 자주 쓰이는 화면이 된다 [13:04]
• 대시보드에서는 일을 시키고 조회하는 흐름이 중심이고, 디버깅은 슈퍼셀에서 Cloud나 Codex를 호출해 수정·정리 작업을 맡기는 방식으로 나뉜다 [13:16]

7. 스킬·칸반·오케스트레이션의 자동화 한계

• 스킬은 예약된 시스템 안에서 자동 실행될 작업 단위로 쓰이고, 칸반 플러그인은 에이전트 업무와 예약 작업을 보드 형태의 태스크로 관리한다 [14:00]
• 칸반은 사람이 태스크를 만들거나 MCP 같은 경로로 데이터를 가져와 예약을 설정하는 방식에 가깝고, 에이전트가 모든 업무를 스스로 보드에 채우는 구조는 아니다 [14:18]

8. 세션 검색·게이트웨이·외부 접속 구조

• 자동 압축, 과거 대화 세션 검색, 스킬 탐색 기능을 이해하면 Hermes가 명령 이후 내부적으로 어떤 절차로 움직이는지 파악하기 쉬워진다 [15:57]
• 게이트웨이는 로컬뿐 아니라 서버에 올린 환경을 URL로 세션에 연결해, 외부 환경에서도 바로 채팅할 수 있게 해준다 [16:18]

9. 데스크톱 채널 설정과 Slack 연동 준비

• 다음 단계는 채널 연동 설정이며, 예전처럼 코드로 설정하지 않아도 데스크톱에서는 토큰 입력만으로 훨씬 간단히 연결할 수 있다 [17:08]
• 프로필별로 채널을 따로 설정하려 할 때 디자이너 프로필의 설정 화면이 메인으로 되돌아가는 버그가 있어, 프로필 단위 운영에는 주의가 필요하다 [17:25]

10. Slack 앱 생성과 매니페스트 기반 설정

• 채널 생성 후에는 봇 설정이 필요하며, 데스크톱의 외부 링크를 통해 api.slack.com으로 이동해 Slack 앱을 만들 수 있다 [18:59]
• 앱은 처음부터 생성하는 방식으로 시작하고, 워크스페이스 지정 뒤 매니페스트 설정을 사용하면 수동 입력 시간을 줄일 수 있다 [19:21]

11. 소켓 모드, 토큰 입력, 자연어 검증 흐름

• 설정을 마친 뒤 앱을 설치하려면 소켓 모드를 켜야 하며, 소켓 통신은 채팅처럼 양방향 실시간 통신이 필요한 구조에 적합하다 [21:30]
• 소켓 모드를 활성화하면 앱 토큰이 생성되고, 이 값을 복사해 Hermes 데스크톱의 Slack 앱 토큰 입력란에 붙여 넣는다 [21:55]

12. 문서 확인과 멘션 규칙이 운영 비용을 좌우한다

• 운영 기록과 응답을 읽는 과정에서 놓친 부분을 다시 확인하고 학습할 수 있어, 팀 안에서도 Hermes 활용 역량이 축적된다 [24:00]
• 정답이 문서에 있어도 도큐먼트를 읽지 않으면 개발자는 같은 시행착오를 반복하고, 초보자는 지름길을 놓쳐 문제 해결 시간이 길어진다 [24:09]

13. 홈 채널·명령어 세팅으로 Slack 봇 흐름을 고정한다

• Hermes 봇의 메인 채널이 자동으로 잡히는 경우와 별도 설정이 필요한 경우가 있으며, 홈 채널이 없으면 발화할 때마다 안내가 반복된다 [25:18]
• 홈 채널은 채널 안 명령어로 지정하거나, 대화 UI에서 기본 채널을 이곳으로 설정해 달라고 요청해 config 단계에서 고정할 수 있다 [25:44]

14. 스레드와 스킬명 규칙으로 협업 산출물을 표준화한다

• 비개발자 내부 작업에서는 “카드 뉴스 스킬 생성”처럼 세션 이름을 먼저 정하고, 하나의 Slack 스레드 안에 작업을 모아 문맥과 책임 범위를 유지한다 [27:00]
• 협업자가 할 일을 먼저 선언하면 자동 요약된 대화 제목보다 온보딩이 쉬워지고, Hermes와의 대화 목적도 더 분명해진다 [27:21]

15. 톡빌더는 내부 서비스 관점에서 Hermes와 업무 데이터를 연결한다

• AI 네이티브 전환에서는 개인이 시스템을 만드는 방식의 한계가 드러나며, 내부 인원을 위한 서비스도 고객 서비스처럼 사용성이 좋아야 실제 채택이 늘어난다 [29:03]
• TalkBuilder는 Hermes Agent와 연결되어 실무자 현황, 프로젝트 현황, 투입 현황, 이슈 현황을 MCP로 묶고, 에이전트가 이를 업무 스킬처럼 활용하게 한다 [29:33]

16. CRM·대시보드·Slack 질의가 인력 배정 프로세스를 만든다

• 실무자는 프로젝트 내용, 계약 과정의 이슈, 특이사항을 묻고, 투입 검토 대상자는 필요한 인원 수와 여유 리소스를 확인한다 [30:31]
• 프로젝트 현황 화면에는 진행 중인 모든 프로젝트와 투입 인원이 나오고, 배정 가능한 사람과 불가능한 사람이 즉시 구분된다 [30:57]

17. 프로젝트 방 자동화와 이력 기반 추천이 운영 품질을 높인다

• 계약 이후 프로젝트 생성·진행 과정은 Slack 내부방·외부방 자동 생성으로 이어지며, Hermes가 채널 생성 권한까지 맡아 운영 공간을 표준화한다 [32:24]
• 클라이언트 신뢰를 위해 내부 방에만 머물지 않고 외부 방에서도 적극적으로 소통해야 하며, 이 원칙은 HR 평가 기준으로까지 확장된다 [32:55]

18. 회사별 맞춤 시스템과 에이전트 위임 범위

• 회사마다 시스템과 판단 기준이 다르기 때문에 같은 개념을 그대로 납품하기보다, 템플릿을 바탕으로 클라이언트 상황에 맞게 개인화·최적화해야 한다 [36:36]
• Hermes Agent만으로 모든 업무를 처리하기에는 한계가 있으므로, 내부 시스템을 먼저 고도화한 뒤 확률적이고 패턴화된 작업을 에이전트에 연결하는 방식이 리스크를 줄인다 [36:53]

19. 톡빌더 기반 프로젝트 투입·진행 관리

• 프로젝트가 들어오면 톡빌더가 투입 담당자 검토 요청을 자동 발송하고, 의뢰 요약과 프로젝트 바로가기를 함께 제공해 담당자 배정 흐름을 시작한다 [37:39]
• 필요한 인력과 투입 담당자를 선택하면 요청은 처리 완료 상태로 전환되고, 대기 중인 건은 옵션 선택을 통해 후속 처리를 이어간다 [37:57]

20. 내부 거버넌스 구축 시행착오와 전담 제품 인력 투입

• 30명 구성원에게 AI 거버넌스 의견을 각자 요청했지만 두 달 가까이 진척이 거의 없었고, 초기 구조는 대표와 AX 컨설팅 리더가 직접 만들었다 [38:40]
• 기획자 관점으로 만든 첫 버전은 디자이너·개발자 관점의 사용성이 부족해, 팀원들이 실제 업무에서 어떻게 써야 할지 알기 어려운 문제가 생겼다 [39:07]

21. 플러그 기반 CRM·재무 통합과 구독형 도구 판단

• 별도 대시보드보다 자체 서비스인 플러그를 고도화하는 방향을 우선하며, 세금계산서 발행·메일 발송·메일 히스토리·견적서·계약서를 한곳에서 처리한다 [40:14]
• 통장 정보와 입출금, 미납·연체 리마인더, 월 수익, 예정 영업권, 정산·미수금 현황을 CRM·재무 관리 데이터로 통합한다 [40:35]

22. 30명 규모 협업 사례와 대형 조직 도입 질문

• 국내에서 이 정도 규모로 영업 사후 관리와 에이전트 활용을 함께 묶은 조직 사례는 드물며, 30명 규모 운영 사례 자체가 중요한 참고 지점이 된다 [42:17]
• 체계적인 대시보드와 클라이언트 소통이 결합되면 외주·교육·납품 과정에서 공급자와 고객 모두의 만족도를 높일 수 있다 [42:38]

23. 초기 도입팀 조건, 서비스 개발 경험, 구축 비용

• 의사결정 가능한 리더십이 필수이며, 10명 미만의 작은 팀에서 업무를 빠르게 AI에 적용·테스트할 수 있어야 도입 속도가 난다 [44:20]
• AI 거부감이 낮고 클로바 코워크·스킬 같은 기본 개념을 이미 이해한 구성원일수록 설명 비용이 줄어들며, 서비스 개발 경험이 핵심 조건이 된다 [44:45]

🧾 결론

• 이 영상의 핵심은 “Hermes를 어떻게 설치하느냐”보다 “조직 안에서 어떤 업무 흐름에 붙이고, 어떤 규칙으로 운영하느냐”에 있다.
• Hermes 도입은 스킬 몇 개를 만드는 수준에서 끝나지 않고, 프로필 관리, 채널 연동, 예약 작업, 내부 데이터 연결, 사람의 승인 흐름까지 함께 설계해야 안정적으로 굴러간다.
• 특히 30명 규모 조직에서는 Slack 스레드, 스킬명 규칙, 홈 채널, 멘션 규칙처럼 사소해 보이는 운영 표준이 협업 품질과 비용을 크게 좌우한다.
• 에이전트에게 모든 판단을 맡기기보다, 반복성과 기준이 높은 업무는 Hermes에 위임하고 모호한 의사결정은 사람이 확인하는 human-in-the-loop 구조가 현실적인 접근으로 제시됐다.
• 검증 필요: Claude 계정 정지 사례, 모델별 안정성 차이, AX 구축 비용 3억~5억 규모, 데스크톱 앱 버그 수준은 영상 내 발언 기준이므로 실제 도입 전에는 최신 문서와 벤더 정책, 견적 확인이 필요하다.

📈 투자·시사 포인트

• AI 에이전트 도입의 가치는 개별 직원의 생산성 향상보다 CRM, 재무, 프로젝트 관리, 인력 배정 같은 내부 운영 데이터와 연결될 때 더 커질 수 있다.
• 소규모 조직이나 100명 이상 조직 모두 전사 일괄 도입보다 의사결정권이 있고 AI 거부감이 낮은 5~10명 파일럿 팀에서 시작하는 방식이 더 현실적이다.
• Hermes 같은 에이전트 운영은 단순 툴 구매가 아니라 내부 업무 프로세스 재설계에 가까우므로, 서비스 개발 경험자와 PO 성격의 전담 인력이 성패에 중요하다.
• 자체 구축과 구독형 도구 사용 사이에서는 세금계산서, 통장, 카드사, 계약서, 메일 히스토리처럼 외부 API 비용과 유지보수 부담이 큰 영역을 냉정하게 따져야 한다.
• B2B AX 시장에서는 “에이전트 자체”보다 회사별 업무 데이터, 권한 구조, Slack 같은 협업 채널, 대시보드를 묶어 실제 현장에 맞게 커스터마이즈하는 역량이 경쟁력이 될 가능성이 크다.

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

• Hermes 데스크톱 앱의 프로필 표시 오류, 채널 설정 화면 이동 오류, 운영 안정성 문제는 영상 시점의 경험에 기반한 설명이므로, 현재 버전에서도 동일한지 별도 확인이 필요하다.
• Claude·Anthropic·Gemini 계열 사용 시 계정 정지 리스크가 높다는 언급은 실제 운영 사례로 소개되지만, 각 서비스의 최신 정책·사용 조건·자동화 허용 범위와 대조해 검증해야 한다.
• “Codex 기반으로 변경해도 결과 품질이 비슷했다”는 평가는 특정 회사의 영업 에이전트 사례에 대한 관찰이므로, 다른 업무·데이터·스킬 구성에서도 동일하게 적용된다고 단정하기 어렵다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• Hermes 도입 전 공식 문서와 현재 설치 가이드를 먼저 확인하고, 데스크톱 앱과 CLI 중 팀 운영에 맞는 설치 방식을 결정한다.
• .hermes 폴더, 프로필 구조, 글로벌 스킬과 프로필별 스킬 위치를 팀원들이 이해할 수 있도록 내부 온보딩 문서를 만든다.
• Slack 연동 시 앱 토큰, 봇 토큰, 채널 ID, 유저 또는 봇 ID, 소켓 모드, manifest 권한을 체크리스트로 관리한다.
• Hermes가 일반 대화에 끼어들지 않도록 멘션 규칙, 홈 채널, 명령어, 스레드 사용 기준을 정한다.

❓ 열린 질문

• 현재 Hermes 데스크톱 앱의 버그와 한계는 영상 업로드 시점 이후 얼마나 개선됐으며, 운영 환경에서 CLI 대비 어느 정도 신뢰할 수 있는가?
• 조직 내에서 어떤 업무를 스킬, 크론, 칸반, 별도 에이전트, 내부 서비스로 나눠야 가장 유지보수가 쉬운가?
• Slack 연동 시 Hermes가 접근할 수 있는 채널·사용자·업무 데이터의 권한 범위는 어디까지로 제한해야 안전한가?