TkDodo의 Designing Design Systems를 번역한 글입니다.

저는 디자이너가 아닙니다. 솔직히 말해서 ‘픽셀 퍼펙트’ 작업이나 CSS가 들어가는 일은 제 강점이 아니에요. Figma도 겨우 켜는 수준이고, 켜더라도 그냥 이것저것 클릭해보면서 잘되길 바랄 뿐입니다. 😅

저는 JVM 기반 언어(Java, Scala, Groovy)로 백엔드 커리어를 시작했고, 이후 풀스택 React를 거쳐 프론트엔드의 뒷단에 정착했습니다. 지난 5년 동안 headless 라이브러리인 TanStack Query를 메인테인 해온 걸 생각하면 꽤 자연스러운 흐름이죠.

그런데 그런 제가 지금 왜 Sentry의 Design Engineering 팀에서 새로운 Scraps 디자인 시스템을 만들고 있을까요?

Design Engineering

일반적으로 보면, 이런 팀에는 여러 종류의 역량이 필요하다고 생각합니다. 예를 들어, Nate Moore 같은 정말 훌륭한 디자인 엔지니어가 있습니다. 인터페이스를 자연스럽고 일관되며 심지어 아름답게 만드는 데는 정말 막을 수 없는 힘을 가진 사람이죠.

하지만 우리는 API 디자인, 성능, DX, 인프라 같은 부분에 집중하는 사람들도 필요합니다. 이런 요소들이야말로 전체 시스템이 매끄럽게 돌아가도록 해주니까요.

디자인 시스템은 예쁜 컴포넌트 모음 이상입니다. 그것은 다른 팀들이 빠르고 효율적으로 일관된 제품을 내보낼 수 있게 해주는 게이트웨이죠.

이렇게 다양한 스킬 셋이 섞여 있을 때 팀이 훨씬 높은 수준에서 움직일 수 있습니다. 그래서 저는 완벽한 그라데이션이나 CSS 트랜지션을 만드는 사람은 아니지만, 시스템이 견고하고 유지보수 가능하며 사용하기 쉬운 상태를 유지하도록 기여할 수 있습니다.

그리고, 우리 팀은 단순히 디자인 시스템만 관리하는 역할이 아닙니다. 사실 우리의 목표는 아주 간단합니다:

팀이 더 빨리 배포할 수 있도록 돕는 것 🚢

Sentry의 코드베이스는 10년 넘게 유기적으로 성장해 왔습니다. 잘 돌아가는 부분도 많지만, 손봐야 할 부분도 많죠. 지금 우리는 그걸 개선할 수 있는 좋은 위치에 있습니다. 디자인 시스템은 이를 위한 강력한 도구 중 하나이지만, 개발자 교육, 빠른 CI 파이프라인, 방해되지 않는 프로젝트 구조도 똑같이 중요합니다.

그런 맥락에서 저는 제 역할을 개발자 경험(engineering experience) 엔지니어라고 생각합니다. 디자인 시스템은 매우 중요합니다, 특히 모두가 더 빠르게 움직이도록 돕기 때문에요. 하지만 전체 퍼즐 중 하나일 뿐이고, 사람들의 속도를 늦추는 어떤 것도 우리는 단순화하거나 자동화하거나 없애려고 합니다.

좋은 디자인 시스템이란 무엇일까

그렇다 보니, 최근에는 좋은 디자인 시스템이란 무엇인가에 대해 꽤 많이 생각하게 되었습니다. 그리고 한 가지 깨달은 게 있는데… 이 주제에 대해 하고 싶은 말이 한 블로그 글에 담기에는 너무 많다는 거예요 😅

그래서 그냥 떠오르는 것들을 구조 없이 쭉 나열해보려고 합니다. 그리고 나중에 그중 일부 주제를 골라서 더 자세한 블로그 글로 써볼 생각입니다.

이 중에서 궁금한 점이 있다면 댓글로 알려주세요. 우선순위를 두고 먼저 써볼게요!

디자인 시스템 원칙들

• props는 갖되, 너무 많지 않게. 특히 boolean은 피하자.
• 타입 안정성을 적극적으로 추구하자.
• 진짜로, 생각보다 훨씬 더 타입 세이프하게.
• 타입 레벨에서 강제할 수 없는 것은 lint로 강제하자.
• 실용적이어야 하고 escape hatch를 허용하되, 내부 구현이 새어 나가서는 안 된다.
• Composition을 우선하자.
• Compound Component는 좋지만, 타입 안전해야 한다.
• 제약은 좋지만, 의도적이고 균형 있어야 한다.
• 일관성이 핵심이다. 시각적 일관성뿐 아니라 컴포넌트 API도 마찬가지다.
• 문서는 정말 중요하지만, 타입은 그보다 더 중요하다.
• 그러니까 jsdoc 제대로 쓰자!
• a11y는 처음부터 내장되어야지 나중에 덧붙이는 게 아니다.
• 실제 사용 사례를 알고, 그것을 위해 구체적으로 만들어라.
• Tooltip 컴포넌트는 없어야 한다.
• 컴포넌트보다 디자인 토큰이 먼저다.
• 성능은 선택 사항이 아니다.
• primitives만이 아니라 패턴을 제공하라.
• 100%가 아니라 90%를 위해 최적화하라.
• 가능하다면 headless가 좋다.
• 도입은 기술 문제가 아니라 문화적인 문제다.
• codemod를 제공하라.
• 외부 기여를 환영하고, 이를 위한 좋은 가이드를 제공하라.
• 동일한 일을 하는 방법은 하나만 두고, 중복을 피하고, 반복하지 말자(DRY).
• 동작 주입을 위한 Provider를 제공하라.
• 기본값은 신중하게 선택하고, 의견을 갖자(opinionated).
• 중요한 것에는 visual regression testing을 하자.
• state syncing은 모든 악의 근원이다.
• 기본적으로 controlled, 필요할 때 uncontrolled. 그리고 타입을 명확히 하자.
• data-test-id는 a11y 관점에서 나쁜 냄새(smell)다.
• React의 미래를 바라보고 만들어라.