텍스트 토큰 구조 정의

Figma variables로 텍스트 토큰화하기

소프트웨어와 웹을 동시에 운영하다 보면 어느 순간 이런 일이 자연스럽게 발생합니다. 같은 역할의 텍스트인데도 제품마다 크기가 다르고 어떤 곳은 얇고, 어떤 곳은 두껍습니다. 처음에는 큰 문제가 아닌 것처럼 보입니다. 하지만 시간이 지날수록 점점 더 많은 비용을 만들어냅니다.

디자인 시스템을 수정할 때 어디까지 영향이 가는지 알기 어렵고 검수에 시간이 많이 들며 디자이너와 개발자가 서로 다른 기준을 이해하게 됩니다. 이 글에서는 이런 문제를 줄이기 위해 정리한 타이포그래피 토큰 구조 설계 방식을 공유하려고 합니다.

---

왜 소프트웨어와 웹을 따로 관리하고 있을까 생각해보면 조금 이상한 일입니다. 소프트웨어와 웹은 서로 다른 플랫폼이지만 대부분의 경우 같은 환경에서 사용됩니다. 바로 데스크톱입니다.

그럼에도 불구하고 우리는 서로 다른 타이포그래피 기준을 사용해왔습니다. 두 가지 문제가 계속 반복됩니다. 가이드를 따로 관리해야 하는 것과 커뮤니케이션 비용이 계속 증가합니다.

기존 타이포그래피는 보통 이런 식으로 관리됩니다.

caption-medium

body-small

body-medium

heading-small

처음에는 직관적이고 편합니다.

하지만 시간이 지나면 구조가 무너지기 시작합니다.

font-size 수정 시 각각 스타일 변경

line-height 전체 조정이 어려움

weight 관리가 중복

결국 스타일이 늘어날수록 관리 포인트도 함께 증가합니다. 이 문제를 해결하기 위해 타이포그래피를 3단계로 분리했습니다. 각 단계는 역할이 명확하게 다릅니다.

1. Primitive 값만 정의하는 단계

Primitive는 의미를 가지지 않는 순수 값 단위입니다. 여기에서는 타이포그래피를 구성하는 기본 값만 정의합니다. Primitive의 중요한 특징은 UI에 직접 사용되지 않는다는 것입니다.

font-size

line-height

font-weight

2. Semantic 역할을 정의하는 단계

Semantic Token은 Primitive 값을 조합하여 텍스트의 역할과 위계를 정의합니다. 역할은 크게 세 가지로 구분했습니다.

Caption

Body

Heading

Semantic Token의 중요한 특징은 다음과 같습니다.새로운 값을 만들지 않고 Primitive 값을 조합해 역할을 정의합니다. 즉, 값이 아니라 역할을 정의하는 단계입니다.

3. Text Style 실제 UI에 쓰는 단계

마지막 단계는 Text Style입니다. 이 단계에서는 Semantic Token이 정의한 역할을 실제 UI 스타일로 사용합니다. 여기서 중요한 원칙 하나가 있습니다. Bold는 Semantic Token에 포함하지 않습니다.

Bold는 의미 강조를 위한 표현이기 때문에 Semantic 단계가 아니라 Style 단계에서만 관리합니다.

이렇게 구조를 나누면 생각보다 많은 문제가 자연스럽게 해결됩니다.

font-size를 수정해도 영향 범위가 명확해지고 line-height를 일괄 조정할 수 있으며 weight 중복이 사라집니다. 그리고 무엇보다 중요한 변화는 하나입니다.

타이포그래피를 잘 만든다는 것은 단순히 보기 좋은 폰트를 쓰는 것이 아닙니다.

어떻게 구조를 나누고 어떻게 관리할 것인지에 대한 문제입니다.

소프트웨어와 웹을 따로 관리하는 대신 하나의 기준으로 묶고 차이는 규칙으로 해결하는 방식.

이 구조는 디자인 시스템을 더 오래 더 안정적으로 유지할 수 있게 만들어줍니다.