LLM 테이블 추론 한계 돌파! ‘Chain-of-Table’ 완벽 가이드

LLM, 엑셀 표만 만나면 왜 작아지는가?

LLM(거대 언어 모델)은 정말 똑똑합니다. 자유로운 형식의 텍스트(free-form text)를 이해하는 능력은 탁월하죠. 하지만 행과 열로 구성된 엑셀 표, 즉 ‘반(半)구조화된 데이터’만 만나면 종종 길을 잃고 맙니다.

AI 개발자나 데이터 분석가라면 누구나 공감할 문제입니다.

단순히 표의 데이터를 읽는 것을 넘어, 여러 조건이 얽힌 복잡한 질문을 던지면 문제는 더 심각해집니다. 예를 들어 볼까요?

“작년 3분기에 상위 3개 제품을 구매한 상위 5개 고객의 평균 구매액은?”

이런 질문은 텍스트처럼 순차적으로 읽어서 답할 수 없습니다. 여러 행과 열에 걸쳐 복잡한 계산과 추론이 필요하죠.

기존 방식들은 왜 실패했을까?

이 문제를 풀기 위해 여러 시도가 있었습니다. 하지만 모두 명확한 한계가 있었죠.

1. 기존의 ‘Chain-of-Thought’ (CoT)

이 방식은 LLM이 ‘생각의 흐름’을 텍스트로 쭉 적어 내려가는 방식입니다. “1단계: 작년 3분기 데이터를 찾는다. 2단계: 상위 3개 제품을 필터링한다…”처럼 말이죠.

문제점: 텍스트 추론에는 강하지만, 표의 ‘구조’ 자체를 다루는 데는 역부족입니다. 말 그대로 ‘생각’만 할 뿐, 표를 직접 ‘처리’하지는 못하니까요.

2. ‘Program-aided Reasoning’ (SQL 생성)

그렇다면 LLM에게 아예 복잡한 SQL 쿼리를 짜게 하면 어떨까요?

문제점: 현실의 데이터는 깨끗하지 않습니다. ‘Alejandro (ESP)’처럼 이름과 국가가 한 셀에 합쳐진 ‘지저분한(messy)’ 테이블을 만나면, LLM이 생성한 SQL은 실행조차 되지 않는 경우가 태반입니다.

결국 LLM이 표를 기반으로 정확한 답을 하려면, 텍스트와 구조화된 데이터를 동시에 이해하고, 심지어 ‘처리’까지 할 수 있는 새로운 방식이 필요했습니다.

새로운 해법: ‘Chain-of-Table’ (CoT)

2024년 ICLR 학회에서 이 문제를 정면으로 돌파한 논문이 발표되었습니다. 바로 ‘Chain-of-Table’ (CoT) (https://arxiv.org/pdf/2401.04398)입니다.

이름에서 알 수 있듯이, 이 프레임워크는 LLM이 ‘생각의 연쇄(Chain-of-Thought)’를 텍스트가 아닌 ‘테이블의 연쇄(Chain-of-Table)’로 구성합니다.

핵심 아이디어는 이것입니다.

“LLM이 질문에 답하기 위해 ‘중간 생각’을 텍스트로 적는 대신, ‘중간 테이블’을 만들도록 하자.”

즉, LLM은 더 이상 수동적인 관찰자가 아닙니다. 추론 과정에 맞춰 표 자체를 ‘진화’시키는 능동적인 행위자가 됩니다.

(기존 CoT): “1단계: A를 찾는다. 2단계: B를 계산한다…” (텍스트로 생각)

(새로운 CoT): “1단계: ‘국가’ 열을 새로 추가해라. 2단계: 상위 3개 행만 선택해라…” (테이블을 직접 조작)

이 일련의 ‘테이블 진화 과정’ 자체가 바로 LLM의 구조화된 추론 과정이 되는 것입니다.

Chain-of-Table은 어떻게 작동할까?

이 과정은 마치 숙련된 요리사가 복잡한 레시피(질문)를 보고, 거대한 창고(원본 테이블)에서 필요한 재료를 순서대로 꺼내고 다듬어(테이블 변형) 최종 요리(답변)를 내놓는 과정과 비슷합니다.

이 과정은 크게 3단계의 ‘반복’으로 이루어집니다.

1단계: DynamicPlan (동적 계획)

먼저 LLM은 현재 테이블 상태와 질문을 보고 ‘다음’에 할 작업을 동적으로 계획합니다. 이때 미리 정의된 5가지 핵심 ‘연장(Operation)’ 중에서 하나를 선택합니다.

• f_add_column(): 새 열 추가 (e.g., ‘이름(국가)’에서 ‘국가’만 추출)
• f_select_row(): 조건에 맞는 행 선택 (e.g., ‘상위 3위’ 행만 필터링)
• f_select_column(): 필요한 열 선택 (e.g., 불필요한 열 제거)
• f_group_by(): 특정 열 기준 그룹화 (e.g., ‘국가’별로 묶기)
• f_sort_by(): 특정 열 기준 정렬 (e.g., ‘개수’ 기준 내림차순 정렬)

2단계: GenerateArgs (인수 생성)

‘무엇을’ 할지(e.g., f_group_by) 결정했다면, ‘어떻게’ 할지에 대한 세부 인수를 생성합니다.

예를 들어 f_group_by 작업을 선택했다면, LLM은 “어떤 열을 기준으로 그룹화할까?”라는 질문에 “Country”라는 인수를 생성합니다.

3단계: 테이블 변형 및 반복

생성된 작업과 인수를 결합하여 실제 테이블을 프로그래밍 방식으로 ‘변형’시킵니다.

이렇게 ‘진화한’ 새로운 중간 테이블은 다시 1단계의 입력값으로 돌아갑니다. 이 과정은 LLM이 모든 추론이 끝났다고 판단할 때까지(종료 태그 [E] 생성) 반복됩니다.

최종 단계: Final Query (최종 질의)

모든 반복이 끝나면, 질문에 답하는 데 최적화된 ‘최종 테이블’이 남습니다. 복잡했던 원본 테이블이 “국가(Country)”와 “횟수(Count)”만 남은 단순한 요약 테이블로 바뀐 것이죠.

LLM은 이 최종 테이블과 원본 질문을 함께 받아, 훨씬 더 쉽고 정확하게 정답(“Italy”)을 도출합니다.

Chain-of-Table은 왜 더 강력할까?

이 접근 방식은 단순한 아이디어를 넘어, 실제 벤치마크에서 기존 방법들을 압도하는 성과를 보여주었습니다.

1. 새로운 SOTA 달성 (정확도)

Chain-of-Table은 WikiTQ, TabFact 등 주요 테이블 이해 벤치마크에서 SOTA(최고 성능)를 달성했습니다. PaLM 2 모델 기준, 기존 CoT 방식(60.43%) 대비 Chain-of-Table(67.31%)은 약 7%p 가까이 성능이 향상되었습니다. 구조화된 중간 결과물(테이블)이 LLM의 안정적인 추론을 돕는다는 것이 증명된 것입니다.

2. 놀라운 효율성 (비용 절감)

더 흥미로운 지점은 ‘효율성’입니다. 더 정확할 뿐만 아니라, LLM 호출 횟수, 즉 비용이 더 저렴합니다.

하나의 질문을 처리하기 위해 다른 파이프라인(Binder 50회, Dater 100회)과 달리, Chain-of-Table은 평균 25회 미만의 LLM 호출을 사용했습니다. 이는 Binder 대비 50%, Dater 대비 75% 적은 수치입니다. LLM이 동적으로 테이블을 변형하며 효과적인 추론 경로를 스스로 찾아내기 때문에, 불필요한 헛수고(샘플링, 검증)가 필요 없어진 것입니다.

3. 대형 테이블에서의 안정성

LLM은 입력 컨텍스트(토큰)가 길어지면 성능이 저하되는 경향이 있습니다. 토큰 수 4,000개가 넘는 ‘대형’ 테이블이 입력되자, 기존 방식들(Binder 6.41%, Dater 34.62%)은 정확도가 급격히 추락했습니다.

반면, Chain-of-Table(44.87%)은 성능 하락 폭이 상대적으로 완만했습니다. 추론 과정에서 f_select_row나 f_select_column 같은 ‘연장’을 통해 불필요한 정보를 동적으로 제거하며 컨텍스트를 효율적으로 관리하기 때문입니다.

결론: LLM 테이블 추론의 새로운 지평

Chain-of-Table은 LLM이 테이블 데이터를 다루는 방식에 대한 근본적인 패러다임 전환을 제시합니다.

LLM은 더 이상 테이블을 ‘읽고’ 텍스트로 ‘생각’하는 수동적인 관찰자가 아닙니다. 이제 LLM은 테이블을 ‘조작’하고 ‘진화’시키는 능동적인 행위자가 되어, 스스로 데이터를 정제하고 구조화된 추론 과정을 시각적으로 증명해냅니다.

이 연구는 LLM을 단순한 챗봇이 아닌, 정교한 데이터 분석가나 BI(비즈니스 인텔리전스) 툴의 핵심 엔진으로 활용할 수 있는 새로운 가능성을 열어주었습니다.