Redis 안을 도시처럼 걸어 다녀볼 수 있다면
Redis를 안 써본 백엔드 개발자는 거의 없을 거예요. 캐시로, 세션 저장소로, 랭킹 보드로, 작업 큐로 정말 많이 쓰이잖아요. 그런데 'Redis가 내부에서 어떻게 동작하나요?'라고 물으면 '음... 메모리에 저장하고... 싱글 스레드고...' 정도에서 말이 끊기는 경우가 많아요. 문서를 읽어도 글자로만 이해하다 보니 요청 하나가 어디로 들어가서 어떻게 처리되는지 그림이 잘 안 그려지거든요.
Redis City는 이 문제를 아주 직관적인 방식으로 풀었어요. Redis 서버의 구성 요소를 3D 도시의 건물과 도로처럼 배치해놓고, 브라우저에서 직접 돌아다니며 각 부분이 무슨 일을 하는지 확인할 수 있게 만든 인터랙티브 사이트예요. 개인 개발자가 만든 프로젝트인데, 학습 자료로 쓰기에 아주 좋아요.
도시를 둘러보기 전에 알아둘 Redis의 핵심 구조
Redis City를 제대로 즐기려면 어떤 건물이 왜 거기 있는지 알아야 하니까, 핵심 개념을 짚어볼게요.
단일 스레드 이벤트 루프. 이게 뭐냐면, Redis는 명령을 처리하는 스레드가 기본적으로 하나예요. 은행 창구가 하나뿐인데 엄청나게 빠른 직원이 앉아 있는 셈이죠. 그런데도 초당 수십만 요청을 처리할 수 있는 이유는 모든 데이터가 메모리에 있고, 창구가 하나라서 락(잠금)을 걸 필요가 없고, epoll 같은 I/O 멀티플렉싱으로 수천 개 연결을 한 번에 지켜볼 수 있기 때문이에요. 반대로 말하면 시간이 오래 걸리는 명령 하나가 창구를 막으면 뒤에 선 모든 요청이 기다려야 해요. 운영 환경에서 KEYS 명령을 쓰지 말라는 이유가 바로 이거예요. Redis 6부터는 네트워크 읽기와 쓰기만 따로 I/O 스레드로 분산할 수 있게 됐지만, 명령 실행 자체는 여전히 하나의 줄로 처리돼요.
자료구조. Redis가 '키-값 저장소'라고 불리지만 값의 종류가 다양해요. 문자열(String), 리스트(List), 해시(Hash), 집합(Set), 정렬된 집합(Sorted Set), 스트림(Stream) 등이 있죠. 재미있는 건 같은 타입이라도 크기에 따라 내부 구현이 바뀐다는 점이에요. 예를 들어 작은 해시는 listpack이라는 촘촘한 배열로 저장해서 메모리를 아끼고, 커지면 진짜 해시 테이블로 바뀌어요. Sorted Set은 스킵 리스트와 해시 테이블을 동시에 들고 있어서, 점수 순 조회와 특정 멤버 조회가 둘 다 빨라요. 랭킹 보드에 딱인 이유죠.
만료와 메모리 관리. TTL을 걸어둔 키는 두 가지 방식으로 지워져요. 누가 그 키를 읽으려 할 때 확인해서 지우는 방식(lazy)과, 주기적으로 키를 무작위 샘플링해서 만료된 걸 정리하는 방식(active)이에요. 메모리가 꽉 차면 maxmemory 정책에 따라 LRU나 LFU 근사 알고리즘으로 키를 밀어내는데, 정확한 LRU가 아니라 샘플 기반 근사라는 점도 알아두면 좋아요.
영속성. 메모리 저장소인데 재시작하면 데이터가 날아가지 않게 하는 방법이 두 가지 있어요. RDB는 특정 시점의 스냅샷을 통째로 파일로 남기는 방식이고, AOF는 실행된 쓰기 명령을 순서대로 로그에 계속 붙이는 방식이에요. RDB는 fork로 자식 프로세스를 만들어서 저장하는데, 이때 copy-on-write 덕분에 부모는 계속 요청을 받을 수 있어요. 대신 메모리 사용량이 순간적으로 늘 수 있죠.
복제와 클러스터. 마스터 하나에 레플리카를 여러 개 붙여 읽기를 분산하고, Sentinel이 마스터 장애 시 자동 승격을 담당해요. 데이터 자체를 쪼개야 하면 Redis Cluster가 16384개의 해시 슬롯으로 키를 나눠서 여러 노드에 분산하고요.
Redis City는 이런 요소들을 도시의 구역처럼 배치해서, 클라이언트 요청이 도시로 들어와 이벤트 루프를 거쳐 자료구조 창고에 닿고, 백그라운드에서는 영속성 담당 구역이 조용히 디스크에 기록하는 흐름을 눈으로 따라갈 수 있게 해줘요.
왜 3D 시각화가 학습에 효과적이냐면
글로 된 문서는 각 요소를 따로따로 설명해요. 그런데 실제 장애는 요소들 사이의 관계에서 나오거든요. 'AOF rewrite가 돌면서 fork가 일어났고, 그 순간 큰 키를 지우는 명령이 이벤트 루프를 막아서 지연이 튀었다' 같은 상황은 각 요소를 공간적으로 배치해서 봐야 이해가 돼요. Bartosz Ciechanowski의 인터랙티브 글이나 Git 시각화 도구가 사랑받는 이유와 같아요.
업계 맥락
Redis 자체도 요즘 변화가 많아요. 2024년에 라이선스를 오픈소스가 아닌 형태로 바꿨다가, 2025년에 AGPL로 다시 오픈소스로 돌아왔죠. 그 사이 Linux Foundation 산하에서 Valkey라는 포크가 나와 AWS와 구글이 밀고 있고, 멀티스레드로 설계된 Dragonfly, 마이크로소프트의 Garnet 같은 대안도 등장했어요. 그런데 이들 대부분이 Redis 프로토콜과 자료구조를 그대로 따르기 때문에, Redis 내부를 이해하는 건 여전히 가장 좋은 출발점이에요.
한국 개발자에게
면접에서 'Redis가 싱글 스레드인데 왜 빠른가요?'는 정말 자주 나오는 질문이에요. 그리고 실무에서 캐시 장애의 상당수가 big key, hot key, 잘못된 명령 하나에서 시작돼요. 이런 문제를 이해하는 데 Redis City 같은 자료로 한 시간 투자하면 충분히 값어치를 해요. 팀 온보딩 자료로 링크 하나 던져주기에도 좋고요.
정리하면
Redis City는 '알고는 있지만 그림이 안 그려지던' Redis 내부를 눈으로 걸어 다니며 익힐 수 있게 해주는 프로젝트예요.
여러분은 Redis 때문에 겪은 장애 중 기억나는 게 있으세요? 그 원인을 이 도시 안 어느 건물에서 찾을 수 있을지 생각해보면 재밌을 것 같아요.
🔗 출처: Hacker News