Redis, 화장실에서 태어나 세상의 속도를 바꾸다 — 등장 배경부터 2026년 현재까지

"아내는 내가 처음 몇 년간 MacBook Air 11인치를 들고 화장실에 앉아서 Redis를 만들었다고 주장한다. 그녀가 틀렸다고 말하고 싶지만, 완벽하게 맞는 이야기다." — Salvatore Sanfilippo (antirez)

오늘날 거의 모든 웹 서비스의 뒤편에는 Redis가 있다. Stack Overflow 개발자 설문에서 4년 연속 "가장 사랑받는 데이터베이스"로 선정되고, Docker Hub에서 매일 가장 많이 실행되는 데이터베이스이며, 2026년 1월 기준 ARR(연간 반복 매출) 3억 달러를 돌파한 이 프로젝트는, 시칠리아의 한 개발자가 자기 스타트업의 성능 문제를 해결하려다 시작된 사이드 프로젝트였다.

---

1. 탄생: 느린 데이터베이스에 대한 분노 (2009)

LLOOGG — 모든 것의 시작

Redis의 창시자 Salvatore Sanfilippo(닉네임 antirez)는 시칠리아 출신의 이탈리아 개발자다. 2009년, 그는 LLOOGG라는 실시간 웹 로그 분석 스타트업을 운영하고 있었다. 문제는 간단했다. 실시간으로 쏟아지는 로그 데이터를 기존 관계형 데이터베이스로는 감당할 수 없었던 것이다.

MySQL이나 PostgreSQL 같은 RDBMS는 디스크 기반이다. 매 요청마다 디스크 I/O가 발생하고, 트랜잭션 오버헤드가 붙는다. 실시간 분석처럼 초당 수천 건의 읽기/쓰기가 필요한 워크로드에서는 구조적 한계가 있었다.

antirez는 먼저 Tcl로 프로토타입을 만들었다. "키-값 쌍을 메모리에 올려놓고 직접 조작하면 되지 않을까?" 이 단순한 아이디어가 Redis의 출발점이었다. 곧 C 언어로 재작성하고, 첫 번째 자료구조인 List를 구현했다. 내부에서 몇 주간 사용해본 뒤 확신이 생겨 Hacker News에 공개했다.

이름의 의미

Redis = Remote Dictionary Server. 원격에서 접근 가능한 딕셔너리(해시맵) 서버라는 뜻이다. 이름 자체가 Redis의 본질을 정확히 설명한다. 테이블도 없고, SQL도 없다. 있는 것은 키와 값, 그리고 그 위에서 동작하는 자료구조 명령어뿐이다.

---

2. 성장: 사이드 프로젝트에서 인프라의 표준으로

2009 — Ruby 커뮤니티의 열광

Redis가 처음 주목받은 곳은 Ruby on Rails 생태계였다. 2009년, GitHub의 CEO Chris Wanstrath가 Redis 기반의 백그라운드 잡 큐 Resque를 만들었다. Rails 세계에서 Resque는 폭발적인 인기를 끌었고, 2012년에 등장한 후속작 Sidekiq 역시 Redis 위에 구축되었다. GitHub과 Instagram이 초기 도입 기업이었다.

2010 — Twitter와 VMware

Twitter가 Redis를 타임라인 페이지에 도입하면서 Redis의 위상이 달라졌다. 흥미로운 건, antirez가 Redis 공개 직후 Retwis라는 Twitter 클론을 Redis 데모용으로 만들었다는 점이다. 본인이 만든 장난감이 실제 Twitter에 채택된 셈이다.

같은 해, VMware에서 연락이 왔다. "우리가 당신을 고용하겠다. 하던 일을 그대로 하면 된다. 웹사이트에 Redis가 VMware의 후원을 받는다고만 적어달라." 약 1년간 무급 사이드 프로젝트였던 Redis가 드디어 공식 후원을 받게 된 순간이었다.

2010~2015 — 자료구조의 확장

이 시기에 Redis는 단순한 키-값 저장소를 넘어 다목적 자료구조 서버로 진화했다:

시기                                    추가된 자료구조                                                                 용 사례

초기	String, List	캐시, 큐
2010~2011	Hash, Set, Sorted Set	세션 관리, 리더보드, 태그
2012+	HyperLogLog	고유 방문자 수 추정
2016+	Streams	이벤트 소싱, 메시지 큐
2018+	Modules (RedisJSON, RediSearch)	문서 DB, 검색 엔진
2024+	Vector Set	AI 벡터 유사도 검색

VMware(2010~2013) → Pivotal(2013~2015) → Redis Labs(2015~2020)로 후원사가 바뀌면서도 antirez는 11년간 단독 메인테이너로서 프로젝트를 이끌었다.

2020 — antirez의 은퇴, 그리고 귀환

2020년 6월, antirez는 Redis 메인테이너 자리에서 물러났다. "유지보수 중심의 단계가 내 성격과 맞지 않는다"는 이유였다. 이후 AI를 소재로 한 SF 소설 Wohpe를 출판하기도 했다.

그리고 2024년 12월, antirez는 Redis 에반젤리스트라는 직함으로 복귀했다. 복귀 후 첫 작업은 Vector Set 자료구조의 구현이었다. AI 시대에 Redis가 벡터 유사도 검색까지 지원하게 된 것은 antirez의 복귀와 직결된다.

---

3. 라이선스 변천: 오픈소스의 빛과 그림자

Redis의 라이선스 역사는 오픈소스 생태계의 축소판이다:

• 2009~2018: BSD-3 라이선스. 완전한 오픈소스.
• 2018: 일부 모듈에 Commons Clause 추가. 클라우드 업체의 무임승차를 견제.
• 2024.3: 코어 Redis 자체가 RSAL v2 + SSPL 듀얼 라이선스로 전환. AWS ElastiCache 등 서드파티 제공 제한.
• 2025: AGPLv3를 추가한 트리플 라이선스로 전환. 다시 오픈소스로 복귀하되, 클라우드 벤더의 직접 패키징은 제한.

이 과정에서 Valkey(Linux Foundation 주도의 Redis 포크)가 탄생했다. 2026년 현재 Redis와 Valkey는 공존하며 경쟁 중이다.

---

4. Redis가 빠른 이유 — 아키텍처의 본질

Redis의 성능은 마법이 아니라 설계 철학의 결과다:

인메모리 스토리지

모든 데이터가 RAM에 상주한다. 디스크 I/O가 읽기/쓰기 경로에서 완전히 제거된다. 일반적인 RDBMS 쿼리가 50~200ms 걸리는 반면, Redis는 0.5~2ms 수준의 응답 시간을 보인다.

싱글 스레드 이벤트 루프

Redis는 명령 처리를 단일 스레드로 수행한다. 직관적으로는 느릴 것 같지만, 실제로는 반대다. 컨텍스트 스위칭이 없고, 락이 필요 없으며, 모든 명령이 원자적(atomic)으로 실행된다. I/O 멀티플렉싱을 통해 수십만 개의 동시 연결을 단일 스레드로 처리한다.

 

 

[클라이언트 1] ──┐
[클라이언트 2] ──┤──→ [이벤트 루프] ──→ [싱글 스레드 명령 실행] ──→ 응답
[클라이언트 3] ──┘       (epoll)          (락 없음, 원자적)

최적화된 자료구조

Redis는 C로 구현된 커스텀 자료구조를 사용한다. 작은 데이터셋에는 메모리 효율적인 인코딩(ziplist 등)을 자동 적용하고, 데이터가 커지면 일반 구조로 전환한다.

영속성 옵션

인메모리라고 해서 데이터를 잃는 건 아니다:

• RDB: 주기적 스냅샷. fork() 시스템 콜로 자식 프로세스가 디스크에 저장하는 동안 부모 프로세스는 계속 서비스.
• AOF: 모든 쓰기 연산을 로그로 기록. 재시작 시 재생하여 복구.
• 혼합 모드: RDB + AOF를 함께 사용하여 빠른 복구와 데이터 안전성을 동시에 확보.

---

5. 활용 사례 — "캐시 그 이상"

Redis를 "캐시"라고만 부르는 것은 스위스 아미 나이프를 "칼"이라고만 부르는 것과 같다.

① 캐싱 (가장 보편적인 활용)

DB 앞에 Redis를 두고 자주 조회되는 데이터를 메모리에 저장한다. Cache-Aside, Write-Through, Write-Behind 등 다양한 전략을 조합할 수 있다.

 

 

typescript

// Cache-Aside 패턴 (Node.js)
async function getProduct(id: string) {
  const cached = await redis.get(`product:${id}`);
  if (cached) return JSON.parse(cached);

  const product = await db.query('SELECT * FROM products WHERE id = $1', [id]);
  await redis.set(`product:${id}`, JSON.stringify(product), 'EX', 600);
  return product;
}

② 세션 스토어

MSA 환경에서 서버가 여러 대일 때, 세션을 특정 서버에 묶지 않고 Redis에 중앙 저장한다. TTL을 설정하면 비활성 세션이 자동으로 만료된다.

 

 

typescript

// Express + Redis 세션
import session from 'express-session';
import RedisStore from 'connect-redis';

app.use(session({
  store: new RedisStore({ client: redisClient }),
  secret: 'your-secret',
  resave: false,
  saveUninitialized: false,
  cookie: { maxAge: 30 * 60 * 1000 } // 30분
}));

③ Rate Limiting

API 남용 방지. Sorted Set이나 단순 INCR + EXPIRE 조합으로 시간 윈도우 기반 요청 제한을 구현한다.

 

 

typescript

async function rateLimit(userId: string, limit: number = 100, windowSec: number = 60) {
  const key = `rate:${userId}`;
  const current = await redis.incr(key);
  if (current === 1) await redis.expire(key, windowSec);
  return current <= limit;
}

④ 실시간 리더보드

Sorted Set의 ZADD, ZREVRANGE, ZREVRANK 명령으로 점수 기반 순위를 실시간으로 관리한다. 게임, 이커머스 판매 순위, 경쟁 플랫폼에서 활용된다.

 

 

typescript

// 점수 업데이트
await redis.zadd('leaderboard:weekly', score, playerId);

// 상위 10명 조회
const top10 = await redis.zrevrange('leaderboard:weekly', 0, 9, 'WITHSCORES');

// 특정 플레이어 순위
const rank = await redis.zrevrank('leaderboard:weekly', playerId);

⑤ Pub/Sub & 메시지 브로커

서비스 간 실시간 이벤트 전달. 채팅, 알림, 캐시 무효화 브로드캐스트에 활용된다. 더 강력한 보장이 필요하면 Redis Streams로 컨슈머 그룹 기반 메시지 처리가 가능하다.

 

 

typescript

// Publisher
await redis.publish('notifications:user:123', JSON.stringify({
  type: 'NEW_MESSAGE',
  from: 'user:456',
  preview: '안녕하세요...'
}));

// Subscriber
subscriber.subscribe('notifications:user:123');
subscriber.on('message', (channel, message) => {
  const notification = JSON.parse(message);
  pushToClient(notification);
});

⑥ 분산 락

MSA에서 공유 리소스에 대한 동시 접근을 제어한다. SET NX EX 명령으로 간단한 뮤텍스를, 더 엄격한 환경에서는 Redlock 알고리즘을 사용한다.

⑦ 지리공간 인덱싱

GEOADD, GEODIST, GEORADIUS 명령으로 좌표 기반 검색이 가능하다. 배달 앱의 "내 주변 음식점", 차량 호출 서비스의 "가까운 드라이버 찾기" 같은 기능에 사용된다.

⑧ AI 벡터 검색 (2024~)

Redis가 Vector Set을 지원하면서, 임베딩 벡터의 유사도 검색이 가능해졌다. LLM의 RAG 파이프라인에서 벡터 DB 역할을 Redis가 대신하는 사례가 빠르게 늘고 있다. 2025년 Stack Overflow 설문에서 Redis는 **AI 에이전트 메모리 저장소로 개발자 선택 1위(42%)**를 차지했다.

---

6. 2026년의 Redis — AI 인프라의 중심

Redis는 단순한 캐시에서 AI 시대의 컨텍스트 엔진으로 진화하고 있다:

• 컨텍스트 엔지니어링: LLM이 올바른 판단을 내리려면 적절한 데이터가 빠르게 제공되어야 한다. 벡터 스토어, 세션 상태, 장기 메모리를 한 곳에서 제공하는 "컨텍스트 레이어"로서 Redis가 부상 중이다.
• LLM 응답 캐싱: 동일한 프롬프트에 대한 LLM 호출을 캐싱하여 비용과 에너지를 절감한다.
• 에이전트 메모리: AI 에이전트의 작업 상태, 대화 히스토리, 도구 호출 결과를 저장하는 실시간 메모리로 활용된다.

Redis CEO Rowan Trollope는 이렇게 표현했다. "에이전틱 의사결정이 이루어지는 스택의 앞단, 바로 그곳이 Redis의 전통적인 자리였다. 개발자들이 자연스럽게 Redis를 AI 워크로드에 채택하고 있는 이유다."

---

7. 실무에서의 선택 기준

Redis가 적합한 경우

• 밀리초 단위 응답이 필요한 읽기 Heavy 워크로드
• 세션, 캐시, 리더보드 등 TTL 기반 임시 데이터
• Pub/Sub 또는 Streams 기반 실시간 이벤트 처리
• MSA 환경에서 서비스 간 공유 상태 저장
• AI/ML 파이프라인의 벡터 검색 및 피처 서빙

Redis만으로는 부족한 경우

• 복잡한 관계형 쿼리 (JOIN, 서브쿼리)
• RAM 용량을 초과하는 대규모 데이터셋
• 강한 트랜잭션 보장이 필요한 금융 원장
• 전문 검색이 핵심인 경우 (Elasticsearch가 더 적합)

핵심은 **"Redis vs DB"가 아니라 "Redis + DB"**라는 것이다. Redis는 DB를 대체하는 것이 아니라, DB의 부하를 흡수하고 응답 속도를 높이는 가속기 역할을 한다.

---

마무리: 단순함의 힘

antirez는 인터뷰에서 반복적으로 **단순함(simplicity)**을 강조했다. "복잡한 시스템은 아무리 노력해도, 프로덕션에서 다른 복잡한 시스템과 만나면 상상할 수 없는 방식으로 실패한다."

Redis가 2009년부터 17년간 살아남은 이유는 기능이 많아서가 아니라, 핵심이 단순해서다. 키와 값, 메모리와 자료구조. 이 근본적인 설계 위에 캐시도, 큐도, 리더보드도, 벡터 검색도 자연스럽게 올라간다.

화장실에서 시작된 이 프로젝트는, "단순한 것이 오래 간다"는 소프트웨어 설계의 원칙을 17년째 증명하고 있다.

---

참고 자료: Redis Wikipedia, Brachiosoft Blog, Redis 공식 블로그, VentureBeat, antirez 개인 사이트