워드프레스 모바일 이미지가 안 보일 때 | Aside 고급 활용 9

이미지 로딩 성공은 화면에 제대로 보인다는 뜻이 아닙니다.

워드프레스 사이트에서 모바일 표지가 보이지 않는다는 제보가 왔다. 첫 점검에서는 문제가 재현되지 않는다는 답이 돌아왔다. 이미지 파일은 열렸고, 브라우저도 로딩이 끝났다고 표시했다. 하지만 운영자가 보낸 화면에는 책 제목만 있고 표지 자리는 비어 있었다.

2026년 10월 19일 보이드로그에서 실제로 겪은 일이다. 고급 활용 8편이 예고한 실험편으로, 이번에는 Aside와 사이트 오류를 점검한 과정을 정리한다. 핵심은 특정 코드를 복사하는 일이 아니다. AI가 무엇을 확인했는지 되묻고, 방문자가 보는 화면을 완료 기준으로 삼는 방법이다.

9.1 왜 정상이라는 답을 그대로 믿으면 안 될까?

AI가 확인한 항목과 사용자가 겪은 문제가 다를 수 있기 때문이다.

첫 점검은 홈 상단의 표지와 이미지 파일의 로딩 상태를 중심으로 이뤄졌다. 실제 문제는 그 아래 ‘새로 나온 책’ 카드에 있었다. 같은 책의 표지를 쓰더라도 상단과 카드의 배치 방식은 다르다. 상단 표지가 보인다는 사실로 카드 표지까지 정상이라고 판단할 수는 없었다. 문제 화면을 받은 뒤 해당 영역을 따로 살폈고, 390px 폭으로 재현한 화면에서도 로딩 완료 상태와 빈 표지 칸이 함께 관찰됐다.

브라우저에는 complete라는 이미지 상태값이 있다. 그러나 이것만으로 성공을 판정하면 안 된다. MDN 문서에 따르면 이미지가 깨졌거나 주소가 비어 있는 경우에도 참일 수 있다. 이미지의 고유 너비를 나타내는 naturalWidth까지 확인하면 단순한 파일 실패를 구분하는 데 도움이 되지만, 그것도 최종 화면이 가려지지 않았다는 증거는 아니다. 수치가 알려 주는 범위와 사람이 눈으로 확인해야 하는 범위를 나눠야 한다.

9.2 모바일 이미지가 비면 무엇부터 확인할까?

수정부터 하지 말고, 화면과 주소를 받아 문제의 위치를 고정한다.

‘모바일에서 안 보인다’는 말만으로는 상단 표지인지, 목록의 다섯 번째 이미지인지, 본문 도판인지 알 수 없다. 전체 화면 캡처와 문제가 난 페이지 주소를 먼저 모으고, 사용한 브라우저와 기기, 스크롤 위치도 함께 적는다. 다른 사람에게 전달할 때는 상태 표시줄의 알림이나 계정 이름처럼 불필요한 정보는 가린다. 이번에도 사용자가 보낸 캡처가 첫 점검의 잘못된 범위를 바로잡았다.

그다음은 세 층으로 나눈다. 첫째는 파일이다. 이미지 주소가 정상 응답하는지, 원본만 열리고 작은 썸네일은 실패하는지, 브라우저가 실제로 선택한 주소는 무엇인지 본다. 둘째는 배치다. 이미지의 가로·세로 크기와 숨김 처리, 부모 상자 밖으로 밀리는지 확인한다. 셋째는 최종 화면이다. 해당 위치까지 스크롤한 뒤 실제로 보이는지 캡처로 판정한다. 파일이 잘 열리는데 화면만 비면 두 번째와 세 번째 층을 더 살펴야 한다.

9.3 이번 사이트에서는 무엇이 문제였나?

자동 크기 계산과 카드 배치 규칙이 맞물린 호환성 현상이 관찰됐다.

워드프레스는 지연 로딩 이미지에 sizes="auto, …"를 추가할 수 있다. 공식 설명에 따르면 이는 실제 표시 크기를 바탕으로 적절한 이미지 파일을 선택하기 위한 기능이다. 자동 크기 자체가 나쁜 기능인 것은 아니다. 이번 환경에서는 이 값이 있는 이미지에 크기 계산을 분리하는 브라우저 규칙이 적용됐고, 자동 너비·자동 높이를 쓰는 카드 안에서 이미지 상자가 표지 비율보다 넓게 계산되는 상태가 확인됐다.

점검 화면에서 선행 auto, 값을 제거하자 표지가 표시됐고, 표지를 담는 상자의 폭과 정렬도 명시해 배치를 안정시켰다. 다만 같은 수정 전 HTML을 다시 그렸을 때 표지가 보이는 경우도 있었다. 그러므로 모든 모바일 기기에서 발생하는 워드프레스 버그라고 단정하지 않는다. 이 글의 결론은 보이드로그의 해당 배치와 점검 환경에서 확인한 호환성 문제 및 그 대응까지다.

수정 전: sizes="auto, (max-width: 200px) 100vw, 200px"
수정 후: sizes="(max-width: 200px) 100vw, 200px"

9.4 작게 고친다는 것은 어디까지일까?

문제가 난 이미지 종류만 다루고, 원래 잘 되던 동작은 남긴다.

이번에는 모든 이미지의 지연 로딩을 끄지 않았다. 공개 도서의 대표 이미지를 출력하는 경로에서 자동 크기 값만 정리했고, 홈 카드의 표지 상자에 폭 방어를 더했다. 이미지 주소와 반응형 후보 목록, 대체 텍스트, 지연 로딩은 유지했다. 본문 도판과 일반 글의 대표 이미지는 이 표지 처리의 대상에 넣지 않았다. 원고·가격·ISBN·서점 링크도 바꾸지 않았다. 수정 전에 운영 파일을 백업해 되돌릴 길부터 확보했다.

도서 목록·상세·분야·저자·검색 등 다른 화면도 살폈다. 같은 자동 크기 설정이 있더라도 모두 빈칸이 된 것은 아니었다. 어떤 곳은 고정된 표지 칸이 있었고, 어떤 곳은 이미지의 높이가 명시돼 있었다. 비슷한 코드를 발견했다는 이유만으로 같은 고장이라고 부르지 않고, 실제 영향과 예방적 호환성 처리를 구분했다.

9.5 고쳤는데도 예전 화면이 보이는 이유는?

수정된 서버와 방문자가 받는 캐시가 서로 다를 수 있다.

코드를 올린 뒤에도 끝이 아니었다. 워드프레스 쪽 LiteSpeed 캐시를 비웠지만, 로그인하지 않은 공개 주소는 여전히 이전 버전의 내용을 반환했다. 별도의 Hostinger CDN 캐시가 남아 있었기 때문이다. CDN은 방문자에게 가까운 곳에서 내용을 전달하는 별도 계층이다. 그 캐시까지 삭제한 뒤에야 공개 HTML에서도 수정된 버전과 이미지 설정이 확인됐다.

이 경험을 ‘캐시는 무조건 두 군데 지운다’는 규칙으로 바꾸지는 않는다. 먼저 로그인하지 않은 공개 주소가 실제로 무엇을 주는지 확인한다. 새 내용이 이미 나왔다면 같은 작업을 반복할 이유가 없다. 반대로 옛 내용이 남아 있다면 어느 계층이 돌려주는지 구분한다. 관리 화면의 성공 안내보다 방문자가 받는 응답이 마지막 근거다.

9.6 어디까지 확인해야 완료라고 할까?

원래 문제가 난 화면과 주변 화면을 다시 보고, 확인하지 않은 범위도 남긴다.

반응형 화면 36개 조건

홈·목록·분야·저자·상세·공개 장·검색 등 9종 화면을 320·390·768·1440px로 확인했다. 주요 표지는 화면별 최대 6개까지 스크롤해 로딩과 크기를 검사했고, 가로 넘침은 없었다.

공개 응답과 내용 보존

공개 도서 57권의 응답과 대표 이미지 마크업을 확인했다. 점검한 화면과 도서의 제목·대표 주소·구조화 데이터·본문 링크는 수정 전후 차이가 없었다. 이는 57권의 모든 이미지 픽셀을 전수 육안 검사했다는 뜻은 아니다.

실제 휴대폰 검사는 별도

브라우저 안에서 화면 폭을 재현한 검사와 실제 iOS·Android 기기 검사는 다르다. 운영 반영 후 실제 휴대폰에서 다시 보이는지는 운영자에게 새로고침해 확인하도록 요청했다. 이 글 작성 시점에는 그 회신을 아직 받지 않았다.

완료 보고에 검사 수만 적으면 숫자가 보증처럼 읽히기 쉽다. 무엇을 몇 개 봤는지, 파일만 확인했는지 실제 화면도 봤는지, 아직 남은 확인은 무엇인지 함께 적어야 한다. 이번 작업에서는 AI의 첫 판단을 사용자 캡처가 바로잡았고, 그 뒤에도 로딩 수치와 시각 결과를 분리해 확인했다. 사람이 오류 화면을 보냈다는 사실이 자동 점검의 실패가 아니라, 점검 범위를 바로잡는 중요한 입력이 됐다.

9.7 Aside에 맡길 때는 어떻게 요청하면 좋을까?

아래는 이번 경험을 정리해 만든 재사용용 요청 예시다. 당시 대화를 그대로 옮긴 인용문은 아니다. 첫 단계에서는 점검과 수정 제안을 받고, 실제 반영은 범위를 확인한 뒤 별도로 승인하는 방식이다.

모바일에서 이 페이지의 이미지가 보이지 않습니다.
첨부한 화면과 같은 위치를 먼저 확인해 주세요.

페이지 주소:
사용한 기기와 브라우저:
안 보이는 위치와 스크롤 상태:

1. 지금은 읽기 전용으로 점검해 주세요.
2. 이미지 파일 응답, 실제 선택된 주소, 화면 크기와 숨김 상태를 구분해 주세요.
3. 로딩 완료 수치만으로 정상이라고 하지 말고 해당 위치의 화면도 확인해 주세요.
4. 재현되지 않으면 정상이라고 단정하지 말고, 필요한 추가 정보를 알려 주세요.
5. 최소 수정 범위와 되돌릴 방법을 제시해 주세요.
6. 수정 승인을 받으면 관련 목록·상세·검색과 여러 화면 폭을 다시 검사해 주세요.
7. 로그인하지 않은 공개 화면과 캐시도 확인해 주세요.
8. 실제 기기에서 확인한 것과 화면 폭만 재현한 검사를 나눠 보고해 주세요.

AI에게 맡길수록 사람의 역할이 없어지는 것이 아니라 더 선명해진다. 사람은 어디가 잘못 보이는지와 무엇을 지켜야 하는지 알려 주고, AI는 재현·비교·반복 검사를 맡는다. 둘 사이의 기준은 ‘코드가 바뀌었다’가 아니라 방문자가 보아야 할 것이 실제로 보인다는 결과다.

이 글의 확인 범위와 참고 자료

• 사례 기준일은 2026년 10월 19일이다. 보이드로그의 당시 운영 환경에서 확인한 결과이며, 다른 테마·플러그인·브라우저의 원인까지 보증하지 않는다.
• 그림 9-1은 점검 중 저장한 브라우저 재현 화면을 편집한 비교 이미지다. 관리자 화면이나 개인 계정 정보는 포함하지 않았다. 그림 9-2는 설명용 도식이다.
• 실제 휴대폰 재확인과 별도 성능 점수 재측정은 이 글의 완료 검증에 포함하지 않았다.

• 워드프레스 공식: 지연 로딩 이미지의 자동 크기 도입 설명
• 워드프레스 공식: 자동 sizes 추가 함수
• MDN: 이미지 complete 속성이 뜻하는 범위
• MDN: 이미지 naturalWidth 속성

보이드로그의 실제 운영 점검 기록을 바탕으로 AI의 도움을 받아 작성·편집했다. 사실 기록, 설명용 도식, 재사용용 요청 예시를 구분했다.