SQL을 정확히 짜고, 대학원 시험 문제를 풀고, 복잡한 코드를 리뷰하는 LLM이 있습니다. 그런데 이 모델에게 숫자로 된 표를 던져주고 “이 값이 A인지 B인지 분류해봐”라고 하면 이야기가 달라지죠. 트랜스포머가 나오기 수십 년 전에 만들어진 단순한 통계 기법에마저 지는 경우가 많습니다.

이 격차가 워낙 뚜렷해서, 아예 표 데이터 전용으로 설계된 “테이블형 파운데이션 모델”이라는 연구 분야까지 따로 생겼습니다. 그런데 정작 “왜 LLM이 이 작업에 약한가”라는 질문에는 다들 전제만 깔았을 뿐, 제대로 답한 적이 없었습니다.

출처: Why Large Language Models Fail at Tabular Prediction – Marta Garnelo, Wojciech M. Czarnecki (arXiv)

도구도 요령도 없이, 모델 그 자체만 시험대에 세우다

연구진은 이 질문에 정면으로 답하기 위해 검색이나 도구 사용, 에이전트 스캐폴딩, 파인튜닝을 모두 걷어냈습니다. 학습 데이터와 테스트 데이터를 통째로 프롬프트 하나에 담아 claude-opus-4-6에게 한 번에 넘기고, 그 결과만으로 판단하는 방식입니다. 무언가를 덧붙여서 점수를 올리는 게 아니라, 모델 자체가 정확히 무엇을 못 하는지 가려내려는 설계였죠.

연구진은 실무에서 떠도는 다섯 가지 가설을 하나씩 검증했습니다. 데이터에 노이즈가 섞이거나 선형으로 나뉘지 않으면 못 다루는 게 아닐까. CSV로 한 줄씩 늘어놓은 형식이 열 구조를 가리는 게 아닐까. 숫자를 토큰으로 쪼개는 방식, 혹은 한 번에 너무 많은 테스트 항목을 물어보는 것도 원인 후보였습니다. 마지막으로 입력 데이터의 차원, 즉 변수 개수 자체가 문제라는 가설도 있었죠.

네 가지는 틀렸고, 하나만 결정적이었다

통제 실험 결과 앞의 네 가지 가설은 모두 기각됐습니다. 노이즈가 섞이든, CSV 형식을 바꾸든, 숫자 표기 방식을 조정하든, 테스트 항목 수를 줄이든 성능에 별다른 영향이 없었던 것입니다.

결정적인 건 딱 하나, 차원 수였습니다. 연구진은 31개 벤치마크 데이터셋에 무작위 선형 투영을 적용해 정보량은 그대로 두면서 차원만 늘려가며 실험했죠. 그 결과 아홉 가지 방법 중 LLM만이 유일하게 차원이 늘어날수록 정확도가 떨어졌습니다. 나머지 전통적인 방법들은 성능이 그대로거나 오히려 개선됐습니다.

2차원까진 똑똑했는데, 그 이상은 아무도 못 알아본다

여기서 더 흥미로운 반전이 나옵니다. 변수가 두 개뿐인 단순한 문제에서는 LLM의 판단 경계가 가우시안 프로세스나 가까운 이웃 몇 개만 보는 거리 기반 알고리즘과 최대 91.6%까지 거의 똑같았습니다. 마치 LLM이 “가까운 데이터를 보고 판단하는” 단순한 방식으로 작동하는 것처럼 보인 것입니다.

문제는 차원이 늘어난 다음부터입니다. 연구진이 252개의 고전적 모델을 세밀하게 조정해가며 비교했지만, LLM의 예측 패턴과 가장 비슷한 모델조차 일치율이 64.8%를 넘지 못했죠. 차원에 따라 노이즈를 조정해 흉내 내려 해도 일치율은 기껏해야 0.64퍼센트포인트 오르는 데 그쳤습니다.

고차원에서 LLM이 정확히 어떤 논리로 예측하는지는, 이 논문에서도 끝내 밝혀내지 못한 채로 남은 것입니다.

표를 실무에 쓰는 사람에게 남는 것

매출 예측, 고객 이탈 예측, 재고 수요 추정처럼 변수가 여러 개인 표를 다루는 작업은 정확히 이 연구가 짚은 취약 지점과 겹칩니다. 변수가 하나둘일 때는 LLM이 그럴듯하게 판단하는 것처럼 보여도, 변수가 늘어날수록 그 판단의 근거는 점점 불투명해지는 것입니다.

이 논문은 LLM에게 표 데이터를 통째로 맡기는 방식 자체의 한계를 보여준 것이지, 검색이나 별도 도구를 결합한 방식까지 같은 결론이라고 말하지는 않죠. 다만 변수가 많은 표를 프롬프트에 그대로 욱여넣고 판단을 맡기는 방식이라면, 그 결과를 곧이곧대로 믿기보다 한 번쯤 의심해볼 이유가 생긴 셈입니다.