어제 본 스케일링·인코딩·결측치 처리를 매번 pandas로 손코딩하면 시간이 오래 걸리고, 적용한 변환 순서를 재현하기도 어렵다. Data Wrangler는 이 전체 흐름을 시각적 인터페이스로 묶어주는 SageMaker Studio 내장 도구다.
핵심은 flow라는 개념이다. flow는 데이터 소스 → 변환 단계들 → 출력으로 이어지는 방향성 그래프(DAG)이며, 각 노드가 하나의 데이터 처리 단계다. 사용자가 GUI에서 변환을 추가하면 Data Wrangler가 내부적으로 그에 해당하는 코드(pandas/PySpark)를 생성한다.
[S3 데이터 소스]
|
v
[결측치 대치: median]
|
v
[One-Hot 인코딩: category]
|
v
[StandardScaler: numeric]
|
v
[출력: Feature Store / S3 / Pipeline]
300개 이상의 내장 변환을 제공하므로 흔한 전처리는 대부분 코드 없이 해결된다. 커스텀 로직이 필요하면 Python(pandas), PySpark, SQL 코드 블록을 직접 넣을 수도 있다.
노트북 손코딩과의 차이
구분
노트북 손코딩
Data Wrangler flow
변환 순서
셀 실행 순서에 좌우됨
그래프에 고정
재현성
낮음(누가 어떤 순서로 돌렸나)
높음(flow 파일이 청사진)
탐색 속도
코드 작성 시간 필요
클릭으로 즉시
대규모 적용
직접 분산 처리 구현
Processing Job export
품질 점검
직접 코드 작성
자동 리포트 제공
Data Wrangler의 flow는 데이터 엔지니어링의 ETL/ELT 파이프라인을 시각화한 것이다. 각 변환이 멱등적(idempotent)이고 순서가 명확한 DAG로 표현되므로, 같은 입력에 같은 변환을 적용하면 항상 같은 출력이 나온다. 이 재현성(reproducibility)이 ML 파이프라인의 핵심 가치다. 손코딩한 노트북은 셀 실행 순서에 따라 결과가 달라지지만, flow는 순서가 그래프에 고정된다.
Data Wrangler는 여러 소스에서 직접 데이터를 가져온다. 시험에서 "어디서 데이터를 불러올 수 있는가"를 묻는 문제가 있다.
데이터 소스
용도
강점
Amazon S3
가장 일반적. CSV, Parquet, JSON 등
데이터 레이크 직결
Amazon Athena
S3 위 데이터를 SQL로 쿼리해 불러옴
WHERE로 필요한 부분만
Amazon Redshift
데이터 웨어하우스에서 직접
이미 정제된 정형 데이터
Snowflake / Databricks
외부 데이터 플랫폼
멀티 플랫폼 환경
SageMaker Feature Store
이미 만든 특성 재사용
팀 간 공유 자산 활용
Athena 연동이 특히 유용하다. 거대한 S3 데이터셋 전체를 다운로드하지 않고, SQL WHERE 절로 필요한 부분만 샘플링해 불러올 수 있다.
⚠️ 함정: Data Wrangler에서 보는 데이터는 기본적으로 샘플(상위 N행 또는 무작위 샘플)이다. 화면에서 변환을 미리보기로 확인하더라도, 실제 전체 데이터에 적용하려면 export하여 SageMaker Processing Job으로 돌려야 한다. 샘플에서 잘 돼 보여도 전체 데이터의 분포가 다르면 결과가 달라질 수 있으니, 샘플 크기와 방식을 인지해야 한다.
# Data Wrangler의 변환은 GUI에서 클릭으로 구성하고# export 시 노트북/스크립트/Processing Job 정의로 생성된다 (개념)## .flow 파일이 변환 정의를 담고, Processing Job이 전체 데이터에 적용한다.# flow(설계도) → export → Processing Job(전체 데이터 실행)
Data Wrangler에는 Quick Model이라는 기능이 있어, 현재까지의 변환 결과로 즉석에서 트리 기반 모델을 학습시켜 예상 성능과 특성 중요도(feature importance)를 미리 보여준다. 이로써 "이 변환이 실제로 모델 성능에 도움이 되는가"를 본격 학습 전에 빠르게 검증할 수 있다. 또 Target Leakage 분석으로 타깃 정보가 새는 특성을 자동 탐지해준다.
변환만큼 중요한 게 데이터 이해다. Data Wrangler는 클릭 한 번으로 여러 분석 시각화를 제공한다.
분석 기능
무엇을 알려주나
이어지는 조치
Data Quality and Insights Report
결측치, 중복, 타깃 누수, 클래스 불균형, 특성 중요도
전체 그림 파악 후 우선순위 결정
히스토그램/산점도
분포와 상관관계
로그 변환·이상치 처리 판단
Quick Model
즉석 성능 추정과 특성 중요도
무의미한 특성 드롭
Target Leakage
타깃 정보가 새는 특성
해당 특성 제거
Bias Report (Clarify 연동)
민감 속성 기준 편향
데이터 재수집·리샘플링 (Day 4)
Multicollinearity
변수 간 다중공선성
중복 특성 정리
이 리포트들은 어제 배운 "데이터 사전 확인, 결측 메커니즘 파악, 이상치 탐지"를 자동화해준다.
한 팀이 이탈 예측 모델을 만들며 "마지막 로그인일" 특성을 넣었는데, 알고 보니 이탈한 고객만 이 값이 채워져 있었다(이탈 시점에 기록). Data Wrangler의 Target Leakage 분석이 이 특성의 비정상적으로 높은 예측력을 잡아내 누수를 사전에 발견했다. 누수 특성을 그대로 뒀다면 오프라인 검증 정확도는 99%였겠지만 실서비스에선 무용지물이었을 것이다.
flow를 완성하면 여러 대상으로 내보낼 수 있다. 시험에서 export 옵션을 구분하는 문제가 나온다.
Export 대상
의미
언제 고르나
SageMaker Processing Job
전체 데이터에 변환을 적용하는 배치 작업 실행
샘플 설계를 전체에 적용
SageMaker Feature Store
처리된 특성을 Feature Store에 적재(Day 3)
팀 간 재사용·학습/추론 일관성
SageMaker Pipelines
변환을 ML 파이프라인 단계로 통합
자동 재학습 파이프라인 구성
Python 코드 / Jupyter Notebook
변환 로직을 코드로 추출해 재사용
기존 코드베이스에 통합
S3
처리 결과를 S3에 저장
단순 결과 저장
Data Wrangler 자체는 미리보기/설계 도구이고, 실제 대규모 처리는 export된 Processing Job이 수행한다. flow(.flow 파일)는 변환 정의를 담은 청사진이고, 이를 재실행하면 새 데이터에도 같은 변환을 적용할 수 있어 재현성이 보장된다.
┌──> Processing Job ──> 전체 데이터에 변환 적용
│
[.flow 청사진] ─────┼──> Feature Store ───> 학습·추론이 같은 특성 공유
│
├──> Pipelines ───────> 자동 재학습 단계로 편입
│
└──> Python/Notebook ─> 코드로 추출해 직접 관리
Data Wrangler → Feature Store → Pipelines로 이어지는 흐름은 MLOps의 "feature pipeline"을 구현한 것이다. 데이터 준비를 일회성 노트북 작업이 아니라 버전 관리되고 재실행 가능한 파이프라인 단계로 만들면, 학습 시점과 추론 시점에 동일한 변환이 적용된다(training/serving skew 방지). 이는 Day 3의 Feature Store 일관성과 직결된다.
[.flow 파일] ← 변환 정의(청사진). 버전 관리 대상
│ export
v
[Processing Job] ← 전체 데이터에 실제 적용
│ 출력
v
[Feature Store] ← 학습·추론이 함께 읽는 저장소
│
└─> [Pipelines] 단계로 편입되면 재학습 때마다 같은 변환이 자동 적용
이 계보가 끊기는 지점이 곧 skew가 생기는 지점이다.
계보가 끊기는 방식
결과
flow를 export하지 않고 노트북에 손으로 옮김
순서·파라미터가 미묘하게 달라짐
추론 서버가 전처리를 따로 구현
training/serving skew
변환 정의를 버전 관리하지 않음
과거 모델을 재현 불가
Processing Job 결과를 임시 경로에 저장
어떤 데이터로 학습했는지 추적 불가
"Data Wrangler로 전처리했다"는 말만으로는 재현성이 보장되지 않는다. flow를 export해 파이프라인 단계로 고정해야 비로소 학습·추론이 같은 변환을 쓴다.