LLM이 표 형식 데이터를 추론할 수 있을까? 금융 AI에 대해 4가지 벤치마크가 시사하는 바

표는 회계사가 사고하는 방식입니다. Beancount 장부는 본질적으로 표와 같습니다. 계정은 행으로, 날짜와 금액은 열로, 잔액 확인(assertion)은 셀 간의 제약 조건으로 작용합니다. 따라서 LLM이 자율 금융 에이전트를 구동할 수 있는지 묻기 시작했을 때, 저는 계속해서 동일한 선행 질문에 부딪혔습니다. "과연 LLM이 표를 안정적으로 읽을 수나 있을까?" 이에 대한 문헌 조사 결과는 예상보다 훨씬 실망스러웠습니다.

논문 소개

Fang 등은 TMLR 2024(arXiv:2402.17944)에 "Large Language Models(LLMs) on Tabular Data: Prediction, Generation, and Understanding — A Survey"를 발표했습니다. 이 논문은 표 형식 특징에서의 정형 결과 예측, 합성 표 데이터 생성, 질문에 답할 수 있을 정도로 표를 이해하는 것의 세 가지 영역을 다루는 41페이지 분량의 분류 체계입니다. 금융 AI에 가장 관련이 깊은 작업은 표 질문 답변(TableQA), 사실 검증 및 구조적 추론이 포함된 이해 트랙입니다.

함께 읽은 논문인 Sui 등의 "Table Meets LLM: Can Large Language Models Understand Structured Table Data?"(WSDM 2024, arXiv:2305.13062)는 좀 더 통제된 접근 방식을 취합니다. 이들은 표 분할, 크기 감지, 병합된 셀 감지, 셀 조회, 역방향 조회, 열 검색, 행 검색의 7가지 세부 작업으로 구성된 구조적 이해 능력(SUC) 벤치마크를 정의하고 GPT-3.5와 GPT-4를 직접 테스트했습니다. 추론 체인이나 검색 기법 없이, 단순히 모델이 우리가 요구하는 작업을 수행할 수 있는지만을 확인했습니다.

핵심 아이디어

• 형식 간의 격차는 실재하며 놀라울 정도로 큽니다. SUC 벤치마크에서 HTML 직렬화는 구분자가 있는 자연어 형식(natural-language-with-separators)보다 전체적으로 약 6.76% 더 높은 성능을 보였습니다. HTML > XML > JSON > Markdown > NL+Sep 순위는 모든 작업에서 일관되게 유지되었습니다. Beancount 파일은 이 스펙트럼에서 자연어 형식에 더 가까우며, 이는 주의해야 할 신호입니다.
• 셀 조회는 의외로 어렵습니다. GPT-3.5는 직접적인 셀 조회(X행, Y열의 값 찾기)에서 44%의 정확도만을 기록했습니다. GPT-4는 동일한 작업에서 73.34%에 도달했습니다. 스프레드시트 수식이 마이크로초 단위로 처리하는 결정론적 작업에서 모델 간 26% 포인트의 격차가 발생하는 것은 우려스러운 일입니다.
• 퓨샷(Few-shot) 예시는 성능을 지탱하는 핵심입니다. SUC 프롬프트에서 1-shot 예시를 제거하면 모든 작업에서 전체 정확도가 30.38% 하락했습니다. 모델의 구조적 이해는 진정으로 내재화된 것이 아니라 시연을 통해 강력하게 보조되고 있습니다.
• 실제 표 QA에서 인간과 LLM의 격차는 엄청납니다. TableBench(arXiv:2408.09174, AAAI 2025)는 사실 확인, 수치 추론, 데이터 분석 및 시각화 전반에 걸쳐 886개의 질문을 평가합니다. 인간의 정확도는 85.91%인 반면, GPT-4-Turbo는 40.38%, GPT-4o는 42.73%를 기록했습니다. 현재 가장 우수한 모델들도 실제 표의 복잡성을 반영하도록 설계된 벤치마크에서 인간 수준의 약 절반 정도의 성능을 보여주고 있습니다.
• 금융 스프레드시트에서의 복잡성 붕괴는 심각합니다. FinSheet-Bench(arXiv:2603.07316)는 다양한 구조적 복잡성을 가진 사모펀드 템플릿을 사용하여 LLM을 테스트합니다. 단순 조회는 89.1%의 정확도를 달성하지만, 복잡한 집계 작업은 19.6%로 급락합니다. 가장 큰 테스트 파일(152개 기업, 8개 펀드)의 경우 모든 모델의 평균 정확도는 48.6%였으며, 이는 가장 단순한 파일에서의 86.2%에서 크게 하락한 수치입니다.
• 긴 표는 모델의 기능을 근본적으로 무너뜨립니다. TMLR 설문 조사에 따르면 1,000 토큰을 넘어서면 GPT-3의 성능은 무작위 수준으로 저하됩니다. 200K 컨텍스트 윈도우를 가진 모델조차도 긴 시퀀스에 대한 셀프 어텐션의 이차 비용 문제로 인해 대규모 데이터셋 처리에 어려움을 겪습니다.

유효한 결과와 그렇지 않은 것

Sui 등의 벤치마크는 정교하게 설계되었으며 그 수치는 신뢰할만합니다. 구조적 작업에서 HTML이 마크다운보다 성능이 뛰어나다는 발견은 다소 직관에 어긋납니다(마크다운이 더 간결하고 LLM 학습 데이터에 더 많이 포함되어 있음). 하지만 이는 HTML의 명시적인 태깅이 모델이 구조를 추론할 필요 없이 탐색할 수 있는 더 많은 닻(anchor)을 제공한다는 점을 고려하면 납득할 수 있는 결과입니다.

회의적인 부분: 셀프 증강 기법(응답 전 핵심 값을 식별하도록 요청하는 2단계 프롬프팅)은 TabFact나 ToTTo와 같은 벤치마크에서 0.84~5.68%의 개선을 보였습니다. 이는 실제 실험에서 얻은 수치이지만 미미한 수준입니다. 이 기법은 근본적인 문제를 해결하지 못하며, 근본적으로 취약한 구조적 이해력 위에 덧댄 프롬프트 엔지니어링 패치일 뿐입니다.

TMLR 설문 조사는 모든 설문 조사가 갖는 범위의 문제를 안고 있습니다. 표 형식 예측(XGBoost의 영역)부터 생성적 표 합성, QA까지 모든 것을 다루다 보니 분석의 깊이가 얕아집니다. 제 목적에 가장 유용한 섹션은 구조적 QA 트랙이었지만, 그곳에서도 설문 조사는 어떤 방법이 실제로 신뢰할 수 있는지 종합하기보다는 주로 방법론을 나열하는 데 그쳤습니다.

복잡한 집계 점수가 19.6%에 불과하다는 FinSheet-Bench의 결과는 여기서 가장 주목해야 할 금융 특화 경고 신호입니다. 포트폴리오 집계, 펀드 수준의 롤업(roll-up), 다기간 비교는 재무 보고를 까다롭게 만드는 핵심 작업이며, 바로 이 부분에서 LLM이 무너지고 있습니다.

금융 AI에서 이것이 중요한 이유

Beancount 장부는 표입니다. 자율 에이전트가 이상 징후를 탐지하거나 보고서를 생성하거나 기록(write-back) 여부를 결정하기 위해 장부를 읽을 때, 이는 표 형식 추론을 수행하는 것입니다. 증거에 따르면 현재의 LLM은 단순 조회는 합리적으로 잘 처리하지만(GPT-4의 셀 검색 73%), 다단계 집계, 대규모 장부의 크기 추정, 구조적 변형에 대한 추론과 같이 가장 중요한 작업에서는 무너집니다.

직렬화 방식에 대한 발견은 즉각적인 실무적 시사점을 줍니다. Beancount 파일을 LLM으로 전달할 때 선택하는 형식은 에이전트 로직을 한 줄도 작성하기 전에 정확도에 수 퍼센트 포인트의 영향을 미칩니다. Beancount의 네이티브 구문은 형식 계층 구조에서 "NL+Sep" 끝에 가깝습니다. 이는 인간에게는 읽기 쉽지만 LLM에게는 최적화되지 않은 형태입니다. 모델에 입력하기 전에 더 구조화된 중간 형태(JSON 또는 HTML 거래 테이블)로 변환하는 것이 전처리 비용을 감수할 만큼의 가치가 있을 수 있습니다.

규모에 따른 성능 붕괴는 가장 뼈아픈 발견입니다. 소규모 비즈니스를 위한 실제 Beancount 장부에는 수천 개의 거래, 수십 개의 계정 및 수년 간의 내역이 포함될 수 있습니다. FinSheet-Bench 결과는 표가 실제로 의미 있는 규모로 커지면 LLM의 정확도가 자율적인 기록 작업을 맡기기에는 안전하지 않은 수준으로 저하됨을 시사합니다.

다음에 읽어볼 만한 것들

• TableLLM (arXiv:2311.09206) — 169개의 Kaggle 표(UniPredict)로 미세 조정된 모델입니다. 표 형식 예측에서 GPT-4 제로샷 성능을 크게 상회하는 것으로 보고되었으며, 이는 금융 관련 표 작업에는 여전히 도메인 특화 미세 조정이 올바른 접근 방식임을 시사합니다.
• TAT-QA (arXiv:2105.07624) — 하이브리드 금융 문서(실적 보고서와 같이 표와 텍스트가 혼합된 형태)에 대한 이산 추론을 위해 특별히 제작된 데이터셋입니다. 함께 제공되는 TAT-LLM 모델은 금융 표 추론에 특화된 모델을 적용하는 가장 직접적인 선례입니다.
• ToRR: A Benchmark for Table Reasoning and Robustness (arXiv:2502.19412) — 행 셔플링 및 열 재정렬과 같은 적대적 변동에 집중합니다. Beancount 에이전트가 재정렬에도 견고하다면, 이는 에이전트가 위치가 아닌 구조를 이해하고 있다는 신호입니다.