14장 : NoSQL과 분산 데이터베이스
RDB vs NoSQL 선택 기준
RDB와 NoSQL은 어느 쪽이 우월한 것이 아니라, 데이터 모델과 접근 패턴에 따라 적합한 선택이 달라집니다. 실제 현장에서 데이터베이스를 선택할 때는 정합성, 쿼리 형태, 확장 방식, 운영 역량, 비용을 함께 봐야 하며, 하나의 서비스 안에서도 여러 저장소를 조합하는 경우가 많습니다.
데이터베이스 선택은 변경 비용이 큰 아키텍처 결정입니다. 다만 처음부터 모든 미래를 맞히려 하기보다, 현재 요구사항을 단순하게 만족시키면서 이후 분리와 확장이 가능한 경계를 남기는 것이 현실적인 접근입니다.
데이터 구조에 따른 선택
데이터의 형태는 데이터베이스 선택의 가장 기본적인 기준입니다.
| 데이터 특성 | RDB 관점 | NoSQL 관점 |
|---|---|---|
| 정형 데이터(테이블 구조) | 제약 조건, 조인, 트랜잭션에 강함 | 가능하지만 모델 이점을 덜 살릴 수 있음 |
| 반정형 데이터(JSON, XML) | JSON 타입과 인덱스로 처리 가능 | Document DB가 문서 경계를 자연스럽게 표현 |
| 비정형/대량 이벤트 데이터 | 저장 가능하지만 모델링 부담 존재 | Key-Value, Wide-Column, 검색/시계열 DB 검토 |
| 관계 중심 데이터 | 조인과 재귀 쿼리로 처리 | 다단계 관계 탐색은 Graph DB가 자연스러움 |
선택 의사결정 플로
정형 데이터와 RDB
특징:
* 데이터 구조가 명확하고 변경이 드묾
* 행과 컬럼으로 자연스럽게 표현됨
* 무결성 제약이 중요
* 복잡한 관계와 조인이 필요
예시:
* 회계 시스템: 차변/대변의 엄격한 구조
* 인사 관리: 사원-부서-급여의 정형 관계
* 은행 시스템: 계좌-거래의 ACID가 필수인 구조
* ERP: 업무 프로세스가 정형화된 시스템반정형 데이터와 Document DB
특징:
* JSON/BSON 형태의 유연한 구조
* 같은 컬렉션 내 문서마다 구조가 다를 수 있음
* 스키마 변경이 잦음
* 중첩된 데이터 구조
예시:
* 상품 카탈로그: 카테고리마다 속성이 다름
전자기기: {화면크기, 해상도, 무게}
의류: {사이즈, 색상, 소재}
식품: {유통기한, 원산지, 알레르기 정보}
* CMS: 게시글마다 구조가 다른 콘텐츠
* 설정 관리: 계층적 JSON 설정 데이터읽기/쓰기 비율에 따른 선택
애플리케이션의 워크로드 패턴은 데이터베이스 성능에 직접적인 영향을 줍니다.
| 패턴 | 자주 쓰는 선택지 | 이유/주의점 |
|---|---|---|
| 읽기 >> 쓰기(조회 위주) | RDB + 인덱스 + 캐시(Redis 등) | 원본 정합성은 RDB, 반복 조회는 캐시로 분리 |
| 쓰기 >> 읽기(로그, IoT) | Wide-Column, 시계열 DB, 이벤트 로그 | 파티션과 배치 쓰기, 보존 기간 설계가 중요 |
| 읽기 ≈ 쓰기(SNS, 피드) | RDB + 캐시/큐 또는 Document/Key-Value | 기능별로 읽기 모델과 쓰기 모델을 나눌 수 있음 |
| 저지연 키 접근 | Redis/Valkey, Memcached, DynamoDB | 메모리/키 기반 접근은 빠르지만 데이터 모델 제약 존재 |
읽기 위주 시스템 최적화
쓰기 위주 시스템 최적화
대량 쓰기 사례:
* IoT 센서 데이터: 초당 수만 건
* 로그 수집: 모든 사용자 행동 기록
* 시계열 데이터: 주식 호가, 서버 메트릭
RDB의 한계:
* 단일 마스터에 쓰기 집중
* 트랜잭션 오버헤드
* 인덱스 유지 비용
NoSQL/분산 저장소에서 자주 쓰는 접근:
* 여러 노드에 쓰기 분산 (Cassandra)
* 배치 쓰기 최적화
* 시간 기반 파티셔닝 (시계열 DB)일관성 vs 가용성
CAP 정리는 네트워크 분할이 생긴 분산 시스템에서 일관성과 가용성을 동시에 완전하게 유지하기 어렵다는 관점입니다. 비즈니스 요구에 따라 강한 읽기, 트랜잭션, quorum, 최종 수렴, 리전 전략 중 어디에 무게를 둘지 결정해야 합니다.
| 요구사항 | 자주 쓰는 선택지 | 읽는 법 |
|---|---|---|
| 강한 일관성 필수(금융, 결제) | RDB, NewSQL/분산 SQL | 트랜잭션 경계와 장애 시 쓰기 정책이 중요 |
| 최종적 일관성 허용(SNS, 로그) | Key-Value, Document, Wide-Column, 이벤트 로그 | 응답성과 수렴 시간, 보정 정책을 함께 설계 |
| 일관성 + 수평 확장 모두 필요 | Spanner, CockroachDB, TiDB 등 | 강한 일관성의 지연 시간과 운영 비용을 검토 |
| 멀티 리전 가용성과 일관성 조절 | DynamoDB Global Tables, Cosmos DB 등 | 구성에 따라 consistency mode/level이 달라짐 |
일관성이 필수인 경우
최종적 일관성이 허용되는 경우
1. SNS 타임라인
게시물이 A에게는 보이고 B에게는 아직 안 보여도 괜찮음
몇 초 후에는 결국 모든 사용자에게 보임
→ 최종적 일관성으로 충분
2. 좋아요 카운터
정확한 실시간 수치가 아니어도 됨
"약 1.2만"처럼 근사값이면 충분
→ 비동기 집계로 성능 확보
3. 로그 수집
일부 로그가 순서가 바뀌어도 분석에 큰 영향 없음
→ 쓰기 성능이 더 중요확장성에 따른 선택
폴리글랏 퍼시스턴스
폴리글랏 퍼시스턴스(Polyglot Persistence)는 서비스의 각 부분에 맞는 데이터베이스를 조합하는 전략입니다. 마이크로서비스에서 자주 보이지만, 단일 서비스 안에서도 원본 DB, 캐시, 검색 인덱스, 분석 저장소를 역할별로 나누는 형태로 나타납니다.
폴리글랏 퍼시스턴스의 장단점
장점:
* 각 영역에 맞는 DB를 사용하여 모델과 성능을 맞추기 쉬움
* 서비스별 독립적 확장 가능
* 읽기 모델, 검색, 분석 부하를 원본 트랜잭션에서 분리 가능
단점:
* 여러 DB의 운영/모니터링 복잡도 증가
* DB 간 데이터 동기화 필요
* 팀 전체가 여러 DB 기술을 알아야 함
* 분산 트랜잭션 처리 어려움
도입 시점:
* 시작은 단순한 주 저장소 하나로 유지
* 특정 영역의 모델/성능 한계가 분명해지면 해당 영역만 분리
* "만약을 위해 미리" 도입하는 것은 권장하지 않음마이그레이션 비용
데이터베이스 선택에서 종종 간과되는 것이 마이그레이션 비용입니다. 처음 선택한 DB에서 다른 DB로 전환하는 것은 단순히 데이터를 옮기는 일이 아니라, 데이터 모델, 쿼리, 인덱스, 트랜잭션 경계, 운영 절차를 함께 바꾸는 일입니다.
마이그레이션 전략
비용과 운영 관점
모니터링:
RDB: 성숙한 도구 생태계 (pg_stat, MySQL Enterprise Monitor)
NoSQL: 제품마다 다른 도구와 관리 콘솔 (MongoDB Compass, Redis Insight 등)
백업/복구:
RDB: 표준화된 백업 방식 (pg_dump, mysqldump, RMAN)
NoSQL: 제품별 고유한 백업 방식, 분산 환경 고려 필요
트러블슈팅:
RDB: 실행 계획(EXPLAIN), 슬로우 쿼리 로그 등 검증된 도구
NoSQL: 제품마다 다른 분석 방법, 분산 이슈 디버깅 어려움
보안:
RDB: 성숙한 접근 제어 (GRANT/REVOKE), 감사 로그
NoSQL: 제품별 인증, 권한, 암호화, 감사 기능을 별도로 확인해야 함자주 하는 실수
1. "스케일 문제를 미리 대비하자" → NoSQL 선택
현실: 병목이 읽기인지, 쓰기인지, 저장량인지 아직 모르면 선택이 빗나가기 쉬움
RDB + 인덱스 + 캐시 + 읽기 복제로 충분한 단계가 많음
→ 실제 병목과 접근 패턴을 확인한 뒤 분리해도 늦지 않은 경우가 많음
2. "NoSQL이 최신이니까 더 좋겠지" → 트렌드 추종
새로운 제품이 항상 더 단순하거나 더 안정적인 것은 아님
팀의 운영 경험, 장애 대응, 데이터 모델 적합성이 더 중요
→ 요구사항에 맞는 기술이 최고의 기술
3. "조인이 느리니까 NoSQL로" → 잘못된 진단
조인이 느린 원인은 대부분 인덱스 부재 또는 잘못된 쿼리
NoSQL로 바꿔도 데이터 모델링을 잘못하면 더 느림
→ RDB에서 쿼리 튜닝을 먼저 시도
4. "MongoDB는 스키마가 없으니 편하다" → 착각
유연한 스키마는 장점이지만, 검증과 버전 관리는 여전히 필요
MongoDB도 JSON Schema 기반 validation을 제공하므로 필요하면 DB 레벨 검증을 함께 사용
→ 스키마 유연성이 진짜 필요한지 확인
5. "팀에 경험자가 없지만 문서를 보며 하면 되겠지"
운영 중 장애 대응은 경험이 핵심
프로덕션에서 처음 써보는 DB는 높은 위험
→ 팀의 역량과 경험을 중요한 선택 기준으로클라우드 시대의 DB 선택
AWS:
* RDS (MySQL, PostgreSQL, Oracle, SQL Server)
* Aurora (RDB, MySQL/PostgreSQL 호환)
* DynamoDB (Key-Value/Document)
* ElastiCache (Redis/Memcached)
* Neptune (Graph)
GCP:
* Cloud SQL (MySQL, PostgreSQL, SQL Server)
* Spanner (분산 SQL, 글로벌/멀티리전 구성)
* Firestore (Document)
* Bigtable (Wide-Column)
* Memorystore (Redis/Valkey/Memcached 계열 관리형 인메모리)
Azure:
* Azure SQL Database
* Azure Cosmos DB (NoSQL/문서, MongoDB API 등 다양한 API와 consistency level)
* Azure Cache for Redis / Azure Managed Redis
매니지드 서비스 장점:
* 설치, 패치, 백업 자동화
* 고가용성(HA) 구성 선택지 제공
* 모니터링 대시보드 내장
* 일부 서비스는 스케일 업/아웃과 리전 구성을 관리형 기능으로 제공
매니지드 서비스 고려사항:
* 벤더 종속(Lock-in) 위험
* 세밀한 튜닝이 제한될 수 있음
* 비용이 셀프 호스팅보다 높을 수 있음
* 서비스별 consistency, 백업, 장애 조치 정책이 다름실전 선택 가이드
실제 프로젝트에서 DB를 선택할 때는 기술적 요인뿐 아니라 팀 역량, 비용, 운영 부담 등 비기술적 요인도 함께 고려해야 합니다.
업종별 권장 아키텍처
조합 1: PostgreSQL + Redis
→ 대부분의 웹 서비스에서 충분
→ RDB로 핵심 데이터, Redis로 캐시/세션
조합 2: PostgreSQL + Elasticsearch
→ 검색 기능이 중요한 서비스
→ RDB로 원본 데이터, ES로 검색 인덱스
조합 3: MySQL + MongoDB + Redis
→ 데이터 특성이 다양한 중대형 서비스
→ RDB로 핵심 비즈니스, MongoDB로 유연한 데이터, Redis로 캐시핵심 정리
업무형 CRUD 웹 서비스는 RDB를 중심으로 시작해도 충분한 경우가 많습니다. NoSQL은 RDB가 감당하기 어려운 규모, 데이터 모델, 지연 시간, 지역 분산 요구가 분명할 때 도입하는 것이 바람직합니다.
다음 장에서는 실운영 환경에서의 데이터베이스 운영을 다루겠습니다.