NoSQL 데이터 모델링과 CAP·BASE 선택 기준
NoSQL의 저장 모델, CAP·BASE 특성, RDBMS와의 차이, 쿼리 중심 데이터 모델링 원칙과 운영 설계 흐름을 정리한다.
2026-08-14 · 최초 발행 2025-08-10
NoSQL은 데이터 접근 방식에서 출발한다
NoSQL은 관계형 데이터베이스(RDBMS)의 한계를 보완하기 위해 등장한 대안적 데이터베이스 시스템이다. 대용량 데이터를 처리하는 빅데이터 환경에서 수평적 확장(Scale-out)과 쓰기 중심 성능을 확보하는 데 초점을 둔다.
엄격한 스키마 대신 유연한 구조를 사용하므로, 서로 다른 형태의 데이터를 수용할 수 있다. 다만 NoSQL은 RDBMS를 일괄적으로 대체하는 선택지가 아니라 데이터의 형태, 쿼리 방식, 일관성 요구사항에 따라 판단해야 하는 저장 모델이다.
분산 환경에서 CAP를 선택하는 방식
2002년 버클리 대학의 Eric Brewer 교수가 제안한 CAP 이론은 분산 시스템의 선택 기준을 설명한다. 일관성(Consistency), 가용성(Availability), 분할 내성(Partition Tolerance)은 동시에 모두 만족시킬 수 없는 속성이다.
- Consistency: 모든 노드가 같은 시간에 같은 데이터를 보유하는 일관성
- Availability: 일부 노드에 장애가 발생해도 서비스를 제공할 수 있는 가용성
- Partition Tolerance: 네트워크 분할 상황에서도 시스템이 정상 동작하는 분할 내성
CAP는 데이터베이스가 장애와 분산 환경을 어떤 방식으로 다루는지 보여준다. 따라서 제품의 기능만 비교하기보다, 서비스가 어느 속성을 우선해야 하는지부터 정해야 한다.
저장 모델별로 달라지는 강점
문서 구조를 그대로 담는 Document DB
Document 기반 데이터베이스는 JSON, XML 등의 문서 형태로 데이터를 저장한다. 유연한 스키마를 바탕으로 다양한 데이터 구조를 다룰 수 있고, Secondary Index를 이용한 빠른 검색을 지원한다.
MongoDB와 CouchDB가 대표 제품이다. 콘텐츠 관리, 카탈로그, 사용자 프로필 관리처럼 문서 단위의 데이터를 다루는 경우에 활용할 수 있다.
대량 쓰기를 처리하는 Column-Family DB
Column-Family 기반 데이터베이스는 컬럼 단위로 데이터를 관리한다. 대량의 쓰기 작업에 적합하며 수평적 확장성이 우수하다.
Cassandra와 HBase가 대표적이며, 로그 데이터, 시계열 데이터, 센서 데이터 처리에 활용된다.
단순한 접근 경로를 제공하는 Key-Value DB
Key-Value 기반 데이터베이스는 키와 값의 쌍으로 데이터를 저장한다. 동적 해시테이블 구조를 활용하며 읽기와 쓰기 성능이 빠르다.
Redis와 Amazon DynamoDB가 대표적이다. 세션 관리, 캐싱, 실시간 분석에 맞는다.
관계 자체를 모델로 다루는 Graph DB
Graph 기반 데이터베이스는 노드와 엣지로 데이터를 구성한다. 복잡한 관계를 표현하는 데 적합하고 시맨틱 데이터 처리에도 유용하다.
Neo4j와 Amazon Neptune이 대표 제품이며, 소셜 네트워크, 추천 시스템, 지식 그래프에 활용된다.
CAP 선택이 서비스 특성에 미치는 영향
CA 시스템
Oracle과 관계형 DB는 강한 일관성과 가용성을 제공한다. 반면 분할 내성이 부족하므로 네트워크 장애가 발생하면 시스템 전체에 영향을 받을 수 있다. 트랜잭션 중심의 비즈니스 애플리케이션에 적합하다.
CP 시스템
MongoDB는 일관성과 분할 내성을 중심에 둔다. 모든 노드의 동기화된 성능을 제공하며, 금융이나 결제처럼 데이터 정확성이 중요한 영역에 적합하다.
AP 시스템
Cassandra는 가용성과 분할 내성을 우선한다. 비동기식 데이터 저장 작업을 수행하므로 실시간 분석, 로그 처리처럼 데이터 손실을 허용할 수 있는 영역에 적합하다.
쿼리 패턴에 맞춰 데이터를 배치한다
NoSQL 모델링은 정규화된 관계를 먼저 만들고 조인으로 조합하는 방식과 다르게 접근한다. 데이터를 어떤 형태로 읽고 쓸지에 맞춰 저장 구조를 정한다.
비정규화(Denormalization)는 데이터 중복을 허용해 조인 연산을 줄이는 방식이다. 사용자 정보와 주문 정보를 하나의 문서에 통합해 저장하거나, 읽기 성능 향상을 위해 데이터를 복제하는 경우가 여기에 속한다.
집계(Aggregation)는 유연한 스키마를 이용해 1:N 관계를 최소화하고 성능을 최적화하는 방식이다. 블로그 포스트와 댓글을 하나의 문서에 저장하는 구성이 예시다.
애플리케이션 조인(Application Join)은 데이터베이스 레벨의 조인 대신 애플리케이션에서 데이터를 조합한다. 복잡한 관계 자체보다 실제 사용 패턴을 중심으로 설계할 때 사용한다.
데이터 구조를 결정하는 설계 흐름
도메인 모델을 파악할 때는 비즈니스 요구사항, 핵심 엔티티와 관계, 데이터 접근 패턴을 확인한다. 이후 사용자 요구에 맞는 쿼리 결과와 데이터 접근 경로를 설계하고, 쿼리 성능도 함께 고려한다.
데이터 모델링 단계에서는 선택한 NoSQL 유형에 맞는 구조, 접근 패턴 기반 인덱스, 비정규화 전략을 정한다. 이어서 성능 향상 기능, 확장성 계획, 데이터 일관성 전략을 목록화한다.
솔루션을 선정한 뒤에는 벤치마크 테스트로 성능을 검증하고 튜닝한다. 운영 환경 구성, 확장 전략, 백업과 복구 계획까지 정리해야 데이터 모델이 실제 인프라에서 작동한다.
ACID를 완화한 BASE 특성
NoSQL은 ACID 속성을 완화한 BASE 특성을 사용한다.
- Basically Available: 기본적인 가용성을 보장한다.
- Soft state: 상태가 시간에 따라 변할 수 있다.
- Eventually consistent: 최종적 일관성을 보장한다.
RDBMS와 NoSQL의 설계 차이
| 특성 | RDBMS | NoSQL |
|---|---|---|
| 확장성 | 수직적 확장(Scale-up) | 수평적 확장(Scale-out) |
| 스키마 | 엄격한 스키마 구조 | 유연한/없는 스키마(Schema-less) |
| 트랜잭션 | ACID 준수 | BASE 특성(완화된 ACID) |
| 데이터 모델 | 테이블, 관계 중심 | 다양한 모델(문서, 키-값, 컬럼, 그래프) |
| 쿼리 언어 | 표준화된 SQL | 제품별 API 또는 제한된 쿼리 언어 |
| 일관성 | 강한 일관성 | 최종적 일관성 또는 선택적 일관성 |
| 적합한 워크로드 | 트랜잭션 중심 애플리케이션 | 대용량 데이터, 실시간 웹 애플리케이션 |
서비스 데이터에 맞춘 활용 방식
소셜 미디어 플랫폼에서는 사용자 프로필과 게시물·댓글을 Document DB에 저장하고, 관계 정보는 Graph DB인 Neo4j로 처리할 수 있다. 세션 관리는 Key-Value DB인 Redis를 사용한다.
전자상거래 시스템에서는 제품 카탈로그에 Document DB, 장바구니 정보에 Key-Value DB, 고객 구매 내역에 Column-Family DB인 Cassandra, 추천 시스템에 Graph DB를 활용할 수 있다.
IoT 시스템에서는 InfluxDB 같은 Time-Series DB로 센서 데이터를 수집하고, 장치 상태 정보는 Key-Value DB에 저장한다. 데이터 분석에는 Column-Family DB를 활용한다.
NoSQL은 사용 사례별로 최적화된 데이터 모델을 제공한다. CAP 특성과 모델링 원칙을 함께 검토하고, 필요하다면 RDBMS와 NoSQL을 결합한 하이브리드 아키텍처로 시스템을 구성할 수 있다.