Claude Code 루틴이 내 재정을 지켜볼 수 있을까?

• 금융 계좌 데이터와 MCP 커넥터를 연결하면 잔액, 거래내역, 투자, 대출 정보를 바탕으로 반복적인 재무 점검을 프롬프트만으로 자동화할 수 있음
• 기존의 Codex CLI cron-job 방식은 웹 로그인, 브라우저 렌더링 문제, 2FA, passkey 제한 때문에 자주 깨졌고 계좌별 점검이 안정적으로 이어지기 어려웠음
• 다시 구성한 일일 이메일 자동화는 아침 스케줄과 custom connector, email_me() 도구를 조합해 모든 계좌와 순자산을 정리해 보내도록 만들었고, 프롬프트만 조정해 내용도 바꿀 수 있음
• 거래 감시 자동화는 이상 거래와 큰 유출을 최근 패턴과 비교해 찾아내고, 조건에 맞을 때만 이메일을 보내도록 설정해 불필요한 알림을 줄여줌
• 이런 방식은 개인 맞춤형 운영 자동화를 매우 낮은 비용으로 빠르게 시험하고 확장하게 만들며, 실시간 데이터에 연결된 재무 점검을 비개발자도 직접 다룰 수 있게 해줌

---

자동화 구성 방식

• Driggsby는 Plaid로 금융 계좌에 연결한 뒤, MCP를 통해 잔액·거래내역·투자 정보·대출 정보 같은 도구를 노출함
• 처음에는 Claude에서 필요할 때마다 질문을 던지는 대화형 사용이 중심이었지만, 순자산 확인·잔액 검토·거래 모니터링처럼 반복되는 패턴이 드러남
• Claude Code routines는 이런 반복 작업을 프롬프트만으로 자동화하기 쉽게 만듦
  • 별도의 agent loop 코드 작성이나 배포 환경 준비 없이 프롬프트와 MCP 커넥터만 연결하면 동작 가능함
  • 데이터와 도구를 MCP 커넥터로 깔끔하게 연결할 수 있으면 자동화 구성이 가능해짐

기존 방식의 한계와 전환

• 이전에는 비대화형 Codex CLI cron-job으로 은행·신용카드·증권·은퇴 계좌에 로그인해 잔액과 최근 거래를 가져오고, 일일 금융 개요 이메일을 보내도록 구성했음
  • Chrome DevTools MCP를 사용해 각 웹사이트에 로그인하고 정보를 추출했음
  • 일일 금융 개요 이메일을 부부에게 보내는 단순한 작업이었지만 실제로는 자주 깨졌음
• 다음 날 바로 실패하는 일이 반복됐고, 브라우저 렌더링 문제나 예기치 않은 2FA 요청 때문에 계정 단위로 동작이 중단되곤 했음
  • GPT가 이메일 형식을 완전히 바꾸거나, 실행 중 헷갈려 한 계좌 정보만 가져오는 경우도 있었음
  • 새로 추가해야 했던 계좌 중에는 passkey 로그인만 허용하는 경우도 있었음
• 이런 반복 장애 때문에 기대한 이메일이 오지 않을 때마다 직접 대응해야 했고, 그 과정을 덜 스트레스받게 만들기 위해 Driggsby를 구축하게 됨

일일 이메일 자동화

• 가장 먼저 다시 만든 것은 일일 이메일이었고, 목표는 모든 계좌와 순자산을 깔끔한 형식으로 요약해 매일 아침 받는 것이었음
  • 이 정보는 원래 Google Drive 어딘가의 오래된 스프레드시트에 있었음
  • 갱신에 15분 정도밖에 걸리지 않았지만 그 작은 마찰 때문에 자주 업데이트하지 못했고, 많아야 6개월에 한 번 정도만 갱신했음
• routines에서는 프롬프트 입력, 아침 스케줄 설정, Driggsby custom connector 연결만으로 초기 구성이 매우 쉽게 끝남
• 다만 처음에는 이메일을 보낼 방법이 없었고, Gmail connector를 붙이자 잘 정리된 초안만 생성됐음
  • Gmail connector는 실제 발송은 하지 못하고 draft만 만들 수 있었음
• 이를 해결하기 위해 Driggsby에 email_me() MCP 도구를 추가했고, 이 방식은 꽤 편리하게 작동함
  • 발송 대상을 계정 소유자의 검증된 이메일로만 제한하고 링크와 이미지를 막아 보안상 수용 가능한 수준으로 맞춤
  • 본문을 Markdown으로 강제하고, Markdown 렌더링 이메일에 CSS를 더해 실행마다 생기는 형식 불일치를 줄였음
• 몇 가지 작은 버그는 routines의 inspectability 덕분에 비교적 쉽게 고칠 수 있었음
  • UI가 Claude Desktop이나 웹 앱의 일반적인 Claude Code 세션처럼 보여, 실행 중 상태를 직접 살펴보기 쉬웠음
• 테스트를 거친 뒤 일일 이메일이 실제로 도착했고, 이후에는 이메일 내용 변경도 코드 수정 없이 routines UI에서 프롬프트만 조정하면 가능함
• 부부가 보는 항목이 달라서 각자 서로 다른 일일 이메일을 별도 프롬프트로 구성할 수 있게 됨

이상 거래와 지출 감시

• 일일 이메일이 자리 잡은 뒤에는, 별도 인프라 부담 없이 agent를 띄울 수 있다는 점을 활용해 더 많은 자동화를 붙이기 시작함
• 먼저 거래 데이터로 이상 거래 감시를 구성했고, 주간 실행 routine에서 Amex 신용카드 1년치 거래를 불러오되 최근 7일만 집중적으로 보도록 설정했음
  • 최근 7일 거래가 과거 패턴과 비교해 이중 청구, 구독료 변경, 낯선 가맹점 이름이나 설명처럼 예상 밖이라면 이메일을 보내도록 했음
  • 최근 7일 거래가 정상적이고 일관되면 알림을 보내지 않도록 제한했음
• 이런 단순한 프롬프트는 false positive를 만들 수 있지만, 시간이 지나며 다듬는 비용도 낮고 검토 비용도 낮아 보임
• 이어서 당좌예금 계좌에서는 큰 규모의 예상 밖 유출을 감시하는 routine을 만들었음
  • 최근 하루의 거래만 검토하고, 지난 12개월 패턴과 비교해 $500 초과 거래 중 큰 유출이나 이례적 유출을 찾도록 했음
  • 자동화가 매일 돌기 때문에 검토 범위를 최근 하루로만 강하게 제한했음
  • 조건에 맞는 항목이 있으면 제목이 "Checking account outflow alert"인 이메일을 보내고, 없으면 알리지 않도록 했음
• 이후 이 방식은 투자 모니터링, 구독 분석, 여러 지출 카테고리 감시로까지 확장됐음
  • routines로 설정하기가 매우 쉬워서, 시간이 지나면 여러 조건을 한 번에 묶거나 프롬프트를 더 정교하게 다듬을 필요가 커짐

왜 중요한가

• routines의 핵심 강점은 거의 노력 없이 시도할 수 있다는 점에 있음
  • 프롬프트가 떠오르면 바로 자동화를 실행할 수 있음
• 클라우드에서 live 데이터가 연결된 자동화를 비개발자도 직접 다룰 수 있다는 점이 두드러짐
  • CPA인 배우자도 Driggsby의 실시간 데이터를 끌어와 자기용 자동화를 직접 돌리고 있음
• 이런 사용 방식은 프롬프트와 커넥터만으로 개인 맞춤형 운영 자동화를 빠르게 만들 수 있게 함

[GN⁺]

Hacker News 의견들

• 최근에 직접 이렇게 구성해봤음. https://tiller.com/로 당좌/신용카드 거래를 Google Sheets에 동기화하고, GitHub Actions로 그 스프레드시트를 무료 Supabase DB에 미러링함
  Supabase MCP나 psql로 Claude/Codex가 거래내역과 잔액에 영어 질의로 접근하게 했는데, 구독 패턴이나 이상 패턴을 찾는 능력이 꽤 인상적이었음. 특히 온라인 도구들이 잘 못하는 현금흐름 예측도 괜찮았고, 예를 들어 월 지출 패턴과 가용 현금을 기준으로 얼마를 저축으로 옮겨도 되는지 물어볼 수 있었음
  자동 분류 쪽에서는 Claude가 커스텀 DSL을 꽤 잘 다뤘음. 수취인/카테고리 정규화를 위한 markdown 테이블 규칙셋을 만들게 했고, 그 규칙도 GitHub Actions에서 함께 돌리고 있음

  • Tiller가 은행 거래 데이터를 어떻게 가져오는지 궁금함
    Plaid 같은 걸 통해 끌어오는지, 여전히 웹뱅킹 자격증명을 넘겨야 하는지, 2FA는 어떻게 처리되는지 알고 싶음
    정식 API가 없는 금융기관에서는 아직도 스크린 스크래핑에 의존하는지, 버그로 의도치 않은 클릭이나 동의, 심지어 잘못된 송금 같은 일이 생기면 어떻게 되는지도 불안함. 읽기 전용이라고 하지만 개인 뱅킹에서 진짜 읽기 전용 보조 계정을 지원하는 은행은 거의 못 봤음
    대규모 금융 피해가 났을 때 배상받을 수 있도록 보험이나 보증이 있는지도 궁금하고, 은행 데이터 전체를 두 업체에 보여주는 프라이버시 함의도 걱정됨. 데이터가 부적절하게 판매·공유됐다는 집단소송 얘기도 들었는데 실제로 무슨 일이 있었는지 모르겠음
    은행 약관에서 비밀번호를 제3자와 공유하지 않겠다고 동의하는 조항도 걸림. 웹/클라우드 서비스에 내 금융을 맡기기엔 영 꺼림칙하고, 로컬에서 돌아가면서 은행 API와 통신하는 클라이언트 소프트웨어가 더 좋겠음. 캐나다에 그런 게 있는지도 궁금함
    오픈 뱅킹이 온다고는 하는데 개인이 직접 만든 소프트웨어로 접근 가능한지도 불분명함. 정말 신뢰할 수 있고, 내려받은 뒤 내부 보관을 최소화하는 정책까지 강제된다면 나도 은행 API를 쓰고 싶음
  • 나도 Tiller에 한 표임
    Mint가 Intuit에 인수된 뒤부터 Tiller를 써왔고, 비슷한 구성을 하고 있음. 다만 나는 로컬 qwen 모델과 OAuth로 만든 API 키로 sheets 접근을 붙였는데, Claude Routine 방식이 훨씬 쉬웠을 듯함
  • 이거 정말 멋짐. 혹시 오픈소스로 공개할 계획이 있는지 궁금함
    전체 설정 방식이나, 특히 어떤 프롬프트를 쓰는지가 보고 싶음
  • 굳이 왜 밑단에서 그냥 Plaid를 안 쓰는지 궁금함

• 내 순자산이 적어서 그런지 몰라도, 솔직히 이게 왜 가치 있는지 잘 모르겠음
  LLM이 매일 이메일 보내는 것도 원치 않고, 투자 현황을 분기보다 자주 봐야 한다면 오히려 더 안전한 투자로 가야 할 것 같음. 예산 관리 도구에는 조금 관심 있지만, 그건 완전히 결정론적이길 바람
  내 재무 계획은 대체로 평온한 편이라, 지금보다 더 지출 최적화에 시간 쓰느니 연봉 더 높은 직장을 찾는 게 낫다고 봄

  • actualbudget.org로 모든 지출을 추적하지만, 투자 계정은 한 달에 한 번만 갱신함
    숫자와 관련된 건 원래 완전히 결정론적이어야 한다고 생각함
    LLM에게 SQLite DB를 보여주고 지난 5년 거래에서 보이는 걸 말해보라고 했더니, 포착한 내용이나 상기시켜준 것들은 인상적이었음. 다만 실제로 내가 뭘 바꾸게 되는 실질적 가치가 있었는지는 잘 모르겠음
    한동안 월별로 검토하게 해보려 하지만, 예산 업데이트만 해도 재무 상태는 대체로 이미 알고 있어서 얼마나 도움될지는 미지수임
  • Actual Budget + SimpleFIN 조합으로 은행 거래를 가져와본 적 있는지 궁금함
    나는 그걸로 신용카드와 당좌계좌를 추적하고 있고, 원하면 거기에 MCP를 연결해서 한곳의 데이터를 분석할 수도 있음
  • 고맙고, 반대로 뭐가 있으면 관심이 생길지 궁금함

• 캐나다 거주자고 추적용으로 https://lunchmoney.app/를 Plaid 연동과 함께 쓰고 있음
  API가 있어서 LLM으로 CLI를 짜게 했고, 그 덕분에 에이전트가 필요한 데이터를 거의 마음대로 가져갈 수 있음
  또 하나 시킨 일은 태깅 규칙들을 쌓는 것이었고, 그건 하루 한 번 cron으로 돌림. 가끔 규칙을 훑어보게 해서 미분류 거래용 새 규칙도 만들게 함
  LLM이 작업을 규칙 엔진이나 코드로 메모화하게 만드는 패턴은 꽤 좋다고 봄. 일단 질의 가능한 CLI만 생기면 에이전트에게 거의 뭐든 시킬 수 있음

  • Lunch Money 창업자인데, 이렇게 써줘서 반가움
  • 주된 사용 사례가 무엇인지 궁금함

• 관심 있는 사람들을 위해 우리 인프라/보안 구성의 큰 그림을 공유하겠음
  백엔드와 CLI는 엄격히 linting된 Rust이고, 웹앱은 Axum 위에서 돌아가며 Postgres엔 sqlx로 연결함
  금융 기능은 읽기 전용임. 이체·납부·송금 도구가 없고 AI 표면에서도 돈을 움직일 수 없음
  Plaid에서는 거래, 투자, 부채만 요청하며 auth/transfer/payment initiation은 요청하지 않아서 전체 계좌번호나 라우팅 번호는 받지 않고 기본 last-4 mask만 받음
  은행 사용자명과 비밀번호는 우리를 거치지 않고 Plaid Link로 가며, 우리는 기관별 access token만 보유함
  Plaid access token은 별도 DB에 두고 단일 custody Cloud Run 서비스 뒤에 둠. 저장 시 Cloud KMS로 암호화되고, broker가 KMS encrypt/decrypt 엔드포인트를 호출하며 루트 키 재료는 Google HSM 경계를 벗어나지 않음. broker 서비스 계정만 암복호화 권한이 있고 웹앱은 그 DB를 읽을 권한이 없음
  모든 암복호화 호출에는 Plaid item ID를 AAD로 넘겨서 한 아이템의 암호문을 다른 아이템 토큰으로 바꿔 복호화할 수 없게 함
  각 Cloud Run 서비스는 저마다의 클라우드 ID와 DB role로 실행되고, 서비스 간 내부 호출도 짧은 수명의 identity token으로 인증함
  운영 DB는 public IP가 없고, 비밀값은 소스나 컨테이너 이미지가 아니라 관리형 secret storage에 둠
  AI connector는 OAuth 2.1 + PKCE이고 사용자별 scope를 가지며 UI에서 revoke 가능함. 모든 tool call에는 도구 이름, 정제된 인자, 호출 클라이언트, 에이전트가 제시한 이유를 기록해서 LLM이 사용자를 대신해 무엇을 요청했는지 볼 수 있음
  AI 표면에는 fetch-URL, shell, 범용 I/O 도구가 없고, 구조화된 금융 데이터만 반환함. 네트워킹, IAM, DB grant는 모두 Terraform으로 관리하고 인프라 변경도 그 경로로만 진행함
  인프라 접근은 2FA와 보안 키로 통제함

  • 이런 기술적 세부사항을 실제로 공개해줘서 고마움
    이 사이트 독자층을 이해하고 있다는 느낌이 들고, 보안을 각 계층에서 세심하게 설계한 점도 전체 도구에 대한 신뢰를 높여줌
    나도 비슷한 걸 직접 만들어보려 했는데, 초반 MVP는 명세서 PDF를 수동으로 내려받아 Claude로 plain text 회계를 위한 ledger를 세팅하는 정도였고 나중에 Plaid를 붙일 생각이었음
    특히 Plaid를 사람들이 어떻게 쓰는지가 궁금함. 시작하려면 일정 수준 사용자 수가 필요한지, 그냥 내 개인·사업 계좌를 깔끔한 API에 연결하려고 개인 용도로 Plaid 계정을 만들 수 있는지 알고 싶음
  • 제품 기술 세부사항이나 Show HN 글을 공유한 사람을 굳이 다운보트할 거면, 적어도 이유는 밝혀줬으면 함

• Routine을 쓸 때는 조심해야 함
  거의 눈에 안 띄는 작은 안내문이 있는데, routine 모드에서는 MCP 도구가 쓰기 권한까지 포함해 항상 허용됨. 그래서 에이전트가 기술적으로는 멋대로 리소스를 바꿔버릴 수도 있음

  • 맞음. 이런 도구를 쓸 때는 늘 프롬프트 인젝션을 염두에 둬야 함

• 이건 문제를 찾는 해결책처럼 보임. https://tiller.com/만으로도 충분히 잘 되고, 스프레드시트에서 원하는 계산을 다 할 수 있으며, 보너스로 환각도 없음
  읽어야 할 장황한 LLM 요약을 굳이 왜 원하는지도 잘 모르겠음. 지출을 가끔씩 직접 분류만 해도 이상치는 금방 눈에 들어오고, Tiller면 그 작업도 쉬움

  • 처음엔 나와 아내를 위해 직접 만든 거라서, 결국 우리에게 필요하고 원하는 걸 만든 셈임
    이 분야에는 정말 다양한 제품이 나올 거고, 우리 제품은 그중 하나의 접근일 뿐임. 이런 시도가 많아지는 건 나도 좋게 봄
  • 핵심은 요약문 자체가 아님
    LLM이 여러 데이터 소스를 쉽게 흡수하고 결합할 수 있다는 점이 더 큼

• 우리 Era Finance는 이걸 정확히 겨냥한 솔루션을 만들고 있음. 호환되는 어떤 에이전트든 개인 재무와 연결하는 MCP인 Era Context이고, https://era.app에서 볼 수 있음
  지금은 읽기 도구에 집중하고 있지만, 돈 이체나 부채 상환 같은 쓰기 도구도 준비 중임
  원하는 기능이 있으면 위 도메인의 alex로 메일 달라고 하고 싶음. 참고로 나는 CEO Alex이고, HN은 거의 처음이지만 예전엔 stripe.com 웹 프레즌스 책임자였고 그전엔 Square/CashApp에 있었음

  • 흥미로워 보이고, 지금 바로 써보는 중임

• 아마 이미 싸움은 진 건지 모르겠지만, 대체 왜 전체 금융 거래내역을 LLM에 맡기고 싶은지 모르겠음
  LLM 제공업체가 이런 데이터 사용에 대해 금융업계보다 더 강한 보호장치를 갖췄을 것 같지도 않음. 금융업계 자체도 우리 데이터를 수집·채굴·판매하는 가혹한 산업인데 말임

  • 적어도 내가 하는 가장 큰 이유는, 인사이트가 실제로 꽤 유용하기 때문임
    지출 패턴이나 투자에 관심이 있는 입장에선 아주 기본적인 프롬프트만으로도 기존엔 놓쳤던 것들을 발견한 적이 있음
    물론 이걸 안전하게 만드는 건 매우 어렵고, 그래서 그 부분을 엄청 오래 고민하고 있음
  • 이 경우 제작자가 이미 전부 읽기 전용이라고 설명했음
    그럼 정확히 뭐가 문제인지 잘 모르겠음
  • 왜 안 되는데? 내 삶에 구체적으로 어떤 악영향을 줄 수 있는지 궁금함

• 내 주거래 은행인 영국 Monzo는 전체 API와 이벤트용 trigger webhook을 제공함
  덕분에 비정상 거래가 생기면 이유를 설명하라고 묻는 WhatsApp 봇을 만들 수 있었고, LLM은 그 추론에만 사용함. 또 매일 자정 전 잔액을 저축 계좌로 쓸어 담아 일일 이자를 최대화하는 자동화도 해뒀음
  일상 계좌에는 소액만 유지하고, 낮에 돈을 쓰면 저축에서 다시 채워 넣어 그 낮은 잔액을 유지함. 더 큰 지출이 필요하면 그때는 수동으로 옮김

  • 정말 멋짐. 이런 건 오픈소스로 공개해줬으면 좋겠고, 미국에도 이런 환경이 있으면 훨씬 쉬워질 텐데 아쉬움

• Claude로 과거 거래를 분석하려고 했을 때, 존재하지 않는 청구를 만들어내거나 새 항목을 추가하고 중복 집계하는 식의 환각이 계속 있었음
  재무를 다룰 때는 Claude가 95% 맞는 수준으로는 부족함. 항상 경계하면서 결과를 검토해야 하니, 내 경우엔 사실상 가치가 없어짐

  • Codex의 GPT도 한번 써보길 권함
    나도 Claude가 특히 불완전하거나 제한된 데이터셋에서 환각을 꽤 잘 일으킨다고 느낌