데이터베이스 (Database)

#개념

데이터베이스(Database)는 조직적으로 구조화된 데이터의 집합이며, 이를 생성·저장·조회·갱신·삭제하고 동시 접근과 장애로부터 데이터를 보호하는 소프트웨어를 데이터베이스 관리 시스템(Database Management System, DBMS)이라 한다. 응용 프로그램이 파일에 직접 데이터를 읽고 쓰는 방식은 데이터 구조가 프로그램에 종속되고, 여러 프로그램이 동시에 수정할 때 데이터가 깨지며, 장애 시 복구가 어렵다는 문제가 있다.

DBMS는 데이터의 물리적 저장 방식과 논리적 구조를 분리하는 데이터 독립성, 선언적 질의 언어, 트랜잭션에 의한 무결성 보장, 접근 제어와 백업·복구를 제공하여 이러한 문제를 해결한다. 현대 데이터베이스의 이론적 기반은 Codd(1970)가 제안한 관계형 모델(Relational Model)이다. 관계형 모델은 데이터를 행(튜플)과 열(속성)로 이루어진 테이블(관계, Relation)로 표현하고, 테이블 간의 연결을 포인터가 아닌 값(외래 키)으로 나타내며, 집합론과 1차 술어 논리에 기반한 관계 대수로 질의를 정의한다.

이를 구현한 표준 언어가 SQL(Structured Query Language)로, 테이블을 정의하는 DDL, 데이터를 조작하는 DML(SELECT·INSERT·UPDATE·DELETE), 권한을 다루는 DCL로 구성되며, 사용자는 "무엇을" 원하는지만 선언하고 "어떻게" 가져올지는 DBMS의 질의 최적화기(query optimizer)가 통계 정보를 바탕으로 실행 계획을 결정한다.

관계형 설계에서는 데이터 중복과 갱신 이상(anomaly)을 막기 위해 테이블을 분해하는 정규화(Normalization)를 수행한다. 제1정규형은 모든 속성이 원자값을 갖도록, 제2정규형은 기본 키 전체에 완전 함수 종속하도록, 제3정규형은 키가 아닌 속성 간의 이행적 종속을 제거하도록 하며, 실무에서는 조회 성능을 위해 의도적으로 중복을 허용하는 역정규화(denormalization)와 균형을 맞춘다.

데이터베이스의 신뢰성은 트랜잭션(Transaction)과 ACID 속성으로 보장된다. 트랜잭션은 논리적으로 하나의 작업 단위를 이루는 연산의 묶음으로, 원자성(Atomicity)은 트랜잭션의 모든 연산이 전부 반영되거나 전혀 반영되지 않음을, 일관성(Consistency)은 트랜잭션 전후에 제약 조건과 무결성 규칙이 유지됨을, 고립성(Isolation)은 동시에 실행되는 트랜잭션이 서로의 중간 상태를 보지 않음을, 지속성(Durability)은 커밋된 결과가 장애 후에도 보존됨을 뜻한다.

원자성과 지속성은 변경 내용을 데이터 파일보다 먼저 로그에 기록하는 선행 기입 로그(Write-Ahead Logging, WAL)로 구현되고, 고립성은 잠금(locking)이나 다중 버전 동시성 제어(Multi-Version Concurrency Control, MVCC)로 구현된다. 완전한 고립은 동시성을 크게 떨어뜨리므로 SQL 표준은 네 가지 격리 수준(Isolation Level)을 정의한다.

SQL 표준의 격리 수준

READ UNCOMMITTED: 커밋되지 않은 데이터를 읽는 더티 리드(dirty read)를 허용한다.
READ COMMITTED: 커밋된 데이터만 읽지만 같은 행을 두 번 읽을 때 값이 달라지는 반복 불가능 읽기(non-repeatable read)가 발생할 수 있다.
REPEATABLE READ: 반복 불가능 읽기를 막지만 조건에 맞는 행이 새로 나타나는 팬텀 리드(phantom read)가 가능하다.
SERIALIZABLE: 트랜잭션들을 순차 실행한 것과 동일한 결과를 보장한다.

MVCC를 사용하는 PostgreSQL이나 MySQL의 InnoDB는 각 트랜잭션에 데이터의 스냅샷을 제공하여 읽기가 쓰기를 막지 않게 하며, 스냅샷 격리(snapshot isolation)에서 발생할 수 있는 쓰기 왜곡(write skew)을 막기 위해 PostgreSQL은 직렬화 가능 스냅샷 격리(SSI)를 제공한다.

조회 성능의 핵심은 인덱스(Index)다. 인덱스가 없으면 조건에 맞는 행을 찾기 위해 테이블 전체를 읽어야 하지만(full scan), 인덱스는 특정 열의 값과 행 위치를 정렬된 구조로 유지하여 탐색을 로그 시간으로 줄인다. 가장 널리 쓰이는 B-트리(B-Tree)(실제로는 리프 노드가 연결 리스트로 이어진 B+트리)는 디스크 페이지 크기에 맞춘 높은 분기 계수를 가져 수억 건의 데이터도 3~4단계의 탐색으로 찾을 수 있고, 등가 조건과 범위 조건, 정렬을 모두 지원한다.

그 외에 등가 검색에 특화된 해시 인덱스, 쓰기 처리량에 유리하여 많은 NoSQL이 채택한 LSM 트리(Log-Structured Merge-Tree), 전문 검색을 위한 역색인, 공간 데이터를 위한 R-트리가 있다. 인덱스는 쓰기 비용과 저장 공간을 늘리므로 질의 패턴에 맞춰 선별적으로 설계해야 하며, 복합 인덱스의 열 순서, 인덱스만으로 질의를 처리하는 커버링 인덱스, 실행 계획(EXPLAIN) 분석은 실무에서 성능 튜닝의 기본이다.

워크로드 관점에서 데이터베이스는 온라인 트랜잭션 처리(Online Transaction Processing, OLTP)와 온라인 분석 처리(Online Analytical Processing, OLAP)로 구분된다. OLTP는 주문 생성, 잔액 이체, 회원 가입처럼 적은 수의 행을 읽고 쓰는 짧은 트랜잭션이 초당 수천에서 수십만 건 발생하는 워크로드로, 행 단위로 데이터를 저장하는 행 지향(row-oriented) 저장소와 B-트리 인덱스, 엄격한 ACID가 적합하다.

OLAP는 수억 행을 스캔하여 집계하는 분석 질의가 중심인 워크로드로, 필요한 열만 읽고 압축 효율이 높은 열 지향(column-oriented) 저장소와 벡터화 실행, 대규모 병렬 처리가 적합하며 데이터 웨어하우스(Data Warehouse)가 이에 해당한다. 두 워크로드를 하나의 시스템에서 동시에 처리하려는 HTAP(Hybrid Transactional/Analytical Processing) 데이터베이스도 등장했다.

2000년대 후반 웹 서비스의 폭발적 성장은 관계형 데이터베이스가 수평 확장에 취약하고 고정된 스키마가 빠른 변화에 맞지 않는다는 문제를 드러냈고, 이에 대한 대안으로 NoSQL 데이터베이스가 등장했다. NoSQL은 데이터 모델에 따라 네 가지로 분류된다.

NoSQL 데이터베이스의 유형

키-값 저장소(Key-Value Store): 키로 값을 조회하는 가장 단순한 모델로 Redis, Amazon DynamoDB가 대표적이며, 세션 저장과 캐싱(Caching)에 널리 쓰인다.
문서 데이터베이스(Document Database): JSON이나 BSON 형태의 중첩 문서를 저장하며 문서마다 다른 구조를 허용하는 유연한 스키마를 제공하고, MongoDB와 Couchbase가 대표적이다.
열 패밀리 저장소(Wide-Column Store): Google Bigtable의 설계를 따라 행 키와 열 패밀리로 데이터를 구성하고 수백 대의 노드에 분산 저장하여 쓰기 처리량이 매우 높으며, Apache Cassandra와 HBase가 있다.
그래프 데이터베이스(Graph Database): 노드와 간선, 속성으로 데이터를 표현하고 관계 탐색 질의에 최적화되어 있어 소셜 네트워크, 추천, 사기 탐지의 경로 분석에 쓰이며, Neo4j가 대표적이다.

분산 데이터베이스 설계의 이론적 제약은 Brewer가 제시하고 Gilbert와 Lynch(2002)가 증명한 CAP 정리로 설명된다. CAP 정리는 네트워크 분할(Partition)이 발생했을 때 모든 노드가 같은 데이터를 보는 일관성(Consistency)과 모든 요청이 응답을 받는 가용성(Availability)을 동시에 보장할 수 없음을 말한다.

분할은 피할 수 없으므로 실제 선택은 분할 시 일관성을 택할지 가용성을 택할지의 문제가 되며, 많은 NoSQL은 ACID 대신 기본적 가용성(Basically Available), 유연한 상태(Soft state), 최종 일관성(Eventual consistency)을 뜻하는 BASE 모델을 택하여 일시적인 불일치를 허용하는 대신 높은 가용성과 확장성을 얻는다. 다만 CAP는 분할 상황만 다루며, 정상 상황에서의 지연 시간과 일관성 사이의 절충을 포함한 PACELC 같은 확장된 틀로 보완된다.

NoSQL이 포기한 SQL과 ACID를 수평 확장과 함께 되찾으려는 흐름이 NewSQL 또는 분산 SQL(Distributed SQL)이다. Google Spanner는 원자 시계와 GPS에 기반한 TrueTime으로 전 세계에 분산된 노드 간에 외부 일관성(external consistency)을 갖는 트랜잭션을 구현했고, 이에 영감을 받은 CockroachDB, TiDB, YugabyteDB 등은 데이터를 범위(range) 단위로 자동 분할하고 Raft 합의 알고리즘으로 복제하여 노드를 추가하기만 하면 용량과 처리량이 늘어나는 관계형 데이터베이스를 제공한다.

특정 데이터 유형에 특화된 데이터베이스도 다양하다. 시계열 데이터베이스(Time-Series Database)는 타임스탬프가 붙은 측정값의 고속 적재, 시간 범위 질의, 다운샘플링과 보존 정책에 최적화되어 있으며 InfluxDB, TimescaleDB, Prometheus가 대표적이다. 벡터 데이터베이스(Vector Database)는 임베딩(Embedding) 벡터를 저장하고 HNSW 같은 근사 최근접 이웃 색인으로 유사도 검색을 수행하며, 검색 증강 생성(Retrieval-Augmented Generation, RAG)의 확산과 함께 Milvus, Pinecone, Weaviate 같은 전용 제품과 PostgreSQL의 pgvector 확장이 널리 쓰인다.

그 밖에 전문 검색 엔진(Elasticsearch, OpenSearch), 공간 데이터베이스(PostGIS), 인메모리 데이터베이스, 임베디드 데이터베이스(SQLite, RocksDB)가 각각의 영역을 차지한다. 최근에는 PostgreSQL처럼 JSON, 전문 검색, 벡터, 시계열 확장을 모두 지원하는 다중 모델(multi-model) 접근과, 반대로 용도별 최적 데이터베이스를 조합하는 폴리글랏 퍼시스턴스(polyglot persistence) 접근이 공존한다.

프로덕션 데이터베이스 운영의 핵심 과제는 복제(Replication), 샤딩(Sharding), 고가용성(High Availability)이다. 복제는 같은 데이터를 여러 노드에 유지하는 것으로, 하나의 리더(primary)가 쓰기를 받고 팔로워(replica)가 변경 로그를 받아 적용하는 리더 기반 복제가 일반적이다. 리더가 팔로워의 확인을 기다린 뒤 커밋하는 동기 복제는 데이터 손실이 없지만 지연이 늘고, 기다리지 않는 비동기 복제는 빠르지만 리더 장애 시 최근 쓰기를 잃을 수 있으며, 팔로워에서 읽기를 분산하면 복제 지연(replication lag)으로 인해 방금 쓴 데이터가 보이지 않는 문제를 다뤄야 한다.

리더 장애 시 팔로워를 새 리더로 승격하는 장애 조치(Failover)를 자동화하고 두 노드가 모두 리더라고 믿는 스플릿 브레인(split-brain)을 막기 위해 합의 알고리즘이나 펜싱(fencing)이 사용된다. 샤딩은 데이터를 키 범위나 해시 값에 따라 여러 노드에 나누어 저장하는 수평 분할로, 단일 노드의 저장·처리 한계를 넘어서게 하지만 샤드를 가로지르는 조인과 트랜잭션이 어려워지고, 특정 샤드에 부하가 몰리는 핫스팟과 노드 추가 시 데이터 재배치(rebalancing) 문제를 수반한다.

응용 프로그램 측면에서는 객체 관계 매핑(Object-Relational Mapping, ORM)이 테이블의 행을 프로그래밍 언어의 객체로 대응시켜 SQL을 직접 작성하지 않고도 데이터를 다룰 수 있게 하며, SQLAlchemy, Django ORM, Hibernate, Prisma가 대표적이다. ORM은 생산성을 높이지만 연관 객체를 순회할 때마다 질의가 발생하는 N+1 문제나 비효율적인 SQL 생성에 주의해야 한다.

데이터베이스 연결은 TCP 접속과 인증, 세션 메모리 할당 비용이 크므로 커넥션 풀(Connection Pool)이 미리 만들어 둔 연결을 재사용하게 하고, PostgreSQL의 PgBouncer처럼 수천 개의 응용 연결을 소수의 데이터베이스 연결로 다중화하는 외부 풀러도 사용된다. 스키마 변경을 코드로 버전 관리하는 마이그레이션 도구(Flyway, Alembic), 정기 백업과 특정 시점 복구(Point-in-Time Recovery), 모니터링과 느린 질의 분석 역시 운영의 필수 요소다.

대표적인 제품을 살펴보면 다음과 같다.

대표적인 데이터베이스 제품

PostgreSQL: 표준 SQL 준수도가 높고 MVCC, 풍부한 데이터 타입, JSONB, 전문 검색, 확장 기능(PostGIS, pgvector, TimescaleDB)을 갖춘 객체 관계형 데이터베이스로, 관대한 PostgreSQL 라이선스 아래 커뮤니티가 개발하며 최근 가장 널리 채택되는 범용 데이터베이스다.
MySQL: 웹 서비스와 함께 성장한 관계형 데이터베이스로 InnoDB 스토리지 엔진이 트랜잭션과 행 수준 잠금을 제공하며, GPL 오픈소스 판과 Oracle의 상용 판이 있고 호환 분기인 MariaDB도 널리 쓰인다.
MongoDB: BSON 문서를 저장하는 대표적인 문서 데이터베이스로 유연한 스키마, 복제 세트, 자동 샤딩, 집계 파이프라인을 제공하며 다중 문서 ACID 트랜잭션도 지원한다.
Redis: 문자열, 해시, 리스트, 정렬 집합 등 다양한 자료 구조를 메모리에 저장하는 키-값 저장소로 캐시, 세션 저장, 순위표, 메시지 브로커, 분산 잠금에 쓰이며, 2024년 라이선스 변경으로 Valkey 같은 BSD 분기가 생겨났다.
Apache Cassandra: 마스터 없는 피어 투 피어 구조와 튜닝 가능한 일관성 수준을 갖춘 열 패밀리 저장소로 다중 데이터센터에 걸친 높은 쓰기 처리량과 가용성이 강점이다.
Neo4j: 속성 그래프 모델과 Cypher 질의 언어를 제공하는 그래프 데이터베이스다.

데이터베이스 선택은 데이터 모델과 질의 패턴, 일관성 요구, 규모와 성장 전망, 운영 역량을 함께 고려해야 하며, 대부분의 서비스는 관계형 데이터베이스를 중심에 두고 캐시, 검색 엔진, 분석용 웨어하우스를 보조적으로 결합하는 구조로 시작한다. 결론적으로 데이터베이스는 관계형 모델이라는 견고한 이론 위에 트랜잭션, 인덱스, 복제와 분산 기술이 축적되어 온 분야이며, 머신러닝 시스템에서도 학습 데이터의 원천, 피처 스토어(Feature Store)의 온라인 저장소, 벡터 검색 기반 RAG의 지식 저장소로서 핵심적인 역할을 한다.

#관련 용어

데이터 웨어하우스

분석 질의에 최적화된 구조로 여러 원천의 데이터를 통합 저장하는 OLAP 지향 시스템

캐싱

자주 조회되는 데이터를 빠른 저장소에 복사해 두어 데이터베이스 부하와 응답 지연을 줄이는 기법

벡터 데이터베이스

임베딩 벡터를 저장하고 근사 최근접 이웃 색인으로 유사도 검색을 수행하는 특수 목적 데이터베이스

빅데이터

단일 데이터베이스로 처리하기 어려운 규모·속도·다양성을 가진 데이터와 이를 다루는 분산 처리 기술

ETL

운영 데이터베이스에서 데이터를 추출·변환하여 분석 저장소로 적재하는 과정

지연 시간

질의 요청부터 응답까지 걸리는 시간으로, 인덱스와 커넥션 풀, 복제 구조에 따라 크게 달라지는 성능 지표

#직무 연관도

Data Analyst높음

SQL로 데이터를 질의·집계하고 테이블 간 관계와 정규화된 스키마를 이해하여 정확한 분석 결과를 도출하는 데 필수적인 도구

Data Scientist보통

학습 데이터와 특징을 SQL로 추출하고, 벡터 데이터베이스와 피처 스토어의 동작 방식을 이해하여 모델 파이프라인을 설계하는 데 필요한 기반 지식

Data Engineer밀접

데이터 모델링, 인덱스와 질의 최적화, 트랜잭션 설계, 복제·샤딩·고가용성 구성, 데이터베이스 선택과 운영을 담당하는 핵심 영역

#사용 사례

금융전자상거래인터넷 서비스통신의료제조공공

개요

데이터베이스는 은행 계좌와 결제 처리, 주문과 재고 관리, 회원과 세션 관리, 통신 요금 정산, 전자의무기록, 제조 실행 시스템, 공공 행정 정보 등 거의 모든 정보 시스템의 핵심 저장소로 사용되며, 머신러닝 시스템에서는 학습 데이터 원천, 온라인 피처 스토어, 벡터 검색 저장소의 역할을 담당한다.

사례

전자상거래 서비스에서 주문 생성은 재고 차감, 결제 기록, 주문 생성을 하나의 트랜잭션으로 묶어 관계형 데이터베이스에 저장하여 결제만 되고 주문이 누락되는 일을 막고, 상품 상세 페이지와 장바구니는 Redis 캐시로 응답 지연을 줄이며, 고객 리뷰와 상품 속성처럼 구조가 자주 바뀌는 데이터는 문서 데이터베이스에 저장한다. 운영 데이터베이스의 변경 로그는 데이터 웨어하우스로 복제되어 매출 분석에 쓰이고, 상품 임베딩은 벡터 데이터베이스에 적재되어 유사 상품 검색에 활용된다.