AI 비서를 쓰다 보면 이상한 순간이 있습니다.
분명히 AI가 로그도 읽고, 에러도 설명하고, 해결 방법도 제안합니다. 그런데 마지막에는 결국 사람이 다시 묻습니다.
“그래서 지금 뭘 고치면 되는데?”
저도 비슷했습니다. Hermes라는 개인 AI 운영 시스템을 쓰면서 블로그, 뉴스 분석, 러닝 대시보드, 위키독스 정리, 텔레그램 알림 같은 자동화를 계속 돌리고 있었습니다. 자동화가 많아질수록 문제도 많아졌습니다. 어떤 작업은 모델 응답 시간이 길어서 멈췄고, 어떤 작업은 사용량 제한 때문에 실패했고, 어떤 작업은 이미 결과물을 만들었는데 중간에 종료 신호를 받아 실패처럼 보였습니다.
처음에는 제가 하나씩 로그를 열어 보고 판단했습니다.
하지만 이건 AI 비서라기보다, AI가 만든 숙제를 제가 다시 검사하는 구조에 가까웠습니다. 그래서 이번에는 방향을 조금 바꿨습니다.
“AI가 문제를 발견하는 데서 끝나지 말고, 위험이 낮은 문제는 스스로 처리하고, 위험한 문제만 나에게 승인받게 만들자.”
이번에 만든 것
이번에 만든 것은 self-improver입니다. 한국어로 말하면 자동개선 실행기입니다.
역할은 단순합니다.
Hermes 운영 로그와 예약 작업 상태를 읽습니다.
반복되는 문제를 제안 단위로 정리합니다.
위험도를 나눕니다.
낮은 위험과 일부 중간 위험은 직접 처리합니다.
위험한 변경은 실행하지 않고 승인 대기 상태로 남깁니다.
모든 결과를 삼체 action tracker에 기록해서 다음 주에도 이어서 볼 수 있게 합니다.
여기서 삼체는 제가 개인적으로 쓰는 주간 자기개선 리뷰 시스템입니다. 매주 자동화와 AI 비서 운영 기록을 돌아보고, 어떤 제안을 실행할지, 보류할지, 폐기할지 정리하는 회고 루프입니다. 외부 서비스 이름이 아니라, 제 AI 운영 시스템 안에서 “다음 개선을 결정하는 회의록”에 가깝습니다. 기존이 삼체는 회의록에 가깝기 때문에 보기 좋게 대시보드로 알려주지만 스스로 행동하지는 않습니다.
여기서 중요한 건 “AI가 마음대로 고친다”가 아닙니다. 오히려 반대입니다.
여기에 어느정도 의 자율성을 줘서 고치고 개선할 수 있도록 했습니다.
AI가 무엇을 직접 고쳐도 되는지, 무엇은 절대 승인 없이 건드리면 안 되는지 경계를 먼저 정했습니다.
1단계: 문제를 감지하고 제안으로 바꾸기
첫 단계에서는 최근 Hermes 로그, cron 예약 작업 상태, 스킬 초안을 읽게 했습니다.
여기서 바로 코드를 고치지 않습니다. 먼저 문제를 proposal, 즉 제안 카드로 만듭니다. 이번 실행에서 실제로 잡힌 항목은 6개였습니다.
weekly-tech-scout: 모델 응답이 180초 안에 오지 않아 실패agent turn timeout: 에이전트 작업이 600초를 넘겨 세션이 끊김daily-thesis-blog: Codex 사용량 제한으로 이미지 단계 실패running-weekly: SIGTERM으로 중간 종료됐지만 결과물이 일부 존재wikidocs-batch: SIGTERM으로 종료됐지만 원문 크롤링 산출물이 존재삼체: provider 사용량 제한으로 실패
예전 같으면 이걸 전부 “실패”라고 뭉뚱그렸을 가능성이 큽니다.
하지만 실제로는 성격이 달랐습니다. 사용량 제한은 코드 버그가 아니고, SIGTERM은 외부 종료나 부분 성공일 수 있고, timeout은 작업을 쪼개거나 체크포인트를 넣어야 하는 신호입니다.
이 구분이 핵심이었습니다. 실패를 많이 찾는 것보다, 실패를 제대로 분류하는 게 먼저였습니다.
2단계: 낮은 위험과 중간 위험은 스스로 처리하기
두 번째 단계에서는 위험도를 기준으로 실행 권한을 나눴습니다.
LOW: 허용 목록에 있으면 자동 처리
MED: 범위가 좁고 롤백 가능한 경우만 자동 처리
HIGH: 새 cron, 발송 정책, API 변경처럼 실패 비용이 큰 것은 승인 전 실행 금지
이번 실행에서 실제로 자동 처리된 대표 사례는 weekly-tech-scout입니다.
기존에는 모델 응답을 180초만 기다렸습니다. 최근 실행에서 이 제한 때문에 빈 응답으로 실패했습니다. 그래서 source 기준 스크립트에서 기본 timeout을 WEEKLY_TECH_SCOUT_TIMEOUT=360으로 올리고, 문법 검사까지 통과시켰습니다.
반대로, 자동으로 고치지 않은 것도 있습니다.
예를 들어 Codex 사용량 제한은 코드를 고쳐서 해결할 문제가 아닙니다. 조용히 다른 provider로 바꿔버리면 더 위험합니다. 그래서 “사용량 제한은 provider 정책 이슈이므로 자동 fallback 금지”로 처리했습니다.
SIGTERM으로 끝난 작업도 바로 코드 수정하지 않았습니다. 일부 결과물이 이미 만들어진 흔적이 있었기 때문입니다. 이 경우에는 “외부 종료 또는 부분 성공 후보”로 보고 다음 실행을 관찰하는 쪽이 더 안전했습니다.
가장 흥미로웠던 건 제가 이 작업을 하던 중에도 같은 문제가 다시 발생했다는 점입니다. 에이전트 작업이 600초를 넘기면서 중간에 끊겼습니다. 그래서 이 케이스도 실행기에 추가했습니다.
이제 agent turn timeout은 승인 대기에서 멈추지 않고, “작업 범위 초과. 코드 패치보다 작업 쪼개기나 체크포인트가 먼저”라는 no-patch 처리로 남습니다.
3단계: 제안이 사라지지 않게 추적표에 넣기
세 번째 단계는 개인적으로 가장 중요했습니다.
AI가 좋은 제안을 해도, 다음 주가 되면 묻힙니다. 그래서 제안과 처리 결과를 Obsidian의 삼체 action tracker에 자동으로 주입하게 만들었습니다.
쉽게 말하면 삼체 action tracker는 “AI가 제안한 개선안이 말로만 끝나지 않게 붙잡아두는 실행 장부”입니다. 제안이 승인됐는지, 보류됐는지, 실제로 처리됐는지, 다음에 무엇을 봐야 하는지를 한 곳에 남깁니다.
이 추적표에는 각 항목이 이렇게 남습니다.
proposal id
위험도
현재 상태
제목
다음 action
마지막 실행 결과
예를 들어 이번에 추가된 agent turn timeout 항목은 이렇게 정리됐습니다.
ec3a9adcef22 / MED / handled_no_patch / turn_timeout_no_patch
말로 풀면, “중간 위험이지만 지금은 코드 수 정 대상이 아니고, 긴 작업을 쪼개거나 이어받기 구조로 처리해야 한다”는 뜻입니다.
또 추적표에는 승인, 보류, 폐기 명령도 같이 남깁니다.
이제 자동개선 실행기는 단순히 리포트를 만들고 끝나지 않습니다. 다음 주 주간 리뷰가 이 추적표를 다시 읽고, 지난 제안이 실행됐는지, 보류됐는지, 효과가 있었는지 확인할 수 있습니다.
결과
이번 작업은 3단계까지 완료했습니다.
1단계에서는 로그와 예약 작업에서 실제 문제를 proposal로 만들었습니다.
2단계에서는 LOW/MED 항목을 허용 목록 기준으로 처리했습니다. 고칠 것은 고치고, 고치면 안 되는 것은 “수정하지 않는 처리”로 분류했습니다.
3단계에서는 처리 결과를 삼체 action tracker에 주입해서 다음 실행의 입력으로 남겼습니다.
검증도 같이 했습니다. 문법 검사, 자체 테스트, Hermes runtime 동기화, 실행 리포트, 추적표 반영까지 확인했습니다. 변경도 커밋으로 남겼습니다.
이번 사례에서 제가 좋았던 부분은, AI가 “제가 봤을 때 이게 문제입니다”에서 멈추지 않았다는 점입니다.
이제는 이렇게 동작합니다.
“이건 내가 고쳐도 되는 낮은 위험입니다. 처리했습니다.”
“이건 중간 위험이지만 롤백 가능해서 처리했습니다.”
“이건 코드 문제가 아니라 사용량 제한입니다. 조용히 provider를 바꾸지 않겠습니다.”
“이건 위험합니다. 승인 없이는 실행하지 않겠습니다.”
이 차이가 꽤 큽니다.
왜 만들었나
제가 원한 것은 더 많은 자동화가 아니었습니다.
이미 자동화는 충분히 많았습니다. 문제는 자동화가 실패했을 때, 그 실패를 사람이 다시 해석해야 한다는 점이었습니다.
그래서 이번 목표는 “자동화 추가”가 아니라 “자동화가 스스로 운영되는 구조”였습니다.
AI가 로그를 읽고, 문제를 분류하고, 안전한 건 처리하고, 위험한 건 질문하고, 그 결과를 다음 실행에 남기는 것.
이 정도까지 와야 개인 AI 비서가 단순한 챗봇을 넘어 운영 파트너에 가까워진다고 느꼈습니다.
아직 남은 점
물론 이것도 완성형은 아닙니다.
아직 HIGH 위험 변경은 자동 실행하지 않습니다. 새 cron을 만들거나, 발송 정책을 바꾸거나, provider fallback을 바꾸는 일은 반드시 사람이 승인해야 합니다.
또 timeout이 반복되는 작업은 단순히 시간을 늘리는 것만으로 해결되지 않습니다. 작업 을 쪼개고, 중간 결과를 저장하고, 다음 턴에서 이어받는 구조가 더 중요합니다.
이번에 만든 self-improver는 그 방향으로 가기 위한 첫 실행 루프입니다.
이제 제 AI 시스템은 문제가 생겼을 때 그냥 “실패했습니다”라고 말하지 않습니다.
적어도 이렇게 말할 수 있습니다.
“무엇이 실패했는지 봤고, 위험도를 나눴고, 처리 가능한 건 처리했고, 나머지는 추적표에 남겨 다음 실행으로 넘겼습니다.”
저는 이게 AI 자동화의 다음 단계라고 생각합니다.
더 똑똑한 답변보다, 더 책임 있게 이어지는 실행이 필요합니다.
