얼마 전, 한 고객으로부터 사이트 수정 후 변경 사항이 반영되지 않는다는 요청을 받았습니다. FTP를 통해 서버에 접속해 확인해 보니, 수정한 파일이 정상적으로 반영되어 있었고 코드에도 문제가 없었습니다. 하지만 브라우저에서 확인해 보면 여전히 이전 버전의 화면이 표시되었습니다.

이런 경우 브라우저 캐시나 쿠키 문제일 가능성이 높다고 판단해, 고객에게 캐시를 지우고 새로고침해볼 것을 안내했습니다. 하지만 고객이 동일한 문제를 계속 겪고 있다고 하여 다시 점검하게 되었습니다.

문제의 원인: www 유무에 따른 차이

한참을 고민하다가, 고객이 접속하는 URL과 제가 접속하는 URL이 다르다는 사실을 발견했습니다. 고객은 www.example.com을 통해 사이트를 보고 있었고, 저는 example.com으로 직접 접속해 변경 사항을 확인하고 있었습니다.

일반적으로 www.example.com과 example.com은 같은 사이트처럼 보이지만, 실제로는 서버 설정 및 캐싱 방식에 따라 다르게 동작할 수 있습니다. 특히, 다음과 같은 이유로 www가 포함된 주소와 포함되지 않은 주소가 서로 다른 캐시 정책을 가질 가능성이 있습니다.

1. 서버 설정 차이
   • 일부 서버에서는 www.example.com과 example.com을 별도의 호스트로 취급합니다.
   • 따라서 각각의 주소에 대해 별도의 캐싱 규칙이 적용될 수 있습니다.
2. 쿠키 적용 범위 차이
   • www.example.com에서 설정된 쿠키는 기본적으로 example.com에서 공유되지 않습니다.
   • 반대로 example.com에서 설정된 쿠키는 www.example.com에서도 사용할 수 있도록 설정할 수 있지만, 반드시 그렇게 설정된다는 보장은 없습니다.
3. CDN 및 프록시 캐시
   • www.example.com과 example.com이 동일한 서버로 연결되더라도, CDN이나 프록시 서버에서 각각 별도의 캐시 정책을 적용할 수 있습니다.
   • 예를 들어, www.example.com은 장기 캐시가 설정되어 있고, example.com은 상대적으로 짧은 캐시가 설정될 수 있습니다.
4. 일반적인 사용자 습관
   • 많은 사용자들은 브라우저에서 “www”를 생략하고 사이트에 접속하는 경우가 많습니다.
   • 이를 감안하여 www.example.com보다 example.com의 캐시 기간을 짧게 설정해 더 자주 변경 사항이 반영되도록 하는 경우가 있습니다.

결론

이번 경험을 통해 같은 사이트라고 하더라도 “www” 유무에 따라 캐시와 쿠키 정책이 다르게 적용될 수 있다는 사실을 깨달았습니다. 서버 설정, 쿠키 정책, CDN 캐싱 등이 복합적으로 영향을 미치기 때문에, 사이트 수정 후 변경 사항이 반영되지 않는다면 반드시 고객이 접속하는 URL과 본인이 확인하는 URL이 일치하는지 먼저 확인해야 합니다.

앞으로는 이런 문제가 발생하지 않도록, www.example.com과 example.com을 통합하는 방식으로 리디렉션을 설정하고, 캐시 정책을 명확하게 관리하는 것이 중요하다는 점을 배우게 되었습니다.