QSike Tech Notes

AI 에이전트 4종 비교: Hermes Agent·​OpenClaw·​Codex·​Claude Code

Hermes Agent, OpenClaw, ChatGPT Codex, Claude Code를 기능 목록 대신 일하는 자리로 비교합니다. 자동화 절차, 멀티채널 게이트웨이, 개발 실행, 코드베이스 워크플로의 차이를 정리합니다.

읽기 전 안내 (2026년 7월 26일 기준): 이 글은 당시의 공식 문서와 공개 기능을 바탕으로 한 비교입니다. AI 에이전트의 기능·권한 모델·채널 지원·정책은 빠르게 추가·변경될 수 있고, 네 도구는 실제로 겹치는 기능도 많습니다. 본문의 네 사례는 실측 사용기가 아닌 가상 예시이며, 기존의 경험담 표현을 바로잡았습니다. 따라서 아래의 선택 기준과 가상 사례는 정답이나 우열표가 아니라, 각 도구가 놓인 업무 환경을 이해하기 위한 예시입니다. 적합한 선택은 개인의 작업 방식, 팀 규칙, 보안 요구, 이미 쓰는 도구에 따라 달라지므로 도입 전 최신 공식 문서를 확인하고 작은 권한 범위부터 직접 검증하는 것을 권합니다.

네 가지 AI 에이전트 업무 환경이 메신저 자동화, 멀티채널 게이트웨이, 개발 실행, 코드베이스 워크플로로 연결되는 모습

AI 에이전트를 고를 때 가장 흔한 실수는 기능 목록만 비교하는 것입니다. 파일을 읽고, 명령을 실행하고, MCP를 연결하고, 하위 에이전트를 쓸 수 있다는 점은 이제 여러 도구의 공통 기능이 됐습니다. 실제 차이는 에이전트가 어디에서 일하고, 어떤 작업을 오래 맡도록 설계됐는가에 있습니다.

Hermes Agent, OpenClaw, ChatGPT Codex, Claude Code는 모두 코드를 읽고 도구를 쓰며 여러 작업을 처리할 수 있습니다. 하지만 중심이 다릅니다. Hermes Agent는 업무 절차를 축적하며 실행하는 자동화 동료에 가깝고, OpenClaw는 여러 메신저와 기기를 연결하는 개인 AI 게이트웨이에 가깝습니다. ChatGPT Codex와 Claude Code는 모두 개발자의 코딩 작업을 강하게 겨냥하지만, Codex는 로컬·클라우드 작업을 오가는 개발 실행 환경에, Claude Code는 코드베이스 문맥과 확장 계층을 갖춘 개발 에이전트에 무게를 둡니다.

한 줄 요약: Hermes Agent는 절차를 배우는 자동화 동료, OpenClaw는 멀티채널 개인 AI 게이트웨이, ChatGPT Codex와 Claude Code는 각각 개발 실행·클라우드 병렬 작업, 코드베이스 문맥과 확장형 개발 흐름에 중심을 둡니다.

Hermes Agent: 일을 하며 절차를 쌓는 자동화 동료

Hermes Agent의 특징은 스킬과 장기 메모리입니다. 잘 수행한 업무의 확인 순서, 형식, 실패 지점을 스킬로 남기고 다음 작업에서 다시 불러옵니다. 모델 제공자를 바꾸거나, 터미널·Docker·SSH·MCP 서버를 조합하고, cron으로 정기 작업을 돌리는 방식도 지원합니다.

그래서 매일 리서치를 모으고, 데이터 검증 뒤 보고서를 작성하고, 정해진 채널에 배포하는 식의 반복 업무에 잘 맞습니다. 단순히 코드를 한 번 만드는 것보다, 팀이나 개인의 업무 방식이 시간이 갈수록 누적되는 환경에서 장점이 드러납니다.

가상 예시: 정기 리서치 보고 절차를 정리한다

참고: 다음은 업무 흐름을 설명하기 위한 가상 예시입니다. 뉴스 수와 실행 시간은 설정 예시이며, 실제 운영 기록이나 시간 절감 실측값이 아닙니다.

매일 아침 7시에 뉴스 20개를 수집하고 핵심 5개를 추려 보고하는 업무를 가정해 보겠습니다. 담당자는 수집 일정, 사용할 출처, 요약 형식, 게시 전 검토 단계를 작업 절차로 정리합니다.

결과에 오류가 있으면 담당자가 출처와 표현을 확인하고, 재사용할 수 있는 교정 기준을 스킬에 반영합니다. 다음 실행에서 그 기준이 적용되는지도 확인해야 합니다. 일정 기간 사용하면 교정이 필요 없어지거나 특정 시간이 절약된다고 가정하지 않습니다.

이 예시의 요점은 반복 절차와 검토 기준을 남기는 것입니다. 실제 효과는 수집 성공률, 사실 오류, 사람의 검토 시간 등을 같은 조건에서 기록해 판단할 수 있습니다.

OpenClaw: 채널과 기기를 연결하는 개인 AI 게이트웨이

OpenClaw는 self-hosted Gateway를 중심에 둡니다. 디스코드·텔레그램·왓츠앱·시그널·iMessage·슬랙 같은 채널 플러그인과 웹 Control UI, iOS·Android 노드를 한곳에 연결합니다. 에이전트·워크스페이스·발신자 단위로 세션을 나눌 수 있어, 개인·가족·프로젝트용 대화를 구분하는 데도 적합합니다.

핵심은 어디에서나 같은 비서에게 말을 거는 경험입니다. 휴대폰에서 사진이나 음성을 보내고, 이동 중 메신저에서 작업을 이어 가고 싶다면 OpenClaw의 게이트웨이 설계가 자연스럽습니다. 대신 채널이 늘수록 페어링, 접근 허용 목록, 원격 접속, 토큰 보호를 운영의 첫 과제로 삼아야 합니다.

가상 예시: 메신저별 업무 접점을 연결한다

참고: 다음은 가상 환경의 설계 예시이며, 운영자의 개인 사용 이력이나 여러 채널 사이의 자동 기억 공유를 입증하는 사례가 아닙니다.

업무 요청은 텔레그램, 가족 대화는 iMessage, 프로젝트 논의는 슬랙으로 받는 사용자를 가정해 보겠습니다. 여러 접점을 연결하더라도 각 채널의 세션과 데이터 접근 범위를 먼저 정해야 합니다.

프로젝트 문서를 다른 채널에서 이어 쓰려면 해당 사용자와 채널에 접근 권한이 있는지 확인합니다. 가족 대화와 업무 파일은 별도로 관리하고, 공유가 필요한 자료만 명시적으로 연결하는 구조를 검토할 수 있습니다.

연결 가능한 채널과 세션 간 문맥 공유 방식은 설치 버전과 설정에 따라 확인해야 합니다. 채널을 연결했다는 사실만으로 모든 대화와 파일을 서로 조회할 수 있는 것은 아닙니다.

스마트폰·메신저 채널이 접근 제어를 거쳐 하나의 AI 게이트웨이로 연결되는 구조

ChatGPT Codex: 로컬 코드와 클라우드 작업을 잇는 개발 실행 환경

ChatGPT Codex는 터미널의 Codex CLI, IDE 확장, 데스크톱·웹, Codex cloud를 함께 제공합니다. CLI는 로컬 저장소를 검사하고 파일을 고치고 명령을 실행하며, codex exec로 반복 작업과 CI 흐름에 넣을 수 있습니다. 클라우드에서는 작업마다 격리된 환경을 두고 여러 작업을 병렬로 실행한 뒤, 결과 요약과 diff를 검토하거나 풀 리퀘스트로 이어 갈 수 있습니다.

따라서 개발자가 ‘지금 이 저장소에서 수정·테스트·리뷰를 끝내고 싶다’거나, 장시간 작업을 클라우드에 넘겨 놓고 나중에 결과를 검토하고 싶을 때 강점이 있습니다. GitHub·Linear·Slack에서 작업을 시작할 수 있다는 점도 소프트웨어 개발 프로세스와 잘 맞습니다.

가상 예시: 세 가지 코드 검토를 나누어 실행한다

참고: 작업 3건은 설명용 가정입니다. 반나절 또는 점심 전 완료와 같은 실제 처리 시간이나 생산성 향상 측정 결과를 제시하는 사례가 아닙니다.

인증 로직 수정, API 응답 형식 변경, 테스트 보완이라는 세 작업을 검토해야 하는 개발팀을 가정해 보겠습니다. 팀은 작업별 코드와 테스트 환경을 준비하고, 격리된 실행 결과를 각각 검토하는 흐름을 구성합니다.

담당 개발자는 요약뿐 아니라 실제 변경 내용과 테스트 결과를 확인합니다. 작업 사이에 의존성이 있으면 통합 후 다시 검증해야 합니다. 병렬 실행이 가능한 범위와 실제 소요 시간은 작업 크기, 실행 환경, 사람의 검토 부담에 따라 달라집니다.

이 예시는 실행과 검토의 역할을 나누는 방법을 설명합니다. 자동 실행의 성공을 코드의 정확성이나 배포 승인으로 간주하지 않습니다.

로컬 코드 저장소와 격리된 클라우드 작업 공간, 테스트와 권한 검토가 연결된 개발 에이전트 워크플로

Claude Code: 코드베이스 문맥을 확장하는 개발 에이전트

Claude Code는 코드베이스를 읽고, 파일을 편집하고, 명령을 실행하는 코딩 에이전트입니다. 터미널, IDE, 데스크톱 앱, 브라우저에서 사용할 수 있습니다. 특히 CLAUDE.md로 프로젝트 규칙을 매 세션에 불러오고, Skills·MCP·hooks·subagents·agent teams를 조합해 개발 환경을 확장하는 방식이 두드러집니다.

대형 코드베이스에서 팀 규칙, 배포 절차, 린트와 테스트, 외부 서비스 연결을 일관되게 적용하고 싶을 때 유용합니다. 예를 들어 파일 편집 뒤 항상 검사 스크립트를 실행하거나, 보안·성능·테스트 관점의 여러 검토자를 병렬로 두는 식의 개발 흐름을 설계할 수 있습니다.

가상 예시: 새 팀원이 참고할 개발 규칙을 명시한다

참고: 다음은 가상 팀의 온보딩 설계 예시입니다. 첫날 준수나 첫 주 성과, 온보딩 기간 단축을 측정한 실제 사례가 아닙니다.

API 파일 위치, 테스트 방식, 배포 전 확인 절차가 있는 팀을 가정해 보겠습니다. 팀은 프로젝트 규칙을 CLAUDE.md에 정리하고, 파일 변경 후 검사할 항목을 hooks로 연결합니다.

검사 도구가 탐지할 수 있는 위반과 사람이 판단할 항목을 구분해야 합니다. 규칙 문서를 읽거나 검사를 실행했다는 사실만으로 코드가 자동으로 교정되거나 모든 팀 규칙을 준수하는 것은 아닙니다.

새 팀원의 결과물은 기존 리뷰 기준으로 확인하고, 반복되는 누락이 있으면 문서와 검사를 보완합니다. 실제 온보딩 효과는 리뷰 수정 횟수와 독립적으로 작업을 마치는 데 걸린 시간 등의 기록으로 평가할 수 있습니다.

한눈에 보는 선택 기준

도구설계 중심잘 맞는 상황먼저 점검할 것
Hermes Agent업무 실행, 스킬·메모리 축적, 멀티채널 자동화정기 리서치, 서버 운영, 반복 보고·배포, 개인화된 작업 절차실행 권한, 메모리 기록 기준, 스케줄과 비밀정보 관리
OpenClaw멀티채널·모바일 개인 AI Gateway여러 메신저와 기기에서 하나의 AI 비서를 지속 사용채널 페어링, 접근 허용 목록, 원격 접속 보안
ChatGPT Codex로컬 저장소·IDE·클라우드를 잇는 개발 실행코드 수정·테스트·리뷰, CI 자동화, 병렬 클라우드 작업권한 모드, 클라우드 환경 설정, 저장소·통합 연결 범위
Claude Code코드베이스 문맥과 확장 가능한 개발 워크플로프로젝트 규칙이 많은 개발, 훅·MCP·서브에이전트 기반 개발CLAUDE.md 품질, 권한 모드, 플러그인·훅의 검증

표는 우열표가 아닙니다. Claude Code와 Codex에도 스킬·MCP·하위 에이전트·자동화 기능이 있고, Hermes Agent와 OpenClaw도 코딩 작업을 할 수 있습니다. 다만 하루 종일 어떤 화면과 어떤 문맥에서 AI를 쓰는지가 선택을 가릅니다.

운영 관점 비교: 권한·데이터·보안

운영 영역Hermes AgentOpenClawChatGPT CodexClaude Code
실행 권한 모델도구별 권한, 터미널·파일·네트워크 분리채널·발신자·워크스페이스별 세션 라우팅권한 모드(읽기 전용·자동·풀), 클라우드 격리권한 모드, hooks로 실행 전·후 검증
데이터 흐름로컬 파일·메모리·스킬, 모델 제공자 선택 가능self-hosted Gateway, 채널별 데이터 분리로컬 저장소 + 클라우드 격리 환경로컬 코드베이스, MCP로 외부 서비스 연결
비밀정보 관리환경 변수·설정 파일, cron 작업별 분리페어링 토큰·접근 허용 목록·원격 접속 보안저장소·통합 연결 범위 설정CLAUDE.md에 비밀정보 포함 금지, MCP 토큰 관리
장기 축적스킬·메모리로 업무 절차 누적세션·워크스페이스별 대화 이력클라우드 작업 이력·diff·PRCLAUDE.md·Skills로 팀 규칙·흐름 누적
운영 리스크권한 과다 부여 시 자동 실행 사고채널 증가 시 접근 통제 복잡도 상승클라우드 환경 설정 오류 시 비용·보안 리스크hooks·플러그인 검증 부족 시 코드베이스 오염

이 표에서 보듯 네 도구 모두 “권한을 어떻게 설계하는가”가 운영의 첫 과제입니다. 차이가 있다면, Hermes Agent는 업무 절차의 누적, OpenClaw는 채널 접근 통제, Codex는 클라우드 격리와 권한 모드, Claude Code는 코드베이스 규칙과 hooks 검증에 운영의 무게중심이 있다는 점입니다.

이렇게 고르면 된다

  • 메신저에서 개인 업무와 서버 자동화를 이어 가고, 반복 절차를 쌓고 싶다면 Hermes Agent를 먼저 봅니다.
  • 휴대폰과 여러 채팅 앱을 하나의 개인 AI 접점으로 묶고 싶다면 OpenClaw가 자연스럽습니다.
  • 현재 저장소에서 구현·테스트·리뷰를 빠르게 반복하고, 필요하면 클라우드 병렬 작업까지 쓰고 싶다면 ChatGPT Codex가 맞습니다.
  • 복잡한 코드베이스 규칙과 팀 개발 흐름을 CLAUDE.md, hooks, MCP, agent teams로 구조화하고 싶다면 Claude Code를 검토할 만합니다.

내게 맞는 도구 고르기: 체크포인트

접점과 화면

  • 나는 하루 종일 어디서 AI를 쓰는가? (메신저 / 터미널 / IDE / 브라우저 / 휴대폰)
  • 여러 채널·기기에서 같은 비서를 이어 쓰고 싶은가?

작업의 성격

  • 매일·매주 반복되는 업무가 있는가? (리서치·보고·배포·모니터링)
  • 코드 저장소 안에서 구현·테스트·리뷰를 반복하는가?
  • 팀 규칙·배포 절차·린트·테스트를 일관되게 적용해야 하는가?

누적과 확장

  • 업무 절차가 시간이 갈수록 쌓여야 하는가? (스킬·메모리)
  • 팀의 코드 규칙과 개발 흐름을 구조화해야 하는가? (CLAUDE.md·hooks·subagents)
  • 클라우드에서 병렬 작업을 돌리고 나중에 검토하고 싶은가?

운영과 보안

  • 실행 권한을 어디서부터 시작할 것인가? (읽기 전용 → 작은 수정 → 자동 실행)
  • 비밀정보·토큰·접근 허용 목록을 어떻게 관리할 것인가?
  • 결과 검토와 로그 확인을 습관으로 만들 수 있는가?

결론: 제품이 아니라 ‘일하는 자리’를 고르자

AI 에이전트는 모델 하나를 고르는 일이 아니라, 일을 맡길 운영 환경을 정하는 일에 가깝습니다. 개인 비서의 접점이 필요하면 OpenClaw, 절차가 누적되는 자동화 동료가 필요하면 Hermes Agent, 개발 저장소의 실행과 병렬 클라우드 작업이 필요하면 ChatGPT Codex, 코드베이스 규칙과 팀 개발 흐름을 깊게 확장하려면 Claude Code가 각각 좋은 출발점이 될 수 있습니다.

처음부터 하나에 모든 권한을 몰아줄 필요는 없습니다. 먼저 읽기 전용 분석, 작은 수정, 테스트 실행처럼 권한을 낮게 시작하고, 결과 검토와 로그 확인이 습관이 된 뒤 범위를 넓히는 편이 안전합니다.

독자 질문

내게 가장 부족한 것은 어디서나 접속 가능한 비서일까요, 반복 업무를 이어받을 자동화 동료일까요, 아니면 코드 저장소 안에서 더 깊게 일할 개발 에이전트일까요?


확인한 출처 / 근거

  • Hermes Agent 공식 문서 — 스킬, 장기 메모리, cron, 6개 터미널 백엔드, 20+ 메시징 플랫폼, MCP, subagents. Nous Research 개발.

  • OpenClaw Gateway 운영 문서 — self-hosted Gateway의 운영·수명주기와 제어 표면을 설명합니다.

  • OpenClaw 채널 문서세션 관리 문서 — 채널 지원 범위와 세션 구조를 확인했습니다. OpenClaw 공식 도메인은 openclaw.aidocs.openclaw.ai이며, openclaw.com은 이 제품의 공식 사이트가 아닙니다.

  • OpenClaw iOS 노드 문서Android 노드 문서 — 모바일 노드 연결과 페어링 범위를 확인했습니다.

  • ChatGPT Codex 공식 문서 — Codex CLI, IDE 확장, Codex cloud(격리 환경·병렬 작업), codex exec(CI 자동화), GitHub/Slack/Linear 통합.

  • Claude Code 공식 문서 — Terminal/VS Code/JetBrains/Desktop/Web, CLAUDE.md, auto memory, hooks, subagents, skills, MCP.

  • 참고: 각 제품의 기능·권한 모델·보안 정책은 버전에 따라 빠르게 변하므로, 도입 전 최신 공식 문서를 확인해야 합니다. 본문은 우열·순위·가격·성능을 단정하지 않습니다.

NEXT READING

같은 주제와 태그를 공유하면서, 이 글의 판단 범위를 다음 단계로 넓혀 주는 해설입니다.

AI 인프라 메타 클라우드, AI 에이전트 병목을 풀까 메타가 AI 연산 자원을 외부에 제공하는 클라우드 사업을 검토 중이다. AI 에이전트 시대의 추론 처리 용량 부족을 일부 완화할 수 있을지, GPU와 HBM 메모리 병목은 별개 문제로 남을 가능성을 기술 관점에서 분석한다. AI 인프라 RAG만으로 부족한 순간: Context·Knowledge Graph·Ontology를 어디까지 써야 하나 기업 AI에서 'RAG 정확도가 낮다'는 말 속에는 문서 검색, 관계 탐색, 의미·규칙 정의라는 서로 다른 층의 문제가 섞여 있다. Context·Knowledge Graph·Ontology가 각각 무엇을 해결하는지 구분하고, GraphRAG와 온톨로지를 올려야 하는 업무 조건과 운영 비용의 경계를 제품·기술 구조 관점에서 정리한다. AI 인프라 LLM 모델 양자화란 무엇인가 FP16·BF16 LLM을 INT8·INT4·FP8·NF4로 양자화할 때 무엇이 달라지는지, PTQ·QAT·GPTQ·AWQ·GGUF·bitsandbytes·QLoRA의 차이와 실무 선택 기준을 정리합니다.