2026/03/19 10

크래프톤 정글 — Week 3 WIL

"세 번째 WIL을 쓴다. 4주가 지났고, 블로그엔 67개의 글이 쌓였다.숫자보다 중요한 건 그 안에서 내가 무엇을 배웠는가이다."Week 3: Data Structures & Algorithms Deep Dive📌 이번 주 목표 3가지✅ 목표 1: 자료구조를 코드로 이해한다 — 배열이 아니라 직접 구현으로.✅ 목표 2: Redis를 쓰는 사람이 아니라, Redis를 만드는 사람이 된다.✅ 목표 3: 팀 프로젝트에서 내 코드가 팀의 코어 엔진이 될 수 있도록 설계한다.세 가지 모두 달성했다. 단, "만든다"의 의미가 각기 달랐다. 목표 1은 자료구조의 내부 동작 원리를 깨닫는 과정이었고, 목표 2는 라이브러리 없이 밑바닥부터 쌓아 올리는 고통이었으며, 목표 3은 단순 구현을 넘어 아키텍처를 고민하는 시..

크래프톤 정글 × 수요코딩회 - 자체제작 Redis, 타겟팅 서비스

크래프톤 정글 × 수요코딩회Redis를 직접 만들어보며배운 것들"Redis를 구현하라" — 단순한 과제를 티케팅 서비스로 확장한4인 팀 프로젝트 회고👥 4인 팀 🐍 Python Only 📦 PyMiniRedis 🎫 Ticketing ServicePrologueRedis를 쓰면서 한 번쯤은 생각해봤을 것이다."이거 대체 어떻게 동작하는 거야?"크래프톤 정글에서 수요코딩회 과제로 Redis를 직접 구현하는 팀 프로젝트가 주어졌다. 과제 자체는 간단했다. Redis라는 키워드를 받았고, 그걸 구현해보라는 것. 외부 라이브러리를 가져다 쓰는 게 아니라, Redis가 하는 일을 우리 손으로 직접 만들어보라는 의미였다.이 글은 그 과정에서 내가 직접 설계하고 구현한 것들, 팀과 병합하면서 배운 것들, 그리고..

개발/프로젝트 2026.03.19

#12 🔐 보안·성능·관측: ACL·eviction·latency

빠른 Redis, 안전하게 운영하려면? ACL로 최소 권한을 설정하고, eviction으로 메모리를 관리하며, slowlog로 병목을 찾는 운영 필수 지식을 정리합니다.⚡ "빠른 만큼 운영이 중요합니다"Redis는 빠릅니다. 초당 수십만 건의 요청을 처리할 수 있죠. 하지만 빠른 만큼 잘못 사용하면 순식간에 메모리가 가득 차거나, 보안 허점이 생기거나, 갑자기 응답이 느려질 수 있습니다.시리즈 마지막 편인 이번 12편에서는 Redis를 안전하고 효율적으로 운영하기 위한 세 가지 핵심 영역을 다룹니다. 첫째는 보안(ACL) — 최소 권한 원칙으로 위험을 줄이는 방법. 둘째는 성능(eviction + pipelining) — 메모리를 관리하고 RTT를 최소화하는 방법. 셋째는 관측(slowlog + late..

개발/REDIS 2026.03.19

#11 🗂️ 클러스터: 샤딩·해시 슬롯·제약

Redis 서버 한 대의 메모리가 부족해졌을 때, 여러 노드에 데이터를 나눠 저장하는 클러스터를 이해합니다.💾 "메모리가 부족해지면 어떻게 하나요?"서비스가 성장하면서 Redis에 저장해야 할 데이터가 늘어납니다. 처음에는 서버 메모리를 늘리면(Scale-Up) 됩니다. 하지만 한 대 서버의 메모리에는 한계가 있습니다. 그때는 서버를 여러 대로 늘리는(Scale-Out) 방법이 필요합니다.Redis Cluster는 데이터를 여러 노드에 나눠서 저장하는 공식 분산 솔루션입니다. 각 노드는 전체 데이터의 일부만 담당하고, 클라이언트는 어떤 노드에 요청해도 올바른 노드로 자동 리다이렉트됩니다.Cluster는 Sentinel과 다릅니다. Sentinel은 "한 대가 죽으면 다른 한 대가 대신"하는 고가용성(H..

개발/REDIS 2026.03.19

#10 🔄 복제·고가용성: Replication·Sentinel

"Redis 서버 한 대가 다운되면 서비스가 멈추나요?" — 복제와 Sentinel로 장애에 강한 고가용성 구성을 만들어 봅니다.🔥 "서버 한 대 죽으면 서비스가 멈추나요?"새벽 2시, 갑자기 Redis 서버가 죽었습니다. 캐시도, 세션도, 실시간 기능도 모두 멈춥니다. 사용자들은 오류 화면을 보고, 고객 센터 전화가 빗발칩니다. 이런 상황을 막으려면 어떻게 해야 할까요?답은 이중화(Redundancy)입니다. 메인 서버(Primary)와 똑같은 데이터를 가진 복사본(Replica)을 항상 준비해 두는 것이죠. Primary가 죽으면 Replica가 즉시 역할을 이어받습니다. 이것이 고가용성(High Availability, HA)의 기본 원리입니다.Redis는 복제(Replication)로 Prima..

개발/REDIS 2026.03.19

#9 💾 퍼시스턴스: RDB·AOF·복구 체크

"Redis는 메모리 DB니까 꺼지면 다 날아가지 않나요?" — 아닙니다! RDB와 AOF로 데이터를 안전하게 보관하는 방법을 알아봅니다.❓ "Redis 꺼지면 데이터 다 사라지나요?""Redis는 메모리에 데이터를 올려놓는 DB잖아요. 서버가 꺼지거나 재시작되면 데이터가 다 날아가는 거 아닌가요?" 이 질문은 Redis를 처음 배우는 분들이 가장 많이 하는 질문 중 하나입니다.반은 맞고 반은 틀립니다. 기본 설정에서는 데이터가 유실될 수 있습니다. 하지만 Redis는 디스크 퍼시스턴스 기능을 제공하며, 올바르게 설정하면 재시작 후에도 데이터를 복구할 수 있습니다.Redis의 퍼시스턴스 방식은 크게 두 가지입니다. RDB(Redis Database)는 특정 시점의 메모리 스냅샷을 디스크에 저장합니다. A..

개발/REDIS 2026.03.19

#8 ⚔️ 동시성 제어: 트랜잭션(MULTI/EXEC)·WATCH

재고 5개인데 동시 주문 10개가 들어왔다면? Redis 트랜잭션과 WATCH로 경쟁 상태(Race Condition)를 안전하게 처리하는 법을 배웁니다.🛒 경쟁 상태: 재고가 마이너스가 됐어요!온라인 쇼핑몰에서 마지막 남은 티켓 1장에 두 명이 동시에 "구매" 버튼을 눌렀습니다. 두 요청이 거의 동시에 처리되면 어떻게 될까요? 첫 번째 요청이 재고를 읽고(1개), 두 번째 요청도 재고를 읽고(여전히 1개), 첫 번째가 1을 빼고(0개), 두 번째도 1을 빼면 재고가 -1이 됩니다.이것이 경쟁 상태(Race Condition)입니다. 두 요청이 서로의 존재를 모르고 같은 데이터를 동시에 수정하면서 데이터 무결성이 깨지는 상황이죠. 일반적인 데이터베이스에서는 트랜잭션과 잠금(Lock)으로 이를 해결합니다..

개발/REDIS 2026.03.19

#7 📡 Pub/Sub vs Streams: 실시간 메시징

채팅, 실시간 알림, 이벤트 처리... Redis에는 두 가지 메시징 방식이 있습니다. 언제 Pub/Sub을 쓰고, 언제 Streams를 써야 할까요?🔔 실시간 알림, 어떻게 구현하나요?사용자가 댓글을 달면 원글 작성자에게 즉시 알림을 보내고 싶습니다. 주문이 들어오면 주방 화면에 즉시 표시되어야 합니다. 이런 "실시간 전달"이 필요한 순간, Redis는 두 가지 선택지를 제공합니다.첫 번째는 Pub/Sub(발행/구독)입니다. 이름 그대로 누군가 메시지를 발행(Publish)하면 구독(Subscribe) 중인 모든 수신자에게 즉시 전달됩니다. 마치 라디오 방송처럼, 방송 중에 채널을 켠 사람만 들을 수 있습니다.두 번째는 Streams입니다. Streams는 메시지를 로그처럼 디스크에 기록합니다. 나중..

개발/REDIS 2026.03.19

#6🏆 Sorted Sets: 랭킹/리더보드

실시간 게임 랭킹, 인기 게시물 순위, 주간 판매량 TOP10... Redis Sorted Set 하나면 O(log N)으로 즉시 구현됩니다.🎮 실시간 랭킹, 어떻게 만드나요?모바일 게임에서 "주간 랭킹" 기능을 만든다고 생각해 봅시다. 수십만 명의 점수를 매번 DB에서 ORDER BY로 정렬해서 가져오면 어떻게 될까요? 랭킹 화면을 열 때마다 전체 테이블을 스캔해야 하고, 동시 접속자가 많아지면 DB가 과부하에 걸립니다.Redis의 Sorted Set(정렬된 집합)은 이 문제를 원천적으로 해결합니다. 데이터를 넣는 순간부터 자동으로 정렬되어 있고, 순위 조회는 O(log N)으로 매우 빠릅니다. 100만 명의 랭킹도 밀리초 수준에서 조회할 수 있죠.Sorted Set은 각 멤버에 점수(score)를 ..

개발/REDIS 2026.03.19

#5 📬 Lists·Sets: 큐와 중복 방지

이메일 발송, 알림 처리 같은 비동기 작업을 어떻게 안전하게 처리할까요? List와 Set으로 큐와 중복 방지를 구현해 봅니다.🤔 비동기 작업, 어떻게 처리하나요?사용자가 회원가입을 하면 환영 이메일을 보내야 합니다. 그런데 이메일을 보내는 작업은 느립니다. 외부 메일 서버에 요청을 보내고, 응답을 기다리고, 실패하면 재시도해야 하죠. 만약 이 작업을 사용자가 회원가입 버튼을 누르는 순간에 동기적으로 처리한다면 어떻게 될까요?사용자는 가입 완료 화면이 뜨기까지 수 초를 기다려야 합니다. 메일 서버가 잠깐 다운된다면 회원가입 자체가 실패할 수도 있습니다. 이런 상황을 막기 위해 "작업을 등록만 하고, 처리는 나중에"라는 비동기 큐 패턴을 사용합니다.Redis의 List는 바로 이 큐 역할을 아주 쉽게 구..

개발/REDIS 2026.03.19