AI로 경리를 자동화하기 전에 알아두어야 할 것 — freee×Claude 연계의 현실
요약
본 기사는 1인 법인의 경리 업무를 AI(Claude)와 회계 프로그램(freee)을 연계하여 자동화하려는 시도에서 얻은 현실적인 교훈을 공유합니다. 결론적으로, 경리는 '완전 자동화'가 위험하며, 특히 계정 과목의 최종 판단과 세무 리스크 관리는 인간의 개입이 필수적입니다. 따라서 AI는 명세서 취득, 초안 작성, 보고서 요약 등 보조적인 역할에 집중하고, 핵심적인 회계 및 세무 판단은 사람이 담당하는 '반자동' 플로우를 유지해야 합니다.
핵심 포인트
- 회계 분야에서 AI의 추정 능력('그럴듯함')은 세무상의 정확성(Accuracy)을 대체할 수 없다.
- freee API 사용 시 레이트 리미트, OAuth 토큰 관리 등 기술적 제약과 운영 비용이 발생한다.
- 경리 업무는 '초안 생성 → 인간 검토/승인 → 실행'의 파이프라인을 거쳐야 세무 리스크를 방지할 수 있다.
- AI 자동화가 효과적인 영역은 명세서 취득, 초안 작성, 보고서 요약 등 보조 작업이며, 계정과목 최종 판단과 결산 정리는 인간의 역할이다.
시작하며 — "경리도 AI로 자동화할 수 있잖아요?"
나는 1인 법인을 경영하고 있으며, 회사의 거의 모든 업무를 AI (Claude Code)로 자동화하고 있다. 자동화율은 98%. SNS 게시, 기사 공개, 아침 경영 다이제스트 생성까지, 17개의 launchd 작업이 매일 자동으로 돌아가고 있다.
그런 이야기를 하면 반드시 듣게 되는 질문이 있다.
"경리도 AI로 자동화할 수 있어? freee와 연계하면 가능하지 않을까?"
결론부터 말하자면, 할 수 있는 부분과 할 수 없는 부분이 있다. 그리고 "할 수 없는 부분"을 모른 채 시작하면 상당히 큰 대가를 치르게 된다.
이 기사에서는 내가 실제로 freee×Claude 연계를 검토 및 검증하는 과정에서 배운 현실을 숨김없이 공유하고자 한다.
freee API로 할 수 있는 것·할 수 없는 것
freee에는 REST API가 마련되어 있어, 거래 등록·취득, 계정 과목 취득, 청구서 작성 등을 프로그램으로 조작할 수 있다.
Claude와 조합하면 이론상 다음과 같은 일이 가능하다.
- 은행 명세 CSV를 읽어 들여, 계정 과목을 자동 추정하여 분개(仕訳) 등록
- 영수증 이미지를 OCR로 읽어 들여, 경비를 자동 분류
- 월간 시산표 데이터를 취득하여, 경영 리포트를 자동 생성
하지만 이론과 현실 사이에는 큰 격차가 있다.
자동 분개의 정확도 문제
AI에게 "이 거래의 계정 과목을 추정해줘"라고 부탁하면 그럴듯한 답을 내놓는다. 하지만 회계의 세계에서는 "그럴듯함"이 통하지 않는다.
예를 들어, Amazon에서 산 물건이 소모품비인지, 신문도서비인지, 연구개발비인지. 이는 구매한 "물건"뿐만 아니라 사업의 맥락이나 과거의 처리 방침에 따라 달라진다. AI는 과거의 분개 패턴을 학습할 수 있지만, 세무상의 판단을 올바르게 내릴 수 있는지는 별개의 문제다.
우리 회사는 월 거래 건수가 많지 않다. 하지만 단 1건이라도 계정 과목을 틀리면 확정 신고 시 수정이 필요하다. AI가 100건 중 95건을 올바르게 처리하더라도, 나머지 5건을 수정하는 비용이 자동화의 효과를 상쇄한다.
API의 제약
freee API에는 다음과 같은 제약이 있다.
- 레이트 리미트 (Rate Limit, 1시간당 요청 수 제한)
- OAuth 인증 토큰 관리 (액세스 토큰의 유효 기간은 24시간)
- 일부 조작 (예: 전자장부보존법 대응 파일 첨부)은 API 미지원
특히 토큰 관리는 은근히 번거롭다. 자동화 작업을 짜두어도 토큰이 만료되어 있으면 아무것도 작동하지 않는다. 나는 launchd를 통한 자동화를 17개 운용하고 있는데, cron이 macOS에서 작동하지 않아 launchd로 전면 이행했던 경험이 있는 것처럼, "계속 작동하게 만드는" 것 자체에 비용이 든다.
내가 실제로 하고 있는 경리 플로우
솔직히 말하자면, 우리 회사의 경리는 반자동이다. 완전 자동화는 하지 않았다.
현재의 플로우
- 거래 데이터 취득: freee의 자동 가져오기 기능으로 은행·신용카드 명세를 취득
- 분개 추정: Claude에게 명세 데이터를 전달하여 계정 과목과 적요 후보를 생성
- 인간의 리뷰: 세무사(또는 본인)가 확인·수정
- freee에 등록: 확인된 분개를 freee에 등록
포인트는 스텝 3를 생략하지 않았다는 것이다.
이는 내가 다른 업무에서 배운 교훈이기도 하다. 이전에 AI가 생성한 영업 메일을 확인 없이 자동으로 발송했다가, 경어가 어색한 메일이 거래처에 전달된 적이 있었다. 이 경험을 통해 대외적인 영향이 있는 액션에는 반드시 "draft(초안) → 승인 → 실행"의 파이프라인을 두고 있다.
경리도 마찬가지다. 분개 등록은 "대외적인 영향이 있는" 액션이다. 세무서에 제출하는 숫자의 근거가 되기 때문이다.
"완전 자동화"가 위험한 3가지 이유
1. 세무 리스크
분개의 오류는 최악의 경우 과소신고 가산세나 납부 지연 가산세로 이어진다. AI가 "아마 이 계정 과목일 것이다"라고 판단한 결과에 대해 경영자가 책임을 지게 된다.
2. 전자장부보존법 대응
2024년 1월부터 전자 거래 데이터의 전자 보존이 의무화되었다. 거래 데이터의 "진실성 확보"와 "가시성 확보"가 요구된다. AI가 자동으로 처리한 로그가 세무 조사에서 "변조 가능성이 있다"라고 지적받을 리스크는 제로가 아니다.
3. 업무 이해의 상실
이것이 의외로 간과된다. 경리를 완전히 AI에 맡기면 경영자 스스로 돈의 흐름을 파악하지 못하게 된다.
나는 "AI는 실행에 사용한다. 판단은 인간이 한다."라는 원칙으로 경영하고 있다. 비용은 10분의 1이 되지만, 매출이 10배가 되는 것은 아니다. 마찬가지로 경리 작업 시간은 10분의 1로 줄일 수 있어도, 경영 판단에 필요한 숫자에 대한 이해를 외주 주어서는 안 된다.
그럼, 어디를 자동화해야 하는가
모든 것을 자동화하려고 하면 무리가 따른다. 다음 부분들은 자동화 효과가 높다.
자동화해야 할 부분
명세서 취득 및 분류 초안 작성: CSV를 읽고 "아마 이것일 것"이라는 후보를 AI가 제시하게 함 -
월간 리포트 생성: 시산표(Trial Balance) 데이터로부터 요약본을 자동 생성 -
경비 정산 입력 보조: 영수증 이미지로부터 텍스트 추출 -
세무 캘린더 리마인드: 납부 기한이나 신고 기한의 자동 통지
인간이 해야 할 부분
계정과목 최종 판단: 특히 판단이 갈리는 항목 (접대비 vs 회의비 등) -
결산 정리 분개: 감가상각, 충당금, 미지급금의 계상 -
세무 판단: 손금 산입 가능 여부, 소비세 과세 구분 -
세무사와의 커뮤니케이션: AI가 생성한 리포트를 바탕으로 상담
구현한다면, 이렇게 구성한다
구체적으로 freee×Claude 연계를 구현한다면, 나는 이렇게 구성할 것이다.
[은행 명세 CSV] → [Claude: 계정과목 추정] → [검토용 스프레드시트]
↓
[인간이 확인·수정]
...
중요한 것은, AI의 출력과 인간의 확인 사이에 버퍼(Buffer)를 두는 것이다. 우리 회사에서는 모든 대외 액션에 draft(초안) → 승인 → 실행의 파이프라인을 두고 있다. 경리 업무도 예외는 아니다.
Claude 측의 프롬프트(Prompt)에는 다음을 포함하면 좋다.
- 과거 3개월간의 분개 패턴 (동일 거래처의 과거 계정과목)
- 자사의 계정과목 체계 (freee의 기본 설정이 아닌, 자사에서 커스텀한 것)
- 판단이 망설여지는 경우에는 "확인 필요" 플래그를 세우도록 지시
요약 — 자동화의 본질은 "안심하고 위임하는 구조"
나는 자동화를 "AI의 능력을 제한하기 위해서"가 아니라, "안심하고 위임하기 위한 구조"라고 생각한다.
경리 자동화도 마찬가지다. AI에게 모든 것을 통째로 맡기는 것이 아니라, AI가 잘하는 부분(패턴 인식, 데이터 처리, 리포트 생성)을 맡기고, 인간이 잘하는 부분(판단, 책임, 커뮤니케이션)은 인간이 한다.
완전 자동화라는 꿈을 쫓기보다, 이 "반자동" 구조를 다듬는 것이 결과적으로 더 빠르고 안전하게 돌아간다.
구조를 만드는 초기 투자 비용은 크다. 하지만 한 번 만들면 자동으로 돌아간다. 경리 업무도 그 원칙은 동일하다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기