피처 엔지니어링: ML 모델 품질을 좌우하는 결정

월요일 아침, 새로운 머신러닝 모델이 프로덕션에 배포됩니다. 점심시간쯤이 되자 분석가들은 오탐지에 시달리고 있습니다. 우선순위가 높은 케이스는 놓치고, 일반적인 케이스는 에스컬레이션되며, 모델의 실제 성능이 검증 결과와 왜 그렇게 달라 보이는지 아무도 설명하지 못합니다.

문제가 반드시 알고리즘에 있는 것은 아닙니다. 데이터가 표현된 방식 때문일 수 있습니다. 트랜잭션 금액이 원값으로 사용되었지만 모델은 해당 구매가 그 특정 고객에게 얼마나 이례적인지 보지 못했을 수 있습니다. 또는 범주가 잘못된 관계를 암시하는 방식으로 인코딩되었을 수도 있습니다. 모델은 정확한 데이터로 학습되었을 수 있지만 그 데이터 안의 신호는 제대로 전달되지 않았습니다.

이것이 바로 피처 엔지니어링의 역할입니다. 가공 전 데이터를 머신러닝 모델이 실제로 사용할 수 있는 입력으로 바꾸는 것입니다. 여기에는 결측값 처리, 범주 인코딩, 숫자 필드 스케일링과 같은 익숙한 데이터 준비 작업이 포함되지만, 모델이 무엇을 어떤 형태로 알아야 하는지에 관한 더 깊은 표현 방식의 선택도 수반됩니다. 이러한 선택은 얼마나 많은 유용한 신호가 모델에 도달하는지, 그리고 모델이 실사용 데이터를 만났을 때 얼마나 잘 작동하는지를 결정합니다.

피처 엔지니어링은 머신러닝 모델이 더 정확한 예측을 할 수 있도록 도메인 지식을 사용해 가공 전 데이터에서 피처라고 하는 입력 변수를 생성, 변환, 선택하는 프로세스입니다.

피처는 트랜잭션 금액이나 계정 생성 후 경과 일수처럼 직접 사용되는 소스 컬럼일 수도 있고, 지난 90일 동안 고객의 평균 주문 금액, 지난 1시간 동안의 인증 실패 횟수, 또는 각각 따로 볼 때보다 함께 볼 때 더 많은 정보를 제공하는 두 측정값 간의 비율처럼 새롭게 파생될 수도 있습니다.

피처 엔지니어링은 가공 전 데이터와 모델 학습 사이에 위치합니다. 팀은 소스 시스템에서 신호를 추출하고, 이를 모델에 바로 사용할 수 있는 입력값으로 변환하며, 어떤 입력값이 검증 성능을 개선하는지 평가하고, 승인된 로직을 재사용할 수 있도록 피처 파이프라인 또는 피처 스토어로 옮깁니다. 모델에 어떤 피처가 필요한지 결정한다는 것은 모델이 도메인에 대해 무엇을 이해해야 하는지 결정하는 일이기도 합니다.

피처 엔지니어링은 비즈니스 문제에 대한 팀의 이해를 모델에 인코딩하기 때문에 데이터 사이언티스트, 데이터 엔지니어, 도메인 전문가 간의 협업이 필요합니다. 제대로 수행하면 머신러닝 수명 주기에서 가장 큰 효과를 내는 활동 중 하나가 됩니다.

모델의 품질은 입력에 의해 제한됩니다. 아무리 알고리즘 선택, 초매개변수 튜닝 또는 컴퓨팅을 해도 처음부터 피처 세트에 존재하지 않았던 신호를 되살릴 수는 없습니다. 피처 엔지니어링은 그 상한이 설정되는 지점이며, 팀이 ML 수명 주기에서 거의 어느 다른 지점보다 모델 품질을 더 직접적으로 제어할 수 있는 지점입니다.

그 상한을 정하는 한 가지 방식은 표현 방식입니다. 동일한 기초 데이터라도 다르게 표현되면 모델에는 문제에 대한 근본적으로 다른 그림이 제공됩니다. 제품 사용 데이터를 기반으로 구축한 이탈 모델을 생각해 보세요. 지난 30일간의 로그인 횟수 원값은 고객이 얼마나 활발했는지를 모델에 알려줍니다. 하지만 실제로 이탈을 예측하는 신호는 활동량 자체보다 그 변화인 경우가 많습니다. 60일 전보다 로그인 빈도가 절반으로 줄어든 고객은 원래부터 그 빈도로 로그인해 온 고객과는 전혀 다른 상황에 놓여 있습니다. 기초 데이터는 동일합니다. 그러나 횟수가 아니라 추세로 표현되면 원값만으로는 담을 수 없는 신호를 담게 됩니다.

Pedro Domingos의 대표 논문 A Few Useful Things to Know About Machine Learning에서는 표현을 이 분야의 핵심 문제 중 하나로 제시합니다. 이 관찰은 여전히 유효합니다. 사용 가능한 피처가 문제의 구조를 포착하지 못하면 알고리즘이 어떻게 튜닝되었든 활용할 수 있는 정보가 줄어듭니다.

피처 엔지니어링은 일반화 성능에도 영향을 미칩니다. 데이터 안의 실제적이고 지속적인 패턴을 반영하는 피처로 학습한 모델은 새로운 고객, 새로운 제품 또는 다른 운영 환경을 만났을 때 더 정확한 예측을 내놓을 가능성이 높습니다. 반대로 학습 기간에는 목표값과 우연히 상관관계를 보였지만 그 이유가 부수적 요인에 불과한 피처로 학습한 모델은 프로덕션에서 더 빠르게 성능이 저하됩니다.

에이전틱 ML로 피처 엔지니어링을 간소화하는 방법을 영상으로 확인해 보세요

피처 엔지니어링은 보통 예측하려는 문제에서 출발해, 필요한 데이터로 거슬러 올라가는 방식으로 진행됩니다. 예를 들어 수요 예측 모델을 만드는 팀과 지원 티켓을 분류하는 팀은 둘 다 고객, 제품, 시계열 데이터를 사용하더라도 필요한 신호가 다릅니다.

실무적인 프로세스는 일반적으로 다음 단계를 포함합니다.

1. 데이터와 문제 이해: 예측 대상, 모델이 지원할 의사 결정, 지연 시간, 설명 가능성, 데이터 액세스와 관련된 제약 조건을 정의합니다.
2. 가공 전 데이터 탐색 및 분석: 분포, 결측값, 이상값, 상관관계, 카테고리 카디널리티, 시간 기반 패턴을 점검합니다.
3. 피처 생성 및 변환: 비율, 롤링 윈도우, 카운트, 플래그, 상호작용, 정규화된 값과 같은 측정값을 도출합니다.
4. 피처 관련성 평가: 통계 테스트, 모델 기반 중요도 지표, 도메인 검토, 검증 결과를 활용해 어떤 피처가 유용한 신호를 담고 있는지 식별합니다.
5. 모델 성능으로 검증: 통제된 실험으로 모델을 학습하고 테스트하면서 데이터 누수, 과적합, 학습 데이터와 프로덕션 데이터 간 드리프트를 점검합니다.

이 프로세스는 반복적으로 진행됩니다. 데이터 사이언티스트는 비율, 카운트, 롤링 집계, 지연 피처, 플래그, 범주형 인코딩, 인터랙션 항을 도출한 뒤 이러한 입력값이 홀드아웃 데이터에서 성능을 개선하는지 테스트할 수 있습니다. 어떤 피처는 즉시 유용성이 입증됩니다. 반면 어떤 피처는 정보 누수를 일으키거나, 기간별 변동이 지나치게 크거나, 추론 시점에 사용할 수 없는 데이터에 의존하기 때문에 제외됩니다.

피처 로직은 여러 환경으로 확산되면서 서로 달라질 수 있으므로 이 프로세스에는 엄격한 관리가 필요합니다. 노트북에서 테스트한 계산을 학습 파이프라인에서 다시 구성하고, 실시간 스코어링 서비스를 위해 세 번째로 재작성하면 동일한 기본 개념에 대해 조금씩 다른 세 가지 값이 생성될 수 있습니다. 재현 가능한 피처 파이프라인과 피처 스토어는 이러한 드리프트를 방지하기 위한 것입니다. 학습 시 사용한 정의를 보존하고, 이를 배치 추론 또는 실시간 추론에서 일관되게 사용할 수 있도록 합니다.

피처 엔지니어링에는 다양한 기법이 활용됩니다. 일부 기법은 가공 전 데이터를 모델링에 적합하게 준비합니다. 또 다른 기법은 기존 필드에서 새로운 신호를 구성합니다. 적절한 조합은 데이터 유형, 모델 계열, 모델이 지원해야 하는 의사결정에 따라 달라집니다.

결측값 대치와 이상값 처리

결측값은 처리하기 전에 먼저 그 의미를 해석해야 합니다. 비어 있는 필드는 값이 알려지지 않았거나, 선택 입력값이었거나, 의도적으로 보류되었거나, 수집 시점에 사용할 수 없었거나, 실제로 존재하지 않았음을 나타낼 수 있습니다. 결측값 대치는 평균, 중앙값, 최빈값, 상수 값, 모델 기반 추정값 등의 방법을 사용해 누락된 값을 채웁니다. 많은 경우 팀은 결측 여부를 나타내는 이진 지표도 추가하여, 값의 부재 자체가 예측에 유용한 정보인지 모델이 학습할 수 있도록 합니다. 실제로 값의 부재가 유의미한 신호가 되는 경우는 많습니다.

이상값도 마찬가지로 판단이 필요합니다. 비정상적으로 큰 트랜잭션은 사기 거래일 수도 있고, 정상적인 엔터프라이즈 구매일 수도 있으며, 데이터 입력 오류일 수도 있습니다. 팀은 값을 특정 임계값으로 제한하거나, 왜도를 줄이는 변환을 적용하거나, 명백히 잘못된 레코드를 제거할 수 있습니다. 또는 모델이 감지해야 하는 의미 있는 행동을 반영하는 경우 극단값을 보존할 수도 있습니다. 이상값 처리는 모델이 학습할 현실의 버전을 정의한다는 점에서 표현 방식에 대한 결정입니다.

스케일링 및 정규화

스케일링은 숫자형 피처의 범위를 조정해 값의 크기 차이가 모델 동작에 인위적인 차이를 만들지 않도록 합니다. 최소-최대 스케일링은 값을 고정된 구간에 매핑합니다. Z-점수 표준화는 값을 해당 분포의 평균과 표준편차를 기준으로 표현합니다. 로버스트 스케일링은 중앙값과 사분위수 범위를 사용하며, 평균 기반 방법보다 이상값에 덜 민감합니다.

스케일에 대한 민감도는 모델 유형에 따라 다릅니다. 선형 모델, 신경망, 거리 기반 알고리즘은 스케일링되지 않은 피처의 영향을 상대적으로 크게 받습니다. 반면 트리 기반 모델은 일반적으로 스케일에 덜 민감합니다. 다만 동일한 피처 세트가 여러 다운스트림 모델이나 시스템에 입력되는 경우에는 전처리 방식을 표준화할 수 있습니다.

범주형 변수 인코딩

대부분의 ML 모델은 범주형 값을 숫자로 표현해야 합니다. 원-핫 인코딩은 각 카테고리에 대해 이진 지표 컬럼을 생성하며, 카디널리티가 낮을 때는 간단하게 적용할 수 있습니다. 순서형 인코딩은 낮음, 중간, 높음처럼 의미 있는 순서를 보존합니다. 레이블 인코딩은 카테고리에 정수 ID를 할당하지만, 실제로는 존재하지 않는 순서를 의도치 않게 암시할 수 있습니다.

가맹점 식별자, 제품 SKU, 지리적 코드처럼 카디널리티가 높은 필드는 더 세심한 처리가 필요합니다. 수준이 수천 개인 카테고리에는 원-핫 인코딩을 적용하기 어렵습니다. 타깃 인코딩과 평균 인코딩은 카테고리 레이블을 예측 타깃에서 도출한 통계값으로 대체하여 이러한 문제를 완화할 수 있습니다. 그러나 이러한 방식은 홀드아웃 세트의 정보가 학습 과정에 누수되지 않도록 엄격한 검증이 필요합니다.

변환, 비닝 및 이산화

변환은 피처의 분포 또는 예측 타깃과의 관계를 조정합니다. 로그 변환은 매출, 세션 지속 시간, 계정 잔액처럼 긴 꼬리 분포를 보이는 값의 영향을 줄일 수 있습니다. Box-Cox 및 관련 변환은 숫자형 피처가 분포 가정을 가진 모델에 더 적합하도록 조정할 수 있습니다. 단, Box-Cox는 입력값이 엄격히 양수여야 합니다.

비닝은 연속형 값을 이산 구간으로 그룹화합니다. 모델은 원시 나이 대신 연령대, 가입 후 정확한 일수 대신 사용 기간 구간, 트랜잭션 금액 대신 지출 등급을 입력값으로 받을 수 있습니다. 비닝은 일부 패턴의 학습을 쉽게 만들고, 규제 대상 맥락에서는 설명을 더 용이하게 합니다. 규제 기준값, 제품 등급 경계, 임상 범위처럼 도메인 임계값이 중요한 경우에는 이러한 임계값과 정렬된 구간이 원시 숫자값보다 더 의미 있는 피처를 생성하는 경우가 많습니다.

피처 생성

피처 생성은 도메인 지식이 가장 직접적으로 영향을 미치는 영역입니다. 수요를 예측하는 리테일 기업에는 최근 판매 속도, 재고 현황, 프로모션 시점, 지역 이벤트와의 근접성을 나타내는 피처가 필요할 수 있습니다. 보안 모델에는 로그인 실패 속도, 디바이스 신규성 점수, 불가능한 이동 지표, 계정 자체 기준선 대비 행동 편차가 필요할 수 있습니다. 고객 건전성 모델에는 제품 참여도 추세, 지원 상호작용 패턴, 계약 상태 변화가 필요할 수 있습니다.

피처 크로싱은 필드를 결합해 상호작용을 포착합니다. 예를 들어 지역별 제품 카테고리, 채널별 고객 세그먼트, 시간대별 디바이스 유형이 여기에 해당합니다. 다항 피처는 일부 모델 계열이 비선형 관계를 표현하는 데 도움이 됩니다. 시간 기반 피처는 타임스탬프에서 하루 중 시간, 요일, 마지막 이벤트 이후 경과 시간, 롤링 평균, 지연 값, 반복 패턴을 위한 주기적 인코딩과 같은 구조를 추출합니다.

차원 축소

데이터 세트의 피처 수가 많거나 노이즈가 많거나 상관관계가 높은 경우, 차원 축소 방법은 유용한 정보를 보존하면서 피처 공간을 압축할 수 있습니다. 주성분 분석은 상관관계가 있는 숫자형 피처를 더 작은 구성 요소 집합으로 투영합니다. 오토인코더와 유사한 방법은 더 복잡한 입력에서 압축된 표현을 학습할 수 있습니다.

절충해야 할 부분은 해석 가능성입니다. 축소된 표현은 모델 효율성과 경우에 따라 성능을 높일 수 있지만, 그 결과로 생성된 구성 요소가 도메인 전문가가 이해할 수 있는 개념과 대응하지 않을 수 있습니다. 중대한 영향을 미치거나 규제를 받는 사용 사례에서는 이러한 투명성 손실이 실제 결과로 이어질 수 있으므로, 팀은 얻는 이점과 포기해야 하는 요소를 비교해 판단해야 합니다.

이러한 용어는 ML 워크플로우에서 서로 밀접하게 연결되어 있기 때문에 자주 함께 등장합니다. 다음은 각각에 대한 간략한 개요입니다.

피처 엔지니어링

피처 엔지니어링은 가공 전 데이터에서 모델 입력을 준비하는 광범위한 작업입니다. 여기에는 피처 생성, 값 변환, 결측값 처리, 범주 인코딩, 차원 축소 적용, 학습에 사용할 피처 식별이 포함됩니다. 아래의 다른 활동은 이와 같은 더 광범위한 작업의 하위 집합이거나 보완 활동입니다.

피처 선택

피처 선택은 사용 가능한 집합에서 어떤 피처가 모델에 포함되어야 하는지 식별합니다. 팀은 중복되거나, 불안정하거나, 타깃과의 관련성이 약하거나, 프로덕션 맥락에서 설명하기 어렵거나, 추론 시점에 사용할 수 없는 피처를 제거합니다.

선택은 과적합을 줄이고 모델 효율성을 개선할 수 있습니다. 또한 운영상의 이점도 있습니다. 안정적이고 잘 이해된 소수의 피처로 구성된 모델은 약하거나 중복되는 많은 입력에 의존하는 모델보다 일반적으로 프로덕션에서 모니터링하기 쉽고 감사하기도 쉽습니다. 일반적인 접근 방식에는 통계적 필터 방법, 모델 성능을 기준으로 피처 하위 집합을 평가하는 래퍼 방법, 정규화 계수 및 트리 기반 중요도 점수와 같은 모델 내부 요소를 사용해 어떤 피처가 영향력을 갖는지 식별하는 임베디드 방법이 포함됩니다.

피처 추출

피처 추출은 가공 전 데이터 또는 복잡한 데이터에서 구조를 도출합니다. 타임스탬프에서는 요일, 월, 기준 이벤트 이후 경과 시간을 추출할 수 있습니다. 자유 텍스트 필드에서는 용어 빈도, 감성 점수, 밀집 벡터 임베딩을 생성할 수 있습니다. 이미지 모델은 중간 네트워크 계층에서 에지, 텍스처 또는 학습된 표현을 추출할 수 있습니다.

실제로 추출은 피처 생성과 상당 부분 겹칩니다. 차이는 강조점에 있습니다. 추출은 원시 입력에서 구조를 끌어내는 데 초점을 맞추는 반면, 피처 엔지니어링은 이러한 입력을 모델링에 맞게 준비하는 더 광범위한 워크플로우를 포괄합니다.

피처 스토어

피처 스토어는 피처 정의, 계산된 피처 값 및 관련 메타데이터를 위한 관리형 리포지토리입니다. 이를 통해 팀은 프로젝트 전반에서 피처를 재사용하고, 중복된 파이프라인 로직을 줄이며, 학습 시점의 피처 정의를 추론 시점의 정의와 일관되게 유지할 수 있습니다.

데이터 증강은 기존 예제의 수정된 버전을 생성하여 학습 데이터를 확장합니다. 이는 컴퓨터 비전과 자연어 처리에서 가장 일반적이며, 특정 수정은 레이블을 변경하지 않고도 학습 세트의 다양성을 높일 수 있습니다.

이미지의 경우 증강에는 뒤집기, 회전, 자르기, 밝기 조정 또는 작은 이동이 포함될 수 있습니다. 텍스트의 경우 동의어 대체, 의역 또는 제어된 교란이 포함될 수 있습니다. 클래스 불균형이 있는 테이블 형식 데이터의 경우, SMOTE와 같은 기법은 표본 수가 부족한 클래스에 대한 합성 예제를 생성합니다.

모든 증강 결정에서 핵심은 변형된 예제가 여전히 동일한 대상을 나타내는지 여부입니다. 제품 이미지를 회전해도 전자상거래 분류 작업에서는 레이블이 유지될 수 있습니다. 반면 제조 결함 감지 모델에서는 방향이 결함 유형에 대한 정보를 담고 있을 수 있습니다. 증강은 모델이 강건하게 대응해야 하는 변동을 반영할 때 유용하지만, 예측 신호를 훼손하면 역효과를 냅니다.

임베딩은 데이터의 관계를 인코딩하는 밀집 벡터 표현입니다. 임베딩은 텍스트, 이미지, 추천 및 카디널리티가 높은 범주형 워크플로우에서 흔히 사용되며, 이 경우 원시 값에는 인코딩 방식이 제공할 수 있는 것보다 더 풍부한 수치 형태가 필요합니다.

예를 들어 제품 ID는 원시 정수로는 내재적 의미가 거의 없지만, 임베딩은 설명, 공동 구매 행동, 시각적 속성, 탐색 패턴을 기반으로 해당 제품을 유사한 제품과 가까운 위치에 배치할 수 있습니다. 텍스트 임베딩은 의미적으로 관련된 구문을 벡터 공간에서 서로 가깝게 배치할 수 있어 검색, 분류, 추천 및 검색 증강 생성(RAG)에 유용합니다.

임베딩은 피처 엔지니어링과의 관계에서 독특한 위치를 차지합니다. 임베딩은 수작업 피처와 마찬가지로 다운스트림 모델에 입력되는 학습된 피처로 사용될 수 있습니다. 또한 도메인 분석을 통해 표현을 정의하는 것이 아니라 대규모 데이터 세트에서 표현을 학습한다는 점에서 피처 개발의 다른 방식을 보여줍니다. 실제로 많은 프로덕션 ML 시스템은 콘텐츠 또는 식별자 피처에는 학습된 임베딩을 사용하고, 행동, 시간, 맥락 신호에는 엔지니어링된 피처를 사용하는 방식으로 두 접근법을 결합합니다.

자동화된 피처 엔지니어링은 소프트웨어를 사용해 가공 전 데이터에서 후보 피처를 대규모로 생성합니다. Featuretools와 같은 도구는 Deep Feature Synthesis를 포함한 방법을 사용해 관련 테이블 전반에서 피처를 체계적으로 생성합니다. AutoML 시스템은 더 광범위한 모델 개발 워크플로우의 일부로 변환, 인코딩, 상호작용 피처를 생성할 수 있습니다.

자동화는 검색 공간이 크거나 후보 변환이 반복적일 때 가장 유용합니다. 시스템은 팀이 각 피처를 수동으로 작성하는 것보다 더 빠르게 롤링 집계, 날짜 파생 필드, 범주형 인코딩, 테이블 수준 요약을 생성할 수 있습니다.

그러나 여전히 도메인 지식으로 작업을 통제해야 합니다. 전문가 검토, 검증, 거버넌스를 통해 어떤 피처를 사용하는 것이 적절한지 결정합니다.

프로덕션 피처 엔지니어링에는 변환 코드 이상의 것이 필요합니다. 팀에는 소스 데이터에 대한 거버넌스 기반 액세스, 대규모 데이터 세트를 위한 확장 가능한 처리 용량, 재사용 가능한 피처 정의, 신뢰할 수 있는 피처 최신성, 학습 데이터에서 배포된 모델로 이어지는 명확한 경로가 필요합니다.

Snowflake는 거버넌스가 적용된 데이터 위에서 엔드투엔드 ML을 위한 통합 기능 세트인 Snowflake ML을 통해 이 워크플로우를 지원하며, 여기에는 피처 엔지니어링, 모델 학습 및 추론이 포함됩니다.

Snowpark를 사용하면 팀은 Python 또는 SQL로 피처 변환을 작성하고, 데이터를 외부 환경으로 이동하지 않고도 데이터 가까이에서 실행할 수 있습니다. Snowflake Feature Store는 관리형 피처 정의와 피처 뷰를 제공하여 팀이 Snowflake 내에서 피처 파이프라인을 생성, 구체화, 가져오기 및 관리할 수 있게 합니다. 피처 뷰는 가공 전 데이터를 모델에 바로 사용할 수 있는 피처로 변환하는 Python 또는 SQL 파이프라인을 캡슐화할 수 있으며, Snowflake 관리형 피처 뷰는 정의된 일정에 따라 자동으로 새로 고침될 수 있습니다.

Dynamic Tables는 SQL로 정의된 변환을 최신 상태로 유지해야 하는 증분 피처 파이프라인을 지원합니다. Snowflake는 Dynamic Tables를 파이프라인으로 관리하고, 종속성을 추적하며, 다운스트림 테이블이 입력의 일관된 스냅샷을 반영하도록 새로 고침을 조정합니다. Dynamic Tables는 데이터가 얼마나 최신 상태여야 하는지를 지정하는 target lag와 지원되는 변환 패턴에 대한 증분 새로 고침도 지원합니다.

프로덕션 ML의 경우, Snowflake Feature Store를 Snowflake Model Registry와 함께 사용할 수 있습니다. 레지스트리는 모델 버전, 지표 및 메타데이터를 저장하고 관리하며, Python, SQL 또는 REST API 엔드포인트를 통한 추론을 지원하고, 역할 기반 액세스 제어(RBAC)를 통해 모델 액세스를 관리합니다.

피처 엔지니어링은 때때로 실제 모델링이 시작되기 전에 이루어지는 준비 작업으로 설명됩니다. 하지만 이러한 설명은 이 작업의 중요성과 실제로 포함되는 내용을 놓치고 있습니다. 변수를 어떻게 표현할지, 결측값을 어떻게 처리할지, 카테고리를 어떻게 인코딩할지, 지연 피처를 어떻게 구성할지에 관한 모든 결정은 모델이 자신이 작동하는 도메인에 대해 무엇을 이해할 수 있는지를 결정합니다.

프로덕션 규모에서는 표현에 관한 결정이 늘어납니다. 피처는 여러 모델에서 재사용되고, 여러 팀에서 다시 구축되며, 서로 다른 환경에서 다시 계산됩니다. 탐색부터 학습, 추론에 이르기까지 이러한 정의를 일관되게 유지하는 것은 모델 품질에 직접적인 영향을 미칩니다.

이것이 피처 엔지니어링과 MLOps가 밀접하게 연결된 이유입니다. 피처 엔지니어링은 모델이 무엇에서 학습하는지를 결정하는 반면, MLOps는 모델이 개발에서 프로덕션으로 이동하는 과정에서 이러한 피처 정의가 일관되고 관찰 가능하며 신뢰할 수 있게 유지되도록 지원합니다.