jtwjs Dev Wiki
  • DEV_ROAD
    • 💪🏻 생존하기
    • Week 1
      • 개발 환경 세팅
      • 타입스크립트
      • 리엑트
      • Testing Library
      • Parcel & ESLint
    • Week 2
      • JSX
      • Virtual DOM
    • Week 3
      • React Component
      • React State
    • Week 4
      • Express
      • Fetch API & CORS
      • React Hook
      • useRef & Custom Hook
    • Week 5
      • TDD
      • React Testing Library
      • MSW
      • Playwrite
      • Snapshot
    • Week 6
      • Separtion of Concerns
      • Principle
      • DI, (Dependency Injection)
      • Reflect-metadata
      • TSyringe
      • External Store
      • Follow Redux
      • usestore-ts
      • useSyncExternalStore
    • Week 7
      • Routing
      • Routes
      • Router
      • Navigation
    • Week 8
      • Design System
      • Style Basics
      • CSS-in-JS
      • Styled-Components
      • Global Style & Theme
    • Week 9
      • 개발하기 전 준비
      • 상품 목록 페이지
      • 상품 상세 페이지
      • 장바구니 페이지
    • Week 10
      • 로그인
      • 로그아웃
      • 회원가입
      • 주문 목록 & 주문 상세
    • Week 11
      • 배송 정보 입력
      • 포트원 결제 요청
      • 배송 및 결제 정보 전달
    • Week 12
      • 관리자 웹사이트개발시작
  • DEV_NOTE
    • TypeScript
      • 기본적 문법
        • Enum
        • 다형성
          • Untitled
        • 구조적 타이핑
        • 제너릭 타입
        • 컨디셔널 타입
        • 함수 메서드 타이핑
        • infer로 타입스크립트의 추론 직접 활용
        • 재귀 타입
        • 템플릿 리터럴 타입
        • 추가적인 타입 검사 satisfies 연산자
        • 타입스크립트 건망증
        • 원시 자료형에도 브랜딩 기법 사용 가능
        • 타입 좁히기
        • 유용한 타입 만들기
        • 데코레이터 함수
        • 앰비언트 선언도 선언 병합이 된다.
        • 앰비언트 선언도 선언병합이 된다.
    • Testing
      • Unit Testing
      • 단위 테스트의 두 분파
      • 좋은 단위 테스트를 구성하는 4대 요소
      • 테스트 대역과 식별할 수 있는 동작
      • 단위 테스트 스타일
      • 가치 있는 단위 테스트를 위한 리팩토링
      • 통합 테스트
      • Cross Browsing Testing
      • 기능 테스트 종류
      • React Testing Pattern
      • 프론트엔드 테스트 입문
        • 테스트 범위
        • 단위 테스트 검증
        • Mock
        • UI 컴포넌트 테스트
        • 테스트 커버리지
        • 웹 통합 테스트
        • MSW
        • 스토리북
        • 시각적 회귀 테스트
        • E2E 테스트
        • Github Actions 설정
        • 깃허브 액션에서 E2E
      • 시프트 레프트
        • 테스트 기본중의 기본
        • 단위 테스트
        • 코드 복잡도
        • 리팩터링
        • 코드 리뷰
        • 통합 테스트 패턴
        • 시스템 테스트의 자동화
        • 탐색적 테스트
      • Test Tip
      • vitest
      • playwright
      • Test Data Generator
      • MSW
    • Algorithm
      • coding test
      • Data Structure
    • Next.js
      • Data Fetching
      • Hydration
      • Next 13
      • Optimization
      • Next 15
    • Tailwind
      • Tailwind CSS
      • Theme
      • Directives
      • Tool
      • Design System
    • Storybook
      • Storybook
      • CSF3
      • CDD
      • Headless Component
    • Funtional Programming
      • 함수형 프로그래밍
      • 참조 투명성
      • 부수효과
      • 함수 합성
      • 제너릭 타입 활용하기
      • 암묵적 입출력
      • 액션과 계산, 데이터
      • 계층형 설계
      • 호출 그래프
      • 함수형 설계
      • 불변성
      • 일급 함수
      • 함수형 도구
    • Git
      • Github Actions
      • Conflict
      • Branch 전략
    • Contents Format
      • Audio
    • 3D Graphic
      • 3D keyword
      • Three.js
      • Geometry
      • Material
      • Light
      • Camera
      • Decal
      • Rotation
      • Text
      • Shadow
      • Fog
      • Post Processing
      • Animation
      • Math
        • Vector Space
        • 벡터의 연산
        • 회전 계산
      • 3D 컨텐츠가 만들어지는 과정
      • R3F
      • Env
      • Scene
      • Transform
      • R3F
      • Interaction & Raycast
      • Rendering Algorithnm
      • Blender
      • Blender
    • Accessibility
      • 접근성이란
    • Interactive Web
      • Parallax
      • Canvas
      • requestAnimationFrame
      • Effect
      • HSL
      • React.js + Canvas
      • Matter.js
    • AWS
      • DevOps
      • Amplify
      • S3
      • 클라우드 컴퓨팅
        • 온프레미스와 클라우드
        • 클라우드 도입효과
        • 클라우드 컴퓨팅의 범위
        • 컴퓨팅 옵션
          • EC2 - Virtual Machin
          • ECS, EKS - Container
          • Lambda - Serverless
        • 네트워크 가상화
        • 스토리지
        • 데이터베이스
        • 데이터 수집
        • 머신 러닝 영역
        • IoT 영역
        • 블록체인 영역
      • 클라우드 아키텍처 설계
    • Network
      • Web Server & WAS
    • System Design
      • System Design
      • Component
      • 의존성을 배제한 개발
      • Error Handling
      • Architecture
        • 모노로틱 아키텍처
        • Clean Architecture
        • Layered Architecture
        • 이벤트 기반 아키텍처
      • 상황을 파악하는 메타인지
      • 중복 문제 해결하기
      • Monorepo Arhitecture
        • 모노레포 운영과 트러블슈팅
        • Module Federation
      • 코드 병목지점
      • API 대응
      • 공통 코드
      • Infra 구축
      • 모듈 기반의 개발 방식
      • Design System
        • 최소 수준의 아키텍처 설정
        • 더 효율적인 디자인시스템 만들기
        • 디자인 시스템과 UI 라이브러리 목적
        • 디자인 토큰
      • 효율적인 업무
        • 업무 프로세스 병목 파악
      • Clean Code
      • Design Pattern
        • CQRS Pattern
        • Strangler Fig Pattern
        • 데코레이터 패턴
        • 커맨드 패턴
        • 전략 패턴
        • 옵저버 패턴
      • A/B 테스팅
      • 대규모 리엑트 웹앱 개발
        • 복잡성 관리
        • 모듈성
        • 성능
        • 디자인 시스템
        • 데이터 패칭
        • 상태 관리
        • 국제화
        • 코드 조직화하기
        • 개인화 A/B 테스팅
        • 확장 가능한 웹 아키텍처
        • 테스팅
        • 툴링
        • 기술적 마이그레이션
        • 타입스크립트
        • 라우팅
        • 사용자 중심 API 디자인
        • 리액트 미래
    • Performance
      • React DevTools
      • Component 최적화
      • Page Load
      • API
    • MFA
      • MSA
      • MFA 도입하기
      • Monorepo
        • Monorepo Tool
        • Yarn Berry Workspace
        • Turborepo
      • MFA Composition
      • SPA 통합
      • Design System
      • Package Manager
        • Yarn
        • pnpm
      • Transpiler & Bundler
        • Babel
        • Rollup
        • esbuild
        • swc
        • Webpack
        • Vite
      • 분해와 통합을 위한 여러 기술 비교
    • State Management
      • Zustand
    • React v18
      • Automatic batching
      • Suspense
      • Transition
    • SEO
      • Search Engine Optimization
      • Open Graph Element
      • Metadata
    • FE Develop
      • Scrubbing
      • Clipboard
    • Refactoring
      • 리팩토링 깊게 들여다보기
      • 긴 코드 조각내기
      • 타입 코드 처리하기
      • 유사한 코드 융합하기
      • 데이터 보호
      • 코드 추가 및 제거
    • OAuth 2.0
    • Analytics
      • Mixpanel
    • ETC
      • VSCode
    • React Hook In Action
      • useContext & Provider
      • 커스텀 훅
      • 코드 분할하기 with Suspense, lazy
      • Suspense와 이미지 적재하기
      • useTransition, uesDeferredValue
      • SuspenseList
Powered by GitBook
On this page
  • 디자인 시스템
  • 코딩 스타일 가이드
  • 디자인 토큰
  • 컴포넌트 라이브러리
  • 접근성
  • 성능
  • 문서화
  1. DEV_NOTE
  2. System Design
  3. 대규모 리엑트 웹앱 개발

디자인 시스템

Previous성능Next데이터 패칭

Last updated 2 months ago

디자인 시스템

팀이 응집된 제품을 구축하는데 도움을 주는 재사용 가능한 컴포넌트, 가이드라인, 에셋의 집합

  • 디자인 시스템은 사용자와 팀이 사용자에게 유용한 디지털 경험을 만들 수 있도록 안내하는 나침반

  • 가장 중요한 목표는 사용자 경험을 향상시키는 것

디자인 시스템 오픈 소스

  • 구글 머터리얼

  • 쇼피파이 Polaris

  • 애플 Human Interface Guidelines

  • 마소 Fluent Design System

  • 디자인 시스템은 중앙 집중화된 설계 요소, 패턴, 가이드라인을 제공하며 개발 및 설계 프로세스의 일관성과 효율성을 보장

  • 가장 중요한 것은 접근성과 일관성

코딩 스타일 가이드

규칙과 가이드라인의 집합

  • 조직 전체의 코드에서 일관성을 보장

  • 디자인 시스템의 컨텍스트에서 핵심적인 역할

  • 통일성: 규칙과 관습, 표준화된 집합은 통일성의 보장을 도움, 개발 환경안의 일관성을 촉진

  • 모듈화된 코드 구조: 모듈화된, 재사용 가능한 컴포넌트의 생성을 독려함

    • 디자인 시스템 효율성의 핵심

  • 응집의 미학: 코딩 스타일 가이드를 디자인 원칙과 시각적 가이드라인과 함께 사용시 코드 구조와 시각적 요소를 정렬함으로써 일관적인 미학과 동작으로 렌더링하는 것을 도움

고려사항

  • 유연성과 확장성 : 변화를 수용할만큼 유연해야하며, 프로젝트의 성장을 다룰 수 있을만큼 확장 가능해야함

    • 새로운 컴포넌트를 쉽게 통합할 수 있고, 기존 시스템을 망가뜨리지 않고 스타일링할 수 있어야함

  • 팀 협업과 효율성 : 팀 멤버 사이의 효율적인 협업을 촉진

    • 명확하고, 간결하며 모든 팀 멤버들의 경험 수준에 관계없이 쉽게 이해할 수 있어야함

  • 디자인 원칙들과의 정렬 : 시스템의 중요한 디자인 원칙과 정렬되어 있어야함

    • 코드가 깨끗하게 보이고, 디자인 의도와 사용자 경험 목표를 반영함

디자인 시스템에서 스타일 가이드의 선택은 프로젝트 요구사항, 팀 선호, 디자인 시스템의 전반적인 목표를 고려해 이뤄져야함

디자인 토큰

재사용 가능한 디자인 정보 조각

  • 색상, 타이포그래피, 간격 등

  • 중앙 집중된 영역에 정의되고 여러 프로젝트에서 접근 및 재사용될 수 있음

  • 주요 목적은 디자인 가치를 애플리케이션으로부터 추상화하는 것

  • 설계 토큰의 큰 장점은 디자인 시스템 안에서 업데이트를 단순화 할 수 있음

디자인 토큰을 생성 및 관리하는 프로세스를 더 쉽게 만들어주는 서드파티 도구들

    • JSON, yaml 로 작성된 디자인 토큰들을 다양한 형태로 변환해줌 (SASS, LESS, CSS 커스텀 속성 등)

    • 단일 토큰 집합으로부터 다양한 플랫폼용 스타일 생성을 도와줌

컴포넌트 라이브러리

사전 설계 및 사전 코딩된 UI 컴포넌트들 모음

  • 웹 애플리케이션 설계의 빌딩 블록 역할

  • 컴포넌트 라이브러리를 구축하고 사용함으로써 앱 전체의 일관성을 보장

  • 일관성은 개발 시간 및 비용을 줄이고, 유지보수를 쉽게 해줌

  • "최고의 설계 도구는 효율적이지만 단순하다"

    • 너무 많은 일을 하려드는 도구는 신뢰할 수 없거나 사용하기 불펴해진다.

    • 하나의 컴포넌트 API에는 너무 많은 옵션을 넣으려하면 불필요하게 경직됨 (유지보수 어려움)

확장성

프로젝트 규모가 커지면서 보다 많은 컴포넌트들이 추가되면 컴포넌트 라이브러리는 유지보수 가능한 상태로 구조화되어야 한다.

  • UI 카테고리에 기반해 폴더로 조직화

  • 명확한 명명 규칙을 보장해야함

  • 종합적인 문서화를 유지해야함

의존성 관리

디자인 라이브러리 내 컴포넌트들은 최소 의존성을 갖도록 항상 보장해야한다.

  • 라이브러리 크기를 줄일 수 있음

  • 해당 라이브러리를 사용하는 프로젝트 안에서 의존성 충돌 발생 가능성도 줄임

접근성

디자인 시스템 내부 요소들 안에서 접근성을 보장하는 것은 매우 중요

  • UI 컴포넌트에는 장애인을 포함해 모든 사용자들이 접근할 수 있어야 함

  • 비-텍스트 컨텐츠(이미지, 비디오, 오디오)를 위해 대체 텍스트 제공

  • 시맨틱 HTML 활용

  • 전경색과 배경색 사이에 색상 대비

  • 키보드 인터렉션

  • 빠르게 반복되는, 깜박거림, 색상 전환되는 컨텐츠 통합 피하기

성능

디자인 시스템의 컴포넌트들은 높은 성능을 위해 최적화되어야함

  • 애플리케이션 내부에서 자주 재사용되고, 한 페이지에서 여러 차례 렌더링되기 때문

  • 이 컴포넌트들의 모든 성능 이슈, 병목은 애플리케이션 전반적인 성능에 큰 영향을 미침

  • UI 컴포넌트에 관해 지연 로딩 구현

    • 이미지, 비디오 같은 리소스를 온디맨드로 로딩

  • 다양한 화면 크기에 적응하는 이미지 활용

    • 이미지를 통합하거나, 사용자 기기 화면 크기에 맞춰 제공

  • UI 컴포넌트 에셋에 관한 HTTP 요청 줄이기

    • 스크립트 혹은 스타일 파일을 하나의 파일로 합치기

문서화

좋은 디자인 시스템 및 컴포넌트 라이브러리의 뼈대

  • 컴포넌트와 디자인 토큰을 효과적으로 사용하는데 필요한 명확성, 컨텍스트, 지시를 제공하는 가이드북 역할

  • 새로운 팀 구성원의 온보딩 프로세스를 쉽게 만듦

  • 컴포넌트 사용과 관련된 잘못된 소통 및 잠재적인 오해를 최소화

  • 디자이너와 개발자가 동일한 방향성을 가지고 작업할 수 있도록 돕는 기준점 역할\

명확한 문서화 작성 요소

  • 컴포넌트 설명: 각 컴포넌트에 대한 간략한 개요 및 목적, 사용 방법

  • 사용 가이드라인: 해당 컴포넌트 구현 방법에 관한 단계적 설명, 코드 스니핏, 시각적 참조 자료 등

  • props 및 API 참조: 컴포넌트의 모든 속성의 세부 목록 및 타입, 속성들이 컴포넌트 동작이나 형태에 미치는 영향

  • 예시: 다양한 컴포넌트 혹은 prop 조합을 보여주는 컴포넌트 예시

  • 접근성 노트: 컴포넌트가 접근성 표준을 얼마나 준수하는지에 관한 구체적인 세부 사항 및 일관성 있는 접근성 보장하기 위한 모든 특별 지시사항 등

  • 버저닝 및 변경이력: 컴포넌트의 다른 버전들에 관한 정보, 변경사항 등

Storybook, Nextra를 활용해서 디자인 시스템 문서화 도전!

DLS

디자인과 개발에서 일관된 UI/UX를 유지하기 위한 원칙, 컴포넌트, 스타일 가이드 등을 체계적으로 정리한 시스템

  • 에어비엔비

  • 영국 정부 디지털 서비스

  • 머터리얼

Salesforce -

아마존 -

사용하기 (이미지 여러개 합침)

Guideline
material ui
Guideline
polaris ui
Guideline
Guideline
fluent ui
Theo
Style Dictionary
WebAIM Contrast Checker
이미지 스프라이트
참고
Building a Visual Language: Behind the scenes of our Arirbnb design system
The way We Build
GDS podcast #16: GOV.UK Design System
Government Design Principles
Material Design at Google IO 2014
get-started
And You Thought Buttons Were Easy?