으악 굴림체다!
블로그 메인페이지를 점검하던 중 운영체제에 따라 텍스트 인상이 다르게 보이는 현상을 발견했다. 처음에는 Windows에서만 일부 한글이 굴림체처럼 보이는 문제라고 생각했다. 하지만 코드를 다시 확인해보니, 실제로는 Windows만의 문제가 아니라 한글 폰트 fallback을 명시하지 않은 상태에서 운영체제별 차이가 드러난 경우에 가까웠다.
Font Fallback? 지금 지정한 폰트에 해당 글자가 없으면, 대신 쓸 다른 폰트를 자동으로 찾아서 보여주는 동작
프로젝트에서는 next/font/google로 Geist와 Geist_Mono를 사용하고 있었다. 문제는 이 폰트들이 한글을 직접 지원하지 않는다는 점이다. 그래서 영문은 웹폰트로 렌더링되지만, 한글은 운영체제의 기본 폰트 fallback에 의존하게 된다.
이 구조에서는 macOS와 Windows가 서로 다른 결과를 보여줄 수밖에 없다. macOS에서는 시스템 한글 폰트가 비교적 자연스럽게 보여서 큰 이질감이 없을 수 있다. 반면 Windows에서는 fallback 결과가 더 거칠게 보이면서 같은 화면도 훨씬 어색하게 느껴질 수 있다. 즉, 맥에서는 정상이고 윈도우에서만 깨진 것이 아니라 두 환경 모두 fallback이 개입하고 있었고, Windows에서 그 차이가 더 눈에 띄게 드러난 셈이다.
문제를 더 키운 원인도 있었다. 전역 CSS에서 font-sans, font-mono를 실제 폰트 변수에 연결하는 설정이 비활성화되어 있었고, body 기본 폰트도 Arial, Helvetica, sans-serif로 고정되어 있었다. 결과적으로 한글은 처음부터 시스템 fallback에 크게 의존하는 상태였다.
수정 방법은 단순했다. 한글을 직접 지원하는 웹폰트를 추가하고, 전역 폰트 체인을 명시적으로 다시 연결하면 된다. 이번에는 Noto Sans KR를 함께 로드하고, font-sans, font-mono가 각각 적절한 fallback 순서를 따르도록 정리했다. 또 body 기본 폰트도 전역 폰트 체인을 사용하도록 수정했다.
수정 전 코드는 대략 이런 형태였다.
이 상태에서는 영문은 의도한 폰트처럼 보여도, 한글은 결국 운영체제 기본 폰트에 의해 결정된다. 특히 font-mono가 적용된 구간에서는 한글 fallback이 더 어색하게 드러날 수 있다.
수정 후에는 한글 폰트를 함께 로드하고 전역 체인을 다음처럼 정리했다.
이번 수정의 핵심은 폰트 하나를 추가한 것이 아니라, 한글이 어떤 순서로 fallback 될지를 코드에서 직접 통제하도록 바꾼 데 있다. 영문용 웹폰트만 지정해두고 한글 처리를 운영체제에 맡기면, 환경에 따라 전혀 다른 화면이 만들어질 수 있다.
이번 작업을 통해 다시 느낀 점은 분명하다. 한국어가 포함된 서비스에서는 웹폰트 설정만 볼 게 아니라 한글 fallback 체인까지 함께 설계해야 한다. 그래야 macOS, Windows 어느 환경에서도 텍스트 인상을 더 일관되게 유지할 수 있다.
짧은 정리
Geist와Geist_Mono만으로는 한글을 안정적으로 처리할 수 없었다.- 기존 설정에서는 한글이 운영체제 fallback 폰트에 의존하고 있었다.
- macOS에서는 덜 티 났고, Windows에서는 더 거칠게 드러났다.
Noto Sans KR와 명시적인 fallback 체인을 추가해 문제를 줄였다.<a href="#ref1" />