웹사이트 속도를 높이고 싶다면? “localStorage와 JVM 캐시” 제대로 이해하기

들어가며

웹 애플리케이션을 개발하다 보면 비슷한 데이터를 여러 번 가져오는 상황을 자주 만나게 됩니다.

예를 들어 서버에서 API를 호출해 경기 목록이나 상품 정보, 공통 코드 같은 데이터를 가져왔다고 해보겠습니다. 사용자가 페이지를 이동할 때마다 똑같은 데이터를 다시 조회한다면 네트워크 요청도 늘어나고 서버에도 불필요한 부하가 생길 수 있습니다.

이럴 때 흔히 사용하는 방법이 바로 캐시(Cache)입니다.

그런데 캐시를 어디에 저장할 것인지가 또 하나의 고민이 됩니다.

브라우저에 저장할 수도 있고, 서버 메모리에 저장할 수도 있습니다. 브라우저에서는 대표적으로 localStorage를 사용할 수 있고, Java 서버 환경에서는 JVM 메모리를 활용해 데이터를 캐싱하는 방법을 생각해볼 수 있습니다.

겉으로 보면 둘 다 “데이터를 잠시 저장해두고 다시 사용하는 것”처럼 보입니다. 하지만 실제로는 저장되는 위치와 공유 범위, 데이터의 생명주기가 상당히 다릅니다.

localStorage 공유캐시는 무엇일까?

localStorage는 사용자의 웹 브라우저 내부에 데이터를 저장하는 공간입니다.

JavaScript를 이용하면 간단하게 데이터를 저장하고 가져올 수 있습니다.

localStorage.setItem(
    "gameData",
    JSON.stringify(data)
);

const gameData = JSON.parse(
    localStorage.getItem("gameData")
);

한 번 서버에서 데이터를 받아 localStorage에 저장해두면 이후 같은 브라우저에서 다시 사용할 수 있습니다.

예를 들어 첫 번째 페이지에서 경기 데이터를 가져왔다고 가정해보겠습니다.

서버에서 데이터를 받은 뒤 localStorage에 저장합니다. 사용자가 두 번째 페이지로 이동하면 두 번째 페이지에서는 서버에 다시 요청하지 않고 브라우저에 저장된 데이터를 가져올 수 있습니다.

이런 방식이 앞에서 이야기했던 localStorage 공유캐시입니다.

물론 여기서 “공유”라는 표현에는 조건이 있습니다.

모든 사용자가 하나의 데이터를 공유한다는 의미가 아닙니다. 기본적으로 같은 출처(origin)의 페이지에서 해당 브라우저가 가지고 있는 저장 데이터를 함께 사용하는 개념입니다.

즉, 사용자 A의 브라우저에 저장된 localStorage 데이터를 사용자 B가 사용하는 것은 아닙니다.

서버 메모리(JVM)는 어떻게 다를까?

Java 기반의 웹 애플리케이션이라면 서버 프로그램은 JVM 위에서 실행됩니다.

이 JVM이 사용하는 메모리에 데이터를 보관해두고 여러 요청에서 재사용하는 방식도 가능합니다.

간단한 예를 들어보면 서버에서 외부 API를 호출한 뒤 결과를 메모리에 저장해둘 수 있습니다.

그다음 다른 사용자가 같은 데이터를 요청하면 외부 API를 다시 호출하지 않고 서버 메모리에 저장된 데이터를 반환하는 방식입니다.

개념적으로 보면 다음과 같은 흐름입니다.

외부 API → 서버(JVM) → 메모리 저장 → 여러 요청에서 재사용

이 구조를 이용하면 여러 사용자가 동일한 데이터를 필요로 하는 서비스에서 특히 효과를 볼 수 있습니다.

예를 들어 오늘의 환율, 경기 일정, 공통 코드, 자주 변경되지 않는 상품 정보처럼 많은 사용자가 동일하게 사용하는 데이터라면 서버에서 한 번 가져온 뒤 일정 시간 동안 메모리에 보관하는 방법을 고려할 수 있습니다.

localStorage와 JVM 메모리의 가장 큰 차이

두 방식의 가장 큰 차이는 데이터가 어디에 존재하느냐입니다.

localStorage는 사용자의 브라우저에 있습니다.

반면 JVM 메모리는 서버에서 실행되는 애플리케이션의 메모리에 있습니다.

이 차이는 생각보다 중요합니다.

사용자 100명이 웹사이트에 접속했다고 가정해보겠습니다.

localStorage를 사용하면 100명의 브라우저가 각각 자신만의 저장 데이터를 가지고 있습니다.

반면 서버 JVM 메모리에 캐시를 저장하면 서버에 있는 하나의 캐시 데이터를 여러 사용자의 요청에서 재사용할 수 있습니다.

따라서 모든 사용자가 동일한 데이터를 사용하는 경우에는 서버 캐시가 상당히 효율적일 수 있습니다.

반대로 사용자별 설정이나 개인화된 데이터를 브라우저에서 관리해야 한다면 localStorage가 더 적합할 수 있습니다.

서버 요청을 줄인다는 점은 비슷하다

흥미로운 부분은 두 방식 모두 결과적으로 서버나 외부 시스템에 대한 불필요한 요청을 줄이는 데 사용할 수 있다는 것입니다.

예를 들어 매번 외부 API를 호출하는 구조라면 다음과 같은 문제가 발생할 수 있습니다.

사용자 요청 → 서버 → 외부 API → 응답

이 과정이 사용자 요청마다 반복됩니다.

하지만 캐시를 적용하면 다음과 같이 바뀔 수 있습니다.

사용자 요청 → 캐시 확인 → 데이터 반환

캐시에 데이터가 없다면 외부 API에서 가져오고, 가져온 데이터를 캐시에 저장합니다.

그 이후 일정 시간 동안은 캐시 데이터를 사용하는 것입니다.

이 방식은 외부 API 호출 횟수를 줄이고 응답 속도를 개선하는 데 도움이 될 수 있습니다.

그렇다면 localStorage와 JVM 메모리 중 무엇을 선택해야 할까?

여기서 무조건 어느 한쪽이 더 좋다고 생각하면 안 됩니다.

어떤 데이터를 누구에게 제공해야 하는지를 먼저 생각하는 것이 좋습니다.

사용자 개인의 설정이나 브라우저에서만 필요한 데이터라면 localStorage가 편리합니다.

예를 들어 사용자가 선택한 화면 모드, 마지막으로 선택한 메뉴, 간단한 검색 조건 등을 저장하는 데 활용할 수 있습니다.

반면 여러 사용자가 공통으로 사용하는 데이터라면 서버 메모리 캐시가 더 적합할 수 있습니다.

예를 들어 모든 사용자에게 동일하게 제공되는 경기 일정이나 공통 코드, 외부 API에서 가져오는 공개 데이터 등이 여기에 해당합니다.

캐시 만료 시간도 중요하다

캐시를 사용하면서 가장 흔하게 발생하는 문제가 바로 오래된 데이터입니다.

서버에서 새로운 데이터가 만들어졌는데 캐시에 이전 데이터가 남아 있다면 사용자는 최신 정보가 아닌 오래된 정보를 보게 됩니다.

그래서 localStorage든 JVM 메모리든 캐시를 사용할 때는 만료 정책을 함께 고민해야 합니다.

예를 들어 10분 동안만 데이터를 사용하고 10분이 지나면 다시 가져오도록 만들 수 있습니다.

localStorage에서는 저장 시간인 savedAt 등을 함께 저장할 수 있습니다.

서버에서는 캐시 데이터와 함께 생성 시간을 기록해두고 일정 시간이 지나면 다시 조회하도록 구현할 수 있습니다.

결국 캐시의 핵심은 단순히 “데이터를 저장한다”가 아닙니다.

언제 저장하고, 얼마나 오래 사용하며, 언제 새로운 데이터로 교체할 것인가가 훨씬 중요합니다.

JVM 메모리 캐시의 주의점

JVM 메모리를 사용하는 경우에는 서버 메모리 자체의 특성도 생각해야 합니다.

JVM이 종료되거나 애플리케이션이 재시작되면 메모리에 저장했던 데이터는 사라집니다.

즉, JVM 메모리는 데이터베이스처럼 영구적으로 데이터를 보관하는 공간이 아닙니다.

서버를 재시작한 뒤에도 반드시 유지되어야 하는 중요한 데이터라면 데이터베이스나 별도의 영속 저장소를 사용해야 합니다.

또한 서버가 여러 대로 구성된 환경에서는 이야기가 조금 더 복잡해집니다.

서버가 1대라면 JVM 메모리에 캐시를 저장하고 사용하는 것이 비교적 단순합니다.

하지만 서버가 3대, 5대처럼 여러 대로 늘어나면 각 서버의 JVM 메모리는 서로 다른 공간입니다.

A 서버의 JVM 메모리에 저장된 캐시를 B 서버가 그대로 사용할 수 있는 것은 아닙니다.

이런 환경에서는 Redis 같은 별도의 중앙 캐시 저장소를 사용하는 방법을 고려할 수 있습니다.

localStorage도 만능은 아니다

localStorage 역시 모든 데이터를 저장하기 위한 공간은 아닙니다.

브라우저에 저장되는 데이터이기 때문에 저장 용량에 제한이 있고, 문자열 형태로 데이터를 관리해야 합니다.

또한 보안이 중요한 데이터를 무조건 localStorage에 넣는 것도 좋은 방법은 아닙니다.

특히 비밀번호나 민감한 인증 정보 등을 단순히 브라우저 저장소에 보관하는 것은 신중하게 판단해야 합니다.

캐시는 편리함을 위해 사용하는 것이지 보안 저장소를 대신하기 위한 기능은 아니기 때문입니다.

마무리

localStorage 공유캐시와 서버 JVM 메모리 캐시는 모두 데이터를 재사용한다는 공통점이 있지만 실제 역할은 꽤 다릅니다.

간단하게 정리하면 localStorage는 사용자 브라우저에 데이터를 저장하고, JVM 메모리 캐시는 서버 애플리케이션의 메모리에 데이터를 저장합니다.

따라서 사용자별 데이터나 브라우저에서 간단하게 재사용할 데이터는 localStorage가 편리하고, 여러 사용자가 공통으로 사용하는 데이터를 서버에서 효율적으로 재사용하려면 JVM 메모리 캐시를 고려할 수 있습니다.

다만 데이터가 얼마나 자주 변경되는지, 사용자마다 데이터가 다른지, 서버가 여러 대인지, 캐시가 사라져도 괜찮은 데이터인지 등을 함께 판단해야 합니다.

결국 좋은 캐시는 단순히 “빠르게 만드는 것”에서 끝나지 않습니다.

데이터의 특성에 맞는 위치에 저장하고, 적절한 시간 동안 사용하고, 필요할 때 최신 데이터로 갱신하는 것이 핵심입니다.

처음 캐시를 적용한다면 너무 복잡하게 시작하기보다는 데이터의 흐름부터 그려보는 것을 추천합니다.

“이 데이터는 누가 사용하는가?”

“얼마나 자주 변경되는가?”

“여러 사용자가 같은 데이터를 사용하는가?”

“서버가 재시작되면 사라져도 되는가?”

이 네 가지 질문에 답해보면 localStorage를 사용할지, JVM 메모리를 사용할지, 아니면 별도의 캐시 서버가 필요한지 판단하기가 한결 쉬워집니다.