← Log

헤르메스로 자동화를 운영하며 접한 사소한 문제들

AI 에이전트 생태계 구축기· 9 / 10
  1. 1 — 멋진 비서를 만들기 위한 뜬구름 시도 끝에, LLM Wiki부터 세웠다
  2. 2 — LLM Wiki를 지식 뇌로 쓰게 해주는 두 가지 자동화
  3. 3 — 지식 뇌와 연결한 첫 번째 비서 알림 기능
  4. 4 — 지식 뇌에 손발을 붙였다: LLM Wiki와 헤르메스 연결하기
  5. 5 — AI 대화 기록으로 블로그 작성하기
  6. 6 — AI 자동화와 사람의 판단을 잇는 우편함 만들기
  7. 7 — 텔레그램에서 슬랙으로 헤르메스 사무실 옮기기
  8. 8 — AI가 쓴 블로그에 필요한 이미지를 더한 방법
  9. 9 — 헤르메스로 자동화를 운영하며 접한 사소한 문제들
  10. 10 — AI 코딩 에이전트의 테스트 PASS를 그대로 믿을 수 있을까

헤르메스를 슬랙에 연결한 뒤, 반복 작업은 헤르메스에게 맡기고 나는 필요한 판단만 하도록 만들고 싶었다.

블로그 발제는 블로그로 쓸 만한 경험을 제안한 문서이고, 컴파일 보고는 대화와 작업 기록을 정리한 결과다. 나는 이런 결과와 이슈 브리핑, 정부지원 알림을 슬랙에서 받아 보고 필요한 일만 직접 판단한다.

처음에는 역할을 정하고 자동 실행을 연결해 두면 일이 자연스럽게 굴러갈 것 같았다. 막상 운영해 보니, 자동화를 설정했다고 해서 내가 원하는 방식으로 동작하는 것은 아니었다.

반복 작업은 맡기고 판단은 내가 하려고 했다

당시에는 매번 내가 직접 찾아보고 정리하고 옮기던 일을 자동으로 처리하고 싶었다. 블로그로 쓸 만한 경험을 찾고, 대화와 작업 기록을 정리하고, 새 이슈나 정부지원 공고처럼 바깥 정보를 살펴보는 일을 헤르메스에게 먼저 맡겼다.

나는 슬랙에서 그 결과를 읽고, 무엇을 더 해 볼지와 어떤 내용을 블로그 글로 만들지를 결정하려 했다. 헤르메스가 먼저 제안한 일은 내가 선택하면 조사나 글 작성으로 이어지고, 끝난 결과와 실패 이유는 다시 같은 곳에서 확인할 수 있기를 바랐다.

처음에는 제안이 내가 새로 해 볼 만한 일보다, 헤르메스 내부의 버그나 카드 품질을 점검하는 내용에 치우치기도 했다. 제안의 재료를 내 기록과 시스템 상태에서만 가져오게 한 탓이었다. 이후에는 바깥의 도구·사례·공고를 먼저 찾고, 내 기록은 그중 지금 나와 관련 있는 것을 고르는 기준으로만 쓰게 했다.

자동화로 맡기려 한 일헤르메스가 처리할 일내가 남기려 한 판단
지식 정리대화와 작업 기록 정리, 놓치면 안 될 내용 알림 설정결과를 본 후 다음에 할 일 정하기
블로그 작성블로그로 쓸 만한 경험 제안, 승인한 주제의 초안 작성 설정글로 만들지와 다듬을 방향 정하기
바깥 정보 탐색새로 나온 AI 이슈와 정부지원 공고 탐색, 개발하거나 시도해 볼 일 제안 설정관심 있는 작업을 골라 진행하기
헤르메스가 탐색·정리·초안을 만들고, 지크의 선택과 승인에 따라 프로그램이 결과 또는 실패 기록을 슬랙에 남기는 흐름

운영하며 실제로 겪은 문제들

헤르메스와 슬랙을 붙인 뒤에는, 예전 방식이 남아서 생긴 문제와 슬랙에서 요청한 일이 끝까지 흐르지 않은 문제, 계속 돌리며 드러난 운영 문제가 차례로 나왔다. 아래는 그때 실제로 확인하고 고친 사례다.

예전 방식이 남아서 같은 일을 막거나 두 번 처리했다

초안을 처리하는 방식과 결과를 보고하는 방식을 바꾸는 동안, 더는 쓰지 않는 파일과 처리 경로가 남아 있었다. 둘 다 지금의 작업을 예전 방식으로 잘못 해석하게 만든 문제였다.

예전 초안 파일 때문에 자동 발행이 멈췄다 — 2026.07.25~08.03

7월 25일에 임시 초안 폴더에 이미 발행한 글의 옛 초안 두 개가 잘못 남았다. 자동 발행은 이 파일을 누군가 아직 쓰고 있는 초안으로 잘못 판단했고, 7월 29일부터 8월 3일까지 발행을 막았다. 파일이 발행된 글의 잔재임을 확인한 뒤 초안 두 개와 예전 초안 저장 방식을 함께 제거했다.

안전선 자체가 틀린 것은 아니었다. 다른 작업이 남아 있으면 자동 발행이 건드리지 않고 멈추는 규칙은 필요했다. 다만 이미 끝난 옛 초안이 그 조건을 계속 만들었고, 멈춘 이유는 로그에 남아 있었지만 슬랙으로 전달되지 않아 내가 바로 알 수 없었다.

새 보고 방식을 더하고 기존 방식을 남겼다 — 2026.07.28~07.30

블로그 글 하나를 발행하면, 내가 글 작성을 승인한 슬랙 메시지 아래에 결과를 남기도록 바꿨다. 그런데 새 댓글 보고를 추가하는 과정에서 별도 완료 메시지를 만드는 기존 방식이 함께 남았다. 같은 발행이 두 처리 경로를 모두 타면서 완료 알림이 두 번 올라왔다.

이 문제는 모델을 바꾼 뒤 눈에 드러났다. 새 모델이 잘못된 것이 아니라, 이전 모델이 두 지시 가운데 하나를 우연히 건너뛰고 있었던 것이다. 새 절차를 만든 뒤 기존 절차를 세 문서에서 함께 정리하지 않은 것이 원인이었다.

성공한 발행 결과는 처음 승인한 메시지의 스레드에만 남기고, 전체 발행 실패일 때만 별도 보고를 남기게 했다.

슬랙에서 선택한 일이 끝까지 이어지지 않았다

#작전회의는 헤르메스가 내가 해 볼 만한 일을 올리던 슬랙 채널이다. 여기서는 선택한 일을 조사하고, 결과를 바탕으로 다음 작업까지 이어지게 하려 했다. 하지만 실제 실행 흐름에는 빠진 연결과 잘못된 실패 표시가 있었다.

관심을 눌러도 조사 결과가 글 작성으로 이어지지 않았다 — 2026.07.25

탐색을 맡은 헤르메스 앱은 #작전회의에 해 볼 만한 일을 한 건씩 메시지로 올렸다. 나는 메시지 아래의 관심 버튼을 눌러 그 일을 실제로 진행할지 고르게 했다. 블로그로 작성할 만한 내용이면 조사 뒤 글 작성까지 이어지도록 설정했다.

하지만 카드에 글을 쓰는 앱의 이름을 적어 둔 것만으로, 조사 결과가 그 앱에 전달되는 것은 아니었다. 화면에 표시한 처리 약속과 실제 처리 경로가 연결돼 있지 않았던 것이다. 처음에는 관심을 눌러도 조사까지만 실행됐다. 조사 결과가 글을 쓰는 헤르메스 앱으로 전달되지 않아 글 작성으로 이어지지 않았고, 나는 결과를 복사해 다시 전달해야 했다.

관심을 누르면 선택한 일에 따라 조사나 글 작성을 시작하게 연결했다. 조사 결과와 글 작성 결과도 처음 메시지의 스레드에 남기게 했다.

AI 서비스 오류가 조사 결과처럼 올라왔다 — 2026.07.25

관심을 누른 뒤 자료를 조사하고 결과를 슬랙 스레드에 올리던 프로그램도 문제가 있었다. 외부 AI 서비스가 오류를 반환했는데, 오류 문구가 정상 조사 결과처럼 스레드에 올라온 적이 있었다. 반대로 빈 결과나 게시 실패가 난 경우에는 아무 메시지도 남지 않아, 결과를 기다려야 하는지 실패한 것인지 알 수 없었다.

오류 문구는 조사 결과로 게시하지 않고, 실패한 이유를 스레드에 짧게 남기도록 바꿨다. 결과를 게시하려 했는데 메시지가 한 건도 올라가지 않으면 완료가 아니라 실패로 처리하게 했다.

계속 돌리며 실행 환경과 기록도 관리해야 했다

자동 작업은 실행되기만 하면 끝나는 것이 아니었다. 맥북의 상태와 자동으로 쌓이는 기록도 결과를 확인할 수 있게 관리해야 했다.

새벽 자동 작업이 멈춰도 바로 알 수 없었다 — 2026.07.31~08.02

새벽에 대화와 작업 기록을 정리하고 그 결과를 검사하던 자동 작업이, 나흘 동안 결과 보고를 남기기 전에 멈췄다. 기록에는 정상 작업 사이에 61분의 공백이 있었고, 원인은 맥북이 잠들면서 실행 중이던 연결이 끊긴 것이었다. 맥북에서 돌아가는 자동 작업은 맥이 잠들면 실행 중에도 멈출 수 있다는 제약을 이때 확인했다.

스케줄러에 실행 기록이 남아 있어도, 그 기록은 작업을 시작했다는 뜻일 뿐 끝까지 마쳤다는 뜻은 아니었다. 처리 완료 뒤에만 장부에 남기도록 해 둔 덕분에, 중간에 멈춘 작업은 다시 실행해 복구할 수 있었다. 결과가 사라진 것은 아니었지만, 멈춘 사실을 슬랙에서 바로 알 수 없었다. 자동화를 예약하는 것만으로는 부족했고, 작업 시간에 맥북이 깨어 있는지와 완료 기록이 남았는지도 함께 관리해야 했다.

검사는 끝났는데 슬랙 보고가 남지 않았다 — 2026.07.28

자동 작업이 실제로 끝났는데도 슬랙에 결과가 남지 않은 적도 있었다. 처리할 일이 없어 앞단에서 AI 실행 자체를 생략하는 것은 정상이다. 하지만 검사가 실행된 뒤에는 결과가 0건이거나 중간에 멈췄어도 그 사실을 알려야 했다.

당시에는 검사에서 세 건의 누락을 찾고도 특이사항 없음으로 보고를 생략했다. 같은 날짜의 보고 파일이 이미 있으면 덮어쓸 수 있다는 이유로 새 보고를 만들지 않은 경우도 있었다. 이후에는 자동 작업이 실행됐다면 결과와 중단 여부를 반드시 남기고, 같은 이름의 보고가 있으면 새 파일로 이어서 남기게 했다.

아무도 관리하지 않던 오류 로그가 9일 만에 82MB가 됐다 — 2026.07.29

역할별로 나눠 둔 헤르메스 앱 네 개의 오류 로그를 훑다가, 자동으로 쌓이기만 하던 파일 네 개가 9일 만에 82MB가 된 것을 발견했다. 그중 하나는 52MB였고, 대부분은 같은 재접속 실패 메시지가 반복된 것이었다. 이 상태에서는 다른 오류가 섞여도 찾기 어려웠다.

파일 크기만 줄이면 실제로 확인해야 할 오류까지 같이 사라진다. 반복된 오류는 횟수와 함께 요약하고, 따로 확인할 신호는 남긴 뒤 로그를 정리하게 했다. 로그를 비우는 일과 이상을 알아차리는 일을 나눠 처리한 것이다.

연결한 뒤에도 계속 고쳐야 했다

자동화는 연결과 설정만으로 끝나지 않았다. 실제로 돌려 봐야 남은 예전 방식, 빠진 전달 경로, 보이지 않는 실패, 맥북 슬립처럼 실행 환경에서 생기는 문제가 드러났다.

그래서 헤르메스를 운영하며 자동화 자체를 계속 고치게 됐다. 슬랙에서 결과와 실패가 분명히 보이는지, 작업이 끝까지 이어지는지, 자동 작업이 멈추지 않는지를 직접 확인하며 손봤다. 앞으로도 새 자동화를 붙일 때는 설정에서 멈추지 않고, 실제 사용 중 드러나는 문제를 고치며 내 방식에 맞게 넓혀 갈 생각이다.

목차