배포를 했는데 왜 어떤 사람만 문제가 생길까

서비스를 운영하다 보면
같은 서비스에 접속했는데

어떤 사용자는 정상적으로 화면이 보이고
어떤 사용자는 오류가 발생하는 상황을 마주하게 된다.

처음에는 서버 문제라고 생각한다.
혹은 배포가 제대로 되지 않았다고 의심하기도 한다.

하지만 운영을 하다 보면
이 질문의 원인이 의외로 단순한 곳에 있는 경우가 많다.

캐시(Cache) 다.

내가 처음 겪은 캐시 문제

한 번은 UI 수정이 포함된 배포를 진행한 적이 있었다.

큰 기능 변경도 아니었고
단순한 화면 디자인 수정이었다.

배포도 정상적으로 완료되었다.

그런데 얼마 지나지 않아 문의가 들어오기 시작했다.

어떤 사용자는 정상적으로 화면이 보이는데
어떤 사용자는 화면이 깨져 보인다는 것이었다.

처음에는 배포가 일부 서버에만 반영된 것이 아닐까 의심했다.

하지만 서버 로그와 배포 상태를 확인해 보니
모든 서버에는 정상적으로 반영되어 있었다.

그때 개발팀에서 한 마디를 했다.

“브라우저 캐시 때문일 가능성이 있습니다.”

확인해 보니 문제는 CSS 파일 캐시였다.

사용자의 브라우저에는 이전 CSS 파일이 남아 있었고
HTML 문서는 새 버전을 불러오고 있었다.

이 경우 브라우저는 이전에 캐시해 둔 CSS 파일을 그대로 사용할 수 있다.

그 결과 일부 사용자 화면에서는
레이아웃이 깨지거나 디자인이 정상적으로 보이지 않았다.

결국 이 문제는 강력 새로고침(Hard Refresh) 을 하면 해결되었다.

브라우저에 저장되어 있던 캐시가 무효화되면서
새 CSS 파일을 다시 받아오기 때문이다.

이때 처음 알게 되었다.

같은 서비스에 접속하더라도
사용자마다 서로 다른 캐시 상태를 가지고 있을 수 있다는 것을.

캐시는 생각보다 많은 곳에 있다

처음에는 캐시라고 하면
브라우저에 저장된 CSS나 이미지 정도만 떠올렸다.

하지만 운영을 하다 보니
캐시는 생각보다 훨씬 많은 곳에 존재한다는 것을 알게 된다.

브라우저 캐시만 있는 것이 아니다.

CDN 캐시가 있을 수도 있고
프록시 서버가 캐시를 가지고 있을 수도 있으며
앱의 웹뷰(WebView)가 자체 캐시를 가지고 있을 수도 있다.

웹에서 사용하는 캐시는 기본적으로
사용자의 요청 속도를 높이고 서버 부하를 줄이기 위해 사용된다.

MDN Web Docs에서는 캐시를 다음과 같이 설명한다.

웹 캐시는 이전에 요청된 리소스를 저장해 두었다가
동일한 요청이 다시 발생했을 때 서버에 다시 요청하지 않고
저장된 데이터를 반환하는 기술이다.

이 구조 덕분에 웹 서비스는 더 빠르게 동작한다.

하지만 동시에 이런 문제가 발생할 수 있다.

사용자마다 다른 시점의 데이터를 캐시하고 있을 수 있다는 점이다.

그래서 같은 서비스를 보고 있어도
서로 다른 화면을 보게 된다.

최근에 겪은 또 다른 캐시 문제

최근에도 비슷한 일이 있었다.

이번에는 이전과는 조금 달랐다.

화면이 깨지는 것이 아니라
데이터가 정상적으로 보이지 않는 문제였다.

즉 디자인 문제가 아니라 데이터 표시 문제였다.

혹시 몰라 브라우저에서 강력 새로고침을 시도했다.

하지만 결과는 같았다.
데이터는 여전히 나타나지 않았다.

처음에는 데이터 자체의 문제라고 생각했다.

개발팀을 통해 DB 상태를 확인했다.
혹시 DB 연결이 정상적으로 안되는 것은 아닌지,

데이터가 누락되었거나
잘못 저장된 것은 아닌지 확인했다.

하지만 DB에는 특별한 문제가 없었다.
DB 연결상태도 데이터도 정상적으로 존재하고 있었다.

원인을 찾기 위해 조금 더 확인해 보니
문제는 다른 곳에 있었다.

캐시 문제였다.

서비스에서는 성능을 위해
정적 파일이나 일부 응답 데이터를 캐시에 저장해 사용하고 있었다.

배포 이후
브라우저나 CDN에 남아 있던 이전 캐시와
새로운 버전의 리소스가 함께 사용되면서 문제가 발생했다.

어떤 사용자는 새 파일을 받았고
어떤 사용자는 이전 캐시를 그대로 사용했다.

그 결과 같은 서비스인데도
사용자마다 다른 결과가 나타났다.

어떤 사용자에게는 데이터가 정상적으로 보였고
어떤 사용자에게는 데이터가 전혀 보이지 않았다.

캐시를 이해해야 하는 이유

캐시는 서비스 성능을 높이기 위해
웹 시스템에서 널리 사용되는 기술이다.

하지만 배포 시점에는

예상하기 어려운 문제를 만들기도 한다.

그래서 운영을 하다 보면
배포는 끝났는데 특정 사용자만 문제가 발생하는 상황을
생각보다 자주 마주하게 된다.

그리고 그 원인이
캐시에서 시작되는 경우도 적지 않다

.

이러한 문제를 해결하기 위해

정적 파일의 버전을 파일 이름으로 관리하거나

CDN 캐시를 무효화하거나

서버 캐시를 초기화하는 방법 등을 사용한다.

하지만 그보다 먼저 필요한 것은

캐시가 어디에 존재하는지 이해하는 것이다.

배포는 코드만 올리는 일이 아니다

처음에는 배포를 단순히 이렇게 생각했다.

코드를 서버에 올리는 작업.

하지만 운영을 하다 보면
배포는 단순히 코드만 올리는 일이 아니라는 것을 알게 된다.

어떤 사용자는 새 화면을 보고
어떤 사용자는 이전 화면을 보고 있을 수도 있다.

그래서 배포 이후 서비스가 정상적으로 보이지 않는다라는 질문을 받게되면

“강력 새로고침 해보셨나요?”

혹은

“브라우저 캐시를 지우면 정상적으로 보이나요?”

라는 질문을 하게 된다.

처음에는 이 질문의 의미를 제대로 이해하지 못한 채 고객사에 안내하곤 했다.

하지만 운영을 하다 보니 알게 된다.

서비스는 코드만으로 동작하는 것이 아니라
여러 곳에 남아 있는 캐시 상태 위에서 함께 움직이고 있다는 것을.