데이터가 많은 화면의 타이포그래피: 폰트 크기보다 역할을 먼저 정하라

데이터가 많은 화면의 타이포그래피는 12px·14px·16px 같은 숫자표에서 시작하지 않는다. 먼저 각 문장이 사용자의 어떤 판단을 돕는지 역할을 정해야 한다. 역할은 유지하되 실제 크기와 무게를 연결하는 token은 기기·밀도·읽기 조건에 맞게 조정한다.

이 글이 답할 질문은 하나다. 숫자와 라벨이 많은 업무 화면에서 텍스트 역할을 어떻게 위계화할 것인가?

폰트 크기보다 먼저 텍스트의 역할을 나눈다

역할의 수를 늘리는 것이 목적은 아니다. 화면의 핵심 질문에 필요하지 않은 역할은 제거한다. 반대로 값만 크게 만들고 비교 기준과 갱신 시각을 떼어 놓으면 숫자는 눈에 띄지만 판단에는 불완전하다.

업무 화면에서 같은 14px 텍스트라도 역할은 전혀 다를 수 있다. “SLA 경계 접근”은 판단이고, “27건”은 현재 값이며, “관리 기준 10건 대비 +17건”은 비교다. “09:10 갱신”은 값의 유효 범위를 설명하는 Context다. 이들을 같은 굵기와 간격으로 나열하면 사용자는 읽으면서 관계를 다시 조립해야 한다.

역할	답하는 질문	가상 고객지원 화면의 문구
Decision	지금 무엇을 판단해야 하는가?	SLA 경계 접근 · 조치 필요
Primary metric	현재 상태는 얼마인가?	30분 내 응답 필요 27건
Comparison	기준과 얼마나 다른가?	관리 기준 10건 대비 +17건
Evidence	어디에 일이 집중됐는가?	결제 문의 12건 · 최장 대기 3시간 52분
Context	언제·어떤 범위의 값인가?	9월 28일 전체 지원 Queue · 09:10 갱신

가상 사례: 같은 데이터인데 읽는 순서가 다른 두 화면

아래는 실제 고객 데이터가 아닌 가상 고객지원 운영 화면이다. 가상 운영 규칙은 접수 후 4시간 이내 1차 응답이며, 남은 시간이 30분 이하인 문의를 “응답 필요”로 분류한다. 09:10 기준 해당 문의는 27건이고, 내부 관리 기준 10건보다 17건 많다. 그중 결제 문의는 12건이며 최장 대기는 3시간 52분이다. 이 규칙과 숫자는 typography 비교를 위한 예시이며 실제 조직의 SLA나 성과가 아니다.

오른쪽 안에서는 “30분 내 응답 필요”와 27건을 하나의 Primary statement로 묶었다. “SLA 경계 접근 · 조치 필요”를 그 위에 두고, 관리 기준과의 차이는 바로 아래에 연결했다. 크기 하나만으로 위계를 만들지 않고 위치, 굵기, 색, 간격을 함께 사용해 큰 숫자가 독립적인 장식이 되지 않게 했다.

선택의 대가도 있다. 27건의 비중을 키우면서 화면이 차지하는 세로 공간은 늘었다. 여러 Queue의 수치를 한 번에 비교해야 하는 표 안에서는 이 크기를 반복하지 않는다. 이 도해는 하나의 이상 상태를 파악하는 요약 영역이므로 큰 Primary metric을 선택했다.

Type scale은 역할을 담는 제한된 어휘여야 한다

Microsoft Fluent 2 Typography는 Type ramp에 크기만이 아니라 semantic role과 weight·line-height를 함께 정의한다. IBM Carbon Typography도 product 공간의 밀도 높은 productive type과 editorial·marketing의 expressive type을 구분한다. 여기서 RUDA가 도출한 원칙은 특정 픽셀 값을 복사하는 일이 아니라, 역할과 사용 환경을 먼저 고정한 뒤 제한된 token으로 반복한다는 방식이다.

따라서 “우리 대시보드는 12·14·16·24·32px을 쓴다”만으로는 시스템이 완성되지 않는다. 어떤 역할이 14px인지, 같은 14px에서 Regular와 Semibold가 왜 나뉘는지, 숫자와 단위의 관계가 무엇인지가 정의되어야 한다. 이번 도해도 사이트 테마의 Small·Medium·X-Large token을 재사용했다. 화면마다 임의의 크기를 새로 만들지 않았다.

역할 token	권장 표현	피해야 할 사용
Decision	짧은 문장, 상단 배치, 필요한 경우 Semibold	모든 상태를 대문자·강조색으로 표시
Primary metric	가장 큰 크기, 짧은 숫자, 단위와 결합	관련 없는 KPI마다 같은 큰 크기 반복
Comparison	기준·차이·방향을 한 덩어리로 표시	색만으로 증가·감소 전달
Evidence	비교 가능한 행과 열, 일관된 정렬	각 행을 서로 다른 크기의 카드로 변환
Context	낮은 위계지만 값 가까이에 유지	갱신 시각·범위를 화면 하단에 숨김

황금비율을 Type scale에 기계적으로 적용하지 않는 이유

1:1.618은 주종 관계를 크게 벌릴 때 유용한 검토 기준이지만, 데이터 화면의 모든 단계에 반복 적용하면 값·기준·단위가 서로 멀어질 수 있다. 특히 표와 필터처럼 다수 항목을 같은 기준으로 비교하는 영역에서는 큰 단계 차이보다 baseline, 열 정렬, 반복되는 role의 일관성이 중요하다.

이번 사례는 Primary metric 한 곳에만 큰 점프를 허용하고, 나머지는 기존 theme token 안에서 가까운 단계로 묶었다. 비례의 아름다움보다 “27건이 무엇이며 어떤 기준에서 위험한가”를 한 시선 안에서 읽는 것이 우선이기 때문이다.

글자 크기만 바꾸면 해결되지 않는 세 가지

1. 숫자와 단위: 27과 “건”을 지나치게 분리하면 하나의 값이 두 요소처럼 보인다. 단위의 크기를 줄이더라도 baseline과 간격으로 결합을 유지한다.
2. 값과 기준: 27건만 크게 두고 관리 기준 10건을 멀리 보내면 사용자가 차이를 다시 계산한다. 이 사례에서는 +17건을 함께 표시해 비교를 완성했다.
3. 값과 Context: 갱신 시각·기간·필터 범위는 낮은 위계여도 값 가까이에 있어야 한다. 오래된 값인지 다른 범위의 값인지 모르면 큰 숫자는 오히려 강한 오해를 만든다.

색은 보조 수단이다. Microsoft Fluent는 색이 텍스트의 prominence를 바꿀 수 있다고 설명하지만, 가독성과 contrast를 함께 확인하도록 안내한다. 기준 초과를 색으로만 표시하지 않고 +17건과 “관리 기준 대비” 문구를 남긴 이유다.

이 방식이 맞지 않는 화면도 있다

• 관제용 대형 화면: 먼 거리에서 한두 개의 상태를 읽는다면 더 큰 display type과 강한 대비가 필요하다. 대신 세부 표는 별도 화면으로 분리한다.
• 행 간 비교가 핵심인 표: 특정 숫자 하나를 크게 만들면 열 정렬이 깨진다. 행과 열의 동일한 typography를 유지하고 정렬·단위·강조 규칙으로 차이를 보여준다.
• 동등한 선택지 비교: 한 항목에만 큰 제목을 주면 추천처럼 읽힐 수 있다. 동등한 옵션은 같은 role과 같은 무게를 유지한다.
• 긴 한글·다국어·텍스트 확대: 한 줄 고정 때문에 글자를 줄이지 않는다. 줄바꿈 뒤에도 역할 관계가 유지되도록 영역과 순서를 재배치한다.

개발 전에 남길 Typography role map

화면마다 폰트 크기를 지정하기 전에 아래 다섯 항목을 한 줄씩 정의하면 된다.

1. 사용자가 가장 먼저 내려야 할 판단은 무엇인가?
2. 그 판단을 대표하는 Primary metric은 하나인가, 동등한 비교 집합인가?
3. 값과 함께 읽혀야 하는 기준·단위·기간·갱신 시각은 무엇인가?
4. 표·상세·모바일에서도 같은 role 이름과 token을 재사용할 수 있는가?
5. 긴 라벨, 200% 텍스트 확대, 좁은 폭에서도 정보 관계가 남는가?

결론은 간단하다. 폰트 크기를 먼저 고르면 화면마다 예외가 늘어나고, 역할을 먼저 고르면 Type scale이 시스템이 된다. 큰 숫자를 만드는 것이 아니라 판단·값·비교·근거·Context의 서열을 반복 가능하게 만드는 것이 데이터 화면 타이포그래피의 핵심이다.

전체 화면의 정보 순서를 정하려면 대시보드는 카드의 집합이 아니다를, 좁은 화면에서 우선순위와 상세 이동을 설계하려면 모바일 대시보드 설계를 함께 볼 수 있다. 상태·선택·데이터 계열의 색 역할은 대시보드 색상 설계에서 이어진다.

근거와 범위

외부 근거는 Microsoft Fluent 2 Typography, IBM Carbon Typography, W3C의 Resize Text 설명을 2026년 9월 28일 확인했다. semantic role, Type ramp, product용 typography 체계와 텍스트 확대 검수 기준에 대한 공식 설명을 참고했다. 역할표·가상 고객지원 데이터·비교 도해·적용 판단은 RUDA DIRECTOR의 공개용 편집 synthesis다. 정적 도해이며 실제 제품 성과나 사용자 시험 결과를 주장하지 않는다.