RAG Lab

경리 한 건에 0.25원 — 비싼 모델이 아니라 RAG였다

경리 업무를 AI로 돌리는 데 한 건에 얼마가 드는지 실측했습니다. 비싼 모델은 답이 아니었습니다. 싼 모델 + RAG + 결정적 커널이면 한 건 0.25원에 사람보다 정확했습니다.

AI 에이전트는 비싸다는 인상이 있습니다. 그런데 실제로 한 건에 얼마가 드는지 재본 적 있으신가요.

경리 업무를 에이전트로 돌려서 task 1건당 비용을 원(₩) 단위로 실측했습니다. 결론부터 말하면, 잘 만든 구성에서 부가세 신고서 초안 한 건이 0.25원이었습니다. 1,000건을 만들어도 250원, 커피 한 잔이 안 됩니다.

그런데 싸다고 다 되는 건 아닙니다. 핵심은 정확도였고, 정확도는 비싼 모델이 아니라 RAG에서 나왔습니다.

빠진 축: $/correct-task

Agent를 평가할 때 보통 정확도만 봅니다. 몇 %를 맞췄나. 그런데 요즘 agent eval에는 축이 하나 더 붙었습니다. 같은 정답을 누가 더 싸게 내느냐 — Cost-of-Pass, 정답 1건을 얻는 데 드는 기대 비용입니다.

이게 빠지면 평가의 절반만 본 셈입니다. 정확도가 비슷한 두 에이전트도, 한 건에 0.25원과 12원이면 완전히 다른 물건이니까요.

재려면 정답이 명확해야 합니다. “잘 썼다” 같은 주관 채점으로는 성립하지 않습니다. 경리 업무는 정답이 한 값으로 떨어집니다 — 부가세 납부세액은 숫자 하나, 원천징수세액도, aging 버킷 합계도. 그래서 결정적 채점기를 만들 수 있습니다.

task는 5개를 정답 fixture로 박았습니다: 부가세 신고서 초안, 원천징수, 미지급금 aging, 근태·연차, 월마감 분개. 필드 단위 exact-match로 채점합니다.

어떤 task인지 — 부가세 한 건

말로만 하면 안 와닿으니 실제 task 하나를 봅니다. 분기 거래를 주고 부가세 신고서 초안을 만들게 합니다.

경리 task 예시 — 잡다한 거래내역을 에이전트가 공제/불공제로 분류하고, 결정적 엔진이 합산해 부가세 신고서를 만든다

입력은 매출 3건, 매입 5건입니다. 어려운 건 매입의 공제/불공제 판정입니다.

매입공급가액세액판정
원재료 (세금계산서)4,000,000400,000공제
기계장치 (세금계산서)20,000,0002,000,000공제
접대비 (세금계산서)1,000,000100,000불공제
비영업용 승용차30,000,0003,000,000불공제
소모품 (신용카드)2,000,000200,000공제(기타공제)

마지막 줄이 함정입니다. 신용카드로 산 소모품의 매입세액은 사업 관련 적격 수취면 “그 밖의 공제매입세액(14번 칸)“으로 공제됩니다. 여기서 매출세액 150만 − 공제매입 260만 = 환급 110만원이 정답입니다.

측정 — 싼 모델은 다 싸고, 다 틀린다

먼저 모델만(bare) 돌렸습니다. 싼 커머디티 티어로 잡았습니다: gpt-4o-mini, gpt-4.1-nano, gpt-5.4-nano, gpt-5.4-mini, 그리고 공개 모델 Qwen3.6-35B-A3B. 같은 task, 같은 채점기, 비용은 각 모델이 실제로 쓴 토큰 × 공개 단가입니다.

커널이 결정적으로 채점하는 3개 task 기준, 모델만 쓴 정확도:

모델 (bare)정확도
gpt-4.1-nano0/3
gpt-5.4-nano0/3
gpt-4o-mini1/3
gpt-5.4-mini1/3
A3B2/3

다 싸고, 다 틀립니다. 제일 싼 nano는 한 개도 못 맞췄습니다. 그리고 위 예시의 카드 매입공제처럼, 세법 디테일에서 미끄러집니다. 비용은 여기서 차별점이 아니었습니다 — 다 fractions of a won인데, 맞추질 못합니다.

비싼 모델이 아니라 RAG였다

틀리는 건 두 갈래 문제입니다.

  1. 분류 오류 — 카드 매입이 공제냐 불공제냐. 세법 지식의 문제입니다.
  2. 산술 오류 — 분류가 맞아도 합산·차감을 LLM이 토큰으로 뱉다 어긋납니다. 계산기로 풀 문제입니다.

그래서 모든 모델에 같은 구조를 입혔습니다. 분류는 LLM이 하되 별지 제21호 서식 기준을 근거로 물려주고(RAG), 합계·세액·납부는 결정적 커널이 계산합니다.

# LLM은 라인별 공제/불공제만 판정(RAG 근거) → 커널이 결정적으로 합산
lines = [VatLine(s["공급가액"], s["세액"], "sale", 영세율=s.zero) for s in sales]
lines += [VatLine(p["공급가액"], p["세액"], "purchase",
deductible=(cls[p.line] == "공제")) for p in purchases]
summary = vat_summary(lines) # 매출세액·공제매입·불공제·납부세액 전부 결정적

결과가 이렇게 바뀝니다.

bare 모델은 정확도가 낮지만, RAG·커널을 입히면 거의 다 3/3로 점프한다. 로컬 엔진(A3B 자가서빙)이 가장 싸다

모델bare → +RAG·커널₩/건
gpt-4.1-nano0/3 → 3/30.16
gpt-4o-mini1/3 → 3/30.25
gpt-5.4-nano0/3 → 2/30.34
gpt-5.4-mini1/3 → 3/31.25
A3B (로컬 엔진)2/3 → 3/30.25

화살표가 다 위로 점프합니다. 비싼 모델이 필요 없었습니다. 제일 싼 gpt-4.1-nano도 RAG·커널을 입으면 3/3이고, 한 건에 0.16원입니다. 오히려 제일 비싼 gpt-5.4-mini가 정확도는 같은데 5~8배 비쌉니다.

정확도는 모델을 키워서 나온 게 아니라, RAG로 근거를 물리고 산술을 코드로 옮겨서 나왔습니다. 이게 RAG가 중요한 이유입니다 — 같은 싼 모델이 RAG 하나로 0/3에서 3/3이 됩니다.

가격 상승은 감안해야 한다

공짜 점프는 아닙니다. RAG로 근거(별지21호 서식)를 프롬프트에 실으면 그 호출의 입력 토큰이 약 800 → 7,000개로 늘어, 분류 호출 비용이 2~3배 오릅니다.

다만 두 가지가 이걸 상쇄합니다. 첫째, 커널이 나머지 task(합산·aging)에서 LLM을 아예 빼므로 task 평균 비용은 오히려 비슷하거나 내려갑니다. 둘째, 같은 근거 프롬프트는 매 호출 동일하니 프롬프트 캐싱으로 더 줄일 수 있습니다.

그래서 RAG를 입혀도 한 건이 0.16~0.34원 선에 머뭅니다. 틀린 답을 0.13원에 내느니, 맞는 답을 0.25원에 내는 게 cost-of-pass입니다.

로컬 엔진이면 바닥을 친다

A3B는 공개 모델이라 직접 서빙할 수 있습니다. RTX PRO 6000 한 장에서 띄우고 동시 요청 8개로 쟀더니 배치 throughput 1,371 tok/s가 나왔습니다(아직 GPU 포화도 아닙니다). 이 GPU 시장 렌탈가 중앙값(시간당 약 $1.27) 기준이면, 토큰 비용은 API 티어보다 한 단계 더 내려갑니다.

정리하면 비용은 이렇게 내려갑니다.

  • 모델만 키우기 → 비싸고, 그래도 틀림
  • 싼 모델 + RAG·커널 → 한 건 0.16~0.25원, 3/3
  • 같은 걸 로컬 엔진으로 자가서빙 → 그 밑

이게 자동화입니다. 부가세 신고서 초안 한 건 0.25원, 1,000건 250원. 사람이 한 건 검토하는 시간·비용과 비교하면 자릿수가 다릅니다.

배운 것

도메인 task에서 cost-accuracy frontier를 미는 방법은 “더 좋은 모델 고르기”가 아니었습니다. 싼 모델은 다 비슷하게 싸고, 그 가격대에서 한국 세무를 그냥 맞추는 모델은 없었습니다.

빈 코너(싸고 정확)는 구조로 채웠습니다. 싼 모델 + RAG(근거) + 결정적 커널. 모델은 자기가 잘하는 분류만 하고, 자주 틀리는 산술은 코드한테 넘깁니다. 그리고 이 모든 걸 로컬 엔진에서 돌리면 한 건이 0.25원입니다.

그리고 에이전트를 평가할 땐 정확도만 보지 마세요. $/task를, 가능하면 원 단위로 같이 봐야 “정답률은 비슷한데 8배 비싼” 구성을 걸러낼 수 있습니다.

다음

지금 커널이 닫은 건 부가세·원천징수·aging 3개입니다. 근태·월마감 분개는 아직 모델 출력에 의존하고 있어서, 여기에도 같은 패턴(분류는 모델, 검산은 커널)을 넣는 게 다음입니다.