“자동화는 만들었는데, 매일 안전하게 돌게 하려면?” — Hermes 스킬로 가계부를 운영한 날

📝 한줄 요약

지난번에 네이버페이 영수증을 버튼 한 번으로 모으는 기능까지 만들었습니다. 이번에는 그 기능을 매일 돌릴 수 있게 만들었습니다. 대신 금융·메일 데이터를 다루는 경계는 더 까다롭게 정했습니다. AI에게 “메일을 읽어와”라고 맡기는 일이 아니라, 사람이 정한 절차를 매일 같은 방식으로 실행하게 하는 Hermes 스킬을 만든 것입니다.

바쁘시면 이것만 읽어도 돼요:

• 스킬은 AI의 기억이 아니라, 반복 작업의 안전한 절차서였다

• 메일은 새 지출을 자동으로 만드는 재료가 아니라, 기존 거래를 확인하는 증거로만 썼다

• “최근 메일 몇 건” 대신 날짜 범위를 정해 수집해야 자동화가 예측 가능해졌다

• 비밀번호 입력과 로그인 판단은 자동화하지 않고, 사람이 직접 로그인하도록 남겼다

• cron은 localhost에서만 움직이고, 대시보드는 Tailscale 전용 경로로 따로 열었다

• 첫 7월 갱신에서 90건을 확인해 12건의 새 증거를 저장하고 14건을 기존 거래에 연결했다

🎯 이런 분들께 도움돼요

• 개인 데이터를 다루는 자동화를 매일 돌리고 싶지만 불안한 분

• AI에게 일을 맡기되, 어디까지 자동으로 맡길지 정하고 싶은 분

• 만든 개인 앱을 노트북 한 대의 테스트에서 벗어나 실제 운영으로 옮기려는 분

😫 문제 상황 (Before)

지난 편까지 제 가계부 앱은 이미 꽤 많은 일을 했습니다. 거래를 모으고, 규칙으로 분류하고, 네이버페이 영수증도 브라우저 자동화로 받아왔죠.

그런데 “기능이 있다”와 “매일 믿고 쓸 수 있다”는 다른 문제였습니다.

매달 또는 며칠마다 직접 버튼을 누르면 됩니다. 하지만 자동으로 돌리려면 질문이 늘어납니다. 어느 기간까지 읽을지, 로그인 만료 때 무엇을 할지, 메일을 읽음으로 바꾸지 않을지, 찾은 주문 정보를 새 지출로 만들어도 되는지, 다른 Mac에서 대시보드를 볼 때 내부 자동화가 노출되지는 않는지 같은 질문입니다.

이번 작업의 출발점은 아주 단순했습니다.

자 이제 현재 맥의 헤르메스 데스크톱을 본격적으로 사용하려고 하는데 우선 스킬을 만들고 싶어.
스킬을 만들기 전에 스킬이 뭔지 자세히 설명해줘

🛠️ 사용한 도구

• Hermes Desktop: 작업 절차를 스킬로 만들고, Mac mini의 cron을 운영

• Next.js + SQLite: 기존 가계부 서비스와 증거 데이터 저장

• Playwright + 전용 Chrome 프로필: 네이버 웹메일을 읽기 전용으로 확인

• macOS launchd: Mac mini에서 가계부 서버를 재시작 후에도 실행

• Tailscale Serve: 다른 Mac에서만 대시보드에 안전하게 접근하는 HTTPS 경로

🔧 작업 과정

스킬은 “기억”이 아니라 “같은 기준으로 다시 하는 방법”

처음엔 스킬이 AI의 메모리와 비슷한 것이라고 생각했습니다. 그런데 실제로 써보니 더 가까운 것은 체크리스트가 있는 작업 매뉴얼이었습니다.

예를 들어 네이버 메일 수집 스킬에는 이런 기준이 들어갑니다.

• 먼저 가계부 서버가 살아 있는지 확인한다

• 날짜 범위를 KST 기준으로 계산한다

• 제공자별로 읽을 페이지 수를 작게 제한한다

• 전체 백필은 기본 작업으로 호출하지 않는다

• 메일을 발송·삭제·이동·라벨 변경·읽음 처리하지 않는다

• 이메일만 보고 새 원장 거래를 만들지 않는다

• 화면이나 알림에는 메일 원문·주문번호·쿠키·비밀번호를 보이지 않는다

이렇게 정리하니 “AI가 알아서 잘하겠지”가 아니라, 사람이 정한 경계를 매번 다시 확인하는 자동화가 됐습니다.

“최근 30건”보다 “7월 1일~25일”이 중요한 이유

메일 자동화를 만들 때 가장 먼저 부딪힌 문제는 범위였습니다. “최근 30건을 읽어”는 얼핏 간단해 보이지만, 메일이 많이 오면 필요한 날짜의 결제가 뒤로 밀릴 수 있습니다. 반대로 전체 메일을 다시 훑는 방식은 느리고 예측하기 어렵습니다.

그래서 수집 단위를 날짜로 정했습니다. 자동 실행은 최근 며칠을 겹쳐 보되, 중복은 이미 있는 증거인지 확인해 건너뜁니다. 처음 시작하는 달은 사람이 날짜를 명시합니다.

우선 이번이 처음 시작하는거니까 7월1일부터 25일까지는 지금 수집해서 갱신해줘

범위를 직접 적으니 작업도 분명해졌습니다. AI는 모호한 “이번 달”이 아니라, 2026년 7월 1일~25일을 기준으로 움직였습니다. 어느 메일을 어디까지 볼지, 나중에 무엇을 검토할지도 함께 정해졌습니다.

자동화가 하면 안 되는 일부터 정했다

개인 금융 데이터는 “더 많이 자동화할수록 좋다”는 식으로 다루면 안 됐습니다.

메일에서 결제 내역을 찾았다고 해서 새 지출 거래를 만들지는 않았습니다. 이메일은 카드나 은행 거래에 붙이는 구매 증거일 뿐입니다. 환불인지, 여러 상품이 섞인 주문인지, 카테고리를 어떻게 나눌지는 결국 사람이 봐야 할 수 있습니다.

로그인도 마찬가지입니다. Mac mini에 전용 Chrome 프로필을 만들었지만, 네이버 로그인과 로그인 유지 선택은 제가 직접 했습니다. 자동화는 로그인된 상태를 이용해 읽기 전용으로 수집할 뿐, 비밀번호를 입력하거나 QR 로그인을 처리하지 않습니다. 로그인 세션이 없으면 짧게 실패하고 원인만 남깁니다.

이런 선을 남겨둬야 자동화가 편해져도, 마지막 판단은 여전히 사람이 할 수 있습니다.

실제로 돌려보기 — 7월 1일~25일

처음 범위 수집은 생각보다 오래 걸렸습니다. 요청 연결은 먼저 끝났지만, Mac mini 안의 수집 작업은 계속 진행 중이었습니다. 여기서 “응답이 없으니 실패했겠지”라고 단정하지 않고, 실행 상태와 집계를 따로 확인했습니다.

최종 결과는 다음과 같았습니다.

90건을 읽었다는 숫자보다, 새 증거 12건과 기존 거래 연결 14건이 더 의미 있었습니다. 이 작업은 장부를 새로 만들지 않고, 이미 있는 거래를 확인할 근거를 늘려줍니다.

막혔던 순간 — 대시보드는 열렸는데 cron이 깨질 뻔했다

수집이 끝난 뒤, 다른 Mac에서 대시보드를 보려 하자 연결이 되지 않았습니다.

잘 수집되었는지 가계부 대시보드에서 확인하려고하는데 연결이 안되네

원인은 단순했습니다. 가계부 서버가 localhost에서만 열려 있었기 때문입니다. 이건 cron에는 안전하지만 다른 Mac의 브라우저에서는 보이지 않습니다.

처음에는 서버를 Tailscale IP에 직접 열었습니다. 그러자 다른 문제가 생겼습니다. cron이 쓰던 localhost 경로가 사라진 것입니다. “대시보드를 보이게 한다”는 문제를 고치다가 “자동 수집의 안전 경로”를 깨뜨릴 뻔한 거죠.

해법은 서버를 두 방향으로 열어두는 것이 아니었습니다. 역할을 나눴습니다.

• 가계부 backend와 cron: 계속 localhost 안에서만 통신

• 대시보드: Tailscale Serve가 HTTPS로 받아 localhost backend에 전달

이렇게 하니 자동 수집은 외부 주소를 모른 채 안전하게 남고, 같은 tailnet의 제 Mac에서는 대시보드를 볼 수 있게 됐습니다. 문제 하나를 해결하려다 다른 경계를 무너뜨리지 않는 것, 이것도 운영 자동화의 중요한 부분이었습니다.

✅ 결과 (After)

검증한 것

• 날짜가 존재하지 않으면 수집 전에 거부되는 테스트 추가

• 전체 테스트 72개 파일·456개 통과

• lint, TypeScript 검사, production build 통과

• Mac mini의 localhost backend HTTP 200 확인

• 데스크톱에서 Tailscale 대시보드 HTTP 200 확인

• Hermes gateway와 매일 오전 8시 KST cron 등록 확인

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 자동화의 동사를 줄이기보다 경계를 먼저 쓴다. “메일을 수집한다”보다 “읽기 전용으로, 날짜 범위 안에서, 기존 거래의 증거만 연결한다”가 좋은 작업 정의였습니다.

2. 스킬을 반복 가능한 판단의 체크리스트로 쓴다. 기능 설명보다 금지할 행동과 실패 시 멈추는 조건을 적는 것이 더 중요했습니다.

3. 수집 결과와 HTTP 응답을 구분해 본다. 긴 작업에서 연결이 끝났다고 작업이 끝난 것은 아닙니다. 실제 DB 상태와 집계를 확인해야 합니다.

4. 접근 경로를 역할별로 분리한다. 사람이 보는 대시보드와 자동화가 부르는 내부 API를 같은 방식으로 열 필요는 없습니다.

이렇게 하면 안 돼요

1. 이메일만 보고 새 장부 거래를 만들지 않기. 중복, 환불, 혼합 주문처럼 메일만으로 확정할 수 없는 경우가 있습니다.

2. 로그인을 자동으로 처리하지 않기. 비밀번호나 QR은 자동화의 편의보다 사람의 확인이 우선입니다.

3. 전체 백필을 일상 cron의 기본값으로 두지 않기. 범위와 페이지를 제한해야 실패를 예측하고 점검할 수 있습니다.

4. 대시보드 접속을 위해 backend 전체를 넓게 노출하지 않기. 내부 자동화 경로와 UI 접근 경로를 나누는 편이 안전합니다.

🌍 다른 업무에 적용한다면?

이 방식은 가계부에만 쓰는 방법이 아닙니다. 메일·문서·주문내역처럼 민감한 정보를 정기적으로 확인해야 하는 업무에 적용할 수 있습니다.

1. 먼저 “자동으로 해도 되는 일”과 “사람이 끝까지 맡아야 하는 일”을 나눕니다.

2. 작업 절차를 스킬로 적고, 성공 조건보다 중단 조건과 금지 행동을 더 구체적으로 씁니다.

3. 범위를 날짜·대상·페이지처럼 측정 가능한 단위로 제한합니다.

4. 자동화의 내부 경로와 사람이 보는 화면의 외부 경로를 분리합니다.

5. 첫 실행은 반드시 사람이 결과를 보고, 그 다음에만 반복 일정을 등록합니다.

🚀 앞으로의 계획

다음은 등록된 cron이 첫 정기 실행을 마친 뒤, 결과 요약이 실제로 충분한지 확인하는 일입니다. 자동 연결되지 않은 증거는 대시보드에서 사람이 검토하고, 필요할 때만 외부 알림 범위도 별도로 정할 계획입니다.

이번 작업을 지나며 남은 결론은 간단합니다. AI가 메일을 읽는다는 사실보다, 사람이 정한 절차를 사람이 계속 확인할 수 있게 반복하는 편이 훨씬 중요했습니다.

📋 재사용 가능한 프롬프트

프롬프트 1: 민감한 정기 수집을 스킬로 만들기

[메일/문서/주문내역]을 정기적으로 확인하는 Hermes 스킬을 만들어줘. 자동으로 해도 되는 행동과 금지할 행동을 먼저 분리하고, 날짜 범위·수집량·로그인 만료 시 중단 조건을 명시해줘. 원문이나 인증정보는 출력하지 말고 집계만 보고하게 해줘.

프롬프트 2: 내부 자동화와 대시보드 접근을 분리하기

[내부 자동화 API]는 localhost에서만 호출하게 유지하고, 사람이 보는 대시보드는 [사설망/VPN]에서만 접근할 수 있는 별도 프록시로 열어줘. 두 경로가 서로의 보안 조건을 깨지 않는지 health check까지 검증해줘.

프롬프트 3: 장시간 수집 작업의 실제 완료 확인

[수집 작업]의 HTTP 요청이 끝나더라도 작업이 실제로 완료됐는지 DB 상태와 집계로 확인해줘. 실행 중이면 중단시키지 말고 완료까지 감시하고, 민감한 원문 없이 최종 카운터만 알려줘.