한 줄 요약
Claude, Codex, Hermes를 같이 쓰다 보니 스킬, 에이전트, 파이프라인 설정이 서로 다른 버전으로 흩어졌고, 이걸 하나의 공용 런타임 소스 폴더로 정리했다.
시작하게 된 이유
저는 Claude, Codex, Hermes를 동시에 씁니다.
처음에는 각각의 장점이 뚜렷했습니다. Claude는 기존에 만들어둔 자동화와 스킬이 많았고, Codex는 코드 수정과 토큰 사용 면에서 편했고, Hermes는 텔레그램·크론·자동화 운영의 중심으로 쓰기 좋았습니다.
그런데 시간이 지나면서 문제가 생겼습니다.
같은 /블로그 작업인데 Claude 쪽 설명과 Hermes 쪽 실행 방식이 다르고, Codex로 옮겨온 스킬은 예전 버전이고, 어떤 파일은 바탕화면 이미지 폴더를 보라고 하고 어떤 파일은 홈 폴더의 blog-images 를 보라고 했습니다.
더 큰 문제는 "어디를 고쳐야 진짜 고친 건지"가 점점 흐려졌다는 점입니다.
~/.claude, ~/.codex, ~/.hermes 안에 각각 스킬과 스크립트가 있고, 홈 폴더의 공통 AGENTS 파일도 읽히고, 예전에 만든 하네스 폴더까지 섞이면서 같은 규칙이 여러 군데에 다른 버전으로 존재했습니다.
AI 도구를 많이 쓰면 모델 성능보다 먼저 설정의 출처가 꼬인다는 걸 깨달았습니다.
밤에 컴퓨터 작업을 하는 사람들의 그룹
컴퓨터와 모니터가 있는 방
어떤 도구를 사용했고, 어떻게 활용했나요?
이번 작업에서는 Hermes를 현재 운영 기준으로 삼았습니다.
이유는 간단했습니다. 실제 자동화, 크론, 텔레그램 연동, 블로그 발행, 데일리 테제, GPTers 수집 같은 운영 작업이 대부분 Hermes 중심으로 돌고 있었기 때문입니다.
그래서 구조를 이렇게 바꿨습니다.
agent-runtime-source
├── skills
├── adapters
│ ├── codex
│ ├── claude
│ └── hermes
├── bundles
└── scripts
핵심은 각 프로그램 폴더를 직접 수정하지 않는 것입니다.
예전에는 이런 식이었습니다.
~/.hermes/skills/blog-naver
~/.codex/skills/blog-naver
~/.claude/skills/blog-naver
그러면 셋 중 하나만 고쳐지고 나머지는 낡은 상태로 남기 쉽습니다.
이번에는 기준 폴더를 하나 만들고, Claude/Codex/Hermes가 그 기준 폴더를 바라보게 했습니다. 복사본을 세 군데에 뿌리는 방식이 아니라, 가능한 한 "같은 원본을 참조 하는 구조"로 바꿨습니다.
자동화는 별도로 분리했습니다.
직접 쓰는 스킬이나 슬래시 명령은 세 도구 모두에서 사용할 수 있어야 하지만, 크론처럼 자동으로 결과물을 만드는 작업은 Hermes에서만 실행되어야 합니다. 그렇지 않으면 같은 블로그나 영상이 세 번 발행될 수 있기 때문입니다.
그래서 원칙은 이렇게 잡았습니다.
스킬 / 에이전트 / 파이프라인:
Claude, Codex, Hermes 모두 사용 가능
자동 실행 / 크론 / 예약 발행:
Hermes만 운영
Codex / Claude:
직접 호출은 가능하지만 백그라운드 자동화는 보류
컴퓨터와 모니터가 있는 방
작업하면서 막혔던 부분
가장 헷갈렸던 건 "공용 폴더를 만든다"는 말의 의미였습니다.
처음에는 공용 폴더에서 세 프로그램 폴더로 복사해서 배포하는 구조처럼 생각했 습니다. 그런데 실제로 운영해보니 복사 방식은 다시 버전 차이를 만들 수 있었습니다.
그래서 방향을 바꿨습니다.
"세 프로그램에 복사한다"가 아니라 "세 프로그램이 같은 기준 폴더를 바라본다"에 가깝게 정리했습니다.
또 하나의 문제는 경로 보안이었습니다.
Hermes 크론은 아무 경로나 실행하면 위험하니까, 기본적으로 ~/.hermes/scripts 안의 스크립트만 실행하도록 막혀 있었습니다. 그런데 우리가 스크립트를 공용 소스 폴더로 옮기고 symlink로 연결하자, 일부 크론이 "scripts 폴더 밖으로 벗어난다"고 판단했습니다.
이건 좋은 보안장치이지만, linked deploy 구조에서는 신뢰할 수 있는 공용 소스 폴더를 별도로 허용해야 했습니다.
작업 중에 또 하나 확인한 것은 Gemini 설정이었습니다. 저는 Gemini를 텍스트 추론이나 보조 모델로 쓰려는 게 아니라, 이미지 생성 API 용도에서만 쓰고 싶었습니다. 그런데 예전 설정의 흔적 때문에 텍스트 압축이나 보조 처리에서 Gemini가 튀어나오는 경우가 있었습니다. 이런 부분도 "Gemini는 이미지 생성에만 사용"으로 정리했습니다.
결과적으로 좋아진 점
가장 큰 장점은 수정 위치가 분명해졌다는 점입니다.
이제 어떤 스킬이나 파이프라인을 고칠 때 "Hermes 쪽을 고쳐야 하나, Codex 쪽을 고쳐야 하나, Claude 쪽을 고쳐야 하나"를 매번 고민하지 않아도 됩니다.
기본 원칙은 하나입니다.
기준은 agent-runtime-source
각 도구는 그 기준을 adapter로 읽는다
실제로 첫 수정도 해봤습니다.
블로그 파이프라인에서 커버 이미지에 불필요한 텍스트가 들어가는 문제가 있었고, 이를 공용 소스 기준으로 수정했습니다. 그 뒤 Codex/Hermes 쪽에서 같은 수정이 반영되는지 확인했습니다.
이때 비로소 "아, 이제 내가 의도한 구조가 맞게 움직이는구나"라는 감이 왔습니다.
또 좋은 점은 운영 책임이 명확해졌다는 것입니다.
Hermes는 자동화 운영 담당이고, Codex와 Claude는 직접 호출하거나 개발 보조로 사용합니다. 덕분에 같은 자동화가 세 군데에서 중복 실행되는 위험을 줄일 수 있습니다.
단점과 조심해야 할 점
이 구조가 무조건 편하기만 한 건 아닙니다.
첫 번째 단점은 초기 정리가 어렵다는 점입니다. 기존에 쌓인 스킬, 에이전트, 스크립트, 파이프라인이 많을수록 무엇이 최신이고 무엇이 구버전인지 확인하는 데 시간이 오래 걸립니다.
두 번째는 공용 소스가 잘못되면 세 도구가 동시에 영향을 받는다는 점입니다. 예전에는 한쪽만 망가졌다면, 이제는 기준 폴더가 잘못되면 전체가 같이 흔들릴 수 있습니다.
세 번째는 symlink와 보안 정책을 잘 맞춰야 한다는 점입니다. 공용 폴더를 바라보게 하는 구조는 좋지만, 크론이나 자동화 시스템 입장에서는 "외부 경로 실행"처럼 보일 수 있습니다. 그래서 trusted root, dry-run, validator 같은 검증 장치가 필요합니다.
마지막으로, GitHub를 중심으로 둔다고 해서 웹상의 GitHub를 런타임으로 직접 쓰는 건 위험하다고 봤습니다. 실제 실행은 로컬의 공용 소스 폴더에서 하고, GitHub는 버전관리와 백업의 중심으로 두는 쪽이 더 안전했습니다.
이번 작업을 하며 배운 점
AI 도구를 여러 개 쓰는 사람에게 진짜 중요한 건 "어떤 모델이 더 똑똑한가"만이 아니었습니다.
오히려 더 중요한 질문은 이것이었습니다.
이 설정의 원본은 어디인가?
이 자동화는 누가 실행해야 하는가?
이 스킬은 세 도구에서 같은 버전인가?
실패했을 때 어디를 보면 되는가?
Claude, Codex, Hermes를 함께 쓰는 건 충분히 가능합니다. 다만 각 도구가 자기만의 폴더와 자기만의 설정을 계속 키우게 두면, 어느 순간 사람이 전체 구조를 이해하지 못하게 됩니다.
이번 3일간의 작업은 AI 자동화를 더 많이 만들기 위한 작업이라기보다, 이미 만들어둔 자동화들이 서로 싸우지 않게 정리한 작업에 가까웠습니다.
앞으로의 계획
이제 당장 더 크게 확장하기보다는, 실제 운영을 하루 정도 지켜볼 생각입니다.
특히 크론 자동화가 다시 정상 실행되는지, 블로그·테제·GPTers 수집 같은 파이프라인이 공용 소스 기준으로 잘 도는지 확인하려고 합니다.
다음 단계는 각 파이프라인별로 "수정은 어디서 하고, 실행은 누가 하고, 검증은 어떻게 하는지"를 더 명확하게 문서화하는 것입니다.
결국 목표는 하나입니다.
제가 Claude를 쓰든, Codex를 쓰든, Hermes를 쓰든 같은 작업은 같은 기준으로 실행되게 만드는 것.
이번 작업은 그 출발점이었습니다.
