Spring Boot로 서비스를 만들다 보면 자연스럽게 관계형 데이터베이스(RDBMS)를 먼저 배우게 된다. 데이터를 영속적으로 저장해야 하니까. 그런데 개발을 계속 하다 보면 문득 이런 상황이 생긴다.
"로그인 상태는 어디에 저장해야 하지? 장바구니 정보는? 조회수처럼 엄청 자주 바뀌는 데이터는?"
이런 데이터들은 영속성(Persistence, 서비스가 종료되어도 데이터가 유지되는 성질)도 중요하지만, 속도가 더 중요한 경우가 많다. 바로 이 지점에서 Redis가 등장한다.
일반적인 RDBMS(MySQL, PostgreSQL 등)는 데이터를 파일시스템(SSD/HDD) 에 저장한다.
이 방식의 핵심 목적은 영속성(Persistence) 이다.
서버가 꺼져도 데이터가 살아남는다는 게 큰 장점이지만,
반대로 디스크 I/O(입출력)가 발생하기 때문에 속도 면에서 본질적인 한계가 존재한다.
반면 일부 데이터는 특성상 이런 구조가 오히려 과하다.
이런 데이터들은 굳이 복잡한 디스크 I/O를 거칠 필요가 없다. RAM(메모리)에 저장하면 훨씬 빠르게 읽고 쓸 수 있다. 이것이 인메모리(In-Memory) 저장소의 핵심 아이디어다.

대표적인 인메모리 저장소, Redis
Redis는 REmote DIctionary Server의 줄임말이다. 이름에서 알 수 있듯, 원격에서 접근 가능한 딕셔너리(Dictionary) 형태의 서버다. Java의 Map, Python의 dict와 유사하게 Key-Value 쌍으로 데이터를 저장한다.
Redis의 가장 큰 특징 두 가지를 정리하면 다음과 같다.
앞서 설명했듯, Redis는 데이터를 RAM에 저장한다. 디스크 접근이 필요 없기 때문에 일반적인 RDBMS에 비해 압도적으로 빠른 읽기/쓰기 성능을 제공한다.
대신 한 가지 중요한 트레이드오프가 있다. 서버가 꺼지면 메모리에 올라가 있던 데이터는 기본적으로 사라질 수 있다는 점이다. (물론 Redis는 RDB 스냅샷이나 AOF 로그 등 영속성 옵션도 제공하지만, 핵심 사용 목적은 '빠른 임시 저장'이다.)
Redis는 테이블과 SQL을 사용하는 RDBMS와 달리, NoSQL 방식으로 데이터를 저장한다.
# RDBMS: SQL로 데이터 조회
SELECT * FROM users WHERE id = 1;
# Redis: Key-Value 방식
SET user:1 "Alice"
GET user:1
이 단순함이 오히려 큰 강점이 된다.
NoSQL은 Not Only SQL의 약자로, RDBMS가 다소 취약한 확장성(Scalability), 유연성(Flexibility), 성능(Performance) 을 보완하기 위해 등장한 데이터베이스 접근 방식이다.
웹 서비스가 폭발적으로 성장하면서 정형화된 스키마로는 감당하기 어려운 비정형 대용량 데이터를 다뤄야 하는 상황이 많아졌고, 이를 해결하기 위해 다양한 NoSQL 유형이 발전했다.
| 유형 | 설명 | 대표 예시 |
|---|---|---|
| Key-Value | Key에 Value를 저장하는 가장 단순한 형태. JSON, Map처럼 생각하면 된다. | Redis, DynamoDB |
| Document | JSON, XML 같은 구조화된 문서(Document) 단위로 저장. Key-Value에서 발전한 형태. | MongoDB, CouchDB |
| Column-Family | Row마다 고정된 컬럼이 없고, 필요한 컬럼만 이름/데이터/타임스탬프와 함께 저장. | Cassandra, HBase |
| Graph | 노드와 엣지로 관계를 표현. 소셜 네트워크, 추천 시스템 등에 적합. | Neo4j |
Redis는 그 중에서도 Key-Value Store 유형이며, 단순 문자열(String)뿐 아니라 List, Set, Hash, Sorted Set 등 다양한 자료구조를 지원한다는 점에서 일반적인 Key-Value 저장소보다 훨씬 강력하다.
Redis는 실제 개발 환경에서 주로 아래와 같은 목적으로 사용된다.
여러 서버 인스턴스(Instance, 실행 중인 서버 프로세스)가 동일한 세션 정보를 공유해야 할 때 활용한다. 예를 들어 서버가 여러 대로 늘어나는 스케일 아웃(Scale-out) 환경에서, 사용자 A가 서버 1에 로그인했어도 서버 2가 요청을 받았을 때 로그인 상태를 유지해야 한다. 이때 Redis가 중간 저장소 역할을 한다.
자주 조회되는 데이터를 Redis에 미리 저장해두고, 데이터베이스 대신 Redis에서 빠르게 응답하도록 구성한다. DB 부하를 줄이고 전반적인 응답 속도를 개선하는 가장 흔한 패턴이다.
Redis의 Sorted Set 자료구조를 활용하면 랭킹 시스템을 매우 효율적으로 구현할 수 있다. 게임 점수 순위, 판매량 TOP 10 등의 기능에 자연스럽게 쓰인다.
2024년 3월 Redis는 기존 BSD 라이선스에서 RSALv2 + SSPLv1 듀얼 라이선스로 변경했다. 이는 AWS, GCP 같은 클라우드 사업자들이 Redis를 기반으로 관리형 서비스를 제공하면서 기여는 거의 하지 않는 구조를 막기 위한 결정이었다.
그 결과 AWS, Google, Oracle 등의 지원 하에 Linux Foundation 산하에 Valkey라는 BSD 라이선스 포크(Fork, 기존 코드를 기반으로 독립적으로 분기한 프로젝트)가 등장했다.
이후 2025년 5월, Redis는 Redis 8.0부터 AGPLv3 라이선스를 추가하며 다시 오픈소스 라이선스를 선택지에 포함시켰다. 현재 Redis 8은 RSALv2, SSPLv1, AGPLv3 세 가지 라이선스 중 하나를 선택할 수 있는 트라이 라이선스(Tri-license) 구조다.
정리하면:
- Redis 7.2 이하: BSD 라이선스 (완전 오픈소스)
- Redis 7.4 ~ 7.8: RSALv2 + SSPLv1 (소스 어베일러블, 오픈소스 아님)
- Redis 8 이상: RSALv2 + SSPLv1 + AGPLv3 선택 가능
개인 학습이나 일반적인 내부 서비스 개발에는 무료로 사용할 수 있다. 다만 팀 프로젝트나 상업적 활용 시에는 정확한 라이선스 조건을 확인하는 것이 좋다.
io-threads 설정을 통해 멀티코어 CPU 활용도를 높일 수 있게 됨실제 개발 환경에서는 이미 많은 레거시 환경이 Redis 7.x 버전을 사용하고 있다. 새로운 프로젝트를 시작한다면 Valkey도 충분히 고려할 만한 대안이다. AWS ElastiCache, Google Cloud Memorystore 등 주요 클라우드 관리형 서비스들도 Valkey를 지원하기 시작했다.
다만 학습 단계에서는 Redis와 Valkey의 명령어 체계, API가 사실상 동일하므로 어느 쪽으로 학습해도 무방하다.
| 구분 | RDBMS | Redis |
|---|---|---|
| 저장 위치 | 디스크(SSD/HDD) | RAM(메모리) |
| 데이터 영속성 | 기본 제공 | 제한적 (옵션으로 설정 가능) |
| 데이터 구조 | 테이블 | Key-Value, List, Set, Hash 등 |
| 조회 방식 | SQL | 전용 커맨드(GET, SET 등) |
| 주요 목적 | 영구 데이터 저장 | 빠른 임시 데이터 저장 |
| 대표 활용 | 회원정보, 주문내역 | 세션, 캐시, 카운터, 리더보드 |
Redis는 RDBMS를 대체하는 게 아니라 보완하는 관계다. 영속성이 필요한 데이터는 RDBMS에, 빠른 처리가 필요한 임시 데이터는 Redis에 담는 것이 일반적인 아키텍처 패턴이다.