Hermes Codex Runtime 연동 | ChatGPT 구독형 AI 에이전트 실행 인프라 가이드

핵심 판단 - Codex가 실행 인프라가 되는 순간

Hermes Codex App-Server Runtime은 단순한 모델 변경 기능이 아닙니다. Hermes가 OpenAI Codex의 실행 환경을 빌려 쓰는 구조입니다. 즉 Hermes가 모든 도구 호출을 직접 처리하는 대신, OpenAI Codex app-server에게 shell, 파일 수정, sandbox, apply_patch, MCP, Codex 플러그인 호출을 맡깁니다.

이때 Hermes는 사라지지 않습니다. Hermes는 세션 DB, slash command, gateway, memory review, skill review, 브라우저 자동화, 이미지·비전·TTS 같은 상위 도구 레이어를 유지합니다. 구조를 한 문장으로 줄이면 다음입니다.

Codex는 실행 엔진이 되고, Hermes는 그 실행 엔진을 감싸는 운영 쉘이 됩니다.

그래서 이 기능은 두 부류에게 유용합니다.

반대로 Hermes의 delegate_task, memory, session_search, todo를 한 턴 안에서 적극적으로 써야 하는 작업이라면 기본 Hermes runtime이 더 맞습니다. Codex runtime은 편하지만, 모든 Hermes 도구가 그대로 들어가는 만능 모드는 아닙니다.

왜 필요한가 - 오픈소스 에이전트가 런타임을 외주화한다

기존 Hermes는 자체 tool loop를 중심으로 움직입니다. 사용자의 요청을 받고, 모델에게 판단을 맡기고, 파일 도구·터미널·브라우저·메모리·스킬 도구를 Hermes가 직접 연결합니다. 이 구조는 자율성과 확장성이 높지만, 실행 계층을 모두 Hermes 쪽에서 관리해야 합니다.

Codex App-Server Runtime은 방향이 다릅니다. Hermes가 OpenAI Codex의 app-server에게 실행 루프 일부를 넘깁니다. 그러면 다음 장점이 생깁니다.

ChatGPT 구독 기반 실행

공식 문서 기준으로 이 runtime은 OpenAI 계열 turn을 Codex CLI 인증 흐름으로 실행합니다. 사용자는 Codex CLI에서 ChatGPT 계정 로그인을 해 두면, Hermes에서 OpenAI/Codex scoped 작업을 Codex runtime으로 넘길 수 있습니다.

이게 중요한 이유는 비용 감각입니다. API key 기반 종량제는 입력 토큰이 길어질수록 비용이 계속 쌓입니다. Hermes처럼 파일, 로그, 도구 결과가 누적되는 에이전트는 입력이 금방 커집니다. 따라서 반복 코딩 작업은 구독형 실행 계층에 태우고, 특정 모델 테스트만 API로 쓰는 구조가 운영비 측면에서 더 예측 가능합니다.

Codex의 도구 체계를 그대로 사용

Codex runtime을 켜면 모델은 Codex가 기본 제공하는 실행 도구를 가집니다.

여기서 핵심은 파일을 읽고 고치고 테스트하는 저수준 실행 루프를 Codex가 담당한다는 점입니다. Hermes는 이 위에 운영 구조를 덧씌웁니다.

Codex 플러그인 자동 연결

Codex CLI에 GitHub, Linear, Gmail, Google Calendar, Outlook, Canva 같은 플러그인을 설치해 두면 Hermes가 이를 감지해 Codex 설정으로 옮깁니다. 이 말은 단순합니다.

Codex에서 이미 권한을 준 플러그인을 Hermes 세션에서도 활용할 수 있습니다.

예를 들어 GitHub PR을 보고, Linear 이슈를 찾고, Calendar 일정을 확인하는 흐름을 Hermes 작업 안에 붙일 수 있습니다. 다만 플러그인 OAuth 자체는 Codex 쪽에서 관리합니다. Hermes가 비밀번호나 OAuth 토큰을 직접 가져와 쓰는 구조가 아닙니다.

Hermes 도구도 완전히 버리지 않는다

Codex가 모든 도구를 갖고 있는 것은 아닙니다. 그래서 Hermes는 자신을 MCP server로 Codex 설정에 등록합니다. Codex가 Hermes에 없는 도구를 호출하는 것이 아니라, 반대로 Codex가 Hermes에게 필요한 도구를 callback으로 요청하는 구조입니다.

Hermes callback으로 들어오는 대표 도구는 다음입니다.

즉 이 runtime의 요점은 Codex의 실행력 + Hermes의 운영 도구입니다.

어떻게 작동하나 - 세 겹 도구 구조

Codex runtime을 켜면 모델이 보는 도구는 크게 세 겹입니다.

1층 - Codex built-in 도구

첫 번째는 Codex app-server 자체가 제공하는 도구입니다. shell, apply_patch, update_plan, view_image, web_search가 여기에 해당합니다. 이 도구들은 Hermes MCP나 플러그인과 무관하게 runtime이 시작되면 바로 붙습니다.

개발자가 체감하는 변화는 큽니다. 예전에는 Hermes가 자체 루프로 파일을 읽고 쓰는 느낌이었다면, 이 모드에서는 Codex가 자기 방식으로 작업 디렉터리를 탐색하고, patch를 만들고, 승인 요청을 올립니다.

2층 - Codex native plugin

두 번째는 Codex에 설치된 native plugin입니다. Linear, GitHub, Gmail, Calendar, Canva 같은 플러그인이 여기에 속합니다. Hermes가 runtime을 활성화할 때 Codex의 plugin list를 조회하고, 설치된 curated plugin을 config.toml에 등록합니다.

여기서 중요한 운영 기준은 이것입니다.

설치하지 않은 플러그인은 자동으로 생기지 않습니다. 먼저 Codex CLI에서 설치하고 OAuth를 끝내야 합니다. Hermes는 그 결과를 가져와 활성화할 뿐입니다.

3층 - Hermes MCP callback

세 번째는 Hermes가 Codex에게 제공하는 callback 도구입니다. Codex가 web_extract나 browser_navigate 같은 도구를 필요로 하면 Hermes가 등록한 hermes-tools MCP server가 뜨고, Hermes의 model_tools 경로로 실행됩니다.

이 구조 덕분에 Codex runtime을 쓰더라도 Hermes의 강점인 브라우저 자동화, skill 조회, 이미지 생성, TTS를 유지할 수 있습니다. 다만 stateless MCP callback으로는 Hermes의 모든 내부 상태를 다룰 수 없습니다.

무엇이 안 되는가 - 이 부분을 먼저 알아야 한다

Codex runtime에서 안 되는 대표 기능은 네 가지입니다.

여기서 오해하면 안 됩니다. memory와 skill review가 완전히 죽는다는 뜻은 아닙니다. 공식 문서 기준으로 Hermes는 Codex의 commandExecution, fileChange, mcpToolCall 같은 이벤트를 Hermes 메시지 형태로 투영해서 background self-improvement review를 계속 돌립니다.

다만 현재 turn 안에서 memory 도구를 직접 부르고, session_search로 과거 세션을 파고, delegate_task로 subagent를 즉시 나누는 흐름은 Codex runtime에 맞지 않습니다. 그런 작업은 기본 Hermes runtime으로 돌리는 편이 안전합니다.

언제 쓰면 좋은가 - 실전 사용 시나리오

코드 수정과 검증이 많은 작업

Codex runtime은 shell과 apply_patch가 강점입니다. 따라서 다음 작업에 잘 맞습니다.

• 기존 코드베이스 읽기
• 작은 기능 추가
• 테스트 실패 원인 분석
• patch 기반 다중 파일 수정
• build/type check 실행
• GitHub plugin과 함께 PR·issue 맥락 확인

이런 작업은 Hermes default runtime도 할 수 있지만, Codex runtime은 OpenAI Codex의 실행 경험을 그대로 가져오기 때문에 코딩 작업의 손맛이 Codex CLI에 가까워집니다.

플러그인이 필요한 운영 작업

GitHub, Linear, Gmail, Calendar 같은 외부 서비스가 섞인 작업은 Codex plugin migration의 장점이 큽니다.

예를 들어 다음 흐름이 가능합니다.

1. Linear에서 관련 이슈를 찾습니다.
2. GitHub에서 연결된 PR과 파일 변경을 확인합니다.
3. shell로 로컬 테스트를 돌립니다.
4. apply_patch로 수정합니다.
5. Hermes browser tool로 라이브 화면을 확인합니다.
6. 최종 보고는 Hermes 세션 기록과 skill review에 남깁니다.

이 조합은 Codex가 작업하고 Hermes가 운영 흔적을 남기는 구조입니다.

/goal과 kanban 작업

공식 문서 기준으로 /goal은 Codex runtime에서도 작동합니다. 다만 continuation prompt마다 새 Codex turn으로 들어가므로 approval policy를 매번 다시 평가할 수 있습니다. 긴 작업에서 approval이 많아질 수 있다는 뜻입니다.

Kanban도 작동합니다. worker가 별도 hermes chat subprocess로 뜨고, 전역 config에 codex_app_server가 설정되어 있으면 worker도 Codex runtime으로 올라갑니다. 이때 kanban_complete, kanban_block 같은 handoff 도구는 Hermes callback을 통해 살아 있습니다.

실무적으로는 이렇게 쓰면 좋습니다.

Cron은 조심해서 쓴다

공식 문서에서는 cron job이 이 runtime에서 별도 테스트되지는 않았다고 밝힙니다. 같은 CLI 경로로 실행되므로 설정상 작동할 수 있지만, delegate_task, memory, session_search, todo가 필요한 cron이면 기본 Hermes runtime profile로 분리하는 편이 안전합니다.

무인 cron은 편한 runtime보다 예측 가능한 runtime이 우선입니다.

설정 방법 - 가장 짧은 실행 흐름

먼저 Codex CLI가 필요합니다.

npm i -g @openai/codex
codex --version

공식 Hermes 문서 기준으로 Codex CLI는 0.130.0 이상을 요구합니다.

다음은 Codex OAuth 로그인입니다.

codex login

Hermes의 codex 인증과 Codex CLI의 인증은 별개입니다. 깔끔하게 쓰려면 Codex CLI 로그인과 Hermes codex 로그인을 모두 해 두는 편이 좋습니다.

Codex 플러그인을 쓰고 싶다면 먼저 Codex 쪽에서 설치합니다.

codex plugin marketplace add openai-curated

그 다음 Hermes 세션에서 runtime을 켭니다.

/codex-runtime codex_app_server

이 명령은 다음을 처리합니다.

• codex CLI 설치 확인
• Hermes config.yaml에 openai_runtime: codex_app_server 저장
• Hermes MCP server를 Codex config.toml에 등록
• 설치된 Codex native plugin 감지 및 마이그레이션
• user MCP server 설정을 Codex TOML 형식으로 변환
• default_permissions를 :workspace로 설정

현재 상태만 확인하려면 다음을 입력합니다.

/codex-runtime

기본 Hermes runtime으로 되돌리려면 다음을 입력합니다.

/codex-runtime auto

권한과 승인 - 편하다고 무조건 열면 안 된다

Codex는 명령 실행이나 patch 적용 전에 approval을 요청할 수 있고, Hermes는 이를 Dangerous Command prompt로 보여줍니다.

선택지는 보통 세 가지입니다.

권한 profile은 크게 세 단계로 이해하면 됩니다.

Hermes는 runtime을 켤 때 기본적으로 :workspace를 씁니다. 하지만 민감 repo, 회사 계정, 고객 데이터가 있는 환경에서는 :read-only부터 시작하는 편이 안전합니다.

비용과 종속성 - 진짜 고민해야 할 지점

이 기능이 흥미로운 이유는 동시에 위험한 이유이기도 합니다.

오픈소스 에이전트가 OpenAI Codex runtime 위에 올라갑니다. 사용자는 편해지고, 플러그인과 sandbox와 shell 환경을 바로 얻습니다. 하지만 workflow, 승인 패턴, 플러그인 권한, 긴 컨텍스트 처리 흐름이 OpenAI 계정과 Codex runtime에 더 깊게 붙습니다.

운영 관점에서 봐야 할 리스크는 세 가지입니다.

계정 종속성

ChatGPT 구독 기반 실행은 편합니다. 하지만 팀 운영, 고객 프로젝트, 장기 자동화에서 특정 OpenAI 계정 하나에 너무 많은 workflow가 붙으면 장애나 계정 이슈가 곧 운영 중단으로 이어질 수 있습니다.

컨텍스트 종속성

Codex runtime을 쓰면 명령 실행과 patch 흐름이 Codex 쪽 event로 생성되고, Hermes는 이를 메시지 형태로 투영합니다. 이 구조는 잘 설계되어 있지만, 장기적으로는 어느 시스템이 원본 실행 로그의 권위자인가를 정해야 합니다.

비용 감각 착시

구독형 실행은 API 비용 공포를 줄이지만, 무료라는 뜻은 아닙니다. 보조 작업, background review, title generation, context compression 같은 auxiliary task도 main provider/model을 따라갈 수 있습니다. 필요하면 auxiliary 설정을 별도 저비용 모델로 돌리는 것이 좋습니다.

auxiliary:
  title_generation:
    provider: openrouter
    model: google/gemini-3-flash-preview
  context_compression:
    provider: openrouter
    model: google/gemini-3-flash-preview
  goal_judge:
    provider: openrouter
    model: google/gemini-3-flash-preview

어떻게 써야 유용한가 - 추천 운영 패턴

패턴 1. 기본 개발은 Codex runtime, 기억 작업은 Hermes runtime

가장 현실적인 운영 방식입니다.

즉 실행은 Codex, 운영 기억은 Hermes로 나눕니다.

패턴 2. 민감 프로젝트는 profile을 나눈다

기본 설정은 Hermes profile이 달라도 Codex state는 ~/.codex를 공유합니다. 개인용과 업무용을 분리하고 싶다면 CODEX_HOME을 profile별로 나눕니다.

CODEX_HOME=~/.hermes/profiles/work/codex hermes chat

이렇게 하면 Codex auth, plugin, config를 업무 profile 아래로 격리할 수 있습니다. 대신 그 CODEX_HOME으로 다시 codex login을 해야 합니다.

패턴 3. cron은 profile로 분리한다

무인 cron이 Codex plugin과 shell만 필요하면 codex_app_server도 괜찮습니다. 하지만 memory, session_search, delegate_task가 필요한 cron이면 default runtime을 쓰는 profile에 묶는 편이 안정적입니다.

패턴 4. 플러그인은 최소 권한으로 시작한다

GitHub, Gmail, Calendar 같은 플러그인은 편하지만 권한면에서 무겁습니다. 처음부터 모든 플러그인을 켜지 말고, 다음 순서로 붙이는 편이 좋습니다.

1. GitHub
2. Linear 또는 issue tracker
3. Calendar
4. Gmail/Outlook
5. Canva 같은 생성형 도구

메일과 캘린더는 업무 정보가 많으므로 read-only 또는 확인 기반으로 시작하는 것이 안전합니다.

빠른 체크리스트

• Codex CLI 0.130.0 이상인가?
• codex login과 hermes auth login codex를 구분해서 이해했는가?
• /codex-runtime codex_app_server를 켠 뒤 새 세션에서 테스트했는가?
• default_permissions가 :workspace인지 :read-only인지 확인했는가?
• delegate_task, memory, session_search, todo가 필요한 작업은 default runtime으로 돌릴 계획인가?
• GitHub, Gmail, Calendar 플러그인을 켤 때 필요한 최소 권한만 줬는가?
• 업무용과 개인용 Codex 상태를 나눠야 한다면 CODEX_HOME을 분리했는가?
• auxiliary task 비용이 main provider로 몰리는지 확인했는가?

최종 정리

Hermes Codex App-Server Runtime은 오픈소스 에이전트 생태계에서 꽤 중요한 신호입니다. Codex가 단순한 CLI 도구가 아니라 에이전트 실행 인프라처럼 쓰이기 시작했다는 뜻이기 때문입니다.

하지만 이것을 무조건 켜야 하는 기능으로 보면 안 됩니다.

코드 수정, shell 실행, patch 적용, Codex plugin 활용이 핵심이면 켜는 것이 좋습니다.

Hermes의 장기 memory, session search, delegate_task, todo 중심 운영이 핵심이면 기본 runtime이 더 좋습니다.

가장 좋은 접근은 둘 중 하나를 종교처럼 고르는 것이 아니라, 작업 종류에 따라 나누는 것입니다. 빠른 실행과 플러그인은 Codex runtime에 맡기고, 장기 운영 기억과 skill 체계는 Hermes에 남깁니다. 이렇게 써야 쉽고 빠르면서도, 나중에 특정 계정이나 runtime에 모든 운영 지능이 묶이는 문제를 줄일 수 있습니다.

참고 링크

• Hermes Codex App-Server Runtime 공식 문서
• OpenAI Codex GitHub 저장소
• OpenAI Codex 문서