모바일에서 사이트 깨짐, 원인 4가지 구분법
화면 깨지는 결함 네 개를 따로 만들어 360px에서 재봤어요.
가로로 밀리는지만 봐도 후보가 절반으로 줄어요.
글씨가 16px에서 5.9px로 줄어든 경우가 있었는데, 그건 브라우저 창만 좁혀서는 안 잡혔습니다.
컴퓨터에서 멀쩡하던 페이지가 좁은 화면에서 글씨만 개미만 해지는 경우가 있어요. 그 상태를 하나 만들어 폭 360px에서 재보니 이렇게 나옵니다.
a-noviewport.html {"layout":980,"scroll":980,"hscroll":false,"scale":0.367,"pFontCss":16,"pFontReal":5.9,"headerCoversH1":null}
pFontCss는 CSS에 적힌 글씨 크기, pFontReal은 화면에 실제로 그려진 크기예요. 16px이라고 써 놨는데 5.9px로 나옵니다. 페이지 전체가 0.367배로 줄어든 거고요.
그런데 같은 파일을 브라우저 창만 360px로 좁혀서 열면 아무 문제가 없어 보입니다. 폭은 똑같이 360인데요.
확인 방법은 이렇습니다. 결함을 하나씩만 넣은 정적 HTML 4장을 만들고 Chromium을 360×720(배율 2배)으로 띄워 쟀어요. 2026년 8월 15일, macOS 26.5.2에 Playwright 1.60.0입니다. 실제 아이폰이나 안드로이드 기기가 아니라 데스크탑 브라우저의 모바일 에뮬레이션이에요. 잰 값은 레이아웃 폭, 내용 폭, 화면 축소 배율, 글씨의 실효 크기입니다. 아래 태그 없는 코드블록은 전부 그 측정에서 그대로 받은 출력이고요.
먼저 화면을 좌우로 밀어 보세요
코드를 열기 전에 폰에서 할 게 하나 있어요. 화면을 좌우로 밀어 봅니다.
가로로 밀리나요. 밀리면 내용이 화면보다 넓은 것이고, 안 밀리는데 글씨가 작으면 화면 전체가 줄어든 것이에요.
둘은 원인도 고치는 자리도 완전히 다릅니다. 제가 만든 넷을 나란히 재보면 이렇게 갈려요.
| 결함 | 레이아웃 폭 | 내용 폭 | 가로 스크롤 | 축소 배율 | 16px의 실효 크기 |
|---|---|---|---|---|---|
| viewport 메타 없음 | 980 | 980 | 없음 | 0.367 | 5.9px |
| 폭을 픽셀로 못 박음 | 360 | 1148 | 있음 | 1 | 16px |
| 표가 화면보다 넓음 | 360 | 649 | 있음 | 1 | 16px |
| 헤더가 본문을 덮음 | 360 | 360 | 없음 | 1 | 16px |
가로 스크롤이 있는 두 개는 축소 배율이 1이라 글씨 크기가 그대로예요. 축소가 걸린 하나는 반대로 가로 스크롤이 없고요. 증상이 서로 배타적이라, 하나만 확인해도 이 넷 중 절반이 지워집니다.
안 밀리는데 글씨가 작다: 선언 한 줄이 빠졌어요
이건 제일 억울한 경우예요. 코드에는 아무 잘못이 없거든요.
폰 브라우저는 기본적으로 페이지를 데스크탑 폭으로 그린 다음 화면에 맞춰 줄입니다. 옛날 사이트들이 대부분 데스크탑용이라 그렇게 하는 게 그나마 나았어요. 그래서 “이 페이지는 모바일용으로 만들었다”고 알려주는 선언이 따로 있습니다.
<meta name="viewport" content="width=device-width, initial-scale=1">
이 한 줄이 <head> 안에 없으면 브라우저는 넓은 폭으로 그린 다음 360px에 욱여넣어요. 제 측정에서는 그 폭이 980px이었습니다. MDN도 980px을 예로 들고, web.dev는 “보통 980px 정도이지만 기기마다 다르다”고 적어요. 배율은 0.367이 나왔고, 16 × 0.367 = 5.9로 계산이 그대로 맞아떨어집니다.
한 줄을 넣고 다시 재면 이렇게 바뀝니다.
a-fixed.html {"layout":360,"scroll":360,"hscroll":false,"scale":1,"pFontCss":16,"pFontReal":16,"headerCoversH1":null}
배율이 1이 되고 글씨가 제 크기로 돌아왔어요.
AI가 만들어 준 파일이라면 <head> 안에 viewport라는 단어가 있는지부터 찾아보세요. 없으면 그 한 줄이 원인입니다.
왜 내 컴퓨터에선 안 보이나
여기가 이 글의 핵심이에요. 같은 파일을 폭 360px에서 두 번 쟀습니다. 한 번은 모바일 흉내를 켜고, 한 번은 끄고요.
=== isMobile=true
a-noviewport.html {"inner":980,"layout":980,"scroll":980,"vvWidth":980,"vvScale":0.367,"bodyW":980}
=== isMobile=false
a-noviewport.html {"inner":360,"layout":360,"scroll":360,"vvWidth":360,"vvScale":1,"bodyW":360}
아래쪽을 보세요. 레이아웃 360, 축소 없음, 글씨 16px. 완벽하게 정상입니다.
브라우저 창을 좁혀서 확인하는 방법으로는 이 결함이 잡히지 않아요. 폭은 똑같이 360인데 결과가 다릅니다. 축소를 거는 건 화면 크기가 아니라 모바일 브라우저의 동작이거든요.
그래서 “AI한테 반응형으로 만들어 달라고 했고 창을 줄여서 확인도 했는데 폰에서만 깨진다”가 벌어져요. 확인을 안 한 게 아니라, 확인 방법이 이 결함을 못 잡는 종류였던 겁니다.
가로로 밀린다: 뭐가 삐져나왔는지 찾아요
밀린다면 화면보다 넓은 요소가 어딘가 있습니다. 재현한 두 경우는 원인이 다릅니다.
폭을 픽셀로 못 박은 경우. width: 1100px 같은 게 들어가 있으면 화면이 360px이어도 내용은 1148px을 차지해요. 이건 max-width: 1100px으로 바꾸면 끝납니다. width는 “무조건 이만큼”이고 max-width는 “최대 이만큼, 화면이 좁으면 줄여도 됨”이라는 뜻이에요. 바꾸고 재보니 내용 폭이 1148에서 360으로 내려왔습니다.
표가 넓은 경우. 열이 여러 개인 표는 360px에 잘 안 들어갑니다. 제가 만든 6열짜리는 649px을 차지했어요. 이건 표를 줄이는 게 아니라 표만 따로 밀 수 있게 만듭니다. 표를 감싸는 상자에 overflow-x: auto를 주면 페이지는 고정되고 표 안에서만 좌우로 밀려요. 이것도 649에서 360으로 내려왔습니다. 위에 있는 비교표도 6열이라 좁은 화면에서는 표 안에서 밀릴 거예요. 그게 이 처리를 한 결과입니다.
밀리게 만드는 게 하나 더 있어요. 사진이나 지도처럼 크기가 박힌 것들인데, 이건 재현해 보지는 않았습니다. 이미지 쪽은 web.dev가 max-width: 100%를 권하고 있고요.
네 개를 고치고 전부 다시 쟀습니다.
고치기 전과 후 (360px에서 실측)
viewport 메타 추가
width를 max-width로
표를 overflow-x로 감쌈
본문 위 여백 88px
밀리지도 않고 글씨도 멀쩡한데 겹친다
마지막 하나는 폭이 전부 정상인데도 이상해 보이는 경우예요.
d-fixed100vh.html {"layout":360,"scroll":360,"hscroll":false,"scale":1,"pFontCss":16,"pFontReal":16,"headerCoversH1":true}
headerCoversH1: true. 화면 맨 위에 붙어 있는 헤더가 본문 제목을 덮고 있다는 뜻입니다.
상단 메뉴바를 스크롤해도 따라오게 만들면(position: fixed) 그 요소는 문서 흐름에서 빠져요. 자기 자리를 차지하지 않으니 뒤에 오는 본문이 그 밑으로 들어갑니다.
여기서 하나 짚고 갈 게 있어요. 처음엔 저도 이게 좁은 화면 문제인 줄 알고 “데스크탑에서는 넓어서 안 보인다”고 썼는데, 폭을 바꿔 가며 재보니 틀렸습니다.
360 모바일 {"layout":360,"scroll":360,"hscroll":false,"scale":1,"pFontCss":16,"pFontReal":16,"headerCoversH1":true,"headerH":72}
768 데스크탑 {"layout":768,"scroll":768,"hscroll":false,"scale":1,"pFontCss":16,"pFontReal":16,"headerCoversH1":true,"headerH":72}
1280 데스크탑 {"layout":1280,"scroll":1280,"hscroll":false,"scale":1,"pFontCss":16,"pFontReal":16,"headerCoversH1":true,"headerH":72}
1920 데스크탑 {"layout":1920,"scroll":1920,"hscroll":false,"scale":1,"pFontCss":16,"pFontReal":16,"headerCoversH1":true,"headerH":72}
1920px에서도 headerCoversH1이 true입니다. 넷 중 이것 하나만 화면 크기와 상관없어요. 좁은 화면에서 생기는 문제가 아니라, 원래부터 계속 덮고 있던 겁니다.
그래서 이건 폰에서 고쳐도 데스크탑에서 같이 고쳐져요. 앞의 셋과 성격이 다릅니다.
고치는 건 본문 위쪽 여백을 헤더 높이보다 크게 주는 겁니다. 헤더가 72px이면 본문에 88px쯤. 재보니 headerCoversH1이 false로 바뀌었어요.
AI에게 다시 시킬 때
“모바일에서 깨져요”라고만 하면 고칠 자리가 특정되지 않아요. 위 넷은 손대는 파일도 줄도 전부 다른데, 증상 한 마디로는 어느 쪽인지 안 갈립니다. 저라면 이 상태로는 안 시켜요.
증상을 먼저 말하면 범위가 확 줄어듭니다.
- 가로로 밀려요 → “가로 스크롤이 생겨요. 화면보다 넓은 요소를 찾아 주세요”
- 안 밀리는데 글씨가 작아요 → “head에 viewport 메타 태그가 있는지 확인해 주세요”
- 위쪽 요소에 가려요 → “fixed 헤더가 본문을 덮어요. 본문 위 여백을 헤더 높이만큼 주세요”
셋 다 에러 문구를 읽는 순서와 같은 방식이에요. 어디서 잘못됐는지부터 가르고, 그다음에 고칩니다. 순서를 뒤집으면 멀쩡한 자리를 고치고 있게 돼요.
이 글의 한계
재현은 Chromium 모바일 에뮬레이션까지입니다. 실제 아이폰 사파리와 안드로이드 크롬에서 기기를 놓고 재보지는 않았어요. 브라우저마다 축소 동작이 조금씩 다를 수 있습니다.
그리고 100vh가 모바일 주소창과 겹치는 문제는 여기서 재현되지 않았어요. 에뮬레이션에는 주소창이 없어서 화면 높이가 고정으로 나옵니다. 그건 다루지 않았습니다.
창 폭만 줄여서는 안 잡히는 게 있어요
폰에서 깨졌을 때 코드를 열기 전에 손가락으로 한 번 밀어 보세요. 밀리면 삐져나온 요소를 찾고, 안 밀리는데 글씨가 작으면 viewport 한 줄을 찾습니다. 둘 다 아니고 뭔가 겹쳐 보이면 fixed 요소를 봐요.
그리고 브라우저 창을 좁혀서 하는 확인은 이 중 하나를 원래 못 잡습니다. 개발자도구의 기기 모드를 켜거나 실제 폰으로 열어야 보여요. 만든 걸 공개하기 전 점검에 “폰으로 열어 본다”가 들어가는 이유가 이겁니다.
여기 말고 다른 데서 막혔다면
증상만 고르면 지금 뭘 하면 되는지 짚어줘요.
참고 자료
읽으면서 떠오른 사람에게 공유해 주세요
레스덕
· 운영자현직 개발자가 AI·바이브코딩·개발자 커리어를 직접 겪고 판단한 개인 기록입니다. 공식 자료를 간략히 요약하고, 그 위에 저의 경험·판단을 덧붙입니다. 전문 자문이 아니므로, 중요한 결정 전에는 최신 원문과 전문가 상담을 함께 확인해 주세요.
최종 수정 2026.08.14 · 문의 lessduck2@gmail.com