NoSQL vs RDBMS, 무엇을 언제 선택할까?

한 줄 요약: “스키마가 안정적이고 트랜잭션이 중요하면 RDBMS, 데이터 형태가 다양하고 폭발적으로 커지며 액세스 패턴이 명확하면 NoSQL. 단, 현실 세계에선 둘을 함께 쓰는 폴리글랏 퍼시스턴스가 정답인 경우가 많다.”

---

이 글을 읽으면 얻는 것

• RDBMS와 NoSQL의 본질적인 차이
• ACID vs BASE, CAP/PACELC까지 핵심 이론 한 번에 정리
• 도메인별(전자상거래, 소셜 피드, IoT, 로그, 금융 등) 추천 아키텍처
• 설계/운영 관점의 체크리스트와 데이터베이스 의사결정 매트릭스

---

1. 기본 개념부터 빠르게 정렬

1.1 RDBMS란?

• 정의: 관계형 데이터베이스 관리 시스템. 테이블(행/열), 명시적 스키마, SQL 쿼리, 정규화된 모델.
• 특징: 강력한 트랜잭션(ACID), 조인, 제약조건(외래키, 유니크 등), 일관된 쿼리 최적화.
• 대표: MySQL, PostgreSQL, Oracle, SQL Server 등.

1.2 NoSQL이란?

• 정의: “Not Only SQL”. 비관계형 DB들의 포괄적 분류.
• 주요 타입
  • 문서지향: MongoDB, Couchbase
  • 키-값: Redis, DynamoDB
  • 컬럼지향(와이드 컬럼): Cassandra, HBase
  • 그래프: Neo4j, JanusGraph
• 특징: 스키마 유연성, 수평 확장 용이, 특정 액세스 패턴에 최적화.

---

2. ACID vs BASE: 일관성과 유연성의 줄다리기

RDBMS(ACID) VS NoSQL(BASE)

트랜잭션	원자성/일관성/격리성/지속성 보장	기본은 최종적 일관성 지향(엔진별 설정차 존재)
스키마	스키마 온 라이트(쓰기 전 구조 고정)	스키마 온 리드(읽을 때 구조 해석) 경향
조인	강력, 복잡 쿼리 유리	문서 내 중첩/중복으로 조인 최소화 설계
확장	수직 확장 중심(수평도 가능하지만 복잡)	수평 확장에 강함(샤딩·파티셔닝 내장/권장)
사용 예	금융, 주문/결제, ERP, 재고, 백오피스	대규모 이벤트/로그, 카탈로그, 피드, IoT

 

현실에서는 “ACID가 절대적으로 좋거나, BASE가 절대적으로 좋은게” 아니라 요구사항에 따른 균형점을 찾는 작업이 핵심입니다.

 

4. 데이터 모델링: 정규화 vs 비정규화

4.1 RDBMS의 모델링

• 정규화로 중복 최소화, 조인으로 재조합.
• 장점: 데이터 무결성, 변경 용이(스키마 변경은 명시적).
• 주의: 읽기 경로가 길어지면 조인이 많아져 성능·복잡도가 상승.

4.2 NoSQL의 모델링(문서지향 예시: MongoDB)

• 읽기 패턴 위주 설계: 한 번 조회에 필요한 정보를 문서 하나에 최대한 담기.
• 비정규화와 중첩 문서/배열 적극 활용.
• 장점: 단건 읽기 빠름, 수평 확장 용이.
• 주의: 중복된 데이터 업데이트 일관성 관리 필요, 문서 크기 제한(예: MongoDB는 문서 크기 16MB 제한) 고려.

---

6. 확장성·가용성·지연: 운영에서 갈리는 승부

RDBMS Vs NoSQL

수평 확장	샤딩/파티셔닝 가능, 구현 복잡	보통 1급 시민 기능(자동/반자동 분산)
수직 확장	매우 익숙하고 안정적	가능하지만 목표는 수평 확장
복제	동기/비동기 선택, 읽기 스케일아웃	레플리카 세트/클러스터 운영 상시
Failover	성숙한 도구 다수(RDS/Aurora 등)	매니지드(Atlas 등)로 비교적 용이
지연	단건 트랜잭션 최적	대량 쓰기/읽기 분산에 유리

MySQL도 Vitess, ProxySQL, 파티셔닝으로 수평 확장이 가능하고, MongoDB도 트랜잭션/조인($lookup)·2차 인덱스가 있어 전통적 모델도 어느 정도 흉내냅니다. 양 진영의 경계가 좁혀지는 중이지만, “기본 철학”은 여전히 선택을 가릅니다.

---

7. 비용/운영/생태계

• 비용: 단일 RDBMS 인스턴스는 상대적으로 저렴하게 시작 가능. 데이터가 폭증하면 NoSQL의 수평 확장이 비용/성능 비율을 높일 수 있음. 다만 네트워크 비용, 노드 수, 모니터링·백업·보안 등 총소유비용(TCO)을 반드시 포함해 비교.
• 운영 난이도: 매니지드 서비스(AWS RDS/Aurora, Cloud SQL, MongoDB Atlas 등) 활용 시 초기 장벽 급락. 자가 운영은 백업/복구/모니터링/보안/스키마/샤딩 모두가 난이도 포인트.
• 생태계: ORM/JPA, BI, 리포팅, ETL은 RDBMS에 풍부. NoSQL도 드라이버·ODM·스트리밍 연계가 좋고, 이벤트·로그·IoT·캐시 등 클라우드 네이티브 워크로드에 친화적.

---

8. 도메인별 추천 시나리오

8.1 전자상거래(주문/결제/정산)

• 권장: RDBMS 중심(주문/결제/재고/정산), 제품 카탈로그·리치한 속성은 문서형에 보조 저장.
• 이유: 강한 트랜잭션과 정합성이 핵심. 카탈로그는 속성 다양성·검색 필요가 크므로 문서지향/검색엔진과 궁합이 좋음.
• 아키텍처 예:
  • Core OLTP: MySQL
  • 제품 카탈로그/리치 콘텐츠: MongoDB
  • 검색/랭킹: OpenSearch/Elasticsearch
  • 이벤트: Kafka(비동기 파이프)

8.2 소셜 피드/메시지 타임라인

• 권장: 문서지향/키-값 중심 + 캐시.
• 이유: 읽기 패턴이 명확, 쓰기 폭증, 낮은 지연 요구. 일부 최종적 일관성 허용.
• 아키텍처 예:
  • 피드 스토리지: MongoDB, Cassandra
  • 캐시: Redis
  • 백업/오프라인 분석: Data Lake + 컬럼 스토어(예: ClickHouse)

8.3 IoT/로그/이벤트 텔레메트리

• 권장: 와이드 컬럼/문서형/타임시리즈.
• 이유: 쓰기량 폭증, TTL/압축/수평 확장 필수. 스키마가 자주 변하고 속성 다양.
• 아키텍처 예:
  • 수집: Kafka
  • 저장: MongoDB(TTL 인덱스), Cassandra, 타임시리즈DB
  • 대시보드/알람: 시계열 쿼리 특화 도구

8.4 금융/회계/정산/권한감사

• 권장: RDBMS.
• 이유: 강한 일관성과 회계적 무결성, 트랜잭션/잠금, 감사 추적 필요.
• 보조: 이벤트 소싱 로그를 NoSQL/오브젝트 스토리지에 장기 보관은 가능.

8.5 콘텐츠 관리·카탈로그·프로필

• 권장: 문서지향.
• 이유: 콘텐츠 속성이 수시로 늘고 필드가 계층적. 문서 단위 읽기/쓰기 최적.

8.6 분석/리포팅/OLAP

• 권장: 컬럼 스토어·데이터 웨어하우스(BigQuery, Snowflake, Redshift, ClickHouse).
• 이유: 대량 스캔·집계·조인에 최적화. 운영 DB(OLTP)와 분리 권장.

8.7 그래프 중심(추천, 상관관계, 경로 탐색)

• 권장: 그래프 DB(Neo4j 등) 또는 그래프 엔진이 얹힌 분석 파이프라인.
• 이유: 관계 탐색의 깊이가 핵심 성능요소.

---

9. 의사결정 매트릭스(빠른 판단용)

점수가 높을수록 해당 기술에 적합하다는 의미입니다.
(0=해당 없음, 5=매우 중요)

 

RDBMS 점수 VS NoSQL 점수

강한 일관성	“트랜잭션과 무결성이 가장 중요?”	5	2
스키마 안정성	“스키마가 안정적이고 규칙적?”	5	2
액세스 패턴 명확성	“조회가 문서 단위로 딱 떨어짐?”	2	5
데이터 다양성	“필드가 수시로 늘고 불규칙?”	2	5
쓰기 확장성	“수평 확장이 필수?”	3	5
조인 복잡도	“다중 테이블 조인이 많음?”	5	2
지연 민감도	“몇 ms 단위 응답 필요?”	3	5
운영 성숙도	“ORM/리포팅/BI 연계 필요?”	5	3
팀 역량	“SQL/정규화에 팀이 강함?”	5	3
비용 모델	“노드 수 확장 대비 TCO는?”	3	4

총점이 RDBMS 쪽이면 RDBMS 중심 + 보조 NoSQL, 반대면 NoSQL 중심 + 보조 RDBMS를 기본 가정으로 검토하세요.

---

12. 실전 예시 5가지

12.1 주문/결제 시스템

• 핵심 요구: 원자성, 재고 일관성, 동시성 제어, 회계 감사.
• 권장: MySQL로 주문/결제/재고 트랜잭션 처리.
  상품 상세·리치 콘텐츠는 MongoDB에 저장, 검색엔진으로 색인.
• 장점: 결제 오류/중복/경합 최소화, 검색·필터링·피드 노출은 빠르게.

12.2 소셜 타임라인

• 핵심 요구: 저지연, 대규모 팬아웃, 고가용성.
• 권장: MongoDB/Cassandra에 타임라인 문서 저장, Redis 캐시.
  백그라운드로 추천/랭킹 처리, 읽기 최적화된 뷰 생성.
• 주의: “좋아요 수” 카운팅은 이벤트 합산형 설계(레이시 업데이트+주기적 정합).

12.3 IoT 텔레메트리

• 핵심 요구: 쓰기 폭증, TTL, 시계열 집계.
• 권장: 문서형(TTL 인덱스) 또는 와이드컬럼(파티션 키에 시간 축), 시계열 특화 DB.
  장기 보관은 오브젝트 스토리지로 이동.

12.4 사내 백오피스/ERP

• 핵심 요구: CRUD 안정성, 리포팅, 스키마 명확.
• 권장: RDBMS 단일 소스, BI/리포팅 도구 연계.
  점진적 확장 시 읽기 전용 마테리얼라이즈드 뷰를 문서형/캐시에 복제.

12.5 이벤트 로그·감사 추적

• 핵심 요구: 대량 Append, 보관/검색.
• 권장: 수집(Kafka) → 저장(문서형 또는 컬럼 스토어) → 분석/서치(OpenSearch/ClickHouse).
  규정 준수 항목은 RDBMS에도 핵심 스냅샷 저장.

---

16. 마이그레이션 전략

16.1 RDBMS → NoSQL

1. 액세스 패턴 분석: 가장 빈도 높은 쿼리들을 추출.
2. 문서 스키마 제안: 한 요청=한 문서 원칙으로 모델링.
3. 데이터 동기화: CDC(Change Data Capture)로 이중 쓰기/소비.
4. 읽기 경로 전환: 점진적 트래픽 스위칭, 오류/지연 모니터링.
5. 정리: 일관성 검증 후 기존 경로 줄이기.

16.2 NoSQL → RDBMS

1. 정규화 설계: 핵심 엔터티/관계 도출, 제약조건 명확화.
2. 키 설계: PK/FK, 유니크 인덱스, 트랜잭션 경계를 정의.
3. 이행: 일괄 마이그레이션 + 검증 쿼리, 트랜잭션 테스트.
4. 보고/리포팅: BI·리포트 파이프라인을 RDBMS에 정착.

---

18. 체크리스트: 선택 전 최종 점검

• 트랜잭션 경계가 어디까지 필요한가?
• 조인 복잡도와 보고/리포팅 요구는?
• 액세스 패턴이 문서 단위로 명확한가?
• 데이터 크기 증가율과 피크 트래픽은?
• 스키마 변화 빈도는 어느 정도인가?
• 팀의 숙련도와 운영 도구/매니지드 서비스는?
• 보안/규정/감사 요구사항은?
• 다운타임 허용 범위와 마이그레이션 계획은?
• TCO(인스턴스 + 네트워크 + 스토리지 + 운영 인력)는?
• 장애/분할/복구 시 의사결정(일관성 vs 가용성)은?

---

20. 결론: “둘 중 하나”가 아니라 “둘 다”일 때가 많다

• RDBMS는 일관성과 트랜잭션의 왕좌를 지키며, 스키마가 안정적인 업무 시스템(OLTP)에 매우 강합니다.
• NoSQL은 스키마 유연성과 수평 확장을 무기로 대량 쓰기/읽기, 문서 중심 액세스, 다양한 속성 데이터에 최적입니다.
• 현실에서는 폴리글랏 퍼시스턴스, CQRS, 이벤트 소싱 등으로 역할을 분담해 성능·일관성·개발 생산성을 동시에 잡습니다.
• 선택은 도메인 요구사항과 운영 역량, 비용 모델, 성장 곡선을 모두 고려한 엔지니어링 판단입니다. 위의 체크리스트/매트릭스를 팀 회의 자료로 써도 손색 없습니다.

---

21. 부록: 빠른 추천 표

상황	추천
결제/정산/회계/권한	RDBMS 중심(보조로 이벤트 로그/검색엔진)
대용량 로그/IoT/피드	NoSQL 중심 + 캐시 + 오브젝트 스토리지
카탈로그/프로필	문서지향 + 검색엔진
복잡 리포팅/집계	컬럼 스토어/웨어하우스(OLTP와 분리)
스타트업 초기 MVP	RDBMS로 빠르게 시작, 필요 시 NoSQL 보조
초고도 트래픽 읽기	NoSQL 읽기 뷰 + 캐시 + 비동기 파이프
그래프 탐색	그래프 DB 또는 분석 파이프라인 병행

---

마지막으로, “DB 종류 선택은 정답은 비즈니스 요구가 정한다”는 말을 꼭 남기고 싶습니다. 데이터베이스는 도구일 뿐이고, 좋은 설계는 도구의 장단을 이해한 다음 문제를 단순하게 만들어 해결하는 데서 시작합니다.

---

태그: NoSQL,RDBMS,데이터베이스설계,MySQL,MongoDB,CAP이론,ACID,스키마설계,수평확장,CQRS