안녕하세요. まさきん입니다.
freee 회계(일본의 클라우드 회계 서비스)에 미처리 내역이 쌓여서 대사 작업이 진행되지 않는다. 그런 상태가 제 쪽에서 한동안 이어졌습니다. 그래서 월 1회 자동 작업으로 만드는 설계를 정했고, 정한 내용을 메모해 둡니다.
※ 글을 공개한 시점의 정보입니다. 최신 조건은 공식 사이트에서 확인해 주세요.
- 미처리 내역이 18건 정도, 주간 확인 6번 동안 건수가 움직이지 않은 채 남아 있었다
- 손이 멈추는 것은 건수보다, 망설여지는 내역이 섞여 있기 때문이 아닐까 생각했다
- 대사 작업은 매월 5일 아침 7:30에 집 Mac에서 돌리기로 정했다
- 내역은 3구분. 확정할 수 있는 분은 월 1건의 묶음 할 일, 망설여지는 내역과 대출 상환은 1건씩(월 15건까지)
- 회계 소프트웨어에 등록하는 일은 사람이 한다. 아직 설계를 정한 단계이고 구현은 이제부터
미처리 내역이 6번 동안 움직이지 않았다
저는 작게 이어 가고 있는 부업의 장부를 freee 회계로 쓰고 있습니다. 계좌와 카드 내역은 자동으로 불러와집니다. 나머지는 확인하고 등록하기만 하면 되는, 그럴 터였습니다.
그런데 미처리 내역이 18건 정도 남은 채로 있었습니다. 매주 확인할 때 건수를 봅니다. 그것이 6번 연속으로 움직이지 않았습니다.
매주 보고 있는데도 줄지 않는다. 이것은 “바빴다”로는 설명이 안 된다고 생각했습니다. 볼 자리는 있는데 손이 움직이지 않는 셈입니다.
손이 멈추는 원인은 망설여지는 내역
멈춰 있는 이유는 건수가 많아서가 아닐지도 모릅니다. 저는 그렇게 생각했습니다.
18건 가운데는 바로 등록할 수 있을 것 같은 내역도 있습니다. 한편으로 열 때마다 생각에 잠기게 되는 내역도 섞여 있습니다. 사업 지출인지 집안 지출인지. 영수증은 어디에 있는지. 그런 내역이지요.
망설여지는 1건이 맨 앞에 있으면 거기서 손이 멈춥니다. 그 뒤에 있는 쉬운 내역까지 함께 남아 버립니다. 그래서 섞은 채로 늘어놓는 것이 좋지 않은 게 아닐까 생각했습니다.
내역 분류에 대해서는 쇼핑몰 카드 내역에 입점 매장 이름이 나오지 않을 때의 분류 글도 있습니다. 이번에는 그보다 앞 단계인 순서와 나누는 방식 이야기입니다.
기존 대조 구조와의 역할 분담
내역과 메일을 AI로 맞춰 보는 구조는 이미 다른 글에 정리해 두었습니다. 부업 경비를 AI로 대조하는 구조입니다. 대조 방법은 그쪽에 맡깁니다.
이 글에서 다루는 것은 그 바깥쪽입니다. 언제 돌릴 것인가. 어디서 돌릴 것인가. 어디부터를 사람에게 넘길 것인가. 이 3가지를 정한 이야기입니다.
대조 구조가 있어도 돌리는 계기가 “마음이 내킬 때”라면 이어지지 않습니다. 저의 6번이 바로 그랬습니다. 그래서 정기 작업의 형태로 만듭니다.
기장은 매일이 원칙
먼저 전제를 확인해 둡니다. 월 1회로 몰아도 되는가 하는 점입니다.
일본 국세청의 “생활 세금 정보”에는 이렇게 적혀 있습니다. 소득을 바르게 계산해서 신고하려면 날마다의 거래 상황을 기장할 필요가 있다. 장부와 서류는 일정 기간 보존할 필요가 있다. 원칙은 어디까지나 날마다의 기장이지요.
그래서 저는 “월 1회 기장이면 된다”고는 생각하지 않습니다. 내역 불러오기와 주간 확인은 지금까지처럼 계속합니다. 월 1회로 하는 것은 망설여지는 내역을 판단하는 자리 쪽입니다.
- 공식 표현은 “날마다의 거래 상황을 기장”. 월 1회 기장이면 된다는 이야기가 아니다
- 월간 대사 작업은 쌓인 망설여지는 내역을 판단하기 위한 자리로 둔다
- 자기 장부 쓰는 방식이 불안할 때는 세무사나 세무서에 확인한다
월간 대사 작업에서 정한 것
정한 것을 먼저 나열합니다.
- 두는 곳은 집 Mac으로 한다
- 실행은 매월 5일 아침 7:30. 첫 회는 다음 달 5일
- 미처리 내역을 3구분으로 나눈다
- 확정할 수 있는 분은 월 1건의 묶음 할 일로 만든다
- 망설여지는 내역과 대출 상환은 내역마다 할 일 1건으로 만든다
- 내역 ID로 중복을 막고, 월 15건을 상한으로 한다
- 회계 소프트웨어에 등록하는 일 자체는 사람이 한다
모두 “정한” 단계입니다. 구현은 아직이고 돌려 본 결과도 없습니다. 그 부분은 마지막의 예정 절에 적습니다.
내역의 3구분
설계의 중심은 내역을 나누는 방식입니다.
| 구분 | 예 | 누가 처리 | 할 일의 형태 |
|---|---|---|---|
| 제안을 확정할 수 있는 분 | 대조가 맞고 계정과목에 망설임이 없는 내역 | 사람이 묶어서 확인하고 등록 | 월 1건의 묶음 할 일 |
| 판단이 필요한 내역 | 사업인지 가사인지 망설여지는 지출, 영수증을 찾지 못한 지출 | 사람이 1건씩 판단 | 내역마다 할 일 1건 |
| 대출 상환 | 매달 상환액의 자동 이체 | 사람이 1건씩 확인 | 내역마다 할 일 1건 |
확정할 수 있는 분은 1건씩 할 일로 만들지 않습니다. 묶어서 1건으로 합니다. 망설임이 없는 내역을 할 일 10개로 쪼개면 할 일 목록만 가득 찰 뿐이기 때문입니다.
반대로 망설여지는 내역은 1건씩 나눕니다. “이 1건을 어떻게 할까”만 생각하면 되는 형태로 만들고 싶습니다. 앞뒤에 다른 내역이 늘어서 있으면 또 손이 멈출 것 같습니다.
대출 상환을 별도 구분으로 둔 것은 다른 지출과 확인하는 내용이 다르기 때문입니다. 매달 반드시 오는 것이기도 합니다. 망설여지는 내역에 섞지 않고 정해진 형태의 할 일로 만들어 둡니다.
중복 방지와 월 15건 상한
1건씩 할 일로 만들면 걱정이 2가지 생깁니다.
하나는 중복입니다. 지난달 할 일이 남은 채로 이번 달 작업이 돌면, 같은 내역의 할 일이 하나 더 생겨 버립니다. 그래서 내역 ID를 표식으로 삼습니다. 같은 ID의 할 일이 이미 있으면 새로 만들지 않습니다.
또 하나는 양입니다. 망설여지는 내역이 한 번에 수십 건씩 할 일이 되면 그것만으로 열어 볼 마음이 사라집니다. 그래서 1건씩 만드는 분량은 월 15건 을 상한으로 했습니다.
15라는 숫자에 깊은 근거는 없습니다. 할 일 목록이 가득 차지 않기 위한 기준입니다. 돌려 보고 맞지 않으면 다시 볼 생각입니다.
등록은 사람이 한다는 선 긋기
AI에게 맡기는 것은 대조와 제안까지로 했습니다. 회계 소프트웨어에 등록하는 일 자체는 제가 화면에서 합니다.
이유는 2가지입니다. 하나는 freee 회계의 사고방식과 맞기 때문입니다. 공식 도움말에서는 내역에 대해 추측된 내용을 확인한 다음 등록하는 흐름을 안내하고 있습니다.
자동 등록 규칙에도 2종류가 있습니다. 공식 도움말에 따르면, 설정한 내용을 거래로 자동 입력할지 자동 등록할지를 고를 수 있습니다. 앞쪽이 “추측”이고 뒤쪽이 “등록”입니다. 저의 3구분은 이 구분을 할 일의 형태로 옮긴 것일지도 모릅니다.
| 처리 | 등록까지 진행되는가 | 사람의 확인 |
|---|---|---|
| 규칙으로 “추측”한다 | 진행되지 않는다(입력 후보가 들어간다) | 확인하고 등록한다 |
| 규칙으로 “등록”한다 | 진행된다 | 등록 전에는 들어가지 않는다 |
| 이번 대사 작업 | 진행되지 않는다(대조와 제안까지) | 확인하고 등록한다 |
또 하나의 이유는 API 사정입니다. API로 거래를 만들어도 내역 쪽은 미처리인 채로 남는다. 이용자들의 보고로는 그런 동작이 있다고 합니다. 지금도 같은지는 제가 확인하지 않았습니다.
그래서 “API만으로 대사를 끝낸다”는 전제는 두지 않았습니다. 마지막 한 걸음을 사람이 화면에서 하는 설계라면 이 점에 덜 좌우된다고 생각합니다.
두는 곳은 집 Mac
작업을 돌리는 장소는 집 Mac으로 정했습니다. 클라우드 쪽 정기 작업은 만들지 않습니다.
흐름은 3단계입니다. macOS의 launchd가 시각이 되면 깨운다. 깨워진 셸 스크립트가 준비를 한다. 그 안에서 Claude Code를 헤드리스로 실행한다. 헤드리스란 대화 화면을 띄우지 않고 claude -p 로 1회분의 지시를 흘려보내는 사용법입니다.
| 비교한 점 | 집 Mac의 헤드리스 실행 | 클라우드 쪽 정기 작업 |
|---|---|---|
| 보이는 파일 | Mac 안의 폴더 | 제 환경에서는 집 Mac의 폴더가 보이지 않았다 |
| 멈추는 조건 | 전원이 꺼져 있으면 다음 지정 시각까지 실행되지 않는다 | 이번에는 조사하지 않았다 |
| 잠자기 중 | 깨어났을 때 실행된다(Apple 자료의 기재) | 이번에는 조사하지 않았다 |
| 이번 판단 | 채택 | 만들지 않는다 |
Apple의 개발자용 자료에는 launchd의 시각 지정에 대한 설명이 있습니다. 예정 시각에 잠자기 상태였던 경우에는 깨어났을 때 실행된다. 전원이 꺼져 있었던 경우에는 다음 지정 시각까지 실행되지 않는다. 그런 내용이었습니다.
다만 이 자료는 갱신이 오래된 아카이브입니다. 지금의 macOS에서 같은 동작이 되는지는 직접 확인할 필요가 있습니다. 매월 5일이라는 지정을 어떻게 쓰는지도 구현할 때 확인하겠습니다.
정기 실행의 제약에 대해서는 Cloudflare Workers 무료 플랜의 Cron Trigger 상한 글도 있습니다. 어디서 돌릴지는 매번 가장 먼저 영향을 주는 것 같습니다.
두는 곳을 먼저 정하는 이유
이 설계를 다듬던 중에 한 번 걸려 넘어졌습니다.
클라우드 쪽 작업 환경에서 집 Mac의 폴더가 보이지 않았던 것이지요. 지금 있는 구조가 어떻게 되어 있는지 확인하고 싶은데 거기에 닿지 않습니다. 확인은 다른 경로로 했습니다.
여기서 배운 것은 순서입니다. 두는 곳을 먼저 정하지 않으면 확인조차 진행되지 않습니다. 무엇을 자동화할지보다 먼저, 어디서 무엇이 보이는지를 파악한다. 다음에 비슷한 것을 만들 때도 거기서부터 시작하려고 합니다.
이런 “구조를 두는 곳”의 재점검은 가계의 고정비에서도 마찬가지일지 모릅니다. 매달 반드시 나가는 통신비 같은 것은 한 번 정한 형태 그대로 움직이지 않은 경우가 많습니다.
월간 일정
한 달의 흐름은 이렇게 두었습니다.
| 시기 | 할 일 | 담당 |
|---|---|---|
| 매일~매주 | 내역 불러오기와 건수 확인 | 사람(지금까지처럼) |
| 매월 5일 7:30 | 대사 작업이 돈다. 내역을 3구분으로 나누어 할 일을 만든다 | 자동 |
| 5일 이후 | 묶음 할 일 1건을 확인하고 등록한다 | 사람 |
| 5일 이후 | 망설여지는 내역과 대출 상환의 할 일을 1건씩 처리한다 | 사람 |
5일은 월초에서 조금 지난 때입니다. 아침 7:30에 돌면 그날 안에 할 일을 열 수 있습니다.
장부의 보존 연수와 가사 관련비
망설여지는 내역의 대부분은 따져 들어가면 2가지 물음에 이릅니다. 증거는 남아 있는가. 사업 지출이라고 할 수 있는가.
증거 쪽은 보존 기간이 정해져 있습니다. 일본 국세청의 “생활 세금 정보”(레이와 8년도판)에는 청색 신고의 경우 보존 기간이 표로 나와 있습니다.
| 보존이 필요한 것 | 보존 기간 |
|---|---|
| 장부(분개장, 총계정원장 등) | 7년 |
| 결산 관계 서류(손익계산서, 재무상태표 등) | 7년 |
| 현금 예금 거래 등 관계 서류(영수증, 예금 통장 등) | 7년(전전년분 사업 소득과 부동산 소득 금액이 300만 엔 이하면 5년) |
| 그 밖의 서류(청구서, 견적서, 납품서 등) | 5년 |
영수증을 찾지 못한 내역을 “판단이 필요”에 넣은 것은 이 때문입니다. 나중에 찾으면 된다고 흘려보내도 되는 것이 아니라고 느끼고 있습니다.
사업 지출이라고 할 수 있는가 쪽은 가사 관련비라는 사고방식이 관계됩니다. 일본 국세청의 택스 앤서에 따르면 가사상의 비용은 필요 경비가 되지 않습니다. 다만 하나의 지출이 가사와 업무 양쪽에 걸리는 경우가 있습니다. 그것이 가사 관련비입니다.
필요 경비가 되는 것은 한정된 부분뿐입니다. 거래 기록 등에 근거해서 업무에 직접 필요했다는 것을 명확히 구분할 수 있는 금액. 그렇게 적혀 있습니다. 이 부분은 AI의 제안만으로 정하지 않고 사람이 보는 구분에 두었습니다.
앞으로의 작업
남아 있는 작업은 2가지입니다.
- 구현해서 이번 달 분을 dry-run으로 돌린다(월말까지)
- Mac 쪽에서 메일의 영수증을 읽는 경로가 있는지를 구현의 맨 처음에 확인한다
dry-run은 할 일을 실제로는 만들지 않고 결과만 보는 시험 방법입니다. 3구분이 나뉘는 모양이 제 감각과 맞는지를 본 실행 전에 봐 둡니다.
2번째를 맨 처음으로 가져온 것은 두는 곳에서 걸려 넘어진 경험 때문입니다. 대조에는 메일의 영수증이 필요합니다. Mac에서 읽을 수 없다는 것을 알게 되면 설계 쪽을 고치게 됩니다.
첫 작업은 다음 달 5일 예정입니다. 돌려 본 결과는 숫자가 나온 뒤에 따로 쓰겠습니다.
흔한 실패와 함정
망설여지는 내역과 쉬운 내역을 섞은 채로 늘어놓는다. 저의 6번은 이것이 아니었을까 보고 있습니다. 맨 앞의 1건에서 멈추면 뒤의 쉬운 내역까지 남습니다.
전부를 1건씩 할 일로 만든다. 망설임이 없는 내역까지 나누면 할 일의 수에 압도됩니다. 확정할 수 있는 분은 1건으로 묶는 형태로 했습니다.
두는 곳을 뒤로 미룬다. 어디서 무엇이 보이는지를 확인하지 않은 채 설계하면 확인 단계에서 멈춥니다.
월 1회 작업을 “월 1회 기장”으로 착각한다. 공식 원칙은 날마다의 기장입니다. 월간 작업은 판단의 자리이지, 기장 빈도를 낮추는 이야기가 아닙니다.
API만으로 끝난다는 전제로 짠다. 등록한 뒤에 내역이 미처리로 남는다는 보고가 있습니다. 사람이 화면에서 마무리할 여지를 남겨 두는 편이 안심이라고 생각합니다.
- 미처리 내역이 몇 건 있고, 몇 주 동안 움직이지 않았는지 세어 보았는가
- 멈춰 있는 원인이 건수인지, 망설여지는 내역인지를 구분했는가
- 작업을 돌리는 장소에서 필요한 파일과 메일이 보이는지 확인했는가
- 확정할 수 있는 분과 판단이 필요한 분을 다른 형태의 할 일로 만들고 있는가
- 같은 내역의 할 일이 이중으로 생기지 않게 하는 표식(내역 ID 등)을 정했는가
- 한 달에 사람에게 넘기는 건수의 상한을 정했는가
- 회계 소프트웨어 등록을 누가 할지의 선을 정했는가
- 날마다의 기장과 주간 확인은 지금까지처럼 계속한다는 전제로 되어 있는가
자주 묻는 질문
Q. 월 1회 대사로도 문제없나요?
일본 국세청의 표현은 “날마다의 거래 상황을 기장”입니다. 월 1회면 된다고 적힌 공식 기술을 저는 찾지 못했습니다. 그래서 불러오기와 주간 확인은 계속합니다. 월 1회로 하는 것은 망설여지는 내역을 판단하는 자리뿐입니다.
Q. 왜 매월 5일 아침 7:30인가요?
월초에서 조금 지난 아침, 이라는 식으로 둔 것입니다. 아침에 돌면 그날 안에 할 일을 열 수 있습니다. 맞지 않으면 돌려 본 뒤에 다시 볼 생각입니다.
Q. 자동 등록 규칙만으로는 부족한가요?
정해진 형태의 내역에는 규칙이 잘 맞는다고 생각합니다. 다만 제 쪽에 남아 있던 것은 망설여지는 내역이었습니다. 규칙으로 다 정할 수 없는 것을 사람이 1건씩 보는 자리가 필요하다고 느끼고 있습니다.
Q. AI에게 등록까지 맡기지 않는 이유는 무엇인가요?
공식 도움말의 흐름이 추측을 확인한 뒤에 등록하는 형태이기 때문입니다. 사업인지 가사인지의 판단도 마지막은 스스로 갖고 싶다고 생각했습니다. AI는 대조와 제안까지로 하고 있습니다.
Q. 집 Mac이 잠들어 있으면 작업이 도나요?
Apple 자료에서는 잠자기 중에 예정 시각이 온 경우 깨어날 때 실행된다고 합니다. 전원이 꺼져 있었던 경우에는 다음 지정 시각까지 실행되지 않습니다. 오래된 자료이므로 지금의 macOS에서의 동작은 구현할 때 확인하겠습니다.
Q. 월 15건 상한은 어떻게 정했나요?
할 일 목록이 가득 차지 않기 위한 기준입니다. 근거가 있는 숫자는 아닙니다. 돌려 본 뒤에 조정하겠습니다.
Q. 효과는 어느 정도 나왔나요?
아직 모릅니다. 이 글은 설계를 정한 단계의 메모입니다. 첫 작업은 다음 달 5일 예정이므로 결과는 그 뒤에 쓰겠습니다.
Q. 경비로 처리할 수 있는지는 이 구조로 정해지나요?
정해지지 않습니다. 구조가 하는 일은 내역을 나누어 사람에게 넘기는 데까지입니다. 세무의 최종 판단은 세무사나 세무서에 확인해 주세요.
참고한 공식 정보
- 기장과 장부 등 보존·청색 신고(일본 국세청 생활 세금 정보)
- No.2070 청색 신고 제도(일본 국세청)
- No.2210 필요 경비의 지식(일본 국세청)
- 자동으로 경리에서 거래를 등록하기(freee 도움말 센터)
- 내역의 자동 등록 규칙 설정하기(freee 도움말 센터)
- Scheduling Timed Jobs(Apple Developer 문서 아카이브)
- Run Claude Code programmatically(Claude Code 문서)
마무리
미처리 내역이 움직이지 않았던 것은 망설여지는 내역이 섞여 있었기 때문이라고 보고 있습니다. 그래서 확정할 수 있는 분은 묶고, 망설여지는 내역만 1건씩 사람에게 넘기는 형태로 합니다. 매월 5일 아침 7:30에 집 Mac에서 돌릴 예정입니다.
아직 설계를 정했을 뿐이고 돌려 보지는 않았습니다. 쌓인 내역 앞에서 손이 멈춰 있다면, 먼저 “망설여지는 내역은 몇 건인가”를 세어 보시는 것은 어떨까요.
매달 반드시 나가는 돈도 같은 식으로 한 번 나누어 살펴보면 다르게 보일지 모릅니다. 통신비 같은 고정비도 괜찮으시다면 내역을 열어 보세요.
이 글에는 제휴 광고가 포함되어 있습니다. 이 사이트의 링크를 통해 상품·서비스에 신청하시면 제휴사로부터 보상을 받을 수 있습니다. 또한 운영자는 라쿠텐 그룹 소속 직원으로, 사원 추천 프로그램을 통해 보상을 받는 경우가 있습니다. 기사 내용과 평가는 광고 유무와 관계없이 운영자의 실제 경험과 조사를 바탕으로 작성했지만, 위 관계를 이해하신 후 읽어 주시기 바랍니다. 자세한 내용은 면책조항·제휴 링크 안내를 참고해 주세요. 면책조항·제휴 링크 안내
이 글에는 기계 번역이 포함되어 있습니다. 정확한 조건은 라쿠텐 모바일 공식 사이트의 다국어 페이지에서 확인해 주세요.
라쿠텐 모바일의 통신 지역·전파 상황이 궁금하신 분은, 공식 전파 개선·조사 요청 양식 을 통해 문의하실 수 있습니다.
