본문으로 건너뛰기

Chain-of-Table: LLM 추론 체인에서의 테이블 진화

· 약 5분
Mike Thrift
Mike Thrift
Marketing Manager

표 형식 추론(tabular reasoning)에 대해 저는 늘 한 가지 불편한 관찰 결과로 되돌아오곤 합니다. LLM이 일반적인 생각의 사슬(Chain-of-Thought, CoT) 텍스트를 사용하여 테이블에 대한 작업을 설명할 때, 실제로는 다른 형식을 추론하면서 동시에 하나의 표현 방식을 서술하고 있다는 점입니다. ICLR 2024에서 발표된 Google Research의 논문인 'Chain-of-Table'은 이러한 괴리를 진지하게 받아들이고 간단한 해결책을 제시합니다. 바로 텍스트가 아닌 테이블 자체가 중간 추론 상태를 담게 하는 것입니다.

논문 요약

2026-06-11-chain-of-table-evolving-tables-reasoning-chain

Wang 등은 'Chain-of-Table: Evolving Tables in the Reasoning Chain for Table Understanding (arXiv:2401.04398, ICLR 2024)'을 발표했습니다. 이 논문은 표 형식 데이터에 표준 CoT 프롬프팅을 적용했을 때 발생하는 간극을 다룹니다. CoT는 자연어로 추론하지만, 테이블은 구조화된 결과물이며 테이블 변환을 언어로 서술하는 것은 장황할 뿐만 아니라 정보 손실이 발생하기 쉽습니다. 핵심 아이디어는 LLM이 프로그래밍 방식의 테이블 연산(필터링, 그룹화, 정렬, 열 선택, 열 추가) 시퀀스를 계획하게 하고, 각 연산을 실행하여 중간 테이블 상태를 생성한 뒤, 진화된 테이블을 다음 단계의 입력으로 LLM에 다시 제공하는 것입니다. 최종 답변은 긴 텍스트 사슬이 아닌 최종 테이블 상태에서 생성됩니다. 저자들은 이를 SQL 개발에 명확히 비유합니다. 숙련된 분석가는 하나의 거대한 쿼리 대신 CREATE TABLE ... AS SELECT와 같은 중간 단계들을 작성한다는 것입니다. Chain-of-Table은 이러한 관행을 LLM 에이전트용으로 공식화했습니다.

평가는 WikiTableQuestions (WikiTQ), TabFact, FeTaQA 등 세 가지 벤치마크를 대상으로 진행되었습니다. 주요 모델은 PaLM 2이며, GPT-3.5 및 LLaMA 2 70B에서 교차 검증을 거쳤습니다.

핵심 아이디어

  • Chain-of-Table은 WikiTQ에서 67.31%의 표기 정확도(denotation accuracy)를 달성하여, 이전의 가장 강력한 베이스라인인 Dater의 61.48% 대비 5.83%포인트 향상된 성능을 보였습니다.
  • 4,000 토큰을 초과하는 테이블에서는 그 격차가 +10.25포인트(44.87% 대 34.62%)로 벌어지는데, 이는 실제 환경에서 이 방법론이 가장 중요하게 작용하는 지점입니다.
  • TabFact 정확도는 Dater의 84.63% 대비 86.61%에 도달했으며, FeTaQA BLEU 점수는 29.47에서 32.61로 개선되었습니다.
  • 다섯 가지 원자적 연산(f_select_row, f_select_column, f_group_by, f_sort_by, f_add_column)은 해당 벤치마크에서 관찰된 대부분의 추론 패턴을 포괄합니다. 특히 계산 오류가 주된 실패 원인인 WikiTQ에서는 f_group_by가 가장 큰 역할을 합니다.
  • Chain-of-Table은 질문당 최대 25개의 샘플 생성을 필요로 하는 반면, Binder는 50개, Dater는 100개가 필요합니다. 이는 더 나은 정확도와 함께 50~75%의 효율성 이득을 의미하며, 성능과 효율성 사이의 트레이드오프가 발생하는 LLM 연구 분야에서는 매우 이례적인 결과입니다.
  • 이 접근 방식은 모델에 구애받지 않습니다(model-agnostic). PaLM 2, GPT-3.5, LLaMA 2 전반에서 텍스트 기반 CoT 베이스라인보다 일관되게 우수한 성능을 보였습니다.

유효한 점과 한계점

이 논문의 핵심적인 실증적 기여는 탄탄합니다. 벤치마크는 표준적이며 베이스라인은 공정하고 효율성 측면의 이야기도 설득력이 있습니다. 테이블 자체를 산문으로 서술하는 대신 명시적인 중간 표현으로 만드는 것은 직관적인 동기를 가진 깔끔한 아이디어입니다. 특히 대규모 테이블에서의 결과가 가장 강력한 증거가 됩니다. 테이블이 컨텍스트에 간신히 들어갈 정도일 때, 연산을 통해 점진적으로 중요한 내용만 남기는 것이 더 많은 텍스트를 생성하는 것보다 분명히 더 낫기 때문입니다.

그럼에도 불구하고 실제적인 한계점들이 존재합니다. 오류 전파(error propagation) 분석이 표면적입니다. 만약 LLM이 5단계 체인의 두 번째 단계에서 잘못된 f_select_row 인자를 생성한다면, 이후의 모든 연산은 오염된 중간 테이블에서 수행되며 최종 답변은 엉망이 됩니다. 논문은 종합적인 정확도를 보고하지만, 초기 단계의 오류와 후기 단계의 오류 중 무엇 때문에 추론이 실패하는지, 또는 이 접근 방식이 부분적으로 잘못된 연산에 얼마나 견고한지에 대해서는 분석하지 않았습니다. 일련의 올바른 호출에 의존하는 방법론으로서는 의미 있는 누락입니다.

연산 어휘(vocabulary)의 선택 또한 일종의 도박입니다. WikiTQ와 TabFact의 대부분의 패턴을 다섯 가지 연산으로 커버할 수 있는 이유는 해당 벤치마크들이 관계형 테이블 작업을 중심으로 설계되었기 때문입니다. 재무 상태표, 원장 시산표, 세무 일정표와 같은 실제 금융 테이블은 관련 테이블 간의 조인(join), 조건부 집계(계정이 '6'으로 시작하는 차변 금액의 합계), 피벗 변환 등을 일상적으로 요구합니다. 이러한 연산들은 현재 세트에 포함되어 있지 않습니다. 저자들도 이를 암시적으로 인정하고 있지만 직접 테스트하지는 않았습니다.

마지막으로, 왜 중간 테이블 상태가 중간 텍스트보다 나은지에 대한 이론적인 설명이 부족합니다. 직관적으로는 매력적이지만 이 논문은 순수하게 실증적입니다. 후속 연구(TableMaster, arXiv:2501.19378; H-STAR, NAACL 2025)가 SQL과 텍스트 추론을 혼합하는 적응형 하이브리드 접근 방식으로 빠르게 전환된 점은, 학계에서도 저와 비슷한 한계를 느꼈음을 시사합니다. 순수 표 형식 연산이 보편적으로 더 나은 것이 아니라, 테스트된 벤치마크에서만 더 낫다는 것입니다.

금융 AI에서의 중요성

Beancount 원장 에이전트의 경우, Chain-of-Table의 아키텍처는 제가 라이트백(write-back) 파이프라인에서 원하는 모습과 거의 완벽하게 일치합니다. ":ignore 태그가 붙은 거래를 제외하고 1분기 카테고리별 순 지출은 얼마인가?"와 같은 Beancount 쿼리는 논문에서 제안한 순차적 테이블 변환(날짜별 행 필터링, 태그별 필터링, 계정 카테고리별 그룹화, 금액 합계)을 정확히 필요로 합니다. 에이전트가 단일 쿼리를 생성하거나 산문으로 추론하는 대신 이를 명시적인 중간 연산의 체인으로 계획할 수 있다면, 감사 추적(audit trail)이 읽기 쉬워지고 각 단계를 독립적으로 검증할 수 있게 됩니다.

대규모 테이블에서의 효율성 향상 또한 직접적으로 관련이 있습니다. 수만 개의 거래가 포함된 다년치 Beancount 원장은 구체화(materialize)될 경우 4,000 토큰을 쉽게 초과합니다. 이러한 환경에서의 10포인트 성능 향상은 단순한 벤치마크 수치가 아닙니다. 추론이 정밀해지기 전에 테이블을 점진적으로 좁혀야 하는 실제 상황을 반영합니다.

Beancount에 있어 빠진 조각은 조인(join) 연산입니다. 복식 부기는 계정 간의 거래를 연결하며, 모든 대조(reconciliation) 작업은 최소 두 개 이상의 계정 타임라인에 걸친 추론을 필요로 합니다. 현재 발표된 Chain-of-Table은 이를 표현할 수 없습니다. 계정 간 조인을 포함하도록 연산 어휘를 확장하는 것이 프로덕션용 Beancount 추론 에이전트를 위한 명백한 다음 엔지니어링 단계입니다.

더 읽어보기

  • Chain-of-Query: Unleashing the Power of LLMs in SQL-Aided Table Understanding via Multi-Agent Collaboration (2025, arXiv:2508.15809) — 조인 문제를 해결하는 다중 에이전트 SQL 생성으로 연산 개념을 확장합니다.
  • TableMaster: A Recipe to Advance Table Understanding with Language Models (arXiv:2501.19378) — 테이블 연산과 텍스트 CoT 사이를 전환하는 적응형 추론을 도입한, Chain-of-Table의 직접적인 후속 연구입니다.
  • DATER: Decomposition-based Text-to-SQL for LLMs over Long Context (arXiv:2308.01463) — 대규모 스키마에 대한 복잡한 SQL을 위한 보완적인 분해 접근 방식으로, beanquery 자연어 인터페이스 설계와 관련이 있습니다.