폰트를 하나 내려받았는데 파일 크기가 13MB로 찍히면 손이 멈칫하게 됩니다.
글자 모양 하나 담은 파일이 사진 수십 장 분량이니 뭔가 잘못 받았나 싶어집니다.
윈도우에 이미 깔려 있는 폰트들을 직접 열어 재 봤습니다.
결론부터 말씀드리면 고장도, 잘못 받은 것도 아닙니다. 다만 "한글 폰트라서 크다"는 설명도 절반만 맞았습니다.

숫자부터 보겠습니다
폰트 파일 안에는 글자 하나하나의 모양이 글리프라는 이름으로 들어 있습니다.
쉽게 말해 글자별 그림 한 장씩입니다. 이 개수를 같이 놓고 보면 크기 차이가 단번에 설명됩니다.
| 폰트 | 파일 크기 | 글리프 수 | 한글 음절 | 라틴 문자 |
|---|---|---|---|---|
| 맑은 고딕 | 13,459,196 B | 28,215 | 11,172 | 215 |
| 나눔고딕 | 4,343,844 B | 20,138 | 11,172 | 191 |
| Arial | 1,045,720 B | 4,651 | 0 | 527 |
| Consolas | 453,088 B | 3,031 | 0 | 527 |
Arial은 알파벳을 오히려 더 많이(527자) 담고도 파일이 13배 작습니다.
담은 글자가 적어서가 아니라, 한글을 하나도 담지 않아서입니다.
한글은 글자마다 그림이 한 장씩 필요합니다
알파벳은 26자를 조합해 모든 단어를 만듭니다.
그래서 글리프도 대문자와 소문자, 기호를 합쳐 수백 개면 충분합니다.
한글은 사정이 다릅니다. 자음과 모음을 조합하는 글자인데도,
컴퓨터에 저장할 때는 가, 각, 갂... 처럼 완성된 음절 11,172자를 각각 별도의 글자로 취급합니다.
폰트 입장에서는 그림을 11,172장 그려 넣어야 한다는 뜻입니다.
정말 그것 때문인지 확인하려고, 맑은 고딕에서 글자를 덜어내며 다시 저장해 봤습니다.
윈도우 11에 깔려 있는 실제 폰트 파일을 파이썬 fontTools 4.63.0으로 열어 처리했습니다.
| 남긴 글자 | 파일 크기 | 원본 대비 |
|---|---|---|
| 원본 그대로 | 13,459,196 B | 100% |
| 한글 11,172자만 | 4,867,736 B | 36.2% |
| 자주 쓰는 한글 2,350자만 | 931,976 B | 6.9% |
| 라틴 215자만 | 35,508 B | 0.3% |
라틴 문자만 남기자 13MB짜리가 35KB로 내려앉았습니다. 원본의 0.3%입니다.
용량을 만드는 건 담은 글자 수라는 뜻입니다.
그런데 한글 폰트라고 다 13MB는 아닙니다
위 표의 아리따는 한글 11,172자를 맑은 고딕과 똑같이 담고 있습니다.
그런데 파일은 779,604바이트로 17배 넘게 작습니다.
차이는 두 군데서 옵니다.
첫째, 맑은 고딕은 글리프가 28,215개인데 아리따는 12,267개입니다.
맑은 고딕은 한글 말고도 한자와 각종 기호를 잔뜩 품고 있습니다.
둘째, 글자 모양을 저장하는 방식이 다릅니다.
파일 첫머리를 읽어 보면 두 폰트가 스스로를 다르게 소개합니다.
malgun.ttf sfnt 0x00010000 윤곽선 저장표: glyf
Arita4.0_M.otf sfnt 0x4f54544f 윤곽선 저장표: CFF
ttf는 glyf, otf는 CFF라는 방식으로 글자의 곡선을 기록합니다.
곡선을 그리는 계산법이 서로 달라서, 같은 모양이라도 저장에 드는 자리가 달라집니다.
그렇다면 글리프 수 차이를 걷어내면 어떨까요. 두 폰트를 똑같이 2,445자만 남겨 다시 저장해 봤습니다.
| 같은 2,445자만 남겼을 때 | 파일 크기 |
|---|---|
| 맑은 고딕 (ttf, glyf 방식) | 945,572 B |
| 아리따 (otf, CFF 방식) | 162,792 B |
조건을 맞춘 뒤에도 5.8배 차이가 남았습니다.
다만 이걸 "otf가 항상 작다"로 굳히면 지나칩니다.
두 폰트는 서체 자체가 다르고, 맑은 고딕에는 화면에서 글자가 또렷하게 보이도록 돕는 보정 정보가
여러 표에 걸쳐 들어 있는 반면 아리따에는 그런 표가 없습니다. 형식만의 차이로 잘라 말하기는 어렵습니다.
파일 하나에 서체가 네 개 들어 있기도 합니다
폰트 목록에는 굴림, 굴림체, 돋움, 돋움체가 따로 보이는데 파일은 gulim.ttc 하나뿐입니다.
확장자가 ttc인 파일은 여러 서체를 한 통에 담은 묶음이기 때문입니다.
안을 열어 확인해 보니 네 서체가 들어 있었고,
각 서체가 글자 모양을 보관한 위치를 찍어 보니 이렇게 나왔습니다.
gulim.ttc 13,533,424 B
서체 4개: Gulim, GulimChe, Dotum, DotumChe
각 서체의 글자 모양 저장 위치: [6986096, 6986096, 6986096, 6986096]
네 서체가 같은 자리를 가리키는가: True
네 서체가 같은 글자 그림을 함께 쓰고 있습니다.
굵기나 자간 같은 설정만 서체별로 다르게 두고 그림은 한 벌만 저장하니, 네 개가 13.5MB에 들어갑니다. 따로 담았다면 훨씬 커졌을 겁니다.
이 구조를 알면 실제로 겪는 일 하나가 풀립니다.
폰트 파일 하나를 지웠을 뿐인데 서체 목록에서 여러 개가 한꺼번에 사라지는 경우입니다.
한 통을 통째로 치웠으니 당연한 결과입니다. 겉보기엔 파일 하나인데 안에 여러 개가 들어 있는 구조는 엑셀 파일도 같습니다. 그 이야기는 따로 다룬 글이 있습니다.
그래서 어느 걸 받으면 되나
내려받는 화면에 ttf와 otf가 나란히 있으면 고민이 되실 텐데, 일상적인 용도에서는 둘 다 잘 됩니다. 상황별로 정리하면 이렇습니다.
| 상황 | 선택 |
|---|---|
| 문서 작업, 발표 자료 등 일반 사용 | 둘 다 무방, 파일이 작은 쪽 |
| 인쇄나 디자인 작업 | otf가 관행적으로 많이 쓰임 |
| 오래된 프로그램에서 써야 할 때 | ttf가 호환 폭이 넓은 편 |
| 웹사이트에 올릴 때 | 쓰는 글자만 추려서 woff2로 변환 |
마지막 줄은 실제로 해 봤습니다.
맑은 고딕을 2,445자로 추린 945,572바이트짜리를 웹폰트 형식인 woff2로 바꾸자 294,612바이트가 됐습니다.
원본 13MB에서 출발해 2%가 조금 넘는 수준까지 내려온 셈입니다.
웹에 올릴 때만은 원본을 그대로 쓰지 마세요. 쓰는 글자만 추리고 woff2로 바꾸는 두 단계로 용량이 수십 분의 일이 됩니다.
덧붙이면, 폰트 파일은 ZIP으로 묶으면 절반 정도로 줄어듭니다. 맑은 고딕이 55.5%, Arial이 54.4%였습니다.
사진이나 동영상처럼 이미 압축된 형식과 달리 아직 짜낼 여지가 남아 있다는 뜻이라,
여러 개를 주고받을 때는 묶어 보내는 편이 낫습니다.
형식별로 압축이 얼마나 먹는지는 ZIP과 7Z를 비교한 글에서 더 자세히 보실 수 있습니다.
위 크기와 글리프 수는 윈도우에 설치된 실제 폰트 파일을 파이썬 fontTools로 직접 열어 세어 본 값이며, 서브셋 결과는 같은 폰트에서 글자를 덜어내 다시 저장해 얻었습니다.
글자 수가 용량을 정한다면 줄이는 방법도 거기서 나옵니다. 포장 방식을 바꿔 더 줄이는 쪽은 WOFF 와 WOFF2 를 비교한 글에, 받은 폰트가 한글을 담고 있는지 미리 보는 방법은 설치 전에 확인하는 글에 있습니다.
'폰트' 카테고리의 다른 글
| 이 폰트, PDF에 끼워 넣어 남에게 보내도 될까요? 코드로 확인하는 법 (0) | 2026.09.03 |
|---|---|
| 같은 폰트를 WOFF와 WOFF2로 각각 바꿔봤더니, 압축 방식 차이가 이만큼 났습니다 (0) | 2026.08.31 |
| 내려받은 폰트가 한글을 지원하는지, 설치하기 전에 코드로 확인하는 법 (0) | 2026.08.29 |
| 폰트를 설치했는데 프로그램 목록에 안 보일 때, 원인을 구분하는 법 (1) | 2026.08.28 |
| 가변 폰트(Variable Font)란, 파일 하나로 굵기가 바뀌는 원리를 열어서 확인했습니다 (0) | 2026.08.24 |