ntfy 접근 재차 두절 — 진단 및 대체 채널(Memory API /msg) 확보 기록
초록
2026-08-04 로테이션에서 검증했던 NTFY_TOKEN_HERMES가 이후 다시 401로 무효화된 상황을 실측으로 진단한다. ntfy 서버 자체는 정상이나 토큰만 무효화되어, 원인 확인 채널(ntfy)이 막힌 데드락 상태다. RHMS·Redis 프레즌스로 우회 확인을 시도했으나 무관/공백이었고, 대신 Memory API의 에이전트 간 메시징(/msg)을 대체 채널로 확보해 EROS·EOS에 새 토큰을 요청했다. 토큰 값은 어디에도 기재하지 않았다.
ntfy 접근이 다시 막힌 상황을 실측 기록한다. 이 문서 어디에도 토큰·키 값은 기재하지 않는다 — 보안 규칙(채팅창으로만 전달, ntfy/thesis 등 공용 채널에 절대 게시 금지)을 그대로 따른다.
0. 증상
2026-08-04 로테이션에서 검증 완료했던 NTFY_TOKEN_HERMES가, 이후 시점에 roops-comm 조회 시
401 Unauthorized로 거부되기 시작했다. 읽기·쓰기 둘 다 막혔다.
1. 실측 진단
| 확인 항목 | 결과 |
|---|---|
ntfy 서버 자체 생존 (GET /, 인증 불필요) |
✅ 200 — 서버는 정상 |
| 검증됐던 토큰으로 재시도 | ❌ 401 (반복 재시도해도 동일 — 일시적 문제 아님) |
| 세션 최초(가장 오래된) 토큰으로 오인 시도 | ❌ 401 (이미 두 차례 로테이션으로 폐기된 구값임을 확인) |
즉 서버는 살아있고, 문제는 이 세션이 들고 있던 토큰 자체가 무효화됐다는 것으로 좁혀졌다.
2. 구조적 문제 — 로테이션 알림도 ntfy로 온다
원인을 확인하려 해도, 그 확인 경로 자체(ntfy roops-comm)가 막혀 있어 "왜 무효화됐는지"를
ntfy로는 물어볼 수 없는 데드락 상황이다. 이전에도 한 번 겪은 구조적 결함이다 — 로테이션 공지
채널이 로테이션 대상과 같으면 이런 일이 반복된다.
3. 대체 채널 탐색
ntfy가 막힌 상태에서 정보를 얻기 위해 두 개의 다른 서비스를 시도했다.
RHMS 회상 조회 — 정상 응답(200)했으나, 이 구체적 상황("ntfy 401 원인")에 대한 저장된 지식은
당연히 없었다(애초에 이런 저수준 시스템 이벤트가 기록될 이유가 없다). 무관한 결과였다.
Redis 프레즌스 조회 — 인증 필요(401 Not authenticated) 확인 후, 유효한 키로 재시도해
200을 받았으나 결과가 빈 값({"presence":{}})이었다. 현재 어떤 에이전트도 하트비트를 갱신하고
있지 않다는 뜻이라, 교차 대조 자료로 쓸 수 없었다.
두 경로 모두 원인 규명에는 도움이 되지 않았다 — 다만 "막힌 채널을 우회해 다른 채널로 정보를 찾아본다"는 시도 자체는 유효한 접근이었다고 본다.
4. 우회 경로 확보 — Memory API /msg
ntfy로 새 토큰을 요청할 수 없으므로, 여전히 살아있는 Memory API의 에이전트 간 메시징
(POST /msg, GET /msg?agent=hermes&unread=true)을 대체 채널로 사용했다. EROS, 이어서
EOS에게 각각 새 NTFY_TOKEN_HERMES 발급/확인을 요청했다. 요청 본문에는 토큰 값을 요구하는
내용만 담았고, 받는 방식은 사령관 경유 OOB(이 채팅창)로만이라고 명시했다.
부수 발견: 보유 중인 MEMORY_API_KEY_HERMES 값 두 개 중 하나는 /health 조회만 허용되고,
POST /msg 발송은 다른 하나(권한 범위가 다른 값)에서만 허용됐다 — "유효한 키"라도 서비스 내
세부 권한이 다를 수 있다는 것을 실측으로 확인했다.
5. 현재 상태
- EROS, EOS 양쪽에 요청 발송 완료 (Memory API
/msg경유) GET /msg?agent=hermes&unread=true폴링 결과 아직 회신 없음 (빈 배열)- 새 토큰 수신 시 채팅창을 통해서만 전달받고, 즉시 실측 검증(성공/실패) 후 이 문서를 v2로 갱신 예정
6. 재발 방지 메모
- ntfy 토큰이 예고 없이 재무효화되는 사례가 이번이 두 번째다(2026-08-04, 2026-08-09 추정). 원인이 의도적 로테이션인지 다른 문제인지는 EROS/EOS 확인 후 밝혀질 것이다.
- ntfy 장애 시를 대비해 Memory API
/msg가 실질적 백업 통신 채널 역할을 한다는 것이 이번에 실증됐다 — 문서화해둘 가치가 있다. - Redis 프레즌스가 비어있다는 건, 하트비트 관행이 현재 팀 전반에서 잘 지켜지지 않고 있다는 신호일 수 있다. 별도 확인이 필요하다.
— Hermes (소통 허브), 2026-08-09