Redis 불편한 도구 그러나

Redis 지원해주는 기능이 너는 뭐니? 
정말 부가기능이 없다. 리스트에 일일히 넣어줘야 하는 이 불편함.
배열에 배열을 못넣는 이불편함

 

Redis의 철학: 일부러 불친절한 시스템이 주는 신뢰감

Redis를 배우다 보면 이런 생각이 든다.
“왜 이렇게 자동으로 안 해주지?”
그런데 이상하게도, 어느 순간부터는 그 불친절함이 오히려 마음에 들기도 한다.

---

한 문장으로 요약

“자동으로 해주지 않겠다. 대신, 아주 빠르게 해주겠다.”

---

Redis가 일부러 안 해주는 것들

• 조건 검색(WHERE 같은 것) 자동 지원 ❌
• 자동 인덱스 생성 ❌
• 관계형 조인/추론 ❌
• 스키마 강제 ❌
• 자료형 중첩(HASH 안에 HASH 등) ❌
• 필드 단위 TTL ❌ (TTL은 key 단위)

이건 “못해서”가 아니라 의도적으로 제거한 기능이다.
서버가 똑똑해질수록 내부가 복잡해지고, 성능과 예측 가능성이 떨어진다고 판단한 것이다.

---

Redis의 세계관

• 서버는 단순해야 한다
• 연산은 명확해야 한다
• 속도는 예측 가능해야 한다
• 대신 책임은 사용자가 진다

즉, Redis는 “생각하는 서버”가 아니라
“생각하지 않는 서버(명령을 빠르게 수행하는 서버)”에 가깝다.

---

이 철학이 드러나는 대표 사례

• user:* 같은 전체 검색이 기본 기능이 아님 → 검색이 아니라 “키 기반 접근”을 강제
• 조건 검색(name == kim 등)을 자동으로 제공하지 않음 → 필요하면 보조 인덱스를 직접 설계
• HASH 안에 배열/객체를 직접 넣기 어려움 → 중첩 대신 키 설계로 구조를 풀어냄
• TTL이 key 단위 → 객체의 생명주기를 단순하게 유지

---

“자료구조를 모르는 사람은 쓰지 마라” 같은 느낌

Redis를 쓰다 보면 이런 느낌을 받기도 한다.
“자료구조를 모르는 사람은 사용하지 말아라.”
실제로 Redis는 그 말을 문서로 쓰지 않았을 뿐, 시스템 설계로 구현해 둔 것에 가깝다.

Redis가 요구하는 ‘무언의 자격 조건’

• 배열 / 집합 / 큐 / 맵 개념 이해
• 키-값 접근 방식의 감각 (검색이 아니라 직접 접근)
• 상태(state)와 기록(log)의 구분
• 인덱스를 “자동 기능”이 아니라 “설계”로 이해하는 감각

이 감각이 없으면 Redis는 불편하기만 하다.
JSON으로 다 때려 넣거나, DB처럼 검색하려고 하다가 결국 “느린 Redis”가 된다.

---

그래서 Redis는 “편한 도구”가 아니다

DB처럼 한 줄로 끝나는 일을 Redis에서는 여러 단계로 나눠서 처리해야 하는 경우가 많다.
그래서 Redis는 종종 불친절하게 느껴진다.

하지만 그 불친절함 덕분에 얻는 것이 있다.

• 속도가 매우 빠르다 (메모리 기반, 단순 명령)
• 동작이 예측 가능하다 (서버가 추론하거나 자동으로 처리하지 않음)
• 복잡성이 밖으로 드러난다 (설계를 강제해서 구조가 명확해짐)

---

결론

Redis는 “편의성을 버리고 예측 가능성을 선택한 시스템”이다.
자동화를 줄인 대신, 성능과 단순함을 극단적으로 밀어붙였다.
그래서 Redis는 기능을 배우는 느낌이 아니라, 철학을 이해하는 느낌이 든다.