이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
특징 엔지니어링(Feature Engineering)에서 가장 중요하다고 생각하는 요소는 도메인 지식과 데이터 탐색을 결합하는 것입니다. 어떤 변수가 예측에 유의미한지를 데이터만으로 판단하기 어려울 때, 도메인 전문가의 인사이트가 유효한 특징을 찾는 지름길이 됩니다. 또 결측값 처리, 이상치 처리, 스케일링 방법 선택도 모델 성능에 직접 영향을 줍니다.
범주형 변수를 인코딩하는 방식(원핫, 레이블, 타겟 인코딩)도 상황에 따라 달리 써야 합니다. 수업 프로젝트에서 특징 선택 과정에 시간을 더 쏟을수록 모델 성능이 안정적으로 올라가는 것을 확인했습니다. 좋은 특징 하나가 복잡한 모델보다 성능을 더 크게 높이는 경우도 많습니다. 데이터를 이해하는 것이 모델링의 출발점입니다.
특징 엔지니어링에서 도메인 이해 없이 변수를 추가했다가 오히려 모델 성능이 떨어진 경험이 있었습니다. 학교 프로젝트에서 상관계수가 높아 보이는 변수를 그대로 추가했는데, 실제로는 타깃 변수와 인과 관계가 없는 변수였고 검증 오류가 오히려 증가했습니다. 도메인 의미를 확인하지 않고 수치만 보고 판단한 결과였습니다. 그 이후로는 새 변수를 추가하기 전에 '이 변수가 왜 예측에 도움이 돼야 하는가'를 한 줄 적는 루틴을 만들었습니다.
변수 추가 이유 메모가 한 줄도 없으면 추가하지 않는 기준을 뒀습니다. 변수의 통계적 상관보다 의미적 근거가 먼저라는 걸 그때 배웠습니다. 지금은 특징을 추가할 때 이유를 먼저 적고 수치를 확인합니다.
특징 엔지니어링이 모델에 실제로 기여했는지를 수치로 확인하지 않으면 효과를 알 수 없다는 걸 경험했습니다. 로그 변환과 스케일링을 적용하고 막연히 '좋아졌겠지'라고 생각하고 넘어갔는데, 나중에 변환 전·후를 비교해보니 특정 변환은 오히려 성능에 영향이 없었고 작업 시간만 늘어난 경우가 있었습니다. 그 이후로는 특징 변환을 적용할 때마다 교차 검증 점수를 전·후로 기록하는 방식을 도입했습니다.
변환 효과 로그를 보면 어떤 변환이 실제로 도움이 됐는지 파악할 수 있었고, 다음 프로젝트에서 참고 자료가 됐습니다. 특징 작업은 수치로 검증하지 않으면 느낌으로 끝난다는 걸 배웠습니다. 지금은 특징 변환 전후를 비교하는 검증 코드를 먼저 작성하고 변환을 적용합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 삼성전자 공통직무·미지정 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.