
【freee MCP】경리에 Claude를 고용하는 시대? 청구서 초안 워크플로우를 Skill화해 보았다
요약
freee MCP를 활용하여 스프레드시트의 데이터를 기반으로 freee에서 청구서 및 견적서 초안을 자동으로 생성하는 워크플로우를 구축하는 방법을 소개합니다. MCP와 에이전트 스킬을 결합하여 복잡한 API 매뉴얼을 외울 필요 없이 자연어로 경리 업무를 자동화하는 사례를 다룹니다.
핵심 포인트
- freee MCP를 통해 Claude가 freee API를 직접 조작하여 업무 자동화 가능
- 에이전트 스킬을 활용하면 API 명세를 학습하지 않아도 자연어로 작업 수행 가능
- 스프레드시트 리스트 읽기부터 청구서 초안 생성, 결과 반영까지의 워크플로우 구현
- 리모트 버전 MCP를 통해 로컬 설정 없이 Claude 커스텀 커넥터로 간편하게 연결 가능
「이 청구서 작성, Claude에게 부탁할 수 없을까?」
경리나 백오피스 업무에는 매달 반복되는 작업이 많이 있습니다.
- 스프레드시트(Spreadsheet)의 청구 대상 리스트를 확인한다
- freee에서 청구서나 견적서의 초안을 만든다
- 작성 완료/미작성 상태를 매출 관리표에 반영한다
- 미회수나 입금 상황을 확인한다
- PDF나 장표 URL을 대장에 남긴다
물론, freee를 열면 할 수 있습니다.
다만, 매번 화면을 열고, 사양을 떠올리고, 비슷한 입력과 확인을 반복하는 것은 은근히 번거로운 일입니다.
이번에는 freee MCP를 사용하여, Claude로부터 freee의 사무·경리 관련 업무를 어디까지 자연어로 다룰 수 있는지 테스트해 보았습니다.
스프레드시트의 청구 대상 리스트를 읽고, freee에 청구서·견적서 초안을 만든 뒤, 결과를 매출 관리표에 다시 쓰는 흐름입니다.
MCP와 에이전트 스킬(Agent Skill) 조합의 가장 큰 장점은, 셋업이 매우 간단하다는 것과 「MCP/API로 무엇을 할 수 있는지」를 사람이 외울 필요가 없다는 점입니다.
freee의 API 매뉴얼에 해당하는 에이전트 스킬을 Claude Code(또는 Codex와 같은 에이전트)가 참조하므로, Claude가 「freee API로 무엇을 할 수 있는지」를 아는 상태에서 작업의 창구가 되어줍니다. 이 부분이 가장 효과적이었습니다(자세한 내용은 후술합니다).
이 기사에서는 다음 내용을 정리합니다.
- 스프레드시트의 청구 대상 리스트로부터 청구서·견적서 초안 만들기
- 작성 결과를 매출 관리표에 다시 쓰기
- 이 워크플로우를 재사용할 수 있도록 만든 Skill의 zip 배포
- freee의 숫자 확인 메모, 미회수 체크, Slack 게시 등 그 외에 시도해 본 것들
보충:
거래처명은 데모용 더미 데이터이며, 실제 회사명, 금액, freee ID는 게시하지 않았습니다.
이번 검증으로 할 수 있었던 것을 먼저 정리하면 다음과 같습니다.
| 수행한 작업 | 결과 |
|---|---|
| 스프레드시트에서 freee 청구서·견적서 초안 만들기 | 가능 |
| ... |
가장 실무에 가까웠던 것은 「스프레드시트에서 장표 초안을 만드는」 흐름입니다.
제대로 구축하면 GAS(Google Apps Script)나 Cloud Run 개발 프로젝트가 될 내용을, MCP와 Skill을 사용하면 상당히 가볍게 시작할 수 있습니다.
freee MCP는 AI 에이전트가 freee의 각종 API를 조작할 수 있게 해주는 MCP 서버입니다.
2026년 3월 27일에 freee로부터 리모트 버전 제공 시작이 발표되었습니다.
리모트 버전은 로컬 환경에 MCP 서버를 세우지 않고, Claude 등의 AI 도구에 URL을 설정하여 사용하는 형식입니다.
참고:
리모트 버전의 접속처는 여기입니다.
Claude의 커스텀 커넥터(Custom Connector)에 이 URL을 추가하고 freee에 로그인하면 사용할 수 있게 됩니다.
셋업 절차는 공식 헬프에 자세히 정리되어 있으므로, 도입할 경우에는 이를 보면서 진행하는 것이 빠릅니다.
다기능 SaaS는 애초에 「무엇을 할 수 있는지」 파악하는 것 자체가 힘듭니다.
파악하더라도 다음은 조작 방법을 익히는 것이 힘듭니다.
게다가 경리 업무처럼 가끔씩만 사용하는 도구라면, 「이거 어떻게 했더라?」라는 상황이 매번 발생합니다.
freee도 예외는 아닙니다.
회계, 청구서, 판매, 인사 노무 등 영역이 넓고, API도 화면도 기능도 많습니다.
「이 작업은 어디서 해야 하지」, 「API로 가능한가?」를 매번 떠올리는 것은 고된 일입니다.
이번에 시도해 보며 가장 편리하다고 느낀 점은, 이 부분을 통째로 Claude에게 맡길 수 있다는 것이었습니다.
여기서 빛을 발하는 것이 에이전트 스킬입니다.
에이전트 스킬이 freee의 API 매뉴얼과 같은 역할을 수행하고, 이를 Claude Code와 같은 에이전트가 호출합니다.
즉, Claude가 freee API로 할 수 있는 것을 아는 상태에서 작업의 창구가 됩니다.
무엇을 할 수 있는지는 물어보면 됩니다.
어떻게 하는지는 외울 필요가 없습니다.
freee에서 〇〇 할 수 있어?
청구서 좀 만들어 줘.
이 청구 데이터로 매출 관리표를 업데이트해 줘.
인간은 최종 확인이나 승인이 필요한 부분만 확인하면 됩니다.
이번 청구서 워크플로우에서도 바로 이 점이 효과적이었습니다.
- 청구서·견적서 초안 작성은 API로 가능함
- 장표 URL은 취득 가능함
- 작성 결과는 스프레드시트로 다시 쓸 수 있음
- 반면, 청구서 PDF의 직접 다운로드는 API만으로는 어려워 보임
- 송부·공개·삭제는 마음대로 하지 않는 것이 좋음
이러한 판단과 실행을 사람이 관리 화면이나 API 매뉴얼을 읽어가며 수행하는 것이 아니라, Claude를 창구로 삼아 진행할 수 있습니다.
이것이 freee MCP와 Skill을 결합했을 때 얻을 수 있는 가장 큰 장점이라고 생각합니다.
이번에 하고 싶었던 것은 freee MCP를 사용하여 "Claude에게 경리·백오피스 업무를 부탁하는" 감각을 확인하는 것이었습니다.
스프레드시트(Spreadsheet)를 읽고, Claude가 freee의 사양을 확인하며, freee MCP를 경유하여 장표 초안을 만들고, 그 결과를 매출 관리표로 되돌려 보냅니다.
필요에 따라 확인 메모를 Slack이나 채팅으로 보낼 수도 있습니다.
즉, freee의 사무·경리 작업을 Claude를 통해 처리하는 구성입니다.
포인트는 freee MCP를 "Claude에서 freee로 접속하는 입구"로 사용할 수 있다는 점입니다.
확인 관점의 정리나 출력 대상의 제어는 Claude 측에서 수행할 수 있습니다.
이번에 가장 실무에 가깝다고 느낀 것은 매출 관리표에서 freee의 장표 초안을 만드는 흐름입니다.
준비한 것은 다음과 같은 청구 대상 리스트입니다.
이 스프레드시트의 미작성 행을 보고,
freee에서 청구서와 견적서 초안을 만들어줘.
작성 전에 확인표를 보여줘.
매출 관리표에는 상태(Status), 장표 종류, 거래처, 건명, 품목명, 수량, 단가, 세율, 청구일, 지급 기한을 입력해 두었습니다.
Claude는 상태=미작성인 행만을 대상으로 하며, 작성 전에 확인표를 출력합니다.
내용은 다음과 같은 이미지입니다 (그 외에 freee 거래처 ID/거래처 코드, 품목명, 지급 기한, 비고 열이 있습니다).
| 상태 | 장표 종류 | 거래처명 | 건명 | 수량 | 단가 | 세율 | 청구일 |
|---|---|---|---|---|---|---|---|
| 미작성 | 청구서 | 주식회사 샘플상사 | 2026년 6월분 유지보수비 | 1 | 1,000 | 10% | 2026-06-30 |
| ... |
포인트는 작성 완료인 행은 대상에서 제외하는 것입니다.
이를 수행하지 않으면 동일한 청구서를 중복으로 만들게 됩니다.
이번에는 데모 데이터로 다음 3건을 작성 대상으로 설정했습니다.
| 장표 종류 | 건수 | 작성 후 상태 |
|---|---|---|
| 청구서 | 2건 | 미전송 초안 |
| 견적서 | 1건 | 미전송 초안 |
freee MCP를 통해 확인하니, freee 청구서 API 측에 청구서 2건, 견적서 1건이 생성되어 있었습니다.
모두 unsent 상태이므로, 마음대로 전송되지는 않습니다.
작성 후에는 매출 관리표에 작성 완료, 거래처 ID, freee 장표 ID, 장표 URL, 작성 일시를 다시 기록(Write-back)했습니다.
기록 후의 이미지입니다.
| 상태 | 장표 종류 | 건명 | freee 장표 ID | 장표 URL | 작성 일시 | 에러 |
|---|---|---|---|---|---|---|
| 작성 완료 | 청구서 | 2026년 6월분 유지보수비 | INV-xxxx (id) | https://... | 2026-06-09T... | |
| 작성 완료 | 견적서 | LP 제작 견적 | QUO-xxxx (id) | https://... | 2026-06-09T... | |
| 작성 완료 | 청구서 | 광고 운영 대행 | INV-xxxx (id) | https://... | 2026-06-09T... |
이 "다시 기록하기(Write-back)"가 중요합니다.
freee에서 만들고 끝내는 것이 아니라, 스프레드시트 측으로 결과를 되돌려줌으로써 어떤 행이 작성 완료되었는지, 어떤 장표 URL에 대응하는지, 어떤 행이 실패했는지를 관리할 수 있습니다.
freee의 API를 직접 호출하기만 한다면 일반적인 시스템 연동입니다.
하지만 스프레드시트를 읽고, 등록 전에 확인표를 내놓고, 승인을 기다려 초안을 만든 뒤, 결과를 원래의 대장으로 되돌려 주는 것. 여기까지가 자연어 요청 하나로 연결된다는 점이 완전히 다르게 느껴졌습니다.
실제 업무에서도 매월의 계약 리스트나 영업 견적 의뢰 리스트에 그대로 적용할 수 있을 법한 형태입니다.
GAS(Google Apps Script)나 Cloud Run으로 본격적으로 구축하기 전에, "Claude에게 스프레드시트를 건네주고 freee 초안까지 만들게 한다" 정도부터 시작할 수 있다는 점이 장점이었습니다.
내부적으로는 CSV나 스프레드시트를 freee에 그대로 업로드하는 방식이 아닙니다.
Claude 또는 동봉된 스크립트가 행 데이터를 읽어 freee API용 JSON으로 변환하고, 행마다 POST /invoices 또는 POST /quotations를 호출합니다.
이번 스프레드시트 → freee 장표 초안 작성 흐름은 재사용할 수 있도록 Skill화했습니다.
배포 zip:
zip의 구성은 다음과 같습니다.
freee-invoice-from-sheet/
SKILL.md
agents/openai.yaml
...
AI 에이전트에게 이 zip을 전달하여, 이용 환경에 맞춰 배치하는 것을 전제로 합니다.
동작 확인은 Claude Code로 진행했습니다.
| 실행 환경 | 배치 경로 |
|---|---|
| Claude Code / Claude | ~/.claude/skills/freee-invoice-from-sheet/ |
| Codex 외 Agent Skills 대응 에이전트 | ~/.agents/skills/freee-invoice-from-sheet/ |
Codex는 Agent Skills 오픈 표준인 .agents/skills 계열 경로(사용자 단위는 ~/.agents/skills/, 리포지토리 단위는 <repo>/.agents/skills/)를 읽습니다.
스크립트는 곧바로 freee로 POST하지 않도록 설계했습니다.
먼저 dry-run을 통해 대상 행과 JSON payload를 확인합니다.
python3 scripts/sync_invoice_rows.py \
--csv assets/sample_invoice_rows.csv \
--company-id <freee_company_id>
Google Sheets를 직접 읽는 경우는 다음과 같습니다.
python3 scripts/sync_invoice_rows.py \
--spreadsheet-url "https://docs.google.com/spreadsheets/d/..." \
--sheet-name 請求対象 \
...
Sheets의 직접 읽기/쓰기에는 Google 공식 CLI인 gws를 사용합니다(환경에 gws가 없다면, 시트를 CSV로 내보낸 후 --csv를 사용하면 됩니다).
gws 설정 방법은 별도 기사에 정리해 두었으니, 이쪽을 참고해 주세요.
freee에 접속하지 않고, 작성이 성공한 것으로 가정하여 다시 쓰기(write-back)만 테스트할 수도 있습니다.
기사용 검증이나 도입 전 동작 확인 시에 유용합니다.
python3 scripts/sync_invoice_rows.py \
--csv assets/sample_invoice_rows.csv \
--company-id <freee_company_id> \
...
실제로 freee로 POST하고, Google Sheets에 결과를 다시 쓰는 경우에만 --execute --write-back을 붙입니다.
FREEE_ACCESS_TOKEN=... python3 scripts/sync_invoice_rows.py \
--spreadsheet-url "https://docs.google.com/spreadsheets/d/..." \
--sheet-name 請求対象 \
...
이 부분은 매우 중요하기 때문에, Skill 측에서도 '작성 전 프리뷰'와 '사용자 승인'을 필수로 설정했습니다.
청구서나 견적서는 업무 데이터이므로, 자연어로 생성할 수 있다 하더라도 마음대로 송부·공개·삭제까지는 하지 않도록 설계했습니다.
청구서 관련 작업 외에, freee의 수치 확인도 시도해 보았습니다.
Claude에게 다음과 같이 요청했습니다.
대상 기간의 PL을 보고, 확인용으로 3줄 요약해 줘.
매출, 매출총이익, 영업이익을 알 수 있는 표도 붙여줘.
숫자의 나열이 아니라, 무엇이 일어나고 있는지를 써줘.
수행되는 흐름은 다음과 같습니다.
- freee MCP를 통해 시산표를 취득
- Claude가 매출, 매출총이익, 영업이익을 추출
- 확인용 3줄 요약으로 변환
- Slack 게시용 짧은 문구로 정형화
공개용이므로 실제 금액과 실제 문구는 가렸지만, 돌아온 결과는 단순한 숫자의 나열이 아니라 매출과 이익의 변동 차이, 비용 측면에서 확인해야 할 항목, 다음에 살펴봐야 할 논점까지 깊이 있게 다룬 3줄 요약이었습니다.
전년 동기와의 비교도 같은 방식으로 요청할 수 있으며, 마지막에 '무엇이 일어나고 있는지'를 한 문장으로 답해줍니다.
숫자만 가져오는 것이라면 API로도 가능합니다.
하지만 매번 확인할 때 정말로 필요한 것은 "그래서, 어디를 봐야 하지?"라는 부분입니다.
freee 화면을 열어 시산표를 찾아 헤매지 않아도, 그 정도 수준까지 자연어로 전달된다는 점이 흥미로웠습니다.
미회수 체크도 읽기 전용으로 시도해 보았습니다.
요청은 다음과 같습니다.
미회수 매출채권을 찾아내 줘.
거래처별로 집계하고, 합계가 BS(대차대조표)의 매출채권 잔액과 일치하는지 확인해 줘.
차액이 있다면 원인 후보도 알려줘.
Claude는 회계 API로부터 미결제 거래를 집계하고, 대차대조표(BS)의 매출채권 잔액을 가져와 대조했습니다.
테스트 사업소는 회계 측 거래가 0건이므로, 결과 자체는 "미회수 0엔 vs BS 매출채권 0엔으로 일치"라는 미미한 내용입니다.
다만, 흥미로웠던 점은 차액의 원인 후보까지 답변이 돌아왔다는 것입니다. 제시된 내용은 다음 세 가지였습니다.
- freee 청구서 측에서 장표를 만든 것만으로는 회계 거래가 되지 않음 (이번에 만든 청구서 2건도 BS의 매출채권에는 반영되지 않음)
- 입금 반제(消込, Reconciliation)가 완료되었다면, 매출채권은 이미 상계 처리됨
- 청구일과 계상기가 겹치는 기말 이월(期ズレ, Period mismatch)
실제로 freee 청구서로 만든 장표는 그대로는 회계상의 매출채권으로 계상되지 않습니다.
"청구서를 만들었는데 매출채권이 늘어나지 않는다"는 실무에서도 빠지기 쉬운 포인트이며, 이 대조 플로우를 넣어두면 차이를 알아챌 수 있습니다.
AI에게 회계 데이터를 읽게 할 때 무서운 점은 "그럴듯해 보이는 표"를 만들어 버리는 것입니다.
BS 잔액과의 대조와 같은 회계상의 검산 포인트를 삽입하면, 추출 결과와 회계 잔액의 정합성을 확인한 후 사용할 수 있습니다.
확인 결과는 Slack의 자신에게 보내는 DM으로 게시하는 단계까지 시도해 보았습니다.
게시된 문구는 다음과 같은 형태입니다.
오늘의 경리 확인 메모
- 매출: 회계 측 매출 거래는 0건, 청구서 장표만 2건 (미발송)
- 미회수: 미회수 매출채권과 BS 매출채권 잔액은 일치
...
이것이 매일 아침 도착한다면, 사람이 freee를 열어 확인하기 전에 확인해야 할 후보를 먼저 전달받는 형태가 됩니다.
매일 아침 정기 실행까지는 아직 구성하지 않았지만, 이 정도까지 동작한다면 나머지는 스케줄 실행에 등록하여 매일 아침의 루틴으로 만들 수 있을 것 같습니다.
좋은 점만 있었던 것은 아니며, 막혔던 부분도 있었습니다.
이번 검증 환경에서는 회계 API를 문제없이 사용할 수 있었습니다.
시산표 취득이나 거래 데이터 취득은 성공했습니다.
반면, 처음에는 freee 청구서 API에서 company_not_found가 반환되어 청구서 템플릿조차 가져올 수 없었습니다.
그 후, freee 청구서 측의 이용 상태를 정비하자 템플릿 취득, 청구서 목록 취득, 견적서 목록 취득, 데모 장표 작성까지 진행할 수 있었습니다.
리모트 MCP(Remote MCP)에서도 마찬가지로, freee 청구서의 이용 설정이 활성화되지 않은 사업소에 대해서는 청구서 API가 403(권한 없음)이 됩니다.
회계 API: 이용 가능
freee 청구서 API: 최초에는 company_not_found, 이용 설정 후에는 사용 가능
판매계 API: 이번에는 미검증
...
즉, "freee MCP를 설치하면 모든 영역을 반드시 사용할 수 있다"는 뜻은 아닙니다.
MCP로서 툴이 준비되어 있더라도, 실제로 사용할 수 있는 범위는 freee 측의 계약, 이용 중인 프로덕트, 권한에 따라 좌우됩니다.
또 하나, 청구서 PDF 관련해서도 주의가 필요했습니다.
freee 청구서 API의 응답으로부터 장표 상세 URL은 취득할 수 있지만, 이번에 조사한 범위 내에서는 작성 완료된 청구서·견적서 PDF를 API만으로 직접 다운로드하는 공개 엔드포인트(Endpoint)는 찾을 수 없었습니다.
freee 청구서 화면에서는 단일 PDF 다운로드나 여러 장표의 일괄 PDF 다운로드가 가능합니다.
따라서 현실적으로는 다음과 같은 흐름이 됩니다.
- freee 청구서 화면에서 PDF 또는 ZIP을 다운로드한다.
- 취득한 PDF/ZIP을 Google Drive에 업로드한다.
- Drive URL을 매출 관리표에 다시 기록한다.
이 부분은 향후 브라우저 조작까지 포함하여 자동화할 여지가 있습니다.
다만, 이번에 배포하는 Skill에서는 PDF 취득을 "화면 조작 또는 별도 공정"으로 분리해 두었습니다.
이번 검증 범위를 정리하면 다음과 같습니다.
사용해 보면서 적합하다고 느낀 부분은 다음과 같습니다.
- 매월의 계약 리스트로부터 청구서 초안 만들기
- 영업 담당자가 입력한 견적 의뢰 리스트로부터 견적서 초안 만들기
- 미작성/작성 완료 상태 관리를 스프레드시트로 수행
- 작성 결과인 freee 장표 URL을 대장에 남기기
- 월차 확인 요약(Summary)을 Slack이나 채팅으로 보내기
반대로, 처음부터 전부를 무인화하는 용도로는 적합하지 않습니다.
특히 청구서·견적서는 금액이나 거래처를 틀리면 영향이 크기 때문에, 작성 전 프리뷰와 승인 단계를 거치는 것이 좋아 보입니다.
freee MCP를 사용하면 Claude를 통해 freee의 회계 데이터나 장표 데이터에 접근할 수 있습니다.
우선 흥미로운 점은, freee를 Claude로부터 자연어로 다룰 수 있다는 것입니다.
숫자를 읽고, 확인하기 쉬운 형태로 정리하며, 장표의 초안까지 만드는 흐름을 지시 하나로 실행할 수 있습니다.
그보다 더 큰 점은, 에이전트 스킬 (Agent Skill)이 freee의 API 매뉴얼이 되어 Claude가 작업의 창구가 되어준다는 것이었습니다.
무엇을 할 수 있는지는 물어보면 되고, 어떻게 하는지는 외울 필요가 없습니다.
가끔씩만 사용하는 툴의 "이거 어떻게 하더라?"라는 의문이 그대로 의뢰 문장이 됩니다.
경리 업무의 완전 자동화라기보다는, 우선 "매달 사람이 수동으로 만들던 장표 초안을, AI가 스프레드시트(Spreadsheet)로부터 작성 후보까지 준비하는" 정도부터 시작하는 것이 현실적이라고 생각합니다.
이번 스프레드시트 → freee 청구서·견적서 초안 작성 워크플로우 (Workflow)는 스킬 (Skill)로서 배포하고 있습니다.
자신의 환경에서 테스트할 경우에는, 우선 --simulate-post 또는 dry-run부터 시작하는 것을 추천합니다.


AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기