크린토피아 모바일 앱, 단순한 세탁 예약을 넘어 이제는 사용자 맞춤형 경험을 제공하는 플랫폼으로 성장하고 있습니다. 이번 앱 리뉴얼 과정에서는 기존의 느리고 무거운 JSP 기반 웹뷰 구조에서 탈피하여, Spring Boot + WebFlux 기반의 반응형 아키텍처로 새롭게 거듭났습니다. 그러나 기술 스택만 바뀌었다고 해서 속도와 성능이 저절로 개선되는 것은 아니었습니다. 서버와 DB의 부하, 그리고 사용자에게 느리게 전달되는 콘텐츠 문제는 여전히 존재했기 때문입니다. 이러한 문제 해결의 핵심 키워드는 바로 '캐싱'이었습니다.

리뉴얼 과정 중 발견된 문제: JSP 기반 구조의 한계

크린토피아 앱은 오랫동안 웹뷰 + JSP 페이지 호출 방식으로 작동하고 있었습니다. 이는 유지보수와 구현이 간단하다는 장점이 있지만, 다음과 같은 명확한 한계가 있었습니다.

• 모든 페이지 호출마다 JSP가 직접 DB를 조회

• 데이터 처리와 페이지 렌더링이 한 곳에서 동시에 발생

• API화가 되지 않아 재사용성과 확장성이 부족

• 사용자 수가 늘어날수록 DB의 부하가 급격히 증가

특히 이벤트, 혜택, 이용안내 등 자주 조회되지만 자주 변경되지 않는 콘텐츠들조차 매번 DB를 호출하는 방식은 매우 비효율적이었습니다. 결과적으로 전체 앱의 반응속도는 느려졌고, 사용자 만족도 역시 떨어지고 있었습니다.

왜 Redis 기반 캐싱을 선택했는가?

이번 리뉴얼에서는 AWS와 같은 클라우드 기반 인프라 없이, 자체 인프라 내에서 성능 개선을 꾀해야 했습니다. 이런 상황에서 가장 적합한 솔루션은 경량의 인메모리 캐싱 시스템, 그 중에서도 Redis였습니다.

Redis 선택의 이유

• 인메모리 저장 방식으로 빠른 데이터 응답

• Key-Value 구조로 API 캐싱에 최적화

• TTL(Time To Live) 설정으로 캐싱된 데이터의 수명 조절 가능

• 오픈소스로 관리와 확장이 자유로움

• 기존 Spring 환경과의 연동성 우수

결과적으로 Redis는 개발 속도, 운영 효율성, 그리고 성능 모두에서 최적의 선택이었습니다.

Redis 외에도 존재하는 다양한 캐싱 대안

Redis 외에도 다양한 캐싱 시스템이 존재합니다. 그러나 각각의 특성과 목적이 다르기 때문에, 상황에 맞는 선택이 중요합니다.

대표적인 캐싱 대안들

• Memcached

  • Redis보다 더 단순하고 빠른 구조

  • 복잡한 자료구조가 필요 없는 단순 캐싱에 적합

• Ehcache

  • JVM 기반 애플리케이션에 자연스럽게 통합

  • 스프링 환경에서는 JCache로도 활용 가능

• Caffeine

  • Java 8 이상에서 활용 가능한 고성능 로컬 캐시

  • Redis처럼 네트워크 비용이 들지 않음

• Apache Ignite

  • 데이터 그리드 형식으로 분산 캐시 기능 제공

  • 대규모 시스템에 적합한 고가용성 구조

크린토피아의 경우, 실시간성을 요구하는 콘텐츠는 많지 않지만, 많은 트래픽을 처리할 수 있는 빠른 응답성과 단순한 구조가 필요했기에 Redis가 가장 적합했습니다.

캐싱 도입 전후의 변화: 속도 개선과 부하 감소

단순히 “캐싱을 적용했다”는 말로는 이 변화의 크기를 설명하기 어렵습니다. 실제 성능 변화는 수치로 확인할 수 있었습니다.

주요 개선 성과

• DB 쿼리 요청량 약 65% 감소

  • 자주 호출되는 콘텐츠(API 기준 약 8개)를 Redis 캐싱 처리

• 전체 API 응답 속도 35~45% 향상

  • 평균 250ms → 140ms 수준으로 개선

• 트래픽 피크 타임 시 DB CPU 사용량 40% 감소

• 앱 실행 후 초기 로딩 속도 체감 향상

  • 사용자 리뷰에서도 “빠릿해졌다”는 반응 확인

단기적으로는 속도 개선이 돋보였지만, 장기적으로는 DB에 집중된 부하를 분산시킴으로써 시스템 안정성도 크게 개선되었습니다.

어떤 콘텐츠를 캐싱 대상으로 선정했는가?

모든 API를 캐싱하는 것은 오히려 데이터 일관성과 자원 낭비를 초래할 수 있습니다. 따라서 다음 기준에 따라 캐싱 우선순위를 설정하였습니다.

[캐싱 대상 선정 기준]

• 조회 빈도가 높고 자주 변경되지 않는 콘텐츠

  • 예: 이벤트 배너, 앱 이용 가이드, 공지사항

• 로그인 여부와 무관한 공개 API

  • 사용자별 데이터는 세션이나 토큰 처리 필요

• 데이터 변경 주기가 명확한 콘텐츠

  • 주기적으로 TTL을 갱신 가능하도록 구성

이를 통해 시스템 자원을 효율적으로 분배할 수 있었고, 불필요한 캐싱 오버헤드도 줄일 수 있었습니다.

유지보수와 운영의 편의성도 함께 고려

캐싱 시스템은 단순히 도입하는 것보다 유지·운영이 얼마나 쉬운가도 중요합니다. Redis는 다음과 같은 장점을 제공하며 운영 효율성을 높였습니다.

• CLI를 통한 실시간 모니터링 가능

• TTL 관리로 자동 만료 처리

• 특정 키만 삭제하거나 갱신 가능하여 정교한 캐시 관리

• Spring Data Redis와 연동되어 운영환경 이식성 확보

이러한 기능 덕분에 개발팀은 애플리케이션 코드 수정 없이도 캐시 정책을 유연하게 변경할 수 있었습니다.

프론트-엔드와 백-엔드의 캐싱 처리 프로세스

프론트엔드에서는 React Query를 활용하여 데이터를 효율적으로 관리하고 있으며, 모바일 기기의 메모리를 이용해 1차 캐싱을 처리하도록 설계했습니다. 이를 통해 캐싱 서버에 과도한 부하를 주지 않으면서도 안정적인 운영이 가능하도록 구현했습니다

기술은 문제 해결의 도구일 뿐

이번 캐싱 도입 프로젝트는 단순한 성능 개선 이상의 가치를 만들어냈습니다. 기술을 도입한 목적은 명확했습니다. 바로 사용자 경험을 해치지 않으면서 시스템의 효율을 극대화하는 것입니다. 특정 기술을 맹신하거나 무조건 최신 트렌드를 따르기보다는, 우리의 인프라, 요구사항, 운영 여건에 가장 적합한 해법을 선택하는 것이 핵심이었습니다.