LLM (Large Language Models)이 모든 로드맵을 집어삼키기 시작할 무렵, 많은 팀에 조용한 믿음이 퍼졌습니다. 모델이 충분히 크다면, 스스로 패턴을 찾아낼 것이라는 믿음입니다. 수천억 개의 파라미터(Parameters)를 가진 모델에 원시 데이터 (Raw data)를 그냥 던져 넣을 수 있는데, 왜 굳이 수작업으로 피처 (Features)를 만들며 고생해야 할까요?

그 믿음은 사람들이 실제로 출시하는 대부분의 결과물에 있어 틀렸습니다. 저는 이것이 이론이 아니라 실제 운영 환경에서 진짜 정확도 (Accuracy)를 깎아먹는 것을 목격했습니다.

여기 아무도 대놓고 인정하고 싶어 하지 않는 사실이 있습니다. 당신이 선택한 알고리즘 (Algorithm)은 당신이 입력하는 피처 (Features)보다 훨씬 덜 중요합니다. 영리한 피처 (Features)를 갖춘 평범한 로지스틱 회귀 (Logistic regression) 모델이, 가공되지 않은 지저분한 데이터에 허덕이는 화려한 신경망 (Neural network) 모델을 이기는 경우가 종종 있습니다.

우리 대부분이 즉시 떠올릴 수 있는 이커머스 (E-commerce)의 이탈 예측 (Churn prediction) 사례를 들어보겠습니다.

게으른 버전

고객이 곧 떠날 것인지를 예측하고 싶다고 가정해 봅시다. 유혹적인 방법은 원시 테이블 (Raw table)을 모델에 그대로 들이붓는 것입니다:

df = pd.DataFrame({
    'user_id':       [101, 102, 103],
    'last_purchase': ['2024-03-15', '2025-11-20', '2025-12-28'],
...

서류상으로는 괜찮아 보입니다. 하지만 실제로는 충분하지 않습니다. 만약 last_purchase를 단순한 숫자 인코딩 (Numeric encoding)으로 남겨둔다면, 모델은 2024-03-15를 20,240,315로 읽게 되며, 2024년 3월이 2024년 1월과 가깝다는 사실을 전혀 알지 못합니다. 또한, 3년 동안 고객이었던 사람의 total_orders = 12가 3개월 된 계정의 동일한 숫자와는 완전히 다른 의미를 갖는다는 것도 구분할 수 없습니다. 하나는 꾸준한 고객이고, 다른 하나는 폭발적인 성장세에 있는 고객입니다.

이러한 원시 컬럼 (Raw columns)들은 피처 (Features)가 아닙니다. 그저 숫자로 되어 있을 뿐인 데이터일 뿐입니다.

피처 엔지니어링 (Feature engineering)이 실제로 더해주는 것

이제 누군가 실제로 고민해서 만든 피처 (Features)와 비교해 봅시다. 이는 이커머스 (E-commerce) 및 리테일 (Retail) ML (Machine Learning)에서 가장 오래된 기법 중 하나인 RFM 패턴, 즉 Recency (최근성), Frequency (빈도), Monetary (구매 금액)를 따릅니다:

from datetime import datetime
today = datetime.now()

...

이제 모델은 실제로 추론할 수 있는 무언가를 갖게 되었습니다. 단 한 번의 학습 패스 (training pass)만으로도 days_since_last_purchase (마지막 구매 후 경과일) 값이 2이면 활성 상태로, 200이면 이탈 상태로 읽힙니다. order_frequency_per_month (월간 주문 빈도)는 원시 주문 횟수가 동일해 보이더라도 충성 고객과 일회성 구매자를 구분해 냅니다. 여기에 monetary_value (금액 가치)와 기준값 조정된 장바구니 가치를 추가하면, 쓸모없던 테이블이 작동하는 이탈 예측기 (churn predictor)로 변모합니다.

제 경험상, 알고리즘을 교체하는 것보다 원시 컬럼 (raw columns)을 이러한 피처 (features)로 교체하는 것이 정확도를 훨씬 더 많이 높여줍니다. 비교조차 되지 않을 정도입니다.

LLM이 실제로 적합한 위치

LLM (Large Language Models)은 이 모든 과정을 대체하는 것이 아닙니다. 그 과정의 일부를 수행하는 새로운 방식일 뿐입니다.

LLM은 지저분한 텍스트를 가져와 구조화된 신호 (structured signal)로 바꿀 수 있습니다. "배송은 영원히 걸릴 것 같았지만 제품은 훌륭했다"와 같은 리뷰는 delivery_sentiment_negative (배송 감성 부정) 및 product_sentiment_positive (제품 감성 긍정)가 됩니다. 이것 역시 여전히 피처 엔지니어링 (feature engineering)입니다. LLM은 도구일 뿐이며, 사고(thinking) 그 자체는 아닙니다.

그리고 이 규칙은 반대의 경우에도 동일하게 적용됩니다. 모든 주문, 타임스탬프, 클릭 로그의 원시 데이터 덤프를 LLM에 입력하는 것은, 파이프라인 (pipeline)이 먼저 수행했어야 할 사고를 모델이 대신해 줄 것이라고 가정하는 과거 모델들의 실수와 똑같은 실수를 저지르는 것입니다. 대신 days_since_last_purchase: 2, order_frequency_per_month: 4.2, recent_complaint: shipping delay (최근 불만: 배송 지연)를 전달하면, 트리 모델 (tree model)이 그러하듯 LLM도 더 잘 추론합니다.

이것이 여전히 중요한 이유

대부분의 비즈니스 데이터는 여전히 구조화되어 있습니다. 고객 테이블, 트랜잭션 로그, 재고, 지원 티켓 등이 그렇습니다. 모든 데이터가 LLM이 해결해주기를 기다리는 텍스트 덩어리(text blob)인 것은 아닙니다.

많은 정형 데이터 (tabular) 문제에서 XGBoost나 LightGBM 같은 모델은 여전히 극복하기 어렵습니다. 이들은 실제 피처 값에 따라 분할 (split)하므로, 잘 설계된 컬럼은 노이즈 (noise)가 아닌 깔끔한 결정 경계 (decision boundary)가 됩니다. 이들은 패턴을 찾기 위해 거대한 데이터셋을 필요로 하지 않습니다. 또한 많은 전처리 (preprocessing) 없이도 숫자형 및 범주형 (categorical) 데이터가 혼합된 형태를 처리할 수 있습니다. 쓰레기 데이터를 입력하면 이들은 빠르고 명확하게 실패합니다. 어떤 아키텍처 (architecture)도 나쁜 피처를 숨길 수는 없습니다.

그러니 다음에 "모델이 알아서 해결하게 두자"라는 계획을 세울 때, 먼저 한 가지 질문을 던져보세요. 모델이 알아낼 만한 가치가 있는 데이터를 실제로 제공했나요?

대부분의 정확도 (accuracy) 문제는 모델의 문제가 아닙니다. 그것은 모델의 명성 뒤에 숨겨진 피처 (feature)의 문제입니다.