재무 AI 에이전트를 실행할 때 고려할 4가지, Claude Academy 인사이트 ②

앞 글에서 AI에 위임할 단계와 사람이 관여할 단계를 나눴습니다. 이번에는 맡긴 일을 실제로 돌리는 쪽입니다. 재료는 Anthropic이 공개한 공식 Finance 플러그인입니다. 대사, 분개, 결산관리, 변동분석, 재무제표, 감사 조서까지 스킬 여덟 개, 1,906줄. 전부 읽었고, 오류 여섯 개를 심은 데이터로 세 번 돌려 채점했습니다. 재무 AI 에이전트에 대사 자동화를 맡길 때 무엇을 지시문에 적어 두어야 하는지가 이 글의 결론입니다.

Claude Finance 플러그인의 대사 스킬에는 무엇이 들어 있나

▍한 줄 설명과 달리 방법론 문서입니다

카탈로그에는 "GL 잔액을 보조원장과 대사"라고 한 줄로 적혀 있지만, 대사 스킬 본문에 들어 있는 것은 회계 교과서 한 챕터 분량입니다.

① 대사 세 유형. GL 대 보조원장(GL to Subledger, 매출채권·매입채무·고정자산·재고), 은행 대사(Bank Reconciliation), 회사 간 대사(Intercompany Reconciliation). 유형마다 절차와 흔한 차이 원인이 따로 적혀 있습니다.

② 조정잔액(Adjusted Balance) 양식. 은행 대사 양식이 표준입니다. 정산자료에는 미기록 수수료를 더하고 장부에는 미입금 이월을 더해, 두 조정잔액이 0에서 만나는지 봅니다. 총액끼리 단순 비교가 아닙니다.

③ 차이 3범주와 사후 관리. 기다리면 풀리는 시점 차이(Timing Differences), 분개가 필요한 조정 건(Adjustments Required), 원인 모르는 조사 건(Requires Investigation). 조사 건은 경과기간(aging, 0~30, 31~60, 61~90, 90일 초과)으로 추적하고, 금액과 경과일 기준으로 감독자와 관리자에게 올리는 에스컬레이션(escalation) 기준이 붙어 있습니다.

④ 직무분리(Segregation of Duties). 대사하는 사람은 그 계정의 거래를 처리하는 사람과 달라야 한다는 원칙까지 명시돼 있습니다. AI 산출물의 검증을 만든 세션 밖에서 해야 한다는 원칙과 같은 취지입니다.

방법론 문서로서는 흠잡을 데가 없습니다. 문제는 이것을 실제 데이터에 돌렸을 때 어디까지 작동하느냐입니다.

실측: 여섯 오류 중 다섯을 잡고, 금액이 가장 큰 하나를 놓쳤습니다

▍금액이 일치하는 오류는 세 스킬을 다 통과합니다

가상 회사의 한 달치 데이터를 만들었습니다. 주문 16,297건, 채널 넷, 그리고 재무팀이라면 다 겪어 본 오류 여섯. 월말 매출인데 입금이 다음 달로 넘어간 것, 플랫폼이 수수료를 떼고 순액만 입금한 것, 취소가 장부에 덜 반영된 것 같은 종류입니다.

여섯 중 다섯을 잡았습니다. 조정잔액 양식 덕에, 단순 매칭이었다면 차이 0으로 묻혔을 플랫폼 수수료 9천만원이 조정항목으로 드러났습니다.

놓친 하나는 이렇게 심었습니다. 이 회사는 입점사 상품을 대신 팔면 판매대금의 18%만 수수료로 가져갑니다. 나머지는 입점사에 줄 돈입니다. 그런데 장부에는 판매대금 전액이 회사 매출로 올라가 있습니다. 매출이 2억 3천만원 부풀려진 상태입니다. 이 오류가 어떻게 됐는가.

① 대사를 통과했습니다. 틀린 금액이 장부와 정산자료 양쪽에 똑같이 적혀 있어서, 맞춰 보면 원 단위까지 일치합니다. ② 분개 검토를 통과했습니다. 스킬의 수익 인식 절차에 "이 돈이 우리 매출인가, 남의 돈을 전달하는 것인가"를 묻는 단계가 없습니다. ③ 변동분석을 통과했습니다. 지난달에도 같은 방식으로 틀려 있어서, 증가율이 평범한 성장으로 보입니다.

이 오류는 계정과목 정의에 적힌 "수수료수익은 총액이 아니라 수수료만 수익"이라는 한 줄에서만 걸립니다. 세 스킬 중 어느 것도 그 파일을 읽으라고 시키지 않습니다.

재무 AI 에이전트를 실행할 때 고려할 네 가지

▍플러그인의 둘에, 실측이 보탠 둘을 더합니다

재무 AI 에이전트를 실제로 굴려 보면 실행 셋업 네 가지가 나옵니다. ①②는 플러그인의 방법론을 그대로 지시문으로 만드는 것이고, ③④는 실측이 드러낸 공백을 메우는 것입니다. 넷 다 매달 반복하는 작업이 아닙니다. 셋업 때 한 번 넣어 두는 설계입니다.

① 검증 양식을 지시문에 박습니다. "대사하라"와 양식 지정의 차이가 오류 다섯 대 한두 개의 차이를 만들었습니다.

[비교] 원장 '금액' 열 ↔ 플랫폼 정산자료 '정산액(순액)' 열. 다른 열 사용 금지.
[양식] 결과는 반드시 조정잔액 형태로만 출력한다.
  정산자료 잔액 + 미기록 수수료 = 조정잔액
  원장 잔액 - 미입금 이월 = 조정잔액
  차이 X원   ← 0이 아니면 건별 내역 첨부

비교할 열은 사람이 정합니다. 총액과 순액 중 무엇을 맞출지는 업무 지식이라 도구가 정하지 못하고, 비워 두면 총액끼리 맞춰 차이 0을 만듭니다.

② 분류 조건과 에스컬레이션을 지시문에 박습니다. "적절히 분류하라"는 실측에서 취소 건을 전부 시점 차이로 밀어 넣었습니다.

[판정] 각 건을 넷 중 하나로 표기한다.
  시점     = 원장에만 있고 거래일이 월말 7일 이내 (정산 이월분)
  조정     = 금액이 다르고 원인 계정이 특정됨 → 분개 초안 첨부
  조사     = 원인 불명 → 경과일 기재, 30일 초과 시 담당자 표기
  판단필요 = 금액은 일치하나 계정·거래 성격이 어긋남 → 사람 회부, 자동 처리 금지
[에스컬레이션] 건당 OO원 초과 또는 60일 경과 → 팀장, 90일 경과 → 관리자
  (금액 기준은 조직이 정한다. 비워 둔 채 실행하지 않는다)

플러그인의 3범주에 "판단필요"를 넷째로 보탠 것이 핵심입니다. 회계처리 판단 건이 "차이"로 뭉개지면 위의 2억 3천만원짜리가 그 안에 섞입니다.

에스컬레이션 금액을 비워 두고 조직이 정하게 한 원문의 설계도 배울 점입니다. 판단 조건을 방법론과 분리해 적게 하면 담당자의 암묵지가 명시적으로 관리되고, 조직이 바뀌어도 문서가 삽니다.

③ 주요 계정의 거래구조를 사전에 정의하고, 그것을 읽는 단계를 맨 앞에 둡니다. 계정분류만으로는 읽히지 않는 거래의 성격(총액인가 순액인가, 우리 매출인가 예수금인가)을 문서로 만들어 두는 것까지가 이 단계입니다.

[0단계] 대사 시작 전에 계정과목 마스터를 읽는다.
  각 계정의 정의(예: 수수료수익 = 수수료만 수익으로 계상)와
  원장의 계상 방식이 어긋나는 항목은 금액이 일치해도 "판단필요"로 표기한다.

금액이 일치해도 계정이 틀린 오류는 이 단계에서만 걸립니다. 셋업에 넣으면 매달 자동입니다.

④ 차이 없음과 비교 실패를 다른 값으로 표시합니다.

[요약 필수 항목] 비교 대상 건수 / 매칭 성공 건수 / 판정 불능 건수
  매칭률 95% 미만이면 결론을 내지 말고 "비교 실패"로 표기한다.
  "차이 없음"은 매칭 성공 위에서만 쓸 수 있는 결론이다.

실측에서 비교를 잘못한 실행이 "조정할 분개 없음"으로 나왔습니다. 이 세 값이 없으면 공회전이 정상 종료로 읽힙니다.

참고로 "판단필요"의 분량이 셋업 품질의 지표입니다. 실측에서 여섯 중 판단필요는 하나였고 이 비율이 정상입니다. 쌓이면 규칙이 덜 적힌 신호이고, 같은 판단이 반복되면 규칙으로 승격해 줄입니다. 회계사가 셋업하고 운영자가 굴리는 분업이 성립하는 이유가 여기에 있습니다. 판단이 필요한 지점을 셋업 때 미리 표시해 두는 것이 회계사의 몫입니다.

이 넷을 어디에 적어두나

▍스킬 문서 한 장에 여섯 항목으로 적습니다

네 가지를 대화창에 매번 입력하면 다음 달에 또 입력해야 합니다. 파일 한 장에 적어 두고 매달 그 파일을 읽히는 것이 셋업입니다. Claude Code에서는 이 파일을 스킬이라고 부르고, 위에서 읽은 Anthropic 플러그인의 여덟 개도 같은 형식입니다.

저희가 결산, 원천세, 인세, 감사 에이전트를 만들면서 다섯 번 같은 목차로 수렴했습니다.

[스킬 문서 목차]
  1 핵심 원리   이 업무에서 품질을 만드는 것 두세 줄
  2 절차        STEP 0~N. 0단계는 자료와 계정 정의를 읽는 단계
  3 검증 N체크  기계가 확인하는 목록. 통과 못 하면 결과를 내지 않는다
  4 판단 규율   사람에게 올릴 조건과 금액 기준
  5 커맨드      실행 방법 한 줄
  6 예외 기록   틀렸던 것과 그때 무엇으로 막았는지

앞의 네 가지는 2번과 3번에 들어갑니다. 계정 정의를 읽는 0단계는 2번의 맨 앞, 검증 양식과 매칭률은 3번, 판단필요와 에스컬레이션 금액은 4번입니다.

1번부터 5번까지는 처음 쓸 때 한 번에 나옵니다. 6번은 틀려 봐야 쌓입니다. 위의 2억 3천만원도 여기에 한 줄로 들어갑니다. 금액은 맞는데 계정이 틀린 건을 대사가 통과시켰고, 0단계를 넣어 막았다.

그래도 남는 한계

▍저희도 전부는 못 잡습니다

재무 AI를 쓰는 입장에서 이 플러그인은 방법론 참고서로 값어치가 충분하고, 저희도 대사 유형 분류와 에스컬레이션 기준은 그대로 참조합니다. 다만 한국 제도는 없습니다. 1,906줄에 부가가치세와 원천징수가 한 번도 나오지 않습니다. 모든 거래에 붙는 부가세예수금·대급금, 지급액에서 떼어 두는 원천징수 예수금, 익월 10일과 25일이 끌고 가는 신고 달력, 법제처 API로 확인하는 법령과 회계기준까지, 한국에서 쓰려면 별도로 심어야 합니다. 재무 방법론에는 국경이 없지만, 제도에는 국경이 있습니다. 그리고 위의 네 가지를 넣어도 못 잡는 오류는 남습니다. 그래서 대사 자동화를 포함한 재무 AI 스킬 전체를, 오류를 심은 데이터로 채점하는 일을 분기마다 반복합니다. 실측 전체 기록은 커널아카데미 연재에 정리해 두었습니다.

자주 받는 질문

Q. Claude Finance 플러그인은 어떻게 설치하나요?

A. Claude Code에서 두 줄입니다. anthropics/knowledge-work-plugins 마켓플레이스를 추가하고 finance 플러그인을 설치하면 스킬 여덟 개가 함께 들어옵니다. 다만 함께 등록되는 외부 연동 서버 여섯 개는 대부분 설정이 비어 있어 실제로 연결되지 않습니다.

Q. 한국 세무 업무에 쓸 수 있나요?

A. 세무에는 못 씁니다. 1,906줄 전문에 부가가치세와 원천징수가 한 번도 나오지 않고, 인용 기준은 미국 ASC 중심입니다. 대사 양식과 결산 순서 같은 방법론만 가져오고, 부가세예수금·대급금 분리, 원천징수 예수금, 계정체계는 국내 실무에 맞게 별도로 만들어야 합니다.

Q. 대사 자동화만 도입하면 결산 오류가 잡히나요?

A. 금액이 어긋나는 오류는 잡히고, 금액이 일치하는 오류는 잡히지 않습니다. 총액 계상이나 계정분류 오류는 양쪽 금액이 같아서 대사를 통과합니다. 대사 전에 계정 정의를 확인하는 단계와 판단필요 판정을 절차에 넣어야 막을 수 있습니다.

Q. 에이전트 셋업에 회계사가 왜 필요한가요?

A. 비교할 열을 고르고, 총액과 순액을 가르고, 사람에게 올릴 판단 조건을 정하는 일이 전부 업무 지식이기 때문입니다. 도구는 이 결정을 대신하지 못하고, 잘못 정해진 채 자동화되면 오류도 매달 자동으로 반복됩니다. 셋업의 품질이 곧 자동화의 품질입니다.

여러분의 대사 절차는, 금액이 정확히 일치하는 오류를 잡을 수 있습니까?