특성 공학
Feature Engineering
특성 공학이란?
- 원본을 유용한 입력 변수로 가공
- '좋은 재료 손질'
- 전통 ML 성능 좌우
특성 공학이 실제로 바꾸는 것은 모델의 성능 수치가 아니라 문제의 난이도 자체입니다. 같은 알고리즘에 같은 테이블을 넣어도, 열이 '가입일 2021-03-14'로 남아 있을 때와 '가입 후 경과 412일, 최근 30일 주문 0건'으로 바뀌었을 때 모델이 풀어야 할 문제는 전혀 다른 문제가 됩니다. 정답과 입력 사이의 거리를 좁히는 작업이라서, 하이퍼파라미터를 만져 0.5%포인트를 짜내는 것보다 파생 변수 하나를 제대로 만드는 쪽이 성과가 큰 경우가 많습니다. 순서상으로도 어떤 모델을 쓸지 고르기 전에 끝나야 하는 일입니다.
실무에서는 대개 네 갈래로 나눠서 봅니다. 스케일을 맞추는 변환(로그·정규화), 원본을 조합해 새 열을 만드는 파생(최근 90일 합계, 전월 대비 증감률), 범주를 숫자로 바꾸는 인코딩(원핫·타깃 인코딩), 쓸모없는 열을 걷어내는 선택입니다. 이 중 인코딩은 고유값 개수가 관건이라, 상품 코드처럼 값이 수천 개인 열을 원핫으로 펼치면 열이 폭증해 학습이 느려지고 과적합으로 갑니다. 사내 시스템에서 뽑은 표 형태 데이터에서는 '딥러닝이 알아서 특성을 학습한다'는 말이 잘 통하지 않아, 부스팅 계열 모델과 수작업 파생 변수의 조합이 여전히 기본입니다. 픽셀이나 파형처럼 원자료 자체가 조밀한 신호인 영역과는 구분해서 봐야 합니다.
현장에서 가장 자주 터지는 사고는 데이터 누수입니다. 이탈 예측 모델에 '해지 사유 코드'나 '위약금 청구액'을 넣으면 검증 정확도가 0.95까지 치솟지만, 그 값은 고객이 해지한 뒤에야 채워지는 열이라 운영 환경에서는 늘 비어 있습니다. 학습 데이터 전체 평균으로 정규화한 다음 학습/검증을 나누는 것도 같은 종류의 오염입니다. 운영 시점에 실제로 계산되는 값인지를 열마다 따져 보는 절차가 없으면, 파일럿에서 멀쩡하던 모델이 배포 첫 주에 무너집니다. 또 하나, 많이 만들수록 좋다고 믿고 특성 500개를 쏟아붓는 경우가 있는데, 재현되지 않는 전처리 코드가 쌓이면 담당자가 바뀌는 순간 아무도 손대지 못하는 짐이 됩니다.
전통 기계학습의 핵심 실무로, 데이터 준비·표현의 중요성에서 정립됐습니다.
가상의 사례로 살펴보겠습니다. 임직원 210명, 연 매출 900억 원대의 식품 정기구독 A사는 월 구독 해지율이 6.8%에서 9.2%로 올라 6개월째 잡히지 않았습니다. 데이터팀이 이탈 예측 모델을 두 번 돌렸지만 정확도는 60%대에 머물렀고, 대표는 '모델을 바꿔보라'고 지시했습니다. 팀은 모델을 그대로 두고 8주간 입력 데이터를 다시 짜는 쪽을 택했습니다.
- 김 과장은 원본 테이블의 42개 열을 펼쳐놓고 '이 중 해지 당일 이후에 값이 채워지는 열이 뭐냐'부터 물었고, 환불 처리일·해지 사유 코드 등 7개를 누수 후보로 걷어냈습니다.
- 마케팅 이 팀장은 CS 상담 로그에서 '배송 지연'이 포함된 문의 건수를 최근 30일과 90일 두 구간으로 집계해, 고객별 불만 누적 특성 4개를 새로 설계했습니다.
- 구독 상품 코드 1,800여 개는 원핫으로 펼치지 않고 카테고리 12개와 가격대 5구간으로 묶어, 입력 열 수를 1,800개에서 17개로 줄였습니다.
- 주문 주기를 '평균 재구매 간격 대비 이번 간격의 배수'로 바꾸자, 평소의 1.8배를 넘긴 고객군에서 해지율이 나머지의 3배로 나타났습니다.
- 배포 직전 김 과장은 새벽 배치에서 실제로 값이 생성되는 열인지 하나씩 확인해 2개를 더 뺐습니다. '파일럿에서만 되는 열은 안 쓴다'가 팀의 기준이었습니다.
- 모델은 손대지 않고 특성만 바꿨는데 이탈 예측 정확도가 61%에서 78%로 올랐고, 상위 10% 고객 대상 쿠폰의 해지 방어율이 12%에서 27%로 개선됐습니다.