The following article is offered for informational purposes only, and is not intended to provide, and should not be relied on, for legal or financial advice. Please consult your own legal or accounting advisors if you have questions on this topic.

Flex는 작은 규모에도 불구하고 큰 성과를 내는 것으로 잘 알려진, 행동 지향적인 엔지니어링 팀입니다. 몇 년간의 빠른 제품 변경과 방향 전환 끝에 상당한 양의 UX 부채가 쌓였고, 이는 투박한 사용자 경험으로 나타나기 시작했습니다. 

우리는 여전히 빠르게 출시해야 했지만, 품질에 대한 기준은 훨씬 높아졌고 '품질'이 실제로 무엇을 의미하는지에 대한 공통된 이해가 필요했습니다. 하지만 디자인 시스템 구축에 대한 아이디어가 제게 제시되었을 때, 저는 내심 당황하기 시작했습니다.

이전에 두 개의 디자인 시스템을 구축해 본 경험이 있었기에, 저는 불필요한 맞춤 작업, 사소한 논쟁, 오래된 문서 등 디자인 시스템이 수반할 수 있는 함정들을 알고 있었습니다. 우리는 디자인 시스템이 가져올 수 있는 부담에 얽매일 시간이나 자원이 없었습니다. 

요구 사항

질문은 빠르게 다음과 같이 바뀌었습니다. "우리를 늦추지 않으면서 가치를 제공하는 '경량' 디자인 시스템을 어떻게 구현할 수 있을까?"

우리가 가장 먼저 해야 할 일은 포괄적인 디자인 시스템이 무엇을 수반하는지, 그리고 우리가 구축하려는 경량 시스템은 무엇을 수반하는지 비교 평가하는 것이었습니다.

일반적인 포괄적 디자인 시스템

• 맞춤형 컴포넌트 (버튼, 모달, 테이블 등)
• 맞춤형 도구 (스토리북 설정, 내부 인프라)
• 변경을 위한 프로세스/거버넌스
• 높은 유지보수 비용

경량 디자인 시스템

• 가장 많이 사용되는 컴포넌트 및 패턴만
• 채택하기 쉬움 — 문서와 코드가 개발자들이 이미 작업하는 곳에 존재
• 처음부터 구축하는 대신 기존 라이브러리 활용 (가능한 경우)
• 사용법을 보여주는 표준이 있음

우리의 제약 사항: 작은 팀, 큰 목표.

원자 단위 컴포넌트(버튼, 입력 필드 등)부터 일반적인 레이아웃과 다단계 플로우에 이르는 우아한 디자인 시리즈로 시작했습니다. 

이 과정 전반에 걸쳐 저희는 모든 노력을 기울였습니다 하지 않기 위해 꼭 필요한 경우가 아니라면 새로운 컴포넌트를 만들지 않기 위해 노력했습니다. 우리가 선택한 도구를 활용하는 것이 필수적이었습니다. 우리는 매주 엄청난 양의 작업을 처리하는 작은 회사였기에, 맞춤형 컴포넌트에서 발생하는 맞춤형 문제의 세부 사항에 얽매이는 것은 가장 피해야 할 일이었습니다.

시각적 불일치는 명확했지만, Flex에서 제가 발견한 더 깊은 문제는 폼과 같은 일반적인 UI를 구축하는 데 있어 통일된 접근 방식이 부족하다는 것이었습니다. 코드베이스를 살펴보면 폼 UI를 구현하는 다섯 가지 다른 방식을 찾을 수 있었습니다. 일련의 표준이 필요하다는 것이 분명했습니다.

통일된 표준 시리즈 만들기

이전에 개발자들이 복사/붙여넣기할 수 있는 모범 사례 모음을 담은 '치트 시트' 섹션을 작업하기 시작했습니다. 이것은 우리의 새로운 디자인 시스템을 선보이기에 완벽한 장소가 되었습니다. 이 영역(나중에 "Playground"로 이름 변경)을 사용하여 개발자들이 가장 일반적인 UI에 대한 이러한 표준을 보고 사용하여 작업을 빠르게 시작할 수 있도록 했으며, 디자이너들이 자신들이 만든 것이 실제로 사용되고 있음을 확인할 수 있도록 했습니다. 마지막으로, 이를 자체 웹 앱에 내장하는 것(Storybook과 같은 외부 플랫폼을 통하는 대신)이 사용을 보장하는 데 도움이 되었습니다.

하지만 이야기는 이제 막 시작되었습니다. 먼저 해결해야 할 몇 가지 난관이 있었습니다.

1. 우리는 선택한 UI 라이브러리의 이전 버전에 묶여 있었습니다 업그레이드하려면 상당한 노력이 필요했습니다. 이 변경 사항은 고객 대면 앱과 내부 도구인 Alfred 전체에 걸쳐 적용될 것이었습니다.
2. 내부 앱과 웹 앱을 함께 배치하기 위해 저장소를 통합해야 했습니다 앱 간 디자인 시스템 사용을 보장하기 위해.

이러한 이정표를 달성한 후, 우리는 두 앱 모두 새로운 디자인에 맞춰 테마를 다시 적용했고 추진력이 붙기 시작했습니다.

시너지 효과

내부 도구인 Alfred와 웹 앱의 테마를 다시 적용한 후, Playground에서 일련의 모범 사례를 만들기 시작했습니다. 시간이 지나면서 Playground는 우리 사용 사례의 "80/20"을 담게 되었는데, 이는 컴포넌트, 레이아웃 및 공유 유틸리티를 위한 원스톱 상점이었습니다.

‍

‍

Playground가 개발자들이 컴포넌트를 복사/붙여넣기하여 작업을 빠르게 시작하는 데 유용할 것이라는 것을 알고 있었지만, 이러한 표준 모음은 LLM이 UI 코드를 어떻게 생성해야 하는지 이해하는 데 완벽하다는 것이 밝혀졌습니다.

등장: Cursor

Playground를 구축하기 시작한 직후, 저희 프론트엔드 팀은 사용하기 시작했습니다 Cursor AI (커서 AI). 저희는 어떤 UI 기반 코드를 생성할 때 시작점으로 활용할 수 있도록 Cursor 규칙 참조 플레이그라운드를 만들었습니다.

• 저희 디자인 시스템 컴포넌트 사용 예시는 `src/areas/playground`에 있는 Playground를 확인하세요.
• Drawers, Tables, Wizards, Layouts 등과 같은 새로운 컴포넌트를 구현할 때는 Playground에 구현된 파일을 복사하여 작업 중인 영역에서 시작점으로 사용하세요.
• 대부분의 경우 `src/areas/playground`의 파일을 업데이트하지 않고, 단지 그 안에 있는 컴포넌트들을 `src/areas`의 새 폴더로 복사해 넣는 시작점으로 사용할 것입니다.

이전의 테마 재작업 노력은 여기서 엄청난 성과를 거두었으며, Cursor가 어떤 스타일 가이드라인도 참조할 필요 없이 저희 디자인 시스템과 일관된 UI를 구축할 수 있는 길을 열어주었습니다.

“Flex에서 프런트엔드 품질이 의미하는 바”를 더욱 명확히 하기 위해, 저희는 UI 팀으로서 이전에 합의했던 표준을 성문화했습니다. Cursor는 Playground의 규칙 외에도 이를 참조하여 LLM이 무엇을 구축해야 할 뿐만 아니라, 저희의 다양한 도구 및 관례와 함께 어떻게 구축해야 하는지를 이해하도록 합니다. 다음은 Cursor 규칙 파일에서 현재 UI 라이브러리인 Mantine을 참조하는 방법의 일부입니다.

• Mantine을 기본 React 컴포넌트 라이브러리로 사용하세요.
• Mantine 라이브러리를 최대한 활용하세요. `@mantine/core`의 컴포넌트, `@mantine/hooks`의 훅, `@mantine/form`의 폼을 포함해서 말이죠.
• 컴포넌트의 경우, 항상 저희 `components/core` 또는 `components/composites` 폴더에 있는 컴포넌트를 먼저 사용하고, 그렇지 않으면 가능한 한 Mantine 핵심 컴포넌트를 사용하세요.
• 인라인 스타일링이나 클래스 사용은 피하세요. 먼저 항상 Mantine props를 사용하여 색상 및 배경색, 간격 및 크기 등을 스타일링하세요.
• 색상의 경우, 항상 저희 Mantine 테마 색상을 사용하세요(예: `theme.colors.yourColorHere[index]`).
• 간격 및 크기의 경우, 픽셀 또는 숫자 값 대신 Mantine의 `rem()` 함수를 사용하세요. 예: `gap={rem(12)}`

Flex 결과

저희 디자인 시스템과 함께 AI를 사용하는 것은 속도와 품질에 대한 더 높은 기준을 만들고 유지하는 데 있어 전반적으로 판도를 바꾸는 일이었습니다. 최근의 미수금 기능은 단 3주 만에 완전히 구축되었습니다! 

마찬가지로, Playground를 견고한 컴포넌트 및 패턴 컬렉션으로 활용하는 것은 개발자와 LLM 모두에게 품질 기준을 더욱 강조했습니다. 디자인 시스템 구축에 대한 보다 가벼운 접근 방식을 추구함으로써, 저희는 디자인 시스템과 흔히 관련된 수많은 함정을 피할 수 있었고, 동시에 일관성과 방향성이라는 이점을 유지할 수 있었습니다.

최근에 저희는 Playground를 교육 자료로 활용하여 저희가 적극적으로 사용 중단을 시도하고 있는 상태 관리 도구의 대안을 개발자들이 어떻게 사용할 수 있는지 보여주었습니다. 가까운 미래에 저희는 Playground 표준을 CI 빌드에 연결하여 채택을 더욱 확실히 할 계획입니다.

다른 팀을 위한 교훈

초기 단계에 있다면, 다음과 같이 권장합니다:

• 작게 시작하세요: 가장 많이 사용되는 UI 구성 요소에 집중하세요.
• 맞춤 작업을 피하세요.: 대부분의 최신 UI 구성 요소 라이브러리는 디자인 시스템 구축 노력을 시작하는 데 활용될 수 있습니다. 더 복잡한 구성 요소와 워크플로를 위해 맞춤 작업을 남겨두세요.
• '좋음'이 무엇인지 구체적으로 정하세요.: 팀이 UI 툴링 및 코딩 규칙에 대한 합의된 표준을 갖추도록 하여 AI 툴링으로 이를 코드화할 수 있도록 하세요.
• 팀에게 명확하게 하세요.: 디자인 시스템이 사용되도록 제품에 내장하세요.
• LLM이 접근 가능하도록 만드세요.: 코드를 생성하기 전에 정렬을 보장할 수 있도록 AI 툴링이 디자인 시스템과 표준을 쉽게 참조할 수 있도록 하세요.

결론

맞춤형 또는 완전한 디자인 시스템이 필요하지 않을 것입니다. 유용한 것이 필요합니다.

Flex에서 저희 디자인 시스템은 엔지니어링, 제품, 디자인 전반에 걸쳐 배율기 역할을 해왔습니다. 이를 통해 훨씬 더 높은 품질 기준을 유지하면서 더 빠르게 움직일 수 있었습니다.

속도와 AI 툴링에 집중하는 초기 단계 팀에게 이것은 가장 현명한 인프라 투자 중 하나가 될 수 있습니다.

‍