RDBMS와 NoSQL을 조합하는 데이터베이스 아키텍처 설계
RDBMS와 MongoDB·Cassandra·Redis의 데이터 모델, 일관성, 확장성 차이를 비교하고 워크로드별 데이터 계층 설계 기준을 정리한다.
2026-08-14 · 최초 발행 2025-10-14
데이터 저장소 선택은 워크로드에서 출발한다
데이터베이스 선택은 성능, 일관성, 확장성 사이의 균형을 정하는 일이다. 주문과 결제처럼 복잡한 트랜잭션이 필요한 경로, 유연한 문서 구조를 다루는 서비스, 대량 이벤트를 기록하는 파이프라인, 짧은 응답 시간이 필요한 캐시 계층은 요구하는 저장 방식이 다르다.
관계형 데이터베이스는 고정된 스키마와 SQL, ACID 트랜잭션을 중심에 둔다. MySQL과 PostgreSQL은 강한 일관성, 조인, 복잡한 질의에 강점이 있다. 반면 NoSQL은 비관계형 모델과 유연한 스키마, 수평 확장에 초점을 둔다. MongoDB는 문서지향, Cassandra는 와이드컬럼, Redis는 키-값 모델로 각기 다른 처리 패턴을 지원한다.
ACID와 BASE, CAP 정리를 실제 설계에 적용할 때는 읽기·쓰기 비율, 질의 복잡도, 데이터 볼륨, 일관성·가용성·지연시간 목표를 함께 봐야 한다. 하나의 저장소로 모든 요구를 해결하기보다 역할에 맞는 저장소를 조합하는 폴리글랏 퍼시스턴스가 적합할 수 있다.
데이터 모델과 일관성 정책이 만드는 차이
MySQL과 PostgreSQL은 정규화된 스키마, 외래키, 조인을 통해 도메인 무결성을 다룬다. 파티셔닝과 파티션 프루닝으로 대용량 처리도 지원한다.
MongoDB는 BSON 문서와 중첩·배열 모델을 사용하며, 애그리게이션 파이프라인 처리에 적합하다. 컬렉션 인덱스와 샤딩 키가 설계의 핵심이 된다. Cassandra는 질의 패턴을 먼저 정하고 파티션 키 중심으로 테이블을 설계한다. 타임시리즈와 로그처럼 쓰기가 많은 데이터에 맞는다. Redis는 String, Hash, Set, ZSet, Stream 같은 자료구조를 제공하는 메모리 중심 키-값 저장소로, 캐시·큐·세션에 사용된다.
트랜잭션의 성격도 다르다. RDBMS는 RC, RR, S, SSI 같은 격리수준을 설정할 수 있어 다중 행과 다중 테이블을 다루는 복잡한 트랜잭션에 적합하다. MongoDB는 단일 문서 원자성을 제공하며 멀티-도큐먼트 트랜잭션도 지원하지만 클러스터 비용이 증가한다. Cassandra는 ONE, QUORUM, ALL의 튜너블 일관성과 LWT를 통한 조건부 업데이트를 제공한다. Redis는 단일 스레드와 명령 단위 원자성을 기반으로 하며, MULTI/EXEC와 Lua 스크립트로 복합 연산을 구성한다.
복제와 확장 방식은 운영 모델까지 바꾼다
RDBMS는 리드 레플리카와 파티셔닝으로 확장한다. 글로벌 분산에는 포지드버퍼, Citus 같은 추가 엔진이 필요하다. MongoDB는 레플리카셋과 자동 샤딩을 내장해 수평 확장과 가용성 구성을 지원한다.
Cassandra는 마스터리스 링 구조를 사용하며 노드를 추가해 선형적으로 확장한다. 멀티 리전 활성-활성 구성에도 적합하다. Redis는 Cluster 기반 샤딩과 복제, Sentinel 또는 Cluster를 이용한 장애 조치를 제공하지만 메모리와 네트워크 한계를 고려해야 한다.
| 시스템 | 성능 | 확장성 | 일관성 | 안정성 | 운영 편의 |
|---|---|---|---|---|---|
| MySQL | 읽기/쓰기 균형 우수, 복잡 트랜잭션 강점 | 리드 레플리카·파티셔닝 | 강한 일관성, 격리수준 제어 | 성숙한 복구·백업 | 인력·도구 풍부 |
| PostgreSQL | 분석·JSONB·지리공간 강점 | 파티셔닝·Citus 등으로 확장 | 강한 일관성, 풍부한 타입/인덱스 | 확장성·안정성 뛰어남 | 표준 호환·운영 자동화 좋음 |
| MongoDB | 문서 모델 고성능, 파이프라인 처리 | 자동 샤딩·레플리카셋 | 멀티문서 트랜잭션 지원 | 고가용 구성 용이 | 스키마 유연, 도구 다양 |
| Cassandra | 쓰기·대량 데이터에 강함 | 마스터리스 선형 확장 | 튜너블 일관성 | 리전 분산 강력 | 운영 난이도 중간 이상 |
| Redis | 초저지연, 캐시/큐에 최적 | Cluster로 수평 확장 | 키 단위 원자성 | Sentinel/Cluster로 HA | 운영 단순, 메모리 관리 유의 |
서비스 계층에서 저장소를 라우팅하는 구조
요구사항을 데이터 계층 설계로 연결하기
먼저 일관성·가용성·지연시간 목표와 읽기·쓰기 비율, 데이터 볼륨·성장률, 질의 복잡도를 수집한다. 거래·보고·조인이 중심이면 RDBMS를, 문서·이벤트와 스키마 유연성이 중요하면 MongoDB를, 타임시리즈·대용량 쓰기·글로벌 분산에는 Cassandra를, 캐시·세션·큐에는 Redis를 검토한다.
선택 뒤에는 저장소별 모델을 구체화한다. RDBMS는 정규화와 핵심 쿼리 인덱스를, MongoDB는 문서 경계와 샤딩 키를, Cassandra는 파티션·클러스터링 컬럼을, Redis는 키 네임스페이스와 TTL을 설계한다. 이어 격리수준, Write Concern, Consistency Level, 재시도와 아이들포텐시 키를 정한다.
레플리카와 샤드 토폴로지, 스냅샷·Point-in-Time Recovery, 장애 조치 절차도 설계 대상이다. 전송구간 TLS와 저장구간 암호화(KMS), 인증·권한, 감사로그, PII 마스킹·행 수준 보안을 포함하고, p95 지연과 오류율 SLO, 트레이싱, 마이그레이션 파이프라인, 용량 및 비용 모니터링으로 운영 상태를 관찰한다.
저장소별로 맞는 업무 경로
MySQL과 PostgreSQL은 주문·결제·재고처럼 외래키와 제약조건으로 무결성을 관리해야 하는 트랜잭션 시스템에 맞는다. PostgreSQL의 윈도 함수·CUBE, JSONB 혼합 모델은 분석과 리포팅 경로에도 활용할 수 있다. 멀티테넌시는 스키마 분리 또는 파티셔닝과 Row-Level Security로 구성한다.
MongoDB는 제품 카탈로그와 콘텐츠 관리처럼 속성이 달라지고 스키마가 진화하는 데이터에 적합하다. 이벤트 수집과 실시간 대시보드에는 TTL과 애그리게이션 파이프라인을 사용할 수 있으며, Read Preference와 샤딩은 지역 분산 읽기 지연을 낮추는 데 쓰인다.
Cassandra는 시간과 엔티티를 조합한 파티션 키로 타임시리즈, 로그, IoT 텔레메트리를 저장하는 경로에 적합하다. 다중 리전 활성-활성 환경에서는 각 리전의 쓰기를 허용하고 튜너블 일관성으로 지연을 조절한다. SLA에 민감한 쓰기 경로에서는 LWT로 조건부 업데이트를 적용하고 중복 데이터를 허용할 수 있다.
Redis는 캐시 미스 때 원장을 조회한 뒤 SET+TTL로 채우는 캐시-어사이드 패턴, INCR/EXPIRE와 Lua 스크립트 기반 세션·레이트 리밋, Redis Streams와 소비자 그룹을 이용한 실시간 큐에 활용된다.
각 제품에서 확인할 수 있는 기본 작업
전제: MySQL 8.0+, PostgreSQL 15+, MongoDB 6.x, Apache Cassandra 4.x, Redis 7.x. 각 DB 클라이언트 셸 또는 드라이버 사용 가능 환경.
-- 공통 SQL(약간의 차이 존재)
CREATE TABLE orders (
id BIGSERIAL PRIMARY KEY,
user_id BIGINT NOT NULL,
amount NUMERIC(12,2) NOT NULL,
status VARCHAR(16) NOT NULL,
created_at TIMESTAMP NOT NULL DEFAULT NOW()
);
CREATE INDEX idx_orders_user_created ON orders(user_id, created_at);
BEGIN;
INSERT INTO orders(user_id, amount, status) VALUES (1001, 49.90, 'NEW');
UPDATE accounts SET balance = balance - 49.90 WHERE user_id = 1001;
-- 검증 로직 후
COMMIT;
-- 오류 시
-- ROLLBACK;// mongosh
db.orders.createIndex({ userId: 1, createdAt: -1 });
db.orders.insertOne({
userId: 1001,
amount: 49.9,
status: "NEW",
items: [{ sku: "A1", qty: 1 }],
createdAt: new Date(),
});
// 집계
db.orders.aggregate([
{ $match: { userId: 1001 } },
{ $group: { _id: "$status", total: { $sum: "$amount" } } },
]);-- cqlsh
CREATE KEYSPACE shop WITH replication = {'class': 'NetworkTopologyStrategy', 'dc1': 3};
USE shop;
CREATE TABLE orders_by_user (
user_id bigint,
created_at timestamp,
order_id uuid,
amount decimal,
status text,
PRIMARY KEY ((user_id), created_at, order_id)
) WITH CLUSTERING ORDER BY (created_at DESC);
CONSISTENCY QUORUM;
INSERT INTO orders_by_user(user_id, created_at, order_id, amount, status)
VALUES (1001, toTimestamp(now()), now(), 49.90, 'NEW');# redis-cli
# 캐시 조회 실패 가정 -> 원장 조회 후 세팅
SET user:1001:profile '{"name":"Kim","tier":"gold"}' EX 600
# 레이트 리밋(분당 100)
INCR user:1001:rl:202509231510
EXPIRE user:1001:rl:202509231510 60
# 트랜잭션으로 재고 차감
MULTI
DECRBY stock:sku:A1 1
SADD orders:user:1001 A1
EXEC운영에서 드러나는 트레이드오프
RDBMS의 마이그레이션 파이프라인에는 락 최소화 전략과 온라인 인덱스를 고려한다. MongoDB와 Cassandra는 샤딩 키 변경 난이도가 높으므로 초기부터 액세스 패턴을 기준으로 설계해야 한다. 스키마 유연성은 쿼리 최적화 비용과 맞바꿀 수 있다.
일관성 설정도 운영 비용을 만든다. RDBMS에서 격리수준을 높이면 잠금 경합이 증가할 수 있다. MongoDB와 Cassandra에서 낮은 일관성을 선택하면 읽기 최신성이 낮아질 수 있다. Redis는 AOF fsync 정책에 따라 지연과 내구성이 절충된다.
수직 확장(RDBMS)과 수평 확장(NoSQL)은 비용과 운영 복잡성이 다르다. 캐시 계층은 원장 부하를 30~70% 절감 가능하지만 워크로드 의존성이 있으므로 사전 벤치마크가 필요하다. 콜드 스타트와 리밸런싱 비용도 함께 고려한다. PII와 결제 데이터에는 토큰화·마스킹, 행·열 수준 접근 제어를 적용한다.
캐시-어사이드 적용 시 p95 읽기 지연은 3080% 감소 가능하다. 쓰기 집중 파이프라인을 Cassandra로 분리하면 쓰기 처리량이 25배 향상된 사례가 다수 있다. 레플리카·샤딩·오토 페일오버는 RTO/RPO 목표 달성을 쉽게 하며, 튜너블 일관성은 지연과 정확성의 균형을 제어한다.
백업·모니터링·스키마 관리 도구 체인은 릴리즈 리드타임 단축에 기여한다. 핫/콜드 저장소 계층화와 TTL·압축을 적용하면 스토리지를 20~50% 절감 가능하다. MVP 단계에서는 RDBMS와 Redis 캐시로 단순화하고, 데이터 모델이 안정화된 뒤 MongoDB 또는 Cassandra 확장을 검토할 수 있다. 운영 단계에서는 인덱스·샤딩·캐시 정책을 모니터링 기반으로 조정하고 백업·DR·보안 자동화를 갖춘다.