# 당신에겐 Redis가 필요하지 않을 수도 있습니다

> Clean Markdown view of GeekNews topic #19665. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=19665](https://news.hada.io/topic?id=19665)
- GeekNews Markdown: [https://news.hada.io/topic/19665.md](https://news.hada.io/topic/19665.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-03-10T13:20:04+09:00
- Updated: 2025-03-10T13:20:04+09:00
- Original source: [viblo.se](https://www.viblo.se/posts/no-need-redis/)
- Points: 9
- Comments: 5

## Summary

Redis는 뛰어난 기술로 긍정적인 평판을 받고 있지만, 항상 필요한 것은 아닙니다. Tantan, Bannerflow, MAJORITY의 사례에서 Redis 도입이 불필요했음을 확인했으며, 각 회사는 기존 데이터베이스 시스템으로도 충분한 성능을 유지할 수 있었습니다. Redis를 도입하기 전에 실제 필요성과 성능 이점을 충분히 고려해야 하며, 불필요한 복잡성을 피하는 것이 중요합니다.

## Topic Body

- Redis는 기술 업계에서 가장 긍정적인 평판을 얻고 있는 기술 중 하나임  
  - 매우 잘 설계된 뛰어난 기술이고 자체에 결함이 있는 것은 아니지만, **항상 필요하진 않을 수 있음**  
- 10+년동안 3곳의 회사에서 같은 패턴을 봄:   
  - 문제가 발생하고 Redis가 적합해 보였지만, 실제로는 상황을 개선하지 못했거나 근본적인 문제를 해결하지 못함  
  - 그저 **복잡성을 위해 복잡성을 더했을 뿐**  
### **첫 번째 사례: Tantan에서의 경험**  
- Tantan은 중국의 두 번째로 큰 데이팅 앱이며, PostgreSQL 기반의 50~100대의 고성능 데이터베이스 서버를 운영함  
- 각 서버는 사용자 ID별로 샤딩되어 특정 사용자의 데이터는 하나의 서버에만 저장됨  
- **문제 상황**  
  - '스와이프' 횟수를 저장하고 빠르게 업데이트해야 하는 요구사항 발생  
  - 초기에는 Redis에 저장하는 것이 적합하다고 판단함  
  - 고성능 Redis 서버 몇 대만 있으면 충분하다고 생각하고 설정 진행  
- **재고 및 해결책**  
  - 팀 내에서 Redis 대신 PostgreSQL에 직접 저장하는 방안을 논의함  
  - PostgreSQL 서버의 부하가 이미 높기 때문에 추가 부하는 미미할 것으로 예상  
  - PostgreSQL에 저장한 후에도 성능 저하가 없었고, Redis 도입이 불필요했음  
  
### **두 번째 사례: Bannerflow에서의 경험**  
- **배경**  
  - Bannerflow는 광고 제작 및 게시 플랫폼임  
  - 새로운 마이크로서비스에서 Facebook 같은 소셜 네트워크에 광고 게시를 지원하기 위해 Redis 도입 결정  
- **문제 상황**  
  - 로드가 Tantan에 비해 현저히 낮은 상황에서 Redis 도입이 필요했는지 불분명함  
  - 초기 개발자가 떠난 후 Redis 도입 이유를 명확히 설명할 수 있는 사람이 없음  
- **결과**  
  - Redis는 로드가 낮아 굳이 필요하지 않았음  
  - 장기적으로 Redis를 제거하는 것이 최선이라는 결론에 도달  
  
### **세 번째 사례: MAJORITY에서의 경험**  
- **배경**  
  - MAJORITY는 핀테크 회사로 외부 API 호출 결과를 캐싱하기 위해 Redis 도입  
  - Redis는 위치 조회 데이터를 캐싱해 처리 속도를 높이고 비용을 절감하기 위해 도입됨  
- **문제 상황**  
  - 동일한 데이터가 DB(Azure SQL)에도 저장됨  
  - Redis 호출 대신 DB 호출로 교체해도 부하 증가가 거의 없을 것으로 예상됨  
  - 잠금(lock) 처리가 필요해 Redis를 계속 사용하려 했으나, Azure SQL에서 충분히 처리 가능했음  
- **결과**  
  - Redis 도입이 불필요하다는 결론에 도달  
  - Redis 대신 Azure SQL 사용으로 전환 계획 수립  
  
### **결론**  
- 세 가지 사례는 모두 서로 다른 도메인, 기술 스택, 로드 조건에서 발생했음  
- 공통점은 불필요한 Redis 도입이었음  
- Redis 도입 전에는 실제 필요성과 성능 이점을 충분히 고려해야 함  
- **Dan McKinley의 'Choose Boring Technology' 강연 추천**

## Comments



### Comment 35657

- Author: iolothebard
- Created: 2025-03-10T16:07:23+09:00
- Points: 1

레디스 사용여부를 떠나 도메인과 퍼시스턴스 사이에 캐싱 레이어를 끼워놓는(기본 구현은 바이패스) 건 전혀 오버엔지니어링이 아님. 로깅, 페이크데이터, 디버깅, 프로파일링, 어쩌면 진짜 캐싱…

### Comment 35661

- Author: nodelay
- Created: 2025-03-10T17:19:42+09:00
- Points: 1
- Parent comment: 35657
- Depth: 1

+1 저도 동의합니다. 레이어 하나 추가하는 것만으로도 `여지` 가 생기고, 수많은 일들을 해결할 수 있는 공간을 만들어주죠.

### Comment 35647

- Author: galadbran
- Created: 2025-03-10T14:02:21+09:00
- Points: 1

레디스에 문제가 있다기 보다는 DB만으로 충분한데 왜 추가 구성 요소를 도입해서 관리 부담을 높여야 하느냐는 관점으로 보입니다.   
좀 간략하게 설명하고 있는 편이라서, 이런 관점도 생각해봐야 한다는 정도로 받아들이면 좋을 것 같네요.   
어플리케이션 로직을 단순하게 유지하면서 레디스 캐시를 도입하는 게 더 나은 선택일 수 있는 상황도 있으니  
 상황에 맞게 선택해야 하겠습니다.

### Comment 36291

- Author: zinisuni
- Created: 2025-03-24T15:47:50+09:00
- Points: 1
- Parent comment: 35647
- Depth: 1

타이틀에 낚였네요. ㅎㅎ 동의합니다~~

### Comment 35643

- Author: neo
- Created: 2025-03-10T13:20:05+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=43301432) 
- 2015년 Uber에서 근무할 때, 우편번호 기반의 지리적 분할을 육각형 기반의 방식으로 전환하려고 했음
  - 도시를 수십 개의 우편번호로 나누는 대신, 수십만 개의 육각형으로 나누고 동적으로 영역을 생성하는 방식이었음
  - 피닉스에서 첫 출시가 있었고, 팀은 수요 가격 시스템을 확장하기 위해 밤을 새웠음
  - 글로벌 출시가 지연되었음
  - Redis를 좋아하는 엔지니어들이 많았음
  - 가격 서비스는 Redis를 기반으로 했고, 수백만 건의 요청을 처리했음
  - 비용이 많이 들었고, 확장성 문제도 있었음
  - 알고리즘을 개선하여 단일 기계에서 여러 도시의 동적 영역을 계산할 수 있었음
  - Isaac이라는 엔지니어가 주말 동안 구현하고 배포했음

- Redis를 과도하게 사용하는 것에 대한 논쟁이 있었음
  - Redis는 멋지지만, 사용 시 네트워크 지연과 직렬화 오버헤드가 발생함
  - 데이터가 이미 분할되어 있다면, 일반적인 해시맵이 더 나을 수 있음
  - Java에서는 ConcurrentHashMap, Guava Caches, Caffeine Caches 등이 있음
  - 로컬 캐싱 구현이 네트워크를 사용하는 것보다 거의 항상 빠름
  - Redis는 과도하게 사용되는 경향이 있음

- Redis 사용 문화가 그 인기에 비해 발전하지 않았음
  - Redis는 다양한 데이터 구조를 지원하며, 회사 문화가 발전할수록 더 많은 패턴을 배울 수 있음
  - Redis의 패턴 모음집이 없다는 것이 아쉬움

- Redis와 비Redis의 문제가 아니라, 직렬화가 잘 되지 않는 데이터와의 작업 문제임
  - 카운터, 뉴스 피드, 채팅 메시지 등은 Redis가 더 효율적일 수 있음
  - 대부분의 경우 MySQL로도 충분히 처리 가능함

- 소프트웨어 개발은 종종 다른 사람의 방식을 반복하는 경향이 있음
  - Memcached에서 시작하여 Redis로 발전했음
  - 데이터베이스의 복잡성을 피하기 위해 캐시를 사용하는 경향이 있음
  - 데이터베이스는 여전히 복잡하고 어려움

- Redis는 유일한 프로덕션 준비된 "데이터 구조 서버"임
  - 여러 인스턴스에서 동일한 서비스를 접근할 때 유용함

- 캐시가 필요하지 않을 수도 있음
  - 캐시를 도입하지 않고 아키텍처 개선에 집중한 경험이 있음

- Redis의 API는 훌륭하지만, 운영상의 위험이 있음
  - 캐시로는 좋지만, 프로덕션 데이터 저장소로는 신뢰할 수 없음

- Redis 사용을 추천하지 않는 경향이 놀라움
  - Redis는 여전히 훌륭한 데이터 구조와 성능을 제공함

- Redis는 임시 캐시로는 괜찮지만, 트랜잭션이나 분산 저장소로는 부족함
  - 분산 잠금 문제에 대한 학습이 필요함