백엔드 데이터 인프라 47편 — Redis란 + PostgreSQL과의 역할 분담

이 글은 백엔드 데이터 인프라 시리즈 130편 중 47편이에요. PostgreSQL 46편 으로 "영속 데이터를 어디에 담느냐" 가 잡혔다면, 그 위에 올라가는 인메모리 계층 Redis 차례. 시리즈 2의 두 번째 큰 덩어리고, 33편으로 풀어 갑니다.

Redis가 처음 어렵게 느껴지는 이유

처음 Redis를 보면 세 가지가 한꺼번에 헷갈려요. 우선 "DB인데 왜 메모리에?" 하는 의문. PostgreSQL·MySQL 같은 디스크 기반 DB만 보다가 "메모리에 다 들어간다"는 소개를 들으면 "전원 끊기면 다 날아가나?"부터 의심하게 됩니다. 답은 "날아가지 않게 디스크에 따로 적는다(persistence — 데이터를 디스크에 보존하는 절차)" 인데, 그 메커니즘이 RDB(스냅샷 백업)·AOF(쓰기 명령 로그) 두 갈래라 또 헷갈리죠.

다음은 PostgreSQL과의 관계. "Redis가 PostgreSQL을 대체하나?"라는 게 가장 흔한 오해예요. 정답은 대체가 아니라 보완. 같은 DB 이름표가 붙어 있을 뿐 역할이 정반대거든요.

마지막은 데이터 타입이 무려 13가지. String·Hash·List·Set·Sorted Set·Stream·Bitmap·Bitfield·Geospatial·JSON·Vector·Time Series·Probabilistic. 이 중에 "내 문제에는 어떤 타입을 골라야 하나"가 안 잡히면 첫 코드를 짤 수 없어요.

이 글에서는 그 세 가지 의문을 한 번에 정리하고, Redis가 어떤 상황에서 빛나는지 큰 그림을 그려 봐요. 다음 48편에서 데이터 타입 13종을 한 번에 묶고, 49편부터 자주 쓰는 6종(String·Hash·List·Set·Sorted Set·Stream)을 하나씩 깊이 풀어 갑니다.

Redis가 뭔가 — 한 줄 정의부터

Redis = "REmote DIctionary Server". 이름 그대로 — 원격에서 접근하는 사전(딕셔너리). 키 하나 던지면 값 하나 돌려주는 키-값 저장소가 본체고, 거기에 값 자리에 들어갈 수 있는 데이터 구조가 13가지나 풍부하다는 게 차별점.

비유 하나로 PostgreSQL과 위치를 잡으면:

• PostgreSQL = 은행 계좌 — 안전하게 보관되고, 모든 거래가 기록되고, 영구적. 다만 입출금 한 번에 수 ms~수십 ms.
• Redis = 지갑 안 현금 — 매우 빠르게 꺼내 쓸 수 있어요. 다만 잃어버리면 (메모리 날아가면) 복구가 까다롭고, 큰 금액은 못 담아요.

"왜 굳이 지갑이 또 필요한가?"라는 질문에는 답이 명확해요. 매번 계좌에서 돈을 빼면 ATM 줄을 서야 합니다. 자주 쓰는 1~2만 원은 지갑에 들고 다니는 게 효율적이죠. Redis가 바로 그 지갑 역할입니다.

핵심 특성 다섯 가지:

• 인메모리 — 데이터를 RAM에 둠. 디스크는 보조(persistence) 용도
• 키-값 모델 — 키로 즉시 접근. SQL 같은 쿼리 없음
• 풍부한 데이터 타입 — 값 자리에 단순 문자열뿐 아니라 List·Set·Hash·Stream 등 자료구조
• 단일 스레드 명령 실행 — 한 번에 한 명령만 처리 → atomic(쪼개지지 않는 한 덩어리) 보장이 자연스러움
• 마이크로초(μs) 단위 지연 — PostgreSQL이 ms 단위라면, Redis는 그보다 1,000배 빠른 영역

Redis가 표준이 된 세 가지 이유

캐시·세션·실시간 처리 도구는 다른 것도 있는데(Memcached·Hazelcast·VoltDB 등), 왜 Redis만 거의 사실상 표준이 됐을까요. 세 가지가 결정적이에요.

(1) 자료구조가 풍부

Memcached는 단순 String 키-값만 다뤄요. "방문자 수 +1" 같은 카운터를 만들려면 클라이언트가 값을 읽고 → +1 하고 → 다시 쓰는 3단계를 직접 처리해야 합니다. 동시 요청이 들어오면 race condition(둘이 동시에 읽고 덮어쓰는 경쟁 상태) 위험.

Redis는 INCR key 한 줄로 끝. 게다가 오늘 방문자 Top 100 같은 랭킹은 Sorted Set 한 줄(ZADD)로 구현. 자료구조가 서버 안에 살아 있으니 비즈니스 로직이 한 줄로 줄어드는 마법.

(2) 활용 영역이 넓음

처음에는 "빠른 캐시" 로 시작했는데, 자료구조가 풍부하다 보니 활용처가 계속 늘어났어요.

• 캐시 — DB 부하 줄이기 (가장 흔한 용도)
• 세션 저장소 — 로그인 정보·장바구니 (브라우저 쿠키 X)
• 랭킹·카운터 — 좋아요 수·실시간 인기 검색어
• 메시지 큐 — List·Stream 으로 간단한 작업 큐
• 분산 락 — 여러 서버가 동시 작업 못 하게
• Pub/Sub(발행-구독 메시지 모델) — 서버 간 실시간 알림
• Rate Limiting — API 호출 횟수 제한
• Vector 검색 — AI 임베딩 유사도 검색 (Redis 8+)

하나의 도구가 이 모든 영역을 다 한다는 점이 운영 입장에서 매우 유리해요. 새 도구 도입 = 새 운영 부담이라, 이미 깔린 Redis로 끝낼 수 있으면 인프라가 단순해집니다.

(3) 단일 스레드 — atomic이 공짜

Redis는 명령 실행이 단일 스레드예요. 처음 들으면 "느리지 않나?" 싶지만, 메모리 접근은 워낙 빠르고 네트워크 I/O를 별도 스레드로 처리해서 단일 스레드 명령 실행이 병목이 안 됩니다.

대신 얻는 게 큽니다 — 모든 명령이 atomic. INCR·LPUSH·SADD 같은 명령은 서버 안에서 한 번에 처리되니 동시성 문제가 원천 차단됩니다. 분산 환경에서 atomic 보장 받기가 얼마나 어려운지 한 번이라도 겪어 봤다면 이 장점이 얼마나 큰지 알 거예요.

Redis vs PostgreSQL — 정확한 역할 분담

여기서 시험 함정이 하나 있어요. "그럼 Redis가 빠르니까 PostgreSQL을 대체할 수 있나요?" — NO. 둘은 서로 다른 문제를 풀어요.

요점 — PostgreSQL은 데이터의 진실(source of truth), Redis는 빠른 사본·실시간 가공물. 둘은 함께 쓰는 게 정석이고, 둘 중 하나를 빼면 시스템이 느리거나(Redis 없음) 데이터를 잃거나(PG 없음) 합니다.

잠깐, 헷갈리는 부분 하나 — "Redis도 디스크에 적는다며 영속 아닌가요?" 맞아요. 다만 그 디스크 쓰기는 "전원 끊기면 최근 몇 초 데이터는 사라질 수 있는" 비동기 백업 성격이라, 진짜 영속 보장은 여전히 PostgreSQL 같은 디스크 우선 DB의 몫이에요. Redis persistence는 "메모리 날아가도 99% 복구되게" 정도지 "100% 보장"이 아닙니다. (66편 persistence에서 깊게 풀어요)

한 줄 정리 — PG = 영속 본진, Redis = 빠른 사본·가공물. 대체 X, 보완 O.

Redis가 빛나는 6가지 자리

처음 Redis를 도입할 때 "어디부터 끼워 넣을까"가 늘 고민이에요. 가장 흔한 6가지 활용처를 짧게 소개합니다 (각각 60~70편에서 깊이 풀어 가니 여기선 "이런 게 가능하구나" 만 잡으면 OK).

1. DB 쿼리 캐시 — 자주 조회되는 SELECT 결과를 Redis에 저장 → 두 번째부터는 DB 안 거치고 Redis에서 바로. 응답 시간 ms → μs로.
2. 세션 저장소 — 로그인 정보를 Redis에 두면 여러 서버가 같은 세션 공유. Sticky session(특정 서버에 사용자 고정) 안 써도 됨.
3. 랭킹/실시간 인기 — Sorted Set으로 Top N 즉시 계산. ZADD board <score> <user> + ZREVRANGE board 0 9 두 줄.
4. 카운터·중복 체크 — INCR pv:2026-05-17 로 일별 방문자 수. SADD seen:user42 article99 로 중복 노출 방지.
5. 분산 락 (Distributed Lock — 여러 서버가 같은 자원에 동시 접근 못하게 거는 잠금) — 여러 서버가 같은 자원에 동시 작업하지 못하게. SET key value NX EX 30 패턴 (Redlock 알고리즘 — 다수 노드로 락을 분산해 안전을 높이는 방식)
6. Pub/Sub·메시지 큐 — 서버 간 알림 또는 간단한 작업 큐. PUBLISH channel msg / SUBSCRIBE channel. 정식 메시지 큐(Kafka)보다 가벼운 영역.

여기서 정말 중요한 시험 함정 — 모든 캐시는 날아갈 수 있다는 가정으로 짜야 합니다. Redis 인스턴스가 재시작되거나 메모리가 가득 차 eviction(쫓아내기 — 오래된 키를 자동으로 제거)이 발동하면 캐시는 사라집니다. 없어지면 PG에서 다시 가져오는 패턴(cache-aside — 앱이 캐시 miss 시 직접 DB 조회)을 기본으로 짜야 운영 사고가 안 나요.

Redis 학습이 다른 도구와 다른 점

Redis는 "명령어가 곧 API"라는 특이한 학습 곡선이 있어요. SQL 같은 언어가 아니라 명령어 200여 개를 외우는 식. 부담스러워 보이지만, 실제로는:

• 자주 쓰는 명령어는 타입당 5~10개 — 30~50개만 알면 일상 70%
• 나머지는 "이런 게 있구나" 만 알고 필요할 때 검색
• 한 번 익히면 "이건 String? Sorted Set?" 같은 자료구조 매칭이 빠르게 익숙해짐

이 시리즈 33편은 그 익숙해지는 과정 을 친절히 풀어 줘요. 자주 쓰는 6종 데이터 타입(49~54편)을 직접 손으로 박아 보고, 패턴 4편(62~65편)으로 어떤 자료구조를 어떤 상황에 쓰는지 감을 잡고, 운영 6편(66~71편)으로 실제 서비스에 깔 때 신경 쓸 부분을 마무리합니다.

공식 문서: Redis Documentation에서 모든 명령어와 사양을 확인할 수 있어요. 영문이지만 명령어 reference는 짧고 명확해서 한 번씩 찾아보는 습관이 도움 됩니다.

한 줄 암기 — Redis = 인메모리 + 키-값 + 자료구조 13종 + 단일 스레드 atomic. PG와는 대체가 아닌 보완.

시험 직전 한 번 더 — Redis 입문자가 매번 헷갈리는 것

• Redis = REmote DIctionary Server — 원격 사전
• 인메모리 + 키-값 + 자료구조 13종 + 단일 스레드 명령 실행
• PG와 관계 = 대체 X, 보완 O — PG는 진실, Redis는 빠른 사본
• 지연 시간 = μs (PG는 ms, 1,000배 빠름)
• 자료구조 = String·Hash·List·Set·Sorted Set·Stream·Bitmap·Bitfield·Geo·JSON·Vector·TimeSeries·Probabilistic
• 자주 쓰는 6종 = String·Hash·List·Set·Sorted Set·Stream
• 표준이 된 이유 3가지 = 풍부한 자료구조 / 활용 영역 / 단일 스레드 atomic
• Memcached와 차이 = Memcached는 단순 String, Redis는 자료구조
• 영속(persistence) 메커니즘 = RDB(스냅샷) + AOF(쓰기 로그)
• persistence ≠ 영구 보장 — "메모리 날아가도 거의 다 살아나는" 수준 (66편)
• 활용 6가지 = 캐시·세션·랭킹·카운터·분산 락·Pub/Sub
• 캐시는 항상 날아갈 수 있다는 가정으로 짤 것 (cache-aside)
• 단일 스레드라 = INCR·ZADD 같은 명령이 자동으로 atomic
• 동시성 처리 = MULTI/EXEC·Lua script (59·60편)
• 명령어 200여 개 — 타입당 5~10개씩 30~50개만 알면 일상 70%
• Java 클라이언트 = Jedis vs Lettuce — Spring Boot 2.x+ 기본은 Lettuce (79편)
• Spring 연동 = Spring Data Redis (73편)
• 분산 환경 = Redis Sentinel(고가용성 — 마스터 장애 시 자동 승격) + Redis Cluster(샤딩 — 키를 여러 노드에 분산) (68·69편)
• 보안 = ACL(Access Control List — 사용자별 명령 권한) + TLS(전송 암호화) (70·71편)
• 모듈 = RedisJSON·RediSearch·TimeSeries·Vector (74~77편)

시리즈 다른 편 (앞뒤 글 모음)

이전 글:

• 42편 — 운영 설치 바이너리·Docker·관리 서비스
• 43편 — postgresql.conf 핵심 설정
• 44편 — 사용자·역할 관리 CREATE ROLE GRANT
• 45편 — 데이터베이스 관리 생성·복제·드롭
• 46편 — 백업과 복구 pg_dump·PITR

다음 글:

• 48편 — Redis 데이터 타입 13종 한 번에 정리
• 49편 — Redis String 깊이 + 분산 락 패턴
• 50편 — Redis Hash + 객체 캐싱 패턴
• 51편 — Redis List + 큐·캡 리스트 패턴
• 52편 — Redis Set + 집합 연산 패턴