[Redis] Redis, 제대로 아는 척하기 전에 톺아보자

임재영·2025년 7월 1일

프로젝트를 진행하면서 Redis를 다양한 부분에 유용하게 활용해왔다.
JWT 기반 로그인 시스템에서는 토큰 관리를 위해 사용했고, Celery를 활용한 비동기 작업 처리에서는 메시지 브로커로써 사용했다.
또, WebSocket 기반의 실시간 채팅 기능 구현할 때도 Redis의 Pub/Sub 구조를 적용했다.
이렇게 여러 곳에서 Redis를 사용하면서도, 정작 제대로 개념을 잡고 공부해본 적은 없었다.

이번 기회에 Redis의 동작 원리와 기능들을 깊이 있게 정리하면서, 앞으로는 제대로 이해하고 활용할 수 있도록 기반을 다지고자 한다.

Redis는 단순한 캐시 그 이상의 기능을 지닌 만큼, 여러 포스팅으로 나누어 천천히 소화하며 정리해 볼 예정이다.

Redis란?

Remote Dictionary Server의 약자로, 오픈 소스 기반의 인 메모리(In-memory) 데이터 저장소이다. 데이터베이스, 캐시, 메시지 브로커 등 다양한 용도로 사용되며, 키-값(Key-Value) 구조를 기반으로 데이터를 처리한다.

이름으로 알아보는 간단 redis이해

Remote : 컴퓨터(또는 서버)에 따로 실행되는 프로그램(서버)이고,
Dictionary : 데이터를 Key와 Value 쌍으로 저장함. (예: "user=1" : "Jaeyeong") 마치 파이썬의 딕셔너리랑 비슷함.
데이터 관리 Server 시스템 : 단순 저장소가 아닌, 데이터를 읽고 쓰고 조작할 수 있는 기능을 가진 서버. 명령어를 통해 다양한 자료구조도 지원함.

➡️ Redis는 이처럼 별도로 실행되는 서버 프로그램이기 때문에, 작성자 본인도 Redis를 사용할 때는 Docker 환경에 Redis 이미지를 띄워 원격 서버에 설치하고 실행하여 사용했다.

Docker 적용 예시 (docker-compose.yml)

redis:
  image: redis:latest
  container_name: redis
  ports:
    - "6379:6379"
  networks:
    - idam-net # 이전에 만든 프로젝트에서 사용한 네트워크

특징☝️: In-Memory 기반

Redis는 보통 프로세스로 존재하는 In-Memoey 기반의 시스템이라고 한다. 이게 무슨 뜻일까?

먼저, "프로세스로 존재한다"는 뜻은 Redis가 그냥 파일이 아니라, 항상 실행 중인 프로그램(서버 프로세스)으로 존재한다는 말이다. 즉, 서버가 '요청'을 보내면 Redis가 '응답'해주는 형식이다.

그리고 "In-Memory 기반"이란, 데이터를 디스크(HDD/SSD)가 아니라 메모리(RAM)에 저장한다.
데이터를 저장 및 조회할 때, 디스크를 오고가는 과정 없이 메모리에서 직접 읽고 쓰기 때문에 속도가 현저히 빨라진다.

특징✌️: Key-Value 구조

또 Key-Value 구조 데이터란, MySQL과 같은 관계형 데이터베이스가 아니라 비관계형 구조로써 데이터를 그저 '키-값'의 형태로 단순하게 저장하는 구조를 말한다.

💡 간단하게 짚고 넘어가는 관계형 DB(RDB) vs 비관계형 DB(NoSQL) / 정형 vs 비정형 데이터

구분 관계형 DB (RDB) 비관계형 DB (NoSQL)
데이터 구조 테이블(행-열 구조) 문서, 키-값, 그래프 등 유연한 구조
스키마 고정됨 (미리 정의해야 함) 유연함 (필드가 달라도 저장 가능)
예시 MySQL, PostgreSQL, Oracle MongoDB, Redis, Cassandra, DynamoDB
적합한 상황 트랜잭션이 중요한 정형 데이터 다양한 형식의 데이터를 빠르게 처리할 때
쿼리 언어 SQL DB마다 다름 (ex: Mongo Query, Redis 명령어 등)

구분 정형 데이터 비정형 데이터
형태 표 형태로 쉽게 구조화됨 (엑셀처럼) 구조화되지 않음 (자유로운 형태)
예시 이름, 나이, 주소 등 테이블 형태 데이터 이미지, 영상, PDF, 이메일 본문 등
저장 위치 주로 관계형 DB 파일 시스템, NoSQL, 클라우드 저장소 등
분석 용이성 바로 쿼리로 분석 가능 전처리 후 분석 필요

핵심 요약

관계형 / 비관계형 : “데이터베이스의 구조와 설계 방식”의 차이.

정형 / 비정형 : “데이터 자체 생김새”의 차이.

구분	관계형 DB (RDB)	비관계형 DB (NoSQL)
데이터 구조	테이블(행-열 구조)	문서, 키-값, 그래프 등 유연한 구조
스키마	고정됨 (미리 정의해야 함)	유연함 (필드가 달라도 저장 가능)
예시	MySQL, PostgreSQL, Oracle	MongoDB, Redis, Cassandra, DynamoDB
적합한 상황	트랜잭션이 중요한 정형 데이터	다양한 형식의 데이터를 빠르게 처리할 때
쿼리 언어	SQL	DB마다 다름 (ex: Mongo Query, Redis 명령어 등)

구분	정형 데이터	비정형 데이터
형태	표 형태로 쉽게 구조화됨 (엑셀처럼)	구조화되지 않음 (자유로운 형태)
예시	이름, 나이, 주소 등 테이블 형태 데이터	이미지, 영상, PDF, 이메일 본문 등
저장 위치	주로 관계형 DB	파일 시스템, NoSQL, 클라우드 저장소 등
분석 용이성	바로 쿼리로 분석 가능	전처리 후 분석 필요

하지만 Redis는 메모리 기반으로 작동하는 만큼, 데이터의 휘발성이 강하다. 이를 보완하기 위해, Redis는 필요 시 디스크에 저장하는 옵션을 제공한다.

이러한 동작을 "데이터를 영속화(Persistence) 한다"고 하며, 메모리에서 처리된 데이터를 주기적으로 디스크에 백업하는 기능이다. Redis의 영속화 방식은 크게 두 가지(RDB, AOF)로 나뉜다.

(영속성에 대한 자세한 내용은 이전 포스팅 "[JAVA] JPA란?" 참고.)

방식1 : RDB (Redis Database File)

메모리에 있는 데이터를 주기적으로 스냅샷(snapshot) 떠서 디스크에 저장하는 방식

일정 시간 간격으로 전체 데이터를 저장
.rdb 파일이 생성됨
재시작 시 이 파일을 읽어 메모리 복원
빠름 (쓰기 성능에 영향이 적음)
단점 : 백업 주기 사이의 데이터는 유실 가능

✅ RDB 저장 방식

자동 저장
- Redis 설정 파일(redis.conf)의 save 옵션을 이용해, "몇 초 동안 몇 번 수정되면 저장해라" 이런 식으로 조건을 줘서 저장함.
- 예: save 900 1 → 15분 동안 1번 이상 수정되면 RDB 저장.
수동 저장
- 명령어: BGSAVE
- "지금 당장 RDB 파일 만들어줘!" 라는 뜻.
- Redis는 백그라운드에서 조용히 저장 시작함.
주의할 점: SAVE는 사용 금지
- SAVE는 메인 쓰레드가 저장 작업을 직접 해서, 다른 요청을 못 받음.
- Redis는 싱글 쓰레드라서 이 명령어는 서비스 중엔 절대 금지.

방식2 : AOF (Append Only File)

Redis에서 실행된 모든 write 명령어를 기록하는 방식 (append-only-log)

SET, DEL, HSET 등 명령어를 순서대로 저장
서버 재시작 시 이 로그를 재실행하여 상태 복원
더 안전함 (실시간에 가까운 복구 가능, 초 단위 데이터는 유실 가능)
파일 크기가 커질 수 있음 (리라이팅으로 압축 가능)
상대적으로 느림 (쓰기 성능에 영향 있음)

✅ AOF 저장 방식

자동 저장 + 최적화(리라이팅)
- 설정 파일(redis.conf)의 auto-aof-rewrite-percentage 옵션 사용 → AOF 파일이 너무 커지면 자동으로 정리(rewrite)
- 예: 기존 AOF보다 100% 커지면 리라이팅 수행
수동 저장(리라이팅)
- 명령어: BGREWRITEAOF
- "AOF 파일이 너무 크면, 수동으로 줄여줘!" 라는 뜻.
- Redis가 백그라운드에서 최적화된 AOF 파일을 새로 만듦.

실무에서의 백업 활용 방식

일부 데이터 손실에 영향을 받지 않는 경우(캐시로만 사용할 때),
→ RDB
장애 상황 직전까지의 모든 데이터가 보장되어야 할 경우,
→ AOF
강력한 내구성이 필요한 경우,
→ RDB + AOF

Redis는 기본적으로 RDB + AOF 병행 사용 가능하며, 실무에서는 AOF를 주로 사용하거나 둘 다 설정해서 안정성과 성능을 모두 챙긴다.

Redis는 어디에 쓰일까?

1. 빠른 캐싱 시스템 (Caching)

가장 흔하게 쓰이는 방식. 데이터베이스나 외부 API의 응답 결과를 Redis에 저장해두고, 같은 요청이 오면 DB 대신 Redis에서 바로 응답함.

사용 예: 게시판 목록, 인기 글, 상품 정보 등 자주 조회되는 데이터
장점: 응답 속도 향상 + DB 부하 감소
Spring에서는 @Cacheable, @CacheEvict 같은 캐시 어노테이션과 함께 사용 가능

2. 세션 저장소 (Session Storage)

사용자의 로그인 정보를 Redis에 저장하고 유지하는 방식. 서버가 재시작되더라도 로그인 정보가 유지되도록 함.

사용 예: 로그인 상태 유지, 사용자 상태 추적
장점: 확장 가능한 서버 아키텍처에서 세션 정보를 중앙 Redis에 저장하면, 여러 서버간 세션을 공유할 수 있음
Spring Session, Express-session(Redis Store) 등에서 널리 사용

3. 실시간 분석 및 대시보드

사용자 행동(클릭, 구매, 방문 등)을 Redis에 실시간으로 저장하고, 이를 기반으로 즉시 통계나 시각화 데이터를 보여주는 구조.

사용 예: 실시간 사용자 수, 조회 수, 차트 수치 등
장점: 메모리 기반이기 때문에 빠른 집계 연산이 가능하며, 주기적으로 배치 처리 후 DB에 저장하는 구조도 가능

4. 메시지 브로커 (Pub/Sub)

Publish/Subscribe 구조를 이용해 한 서비스가 메시지를 발행하면, 다른 서비스가 이를 구독하여 실시간으로 수신함.

사용 예: 실시간 채팅, 알림 시스템, 이벤트 브로커
장점: Kafka 만큼은 아니더라도 간단한 메시징 시스템 구축에 매우 적합
Redis 채널에 PUBLISH하고, 다른 서비스는 SUBSCRIBE로 수신

[참고]
https://velog.io/@banggeunho/%EB%A0%88%EB%94%94%EC%8A%A4Redis-%EC%95%8C%EA%B3%A0-%EC%93%B0%EC%9E%90.-%EC%A0%95%EC%9D%98-%EC%A0%80%EC%9E%A5%EB%B0%A9%EC%8B%9D-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%EC%9E%90%EB%A3%8C%EA%B5%AC%EC%A1%B0-%EC%9C%A0%ED%9A%A8-%EA%B8%B0%EA%B0%84
https://velog.io/@wnguswn7/Redis%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C-Redis%EC%9D%98-%ED%8A%B9%EC%A7%95%EA%B3%BC-%EC%82%AC%EC%9A%A9-%EC%8B%9C-%EC%A3%BC%EC%9D%98%EC%A0%90
https://velog.io/@pak4184/Redis-%ED%86%BA%EC%95%84%EB%B3%B4%EA%B8%B0
https://www.elancer.co.kr/blog/detail/768