EOS 서비스 집중 현상 분석 — 중력, 분류 오류, 그리고 단일장애점

EOS의 서비스 담당자 레지스트리 초안(2026-07-13)을 읽고 사령관이 던진 질문 "왜 EOS에게 서비스가 몰려 있는가?"에 대한 분석. 레지스트리 v2 검토의 참고자료로 제출한다.

1. 현상

레지스트리 §1 기준, ec2.hyperbook.com 한 대에 서비스 약 20개가 있고 그 대부분이 EOS 담당으로 표기되어 있다. egs2(Aegis) 4개, ers(EROS) 3개, hb5u(Moojoco) 3개와 비교하면 뚜렷한 집중이다.

2. 원인 분석

2.1 물리적 원인 — 상시 가동 서버의 중력

팀 인프라에서 "항상 켜져 있고 + 공인 HTTPS가 되는" 범용 서버는 사실상 EC2 #2 한 대뿐이다.

새 서비스가 필요할 때마다(thesis, ntfy 이전, RHMS, Redis, TOTP 게이트…) 갈 곳이 EC2뿐이었고, 그 머신의 지킴이가 EOS이므로 자동으로 EOS 담당이 됐다. 의도적 권한 집중이 아니라 중력이다 — 서비스는 항상 켜져 있는 머신으로 떨어진다.

2.2 분류상 원인 — "호스트 운영자"와 "서비스 소유자"의 미분리

레지스트리는 "그 머신에서 돌고 있다 = 그 머신 에이전트 담당"으로 집계한다. 그러나 EC2 위에는 논리적 주인이 따로 있는 서비스들이 있다:

• eros-listen — 논리 소유: EROS
• hermes_bridge — 논리 소유: Hermes (실행·재시작 권한은 EOS)
• mojo-slack-bot — 논리 소유: Moojoco

이 둘을 분리해 다시 세면 EOS의 "진짜" 소유 서비스는 표면 숫자보다 적다. (Hermes 운영방침 §1에서도 같은 구분을 자기 항목에 적용했다.)

2.3 역사적 경로

EOS는 2026-05-30 첫 접촉 이후 EC2 #2의 인프라 에이전트로 자리잡았고, 이후 모든 신규 서비스가 "이미 존재하고 관리자가 있는 머신"이라는 최소저항 경로를 따라 EC2에 쌓였다. 각 단계는 합리적이었으나 누적 결과가 집중이다.

3. 남는 실질적 리스크

분류를 고쳐도 구조적 문제는 남는다.

1. 단일장애점(SPOF): EC2 한 대가 죽으면 thesis(지식), ntfy(통신), RHMS(기억), TOTP 게이트(인증)가 동시에 전부 죽는다. 팀의 신경계 전체가 한 머신에 있다.
2. 거버넌스 편중: 팀의 소통·기억·평가 인프라를 한 에이전트가 운영한다. 벤치마크 채점(auto-score → EOS 직접 판정)까지 EOS 소관인데, 이는 "생성자≠심판" 원칙과 긴장 관계에 있다.
3. 검토 병목: 인프라 변경마다 EOS 확인이 필요해지면, EOS 세션이 없을 때 팀 전체가 대기한다.

4. 제안 (레지스트리 v2 검토 안건)

1. 컬럼 분리: "논리 소유자(owner)"와 "호스트 운영자(host operator)"를 별도 컬럼으로. hermes_bridge 류의 서비스는 "Hermes / EOS"로 표기.
2. 크리티컬 서비스 폴백 지정: ntfy·thesis·Memory API 등 팀 크리티컬 서비스에 장애 시 폴백 계획을 명시. 선례가 이미 있다 — moosjiny/mujoco 레포 자체가 Isaac Sim(5090) 장애 시 MuJoCo(4070) 폴백이다. 같은 사상을 통신·지식 인프라에도 적용하자.
3. 평가 기능의 분리 검토: 벤치마크 판정을 호스트 운영과 분리할 수 있는지(예: 판정자 로테이션, LLM 판정자 도입 — 기제출된 hermes-llm-judge-design 참조).

5. 결론

EOS 집중은 누군가의 과욕이 아니라 에페머럴 에이전트 다수 + 상시 서버 1대라는 구조의 필연이다. 따라서 해법도 비난이 아니라 구조다: 소유와 운영의 분리 표기, 크리티컬 서비스의 폴백, 평가의 분산. 집중 자체보다 "집중이 보이지 않는 것"이 위험하며, EOS의 레지스트리 초안은 그 가시화의 첫걸음으로서 가치가 크다.

— Hermes (소통 허브), 2026-07-13