Theory
Session 1AWS Data Platform입문

Data Platform 개요 & 아키텍처

데이터 플랫폼의 진화, 데이터 레이크/웨어하우스/레이크하우스의 차이, AWS 데이터 서비스 전체 맵을 학습합니다.

학습 목표

  • 데이터 플랫폼의 역사적 진화 과정을 설명할 수 있다
  • 데이터 레이크, 웨어하우스, 레이크하우스의 차이점과 적합한 사용 사례를 구분할 수 있다
  • AWS 데이터 서비스의 역할과 상호 관계를 이해한다
  • Modern Data Stack의 구성 요소와 ELT 패턴을 설명할 수 있다
  • 산업별 데이터 플랫폼 아키텍처의 특징을 이해한다
  • 데이터 플랫폼 비용 최적화 전략을 적용할 수 있다

1. 데이터 플랫폼의 진화

"데이터는 21세기의 석유다. 하지만 석유와 달리 데이터는 정제하고 분석할수록 그 가치가 기하급수적으로 증가한다."

— Clive Humby, 데이터 과학자

1.1 데이터 플랫폼이란?

데이터 플랫폼(Data Platform)은 조직의 데이터를 수집, 저장, 처리, 분석하기 위한 통합된 기술 인프라입니다. 단순히 데이터베이스 하나를 운영하는 것이 아니라, 다양한 소스에서 발생하는 데이터를 효율적으로 관리하고 비즈니스 가치를 창출하는 전체 생태계를 의미합니다.

데이터 플랫폼의 핵심 구성 요소

수집 (Ingestion)

다양한 소스에서 데이터를 가져오는 파이프라인. 배치와 실시간 처리를 모두 지원해야 합니다.

저장 (Storage)

원시 데이터부터 정제된 데이터까지 효율적으로 저장하는 계층화된 스토리지 시스템.

처리 (Processing)

ETL/ELT 파이프라인을 통한 데이터 변환, 정제, 집계 작업을 수행합니다.

분석 (Analytics)

BI 도구, SQL 쿼리, ML 모델을 통해 데이터에서 인사이트를 도출합니다.

1.2 데이터 플랫폼의 역사적 진화

1

1990년대: 데이터 웨어하우스 시대

Teradata, Oracle, IBM DB2 등 전통적인 데이터 웨어하우스가 등장했습니다. 구조화된 데이터를 중앙 집중식으로 저장하고 OLAP 분석을 수행했습니다.

Star SchemaETLOLAP Cube
2

2000년대 후반: 빅데이터 혁명

Google의 MapReduce 논문(2004)과 Hadoop의 등장으로 대용량 비정형 데이터 처리가 가능해졌습니다. 데이터 레이크 개념이 탄생했습니다.

HadoopMapReduceHDFSHive
3

2010년대: 클라우드 데이터 플랫폼

AWS, GCP, Azure의 클라우드 서비스가 데이터 플랫폼을 혁신했습니다. 서버리스, 관리형 서비스로 운영 부담이 크게 줄었습니다.

RedshiftBigQuerySnowflakeSpark
4

2020년대: 레이크하우스 & AI 통합

데이터 레이크와 웨어하우스의 장점을 결합한 레이크하우스 아키텍처가 부상했습니다. 실시간 분석, ML/AI 통합이 핵심 요구사항이 되었습니다.

Delta LakeIcebergHudidbt

1.3 왜 AWS 데이터 플랫폼인가?

AWS는 가장 성숙하고 포괄적인 클라우드 데이터 서비스 포트폴리오를 제공합니다. 2006년 S3 출시 이후 지속적으로 데이터 서비스를 확장해왔으며, 현재 전 세계 클라우드 데이터 플랫폼 시장의 약 32%를 점유하고 있습니다.

AWS 데이터 플랫폼의 강점

완전한 서비스 스택

수집부터 분석까지 모든 단계를 커버하는 네이티브 서비스를 제공합니다.

  • • 15+ 데이터 분석 서비스
  • • 8+ 데이터베이스 서비스
  • • 완전한 ML/AI 통합

검증된 확장성

Netflix, Airbnb, Lyft 등 세계 최대 규모의 데이터 워크로드를 처리합니다.

  • • 엑사바이트 규모 저장
  • • 초당 수백만 이벤트 처리
  • • 글로벌 분산 아키텍처

비용 효율성

서버리스, 온디맨드 가격 모델로 실제 사용량만큼만 비용을 지불합니다.

  • • S3 Intelligent-Tiering
  • • Redshift Serverless
  • • Athena 쿼리당 과금

1.4 현대 데이터 플랫폼의 핵심 트렌드

ELT > ETL

클라우드 웨어하우스의 강력한 컴퓨팅 파워로 변환을 저장 후에 수행하는 ELT 패턴이 주류가 되었습니다.

실시간 분석

배치 처리에서 스트리밍 처리로 전환. 이벤트 발생 즉시 분석하고 대응하는 것이 경쟁력이 되었습니다.

데이터 메시

중앙 집중식에서 도메인 중심의 분산 데이터 소유권으로 전환. 각 팀이 자신의 데이터 제품을 책임집니다.

DataOps

DevOps 원칙을 데이터 파이프라인에 적용. CI/CD, 버전 관리, 자동화된 테스트가 필수가 되었습니다.

데이터 거버넌스

GDPR, CCPA 등 규제 강화로 데이터 계보, 품질 관리, 접근 제어가 핵심 요구사항이 되었습니다.

AI/ML 통합

데이터 플랫폼과 ML 플랫폼의 경계가 흐려지고 있습니다. Feature Store, MLOps가 데이터 플랫폼의 일부가 되었습니다.

2. 데이터 레이크 vs 데이터 웨어하우스 vs 레이크하우스

현대 데이터 아키텍처를 이해하려면 세 가지 핵심 패러다임의 차이점과 각각의 적합한 사용 사례를 명확히 알아야 합니다. 이 세 가지는 상호 배타적이 아니라 상호 보완적이며, 많은 조직이 하이브리드 접근 방식을 채택하고 있습니다.

2.1 데이터 웨어하우스 (Data Warehouse)

데이터 웨어하우스의 특징

데이터 웨어하우스는 구조화된 데이터를 위한 중앙 집중식 저장소입니다. 사전에 정의된 스키마(Schema-on-Write)를 사용하며, 비즈니스 인텔리전스(BI)와 보고서 생성에 최적화되어 있습니다.

핵심 특징

  • 스키마 온 라이트: 데이터 적재 전 스키마 정의 필수
  • ACID 트랜잭션: 데이터 일관성 보장
  • SQL 기반: 표준 SQL로 쿼리
  • 컬럼 기반 저장: 분석 쿼리에 최적화
  • 높은 쿼리 성능: 인덱스, 파티셔닝 지원

적합한 사용 사례

  • • 정형화된 비즈니스 보고서
  • • 대시보드 및 KPI 모니터링
  • • 재무/회계 분석
  • • 규제 준수 보고
  • • 예측 가능한 쿼리 패턴

// 데이터 웨어하우스 스키마 예시 (Star Schema)

-- 팩트 테이블: 주문
CREATE TABLE fact_orders (
    order_id        BIGINT PRIMARY KEY,
    customer_key    INT REFERENCES dim_customer(customer_key),
    product_key     INT REFERENCES dim_product(product_key),
    date_key        INT REFERENCES dim_date(date_key),
    quantity        INT,
    unit_price      DECIMAL(10,2),
    total_amount    DECIMAL(12,2),
    discount_amount DECIMAL(10,2)
) DISTKEY(customer_key) SORTKEY(date_key);

-- 디멘션 테이블: 고객
CREATE TABLE dim_customer (
    customer_key    INT PRIMARY KEY,
    customer_id     VARCHAR(50),
    name            VARCHAR(100),
    email           VARCHAR(100),
    segment         VARCHAR(50),  -- Gold, Silver, Bronze
    region          VARCHAR(50),
    created_at      TIMESTAMP,
    -- SCD Type 2 컬럼
    effective_from  DATE,
    effective_to    DATE,
    is_current      BOOLEAN
);

2.2 데이터 레이크 (Data Lake)

데이터 레이크의 특징

데이터 레이크는 모든 형태의 데이터를 원시 형태로 저장하는 중앙 저장소입니다. 스키마 온 리드(Schema-on-Read) 방식으로, 데이터를 읽을 때 스키마를 적용합니다. 유연성이 높지만 관리가 어려울 수 있습니다.

핵심 특징

  • 스키마 온 리드: 저장 시 스키마 불필요
  • 모든 데이터 타입: 정형/반정형/비정형
  • 저비용 스토리지: 객체 스토리지 기반
  • 무제한 확장: 페타바이트 규모 저장
  • 원시 데이터 보존: 원본 그대로 저장

적합한 사용 사례

  • • 머신러닝 학습 데이터
  • • 로그 및 이벤트 데이터 저장
  • • IoT 센서 데이터
  • • 이미지/비디오/오디오 저장
  • • 탐색적 데이터 분석(EDA)

// 데이터 레이크 구조 예시 (S3)

s3://my-data-lake/
├── raw/                          # 원시 데이터 (Bronze)
│   ├── orders/
│   │   └── year=2024/month=01/day=15/
│   │       └── orders_20240115_001.json
│   ├── clickstream/
│   │   └── dt=2024-01-15/
│   │       └── events_*.parquet
│   └── images/
│       └── product_images/
│           └── *.jpg
│
├── processed/                    # 정제된 데이터 (Silver)
│   ├── orders_cleaned/
│   │   └── year=2024/month=01/
│   │       └── part-*.parquet
│   └── user_sessions/
│       └── dt=2024-01-15/
│           └── sessions.parquet
│
└── curated/                      # 분석용 데이터 (Gold)
    ├── daily_sales_summary/
    │   └── date=2024-01-15/
    │       └── summary.parquet
    └── customer_360/
        └── snapshot_date=2024-01-15/
            └── customer_profiles.parquet
데이터 레이크의 함정: 데이터 늪(Data Swamp)

적절한 거버넌스 없이 데이터 레이크를 운영하면 "데이터 늪"이 됩니다. 데이터는 있지만 찾을 수 없고, 신뢰할 수 없으며, 활용할 수 없는 상태가 됩니다.

데이터 늪의 증상

  • • 메타데이터 부재로 데이터 의미 파악 불가
  • • 중복 데이터 난립
  • • 데이터 품질 검증 없음
  • • 접근 권한 관리 부재
  • • 데이터 계보(Lineage) 추적 불가

예방 방법

  • • AWS Glue Data Catalog 활용
  • • Lake Formation으로 권한 관리
  • • 데이터 품질 규칙 정의
  • • 명확한 네이밍 컨벤션
  • • 자동화된 데이터 프로파일링

2.3 레이크하우스 (Lakehouse)

레이크하우스: 두 세계의 장점을 결합

레이크하우스는 데이터 레이크의 유연성과 저비용에 데이터 웨어하우스의ACID 트랜잭션과 성능을 결합한 아키텍처입니다. Delta Lake, Apache Iceberg, Apache Hudi 같은 오픈 테이블 포맷이 이를 가능하게 합니다.

레이크하우스의 핵심 기능

ACID 트랜잭션

데이터 레이크 위에서 트랜잭션 보장. 동시 읽기/쓰기 충돌 방지.

스키마 진화

기존 데이터를 재작성하지 않고 스키마 변경 가능.

타임 트래블

특정 시점의 데이터 스냅샷 조회. 감사 및 롤백 지원.

Upsert/Merge

CDC 패턴 지원. 변경된 데이터만 효율적으로 업데이트.

통합 배치/스트리밍

같은 테이블에 배치와 스트리밍 데이터 동시 처리.

오픈 포맷

벤더 종속 없이 다양한 엔진에서 접근 가능.

// Apache Iceberg 테이블 예시 (AWS Glue + Athena)

-- Iceberg 테이블 생성
CREATE TABLE my_catalog.my_database.orders (
    order_id        BIGINT,
    customer_id     STRING,
    order_date      DATE,
    total_amount    DECIMAL(12,2),
    status          STRING,
    updated_at      TIMESTAMP
)
PARTITIONED BY (days(order_date))
LOCATION 's3://my-lakehouse/orders/'
TBLPROPERTIES (
    'table_type' = 'ICEBERG',
    'format' = 'parquet',
    'write_compression' = 'zstd'
);

-- MERGE (Upsert) 작업
MERGE INTO orders t
USING orders_updates s
ON t.order_id = s.order_id
WHEN MATCHED THEN
    UPDATE SET status = s.status, updated_at = s.updated_at
WHEN NOT MATCHED THEN
    INSERT (order_id, customer_id, order_date, total_amount, status, updated_at)
    VALUES (s.order_id, s.customer_id, s.order_date, s.total_amount, s.status, s.updated_at);

-- 타임 트래블: 1시간 전 데이터 조회
SELECT * FROM orders FOR SYSTEM_TIME AS OF (current_timestamp - interval '1' hour);

-- 스냅샷 히스토리 조회
SELECT * FROM my_catalog.my_database."orders$snapshots";

2.4 세 가지 아키텍처 비교

특성데이터 웨어하우스데이터 레이크레이크하우스
데이터 타입정형 데이터만모든 타입모든 타입
스키마Schema-on-WriteSchema-on-Read둘 다 지원
ACID 트랜잭션
스토리지 비용높음 ($$$)낮음 ($)낮음 ($)
쿼리 성능매우 빠름느림~보통빠름
ML/AI 지원제한적우수우수
실시간 처리제한적지원우수
AWS 서비스RedshiftS3 + Glue + AthenaS3 + Iceberg + Athena

2.5 실무 권장 아키텍처

현대적 하이브리드 접근법

대부분의 조직에서는 단일 아키텍처가 아닌 하이브리드 접근법이 최적입니다. 데이터 특성과 사용 사례에 따라 적절한 저장소를 선택합니다.

Bronze (원시)

S3에 원본 그대로 저장. 데이터 손실 방지, 재처리 가능.

Silver (정제)

Iceberg 테이블로 정제. 중복 제거, 스키마 적용, 품질 검증.

Gold (분석)

비즈니스 로직 적용. 집계, 조인, 파생 지표 계산 완료.

3. AWS 데이터 서비스 전체 맵

AWS는 데이터 파이프라인의 모든 단계를 커버하는 포괄적인 서비스 포트폴리오를 제공합니다. 각 서비스의 역할과 적합한 사용 사례를 이해하면 최적의 아키텍처를 설계할 수 있습니다.

3.1 데이터 수집 (Ingestion) 서비스

데이터 수집 서비스
KDS

Kinesis Data Streams

실시간 데이터 스트리밍 서비스. 초당 수백만 레코드 처리 가능.

사용 사례: 클릭스트림, IoT 센서, 로그 실시간 처리

특징: 샤드 기반 확장, 24시간~365일 보존

KDF

Kinesis Data Firehose

완전 관리형 데이터 전송 서비스. S3, Redshift, OpenSearch로 자동 전송.

사용 사례: 로그 수집, 분석 데이터 적재

특징: 자동 스케일링, 변환 지원, 배치 처리

DMS

Database Migration Service

데이터베이스 마이그레이션 및 복제 서비스. CDC(Change Data Capture) 지원.

사용 사례: DB 마이그레이션, 실시간 복제, CDC

특징: 이기종 DB 지원, 최소 다운타임

MSK

Amazon MSK

완전 관리형 Apache Kafka 서비스. 기존 Kafka 워크로드 마이그레이션에 적합.

사용 사례: 이벤트 스트리밍, 마이크로서비스 통신

특징: Kafka 호환, 자동 복구, 암호화

AF

Amazon AppFlow

SaaS 애플리케이션과 AWS 서비스 간 데이터 통합. 코드 없이 설정 가능.

사용 사례: Salesforce, Slack, ServiceNow 데이터 수집

특징: 50+ 커넥터, 스케줄/이벤트 트리거

TF

AWS Transfer Family

SFTP, FTPS, FTP 프로토콜로 S3/EFS에 파일 전송. 레거시 시스템 연동.

사용 사례: B2B 파일 교환, 레거시 통합

특징: 기존 인증 시스템 연동, 관리형

3.2 데이터 저장 (Storage) 서비스

데이터 저장 서비스
S3

Amazon S3

핵심

무제한 확장 가능한 객체 스토리지. 데이터 레이크의 기반.

스토리지 클래스: Standard, IA, Glacier, Deep Archive

특징: 99.999999999% 내구성, 버전 관리, 수명 주기

GC

Glue Data Catalog

중앙 집중식 메타데이터 저장소. Hive Metastore 호환.

사용 사례: 테이블 정의, 스키마 관리, 파티션 관리

특징: Athena, Redshift Spectrum, EMR과 통합

LF

Lake Formation

데이터 레이크 구축 및 관리 서비스. 세분화된 접근 제어.

사용 사례: 데이터 레이크 거버넌스, 권한 관리

특징: 행/열 수준 보안, 태그 기반 접근 제어

DDB

DynamoDB

완전 관리형 NoSQL 데이터베이스. 밀리초 지연 시간.

사용 사례: 실시간 조회, 세션 저장, 메타데이터

특징: 자동 스케일링, 글로벌 테이블, Streams

3.3 데이터 처리 (Processing) 서비스

데이터 처리 서비스
Glue

AWS Glue

핵심

서버리스 ETL 서비스. Apache Spark 기반.

구성 요소: Crawler, Job, Workflow, Data Quality

특징: 서버리스, 자동 스키마 추론, 북마크

EMR

Amazon EMR

관리형 빅데이터 플랫폼. Spark, Hive, Presto, Flink 지원.

사용 사례: 대규모 배치 처리, ML 학습

특징: EC2/EKS/Serverless 옵션, 스팟 인스턴스

KDA

Kinesis Data Analytics

실시간 스트림 분석. Apache Flink 기반.

사용 사례: 실시간 집계, 이상 탐지, 윈도우 분석

특징: SQL/Flink 지원, 자동 스케일링

λ

AWS Lambda

서버리스 컴퓨팅. 이벤트 기반 데이터 처리.

사용 사례: 경량 변환, 트리거 기반 처리

특징: 15분 제한, S3/Kinesis 트리거

SF

Step Functions

서버리스 워크플로우 오케스트레이션.

사용 사례: ETL 파이프라인 조율, 에러 핸들링

특징: 시각적 워크플로우, 재시도 로직

MWAA

MWAA (Airflow)

관리형 Apache Airflow. 복잡한 데이터 파이프라인 스케줄링.

사용 사례: DAG 기반 워크플로우, 의존성 관리

특징: Python 기반, 풍부한 오퍼레이터

3.4 데이터 분석 (Analytics) 서비스

데이터 분석 서비스
RS

Amazon Redshift

핵심

페타바이트 규모 클라우드 데이터 웨어하우스.

특징: 컬럼 기반, MPP, Spectrum으로 S3 쿼리

옵션: Provisioned, Serverless, RA3 노드

ATH

Amazon Athena

핵심

서버리스 대화형 쿼리 서비스. S3 데이터 직접 분석.

특징: 스캔한 데이터만 과금, Presto/Trino 기반

지원: Parquet, ORC, JSON, CSV, Iceberg

QS

Amazon QuickSight

클라우드 네이티브 BI 서비스. ML 기반 인사이트.

특징: SPICE 인메모리 엔진, Q (자연어 쿼리)

연동: Redshift, Athena, RDS, S3

OS

Amazon OpenSearch

검색 및 로그 분석 서비스. Elasticsearch 호환.

사용 사례: 로그 분석, 전문 검색, 실시간 대시보드

특징: Kibana 대시보드, 서버리스 옵션

3.5 거버넌스 & 보안 서비스

거버넌스 및 보안 서비스

Lake Formation

세분화된 접근 제어, 데이터 공유, 태그 기반 보안

Glue Data Quality

데이터 품질 규칙 정의 및 자동 검증

DataZone

데이터 카탈로그, 검색, 공유를 위한 데이터 포털

Macie

ML 기반 민감 데이터 자동 탐지 (PII, 금융 정보)

KMS

암호화 키 관리, S3/Redshift/Glue 암호화

CloudTrail

API 호출 감사 로그, 규정 준수 증적

4. Modern Data Stack 아키텍처

Modern Data Stack(MDS)은 클라우드 네이티브, 모듈화된 도구들의 조합으로 데이터 파이프라인을 구축하는 현대적 접근 방식입니다. 각 계층에서 최적의 도구를 선택하고 조합할 수 있는 유연성이 핵심입니다.

4.1 Modern Data Stack의 특징

☁️

클라우드 네이티브

SaaS 기반, 인프라 관리 최소화

🧩

모듈화

Best-of-breed 도구 조합

📊

ELT 패턴

웨어하우스에서 변환 수행

🔄

버전 관리

Git 기반 DataOps

4.2 Modern Data Stack 레이어

4.3 AWS 기반 Modern Data Stack 구성

AWS 네이티브 Modern Data Stack
수집
Firehose + DMS
저장
S3 + Iceberg
처리
Glue + dbt
분석
Athena
시각화
QuickSight

Option A: 서버리스 중심

  • Kinesis Firehose → S3
  • Glue ETL (Serverless)
  • Athena + Iceberg
  • QuickSight

적합: 가변적 워크로드, 비용 최적화 우선

Option B: 웨어하우스 중심

  • DMS + AppFlow → S3
  • Redshift COPY
  • dbt on Redshift
  • Tableau / Looker

적합: 복잡한 조인, 높은 동시성 쿼리

4.4 dbt (Data Build Tool) 소개

dbt는 Modern Data Stack의 핵심 도구로, SQL 기반의 데이터 변환을 소프트웨어 엔지니어링 베스트 프랙티스(버전 관리, 테스트, 문서화)와 결합합니다.

// dbt 모델 예시: 일별 매출 집계

-- models/marts/daily_sales.sql
{{ config(
    materialized='incremental',
    unique_key='sale_date',
    partition_by={'field': 'sale_date', 'data_type': 'date'}
) }}

WITH orders AS (
    SELECT * FROM {{ ref('stg_orders') }}
    {% if is_incremental() %}
    WHERE order_date > (SELECT MAX(sale_date) FROM {{ this }})
    {% endif %}
),

order_items AS (
    SELECT * FROM {{ ref('stg_order_items') }}
),

daily_aggregation AS (
    SELECT
        DATE(o.order_date) AS sale_date,
        COUNT(DISTINCT o.order_id) AS total_orders,
        COUNT(DISTINCT o.customer_id) AS unique_customers,
        SUM(oi.quantity) AS total_items_sold,
        SUM(oi.quantity * oi.unit_price) AS gross_revenue,
        SUM(oi.discount_amount) AS total_discounts,
        SUM(oi.quantity * oi.unit_price - oi.discount_amount) AS net_revenue
    FROM orders o
    JOIN order_items oi ON o.order_id = oi.order_id
    GROUP BY 1
)

SELECT
    sale_date,
    total_orders,
    unique_customers,
    total_items_sold,
    gross_revenue,
    total_discounts,
    net_revenue,
    net_revenue / NULLIF(total_orders, 0) AS avg_order_value,
    CURRENT_TIMESTAMP AS updated_at
FROM daily_aggregation

ref() 함수

모델 간 의존성 자동 관리. DAG 자동 생성.

Incremental

변경된 데이터만 처리. 대용량 테이블 효율적 업데이트.

테스트 & 문서화

스키마 테스트, 데이터 품질 검증, 자동 문서 생성.

4.5 ETL vs ELT 패러다임

ETL (Extract-Transform-Load)

Source → [Transform Engine] → Warehouse
         (Glue, Spark)
         
• 변환 후 적재
• 별도 컴퓨팅 리소스 필요
• 복잡한 변환에 적합
  • • 데이터 품질 검증 후 적재
  • • 스토리지 비용 절감
  • • 민감 데이터 마스킹 가능

ELT (Extract-Load-Transform)

Source → Warehouse → [Transform in DW]
                     (dbt, SQL)
         
• 적재 후 변환
• 웨어하우스 컴퓨팅 활용
• 빠른 데이터 가용성
  • • 원시 데이터 보존
  • • 변환 로직 변경 용이
  • • 클라우드 DW에 최적화

💡 현대적 권장: ELT + 레이크하우스

S3에 원시 데이터를 먼저 적재(Bronze)하고, Glue/dbt로 변환하여 정제된 데이터(Silver/Gold)를 생성합니다. 원본 보존과 유연한 변환이 모두 가능합니다.

5. 산업별 데이터 플랫폼 아키텍처

데이터 플랫폼의 설계는 산업 특성에 따라 크게 달라집니다. 각 산업의 데이터 특성, 규제 요구사항, 분석 패턴을 이해하면 최적의 아키텍처를 설계할 수 있습니다.

5.1 이커머스 / 리테일

이커머스 데이터 플랫폼

핵심 데이터

  • • 클릭스트림 / 사용자 행동 로그
  • • 주문 및 결제 트랜잭션
  • • 상품 카탈로그 및 재고
  • • 고객 프로필 및 세그먼트
  • • 리뷰 및 평점 데이터

주요 분석 사례

  • • 실시간 개인화 추천
  • • 장바구니 이탈 분석
  • • 고객 생애 가치(CLV) 예측
  • • 수요 예측 및 재고 최적화
  • • A/B 테스트 분석

// 이커머스 데이터 플랫폼 아키텍처

┌─────────────────────────────────────────────────────────────────────┐
│                         데이터 소스                                   │
│  [웹/앱 클릭스트림] [주문 DB] [상품 DB] [CRM] [결제 시스템] [리뷰]    │
└─────────────────────────────────────────────────────────────────────┘
         │              │           │         │          │
         ▼              ▼           ▼         ▼          ▼
┌─────────────┐  ┌─────────────┐  ┌─────────────────────────────────┐
│   Kinesis   │  │     DMS     │  │           AppFlow               │
│  Firehose   │  │    (CDC)    │  │    (Salesforce, Zendesk)        │
└──────┬──────┘  └──────┬──────┘  └───────────────┬─────────────────┘
       │                │                         │
       └────────────────┼─────────────────────────┘
                        ▼
┌─────────────────────────────────────────────────────────────────────┐
│                    S3 Data Lake (Bronze)                             │
│  s3://ecommerce-lake/raw/clickstream/                               │
│  s3://ecommerce-lake/raw/orders/                                    │
│  s3://ecommerce-lake/raw/products/                                  │
└─────────────────────────────────────────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────────────────┐
│                    Glue ETL + dbt (Silver)                          │
│  • 클릭스트림 세션화  • 주문-상품 조인  • 고객 360 뷰 생성          │
└─────────────────────────────────────────────────────────────────────┘
                        │
          ┌─────────────┼─────────────┐
          ▼             ▼             ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│  Redshift   │ │   Athena    │ │ SageMaker   │
│ (BI 쿼리)   │ │ (Ad-hoc)    │ │ (추천 모델) │
└─────────────┘ └─────────────┘ └─────────────┘
          │             │             │
          └─────────────┼─────────────┘
                        ▼
┌─────────────────────────────────────────────────────────────────────┐
│  QuickSight (대시보드) │ Personalize (실시간 추천) │ 마케팅 자동화   │
└─────────────────────────────────────────────────────────────────────┘

5.2 금융 서비스

금융 데이터 플랫폼

핵심 데이터

  • • 거래 트랜잭션 (실시간)
  • • 시장 데이터 (주가, 환율)
  • • 고객 KYC/AML 정보
  • • 신용 평가 데이터
  • • 규제 보고 데이터

규제 요구사항

  • • 데이터 암호화 필수 (저장/전송)
  • • 감사 로그 장기 보존
  • • 데이터 거주지 규정 준수
  • • PCI-DSS, SOX 컴플라이언스
  • • 실시간 사기 탐지 필수

// 금융 데이터 플랫폼 - 보안 강화 아키텍처

┌─────────────────────────────────────────────────────────────────────┐
│                    보안 경계 (VPC + PrivateLink)                     │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │                     데이터 수집 계층                           │  │
│  │  [Core Banking] ──DMS──▶ [Kinesis] ◀── [Market Data Feed]    │  │
│  │        │                    │                                 │  │
│  │        ▼                    ▼                                 │  │
│  │  ┌─────────────────────────────────────────────────────────┐ │  │
│  │  │           S3 (SSE-KMS 암호화)                           │ │  │
│  │  │  • 버킷 정책으로 접근 제한                              │ │  │
│  │  │  • Object Lock으로 변경 방지                            │ │  │
│  │  │  • 버전 관리 활성화                                     │ │  │
│  │  └─────────────────────────────────────────────────────────┘ │  │
│  │                           │                                   │  │
│  │                           ▼                                   │  │
│  │  ┌─────────────────────────────────────────────────────────┐ │  │
│  │  │              Lake Formation                             │ │  │
│  │  │  • 행/열 수준 접근 제어                                 │ │  │
│  │  │  • 태그 기반 보안 정책                                  │ │  │
│  │  │  • 데이터 마스킹                                        │ │  │
│  │  └─────────────────────────────────────────────────────────┘ │  │
│  │                           │                                   │  │
│  │         ┌─────────────────┼─────────────────┐                │  │
│  │         ▼                 ▼                 ▼                │  │
│  │  ┌───────────┐     ┌───────────┐     ┌───────────┐          │  │
│  │  │ Redshift  │     │  Athena   │     │ SageMaker │          │  │
│  │  │(규제보고) │     │(Ad-hoc)   │     │(사기탐지) │          │  │
│  │  └───────────┘     └───────────┘     └───────────┘          │  │
│  └───────────────────────────────────────────────────────────────┘  │
│                                                                      │
│  [CloudTrail] ──▶ [S3 감사 로그] ──▶ [7년 보존]                     │
│  [Macie] ──▶ [PII 자동 탐지] ──▶ [알림]                             │
└─────────────────────────────────────────────────────────────────────┘

5.3 헬스케어

헬스케어 데이터 플랫폼

핵심 데이터

  • • 전자의무기록 (EMR/EHR)
  • • 의료 영상 (DICOM)
  • • 웨어러블 디바이스 데이터
  • • 유전체 데이터
  • • 청구 및 보험 데이터

주요 분석 사례

  • • 질병 예측 및 조기 진단
  • • 의료 영상 AI 분석
  • • 약물 상호작용 분석
  • • 임상 시험 데이터 분석
  • • 인구 건강 관리

⚠️ HIPAA 컴플라이언스 필수

  • • PHI(Protected Health Information) 암호화 필수
  • • BAA(Business Associate Agreement) 체결 필요
  • • 접근 로그 6년 보존
  • • 최소 권한 원칙 적용

// 헬스케어 데이터 레이크 - HIPAA 준수

┌─────────────────────────────────────────────────────────────────────┐
│                    AWS HealthLake (FHIR 저장소)                      │
│  • HL7 FHIR R4 표준 지원                                            │
│  • 자동 PHI 탐지 및 마스킹                                          │
│  • 자연어 처리 내장                                                  │
└─────────────────────────────────────────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────────────────┐
│                    S3 (의료 영상 저장)                               │
│  • DICOM 이미지 저장                                                │
│  • Intelligent-Tiering (접근 빈도 기반)                             │
│  • Cross-Region Replication (재해 복구)                             │
└─────────────────────────────────────────────────────────────────────┘
                        │
          ┌─────────────┼─────────────┐
          ▼             ▼             ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ SageMaker   │ │ Comprehend  │ │   Athena    │
│ (영상 AI)   │ │Medical(NLP) │ │ (분석)      │
└─────────────┘ └─────────────┘ └─────────────┘

5.4 게임

게임 데이터 플랫폼

핵심 데이터

  • • 플레이어 행동 이벤트 (초당 수백만)
  • • 인앱 구매 트랜잭션
  • • 매치메이킹 데이터
  • • 치트 탐지 로그
  • • 서버 성능 메트릭

주요 분석 사례

  • • 실시간 플레이어 세그먼테이션
  • • 이탈 예측 및 리텐션 분석
  • • 게임 밸런스 분석
  • • A/B 테스트 (게임 메카닉)
  • • 실시간 치트 탐지

// 게임 분석 플랫폼 - 대용량 실시간 처리

┌─────────────────────────────────────────────────────────────────────┐
│                    게임 클라이언트/서버                               │
│  [모바일 앱] [PC 클라이언트] [게임 서버] [매치메이킹 서버]           │
└─────────────────────────────────────────────────────────────────────┘
                        │
                        ▼ (초당 100만+ 이벤트)
┌─────────────────────────────────────────────────────────────────────┐
│                    Kinesis Data Streams                              │
│  • 샤드 자동 스케일링                                               │
│  • 24시간 보존 (재처리 가능)                                        │
└─────────────────────────────────────────────────────────────────────┘
         │                              │
         ▼                              ▼
┌─────────────────────┐      ┌─────────────────────┐
│  Kinesis Analytics  │      │   Kinesis Firehose  │
│  (실시간 분석)      │      │   (S3 적재)         │
│  • 치트 탐지        │      │   • Parquet 변환    │
│  • 실시간 대시보드  │      │   • 파티셔닝        │
└─────────────────────┘      └─────────────────────┘
         │                              │
         ▼                              ▼
┌─────────────────────┐      ┌─────────────────────┐
│    OpenSearch       │      │    S3 Data Lake     │
│  (실시간 검색)      │      │  (배치 분석)        │
│  • 플레이어 검색    │      │                     │
│  • 로그 분석        │      │         │          │
└─────────────────────┘      │         ▼          │
                             │  ┌─────────────┐   │
                             │  │   Athena    │   │
                             │  │ (Ad-hoc)    │   │
                             │  └─────────────┘   │
                             └─────────────────────┘

6. 비용 최적화 전략

클라우드 데이터 플랫폼의 비용은 빠르게 증가할 수 있습니다. 설계 단계부터 비용을 고려하고, 지속적으로 모니터링하며 최적화해야 합니다.

6.1 주요 비용 요소

AWS 데이터 서비스 비용 구조
서비스과금 기준예상 비용 (월)최적화 포인트
S3저장량 + 요청 수$23/TB (Standard)Intelligent-Tiering, 수명 주기
Athena스캔한 데이터량$5/TB 스캔Parquet, 파티셔닝, 컬럼 선택
Redshift ServerlessRPU-시간$0.36/RPU-시간기본 용량 설정, 유휴 시간 관리
Glue ETLDPU-시간$0.44/DPU-시간Auto Scaling, Job Bookmark
Kinesis Data Streams샤드-시간 + PUT$0.015/샤드-시간온디맨드 모드, 적정 샤드 수
Kinesis Firehose수집 데이터량$0.029/GB압축, 배치 크기 최적화

6.2 S3 비용 최적화

Intelligent-Tiering

접근 패턴에 따라 자동으로 스토리지 클래스 전환

  • • 자주 접근: Standard 티어
  • • 30일 미접근: Infrequent Access
  • • 90일 미접근: Archive Instant
  • • 180일 미접근: Deep Archive

수명 주기 정책

규칙 기반 자동 전환 및 삭제

{
  "Rules": [{
    "ID": "ArchiveOldData",
    "Filter": {"Prefix": "raw/"},
    "Transitions": [
      {"Days": 30, "StorageClass": "STANDARD_IA"},
      {"Days": 90, "StorageClass": "GLACIER"}
    ],
    "Expiration": {"Days": 365}
  }]
}

💡 S3 비용 절감 체크리스트

  • ✅ 불필요한 버전 삭제 (버전 관리 활성화 시)
  • ✅ 불완전한 멀티파트 업로드 정리
  • ✅ 압축 포맷 사용 (Parquet + Snappy/ZSTD)
  • ✅ S3 Analytics로 접근 패턴 분석
  • ✅ 리전 간 복제 필요성 재검토

6.3 Athena 비용 최적화

Athena는 스캔한 데이터량에 따라 과금됩니다. 데이터 포맷과 쿼리 최적화로 비용을 90% 이상 절감할 수 있습니다.

// 비용 최적화 전후 비교

-- ❌ 비효율적인 쿼리 (CSV, 파티션 없음)
-- 스캔: 1TB → 비용: $5.00
SELECT * FROM orders_csv WHERE order_date = '2024-01-15';

-- ✅ 최적화된 쿼리 (Parquet, 파티션, 컬럼 선택)
-- 스캔: 10GB → 비용: $0.05 (99% 절감!)
SELECT order_id, customer_id, total_amount 
FROM orders_parquet 
WHERE year = 2024 AND month = 1 AND day = 15;

1. Parquet 포맷

컬럼 기반 저장으로 필요한 컬럼만 스캔. CSV 대비 80-90% 절감.

2. 파티셔닝

날짜/지역 등으로 파티션. WHERE 조건으로 스캔 범위 제한.

3. 컬럼 선택

SELECT * 대신 필요한 컬럼만 명시. 불필요한 스캔 방지.

6.4 비용 모니터링

비용 알림 설정

// AWS Budgets 설정 예시

{
  "BudgetName": "DataPlatform-Monthly",
  "BudgetLimit": {
    "Amount": "5000",
    "Unit": "USD"
  },
  "BudgetType": "COST",
  "CostFilters": {
    "Service": [
      "Amazon Simple Storage Service",
      "Amazon Athena",
      "Amazon Redshift",
      "AWS Glue"
    ]
  },
  "NotificationsWithSubscribers": [
    {
      "Notification": {
        "NotificationType": "ACTUAL",
        "ComparisonOperator": "GREATER_THAN",
        "Threshold": 80
      },
      "Subscribers": [
        {"SubscriptionType": "EMAIL", "Address": "data-team@company.com"}
      ]
    }
  ]
}

Cost Explorer 활용

  • • 서비스별 비용 추이 분석
  • • 태그별 비용 할당
  • • 이상 비용 탐지
  • • 예측 비용 확인

태그 전략

  • • Environment: dev/staging/prod
  • • Project: 프로젝트명
  • • Team: 담당 팀
  • • CostCenter: 비용 센터

7. 정리 및 다음 세션 예고

7.1 핵심 요약

데이터 플랫폼의 진화

데이터 웨어하우스 → 데이터 레이크 → 레이크하우스로 진화. 현대적 아키텍처는 유연성과 성능을 모두 제공합니다.

세 가지 아키텍처 패턴

웨어하우스: 정형 데이터, 고성능 BI |레이크: 모든 데이터, ML/AI |레이크하우스: 두 장점 결합

AWS 데이터 서비스 스택

수집(Kinesis, DMS) → 저장(S3, Glue Catalog) → 처리(Glue, EMR) → 분석(Athena, Redshift) → 시각화(QuickSight)

Modern Data Stack

클라우드 네이티브, 모듈화, ELT 패턴, dbt 기반 변환이 핵심. 버전 관리와 DataOps 적용이 필수입니다.

비용 최적화

S3 Intelligent-Tiering, Parquet 포맷, 파티셔닝으로 90% 이상 비용 절감 가능. 지속적인 모니터링 필수.

7.2 핵심 용어 정리

Data Lake

모든 형태의 원시 데이터를 저장하는 중앙 저장소

Data Warehouse

구조화된 데이터를 위한 분석 최적화 저장소

Lakehouse

레이크의 유연성 + 웨어하우스의 ACID 트랜잭션

ETL vs ELT

변환 시점의 차이. ELT는 적재 후 웨어하우스에서 변환

Schema-on-Write

데이터 저장 전 스키마 정의 (웨어하우스)

Schema-on-Read

데이터 읽을 때 스키마 적용 (레이크)

Data Catalog

메타데이터 중앙 저장소 (Glue Data Catalog)

Bronze/Silver/Gold

데이터 품질 계층 (원시/정제/분석용)

7.3 다음 세션 예고

Session 2: 데이터 수집 (Ingestion)

다음 세션에서는 다양한 소스에서 데이터를 수집하는 방법을 깊이 있게 다룹니다.

Kinesis Data Streams vs Kinesis Firehose 선택 기준
DMS를 활용한 데이터베이스 CDC 구현
AppFlow로 SaaS 데이터 통합
배치 vs 실시간 수집 아키텍처 설계
데이터 수집 파이프라인 모니터링

7.4 추가 학습 자료

AWS 공식 문서

  • • AWS Analytics Services Overview
  • • Building Data Lakes on AWS
  • • AWS Well-Architected - Analytics Lens
  • • AWS Data Lab 워크샵

추천 도서

  • • Fundamentals of Data Engineering (O'Reilly)
  • • Data Pipelines Pocket Reference
  • • The Data Warehouse Toolkit (Kimball)
  • • Designing Data-Intensive Applications