데이터베이스 모델: RDB, NoSQL, NewSQL

데이터베이스는 데이터의 집합이고, 이를 저장·관리하는 소프트웨어가 DBMS(Database Management System)다. 데이터를 어떤 구조로 저장하느냐에 따라 데이터베이스 모델이 나뉜다. 정해진 스키마와 강한 일관성을 원하면 관계형, 유연한 구조와 수평 확장을 원하면 NoSQL, 둘 다 원하면 NewSQL이라는 식으로 요구사항에 맞춰 고른다.

DBMS가 해결하는 문제

DBMS 이전에는 응용 프로그램마다 운영체제의 파일에 데이터를 따로 저장했다(파일 처리 시스템). 학적 프로그램과 수강 프로그램이 학생 정보를 각자 파일로 갖는 식이다. DBMS는 데이터를 한곳에 모아 여러 프로그램이 공유하게 해서 이 방식의 문제를 푼다. 데이터베이스, DBMS, 그 위의 응용 프로그램을 함께 데이터베이스 시스템이라 부른다.

대가는 DBMS 자체의 비용(라이선스·서버·운영 인력)과 단순한 작업에도 붙는 처리 오버헤드다. 데이터가 작고 한 프로그램만 쓰면 파일이 더 싸다.

DBMS를 다루는 사람은 역할로 나뉜다. DBA(데이터베이스 관리자) 는 스키마 정의, 저장 구조와 접근 방법 결정, 권한 부여, 백업·복구, 성능 감시를 맡는다. 설계자는 개체·관계·제약·뷰를 설계하고, 최종 사용자는 응용 프로그램이나 질의로 데이터를 쓴다.

1계층·2계층·3계층 구조

DBMS를 어떤 층을 거쳐 쓰느냐로 구조를 나눈다.

한눈에 비교

데이터 모델의 계보

관계형 이전에도 데이터를 구조화하는 모델이 있었고, 관계형은 그 한계를 풀며 표준이 되었다.

계층·네트워크 모델의 발상은 사라지지 않았다. 문서형 DB는 계층(트리) 모델을, 그래프 DB는 네트워크 모델을 현대적으로 되살린 셈이다.

분석용 모델: 스타 스키마와 스노플레이크 스키마

데이터 웨어하우스(OLAP)에서는 정규화보다 집계 쿼리를 빨리 돌리는 것이 중요해 테이블을 다르게 배치한다.

스타 스키마

flowchart TB
  dt["dim_날짜"] --- fact["fact_매출"]
  pr["dim_상품"] --- fact
  fact --- sh["dim_매장"]
  fact --- cu["dim_고객"]

스노플레이크 스키마

flowchart TB
  ct["dim_카테고리"] --- pr["dim_상품"] --- fact["fact_매출"] --- sh["dim_매장"] --- rg["dim_지역"]
  dt["dim_날짜"] --- fact
  fact --- cu["dim_고객"]

어떤 질문에 어떤 DB를 쓰는지는 용도별 데이터베이스와 고르는 법에 있다.

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

데이터를 행과 열로 이루어진 테이블(릴레이션)에 저장하고, 테이블 간 관계를 키로 표현한다.

• ACID 트랜잭션: 원자성, 일관성, 격리성, 지속성
• 정규화(1NF, 2NF, 3NF …)로 중복과 이상 현상을 줄임
• ANSI 표준 SQL과 JOIN으로 복잡한 질의 가능
• 확장은 주로 더 좋은 서버로 바꾸는 scale-up 방식. 서버를 늘리는 scale-out(읽기 복제본, 샤딩)은 따로 설계해야 한다(데이터베이스 확장과 성능 최적화, 데이터베이스 샤딩)

한계: 스키마가 경직되어 있어 구조가 자주 바뀌거나 비정형인 대용량 데이터(빅데이터)를 다루기에는 불리하다.

무엇이 관계형인가: 코드의 규칙. 관계형 모델을 제안한 E. F. Codd는 1985년 DBMS가 「관계형」이라 불리려면 지켜야 할 규칙을 0번 기초 규칙(관계형 기능만으로 데이터를 관리한다)과 1~12번으로 정리했다(번호가 13개지만 흔히 「12규칙」이라 부른다). 모두 지키는 상용 제품은 사실상 없고, 관계형다움을 재는 기준으로 쓴다.

대표 제품

• MySQL: 가장 널리 쓰이는 오픈소스 RDBMS 중 하나, 가볍고 다중 사용자 환경에 강함
• PostgreSQL: 표준 준수와 확장성이 뛰어난 오픈소스 RDBMS (아래 절 참고)
• Oracle: 대기업·금융권에서 많이 쓰는 상용 RDBMS
• Microsoft SQL Server

PostgreSQL과 MySQL

PostgreSQL은 사용자 정의 타입, 테이블 상속, 배열·JSON 컬럼 같은 객체 지향 기능을 갖춰 객체관계형 DBMS(ORDBMS)로 분류된다. 다만 지금은 주요 RDBMS 대부분이 이런 기능을 받아들여, ORDBMS와 RDBMS를 나누는 의미는 작다. 로고의 코끼리 이름은 Slonik이다.

버전이 오르며 두 DB의 기능 격차는 많이 줄었고, 기본 기능이 비슷해 서로 옮기기도 어렵지 않다.

PostgreSQL의 구조: 클라이언트가 접속하면 postmaster(현재 이름은 postgres 서버 프로세스)가 연결마다 백엔드 프로세스를 하나씩 띄운다. 스레드가 아니라 프로세스라서 연결이 많아지면 메모리 부담이 크므로, 앞단에 PgBouncer 같은 커넥션 풀러를 두는 경우가 많다(DB 커넥션 풀). 쿼리는 파싱 → 의미 분석 → 규칙(rule) 기반 재작성 → 실행 계획 선택 → 실행 순서로 처리된다. 타입·함수·인덱스 접근 방식까지 시스템 카탈로그에 정의할 수 있어 확장이 쉽고, PostGIS(공간), pgvector(벡터 검색), hstore(키-값) 같은 확장이 이 구조 위에 올라간다.

옮길 때 걸리는 차이: 문자열 끝 공백. SQL 표준의 PAD SPACE 비교는 길이가 다른 두 문자열의 짧은 쪽 뒤에 공백을 채운 뒤 비교한다. 그래서 'a' = 'a '의 결과가 DB와 설정마다 다르다.

DB를 옮기거나 둘을 섞어 쓸 때는 컬럼 타입(CHAR·VARCHAR)과 콜레이션을 함께 확인하고, 입력 단계에서 공백을 정리해 두는 편이 안전하다. GUI 클라이언트로 접속하는 방법은 DBeaver에 있다.

NoSQL

"Not only SQL". 비정형 데이터를 다루며 고정 스키마가 없고, 애플리케이션의 도움 없이도 여러 서버에 데이터를 나눠 저장(자동 분산·밸런싱)하는 경우가 많다. 캐싱이 통합된 제품도 있다.

RDB의 ACID에 대비해 많은 NoSQL이 따르는 성질을 BASE라 부른다. 기본적으로 가용하고(Basically Available: 일부 노드가 죽어도 응답한다), 상태가 고정돼 있지 않으며(Soft state: 입력이 없어도 복제가 따라잡는 동안 값이 바뀐다), 결국 일관해진다(Eventually consistent: 쓰기가 멈추면 언젠가 모든 복제본이 같은 값이 된다). 일관성을 늦추는 대신 가용성과 확장성을 얻는다는 뜻으로, 아래 CAP 정리의 AP 쪽 선택과 같은 방향이다. MongoDB·DynamoDB처럼 단일 문서·다중 문서 트랜잭션을 지원하는 NoSQL도 많아 BASE와 NoSQL이 같은 말은 아니다.

문서형 (Document)

• JSON(BSON) 같은 트리 구조 문서를 저장. 문서마다 구조가 달라도 된다.
• 문서 내부 필드로 검색하기 쉽다.
• 객체 모양 그대로 저장해 직관적이고 수평 확장이 쉽다. 대신 스키마가 없다는 것이 양날이다. 형식이 문서마다 어긋나도 DB가 막지 않고, 문서 사이의 관계(조인)는 약하다.
• 예: MongoDB, Couchbase

키-값형 (Key-Value)

• 하나의 키에 하나의 값을 매핑하는 가장 단순한 구조. 키로 바로 찾으므로 단순 조회가 빠르다.
• 주로 메모리에 두고 세션, 캐시, 실시간 순위·시세 같은 상태 저장에 쓴다.
• 기본 연산이 키 단위 CRUD뿐이다. 값의 내용으로 거르거나 범위를 훑거나 보조 인덱스로 찾는 복잡한 질의에는 맞지 않는다(제품마다 자료구조·보조 인덱스를 일부 더한다).
• 예: Redis, Valkey, Amazon DynamoDB(키-값 + 문서)

와이드 컬럼형 (Wide Column)

• 행마다 서로 다른 컬럼 집합을 가질 수 있는 거대한 2차원 맵 구조.
• 대규모 분산 저장과 대량 쓰기·조회에 강하다.
• 예: Cassandra, ScyllaDB, HBase
• 파티션 키·클러스터링 키 설계, LSM 트리 저장 엔진, 핫 파티션 대응은 와이드 컬럼 DB와 대규모 메시지 저장: Cassandra·ScyllaDB에 있다.

그래프형 (Graph)

• 데이터를 노드, 관계를 엣지로 저장한다. 관계 자체가 저장되어 있어 여러 단계의 관계를 따라갈 때 RDB처럼 단계마다 JOIN을 할 필요가 없다.
• 소셜 네트워크, 추천 시스템, 사기 탐지(계좌·기기·사람 사이의 수상한 고리 찾기), 네트워크·인프라 의존 관계 지도에 적합.
• 관계를 따라가는 질의는 빠르지만, 모델링과 운영이 익숙하지 않고 분산이 어렵다. 질의 언어는 오래 제품마다 달랐지만(Neo4j의 Cypher, Apache TinkerPop의 Gremlin), 2024년에 ISO 표준 그래프 질의 언어 GQL(ISO/IEC 39075)이 나왔다.
• 예: Neo4j, Amazon Neptune

시계열형 (Time Series)

• 시각이 찍힌 측정값(지표, 센서 값, 시세)을 쓰기 순서대로 빠르게 쌓고, 시간 구간으로 집계하는 데 최적화했다. 압축과 오래된 데이터 자동 삭제·다운샘플링으로 저장 효율을 높인다.
• IoT 데이터, 애플리케이션 모니터링 지표, 금융 시세 분석에 쓴다.
• 예: InfluxDB, Prometheus, TimescaleDB. 고르는 기준은 용도별 데이터베이스와 고르는 법에 있다.

멀티 모델 (Multi-model)

• 관계형·문서·키-값·그래프 같은 여러 모델을 한 DB 엔진에서 함께 제공한다. 데이터 종류마다 다른 DB를 두는 대신 한 저장소에서 여러 모델로 저장·색인·질의한다.
• 저장소를 여럿 운영하지 않아도 되고 모델 사이 일관성을 지키기 쉽다. 대신 엔진이 복잡하고, 각 모델의 기능은 전용 DB보다 덜 성숙한 경우가 많다.
• 예: ArangoDB, Azure Cosmos DB(여러 API), 그리고 JSONB·확장으로 문서·벡터·지리 데이터까지 다루는 PostgreSQL도 이 방향이다

CAP 정리

분산 데이터베이스는 네트워크가 끊겨 노드끼리 연락이 안 되는 상황(분할)을 피할 수 없다. CAP 정리(CAP theorem)는 분할이 생겼을 때 일관성과 가용성 중 하나를 포기해야 한다는 뜻이다.

CAP을 정확히 읽으려면 정리가 쓰는 말의 뜻을 알아야 한다. 2000년 Eric Brewer가 추측으로 제시했고 2002년 Gilbert와 Lynch가 증명했다.

증명의 핵심은 간단하다. 분할 한쪽에 쓰기가 들어오면 반대쪽 읽기는 그 값을 알 수 없다. 옛 값을 주면 일관성이, 저쪽 소식을 끝없이 기다리면 가용성이 깨진다. 전화로 기억을 대신해 주는 회사를 두 직원이 나눠 맡았는데 둘 사이 연락이 끊긴 상황을 떠올리면 된다. 고객에게 답할지(가용성), 상대에게 확인될 때까지 답을 미룰지(일관성)를 골라야 한다.

분할 내성은 분산 시스템에서 뺄 수 없으므로 실제 선택은 CP(분할 중에는 일부 요청을 거절하고 정확성을 지킨다)와 AP(일단 응답하고 나중에 맞춘다, 최종 일관성) 사이다. 분할이 없을 때도 지연 시간과 일관성을 맞바꾼다는 점까지 넣은 확장이 PACELC다. 많은 제품은 하나로 고정되지 않고 설정(복제 수, 읽기·쓰기 정족수)으로 조절한다.

PACELC는 복제하는 시스템에 대해 「분할(P)이 나면 가용성(A)과 일관성(C) 중에, 그렇지 않으면(E) 지연(L)과 일관성(C) 중에 고른다」고 말한다. 앞의 PAC은 CAP과 같고, ELC가 평소 상태를 다룬다. 가용성을 복제로 얻는다고 가정하므로, 장애가 없을 때도 복제본을 기다릴지(일관성) 바로 답할지(지연)를 정해야 한다.

CAP은 자주 오해된다.

• 「셋 중 둘을 고른다」는 표현은 거친 단순화다. CAP이 금지하는 것은 「분할이 난 상황에서 완벽한 일관성과 완벽한 가용성을 동시에」뿐이다. 분할이 없을 때는 둘 다 가질 수 있다.

• CAP의 C와 A는 100% 를 뜻한다. 실제 설계 논의는 분할이 없는 평소에 지연과 일관성을 어떻게 맞바꾸느냐(PACELC의 ELC)가 더 자주 문제가 된다.

• 「CA 시스템」이라는 말은 성립하지 않는다. 분할 내성은 고르는 성질이 아니라 네트워크가 정하는 조건이다. 분할을 겪을 수 있는 분산 시스템이라면 「분할 가능성 → C와 A를 늘 함께 가질 수는 없다」로 읽는다. 분할이 없는 단일 노드 DB만 CA라고 부를 수 있다.

• 정리는 어떤 상황에서 C나 A를 포기해야 한다고만 말하고, 그 상황이 얼마나 자주 오는지는 말하지 않는다. 다만 오래 도는 시스템은 언젠가 그 상황을 만난다.

• 실제 시스템은 둘 중 하나를 느슨하게 만든다. ZooKeeper처럼 정확성이 우선이면 가용성을, Dynamo처럼 쓰기 가용성이 우선이면 일관성을 늦춘다. 정의를 하나라도 약하게 바꾸면 CAP의 불가능성은 더 이상 그대로 적용되지 않는다.

• CAP과 FLP는 다른 정리다. FLP 불가능성은 노드 하나가 멈출 수 있는 비동기 네트워크에서 결정적 합의 알고리즘이 항상 끝난다는 보장은 불가능하다는 결과다. FLP는 메시지 유실을 가정하지 않고 합의를 다루며, CAP은 메시지 유실을 허용하고 저장소의 일관성을 다룬다. 합의 알고리즘 쪽은 분산 시스템의 시간과 장애에 있다.

• 죽은 노드는 응답 의무가 없지만 분할된 노드는 응답해야 한다는 점에서 둘은 다르고, 느린 노드는 메시지가 결국 도착한다는 점에서 분할과 다르다. 그런데 셋을 바깥에서 구별할 수 없다는 사실이 CAP·FLP가 성립하는 이유다.

• CAP만으로 DB를 고르지 않는다. 채팅 메시지 저장에 Cassandra를 쓰는 이유는 AP라서가 아니라 쓰기 처리량, 파티션 단위 조회 같은 특성 때문이다. CAP은 트레이드오프를 따져 보게 하는 출발점이다.

NewSQL

RDB의 ACID와 SQL을 유지하면서 NoSQL 수준의 수평 확장성과 성능을 얻으려는 데이터베이스.

• 파티셔닝/샤딩으로 데이터를 여러 노드에 분산
• 분산 환경에서의 동시성 제어
• 복제(replication)와 장애 복구(crash recovery)
• 예: Google Spanner, CockroachDB, TiDB, YugabyteDB. "분산 SQL(Distributed SQL)"이라고도 부른다. 초기 대표 제품이던 NuoDB는 2020년 다쏘시스템에 인수되었다.

무엇을 고를까

판단 기준은 데이터가 테이블에 담기는 쪽이 유리한지, 문서에 담기는 쪽이 유리한지다.

RDB가 무거워지는 지점과 NoSQL이 치르는 대가

NoSQL이 늘 빠른 것은 아니다. NoSQL은 RDB가 기본으로 제공하는 기능 일부를 빼서 그 비용을 아낀다. 빠진 기능이 워크로드에 필요하면 결국 애플리케이션이 그 비용을 다시 치른다.

그래서 NoSQL을 고르는 근거는 「빠르다」가 아니라 워크로드의 모양이다. 접근 패턴이 키 중심으로 정해져 있고, 쓰기량이나 데이터 양이 한 서버를 넘고, 다중 엔터티 트랜잭션이 거의 필요 없을 때 NoSQL이 이득이다. 반대로 질의가 다양하고 정합성이 중요한 데이터는 RDB가 싸다.

흔히 "MongoDB는 쉽다"고 하는데, 이는 쿼리 문법이 JavaScript 객체와 닮아 입문 장벽이 낮다는 뜻이다. 초보용·숙련자용을 가르는 기준은 아니다.

검색·분석·시계열·벡터처럼 용도별로 DB를 고르는 순서와 결정 트리는 용도별 데이터베이스와 고르는 법에 있다.

애플리케이션에서 접근하기: ORM과 ODM

애플리케이션 코드는 보통 DB를 직접 다루지 않고 매핑 도구를 거친다.

• ORM(Object-Relational Mapping): 테이블 행을 객체로 매핑한다. 예: Django ORM, TypeORM, Prisma
• ODM(Object-Document Mapping): 문서를 객체로 매핑한다. 예: Mongoose

관련 노트: SQL 기초, MongoDB 시작하기와 CRUD, 트랜잭션과 회복, 정규화와 반정규화, 백엔드 개발자가 알아야 할 것, 데이터베이스 샤딩, 용도별 데이터베이스와 고르는 법