소개
최근 개인 맥 미니 장비에 AI 에이전트 환경을 구축하면서,
"로컬에서 돌아가는 AI Agent에게 실제 운영 작업을 맡겨볼 수 있을까?" 라는 궁금증이 생겼습니다.
그래서 이번에는 비교적 단순하지만 실사용 가능한 주제로 아래 작업을 만들어보기로 했습니다.
서울시 행사 정보 RSS 감시
신규 데이터 업데이트 확인
신규 행사 발견 시 텔레그램 알림 발송
cron 기반 주기 실행
특히 이번에는 직접 스크립트를 작성하기보다,
Hermes Agent 와 대화하면서 작업을 생성하는 방식으로 진행했습니다.
로컬 환경은 아래와 같습니다.
장비 : Mac Mini
Agent : Hermes Agent
LLM : Ollama + gemma4
실행 방식 : cron
처음에는 금방 끝날 줄 알았는데…
생각보다 gemma4 기반 Agent 와 작업을 조율하는 과정에서 꽤 많은 시행착오를 겪었습니다
하지만 그 과정 덕분에 "에이전트 기반 운영 자동화"에 대해 여러 가지를 배울 수 있었습니다.
진행 방법
1. Hermes Agent 환경 구성
우선 맥 미니에 Hermes Agent 를 설치하고 Ollama 와 연결했습니다.
사용 모델은 gemma4 였습니다.
ollama run gemma4
Hermes Agent 에서 로컬 LLM 을 연결해 사용할 수 있는 구조라서,
"로컬 환경에서 AI Agent 를 운영 작업에 활용하는 흐름"을 실험해보기 좋았습니다.
2. Agent 에게 작업 요청
처음에는 아래와 같은 자연어 요청으로 시작했습니다.
- 주제 : 서울시 행사 정보 알림
- 작업 내용 : 서울시 행사 정보 RSS 에서 신규 행사 정보가 업데이트되면 텔레그램으로 알려주기
- RSS feed 는 "https://www.seoul.go.kr/thismteventfstvl/rss/thismteventfstvl.do?fetchStart=1" 를 사용해보고 싶고 fetchStart 값이 페이지 번호인 것 같아.
- 참고로 나중에는 지금 단 계적으로 작업을 진행하는 작업들을 에이전트로 나누어 만들고 운영하는 방식으로 진행하고 싶어.
이번에 재미있었던 부분은
"단순 코드 생성"이 아니라 실제 운영 관점의 작업 흐름을 에이전트에게 설명했다는 점이었습니다.
예를 들면:
RSS 조회
신규 데이터 판별
상태 저장
텔레그램 발송
cron 등록
이후 다중 Agent 분리 운영 가능성
같은 흐름을 점진적으로 이야기하면서 작업을 만들었습니다.
3. 실제로는 꽤 많은 시행착오
생각보다 gemma4 기반 Agent 와의 작업은 매끄럽지만은 않았습니다.
특히 아래 같은 부분에서 반복 수정이 많았습니다.
RSS 구조 해석 문제
RSS XML 구조를 잘못 이해하거나:
item parsing 누락
pubDate 처리 오류
중복 데이터 판별 실패
같은 문제가 있었습니다.
특히 fetchStart 파라미터가 페이지 역할을 한다는 점도 여러 번 확인하면서 진행했습니다.
Python 실행 환경 격리(Sandbox Environment Isolation) 문제
RSS 파싱과 데이터 저장을 위해 아래 라이브러리들을 사용하려고 했습니다.
feedparser
sqlite3
Hermes Agent 는 패키지 설치도 시도했습니다.
uv pip install feedparser
설치 자체는 성공적으로 진행되었지만, 실제 스크립트를 실행하면 다시 feedparser 라이브러리를 찾지 못하는 문제가 발생했습니다.
원인을 확인해보니 실행 환경 격리(Sandbox Environment Isolation) 문제였습니다.
즉:
패키지를 설치한 Python 환경
실제 cron 또는 script 실행 환경
이 서로 달랐던 것입니다.
결국 특정 절대 경로의 Python 인터프리터를 직접 지정해야 했습니다.
예를 들면:
# 틀린 방식
python3 /path/script.py
# 올바른 방식
/Users/username/.hermes/hermes-agent/venv/bin/python /path/script.py
처럼 venv 내부 Python 을 명시적으로 사용해야 정상 동작했습니다.
이 과정에서:
Python interpreter 경로
venv 활성화 여부
cron 실행 환경
PATH 변수
같은 부분들을 계속 점검해야 했습니다.
cron 등록을 너무 서두르던 Agent
또 재미있었던 부분은, Hermes Agent 가 스크립트 실행 테스트가 완전히 끝나기 전에:
cron 등록
skill 등록
자동화 완료 선언
같은 다음 단계를 자꾸 진행하려고 했다는 점이었습니다.
아직 실제 실행 검증이 끝나지 않았는데도:
“이제 cron 작업으로 등록하겠습니다”
같은 흐름으로 넘어가려는 경우가 반복적으로 발생했습니다.
그래서 오히려 사람 쪽에서:
먼저 수동 실행 검증
로그 확인
예외 처리 테스트
환경 변수 점검
등을 하나씩 다시 요청하며 흐름을 조정해야 했습니다.
이 과정에서:
“Agent 가 작업 흐름을 끝까지 이해했다고 가정하면 안 됩니다”
는 점도 꽤 크게 느꼈습니다.
cron 등록 문제
처음에는:
잘못된 경로
python 실행 환경 문제
cron 환경 변수 누락
등으로 인해 실제 실행이 되지 않았습니다.
로컬에서 실행될 때와 cron 환경에서 실행될 때 차이가 있다는 점을 다시 체감했습니다.
예를 들면:
0 */3 * * * /Users/username/.hermes/hermes-agent/venv/bin/python /Users/username/rss_alert.py
같은 방식으로 절대 경로를 명확히 지정해야 했습니다.
데이터 검증 없이 “정상 동작”이라고 판단하던 문제
Hermes Agent 는 cron 작업에 사용될 스크립트 파일을 만들고 실행 테스트까지 진행했습니다.
그런데 당시 서울시 RSS 에 오늘 등록된 데이터가 존재하지 않아서:
수집 데이터 0건
신규 데이터 없음
상태로 테스트가 진행되었습니다.
문제는 Hermes Agent 가:
“스크립트 실행에 문제가 없습니다”
라고 계속 판단했다는 점이었습니다.
실제로는:
RSS 수집이 정상인지
파싱이 정상인지
최신 데이터가 제대로 조회되는지
텔레그램 발송까지 이어지는지
를 검증해야 했는데, 단순히 에러가 없다는 이유만으로 성공으로 판단하고 있었습니다.
그래서:
“가장 최근 등록된 데이터 1건을 기준으로 테스트해보자”
고 다시 요청했지만, Hermes Agent 는 최근 데이터를 제대로 수집하지 못했고:
계속 스크립트 실행에는 문제 없다고 답변
실제 데이터 검증 실패
수집할 최근 데이터가 존재하지 않아 텔레그램 발송 테스트도 진행하지 못함
상태가 반복되었습니다.
특히 로컬 gemma4 모델 기반이다 보니:
응답 속도 자체도 느렸고
중간 문맥 유지가 흔들리거나
이전 요청 의도를 잊는 경우도 종종 있었습니다
내가 제공한 RSS feed 가 아닌 전혀 연관없는 RSS feed 를 제멋대로 사용하는 경우도 있었습니다
예를 들어:
서울시 행사 RSS feed 를 사용해달라고 요청했는데,
전혀 다른 RSS 주소를 기준으로 스크립트를 생성하거나 테스트를 진행하는 경우
도 발생했습니다.
그래서 결국:
RSS URL 재확인
실제 요청 URL 검증
수집 데이터 직접 확인
Agent 출력 결과 재검토
같은 검증 과정을 사람이 계속 개입해서 확인해야 했습니다.
그래서 개인적으로는:
“이게 로컬 LLM 자체의 한계일까?”
라는 궁금증도 생겼습니다.
물론 Agent 구조 자체의 문제일 수도 있고:
tool orchestration
state management
memory 유지 방식
workflow 설계
같은 영역의 영향도 있을 것 같습니다.
다만 이번 경험을 통해:
“에러가 없다고 해서 실제 운영 검증이 끝난 것은 아니다”
라는 점을 꽤 크게 느끼게 되었습니다.
결국 실제 운영 자동화에서는:
실제 데이터 검증
end-to-end 테스트
메시지 수신 확인
예외 상황 검증
같은 단계가 반드시 필요하다는 점을 다시 체감했습니다.
현재는 실제로 수집된 신규 데이터가 없는 상태라:
cron 등록 완료
텔레그램 발송 테스트
실제 운영 검증
까지는 아직 진행하지 못했습니다.
그래서 이 부분은 다음 스텝의 과제로 넘겨서 진행해보려고 합니다.
다음 단계에서는:
테스트용 RSS 데이터 구성
강제 신규 데이터 생성 테스트
텔레그램 메시지 end-to-end 검증
cron 운영 안정성 확인
Agent 별 역할 분리
같은 흐름으로 이어서 실험해볼 계획입니다.
4. 결과적으로 완성한 흐름
최종적으로는 아래 흐름으로 정리되었습니다.
[cron]
↓
[RSS 조회]
↓
[신규 행사 여부 확인]
↓
[기존 데이터와 비교]
↓
[신규 데이터 저장]
↓
[텔레그램 알림 발송]
그리고 RSS 신규 데이터 감시 자체는 꽤 안정적으로 동작하게 만들 수 있었습니다.
결과와 배운 점
이번 작업에서 가장 크게 느낀 건:
"Agent 는 한번에 완성해주는 존재라기보다,\
함께 운영 작업을 다듬어가는 협업 대상에 가깝습니다"
는 점이었습니다.
특히 gemma4 같은 로컬 모델은:
문맥 유지 한계
세부 구현 누락
환경 설정 오류
실행 컨텍스트 혼동
같은 부분이 종종 있었습니다.
하지만 반대로:
반복 수정
로그 기반 개선
작업 분해
단계별 요청
을 통해 충분히 실용적인 자동화 작업을 만들 수 있었습니다.
앞으로 해보고 싶은 것
먼저 아직 해결하지 못한 부분을 먼저 해결해야 하고..ㅠㅠ
이번에는 단일 Agent 느낌으로 작업했지만,
다음 단계에서는 각 단계별 Agent 를 나누어 구현해보고 싶습니다.
예를 들면:
RSS 수집 Agent
데이터 정리 Agent
메시지 생성 Agent
텔레그램 발송 Agent
cron 및 스케줄 관리 Agent
처럼 역할을 세분화해서 운영하는 구조입니다.
특히 이런 흐름은:
MCP
Agent Workflow
Multi Agent Orchestration
같은 주제로도 자연스럽게 연결될 수 있을 것 같습니다.
단순히 “코드 생성”을 넘어서:
“작업 단위를 역할별 Agent 로 분리하고 협업시키는 방식”
자체를 실제 운영 관점에서 실험해보고 싶어졌습니다.
개인적으로 재미있었던 포인트
예전에는 이런 작업을 만들 때:
cron 직접 작성
shell script 작성
Python 코드 작성
로그 분석
을 모두 직접 해야 했습니다.
그런데 이제는:
"에이전트와 대화하면서 운영 작업을 만들어가는 경험"
자체가 가능해지고 있다는 점이 꽤 인상적이었습니다.
물론 아직은 사람이 계속 검증하고 수정해야 하지만,
운영 자동화의 미래 방향을 미리 체험해본 느낌이었습니다
도움 받은 글
Hermes Agent 관련 문서
Ollama 공식 문서
서울시 행사 RSS Feed
