

타이포그래피를 고를 때 많은 사람이 먼저 글자의 분위기를 봅니다. 둥근지, 딱딱한지, 세리프가 있는지, 숫자가 예쁜지 같은 것들입니다. 물론 이것도 중요합니다. 하지만 실제 제품 화면에서는 글자의 인상보다 먼저 문제를 만드는 요소가 따로 있습니다. 바로 글자가 어떤 기준선 위에 서 있고, 어디까지 올라가고, 어디까지 내려가는지입니다.
같은 16px 폰트라도 어떤 서체는 크게 보이고, 어떤 서체는 작게 보입니다. 버튼 안에서는 괜찮아 보였던 텍스트가 입력창에서는 위로 떠 보이기도 하고, 영어와 한글이 섞이면 줄 간격이 갑자기 답답해지기도 합니다. 이 문제는 대개 폰트 크기 하나로 해결되지 않습니다. 글자의 구조를 알아야 원인을 볼 수 있습니다.
글자는 박스 안에만 있지 않습니다
CSS에서 텍스트를 다룰 때는 font-size, line-height, letter-spacing 같은 값을 주로 만집니다. 그래서 글자도 정해진 사각형 안에 깔끔하게 들어간다고 생각하기 쉽습니다. 하지만 서체는 그렇게 단순하지 않습니다.
서체에는 글자가 놓이는 기준선이 있고, 소문자가 주로 차지하는 높이가 있으며, 대문자가 올라가는 높이와 일부 소문자가 더 올라가거나 내려가는 영역이 있습니다. 이 구조를 모르면 line-height: 1.5를 줬는데도 왜 어떤 서체는 느슨하고 어떤 서체는 꽉 차 보이는지 설명하기 어렵습니다.
디자인 시스템에서 타이포그래피 토큰을 만들 때도 마찬가지입니다.
:root {
--text-body-size: 16px;
--text-body-line-height: 24px;
}
이 값만 보면 충분히 명확해 보입니다. 하지만 실제로는 어떤 서체를 쓰는지, 그 서체의 x-height가 얼마나 큰지, 디센더가 얼마나 내려가는지에 따라 같은 토큰이 전혀 다르게 보일 수 있습니다. 타이포그래피 해부학은 이 차이를 설명하기 위한 기본 언어입니다.
기준선: 베이스라인
베이스라인(baseline)은 글자가 서 있는 기준선입니다. 라틴 알파벳 기준으로 x, n, o 같은 글자는 베이스라인 위에 놓이고, p, g, y 같은 글자는 일부가 베이스라인 아래로 내려갑니다.
UI에서 베이스라인은 생각보다 자주 문제를 만듭니다. 예를 들어 아이콘과 텍스트를 가로로 정렬할 때 align-items: center만 사용하면 시각적으로 가운데가 맞지 않을 때가 있습니다. 아이콘은 실제 박스의 중심을 기준으로 보이지만, 텍스트는 베이스라인과 글자 내부 공간의 영향을 받기 때문입니다.
그래서 텍스트 정렬은 수학적 중앙과 시각적 중앙을 구분해서 봐야 합니다. 특히 버튼, 탭, 배지처럼 높이가 작은 컴포넌트에서는 1px 정도의 차이도 어색하게 느껴집니다.
.button {
display: inline-flex;
align-items: center;
min-height: 40px;
padding-inline: 16px;
font-size: 14px;
line-height: 20px;
}
이 코드는 틀리지 않습니다. 다만 서체를 바꾸면 텍스트가 살짝 위나 아래로 치우쳐 보일 수 있습니다. 이때 무작정 padding-top을 더하는 것보다, 먼저 베이스라인과 line-height의 관계를 확인해야 합니다.
x-height: 같은 크기인데 다르게 보이는 이유
x-height는 소문자 x의 높이를 기준으로 설명하는 영역입니다. 실제 제품에서는 이 값이 체감 크기에 큰 영향을 줍니다. x-height가 큰 서체는 같은 font-size에서도 더 크게, 더 또렷하게 보입니다. 반대로 x-height가 작은 서체는 여백이 많고 우아하게 보일 수 있지만 작은 화면에서는 약하게 보일 수 있습니다.
이 차이는 본문 서체를 고를 때 특히 중요합니다. 본문은 긴 시간 읽혀야 하므로 단순히 예쁜 서체보다 작은 크기에서도 안정적으로 읽히는 서체가 필요합니다. 같은 16px이라도 x-height가 충분한 서체는 모바일 화면에서 더 버티기 쉽습니다.
하지만 x-height가 크다고 항상 좋은 것은 아닙니다. x-height가 지나치게 크면 글자 사이의 위아래 리듬이 단조로워지고, 어센더와 디센더가 짧아져 글자의 개별 형태가 덜 구분될 수 있습니다. 즉, 본문에서는 가독성에 유리할 수 있지만 브랜드용 큰 제목에서는 개성이 약해 보일 수도 있습니다.
캡 하이트: 대문자와 UI 라벨의 기준
캡 하이트(cap height)는 대문자의 높이를 말합니다. H, I, T 같은 대문자가 어디까지 올라가는지 보는 기준입니다.
캡 하이트는 영문 라벨, 버튼 텍스트, 약어가 많은 UI에서 중요합니다. 예를 들어 API, HTTP, URL 같은 대문자 약어는 본문 속에서 생각보다 크게 튀어 보일 수 있습니다. 한글 본문 안에 영문 대문자가 섞이면 이 차이가 더 눈에 띕니다.
디자인 시스템에서 라벨 스타일을 만들 때는 본문과 같은 크기를 그대로 쓰기보다 캡 하이트와 자간을 함께 봐야 합니다.
.eyebrow {
font-size: 12px;
line-height: 16px;
letter-spacing: 0.04em;
text-transform: uppercase;
}
대문자 라벨에 약간의 자간을 주는 방식은 흔하지만, 모든 상황에 자동으로 맞는 규칙은 아닙니다. 한글, 숫자, 영문 약어가 섞이는 서비스라면 실제 데이터로 확인해야 합니다.
어센더와 디센더: 줄 간격을 흔드는 부분
어센더(ascender)는 소문자에서 x-height 위로 올라가는 부분입니다. b, d, h, l 같은 글자에서 확인할 수 있습니다. 디센더(descender)는 베이스라인 아래로 내려가는 부분입니다. g, p, q, y 같은 글자가 대표적입니다.
이 둘은 줄 간격과 텍스트 박스의 안정성에 직접 영향을 줍니다. 디센더가 긴 서체를 좁은 line-height로 쓰면 아래 줄과 가까워져 답답해 보입니다. 반대로 어센더와 디센더가 짧은 서체는 같은 line-height에서도 더 넉넉하게 보일 수 있습니다.
문제는 제품 텍스트가 항상 예쁜 예문으로만 나오지 않는다는 점입니다. 이름, 이메일, 코드, 가격, 다국어 문장, 사용자 입력값은 어떤 글자 조합으로 들어올지 알 수 없습니다. 타이포그래피를 검수할 때 가나다라마바사나 ABCDEF만 넣어보면 이런 문제를 놓치기 쉽습니다.
최소한 다음처럼 위아래로 튀는 글자가 섞인 샘플을 함께 봐야 합니다.
Hamburgefonts
Typography, glyph, baseline
김영규 Typography 123
gypqj bdhlft API URL
이런 문장을 넣었을 때 버튼 높이, 입력창 높이, 카드 제목 줄바꿈, 리스트 행 높이가 안정적인지 확인하는 것이 좋습니다.
디자인 시스템에서는 무엇을 봐야 할까
타이포그래피 해부학을 안다는 것은 용어를 외우는 일이 아닙니다. 실제로는 서체를 바꾸거나 토큰을 만들 때 무엇을 검수해야 하는지 아는 일에 가깝습니다.
첫 번째로, 본문 크기를 정할 때 x-height를 같이 봐야 합니다. 기존 서체보다 x-height가 큰 서체로 바꾸면 같은 font-size에서도 화면 밀도가 올라갑니다. 반대로 x-height가 작은 서체로 바꾸면 전체 UI가 갑자기 작고 헐거워 보일 수 있습니다.
두 번째로, line-height는 숫자만 보지 말고 실제 글자 조합으로 확인해야 합니다. 특히 두 줄 이상의 본문, 카드 제목, 테이블 셀, 모바일 리스트에서는 디센더와 어센더가 줄 사이를 얼마나 차지하는지 봐야 합니다.
세 번째로, 아이콘과 텍스트가 함께 있는 컴포넌트는 베이스라인 기준으로 다시 확인해야 합니다. 가운데 정렬이 되어 있어도 시각적으로 어긋나 보이면 사용자는 그것을 버그처럼 느납니다.
네 번째로, 한글과 영문이 섞이는 제품이라면 영문 기준의 해부학만으로 판단하면 부족합니다. 한글은 라틴 소문자의 어센더, 디센더 구조와 다르게 보이므로 실제 서비스 문장에 가까운 샘플을 사용해야 합니다.
피해야 할 접근
가장 피해야 할 방식은 서체를 바꾼 뒤 font-size만 조금 조정해서 끝내는 것입니다. 겉보기 크기는 비슷하게 맞출 수 있어도 줄 간격, 컴포넌트 높이, 아이콘 정렬, 테이블 밀도는 그대로 틀어질 수 있습니다.
두 번째로 위험한 방식은 디자인 툴의 한 화면만 보고 확정하는 것입니다. 디자인 툴에서는 텍스트가 정돈된 예문으로 들어가지만, 실제 제품에서는 긴 이름, 한 줄짜리 오류 메시지, 숫자와 단위, 다국어 문장이 들어옵니다. 서체 검수는 반드시 실제 데이터에 가까운 문장으로 해야 합니다.
세 번째로는 line-height: normal에 기대는 방식입니다. 브라우저와 서체의 메트릭에 맡기면 빠르게 시작할 수는 있지만, 디자인 시스템 관점에서는 재현 가능한 리듬을 만들기 어렵습니다. 본문, 제목, 라벨, 캡션처럼 역할별 line-height를 명시하는 편이 관리하기 쉽습니다.
바로 적용할 체크리스트
새 서체를 검토하거나 타이포그래피 토큰을 만들 때는 다음 항목을 확인하면 좋습니다.
- 같은
font-size에서 기존 서체보다 커 보이는지, 작아 보이는지 확인합니다. - 본문, 제목, 버튼, 입력창, 테이블 셀에 같은 문장 샘플을 넣어봅니다.
g,p,y,j처럼 아래로 내려가는 글자가 줄 간격을 침범하지 않는지 봅니다.b,d,h,l처럼 위로 올라가는 글자가 헤딩과 라벨에서 답답하지 않은지 봅니다.- 영문 대문자 약어와 한글이 섞일 때 라벨이 튀어 보이지 않는지 확인합니다.
- 아이콘과 텍스트가 함께 있을 때 시각적 중앙이 맞는지 확인합니다.
정리
타이포그래피 해부학은 디자이너만을 위한 장식적인 지식이 아닙니다. 제품 화면에서 글자가 왜 떠 보이는지, 왜 같은 크기인데 다르게 느껴지는지, 왜 줄 간격이 갑자기 답답해지는지 설명해 주는 실무 언어입니다.
서체를 고를 때 분위기만 보면 문제를 늦게 발견합니다. 베이스라인, x-height, 캡 하이트, 어센더, 디센더를 함께 보면 서체가 실제 UI 안에서 어떻게 버틸지 더 빨리 판단할 수 있습니다. 좋은 타이포그래피는 예쁜 글자를 고르는 일에서 끝나지 않고, 예측 가능한 기준선을 만드는 일까지 포함합니다.
참고
Read more

DMARC, 이메일 도메인을 피싱에서 지키는 최소한의 정책
SPF와 DKIM만으로 부족한 이유, DMARC가 인증 실패 메일을 어떻게 처리하고 보고서를 통해 운영 상태를 보여주는지 정리합니다.

EKS IRSA, Pod에 AWS 권한을 나눠주는 현실적인 방법
EKS에서 IRSA가 어떤 보안 문제를 해결하는지, OIDC와 ServiceAccount를 통해 Pod 단위 IAM 권한이 연결되는 방식을 정리합니다.

LSP는 에디터와 언어의 M×N 문제를 어떻게 줄였나
Language Server Protocol이 왜 등장했는지, 에디터와 언어 서버가 어떤 방식으로 통신하는지, 개발 도구와 AI 도구에서 왜 중요한지 정리합니다.