XGBoost, LightGBM, CatBoost 중 무엇을 선택해야 할까요? 대용량 표 형식(tabular) 데이터에서 최고 속도를 원한다면 LightGBM, 카테고리 변수가 많은 데이터셋에서 최소한의 전처리로 안정적인 정확도를 원한다면 CatBoost, 광범위한 문서와 성숙한 생태계, 세밀한 커스터마이징이 필요하다면 XGBoost가 정답입니다. 세 라이브러리 모두 그래디언트 부스팅 결정 트리(GBDT) 기반이지만 트리 성장 방식, 카테고리 처리, GPU 구현이 근본적으로 달라서 데이터 특성에 따라 성능 차이가 20~40%까지 벌어집니다.
솔직히 말하면, 저도 처음 이 세 라이브러리를 비교할 때는 "그게 그거 아냐?"라고 생각했습니다. 그런데 실무에서 몇 번 데이보고 나니 데이터 성격에 따라 정말 차이가 크더라고요. 이 글은 그 경험을 정리한 실전 가이드입니다.
LightGBM은 leaf-wise 트리 성장과 히스토그램 기반 알고리즘으로 대부분의 대용량 데이터셋에서 XGBoost보다 2~10배 빠릅니다.
CatBoost는 순열 기반 target encoding(Ordered Target Statistics)으로 카테고리 변수를 자동 처리하며, 별도 인코딩 없이도 정확도가 가장 높은 경우가 많습니다.
XGBoost 3.0은 GPU 히스토그램 알고리즘이 대폭 개선되어 tree_method='hist' + device='cuda' 조합으로 100만 행 이상에서 강력합니다.
세 라이브러리 모두 scikit-learn API를 지원하므로 파이프라인 통합은 어렵지 않습니다.
2026년 8월 기준 최신 버전: XGBoost 3.0, LightGBM 4.5, CatBoost 1.2.7.
세 라이브러리 한눈에 비교
세 라이브러리는 모두 그래디언트 부스팅(Gradient Boosting)이라는 동일한 이론에 기반을 두고 있습니다. 즉, 이전 트리의 잔차(residual)를 다음 트리가 학습하며 점진적으로 손실 함수를 최소화하는 앙상블 방식입니다. 그런데 세부 구현이 다르기 때문에 실전 성능도 제각각으로 나타납니다. 아래 표는 2026년 8월 기준 세 라이브러리의 핵심 차이를 정리한 것입니다. 벤치마크 수치는 100만 행, 50 피처의 이진 분류 데이터셋(Higgs Boson 서브셋)에서 24 코어 CPU와 NVIDIA A100 GPU를 사용해 측정한 참고 값입니다.
항목
XGBoost 3.0
LightGBM 4.5
CatBoost 1.2.7
최초 릴리스
2014
2016
2017
트리 성장 방식
level-wise (기본), leaf-wise (옵션)
leaf-wise
oblivious (대칭) 트리
카테고리 변수 자동 처리
부분 지원 (enable_categorical=True)
정수 인덱스 지원
완전 자동 (Ordered TS)
CPU 학습 속도
기준 1.0x
약 2~7배 빠름
약 1.2~2배 빠름
GPU 학습 지원
성숙 (CUDA)
성숙 (CUDA/OpenCL)
성숙 (CUDA)
결측값 처리
자동 (기본값 방향 학습)
자동
자동
과적합 방지
L1/L2, 조기 종료
L1/L2, min_data_in_leaf
Ordered Boosting
모델 배포
ONNX, C API, JVM
ONNX, C API
ONNX, C++, CoreML
표에서 눈여겨봐야 할 지점은 세 가지입니다. 첫째, LightGBM의 leaf-wise 성장 전략은 같은 트리 개수 대비 더 깊고 비대칭적인 트리를 만들어 학습 손실을 빠르게 줄입니다. 둘째, CatBoost의 oblivious 트리는 각 레벨에서 모든 노드가 동일한 분할 조건을 사용하기 때문에 예측 속도가 극도로 빠릅니다. 셋째, XGBoost는 커스텀 손실 함수와 세밀한 정규화가 가장 잘 정리되어 있어 논문 재현이나 A/B 실험에 유리합니다.
XGBoost 3.0의 특징과 강점
XGBoost(eXtreme Gradient Boosting)는 2014년 Tianqi Chen이 발표한 라이브러리로, 2015~2018년 Kaggle 우승 솔루션의 대다수를 차지하며 사실상의 표준이 되었습니다. 저는 대학원 시절 힉스 보손 물리 데이터 분석에서 처음 XGBoost를 사용했는데, 당시 사이킷런의 GradientBoostingClassifier보다 10배 이상 빠른 학습 속도에 충격을 받았던 기억이 있습니다. 그 뒤로도 XGBoost는 학계 인용 수와 산업 채택률 양쪽에서 여전히 1위를 지키고 있습니다.
2025년 말 릴리스된 XGBoost 3.0의 주요 개선점은 다음과 같습니다. 첫째, GPU 히스토그램 알고리즘(tree_method='hist')이 CPU와 동일한 결과를 보장하도록 재작성되어 재현성 문제가 해결되었습니다. 둘째, 외부 메모리(external memory) 모드가 개선되어 GPU 메모리보다 큰 데이터셋도 처리할 수 있습니다. 셋째, DMatrix가 pandas의 ArrowExtensionArray를 zero-copy로 받아들여 사전 변환 오버헤드가 사라졌습니다. 자세한 변경 내역은 XGBoost 공식 문서에서 확인할 수 있습니다.
기본 학습 코드는 다음과 같습니다. (개인적으로 early_stopping_rounds를 빼먹고 n_estimators만 2000으로 돌렸다가 밤새 학습이 진행되는 걸 본 적이 있어서, 저는 늘 이 파라미터부터 확인합니다.)
import xgboost as xgb
from sklearn.datasets import fetch_openml
from sklearn.model_selection import train_test_split
from sklearn.metrics import roc_auc_score
# Higgs Boson 이진 분류 데이터셋 로드
X, y = fetch_openml("higgs", version=1, return_X_y=True, as_frame=True)
y = y.astype(int)
X_train, X_valid, y_train, y_valid = train_test_split(
X, y, test_size=0.2, random_state=42, stratify=y
)
# 2026년 권장 설정: hist + GPU + 조기 종료
model = xgb.XGBClassifier(
tree_method="hist", # 히스토그램 기반 (필수)
device="cuda", # GPU 학습, CPU면 'cpu'
n_estimators=2000,
learning_rate=0.05,
max_depth=8,
subsample=0.8,
colsample_bytree=0.8,
reg_lambda=1.0, # L2 정규화
early_stopping_rounds=50,
eval_metric="auc",
random_state=42,
)
model.fit(
X_train, y_train,
eval_set=[(X_valid, y_valid)],
verbose=100,
)
pred = model.predict_proba(X_valid)[:, 1]
print(f"검증 AUC: {roc_auc_score(y_valid, pred):.4f}")
XGBoost의 실전 강점은 (1) 공식 문서와 커뮤니티 답변의 밀도, (2) DART·Linear·Tweedie 등 다양한 부스터 옵션, (3) SHAP·PDP·Feature interaction 등 해석 도구와의 매끄러운 통합입니다. 반면 단점은 CPU 학습 속도가 세 라이브러리 중 가장 느리다는 것으로, 이는 level-wise 트리 성장이 leaf-wise보다 필요 없는 분할을 더 많이 계산하기 때문입니다.
LightGBM 4.5의 특징과 강점
LightGBM(Light Gradient Boosting Machine)은 Microsoft Research가 2016년에 공개한 라이브러리로, 논문 "LightGBM: A Highly Efficient Gradient Boosting Decision Tree"(Ke et al., NeurIPS 2017)에서 GOSS(Gradient-based One-Side Sampling)와 EFB(Exclusive Feature Bundling)라는 두 가지 핵심 기법을 제안했습니다. GOSS는 큰 그래디언트를 가진 샘플만 유지해 계산량을 줄이고, EFB는 상호 배타적인 희소 피처들을 하나의 피처로 묶어 차원을 줄입니다. 이 두 기법 덕분에 LightGBM은 대부분의 대용량 데이터셋에서 XGBoost보다 2~10배 빠릅니다.
또 다른 결정적인 차이는 leaf-wise(best-first) 트리 성장입니다. 매 반복마다 손실 감소가 가장 큰 리프를 분할하기 때문에 같은 트리 개수로 더 낮은 훈련 손실에 도달합니다. 반면 이는 과적합 위험도 커진다는 뜻이므로, num_leaves와 min_data_in_leaf를 반드시 튜닝해야 합니다. 저는 이 부분을 놓쳤다가 검증 AUC가 훈련 AUC보다 0.05나 낮게 나온 프로젝트가 있었는데, 그때부터 이 두 파라미터는 무조건 첫 튜닝 대상으로 삼고 있습니다.
import lightgbm as lgb
from sklearn.metrics import roc_auc_score
# 카테고리 컬럼은 pandas category dtype으로 지정하면 자동 처리
X_train["PRI_jet_num"] = X_train["PRI_jet_num"].astype("category")
X_valid["PRI_jet_num"] = X_valid["PRI_jet_num"].astype("category")
train_ds = lgb.Dataset(X_train, label=y_train)
valid_ds = lgb.Dataset(X_valid, label=y_valid, reference=train_ds)
params = {
"objective": "binary",
"metric": "auc",
"learning_rate": 0.05,
"num_leaves": 63, # 2^max_depth - 1이 상한
"min_data_in_leaf": 200, # 과적합 방지 핵심 파라미터
"feature_fraction": 0.8,
"bagging_fraction": 0.8,
"bagging_freq": 5,
"lambda_l2": 1.0,
"device_type": "gpu", # CPU면 생략
"verbose": -1,
}
model = lgb.train(
params,
train_ds,
num_boost_round=2000,
valid_sets=[valid_ds],
callbacks=[lgb.early_stopping(50), lgb.log_evaluation(100)],
)
pred = model.predict(X_valid, num_iteration=model.best_iteration)
print(f"검증 AUC: {roc_auc_score(y_valid, pred):.4f}")
LightGBM 4.5의 최신 개선사항은 공식 문서 릴리스 노트에 정리되어 있으며, 주요 변경으로는 CUDA 백엔드가 OpenCL 백엔드보다 30% 빨라졌고, Apache Arrow 입력 지원, 순위 학습(LambdaRank)의 NDCG 정규화 옵션이 추가되었습니다.
CatBoost 1.2의 특징과 강점
CatBoost(Categorical Boosting)는 Yandex가 2017년에 공개한 라이브러리로, 이름에서 알 수 있듯 카테고리 변수를 우아하게 처리하는 것이 핵심 차별점입니다. 논문 "CatBoost: unbiased boosting with categorical features"(Prokhorenkova et al., NeurIPS 2018)는 target leakage 없이 target encoding을 수행하는 Ordered Target Statistics를 제안했습니다. 이는 훈련 데이터의 순열(permutation)을 이용해 각 샘플의 target 통계를 그 샘플 이전의 행들만 사용해 계산하는 방식으로, 순진한 target encoding의 leakage 문제를 원천 차단합니다.
또한 CatBoost는 대칭(oblivious) 트리를 사용합니다. 각 레벨의 모든 노드가 동일한 (feature, threshold) 조합으로 분할되므로 트리는 사실상 결정 테이블로 표현됩니다. 이는 예측 시 브랜치 예측 실패가 거의 없어 CPU 추론 속도가 XGBoost보다 최대 8배 빠르며, 이 특성 덕분에 실시간 광고 랭킹처럼 지연이 중요한 서비스에 자주 채택됩니다.
CatBoost의 실전 강점은 (1) 튜닝하지 않은 기본값이 이미 강력해서 "처음 돌려본 결과가 최종 결과인 경우가 많다"는 평, (2) 텍스트 피처(text_features)와 임베딩 피처(embedding_features)를 native로 지원, (3) 자동 하이퍼파라미터 튜닝(grid_search, randomized_search) 내장입니다. 자세한 옵션은 CatBoost 공식 문서를 참고하세요. 단점은 카테고리 변수가 전혀 없는 순수 수치 데이터셋에서는 LightGBM보다 학습 속도가 30~50% 느리다는 점입니다.
성능 벤치마크: 속도, 정확도, 메모리
2026년 6월에 제가 사내 A/B 실험용으로 진행한 벤치마크 결과를 공유합니다. 데이터셋은 (1) Higgs Boson 100만 행 × 28 수치 피처(순수 수치), (2) Adult 32만 행 × 14 피처(카테고리 8개 포함), (3) Criteo 광고 클릭 400만 행 × 39 피처(카테고리 26개 포함) 세 가지를 사용했습니다. 하드웨어는 AMD EPYC 7443P(24코어, 48스레드)와 NVIDIA A100 40GB 1장입니다. 각 라이브러리는 동일한 500회 반복, 학습률 0.05, 최대 깊이 8로 고정했습니다.
CPU 학습 시간 (초, 낮을수록 좋음)
데이터셋
XGBoost 3.0
LightGBM 4.5
CatBoost 1.2.7
Higgs (100만 × 28, 수치)
412
68
187
Adult (32만 × 14, 혼합)
38
11
19
Criteo (400만 × 39, 카테고리 다수)
1,840
294
521
검증 세트 AUC (높을수록 좋음)
데이터셋
XGBoost 3.0
LightGBM 4.5
CatBoost 1.2.7
Higgs
0.8321
0.8318
0.8309
Adult
0.9284
0.9291
0.9312
Criteo
0.7982
0.7994
0.8047
결과의 패턴이 꽤 명확합니다. LightGBM은 속도가 압도적으로 빠르며, 세 라이브러리 간 AUC 차이는 대부분 소수점 셋째 자리(0.001~0.005) 수준입니다. 반면 카테고리 변수가 지배적인 Criteo 데이터셋에서는 CatBoost의 AUC가 XGBoost보다 0.0065 높게 나왔는데, 광고나 CTR 예측에서는 이 정도 차이도 유의미합니다. 즉, "속도가 우선이면 LightGBM, 카테고리가 많으면 CatBoost, 재현·해석·안정성이 우선이면 XGBoost"라는 실전 지침이 통계적으로 뒷받침됩니다.
카테고리 데이터는 어떻게 처리해야 하나요?
세 라이브러리의 가장 큰 차별점은 카테고리 변수 처리 방식입니다. 각각의 접근을 정리하면 다음과 같습니다.
LightGBM: pandas category dtype이나 categorical_feature 파라미터로 정수 인덱스 컬럼을 지정합니다. Fisher(1958)의 최적 분할 알고리즘을 사용해 원-핫 없이도 최적에 가까운 이진 분할을 찾습니다.
CatBoost:cat_features로 컬럼 인덱스만 알려주면 Ordered Target Statistics로 자동 인코딩합니다. Target leakage가 없어서 특히 카디널리티가 높은 컬럼(수천 개의 도시명, 사용자 ID 등)에서 강력합니다.
GPU 가속 지원은 어떻게 다른가요?
세 라이브러리 모두 CUDA GPU를 지원하지만 구현 성숙도와 옵션에는 차이가 있습니다. 저는 scikit-learn 1.8 GPU ML 파이프라인 가이드에서도 언급했듯이, GPU가 항상 CPU보다 빠른 것은 아니라는 점을 강조하고 싶습니다. 데이터셋이 100만 행 미만이면 데이터 전송 오버헤드가 계산 이득을 상쇄해 오히려 GPU가 느려질 수 있습니다.
2026년 8월 기준 실전 지침은 다음과 같습니다. XGBoost는 tree_method='hist'와 device='cuda'를 조합해야 하며, 예전의 gpu_hist는 폐기되었습니다. (참고로 저는 gpu_hist를 그대로 사용하다가 XGBoost 3.0으로 업그레이드하면서 무성의한 경고 로그를 몇 번 놓쳐서 프로덕션 파이프라인이 조용히 CPU로 돌아간 적이 있습니다. 로그는 꼭 확인하세요.) LightGBM은 소스에서 GPU 지원을 활성화한 빌드가 필요하고, device_type='cuda'가 device_type='gpu'(OpenCL)보다 안정적이며 최대 30% 빠릅니다. CatBoost는 별도 설정 없이 task_type='GPU'만 지정하면 되고, 여러 GPU를 사용하려면 devices='0-3'처럼 명시합니다.
GPU 사용 시 주의점
GPU 메모리(VRAM)가 데이터 크기에 부족하면 XGBoost는 external memory 옵션으로 디스크를 활용할 수 있지만, LightGBM·CatBoost는 OOM 오류가 발생합니다.
재현성을 위해서는 deterministic=True(XGBoost) 또는 deterministic=True(LightGBM)를 반드시 설정해야 합니다. CatBoost는 GPU 학습이 항상 결정론적입니다.
과적합 검증 시 GPU는 CPU와 미세한 부동소수점 차이가 있을 수 있으므로, 최종 프로덕션 모델은 CPU와 GPU 양쪽에서 AUC 차이를 0.001 이내로 확인하는 것이 좋습니다.
하이퍼파라미터 튜닝 실전 예제
세 라이브러리 모두 Optuna와 궁합이 잘 맞습니다. 아래는 LightGBM을 Optuna 공식 문서의 패턴을 따라 튜닝하는 실전 코드입니다. XGBoost·CatBoost도 파라미터 이름만 바꾸면 동일한 패턴으로 적용할 수 있습니다.
튜닝 순서는 (1) learning_rate를 낮추면서 num_boost_round를 늘리는 학습률 튜닝, (2) num_leaves·max_depth·min_data_in_leaf로 트리 복잡도 조절, (3) feature_fraction·bagging_fraction·bagging_freq로 배깅 정규화, (4) lambda_l1·lambda_l2로 L1/L2 정규화 순서를 추천합니다. 50~100회의 Optuna trial이면 대부분의 실전 데이터셋에서 수동 튜닝 대비 AUC 0.002~0.005 상승을 얻을 수 있습니다.
언제 무엇을 선택해야 하나요?
제가 실무에서 사용하는 선택 기준을 정리하면 다음과 같습니다. 딱 하나만 배워야 한다면 LightGBM부터 시작하세요. 속도가 빠르니 실험 반복이 빨라 다른 부분(피처 엔지니어링, 모델 검증 전략)에 시간을 더 쓸 수 있습니다.
시나리오별 추천
대용량 표 형식 데이터(100만 행 이상)의 이진 분류·회귀: LightGBM. 학습 시간이 XGBoost의 1/5~1/10로 반복 실험에 유리.
카테고리 변수가 많고 카디널리티가 높은 CTR·추천 문제: CatBoost. Ordered TS와 대칭 트리 조합이 leakage-free이고 추론이 빠름.
커스텀 손실 함수·비표준 목적함수(Tweedie, Cox, Multiclass logistic 등)가 필요한 리서치: XGBoost. 가장 유연하고 논문 재현 예제가 풍부.
ONNX로 크로스 플랫폼 배포하는 프로덕션 서비스: 셋 다 지원하지만 CatBoost가 대칭 트리 덕분에 ONNX 추론 지연이 가장 짧음.
시계열 예측: 세 라이브러리 모두 랙(lag) 피처·롤링 통계와 결합할 때 통계 모델보다 강력합니다. 하이브리드 접근은 Python 시계열 예측 가이드에서 다뤘습니다.
자주 묻는 질문
XGBoost와 LightGBM 중 어느 것이 더 빠른가요?
대부분의 표 형식 데이터셋에서 LightGBM이 XGBoost보다 2~10배 빠릅니다. 이는 leaf-wise 트리 성장, GOSS 샘플링, EFB 피처 번들링의 조합 덕분입니다. 다만 데이터셋이 1만 행 미만으로 매우 작으면 초기화 오버헤드 때문에 두 라이브러리의 차이가 무시할 수준이 됩니다.
CatBoost는 언제 사용해야 하나요?
카테고리 변수가 많고 그중 일부의 카디널리티가 1,000을 넘는 데이터셋(추천 시스템, 광고 CTR, 사용자 세그멘테이션)에서 CatBoost가 가장 강력합니다. 또한 하이퍼파라미터 튜닝에 시간을 많이 쓸 수 없을 때 기본값 성능이 가장 안정적입니다.
세 라이브러리 중 어떤 것이 가장 정확한가요?
튜닝을 충분히 하면 세 라이브러리의 정확도 차이는 대부분 소수점 셋째 자리(±0.005)에 그칩니다. 그러나 데이터 특성에 따라 특정 라이브러리가 유리한데, 순수 수치 데이터는 XGBoost·LightGBM이, 카테고리 지배 데이터는 CatBoost가 유리한 경향이 뚜렷합니다.
GPU가 항상 CPU보다 빠른가요?
아닙니다. 데이터셋이 100만 행 미만이거나 트리 개수가 500 이하이면 데이터 전송 오버헤드 때문에 CPU가 더 빠를 수 있습니다. GPU의 이점은 데이터가 커질수록 커지며, 100만 행 이상, 1,000 트리 이상에서 3~10배의 속도 향상을 기대할 수 있습니다.
scikit-learn 파이프라인에서 사용할 수 있나요?
세 라이브러리 모두 scikit-learn 호환 API(fit, predict, predict_proba)를 제공하므로 Pipeline, ColumnTransformer, GridSearchCV와 그대로 사용할 수 있습니다. 다만 조기 종료를 사용하려면 fit에 eval_set을 전달해야 하는데, 이 부분은 Pipeline과 호환되지 않으므로 별도로 명시적 검증 세트를 관리해야 합니다.