안동민 개발노트 아이콘

안동민 개발노트

1장 : 데이터베이스 소개

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

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

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

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

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

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

주요 RDBMS 비교

아래 표는 제품의 고정된 용도를 정리한 것이 아니라, 자주 언급되는 강점과 선택 맥락을 학습용으로 단순화한 것입니다. 실제 선택은 버전, 운영 환경, 팀 역량, 비용, 클라우드 서비스 구성에 따라 달라집니다.

RDBMS특징적합한 사용처
Oracle엔터프라이즈 운영 기능, 질의 최적화대규모 조직, 엄격한 운영 환경
MySQL오픈소스 생태계, 웹 서비스 활용 사례웹 애플리케이션, 범용 서비스
PostgreSQL오픈소스, 확장 기능, 표준 SQL 지향정형 데이터 + 확장 요구
SQL ServerMicrosoft 생태계 통합.NET 기반 엔터프라이즈
SQLite파일 기반, 서버리스모바일 앱, 임베디드
MariaDBMySQL 포크, 커뮤니티 주도MySQL 대체, 클라우드

Oracle

Oracle은 엔터프라이즈 환경에서 오래 사용되어 온 RDBMS로, 고가용성, 파티셔닝, 운영 도구, 질의 최적화 기능이 중요한 조직에서 자주 검토됩니다. 다만 라이선스 비용, 운영 복잡성, 전문 인력 의존도도 함께 고려해야 합니다.

MySQL

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

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

PostgreSQL

PostgreSQL은 SQL 표준 지원과 확장 기능을 강점으로 내세우는 오픈소스 RDBMS입니다. 사용자 정의 타입, 함수, 연산자, 인덱스, 확장 모듈을 통해 관계형 모델 위에서 다양한 요구를 처리할 수 있지만, 확장 기능을 많이 쓸수록 설계와 운영 관리가 중요해집니다.

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이라는 표준 언어로 관계형 데이터를 표현하기 좋음
* 정규화를 통해 데이터 중복을 줄이기 좋음
* 외래키, CHECK, UNIQUE 같은 제약 조건으로 잘못된 상태를 줄일 수 있음
* 조인으로 복잡한 데이터 관계를 표현할 수 있지만 성능은 스키마, 인덱스, 질의 패턴에 좌우됨
* 오래 검증된 모델이지만 모든 워크로드에서 자동으로 최선은 아님

NoSQL 데이터베이스

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

NoSQL은 CAP 정리의 영향을 받았습니다. 분산 시스템에서 일관성(Consistency), 가용성(Availability), 파티션 허용(Partition Tolerance) 세 가지를 동시에 만족시킬 수 없다는 이론입니다. 많은 분산 NoSQL 설계는 워크로드에 따라 일관성, 가용성, 확장성 사이의 균형점을 선택합니다.

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

CA: 단일 노드처럼 네트워크 파티션을 전제로 하지 않는 구성
CP: 파티션 상황에서 일관성 쪽을 우선하는 분산 구성
AP: 파티션 상황에서 가용성 쪽을 우선하는 분산 구성

CAP 분류는 제품의 절대 속성이라기보다, 분산 구성에서 어떤 보장을 우선하도록 설계·설정했는지를 설명하는 단순화된 관점입니다.

Key-Value 스토어

가장 단순한 형태의 NoSQL입니다. 키로 값을 저장하고 조회합니다. 해시 테이블과 유사한 방식으로 키 기반 단건 조회에 빠르지만, 장점은 키를 알고 있다는 전제에서 가장 크게 나타납니다.

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"
  }
}

RDBMS에서는 주문 정보를 여러 테이블로 정규화하는 경우가 많지만, Document DB에서는 함께 조회되는 데이터를 하나의 문서에 중첩해 저장할 수 있습니다. 조회 단위가 문서 구조와 잘 맞으면 조인이나 추가 조회를 줄일 수 있지만, 문서 크기, 중복, 갱신 일관성, 인덱스 설계를 함께 관리해야 합니다.

Column-Family 데이터베이스

Column-Family DB는 행(row)마다 다른 컬럼을 가질 수 있는 wide-column 구조입니다. row key와 column family를 기준으로 함께 읽을 데이터를 미리 묶어 설계하며, 대규모 쓰기, 시계열, 로그, sparse 데이터처럼 접근 패턴이 비교적 명확한 워크로드에 강합니다. 일반적인 columnar OLAP DB처럼 임의의 컬럼 집계 쿼리에 최적화된 시스템으로 이해하면 안 됩니다.

대표 제품
Cassandra:
  * 분산 아키텍처, 단일 장애점 없음(Masterless)
  * 쓰기 최적화: LSM-Tree 기반
  * 튜닝 가능한 일관성 수준 (ONE, QUORUM, ALL)
  * 링 구조 해시 파티셔닝
  * 적합: IoT 로그, 시계열 데이터, 대용량 쓰기

HBase:
  * Hadoop HDFS 위에 구축
  * 구글 Bigtable 오픈소스 구현
  * 강한 일관성 제공
  * 적합: row key 기반 랜덤 읽기/쓰기, 범위 조회, 로그 분석

Graph 데이터베이스

Graph DB는 데이터를 노드(Node)와 엣지(Edge)로 표현합니다. 관계 경로가 질문의 중심일 때 자연스러운 모델을 제공하지만, 모든 관계형 데이터를 그래프로 옮긴다고 성능이 좋아지는 것은 아닙니다. 노드·엣지 설계, 고차수 노드, 경로 제한, 인덱스 전략에 따라 성능과 복잡성이 크게 달라집니다.

Graph DB는 소셜 네트워크, 추천 엔진, 사기 탐지, 네트워크 관리, 지식 그래프처럼 관계 경로가 질문의 중심인 영역에서 자연스럽게 쓰입니다. 다만 대량 집계, 범위 검색, 정형 리포팅은 관계형 DB나 분석 DB가 더 단순한 선택일 수 있습니다.

NoSQL의 장단점

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(검색 증강 생성) 시스템의 핵심 구성 요소로 부상하고 있습니다.

데이터베이스 선택 기준

선택 시 고려 사항

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

규모와 요구사항이 커지면 하나의 저장소만으로 모든 접근 패턴을 감당하기 어려워, 데이터 성격에 맞는 여러 저장소를 조합하는 경우가 있습니다. 이를 폴리글랏 퍼시스턴스라 합니다.

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

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

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

클라우드 환경에서는 DBMS를 직접 설치하고 관리하는 대신, 클라우드 제공자가 운영을 지원하는 관리형 서비스를 사용할 수 있습니다. 일부 반복 운영 부담을 서비스로 옮기고, 워크로드에 따라 탄력적 확장 옵션을 선택할 수 있습니다.

Amazon Aurora 계열은 MySQL/PostgreSQL 호환성과 클라우드식 스토리지·복제 운영을 결합합니다. Azure Cosmos DB 계열은 여러 데이터 모델 API와 글로벌 분산, 일관성 옵션을 제공합니다. 정확한 한도와 기능은 서비스, 엔진, 버전에 따라 달라지므로 실제 설계 시 공식 문서를 확인해야 합니다.

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

데이터베이스를 배치하는 방식도 시스템 설계의 중요한 결정입니다. 많은 신규 서비스에서는 단일 DB 구성이 가장 단순한 출발점이지만, 기존 제약이나 도메인 경계에 따라 시작 구조는 달라질 수 있습니다.

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

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

DBMS의 구조와 기능

이전 페이지

릴레이션의 개념

다음 페이지

목차

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