1. NoSQL의 등장 배경: RDB만으로 해결할 수 없는 문제
과거의 서비스는 정형화된 데이터를 안전하게 저장하는 것이 최우선이었다.
하지만 현대 웹 서비스는 단순한 데이터 보관을 넘어선 과제에 직면했다.
- 비정형 데이터의 증가: SNS, IoT 등에서 발생하는 데이터는 고정된 테이블 구조에 맞추기 어렵고 유연성이 떨어진다.
- 초고속 응답 속도의 요구: 밀리초() 단위의 지연 시간이 사용자 경험을 결정짓는 환경에서, 모든 데이터를 물리적 디스크 I/O가 발생하는 RDB로만 처리하는 것은 성능적 병목이 되기 쉽다.
이처럼 현대 웹의 유연성과 성능 문제를 해결하기 위해 "Not Only SQL"을 의미하는 NoSQL이 등장하게 되었다.
2. RDB와 NoSQL의 차이
두 저장소는 데이터를 관리하는 패러다임 자체가 다르다.
| 구분 | RDB (Relational) | NoSQL (Not Only SQL) |
|---|---|---|
| 데이터 모델 | 고정된 스키마, 테이블 형태 | 유연한 스키마, Key-Value, Document 등 |
| 질의 방식 | SQL (구조화된 질의) | 다양한 API 및 전용 쿼리 방식 |
| 주된 장점 | 데이터 무결성, 명확한 데이터 관계 | 높은 읽기/쓰기 성능, 데이터 가변성 수용 |
3. 근본적인 질문: 왜 저장소의 분리가 필요한가?
모든 데이터를 하나의 RDB에 넣지 않는 이유는 '관심사의 분리' 때문이다.
-
영속성 데이터: 사용자 정보, 결제 내역처럼 서비스가 종료되어도 절대 사라지면 안 되는 데이터는 파일 시스템 기반의 RDB에 보관한다.
-
일시적/고성능 데이터: 로그인 세션, 장바구니, 인증 토큰처럼 빈번하게 수정되고 일정 시간이 지나면 삭제되어야 하는 데이터는 NoSQL에 위임한다.
이렇게 성격에 따라 저장소를 분리함으로써 RDB의 부하를 줄이고 전체 시스템의 응답 속도를 효율적으로 끌어올릴 수 있다.
4. NoSQL의 종류 3가지 비교
NoSQL은 데이터를 저장하는 방식에 따라 크게 세 분류로 나뉜다.
-
Key-Value (Redis): 가장 단순하며 속도가 가장 빠르다. 실시간 캐싱에 최적화되어 있다.
-
Document (MongoDB): JSON과 유사한 문서 형태로 저장한다. 데이터 구조가 자주 바뀌는 경우 유리하다.
-
Column-Family (Cassandra): 대용량 데이터의 쓰기에 특화되었으며, 대규모 분산 환경에 적합하다.
5. Redis: 가장 강력한 인메모리 Key-Value 스토어
그중에서도 Redis는 백엔드 시스템에서 성능 최적화를 위한 핵심적인 위치를 차지한다.
5-1. Redis의 핵심 특징
-
In-Memory: 모든 데이터를 RAM에 저장한다. 디스크를 거치지 않아 지연 시간이 거의 없다.
-
휘발성: 서버가 종료되거나 재시작되면 메모리상의 데이터는 소멸한다. 따라서 사라져도 재구성이 가능한 데이터를 다루거나, 필요에 따라 별도의 영속성 옵션(AOF/RDB 스냅샷)을 구성해야 한다.
-
Key-Value: Java의 Map이나 Python의 Dictionary처럼 키를 통해 값을 즉시 찾아내는 구조를 가진다.
5-2. Redis 설치 시 선택지
-
redis-stack: Redis Core와 함께 JSON, Search 등 확장 모듈과 시각화 도구인 Redis Insight가 포함된 버전이다. 로컬 개발 환경에서 데이터를 눈으로 확인하며 디버깅하기에 매우 좋다.
-
redis-stack-server: Redis Stack에서 시각화 GUI(Insight)만 제외된 버전이다. 주로 서버 리소스를 아끼며 가볍게 운영할 때 사용한다.
💡 정리 및 고찰
Redis는 단순한 데이터베이스가 아니다.
RDB가 가진 속도의 한계를 보완하고, 일시적인 데이터를 가장 효율적으로 처리하는 전략적 도구다. 메모리는 빠르지만 비싸고 휘발된다는 점을 명심하고, 서비스의 어떤 데이터를 메모리에 배치할지 결정하는 것이 설계의 핵심이다.
