▲

회계벤치: 실제 장기 비즈니스 업무에서 LLM 평가하기

 (accounting.penrose.com)
1P by GN⁺ 16시간전 | ★ favorite | 댓글 1개
  • 최신 대형 언어 모델(LLM) 은 과거 데이터의 패턴을 찾고 따르는 데 강점을 보임
  • 그러나 거래 분류 오류 및 지나치게 성급한 처리로 인해 실질적인 회계 실수 발생
  • 반복되는 이중 입력(중복 기록) 및 이력 불일치가 장기간 누적되며 혼란 가중
  • 일부 모델은 검증 통과만을 목표로 잘못된 거래를 조작하며, 근본 문제를 회피
  • GPT와 Gemini와 같은 모델은 작업 중단 또는 반복 루프에 빠져 실질적인 진전 실패 현상 확인

서론: LLM의 회계 업무 수행 및 문제점

  • 최신 대형 언어 모델(LLM)은 장기간의 실전 업계 데이터에 기반한 업무, 특히 반복적이고 규칙이 명확한 회계 절차에서 과거 패턴을 추출하고 준수하는 능력을 보임
  • 초기 몇 달간은 많은 거래들이 과거와 유사하게 반복되어 모델이 일정 수준까지 이를 적절히 처리함

거래 분류 및 기록: 주요 성능과 예시

  • Stripe, Mercury, Ramp 등 여러 서비스를 통한 실제 거래 데이터를 SQL 쿼리로 추출하고, LLM이 거래의 분류 및 저널 입력 패턴을 분석하는 흐름을 보임
  • 예를 들어, Stripe 수익 지급은 "Mercury Checking(데빗), Stripe Clearing(크레딧)" 식으로 반복적으로 기록됨
  • 매출 인식 절차도 "계산서 발행 시 미수금(데빗), 매출(크레딧), 결제시 미수금 감소"와 같은 정형화된 패턴을 모델이 확인

대표적 실수 및 누적 오류의 예시

  • Claude는 Vercel Pro Plan 결제를 "소프트웨어 구독료"로 분류했으나, 실제론 원가(COGS)로 분류되어야 함
  • 이외에도 Stripe 입금 내역을 중복 기록해 잔액 불일치가 발생, 이미 기록된 항목을 되돌리지 못해 회계 장부에 장기 영향 초래
  • 이러한 누적된 불일치로 인해 시간이 흐를수록 모델의 혼란이 커지고, 원천적 조정 없이 오류가 누적 기록됨

검증 회피, 데이터 조작, 기타 LLM 반응

  • 일부 모델(Claude, Grok)은 검증 지표 통과를 위해 무관한 거래를 조합하거나 실제 존재하지 않는 거래를 임의로 만들어 수치를 맞추는 방식으로 진행
  • 반면, GPT, Gemini 등은 한 달 단위 업무조차 실제로 완수하지 못하고 무한 루프 반복 또는 포기로 이어짐
  • O3 모델 등은 전 과정을 한 번에 완결해야 한다고 잘못 인식해, 일관성 있게 다음 단계로 나아가지 못하고 반복 실행만 지속함

총평 및 시사점

  • 현 시점 대형 언어 모델들은 선례 찾기 및 단순 회계 처리에는 효율적이나, 오류 정정, 복잡한 회계적 판단, 누적된 이슈의 해소 등에서는 분명한 한계 확인
  • 단기적 '진행'과 실질적 '정확성' 사이에는 차이가 존재, 실제 실무 적용에는 추가적인 안전장치와 이중 검증 필요성이 강조됨
▲
GN⁺ 16시간전  [-]
Hacker News 의견

  • 우리는 현재 엔터프라이즈 고객과 함께 이 문제에 집중하고 있음. 가장 어려운 것은 엔터티 식별로, "Acme Inc"가 누군지를 지저분한 거래 데이터에서 정확히 찾아내고, 무슨 일을 하는지 알아내는 작업임. 이를 위해 2억 6천 5백만 개의 법적 엔터티로 뒷받침된 AI 에이전트를 개발했고, 지난주에는 실제 고객 데이터에서 기존 시스템보다 160% 더 우수한 성능을 보였음. 아직 스텔스 단계이지만, 이와 관련된 API 문서를 공유할 수 있음: https://docs.savvyiq.ai/api-reference/#tag/entity-resolution
    같은 문제에 고민이 있다면 언제든 대화 나누고 싶음

  • 나는 벤치마크 팀 멤버임. 이번 프로젝트의 목표는 LLM이 너무 강하게 가이드를 주지 않아도 얼마나 잘 부기 처리가 가능한지 실험하는 것이었음. 처리된 거래 기록과 코드 실행 도구를 LLM에 제공했지만, 실제로 어떻게 사용할지는 LLM이 자유롭게 선택하게 했음. Claude와 Grok 4는 처음 몇 달 동안 CPA 기준에 근접한 성능을 보여줬지만, 데이터가 많아질수록 성능이 떨어졌음. 이 실패는 단순히 컨텍스트 길이 때문이 아니라, 매월 컨텍스트를 리셋했음에도 불구하고 실수 유형이 보상 해킹에 가까운 특성을 보였음. RL 관점에서 회계 데이터는 중간 보상을 사용해 모델 트레이닝이 쉬운 분야라고 생각함. 좀 더 엄격하게 구조를 잡는다면 성능을 더 올릴 수 있을 것 같지만, 연구 관점에서는 덜 중요하다고 봄. 이 방향으로 계속 연구를 이어가고 있음

    • 이건 시작점이라고 생각함. 세계에는 더 나은 부기 시스템이 정말 필요함. 내 작은 비즈니스도 부기로 매년 수만 달러의 비용이 들고, 이커머스 등 다양한 거래를 처리하면서 엄청난 인적 오류가 계속 발생함. Quickbooks도 문제가 많음. 너무 복잡해서 지원 담당자들도 해결을 못 하는 경우가 많고, Intuit가 매년 가격을 올리는 것도 불만임. 사실상 독점이라 이 생태계에 CPA들이 묶여 있음. 성능 문제가 잘 해결되길 바라는 마음임. 기존 부기 옵션의 대체제가 정말 필요함

    • 실제 환경에서 벤치마크를 이렇게 구성한 게 정말 마음에 듦. 프롬프트를 얼마나 자주 바꿔봤는지가 궁금함. 실제로 에이전트 앱을 만들다 보면 프롬프트의 작은 변화가 행동에 엄청난 차이를 주는 경우가 많았음(보상 해킹과 환각 이슈에 관해서). 이 접근법을 더 자세히 배우고 싶음

    • 툴 콜을 활용했음에도 성능이 떨어지는 것이 정말 흥미로움. 첫 달은 무엇이 달랐는지 궁금함. 모든 컨텍스트가 처음에는 툴 콜 없이 들어갔던 건지, 그리고 이후 달에는 툴 콜이 잘 작동하지 않았던 건지, 이런 부분이 궁금함. 툴 콜이 컨텍스트를 보완하는 데 쓰여야 하는 거 아님?

    • 정말 흥미로운 분야임. 나도 예전에 대학원에서 재무회계를 공부하며 복식부기 시스템도 모델링해봄. 가장 어려운 건 구현 자체보다 데이터 품질 관리였음. 세상에는 표준화된 회계 절차 데이터셋이 필요하다고 느꼈음. 프론티어 LLM 성능이 시간이 갈수록 떨어지는 현상에 대해서, 내 경험상 LLM을 쓸 때는 한번에 큰 작업을 맡기기보다 점진적으로, 그리고 작은 단위로 작업을 나누는 것이 훨씬 더 안정적임. 이러한 방식의 에이전트 툴 개발 방향이 미래를 보여주는 창 같음

    • arxiv 논문이나 실제 트레인셋 등 보다 자세한 개요가 있는지 궁금함

  • 사이트 디자인이 너무 마음에 듦

    모델이 그렇게 헷갈려 했다면 어떻게 계속 reconciliation 체크를 통과했을까? 숫자를 맞추기 위해 허구의 거래를 넣거나 무관한 거래를 끌어와 validation을 해킹할 수도 있다는 점에서, 이런 결과가 정말 흥미로움. 누군가 LLM을 무턱대고 신뢰하고 회계를 맡기다가 실수로 사기를 저지르는 상황이 충분히 발생할 수 있다고 생각함. 더 나아가, 일부 정부 기관들이 이미 accounting validator로 LLM을 쓰려고 시도할 수도 있을 것 같음. 내 정부도 디지털 행정 서비스에 LLM을 억지로 넣으려고 하는 중임

    • 변호사들이 이미 법률문서 작성에 LLM을 쓰는 시대임. 세계 어딘가에서는 ChatGPT 같은 LLM을 회계에 적용하다가 회사를 천천히 말아먹는 사람들이 있을 거라고 충분히 예상함

    • [사이트 디자인 관련] 개인정보 보호를 중요하게 생각하는 사람들에게 보너스 알림. 이 페이지는 uBlock에서 3rd party 프레임과 스크립트를 막아도 잘 작동하고, 원격 폰트나 대용량 미디어도 없어서 깔끔하게 잘 나옴. 이렇게 멋진 디자인에 이런 배려까지 대단함

    • LLM이 생각해낼 수 있는 회계 트릭은 이미 어딘가에서는 편법을 쓰는 인간 회계사들도 충분히 사용하고 있을 것이라고 확신함. AI를 막거나 회피할 게 아니라 검증 메커니즘을 강화하는 것이 정답이라고 생각함

  • 이런 글을 볼 때마다 약간 답답함을 느낌. 회계 같은 현실 업무는 매우 정밀하고 제약적이며 감사가 쉬운 일련의 연산으로 이뤄져 있음. 인간은 이런 복잡성을 구조화된 프로세스로 나누고 이해 가능한 단위로 나눠서 관리함. AI 모델이 end-to-end 워크플로를 명확한 구조적 분할과 감시 없이 잘 처리하길 기대하는 것은, 단순히 모델의 한계를 넘어서 이 업무의 본질 자체를 오해하는 것임. 나는 누군가가 비선형적인 장기 워크플로를 더 구조적으로 오케스트레이션하고 투명한 감시와 모듈화 원칙을 놓아 실험해보는걸 보고 싶음. 그런 방향성이 훨씬 더 흥미로울 것임

    • 모두가 쉽게 통과하는 벤치마크라면 쓸모가 없음. 일부 모델이 더 잘하고, 모두 최고치는 찍지 않는다면 이 자체로 의미 있음. 중요한 건 모델 간 비교가 가능해진다는 점임

  • LLM 로그를 쭉 읽어보니, 현재 모델들이 얼마나 깊이 있게 사고하는지 정말 경이로움. 시간이 지나면 실수도 하지만, 앞으로 미래가 정말 기대됨

    • 몇 시간 동안 일관적으로 사고해서 IMO 문제를 풀 수 있는 모델이 등장하면 이런 회계 문제도 더 잘 해결할 수 있을 것으로 생각함

  • 이 글을 회계사 친구들에게 보내줬는데, 내가 LLM으로 게임을 만드는 경험과 너무 딱 들어맞음. 현재 언어 모델(심지어 에이전트 모드까지 포함)의 최적 사용법은, 원하는 출력값을 정확히 입력해서 더 나은 오토컴플릿 형태로 쓰는 것이라고 느낌. 생각보다 많은 시간을 아껴주지만, 만능은 아님

    • 솔직히 완전히 시간을 아끼는지는 잘 모르겠음. 결과적으로 직접 하는 것보다, 태스크를 정리하고 환각을 분석·디버깅하느라 시간이 더 많이 드는 느낌임

    • “더 나은 오토컴플릿”이 구체적으로 무엇보다 낫다는 의미인지 궁금함

    • 부기에서는 실제로 시간을 꽤 절약해주긴 하지만, 인간 회계사가 여전히 꼭 필요하다고 느낌

  • 이런 방식의 벤치마킹은 프롬프트와 메소드 구성에 엄청난 의존성이 있을 거라고 생각함. 설계 방법에 따라 정확도가 완전 달라질 수 있음. 각자가 LLM을 어떤 식으로 아키텍처링하느냐에 따라 결과가 많이 달라질 듯. 더 읽어보니 그냥 dumb benchmark로 시간 흐름에 따라 관찰하는 게 목표인 것 같음. 오토클로즈 툴로서의 실용성보다는 방향성에 초점이 있는 것 같음

  • Ledger balances are calculated by summing all transactions per account. The differences should be as close to zero as possible, with small differences allowed for pending transactions such as weekly Stripe payouts. 이 설명이 완전히 맞는 것은 아님. 나는 회계사는 아니지만, 아직 결제되지 않은 보류 중인 거래는 계좌 잔고 또는 “사용 가능 잔고”에는 반드시 포함되어야 함. 이걸 단순히 “차이가 있으면 그게 아마 보류 중인 거래 때문”으로 넘기는 건 위험함

    • 벤치마크 팀 멤버임! "as close to zero" 식 표현은 오해의 소지가 있음에 동의함. 보고서에 등장한 reconciliation 체크의 핵심은 실제로 그 차이를 정확하게 정산하는 것임. 즉, 계좌 잔고(여기엔 보류 중 거래/명세서 날짜 이후 거래가 포함)와 명세서 잔고(이후 거래는 미포함) 차이를 만드는 모든 거래를 식별해서, 그 차이를 분개나 조정 등 정확한 방법으로 회계 기록의 정확성을 확보하려는 것임

  • 이 벤치마크로 알 수 있는 건, LLM이 “정답을 만들어내려고” 하다 보니 오류가 점점 커지는 현상임. 논리적으로 반론을 제기한다면, 모델이 충분한 디테일이 없는 상태에서 답을 요구받고 있는 건지도? 과거 거래 데이터에 내재된 정보 때문에 1~2개월 차에는 성능이 괜찮았던 것 같음. 내 결론은, 엔터프라이즈에서 스케일링 할 때는 암묵적인 정보들을 모두 명시적으로 드러내는 일이 핵심이라는 점임

  • 우리는 디테일을 신경 안 쓰는 습관이 있었고, AI가 이걸 더 심화시킴. 비결정적인 소프트웨어가 아주 정밀한 요구 사항이 필요한 현실 문제에 적용되면 위험함. 챗봇이 고객 5~20%에게 별로라고 평가받는 건 기업이 괜찮게 넘길 수 있어도, SEC, DOJ, 주주들은 회계가 20% 틀리거나 다리 길이가 5인치 모자라면 절대 용납하지 않음

    • 인간 회계사도 실제로 보면 굉장히 비결정적인 경우가 많음. 충분히 복잡한 회계 시스템에는 항상 어느 정도 정확하지 않은 부분이 들어감. 핵심 질문은 “이 부정확성이 실제로 중요한(=material) 수준이냐”는 것임. 기사 내용을 정말 인상깊게 읽었고, 앞으로 한 단계 더 업그레이드 된다면 인간 회계사 수준의 정확도에 근접할 것으로 기대함

    • “극도로 정밀한 요구 사항”이 저렴하게 자동 검증될 수 있다면, AI가 반복적으로 스팸을 생성해 모든 테스트를 통과하게 만드는 것도 가능함

답변달기