hermes journey — 에이전트가 무엇을 배웠는지 타임라인으로 보고 잘못 배운 것 지우기
에이전트가 알아서 배우기 시작하면 무엇을 배웠는지 모르게 된다. hermes journey 는 그걸 시간순으로 펼쳐 보여 주고, 잘못 배운 것을 그 자리에서 고치거나 지우는 창구다. 무엇이 점이 되고 무엇이 선이 되는지, 내 스킬이 목록에 안 보이는 이유까지.
에이전트가 알아서 배우기 시작하면 무엇을 배웠는지 모르게 된다. hermes journey 는 그걸 시간순으로 펼쳐 보여 주고, 잘못 배운 것을 그 자리에서 고치거나 지우는 창구다. 무엇이 점이 되고 무엇이 선이 되는지, 내 스킬이 목록에 안 보이는 이유까지.
작업 하나의 로그 34줄이 파드 4개에 흩어져 있었고, web 로그의 56.9% 는 /healthz 였다. 노드마다 Fluentd forwarder 를 DaemonSet 으로 띄워 한곳의 aggregator 로 모았더니 지운 파드의 로그도 남았다. 대신 aggregator 가 바뀌자 쌓여 있던 581건이 사라졌다.
같은 절차를 매번 설명하지 않으려면 스킬로 남긴다. /learn 으로 자동 생성하는 법과 SKILL.md 를 직접 쓰는 법을 처음부터 따라간다. description 이 60자인 이유, 스킬이 있는데도 안 불리는 이유, 자료가 크면 references/ 로 쪼개는 법까지.
취약점 조치로 httpclient5 를 올렸더니 사설 인증서 서버에 `No subject alternative DNS name matching ... found` 로 붙지 않는다. DefaultClientTlsStrategy 에 NoopHostnameVerifier 를 넣어도 소용없는 이유와, HostnameVerificationPolicy.CLIENT 로 푸는 방법.
넥슨 오픈API 로 캐릭터 조회 사이트를 집 서버에 올렸다. 공식 라이브러리 DTO 에는 complete_flag 라고 적혀 있는데 실제 응답은 clear_flag 였고, 난이도는 한글이 아니라 normal·chaos 로 왔다. 없는 데이터는 오류가 아니라 200 으로 오고, API 키는 데이터 범위를 나누지 않는다 — 딱 한 군데만 빼고. 문서와 실제가 어긋났던 여섯 자리를 정리했다.
실패를 다시 할 것과 끝낼 것으로 나누고, TTL 과 데드레터만으로 5초·15초 재시도와 DLQ 를 만든다. 워커를 강제로 죽였더니 작업은 사라지지 않았지만 72.9초 뒤에야 돌아왔고, 평범하게 내렸더니 python 이 PID 1 이라 SIGTERM 을 무시해 31.2초가 걸렸다.
동기 호출을 RabbitMQ 큐로 바꿨더니 죽은 주소가 섞여도 접수가 24ms 에 끝났다. 대신 결과 조회가 404 를 내며 실패했다. 파드가 여럿일 때 상태를 메모리에 두면 생기는 일과, 큐가 대기를 없애는 게 아니라 옮긴다는 점까지 실측으로 짚는다.
링크 미리보기 서비스의 평균 응답은 0.41초다. 그런데 죽은 주소 두 개가 들어오자 멀쩡한 요청이 7.17초를 기다렸다. 34배다. 평균만 보면 멀쩡해 보이는 시스템이 왜 무너지는지 직접 재 본다.
매니페스트 세 종류가 각각 무슨 일을 하는지 한 줄씩 짚는다. 서비스끼리는 IP 가 아니라 이름으로 부른다. 하위 경로에 앱을 붙였다가 API 요청이 엉뚱한 서비스로 새어 나간 이야기도 함께.
파드 왜 죽었어?" 한 줄을 보내면 에이전트는 그 문장만 모델에 보내지 않는다. 13,199자짜리 시스템 프롬프트를 조립하고, 모델이 부른 도구를 실행해 결과를 붙여 다시 묻기를 반복한다. Hermes v0.21.3 소스와 실제 저장된 세션 DB로 다섯 단계를 따라갔다. /learn · /refine · /journey · /compress 같은 고유 기능이 그 다섯 단계 어디에 끼어드는지도 함께 정리했다.