문제 발생
프로젝트 종료 후 운영팀으로 배정되어 실제 서비스에서 Redis를 계속 활용하던 중 예상치 못한 상황이 발생했다. 특히 지난주 특가 이벤트에서 상품 상세 페이지 옵션 데이터 처리 과정에서 지연이 발생했다.
- 상품 상세 페이지는 옵션 고정 정보는 캐시에서, 재고 수량은 DB에서 가져와 두 데이터를 합치는 과정이 필요했다.
- 이벤트 중 일부 상품의 옵션 선택지가 매우 많아(11 × 11 × 9 = 891개), 모든 옵션을 조회하고 반복적으로 setting하면서 지연이 발생했다.
- 기존 프로젝트 진행 중에는 발견할 수 없던 케이스 → 운영에서는 다양한 트래픽 패턴과 예외 상황이 발생한다.
- 트래픽 패턴이나 이벤트 성격에 따라 예기치 못한 캐시 미스도 반복됐다.
단순 캐싱만으로는 해결되지 않는 운영 특화 문제가 존재했고, 새로운 과제가 계속 주어졌다.
원인 파악
- 옵션 수가 많아지면 캐시와 DB 데이터를 합치는 patch 로직이 반복적으로 수행되어 성능 병목이 발생한다.
- 이벤트 트래픽 집중 시, 단일 상품의 옵션 처리 과정이 전체 페이지 로딩 속도에 영향을 준다.
- 개발 단계에서는 이런 극단적 조합 케이스를 확인하기 어렵다 → 운영에서만 확인 가능.
- 상품/전시 페이지의 미리보기 기능 등 일부 기능은 캐시 예외 처리가 별도로 필요하다.
해결 및 개선 방향
1. 쿼리 및 로직 최적화
옵션 데이터 조회와 patch 로직을 개선하고, 반복적으로 setting하는 부분을 효율화해 지연 시간을 최소화했다.
2. 운영 친화적인 Redis 전략 수립
- 고정 데이터와 동적 데이터를 분리해 캐싱 (고정 정보는 Redis, 수량 등 실시간 정보는 DB 조회)
- 미리보기, 특가 이벤트 등 상황별 캐시 예외 처리 정책 적용
- Warm-up 등 확장 가능한 전략 추가 검토
3. 지속적 피드백 반영
기획팀과 협업하여 실시간 반영이 필요한 데이터와 TTL 정책을 조정하고, 장애 및 지연 사례를 기반으로 개선 포인트를 계속 추가하고 있다.
효과 / 깨달음
- 운영 과정에서 나타나는 다양한 케이스를 직접 경험하며 Redis 캐싱 전략의 한계와 확장 포인트를 학습했다.
- 프로젝트 종료 후에도 지속적인 모니터링과 개선이 서비스 안정성과 사용자 경험 품질을 결정함을 체감했다.
- Redis 프로젝트는 단순히 한 번 끝나는 개발 과제가 아니라, 서비스 안정성과 사용자 경험 품질을 계속 유지·향상시키는 운영 과제라는 걸 깨달았다.
- “완료”보다 “지속 개선”이 더 큰 의미를 가진다는 점에서, Redis는 단순한 캐시 솔루션을 넘어 서비스 성장의 핵심 인프라로 자리잡았다.
시리즈 마무리
Redis 프로젝트는 개발 과정에서의 문제 해결과 운영 경험을 통해, 단순 캐시 구현을 넘어 실제 서비스 운영에 맞춘 캐싱 전략과 개선 프로세스를 확립할 수 있었다.
앞으로도 운영 상황과 이벤트 성격에 따라 Redis 활용 방법을 지속적으로 개선할 계획이다.
아무리 예상을 많이 해도 예상치 못한 문제가 나온다는 걸 배운 그런 프로젝트였다.
