한글 폰트를 찾다 보면 결국 비슷한 목록을 여러 번 만나게 된다. “무료 폰트 추천 20선”이라고 적혀 있지만 정작 내 블로그 본문에 어울리는지, 썸네일에서 눈에 띄는지, 숫자는 예쁘게 보이는지 판단하기 어렵다. 글꼴 이름만 봐서는 실제 인상이 잘 떠오르지 않기 때문이다.
그래서 이번에는 10개 서체를 완전히 같은 문장과 숫자로 직접 렌더링했다. 본문용, 앱·웹 UI용, 감성적인 명조, 강한 제목용처럼 목적도 나눴다. 모두 공식 배포처에서 SIL Open Font License 1.1을 확인할 수 있는 서체만 골랐다.
먼저 결론부터 말하면 하나만 설치할 사람에게는 Pretendard, 앱이나 웹 화면을 만드는 사람에게는 SUIT, 차분한 에세이에는 Noto Serif KR, 짧고 강한 썸네일에는 Black Han Sans를 추천한다. 하지만 폰트는 ‘가장 예쁜 것’을 고르는 일이 아니라 읽히는 환경과 문장의 역할에 맞추는 일이다.
비교 기준은 이렇게 잡았다
각 견본에는 “디자인은 예쁘게, 정보는 정확하게”라는 같은 문장을 넣었다. 한글 자모의 전체 분위기를 보기 위해 가나다라마바사아자차카타파하를, 숫자 모양을 비교하기 위해 0123456789도 함께 넣었다.
실제 선택에서는 다음 네 가지를 봤다.
- 긴 문장을 읽을 때 획이 뭉치지 않는가
- 한글과 영문, 숫자가 한 화면에서 자연스러운가
- Regular와 Bold 등 필요한 굵기가 있는가
- 본문, UI, 제목처럼 맡은 역할에 맞는 성격인가
화면에서 폰트를 고를 때는 크게 확대된 홍보 문구만 보면 안 된다. 예쁜 글꼴도 15~17px 본문에서는 답답할 수 있고, 본문에서는 훌륭한 서체가 썸네일에서는 존재감이 약할 수 있다.
1. Pretendard — 고민하기 싫을 때 가장 안전한 기본값
Pretendard는 현대적인 웹과 앱 환경에 맞게 다듬어진 고딕 계열 서체다. 한글과 라틴 문자, 숫자의 균형이 자연스럽고 다양한 굵기를 제공한다. 운영체제 기본 서체와 어울리는 폴백 구성도 공식 문서에 안내돼 있어 웹사이트에 적용하기 편하다.
블로그 본문, 서비스 UI, 카드뉴스, 발표자료까지 두루 사용할 수 있다는 것이 가장 큰 장점이다. 개성이 지나치게 강하지 않으면서도 낡은 인상이 적다. 하나만 설치해야 한다면 픽셀의 첫 선택도 Pretendard다.
아쉬운 점은 워낙 널리 쓰여 브랜드만의 독특한 목소리를 만들기 어렵다는 것이다. 그럴 때는 본문을 Pretendard로 유지하고 제목만 개성 있는 서체로 바꾸는 조합이 안전하다.
2. SUIT — 숫자와 작은 UI가 많은 화면
SUIT는 공식 소개부터 UI 본문용 폰트라고 목적을 분명히 밝힌다. 작은 버튼, 메뉴, 가격, 날짜처럼 한 화면에 정보가 촘촘하게 들어가는 상황에서 단정하다.
Pretendard와 겉보기에는 비슷하지만 숫자와 영문의 리듬, 획의 인상에서 차이가 난다. 모바일 앱, 관리 화면, 쇼핑몰의 가격 정보처럼 짧은 레이블이 반복되는 디자인에 특히 잘 맞는다. 여러 굵기를 변수 폰트 하나로 관리할 수 있는 것도 웹 제작에서는 장점이다.
감성적인 에세이 제목보다는 정확하고 기능적인 화면에 어울린다. 부드러운 분위기가 필요하면 사진과 색상, 여백으로 온도를 더하는 편이 좋다.
3. Noto Sans KR — 긴 본문과 다국어 콘텐츠
Noto Sans KR는 Google과 Adobe의 CJK 서체 프로젝트에 뿌리를 둔 대표적인 한글 고딕이다. 다양한 한자와 기호가 섞이는 문서, 여러 언어가 함께 등장하는 사이트에서 안정적으로 사용할 수 있다.
인상이 중립적이라 뉴스, 설명서, 공공 정보, 긴 블로그 글에 무난하다. 글꼴 자체가 앞에 나서기보다 내용이 먼저 읽힌다. 지원 범위가 넓은 만큼 전체 파일을 웹폰트로 무작정 올리면 용량이 커질 수 있으므로 Google Fonts의 서빙 방식이나 필요한 서브셋을 검토해야 한다.
본문이 한국어만 있고 가벼운 웹페이지라면 Pretendard나 SUIT도 좋은 대안이다. 반대로 여러 문자권을 함께 다뤄야 한다면 Noto 계열의 일관성이 강점이 된다.
4. Spoqa Han Sans Neo — 쇼핑과 데이터 화면
Spoqa Han Sans Neo는 실제 디지털 서비스 환경을 염두에 두고 설계된 서체다. 공식 페이지에서 개인과 기업이 자유롭게 사용·수정·재배포할 수 있다고 설명하며, 원본과 더 가벼운 한글 서브셋도 제공한다.
가격, 수량, 날짜처럼 숫자가 자주 등장하는 쇼핑 화면과 데이터 카드에서 깔끔하다. 지나치게 장식적이지 않고 작은 크기에서도 정보의 우선순위를 만들기 쉽다.
공식 기술 블로그는 무료 CDN을 그대로 쓰면 환경에 따라 로딩이 느려질 수 있어 자체 CDN에 서브셋 파일을 올리는 방법도 제안한다. 웹폰트는 보기 좋은 것만큼 로딩 성능과 캐시 전략이 중요하다는 좋은 사례다.
5. IBM Plex Sans KR — 테크와 리포트의 기계적인 인상
IBM Plex는 IBM이 공개한 오픈소스 서체 패밀리다. Sans Korean을 포함해 Sans, Serif, Mono 등 여러 계열을 제공하며 공식 저장소에서 OFL 라이선스를 확인할 수 있다.
IBM Plex Sans KR은 다른 중립적인 고딕보다 기술적이고 구조적인 분위기가 조금 더 선명하다. 개발 문서, 데이터 리포트, AI·과학 콘텐츠, 포트폴리오에 사용하면 단정하면서도 정체성이 생긴다.
생활 정보나 따뜻한 육아 콘텐츠처럼 친근함이 먼저 필요한 화면에서는 다소 차갑게 느껴질 수 있다. 색상과 이미지가 이미 화려한 디자인에서는 오히려 이 절제된 성격이 균형을 잡아준다.
6. Noto Serif KR — 오래 읽는 에세이와 매거진
고딕만 쓰면 모든 글이 앱 안내문처럼 보일 때가 있다. Noto Serif KR은 명조 계열의 획 대비와 차분한 리듬을 가지면서 여러 굵기를 제공한다.
에세이, 인터뷰, 역사와 문화 이야기, 브랜드 스토리처럼 천천히 읽히는 콘텐츠에 잘 맞는다. 큰 제목에서는 품위가 생기고, 적절한 크기와 줄 간격을 주면 본문에서도 안정적이다.
모바일의 아주 작은 버튼이나 숫자가 많은 표에서는 고딕보다 빠르게 읽히지 않을 수 있다. 전체 UI까지 명조로 통일하기보다 제목과 긴 읽을거리에 제한적으로 사용하는 것이 좋다.
7. Gowun Batang — 따뜻한 감성 글
Gowun Batang은 이름처럼 부드럽고 고운 인상의 바탕체다. Noto Serif KR보다 손맛과 온도가 느껴져 문화, 책, 여행, 음식, 개인 에세이의 짧은 제목이나 인용문에 어울린다.
사진 위에 짧은 문장을 얹거나 여백이 넓은 카드에 사용하면 분위기가 산다. 반대로 정보가 빽빽한 표와 작은 모바일 메뉴에 사용하면 획의 매력이 충분히 드러나지 않고 판독성이 떨어질 수 있다.
감성 폰트라고 해서 줄 간격을 좁게 쓰면 안 된다. 명조와 바탕 계열은 위아래 여백을 넉넉히 주고 한 줄 길이를 줄여야 특유의 호흡이 살아난다.
8. Black Han Sans — 한눈에 박히는 강한 제목
Black Han Sans는 한 가지 굵기로 제공되는 디스플레이용 서체다. 화면을 작게 줄여도 굵은 실루엣이 남아 유튜브 썸네일, 포스터, 행사 제목, 카드뉴스의 첫 장에 강하다.
이 서체의 장점은 힘이고 단점도 힘이다. 긴 문단에 쓰면 검은 면적이 너무 커져 눈이 쉽게 피곤해진다. 한두 줄의 핵심 문구에만 사용하고 본문은 중립적인 고딕으로 받쳐야 한다.
자간을 무작정 줄이면 두꺼운 글자끼리 붙어 보일 수 있다. 실제 썸네일 크기로 축소해 읽히는지 확인하는 과정이 필요하다.
9. Do Hyeon — 친근하면서 힘 있는 카드뉴스
Do Hyeon은 붓글씨의 구조를 단순하고 현대적으로 정리한 제목용 서체다. Black Han Sans보다 부드럽고 Jua보다는 단단한 중간 지점에 있다.
음식, 여행, 생활 정보, 행사 소개처럼 친근해야 하지만 제목의 존재감도 필요한 콘텐츠에 쓰기 좋다. 짧은 소제목이나 카드뉴스 제목에서는 개성이 분명하다.
본문 전체에 사용하면 반복되는 독특한 획이 피로를 줄 수 있다. 이 역시 제목 전용으로 생각하는 편이 안전하다.
10. Jua — 둥글고 명랑한 짧은 제목
Jua는 둥글고 밝은 인상이 강한 디스플레이 서체다. 캐주얼한 썸네일, 어린이 콘텐츠, 음식이나 취미 주제처럼 재미가 중요한 디자인에 잘 어울린다.
서체의 목소리가 강해서 금융, 법률, 보안 경고처럼 신뢰와 긴장감이 중요한 주제에는 어울리지 않을 수 있다. 귀엽다는 이유만으로 모든 콘텐츠에 쓰기보다 브랜드의 말투와 맞는지 먼저 확인하자.
굵기는 폰트만큼 중요하다
같은 Pretendard도 Light와 ExtraBold는 거의 다른 목소리로 보인다. 긴 본문은 보통 400 Regular 전후가 편하고, 소제목은 600 SemiBold, 짧은 대표 제목은 700~800 정도부터 검토할 수 있다.
가장 흔한 실수는 중요한 내용을 전부 굵게 만드는 것이다. 모든 문장이 강조되면 실제로는 아무것도 강조되지 않는다. 제목, 소제목, 본문, 보조 설명 사이에 굵기와 크기의 계층을 만들자.
접근성도 생각해야 한다. 가는 글씨를 밝은 회색으로 쓰면 고해상도 화면에서는 세련돼 보이지만 햇빛 아래의 모바일이나 저시력 사용자에게는 읽기 어렵다. 색 대비와 글자 크기를 함께 확인해야 한다.
무료 폰트는 라이선스를 어디까지 확인해야 할까
이번에 소개한 10종은 공식 배포처에서 SIL Open Font License 1.1을 확인한 서체다. OFL은 일반적으로 상업적 사용과 문서·이미지·웹사이트 임베드를 폭넓게 허용한다. 폰트 자체를 수정하거나 재배포할 때는 라이선스 유지, 저작권 고지, Reserved Font Name 같은 조건을 지켜야 하며 폰트 파일 자체만 따로 판매해서는 안 된다.
“무료 다운로드”라는 블로그 문장만 믿지 말고 공식 저장소의 LICENSE 파일을 확인하자. 같은 이름의 서체라도 비공식 재배포 파일이 오래됐거나 라이선스 문서가 빠질 수 있다. 회사 로고, 앱 번들, 전자책, 영상 자막처럼 사용 범위가 넓다면 배포 시점의 원문을 보관해 두는 것도 좋다.
OFL 서체를 사용해 만든 PNG 썸네일이나 PDF 문서에 라이선스를 매번 표시해야 한다는 뜻은 아니다. 다만 폰트 파일 자체를 제품에 묶거나 수정본을 배포하면 조건이 달라질 수 있으므로 공식 라이선스 원문을 기준으로 판단해야 한다.
웹폰트로 쓸 때 속도도 확인하자
한글은 필요한 글자 수가 많아 영문 웹폰트보다 파일이 커지기 쉽다. 모든 굵기의 전체 파일을 첫 화면에서 불러오면 글이 늦게 나타나거나 처음에 시스템 폰트로 보였다가 바뀌는 현상이 생길 수 있다.
실제로 쓰는 굵기만 선택하고 WOFF2 형식을 우선하며, 동적 서브셋이나 한글 서브셋을 제공하는 프로젝트라면 공식 안내를 검토하자. 외부 CDN은 편하지만 서비스 성능과 개인정보 정책, 장애 가능성도 고려해야 한다. 운영 사이트라면 자체 호스팅이 더 적합할 수 있다.
CSS에는 한 가지 폰트 이름만 쓰지 말고 시스템 폰트까지 폴백을 둔다. 폰트가 늦거나 특정 문자를 지원하지 않아도 내용이 사라지지 않게 하기 위해서다.
네이버 블로그에서도 이 폰트를 그대로 쓸 수 있을까
네이버 블로그 편집기는 사용자가 임의의 웹폰트 파일을 넣어 전체 본문 서체로 유지하는 방식에 제한이 있다. 따라서 일반 본문은 네이버가 제공하는 읽기 편한 글꼴을 쓰고, 이번 글처럼 정확한 서체 차이를 보여줘야 할 때는 실제 폰트로 렌더링한 고해상도 이미지를 넣는 방법이 가장 안정적이다.
하지만 중요한 정보를 모두 이미지 속 글자로만 만들면 검색과 접근성이 나빠진다. 이미지 바로 앞뒤에 폰트 이름과 설명을 실제 텍스트로 함께 적고, 이미지에는 내용을 설명하는 대체 텍스트를 제공해야 한다. 이 글도 견본 이미지와 동일한 정보를 본문에서 다시 설명한 이유다.
픽셀의 최종 추천
무난한 기본값이 필요하면 Pretendard, 작은 UI와 숫자가 많으면 SUIT, 폭넓은 문자와 긴 정보 글에는 Noto Sans KR이 좋다. 테크 분위기를 내고 싶다면 IBM Plex Sans KR, 감성적인 긴 글에는 Noto Serif KR이나 Gowun Batang을 먼저 시험해 보자.
제목에서는 Black Han Sans가 가장 강하고, Do Hyeon은 친근한 정보 카드, Jua는 밝고 캐주얼한 콘텐츠에 잘 맞는다. 한 화면에서 폰트를 세 종류 이상 섞기보다 본문 하나와 제목 하나, 많아도 보조 서체 하나 정도로 제한하는 편이 완성도가 높다.
결국 좋은 폰트는 확대했을 때 가장 예쁜 폰트가 아니다. 독자가 실제로 보는 크기에서 내용의 성격을 해치지 않고 오래 읽히는 폰트다. 마음에 드는 후보가 생겼다면 샘플 문구가 아니라 내 글의 가장 긴 문단과 실제 숫자로 먼저 테스트해 보자.
