6장. 변수와 모드 — 라이트/다크, 다국어, 브랜드 분기

화면 수보다 분기 수가 더 중요하다

디자인 시스템이 커질수록 사람들은 보통 화면 개수부터 센다. 로그인 12개, 결제 18개, 설정 9개. 그런데 실제로 제품을 복잡하게 만드는 것은 화면 수보다 분기 수다. 같은 결제 화면이라도 라이트와 다크가 있고, 한국어와 영어가 있고, 기본 브랜드와 파트너 브랜드가 있으면 이미 한 장의 화면 안에 여러 맥락이 겹쳐 있다.

예전에는 이 분기를 프레임 복제로 버텼다. Checkout / Light / KO, Checkout / Dark / EN, Checkout / BrandB / KO 같은 이름의 프레임이 끝없이 늘어났다. 처음엔 정리된 것처럼 보이지만, 어느 날 버튼 반경을 8에서 10으로 바꾸는 순간 재난이 시작된다. 어디를 바꿨고, 어디를 빼먹었는지 확인하는 데 반나절이 날아간다.

변수와 모드는 이 문제를 반대로 푼다. 화면을 늘리지 않고 문맥을 바꾼다. 같은 컴포넌트, 같은 화면 구조를 유지한 채 값만 바꿔서 다른 조건을 검증하는 방식이다. 피그마의 모드는 바로 이 "같은 구조, 다른 문맥"을 다루기 위한 장치다.¹

이 장에서 기억해야 할 문장은 단순하다.

확장 가능한 제품은 화면 수보다 분기 수를 다루는 구조에서 결정된다.

모드는 같은 이름으로 다른 상황을 다루는 방법이다

모드를 가장 쉽게 이해하는 방법은 서랍장을 떠올리는 것이다. 변수 컬렉션이 서랍장이라면, 모드는 그 안의 칸이다. color/text/primary라는 같은 이름의 변수가 있어도, Light 칸에서는 진한 회색이고 Dark 칸에서는 밝은 회색일 수 있다. 이름은 같고, 문맥에 따라 값만 달라진다.¹

피그마에서 중요한 점은 모드가 단순히 "테마 바꾸기 버튼"이 아니라는 것이다. 모드는 페이지, 프레임, 섹션, 컴포넌트, 레이어에 적용할 수 있다. 그래서 전체 페이지를 다크로 돌려볼 수도 있고, 같은 화면 안에서 왼쪽 카드만 Brand A, 오른쪽 카드는 Brand B로 비교할 수도 있다.¹

여기서 초보자가 가장 자주 헷갈리는 것이 Auto와 명시적 모드다. 부모 프레임이 Dark 모드인데 내부 버튼이 따라오지 않는다면, 대개 버튼이나 텍스트 레이어가 개별적으로 다른 모드에 고정되어 있기 때문이다. 내부 레이어는 가능하면 Auto 상태로 두고, 프레임이나 페이지에서 문맥을 바꾸는 편이 안정적이다. 그래야 부모가 바뀔 때 자식도 자연스럽게 따라온다.¹

한마디로 정리하면 이렇다. 모드는 복제의 대체재가 아니라, 문맥 전환의 기본 단위다.

분기를 한 컬렉션에 몰아넣으면 반드시 폭발한다

변수와 모드를 쓰기 시작하면 누구나 한 번쯤 이런 유혹을 느낀다. "그냥 한 컬렉션에서 다 처리하면 되지 않을까?"

예를 들어 Light, Dark, KO, EN, Brand A, Brand B를 모두 한 컬렉션 안에 모드로 넣어 버리면 처음엔 간단해 보인다. 하지만 곧 문제가 생긴다. 라이트/다크 2개, 언어 3개, 브랜드 2개만 있어도 조합은 12개다. 여기에 고대비 모드 하나, 일본어 하나만 추가해도 머리가 아파진다.

좋은 구조는 분기를 축으로 나눈다. 보통은 다음처럼 나누는 편이 가장 다루기 쉽다.

• Theme 컬렉션: Light, Dark, High Contrast

• Language 컬렉션: ko, en, ja, ar

• Brand 컬렉션: Core, Partner, White-label

• Layout 또는 Density 컬렉션: Compact, Cozy 같은 추가 문맥이 필요할 때만

이렇게 나누면 하나의 프레임에서 Theme는 Dark, Language는 en, Brand는 Partner로 각각 독립적으로 바꿔 볼 수 있다. 조합은 많아져도 관리 포인트는 늘어나지 않는다. 피그마가 컬렉션별로 모드를 적용할 수 있게 설계된 이유도 바로 여기에 있다.¹

즉, 모드는 많아져도 괜찮다. 축이 섞이는 것이 위험하다.

라이트와 다크는 색상 전환이 아니라 의미 전환이다

라이트/다크를 처음 만들 때 가장 흔한 실수는 색상 자체를 기준으로 생각하는 것이다. "이 흰색은 검은색으로, 이 회색은 더 밝은 회색으로." 이렇게 접근하면 한두 화면은 빨리 되지만 시스템이 커질수록 수정이 어려워진다.

더 좋은 방법은 역할 기준으로 바꾸는 것이다. 예를 들어 컴포넌트에 직접 gray/900을 바르지 않고, color/text/primary, color/bg/surface, color/border/default, color/action/primary 같은 의미 토큰을 연결해 둔다. 그러면 Light 모드에서는 color/text/primary가 짙은 텍스트를 가리키고, Dark 모드에서는 밝은 텍스트를 가리키면 된다.¹

이 방식의 장점은 간단하다. 화면을 다시 그리지 않아도 된다. 한 번 구조를 잡아 두면 프레임 모드만 바꿔도 전체 UI가 다른 조명 아래로 들어간 것처럼 전환된다. 다크 모드 미리보기를 위해 화면을 복제하는 대신, 같은 프레임을 두 개 두고 하나는 Light, 하나는 Dark로 지정해 비교하는 것도 가능하다.

여기서 꼭 기억할 점이 하나 있다. 다크 모드는 "색 반전"이 아니다. 대비와 역할의 재설계다. 라이트에서 잘 보이던 버튼 배경과 텍스트 조합이 다크에서는 갑자기 답답해질 수 있다. 그럴 때는 화면을 다시 그리는 것이 아니라 해당 의미 토큰의 Dark 값을 조정하면 된다. 구조가 좋으면 수정은 국소적이고, 효과는 전역적이다.

그리고 접근성 측면에서도 이 구조는 유리하다. 다크를 추가한 뒤 고대비 모드까지 필요해져도 새로운 프레임 세트를 만들 필요 없이 모드 하나를 더 추가하면 된다.¹

다국어는 문자열 바꾸기가 아니라 레이아웃 검증이다

다국어 지원을 생각할 때 많은 팀이 번역을 나중 일로 미룬다. 영어 디자인을 끝내고, 개발이 거의 끝난 다음에 번역을 넣는다. 그러면 꼭 독일어가 버튼 밖으로 넘치고, 핀란드어가 탭을 깨고, 아랍어가 정렬을 뒤집어 놓는다. 이 비용은 대부분 디자인 단계에서 미리 발견할 수 있었던 문제다.³

피그마의 문자열 변수와 모드는 여기서 아주 강력하다. 언어 전용 컬렉션을 하나 만들고, auth/login/title, auth/login/cta, cart/empty/message 같은 문자열 변수를 등록한다. 그리고 ko, en, ja 같은 모드를 만들면 같은 화면 구조에서 언어만 순식간에 바꿔 볼 수 있다.²

이 기능의 핵심은 번역 자동화가 아니다. 레이아웃 검증이다. 영어에서는 한 줄이던 문장이 한국어에서는 두 줄이 되고, 일본어에서는 버튼 폭이 달라지고, 독일어에서는 카드 제목이 길어질 수 있다. 이런 변화를 디자인 파일 안에서 먼저 보면 개발 전에 수정할 수 있다.³

그래서 다국어 파일은 예쁘게 만드는 것보다 잘 무너지게 만드는 편이 더 중요하다. 일부러 긴 언어를 넣어 보고, 짧은 언어를 넣어 보고, 숫자와 단위가 길어지는 상황도 확인해야 한다. 이때 자동 레이아웃이 받쳐 주지 않으면 문자열 변수는 그냥 고통 증폭기다. 텍스트 박스를 고정 폭으로 잠가 두고 언어만 바꾸면 문제를 찾는 것이 아니라 문제를 양산하게 된다.

다국어에서 특히 유용한 체크 포인트는 세 가지다.

• 텍스트가 길어질 때 버튼, 칩, 탭이 자연스럽게 늘어나는가

• 줄바꿈이 생겨도 카드 높이와 리스트 간격이 무너지지 않는가

• 사용 중인 폰트가 목표 언어의 문자셋을 충분히 지원하는가

RTL 언어도 같은 맥락에서 봐야 한다. 문자열 변수는 복사본을 바꿔 주지만, 레이아웃 방향까지 자동으로 해결해 주지는 않는다. 오른쪽 정렬, 아이콘 위치, 화살표 방향, 시작과 끝의 개념은 컴포넌트 구조와 오토 레이아웃이 함께 준비되어 있어야 한다.³

정리하면, 다국어 모드는 번역팀을 위한 기능이기 전에 레이아웃을 솔직하게 드러내는 테스트 장치다.

브랜드 분기는 파일을 늘리는 일이 아니라 값을 갈아끼우는 일이다

멀티브랜드나 화이트라벨 제품을 만드는 팀은 오랫동안 "브랜드별 파일 분리"를 당연하게 여겼다. Brand A 파일, Brand B 파일, 파트너 전용 파일. 하지만 이 방식은 구조를 공유하지 못한다. 버튼 컴포넌트를 개선하면 모든 브랜드 파일에 같은 수정을 반복해야 한다.

모드 기반 운영은 접근이 다르다. 구조는 하나로 유지하고, 브랜드마다 달라지는 값만 분리한다. 예를 들어 Brand 컬렉션에서 다음 같은 변수를 운영할 수 있다.

• brand/color/primary

• brand/color/secondary

• brand/radius/control

• brand/font/display

• brand/name/product

그리고 Core, Partner, White-label 같은 모드를 둔다. 그러면 같은 버튼 컴포넌트라도 브랜드 모드에 따라 주 색상, 반경, 제목 폰트 인상이 달라질 수 있다.⁴

여기서 중요한 원칙은 테마와 브랜드를 같은 문제로 보지 않는 것이다. 다크/라이트는 사용 환경의 문맥이고, 브랜드는 사업적 정체성의 문맥이다. 이 둘을 한 컬렉션에 섞어 Brand A Dark, Brand B Light처럼 만들기 시작하면 곧바로 조합 지옥이 열린다. 보통은 Theme 컬렉션과 Brand 컬렉션을 분리하고, 컴포넌트가 두 컬렉션의 값을 함께 읽도록 설계하는 편이 훨씬 유연하다.⁴

예를 들어 이런 식이다. 버튼의 텍스트 대비와 표면 색은 Theme 컬렉션이 담당하고, 브랜드 강조색과 반경은 Brand 컬렉션이 담당한다. 그러면 Dark + Partner라는 조합도 파일 복제 없이 바로 검증할 수 있다.

물론 모든 브랜드 차이를 모드만으로 해결할 필요는 없다. 어떤 브랜드는 버튼이 네모이고, 어떤 브랜드는 아이콘을 전혀 쓰지 않을 수도 있다. 이런 구조적 차이는 컴포넌트 속성이나 변형이 더 적합하다. 모드는 값을 바꾸는 데 강하고, 변형은 형태를 바꾸는 데 강하다. 둘의 역할을 섞지 않는 것이 중요하다.

한 파일 안에서 시작하는 추천 구조

이 장의 목표는 거대한 엔터프라이즈 체계를 만드는 것이 아니다. 한 파일 안에서도 분기 운영을 제대로 시작할 수 있어야 한다. 가장 실용적인 시작점은 다음과 같다.

페이지 구조는 단순하게 잡는다. 01 Foundations, 02 Components, 03 Screens, 04 QA Preview 정도면 충분하다. 그리고 변수 컬렉션은 목적별로 나눈다.

작은 팀이라면 이 구조만으로도 충분히 오래 간다. 팀이 커지면 Foundations와 Semantic을 별도 파일이나 라이브러리로 분리하는 방식으로 확장할 수 있는데, 이런 분리는 다음 장에서 더 자세히 다룰 것이다. 실제로 복잡한 멀티브랜드 팀은 Foundations, Semantic, Components를 분리해 운영하기도 한다.⁵

중요한 것은 파일 수가 아니라 책임 분리다. 어떤 컬렉션이 "환경"을 담당하고, 어떤 컬렉션이 "언어"를 담당하고, 어떤 컬렉션이 "브랜드"를 담당하는지만 분명하면 구조는 오래 버틴다.

실전 예시: 하나의 결제 화면으로 12가지 상태 보기

가상의 결제 화면을 떠올려 보자. 조건은 이렇다.

• 테마 2개: Light, Dark

• 언어 3개: ko, en, ja

• 브랜드 2개: Core, Partner

겉으로 보면 12개 화면이 필요해 보인다. 하지만 구조를 잘 잡으면 실제로는 결제 화면 하나와 비교용 프레임 몇 개면 충분하다.

먼저 결제 화면의 모든 색, 간격, 텍스트를 변수에 연결한다. 텍스트는 Language 컬렉션의 문자열 변수를 쓰고, 표면과 텍스트 대비는 Theme 컬렉션을 따르고, 브랜드 주 색상과 반경은 Brand 컬렉션에서 읽는다. 그다음 04 QA Preview 페이지에 같은 화면 프레임을 세 개 정도 복제해 둔다. 하나는 기본값, 하나는 Dark + en, 하나는 Light + ja + Partner로 둔다.

이제 테스트가 훨씬 정직해진다. 영어에서 버튼이 길어지면 자동 레이아웃을 고친다. Partner 브랜드에서 반경이 커져도 카드 배치가 어색하면 컴포넌트 패딩을 조정한다. 다크 모드에서 대비가 약하면 Theme 토큰 값을 손본다. 한 번 수정하면 12개 상태 전체에 개선이 퍼진다.

이때 느끼는 감각이 중요하다. "12장을 관리한다"는 느낌이 아니라 "하나의 시스템이 12가지 상황에 반응한다"는 느낌으로 바뀐다. 바로 그 지점에서 파일이 제품처럼 작동하기 시작한다.

자주 무너지는 네 가지 패턴

변수와 모드는 강력하지만, 몇 가지 실수만으로도 금방 흐트러진다.

첫째, 내부 레이어를 여기저기 명시적 모드로 고정하는 경우다. 부모 프레임이 바뀌어도 자식이 따라오지 않아 디버깅이 끝없이 길어진다. 특별한 이유가 없다면 내부는 Auto가 기본이다.¹

둘째, 다국어를 넣으면서 자동 레이아웃은 손대지 않는 경우다. 문자열 변수는 잘 들어갔는데 화면은 더 자주 깨진다. 이건 변수의 문제가 아니라 구조의 문제다.³

셋째, 브랜드와 테마와 언어를 하나의 컬렉션에 우겨넣는 경우다. 처음에는 빠른 지름길 같지만, 곧 이름이 길어지고 조합이 늘어나고 누구도 자신 있게 다루지 못하게 된다.

넷째, 컴포넌트가 여전히 원시값을 직접 참조하는 경우다. 라이트/다크도, 브랜드 전환도 결국 부분적으로만 작동한다. 모드는 토큰 구조가 받쳐 줄 때 진짜 힘을 낸다.

기억해야 할 한 문장

좋은 모드 설계는 "보기 전환"이 아니라 "문맥 분리"다.

라이트와 다크는 환경의 문맥이고, 언어는 콘텐츠의 문맥이며, 브랜드는 정체성의 문맥이다. 이 셋을 같은 프레임 복제로 감당하려 들면 파일은 금방 무거워진다. 반대로 문맥을 축으로 분리하고, 변수 컬렉션과 모드로 운영하면 한 파일 안에서도 제품의 복잡성을 훨씬 우아하게 다룰 수 있다.

그리고 이 구조는 사람에게만 좋은 것이 아니다. AI에게도 좋다. 문맥이 분리된 파일은 읽기 쉽고, 예측 가능하고, 실수할 여지가 적다. 결국 확장 가능한 디자인 시스템은 많은 화면을 그리는 시스템이 아니라, 많은 분기를 흔들리지 않게 다루는 시스템이다.

참고

¹Modes for variables – Figma Learn - Help Center

²How to adapt Designs to work with Multiple Languages in Figma

³Figma Localization for Seamless Design Workflows

⁴The Future Is Tokenized: How to Use Figma Variables Across Brands with Modes – Designilo

⁵How do you set up Figma Variables for single vs multi-brand themes?