NoSQL 데이터베이스 (NoSQL Databases)

NoSQL이란

NoSQL 은 관계형 데이터베이스가 아닌 다양한 데이터 모델을 사용하는 데이터베이스 계열을 묶어 부르는 표현입니다. 보통 문서형, 키-값형, 컬럼 패밀리형, 그래프형 데이터베이스가 여기에 들어갑니다.

이 문서는 저장소 선택과 제품 특성 관점에서 NoSQL을 설명하는 문서입니다.
시스템 설계 면접에서 “왜 이 서비스에 NoSQL을 선택하는가”라는 의사결정 흐름은 데이터베이스 설계 문서와 함께 보면 더 자연스럽습니다.

중요한 점은 NoSQL이 하나의 제품이나 하나의 일관성 모델을 뜻하지 않는다는 것입니다.

어떤 제품은 eventual consistency를 기본으로 합니다.
어떤 제품은 강한 일관성 옵션을 제공합니다.¹
어떤 제품은 다중 문서 트랜잭션도 지원합니다.²

따라서 NoSQL은 하나의 성질로 묶기보다, 제품별 데이터 모델과 보장 수준을 기준으로 설명하는 편이 좋습니다.

왜 NoSQL이 등장했는가

NoSQL이 주목받은 배경은 다음과 같습니다.

대규모 분산 환경 대응
유연한 데이터 모델 필요
수평 확장 요구
특정 접근 패턴에 특화된 저장소 필요

예를 들어:

세션 저장은 키-값 저장소가 자연스럽고
소셜 그래프는 그래프 DB가 더 적합하며
로그 이벤트 저장은 문서형이나 컬럼 계열이 더 잘 맞을 수 있습니다.

주요 유형

문서형 데이터베이스

예시: MongoDB, CouchDB
특징: JSON/BSON 같은 문서 단위 저장
적합한 경우: 프로필, 카탈로그, 콘텐츠, 반정형 데이터

키-값 데이터베이스

예시: Redis, DynamoDB
특징: 키를 통해 빠르게 값을 조회
적합한 경우: 캐시, 세션, 간단한 상태 저장

컬럼 패밀리형 데이터베이스

예시: Cassandra, HBase
특징: 대규모 분산 저장과 쓰기 처리에 강한 경우가 많음
적합한 경우: 로그, 시계열, 대용량 이벤트 데이터

그래프 데이터베이스

예시: Neo4j
특징: 노드와 엣지 중심 모델
적합한 경우: 추천, 소셜 관계, 경로 탐색

RDBMS와의 차이

항목	RDBMS	NoSQL
데이터 모델	테이블과 스키마 중심	제품별로 다양
강점	조인, 무결성, 트랜잭션	확장성, 유연성, 특정 패턴 최적화
스케일링	전통적으로 수직 확장 중심	수평 확장 친화적인 경우가 많음
스키마	엄격한 편	유연한 편
적합한 경우	정형 데이터와 강한 무결성	대규모 분산, 반정형 데이터, 특화된 접근 패턴

함께 기억할 점은 다음과 같습니다.

RDBMS도 샤딩과 복제로 수평 확장이 가능합니다.
NoSQL도 제품에 따라 트랜잭션과 강한 일관성을 지원합니다.
저장소 선택은 유행보다 데이터 구조와 접근 패턴이 기준이 됩니다.

CAP과 일관성 모델

CAP 이론은 네트워크 파티션이 발생했을 때 일관성과 가용성 중 무엇을 우선할지 생각하는 틀입니다.
다만 NoSQL 전체를 하나의 CAP 성향으로 묶을 수는 없습니다.

DynamoDB는 기본적으로 eventually consistent read를 사용하지만, strongly consistent read도 제공합니다.¹
MongoDB도 read concern, write concern, read preference 조합에 따라 읽기/쓰기 보장 특성이 달라집니다.²

그래서 NoSQL을 설명할 때는 보통 다음 흐름으로 정리합니다.

NoSQL 제품은 분산 환경을 전제로 설계된 경우가 많다
일관성 모델은 제품마다 다르다
워크로드와 장애 허용 범위에 맞춰 선택해야 한다

NoSQL을 선택할 때 보는 기준

데이터 모델이 관계형인가, 문서형인가
조인이 핵심인가
수평 확장이 얼마나 중요한가
일관성을 어디까지 요구하는가
접근 패턴이 단순 키 조회인지, 복잡한 관계 탐색인지

선택 예시는 대략 이렇습니다.

RDBMS가 유리한 경우: 주문, 결제, 회계, ERP
NoSQL이 유리한 경우: 세션, 로그, 피드, 콘텐츠, 추천, 고속 캐시

정답은 “NoSQL이 더 최신이라서”가 아니라, 문제 구조에 저장소가 맞는가입니다.

면접 포인트

NoSQL은 하나의 제품이 아니라 여러 데이터 모델 계열의 묶음입니다.
NoSQL은 제품별 데이터 모델과 일관성 모델이 다르다는 점을 함께 설명하는 편이 좋습니다.
제품별 일관성 모델과 트랜잭션 지원 범위를 구분해 설명해야 합니다.
RDBMS와 NoSQL은 대체 관계보다 문제 유형에 따라 역할이 갈리는 경우가 많습니다.
답변에서는 데이터 모델, 스케일링, 일관성, 대표 사용 사례를 같이 묶어 설명하는 편이 좋습니다.