P4-7.1 특징 선택(feature selection)¶

Section ID: P4-7.1 Version: v2026.07.20

P4-6에서는 무엇을 기준으로 평가할 것인가를 봤습니다. 이제 질문을 한 단계 앞으로 옮깁니다. 평가 지표를 바꾸기 전에, 애초에 모델에게 어떤 입력을 줄지부터 점검해야 합니다. 특징 선택(feature selection)은 이 입력 설계의 시작점입니다.

이 절은 좋은 특징을 어떻게 고를 것인가를 다룹니다. 복잡한 선택 알고리즘을 깊게 설명하기보다, 실제 업무에서 우선 확인할 판단 기준을 잡는 데 목적이 있습니다.

이 절은 특징 선택(feature selection)과 특징 공간(feature space)의 뜻을 설명합니다. 뒤 절에서는 이 손잡이를 바탕으로 현재 맥락의 판단을 이어 가고, 입력 칸을 무엇으로 채택할지 판단하는 기본 기준은 이 절과 개념사전을 기준으로 다시 연결합니다.

특징 선택(feature selection)에서 닫을 질문¶

이 절은 다음 질문에 답합니다.

• 특징(feature)은 무엇이며, 왜 입력 설계가 중요한가?
• 사용할 수 있는 데이터가 많다고 해서 모두 넣으면 안 되는 이유는 무엇인가?
• 독자가 우선 확인해야 할 특징 선택 기준은 무엇인가?
• 특징 선택과 전처리(preprocessing)는 어떻게 다른가?

이 절은 먼저 좋은 특징을 어떻게 고를 것인가와 특징 선택이 왜 입력 설계 문제인가를 닫습니다. 전처리 종류를 입력 문제 기준으로 나누는 감각은 P4-7.3 보충학습에서 다시 붙잡고, 통계 검정 기반 선택과 재귀적 특징 제거의 비교 관점은 P4-7.4 보충학습에서 다시 정리합니다. 차원 축소의 큰 그림은 P4-18.1, P4-18.2에서 이어집니다.

특징 선택(feature selection)에서 남길 판단 기준¶

• 특징(feature)을 현실의 정보가 모델 입력으로 바뀐 형태로 설명할 수 있습니다.
• 특징 선택이 성능 숫자만의 문제가 아니라, 누수(leakage), 비용, 안정성, 해석 가능성과 연결된다는 점을 말할 수 있습니다.
• 우선 버릴 특징과 우선 남길 특징을 구분하는 기본 질문을 사용할 수 있습니다.
• 전처리(preprocessing)가 선택된 특징을 다듬는 일이라면, 특징 선택은 어떤 특징을 애초에 채택할지 정하는 일이라는 차이를 설명할 수 있습니다.

학습 배경¶

특징은 무엇인가¶

머신러닝에서 특징(feature)은 현실의 대상을 모델이 읽을 수 있는 입력 칸으로 바꾼 것입니다.

예를 들어 고객 이탈(churn) 예측 문제를 다음처럼 읽을 수 있습니다.

특징은 원래 세상에 있던 사실을 그대로 복사한 것이 아니라, 문제를 풀기 좋게 잘라서 만든 입력 표현입니다.

그래서 같은 데이터라도 어떤 칸을 특징으로 삼느냐에 따라 전혀 다른 모델이 됩니다.

다만 이 판단은 무엇이 샘플 1건인가가 먼저 정해져 있어야 안정적으로 할 수 있습니다. 한 행이 한 고객인지, 한 번의 동작인지, 여러 시점이 모인 요약 행인지가 흔들리면 특징의 뜻도 함께 흔들리기 때문입니다.

조금 더 이론적으로 말하면, 특징은 입력 변수(input variable)의 단위입니다. 모델은 보통 하나의 큰 정답을 바로 이해하지 못합니다. 대신 여러 입력 변수를 함께 보고, 그 조합에서 반복되는 패턴을 찾습니다. 이때 각각의 입력 변수가 특징입니다.

예를 들어 집값 예측 문제에서는 면적, 방 수, 역과의 거리가 특징이 될 수 있습니다. 스팸 분류 문제에서는 특정 단어의 출현, 첨부파일 유무, 발신 도메인 패턴이 특징이 될 수 있습니다. 즉, 특징은 문제에 따라 바뀌며, 같은 현실도 어떤 질문을 하느냐에 따라 다른 특징 집합으로 표현됩니다.

주요 학습내용¶

왜 특징 선택이 먼저 중요한가¶

특징 선택은 단순히 칸 수를 줄이는 작업이 아닙니다. 어떤 정보를 모델 판단에 참여시킬 것인가를 정하는 일입니다.

scikit-learn 문서는 특징 선택 모듈이 불필요하거나 잡음이 큰 특징을 줄여 성능과 계산 효율을 개선하는 데 쓰일 수 있다고 설명합니다. 특히 차원이 큰 데이터에서는 이 판단이 더 중요해집니다.

핵심은 다음 네 가지 이유입니다.

1. 관련 없는 입력이 많으면 모델이 잡음을 배울 수 있습니다.
2. 너무 많은 입력은 학습과 추론 비용을 키울 수 있습니다.
3. 설명하기 어려운 입력이 많을수록 결과 해석이 어려워질 수 있습니다.
4. 미래 예측 시점에 사용할 수 없는 입력을 넣으면 데이터 누수(leakage)가 생길 수 있습니다.

특징 선택은 좋은 신호는 남기고, 위험한 신호와 불필요한 신호는 줄이는 일입니다.

이론적으로 다시 말하면, 특징 선택은 다음 네 가지를 동시에 조정하는 과정입니다.

이 표를 기준으로 보면, 특징 선택은 단순한 데이터 정리 작업이 아니라 학습 문제를 다시 정의하는 일에 가깝습니다.

특징 공간(feature space)과 표현(representation)¶

특징을 하나씩 보는 것도 중요하지만, 머신러닝은 보통 특징 하나만으로 판단하지 않습니다. 여러 특징이 함께 만들어 내는 입력 공간을 봅니다. 이 절은 이를 특징 공간(feature space)으로 다룹니다.

예를 들어 두 개의 특징만 있다고 해 보겠습니다.

• visits_30d
• support_tickets_30d

이 경우 한 고객은 (방문 횟수, 문의 횟수)라는 한 점으로 표현될 수 있습니다. 고객이 수천 명이면, 그 점들이 모여 하나의 공간을 만듭니다. 모델은 그 공간 안에서 이탈하는 점들의 경향, 비슷한 점들끼리의 묶임, 경계의 모양을 배우게 됩니다.

그래서 특징 선택은 단순히 칼럼 개수를 줄이는 작업이 아니라, 모델이 보게 될 입력 공간 자체를 설계하는 일이기도 합니다.

flowchart TB
  A["현실<br/>사람 / 제품 / 사건"]
  B["특징 설계<br/>측정 가능한 관점 선택"]
  C["특징 공간<br/>행을 입력 공간의 점으로 표현"]
  D["모델 학습<br/>패턴이나 경계를 찾음"]

  A --> B
  B --> C
  C --> D

이 도식은 특징 선택이 단순히 칼럼을 고르는 일이 아니라, 현실을 어떤 입력 공간으로 번역할지 정하는 과정이라는 점을 보여 줍니다. 같은 현실도 어떤 특징을 뽑느냐에 따라 모델이 배우게 될 패턴과 경계가 완전히 달라질 수 있습니다.

이 도식의 핵심은, 특징이 많고 적음보다 어떤 관점으로 현실을 잘라 입력 공간을 만들었는가가 더 중요하다는 점입니다.

같은 사실도 어떤 표현으로 바꾸느냐에 따라 모델이 배우기 쉬워질 수도, 어려워질 수도 있습니다.

예를 들어 고객 활동을 표현한다고 해 보겠습니다.

이 표가 보여 주는 핵심은, 특징 선택이 단지 원본 칼럼을 고르기만이 아니라 어떤 표현 단위로 입력을 만들 것인가와도 이어진다는 점입니다.

원시 로그를 다루는 경우에는 이 차이가 더 분명해집니다. 시간 순서대로 쌓인 값들이 그대로 보이더라도, 모델 입력으로는 그 전체 행을 모두 넣기보다 동작 단위로 다시 요약한 특징 후보를 만들게 되는 경우가 많습니다.

여기서도 순서는 원시 시계열 -> 동작 1회 요약 행 -> 특징 선택입니다. 특징 선택은 이 순서가 끝난 뒤에 요약 행의 어떤 입력 칸을 남길 것인가를 다시 정하는 단계입니다.

이때 중요한 것은 특정 이름을 외우는 일이 아니라, 원시 값 그대로보다 문제와 더 직접 연결되는 읽기 단위로 바꾸고 있는가입니다. 즉, 특징 선택은 칼럼 제거만이 아니라 원시 시계열 -> 동작 1회 요약 행 -> 모델 입력 칸으로 표현을 다시 설계하는 작업이기도 합니다.

이 문장을 뒤집어 읽으면, 아직 한 행이 무엇을 뜻하는가가 불분명한 표에서는 특징 선택 이야기를 너무 일찍 시작하면 안 된다는 뜻이기도 합니다.

이 장면을 더 직접적으로 보면 다음처럼 읽을 수 있습니다.

이 표는 여러 시점의 원시 시계열을 동작 1회당 한 행의 요약 행으로 다시 표현한 예시입니다. 여기서 control_mean, sensor_a_peak, sensor_a_slope 같은 열은 그냥 계산값이 아니라, 무엇을 모델 입력 칸으로 남길지에 대한 선택 결과입니다. 즉 특징 선택은 어떤 열을 버릴까 이전에, 무엇을 어떤 표현으로 남길까라는 질문과 이미 연결됩니다.

한 걸음 더 나아가면, 어떤 특징은 개별 동작을 설명하는 데서 끝나지 않고 최근 상태와 기준선을 비교하는 입력으로도 이어질 수 있습니다.

이 비교표에서 중요한 것은 delta 숫자 그 자체보다, 앞에서 만든 특징이 이제 최근 구간과 기준선을 비교하는 해석 프레임으로 다시 쓰인다는 점입니다. 따라서 특징 선택은 학습용 입력 설계이면서 동시에 사람이 읽는 비교 리포트 설계이기도 합니다.

다만 이 비교표는 변화 신호를 먼저 보여 줄 뿐이고, 그 차이의 원인을 자동으로 확정해 주지는 않습니다.

짧은 코드로 보면 이 흐름은 더 분명합니다.

문제 상황:

• 여러 행의 원시 로그를 동작 단위 특징으로 바꾸고, 그 특징을 최근 구간과 기준선 비교 입력으로 다시 쓰고 싶다

입력(input):

• action_id, time_step, control_level, sensor_a, sensor_b가 들어 있는 작은 원시 로그 표

기대 출력(output):

• 동작 단위 요약 표
• 최근 평균, 기준선 평균, 차이값 비교 표

확인할 개념:

• 특징은 원시 로그를 한 행 입력으로 바꾸는 표현 설계다
• 같은 특징은 모델 입력과 운영 비교표 양쪽에 다시 쓰일 수 있다

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

# 원시 특징 후보와 선택된 특징 묶음을 비교해 모델 입력 공간을 설계하는 예제입니다.
import pandas as pd

raw = pd.DataFrame(
    [
        ["A-101", 0, 0.20, 24.8, 0.3],
        ["A-101", 1, 0.35, 25.6, 0.8],
        ["A-101", 2, 0.55, 27.1, 1.5],
        ["A-102", 0, 0.18, 24.5, 0.2],
        ["A-102", 1, 0.32, 25.3, 0.7],
        ["A-102", 2, 0.60, 27.8, 1.6],
        ["A-103", 0, 0.22, 25.0, 0.4],
        ["A-103", 1, 0.36, 26.1, 0.9],
        ["A-103", 2, 0.54, 29.1, 1.8],
    ],
    columns=["action_id", "time_step", "control_level", "sensor_a", "sensor_b"],
)

summary = (
    raw.groupby("action_id")
    .agg(
        duration_steps=("time_step", "count"),
        control_mean=("control_level", "mean"),
        sensor_a_peak=("sensor_a", "max"),
        sensor_b_mean=("sensor_b", "mean"),
    )
    .reset_index()
)

recent = summary.tail(2).mean(numeric_only=True)
baseline = summary.head(len(summary) - 2).mean(numeric_only=True)

comparison = pd.DataFrame(
    {
        "recent": recent,
        "baseline": baseline,
        "delta": recent - baseline,
    }
)

print(summary)
print(comparison.round(2))

이 코드에서 먼저 봐야 할 것은 성능 숫자가 아니라 표현의 변환입니다.

• 원시 로그 여러 행이 동작 단위 특징 표로 바뀐다.
• 그 특징 표가 다시 최근 구간과 기준선 비교표로 이어진다.
• 즉 특징 선택은 학습 전처리 이전에 이미 무엇을 비교 가능한 입력으로 만들 것인가를 정하는 일이다.
• 요약 행은 비교를 쉽게 만들지만, 원시 시계열의 모든 맥락을 완전히 대체하지는 않는다.

따라서 특징 선택은 다음 두 질문을 함께 품습니다.

1. 어떤 정보를 남길 것인가?
2. 그 정보를 어떤 형태의 입력 표현으로 만들 것인가?

두 번째 질문은 전처리와도 이어지지만, 출발점은 여전히 특징 설계입니다.

좋은 특징은 무엇을 가져야 하는가¶

종종 좋은 특징 = 숫자로 된 특징이라고 오해합니다. 하지만 중요한 것은 자료형이 아니라, 그 특징이 문제와 어떤 관계를 맺는가입니다.

이 절에서는 좋은 특징을 모델이 배우기 쉬운 신호이면서, 실제 운영에서도 다시 만들 수 있는 입력으로 봅니다. 즉, 학습용 표 안에서만 그럴듯해 보이는 칼럼이 아니라 예측 순간에도 정당하게 쓸 수 있고, 의미가 흔들리지 않으며, 다른 특징들과 함께 놓였을 때도 역할이 분명한 입력이어야 합니다.

이론적으로는 다음 다섯 가지 관점이 중요합니다.

1. 신호(signal)가 있는가¶

그 특징이 정답(label)과 어느 정도 관련된 패턴을 담고 있어야 합니다.

예를 들어 고객 이탈 문제에서 최근 방문 횟수는 이탈과 관련 있을 가능성이 있습니다. 반면 완전히 임의로 붙인 내부 일련번호는 보통 문제의 원인이나 경향을 설명하지 못합니다.

좋은 특징은 정답을 예측하는 데 도움이 되는 신호를 어느 정도 담고 있어야 합니다.

2. 잡음(noise)이 너무 크지 않은가¶

값이 있어 보인다고 해서 항상 좋은 특징은 아닙니다.

• 측정 자체가 부정확한가?
• 사람이 임의로 입력해서 흔들림이 큰가?
• 상황마다 의미가 자주 바뀌는가?

이런 특징은 신호보다 잡음이 더 커질 수 있습니다. 그러면 모델은 안정적인 규칙보다 우연한 흔들림을 배우기 쉬워집니다.

3. 예측 시점에 실제로 쓸 수 있는가¶

좋은 특징은 학습 데이터셋 안에 존재하는 값이면 충분한 것이 아니라, 실제 예측 순간에도 얻을 수 있는 값이어야 합니다.

• 결과가 나온 뒤에만 기록되는가?
• 사람이 사후적으로 판정을 붙인 값인가?
• 전체 기간을 다 보고 나서야 계산할 수 있는 요약값인가?

예를 들어 contract_cancelled_at, refund_confirmed_at, next_30d_spend 같은 값은 학습 표에서는 매우 강한 신호처럼 보일 수 있지만, 실제로는 예측 시점에 아직 모를 가능성이 큽니다. 이런 특징은 신호가 강해 보여도 좋은 특징이 아니라 누수 가능 특징입니다.

즉, 좋은 특징은 잘 맞히는 데 도움만이 아니라 예측 순간에도 정당하게 사용 가능함을 함께 가져야 합니다.

4. 중복(redundancy)이 과도하지 않은가¶

비슷한 뜻의 특징을 너무 많이 넣으면, 정보가 풍부해지기보다 설명이 반복될 수 있습니다.

예를 들어 다음 칼럼이 동시에 있다면 어느 정도 중복을 의심할 수 있습니다.

• monthly_spend
• quarterly_spend
• yearly_spend

물론 모두가 항상 불필요한 것은 아닙니다. 다만 비슷한 뜻을 다른 단위로 반복하고 있지 않은가를 먼저 확인해야 합니다.

5. 운영에서 다시 만들 수 있는가¶

좋은 특징은 오프라인 실험 표에서만 존재하는 값이 아니라, 실제 서비스에서도 비슷한 규칙으로 재현할 수 있어야 합니다.

• 수집 지연이 너무 크지 않은가?
• 사람이 임의로 적는 메모처럼 품질 흔들림이 크지 않은가?
• 개인정보, 비용, API 의존성 때문에 추론 시점마다 안정적으로 가져오기 어려운 값은 아닌가?

예를 들어 상담사가 나중에 남긴 메모 요약은 학습 때는 유용해 보여도, 실시간 이탈 예측에는 늦게 들어오거나 형식이 흔들릴 수 있습니다. 반면 visits_7d, failed_payments_30d 같은 집계형 특징은 상대적으로 더 안정적으로 재현할 수 있습니다.

정리하면 좋은 특징은 대체로 다음 조건을 향합니다.

문제와 관련된 신호는 담고, 잡음은 과도하지 않으며, 예측 시점에 사용할 수 있고, 다른 특징과의 중복은 관리 가능하며, 운영에서도 다시 만들 수 있어야 한다.

이 다섯 조건은 사실 따로 놀지 않습니다. 예를 들어 신호가 강해 보여도 예측 시점에 쓸 수 없으면 탈락하고, 운영에서 재현이 안 되면 서비스 입력으로는 부적합합니다. 반대로 신호가 아주 강하지 않아도 안정적으로 반복 수집되고 의미가 분명하다면 좋은 기본 특징 후보가 될 수 있습니다.

좋은 특징을 더 직관적으로 잡으려면, 좋아 보이지만 실제로는 위험한 특징과 대비해 보는 편이 좋습니다.

즉, 좋은 특징은 강해 보이는 특징이 아니라 정당하고 안정적으로 다시 쓸 수 있는 특징에 더 가깝습니다.

같은 고객 이탈 문제를 예로 들면 다음처럼 읽을 수 있습니다.

여기서 중요한 점은 신호가 가장 강한 특징 하나를 찾는 일이 아니라, 모델과 운영이 함께 버틸 수 있는 특징 묶음을 만드는 일이라는 점입니다. 예를 들어 contract_cancelled_at은 신호가 매우 강해 보여도 탈락하고, visits_30d는 완벽하지 않아도 남을 수 있습니다. 그 이유는 후자가 더 정당하고 반복 가능하기 때문입니다.

이 세 조건을 한 번에 묶어 보면 다음처럼 정리할 수 있습니다.

flowchart TB
  A["특징 후보<br/>가능한 입력 신호"]
  B["신호성<br/>목표와 관련 있는가?"]
  C["잡음성<br/>충분히 안정적인가?"]
  D["시점<br/>예측 시점에 쓸 수 있는가?"]
  E["중복<br/>단순 반복은 아닌가?"]
  F["운영성<br/>서비스에서도 재현 가능한가?"]
  G["좋은 특징 후보<br/>남길 가치가 있음"]

  A --> B
  B --> C
  C --> D
  D --> E
  E --> F
  F --> G

이 도식은 좋은 특징을 하나의 신비한 속성처럼 보지 말고, 관련성, 안정성, 시점 정당성, 중복 관리, 운영 재현성이라는 다섯 질문으로 나누어 읽으라는 뜻입니다.

좋은 특징을 고를 때 마지막으로 붙는 질문¶

좋은 특징은 보통 다음 질문까지 통과해야 오래 살아남습니다.

1. 이 특징이 빠지면 모델이 실제로 중요한 신호를 놓치는가?
2. 이 특징이 있어도 나중에 운영에서 재현하지 못하면 무슨 소용이 있는가?
3. 이 특징은 다른 특징이 이미 말하고 있는 내용을 다시 말하는 것인가, 아니면 새로운 관점을 주는가?

이 질문을 붙이면 특징 선택이 칼럼 많이 모으기가 아니라 설명 가능한 입력 설계에 더 가까워집니다.

사용할 수 있다고 다 넣으면 안 되는 이유¶

실무에서는 데이터베이스에 칼럼이 많을수록 오히려 위험할 때가 많습니다.

예를 들어 대출 심사 모델에 다음과 같은 칼럼이 있다고 가정해 보겠습니다.

이 표가 보여 주는 핵심은 간단합니다.

특징 선택은 많이 넣는 경쟁이 아니라, 예측 시점에 정당하게 쓸 수 있는 정보를 고르는 일이다.

독자가 먼저 쓰면 좋은 세 가지 질문¶

특징 선택을 시작할 때는 복잡한 알고리즘보다 질문 순서가 더 중요합니다.

1. 이 정보는 예측 시점에 정말 사용할 수 있는가¶

가장 먼저 확인해야 할 것은 시점입니다.

• 결과가 나온 뒤에만 생기는 값인가?
• 사람이 사후적으로 붙인 판정인가?
• 테스트 데이터 전체를 보고 나서 만든 값인가?

scikit-learn의 common pitfalls 문서는 특징 선택을 포함한 전처리 단계가 훈련 데이터(train data)만 사용해야 하며, 테스트 데이터를 끌어오면 성능이 낙관적으로 부풀려진다고 설명합니다.

이렇게 기억하면 됩니다.

예측 순간에 모를 정보를 입력에 넣으면, 잘 맞는 모델이 아니라 미리 답을 훔쳐본 모델이 된다.

2. 이 정보는 문제와 관련된 신호인가¶

두 번째 질문은 관련성입니다.

모든 칼럼이 다 같은 무게를 갖지 않습니다.

• 문제와 직접 연결되는 행동 기록인가?
• 사람이나 사물을 구분만 하는 번호인가?
• 거의 항상 같은 값이라 정보량이 적은가?
• 다른 칼럼과 거의 같은 뜻을 반복하는가?

scikit-learn 문서는 분산이 거의 없는 특징(low variance), 단변량 통계로 점수를 매길 수 있는 특징(univariate selection), 모델이 중요도를 줄 수 있는 특징(model-based selection) 등을 줄이는 접근을 제공합니다. 다만 이 절에서는 알고리즘보다 먼저, 왜 줄일 수 있는가를 이해하는 데 집중합니다.

3. 이 정보는 운영에서 안정적으로 구할 수 있는가¶

세 번째 질문은 현장성입니다.

훈련 데이터셋 안에서는 있어 보여도, 실제 서비스에서는 매번 안정적으로 구하기 어려운 특징이 있습니다.

• 수집 지연이 자주 생기는가?
• 사람이 손으로 입력해야 해서 품질이 흔들리는가?
• 개인정보나 비용 문제 때문에 운영에서 쓰기 어려운가?
• 모델 추론마다 불러오면 지연 시간(latency)이 커지는가?

결국 특징 선택은 데이터 과학만의 문제가 아니라 서비스 설계 문제이기도 합니다.

이 판단 흐름의 핵심은 알고리즘이 아니라 점검 순서입니다. 특히 예측 시점에 쓸 수 있는가를 먼저 묻는 구조가 중요합니다.

특징 선택과 전처리는 어떻게 다른가¶

독자는 이 둘을 자주 섞어 생각합니다. 하지만 질문이 다릅니다.

특징 선택은 입구를 정하는 일이고, 전처리는 선택한 입력을 모델이 읽기 좋게 다듬는 일입니다.

이 차이를 간단히 그리면 다음과 같습니다.

flowchart TD
  A["원시 칼럼<br/>사용 가능한 모든 필드"]
  B["특징 선택<br/>유지 / 제거 / 보류"]
  C["선택된 특징<br/>사용 가능한 입력 묶음"]
  D["전처리<br/>스케일 / 결측 보정 / 인코딩"]
  E["모델 입력<br/>학습 준비 완료"]

  A --> B --> C
  C --> D --> E

어떤 특징을 먼저 남기고 무엇을 먼저 뺄 것인가¶

특징 선택은 복잡한 알고리즘보다 먼저 어떤 이유로 남기고 어떤 이유로 보류하거나 제거하는가를 분명히 하는 일이기도 합니다.

이 표의 순서는 중요합니다. 관련 있어 보이는가보다 먼저 예측 시점에 정당하게 쓸 수 있는가를 확인해야 합니다. 그래야 성능 숫자가 아니라 입력의 정당성을 먼저 점검하게 됩니다.

세부 학습내용¶

학술적 문맥에서의 의미 정리¶

입문서에서는 변수(variable)와 특징(feature)를 거의 같은 말처럼 쓰는 경우가 많습니다. 하지만 학술 문맥에서는 둘을 약간 구분하기도 합니다.

Guyon과 Elisseeff의 고전적인 정리 논문은 raw input variables와 constructed features를 구분합니다. 이 차이를 입문 수준에서 옮기면 다음과 같습니다.

예를 들어 다음처럼 읽을 수 있습니다.

특징은 단순 칼럼 이름이 아니라 학습에 투입되는 입력 표현 전체를 가리키는 말입니다. 그래서 특징 선택(feature selection)은 때로 원래 변수 중 무엇을 남길 것인가와 가공된 특징 중 무엇을 채택할 것인가를 모두 포함하는 넓은 말로 쓰입니다.

학술적으로 특징 선택의 목적도 조금 더 분명하게 정리됩니다. Guyon과 Elisseeff는 그 목적을 다음처럼 설명합니다.

1. 예측 성능(prediction performance)을 높이기
2. 더 빠르고 비용이 적은 예측기(predictor)를 만들기
3. 데이터를 만든 과정에 대한 이해(understanding)를 돕기

이 세 목적은 실무에서도 그대로 이어집니다.

또 하나 중요한 것은 관련성(relevance)과 유용성(usefulness)이 항상 같은 말이 아니라는 점입니다.

예를 들어 두 칼럼이 거의 같은 정보를 담고 있다면, 둘 다 관련성은 있을 수 있습니다. 하지만 예측기를 만들 때는 둘 중 하나만 있어도 충분할 수 있습니다. 이때 나머지는 관련은 있지만 추가로는 덜 유용한 특징이 될 수 있습니다.

이 구분은 특징 선택이 가장 관련 있는 칼럼을 전부 남기는 작업이 아니라, 중복이 적고 함께 쓸 때 유용한 부분집합(subset)을 찾는 문제라는 점을 보여 줍니다.

사례 및 예시¶

사례 1. 이탈 예측 테이블에 칼럼이 많을수록 오히려 위험해질 때¶

구독 서비스 팀이 고객 이탈 예측 모델을 만들고 있습니다. 사람이 먼저 보던 기준은 최근 로그인 횟수, 문의 빈도, 결제 실패 여부, 요금제 변경 이력 같은 신호였습니다.

그런데 데이터베이스를 열어 보니 사용할 수 있는 칼럼이 훨씬 많습니다. customer_id, 해지 완료 시각, 상담사가 사후에 남긴 메모, 다음 달 연체 여부까지 모두 넣으면 정보가 풍부해 보일 수 있습니다. 하지만 이 중에는 사람을 구분만 하는 번호도 있고, 결과가 나온 뒤에만 생기는 값도 있으며, 실제 예측 시점에는 아직 모를 정보도 섞여 있습니다.

이 장면에서 특징 선택은 많이 넣기가 아니라 정당하게 쓸 수 있는 신호만 남기기가 됩니다. 먼저 예측 시점에 사용할 수 있는지 보고, 문제와 관련된 신호인지 확인하고, 운영에서 안정적으로 수집 가능한지 점검해야 합니다. 이 과정을 거치면 겉보기에는 정보가 줄어들어도, 실제로는 더 일반화 가능한 입력 공간을 만들게 됩니다.

확인 가능한 결과도 분명합니다. 누수가 있는 칼럼을 포함했을 때와 제외했을 때의 검증 점수를 비교하면, 처음의 높은 성능이 왜 착시였는지 드러날 수 있습니다. 또 남긴 특징 목록을 검토하면 어떤 칼럼이 실제 행동 신호이고 어떤 칼럼이 사후 정보였는지 설명할 수 있습니다.

flowchart TD
  A["이탈 예측 칼럼이 많음"]
  B["ID와 사후 정보 칼럼까지 포함"]
  C["누수 때문에 점수가 높아 보일 수 있음"]
  D["예측 시점에 쓸 수 있는 신호만 남김"]
  E["ID, 라벨, 결과 이후 칼럼 제거"]
  F["검증 점수를 다시 확인"]
  G["왜 남긴 특징 목록이 더 안전한지 설명"]

  A --> B --> C
  A --> D --> E --> F --> G

사례 및 예시¶

실무 휴리스틱으로 먼저 버릴 후보들¶

복잡한 계산을 하기 전에, 다음 특징들은 먼저 점검할 가치가 큽니다.

이 목록은 수학 공식이 아니라, 독자가 데이터를 처음 펼쳤을 때 바로 써먹을 수 있는 점검표입니다.

작은 예시로 특징 후보를 골라 보기¶

다음은 고객 이탈 예측 문제를 가정한 아주 작은 예시입니다.

이 예시에서 중요한 것은 포함 자체보다 왜 포함하거나 제외했는가를 설명할 수 있는가입니다.

연습 및 예제¶

좋은 특징의 다섯 기준을 천천히 점검해 보기¶

아래 다섯 묶음은 앞에서 본 기준을 작은 장면 -> 먼저 볼 질문 -> 1차 판단 -> 해설 순서로 다시 붙잡기 위한 연습입니다. 핵심은 정답 하나를 외우는 일이 아니라, 왜 이 특징이 남고 왜 저 특징은 보류되거나 탈락하는가를 한 단계씩 설명할 수 있는지 확인하는 데 있습니다.

처음에는 답을 빨리 고르기보다, 다음 두 단계를 일부러 나눠서 보는 편이 좋습니다.

1. 이 특징이 겉으로는 왜 좋아 보이는가
2. 그래도 남길지, 보류할지, 뺄지를 어떤 이유로 결정하는가

이 판단 순서를 먼저 짧은 흐름으로 보면 다음과 같습니다.

flowchart TB
  A["특징 후보"]
  B["왜 좋아 보이는가?"]
  C["다섯 기준 점검<br/>신호 / 잡음 / 시점<br/>중복 / 운영"]
  D["남김"]
  E["보류"]
  F["제거"]

  A --> B
  B --> C
  C -->|명확하고 쓸 수 있음| D
  C -->|판단이 더 필요함| E
  C -->|위험하거나 부적합함| F

이 도식은 정답을 바로 찍기보다 왜 좋아 보이는지 먼저 말해 보고, 그다음 다섯 기준으로 남김/보류/제거를 가르는 순서를 붙잡기 위한 것입니다. 아래 다섯 연습은 이 흐름을 기준으로 하나씩 천천히 분해한 것입니다.

1. 신호(signal)가 있는가¶

예시:

온라인 강의 이탈 예측에서 다음 두 특징 후보를 비교해 보겠습니다.

먼저 볼 질문:

• 두 특징 중 어느 쪽이 행동 변화를 담고 있는가?
• 어느 쪽이 문제와 연결된 이유를 말로 설명하기 쉬운가?

이 장면에서는 videos_completed_7d가 더 좋은 후보입니다. 최근 학습 행동과 이탈이 연결되어 보이기 때문입니다. 반면 user_id_suffix는 값은 숫자지만, 문제와 관련된 신호를 설명하지 못합니다.

연습:

다음 둘 중 1차 후보로 더 먼저 남길 특징을 고르고, 판단을 두 문장으로 나눠 적어 보세요.

적어 볼 순서:

1. 겉으로 보기엔 둘 다 숫자인데, 어떤 값이 실제 행동 신호에 가까운가?
2. 왜 다른 하나는 일반화된 패턴보다 식별자 조각에 가깝다고 볼 수 있는가?

해설:

failed_logins_14d를 먼저 남기는 편이 맞습니다. 계정 접근 문제나 사용 불편과 연결될 수 있는 행동 신호이기 때문입니다. account_number_last_digit는 식별자 조각에 가까워 일반화된 패턴을 기대하기 어렵습니다.

2. 잡음(noise)이 너무 크지 않은가¶

예시:

고객 불만 예측 문제에서 다음 두 특징을 생각해 보겠습니다.

먼저 볼 질문:

• 누가 이 값을 만들었는가?
• 같은 상황이 다시 와도 비슷한 기준으로 반복 기록될 수 있는가?

둘 다 불만과 관련은 있을 수 있지만, agent_feeling_score는 입력 기준이 흔들릴 가능성이 큽니다. 이런 특징은 신호보다 잡음을 더 많이 끌어올 수 있습니다.

연습:

다음 중 잡음이 더 클 가능성이 높은 특징을 고르고, 왜 그런지 기록 방식 기준으로 설명해 보세요.

적어 볼 순서:

1. 어떤 특징이 기록 형식이 더 일정한가?
2. 어떤 특징이 사람마다 다르게 쓰여 같은 뜻을 비교하기 어려운가?

해설:

customer_mood_text 쪽이 잡음 위험이 큽니다. 같은 상황도 사람마다 다르게 적을 수 있고, 기록 형식도 일정하지 않기 때문입니다. 자동 기록되는 지연 시간은 기준이 더 안정적입니다.

3. 예측 시점에 실제로 쓸 수 있는가¶

예시:

결제 이탈 예측에서 다음 특징 후보가 있습니다.

먼저 볼 질문:

• 이 값을 예측 버튼을 누르는 순간 이미 알고 있는가?
• 아니면 결과가 벌어진 뒤에야 확정되는가?

refund_confirmed_at는 학습 표에서 매우 강한 신호처럼 보여도, 실제 예측 순간에는 아직 모를 수 있습니다. 이런 값은 좋은 특징이 아니라 누수 가능 특징입니다.

연습:

다음 둘 중 시점 정당성이 더 높은 특징을 고르고, 왜 다른 하나는 위험한가까지 같이 적어 보세요.

적어 볼 순서:

1. 두 값 중 하나는 미래 구간을 보고 있는가?
2. 실제 서비스에서 예측 시점에 바로 계산 가능한 것은 어느 쪽인가?

해설:

spend_14d_before_prediction만 정당하게 쓸 수 있습니다. next_14d_spend는 미래 정보를 미리 가져온 값이라 예측 모델 입력으로는 사용할 수 없습니다.

4. 중복(redundancy)이 과도하지 않은가¶

예시:

구매 이탈 예측에 다음 칼럼을 한꺼번에 넣으려 합니다.

먼저 볼 질문:

• 이 특징들이 서로 다른 행동을 보여 주는가?
• 아니면 같은 행동을 기간만 바꿔 반복하고 있는가?

세 칼럼이 모두 쓸모없다는 뜻은 아닙니다. 다만 같은 소비 규모를 기간만 바꿔 반복하고 있다면, 정보가 늘기보다 같은 설명을 여러 번 넣는 셈이 될 수 있습니다.

연습:

다음 두 조합 중 중복 점검이 더 시급한 쪽을 고르고, 같은 역할 반복인지 다른 역할 조합인지 구분해 보세요.

적어 볼 순서:

1. 첫 번째 조합의 세 값은 결국 무엇을 공통으로 말하고 있는가?
2. 두 번째 조합은 왜 서로 다른 관점을 보완한다고 볼 수 있는가?

해설:

첫 번째 조합이 먼저 중복 점검 대상입니다. 같은 역할의 특징을 기간만 바꿔 반복하고 있기 때문입니다. 두 번째 조합은 서로 다른 행동 측면을 보여 주므로 역할이 더 분리되어 있습니다.

5. 운영에서 다시 만들 수 있는가¶

예시:

실시간 추천 모델에 다음 특징 후보가 있습니다.

먼저 볼 질문:

• 이 특징을 추론 시점마다 같은 방식으로 다시 만들 수 있는가?
• 비용, 지연, 수기 입력 때문에 자주 빠지거나 늦어질 위험은 없는가?

manual_quality_note는 학습 표에서는 그럴듯해 보여도, 실제 추론 시점마다 제때 들어오지 않을 수 있습니다. 이런 특징은 운영 재현성이 낮습니다.

연습:

다음 중 운영 재현성이 더 높은 특징을 고르고, 수집 안정성과 운영 비용 관점으로 나눠 설명해 보세요.

적어 볼 순서:

1. 어떤 특징이 장애나 외부 의존성에 더 크게 흔들리는가?
2. 어떤 특징이 추론 시점마다 더 싸고 안정적으로 다시 계산되는가?

해설:

sessions_1h가 더 안전한 후보입니다. 내부 로그 기반으로 반복 계산할 수 있기 때문입니다. api_partner_score는 비용, 지연, 장애에 따라 추론 시점 재현성이 흔들릴 수 있습니다.

Python 예제로 특징 후보를 1차 점검해 보기¶

아래 예제는 실무에서 흔히 하는 아주 단순한 1차 점검을 흉내 낸 것입니다. 식별자, 정답 칼럼, 결과 이후에 생긴 칼럼, 상수 칼럼을 먼저 골라냅니다.

문제 상황:

• 특징 후보를 처음 펼쳐 보면 무엇을 입력으로 남기고 무엇을 제외해야 할지 바로 정리되지 않을 수 있다

입력(input):

• 고객 행 목록 rows

기대 출력(output):

• 각 칼럼의 포함/제외 판단
• 그 판단 이유

확인할 개념:

• 특징 선택의 첫 단계는 모델 학습 전 후보 칼럼을 위험 신호별로 점검하는 일이다
• 식별자, 정답, 결과 이후 값은 먼저 제외 후보로 읽는 편이 안전하다

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

# 원시 특징 후보와 선택된 특징 묶음을 비교해 모델 입력 공간을 설계하는 예제입니다.
rows = [
    {
        "customer_id": "C001",
        "visits_30d": 12,
        "support_tickets_30d": 0,
        "contract_cancelled_at": "",
        "membership_tier": "gold",
        "country": "KR",
        "churn_next_month": 0,
    },
    {
        "customer_id": "C002",
        "visits_30d": 3,
        "support_tickets_30d": 2,
        "contract_cancelled_at": "2026-05-14",
        "membership_tier": "gold",
        "country": "KR",
        "churn_next_month": 1,
    },
    {
        "customer_id": "C003",
        "visits_30d": 7,
        "support_tickets_30d": 1,
        "contract_cancelled_at": "",
        "membership_tier": "gold",
        "country": "KR",
        "churn_next_month": 0,
    },
]

target = "churn_next_month"
columns = list(rows[0].keys())

selected = []
rejected = []

for column in columns:
    values = [row[column] for row in rows]
    unique_count = len(set(values))

    if column == target:
        rejected.append((column, "label"))
    elif column.endswith("_id"):
        rejected.append((column, "identifier"))
    elif column.endswith("_at"):
        rejected.append((column, "post-outcome timestamp"))
    elif unique_count == 1:
        rejected.append((column, "constant value"))
    else:
        selected.append((column, "keep as candidate"))

print("selected candidates:")
for name, reason in selected:
    print("-", name, "->", reason)

print()
print("rejected candidates:")
for name, reason in rejected:
    print("-", name, "->", reason)

실행 결과는 다음과 같습니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

selected candidates:
- visits_30d -> keep as candidate
- support_tickets_30d -> keep as candidate

rejected candidates:
- customer_id -> identifier
- contract_cancelled_at -> post-outcome timestamp
- membership_tier -> constant value
- country -> constant value
- churn_next_month -> label

이 출력은 좋은 특징을 완전히 결정했다는 뜻이 아닙니다. 다만 독자가 데이터 테이블을 처음 펼쳤을 때, 무엇부터 의심해야 하는지 보여 줍니다.

세부 학습내용 보충¶

scikit-learn에서 흔히 보는 특징 선택 방식은 무엇인가¶

실무에서는 다음 같은 방식이 자주 나옵니다.

여기서 남길 기준은 이 알고리즘들을 외우는 일이 아닙니다. 먼저 선택의 이유를 설명할 수 있는가를 잡아야 하고, 알고리즘은 그 다음 단계에서 도와주는 도구입니다.

체크리스트¶

• 이 칼럼이 예측 시점에 실제로 존재하는지 먼저 확인하고 있는가?
• 신호가 있어 보여도 운영에서 안정적으로 수집할 수 없는 특징은 따로 표시하고 있는가?
• 특징 선택과 전처리를 무엇을 남길지와 어떻게 바꿀지로 구분해 설명할 수 있는가?
• 예측 시점에 알 수 없는 칼럼을 빼고 있는가?
• 정답(label)이나 정답 이후 정보가 섞이지 않았는가?
• 식별자와 상수 칼럼을 먼저 점검했는가?
• 실제 서비스에서 안정적으로 구할 수 있는 특징만 남기고 있는가?
• 특징 선택과 전처리를 같은 일로 섞어 생각하지 않는가?
• 특징(feature)이 현실 정보를 모델 입력으로 바꾼 표현이며, 특징 선택은 많이 넣기보다 정당하게 쓸 수 있는 입력을 고르기에 가깝다는 점을 설명할 수 있는가
• 가장 먼저 누수(leakage), 관련성, 운영 가능성을 확인해야 하는 이유를 설명할 수 있는가

출처와 참고 자료¶

• scikit-learn, 1.13. Feature selection, scikit-learn User Guide, 확인 날짜: 2026-06-26. https://scikit-learn.org/stable/modules/feature_selection.html
• scikit-learn, 12.2. Data leakage during pre-processing, scikit-learn User Guide, 확인 날짜: 2026-06-26. https://scikit-learn.org/stable/common_pitfalls.html