Day 3 - Glue Studio와 DataBrew: 코드 없이 변환하기

Glue Studio: 박스를 끌어 ETL 파이프라인을 그린다

어제의 Glue ETL Job은 강력하지만 PySpark 코드를 직접 짜야 한다. 모든 데이터 작업자가 Spark에 능숙한 건 아니다. 데이터 분석가, 데이터 과학자, 비즈니스 사용자도 데이터를 정제하고 변환해야 한다. AWS는 이 간극을 메우려고 두 개의 비주얼/노코드 도구를 제공한다 — Glue Studio(비주얼 ETL)와 Glue DataBrew(비주얼 데이터 정제). 둘은 비슷해 보이지만 목적이 다르다. 이 차이를 구분하는 것이 시험 범위에 든다.

Glue Studio는 Glue ETL Job을 드래그 앤 드롭 그래프로 만드는 비주얼 인터페이스다. 노드(박스)를 캔버스에 놓고 연결하면, Studio가 뒤에서 해당하는 PySpark/Scala 코드를 자동 생성한다. 즉 결과물은 어제 배운 Glue ETL Job과 동일하다 — 다만 코드를 손으로 쓰는 대신 그래프로 설계할 뿐이다.

[Source: Catalog table]
        ↓
[Transform: Filter (amount > 0)]
        ↓
[Transform: Join with customers]
        ↓
[Transform: ApplyMapping]
        ↓
[Target: S3 Parquet]

노드는 크게 세 종류다.

Glue Studio의 강력한 점은 코드로 넘어갈 출구가 있다는 것이다. 비주얼로 시작했다가 특정 노드만 커스텀 코드로 바꾸거나, 전체를 스크립트 편집기로 열어 직접 수정할 수 있다(단, 스크립트를 직접 편집해 저장한 Job은 스크립트 전용이 되어 비주얼 편집기로 되돌릴 수 없다). 즉 "노코드로 시작 → 필요하면 코드로 정밀 제어"가 가능하다. 생성되는 것은 결국 DPU로 과금되는 Spark Job이다.

# Studio가 자동 생성하는 코드의 일부 (Filter 노드)
filtered = Filter.apply(
    frame=source_node,
    f=lambda row: row["amount"] > 0
)

비주얼 ETL은 새로운 발상이 아니다. Informatica, Talend, SSIS 같은 전통 ETL 도구가 수십 년간 "데이터 플로우를 그래프로 그린다"는 패러다임을 정립했다. Glue Studio는 이 검증된 패러다임을 서버리스 Spark 위에 올린 것이다. 그래프(DAG)로 표현하면 데이터 계보(lineage)가 시각적으로 드러나고, 변환 순서를 한눈에 검증할 수 있다는 본질적 장점이 있다.

Glue DataBrew: 변환이 아니라 "정제와 프로파일링"

DataBrew는 결이 다르다. Studio가 "ETL 파이프라인 구축 도구"라면, DataBrew는 데이터 분석가를 위한 시각적 데이터 준비(data preparation) 도구다. 250개 이상의 사전 정의된 변환을 클릭으로 적용하고, 결과를 즉시 미리보기하며, 데이터 품질을 프로파일링한다. PySpark는 물론 어떤 코드도 작성하지 않는다.

DataBrew의 핵심 개념은 세 가지다.

샘플 데이터 미리보기에서:
1. "phone" 컬럼의 결측값 → "UNKNOWN"으로 채우기  (클릭)
2. "email" 컬럼 소문자 변환                        (클릭)
3. "date" 컬럼을 표준 날짜 형식으로 파싱           (클릭)
   → 이 3단계가 Recipe로 저장됨
   → Recipe Job이 전체 데이터셋(수억 행)에 적용

분석가는 샘플(예: 처음 500행)로 변환을 대화식으로 만들고 결과를 즉시 확인한 뒤, 그 Recipe를 전체 데이터에 일괄 적용한다. 이 "샘플로 설계 → 전체에 적용" 흐름이 DataBrew의 핵심 가치다.

DataBrew의 데이터 프로파일링 기능은 단순 정제 이상이다. 프로파일 Job을 돌리면 컬럼별 통계(고유값 수, 결측 비율, 최소/최대, 분포, 상관관계, 이상치)를 자동으로 산출하고 시각화한다. 데이터를 변환하기 전에 "이 데이터가 얼마나 더러운가"를 먼저 진단하는 단계다. 또 DataBrew는 PII 자동 탐지도 지원해, 개인정보로 의심되는 컬럼을 표시하고 마스킹·해시 변환을 클릭으로 적용할 수 있다.

Studio vs DataBrew: 언제 무엇을?

시험에서 헷갈리기 쉬운 부분이다. 핵심 기준은 사용자와 목적이다.

직관적으로: 운영 ETL 파이프라인을 짜는 엔지니어라면 Studio, 데이터를 빠르게 들여다보고 정리하려는 분석가라면 DataBrew다. DataBrew는 즉각적 피드백과 프로파일링에 강하고, Studio는 복잡한 분산 변환과 파이프라인 통합에 강하다.

⚠️ 함정: "노코드 데이터 정제, 즉시 미리보기, 프로파일링"이 나오면 DataBrew, "비주얼 ETL Job, 코드 생성, 프로덕션 파이프라인"이 나오면 Studio다. 둘 다 "Glue"이고 "비주얼"이라 헷갈리기 쉽다. 또 하나, DataBrew Recipe Job도 실행 시 비용이 발생하며(노드/세션 시간 기반), "무료 노코드"가 아니다.

비용과 실행 모델

Glue Studio Job은 결국 Spark Job이므로 DPU × 실행 시간으로 과금된다. DataBrew는 (1) 대화식 세션 시간(프로젝트를 열어 작업하는 시간)과 (2) Recipe/Profile Job 실행 노드 시간으로 과금된다. 둘 다 서버리스라 클러스터를 띄울 필요는 없지만, 공짜는 아니다.

🎯 시나리오: 마케팅 분석가가 고객 CSV를 받았는데 전화번호 형식이 제각각이고 결측값이 많다. 분석 전에 정제가 필요하지만 그는 코드를 모른다. 구성은 (1) DataBrew에서 CSV를 Dataset으로 등록 → (2) Project를 열어 샘플로 결측값 채우기·형식 표준화·PII 마스킹을 클릭으로 적용하고 즉시 확인 → (3) 이 단계들을 Recipe로 저장 → (4) Recipe Job으로 전체 데이터에 적용해 정제본을 S3에 저장 → (5) 정제본을 Athena/QuickSight로 분석. 엔지니어 없이 분석가 혼자 완결한다.

Glue Studio를 더 정확히: 실행 엔진이 아니라 저작 화면

Studio를 "별도의 ETL 서비스"로 이해하면 문제를 틀린다. Studio는 Glue Job을 만드는 화면이고, 어떤 방식으로 만들든 실행되는 것은 Day 2의 Glue Job이다. 따라서 워커 유형, Auto Scaling, Flex, Job 북마크, 트리거·워크플로가 그대로 적용된다.

• 비주얼 → 스크립트는 일방통행이다. 스크립트 편집을 선택해 저장하면 그 Job은 영구히 스크립트 전용이 된다. 그래서 소스·변환·타깃 구성은 비주얼에서 끝낸 뒤, 마지막에 스크립트로 넘어가는 순서가 권장된다.
• 비주얼을 유지하면서 코드를 넣는 방법은 커스텀 코드 노드나 SQL 쿼리 노드다. 그래프의 한 칸만 코드로 채우므로 나머지는 계속 비주얼로 고칠 수 있다.
• 데이터 품질 검사도 노드로 넣는다. 내일 다룰 Glue Data Quality 평가를 비주얼 그래프 중간에 끼워, 통과한 데이터만 타깃으로 보내는 흐름을 그릴 수 있다.

DataBrew의 동작 모델: 샘플 → Recipe → Job

DataBrew가 수억 행 데이터에서도 클릭 즉시 미리보기를 보여 주는 이유는 화면에서 다루는 것이 샘플이기 때문이다.

• 프로젝트는 데이터셋(원본에 대한 읽기 전용 연결)과 Recipe의 조합이다. 화면에 보이는 것은 데이터셋의 샘플이며, 기본은 처음 500행이다. "처음 n행" 또는 "무작위 행"을 고를 수 있고 크기는 최대 5,000행까지다.
• 샘플을 키우면 원본을 더 잘 대표하지만 세션 시작과 미리보기가 느려진다.
• Recipe는 작업 중 자동 저장되고, 게시(publish)하면 버전이 생긴다. Job은 게시된 버전을 실행한다.
• Job은 두 종류다.

• Job은 여러 노드에서 병렬로 실행된다(기본 5개, 상한을 설정으로 조정). 스케줄을 붙여 주기적으로 돌릴 수 있어, 분석가가 만든 정제 단계를 매일 자동 적용하는 운영도 가능하다.
• Profile Job에는 데이터 품질 규칙을 붙여 프로파일링과 함께 검증할 수 있다.

⚠️ 함정: 샘플에서 깨끗했다고 전체가 깨끗한 것은 아니다. "처음 500행"에는 파일 뒤쪽에만 있는 형식 오류나 드문 이상값이 잡히지 않는다. Recipe를 설계하기 전에 Profile Job으로 전체 분포를 먼저 보거나, 무작위 샘플로 바꿔 확인한다. Recipe Job을 돌린 뒤 결과를 다시 프로파일링하는 것까지가 한 사이클이다.

과금 단위로 보는 차이

닮은 기능 구분하기

시나리오 판별: 단서 읽기

"노코드"라는 단서만으로 DataBrew를 고르지 말고, 누가 무엇을 위해 쓰는지를 한 번 더 본다. Studio 비주얼 Job도 코드를 쓰지 않고 만들 수 있다. 엔지니어가 운영 파이프라인을 코드 없이 그리는 것이면 Studio, 분석가가 데이터를 들여다보며 정리하는 것이면 DataBrew다. 반대로 "즉시 미리보기"와 "프로파일링"은 DataBrew 쪽으로만 기우는 단서다.

내일은 변환된 데이터의 스키마를 관리하고 품질을 보장하는 Schema Registry와 Glue Data Quality로 들어간다.

📖 용어

• Glue Studio : Glue ETL Job을 비주얼 그래프, 스크립트, 노트북으로 만드는 저작 화면. 실행되는 것은 일반 Glue Job이다.
• DataBrew : 코드 없이 클릭으로 데이터를 정제·프로파일링하는 시각적 데이터 준비 도구.
• Dataset : DataBrew가 다룰 원본 데이터에 대한 읽기 전용 연결 정의.
• Project : 샘플 데이터를 보며 변환을 하나씩 시도해 보는 DataBrew의 작업 공간.
• Recipe : 적용한 변환 단계를 순서대로 적어 둔 목록. 게시하면 버전이 생기고 다른 데이터에 재사용할 수 있다.
• Recipe Job : 게시된 Recipe를 샘플이 아닌 데이터셋 전체에 적용해 결과를 출력하는 실행.
• 프로파일링 : 컬럼별 결측률, 고유값 수, 분포, 상관관계 같은 통계를 뽑아 데이터 상태를 진단하는 일.
• PII : 이름·전화번호·이메일처럼 개인을 식별할 수 있는 정보.
• 인터랙티브 세션 : 화면에서 결과를 바로 확인하며 작업하도록 띄워 두는 실행 환경. 떠 있는 시간만큼 과금된다.
• 데이터 계보(lineage) : 데이터가 어디서 와서 어떤 변환을 거쳐 어디로 갔는지의 경로.