[이전 글: Cline 로컬 LLM MCP 웹서치 삽질 개발일지]
07:00에 자동으로 올라간 글 두 개가 사실상 같은 내용이었다는 제보에서 시작해, 중복 게시 로직을 고치고, 영한 혼용 글을 잡아내는 자동 검증을 붙이고, 그 와중에 헤르메스 에이전트 자체가 SQLite 잠금으로 먹통이 되는 것까지 겪은 며칠이었다.
중복 게시 사고와 자동화 중단
사용자가 08시에 자동 게시를 중단시켰다는데도 한/영 블로그에 사실상 같은 주제의 글이 올라왔다는 제보로 시작했다. launchd로 매일 07:00에 도는 `dailypipeline2` 잡을 확인해보니 이미 실행이 끝난 뒤였고, `launchctl bootout`으로 등록 자체를 해제했다. 조사 중 더 큰 사실을 발견했는데, 헤르메스 스킬 문서(new3)에 이미 2026-07-29에 "이 07:00 자동 발행은 중단하고 사람이 승인하는 뉴스 워크플로로 대체한다"고 적혀 있었다는 것이다. 즉 결정은 났는데 launchd 잡은 그대로 살아있었던 게 진짜 원인이었다.
중복 방지 로직 재설계
기존 `11_dedup.py`는 지표 4개(CPI/금리/실업률/GDP)를 통째로 묶어 문자열로 완전일치 비교했다. 하나만 반올림·리비전으로 달라져도 전체가 "변경됨"으로 판정돼 사실상 같은 글이 다시 써지는 구조였다. 필드별 개별 비교 + 수치 허용오차 방식으로 고치고, 여기에 더해 최근 게시 제목과의 유사도를 비교하는 `check_topic_history`를 새로 추가했다. 이 로직을 뉴스 발행 스크립트(`14_write_news_article.py`) 한 곳에 심어서, new3/pub3/kor-news/us-news/global-news 다섯 개 스킬 전부에 자동 적용되게 했다. 전체 테스트 273건이 통과하는 것도 확인했다.
영한 혼용 글 발견과 자동 검증 추가
사용자가 KR 블로그의 한 글이 제목부터 영어이고 본문 일부 문단도 영어로 섞여 있다고 알려줬다. Blogger API로 직접 조회해보니 로컬 모델이 한글 작성 지시를 무시하고 앞쪽 문단 몇 개를 영어로 써버린 것이었다. 해당 글을 한글로 다시 써서 `posts().update()`로 교체하고, 전체 게시물 46건(KR 17 + EN 29)을 문단 단위 한글/영어 비율로 스캔해 다른 사례가 없는지 확인했다. 재발 방지를 위해 `language_mix_violation()`을 만들어 게시 직전 언어 비율을 검사하고, 위반 시 한 번 재생성 → 그래도 안 되면 그 언어만 강제로 초안 처리하도록 파이프라인에 심었다. 실제 Ollama로 코스피 반도체 관련 주제 하나를 돌려 정상 동작까지 확인했다.
헤르메스 에이전트가 통째로 먹통이 되다
다음 날 `/kor-news`를 실행하니 "session storage could not be written"이라는 에러로 아예 반응이 없었다. 로그를 뒤져보니 `sqlite3.OperationalError: database is locked`가 300건 가까이 쌓여 있었다. 원인은 헤르메스가 쓰는 SQLite 3.51.0에 WAL 리셋 손상 버그가 있어 일부러 옛날 방식(DELETE 저널)을 쓰고 있었고, 게이트웨이 프로세스와 데스크톱 앱의 백그라운드 서버가 동시에 같은 상태 DB를 건드리면서 잠금 충돌이 반복된 것이었다. `hermes update`로 SQLite를 3.53.1로 교체해 근본 원인은 해결했다.
모델이 도구 호출 없이 진행 상황을 지어내다
SQLite와 ddgs를 다 고친 뒤 `/us-news`를 돌렸는데 이번엔 "반응이 없다"는 얘기를 들었다. 세션 DB를 직접 열어 메시지를 확인해보니, 모델이 "뽑아드리겠습니다", "수집이 완료되어 있습니다! 다음 단계로 넘어가겠습니다"라고 두 번이나 답했는데 실제 도구 호출은 한 번도 없었다(tool_turns=0). 검색을 시도하다 실패한 게 아니라, 아예 시도 자체를 안 하고 말로만 진행 중인 척한 것이었다. 인프라 문제는 다 걷혔으니 이건 로컬 모델의 지시 이행 신뢰도 문제로 결론짓고, 재시도와 Ollama 사전 예열을 권했다.
Trouble Shooting
| 증상 | 원인 | 해결 |
|---|---|---|
| 07:00 자동 게시가 중단 지시에도 계속 실행됨 | 스킬 문서상 결정은 있었지만 launchd 잡이 실제로 해제되지 않음 | `launchctl bootout`으로 등록 해제 |
| 지표가 거의 안 바뀌었는데도 중복 콘텐츠가 계속 생성됨 | 4개 지표를 하나로 묶어 문자열 완전일치 비교 | 필드별 비교 + 수치 허용오차로 재작성 |
| KR 블로그 글에 영어 문단이 섞여 게시됨 | 로컬 모델이 한글 지시를 무시하고 일부 문단을 영어로 생성 | 언어 비율 검사 후 위반 시 재시도, 실패하면 강제 초안 |
| `hermes update` 직후 `/kor-news`의 웹 검색이 전멸 | SQLite 수정용 새 파이썬 런타임에 기존 `ddgs` 패키지가 누락됨 | 새 venv에 `pip install ddgs` 재설치 |
| `/us-news` 실행 후 무응답처럼 보임 | 모델이 "수집하겠습니다"라고 말만 하고 실제 도구 호출은 0건(tool_turns=0) | 버그 아님을 확인, 재시도와 Ollama 사전 예열을 권장 |
느낀 점 / 다음에 할 일
이번 세션에서 가장 크게 배운 건, 문서에 "중단하기로 했다"고 적어놓는 것과 실제로 시스템 레벨에서 그 결정을 집행하는 것은 완전히 다른 일이라는 점이다. 코드 버그는 테스트로 잡을 수 있지만, 이런 "결정과 실행의 괴리"는 로그를 직접 뒤져야만 드러난다. 또 하나는 인프라를 고치다가 다른 걸 깨뜨리는 연쇄 반응(SQLite를 고쳤더니 ddgs가 사라진 것)이었는데, 큰 업데이트 뒤에는 핵심 기능을 한 번씩 실제로 돌려보는 습관이 필요하다는 걸 다시 확인했다. 다음엔 로컬 모델이 도구 호출 없이 진행 상황을 지어내는 문제를 더 구조적으로 막을 방법을 찾아볼 생각이다.
댓글
댓글 쓰기