안녕하세요, まさきん입니다.
이전에 AI와 freee를 조합해서 가계를 매일 아침 돌아보는 구조를 소개했습니다. 이번에는 그 밤 버전입니다. 그날 쓴 카드 이용 내역을, 자기 전에 AI가 자동으로 체크해주는 구조에 대해 씁니다.
아침의 리뷰가 “어제 경향에서 깨달음 하나”라면, 밤의 구조는 조금 성격이 다릅니다. “오늘, 확인해두는 게 좋을 지출이 있는가”를 그날 안에 파악하기 위한 구조입니다. 이번에는 판정 규칙의 수식이나 실행 시의 세세한 제어까지 포함해서 소개합니다.
계기는 “큰 지출일수록 미뤄지기 쉽다”는 것
일상의 소소한 지출은 가계부 앱에 자연스럽게 기록됩니다. 다만 한 번에 큰 지출은 다릅니다. “나중에 이야기하자”고 생각하는 사이에 잊어버리는 경우가 있습니다.
그래서 금액이 큰 지출만 골라 건져내어, 그날 안에 인지할 수 있게 하는 구조를 만들었습니다. 이 구조는 사람이 직접 실행하는 것이 아니라, 정해진 시각에 자동으로 실행되는 “스케줄 작업”으로 동작하고 있습니다.
자동 실행이기 때문에 신경 쓰는 것
정해진 시각에 자동으로 움직이는 이상, 그 자리에서 사람에게 확인받을 수 없습니다. 그래서 실행의 전제로 다음과 같은 규칙을 두고 있습니다.
- 중간 어딘가의 데이터 가져오기가 실패해도, 그 자리에서 처리를 멈추지 않고 나머지를 계속한다
- 판단이 어려운 경우는 무리하게 파고들지 않고 스킵해서 로그에만 남긴다
- 외부 API 가져오기가 실패한 날은 통상적인 집계를 포기하고 간단한 리뷰로 폴백한다
자동 실행 작업은 “완벽하게 동작하는” 것보다 “매일 반드시 뭔가 결과를 남기는” 것을 우선하는 설계로 하고 있습니다.
지출을 3종류로 나눠서 다룬다
모든 지출을 같은 기준으로 체크하면 알림투성이가 되어 오히려 안 보게 됩니다. 그래서 지출을 다음 3종류로 나눠서 다루고 있습니다.
| 종류 | 내용 | 체크 대상인가 |
|---|---|---|
| 고정비·구독 | 매달 거의 같은 금액이 발생하는 지불 | 대상 외(제외) |
| 사전에 합의된 큰 지출 | 미리 가족끼리 이야기한 지출 | 대상 외(제외) |
| 그 외 지출 | 돌발적·재량적인 지출 | 체크 대상 |
고정비는 매달 같으므로 매번 체크해도 의미가 없습니다. 사전에 합의된 지출도 이미 논의를 마쳤으므로 알림이 필요 없습니다. 체크해야 할 것은 그 외 “그 자리에서 발생한 지출”뿐입니다.
고정비의 대표는 집세거나 통신비입니다. 금액이 거의 변하지 않기 때문에 매일의 체크 대상에서 빼두는 것입니다.
구독 판정에서 헷갈리는 업체, 즉 단발성인지 정기 구매인지 판단이 안 되는 경우는 무리하게 “구독”에 포함시키지 않고 “판정 보류”로 따로 한 줄 기록하도록 하고 있습니다. 여기를 애매하게 넘기면 나중에 집계 전체의 신뢰성이 흔들린다고 느낍니다.
다만 체크에서 뺀 지출에도 예외는 있습니다. 통신비 같은 고정비일수록 가끔 재검토할 가치가 있다고 느낍니다. 일상의 감시는 자동화할 수 있어도, 고정비의 수준 자체는 스스로 움직일 수밖에 없습니다.
”상담해야 할 지출”의 판정 규칙
체크 대상 지출 중 일정 금액을 넘는 것만 “상담해야 할 지출”로 다루고 있습니다. AI에게 전달하고 있는 지시를 일반화해서 소개합니다.
오늘의 카드 이용 내역에서 다음 절차로 "상담해야 할 지출"을 추출해주세요.
1. 고정비·구독으로 분류된 거래는 제외한다
2. 사전 합의 목록에 등록된 거래는 제외한다
3. 남은 거래 중 1건당 일정 금액(기준 1만 엔) 이상인 것을 추출한다
4. 추출한 거래는 "금액" "이용처" "시각" 세 항목으로 나열한다
일정 금액을 넘는 거래가 없으면 "오늘은 해당 없음"이라고만 답할 것.
기준이 되는 금액은 가정마다 적절한 수준이 다를 것입니다. 중요한 것은 “얼마인가”보다 “사전에 기준을 정해둔다”는 것이라고 느낍니다. 기준이 없으면 결국 나중에 “이건 상담해야 했나”를 매번 논의하게 됩니다.
동기화 지연을 수치로 다룬다
가계부 SaaS의 카드 연동은 며칠 정도의 반영 지연이 일상적입니다. 연휴가 끝난 뒤에는 더 늦어집니다. 이를 “이상”으로 취급하면 알림이 오탐투성이가 됩니다. 그래서 지연을 다음 지표로 수치화하고 있습니다.
latest_txn_date: 그 카드에서 가장 최근에 관측된 거래 날짜lag_days: 오늘 날짜 −latest_txn_date(일수)lag_status:lag_days의 크기로부터 다음 4단계로 분류한다
| 상태 | 기준 일수 | 의미 |
|---|---|---|
| normal | 2일 이내 | 통상적인 반영 지연 범위 |
| watch | 3~4일 | 연휴 뒤 등으로 지켜보는 단계 |
| delayed | 5~9일 | 장기 휴가 등으로 일어날 수 있는 지연 |
| stalled | 10일 이상 | 장기간 거래가 반영되지 않은 상태 |
포인트는 stalled, 즉 장기간 미반영을 즉시 “연동 오류”로 단정하지 않는 것입니다. 단순히 “그 카드를 잠시 안 쓰고 있을 뿐”인 경우가 실제로는 더 많기 때문입니다.
”안 쓰고 있을 뿐”과 “연동 오류”를 구분한다
stalled가 관측되면 단정하기 전에 지난 30일간의 거래 패턴을 확인합니다.
- 지난 30일 중 1건 이상 거래가 있고, 최근만 10일 이상 비어 있다 → 단순한 장기 미사용. 연동 자체는 살아있음
- 지난 30일간 거래가 완전히 0건이고, 실제로는 사용한 기억이 있다 → 연동 오류를 의심
다만 후자만으로도 즉시 “오류”로 단정하지 않습니다. 다음 3조건이 모두 갖춰졌을 때 비로소 연동 오류로 취급합니다.
- 여러 카드에서 동시에
stalled가 발생하고 있다 - 실제로 사용한 기록(영수증이나 메모 등)이 따로 남아 있는데 가계부 SaaS에는 나타나지 않는다
- 가계부 SaaS 쪽 화면에서 동기화 오류 표시를 눈으로 확인할 수 있다
3조건이 갖춰지지 않는 한, “N일간 카드를 쓰지 않음(절약 경향의 지속)“으로 중립적으로 취급하고, 함부로 알림을 내지 않도록 하고 있습니다. 이 구분을 넣기 전에는 단순히 안 쓰고 있을 뿐인 카드에 대해 “연동이 망가진 게 아닐까”라고 매번 불안해했습니다.
외부 API 호출 횟수에 상한을 둔다
자동 실행 작업이므로, 어떤 계기로 무한히 API를 계속 호출하는 루프에 빠지지 않도록 1회 실행당 호출 횟수에 상한을 두고 있습니다.
- 통상적인 패턴, 즉 당일분 가져오기·월초부터의 누적 가져오기 등으로 미리 예상되는 호출 횟수를 계산해둔다
- 예상 밖의 오류가 발생해도 상한 횟수에 도달하면 재시도를 멈추고 즉시 “가져오기 실패”로 폴백한다
- “횟수 상한에 도달했으므로 처리를 중단한다”는 것을, 타임아웃을 기다리는 것보다 우선한다
상한을 정해두지 않으면 인증 오류 등이 발생했을 때 재시도를 반복해서 불필요한 요청을 계속 보내는 위험이 있습니다. 자동 실행 구조일수록 이런 안전장치가 필요하다고 느낍니다.
”이상이 계속되고 있다”와 “새로운 이상”을 구분한다
이번 달 지출이 목표의 일정 비율을 넘었을 때 알리는 규칙을 넣어두었는데, 이를 그대로 매일 밤 알림에 쓰면 한 번 초과한 뒤로는 월말까지 매일 밤 같은 알림이 계속됩니다. 이러면 “새로 기준을 넘긴 날”과 “이미 초과한 상태가 계속 초과 중인 날”을 구분할 수 없습니다.
그래서 초과가 며칠째 계속되고 있는지 세어서 “초과 지속 ◯일째”라는 형태로 덧붙이도록 하고 있습니다. 신규 이상과 지속 중인 이상을 구분할 수 있으면 주 단위로 돌아볼 때도 상황을 정확히 파악하기 쉬워집니다.
알림은 일부러 무덤덤하게 하고 있다
“상담해야 할 지출”이 발견된 날도 알림은 담담한 내용으로 하고 있습니다. 금액과 이용처를 제시할 뿐, 좋고 나쁨의 판단은 하지 않습니다.
판단하는 것은 저희 자신입니다. AI의 역할은 “놓칠 수 있는 지출을 깨닫게 하는 것”까지라고 선을 긋고 있습니다.
해보고 느낀 점
가장 큰 효과는 큰 지출에 대해 “말했다 안 했다”가 없어진 것입니다. 그날 안에 정보가 공유되므로 이야기할 타이밍을 놓치기 어려워졌습니다.
한편 기준 금액 설정은 처음부터 완벽하게는 되지 않았습니다. 너무 낮으면 알림이 너무 많아져 형식적으로 흘러가고, 너무 높으면 의미 있는 지출을 놓칩니다. 몇 번 조정해서 지금 수준에 안착했습니다.
이런 분에게 추천합니다
- 가계부 앱으로 카드 연동은 하고 있지만 큰 지출 공유에 시간차가 있는 분
- 가족끼리 “지출 상담 기준선”을 명확히 하고 싶은 분
- 자동 실행 작업의 오탐·과탐을 꾸준히 튜닝해나가는 작업을 마다하지 않는 분
정리
고정비와 합의된 지출을 제외하고, 그 외 큰 지출만 건져낸다. 이 단순한 좁히기가 알림을 형식적으로 만들지 않는 요령이라고 느낍니다.
동기화 지연을 수치화해서 “안 쓰고 있을 뿐”과 “오류”를 구분하는 시각, API 호출 횟수에 상한을 두는 안전장치, 둘 다 소소하지만 자동화를 안정적으로 계속 돌리는 데 효과가 있다고 실감하고 있습니다.
이 구조가 건져내는 것은 어디까지나 변동하는 지출입니다. 반면 통신비 같은 고정비는 성격이 다릅니다. 매번 체크하기보다 한 번 재검토하는 쪽이 효과가 오래가지 않을까요. 자동화와 병행해서 그쪽에도 눈을 돌려보려고 합니다.
이 글에는 제휴 광고가 포함되어 있습니다. 이 사이트의 링크를 통해 상품·서비스에 신청하시면 제휴사로부터 보상을 받을 수 있습니다. 또한 운영자는 라쿠텐 그룹 소속 직원으로, 사원 추천 프로그램을 통해 보상을 받는 경우가 있습니다. 기사 내용과 평가는 광고 유무와 관계없이 운영자의 실제 경험과 조사를 바탕으로 작성했지만, 위 관계를 이해하신 후 읽어 주시기 바랍니다. 자세한 내용은 면책조항·제휴 링크 안내를 참고해 주세요. 면책조항·제휴 링크 안내
이 글에는 기계 번역이 포함되어 있습니다. 정확한 조건은 라쿠텐 모바일 공식 사이트의 다국어 페이지에서 확인해 주세요.
라쿠텐 모바일의 통신 지역·전파 상황이 궁금하신 분은, 공식 전파 개선·조사 요청 양식 을 통해 문의하실 수 있습니다.