2026 개정판 · 1차 8월 8일 공개전체 커리큘럼 →
TECH 으로 돌아가기
TECH HACKER NEWS 오늘 6분 읽기 39 READS

LLM은 왜 표 데이터 예측에 약할까 — 여전히 XGBoost를 못 이기는 이유

LLM은 왜 표 데이터 예측에 약할까 — 여전히 XGBoost를 못 이기는 이유
SOURCE IMAGE · HACKER NEWS
LLM은 왜 표 데이터 예측에 약할까 — 여전히 XGBoost를 못 이기는 이유

ChatGPT 같은 LLM한테 코드를 짜달라고 하면 척척 해내고, 긴 문서 요약도 잘하죠. 그런데 의외로 못하는 게 하나 있어요. 바로 엑셀이나 데이터베이스에 들어있는 '표 형태의 데이터'로 뭔가를 예측하는 일이거든요. 예를 들어 고객 정보 테이블을 주고 "이 고객이 다음 달에 이탈할까?"를 맞혀보라고 하면, 20년 된 전통적인 머신러닝 기법보다 못한 결과를 내는 경우가 많아요. 최근 아카이브(arXiv)에 올라온 논문이 바로 이 문제, 'LLM은 왜 표 데이터 예측에 실패하는가'를 정면으로 파고들었는데요. 오늘은 이 내용을 차근차근 풀어볼게요.

표 데이터 예측이 뭐냐면요

'테이블러 프레딕션(tabular prediction)'이라고 하면 어렵게 들리는데, 사실 실무에서 제일 흔한 머신러닝이에요. 행(row)과 열(column)로 된 데이터, 그러니까 나이·연봉·가입일 같은 컬럼이 있는 테이블에서 "대출을 갚을까?", "이 거래가 사기일까?" 같은 값을 예측하는 거죠. 은행, 커머스, 게임사 할 것 없이 회사에서 실제로 돌아가는 머신러닝의 대부분이 이런 정형 데이터 예측이에요. 그러니 LLM이 여기서 약하다는 건 생각보다 큰 이야기인 거죠.

LLM이 헤매는 이유

첫 번째 이유는 숫자를 다루는 방식 자체에 있어요. LLM은 텍스트를 '토큰'이라는 조각으로 쪼개서 읽는데요, 이 과정에서 34521 같은 숫자가 '345'와 '21'처럼 엉뚱하게 잘려버려요. 사람은 34521이 34520보다 딱 1 크다는 걸 직관적으로 알지만, 토큰으로 쪼개진 모델 입장에선 그 '크기 감각'이 흐릿해지는 거죠. 소수점 아래 정밀한 값의 비교가 승부를 가르는 표 데이터에서는 치명적이에요.

두 번째는 표를 텍스트로 바꾸는 과정에서 구조가 망가진다는 점이에요. LLM에 표를 넣으려면 결국 "나이: 34, 연봉: 5200, ..." 같은 문장으로 풀어서(직렬화해서) 넣어야 하는데, 이러면 컬럼 순서를 바꾸기만 해도 예측 결과가 달라지는 황당한 일이 생겨요. 원래 표 데이터에서 열의 순서는 아무 의미가 없어야 하는데 말이죠.

세 번째는 학습량의 문제예요. XGBoost 같은 모델은 수십만 행을 통째로 학습하면서 데이터 속 통계적 패턴을 뽑아내는데, LLM은 컨텍스트 창에 넣을 수 있는 몇십~몇백 개의 예시만 보고 판단해야 하거든요. 게다가 사전학습 때 배운 '상식'이 오히려 방해가 되기도 해요. 눈앞의 데이터가 보여주는 패턴보다 "보통 나이가 많으면 연봉이 높지" 같은 세상 지식으로 때려맞히는 경향이 있다는 거죠. 데이터가 상식과 다른 패턴을 가지고 있으면 그대로 틀리는 거예요.

그래서 지금 판세는

이건 사실 학계에서 꾸준히 확인되어 온 흐름이에요. 캐글(Kaggle) 대회에서 정형 데이터 문제의 우승 솔루션은 여전히 XGBoost, LightGBM, CatBoost 같은 그래디언트 부스팅 트리 계열이 꽉 잡고 있고요. 딥러닝 쪽에서는 아예 표 데이터 전용으로 사전학습한 TabPFN 같은 '표 전용 파운데이션 모델'이 대안으로 떠오르고 있어요. TabPFN은 작은 데이터셋에서 부스팅 모델을 이기는 결과로 네이처에 실리기도 했죠. 즉 '범용 LLM을 그대로 들이대는 것'과 '표에 특화된 모델을 쓰는 것' 사이의 격차가 분명히 존재한다는 게 점점 뚜렷해지는 중이에요.

우리한테 주는 교훈

실무에서 "요즘은 다 LLM으로 하는 거 아니야?"라는 압박을 받는 분들이 많을 텐데요, 적어도 정형 데이터 예측만큼은 아직 아니라는 게 이 논문의 메시지예요. 이탈 예측, 수요 예측, 이상 거래 탐지 같은 문제라면 LightGBM 하나 잘 튜닝하는 게 API 비용도 없고 성능도 좋을 가능성이 높아요. 대신 LLM은 다른 자리에서 빛나요. 컬럼 이름만 보고 어떤 파생 변수를 만들면 좋을지 아이디어를 내주는 피처 엔지니어링 조수, 전처리 코드 생성, 텍스트 컬럼을 임베딩으로 바꿔주는 역할처럼요. '예측기'가 아니라 '보조자'로 쓰는 거죠.

정리하면, LLM은 언어의 천재지만 숫자 표 앞에서는 아직 신입사원이라는 얘기예요. 여러분 회사에서는 정형 데이터 문제에 LLM을 써보신 적 있나요? 부스팅 모델과 비교해봤을 때 어땠는지 경험담이 궁금해요.


🔗 출처: Hacker News

SOURCE · HACKER NEWS
원문 전체 보기 → https://arxiv.org/abs/2608.02412
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기
처리 중...