Mini Redis를 직접 구현하고 게시판에 붙여본 프로젝트 정리
1. 왜 이 프로젝트를 시작했나
처음에는 Redis를 그냥 빠른 저장소 정도로만 이해하고 있었다.
그런데 단순히 SET, GET 명령만 구현하면 “그래서 이게 어디에 쓰이는데?”라는 질문에 답하기 어렵다고 느꼈다.
그래서 이번 프로젝트는 다음 목표를 가지고 진행했다.
- Mini Redis를 직접 구현하기
- Redis를 실제 웹페이지에 연결해 보기
- MongoDB와 Redis의 역할을 분리해 보기
- 세션, 캐시, 조회수 같은 Redis의 대표 사용 사례를 직접 시연할 수 있게 만들기
즉, 이번 프로젝트의 핵심은
“Redis 명령어 구현”보다 “Redis를 왜 쓰는지 보여주는 것” 이었다.
2. Redis를 어떻게 이해했는가
프로젝트를 하면서 Redis를 가장 쉽게 이해한 방식은 이거였다.
Redis는 메모리에 있는 초고속 key-value 저장소다.
Python으로 비유하면 딕셔너리와 비슷하다.
store = {
"session:abc123": {"username": "donghyun"},
"views:post:1": 132,
"cache:top_posts": [...]
}하지만 단순한 dict와 다른 점도 있다.
외부 서버처럼 분리해서 사용할 수 있음
TTL 같은 만료 기능이 있음
세션, 캐시, 카운터처럼 빠른 반응이 필요한 곳에 잘 맞음
필요하면 dump 파일로 저장/복구도 가능함
즉, Redis는 단순한 변수 하나가 아니라
서비스 안에서 빠른 임시 데이터를 관리하는 저장소 라고 이해하게 되었다.
3. 프로젝트 전체 구조
이번 프로젝트는 크게 3개 서버/영역으로 나뉘었다.
브라우저
↓
게시판 FastAPI 서버
├─ MongoDB : 게시글 원본 데이터 저장
└─ Mini Redis 서버 : 세션 / 캐시 / 조회수 저장
역할을 정리하면 이렇다.
MongoDB
게시글 제목
게시글 본문
작성자
영구 보관용 조회수
Mini Redis
로그인 세션
게시글 단건 캐시
인기글 캐시
조회수 카운터
즉,
원본 데이터는 MongoDB
빠른 임시 데이터는 Redis
이렇게 역할을 나눴다.
4. Mini Redis는 어떻게 구현했나
Mini Redis의 내부 구조는 생각보다 단순하다.
핵심은 두 개의 저장소였다.
store = {}
expire_at = {}
store
실제 key-value 데이터 저장
expire_at
TTL 만료 시간 저장
여기에 다음 기능을 붙였다.
set(key, value)
get(key)
delete(key)
exists(key)
incr(key)
setex(key, seconds, value)
ttl(key)
즉,
메모리 저장소 + 명령 처리 + TTL 처리
이 조합으로 Mini Redis를 만들었다.
5. Redis 서버를 왜 FastAPI 밖으로 뺐나
처음에는 Redis를 FastAPI 내부에서 그냥 dict처럼 들고 있었다.
이 구조는 너무 빨랐다.
왜냐하면
같은 프로세스 안에서
같은 메모리를 바로 읽고
네트워크 요청도 없었기 때문이다
이렇게 되면 Redis가 너무 비정상적으로 빠르게 보였다.
그래서 구조를 더 현실적으로 만들기 위해 Mini Redis를 별도 서버로 분리했다.
게시판 서버 -> HTTP -> Mini Redis 서버
이렇게 바꾸고 나니 확실히 느낀 점이 있었다.
구조는 더 실제 서비스에 가까워졌다
하지만 단건 읽기에서는 오히려 MongoDB가 더 빠를 때도 있었다
이걸 통해
“Redis는 무조건 모든 상황에서 더 빠른 게 아니라, 어떤 작업에 쓰느냐가 중요하다” 는 걸 더 명확히 이해하게 되었다.
6. MongoDB는 왜 붙였나
처음에는 JSON 파일이나 SQLite 같은 로컬 저장소를 사용했다.
하지만 실제 서비스 구조를 더 닮게 만들고 싶어서 MongoDB로 바꿨다.
MongoDB를 붙이면서 바뀐 점은 다음과 같다.
게시글 원본 데이터가 외부 DB 서버에 저장됨
FastAPI가 직접 MongoDB에 요청해서 데이터를 읽음
게시글 생성/수정/삭제가 더 현실적인 구조가 됨
즉,
Redis는 메모리 임시 저장소,
MongoDB는 원본 데이터 저장소
라는 구분이 더 분명해졌다.
7. 웹페이지에서 어떤 기능을 만들었나
단순한 콘솔 시연 대신, 실제 서비스처럼 보이는 게시판 형태로 만들었다.
구현한 대표 기능은 다음과 같다.
- 게시글 목록 조회
전체 게시글 목록 표시
게시글 제목, 작성자, 조회수 확인 가능 - 게시글 상세 보기
처음 읽을 때는 DB read
다시 읽을 때는 cache read - 로그인 / 로그아웃
로그인 시 세션 토큰 생성
Redis에 session:{token} 저장
새로고침 후 세션 복구 가능 - 조회수 증가
게시글 보기 클릭 시 조회수 1 증가
Redis에서 빠르게 처리
MongoDB에도 반영 - 인기글 캐시
인기글 계산 결과를 Redis에 저장
다음 요청에서 바로 재사용 - 데모용 기능
게시글 100개 자동 생성
조회수 랜덤 주입
DB 초기화
속도 비교
즉,
보여주기용 데모가 아니라 Redis가 실제 어디에 쓰이는지 설명할 수 있는 기능들 위주로 구성했다.
8. 조회수는 왜 Redis에 두었나
이번 프로젝트에서 가장 Redis답게 느껴졌던 기능은 조회수였다.
조회수는 특징이 명확하다.
숫자 하나를 아주 자주 바꿈
동시에 많은 요청이 올 수 있음
빠르게 반응해야 함
이런 작업은 DB보다 Redis에 더 잘 맞는다.
현재 조회수 흐름은 이렇다.
사용자가 게시글 보기 클릭
Redis의 views:post:{id} 증가
증가된 값을 MongoDB에도 저장
화면에 최신 조회수 표시
엄밀히 말하면 실서비스에서는
Redis에서만 먼저 처리하고 DB에는 나중에 반영하는 경우가 많다.
하지만 이번 프로젝트는 학습용이라
Redis의 빠른 반응
MongoDB의 영구 저장
을 둘 다 보여주기 위해
Redis 증가 후 MongoDB 반영 구조로 만들었다.
9. 캐시는 어떻게 동작하게 했나
게시글 단건 캐시는 다음 흐름으로 동작한다.
첫 번째 요청
Redis에 post:{id} 없음
MongoDB에서 게시글 읽기
Redis에 캐시 저장
화면에는 DB READ
두 번째 요청
Redis에 post:{id} 있음
Redis에서 바로 읽음
화면에는 CACHE READ
즉,
처음엔 DB, 다음엔 캐시
이 흐름을 웹페이지에서 바로 볼 수 있게 했다.
인기글도 비슷하다.
첫 번째 요청
cache:top_posts 없음
게시글 목록을 읽고 정렬해서 계산
Redis에 저장
다음 요청
Redis에 이미 cache:top_posts 있음
바로 반환
이 흐름 덕분에
“Redis는 이미 계산한 결과를 다시 쓰는 저장소” 라는 점을 명확히 설명할 수 있었다.
10. TTL과 만료는 왜 중요했나
Redis를 설명할 때 TTL은 빠질 수 없는 기능이었다.
이 프로젝트에서는
세션 TTL
게시글 캐시 TTL
인기글 캐시 TTL
을 넣었다.
이게 중요한 이유는 Redis가 보통
영구 저장소가 아니라
잠깐 저장해두고
필요 없어지면 사라지는 데이터
에 잘 맞기 때문이다.
예를 들어
로그인 세션
인증번호
인기글 캐시
게시글 캐시
이런 데이터는 영구 저장보다 자동 만료가 더 자연스럽다.
11. Redis 서버가 꺼지면 어떻게 되나
이 부분도 프로젝트를 하면서 중요하게 생각한 부분이었다.
Redis는 기본적으로 메모리 저장소라서
서버가 꺼지면 데이터가 사라질 수 있다.
그래서 이 프로젝트에서는 redis_dump.json 파일을 이용해서 dump 저장/복구 기능을 넣었다.
현재 방식은 이렇다.
값이 바뀔 때 dump 저장
서버 종료 시 한 번 더 저장
서버 시작 시 dump 읽어서 복구
즉,
완전한 실서비스 수준은 아니지만
Mini Redis가 메모리 기반이면서도 복구는 가능하다 는 점을 설명할 수 있게 만들었다.
12. 성능 비교를 하면서 느낀 점
처음에는 “Redis는 무조건 빠르다” 정도로 생각했다.
그런데 직접 비교해 보니 훨씬 더 중요한 사실을 알게 됐다.
- 게시글 단건 읽기
항상 Redis가 압도적으로 빠른 건 아니었다.
이유는 지금 Mini Redis가
진짜 Redis 서버가 아니라
FastAPI + Python + HTTP 기반 학습용 서버
이기 때문이다.
즉 단건 읽기에서는
MongoDB 직접 접근
Redis 서버 HTTP 호출
을 비교하게 되면서, 캐시가 오히려 더 느릴 때도 있었다.
2. 조회수 증가
이건 Redis가 왜 강한지 훨씬 잘 보여줬다.
왜냐하면 조회수는
숫자 하나를 자주 바꾸는 작업
INCR 한 번이면 끝나는 구조
와 잘 맞기 때문이다.
결국 성능 비교를 통해 얻은 결론은 이거였다.
Redis는 무조건 모든 상황에서 더 빠른 저장소가 아니라,
캐시, 세션, 카운터처럼 특정 용도에서 강한 저장소다.
이건 프로젝트를 하기 전보다 훨씬 더 현실적인 이해였다.
13. 이 프로젝트를 하면서 가장 크게 배운 점
이번 프로젝트를 하면서 가장 크게 느낀 건,
Redis를 DB의 대체재처럼 보면 안 된다는 점이었다.
Redis와 DB는 경쟁 관계가 아니라 역할 분담 관계에 더 가깝다.
DB가 잘하는 것
원본 데이터 보관
영구 저장
안정적인 기록
Redis가 잘하는 것
빠른 임시 데이터 처리
세션 저장
조회수/좋아요 같은 카운터
캐시 재사용
즉, 실제 서비스에서는
DB가 원본을 지키고
Redis가 빠른 반응을 담당하는
구조가 자연스럽다는 걸 직접 구현하면서 이해하게 되었다.
14. 프로젝트를 통해 보여주고 싶었던 핵심
이 프로젝트에서 가장 보여주고 싶었던 건 딱 하나다.
Redis는 “빠른 저장소”가 아니라,
서비스에서 빠른 반응이 필요한 데이터를 맡기는 저장소다.
그래서 이번 프로젝트는 단순히 명령어 구현으로 끝내지 않고,
게시판이라는 실제 서비스 형태에 연결해서
로그인 세션
게시글 캐시
인기글 캐시
조회수 증가
를 보여주는 방향으로 만들었다.
그 결과,
Redis가 어디에 왜 쓰이는지
이론이 아니라 구조와 화면으로 설명할 수 있는 프로젝트가 되었다.
15. 마무리
처음에는 “Mini Redis를 만든다”는 게 단순히 Redis를 흉내 내는 과제처럼 느껴졌지만,
직접 MongoDB와 분리하고, FastAPI와 연결하고, 게시판에 붙여보면서 생각이 바뀌었다.
이 프로젝트를 통해 이해하게 된 건 다음과 같다.
Redis는 메모리 기반 key-value 저장소다
DB와 Redis는 역할이 다르다
캐시, 세션, 카운터는 Redis에 잘 맞는다
Redis를 설명하려면 명령어보다 사용처를 보여주는 게 중요하다
즉 이번 프로젝트는
Mini Redis 구현 프로젝트이면서 동시에 Redis를 설명하는 프로젝트 였다.
