디자인 시스템은 성장에 따라 경직되기 마련이며, 시스템이 제품 팀의 변화하는 요구사항을 제때 수용하지 못할 경우 팀은 시스템을 우회하거나 파편화된 코드를 생성하게 됩니다. 토스의 디자인 시스템(TDS)은 디자인 시스템을 통제 수단이 아닌 '하나의 제품'으로 정의하고, 수요자의 니즈에 따라 유연하게 대응할 수 있는 설계 구조를 지향합니다. 이를 위해 단순함과 유연함을 동시에 잡을 수 있는 하이브리드 API 전략을 도입하여 일관성과 생산성을 모두 확보하는 해결책을 제시합니다.

시스템의 경직성과 파편화 문제

조직이 커지고 제품이 다양해지면 기존 시스템의 제약 내에서 해결할 수 없는 UI 요구사항이 빈번하게 발생합니다.
제품 팀은 빠른 해결을 위해 피그마 컴포넌트를 해제(detach)하거나 라이브러리 코드를 복제(fork)하여 로컬에서 수정해 사용하게 됩니다.
이러한 우회 방식은 시스템 업데이트와의 연결을 끊어버려 UI 불일치를 초래하고, 장기적으로 디자인 시스템의 핵심 가치를 무너뜨립니다.
결국 디자인 시스템이 팀의 속도를 늦추는 장애물이 되지 않으려면, 강력한 규칙보다 '우회할 이유를 줄이는 유연한 설계'가 필요합니다.

확장성을 고려한 컴포넌트 API 패턴 비교

Flat 패턴: 내부 구조를 숨기고 모든 변형을 props로 처리하는 방식입니다. 사용이 직관적이고 간결하지만, 예외적인 요구사항이 늘어날수록 props가 기하급수적으로 증가하여 유지보수가 어려워집니다.
Compound 패턴: 하위 컴포넌트(Header, Body, Footer 등)를 제공하여 사용자가 직접 조합하는 방식입니다. 시스템이 예측하지 못한 레이아웃도 유연하게 구현할 수 있으나, 코드량이 늘어나고 구조에 대한 학습 비용이 발생한다는 단점이 있습니다.
두 패턴은 상충하는 장단점을 가지고 있으므로, 단순히 하나의 패턴을 강요하는 것은 사용자의 이탈을 막기에 부족합니다.

TDS의 하이브리드 전략과 Primitive 레이어

TDS는 단순하고 빈번한 케이스를 위한 Flat API와 복잡한 커스텀을 위한 Compound API를 동시에 제공합니다.
사용자는 별도의 커스텀이 필요 없을 때는 간결한 Flat 형식을 선택하고, 세밀한 제어가 필요할 때는 Compound 형식을 선택하여 시스템 내부에서 문제를 해결할 수 있습니다.
디자인 시스템 팀은 관리 효율을 위해 Primitive(기초 단위) 레이어를 먼저 구축합니다.
내부적으로는 동일한 Primitive 컴포넌트를 공유하면서 외부로 드러나는 API만 두 가지 형태로 노출함으로써, 유지보수 부담을 최소화하면서도 사용자 경험을 극대화합니다.

디자인 시스템은 팀을 가두는 울타리가 아니라 안전하게 안내하는 가드레일이 되어야 합니다. 중앙에서 모든 것을 통제하려 하기보다, 규칙에서 벗어난 예외 상황까지 시스템 안에서 지원할 수 있는 유연한 설계를 갖출 때 진정한 일관성을 유지할 수 있습니다.