icon

안동민 개발노트

1장 : 데이터베이스 소개

데이터베이스 시스템의 종류

데이터베이스 시스템은 데이터를 저장하고 관리하는 방식에 따라 여러 유형으로 나뉩니다. 어떤 시스템을 선택하느냐에 따라 개발 방식, 확장 전략, 성능 특성이 크게 달라집니다. 이 절에서는 각 유형의 특징과 내부 원리를 이해하고, 실무에서 올바른 선택을 할 수 있도록 깊이 있게 살펴봅니다.

데이터베이스 시스템 진화 흐름
1960s  계층형/네트워크형 DB (IMS, CODASYL)
  │
1970s  관계형 모델 (E.F. Codd 논문)
  │
1980s  상용 RDBMS 등장 (Oracle, DB2, SQL Server)
  │
1990s  객체지향 DB → 실패, 객체관계형으로 흡수
  │
2000s  NoSQL 등장 (BigTable, Dynamo 논문)
  │
2010s  NewSQL 등장 (Spanner), 클라우드 DB 대중화
  │
2020s  벡터 DB 부상 (AI/LLM), 서버리스 DB

데이터베이스의 역사는 더 많은 데이터를, 더 빠르게, 더 안정적으로라는 요구에 대한 응답의 역사입니다.

관계형 데이터베이스 (RDBMS)

관계형 데이터베이스는 데이터를 테이블(릴레이션)로 구조화합니다. 행(row)과 열(column)로 이루어진 표 형태이며, 테이블 간의 관계를 외래키로 연결합니다. SQL을 사용하여 데이터를 조작합니다.

1970년 에드거 커드(Edgar F. Codd)가 발표한 관계형 모델 논문이 기초가 되었으며, 이후 50년 넘게 데이터 관리의 주류 패러다임으로 자리 잡았습니다. 관계형 모델의 수학적 기반이 탄탄하고, SQL이라는 표준 언어로 다양한 DBMS에서 일관된 방식으로 데이터를 다룰 수 있기 때문입니다.

주요 RDBMS 비교

RDBMS특징적합한 사용처
Oracle엔터프라이즈급, 강력한 옵티마이저대기업, 금융, 공공기관
MySQL오픈소스, 웹 서비스에 널리 사용웹 애플리케이션, 스타트업
PostgreSQL오픈소스, 확장성, 표준 준수복잡한 쿼리, GIS, 분석
SQL ServerMicrosoft 생태계 통합.NET 기반 엔터프라이즈
SQLite파일 기반, 서버리스모바일 앱, 임베디드
MariaDBMySQL 포크, 커뮤니티 주도MySQL 대체, 클라우드

Oracle

Oracle은 엔터프라이즈 시장에서 가장 오랜 역사와 점유율을 가진 RDBMS입니다. 강력한 옵티마이저, 파티셔닝, RAC(Real Application Clusters)를 통한 고가용성, Exadata 같은 하드웨어 통합 솔루션이 특징입니다.

Oracle 핵심 특징
* 옵티마이저: 비용 기반(CBO), 히스토그램 활용
* 고가용성: RAC → 여러 서버가 하나의 DB 공유
* 파티셔닝: Range, Hash, List, Composite
* MVCC: Undo 세그먼트 기반 다중 버전 관리
* 라이선스: 상용 (프로세서당 / 사용자당 과금)
* PL/SQL: 절차적 확장 언어

MySQL

MySQL은 세계에서 가장 널리 사용되는 오픈소스 RDBMS입니다. 웹 애플리케이션의 표준 데이터베이스로, 기본적인 기능에서 충분한 성능을 제공하면서도 설치와 운영이 비교적 간단합니다. 현재 Oracle이 소유하고 있지만 오픈소스 라이선스를 유지합니다.

MySQL 핵심 특징
* 스토리지 엔진: InnoDB(기본, ACID), MyISAM(레거시)
* 복제: 비동기 복제, 그룹 복제, InnoDB Cluster
* JSON 지원: JSON 컬럼 타입, JSON 함수
* 풀텍스트 검색: InnoDB에서 지원
* 라이선스: GPL (커뮤니티) / 상용 (엔터프라이즈)

PostgreSQL

PostgreSQL은 세계에서 가장 진보된 오픈소스 관계형 데이터베이스를 표방합니다. SQL 표준을 가장 잘 준수하며, 사용자 정의 타입, 함수, 연산자, 인덱스를 만들 수 있는 확장성이 뛰어납니다.

PostgreSQL 핵심 특징
* 확장성: 사용자 정의 타입/함수/연산자/인덱스
* PostGIS: 지리 정보(GIS) 확장 → 위치 기반 서비스
* JSONB: 바이너리 JSON으로 인덱싱 가능
* 윈도우 함수, CTE, 래터럴 조인 등 고급 SQL 완벽 지원
* MVCC: 튜플 버전 관리 (Vacuum 필요)
* 논리적 복제, 테이블 파티셔닝

SQL Server와 SQLite

SQL Server는 Microsoft의 RDBMS로, .NET 프레임워크, Azure 클라우드와 자연스럽게 통합됩니다. T-SQL이라는 확장 SQL을 사용하며, SSMS(SQL Server Management Studio)라는 강력한 관리 도구를 제공합니다.

SQLite는 서버가 없는 내장형 데이터베이스입니다. 하나의 파일이 곧 데이터베이스이며, 별도 설치 없이 라이브러리 형태로 사용합니다. 안드로이드, iOS 앱의 로컬 저장소, 브라우저, IoT 디바이스 등에서 널리 사용됩니다.

SQLite 특징
* 파일 기반: 데이터베이스 = 하나의 .db 파일
* 제로 설정: 설치, 설정, 관리 불필요
* 동시성 제한: 쓰기 시 전체 DB 락 (WAL 모드로 일부 개선)
* 크기 제한: 최대 281TB (실무에서는 수 GB 미만 권장)
* 타입 시스템: 동적 타입 (Type Affinity)

RDBMS의 장단점

RDBMS 장점
* ACID 트랜잭션으로 데이터 정확성 보장
* SQL이라는 표준 언어로 학습 비용 낮음
* 정규화를 통한 데이터 중복 최소화
* 외래키, 제약조건으로 무결성 자동 검증
* 강력한 조인으로 복잡한 데이터 관계 표현
* 50년간 검증된 안정성
RDBMS 단점
* 수평 확장(Scale-out)이 어려움
* 스키마 변경이 비용이 큼 (ALTER TABLE → 테이블 재구성)
* 비정형 데이터(이미지, 로그, 문서) 저장에 비효율
* 초대용량(petabyte급)에서 성능 한계
* 수직 확장(Scale-up)에 의존 → 비용 증가

NoSQL 데이터베이스

NoSQL(Not Only SQL)은 관계형 모델을 따르지 않는 데이터베이스의 통칭입니다. 2000년대 후반 구글, 아마존, 페이스북 등이 관계형 데이터베이스로 처리하기 어려운 초대용량 데이터 문제에 직면하면서 등장했습니다.

NoSQL은 CAP 정리의 영향을 받았습니다. 분산 시스템에서 일관성(Consistency), 가용성(Availability), 파티션 허용(Partition Tolerance) 세 가지를 동시에 만족시킬 수 없다는 이론입니다. RDBMS가 일관성을 우선시한다면, 많은 NoSQL은 가용성이나 확장성을 우선시합니다.

CAP 정리
        Consistency (일관성)
           /\
          /  \
    CA   /    \   CP
        /  모두  \
       /   불가   \
      /____________\
  Availability      Partition
  (가용성)          Tolerance
                    (분할 허용)

CA: 전통적 RDBMS (단일 서버)
CP: MongoDB, HBase (일관성 + 분할 허용)
AP: Cassandra, DynamoDB (가용성 + 분할 허용)

Key-Value 스토어

가장 단순한 형태의 NoSQL입니다. 키로 값을 저장하고 조회합니다. 해시 테이블과 유사하며, 단순한 만큼 극도로 빠릅니다.

Key-Value 구조
┌──────────────┬──────────────────────┐
│     Key      │        Value         │
├──────────────┼──────────────────────┤
│ user:1       │{"name":"김","age":30}│
│ session:abc  │ {token, expiry, ...} │
│ cache:page:1 │ <HTML 캐시 데이터>   │
│ rank:game:1  │[("김",100),("이",90)]│
└──────────────┴──────────────────────┘
대표 제품과 특징
Redis:
  * 인메모리 → 읽기/쓰기 1ms 이하
  * 다양한 자료구조: String, Hash, List, Set, Sorted Set
  * Pub/Sub, Stream, Lua 스크립팅
  * 캐시, 세션, 실시간 랭킹, 메시지 큐

DynamoDB:
  * AWS 완전 관리형, 서버리스
  * 파티션 키 + 정렬 키 구조
  * 밀리초 지연 시간 보장
  * 글로벌 테이블(다중 리전 복제)

Key-Value 스토어는 복잡한 조건 검색이나 조인이 불가능합니다. 키를 아는 상태에서 빠르게 꺼내기에 최적화되어 있습니다.

Document 데이터베이스

Document DB는 JSON, BSON 같은 문서(Document)를 저장합니다. 스키마를 사전에 정의하지 않으며, 문서마다 다른 구조를 가질 수 있습니다. 문서 내부의 중첩된 필드에도 인덱스를 걸고 질의할 수 있습니다.

Document 구조 (MongoDB)
{
  "_id": ObjectId("64a1f2..."),
  "name": "김철수",
  "email": "kim@mail.com",
  "orders": [
    { "product": "노트북", "price": 1200000, "date": "2024-01-15" },
    { "product": "마우스", "price": 35000, "date": "2024-02-20" }
  ],
  "address": {
    "city": "서울",
    "district": "강남구",
    "zip": "06000"
  }
}
MongoDB 핵심 특징
* 스키마리스: 컬렉션 내 문서 구조 자유
* 집계 파이프라인: $match → $group → $sort → $project
* 샤딩: 샤드 키 기반 자동 수평 분산
* 복제 세트: Primary + Secondary (자동 장애 조치)
* 인덱스: 단일, 복합, 다중키, 텍스트, 지오스패셜
* 트랜잭션: 4.0부터 다중 문서 ACID 트랜잭션 지원

RDBMS에서는 주문 정보를 users, orders, order_items 세 테이블로 정규화하지만, Document DB에서는 하나의 문서에 중첩하여 저장합니다. 조인이 필요 없으므로 읽기가 빠르지만, 같은 데이터가 여러 문서에 중복 저장될 수 있습니다.

Column-Family 데이터베이스

Column-Family DB는 행(row)마다 다른 컬럼을 가질 수 있는 구조입니다. 같은 컬럼 패밀리에 속하는 데이터를 함께 저장하여, 특정 컬럼만 읽는 분석 쿼리에서 뛰어난 성능을 보입니다.

Column-Family 구조
Row Key │ Column Family: 기본정보     │ Column Family: 주문
────────┼─────────────────────────────┼──────────────────
user:1  │ name:"김" │ email:"k@m.com" │ order:1:상품:"노트북"
user:2  │ name:"이" │ phone:"010-..." │ order:1:상품:"키보드"
user:3  │ name:"박" │                 │
대표 제품
Cassandra:
  * 분산 아키텍처, 단일 장애점 없음(Masterless)
  * 쓰기 최적화: LSM-Tree 기반
  * 튜닝 가능한 일관성 수준 (ONE, QUORUM, ALL)
  * 링 구조 해시 파티셔닝
  * 적합: IoT 로그, 시계열 데이터, 대용량 쓰기

HBase:
  * Hadoop HDFS 위에 구축
  * 구글 Bigtable 오픈소스 구현
  * 강한 일관성 (Cassandra보다 읽기에 유리)
  * 적합: 대용량 랜덤 읽기/쓰기, 로그 분석

Graph 데이터베이스

Graph DB는 데이터를 노드(Node)와 엣지(Edge)로 표현합니다. 관계 자체를 일급 시민으로 취급하여, 복잡한 관계 탐색에서 RDBMS보다 수백 배 빠릅니다.

Graph 구조
(김철수)──[친구]──→(이영희)
   │                  │
 [구매]              [구매]
   │                  │
   ▼                  ▼
(노트북)            (노트북)
   │
 [카테고리]
   │
   ▼
(전자제품)
Neo4j Cypher 쿼리 예시
-- 김철수의 친구가 구매한 상품 추천
MATCH (user:Person {name: '김철수'})-[:친구]->(friend)-[:구매]->(product)
WHERE NOT (user)-[:구매]->(product)
RETURN product.name, COUNT(friend) AS 추천수
ORDER BY 추천수 DESC

-- RDBMS에서 같은 쿼리: 자기 조인 3번 + LEFT JOIN + 서브쿼리
-- → 성능 차이가 극심

Graph DB는 소셜 네트워크, 추천 엔진, 사기 탐지, 네트워크 관리, 지식 그래프에서 독보적인 성능을 보입니다. 하지만 대량 집계나 범위 검색에는 적합하지 않습니다.

NoSQL의 장단점

NoSQL 장점
* 수평 확장(Scale-out)이 용이
* 스키마 유연성 → 빠른 개발, 빠른 변경
* 대용량 데이터 처리에 적합
* 특정 패턴에 극도로 최적화된 성능
NoSQL 단점
* ACID 보장이 약하거나 제한적
* 조인 없음 → 데이터 중복 불가피
* SQL 수준의 풍부한 쿼리 불가
* 일관성 모델이 복잡 (최종 일관성)
* 제품마다 API가 달라 학습 비용

NewSQL

NewSQL은 관계형 데이터베이스의 ACID 속성을 유지하면서, NoSQL 수준의 수평 확장성을 제공하는 새로운 세대의 RDBMS입니다. 관계형 모델 + 분산 시스템의 장점을 결합하려는 접근입니다.

NewSQL의 핵심 아이디어
RDBMS의 강점        NoSQL의 강점         NewSQL
─────────────────  ─────────────────  ─────────────────
ACID 트랜잭션      수평 확장           ACID + 수평 확장
SQL 표준           높은 가용성         SQL + 고가용성
강한 일관성        분산 처리           분산 + 강한 일관성
시스템특징핵심 기술
Google Spanner글로벌 분산, 외부 일관성TrueTime API (원자시계)
CockroachDBSpanner 오픈소스 클론PostgreSQL 호환
TiDBMySQL 호환, 분산 처리Raft 합의 알고리즘
YugabyteDBPostgreSQL 호환Raft + 분산 트랜잭션
Amazon AuroraMySQL/PG 호환, 클라우드 네이티브스토리지 분리 아키텍처
VoltDB인메모리, 초저지연파티션별 직렬 실행

Google Spanner는 전 세계에 분산된 데이터 센터에서 강한 일관성을 보장하는 세계 최초의 시스템입니다. 원자시계와 GPS 수신기를 사용하여 전 세계의 시점을 동기화(TrueTime API)하고, 이를 기반으로 분산 트랜잭션을 처리합니다.

특수 목적 데이터베이스

범용 DBMS 외에도 특정 용도에 최적화된 데이터베이스들이 있습니다.

시계열 데이터베이스 (Time Series DB)

시간 순서로 발생하는 데이터를 저장하고 분석하는 데 특화되어 있습니다.

시계열 DB
InfluxDB:
  * 태그 기반 인덱싱
  * 다운샘플링, 연속 쿼리
  * IoT 센서, 서버 모니터링

TimescaleDB:
  * PostgreSQL 확장
  * SQL로 시계열 분석
  * 하이퍼테이블 자동 파티셔닝

Prometheus:
  * 풀(Pull) 방식 메트릭 수집
  * PromQL 쿼리 언어
  * Grafana와 연동

검색 엔진

대량의 텍스트 데이터에서 빠른 전문 검색(Full-text Search)을 제공합니다.

검색 엔진
Elasticsearch:
  * 역인덱스(Inverted Index) 기반
  * 분산 검색, 실시간 분석
  * REST API, Kibana 대시보드
  * 로그 분석(ELK 스택), 상품 검색

Apache Solr:
  * Lucene 기반, Elasticsearch와 동류
  * 기업용 검색에 강점

벡터 데이터베이스

AI/ML에서 임베딩(벡터)을 저장하고, 유사도 검색을 수행하는 DB입니다. LLM과 RAG(검색 증강 생성) 시스템의 핵심 구성 요소로 부상하고 있습니다.

벡터 DB
Pinecone, Milvus, Weaviate, Qdrant, Chroma

사용 예
1. 텍스트 → 임베딩 모델 → [0.12, -0.34, 0.56, ...] (1536차원 벡터)
2. 벡터 DB에 저장
3. 질의 텍스트 → 임베딩 → 유사한 벡터 검색 (코사인 유사도)
4. 가장 유사한 문서 반환

데이터베이스 선택 기준

선택 가이드
질문                                  → 추천
──────────────────────────────────────────────────
ACID 트랜잭션이 필수?                 → RDBMS
스키마가 자주 바뀜?                   → Document (MongoDB)
초고속 읽기/쓰기?                     → Key-Value (Redis)
대용량 쓰기 + 분석?                   → Column-Family (Cassandra)
복잡한 관계 탐색?                     → Graph (Neo4j)
ACID + 수평 확장 모두?                → NewSQL (CockroachDB)
시계열 데이터?                        → Time Series (InfluxDB)
전문 검색?                            → 검색 엔진 (Elasticsearch)
AI 유사도 검색?                       → 벡터 DB (Pinecone)

선택 시 고려 사항

기술 외적 요소
* 팀의 역량: SQL에 익숙하면 RDBMS/NewSQL이 안전
* 생태계: 라이브러리, 드라이버, 모니터링 도구 지원
* 비용: 오픈소스 vs 상용, 클라우드 vs 온프레미스
* 운영 부담: 관리형 서비스(RDS, Atlas) vs 직접 운영
* 데이터 규모: GB → RDBMS 충분, PB → NoSQL/NewSQL 고려
* 일관성 요구: 강한 일관성(금융) vs 최종 일관성(SNS)

폴리글랏 퍼시스턴스 (Polyglot Persistence)

실무에서는 하나의 데이터베이스만 사용하는 경우가 드뭅니다. 각 데이터의 특성에 맞는 최적의 데이터베이스를 조합하여 사용하는 것을 폴리글랏 퍼시스턴스라 합니다.

전자상거래 폴리글랏 퍼시스턴스 예시
┌──────────────────────────────────────────────────┐
│              전자상거래 시스템                   │
├────────────┬──────────────┬──────────────────────┤
│ 주문/결제  │ 사용자 세션  │ 상품 검색            │
│ PostgreSQL │ Redis        │ Elasticsearch        │
│ (ACID)     │ (초고속 R/W) │ (전문 검색)          │
├────────────┼──────────────┼──────────────────────┤
│상품 카탈로그│ 추천 엔진    │ 클릭 로그           │
│ MongoDB    │ Neo4j        │ Cassandra            │
│(유연 스키마)│ (관계 탐색)  │ (대용량 쓰기)       │
└────────────┴──────────────┴──────────────────────┘

폴리글랏 퍼시스턴스의 핵심은 하나의 도구로 모든 문제를 풀지 않는다는 원칙입니다. 각 데이터베이스의 강점을 활용하되, 시스템 복잡성이 증가하는 트레이드오프를 감수해야 합니다.

폴리글랏 퍼시스턴스의 과제
* 데이터 동기화: 여러 DB 간 데이터 일관성 유지
* 트랜잭션: 분산 트랜잭션 또는 Saga 패턴 필요
* 운영 복잡성: 여러 DB의 모니터링, 백업, 장애 대응
* 인력: 각 DB 전문가 또는 관리형 서비스 활용

클라우드 데이터베이스 서비스

클라우드 환경에서는 DBMS를 직접 설치하고 관리하는 대신, 클라우드 제공자가 관리하는 완전 관리형 서비스를 사용할 수 있습니다. 인프라 관리 부담이 줄어들고, 탄력적 확장이 가능합니다.

주요 클라우드 DB 서비스
┌────────────┬──────────────────────┬───────────────────────┐
│   제공자   │        관계형        │ NoSQL                 │
├────────────┼──────────────────────┼───────────────────────┤
│    AWS     │ RDS, Aurora          │ DynamoDB, ElastiCache │
│    GCP     │ Cloud SQL, Spanner   │ Firestore, Bigtable   │
│ Azure      │ SQL Database         │ CosmosDB              │
├────────────┼──────────────────────┴───────────────────────┤
│ 공통 특징   │ 자동 백업, 자동 장애 조치, 모니터링 내장    │
│            │ 읽기 복제본 자동 생성, 보안 패치 자동 적용   │
└────────────┴──────────────────────────────────────────────┘

Amazon Aurora는 MySQL/PostgreSQL 호환이면서 스토리지를 분리하여 최대 128TB까지 자동 확장하고, 읽기 복제본을 15개까지 생성할 수 있습니다. Azure CosmosDB는 다중 모델(Document, Key-Value, Graph, Column-Family)을 하나의 서비스로 제공하며, 글로벌 분산과 5가지 일관성 수준을 지원합니다.

데이터베이스 아키텍처 패턴

데이터베이스를 배치하는 방식도 시스템 설계의 중요한 결정입니다.

배치 아키텍처
1. 중앙 집중식 (Centralized)
   하나의 서버에 모든 데이터 저장
   장점: 단순, 일관성 보장 용이
   단점: 단일 장애점, 확장 한계

2. 클라이언트-서버 (Client-Server)
   서버가 데이터 관리, 클라이언트가 요청
   장점: 역할 분리, 여러 클라이언트 지원
   단점: 서버 병목 가능

3. 분산 데이터베이스 (Distributed)
   여러 서버에 데이터 분산 저장
   장점: 확장성, 고가용성, 지역 지연 감소
   단점: 일관성 유지 복잡, 분산 트랜잭션 비용

4. 복제 (Replication)
   동일 데이터를 여러 서버에 복사
   Primary-Replica: 쓰기는 Primary, 읽기는 Replica
   장점: 읽기 성능 향상, 장애 복구
   단점: 복제 지연(Replication Lag)

5. 샤딩 (Sharding)
   데이터를 분할하여 여러 서버에 나눠 저장
   예: user_id % 4 → 4개 샤드에 분배
   장점: 수평 확장
   단점: 크로스 샤드 조인 불가, 리밸런싱 복잡

데이터베이스 시스템 전체 정리

DB 유형별 요약
┌──────────────────┬────────────────────┬─────────────────────┐
│       유형       │ 핵심 특징          │ 대표 제품           │
├──────────────────┼────────────────────┼─────────────────────┤
│ RDBMS            │ ACID, SQL, 정규화  │ Oracle, MySQL, PG   │
│ Key-Value NoSQL  │ 초고속, 단순       │ Redis, DynamoDB     │
│ Document NoSQL   │ 유연 스키마, JSON  │ MongoDB             │
│ Column NoSQL     │ 대용량 쓰기/분석   │ Cassandra, HBase    │
│ Graph NoSQL      │ 관계 탐색 특화     │ Neo4j               │
│ NewSQL           │ ACID + 수평 확장   │ Spanner, CockroachDB│
│ Time Series      │ 시계열 데이터      │ InfluxDB, Prometheus│
│ Search Engine    │ 전문 검색          │ Elasticsearch       │
│ Vector DB        │ AI 유사도 검색     │ Pinecone, Milvus    │
└──────────────────┴────────────────────┴─────────────────────┘

핵심 선택 원칙
  1. 데이터 특성에 따라 적합한 유형 선택
  2. ACID가 필수이면 RDBMS 또는 NewSQL
  3. 확장성이 필수이면 NoSQL 또는 NewSQL
  4. 실무에서는 폴리글랏 퍼시스턴스가 일반적
  5. 클라우드 관리형 서비스로 운영 부담 최소화

다음 장에서는 관계형 데이터베이스의 핵심 이론인 관계형 데이터 모델을 다루겠습니다.

DBMS의 구조와 기능

이전 페이지

릴레이션의 개념

다음 페이지

목차

관계형 데이터베이스 (RDBMS)
주요 RDBMS 비교
Oracle
MySQL
PostgreSQL
SQL Server와 SQLite
RDBMS의 장단점
NoSQL 데이터베이스
Key-Value 스토어
Document 데이터베이스
Column-Family 데이터베이스
Graph 데이터베이스
NoSQL의 장단점
NewSQL
특수 목적 데이터베이스
시계열 데이터베이스 (Time Series DB)
검색 엔진
벡터 데이터베이스
데이터베이스 선택 기준
선택 시 고려 사항
폴리글랏 퍼시스턴스 (Polyglot Persistence)
클라우드 데이터베이스 서비스
데이터베이스 아키텍처 패턴
데이터베이스 시스템 전체 정리