자신이 쓴 코드 한 줄의 근거를 사용자의 경험에서 찾을 수 있나요?
수많은 프로젝트를 진행하며 우리는 관성적으로
px을 사용해 왔습니다.
웹 초창기에는 화면 해상도가 단순했고
‘접근성’에 대한 인식이 낮았기에, 절대 단위인 px만으로도
충분했기 때문입니다. 하지만 웹 생태계가 확장되며
사용자가 원하는 글자 크기로 콘텐츠를 소비하고 싶어 하는 니즈가 생겨났고,
그 과정에서 em이 등장했습니다.
그러나em은 부모 요소에 종속되어 중첩될수록
크기 예측이 어려워지는 단점이 있었죠.
이를 해결하기 위해 등장한 것이 바로 최상위 요소(html)의
폰트 사이즈를 기준으로 삼는
rem(Root em)입니다.
대부분의 브라우저는 기본 글꼴 크기를
16px로 설정해 둡니다.
html태그는 이 브라우저 설정값을 그대로 상속(Inherit)받으며,
rem은 바로 이 값을 기준으로 계산됩니다.
여기서 우리가 흔히 헷갈리는 포인트가 있습니다.
브라우저 확대/축소(Zoom): 화면 전체를 돋보기로 보듯 키우는 기능으로, px과 rem을 가리지 않고 모든 요소를 비례적으로 키웁니다.
기본 글꼴 크기 설정: 사용자가 브라우저 설정에서 글꼴 크기만 바꾸는 경우입니다. 이때 px로 고정된 요소는 변하지 않지만, rem으로 설정된 요소는 설정값에 맞춰 커집니다.
즉, 모든 곳에 rem을 쓴다는 것은 사용자가 글자 크기만 키웠을 때
내 의도와 상관없이 레이아웃 전체가 거대해지는 위험을 감수하겠다는 뜻이기도 합니다.
rem은 접근성을 위한 훌륭한 도구이지만, 무분별한 사용은 독이 됩니다.
우리는 “이 UI는 커져도 안전한가?”를 먼저 자문해야 합니다.
읽기 경험이 중요한 본문 텍스트에는 rem이 적합하지만
다음 영역들은 px고정을 고려해야 합니다.
비주얼 구성 요소로서의 텍스트: 메인 히어로 영역의 큰 타이포그래피나 랜딩 페이지의 화려한 텍스트는 정보 전달보다 ‘디자인적 균형’이 우선입니다. 크기가 변해 레이아웃이 깨진다면 본연의 미학적 기능을 잃게 됩니다.
그리드 안정성이 우선되는 UI: 상품 목록 카드처럼 높이가 고정되어 있고, 줄 바꿈 제한이 엄격한 요소들입니다. rem 적용 시 사용자가 폰트 크기를 키우면 카드 밖으로 글자가 넘치거나 그리드가 무너질 가능성이 큽니다.
인터랙션 및 레이아웃 요소: 슬라이드, 배너, 캐러셀 내부의 요소들은 애니메이션 수치와 긴밀하게 연결되어 있습니다. 텍스트 크기만 따로 커지면 예기치 못한 오동작이나 시각적 파편화가 발생합니다.
rem과 px사이의 선택은 단순한 기술적 결정이 아니라, 세밀한 UX 의사결정이어야 합니다.
우리가 단위를 선택할 때 스스로에게 던져야 할 질문은 “어떤 단위가 더 최신인가?”가 아닙니다.
“사용자가 글자 크기를 키웠을 때, 이 화면이 무너지지 않고 유연하게 정보를 전달할 수 있는가?”를
설명할 수 있어야 합니다.
이 기준이 잡히는 순간, 단위 선택은 더 이상 고민이 아니라 명확한 설계가 됩니다.
결국 좋은 개발자란 코드를 잘 짜는 사람이 아니라,
자신이 쓴 코드 한 줄의 근거를 사용자의 경험에서 찾을 수 있는 사람일 것입니다.