데이터베이스 — 4강: NoSQL·클라우드 DB·데이터 웨어하우스

NoSQL 데이터베이스

NoSQL (Not Only SQL):
→ 관계형 DB의 한계를 극복하기 위해 등장
→ 비정형·반정형 데이터·수평 확장·유연한 스키마
→ BASE 특성:
  Basically Available (기본적 가용성)
  Soft State (유연한 상태)
  Eventually Consistent (최종 일관성)

NoSQL 유형:

1. 문서 저장소 (Document Store):
→ JSON·BSON·XML 문서 단위 저장
→ 스키마 없음 (Schema-free)·중첩 구조 가능
→ MongoDB: 가장 대표적
  컬렉션 → 문서 → 필드
  인덱스·애그리게이션 파이프라인
  샤딩·레플리카셋으로 수평 확장
→ CouchDB·Firestore·DocumentDB

2. 키-값 저장소 (Key-Value Store):
→ 고유 키로 값 접근 (해시 테이블)
→ 매우 빠른 읽기·쓰기·단순 구조
→ Redis:
  인메모리·마이크로초 응답
  문자열·리스트·집합·해시·정렬 집합 자료구조
  TTL·퍼시스턴스·Pub/Sub·Lua 스크립팅
  세션 저장·캐시·랭킹·실시간 카운터
→ DynamoDB·Riak·Memcached

3. 컬럼 패밀리 저장소 (Column-family):
→ 컬럼을 그룹화하여 저장
→ 희소 데이터에 효율적
→ Cassandra:
  애플·넷플릭스·인스타그램 사용
  쓰기 최적화·분산·고가용성
  CQL (Cassandra Query Language)
  파티션 키로 데이터 분산
→ HBase: Hadoop 기반·HDFS 위

4. 그래프 데이터베이스 (Graph):
→ 노드(개체)·엣지(관계)·속성
→ 복잡한 관계 탐색 (소셜 네트워크·추천·사기 탐지)
→ Neo4j: Cypher 쿼리 언어
  MATCH (a:Person)-[:KNOWS]->(b:Person)
→ Amazon Neptune·JanusGraph

SQL vs NoSQL 비교:
→ SQL: ACID·조인·스키마 강제·수직 확장
→ NoSQL: BASE·유연한 스키마·수평 확장·특화
→ NewSQL: SQL의 ACID + NoSQL의 확장성 (CockroachDB·YugabyteDB)

---

클라우드 데이터베이스

클라우드 DB 종류:
→ IaaS 방식: 가상 서버에 직접 DB 설치 (EC2 + PostgreSQL)
→ DBaaS (Database as a Service): 완전 관리형
  패치·백업·복제·모니터링 클라우드가 담당

AWS 데이터베이스 서비스:
→ RDS (Relational Database Service):
  MySQL·PostgreSQL·MariaDB·Oracle·SQL Server
  Multi-AZ 고가용성·자동 백업·스냅샷
  Read Replica: 읽기 부하 분산
→ Aurora:
  MySQL·PostgreSQL 호환·5배 빠른 MySQL·3배 빠른 PostgreSQL 수준
  Aurora Serverless: 자동 용량 조정
→ DynamoDB:
  완전 관리형 NoSQL·키-값+문서
  싱글 밀리초 지연·자동 확장
  온디맨드·프로비저닝 용량 모드
→ Redshift: 데이터 웨어하우스·열 지향 저장
→ ElastiCache: Redis·Memcached 관리형 캐시

GCP 데이터베이스:
→ Cloud SQL: MySQL·PostgreSQL·SQL Server 관리형
→ Cloud Spanner: 전 세계 분산·강한 일관성·SQL
  금융·글로벌 서비스에 최적
→ Bigtable: HBase 호환·페타바이트 규모
→ BigQuery: 서버리스 데이터 웨어하우스

Azure 데이터베이스:
→ Azure SQL Database: SQL Server 관리형
→ Cosmos DB: 다중 모델 (SQL·MongoDB·Cassandra·Gremlin)
  전 세계 복제·5가지 일관성 수준 선택

데이터베이스 마이그레이션:
→ DMS (Database Migration Service): 온프레미스 → 클라우드
→ CDC (Change Data Capture): 실시간 변경 사항 캡처
→ 동종 이전 (MySQL→MySQL) vs 이기종 이전 (Oracle→PostgreSQL)
→ Schema Conversion Tool: 스키마·코드 자동 변환

---

데이터 웨어하우스와 레이크

OLTP vs OLAP:
→ OLTP (Online Transaction Processing):
  짧고 빈번한 트랜잭션·행 지향 저장
  현재 데이터·수정 많음
  사례: 쇼핑몰 주문·은행 계좌
→ OLAP (Online Analytical Processing):
  복잡한 집계 쿼리·열 지향 저장
  과거 데이터·읽기 집중
  사례: 매출 분석·사용자 행동 분석

데이터 웨어하우스 (Data Warehouse):
→ 여러 소스 데이터 통합·분석용 중앙 저장소
→ 구조: 소스 시스템 → ETL → 스테이징 → DWH → 데이터 마트

데이터 모델링:
→ 스타 스키마 (Star Schema):
  중앙 팩트 테이블 + 차원 테이블
  단순·이해 쉬움·조인 적음
→ 스노우플레이크 스키마:
  차원 테이블이 정규화되어 계층 구조
  공간 절약·조인 많음

ETL vs ELT:
→ ETL (Extract·Transform·Load):
  소스에서 추출 → 변환 → 적재
  전통적·변환 중간 단계
→ ELT (Extract·Load·Transform):
  소스에서 추출 → 적재 → 변환 (웨어하우스 내)
  클라우드 DWH·빅쿼리·Snowflake 방식
  빠른 적재·유연한 변환

데이터 레이크 (Data Lake):
→ 원시 데이터를 그대로 저장 (정형·반정형·비정형)
→ 스키마-on-리드: 조회 시 스키마 적용
→ vs 웨어하우스: 저비용·유연성·모든 데이터 타입
→ AWS S3 + Glue·Azure Data Lake·GCS
→ 레이크하우스 (Lakehouse): 레이크 + 웨어하우스 통합
  Delta Lake (Databricks)·Apache Iceberg·Apache Hudi

현대 데이터 스택:
→ Ingestion: Fivetran·Airbyte·Kafka
→ Storage: Snowflake·BigQuery·Redshift·Databricks
→ Transform: dbt (data build tool)
→ Orchestration: Airflow·Prefect·Dagster
→ BI·시각화: Tableau·Looker·Metabase·Superset

데이터 메시 (Data Mesh):
→ 도메인 소유 분산 데이터 아키텍처
→ 중앙 집중식 웨어하우스 한계 극복
→ 팀별 데이터 제품(Data Product) 책임

---

데이터 거버넌스와 품질

데이터 거버넌스 (Data Governance):
→ 데이터의 가용성·사용 가능성·무결성·보안 관리 체계
→ 정책·프로세스·조직·도구로 구성

메타데이터 관리:
→ 기술 메타데이터: 테이블 구조·데이터 타입·크기
→ 비즈니스 메타데이터: 데이터 의미·출처·소유자
→ 운영 메타데이터: 수집 시간·처리 로그·사용 현황
→ 데이터 카탈로그 (Data Catalog): 메타데이터 중앙 관리
  Apache Atlas·Amundsen·DataHub

데이터 리니지 (Data Lineage):
→ 데이터 출처와 변환 과정 추적
→ 감사·규제 준수·문제 원인 파악
→ Apache Atlas·OpenLineage

데이터 품질 차원:
→ 정확성 (Accuracy): 실제 값과 일치
→ 완전성 (Completeness): 누락 없음
→ 일관성 (Consistency): 여러 시스템 간 동일
→ 적시성 (Timeliness): 필요 시점에 사용 가능
→ 유일성 (Uniqueness): 중복 없음
→ 타당성 (Validity): 정의된 형식·범위 준수

개인정보 보호:
→ GDPR (EU 일반 데이터 보호 규정):
  데이터 최소화·목적 제한·삭제권
→ 한국 개인정보보호법·신용정보법
→ 데이터 익명화: 삭제·마스킹·일반화·교란
→ 차등 프라이버시 (Differential Privacy): 수학적 프라이버시 보장
  Apple·Google·미국 통계국 활용

규제 준수 (Compliance):
→ SOX (사베인스-옥슬리): 재무 데이터 감사
→ HIPAA: 의료 정보 보호 (미국)
→ PCI-DSS: 결제 카드 데이터 보안
→ 한국: 전자금융거래법·의료법·통신비밀보호법

---

자주 묻는 질문

Q. 프로젝트에 SQL과 NoSQL 중 어떤 것을 선택해야 하나요? A. 데이터의 특성과 요구사항에 따라 달라집니다. SQL(관계형 DB)이 적합한 경우는 데이터 간 복잡한 관계(조인)가 많고, 강한 일관성(ACID)이 필수적이며(금융·결제·예약), 스키마가 잘 정의되어 있고 자주 바뀌지 않을 때입니다. 반면 NoSQL이 적합한 경우는 수평 확장이 필요할 때(수백만~수억 건), 스키마가 유연하게 바뀌거나 다양한 형태의 데이터를 다룰 때(소셜 미디어·IoT 로그·카탈로그), 특정 접근 패턴(키로만 조회, 그래프 탐색)에 최적화가 필요할 때입니다. 현실에서는 하나의 서비스가 SQL과 NoSQL을 병행 사용하는 경우가 많습니다. 예를 들어 사용자 계정은 PostgreSQL, 세션은 Redis, 상품 카탈로그는 MongoDB, 활동 로그는 Cassandra를 쓰는 식입니다.

Q. 데이터 레이크와 데이터 웨어하우스의 실질적 차이는 무엇인가요? A. 비유하면, 데이터 웨어하우스는 잘 정리된 도서관(분류·색인 완비)이고, 데이터 레이크는 모든 원서를 그대로 쌓아 두는 창고입니다. 웨어하우스는 사전에 스키마를 정의하고 정제된 데이터만 적재(Schema-on-Write)하여 BI 도구로 빠르게 분석할 수 있습니다. 반면 레이크는 원시 데이터를 그대로 저장하여 나중에 필요할 때 스키마를 적용(Schema-on-Read)합니다. 저비용이고 데이터 과학자가 원시 데이터를 자유롭게 탐색할 수 있습니다. 단, 레이크는 잘 관리하지 않으면 ‘데이터 늪(Data Swamp)‘이 되어 아무도 어떤 데이터가 어디 있는지 모르는 상황이 됩니다. 최근에는 두 장점을 합친 ‘레이크하우스(Lakehouse)’ 아키텍처가 주목받고 있습니다.