사람처럼 판단하고, 기계처럼 검증하는 분개 봇
27단계까지 우리는 완벽하게 연결된 '통합 거래 데이터'를 만들었습니다.
이번 28단계에서는 단순히 "이게 무슨 비용이게?" 묻는 것을 넘어, 과거의 처리 사례(RAG)와 회사별 회계 정책을 복합적으로 참조하여 차변/대변 분개를 생성하고 회계사의 최종 승인을 받는 시스템을 구축합니다.
분개 구조와 시스템의 목표
프로그래밍을 하기 전, 회계 초보자라면 반드시 분개(Journal Entry) 구조를 알아야 합니다.
어떤 거래든 발생하면 원인과 결과를 왼쪽(차변)과 오른쪽(대변)에 나누어 기록하며, 항상 차변 합계 = 대변 합계 여야 합니다.
이 시스템의 궁극적인 목표는 파이썬이 통장 내역("ABC문구 / 프린터 토너 / 110,000원")을 읽고 위와 같은 완벽한 분개 뭉치를 스스로 만들어내어 회계사에게 "승인"을 요청하도록 하는 것입니다.
계정과목(Account Codes) DB 테이블 구성
우선 회계기준 및 사무소 체계에 맞는 계정과목 마스터 테이블이 필요합니다.
CREATE TABLE account_codes ( id BIGINT PRIMARY KEY AUTO_INCREMENT, office_id BIGINT, code VARCHAR(20) NOT NULL, -- 예: '8500' name VARCHAR(100) NOT NULL, -- 예: '소모품비' account_type VARCHAR(30), -- 예: 'expense' (비용) parent_id BIGINT, is_active BOOLEAN DEFAULT TRUE, created_at DATETIME DEFAULT CURRENT_TIMESTAMP );
여기에 1100 보통예금, 4000 매출, 8100 복리후생비 등의 마스터 데이터를 미리 Insert 해둡니다.
역할 분담: 파이썬의 계산과 AI의 문맥 이해
"업무용 프린터 토너" ➡️ 소모품비
물론 1차적으로는 파이썬 Rule Engine을 돌립니다. (예: if "택시" in desc: return "여비교통비") 하지만 "프린터 구매(비품/소모품)"와 "프린터 수리(수선비)"처럼 미묘한 뉘앙스 차이는 파이썬 Rule만으로는 한계가 오기 마련입니다.
회사별 회계 정책과 과거 데이터 (RAG)
AI에게 묻기 전에 가장 중요한 작업이 있습니다. 회계처리는 회사(Customer)마다 내부 기준이 다르다는 것입니다.
A회사는 소액 장비를 소모품비로 떨지만, B회사는 자산(비품)으로 잡아 감가상각을 태울 수 있습니다.
/* 회사별 정책 테이블 */ CREATE TABLE accounting_policies ( office_id BIGINT NOT NULL, customer_id BIGINT NOT NULL, policy_type VARCHAR(50), policy_value JSON ); /* 예: {"small_equipment_threshold": 1000000, "default_expense_account": "소모품비"} */
또한 과거 처리 사례는 가장 훌륭한 교보재입니다. DB에서 과거 해당 거래처에 매겨진 계정과목 내역 20건을 끌고 와 AI 프롬프트에 쑤셔 넣습니다.
AI JSON 프롬프트 설계
우리는 AI에게 단답형을 요구하지 않습니다. "후보군", "신뢰도", 그리고 왜 그렇게 생각했는지 "사유"를 포함한 엄격한 JSON을 요구합니다.
{ "account": "소모품비", "confidence": 0.94, "reason": [ "프린터 토너 구매 문맥 확인", "거래처가 문구/사무용품 업체에 해당", "과거 동일 거래처 처리 사례(소모품비)와 100% 일치" ] }
파이썬 분개 생성 및 부가세 룰 엔진
AI가 "소모품비"를 추천했다면, 이제 파이썬이 나서서 차변(debit) 배열과 대변(credit) 배열을 조립합니다.
# 단순 10% 계산을 넘어서는 VAT Rule Engine def calculate_vat(supply_amount, vat_type): if vat_type == "standard": return round(supply_amount * 0.10) if vat_type in ["zero", "exempt"]: return 0 return None # Python 분개 JSON (저장용 딕셔너리) journal = { "debit": [ {"account": "소모품비", "amount": 100000}, {"account": "부가세대급금", "amount": 10000} ], "credit": [ {"account": "보통예금", "amount": 110000} ] }
절대 규칙: 차변-대변 검증 (Validation)
시스템이 분개를 DB에 밀어넣기 전에 파이썬이 수행해야 하는 절대적인 회계 원칙 검증 리스트입니다.
- ① 차변 합계 = 대변 합계 (대차평균의 원리)
assert debit_total == credit_total - ② 금액 검증: 공급가액 + 부가세 = 합계액이 맞는지
- ③ 증빙 검증: 거래에 맵핑된 증빙 데이터가 유효한지
- ④ 거래처 검증: 사업자등록번호 유효성 검사
- ⑤ 중복 검증: 동일 거래에 대한 이중 분개 여부 확인
최종 검문소: 회계사 승인 화면 (Human-in-the-loop)
위의 모든 검증을 거친 결과물은 UI 대시보드에 뿌려집니다.
만약 AI가 추천한 소모품비를 회계사가 비품으로 수정하여 승인했다면, 그 수정 내역은 시스템 DB에 보존되어 다음 번 유사 거래가 발생했을 때 RAG 지식창고로 기능하게 됩니다. 사용할수록 똑똑해지는 마법이 완성됩니다.
25~28단계: 거대한 회계 자동화 파이프라인의 완성
지금까지 배운 것을 하나로 묶으면 다음과 같은 완벽한 회계업무 자동화 엔진이 탄생합니다.
"회계사가 자료를 통째로 업로드하면 ➡️ 시스템이 문서 사진(OCR)을 읽고 ➡️ 흩어진 통장/카드를 묶어 통합 대사하고(Reconciliation) ➡️ 이상거래를 걸러낸 후 ➡️ AI가 과거 회사 정책을 뒤져 분개를 추천하고 ➡️ 회계사는 클릭으로 승인만 한다."
# 28단계 엔진의 전체 파이썬 슈도코드(Pseudocode) 흐름 def process_transaction(transaction): customer = find_customer(transaction) invoice = find_invoice(transaction) history = find_history(customer) # RAG + AI candidates = recommend_account(transaction, customer, invoice, history) # 분개 생성 및 파이썬 룰 검증 journal = create_journal(transaction, candidates[0]) validate_journal(journal) return journal # 회계사 승인 대기열로 송신
29단계 예고: 개별 분개를 넘어 '결산(Closing)'의 영역으로
28단계까지가 개별 거래 건들의 미시적인 처리였다면, 다음 단계에서는 거시적인 월말/연말 결산(Closing)의 세계로 올라갑니다.
총계정원장(GL) ➡️ 합계잔액시산표 ➡️ 미수/미지급금 정리 ➡️ 감가상각 ➡️ 재무상태표/손익계산서 자동 생성으로 이어지는 파이썬 결산 자동화 파이프라인을 구축해 보겠습니다.