워드프레스 CSS 수정이 화면에 안 보일 때 캐시 확인법

세 줄 요약
증상: 스타일이나 테마 설정을 바꿨는데 HTML 에서 찾으면 없고 화면도 그대로이며, 캐시를 피하려고 붙인 주소는 502 를 냅니다.
원인: LiteSpeed 가 CSS 를 따로 합친 파일에 두고, GeneratePress 는 만든 CSS 를 옵션에 저장해 두며, 쿼리를 붙인 주소는 방문자와 다른 응답을 받습니다.
해결: 합친 CSS 파일을 직접 열어 보고, 테마 CSS 옵션과 LiteSpeed 캐시를 지운 뒤, 쿼리 없는 주소로 다시 잽니다.

워드프레스 화면을 고친 뒤 "안 바뀌었다"고 느끼는 경우는 대개 셋 중 하나입니다. 실제로 안 바뀌었거나, 바뀌었는데 내가 엉뚱한 곳을 보고 있거나, 캐시가 아닌 다른 원인이 있는 경우입니다. 하루에 이 세 가지를 모두 겪었습니다.

고쳤는데 없다, 깨졌다, 하나만 남았다

스타일을 넣은 뒤 페이지 HTML 에서 그 색상 값을 찾으니 0회였습니다.
GeneratePress 에서 본문 폭(container_width)을 바꿨는데 화면은 옛 폭 그대로였습니다.
캐시를 피하려고 ?cb=난수 를 붙여 열었더니 502 가 나서 사이트가 깨진 줄 알았습니다.
쿼리를 붙여 받은 페이지에는 CSS 가 통째로 빠져 있었습니다.
스타일 미리보기에서 여러 인라인 스타일 중 첫 번째만 살아남았습니다.

반대로 "캐시 탓"이라고 단정했는데 실제로는 문단 구조가 원인이었던 적도 있습니다. 그래서 순서대로 구분하는 것이 중요합니다.

원인은 증상마다 달랐다

증상	원인
HTML 에 넣은 스타일이 없음	LiteSpeed 가 CSS 를 `wp-content/litespeed/css/*.css` 로 합쳐 둠
테마 폭을 바꿔도 그대로	GeneratePress 가 만든 CSS 를 옵션에 통째로 저장해 둠
`?cb=` 주소만 502	Rank Math 리다이렉션 표가 없어 PHP 오류가 nginx 응답 머리말 한도를 넘김(`upstream sent too big header`)
쿼리 붙인 주소에 CSS 없음	LiteSpeed 가 쿼리가 붙으면 CSS 빠진 응답을 줌
인라인 스타일이 하나만 남음	LiteSpeed CSS Combine 이 동적 인라인 스타일을 합치며 하나만 남김

502 가 난 주소도 파라미터 없이 열면 200 이었고, 캐시를 모두 비운 뒤에도 200 이었습니다. 방문자에게는 영향이 없었다는 뜻입니다.

보는 곳을 바로잡고 캐시를 지운다

1. 합친 CSS 파일을 직접 열어 보기

curl -s https://example.com/ | grep -o 'wp-content/litespeed/css/[^"]*\.css' | head -n 3
curl -s https://example.com/wp-content/litespeed/css/파일이름.css | grep -c '#1a73e8'

HTML 이 아니라 합쳐진 CSS 파일 안에서 넣은 값을 찾아야 정확합니다.

2. GeneratePress 동적 CSS 다시 만들게 하기

wp option delete generate_dynamic_css_output
wp option delete generate_dynamic_css_cached_version

3. LiteSpeed 캐시 비우기

rm -rf wp-content/litespeed/*
wp cache flush
wp eval "opcache_reset();"

기록한 서버에서는 wp litespeed-purge all 이 400 오류를 내서 위 세 줄로 비웠습니다. wp cache flush 하나만으로는 부족했습니다.

4. 미리보기 동안 CSS 합치기 끄기

동적 인라인 스타일이 하나만 남는 문제는 LiteSpeed 의 CSS 합치기 설정(optm-css_comb)을 미리보기 동안만 0 으로 꺼 두고, 끝나면 다시 1 로 켜는 방법으로 피했습니다.

확인 방법

판정은 방문자와 같은 조건, 곧 파라미터 없는 주소로 캐시를 비운 뒤에 다시 잽니다. 캐시 우회용 주소가 낸 오류를 사이트 고장으로 읽지 않습니다.

curl -s -o /dev/null -w "%{http_code}\n" https://example.com/sample-post/
curl -s https://example.com/sample-post/ | grep -c '<br'

캐시라고 단정하기 전에 쿼리 없는 주소의 서버 렌더를 직접 셉니다. 문단 수나 줄바꿈 수가 고친 대로라면 서버는 이미 바뀐 것이고, 남은 것은 브라우저 캐시(Ctrl+Shift+R)일 수 있습니다.

캐시라고 단정하기 전에

한 번은 고친 글이 화면에서 여전히 문장마다 줄이 끊겨 보여서 캐시 탓이라고 단정했습니다. 그런데 쿼리 없는 주소의 서버 응답을 직접 세어 보니 진짜 원인은 문단이 너무 잘게 나뉜 본문 구조였습니다. 캐시를 아무리 비워도 고쳐질 문제가 아니었습니다.

그 뒤로는 순서를 정해 두었습니다. 먼저 서버가 실제로 내보내는 HTML 과 CSS 파일에서 바꾼 값을 셉니다. 값이 있으면 캐시를 의심하고, 값이 없으면 고친 곳이 맞는지부터 다시 봅니다.

확인한 환경

항목	내용
웹 서버	nginx, PHP
플러그인	LiteSpeed Cache, Redis 객체 캐시, Rank Math
테마	GeneratePress
도구	wp-cli, curl

이 글의 내용은 2026년 10월 5일에 마지막으로 확인했습니다. 틀린 곳을 발견하시면 연락처로 알려 주세요.