Phase 5 · 실전 자동화 플랫폼 제작

마침내, 말귀를 알아듣는 AI 회계 에이전트

31단계에서 만든 강력한 플랫폼을 회계사가 직접 클릭하며 조회하는 것도 훌륭하지만, 한 발 더 나아가 봅니다.
회계사가 "ABC기업 이번 달에 주의할 거래가 뭐야?"라고 자연어로 물어보면, 파이썬이 질문 의도를 파악하고 DB를 뒤져 RAG(검색 증강 생성) 기술로 명확한 근거를 갖춘 브리핑을 작성하는 에이전트 구축법을 배웁니다.

예상 학습 시간 : 280분
난이도 : ★★★★★
사전 단계 : SaaS 아키텍처 (Step 31)
다음 단계 : RAG 지식베이스 검색 (예정)
01

절대 DB를 통째로 넘기지 마십시오

단순한 챗봇과 "회계 비서"의 차이는 정보를 다루는 방식에 있습니다. 초보자는 흔히 DB 테이블 전체를 텍스트로 뽑아서 LLM 프롬프트에 구겨 넣습니다. 매우 위험하고 비효율적인 접근입니다.

핵심 설계 원칙

AI가 데이터베이스를 직접 통제하거나 읽는 것이 아닙니다. "Python 애플리케이션이 질문을 분석하고, 필요한 데이터만 DB에서 안전하게 추려낸 뒤, AI에게 요약된 수치만 전달"해야 환각(Hallucination) 없이 가장 정확한 답이 나옵니다.

02

질문의 의도(Intent) 분석하기

가장 먼저 할 일은 회계사가 입력한 텍스트가 어떤 유형인지 분류하는 것입니다. 이를 Intent(의도)라고 부릅니다.

# 단순 키워드 기반 Intent 분류 (실제 서비스에선 경량 NLP나 LLM 분류기 사용)
def classify_question(question):
    if "이상거래" in question or "주의" in question:
        return "ANOMALY"
    if "증빙" in question:
        return "DOCUMENT"
    if "500만원" in question:
        return "LARGE_TRANSACTION"
    return "GENERAL"

의도가 "ANOMALY"(이상징후 탐지)로 분석되었다면, 파이썬은 다음 단계인 '이상징후 관련 DB 조회' 로직으로 넘어갑니다.

03

이상징후 DB조회와 위험 점수화 (Risk Score)

파이썬이 마리아DB(MariaDB)에 접근해 ① 고액 거래 ② 증빙 누락 거래 ③ AI 추천 계정과목 불일치 내역을 가져옵니다. 이때, 단순히 "있다/없다"가 아니라 위험 점수(Risk Score)를 계산합니다.

🐍 python
def calculate_risk_score(large_count, missing_count, unusual_count):
    score = 0
    score += min(large_count * 5, 30)
    score += min(missing_count * 5, 30)
    score += min(unusual_count * 10, 40)
    return min(score, 100)
    
# 위험도 50점 -> "주의(WARNING)" 등급 산출
04

출처와 근거를 명시하는 프롬프트 (RAG)

파이썬이 수집한 요약본을 AI에게 전달합니다. 이 때 절대로 AI가 "단정(탈세입니다)"을 짓지 않도록 안전장치 프롬프트를 주입합니다.

[System Prompt] "당신은 회계사의 업무를 보조하는 AI 회계비서입니다. 다음 데이터를 분석하여 회계사가 확인해야 할 사항을 중요도 순으로 설명하십시오. [경고] 확인되지 않은 사실을 추측하거나 탈세 등을 단정하지 마십시오." [Data Injection (RAG)] - 매출 증가율: 11.2% / 매출채권 증가율: 36.4% - 500만원 이상 대규모 거래: 2건 (ID: 10231, 10248) - 증빙 미확인 거래: 4건 [AI의 생성 답변] "ABC기업의 주요 확인사항입니다. 1. 매출채권 급증: 매출 증가율(11.2%) 대비 채권 증가율(36.4%)이 월등히 높아 주요 거래처의 채권 회수 현황 점검이 권고됩니다. 2. 대규모 거래 및 증빙: 500만원 이상 거래 2건 및 증빙 누락 4건에 대해 [거래 ID 10231 외 5건]의 계약서를 추가로 요청하시기 바랍니다."

웹 UI에서는 [거래 ID 10231] 텍스트가 Source Reference(하이퍼링크)로 동작하여 클릭 시 즉시 해당 전표 화면으로 넘어가게 설계합니다. 이것이 진정한 비즈니스용 RAG입니다.

05

정형 데이터(RDBMS) vs 비정형 자료(Vector DB)

AI 챗봇을 설계할 때 가장 많이 혼동하는 부분이 데이터의 저장소입니다.

  • MariaDB (정형 데이터): 전표 번호, 매출액 5억원, 세금계산서 발행일 등 정확한 쿼리와 산술연산이 필요한 데이터.
  • Vector DB (비정형 데이터): 회계사무소 내부 매뉴얼, 과거 검토의견서, 계약서 PDF 등 단어의 "맥락(유사도)"으로 검색해야 하는 데이터.

가장 이상적인 AI 에이전트는 이 두 DB의 특징을 파이썬이 조율하여 양쪽에서 근거 자료를 가져와 AI에게 던져주는 구조입니다.

06

SQL 인젝션 방지: 자연어 ➡️ SQL의 한계와 Tool Calling

자연어를 입력받으면 AI가 SQL(예: SELECT * FROM transactions)을 직접 짜서 DB를 조회하게 만들고 싶을 겁니다 (Text-to-SQL). 하지만 이는 보안(DROP TABLE 등)과 데이터 격리성(다른 사무소 데이터 조회 위험) 측면에서 매우 치명적입니다.

AI Tool Calling 구조 사용하기

AI가 직접 SQL을 짜는 대신, 파이썬에 get_missing_documents(customer_id), get_sales(customer_id) 같은 안전한 '도구(Tool/Function)'를 미리 정의해 둡니다.
AI가 질문을 이해하면 "파이썬아, `get_sales` 함수를 좀 실행해서 나한테 결과를 줘!"라고 도구를 호출(Tool Calling)하게 만듭니다. 이렇게 하면 보안이 100% 보장됩니다.

07

실습 완성: AI 회계비서 대시보드 화면

32단계를 수료하면 학생들은 다음과 같은 AI 에이전트 미니 프로젝트를 완성하게 됩니다.

┌─────────────────────────────────────────────┐ │ 🤖 AI 회계비서 에이전트 │ ├─────────────────────────────────────────────┤ │ │ │ 거래처: [ 대한제조 ▼] │ │ │ │ 💬 질문 │ │ ┌─────────────────────────────────────────┐ │ │ │ 이번 달 주의해야 할 거래를 알려줘 │ │ │ └─────────────────────────────────────────┘ │ │ [AI 분석하기] │ ├─────────────────────────────────────────────┤ │ 🔎 분석 결과 │ │ │ │ ⚠ 매출채권 증가율 36.4% │ │ ⚠ 증빙 미확인 4건 [보기] │ │ ⚠ 계정과목 검토 필요 3건 [보기] │ │ │ │ 💡 AI의견: 증빙이 누락된 거래에 대해 빠른 │ │ 회수가 권고됩니다. │ └─────────────────────────────────────────────┘
08

33단계 예고: RAG 지식베이스 검색 확장

이제 AI 비서가 DB의 '숫자(정형 데이터)'를 보고 브리핑할 수 있게 되었습니다.

다음 33단계에서는 앞서 잠깐 언급한 Vector DB를 본격적으로 다룹니다.
"우리 사무실의 회계처리 기준과 과거 유사 사례를 찾아봐 줘" 같은 비정형 텍스트 기반 지식베이스 RAG (Retrieval-Augmented Generation) 시스템을 구축하여 진정한 '나만의 AI 회계 비서'를 완성해 보겠습니다.

Step 31 : SaaS 아키텍처 Phase 5 후반부 공사중