Hermes에 Codex Runtime을 붙여서, Discord에서 작업시키기

Threads에서 흥미로운 글을 하나 봤다.

Hermes는 단순히 LLM을 호출하는 챗봇이 아니라, 개인 에이전트의 운영 레이어가 될 수 있다.

그리고 Codex는 실행 엔진이 된다.

https://www.threads.com/@dante_ailab/post/DYYMjcJElBL?xmt=AQG0lirdPRtN3xoqU8b57rbMPdTX13L_4Dq3u3Iv3QdaEA

 

핸드폰이나 Discord에서 Hermes에게 명령한다.
Hermes는 메시지를 받아 세션, 메모리, skill, gateway를 관리한다.

 

실제 코딩 작업은 Codex runtime이 맡는다.
Codex는 로컬 프로젝트 디렉터리 안에서 파일을 수정하고, 테스트를 돌리고, 결과를 다시 Hermes를 통해 돌려준다.

 

즉, 목표는 이런 흐름이다.

Discord / Telegram
        ↓
Hermes Gateway
        ↓
Hermes Agent
        ↓
Codex App-Server Runtime
        ↓
Local Workspace

처음에는 이게 정말 가능한지 확인하는 게 우선이었다.
문서상으로는 가능해 보였지만, 실제로 내 Mac에서 Hermes gateway를 거쳐 Codex가 로컬 작업공간까지 접근하는지 확인해야 했다.

---

왜 이 구조가 중요한가

기존의 AI 코딩 도구는 대부분 “내가 IDE 앞에 앉아 있을 때” 가장 강력하다.

하지만 에이전트 작업은 꼭 IDE 안에서만 시작할 필요가 없다.
예를 들어 이동 중에 Discord로 이렇게 말하고 싶다.

OOO 프로젝트 들어가서 로그인 오류 원인 확인하고 수정해줘.
테스트까지 돌리고 결과 요약해줘.

이 명령이 실제 로컬 프로젝트 작업으로 이어진다면, AI 에이전트는 단순한 채팅 상대가 아니라 백그라운드 개발 파트너에 가까워진다.

중요한 점은 “모델만 바꾸는 것”이 아니라는 것이다.

이 구조에서는 역할이 나뉜다.

 

Hermes는 입구이자 운영 레이어다.

메시징 gateway, 세션 관리, memory, skill, slash command, 프로젝트 별칭 같은 것을 담당한다.

 

Codex runtime은 실행 레이어다.
파일 수정, 쉘 실행, 샌드박스, MCP/tool-heavy 작업, 코드 검증 같은 실제 개발 작업을 담당한다.

---

실제로 적용한 것

이번에 내 환경에서는 Hermes를 최신 버전으로 업데이트하고, 기본 모델 라우팅을 OpenAI Codex 계열로 연결했다.

구성 방향은 다음과 같았다.

model:
  provider: openai-codex
  openai_runtime: codex_app_server

fallback_providers:
  - provider: anthropic
    model: claude-sonnet-OOO

핵심은 openai_runtime: codex_app_server다.
이 설정을 통해 Hermes가 OpenAI/Codex 계열 작업을 Codex app-server runtime으로 넘길 수 있게 된다.

물론 설정만 바꾼다고 끝나지는 않았다.

OpenAI Codex OAuth 인증이 필요했고, 실제로 처음에는 Hermes 기준으로 logged out 상태였다. Device code 인증을 다시 진행한 뒤 openai-codex: logged in 상태를 확인했다.

그 다음에는 Codex 쪽 설정으로 MCP 서버와 플러그인도 연결했다.

내 환경에서는 Notion, Gmail, Google Calendar, Slack, GitHub, Vercel, Browser, Chrome, Computer Use, Documents, Spreadsheets, Presentations 같은 플러그인이 Codex config 쪽으로 들어갔다.

 

이 단계가 중요한 이유는 Hermes가 메시지를 받더라도, 실제 작업은 Codex runtime 안에서 실행되기 때문이다.
Codex 쪽에 필요한 tool과 plugin 상태가 준비되어 있어야 Hermes를 통해 들어온 요청도 제대로 처리된다.

---

Gateway 검증

설정 후 Discord에서 간단한 명령을 내려봤다.

먼저 현재 작업 디렉터리와 런타임 환경을 확인했다.
초기 응답에서는 Hermes agent 디렉터리에서 실행 중이었고, 환경 변수에는 다음 단서가 보였다.

CODEX_SANDBOX=seatbelt

macOS에서 seatbelt는 샌드박스 실행의 강한 단서다.
다만 CODEX_APP_SERVER 같은 이름의 환경 변수가 직접 보이지는 않았다.

이건 실패라기보다 정상에 가깝다.

Codex app-server runtime을 사용한다고 해서 반드시 쉘 환경에 CODEX_APP_SERVER라는 변수가 노출되는 것은 아니다.

중요한 것은 Hermes gateway를 거쳐 샌드박스된 Codex 실행 환경에서 명령이 수행되는지다.

그래서 다음에는 프로젝트 경로를 직접 지정해서 테스트했다.

/Users/OOO/Documents/OOO

Discord에서 요청한 결과, pwd, ls -la, git status가 해당 프로젝트 기준으로 정상 실행됐다.
환경 변수에는 다음 값들이 확인됐다.

CODEX_CI=1
CODEX_SANDBOX=seatbelt
CODEX_SANDBOX_NETWORK_DISABLED=1
_HERMES_GATEWAY=1
HERMES_SESSION_KEY=agent:main:discord:OOO

이 결과로 확인한 것은 명확하다.

Discord 메시지가 Hermes gateway를 통과했고, Hermes 세션 안에서 Codex 샌드박스 기반 로컬 명령이 실행됐다.
즉, “Discord → Hermes → Codex runtime → 로컬 작업공간” 흐름이 실제로 동작했다.

---

프로젝트 별칭 만들기

다음 문제는 사용성이다.

매번 Discord에서 전체 경로를 입력하는 것은 불편하다.

/Users/OOO/Desktop/OOO/OOO

이런 경로를 계속 쓰는 대신, Hermes가 프로젝트 별칭을 알아먹게 만들면 훨씬 자연스럽다.

그래서 Hermes memory와 local skill에 프로젝트 별칭을 등록했다.

예를 들면 이런 식이다.

project-a = /Users/OOO/Desktop/OOO/project-a
project-b = /Users/OOO/Desktop/OOO/project-b
project-c = /Users/OOO/Desktop/OOO/project-c
project-d = /Users/OOO/Desktop/OOO/project-d
test-project = /Users/OOO/Documents/OOO

그리고 project-dispatch라는 Hermes local skill을 만들었다.
이 skill의 역할은 짧은 프로젝트 호출을 실제 경로 기반 작업으로 바꿔주는 것이다.

이제 Discord에서는 이렇게 말하면 된다.

/new
project-a에서 로그인 오류 확인하고 수정해줘.
필요한 파일은 직접 수정하고 테스트/검증 결과까지 알려줘.

조금 더 명확하게 쓰고 싶으면 이렇게 쓴다.

/new
프로젝트: project-a
작업: 로그인 오류 원인 확인 및 수정
방식: 관련 파일을 직접 수정하고 테스트/빌드/검증까지 진행
결과: 변경 파일, 검증 결과, 남은 리스크만 요약

내가 원했던 것은 바로 이 형태였다.
핸드폰이나 Discord에서 짧게 지시하면, Hermes가 프로젝트를 찾고, Codex runtime이 실제 작업을 수행하는 구조다.

---

지금 가능한 것

현재 구성 기준으로 가능한 일은 다음과 같다.

Discord에서 프로젝트 별칭으로 작업을 시작할 수 있다.
Hermes는 해당 요청을 gateway 세션으로 받고, Codex runtime은 로컬 작업공간에서 명령을 실행할 수 있다.

파일 수정, 쉘 실행, git 상태 확인, 테스트 실행 같은 코딩 작업을 맡길 수 있다.
작업 결과는 Discord로 다시 요약받을 수 있다.

특히 좋은 점은 이것이 단순한 원격 터미널이 아니라는 것이다.

Hermes memory와 skill이 있으므로 “내 프로젝트 이름”이나 “내가 선호하는 작업 방식”을 점점 축적할 수 있다.

예를 들어 앞으로는 이런 명령도 자연스러워질 수 있다.

/new
project-c에서 최근 변경사항 리뷰하고, 위험한 부분 있으면 수정해줘.

/new
project-d에서 빌드 깨지는 부분 먼저 확인하고 고쳐줘.

/new
test-project에서 README 정리하고 커밋 메시지까지 추천해줘.

---

남은 리스크

아직 완전히 끝난 것은 아니다.

첫째, Codex app-server runtime은 Hermes에서 옵션 기능이다.
문서 기준으로도 기본 동작을 대체하는 것이 아니라 사용자가 명시적으로 켜는 구조다.

그래서 업데이트 이후에도 설정이 유지되는지 확인해야 한다.

 

둘째, gateway 보안이 중요하다.
Discord나 Telegram gateway는 결국 내 로컬 작업공간으로 이어지는 입구다.

허용된 사용자, bot token, group mention policy 같은 접근 제어를 대충 두면 위험하다.

 

셋째, 모든 작업을 Codex runtime으로 보내는 것이 정답은 아니다.
일반 대화, 아이디어 정리, 가벼운 문답은 기존 모델로도 충분하다.

반대로 파일 수정, 쉘 실행, 테스트, MCP/tool-heavy 작업은 Codex runtime 쪽이 더 적합하다.

 

그래서 내 결론은 “Hermes의 모든 두뇌를 Codex로 바꾼다”가 아니다.
더 정확히는 “Hermes를 개인 에이전트 운영 레이어로 두고, 로컬 개발 실행이 필요한 순간 Codex runtime으로 라우팅한다”에 가깝다.

---

결론

이번 업데이트로 Hermes는 조금 더 “항상 켜져 있는 개인 개발 에이전트”에 가까워졌다.

 

Hermes는 gateway, memory, skill, 세션을 관리한다.
Codex는 로컬 작업공간에서 파일과 명령을 다룬다.
Discord와 Telegram은 그 둘을 호출하는 일상적인 입구가 된다.

 

아직은 조심스럽게 써야 한다. 하지만 방향은 꽤 분명하다.

앞으로 AI 코딩 에이전트는 IDE 안에만 있지 않을 것이다.
내가 어디에 있든, 짧게 지시하면 로컬 작업공간에서 실제 일이 진행되는 쪽으로 갈 가능성이 크다.

이번 Hermes + Codex runtime 구성은 그 흐름을 내 환경에서 작게 구현해본 첫 단계다.