디자이너가 웹 폰트를 최적화하는 5가지 실무 방법
UXUI디자이너가 피그마와 실제 화면의 차이에 대해 알아야 하는 것
아 폰트는 이상 없는데 왜 다르지?
https://peerlist.io/designerdada/articles/why-fonts-look-bolder-in-browsers-compared-to-figma디자이너라면 한 번쯤 이런 경험이 있을 것이다. 피그마에서 분명 균형 잡힌 화면이었는데, 실제 웹 페이지를 열어보면 글자가 묘하게 다르게 보인다. 어떤 건 자간이 더 벌어져 있고, 어떤 건 폰트가 한 단계 두꺼워 보인다. 개발자에게 “폰트 맞게 들어갔나요?”라고 물어보면, “디자인 그대로예요.”라는 답이 돌아온다. 그리고 그때부터 미묘한 오차의 원인을 찾는 과정이 시작된다. 아래는 그런 상황에서 디자이너가 직접 점검해볼 수 있는 다섯 가지 포인트다.
1. 피그마의 폰트는 ‘기준점‘으로만 본다
https://stackoverflow.com/questions/16956533/poor-font-rendering-in-firefox-vs-other-browsers피그마에서 사용하는 폰트는 실제 서비스의 렌더링 결과와 일치하지 않을 수 있다. 운영체제(Windows, macOS 등)와 브라우저(Chrome, Safari, Edge 등)의 렌더링 방식이 다르기 때문이다. 예를 들어 맥에서는 더 얇고 정제돼 보이는 글자가, 윈도우에서는 조금 더 두껍게 보일 수 있다. 따라서 피그마의 폰트는 디자인을 위한 시각적 기준점으로 이해하는 편이 좋다.
가능하다면 피그마에서는 기준 폰트를 사용해 대략적인 덩어리감을 확인하고, 실제 사용 환경에서 미세 조정하겠단 생각을 하거나, 이 부분을 과감하게 넘기는 게 좋다. 또한 시스템 폰트를 쓸 경우에는 ‘대체 폰트(fallback font)’를 지정해보면 좋다. 대체 폰트란, 원래 폰트가 로드되지 않았을 때 대신 표시되는 글꼴로, 실제 서비스에서 폰트가 교체될 때의 인상을 미리 가늠할 수 있게 해준다. 이런 비교 과정을 거치면 디자이너와 개발자가 더 비슷한 기준으로 화면을 바라볼 수 있다.
2. Line height는 웬만하면 숫자로
https://iamvdo.me/en/blog/css-font-metrics-line-height-and-vertical-align피그마에서 Line height(줄 간격)를 “Auto(자동)”로 두면, 실제 코드에서는 line-height: normal로 변환된다. 이 경우 브라우저마다 내부 계산식이 달라 라인 간격이 조금씩 달라질 수 있다.
그래서 피그마에서도 명확한 수치로 라인 높이를 고정하는 게 비교적 안정적일 수 있다.
예를 들어 16px 텍스트라면 Line height를 24px로 지정하고, 이 수치를 개발자에게 그대로 전달하는 식이다. 이렇게 하면 브라우저 간 간격 차이를 줄일 수 있고, QA 단계에서 오차의 원인을 명확히 설명하기도 수월해진다. 내가 정확하게 통제할 수 없다면 변수를 줄이는 것이 바람직하다.
3. 폰트 크기는 px 단위를 병기하자
https://yozm.wishket.com/magazine/detail/1410/피그마에서는 텍스트가 기본적으로 px 단위로 표시되지만, 실제 웹에서는 rem 또는 em 단위로 변환되어 적용되는 경우가 많다. 이때 기준이 되는 root font size(루트 폰트 크기, 보통 16px)가 다르면 전체 비율이 함께 달라질 수 있다.
예를 들어 개발자가 1rem = 10px로 설정해두었다면, 피그마에서 16px로 지정한 텍스트가 실제로는 다른 비율로 표시될 수 있다. 따라서 디자이너는 시안을 전달할 때 절대 단위(px)를 기준으로 명시하고, 개발팀이 rem 단위를 사용할 경우에는 “1rem이 몇 px인지”를 함께 확인해보는 게 좋다. 이렇게 단위를 맞춰두면 전체적인 비율을 더 유연하게 조정할 수 있다. 물론 가장 좋은 방법은 rem 을 사용해 유연하고 일관된 타이포그래피 스타일을 맞추는 거지만, 처음엔 막막하고 쉽지 않다. 익숙한 단위인 px을 먼저 사용하고 rem 단위를 여유가 될 때 고민해서 고도화하는 방향이 바람직하다.
4. 글자 굵기는 수치보다 시각적으로 판단한다
https://blog.stephaniestimac.com/posts/2020/06/browser-fonts/피그마에서 Medium(500)으로 보이던 글자가 실제 브라우저에서는 더 얇게 보이거나, Bold(700)가 예상보다 두꺼워 보일 때가 있다. 이는 브라우저가 글자를 픽셀 단위로 렌더링하면서 힌팅(hinting, 글자를 픽셀 격자에 맞게 조정하는 과정)을 다르게 적용하기 때문이다.
이럴 땐 수치의 일치보다 시각적 인상에 더 가깝게 보이도록 조정하는 게 현실적일 수 있다. 예를 들어 피그마에서 Regular(400)로 보이던 폰트가 실제로 더 가늘게 느껴진다면, CSS에서 500 정도로 조정해보는 식이다. 디자이너는 개발자에게 “Medium으로 고정해주세요”보다는 “피그마에서의 Regular처럼 보이게 맞춰주세요”라고 전달하는 편이 시각적으로는 더 유연하다. 물론 개발자가 얼마나 눈썰미가 좋으냐에 따라 다르겠지만...
5. 비교 이미지는 동일한 환경에서 캡처한다
https://codeburst.io/react-native-quirks-2fb1ae0bbf80디자인 QA(품질 검수) 단계에서 가장 흔한 오류 중 하나는 서로 다른 환경에서 화면을 비교하는 것이다. 맥북의 Retina 디스플레이에서 캡처한 폰트는 윈도우 기본 해상도보다 더 얇고 선명하게 보인다. 또한 브라우저 줌(Zoom) 비율이 90%로 조정된 상태에서 캡처한 화면은 실제 100%일 때보다 자간이 더 넓게 느껴질 수 있다. 그래서 QA 캡처는 가능하면 동일한 브라우저, 동일한 해상도, 동일한 배율(100%)에서 진행하는 게 좋다. 디자이너가 이 기준을 문서로 정리해두면, 이후 개발자나 QA 담당자와 같은 조건에서 검수할 수 있다. 이렇게 하면 ‘같은 화면을 본다’는 합의가 조금 더 명확해질 수 있다.
웹 폰트 최적화는 결국 성능의 문제가 아니라 같은 화면을 어떻게 해석하느냐의 문제일 때가 많다. 피그마에서의 설정을 조금 더 세밀하게 다듬고, 개발자와의 대화에서 단위나 환경을 함께 점검하는 것만으로도 결과는 한층 일관되게 보일 수 있다. 디자이너가 모든 걸 통제할 수는 없지만, 무엇을 기준으로 삼을지 선택할 수는 있다. 그 선택이 쌓여야 디자이너의 의도에 가깝게 보이기 시작할 것이다.
