한글 폰트 페어링 공식 7가지: 2026년 실무 가이드

한글 폰트 페어링의 본질: 왜 영문과 다른 규칙이 필요한가

한글 페어링을 영문 공식대로 풀면 어긋나기 쉽습니다. 같은 9pt에서 "Typography"와 "타이포그래피"를 나란히 놓으면 한글은 글자틀(가상 보디)을 라틴 알파벳보다 꽉 채워 시각적으로 더 크고 무겁게 보입니다. 모아쓰기 구조 탓에 자소가 한 칸 안에 압축되고, 받침이 있는 글자는 자소 수가 많아 같은 칸 안에서 검은 면적(밀도)이 더 높아집니다. 영문이 가로 흐름의 리듬을 만든다면, 한글은 정사각형 블록의 무게 분포가 리듬을 만듭니다.

네모틀 한글의 시각적 무게

한글 본문 서체 대부분은 네모틀(고정 가상 보디) 안에 자소를 배치합니다. 이 구조는 글줄 정렬이 깔끔한 대신, 받침 유무로 글자 높이가 출렁이는 라틴 알파벳과 달리 위아래 여백이 균일합니다. 결과적으로 한글 본문은 "검은 면적이 일정한 회색 띠"로 인지됩니다. 이 회색 띠 위에 헤드라인을 얹을 때, 영문처럼 세리프 디테일만 바꿔서는 위계가 잘 생기지 않습니다. 한글에서는 굵기 자체의 면적 차이가 위계를 만드는 주된 수단이 됩니다.

자소 복잡도와 본문 가독성

"빨갛게"와 "가다"는 같은 본문 크기에서도 인지 부담이 다릅니다. 자소 수가 많을수록 본문 서체의 자소 균일도가 중요해집니다. 본고딕(Noto Sans KR)이 본문에서 안전한 이유는 자소 간 굵기 편차가 작아 받침이 복잡한 글자에서도 막히지 않기 때문입니다. 반대로 획 대비(자소 강약)가 큰 서체는 작은 본문 크기에서 자소가 몰리는 받침 부분이 뭉쳐 보일 수 있어, 본문보다 제목에 적합합니다.

영문 페어링 공식을 그대로 쓰면 실패하는 이유

"Serif + Sans"를 "명조 + 고딕"으로 단순 치환하면 두 가지 함정에 빠집니다. 첫째, 한글 명조는 가로획이 가늘고 세로획이 굵은 구조이지만, 본문 크기에서는 이 대비가 잘 드러나지 않아 라틴 고대비 세리프(예: 디돈)만큼 강한 대비 효과를 기대하기 어렵습니다. 둘째, 한글 고딕은 자소 밀도가 높아 라틴 산세리프보다 본문에서 페이지가 어둡게 인지되는 경향이 있습니다. 그래서 이 가이드는 한글 페어링을 분류(명조/고딕)보다 굵기 대비 + 자폭 대비 + 자소 밀도 대비 세 축으로 봅니다.

2026년 페어링을 좌우하는 3가지 변수: 굵기·자폭·자소 밀도

굵기(weight) 대비 — 단계를 건너뛴 굵기 차 두기

CSS의 font-weight는 100~900까지 9단계입니다. 인접한 단계(예: Regular 400과 Medium 500)는 화면에서 거의 같은 무게로 보여 위계가 잘 생기지 않습니다. 헤드와 본문을 분리하려면 한 단계 이상 건너뛴 굵기 차(예: 400과 700)를, 더 또렷하게는 300과 700처럼 폭넓은 차를 둡니다.

자폭(width) — 본문과 제목의 자폭 격차 해석

자폭이 좁은 응축형(condensed) 헤드라인에 자폭이 넓은 본문을 짝지으면 페이지 무게중심이 위로 쏠립니다. 반대로 자폭이 넓은 헤드에 좁은 본문을 깔면 헤드가 떠 보입니다. 헤드라인이 응축형이면 본문도 자폭 100% 기준의 평균치를, 헤드가 평균 자폭이면 본문은 그보다 살짝 넓은 자폭을 선택합니다.

자소 밀도 — 본고딕 계열과 산돌 계열의 차이

같은 "고딕"으로 분류되어도 본고딕(Noto Sans KR, 프리텐다드 계열)은 자소 굵기가 균일하고, 산돌고딕Neo·산돌그레타산스는 자소 강약이 뚜렷합니다. 자소 강약이 강한 서체는 헤드라인에 강하고 본문에 약합니다. 페어링 짝을 고를 때 한쪽이 강약형이면 다른 쪽은 균일형으로 가는 것이 안전합니다.

3가지 변수별 점검 체크리스트

굵기 대비

• 헤드와 본문의 굵기가 한 단계 이상 건너뛰어 뚜렷이 구별되는가
• 동일 화면에서 헤드가 본문보다 명확히 무거워 보이는가
• 50%로 축소해도 위계가 유지되는가

자폭

• 헤드와 본문의 자폭 분류(좁음/평균/넓음)를 파악했는가
• 자폭 격차가 두 단계 이상 벌어지지 않는가
• 단락 줄 끝선이 들쭉날쭉하지 않은가

자소 밀도

• 헤드와 본문이 강약형/균일형으로 역할이 분리되어 있는가
• 본문에 자소 강약이 강한 서체를 쓰지 않았는가
• 받침 복잡한 글자("빨갛게", "맑았다")에서 자소가 뭉치지 않는가

실무 즉시 적용 페어링 공식 7가지

각 공식은 헤드/본문 weight, 권장 자간·행간, 적합 매체, 라이선스를 함께 명시합니다. 자간 단위는 CSS letter-spacing(em 또는 px), 행간은 line-height(배수)입니다. 아래 자간·행간 수치는 권장 시작값이며, 실제 본문 크기·매체·줄 길이에 맞춰 미세 조정합니다.

공식 1: 프리텐다드 + 노토 세리프 KR — 무료 조합의 표준

• 헤드: Pretendard 700 / 본문: Noto Serif KR 400
• 자간: 헤드 -0.02em, 본문 -0.01em / 행간: 본문 1.7
• 적합 매체: 웹·모바일 (인쇄도 가능)
• 라이선스: 둘 다 SIL OFL, 상업 사용 무제한
• 쓰지 말 것: 9pt 이하 인쇄. 노토 세리프의 가는 획이 약해지는 경향이 있습니다.

.headline { font-family: 'Pretendard', sans-serif; font-weight: 700; }
.body { font-family: 'Noto Serif KR', serif; font-weight: 400; line-height: 1.7; }

공식 2: SUIT + 이롭게바탕체 — 모던 명조 대비

• 헤드: SUIT 800 / 본문: 이롭게바탕체 Regular
• 자간: 헤드 -0.025em, 본문 0 / 행간: 본문 1.8
• 적합 매체: 브랜드 웹사이트, 디지털 아티클 (이롭게바탕체는 웹 전용 바탕체)
• 라이선스: SUIT·이롭게바탕체 둘 다 SIL OFL (상업 가능)
• 쓰지 말 것: 고품질 인쇄 본문. 이롭게바탕체는 화면 전용이라 지면 명조는 마루 부리로 대체합니다.

.headline { font-family: 'SUIT', sans-serif; font-weight: 800; }
.body { font-family: 'IropkeBatangM', serif; font-weight: 400; line-height: 1.8; }

공식 3: 본고딕(Noto Sans KR) + 나눔명조 — 가장 안전한 공공 조합

• 헤드: Noto Sans KR 700 / 본문: 나눔명조 Regular
• 자간: 헤드 -0.02em, 본문 0 / 행간: 본문 1.7
• 적합 매체: 공공기관, 보고서, 행정 문서, 교육 자료
• 라이선스: 둘 다 OFL, 무제한 상업 사용
• 쓰지 말 것: 감성 브랜딩 헤드라인. 인지도가 너무 높아 차별화가 안 됩니다.

.headline { font-family: 'Noto Sans KR', sans-serif; font-weight: 700; }
.body { font-family: 'NanumMyeongjo', serif; font-weight: 400; line-height: 1.7; }

공식 4: 카페24 써라운드 + 프리텐다드 — 브랜딩 헤드라인용

• 헤드: 카페24 써라운드 / 본문: Pretendard 400
• 자간: 헤드 -0.04em, 본문 -0.01em / 행간: 본문 1.65
• 적합 매체: 이커머스 배너, 캠페인 페이지, SNS 카드뉴스
• 라이선스: 카페24 써라운드 무료·상업 가능 (SIL OFL, 폰트 자체 판매만 금지)
• 쓰지 말 것: 본문에 써라운드 사용. 자폭 응축형이라 가독성이 떨어집니다.

.headline { font-family: 'Cafe24Ssurround', sans-serif; font-weight: 700; }
.body { font-family: 'Pretendard', sans-serif; font-weight: 400; line-height: 1.65; }

공식 5: 양진체 + 본고딕 — 손글씨 헤드 + 정돈 본문

• 헤드: 양진체 Regular / 본문: Noto Sans KR 400
• 자간: 헤드 0(손글씨는 자간 손대지 않음), 본문 -0.01em / 행간: 본문 1.75
• 적합 매체: 에세이, 브랜드 스토리, 단행본 표지
• 라이선스: 양진체 무료(상업 가능), 본고딕 OFL
• 쓰지 말 것: 모바일 헤드라인 20px 미만. 작을수록 손글씨 디테일이 약해지는 경향이 있습니다.

.headline { font-family: 'Yangjin', cursive; font-weight: 400; }
.body { font-family: 'Noto Sans KR', sans-serif; font-weight: 400; line-height: 1.75; }

공식 6: IBM Plex Sans KR + IBM Plex Serif — 글로벌 톤

• 헤드: IBM Plex Sans KR 600 / 본문: IBM Plex Serif 400 (영문 본문) + IBM Plex Sans KR 400 (한글 본문)
• 자간: 헤드 -0.015em, 본문 0 / 행간: 본문 1.7
• 적합 매체: 다국어 웹사이트, 기술 문서, 글로벌 B2B
• 라이선스: SIL OFL
• 쓰지 말 것: 한글 본문에 Plex Serif(라틴 전용). 한글이 fallback으로 빠집니다.

.headline { font-family: 'IBM Plex Sans KR', sans-serif; font-weight: 600; }
.body-en { font-family: 'IBM Plex Serif', serif; font-weight: 400; }
.body-ko { font-family: 'IBM Plex Sans KR', sans-serif; font-weight: 400; line-height: 1.7; }

공식 7: 에스코어드림 + 마루부리 — 감성 콘텐츠 표준

• 헤드: 에스코어드림 6 Bold / 본문: 마루 부리 Regular
• 자간: 헤드 -0.03em, 본문 -0.005em / 행간: 본문 1.8
• 적합 매체: 라이프스타일 매거진, 브랜드 저널, 인터뷰 콘텐츠
• 라이선스: 에스코어드림 무료(상업 가능), 마루 부리 OFL
• 쓰지 말 것: 9pt 이하 인쇄. 작은 크기에서 마루 부리 곡선 디테일이 뭉치는 경향이 있습니다.

.headline { font-family: 'S-Core Dream', sans-serif; font-weight: 700; }
.body { font-family: 'MaruBuri', serif; font-weight: 400; line-height: 1.8; }

매체별 페어링 결정 트리: 웹·모바일·인쇄·영상

매체가 무엇인가?
├─ 웹 (PC + 모바일 반응형)
│  ├─ 본문은 가변 폰트 우선 → Pretendard Variable / SUIT Variable
│  ├─ 명조 본문이 필요하면 → 이롭게바탕체(웹 전용)·노토 세리프 KR
│  ├─ 헤드는 동일 패밀리의 굵은 weight 또는 명조 대비
│  └─ 서브셋(KR-subset) 적용으로 초기 로딩 200KB 이하 목표
│
├─ 모바일 전용 (앱, 인앱 웹뷰)
│  ├─ 본문 14~16px → 자소 균일형 필수 (본고딕, Pretendard)
│  ├─ 헤드는 자소 강약형 가능 (SUIT 800, 에스코어드림 9)
│  └─ 시스템 폰트 fallback 명시 (-apple-system, sans-serif)
│
├─ 인쇄 (단행본·매거진)
│  ├─ 본문 9~10pt
│  │  ├─ 명조 쓰려면 → 마루 부리, 나눔명조
│  │  └─ 8pt 이하면 → 명조 금지, 본고딕·나눔고딕
│  ├─ 헤드는 자소 디테일 살아나므로 강약형 자유 선택
│  └─ CMYK 변환 시 가는 획 두께 보정 필수
│
└─ 영상·모션 (1~3초 노출)
   ├─ 본문 개념 없음 → 헤드 위주 설계
   ├─ weight 700 이상, 자간 -0.03em 이상 좁힘
   └─ 자막은 본고딕 500 + 외곽선 0.5px (가독성 안전선)

피해야 할 페어링 안티패턴 6가지

1. 같은 분류 안 다른 서체 섞기 (고딕 + 고딕)

• 왜 안 되는지: 두 고딕의 미묘한 차이는 위계가 아니라 어긋남으로 인지됩니다.
• 대신 이렇게: 같은 패밀리 내에서 weight로 위계를 만들거나, 고딕+명조로 분류를 바꿉니다.

2. 인접 굵기 단계만으로 미세 대비

• 왜 안 되는지: 400과 500은 디스플레이에서 거의 같은 무게로 보입니다.
• 대신 이렇게: 한 단계 이상 건너뛴 굵기 차(400 vs 700)를 둡니다.

3. 자폭이 모두 좁은 응축형 조합

• 왜 안 되는지: 페이지가 답답하고 본문 줄 끝선이 들쭉날쭉해집니다.
• 대신 이렇게: 헤드 응축형이면 본문은 평균 자폭으로 균형을 맞춥니다.

4. 명조 헤드 + 명조 본문 (구분 불가)

• 왜 안 되는지: 본문 크기의 한글 명조는 획 대비가 약하게 보여 명조끼리는 분류 차이가 잘 드러나지 않습니다.
• 대신 이렇게: 헤드를 고딕 Bold 이상으로 바꾸고 본문에 명조를 둡니다.

5. 무료 + 유료 라이선스 혼용 시 갱신 누락

• 왜 안 되는지: 유료 쪽 갱신을 놓치면 페어링 절반이 무단 사용 상태가 됩니다.
• 대신 이렇게: 라이선스 갱신 일정을 한 시트에 묶어 관리하거나, 핵심 매체는 OFL 조합으로 통일합니다.

6. 단종·라이선스 변경 예정 서체

• 왜 안 되는지: 1~2년 내 재배포 중단되면 페어링 일관성이 깨집니다.
• 대신 이렇게: 페어링 채택 전 제공사 공지·약관 변경 이력을 확인합니다.

페어링 검증 체크리스트: 발행 전 확인할 12항목

시각적 위계 (4항목)

• 눈을 가늘게 떠도 헤드와 본문의 무게 차이가 보이는가
• 50%로 축소해도 헤드가 본문보다 명확히 무거운가
• 페이지를 흑백으로 변환해도 위계가 유지되는가
• 헤드와 본문의 굵기가 한 단계 이상 건너뛰어 뚜렷이 구별되는가

가독성·접근성 (4항목)

• 본문 자소 강약이 균일한가 (받침 복잡한 글자 뭉침 없음)
• 모바일 14px 기준 행간 1.6 이상인가
• 본문 색 대비비가 WCAG AA(4.5:1) 이상인가
• 시스템 폰트 fallback이 명시되어 있는가

라이선스·기술 (4항목)

• 두 서체 모두 해당 매체(웹/인쇄/영상)의 사용 범위에 포함되는가
• 유료 서체의 갱신 만료일을 캘린더에 등록했는가
• 웹폰트라면 사용 도메인이 라이선스에 등록되어 있는가
• 서브셋·variable 적용으로 본문 폰트 로딩 200KB 이하인가

FAQ

Q1. 페어링은 몇 종까지 써도 되나요 원칙은 2종입니다. 헤드 1종 + 본문 1종입니다. 3종을 쓰려면 "본문 한글 + 본문 영문 + 헤드"처럼 역할이 완전히 분리될 때만입니다. 카드뉴스·랜딩페이지에서 4종 이상 쓰면 위계가 무너집니다. Pretendard처럼 weight 9단계를 가진 가변 폰트는 한 패밀리만으로 헤드(700~900)·서브헤드(600)·본문(400)·캡션(300)까지 모두 처리할 수 있어 사실상 1종 운영이 가능합니다.

Q2. 유료 서체와 무료 서체를 함께 써도 되나요 기술적으로는 가능하고 실무에서도 흔합니다. 다만 유료 쪽 라이선스 갱신을 놓치면 페어링 절반이 무단 사용 상태로 빠집니다. 산돌구름·윤디자인 구독을 쓴다면 만료 60일 전 알림을 등록하고, 핵심 매체(메인 페이지·간판 인쇄물)에는 OFL 무료 조합(Pretendard + Noto Serif KR 등)을 백업으로 준비합니다.

Q3. 영문은 본문 한글 서체에 내장된 라틴을 그대로 써도 되나요 서체별로 다릅니다. Pretendard·SUIT·IBM Plex Sans KR은 라틴 글리프가 별도 설계되어 그대로 써도 무방합니다. 반면 Noto Sans KR의 라틴은 Noto Sans와 자형이 달라 영문 비중이 높은 본문에서는 어색할 수 있습니다. 영문 비중이 높은 본문이라면 한글 서체와 별도로 라틴 본문 서체를 지정하는 것이 안전합니다.

Q4. Variable Font 하나로 페어링을 대체할 수 있나요 부분적으로 가능합니다. Pretendard Variable은 weight 100~900을 한 파일에서 조절하므로 헤드(800)·서브헤드(600)·본문(400)의 3단 위계가 한 패밀리 안에서 만들어집니다. 다만 "분류 대비(고딕+명조)"가 주는 톤 변화는 가변 폰트만으로 만들 수 없습니다. 매거진·에세이처럼 톤 변화가 중요한 콘텐츠는 여전히 2종 페어링이 필요합니다.

Q5. 2026년 새로 주목할 한글 서체는 무엇인가요 일반적인 단정보다 검증된 흐름만 짚겠습니다. Pretendard 계열의 weight·자폭 확장, 산돌의 가변 폰트 라인업, 마루 부리의 단행본 활용이 꾸준히 이어지고 있습니다. 새 서체를 채택할 때는 출시 직후보다 6개월 이상 실무 사례가 쌓인 시점에 도입하는 것이 라이선스 안정성과 fallback 호환성 면에서 안전합니다.