RN 디자인 시스템 구현하기 3편 - 디자인시스템 적용 구조 (대규모 프로젝트)

1. Atomic 디자인 - 사용 여부

Atomic Design은 UI 컴포넌트를 atoms, molecules, organisms, templates, pages 5단계로 구조화하는 방법론입니다. DEV CommunityStackademic 하지만 실무에서는 선택적으로 사용합니다:

장점:

• 컴포넌트 재사용성 극대화
• 일관성 있는 계층 구조
• 팀원 간 명확한 컴포넌트 분류 기준

단점:

• 소규모 프로젝트에는 과도한 구조
• atoms/molecules 구분이 모호할 때가 많음
• 실제로는 3단계 정도로 단순화해서 많이 사용

현실적인 접근:

 

 

src/
  components/
    base/           # atoms 역할 (Button, Input, Text)
    composed/       # molecules 역할 (SearchBar, FormField)
    feature/        # organisms 역할 (LoginForm, ProductCard)

많은 팀이 완전한 Atomic Design보다는 **"컴포넌트 복잡도에 따른 분류"**를 선호합니다.

2. 실무에서 많이 쓰는 파일 구조

React Native 프로젝트의 일반적인 구조는 assets, screens, components, hooks, services, utils 등의 디렉토리로 구성됩니다. MediumDEV Community

추천 구조 (Feature-First + Component-Based 혼합)

 

 

src/
  ├── design-system/          # 디자인 시스템 전용
  │   ├── tokens/
  │   │   ├── colors.ts
  │   │   ├── typography.ts
  │   │   ├── spacing.ts
  │   │   └── index.ts
  │   ├── components/
  │   │   ├── Button/
  │   │   │   ├── Button.tsx
  │   │   │   ├── Button.stories.tsx  # (optional)
  │   │   │   ├── Button.test.tsx
  │   │   │   └── index.ts
  │   │   ├── Input/
  │   │   └── Card/
  │   ├── hooks/
  │   │   └── useTheme.ts
  │   └── theme.ts
  │
  ├── features/               # 기능별 모듈
  │   ├── auth/
  │   │   ├── components/
  │   │   ├── screens/
  │   │   ├── hooks/
  │   │   └── api/
  │   └── home/
  │
  ├── shared/                 # 공통 모듈
  │   ├── components/
  │   ├── hooks/
  │   └── utils/
  │
  ├── navigation/
  ├── services/               # API 통신
  ├── assets/
  └── App.tsx

핵심 원칙

1. 디자인 시스템은 독립적으로: design-system 폴더를 완전히 분리
2. Feature-First: 큰 기능은 features/ 아래에서 자체 완결적으로 관리
3. 공통 요소는 shared/: 여러 feature에서 쓰이는 것만

3. Storybook 사용 여부

Storybook for React Native 8.3은 웹 버전과 통합되어 Amazon, Shopify, Brex 등 많은 모바일 팀이 사용합니다. Storybook

사용하는 경우

• 대규모 팀: 디자이너/개발자 간 협업이 많을 때
• 디자인 시스템 중심 개발: 재사용 컴포넌트 라이브러리 구축 시
• 문서화 필요성: 컴포넌트 사용법을 명확히 공유해야 할 때

사용하지 않는 경우

• 소규모 프로젝트: 2-3명 팀에서는 오버헤드
• 빠른 MVP: 초기 프로토타입 단계
• 학습 곡선: 팀원들이 Storybook에 익숙하지 않을 때

일부 팀은 Storybook을 "비주얼 유닛 테스트"로 사용하고, 다른 팀은 재사용 가능한 위젯 라이브러리 문서화 도구로 활용합니다. Stack Overflow

대안

Storybook 대신 간단한 **"Component Gallery 화면"**을 앱 내부에 만드는 것도 좋은 방법입니다:

 

 

typescript

// screens/DevGallery.tsx (개발 환경에서만)
const DevGallery = () => (
  <ScrollView>
    <Section title="Buttons">
      <Button variant="primary">Primary</Button>
      <Button variant="secondary">Secondary</Button>
    </Section>
    <Section title="Inputs">
      <Input placeholder="Enter text" />
    </Section>
  </ScrollView>
);

실무 팁

1. 시작은 단순하게: 처음부터 완벽한 구조보다는 필요에 따라 점진적으로 발전
2. 팀 컨벤션 우선: Atomic Design보다 팀이 이해하기 쉬운 구조가 중요
3. TypeScript 필수: 디자인 토큰과 컴포넌트 Props 타입 안정성 확보
4. Figma Variables 활용: Figma의 Variables 기능으로 디자인 토큰 관리하면 추출이 쉬움
5. 문서화는 코드 주석으로 시작: Storybook 도입 전에 JSDoc으로 먼저 시작