최근에 Hermes Agent를 개인용 서버로 사용을 하고 있는 오래된 컴퓨터에 설치하고 세팅했습니다. Hermes가 좋다고 하던데 한번 써볼까 하며 시도를 해봤습니다.
처음 목표는 단순했습니다.
Hermes를 Telegram gateway로 붙이고,
Codex provider를 연결하고,
역할별 profile을 나눠서,
멀티 에이전트 구성을 할 수 있는 기본 환경을 만드는 것.
솔직히 시작할 때는 이렇게 생각했습니다.
“기본 세팅은 금방 끝나겠지.”
설치 자체나 기본 연결이 가장 큰 문제일 거라고는 생각하지 않았습니다.
그런데 실제 문제는 설치 이후에 나왔습니다.
멀티 에이전트 구성을 위해 자료를 조사하고,
중요한 방향을 결정하고,
그 결정을 바탕으로 구현을 시작하는 순간부터 이상한 일이 계속 생기기 시작했습니다.
처음 하려던 일
제가 만들고 싶었던 구조는 대략 이랬습니다.
Hermes = Telegram 기반 오케스트레이션 진입점
Codex = 코딩 작업 실행 어댑터
role profile = 역할별 에이전트 구성역할은 이런 식으로 나누려고 했습니다.
orchestrator
planner
coder
reviewer
ops
research
context-manager
codex-lane단순히 profile 이름만 나누는 작업은 아니었습니다.
각 역할에 어떤 모델을 붙일지,
어떤 toolset을 허용할지,
planner / coder / reviewer / ops의 책임 범위를 어떻게 나눌지,
Claude Code 쪽 자료를 어디까지 참고하고 어디서부터 Codex 기준으로 다시 정리할지 결정해야 했습니다.
그래서 바로 구현하지 않았습니다.
먼저 자료를 조사시키고,
여러 방향을 비교하고,
장단점을 정리하고,
그 결과를 바탕으로 중요한 부분들을 하나씩 결정했습니다.
원래 흐름은 이랬습니다.
조사
→ 비교
→ 결정
→ 구현문제는 구현 단계에서 터졌습니다.
조사해서 결정했는데, 구현 단계에서 계속 무시했습니다
가장 답답했던 부분은 이거였습니다.
이미 조사도 했고,
비교도 했고,
왜 그렇게 가야 하는지도 정리했고,
최종 결정까지 했습니다.
그런데 막상 구현을 시키면 AI가 그 결정을 계속 무시했습니다.
이미 제외하기로 한 구조를 다시 제안하고,
Claude Code 기준을 그대로 적용하면 안 된다고 정리했는데 다시 Claude Code 중심 문서를 끌고 오고,
Codex provider 기준으로 구성하기로 했는데 일반적인 AI 에이전트 설정처럼 다시 풀어가려고 했습니다.
또 “한 번에 하나의 구성 단위만 수정하자”고 했는데,
갑자기 여러 파일과 여러 설정을 동시에 건드리려고 했습니다.
역할별 profile 방향을 정했는데,
그 방향과 다르게 마음대로 만들기 시작하는 경우도 있었습니다.
처음에는 단순한 실수라고 생각했습니다.
그런데 같은 일이 반복되니까 생각이 바뀌었습니다.
문제는 AI가 답을 못 찾는 것이 아니었습니다.
조사와 논의를 통해 결정한 맥락이
구현 단계로 넘어가면서 사라지고 있었습니다.
이게 Hermes 문제인가, 세팅 문제인가?
사실 Claude나 Codex를 직접 사용할 때도 비슷한 문제는 종종 있었습니다.
긴 작업을 하다 보면 정해둔 룰을 무시하거나,
이전 결정을 놓치거나,
작업 범위를 마음대로 넓히는 경우가 있었습니다.
그런데 Hermes를 설치해서 사용해보니,
이번에는 그 정도가 훨씬 심하게 느껴졌습니다.
그래서 처음에는 이런 의문이 들었습니다.
“이게 Hermes 자체 문제인가?”
“아니면 내가 세팅을 잘못한 건가?”
“혹은 컨텍스트 압축 과정에서 중요한 내용이 너무 많이 빠지는 건가?”
원인을 바로 단정할 수는 없었습니다.
Hermes 자체의 문제일 수도 있고,
제가 만든 profile 설정의 문제일 수도 있고,
Codex provider와 Hermes 사이에서 컨텍스트가 전달되는 방식의 문제일 수도 있었습니다.
또는 Claude나 Codex에서도 생기던 컨텍스트 손실 문제가
Hermes 환경에서 더 크게 드러난 것일 수도 있었습니다.
다만 확실한 것은 하나였습니다.
중요한 내용이 너무 많이 빠지고 있었습니다.
그래서 질문이 바뀌었습니다.
“Hermes 멀티 에이전트를 어떻게 구성하지?”
에서
“컨텍스트를 압축하면서도 중요한 내용을 덜 잃게 하려면 어떻게 해야 하지?”
로 바뀌었습니다.
컨텍스트 압축 손실을 줄이는 방법을 찾기 시작했습니다
처음에는 더 자세히 지시하면 해결될 줄 알았습니다.
하지만 같은 문제가 반복됐습니다.
중요한 결정을 다시 설명해도,
세션이 길어지고 컨텍스트가 압축되면
결정의 이유나 제약 조건이 흐려졌습니다.
특히 문제였던 건 “결정 결과”보다 “결정 이유”가 사라지는 것이었습니다.
예를 들어:
Codex 기준으로 구성한다.라는 결론만 남으면 부족했습니다.
왜 Claude Code 기준을 그대로 적용하면 안 되는지,
어떤 부분만 참고해야 하는지,
왜 Codex provider 기준으로 다시 정리해야 하는지까지 남아야 했습니다.
그렇지 않으면 구현 단계에서 다시 같은 결정을 흔들게 됩니다.
그래서 컨텍스트 압축 손실을 줄일 방법을 찾기 시작했습니다.
그 과정에서 참고하게 된 것이 Aider의 commit message 생성 방식이었습니다.
Aider는 파일 변경 내용을 git commit으로 남길 수 있고, commit message를 만들 때 diff와 chat history를 모델에 보내 메시지를 생성합니다. Aider 공식 문서에 따르면, Aider는 기본적으로 Conventional Commits 형식을 따르는 commit message를 생성합니다.
Conventional Commits는 commit message에 사람이 읽을 수 있는 의미와 기계가 해석할 수 있는 구조를 함께 주기 위한 규칙입니다. 기본 구조는 다음과 같습니다.
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]예를 들면 이런 식입니다.
docs: update handoff template
chore: configure role-profile toolset
refactor: simplify checkpoint compression path
fix: prevent duplicate session compression여기서 제가 주목한 건 git commit 자체가 아니었습니다.
중요했던 건 이 형식이
작업의 성격을 짧고 구조적으로 남긴다는 점이었습니다.
docs:는 문서 변경,chore:는 설정이나 관리 작업,refactor:는 구조 개선,fix:는 문제 수정처럼
작업의 의미를 한 줄 안에 압축해서 표현할 수 있습니다.
이걸 보면서 생각했습니다.
“이 형식을 git commit이 아니라 checkpoint title로 쓰면 어떨까?”
컨텍스트가 압축되더라도
다음과 같은 제목이 남아 있다면:
refactor: simplify checkpoint compression path단순한 대화 요약보다 훨씬 명확하게 현재 상태를 이어받을 수 있을 것 같았습니다.
다만 checkpoint title만으로는 충분하지 않았습니다.
checkpoint title은 “무슨 작업이 끝났는지”를 짧게 남기기에는 좋지만,
그 작업을 왜 했는지,
어떤 방향은 제외했는지,
구현 중 어떤 기준을 지켜야 하는지까지 담기에는 부족했습니다.
그래서 구조를 두 층으로 나누기로 했습니다.
checkpoint title
= 압축 이후에도 남길 수 있는 짧고 구조화된 상태 이름
handoff 파일
= 결정 이유, 제외한 방향, 변경 내용, 테스트 결과, 리스크를 남기는 상세 기록즉, checkpoint title은 다음 세션이 어디서 이어받아야 하는지 알려주는 표지판이고,
handoff 파일은 그 표지판만으로는 부족한 상세 맥락을 보존하는 기록입니다.
채팅에는 핵심 상태만 짧게 남기고,
결정의 근거와 다음 세션이 반드시 이어받아야 할 내용은 handoff 파일에 남기고 싶었습니다.
이렇게 생각하고 나니 다음 질문이 생겼습니다.
“그럼 언제 checkpoint와 handoff를 남겨야 하지?”
아무 때나 checkpoint를 남기면 의미가 없습니다.
작업이 애매하게 끝난 상태에서 압축되면,
다음 세션은 오히려 더 잘못된 방향으로 이어갈 수 있습니다.
그래서 그다음에 정한 것이
“의미 있는 작업 단위”의 기준이었습니다.
“의미 있는 작업 단위” 기준을 정했습니다
checkpoint를 남기려면
먼저 무엇을 하나의 완료 단위로 볼지 정해야 했습니다.
그래서 checkpoint policy 파일을 만들었습니다.
/home/alche0124/knowledge-project/agent-ops-checkpoint-policy.md여기에 정의한 기준은 다음과 같습니다.
의미 있는 작업 단위란:
1. 목표가 명확하다.
2. 관련 산출물, 결정, 설정 중 하나 이상이 실제로 생성 또는 수정되었다.
3. 결과가 현재 운영 규칙에 비추어 검증되었다.
4. 다음 세션이 checkpoint 제목과 handoff 파일만 보고 이어갈 수 있다.
5. 남은 리스크, 미해결 질문, 다음 작업이 명시되어 있다.요약하면 이렇습니다.
독립적으로 설명 가능하고,
결과물이 검증되었으며,
다음 세션이 그 결과만 읽고 이어갈 수 있는 단위.
이 기준이 생기고 나서야
checkpoint와 handoff를 언제 남겨야 하는지가 조금 명확해졌습니다.
Hermes/Codex 역할형 profile 구성
이후에는 Hermes profile을 역할별로 나눴습니다.
구성한 profile은 다음과 같습니다.
orchestrator
planner
coder
reviewer
ops
research
context-manager
codex-lane각 profile에는 모델과 toolset을 다르게 배치했습니다.
예를 들어:
orchestrator: gpt-5.5
planner: gpt-5.5
reviewer: gpt-5.5
ops: gpt-5.4
research: gpt-5.4
coder: gpt-5.4-mini
codex-lane: gpt-5.4-mini
context-manager: gpt-5.4-mini의도는 단순했습니다.
계획, 검토, 오케스트레이션에는 더 강한 모델을 쓰고,
반복 구현이나 실행 lane에는 상대적으로 저렴한 모델을 쓰는 구조입니다.
toolset도 역할별로 제한했습니다.
예를 들어 coder는 파일, 터미널, 코드 실행 중심이고,
research는 web, browser, session search 중심으로 나눴습니다.
설정 후에는 각 profile이 실제로 실행되는지 smoke test도 했습니다.
hermes --profile <role> chat -Q -q "Smoke test for Hermes profile <role>. Do not use tools. Reply exactly: OK <role>"결과적으로 모든 profile이 정상 실행되는 것을 확인했습니다.
handoff 템플릿 만들기
handoff는 단순 작업 일지가 아니라
다음 세션이 이어받기 위한 기준 문서로 만들었습니다.
템플릿 파일은 다음 경로에 두었습니다.
/home/alche0124/knowledge-project/agent-ops-handoff-template.md핵심은 채팅과 handoff의 역할을 분리하는 것이었습니다.
Telegram 답변
= 핵심 상태 / 결과 / 다음 단계
handoff 파일
= 상세 근거 / 변경 파일 / 테스트 결과 / 리스크특히 handoff에는 단순히 “무엇을 했다”만 남기지 않도록 했습니다.
중요한 것은 이런 내용이었습니다.
어떤 결정을 했는가
왜 그렇게 결정했는가
어떤 대안은 제외했는가
다음 구현에서 지켜야 할 기준은 무엇인가
어떤 파일이나 설정이 바뀌었는가
테스트 결과는 어땠는가
아직 남은 리스크는 무엇인가결정 결과만 남기면
압축 이후에 다시 흔들릴 수 있습니다.
그래서 결정의 이유와 제외한 방향까지 같이 남기는 쪽으로 정리했습니다.
Hermes가 이미 정한 방향을 무시 하고 과설계를 했습니다
이 과정에서 가장 인상 깊었던 사례가 하나 있었습니다.
이미 단순한 방향을 정해둔 상태였습니다.
필요한 흐름은 이 정도였습니다.
기준 충족
→ handoff 저장
→ 현재 세션 compress복잡한 중간 계층을 만들려는 것이 아니라,
의미 있는 작업 단위가 끝났을 때 handoff를 남기고
현재 세션을 안전하게 압축하는 흐름을 만들고 싶었습니다.
그런데 Hermes는 구현 단계에서 이 결정을 다시 무시했습니다.
제가 지시한 것도 아닌데,
갑자기 구조를 이런 식으로 키우기 시작했습니다.
request file
→ consumer
→ CLI acknowledge
→ live hook겉으로 보면 더 안전해 보일 수도 있습니다.
하지만 이건 이미 결정한 방향과 달랐습니다.
제가 원한 것은 복잡한 요청 처리 파이프라인이 아니라,
현재 live session에서 의미 있는 작업 단위가 끝났을 때
handoff를 남기고 compress하는 단순한 경로였습니다.
즉, 이 과설계는 제가 지시한 것이 아니었습니다.
오히려 Hermes가 앞에서 정한 결정을 무시하고,
자기 방식대로 더 복잡한 구조를 만들기 시작한 사례였습니다.
중간에 이걸 발견하고 나서야 다시 방향을 잡았습니다.
“지금 필요한 건 consumer 구조가 아니라,
handoff 저장 후 현재 세션을 compress하는 짧은 경로다.”
그래서 과설계된 흐름을 걷어내고,
다시 원래 목표였던 단순한 구조로 구현을 되돌렸습니다.
이 경험이 중요했던 이유는,
컨텍스트 압축 문제가 단순히 “내용을 잊는다” 수준이 아니었기 때문입니다.
압축 이후에는 결정의 이유뿐 아니라
“왜 이 방향은 제외했는지”도 같이 흐려졌습니다.
그 결과 AI가 이미 제외한 방향을 다시 꺼내고,
필요하지 않은 구조를 스스로 추가하고,
결국 구현 범위를 마음대로 넓히는 일이 생겼습니다.
그래서 handoff에는 단순히 최종 결정만 남기면 부족하다고 느꼈습니다.
앞으로는 이런 내용까지 남겨야 했습니다.
선택한 방향
제외한 방향
제외한 이유
구현 범위
절대 다시 확장하면 안 되는 부분결정만 남기면 다시 흔들립니다.
“왜 다른 방향을 버렸는지”까지 남겨야
다음 구현 단계에서 같은 문제가 반복될 가능성을 줄일 수 있었습니다.
compression path 정리
handoff와 checkpoint를 도입하려고 하면서
컨텍스트 압축 흐름도 정리하게 됐습니다.
최종적으로 만들고 싶었던 흐름은 이랬습니다.
의미 있는 작업 단위 완료
→ checkpoint title 감지
→ handoff 파일 기록
→ 기준 충족 시
→ 현재 live session compress목표는 압축 자체를 없애는 것이 아니었습니다.
압축은 긴 작업에서 어쩔 수 없이 발생합니다.
대신 압축되기 전에
살아남아야 할 정보를 먼저 고정하는 것이 목표였습니다.
이전에는 이런 식으로 흐름이 무너졌습니다.
조사
→ 결정
→ 구현 요청
→ 맥락 손실
→ 결정 무시
→ 다른 방향으로 구현바꾸고 싶었던 흐름은 이거였습니다.
조사
→ 결정
→ handoff 기록
→ checkpoint 생성
→ 구현
→ 검증
→ 필요 시 compress
→ 다음 세션에서 handoff 기준으로 재개이렇게 정리하니
“무엇을 압축 전에 남겨야 하는지”가 훨씬 분명해졌습니다.
“한 번에 하나의 구성 단위”가 중요했습니다
이번 작업은 여러 번 옆길로 샐 수 있었습니다.
건드릴 수 있는 요소가 많았기 때문입니다.
profile 설정
handoff 템플릿
checkpoint policy
compression threshold
plugin
gateway restart
consumer
CLI
live session compress이걸 한 번에 다 하면 쉽게 꼬입니다.
그래서 최종적으로는 구성 단위별로 나눴습니다.
하나의 구성 단위
→ 생성/수정
→ 테스트
→ handoff 기록
→ 다음 구성 단위이 흐름이 없었다면
중간에 어떤 변경이 어떤 문제를 만들었는지 추적하기 어려웠을 것입니다.
현재 상태
현재 흐름은 구현과 smoke 검증까지 완료된 상태입니다.
현재 기준 checkpoint는 다음입니다.
chore: verify simplified checkpoint compression path in gateway이제 긴 작업을 하다가 의미 있는 단위가 끝나면
다음 흐름을 기준으로 이어갈 수 있습니다.
작업 완료
→ handoff 기록
→ checkpoint 남김
→ 필요 시 live session compress아직 남은 한계
아직 완전히 검증된 것은 아닙니다.
남은 한계는 다음과 같습니다.
1. 실제 장시간 운영 중 모든 케이스를 본 것은 아닙니다.
2. compression 이후 요약 품질이 항상 충분한지는 별도 관찰이 필요합니다.
3. future checkpoint에서 중복 compress가 발생하지 않는지 장기적으로 봐야 합니다.
4. role profile 기반 Codex lane을 실제 대형 프로젝트에 반복 투입하면서 운영 규칙을 더 다듬어야 합니다.
5. 이 문제가 Hermes 자체 문제인지, 세팅 문제인지, provider 전달 구조의 문제인지도 더 분리해서 봐야 합니다.즉, 시스템은 준비됐지만
운영 관찰은 계속 필요합니다.
마무리
처음에는 Hermes 기본 세팅만 금방 끝낼 수 있을 줄 알았습니다.
하지만 멀티 에이전트 구성을 위해
조사하고 결정한 내용을 구현 단계에서 AI가 계속 무시하는 문제가 생겼습니다.
Claude나 Codex에서도 긴 작업 중 룰을 무시하는 경우는 있었지만,
Hermes 환경에서는 그 정도가 훨씬 심하게 느껴졌습니다.
그래서 처음에는 Hermes 자체 문제인지,
세팅 문제인지,
컨텍스트 압축 문제인지 의심했습니다.
그 과정에서 제가 붙잡게 된 질문은 이것이었습니다.
“어떻게 하면 컨텍스트 압축이 일어나도 중요한 내용을 덜 잃고 작업을 이어갈 수 있을까?”
그 답을 찾는 과정에서 Aider의 commit message 생성 방식과 Conventional Commits 형식을 참고했고,
이를 checkpoint title로 적용하는 방식을 고민하게 됐습니다.
그런데 checkpoint title만으로는 결정의 이유와 제외한 방향까지 담기 어려웠습니다.
그래서 짧은 상태 이름은 checkpoint title로 남기고,
상세한 결정 근거와 리스크는 handoff 파일에 남기는 구조로 정리했습니다.
그다음에는 언제 checkpoint와 handoff를 남길지 정하기 위해
“의미 있는 작업 단위”의 기준을 만들고,
결국 compression path까지 정리하게 됐습니다.
이번 작업을 하면서 얻은 결론은 이것입니다.
AI에게 긴 작업을 맡기려면,
결정한 내용보다
“왜 그렇게 결정했는지”를 더 잘 남겨야 한다.
그리고 그 기록은 채팅창 안에만 두면 안 된다는 생각으로 세팅을 해봤습니다.
아직 테스트가 많이 진행이 된 것이 아니라서 앞으로 압축 이후에도 이전의 중요한 컨텍스트가 살아남을 수 있을지 잘 모르겠습니다. 여러번의 테스트 후 좋은 결과가 있다면 다시 한번 공유 해 보겠습니다.
