NoSQL: 스키마 없는 데이터베이스가 필요했던 이유
관계형 DB의 한계를 넘어서려 나온 NoSQL의 CAP·BASE 설계 원칙, 키-값·문서형·컬럼·그래프 저장 모델과 실제 도입 사례를 정리한다.
2026-08-13 · 최초 발행 2025-05-23
SQL만으로는 감당이 안 될 때 나온 대안
NoSQL은 Not Only SQL의 약자로, 기존 관계형 데이터베이스(RDBMS)의 한계를 극복하려고 등장한 데이터베이스 패러다임이다. 빅데이터, 클라우드 컴퓨팅, 실시간 웹 애플리케이션이 늘면서 데이터 처리 요구사항이 바뀐 데 따라 발전했고, 비관계형·분산 데이터 저장소로서 스키마 없이 데이터를 저장·처리할 수 있다.
관계형 DB가 감당 못하게 된 것들
기존 RDBMS는 수직적 확장(Scale-up)만 가능해 대용량 데이터를 처리하려면 비용이 늘고, 엄격한 스키마 탓에 유연성이 부족했다. 복잡한 쿼리·조인 작업에서는 성능이 떨어졌고, 고가용성과 파티셔닝에도 제약이 있었다.
반면 웹 2.0과 빅데이터 시대는 대용량 데이터를 효율적으로 저장·처리하고, 비정형 데이터를 다루며, 수평적 확장(Scale-out)으로 분산 처리하고, 고가용성과 장애 허용성, 실시간 처리·응답 속도를 요구했다. NoSQL은 이 요구사항을 채우려고 나왔고, 2000년대 중반부터 구글·아마존·페이스북 같은 대형 IT 기업이 자체 NoSQL 솔루션을 개발하기 시작했다.
설계를 떠받치는 축들
NoSQL 데이터베이스는 대개 CAP 이론에 기반해 설계된다. 분산 시스템에서 일관성(Consistency), 가용성(Availability), 분할 내성(Partition Tolerance) 세 가지를 동시에 만족할 수 없다는 이론으로, NoSQL 데이터베이스는 보통 CA·AP·CP 중 두 가지를 선택한다.
일관성을 일부 희생하는 대신 BASE 속성을 따르는 경우도 많다. Basically Available(기본적인 가용성 보장), Soft state(일시적 불일치 허용), Eventually consistent(최종적 일관성 보장)로, ACID의 원자성·일관성·격리성·지속성과 대비되는 개념이다.
스키마리스(Schema-less) 설계도 특징이다. 미리 정의된 스키마 없이 데이터를 저장할 수 있어 필드 추가·삭제가 자유롭고, 데이터 모델이 바뀌어도 마이그레이션 비용이 적다.
수평적 확장성(Horizontal Scalability)도 핵심이다. 서버를 추가해 시스템 용량을 선형적으로 늘릴 수 있고, 샤딩(Sharding)과 복제(Replication)로 분산 처리하며 하드웨어 비용 효율을 높인다.
저장 모델에 따라 갈라지는 종류
키-값(Key-Value) 데이터베이스는 가장 단순한 형태로, 키와 값의 쌍으로 데이터를 저장한다. 읽기·쓰기 성능이 빠르고 확장성이 높다. Redis, Amazon DynamoDB, Riak이 대표적이다.
문서형(Document) 데이터베이스는 JSON, BSON, XML 같은 문서 형식으로 데이터를 저장한다. 각 문서가 구조화된 데이터를 담을 수 있어 스키마 유연성과 복잡한 데이터 구조 표현이 가능하다. MongoDB, CouchDB, Firebase Firestore가 여기 속한다.
컬럼 기반(Column-Family) 데이터베이스는 행과 열 대신 컬럼 패밀리 개념을 쓴다. 데이터를 컬럼 단위로 저장해 대량 데이터 분석과 쓰기 작업에 최적화돼 있다. Apache Cassandra, HBase, Google Bigtable이 대표적이다.
그래프(Graph) 데이터베이스는 노드와 에지(관계)로 데이터 간 관계성을 표현한다. 복잡한 관계를 가진 데이터를 처리하는 데 효율적이라 소셜 네트워크, 추천 엔진에 쓰인다. Neo4j, Amazon Neptune, JanusGraph가 대표적이다.
RDBMS 옆에 놓으면 보이는 차이
| 특성 | NoSQL | RDBMS |
|---|---|---|
| 데이터 모델 | 다양한 모델(키-값, 문서, 컬럼, 그래프) | 테이블 기반 관계형 모델 |
| 스키마 | 유연함(스키마리스) | 엄격한 스키마 |
| 확장성 | 수평적 확장(Scale-out) | 주로 수직적 확장(Scale-up) |
| 트랜잭션 | 제한적 ACID 지원(일부 제품) | 완전한 ACID 트랜잭션 |
| 쿼리 언어 | 제품별 API, 제한적 쿼리 | 표준 SQL |
| 일관성 | 최종 일관성(일부 제품), 유연한 일관성 모델 | 강한 일관성 |
| 복잡한 조인 | 제한적 지원 | 완벽 지원 |
| 사용 사례 | 빅데이터, 실시간 웹, IoT, 소셜 미디어 | 금융, ERP, CRM, 전통적 비즈니스 애플리케이션 |
누가 무엇에 쓰고 있는가
대규모 웹 애플리케이션에서는 Facebook이 Cassandra를, Twitter가 Redis를 쓰고, LinkedIn은 Voldemort로 대규모 사용자 프로필을 관리하며, Netflix는 Cassandra로 실시간 분석을 한다. 빅데이터·로그 분석에서는 Elasticsearch·Cassandra로 로그 데이터를 저장·분석하고, MongoDB·HBase로 사용자 행동을 분석하며, InfluxDB·TimescaleDB로 시계열 데이터를 분석한다. IoT에서는 MongoDB·Cassandra로 센서 데이터를 모으고, Redis·Apache Kafka로 실시간 처리한다. 콘텐츠 관리에서는 MongoDB·Couchbase로 CMS를 운영하고, DynamoDB로 미디어 메타데이터를 저장한다.
실제 구현 사례로는 아마존이 장바구니·세션 관리에 DynamoDB를, 페이스북이 사용자 메시지에 HBase를, 넷플릭스가 추천 엔진에 Cassandra를, 우버가 위치 데이터 처리에 MongoDB를, 에어비앤비가 검색 기능 강화에 Elasticsearch를 쓴다.
설계에서 미리 정해둬야 하는 것들
쿼리 패턴을 중심으로 데이터를 모델링하고, 비정규화로 읽기 성능을 최적화하며, 적절한 데이터 파티셔닝 전략을 세워야 한다. 강한 일관성과 최종 일관성 중 무엇이 필요한지 분석하고, 쓰기 성능과 일관성 사이의 균형점을 찾아야 한다. 샤딩 키 설계, 리플리케이션 전략, 로드 밸런싱도 확장 전략에서 결정해야 할 부분이다. 인증·권한 관리, 암호화 전략, 백업·복구 계획도 보안·백업 측면에서 미리 세워둬야 한다.
NoSQL이 여전히 못하는 것들
제품마다 쿼리 언어와 API가 달라 표준화가 안 돼 있고, 이식성과 벤더 종속성 문제가 있다. 다중 문서·키 트랜잭션 지원이 부족해 분산 환경에서 일관성을 보장하기 어렵다. 복잡한 조인·집계 기능이 제한적이라 BI 도구와 통합하기 어렵고, 분산 시스템의 모니터링·관리와 성능 튜닝도 까다롭다.
여러 DB를 섞어 쓰는 게 흐름이 되고 있다
NoSQL은 기존 RDBMS를 대체하기보다 보완하는 방향으로 자리 잡았다. 애플리케이션의 특성과 요구사항에 맞는 데이터베이스를 고르는 것이 중요하고, Polyglot Persistence(다중 DB 활용)로 각 데이터베이스의 장점을 조합하는 아키텍처 설계가 흔해지는 추세다. NoSQL과 SQL의 경계가 흐려지며 하이브리드 형태의 데이터베이스 시스템이 더 발전할 것으로 보인다.