쉬운 설명
관계형 DB는 잘 정리된 표와 표 사이 관계로 데이터를 다룹니다. 일관성·정확성에 강하지만, 형태가 자주 바뀌는 데이터나 폭발적으로 늘어나는 데이터에는 다소 무거울 수 있습니다. NoSQL은 이런 상황을 다른 방식으로 풉니다.
왜 'No SQL'이라는 이름이 붙었나 하면, 2000년대 후반 '관계형 DB가 모든 문제의 답은 아니다'라는 인식이 퍼지며 등장한 흐름이기 때문입니다. 이름과 달리 'SQL을 안 쓴다'기보다는 '관계형 모델의 강제를 안 받는' 데이터베이스를 묶은 이름이고, 실제로는 SQL 비슷한 쿼리를 지원하는 NoSQL도 많습니다.
대표 갈래는 네 가지입니다. ① 문서형(MongoDB·Couchbase): JSON 같은 자유 구조 저장. 형태가 자주 바뀌는 데이터에 강함. ② 키-값(Redis·DynamoDB): 단순 키로 빠른 조회. 캐시·세션·실시간 카운터에 강함. ③ 와이드컬럼(Cassandra·HBase·ScyllaDB): 거대한 쓰기·읽기 처리량. SNS 피드·시계열에 강함. ④ 그래프(Neo4j·ArangoDB): 노드-엣지 모델. 친구의 친구·추천·사기 탐지에 강함.
장점·단점이 분명합니다. 장점: 유연한 스키마, 수평 확장(서버 늘리기)이 쉬움, 특정 작업 패턴에서 매우 빠름. 단점: 트랜잭션·일관성 보장이 관계형보다 약한 경우가 많고, JOIN 같은 복잡한 쿼리가 약하고, 잘못 쓰면 데이터가 흩어집니다.
오해 하나 풀자면, 'NoSQL이 SQL을 대체한다'가 아니라 '용도에 맞는 도구를 고른다'가 맞습니다. 결제·재무처럼 정확성이 핵심인 데이터는 여전히 SQL이 적합하고, 사용자 활동 로그·캐시처럼 빠른 단순 접근이 핵심인 경우 NoSQL이 더 잘 맞습니다. 큰 회사들은 거의 항상 두 가지를 같이 씁니다.
비유로 보면
관계형 DB가 잘 정돈된 회계 장부라면, NoSQL은 메모지·포스트잇·자석 보드의 다양한 모음과 같습니다. 회계 장부는 정확하지만 새 칸을 추가하기 어렵고, 메모지·포스트잇은 자유롭지만 일관된 통계 내기가 어렵습니다. 둘 다 쓰임새가 있어 책상 위에 함께 둡니다.
어디에서 만나나
실시간 채팅·게임의 상태 저장, 캐시·세션, 사용자 행동 로그, IoT 센서 데이터, 추천·소셜 그래프, 검색 인덱스 보조, JSON 구조의 메타데이터 저장. 거의 모든 대규모 서비스가 한두 종류의 NoSQL을 함께 운영합니다.
작은 예시
큰 쇼핑몰을 운영한다면 보통 사용자·주문·결제는 관계형 DB(MySQL·Postgres)에 두고, 추천에 쓰는 '내가 본 상품 목록' 같은 단순 키-값은 Redis에, 사용자 행동 로그는 Cassandra에, 친구 관계는 그래프 DB에 두는 식으로 섞어 씁니다.
자주 하는 오해
한 줄 정리
NoSQL의 가치는 '도구의 다양성'에 있습니다. 같은 문제에 한 도구만 들이대지 않고, 작업 패턴에 맞는 그릇을 고르는 안목이 핵심입니다.