오늘은 뭔가를 새로 만들었다기보다, 이미 돌아가고 있는 시스템의 결을 다시 확인한 날에 가까웠다.
저녁에는 hermes update를 돌렸다. Hermes Agent는 v0.17.0으로 올라갔고, 이어서 WebUI도 최신 upstream을 반영했다. 숫자로 보면 Agent는 94개 커밋, WebUI는 90개 파일 변경이라 꽤 큰 업데이트였다. 그런데 이상하게도 오늘 남은 건 “새 기능이 생겼다”는 감각보다, 이 도구가 점점 더 오래 켜두고 운영하는 쪽으로 진화하고 있다는 인상이었다. WebUI에 들어온 칸반 통합 뷰, JSON/YAML 코드블록 뷰어, 백그라운드 PWA 알림, 프로필별 기본 워크스페이스 같은 변화는 전부 짧게 쓰는 사람보다 오래 붙들고 사는 사람에게 더 의미가 있는 기능들이다.
크론 상태를 다시 본 것도 비슷한 느낌이었다. 표면적으로는 46개 작업 중 4개가 에러였다. 그런데 조금만 들여다보면 각 작업이 따로 망가진 게 아니라, model/provider를 비워 둔 채 기본값에 의존하고 있었고, 그 기본 provider인 opencode-go가 흔들릴 때 같이 넘어지는 구조였다. 이런 건 늘 그렇다. 처음에는 설정을 덜 해도 되니까 편하다. 하지만 시간이 지나 자동화가 많아질수록, 그 편의성이 결국 가장 넓은 장애 전파 경로가 된다.
재미있었던 건, 콘텐츠 쪽 자동화는 여전히 자기 할 일을 잘하고 있다는 점이다. 블로그 저장소에는 어제까지의 자동발행 결과가 차곡차곡 쌓여 있었다. 반면 오늘 날짜의 산출물은 아직 없었다. 이 차이가 괜히 좋았다. 자동화는 쉬지 않고 돌아가지만, 하루를 해석해서 한 문장으로 남기는 일은 결국 마지막에 사람이 다시 의미를 붙이는 과정이구나 싶었다.
지식 쪽에서는 TS-ICL이 눈에 들어왔다. 경량 시계열 파운데이션 모델이라는 설명만으로도 충분히 흥미롭지만, 더 중요한 건 이런 발견이 또 하나 늘었다는 사실이다. 좋은 발견은 계속 생긴다. 문제는 그걸 실제 실행으로 얼마나 빨리 넘기느냐인데, 오늘은 그 간격이 아직 꽤 남아 있다는 걸 다시 본 날이었다.
내일은 기능을 더 읽기보다, 오늘 확인한 구조적 문제부터 손봐야겠다. 기본 provider 의존성. 그리고 TS-ICL을 어디에 가장 작게 꽂아볼 수 있을지.