모니터 해상도와 브라우저 화면은 다른 이야기예요
프론트엔드 작업을 하다 보면 “요즘 모니터는 거의 1920×1080이니까 세로 1080px 기준으로 잡으면 되겠지” 하고 생각하기 쉬운데요. 그런데 실제 사용자 브라우저에서 웹페이지가 그려지는 영역은 그보다 훨씬 작아요. screensize.net이 실제 방문자 브라우저 약 1,000개의 뷰포트 크기를 모아서 리포트로 공개했는데, 결론이 딱 제목 그대로예요. 1080p 모니터를 쓰는 사람의 브라우저 뷰포트 세로 길이는 1080px이 아니라 920px 근처라는 거예요.
뷰포트가 뭐냐면, 브라우저 창에서 탭, 주소창, 북마크 바 같은 브라우저 자체 UI를 뺀 나머지, 그러니까 실제 웹페이지가 표시되는 영역이에요. 여기서 운영체제의 작업 표시줄이나 Dock까지 빠지면 세로 공간이 확 줄어들죠. 1080px 중 150px 넘는 부분은 애초에 우리 페이지 몫이 아니었던 셈이에요.
왜 이런 차이가 생기냐면
윈도우에서 크롬을 최대화해서 쓴다고 해볼게요. 위에는 탭 줄과 주소창이 있고, 북마크 바를 켜뒀다면 한 줄이 더 있어요. 아래에는 윈도우 작업 표시줄이 있고요. 이걸 다 합치면 보통 130~170px 정도가 빠져요. 그래서 1080에서 920 언저리가 되는 거예요. 맥은 메뉴 바와 Dock이 있고, 사파리든 크롬이든 상단 UI가 있으니 비슷하게 줄어들어요. 창을 최대화하지 않고 쓰는 사람도 꽤 많고요.
여기에 한 가지가 더 있어요. 바로 디스플레이 배율이에요. 요즘 윈도우 노트북은 1920×1080 패널에 125%나 150% 배율을 기본으로 켜두는 경우가 많거든요. 이러면 브라우저가 인식하는 CSS 픽셀 기준 화면은 1536×864나 1280×720이 돼요. 여기서 브라우저 UI와 작업 표시줄까지 빼면 뷰포트 세로가 600px대까지 내려가요. 같은 “1080p 노트북”이라도 실제 웹페이지가 쓸 수 있는 공간은 절반 가까이 줄어드는 거죠.
이 리포트가 의미 있는 이유는, 애널리틱스 도구가 보통 보여주는 “화면 해상도”(screen.width/height)가 아니라 실제 “뷰포트 크기”(window.innerWidth/innerHeight)를 측정했다는 점이에요. 둘은 이름이 비슷해서 헷갈리기 쉬운데요. 화면 해상도는 모니터 전체 픽셀 수고, 뷰포트는 그중 웹페이지가 실제로 차지하는 영역이에요. CSS로 레이아웃을 잡을 때 기준이 되어야 하는 건 당연히 후자죠. 그런데 많은 팀이 GA 같은 도구에서 화면 해상도 통계만 보고 “우리 사용자는 1080p가 많네” 하고 넘어가요.
실무에서 뭐가 달라지냐면
가장 직접적으로 영향을 받는 건 “폴드 위(above the fold)” 설계예요. 폴드 위라는 건 스크롤하지 않고 처음 보이는 영역을 말하는데요, 히어로 섹션, 핵심 CTA 버튼, 첫 번째 상품 카드 같은 걸 여기에 넣으려고 하잖아요. 세로 1080px을 기준으로 히어로 이미지를 800px 높이로 잡아버리면, 실제 920px 뷰포트에서는 그 아래 버튼이 잘려서 안 보여요. 랜딩 페이지 전환율이 이유 없이 낮다면 이걸 의심해볼 만해요.
두 번째는 100vh 같은 뷰포트 단위를 쓸 때예요. height: 100vh는 뷰포트 높이 전체를 차지하라는 뜻이라서 뷰포트가 920px이면 920px이 돼요. 단위 자체는 잘 동작하는데, 그 안에 넣은 콘텐츠를 1080px 기준으로 배치했을 때 문제가 생겨요. 모달이나 풀스크린 섹션 안에서 내용이 잘리거나 엉뚱한 스크롤이 생기는 일이 여기서 나와요. 모바일에서는 주소창이 나타났다 사라지면서 뷰포트가 변하는 문제까지 있어서 dvh, svh, lvh 같은 단위가 새로 생긴 거고요.
세 번째는 반응형 브레이크포인트예요. 보통 가로 폭 기준으로만 브레이크포인트를 잡는데, 세로 방향 미디어 쿼리도 있어요. @media (max-height: 700px) 같은 식으로요. 노트북 사용자가 많은 서비스라면 세로가 짧을 때 헤더 높이를 줄이거나 히어로 섹션 패딩을 줄이는 대응이 꽤 효과적이에요.
어떻게 확인하면 좋을까요
개발자 도구를 열어놓고 작업하면 뷰포트는 더 작아져요. 그러니 최종 확인은 개발자 도구를 닫고, 북마크 바까지 켠 상태로 해보세요. 그리고 자기 서비스의 실제 뷰포트 분포를 직접 재보는 게 제일 좋아요. 페이지 로드 시점에 window.innerWidth, window.innerHeight, window.devicePixelRatio 세 값을 한 번 읽어서 애널리틱스 커스텀 이벤트로 보내면 끝이에요. 몇 줄이면 되고, 몇 주만 모아도 “우리 사용자의 뷰포트 세로 중앙값은 얼마” 같은 숫자가 나와요. 디자이너와 이야기할 때 근거가 생기는 거죠.
정리
모니터 해상도와 브라우저 뷰포트는 다르고, 1080p 모니터의 실제 작업 영역은 920px 안팎이라는 걸 기억하면 돼요. 디자인 시안을 1920×1080 아트보드에 그리더라도, 세로 900px 선에 “여기까지가 첫 화면” 가이드라인 하나만 그어두면 많은 문제가 예방돼요.
여러분 서비스는 어떤 뷰포트가 가장 많던가요? 세로 높이까지 고려한 디자인을 실제로 해보신 분이 있다면 어떤 식으로 접근하셨는지 궁금해요.
🔗 출처: Hacker News