소개
최근 개인 맥 미니 장비에 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
