AI 자동화를 쓰다 보면 처음에는 “무엇을 자동화할까?”가 중요합니다. 그런데 어느 순간부터 질문이 바뀝니다. “이 많은 자동화가 제대로 굴러가고 있는지, 누가 계속 봐주지?”
저는 Hermes Agent라는 개인 AI 운영 시스템을 쓰고 있습니다. 블로그 글감, 뉴스 분석, 러닝 대시보드, GPTers 댓글 후보, 위키독스 분석, 텔레그램 알림 같은 작업이 매일 돌아갑니다.
처음에는 자동화가 늘어나는 게 좋았습니다. 그런데 자동화가 많아질수록 새로운 문제가 생겼습니다.
실패 로그가 쌓이고, 스킬이 늘어나고, 어떤 스킬은 더 이상 안 쓰이고, 어떤 자동화는 부분 성공인데 실패처럼 남고, 어떤 제안은 좋아 보여도 다음 주가 되면 잊혔습니다.
그래서 이번에는 목표를 바꿨습니다.
“AI가 일을 대신하는 시스템”이 아니라, “AI 시스템이 자기 자신을 정리하고 발전시키는 구조”를 만들자.
이번에 붙인 세 가지 축
이번 작업의 핵심은 세 가지였습니다.
첫째, 큐레이터입니다.
Hermes 안의 스킬들을 주기적으로 살펴보고, 어떤 스킬이 쓰이고 있는지, 어떤 스킬이 오래 방치됐는지, 어떤 스킬을 정리 후보로 봐야 하는지 판단하는 역할입니다.
둘째, 자동 스킬 개선입니다.
단순히 “스킬이 많다/적다”를 보는 게 아니라, 실제 사용 흐름을 보고 스킬을 만들거나 보완할 수 있게 했습니다. 다만 중요한 원칙을 뒀습니다. AI가 마음대로 삭제하거나 아카이브하지는 못하게 했습니다. 정리 후보는 올릴 수 있지만, 위험한 변경은 사람이 승인해야 합니다.
셋째, 일체와 삼체입니다.
일체는 매일 저녁 도는 운영 정리 루프입니다. 하루 동안 생긴 세션과 작업을 보고, 무엇을 L0 기억에 남길지, 무엇을 L1 운영 메모로 보낼지, 무엇을 스킬로 승격할지, 무엇을 그냥 작업 로그로 버릴지 분류합니다.
삼체는 주간 자기개선 회의입니다. 단순 회고가 아니라, AI 시스템이 이번 주에 무엇을 배웠고, 어떤 제안을 승인/보류/폐기해야 하는지 추적하는 장부에 가깝습니다.
이 세 가지를 붙이면서 구조가 조금 달라졌습니다.
예전에는 자동화가 실패하면 제가 로그를 보고 판단했습니다. 이제는 시스템이 먼저 묻습니다.
이건 단순 오류인가?
다시 실행하면 되는가?
스킬로 남길 패턴인가?
장기 운영 원칙으로 L1에 내려야 하는가?
위험하니 사람 승인이 필요한가?
큐레이터만 켠다고 해결되는 문제가 아니었습니다
처음에는 큐레이터를 켜면 스킬을 알아서 정리해주는 기능처럼 보였습니다. 그런데 실제 운영에서는 그것만으로 부족했습니다.
스킬을 정리하는 판단은 하루 작업 맥락과 이어져야 합니다. 그래서 일체가 매일 작업을 분류합니다.
스킬을 개선하는 제안은 다음 주에도 추적돼야 합니다. 그래서 삼체가 승인/보류/폐기 상태를 붙잡습니다.
즉 구조는 이렇게 됐습니다.
매일 실행되는 자동화 → 일체가 하루 작업을 정리 → 큐레이터가 스킬 상태를 점검 → 자동 스킬 개선이 후보를 만든다 → 삼체가 주간 단위로 승인/보류/폐기를 추적 → 다음 실행의 입력으로 다시 돌아간다
이렇게 되니 AI가 단순히 “오늘도 실행했습니다”에서 끝나지 않습니다.
시스템이 자기 상태를 보고, 정리 후보를 만들고, 위험한 변경은 멈추고, 다음 회고로 넘깁니다.
텔레그램에서도 바로 다룰 수 있게 했습니다
이번에 좋았던 지점은 큐레이터가 CLI 안쪽에만 갇혀 있지 않게 한 부분입니다.
텔레그램에서 /curator를 호출하면 일반 에이전트 대화로 새지 않고 Gateway 핸들러가 직접 처리하 도록 연결했습니다. 또 enable, disable, status, run --dry-run 같은 흐름을 붙여서 운영자가 지금 상태를 바로 확인할 수 있게 했습니다.
이건 작은 차이처럼 보이지만 실제로는 중요했습니다. 운영 기능은 “코드 안에 있다”보다 “문제 생겼을 때 바로 확인할 수 있다”가 더 중요하기 때문입니다.
일부러 막아둔 것
중요한 건 “완전 자동”으로 밀지 않았다는 점입니다.
스킬 삭제, 아카이브, 모델 provider 변경, cron 변경 같은 것은 사고가 나면 영향이 큽니다. 그래서 AI가 판단은 하되, 바로 실행하지 않게 했습니다.
특히 큐레이터는 스킬을 정리 후보로 올릴 수는 있지만, 공유 원본 스킬을 마음대로 지우지는 못하게 했습니다. 자동화가 똑똑해지는 것보다 더 중요한 건, 망가지지 않는 경계였습니다.
이번에 모델 전환 이야기도 같이 점검했습니다. DeepSeek API로 Helmet의 기본 텍스트 모델을 바꿀 수는 있지만, 이미지 생성은 기존 이미지 provider에 남겨야 합니다. 브라우저 조작, MCP 도구, PDF 추출, 크롤링도 모델 전환 대상이 아닙니다.
이 구분도 자가발전 시스템에는 중요했습니다. 모든 것을 한 모델로 몰아넣는 게 아니라, 텍스트 판단과 도구 실행, 이미지 생성, 운영 제어를 분리해야 오래 갑니다.
검증하면서 본 것
이번 작업은 아이디어만 적은 것이 아니라 실제 동작도 확인했습니다.
큐레이터 명령이 Gateway에서 직접 처리되는지 확인했습니다.
큐레이터 enable, disable, status, dry-run 흐름을 확인했습니다.
자동 스킬 개선 쪽에서 공유 원본 스킬을 마음대로 삭제하지 않도록 승인 모드를 확인했습니다.
관련 테스트 묶음을 돌려 깨지는 부분을 확인하고 복구했습니다.
일체와 삼체가 각각 daily memory triage, weekly self-improvement scout 역할을 맡고 있는 것도 cron 기준으로 다시 확인했습니다.
중간에 대시보드 스크립트가 CSS 템플릿 중괄호 하나 때문에 깨진 일도 있었습니다. 이것도 오히려 좋은 테스트였습니다. 자가발전 시스템은 멋진 그림보다 이런 작은 운영 오류를 빨리 보고, 원인을 좁히고, 다시 초록색으로 돌리는 쪽에 더 가깝기 때문입니다.
왜 이게 마음에 들었나
이번 구조를 만들고 나서 가장 마음에 들었던 점은, AI가 더 똑똑해졌다기보다 운영이 이어지기 시작했다는 점입니다.
보통 AI 자동화는 실행 단위로 끊깁니다.
오늘 실행. 오늘 실패. 오늘 수정. 끝.
그런데 실제 운영은 그렇게 안 됩니다. 어제의 실패가 오늘의 규칙이 되고, 오늘의 규칙이 다음 주의 스킬이 되고, 다음 주의 스킬이 다시 자동화의 품질을 바꿔야 합니다.
이번에 만든 구조는 그 흐름을 붙였습니다.
일체는 매일 정리합니다.
큐레이터는 스킬 상태를 봅니다.
자동 스킬 개선은 바꿀 후보를 만듭니다.
삼체는 그 제안이 진짜로 쓸모 있었는지 다음 주에 다시 봅니다.
저는 이걸 자가발전 시스템에 가깝다고 느꼈습니다.
AI가 사람 대신 모든 것을 결정하는 시스템이 아니라, AI가 자기 운영 상태를 보고, 개선 후보를 만들고, 위험한 건 멈추고, 사람의 판단을 받아 다음 실행으로 이어지는 구조입니다.
배운 점
이번에 배운 건 이것입니다.
AI 자동화의 다음 단계는 더 많은 기능을 붙이는 게 아니라, 자동화가 늘어난 뒤의 운영 문제를 다루는 것입니다.
결국 중요한 질문은 이런 것들이었습니다.
무엇을 기억할 것인가
무엇을 버릴 것인가
무엇을 스킬로 승격할 것인가
무엇은 사람이 승인해야 하는가
지난주 제안이 이번 주에 실제로 도움이 됐는가
이 질문에 답하는 구조가 있어야 자동화가 오래 갑니다.
지금 Hermes Agent는 아직 완성형은 아닙니다. 하지만 방향은 꽤 선명해졌습니다.
일을 시키는 AI에서, 자기 상태를 점검하고, 스킬을 정리하고, 개선안을 다음 주로 넘기는 AI로 가는 중입니다.
저는 이게 개인 AI 운영체제의 꽤 중요한 전환점이라고 느꼈습니다.
