좋아요는 왜 Redis에만 저장하고, 찜하기는 왜 DB 엔티티를 만들어야 하는가?
상품 서비스에서 “좋아요”와 “찜하기” 기능은 겉보기에는 비슷해 보이지만, 내부적으로는 완전히 다른 성격을 갖는다.
많은 서비스들이 좋아요는 Redis로 처리하고, 찜하기는 RDBMS(Entity)로 저장하는 이유가 무엇인지 논리적으로 정리해본다.
1. 좋아요와 찜하기는 목적이 다르다
두 기능은 사용자 행동 관점에서 유사하지만, 실제 서비스 요구사항은 명확히 다르다.
좋아요(Like)의 목적
- 실시간 반영
- 빠른 카운팅
- 중복 방지
- 즉각적인 UI 반응
즉, 좋아요는 “실시간 반응성”이 핵심이다.
사용자가 버튼을 누르는 순간 즉시 숫자가 바뀌어야 하며, 트래픽이 몰려도 지연 없이 처리되어야 한다.
찜하기(Favorite)의 목적
- 내가 저장한 상품을 다시 확인
- 오래도록 데이터 유지
- 사용자별 목록 제공
- 정확한 무결성 보장
찜하기는 사용자의 “개인 저장소” 역할을 한다.
데이터가 사라지면 안 되고, 사용자별로 정확하게 조회할 수 있어야 한다.
이 차이가 저장소 선택을 완전히 갈라놓는다.
2. 좋아요는 Redis가 적합한 이유
좋아요 기능이 요구하는 기술적 특성을 정리하면 다음과 같다.
2.1 즉시성
좋아요는 “누르는 순간 바로 수가 바뀌는지"가 UX의 핵심이다.
관계형 DB UPDATE는 높은 동시성 상황에서 병목이 발생할 가능성이 있다.
반면 Redis는 메모리 기반이라 읽기/쓰기 속도가 압도적으로 빠르다.
2.2 중복 방지
Redis의 Set 구조(SADD)는 동일 userId가 여러 번 추가되더라도 자동으로 중복을 제거한다.
따라서 별도의 중복 체크 로직 없이 안전하게 처리된다.
2.3 빠른 집계
좋아요 수는 제품 상세 화면에서 매우 자주 사용된다.
Redis의 SCARD는 Set 크기를 즉시 계산해 반환하므로 조회 성능이 뛰어나다.
2.4 장기 저장 필요 없음
좋아요는 '실시간 집계 데이터'로 분류된다.
"사용자가 좋아요를 언제 눌렀는지" 같은 상세 이력은 대부분 비즈니스 핵심 데이터가 아니다.
또한 좋아요 데이터가 조금 늦게 동기화되거나 유실되어도 치명적 영향을 주지 않는다.
정리하면, 좋아요는 다음 특성을 가진다.
- 즉시성 요구
- 높은 트래픽
- 낮은 무결성 요구
- 빠른 카운팅
- 장기 저장 필요 없음
따라서 Redis가 가장 적합하다.
3. 찜하기는 왜 DB 엔티티가 필요한가?
찜하기는 좋아요와 달리 반드시 영구 보관해야 하는 사용자 행동 데이터이다.
3.1 사용자별 조회가 핵심
찜하기 기능의 가장 중요 요구사항은
- 어떤 유저가 어떤 상품을 찜했는지,
- 해당 유저가 찜한 상품 목록이 무엇인지
를 정확히 조회해야 한다는 것이다.
이 부분은 키-값 기반인 Redis보다는 RDB의 관계형 쿼리가 훨씬 적합하다.
3.2 장기적으로 유지해야 하는 데이터
찜하기 내역은 사용자가 며칠, 몇 주, 심지어 몇 달 후에도 다시 확인해야 하는 데이터다.
데이터 손실 가능성이 매우 낮아야 하므로 트랜잭션과 무결성이 필요한 RDB가 적합하다.
3.3 서비스의 핵심 데이터
찜하기는 향후 “사용자 취향 분석”, “개인화 추천”, “마케팅 타겟팅” 등 다양한 비즈니스 기능과 직접 연결된다.
따라서 반드시 안정적으로 보관해야 한다.
3.4 중복 방지를 위해 Unique 제약이 필요
user_id + product_id 조합을 Unique로 관리해야 한다.
이는 RDB의 제약 조건으로 쉽게 보장할 수 있지만 Redis만으로는 강제하기 어렵다.
정리하면 찜하기는 다음 특성을 가진다.
- 사용자 중심 조회 필요
- 데이터 무결성 중요
- 장기 저장 필요
- 비즈니스 핵심 데이터
- Unique 제약 필요
따라서 JPA 엔티티와 RDB 테이블이 필요하다.
4. 왜 같은 사용자 행동인데 저장소를 분리할까?
두 기능은 사용자 인터랙션이라는 공통점이 있지만,
저장소 선택 기준은 ‘데이터의 성질’에 따라 결정된다.
| 구분 | 좋아요 | 찜하기 |
|---|---|---|
| 목적 | 실시간 반응 | 장기 저장 |
| 핵심 쿼리 | 카운트 조회 | 유저별 목록 |
| 무결성 | 낮음 | 매우 중요 |
| 중복 방지 | Redis Set | Unique 제약 |
| 읽기 패턴 | Product 기준 | User 기준 |
| 저장 기간 | 비영구 | 영구 |
| 적합한 저장소 | Redis | RDB |
동일해보이는 기능도, 데이터 성격에 따라 적합한 저장소는 다르다.
5. 결론
좋아요는 실시간 이벤트 데이터이며 Redis가 최적이다.
찜하기는 사용자 행동 이력 데이터이며 RDB 테이블로 영구 보관해야 한다.
- 좋아요는 “빠르고 즉각적인 피드백이 가장 중요”
- 찜하기는 “정확하고 보존 가능한 정보가 가장 중요”
동일한 사용자 액션처럼 보여도, 서비스 요구사항을 깊게 분석해보면
각 기능이 요구하는 저장소의 특성이 완전히 다르다는 것을 알 수 있다.
